가치 있고 동작하는 소프트웨어를 위한 <THE NATURE OF SOFTWARE DEVELOPMENT>

The Nature of Software Development - 간결하게, 가치 있게, 하나씩 완성하기
론 제프리스 지음, 이기곤 옮김 / 한빛미디어 / 2017년 1월

 책 제목이 무려 <THE NATURE OF SOFTWARE DEVELOPMENT> 다. 소프트웨어 개발의 본질이라고 번역할 수 있겠는데, 185 페이지의 얇은 분량에 본질을 담았다니 안 읽어 볼 수가 없다. 책 커버를 벗겨보면 안에 빨간 책표지가 나오는데, 제일 중요한 건 가장 앞에 나온다는 말을 충실히 지키기 위해서 인지 커버와 표지에 이 책의 가장 큰 핵심인 VALUE(가치)가 가장 높이 빛나고 있다.

 저자인 론 제프리스도 참여한 애자일 소프트웨어 개발 선언문과 책 내용은 큰 흐름을 같이 하는데, 책을 읽은 후에 같이 읽으면 큰 도움이 될 것 같다. 

(http://agilemanifesto.org/iso/ko/manifesto.html)

 책은 가장 핵심이라고 할 수 있는 가치에 대한 이야기로 시작한다. 

 어느 정도로 가치에 집중을 하자고 이야기하냐면 아직까지 프로젝트에서 정확한 추정을 중요하게 생각하는 상황도 많이 있음에도 극단적으로 모든 프로젝트에서 추정은 논란이 많고 어긋나기 마련인데, 기본적으로 사람이 추정 능력이 형편없고 과장과 비교에 대한 욕구를 갖고 있기 때문이므로. 아예 중요도를 낮추거나 배제하고 가치에 중점을 두어야 한다고 이야기한다.

 이렇게 중요한 가치란 무엇일까?

 간결하게 말하자면 가치는 우리가 원하는 것이라 한다. 

 그 가치가 무엇이 되었든 간에 소프트웨어 결과물이 필요하다면 그 가치를 실현하기 위해서는 지금까지와는 다른 새로운 조직, 마인드가 필요한 것이다. 이후 설명하는 내용이 새로운 조직에 필요한 방법과 마인드이다.

 먼저 만들어야 할 제품을 피처로 구분하고, 해당 피처는 그냥 세세하다기 보다 작고 의미가 있는 피처 단위로 만들고, 이 중 가장 필요한 피처만 모아 만든 간결한 제품 MVP를 가능한 빨리 개발하는 것이 중요하다. 가장 필요한 제품만 만들어서 출시를 하는 것은, 사용자가 원하지도 않은 제품을 오랜 기간 만들어 시간과 비용을 쓰는 것도 막을 수 있고, 올바른 방향으로 진행되고 있는지도 확인이 가능하다. 린스타트업 개념으로 이야기한다면 핵심가치를 구현한 제품 MVP의 빠른 출시로 시장의 반응을 보고 그 반응에 따라 피벗을 하는 내용과 일맥상통한다고 할 수 있다.

 즉 개발하는 동안 어떤 피처를 우선으로 할지 결정해야 하고, 가장 중요한 피처를 먼저 개발해야 하는 것이다. 이뿐 아니라 모든 피처들의 진행 상항은 완료, 미완료로만 중간은 허용하지 않고 투명하게 공유되어야 한다.

 그리고 이제부터는 문서가 아닌 모든 것은 작동하는 소프트웨어로 이야기되어야 한다. 예를 들어 지금까지 얼마나 개발이 진행되었나 궁금하다면, "작동하는 소프트웨어를 보여주세요."라고 요구하여 진행 상황을 알아야 한다. 그렇기 위해 피처 단위로 개발을 하고, 짧은 주기로 배포가 되어야 할 것이다. 실제로 동작하는 소프트웨어가 짧은 주기로 배포된다면 역으로 우리가 원하는 게 뭔지 깨달을 수도 있게 될 것이다. 

 책은 끈질기게 항상 가치에 집중하고, 항상 계획 단계부터 가장 가치 있는 것이 무엇인지 확인하고, 요청했던 가치가 어떻게 표현됐는지 잘 살펴보라고 이야기한다. 그렇기에 개발자 뿐만 아니라 개발 조직이 있는 회사의 경영자, 기획자, 개발자 출신이 아닌 소프트웨어와 관련된 창업을 희망하는 분들도 읽는다면 큰 도움이 될 내용들이다. 

다만 저자도 이야기 한 부분이지만, 이 책에 있는 내용 대부분이 너무 함축적이기에 어느 정도 경험이 없으면 쉽게 이해하기 어렵거나, 실제 업무와 회사에서 적용할 수 있는 의사 결정자가 아니라면 마음에만 품고 있어야 하는 내용일 수밖에 없는 한계가 있다. 하지만 조금씩, 하나씩 적용해볼 수도 있을 것이고, 여러분이 결정할 수 있는 순간이 올 때 가치에 집중하는 소프트웨어의 개발의 본질을 실현할 수 있을 것이다.

 끝으로 개발자라면 특히 모든 경영진들이 읽었으면 하는 내용이라고 생각할 내용을 덧붙인다.

 프로젝트가 기대했던 것보다 느리게 진행되고 있을 때 단순히 개발팀을 압박한다면 팀은 테스트를 거르고 그만큼 많은 결함이 생기게 된다.

 만약 개발팀이 품질을 떨어트린다면 더 많은 결함이 생길 것이고 오히려 일정도 지연되어, 가치가 떨어지게 된다.