편한마음으로 쉽게 애자일은 이렇게 쓰는거구나 이해를 해볼 수 있었던 기회주는 책이라고 생각해주는 책이라고 생각합니다.

모든 챕터들이 길지 않고 중요한 부분은 볼드체로 처리한게 보기가 좋게 편집이 된거 같습니다.

책의 분량도 적지만 그렇다고 내용이 부실하거나 하진 않고 핵심만 잘 설명이 된거 같습니다.

옆에 두고선 여러번 읽으면서 채득을 천천히 해나가야 할 책인거 같습니다.

출처: http://digitalbourgeois.tistory.com/2 [효성이 사색공간]

책을 읽고 이렇게 독후감(?)을 쓰는게 얼마만인지.. 초등학교 방학 숙제로 독후감을 쓴 이후 처음인 것 같다.

책을 그 동안 많이 읽은건 아니지만, 그래도 나름 책을 조금씩은 읽었는데.. 내가 그동안 어떤 책을 읽었고, 어떤 내용들을 배울 수 있었는지.. 시간이 흐르면 다 잊혀지는것 같아 이번에는 이렇게 글로써 내가 읽은 책에 대해 조금 끄적거려 보려 한다.

첫 느낌

"엇! 왜 이렇게 얇아?" 이것이 내가 처음 책을 받아들고 들었던 생각이다. 아마 이 책을 처음 받고 많은 분들이 나와 비슷한 생각을 하지 않았을까.. 책을 펼쳐들고 또 한번 놀랐던건(놀랐다기 보단.. 어라? 느낌 정도..ㅎ) 다른 애자일 관련 서적과는 다르게 삽화가 아주 많아서 일단 "부담없이 읽을 수 있겠구나~" 였다.

결론적으로.. 2~3일이면 다 읽을줄 알았던 이 책을 완독 하는데 2주 정도 걸렸지만, 이건 오롯이 개인적인 사정으로 시간이 많이 걸린거지 절대 책이 부담되어 그런것은 아니었다.

저자가 말하려고 하는 것은?

이 책은 앞에서 잠깐 언급했지만 애자일에 대해 얘기한다. 이 책을 알기전엔 몰랐지만 책의 저자가 애자일 선언문에 참여한 17명 중에 한 명이며, 익스트림 프로그래밍의 창시자 중 한 명이다. 이러한 화려한 경력을 가지신 분이 책을 썼다면 무슨 말을 하고 싶어할지 대충은 짐작가지 않는가? 당연히 효율적인, 합리적인 소프트웨어 개발에 대한 얘기이며, 이는 결국 애자일이다.

책도 두껍지 않고, 부담스럽지 않아 애자일 입문서로 좋을 것 같다. 하지만 저자가 이 책에서 말하려는 것이 "이것이 애자일이다!" 같이 애자일에 대한 정의는 아니다. 그것보다는 어떻게 효율적으로 + 완성도 높은 소프트웨어를 개발할 수 있을까? 에 더 집중하고 있다. (사실 이게 애자일에서 말하는 핵심인 것 같긴 하지만.. 내가 애자일 전문가는 아니라 잘 모르겠다 ^^;;)

이 주제에 대해 저자가 말하고 싶어하는 큰 맥락은 다음과 같이 요약할 수 있을 것 같다.

• 피처(feature) 단위 개발
• 항상 소프트웨어를 가치있는 상태로 유지하기
• 그리고 조직 관리

또한, 일방적으로 정보를 알려주기 보다는 독자가 실제 소프트웨어를 개발하면서 경험 했던 것들을 바탕으로 어떻게 하면 좋은 소프트웨어를 개발할 수 있을지.. 생각할 거리(?)들을 툭툭~ 던져 준다. 
저자가 독자에게 하는 질문들을 토대로 그 질문들에 대한 답을 찾다보면 독자는 자기만의 노하우를 터득할 수 있는 좋은 기회가 될 것이라 생각하지만.. 개인적으로 거기까진 귀찮아서 패스~ ㅋ

어떤 사람들이 읽으면 좋을까?

이 책을 읽는다고 해서 하루 아침에 좋은 소프트웨어를 개발할 수 있는 것은 물론 아니다. 다만, 저자의 경험과 지식을 조금 전수(?) 받을 수 있는 기회를 가질 수 있다.

하지만, 이 지식이라는 것은 결국 활용을 해봐야 본인의 것으로 만들 수 있는 것임을 많은 사람들이 알고 있을 것이다.

따라서, 지금보다는 좀 더 효율적으로 완성도 있는 소프트웨어를 만들고 싶은 팀이라면, 팀원 모두(프로젝트 관리자 + 개발자 + 기획자) 이 책을 읽고, 거침없는 토론의 시간을 가진다면, 그 팀에 맞는 방법들을 찾아나가는데 이 책의 지식이 큰 도움이 될 수 있으리라 확신한다.

이 책 뿐만 아니라, 시중에는 좋은 소프트웨어를 만들기 위한 지침서들이 아주 많이 나와있다. 내가 이 많은 책들을 다 아는 것도 아니라 장담하긴 힘들지만, 아마도 이 책이 다른 많은 지침서들 중에서 좋은 입문서 정도는 되지 않을까 생각한다.

마크다운 문법이 적용 된 글을 읽고 싶으신 분은 여기로..

책을 받았을 때 첫 느낌은 음.. 짧다.. 였습니다. 다 읽고 나서 전체 페이지를 확인해보니 187p 정도의 분량이더군요. 이 책의 특성상 그림이 많고 글이 한 페이지가 가득 차는 케이스가 적다는 걸 생각해보면 사실 90p 정도의 분량이라고 보셔도 됩니다. 그래서 책을 받고 '아 오늘 다 읽고 내일 끝내야지'라고 생각했었습니다. 근데 읽다 보니 다 읽는데 일주일 정도는 걸렸습니다. 

 집중해서 읽지 않았기 때문은 아닙니다. 책을 읽을 때마다 '책을 읽어야지~' 라고 생각하고 일부러 시간을 내서 읽었습니다. 다만 한페이지 한페이지 넘어가기가 쉽지 않더군요. 

## 책을 읽는건가..

 우선 이 책의 저자는 처음부터 하나를 큰 원칙을 강조하는데 바로 간결성입니다. 그리고 그건 책 전반에 걸쳐 '피'라는 중심 주제와 연결돼서 계속 표현이 됩니다. 근데 이 간결성은 책을 쓰는데도 꽤 영향이 컸던 거 습니다. 하나의 꼭지는 보통 그림을 포함하여 한 페이지를 넘어가지 않고 종결이 납니다. 그리고 매우 높은 확률로 독자의 의견을 물으면서 끝납니다. 

 ＞ 압박이 몰고 오는 나쁜 점은 무엇인가요? 결함이 늘어난 적이 있나요? 일정이 지연된 적은요? 유능한 사람을 잃은 적이 없는지 생각해봅시다. 압박이 정말 도움이 된 적이 있나요? 그렇다면 같은 효과를 낼 수 있는 다른 방법도 생각해봅시다. 

 뭐 이런 식으로 끝나는 거죠. 그리고 이런 물음에 생각하다 보면 좀처럼 다음 페이지로 넘어가기가 어렵습니다. 전에 겪었던 정말 말도 안 되던 프로젝트가 생각나면서 화도 나더라고요. 어떻게 단 하나의 주제도 제대로 진행한 것이 없네.. 아, 이 책 들고 가서 그때 pm에게 던져주고 싶다.. 뭐 이런 생각도 났습니다. 그렇게 생각을 정리하고 다음 페이지를 가보면 저자의 의견을 제시하죠. 의견의 끝은 이렇게 하세요. 보다는 그럼 또 이건 어떤 거 같은가요? 이런 식입니다. 꼬리의 꼬리를 물고 생각하다 보면 책이 짧다는 생각은 없어졌습니다. 

## 읽는데 계속 빡침

저는 개인적으로 전에 겪었던 최악의 프로젝트 하나가 계속 생각이 났습니다. 정말 소름돕게도 '이 책에서 이런 경험은 없었나요?'' 했던 모든 부분에서 그런 경험이 그 프로젝트에서 있었거든요.. 그래서 전반적으로 조금은 흥분한 채로 읽기도 했었습니다. 뒷골이 땡기기도 했습니다. 그러면서도 그때 이러면 어땠을까.. 저랬으면 좀 나아지지 않았을까.. 몰입해서 생각하기도 했었습니다. 프로젝트 경험이 많은 분들일수록 더욱 생각할 것들이 많고 더 많이 얻어갈 수 있을 것 같습니다. 

## 줄거리는 패스

책의 전반적인 내용은 소개하지 않으려 합니다. 개인적으로 너무 재밌게 읽었는데 사실 책 자체가 재밌었다기보단 위의 이유로 좋았습니다. 책의 내용은 사실 화두 중심이기 때문에 책의 전반적인 내용을 밝히는 게 약간 영화 스포일러 하는 것 같아 꺼려지네요. 몇 까지 키워드만 밝히자면.. 

이 책은 애자일을 설명하고 전파하는 책이 아닙니다. 저자가 애자일 선언문에 기여한 만큼 전체적인 내용이 애자일과 연관이 없어 보이진 않습니다. 하지만 애자일이라는 단어는 거의 나오지 않고 연관 지으려 하지도 않습니다. 게다가 제가 알고 있던 애자일과는 꽤 다른 부분이 많습니다. 그냥 프로젝트에 대해 어떻게 하면 더 잘할 수 있을까를 차곡차곡 얘기하고 토론해 나가는 형식입니다. 그러다 보면 어디선가 들었던 그리고 언젠가 어설프게 애자일이랍시고 시도해보기도 했던 그런 내용이 등장하기도 합니다. 하지만 애자일을 공부하고자 하는 분과는 맞지 않는 책이라고 생각합니다.

또 책의 내용이 엄청 쉽습니다. 번역하신 분이 잘하신 건지 원래 문체가 이렇게 짧고 간결했었는지는 알 수 없지만.. 글의 호흡이 짧고 주저리주저리 설명하지 않기 때문에 이해가 금방금방 됩니다. 근데 '이 책 전체를 관통하는 주제가 쉬운가?'' 라고 묻는다면 절대 그렇지 않습니다. 소프트웨어 프로젝트를 어떻게 성공적으로 수행할 것인가 하는 .. 여러 개발자와 운영자들이 고민하고 실패했던 바로 그 주제입니다. 이런 어려운 주제를 술술 읽히도록 표현한 것도 인상 깊었습니다. 책이 쉬어 책을 읽는 시간 동안 더 많은 시간을 생각하는데 쓸 수 있기도 했습니다. 

제가 계속 생각할 거리를 던져준다고 표현하고 평을 해놔서 이런 오해가 생길 수도 있을 것 같습니다. '아, 이 책은 내용은 없고 그냥 질문만 하나 보다. 내가 책을 샀는데 그 가치를 내가 만들어야만 하는 책인가 보네..' 이 책의 가치는 독자가 만들어 가는 것이 맞다고 생각하긴 합니다만 무작정 화두만 던지고 내용이 없는 책은 절대 아닙니다. 오히려 그 화두를 끌어 내는 과정에서 프로젝트의 전반적인 문제점과 그 문제점이 생겨나는 원인 그리고 저자가 생각하는 방향들이 아주 논리적이고 탄탄하게 나옵니다. 

## 책은 역시 경건한 마음으로.. 

앞으로 이 책을 읽을 분들에게 조언하자면 꼭 조용한 곳에서 맛있는 커피 한잔과 집중해서 천천히 읽어보길 바랍니다. 계속 강조하듯 이 책의 본질은 그냥 '읽음'에만 있지는 않다고 생각합니다. 제가 만약 요즘 개인적인 일들로 생각이 많은 시기가 아니었다면 그래서 집중해서 읽으려 하지 않고 그냥 지하철에서 쓱쓱 지나가며 읽었다면 정말 그저 그런 책이라고 생각했을지도 모르겠습니다. 그런 분이 없었으면 합니다. 만약 자신이 '아 난 그럴 거 같은데?' 라고 생각한다면 절대 구매하지 않길 추천해 드립니다. 그렇게 읽기엔.. 90p에 16,000원입니다. ... 그냥 치맥 사드세요.

## 이런 분이 읽으면 좋을 거 같네요

개인적으론 신입 개발자보단 프로젝트 경험이 있는 분들이 읽을 때 더 재밌을 것 같습니다. 이 책은 개인의 경험과 맞물려서 시너지가 나니까요.. 특히 수많은 잘못된 프로젝트에 투입됐었던 사람들 그중에서도 리더분들께는 꼭 추천해드리고 싶네요.. 음 누굴 특정하는 건 아니지만, 윗분들도 제발 좀 읽어주셨으면 좋겠습니다.. (그대로 해달란 건 아닙니다. 그래도 할 수 있을 것 같지도 않구요.. 최소한 읽고 고민이라도 했으면 좋겠네요.. 제발 좀요..) 개인적으로 프로젝트를 하면서 좋은 시도를 계속하려고 노력하는 프로젝트를 알고 있습니다. 근데 뒤로 들려오는 소리는 그리 썩 성공적이지만은 않더군요. 노력해도 모두가 만족하며 성공하는 프로젝트를 만들기가 그리 어려운데.. 이런 시도도 없이 프로젝트를 이끌려 하는 것이 얼마나 무모한가에 대해 생각해보게 됩니다. 

## 끝

책을 읽으면서 재밌었지만 즐겁지만은 않았습니다. 걱정이 앞서기도 합니다. 내가 이걸 이렇게 고민하면서 읽는다고 뭔가 나아지긴 할까? 앞으로 들어가게 될 프로젝트에서 과연 이렇게 할 수 있을까? 아니라면 내가 바꿀 수 있을까? 등등.. 참 정말 너무나 어려운 주제인 거 같습니다. 이 책이 꼭 정답인지도 잘 모르겠습니다. 몇몇 부분은 저자가 마치 이게 답인 것처럼 단호하게 '이렇습니다.'라고 말하는 부분이 있기도 하지만 그런 프로젝트를 해보지 않아서 그럴 수도 있으나 제가 겪은 현실과는 너무 동떨어져 '정말 이렇게 할 수 있을까?' 하는 파트도 몇몇 군데 (사실 꽤 많이) 있었습니다. 그래도 이런 것에 대해 저뿐만 아니라 수많은 개발자가 계속 생각하다 보면.. 언젠간 긍정적인 방향으로 나아갈 수 있지 않을까 생각해봅니다.

안녕하세요, 오늘은 한빛미디어에서 출간한 따끈따끈한 번역본 론 제프리스의 The Natur of Software Development (이기곤 옮김)을 리뷰해보고자 합니다.

＜요로콤 생기신 아저씨 (할아버지) 입니다＞

해당 저자 론 제프리스는 우선 애자일 선언 (Agile Manifesto)에 참여한 인물로써, 현대 소프트웨어 개발론에서 빼놓고 이야기 할수 없는 애자일 방법론을 정립하고 이를 전파하는 대표적인 인물입니다. (하지만 무려 1939년생 ㅎㅎ)

그렇기 때문에 자연히 책 또한 애자일에 관한 내용으로 가득가득 차 있습니다.

책은 크게 2부로 나뉘게 되며, 1부는 어떻게 소프트웨어 개발을 잘 할 수 있을까. 그 본질에 대한 의문으로 부터 시작해서 어떻게 개발을 해야하는가에 대하여 이야기를 하고 있습니다. 2부에서는 1부에서 파악한 "우리가 무엇에 대하여 집중을 해야하는가"에서 시작하여 '프로젝트 관리자'로서, 또는 '비즈니스 관리자' 어떻게 개발팀에 활기를 불어넣어 제품을 잘 만들 수 있을까에 대하여 이야기 하고 있습니다.

어? 뭔가 이상한데..

그렇습니다.

이 책은 개발자를 위한 책이 아닙니다. 아 물론 개발을 겸 하는 PM 분들은 읽어볼만한 책입니다.

저도 사실 이 책을 개발자들이 어떻게 하면 더 잘 개발을 할 수 있을까에 관하여 집필을 하고 있는줄 알았는데 그건 아니었더군요. ㅎㅎㅎㅎ

책 사진의 정면 샷 입니다. ㅎㅎㅎ 정말 외국 책처럼 생겼습니다. ㅎㅎ 아 이건 정말 딱 봐도 외국에서 만들었으니 외국 표지를 채택 했습니다 라는 느낌입니다.

책의 두께 또한 굉장히 얇습니다. 약 180페이지 정도가 되는 내용이고, 한 페이지에도 글이 꽉차지 않아서 참 좋습니다.. 읽는데 부담이 없죠. 하지만 내용은 그만큼 압축적인 내용이 많아 한 챕터를 읽고 쭉 한번 생각을 해보면 좋습니다.

1부에서는 우리가 개발하는 S/W에서 가치란 무엇인가에서 부터 시작합니다.

'가치'란 우리가 원하는 것. 이라고 정의합니다. 다시 말하자면 사용자가 원하는것, 나의 상사가 원하는것, 오너가 원하는 것 모두 가치가 될 수 있다는 뜻이지요. ㅎㅎ

사람이들이 원하는 것은 곧 피처로의 매핑 혹은 여러개의 피처가 모여서 하나의 가치. 원하는 것이 되는 것이지요. 이렇게 피처를 기반으로 하여

"돌아가는 소프트웨어를 만들것"

이 이 책에서 주장하는 주요 골자이며, 애자일 선언문에서도 나오게 되는 내용의 기준이 됩니다. 즉, 애자일 방법론과 같이 기획 -＞ 설계 -＞ 구현 -＞ 테스트 의 사이클을 빠르게 반복하여 제품을 점진적으로 완성하는 애자일 방법론과 같은 기조를 띄고 있다고 말 할 수 있습니다.

약 2주 마다 하나의 피처를 완성할 수 있도록 피처를 분할하고, 해당 피처를 완성할 수 있도록 개발팀을 운영하는 것이죠.

＜ 애자일 개발 도식 : 그림 출처 http://blog.rightbrain.co.kr/?p=5810 ＞

실제로 애자일 개발 방법론에 대하여 이야기하고 있는 책도 많지만, 이번 책은 저자가 실제 애자일 선언에 참여하였다는 것이 다른 책들과 조금 다르다고 할 수 있을것 같네요. (물론 다른 책에도 애자일 선언에 참여한 이들이 저술한 책도 있지만..)

프로젝트 관리, 애자일 방법론에 대하여 실질적인 코치를 하고 있지는 않습니다. 하지만, 현재 우리나라를 IT 분야를 나름 제패하고 많은 이들이 선망하는 기업 (K사라던가.. L사라던가..)에서는 실제 들어오는 이야기는 이와 같은 방법론이 적용하고 있습니다. 이를 비추어 볼 때, 이전 폭포수 모델을 도입하고 있는 조직에서는 기민함을 위해 이 책을 기점삼아 방법론을 적용하는 것도 나쁘지 않을것이라 생각합니다 :)

출처: http://junolab.tistory.com/46 [JunoLab]

노자가 그랬는가 태극권에서 그러던가 극의를 깨치게 되면 그 자신이 아무것도 없음이요 물이 곧 아가 되고 아가 즉 물이되는 경지에 이른다.. 하는 그런 뭔가 동양 고대철학의 견지에서 써내려간 소프트웨어 개발 프로세스에 대한 가이드북이라고 생각하고 읽으면 좋다 무척 작고 얇고 가벼운 책인데 그 내용만큼은 대단히 무게감이 있다 혹자는 누구나 뻔히 아는 얘기 실무에 투입되고 한 두달이면 그냥 체득할 이야기들이라고 치부할 수 있겠지만 짬이 쌓이고 쌓여 아키텍트의 반열에 이를라치면 결국 이런 처음의 이론으로 돌아갈 수 밖에 없다.. 도커 열풍 뒤로 그 불길이 사그라들기는 커녕 날로 거세지는 DevOps의 바람에 함부로 휘날리지 말고 이 책으로 중심을 잡을지어다..

전에 일하던 스타트업에서 애자일-스크럼을 도입한 적이 있다. 3–4명의 소규모일때는 각자의 방식대로 일하다가 팀원이 10명 가까이 늘어나면서 하나의 제품을 통일성 있게 개발하고 관리하기 위함이었다.

애자일-스크럼의 장점은 진입장벽이 낮다는 점이다. 애자일 선언문을 한 번 읽어보고, 스크럼의 방법 및 원칙 몇가지를 숙지하면 당장이라도 시작할 수 있다. 이와 관련된 책만 해도 수십권이 넘어가지만, 대충 둘러봐도 다들 비슷한 내용인 듯 싶다. 당시 우리팀도 약간의 문서를 읽고 몇 번의 회의를 통해 배포 주기, 일정 관리 도구 등의 세부 사항을 확정한 뒤 바로 실행에 돌입했다.

애자일-스크럼의 단점은 탈출장벽(?) 또한 낮다는 점이다. 워낙에 간결한 방법론이다보니 현실 세계에서 벌어지는 수 많은 난관을 어떻게 헤쳐 나가야 하는지 알려주지 않는다. 점점 발언권이 센 누군가의 의견이 강하게 반영되면서 어느샌가 ‘이건 애자일이 아니야…’라는 생각이 모두의 마음 속에 자리잡게 된다.

현실의 난관에는 많은 것들이 있지만 대체로 아래와 같이 공통적인 범주 안에 있을 것이다.

당시에는 이런 문제들에 대해서 어떻게 대처해야 하는지 잘 몰랐고, 그렇게 애자일에서 멀어지면서 ‘원래 애자일이 쉬운게 아니야.’ 란 생각만 굳게 되었다.

그 때 이 책과 함께였으면 어땠을까라는 생각이 든다. 새롭게 애자일한 개발방식을 적용하려고 하는 모든 사람들이 다 같이 이 책을 읽고 어려운 일이 있을 때마다 같은 방향으로 해결책을 모색했다면 더 나은 개발문화가 정착되지 않았을까 하는 생각이 들었다.

이 책은 크게 1부와 2부로 나뉘어져서 1부는 애자일의 기본 원칙을 설명하고 2부에서는 좀 더 각론으로 들어가 위에서처럼 마주칠 수 있는 어려움들을 어떻게 해결할 수 있을지 부연해준다.

1부는 여차 애자일 서적, 자료들과 크게 다를 바 없는 내용이다. 다만 책의 저자가 애자일 선언문 작성자 중 한명이며 애자일 철학을 구체화시킨 Extreme Programming의 창시자라는 점을 상기한다면 더욱 신뢰감있게 다가오는 것이 사실이다.

하지만 이 책의 백미는 2부에 있다. 경영진, 제품 책임자, 개발자 모두에게 생길 수 있는 의문들에 대해 대답해준다. 적어도 모든 팀원들이 이 책을 읽었다면, 최소한 같은 방향을 바라보며 해결책을 구상할 수 있을 것이다. 그리고 위의 문제들에 대해서 이렇게 대처하지 않았을까.

=＞ 처음엔 느려보여도 나중에 테스트, 버그 수정할 시간을 지금 쓴거에요. 일단 당장 배포 가능한 제품이잖아요.

=＞ 그럼 한 번에 끝낼 수 있는 분량으로 쪼개보고 그 중 가장 중요한 것 부터 만들죠.

=＞ 지금 만드는게 현재 가장 중요한 기능이에요. 그것보다 중요한게 확실한지 다시 한번 판단해 볼 필요가 있어요.

=＞ 가장 중요한 기능의 아주 작은 부분이라도 동작하도록 추가하고 해당 부분에서만 리팩토링하면서 개선해야해요.

이 책에 애자일을 성공으로 이끄는 모든 것이 들어있지는 않다. 그래도 최소한 성공적인 애자일을 위해서는 테스트 주도 개발 능력이 필수적이고 제품 개발을 위해 필요한 핵심 기술이 모두 한 팀에 있어야 하며, 무엇보다 제품 개발의 가치를 모든 팀원들이 공유하고 있어야 한다는 점은 확실하게 알게 되었다.

책 내용에 따라 쓰여진 듯한 책입니다.

많은 얘기를 하기보다 ‘소프트웨어 개발을 이런식으로 풀어간다’라고 얘기하고 있습니다.

개발 환경이나 상황이 워낙 천차만별이라서 읽는 사람에 따라 읽은 뒤 반응은 다를 수 있을 것 같습니다.

끝까지 읽는데 많은 시간이 들지 않지만, 읽고 나면 '쉽지 않네'라는 생각이 듭니다.

개발을 위한 팁이나 조언은 없습니다.

개발하며 만나는 다양한 상황과 단계, 대응과 고민, 방향은 있습니다.

읽은 뒤에도 뒤적거리게 될 것을 예상했는지

찾기 쉽도록 각 장이 왼쪽 페이지부터 시작합니다.

작동하는 소프트웨어를 보여주세요.

간결함을 유지하면서 확장과 개선을 반복해야 합니다.

테스트와 리팩토링이 반드시 필요하겠죠?!

너무 어려울 것 같지만 야영지 규칙을 따르면 됩니다.

한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다.