애자일과 워터폴, PM 관점에서 본 방법론 선택 기준

방법론 이야기를 꺼내면 항상 반응이 두 갈래로 나뉩니다.
"애자일이 옳다"는 쪽과 "우리 조직엔 안 맞는다"는 쪽으로요.
저도 한동안 애자일 전도사처럼 굴었던 시기가 있었는데, 최근 2년 동안 워터폴 방식의 SI 프로젝트와 자체 서비스의 애자일 프로젝트를 나란히 겪어보면서 생각이 많이 바뀌었습니다.
방법론에 정답이 있는 게 아니라, 프로젝트의 성격을 먼저 읽어야 한다는 걸 몸으로 배운 셈이에요.

 

2018년 초에 맡았던 프로젝트는 외부 발주처가 있는 6개월짜리 구축형 프로젝트였습니다.
요구사항 정의서, 화면설계서, 테스트 계획서까지 문서 승인 절차가 단계마다 있었고, 앞 단계 문서에 발주처 도장이 찍히기 전에는 다음 단계로 넘어갈 수 없었어요.
처음엔 이 절차가 너무 답답하다고 생각했습니다.
회의 한 번 하려면 일주일 전에 안건을 공유해야 했고, 화면 하나를 바꾸려면 변경 관리 문서를 새로 써야 했으니까요.

그런데 프로젝트 중반쯴 되니 이 답답함이 왜 필요한지 이해가 됐습니다.
발주처 담당자가 중간에 두 번 바뀌었는데, 그때마다 새 담당자가 그동안의 문서를 보고 프로젝트 맥락을 스스로 파악할 수 있었어요.
만약 문서 없이 구두로만 합의하고 넘어갔다면, 담당자가 바뀔 때마다 프로젝트가 처음부터 다시 시작됐을 겁니다.
계약 관계가 있고, 책임 소재를 명확히 해야 하는 프로젝트일수록 워터폴의 문서 중심 구조가 오히려 안전망 역할을 한다는 걸 그때 처음 체감했어요.

물론 단점도 분명했습니다.
요구사항 정의 단계에서 놓친 부분이 개발 후반부에 발견되면, 되돌리는 비용이 엄청나게 커졌어요.
저희 프로젝트에서도 결제 연동 방식이 기획 단계에서 확정한 것과 실제 PG사 정책이 달라서, 이미 만들어진 화면 세 개를 통째로 다시 설계해야 했던 적이 있습니다.
그 한 번의 변경으로 일정이 3주 밀렸고, 그 여파로 QA 기간이 절반으로 줄어드는 악순환이 이어졌어요.
워터폴에서는 앞 단계의 실수가 뒷 단계에서 걷잡을 수 없이 커진다는 걸 그때 제대로 느꼈습니다.

 

같은 해 하반기에 맡은 자체 서비스 프로젝트는 반대였습니다.
2주 스프린트로 돌리면서, 매주 실제 사용자 데이터를 보고 다음 스프린트 계획을 조정했어요.
초반에 "이 기능이 필요할 것"이라고 가정했던 것 중 절반 가까이가 실제 사용자 로그를 보니 우선순위가 낮다는 게 드러났고, 그 자리에서 백로그를 다시 정리할 수 있었습니다.
워터폴이었다면 이미 승인된 요구사항 정의서를 다 뜯어고쳐야 했을 텐데, 애자일 구조에서는 다음 스프린트 계획 회의에서 바로 반영이 됐어요.

다만 애자일도 공짜는 아니었습니다.
계약이나 예산이 걸린 외부 이해관계자에게 "이번 스프린트에서 방향이 바뀌었습니다"라고 설명하는 일이 반복되니, 신뢰도가 오히려 떨어지는 순간도 있었어요.
경영진 보고 자리에서 "지난달에 말씀하신 그 기능은 어떻게 됐나요"라는 질문에 "사용자 데이터를 보고 우선순위를 바꿨습니다"라고 답했더니, 처음에는 "그럼 계획이 원래부터 없었던 거냐"는 오해를 사기도 했습니다.
애자일의 유연함이 특정 이해관계자에게는 "일관성이 없다"로 읽힐 수 있다는 걸 이때 배웠어요.

 

이 두 경험을 겪으면서 제 나름의 판단 기준을 세 가지로 정리했습니다.

첫째, 요구사항이 프로젝트 시작 시점에 얼마나 확정 가능한가.

계약, 법적 요건, 외부 시스템 연동처럼 처음부터 명확하게 정해지는 요소가 많다면 워터폴 쪽이 안전합니다.
반대로 사용자 반응을 봐야 다음 방향이 나오는 서비스라면 애자일이 맞아요.

둘째, 실패의 비용이 어느 단계에서 가장 크게 발생하는가.

워터폴은 뒷단에서 문제가 터지면 복구 비용이 기하급수적으로 커집니다.
애자일은 매 스프린트마다 작게 실패하고 작게 고칠 수 있는 대신, 큰 그림을 놓치기 쉬워요.
저는 실패 비용이 뒤로 갈수록 커지는 프로젝트일수록 초반 요구사항 정의에 훨씬 더 많은 시간을 투자하려고 합니다.

셋째, 이해관계자가 변화를 어떻게 받아들이는가.

외부 발주처나 규제 기관처럼 "약속한 대로"를 중요하게 여기는 상대라면, 애자일의 유연함을 그대로 노출하기보다 마일스톤 단위로 재구성해서 보여주는 게 낫습니다.
저는 요즘 애자일로 프로젝트를 돌리더라도, 외부 보고용으로는 스프린트 4~5개를 묶어서 "이번 마일스톤 목표"라는 형태로 재가공해서 공유하고 있어요.

 

솔직히 말하면, 요즘 제가 실제로 쓰는 방식은 순수 워터폴도 순수 애자일도 아닙니다.
큰 마일스톤과 예산, 대략적인 범위는 워터폴처럼 초반에 확정해두고, 그 안에서의 실행은 스프린트 단위로 돌리는 혼합형에 가까워요.
이렇게 하니 경영진에게는 "전체 로드맵이 있다"는 안정감을 줄 수 있었고, 실행팀에게는 "매주 방향을 조정할 수 있다"는 유연함을 동시에 줄 수 있었습니다.

방법론을 종교처럼 믿는 순간 문제가 생긴다고 생각합니다.
애자일이 유행이라고 무작정 도입했다가 계약 구조와 안 맞아서 고생하는 팀도 봤고, 워터폴이 안전하다고 무조건 고수하다가 시장 변화를 못 따라가는 팀도 봤어요.
저는 이제 새 프로젝트를 시작할 때 "이 프로젝트에 어떤 방법론이 어울릴까"를 먼저 묻습니다.
방법론은 목적이 아니라 도구니까요.
다음에 맡을 프로젝트는 또 어떤 조합이 필요할지, 매번 새로 판단해야 하는 게 조금 피곤하기도 하지만 동시에 PM으로서 제일 재미있는 부분이기도 합니다.