기획자로서 애자일 개발 프로젝트를 진행하라고 하면 가장 먼저 하는 것

먼저 왜 애자일로 프로젝트를 하라는 것인지, 이 프로젝트의 목적과 목표가 무엇인지, 그리고 이를 위해 지금 해야 하는 것은 무엇인지에 대한 정리를 할 것입니다. 기획자로서 해야 하는 기본적인 일의 순서는 애자일이라고 달라질 게 없습니다. 단지 디테일이 달라질 뿐입니다.

 

 

왜 애자일 개발인가?

일반적 개발 현장의 조직 구조와 업무는 크게 고정된 시장 상황에 대하여 개발 생산성을 높이기 위한 관리의 방식으로 설계됩니다. 그러나 2000년 이후 온라인에 이어 모바일이 성장하면서 시장 상황이 복잡해지고 변화가 심해지게 되었습니다. 결국 기존 방식으로 개발을 한 앱을 론칭하는 시점이 되면 시장 상황이 바꾸어져 있는 것을 확인하게 되는 것입니다.

 

이는 물론 시장에서 수익을 올릴 수 있는 앱의 개발, 그러니까 기능이나 디자인 등을 론칭 전 아는 것이 불가능하다는 사실을 의미하기도 합니다. 결국 확신을 가지고 진행한 앱 개발이 사실은 아무것도 모르는 개발이 되어 버리는 것입니다.

 

애자일 개발은 이런 문제를 최소화하기 위해 발생한 방식이라 할 수 있습니다.

 

기획 방식으로는 사전에 가설을 통해 개발을 진행하는데, 기간을 최소화하여 가설 수립 시점과 앱 론칭 시점의 변수 영향을 작게 만든 뒤, 앱 론칭을 통해 수집되는 사용자 정보를 통해 기존 가설을 수정하고, 이 수정 과정에서 나타나는 오차를 통해 변수 구성과 영향 가중치를 조정하여 앱의 시장 유효성을 향상합니다.

 

개발 방식으로 애자일은 새로운 방식일 수 있지만, 기획 방식으로 애자일은 기존의 JIT, 린, 문제 해결형 조직, TFT, 플랫폼 조직, 가상 조직, 글로벌 밸류 체인, MVP 그리고 제가 최근 작업하기도 했던 밀크런 등 나름 역사와 전통이 있는 경영 기획 사상 중 한 갈래입니다.

 

십여 년 전부터, 특히 스타트업과 함께 애자일 개발이 부각된 것은 개발을 통해 비즈니스를 해야 하는 시장 환경이 복잡해지고 변화가 심해졌다는 이유 때문이라 생각합니다.

 

이 또한 경영학을 전공했다면 대학에서 배우는 시장 환경에 따른 전략, 기술의 특성에 따른 조직 구성 등에서 나오는 이야기이므로 기획자 입장에서는 새로울 것은 없기는 합니다. 단지 흐름의 변화, 그리고 지금 기획을 하고 있는 곳이 IT 인터넷 업계라는 때문에 더 많이 보게 되는 것은 아닌가 생각합니다.

 

그리고 최근 주로 외주 기획 작업을 하는 입장에서 애자일 개발이 중요한 것은 아니었습니다. 외주 개발은 일정 범위를 계약한 기간에 개발하고 철수하기 때문입니다. SI, 웹에이전시 주로 하던 최근 외주 기획 시기 이전 자체 온라인 서비스를 기획/개발/운영할 때는 기획 관점에서 애자일 특성 고려는 많이 하기는 했습니다. 이 때도 외주 개발 부분이 많아 개발 과정을 디자인하는 것은 어렵기는 했습니다.

 

 

애자일 개발을 위한 팀 세팅과 기획자

애자일 개발을 추구하면서 기획 툴을 의존하고 재택근무로 원격 회의를 진행하는 것은 말이 되지 않습니다. 일단 애자일 개발 철학과 맞지 않습니다. 아래 이전 언급한 위키에서 찾은 애자일 선언문을 다시 올려놓겠습니다.

 

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를

 

기획 툴을 사용한다는 것은 개발 툴을 사용하는 것과는 다릅니다. 일단 상호 작용을 툴을 통해 한다는 것을 의미합니다. 기획 툴은 개발자들이 재택근무 시에나, 대규모 팀이라 개인과 상호작용이 어려울 때 효과적입니다. 그리고 의도적이든 무의식적이든 기획 툴은 문서 지향적 방향을 형성합니다. 툴, 특히 기획 툴의 사용 의도 중 하나는 보기 좋은 문서 생산이기 때문입니다.

 

이런 점에서 애자일 개발을 추구하는 스타트업의 경우 팀 전체 토론과 이에 대한 정리는 특정 형식의 문서보다 토론과 회의 시 진행한 화이트보드 내용을 공유하는 것으로 종료합니다.

 

흔히 이런 팀은 생산보다는 문제 해결을 위한 조직이라고 하고, 전통적인 경영 용어로 TFT라고 합니다. 즉, 애자일 개발 팀도 문제 해결 팀, TFT의 조직화 원리에 따라 팀을 구성해야 한다는 것을 의미합니다.  

 

상호 보완적 기술을 가진 사람들의 상호 작용으로 문제를 해결할 수 있도록 조직화되어야 합니다. 문제는 기능 단위의 규모가 커질 경우 시너지 작용보다 정치적 역학 관계가 형성될 수 있다는 점입니다.

 

이는 최근 이슈가 되는 토스의 동료 평가에도 나타납니다. 이런 동료 평가는 기존 관료적인 상사 평가에 비해 다면 평가적 요소도 있고, 무언가 임파워먼트적 느낌도 있는 듯 수평적인 평가와 같습니다. 문제는 이들이 조직화할 경우 향후 조직 내에서 경쟁자가 될 만한 동료의 배제와 단순히 맘에 들지 않는다는 이유로 퇴사시키는 용도로 사용될 수 있다는 점입니다. 말 그대로 찍히면 안 되는 새로운 형태의 사내 왕따 도구가 될 수 있다는 점입니다.

 

이 때문에 기획자는 애자일 개발 팀의 상호 작용이 긍정적으로 흐를 수 있도록 관리해야 합니다. 생산성을 중요시하는 일반적인 SI나 웹에이전시 프로젝트에서는 이를 PM이나 각 파트 PL들이 하나 애자일 팀에서는 PM, PL을 따로 두는 것도 비효율과 상호작용을 저해하게 됩니다. 

 

그리고 기획자의 업무는 전통적 개발 프로젝트에서 처럼 화면을 그리는 작업을 할 필요는 없습니다. 이에 대한 이유는 위의 문서 부분에서도 한번 언급하였습니다. 추가되는 이유는 아래 조직 관리 부분에서 다시 나오게 될 것입니다.

 

기획자의 업무가 문서가 아닌 애자일 개발의 최종 앱과 이 앱이 출시되는 빠른 타이밍에 집중된다는 점에서 전통적 IT 인터넷 프로젝트 담당 업무가 아닌 학문적인 기획 업무에 더 가깝다 할 수 있습니다.       

 

 

애자일 개발 조직 관리

애자일 개발은 원론적으로 이견과 불협 화음의 과정입니다. 이 때문에 대규모 생산성은 낮아질 수밖에 없습니다. 반대로 이런 이견 때문에 문제 해결 가능성은 커지게 됩니다.

 

기획자는 애자일 팀에서 발생하는 이견과 다툼이 문제 해결을 위한 방향으로 흐를 수 있도록 만들어야 합니다. 이를 위해서 상대의 업무가 존중될 수 있는 환경을 구성해야 합니다. 역량이 낮다면 아무리 기획자가 노력해도 상대가 인정하지 않으려 할 것입니다. 상대 또한 인정받는 능력의 소유자이기 때문입니다. 이 때문에 애자일 조직의 인력은 역량이 높아야 하는 것입니다.

 

그리고 기획자는 개발 문제를 단순화해야 합니다. 복잡할수록 상충의 노드는 많아질 것이고 이는 개발 자체를 복잡하게 만들어 빠른 개발을 불가능하게 합니다. 결국 단순화는 애자일 기획의 핵심이라 할 수 있습니다.

 

기획자의 머릿속에는 이 단순이 시스템화되어 있어야 합니다.

 

과거 제가 한 업무 중 중간에 중단되었지만 밀크런 서비스 기획을 했을 때, 기본적인 밀크런 서비스 흐름을 정리하고, 이 흐름에서 처리해야 하는 업무와 각 포인트에서 인터페이스 되는 프로세스를 따로 정리했습니다. 이 포인트 각각은 애자일 개발 프로젝트의 대상이 됩니다. 개발자는 이 포인트만 해결하면 됩니다. 그러나 기획자는 이 포인트들이 어떻게 연결되고 작동되는지 머릿속에 정리되어 있어야 합니다.

 

그러므로 기획자 역량은 애자일 개발 시 매우 중요한 성공 요인 중 하나입니다. 이때 기획은 기존 SI나 웹에이전시의 기획자 업무와 완전히 다른 것입니다. 아니 애자일 개발에서는 이런 기획자는 도움이 되지 않습니다.

 

애자일 조직 개발자는 기획자에 의해 설계된 눈앞의 명확하고 단순한 문제만 해결하면 됩니다 이것이 MVP일수도 있지만 전체 시스템의 한 부분이 될 수도 있습니다. 이렇게 문제를 해결하는 개발을 하다 보면 어느덧 토스, 쿠팡과 같은 거대한 온라인 시스템이 되어 있을 것입니다.

 

추가로 기획자는 외부의 애자일 조직을 흔드는 시도 또는 외부 타 조직과 협업을 해야 하는 필요에 대한 대응과 이를 정리하여 개발자들이 처리할 내용을 이해하기 쉽게 해 주어야 합니다.

 

애자일 개발 조직은 단순하고 분명한 개발 대상을, 빠르게 완료하여 론칭한 후 테스트하고 다시 보완하는 작업이 빠르게 반복될 수 있도록 구성되어야 하는 것입니다. 기획자는 이 순환이 효과적으로, 효율적으로 이루어질 수 있게 설계/관리하는 것이 역할이라 생각합니다.