애자일방법론과 워터폴방법론, 도그냥식 설명법
'펜션으로 쓰기 위한 3층집'으로 한방에 이해하기
간혹 워터폴방법론과 애자일방법론의 차이에 대해서 강의를 할 때가 있습니다. 물론 제가 프로젝트전문가나 애자일 코치가 아니기 때문에 대기업과 스타트업 환경의 실무자 입장에서 경험적으로 느낀 현실적인 설명을 필요로 하는 곳에서 비개발자들을 대상으로 설명하고는 하는데요.
특히 IT 개발을 외주로 하는 경우 고착화된 프로세스 때문에 고민을 많이 하기도 하고, 내부에서 어디선가 구호로만 외치면서 일은 그대로인데 Jira와 slack쓰라고 협박받다보니 '애자일'에 대해서 내적 반감과 불쾌감이 높은 대기업인 경우에 제 설명이 더 유용하게 다가갔던 것 같습니다.
몇 번을 설명하면서 저만의 적합한 비유적인 설명방법을 깨닫게 되었는데요. 얼마전 이쓔스에서도 똑같은 설명을 하기도 했죠.
프로젝트 방법론을 기획자는 왜 알아야 할까
일단 이 부분을 꼭 짚고 넘어가고 싶은데요. 대부분의 기업에서 처음 입사한 사람에게 그 누구도 우리 회사는 어떤 프로젝트 방법론을 쓰고 있다라고 설명해주는 경우는 없습니다. 왜냐하면 이미 그 회사에 일하는 사람들은 일하는 방식이 너무 고착화되서 그게 익숙하기 때문이죠.
서비스기획자와 PM/PO를 오가고 있는 기획자들은 화면설계서를 쓰고 PRD를 쓰는 기준이나 스프린트 단위로 산출물을 내느냐 마느냐와 같은 애매한 기준으로 프로젝트 진행 방식을 익힙니다. 하지만 그러다보면 이직하는 과정에서 이전 회사와 다른 프로세스나 R&R으로 고통받죠. 예를 들면 완벽한 폭포수 프로젝트를 지향하는 곳에서는 기획이 안끝나면 디자인, 개발이 시작도 못하는데 스타트업에서 그냥 요구사항만 정의해서 진행하던 사람이라면 메이커들이 왜 그렇게 보수적인가 충격을 받기도 하고, 반대로 폭포수를 지향하는 곳에서 아주 빠듯하게 화면설계서를 쓰고 그것대로만 만들기를 주장하던 사람이 스타트업에 가면, 자신의 요구사항에 대해서 그대로 들어주지 않고 논쟁을 하게 되는 상황에 당황하게 됩니다. 물론 하이브리드도 있어요. 논쟁도 하는데 화면설계서가 없으면 진행도 안되고 스프린트도 있는거죠. 말이 좋아서 하이브리드지 끔찍한 혼종이라고 할 수도 있는 것 같아요.
저는 이런 상황이 프로젝트 방법론에서 지향하는 방향성과 부분부분적으로 툴(tool)만 들여오는 과정에서 개개인들의 지식격차가 문제라고 생각합니다. 아무도 근본적인 두 방법론의 차이에 대해서 알려주지도 않고 공부하는 사람들도 대충 문서를 뭘 쓰는지 정도로만 이해하고 말기 때문인 것이죠. 그렇다보니 애자일 방법론이 좋다는 말에 크게 데여서 쳐다도 보기 싫은 사람들이나 폭포수 방법론에 대해서 무조건 나쁘다고 하는 사람들도 나타나는 거고요.
저는 기획자가 방법론에 대해서 명확하게 알아야 하는 이유는 회사내 프로젝트의 방법론을 올바로 바로 잡기 위해서가 아니라고 생각합니다. 오히려 그 반대로 이미 이것저것 툴과 구호가 뒤섞인 상황을 분석해서 어떤 방법론을 기반으로 기획자가 해야하는 역할을 모두가 요구하고 있는지를 파악하기 위해서 알아야 한다고 생각해요. 즉, 겉으로 뭘 떠들고 실제로는 어떻게 일하든지간에 그 상황에서 우리의 역할을 잘 정의해서 잘 해낼 수 있으면 되는 거니까요. 이건 화면설계서를 쓰냐 PRD를 쓰고 유저스토리를 쓰냐 스프린트를 해봤냐 이런것과는 전혀 다른 실무적인 방점이라고 생각해요.
자, 3층짜리 펜션을 짖는다고 가정해볼께요.
폭포수 방법론으로 3층짜리 집을 지을 때를 가정해봅시다.
1층기획자, 2층기획자, 3층 기획자, 화장실 기획자, 주방 기획자 이렇게 여러 사람들이 각자의 요구사항을 가지고 동시에 기획을 해요. 그리고 각각의 기획에 따라 디자이너, 개발자들이 동시에 개발에 작업을 하게 되죠. 1층부터 3층까지 집을 순차로 짓지 않고 마치 조립식 집처럼 각각 1층, 2층, 3층을 지어서 한번에 집을 오픈하려고 해요.
이제 테스트기간이 되서 집이 제대로 되었는지 확인을 하죠. 어라? 1층의 계단과 2층의 입구의 위치가 들어맞지 않아요. 1층의 배관고 2층의 배관이 연결되지 않아서 2층에 수도가 연결되지 않았어요. 각자 기획하고 개발하는 과정에서 틀어짐이 발생한 것이죠. 테스트 기간에 합을 맞추는 과정에서 결함이 발생하게 되고, 이를 테스트 기간에 수정을 하게 됩니다. 아마도 큰 프로젝트를 수행해본 사람이라면 이런 경험이 많으실 거에요. 폭포수 방법론의 가장 큰 단점은 3층이라는 거대한 집을 짓는 동안 요구사항을 수정하기 어렵고, 테스트 기간에 동시다발적으로 많은 결함이 발견되어서 프로젝트 오픈 지연이 발생하기 쉽다는 점이에요.
반면에 장점은 명확합니다. 어쨌든 기간이 끝나면 3층집이 나옵니다. 만약에 납기를 목표로 하는 프로젝트라면 3층집이 나온다는 것이 훨씬 더 중요해요. 대기업일수록 외주방식의 구축을 많이 하고 애초에 목표하는 서비스의 사이즈가 크기 때문에 폭포수 방법을 선택하기 쉬운 것이죠.
하지만 더 큰 단점이 남아있는데요. 바로 시장 적합성의 문제에요. 우리가 3층집을 짓느라 1년여의 시간을 소비하는 동안, 컨테이너 박스로 오픈한 펜션들과 기존 집들을 개조한 팬션들에 손님들이 많이 몰리게 된 것이죠. 이미 다른 곳들이 유명해진 탓에 시작을 일찍 하고 멋있지만 후발주자가 되어 버려요. 그 사이에 시장 경쟁력을 잃는 것이죠. 그리고 애초에 그 동네의 팬션은 3층짜리보다는 1층짜리가 더 적합한 형태일수도 있어요. 하지만 이미 만들어 버렸기 때문에 많은 비용이 투자가 되어버린 상태가 되어버리는 것이죠.
애자일 방법론으로 3층짜리 집을 짓는다고 생각해볼께요.
애자일 방법론에서는 빠른 구현을 통한 실험을 중요시해요. 그래서 이 건물을 짓는 근본적인 이유를 찾아갑니다. 알고 보니 이 동네에 바닷가가 가까이 있고 관광수요가 늘어나고 있어요. 그래서 여기에 펜션을 짓어야 겠다는 생각을 했다는 거죠. 그럼 이 지역의 펜션이 갖추어야 할 가장 핵심적인 구조들을 정리해요. 바닷가니까 마당에서 바닷가를 내다볼 수 있는 곳이 있으면 좋겠다든가, 펜션이라도 고기 구워먹는 것보다 해산물을 먹을 일이 많으므로 해산물 쓰레기를 잘 처리할 수 있는 형태가 필요하다든가, 바닷가가 잘 보이는 테라스에 배스텁을 둔다든가 하는 것들이 필요해요. 이렇게 꼭 필요한 것들만 정리해서 1층짜리 펜션을 먼저 지어봅니다. 그리고 그 펜션이 얼마나 수요가 있고 사랑받는지를 체크해요. 이게 바로 MVP(Minimum viable Product)의 개념이죠. 궁극적으로는 3층짜리 펜션까지 가고 싶지만 그것을 End Picture로 두고 정말 3층까지 갈 지는 나중에 생각합니다.
장점이 있죠. 1층만 짓기 때문에 비즈니스적으로 시장 진출이 빨라져요. 그리고 범위가 적기 때문에 테스트 기간에 발생하는 오류도 상대적으로 적을 수 있어요. 개발량이 적기에 더 적은 인원으로 진행하기도 용이하죠. 그래서 애자일 방법론이 이제 막 온라인 서비스를 만들어야 하는 스타트업에서 선호되는 것은 필연적이에요.
그리고 더 중요한 부분은 이 다음부터에요. 1층을 지어서 시장성이 있다는 것이 판단되면 2층을 확장할 필요가 있을지 수치적 매트릭으로 판단을 합니다. 그리고 2층이 더 필요하고 수요가 늘어나고 있다고 판단이 되면 2층을 짓기로 해요. 이때 2층을 짓기 위해서 제일 먼저 필요한 것은 1층의 지붕을 뿌시고 2층을 짓는다는 점이에요. 즉, 2층을 짓기 위해서 처음에 개발해둔 1층의 일부를 부시고 1층의 배관이나 구조를 잘 연결해서 2층을 짓고 지붕을 다시 지어야 해요. 이것을 잘하려면 기존의 1층에 대해서도 잘 알고 있는 내부 인력이어야 하고 개발했던 지붕을 2번 개발하는 것에 대해서 마음이 열려있어야 해요. 애자일 방법론을 추구하는 조직들이 개발 인력을 내재화하고 프로덕트팀으로 특정 프로덕트에 전문성을 가지는 것과 같은 이유죠.
2층에서 3층으로 넘어갈 때도 마찬가지에요. 지붕을 또 부수고 구조를 개선하며 1층을 운영하는 상태로 2층과 3층을 점점 높여갑니다. 이 방식대로라면 3층이 아니라 100층까지도 목표가 있다면 크게 확장이 가능한 거에요. 그게 애자일 방법론이 가지고 있는 지향점이죠.
사실 기존의 대기업들은 꿈도 크기도 하지만 외주인력으로 개발을 하기 떄문에 지붕을 2번 개발하는 것을 비효율이라고 생각하죠. 저 역시도 클래식한 대기업에서 여러가지 프로덕트의 한계가 발견되면 임기응변으로 무언가 개발을 해서 서비스를 실험하기 보다는 '차세대' 또는 '리뉴얼'이라는 이름으로 3층집까지 개발량을 늘리는 경우가 더 많았습니다. 임시로 만들 '레거시'를 만들지 않으려고 하는 것이죠.
하지만 진짜 애자일을 지향한다면 레거시를 만들더라도 일단 최소한의 기간으로 비즈니스를 성공시키는 것에 더 포커스를 맞추죠. 그리고 그 레거시를 만든 사람들이 레거시에 대해서 직접 부수고 다시 만들 의지가 있어야 해요. 이것이 없다면 애자일은 성립되지 않는다고 생각합니다. 대신에 꼭 필요한 기능을 콤팩트하게 스콥을 잡아내는 로드맵 설계 능력이 굉장히 중요해지는 거고요.
물론 일하는 사람으로서 애자일에도 단점은 있습니다. 애자일 방법론을 위해서 주로 사용하는 스크럼의 스프린트라는 방식은 폭포수방법론처럼 맺고 끊음이 명확하지 않아요. 일하는 사람 입장에서는 프로젝트가 끝나고 숨쉬고 할 여유없이 계속해서 판단하고 부수고 더 크게 다시 짓고를 반복해요. 계속해서 2주라는 챗바퀴가 굴러가는 셈이죠.
해외에서 개발자들이 스프린트 애자일 방식에 이제 지쳐간다는 글이 나오는 것도 이 때문이에요. PM/PO역시 쉴 틈이 없어요. 계속해서 파악하고 분석하고 이유를 찾아야하죠. 끝없이 좋은 팬션을 만들기 위한 고민을 해야하거든요.
또 다른 문제는 애자일방법론을 잘 수행하기 위한 조직 구성이 제대로 작동하지 않는다면 속도가 생각보다 빠르지 않다는 점도 있어요. 애자일 방법론은 폭포수처럼 완벽한 기획으로 프로젝트를 진행하기 보다는 목표를 정해두고 크로스펑셔널팀에서 디자이너와 개발자가 붙어서 동시에 2주단위의 개발을 진행합니다. 백지장도 나눠들면 빠르지만 기간은 동시에 하는 기간인데 실제 폭포수처럼 PM/PO에게 업무가 몰리게 되면 개발량이 폭포수보다 많지 않은데도 속고가 생각보다 빨리 나지 않게 되죠. 결국 어떻게 납품을 빠르게 할 것인가가 계속해서 도마에 올라요. 컨베이어 벨트처럼 여러 사람이 기획을 하고 텍트리스처럼 리소스를 받아가는 폭포수보다 결론적으로 느리게 나오는 것이죠.
정리해보면, 대기업에서 애자일이 필요하다고 표방하지만 대기업이 여전히 처음부터 3층자리 펜션을 화려하고 짓고 싶어한다면 상대적으로 폭포수 프로젝트 방법론을 선택하는 것이 더 빠릅니다. 하지만 실제로 서비스가 의미있는지 빨리 시장에 확인해보고 계속해서 발전시켜나가려면 애자일 조직을 채택할 수도 있겠죠. 다만 정말로 그렇게 작동시키기 위해서는 내재화된 PM/PO와 개발조직이 일관성있게 프로덕트를 관리해야하고 또 전문성이 상당히 올라와서 디자이너와 PM/PO, 개발자가 거의 동등한 수준으로 비즈니스와 사용자에 대해서 파악할 수 있어야 해요. 그리고 조직 자체의 끝없이 이어지는 개발 굴레로 인해서 높아지는 개개인의 피로감 관리도 해줄 수 있어야 하고요.
자, 이렇게 3층 펜션을 짓는 것으로 두가지 프로젝트 그리고 그 속에 숨어있는 조직의 이야기를 해보았는데요.
여러분들은 어떤 방식으로 일하고 싶으신가요?
그리고 지금은 어떤 방식으로 프로젝트를 진행하고 계신가요?
앞으로 진행하실 프로젝트도 화이팅하시길 바랍니다.
