이는 필자가 2007년 이탈리아에서 열리는 콘퍼런스에서 많은 참석자들에게 들었던 말입니다. 당시만 해도 ‘애자일은 대형 프로젝트에 적용할 수 없다’는 의견이 시장에서 지배적이었고, 실제로 애자일을 하는 사람도 대형 프로젝트에서의 애자일 방식에 대해서는 회의적인 경우가 많았습니다.
아마도 그 이유는 2001년 “애자일 선언”에 있지 않을까 싶습니다. 애자일의 기원 자체가 작은 팀을 중심으로 일하는 프로세스에 기초하기 때문입니다.

당시 스크럼, XP, 린 S/W 개발 등은 7~9명 단위의 작은 팀을 기반으로 설명되어 있었고, 이 인원으로도 최고의 생산성과 품질을 낼 수 있다고 언급하였습니다. 그나마 스크럼 프로세스만이 ‘여러 스크럼 팀으로 확장될 때는 작은 팀들을 여러 개 만들고, 이를 스크럼의 스크럼이라는 형태의 회의로 이슈를 해결하면 된다’라고 확장에 대한 고민을 담고 있었습니다.

하지만 스크럼도 개발 외 요구사항을 받는 방법이라든지, 릴리스 방식에 대한 구체적인 언급이 없었기 때문에, 대규모 프로젝트에 적용하기엔 어려움이 있겠다는 생각이 지배적이었습니다.
그 때문이었는지 이후 10년이 넘도록 대형 프로젝트에서 애자일을 활용하려는 노력의 과정은 꽤나 험난했습니다. 작은 팀 위주에 초점을 맞추던 기존의 프랙티스에서 벗어나 대형 프로젝트에 맞추어 일부 변경된 시도를 하려던 사람들에게 많은 비난이 쏟아졌고, 이전의 오리진(Origin)을 버리는 것이라며 질책도 받았습니다. 또, 조금이라도 문서화에 초점을 맞추려 하면 이건 애자일이 아니라고 폄하했습니다.

하지만, 시간이 흐를수록 기존 프로세스에 대한 불만과 클라우드로 전환되는 시장의 흐름에 따라, 애자일 확산에 대한 니즈가 증폭되었고, 이로 인해 애자일의 일반화/정형화/대중화에 대한 움직임들이 나타났습니다.

또, 좀 더 다양한 조직의 사람들이 애자일 방식을 기반으로 한 새로운 프로세스를 만들어 나갔습니다. 기존의 한계를 극복하며 현실적인 접근을 시도했던 것입니다.
대표적인 프로세스로 DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum) 등이 있습니다. 심지어 SAFe는 미국 정부를 비롯하여 애자일을 하는 회사의 50% 이상이 활용할 정도로 큰 인기를 누리는 애자일 프로세스가 되었습니다.

참고: http://www.scaledagileframework.com/
   150명 이상의 Portfolio 관리가 필요한 대형 애자일 프레임워크

이러한 프로세스에는 기존의 도그마(Dogma: 독단적인 학설, 이성적으로 증명되지 않은 가설)라고 이야기되던 순수 애자일에서 벗어나 현실적으로 기존 문화와 다양한 프랙티스들을 섞는 것을 시도하는 내용들이 담겨 있습니다. 시장 상황, Stakeholder들의 일해오던 방식 등은 존중하면서도, 애자일 방식을 통해 가치를 얻을 수 있는 중간 단계의 무엇인가를 찾는 노력들이 있었던 것이죠.
여기에 디자인 싱킹으로 대표되는 디자인 방식의 변화, 린 스타트업으로 대표되는 스타트업 바람이 더해지면서 이제는 소프트웨어 회사의 94% 이상이 스스로를 ‘애자일을 하는 회사’라 주장하고 있습니다.

그렇다면 대형 프로젝트의 애자일과 이전의 구체적인 차이는 무엇이고, 현실과 맞물려 일하는 방법이란 무엇일까요? 이를 효과적으로 설명하려면 2001년의 애자일 선언을 살펴보면 됩니다.
과거 작은 팀을 중심으로 한 (왼쪽의) 애자일 방식은 반대편인 오른쪽을 마치 금기처럼 무시하려는 분위기가 강했습니다. 그래서 오른쪽에 접근하는 것을 경계했죠.
하지만 현실과 맞물리자, 대형 프로젝트의 경우에는 왼쪽만큼이나 오른쪽 부분 또한 중요하다는 인식의 전환이 생겨났습니다.

그리고 아래는 그에 대한 절충안들입니다.

1. 대규모 프로젝트(50명 이상)에서 개인과 상호작용만을 강조하면, 두 개 이상의 팀이 되었을 때 효과적인 커뮤니케이션이 힘들기 때문에 툴을 사용하는 것이 좋습니다.
2. 동작하는 소프트웨어에만 집중하면 팀 내 진행 상황에 대해서는 잘 이해할 수 있으나, 두 개 이상의 팀이 되었을 때에는 서로의 진행사항을 확인하기 어렵습니다. 애자일 팀은 “우리 팀에 와서 언제든 제품을 보세요"라고 쉽게 말할 수 있지만 여러 팀을 돌봐야 하는 관리자에게는 눈살을 찌푸리게 만드는 대화가 될 수도 있습니다. 때문에 적당한 문서화가 커뮤니케이션에 도움이 될 수 있습니다.
3. 고객과의 협업만 강조하면 다양한 이해관계자를 모두 포용하지 못할 수 있습니다. 때문에 계약과 협상을 통해 전체 이해관계자와 동일한 비전/생각을 갖고 일을 해야 합니다.
4. 상황에 따른 변화도 중요하지만, 주변 팀에 이야기하지 않으면 두 팀 이상이 될 경우 의존관계를 무시하게 되어 고객의 비즈니스 가치를 제때 전달하지 못하는 상황을 만날 수 있습니다.

이상으로 대형 프로젝트, 대규모 조직에서 애자일을 적용하다 현실의 벽에 부딪혀 고민하고 있는 독자들에게 도움이 되길 바라며, 한 가지만 당부하고 싶습니다. 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 상황에 따른 변화는 여전히 더 중요합니다. 그래야 애자일 방식이기 때문입니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.