24 큰 일괄작업의 낭비
성공적인 소프트웨어 신상품 개발가이드
소프트웨어 상품개발의 규모는 과잉개발, 출시주기와 밀접한 관련이 있다. 과잉개발을 하고 출시주기가 길수록 개발규모는 커진다. 예를 들어 꼭 필요한 80개의 기능을 한 번에 개발하는 것도 큰 개발이 될 수 있다. 물론 최악은 과잉기능 20개를 추가한 100개의 기능을 한 번에 개발하는 것이다.
에릭리스는 큰 일괄작업의 문제점을 봉투에 소식지를 넣는 것에 비교하여 설명했다. <The Lean Startup, 2012>
100개의 소식지를 접어 봉투에 넣을 때 소식지를 한꺼번에 접은 뒤 봉투에 넣는 방식과, 소식지를 개별로 접어 봉투에 넣는 것 중 어떤 방식이 효율적일까? 소식지가 봉투에 꼭 들어맞지 않는다고 가정해보자. 일괄작업 크기를 크게 잡은 진행방식에서는 이 사실을 마지막에 가서야 알 수 있다. 일괄작업 크기가 작은 진행 방식에서는 이 사실을 곧바로 알게 된다.
큰 일괄작업을 하는 배경에는 규모의 경제가 생산성을 높인다는 믿음이 있다. 이는 작업의 오류가 없다는 가정을 할 때 그렇다. 예를 들어 UX 디자이너가 전체 화면의 디자인을 한꺼번에 끝내고 개발팀에게 넘겨주는 것은 큰 일괄작업 방식이다. 디자이너의 관점에서는 몰입하여 한꺼번에 작업하는 것이 생산성을 향상시킨다고 생각할 수 있다.
아키텍처의 문제 또는 상품관리자와 잘못된 의사소통으로 오류가 있는 디자인 전체를 개발팀에 넘겨준 뒤 다른 프로젝트의 디자인 업무를 수행하는 도중에 오류도 발견되고, 변경사항도 발생한다면 어떻게 될까? 이런 경우엔 두 프로젝트의 디자인이 모두 힘들어진다. 개발자도 일정에 쫓기니 부실한 디자인에 대해 개발자 임의로 판단하여 부실한 디자인으로 개발을 하게 된다. 부실한 작업의 결과는 출시 전 통합테스트때 더 큰 부메랑이 되어 돌아온다.
큰 일괄작업의 문제점과 작은 일괄작업의 장점을 지적한 대표적인 문구는 다음과 같다.
큰 일괄작업크기로 일하면 이 크기가 점점 더 커지는 경향이 있다. 일괄 작업들이 완성 결과물 쪽으로 가면 갈수록 추가로 해야 하는 일이나 다시 해야 하는 일, 지연, 그리고 이로 인해 생기는 많은 중단 때문에 과부하를 줄이려고 일괄 작업크기를 더 키울 필요를 모두가 느끼는 것이다. 이것을 큰 일괄작업크기의 악순환이라고 부른다.(<The Lean Startup>. 2012)
작은 실패를 피하려는 노력은 큰 실패를 초래한다. 복잡한 금융시스템도 그렇고 자연도 그렇다. 복잡한 금융시스템의 붕괴는 큰 위기로 이어지며, 자연도 작은 산불이 없으면 큰 산불이 발생한다. 작은 실패를 극복하면서 복원력을 가지는 것이 좋다. (<안티프래질> 수정인용, 2013)
배조스는 2015년 주주들에게 보내는 공개서한에서 아마존이 '실패를 가장 잘하는 기업'이라고 말했다. 아마존은 실험 횟수를 두 배로 늘리고, 확고한 투자수익률이 보장된 '규모 확장형 투자'와 가끔 실패하는 '베팅'사이에 위험을 분산하는 명확한 투자 철학을 고수한다. 요컨대 그 전략은 감당할 수 있는 적정한 가격으로 가능한 많은 베팅을 하는 것이다.(<아마존웨이>, 2016)
큰 개발의 대표적인 부작용은 다음과 같다.
• 결함이나 변경 필요사항을 나중에 알게 되고 이를 바로잡는 재 작업 비용이 증가한다.
• 큰 일괄작업은 출시주기를 길게 하여 스피드 경쟁력을 저하시킨다.
• 개발규모가 크고, 복잡도가 증가할수록 개발기간이나 투입공수의 추정이 어려워진다.
큰 일괄작업의 피해를 최소화하는 방법은 다음과 같다.
• 출시를 하지 않더라도 N개의 개발주기(스프린트 또는 이터레이션)로 나누어 개발하여 결함이나 변경사항을 조기에 식별한다.
• 납기지연을 희석시키기 위해 물타기 식의 기능 추가를 예방할 수 있어야 한다.
• 개별 개발주기의 결과물에 대한 검토회의(예:show case)를 실시한다.
