Jello's development blog

Jello's development blog

책 [The nature of software development]

뭔가 핫한 것 같아서 읽어보았다. 200 페이지도 안되는 적은 분량이라서 가볍게 읽을 생각이었지만, 각 페이지에 담긴 말들이 너무 가치있어서 머리에 되새기면서 읽어야 했다.

이 책의 저자인 론 제프리스는 애자일 선언문 작성에 참여했고, 50년차 개발자이다. 초창기부터 애자일과 함께했고, 애자일 개발 방법론의 발전에 기여한 사람이다. 책에서는 가치, 작동하는 소프트웨어, 피처 단위라는 말이 굉장히 많이 나오는데, 모두 애자일스러움을 강하게 풍기는 단어들이다. 이 책은 어떻게 하면 팀이 가장 효율적으로 소프트웨어 개발을 할 수 있을지에 대해서 속 시원하게 정리해 놓았다.

우리는 무언가를 만들기 전에 먼저 가치를 찾아야 한다. 가치는 우리가 원하는 것이다. 예를 들면 행복해하는 유저, 엄청난 돈 등이 될 수 있다. 우리는 이 가치를 위해서 개발을 하는 것이며, 가장 우선시 되어야 한다. 개발을 하다 보면 이러한 가치를 후순위로 밀어버리고 변질되는 경우가 많다. 따라서 항상 우리라는 공동체가 무엇을 위해서 개발을 하고 있는지 느끼고 있어야 하고, 깨어 있어야 한다.

많은 경우에, 우리는 기획을 열심히 하고, 한번에 완성품을 만들려고 한다. 이것이 나쁘다는 것은 아니다. 하지만 그 중에 대다수가 엄청나게 크고 많은 내재된 문제에 맞닥뜨리고 코드를 뒤엎게 된다. 이는 팀원의 의욕을 저하시키고 포기하게 만든다. 또, 관리자(경영자)에게 현 상황이 어떻게 되어가고 있는지 정확하게 설명할 길이 없다.

그래서 피처 단위로 작동하는 소프트웨어를 만드는 것이 중요하다. 가치에 근거하여 만든 피처를 몇 가지 고르고, 1~2주 단위(스프린트)로 개발을 완료할 수 있을 때까지 피처를 작게 쪼갠다. 그리고 가장 많은 가치를 전달해 줄 수 있는 순서대로 하나의 피처 단위로 개발을 하고, 작동하는 소프트웨어를 만들어야 한다.

하나의 피처가 완성되었다면(테스트까지 통과해야 한다, 리팩토링도 꾸준히) 다른 피처를 개발하는 도중에 에러가 발생해도 문제의 범위는 획기적으로 줄어들게 된다. 따라서 피처 단위 개발 시에 내재된 에러의 깊이는 그리 깊지 않다. 물론 테스트는 항상 사용자 관점에서 작성해야 한다.

이렇게 차근차근 기능이 덧붙여지는 결과물을 눈으로 직접 본다면 관리자와 개발자는 뿌듯함을 느끼게 될 것이다. 또한 장기적으로 버그의 수가 일정하게 유지되어 워터풀 방식보다 더 빠르게 개발을 완료할 수 있다. 개발 중에 외부나 내부의 변화로 인해서 가치가 바뀌어도 빠르게 대응할 수 있다.

압박이나 과한 업무는 독이 될 뿐이다. 개발자는 시간을 맞추기 위해서 품질이 낮은 코드를 작성하게 되고, 리팩토링도 하지 않고, 테스트도 자신의 입맛대로 작성하게 되기 때문이다. 이는 점점 쌓여서 언젠가 큰 에러로 드러나게 된다.

하지만 위에서 말한 방법과 똑같이 하기는 매우 어렵다. 회사의 사정에 따라서 경험이 없는 기술을 이용하는 프로젝트에 투입될 수도 있고, 압박이 들어왔을 때 테스트를 엄격하게 작성할 수 없을 수도 있다. 정치적인 싸움이 될 수도 있다. 그 외에도 수많은 요인들이 일정을 딜레이되게 만든다.

비록 짧은 개발 경력이지만, 내가 지금까지 여러 개발 팀 안에 속해 있으면서 무언가 답답했던 것들, 하지만 해결책을 찾을 수 없었던 것들에 대한 답이 여기에 모두 있었다. 위처럼 하기는 어렵더라도 정답에 가까운 가치관이 정립된 느낌이다. 그것만으로도 큰 수확이었다고 생각한다. 친구들이나 다른 개발자들에게 추천해주고 싶은 책이다.