안녕하세요! (주)이노핀의 CTO를 맡은 김한울 입니다. 항상 짧게만 느껴지만 설 연휴가 끝이 났습니다. 다들 새해 복 많이 받으시기 바랍니다. 지난 글까지는 개발 일정관리가 왜 어려운지에 대해 글을 썼다면, 이번 글부터는 본격적으로 "개발 일정관리를 어떻게 하면 잘할 수 있을까?"를 주제로 글을 적어볼까 합니다. 편의상 말을 낮춰서 적는 점 양해 바랍니다. — "Waterfall vs Agile" 'Waterfall'과 'Agile'. IT 업계에서 일하지 않아도 다들 한 번씩은 들어본 단어일 것이다. 두 개발방식에 관한 내용은 매우 방대하기에, 여기서는 아주 간단하게만 짚고 넘어가도록 하겠다. Waterfall은 1950년대에 언급된 매우 전통적인 방식의 SW 개발 방법론으로, Top-down 방식으로 A -> B -> C 단계를 밟아가는 방법이다. 이는 제조업과 건설업에서 효과를 본 방식을 SW에 적용한 것이다. 내가 지난 글에서 비 개발자는 "흔히 SW 개발을 건물을 짓는 것처럼 생각하기 쉽다"고 하면서 예시를 들었었는데, 이는 사실 그냥 든 예시가 아니라 오죽하면 방법론이 건설의 그것에서 나왔을 정도로 유사하게 생각되기 때문이다. 그러나 Waterfall 방식에 장점이 없는 것은 아니지만, 현대 SW프로젝트의 대다수는 Waterfall 방식을 지양하고 Agile을 추구하는 만큼, 개발 업무의 특성을 잘 반영한 방법론이라 보기는 어렵다. 반면에 Agile 방법론은 2001년 '애자일 선언문'으로부터 본격화 되었는데, Google, MS, Amazon 등 선도적인 IT 기업에서 그 효용성을 입증하면서 대다수의 IT 기업들이 SW개발시 적용하고 있는 방법이다. 기존 Waterfall 방식과 달리 길고 연속된 흐름으로 SW를 개발하는 것이 아니라, 단계를 나누어 유연하게 대처하는 방법이라 할 수 있겠다. — "Agile 방법론이 얼마나 더 우월할까?" 아래는 여러 통계를 기반으로 정리한 내용이다. A. 2020년 SW프로젝트 성공률: Agile 43%, Waterfall 13% - Source: 2020 Standish Group Report B. 2015년 SW프로젝트 성공률: Agile 39%, Waterfall 11% - Source: 2011-2015 Standish Group Chaos Studies Report C. [사진1] 프로젝트 규모에 따른 Agile vs Waterfall 성공률 - Source: 2011-2015 Standish Group Chaos Studies Report - 첨부한 [사진1] 참고. D. 네덜란드 IT 프로젝트 성공률: Small 75%, Large 10% - Source: Increase the success of Governmental IT-projects, 2019 위 통계의 결론을 다음과 같이 내보자. 1. 해가 갈수록 SW프로젝트의 성공률은 높아지고 있다. 2. Agile 방법론을 적용한 SW프로젝트의 성공률은 Waterfall보다 매우 높다(전체로 보면 3배 이상) 3. 프로젝트 규모 커질수록 SW프로젝트의 성공률은 매우 낮아진다. 1번 결론에 대해서는 나는 Agile을 제대로 이해하는 IT 기업들이 많아져서라고 간단하게 생각한다. 2번의 결론에 대해서는 프로젝트를 쪼개서 접근하는 Agile 방법론의 원리가 Waterfall의 그것에 비해 우월해서라고 본다. 그리고 3번의 결론이 바로 '프로젝트는 작아야 한다'라는 아주 중요한, 이 글에서 내가 가장 강조하고 싶은 포인트 말이다. — "Agile: Divide and Conquer" Waterfall에 비해 Agile은 확실히 우월하다. 그러나 '애자일이 우월하니 애자일 방식으로 개발하라', 라는 것은 이 글에서 말하고자 하는 요지가 아니다. 애자일은 방법론은 구체적으로는 스프린트(Sprint)라고 불리는 주 단위 정도의 작은 단위 주기로 작동 가능한 단위의 프로그램을 만들어나가는 방식이다. 즉 'Divide and Conquer'라고 불리는 매우 효율적인 원리를 바탕으로 하나의 프로젝트를 진행해나가는 거다. 그러나 프로젝트의 규모가 커진다면? [사진1]의 통계에서 볼 수 있듯, 큰 규모의 프로젝트에서는 애자일이라 해도 그 성공률은 19%에 불과하다. 애자일이든 뭐든, 이는 매우 불편한 수치이자, 관리자로서 용납해서는 안 되는 수치이다. 그렇다. 애자일 방법론만으로는 충분하지 않다. 따라서 우리는 프로젝트를 진행하는 방법론보다, 프로젝트 자체를 구성하는 좀 더 근본적인 부분을 바라보아야 한다. — "작은 프로젝트로 구성하라" 이 연재 글들은 '도대체 개발 일정을 어떻게 관리해야 하는가'라는 질문에서부터 시작되었다. 앞으로도 다양한 주제들을 나눌 것이지만, 가장 중요한 것은 바로 이것이라고 단언할 수 있다. 바로 긴 프로젝트는 성공할 수 없으니(혹은 매우 어려우니), 작은 프로젝트의 집합으로 구성하라는 것이다. 내가 쓴 글에 어떤 분이 이러한 취지의 질문을 하였다. "그러면 그냥 데드라인을 정하지 말아야 하나요?" 아니다. 데드라인은 필요하다. 다만 내 경험상 SW프로젝트의 기한이 1년을 넘어간다면, 그것은 이미 정상적인 의미의 '계획'의 영역을 벗어났다고 본다. 조금 보수적으로 보면 6개월을 넘어서도 안 된다. 즉 측정과 성공률을 보장할 수 없다는 것이다. 보기 좋은 WBS를 만들고 그럴싸한 문서로 포장해봤자, 그 계획은 계획을 위한 계획일 뿐, 실현가능한 계획이 아니다. 개발팀을 아무리 쪼아도, 분명 변수가 발생할 것이다. 그렇게 해서 개발이 성공적으로 끝났다 한들, 그것은 그때 운이 좋았을 뿐이지 동일한 방식을 반복했을 때 또 성공한다는 보장은 없다. — "나누지 말고 쌓아 올려라" 눈치를 챈 사람들도 있겠지만, 나는 의도적으로 큰 프로젝트를 '쪼갠다', '나눈다'라는 말을 지양하였다. [사진2]를 보라. 위 A방식도 단계가 나눠져 있지만, 그 독립된 단계는 아무런 기능을 하지 못한다. 이는 2년 짜리 3년 짜리 프로젝트를 잘게 쪼개어 3~4개월 단위로 만드는 것과 같은데, 별 효용을 찾기는 어려운 방식이다. 반면에 [사진2]의 B를 보자. 각 식기는 독립적인 기능을 할 수 있는 온전한 기능을 갖춘 도구이다. 이처럼 하나씩의 식기를 만들어가서 결국 식기 세트가 되었다. 이것이 우리가 지향해야 하는 방식이다. 큰 프로젝트를 쪼개는 것이 아니라, 애초에 3~4개월, 혹은 6개월 정도의 기한으로 온전한 단위의 프로젝트를 구성해서 쌓아 올리는 거다. 이 '리멤버' 서비스를 예로 들어보자. 현재 리멤버는 기본적인 명함 관리 기능은 물론, 팀명함첩 및 커뮤니티 기능이 있다. 그러나 처음 리멤버는 그냥 명함 관리 기능 하나만 있는, 그것을 아주 잘 만든 서비스였다. 거기에 팀명함첩 기능을 쌓았고(더했고), 지금은 커뮤니티 기능을 쌓았다. 즉 단위 단위로 볼 때 온전한 기능을 하는 서비스였단 것이다. 흔히 말하는 MVP(Minimum Viable Product)는 바로 이러한 특성을 말한다. 물론 MVP가 나오는데 1년이 걸릴 수도 있다. 그러나 이 역시 1년짜리의 기능을 6개월 단위 2번이나 3개월 단위 4번으로 쪼개라는 것이 아니라, 그것이 Alpha, Beta의 형태를 띨 지언정, 혹은 내부에서만 테스트/오픈을 할 지언정 애초에 3~6개월 단위의 프로젝트를 진행하고, 그것을 더해 하나의 MVP를 만들라는 거다. 프로젝트의 최소 단위를 3개월, 6개월, 혹은 1년(미래의 내가 "Stay!"를 외친다)으로 정할지는 각 회사마다 사정이 다를 것이다. 그러나 중요한 것은 그것이 '예측 가능한 계획의 범위'를 넘어가서는 안 된다는 원칙이다. 만약 급변하는 시장 상황 속에서 MVP를 내보이는데 1년 이상이 걸린다면, 기획 혹은 개발팀 구성에서 문제점을 찾는게 더 적합한 접근일 수 있다. — "Divde and Conquer?" 정리해보겠다. SW프로젝트는 항상 변수요인을 안고 있고, 이는 그 프로젝트의 사이즈가 커질수록 기하급수적으로(복리로) 증가한다. 모든 SW 관련 통계에서 말하는 가장 중요한 요인이 프로젝트의 크기인 이유가 거기에 있다. 애자일이 추구하는 이른바 'Divide and Conquer'라는 유명한 말이 여기에 대한 해답처럼 보이는 것은 그 때문이다. 그러나 나는 이 글의 제목을 'Divide and Conquer?'라고 물음표를 붙여서 정했다. 그것은 프로젝트를 'Divide' 하는 것만으로는 충분치 않기 때문이다. 프로젝트의 규모가 커지만 애자일 방법론을 적용해도 성공률은 매우 낮다. 따라서 큰 비전을 머릿속에 품고는 있되, 애초에 작은 단위로 완성할 수 있는 프로젝트로 시작을 해야 한다. 그리고 그것을 쌓아올리는 것이다. 사실 이런 말이 있을지는 모르겠지만, 나는 이렇게 말하고 싶다. "Complete and Add". 완성시키고, 더해라. 작은 단위로 동작 가능한 프로그램을 만든다는 애자일의 원리를, 프로젝트 자체에 적용시켜 '애초에 프로젝트 단위의 크기를 작게 유지해야 한다'. 나는 이것만이 가능한 변수를 줄일 수 있는 최선의 방식이라고 생각한다.
