애자일(Agile)만 하면 안되는 이유!

제목이 거창하다. 최근 실용적이고 효율적인 조직 문화를 만들어 생산성을 극대화하고자 하는 기업들이 가장 많이 선택하고 답습하고 있는 애자일은 위키에 아래와 같이 정의되어 있다.

 

애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다. 최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링뿐 아니라 다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.

 

사실 애자일에 대해 깊이 있게 알고자 하면 구글링만 해도 워낙 많은 자료들이 쏟아져 나오기 때문에 애자일에 대한 이야기보다는 애자일을 무작정 찬양하는 일부의 사람과 기업에 반대되는 글을 기고하려고 한다. 사실 린(Lean), 애자일 등이 스타트업에 극단적으로 퍼지게 된 가장 큰 이유는 프로토타입의 빠른 검증 때문이다. 여기서 중요한 것은 스타트업에 극단적으로 많이 퍼지게 된 배경이다. 창업을 한다는 것은 창업자를 포함해 초기 멤버들에게 있어 엄청난 기회비용을 가져온다. 창업한 기간이 1년이면 어느 기업에 취업하고 벌었을 1년 간의 연봉, 취업하면 사용하지 않았을 초기 투자와 같은 금전적인 '비용'을 넘어 시간과 경험이라는 어마어마한 비용을 지불한다. 물론 창업 경험과 기업에서의 실무 경험 중 어떤 것이 더 이득인지 논하기 어렵지만 대부분의 실무 프로세스를 몸으로 경험한다는 점에서 필자는 기업에서의 실무 경험을 초기에는 더 높게 평가하는 편이다. 게다가 대부분의 시드(Seed) 투자가 개인이 모았거나 지인들의 자금인 만큼 검증되지 않은 아이디어에 과감한 투자가 어렵기 마련이다. 따라서 리스크 비용을 줄이기 위해 빠르게 시장에 적합한 아이디어인지 최소한의 테스트가 중요하다. 그래서 많은 스타트업들이 직접 목업을 그려서 설문조사하는 것부터 시작해 제품을 만들기까지 다양한 검증 작업을 실행한다. 그리고 이러한 현상에 맞춰 다시 각광받게 된 것들이 PoC(Proof of Concept) 또는 Pilot 제품 개발이다. 사실 이름은 거창하지만 결국 빨리 시장에 내놓고 반응을 지켜본다는 것인데 굳이 전통적인 경영학까지 돌아가지 않더라도 많은 기업들이 이미 신제품을 개발함에 있어 이런 과정을 거친다. 

 

예를 들어 음료를 만드는 기업이 새로운 음료를 시장에 출시하여 반등을 꾀한다고 가정하자. 목표는 점유율 2위인 탄산 음료 시장에서 1위를 탈환하는 것이고 이를 위해 기업은 다양한 가설을 설정한다. 새로운 탄산음료를 출시하여 다양한 제품 라인으로 고객층을 확보하는 방법부터 기존 음료의 맛을 더 첨가하거나 가격을 낮추거나 하는 등의 여러 가지 아이디어가 도출되면 생산에 필요한 가격부터 기대 효과까지 전체적인 시뮬레이션을 시작하게 된다. 정확하게 맞는 상황은 아니지만 이렇게 여러 가지의 가설 속에서 대안들을 찾아가고 기회를 발견하는 What-if 또는 PON(Problem-Opportunity-Needs)이 끝나면 가장 좋은 효과가 기대되는 한 가지의 안을 선택하여 Pilot 제품을 만들게 된다. 이러한 과정을 거쳐 만들어진 초기 제품은 시음회라는 이름으로 무작위로 추출된, 혹은 타깃 고객층과 유사한 그룹으로 선별된 테스터들에게 검증을 받게 된다. 물론 제조업의 특성을 고려하면 여기까지도 엄청난 비용이 들어갈 것이고 시음회의 이름을 걸고 모집된 이상 어느 정도 내부 검증이 끝난 상태에서 시음회가 펼쳐졌으니 이렇게 개략적으로 살펴보는 것만으로는 비교가 어렵다. 다만 필자가 이 사례에서 강조하고 싶은 것은 일부에서 말하는 '굴뚝산업 꼰대 기업'들도 실험, 검증, 피드백의 기본적인 절차 속에서 작동하고 있다는 것이다.

 

경영학에서도 이 부분은 강조되어 설명되어 오는데 폭포수 모델이라고 불리는 Waterfall과 애자일의 가장 큰 차이는 이러한 빠른 실행과 검증 프로세스에 있는 것이 아니라 고객과의 접점의 차이가 가장 크다. 애자일은 기본적으로 단계를 구분하지 않고 개발자들이 고객의 피드백에 빠르게 반응하고 제품의 완성도를 고객이 높일 수 있게끔 하는 것이다. 전체의 프로젝트가 기획-디자인-개발로 나누어 버리는 방법이 아닌 기획, 디자인, 개발의 3단계가 프로젝트 안에서도 계속 반복되는 iteration으로 하나의 프로젝트를 세분화하고 나누는 것이다. 그래서 일부의 폭포수 모델을 사용하던 분들은 애자일도 결국 폭포수 모델을 작게 해서 반복하는 것 아니냐고 반문하곤 한다. 물론 이 둘은 동일하지 않다. 폭포수는 명확한 계획 아래 작동하는 프로젝트이므로 실패에 대한 비용이 크다. 예를 들어 제품이 다 완료되기 전에 다른 경쟁 업체에서 우리의 계획과 유사한 제품을 먼저 출시할 수 있는 것이다. 반면 애자일은 빠른 제품 피드백을 추구하므로 다소 계획은 명확하지 않지만 고객과 함께 성장하는 프로세스를 갖고 있어 우리의 계획이 남들보다 늦어지기 어렵다. 이러한 차이로 인해 많은 스타트업들이 애자일을 추구하는 것이 현실이다. 하지만 그렇다고 애자일이 모든 영역에서 정답일 수 없다.

 

애자일을 채택하던지 폭포수를 채택하던지 두 가지 방법론 모두 Plan-do-See의 기본적인 로직을 따른다. 어떠한 경우에는 'See'가 더 중요하다고 판단되어 잦은 See를 위해 짧은 do를 가져가고 더 짧은 Plan을 선택 해야할 수 있다. 반면 어떤 경우에는 잦은 See를 위한 Do가 우리에게 해가 될 수 있다. 스타트업들이 IR을 진행하며 VC들에게 가장 많은 질문을 받는 것 중 하나가 '카카오나 네이버가 하면 어떻게 경쟁할 것이냐?'이다. 사실 경쟁우위 전략이 아무리 잘 나와도 강력한 투자 앞에서는 속수무책으로 시장을 뺏기는 게 현실이다. 특히 아무도 따라올 수 없는 엄청난 기술을 갖고 있지 않는 Low tech 서비스일수록 이러한 질문에 더 취약하다. 그래서 테크 스타트업이 주목받는 이유이기도 하며 글로벌 성장에도 테크 스타트업이 유리하다고 대부분의 엑셀러레이터들이 말하는 이유이다. 근데 언제든지 시장 점유를 뺏길 수도 있는 상황에서 아이디어가 전부인 사업 아이템을 빠르게 시장에 출시하고 검증하겠다는 일념으로 파일럿 제품을 빠르게 내놓는 것은 결과적으로 아이디어만 경쟁에서 뺏기는 형태로 갈 수 있다. 사실 수많은 창업가들이 이렇게 아이디어를 뺏기거나 놓치고 있기도 하다. 중요한 기능과 서비스의 핵심 포인트를 완벽하게 숨기고 시장에 출시할 수 없지만 핵심 기능을 포함해 대부분의 서비스 자체를 파일럿이 아닌 일정 수준 이상의 완성도로 높이는 게 중요한 이유이다. 그래서 필자는 지금 하고자 하는 대략적인 Plan을 듣고 애자일이나 폭포수 중에 하나로 개발하기를 권하며 기업의 상황과 상태에 따라 두 가지를 병행하기를 권하는 경우도 있다. 물론 자신의 생각이 전부인 분들은 내게 애자일의 장점을 다시 역설하며 핵심 기능을 잘게 쪼개서 출시하겠다고 하기도 한다. 그리고 이렇게 하는 것이 애자일이고 린이라고 말한다. 사실 필자 입장에서 창업가가 어렵게 모은 시드머니를 쓰면서, 그리고 젊음을 불태우면서 See가 더 중요하다니 이해할 수 없다. 

 

이렇게 창업 아이템을 개발하는 과정 외에도 제품 자체를 개발하는 것에서도 애자일이 능사일 수는 없다. 대표적으로 기간과 제품 자체가 중요한 상황이거나 초기 가설을 검증하는 단계에서는 가설 설정부터 가설 검증을 위한 방법을 마련하고 최소한의 후보군 선정까지의 what-if 자체를 만드는 과정에서는 디자이너나 개발자들이 합류하여 어떤 행위를 할 수 없으므로 애자일 방식을 채택할 수 없다. 물론 그렇다고 모든 프로세스에서 폭포수가 정답이 될 수도 없다. 다만 애자일과 폭포수를 적절하게 활용하기 위해서는 구성원들의 Influence를 비롯해 계획의 Impact Factor들까지 고려하여 계획하고 올바른 방향으로 Facilitate할 수 있도록 리드해야 한다.

 

참고로 이렇게 어떤 방법론을 택하는게 적합한지 가설을 설정하고 검증하는 과정 자체도 쉽지 않고 어려운 일들이 반복된다. 심지어 시장이 제품과 트렌드에 반응하는 속도도 증가하여 최근에는 대기업들 조차 스타트업의 조직문화를 벤치마킹하며 자신들의 것으로 만들고 있다. 그리고 이 과정에서 이런 업무를 수행하는 직군의 필요성이 재조명받으며 Product Manager 또는 Product Owner로 불리는 사람들이 작은 조직별로 배치되고 Faclitator로서의 업무를 수행하게끔 하고 있다.