인터넷 시대에는 출시 속도가 소프트웨어 개발에서 가장 중요한 고려사항이다. 10년 전에는 한 프로젝트를 수년간 진행했고 프로젝트의 각 단계에도 수개월이 소요됐다. 요즘에는 대부분의 프로젝트가 수개월 정도의 규모이고, 각 단계의 진행 기간은 대부분 몇 주에 불과하며 심지어 며칠인 경우도 있다. 프로젝트 초기 단계에 소프트웨어 설계를 대규모로 진행하거나 요구사항을 상세하게 정의하는 것과 같이 프로젝트를 장기간에 걸쳐 계획하게 만드는 요인은 이제 사라졌다. 프로젝트의 각 단계를 진행하는 데 평균적으로 걸리는 기간보다 더 많은 시간이 필요한 작업도 더는 찾아볼 수 없다. 코드 프리즈와 몇 주가 소요되는 수동 회귀 테스트와는 이제 작별이다!
변화가 자주 생기면 문서는 금세 쓸모없어진다. 상세한 명세와 테스트 계획을 최신 상태로 유지하려면 너무나 많은 노력이 필요하고 이 같은 노력은 낭비로 여겨진다. 비즈니스 분석가나 테스터처럼 문서를 토대로 업무를 수행하던 사람들은 주 단위의 이터레이션이라는 새로운 시대에 어떻게 일해야 할지 혼란스러워 한다. 문서가 부족해도 상관없다고 생각하는 개발자는 필요하지 않은 기능을 유지보수하거나 재작업하는 데 시간을 낭비하게 된다. 방대한 계획을 세우는 게 아니라 잘못된 제품을 만드느라 시간을 허비하는 것이다.
지난 십 년간 소프트웨어 개발 업계에서는 기술적인 실천법과 높은 품질을 보장하기 위한 아이디어에 집중했고, “올바른” 방식으로 소프트웨어를 개발하기 위해 노력해왔다. 하지만 제품을 올바르게 만드는 것과 올바른 제품을 만드는 것은 다른 문제다. 성공을 위해서는 둘 다 필요하다.
올바른 제품을 효과적으로 만들려면 소프트웨어 개발 실천법에서 다음과 같은 사항들이 보장돼야 한다.
- 이해관계자와 개발팀원 모두가 제품 인도에 필요한 사항을 동일한 방식으로 이해한다.
- 개발팀은 명확한 명세를 통해 모호함 및 기능상의 차이에 따른 불필요한 재작업을 하지 않는다.
- 객관적인 수단을 통해 단위 작업이 완료된 시점을 측정한다.
- 문서가 소프트웨어 기능과 팀 구조 측면 모두의 변화를 촉진한다.
전통적으로 올바른 제품을 만들려면 방대한 기능 명세, 문서화 그리고 오랜 기간에 걸친 테스트 단계가 필요했다. 하지만 요즘처럼 주 단위로 소프트웨어를 출시하는 시대에는 이런 방법이 통하지 않는다. 따라서 다음과 같은 해결책이 필요하다.
- 지나친 명세화는 피한다. 실제 개발에 들어가기도 전에 변경될지도 모르는 세부 사항을 정의하느라 시간을 허비하지 않는다.
- 시스템이 수행하는 내용을 설명하는 신뢰할 만한 문서를 만든다. 그러면 시스템을 쉽게 변경할 수 있다.
- 명세에 정의된 대로 시스템이 실행되는지 효율적으로 점검한다.
- 최소한의 유지보수 비용으로 문서를 적절하고 신뢰할 수 있게 유지한다.
- 앞으로 수행해야 할 작업에 관한 정보를 적기에 공급할 수 있게 모든 것을 짧은 이터레이션과 흐름 기반의 프로세스[^1]에 맞춘다.
[^1]: (옮긴이) Flow-based software development(FSD)라고도 하며 lean, pull-based, kanban이라는 이름으로도 알려져 있다. FDS는 워크플로우 상태에 따라 작업 개수(WIP; Work in progress)를 제한한다. 반면 스크럼은 이터레이션별로 작업 개수를 제한하기 때문에 Timebox-based development라고 한다(이 책에서는 짧은 이터레이션 방식이라 언급). 전통적인 폭포수 모델은 구조적 개발 프로세스라고 한다.
처음에는 이러한 목표가 상충하는 듯해도 대부분의 팀이 이 목표를 성공적으로 달성하고 있다. 이 책을 쓰기 위해 50여 개의 프로젝트와 그러한 프로젝트를 수행한 30개 팀을 인터뷰하면서 패턴과 공통적인 실천법, 그리고 이러한 실천법의 기반이 되는 원리를 찾을 수 있었다. 그리고 프로젝트에서 공통적으로 발견한, 소프트웨어를 만드는 좋은 방법 중 하나는 바로예 제를 활용한 명세다.
예제를 활용한 명세는 팀이 올바른 소프트웨어를 만드는 데 이바지하는 프로세스 패턴들을 일컫는다. 팀에서는 예제를 활용한 명세를 통해 짧은 이터레이션 또는 흐름 기반의 개발에서 변경을 효과적으로 적용하는 데 필요한 만큼의 문서만 작성하면 된다.
예제를 활용한 명세의 주요 프로세스 패턴은 다음 장에서 소개한다. 1장에서는 예제를 활용한 명세의 이점을 설명한다. 여기서는 예제를 활용한 명세의 형식을 활용해 예제를 활용한 명세의 이론적인 사례를 만들어내는 것이 아니라 예제를 활용한 명세의 이점을 경험한 18개 팀의 실제 사례를 제시한다.
시작하기에 앞서, 프로젝트에서 어떤 아이디어 하나가 미치는 영향이나 효과만 따로 떼어낼 수 없음을 강조하고 싶다. 이 책에서 소개하는 실천법은 (테스트 주도 개발, 지속적인 통합, 그리고 사용자 스토리를 활용한 계획 수립과 같이) 이미 확립된 애자일 실천법이 효과를 발휘하는 상황에서 유용하고 애자일 실천법의 효과를 더욱 강화한다. 패턴은 다양한 상황에 있는 프로젝트를 고찰할 때 드러난다. 인터뷰를 한 팀 중에는 예제를 활용한 명세를 도입하기 전부터 애자일 실천법을 활용하던 팀도 있었고, 애자일 실천법을 도입하면서 예제를 활용한 명세를 도입한 팀도 있었다.
대부분의 팀은 스크럼(Scrum)이나 익스트림 프로그래밍(XP; Extreme Programming) 같은 이터레이션 기반 프로세스나 칸반(Kanban) 같은 흐름 기반 프로세스를 활용하고 있었다. 하지만 일부는 어떤 기준에서도 애자일이라고 볼 수 없는 실천법을 활용하고 있었다. 그럼에도 대부분의 팀이 예제를 활용한 명세를 도입한 후에 보고한 효과는 비슷했다.
- 변경 작업의 효율화: 시스템 기능에 대한 믿을 수 있는 정보의 원천인 리빙 도큐멘테이션(living documentation)[^2]을 통해 잠재적 변경이 미칠 영향을 분석하고 지식을 효과적으로 공유할 수 있었다.
- 제품 품질 개선: 시스템에 대한 기대를 명확하게 정의하고 검증 프로세스를 효율적으로 개선했다.
- 재작업 감소: 명세를 중심으로 긴밀하게 협업하고, 시스템의 요구사항을 팀원 모두가 동일하게 이해할 수 있었다.
- 각 역할의 활동에 대한 효과적인 조율: 긴밀한 협업으로 제품 출시 흐름이 일정하게 진행됐다.
[^2]: (옮긴이) 원서에서 ‘시스템이 변경될 때 문서에도 그러한 변경사항이 즉시 반영될 수 있는 문서’, ‘실행 가능한 문서’를 지칭할 때 ‘Living documentation’이라는 표현을 사용하고 있다. 이것은 오랫동안 업데이트되지 않아서 쓸모 없게 된 문서가 아니라, 항상 최신 상태가 유지되어 신뢰할 수 있을 뿐더러 언제나 사용하고 실행해볼 수 있는 문서를 의미한다. 복합적인 의미를 담고 있는 용어이므로 우리말로 직역하기보다는 저자의 의도를 그대로 반영하기 위해 ‘리빙 도큐멘테이션’으로 그대로 옮긴다. 리빙 도큐멘테이션에 대한 자세한 내용은 3장을 참고한다.
이어지는 네 개의 절에서는 실제 사례를 통해 얻은 이점들을 하나씩 자세히 살펴본다.
