개발하는데 도움이 될 것 같아서..
[서평] The nature of software development
[책] The nature of software development"가치를 얻기 위해 작은 단위로 개발하여 자주 배포하라, 이것이 이 책의 전부..."
이 책은 “올바르게 소프트웨어를 개발하기 위한 안내서”라는 한 문장으로 소개되고 있다. 개발자 입장에서 안내서라는 말은 가이드북, 지침서로 방법을 안내해 줄 것이라 기대하게 된다.
허나 책을 읽고 나면 책에서 제시한 인사이트들로 인해 생각을 하는 시간을 가지게 되긴 하지만, 다소 허무한 감이 없지 않다. 이 책이 말하고자 하는 것은 위의 한 문장이 전부고 이를 다르게 설명하는 것이 반복되기 때문이다.
가치, 우리가 원하는 것
책의 내용은 가치라는 것에서 시작한다. 여기서 가치는 우리가 원하는 것으로 해석하면 최종 산출물, 결과 정도로 해석된다. 또 가치는 소프트웨어를 배포할 때 나타나고 얻을 수 있는 것의 의미로 표현된다. 그리고 가치를 얻기 위해서는 작은 단위의 피처로 개발할 것을 권한다. 여기서 피처는 조각으로 표현되고 이 조각은 기술 조각이 아닌 사용자가 이해할 수 있는 조각이다. 이렇게 이 책에서는 작은 피처를 자주 배포함으로 최고의 가치를 얻을 수 있다. 즉, MMF* 개발로 빠른 주기로 MVP*를 배포하여 가치를 얻는다라고 말하고 있다.
*MMF: Minimum Marketable Feature
*MVP: Minimum Value Product
피처 단위의 개발로 얻을 수 있는 것
작은 피처 단위를 자주 배포함으로 최고의 가치를 얻는다. 그렇다면 피처 단위의 개발은 어떻게 해야 하는 것일까? 책에서는 여기서 두 가지만 강조한다. 피처는 테스트가 아니라는 점과 중요도가 높은 피처부터 개발하라는 것이다. 테스크라는 단위의 개발이 되면 작은 단위의 피처 개발이라고 할 수 없고 피처는 작고 세분화될수록 좋다는 것이다. 또 중요도가 높은 피처부터 개발하는 점이 중요하다고 한다. 블럭을 예로 들어 블럭의 높이가 중요도이고 넓이가 개발 자원(인력, 시간 등)이라고 하고 그림과 같이 나열했다. 두 가지가 모두 결국 끝에 만나는 것은 똑같을 것이지만 여기서 중요한 것은 중간에 대처할 수 있다는 차이이다. 높고 좁은 블럭. 즉, 중요도가 높은 피처로 개발하다가 다른 가치를 얻을 수 있는 방법이 생기면 유연하게 새로운 피처 개발로 전환해 더 높은 높이로 쌓아진 블록을 만들 수 있다. 더 높은 가치를 얻을 수 있다는 말이다.
추가로 피처 단위의 개발 과정에서 중요한 점으로는 피처 단위의 개발은 단순 코딩이 아니라 피처마다 코딩-테스트-리팩토링이 이루어져야 한다는 것이다. 피처가 하나의 개발 단위가 되다 보니 자연스러운 모습이고 전체적인 개발 과정에도 도움이 된다. 그 이유는 전통적인 Waterfall 방식으로 분석, 설계, 코딩, 테스트라는 과정을 거치면 마지막 테스트쯤에서 곡선이 위로 솟구치는 모습을 볼 수 있고 이러한 모습은 배포 지연이 될 수 있다. 그에 반해 피처 단위로 개발하면 코딩, 테스트, 리팩토링이 하나의 단위가 되고 피처 하나하나 개발되는 모습은 원만한 곡선이 된다는 이야기이다. 즉 전체적인 일정이 일정해지고 코드 또한 비교적 깔끔하게 구현해갈 수 있다는 결론이다.
마지막으로 유념해야 할 것
이렇게 피처에 대한 설명이 끝난 후에 몇 가지 유념해야 할 것으로 이 책은 마무리가 된다. 했던 이야기를 또 하는 느낌이지만 몇 가지를 정리해보면 아래와 같다.
1. 장기적 세부 계획은 불필요하다.
2. 추정은 위험하다.
3. 큰 목표는 자멸에 다가가는 길이다.
4. 짧은 주기마다 작지만 안전한 제품을 만들어라.
5. 반드시 있어야만 하는 피처와 있으면 좋은 피처를 구분하라.
6. 가장 높은 가치의 피처를 우선 개발하라.
7. 테스트와 수정은 완료 과정에만 있어선 안된다.
1~3은 자주 계획하고 다음 할 일을 정하라는 것으로 정리할 수 있고, 4~6번은 피처로 더 좋은 가치를 얻을 수 있다는 점을 나타내는 이야기로 정리할 수 있다.
이 책은 가치를 얻기 위한 피처 개발에 대한 이야기를 이렇게 저렇게 반복해서 풀어내고 있다. 그 점에서 위에 내용은 이 책의 전부라고 해도 무방 할 것 같다. 그리고 개발자를 위한 서적처럼 나타나 있지만 후반부를 읽어보면 비즈니스 매니저나 경영자라는 말이 등장하며 개발을 어떻게 관리해야 하는지에 대한 점을 쓴 것으로 보아 이 책은 개발을 알아가고자 하는 계획은 세우는 부서에 있는 자에게 더 어울리는 책이 아닌가 싶다.
