WBS와 애자일, 외주 개발

요즘 외주 개발에서도 애자일 방식 이슈가 있는 듯합니다. 과거 함께 일했던 개발사도 애자일 방식을 적용하겠다는 이야기를 들었고, SDS 같은 대형 SI 회사도 애자일 방식으로 개발을 진행하고 있다는 말을 들었습니다. 그런데 계약과 대상에 기반한 개발이 과연 애자일과 어울리는 것일까 하는 의문은 듭니다.

 

 

애자일과 외주 개발 궁합

 

외주 개발은 기본적으로 계약에 기반합니다. 그렇기 때문에 계약의 범위를 구체화하는 요구 사항 정리가 진행됩니다. 이 구체적인 계약의 범위를 정하는 과정은 계약 금액과 연결되어 프로젝트 수익률을 결정하는 중요한 요인이 됩니다.

 

그리고 외주 개발 계약은 기간 조건을 달고 있습니다.

 

그렇기 때문에 일반적인 외주 개발은 계약과 요구 사항 그리고 기간을 기초로 한 WBS가 작성됩니다. 이 WBS를 보면 해당 계약의 개발이 언제까지 어떻게 진행되는지 파악할 수 있습니다. 또한 지금까지 개발된 내용과 현재 작업하고 있는 내용을 파악할 수 있습니다.

 

이 WBS를 통해 개발 진행 사항을 알 수 있을 뿐 아니라, 향후 어떤 개발이 진행될지 또한 미리 알 수 있어 이에 대한 준비를 사전에 할 수 있도록 합니다.

 

이러한 계획은 전반적인 앱/웹 서비스 전략 관리에 중요한 소스가 됩니다.

 

그러나 이러한 개발 특성은 애자일과 다소 맞지 않는 부분이기도 합니다. 개발에 대한 사고와 대상이 다르다는 표현이 어쩌면 더 쉬운 설명이 될 수 있을 듯합니다.

 

이를 위키백과에 나오는 애자일 선언문을 통해 검토해 보아도, 이 충돌 지점은 쉽게 파악될 수 있습니다.

 

• 공정과 도구보다는 개인과 상호작용을

요구 사항에 기반한 개발 도구의 지정 및 공정 관리 외주 개발 프로젝트의 시작을 엽니다. 

 

• 포괄적인 문서보다 작동하는 소프트웨어를

요구 사항, WBS, 화면 설계서 등의 문서를 작성하는 것은 외주 개발 프로젝트의 너무 당연한 것입니다. 그리고 이를 당연하다고 하면서 애자일을 의미하는 것은 모순입니다.

 

• 계약 협상보다 고객과의 협력을

계약의 외주 개발의 기본입니다. 계약이 없거나 불분명한 프로젝트는 항상 문제를 만듭니다. 그렇기에 계약을 구체화하는 요구 사항 상세화, 기능 정의, 화면 정의 등의 기획 작업이 외주 개발 시 진행됩니다. 더하여 종종 녹취 방법도 활용됩니다. 이 차제가 애자일 사상과는 충돌하는 부분입니다.

 

• 계획을 따르기보다 변화에 대응하기를

WBS를 작성한다는 사실 자체로 철저히 계획하에 작업한다는 것을 의미합니다. 많은 외주 개발 프로젝트가 WBS를 간단히 또는 준비 없이 작성하기도 합니다. 그러나 주간 보고, 월간 보고 시 고객의 요구에 따라 이 성의 없이 작성된 WBS는 프로젝트 팀의 목을 옥죄게 될 것입니다. 만약 이런 일이 있다면 이 성의 없는 WBS 작성 유도는 마치 계약 내용을 보지 않고 사인했을 때 발생되는 현상을 향후 개발 협상 과정에서 볼 수 있을 것입니다.  

 

 

 

WBS를 작성한다는 것의 의미

 

WBS 작성은 개발 기간을 특정하고, 이 기간 동한 개발 완료되어야 하는 부분을 구체화한다는 것을 의미합니다. 이 말은 사전에 이 기간에는 무엇을 개발하고, 이를 어떻게 개발할지를 미리 정한다는 사실을 의미합니다.

 

이는 다시 확실성 하의 개발 전략을 의미하며, 이 때문에 계약은 중요해집니다. 또한 이러한 개발 방식으로 인해 대규모 개발 인력의 효율적 관리가 가능해집니다. 

 

이 말은 다시 개발이 환경 적응 기반, 문제 해결 기반으로 진행되는 것이 주목적이 아니라는 것을 의미하여도 합니다. 계약과 WBS 기반 개발은 근본적으로 관리형, 효율성 개발을 추구한다는 의미를 가집니다.

 

이를 이해하기 위해서는 경영 전략 측면과 조직 관리 측면의 이해가 있어야 하기는 합니다. 단지 개발론만으로는 이를 이해하기에는 조금 힘이 들 수도 있습니다.

 

그러나 분명한 사실은 계약과 WBS에 기반한 개발 조직과 애자일 개발 조직은, 각 개발 조직이 지향하는 목표가 다르다는 것입니다.

 

이는 마치 대기업이 문제 해결을 위해 TFT를 구성하는 것과 같습니다. 생상성 측면과 관리 효율 측면에서 TFT는 기존 대기업 조직에 비해 현저히 낮은 퍼포먼스를 나타냅니다. 그러나 문제 해결이라는 측면에서 기존 대기업 조직이 풀어내지 못하는 퍼포먼스를 보입니다.

 

그러기에 애자일 개발 조직은 매우 소규모입니다. 그러기에 개인의 상호작용을 중요시할 수 있고, 문서보다는 소프트웨어를, 협력을, 변화 대응 기반 개발이 가능한 것입니다.

 

계약과 WBS 외에도 만약 기획 툴을 피그마, 액슈어, 어도비 등 특정 도구를 지정하고 진행한다면 이미 프로젝트 사고 자체가 애자일이 아닌 것은 분명합니다. 이는 특정 조직이 내부적 관리 효율화 목적을 기반으로 설정하는 것이기 때문입니다.  

 

 

 

지식과 경험

 

애자일이나 폭포수 방법론 등을 포함한 작업 방법론과 조직 관련 구조에 따른 퍼포먼스 유형에 대한 연구는 이미 많이 이루어졌습니다.

 

이는 축구 전술에서 3-3-4, 4-2-4, 4백, 5백 같은 포메이션에 따른 경기의 차이만큼이나 경영 기획/전략 측면에서 많은 연구가 있었던 분야이기도 합니다.

 

초기 스타트업의 기업의 경우 3~4명이 시작합니다. 이러한 기업 조직이 생산성이나 규모의 경제를 추구한다면 경쟁에서 도태될 것입니다. 그러기에 스타트업은 창의성, 문제 해결 능력 기반 기존에 없는 시장 접근법을 통해 경쟁력을 형성합니다.

 

그러다 성장해서 직원 10명 전후 소기업이 되어도 대표가 직원 하나 하나와 커뮤니케이션할 수 있는 정도입니다. 이 때도 관리와 기업의 운영은 애자일 같이 할 수 있습니다. 아직도 이 규모는 대기업으로 보면 TFT 수준이기 때문입니다.

 

그러나 기업이 더 성장해서 30~40명을 넘어가면 조직이 분화되고 중간 관리자를 통한 관리가 진행됩니다. 상호 작용은 각 파트로 나뉘어 진행되고, 이는 조직 정치를 만들어 내는 요인이 되기도 합니다. 이때의 갈등 관리는 아이디어를 폭발하는 계기가 되기도 하지만, 기업이 시장과 멀어지는 계기가 되기도 합니다.

 

이 정도 되면 기업은 여러 관리 툴을 도입하려 할 것입니다.

 

이 단계에 흔히 말하는 린 기업, 애자일 기업, 플랫폼 기업 등에서 생산성과 관리 중심의 기업으로 변화해 가는 과정이기도 합니다.

 

사람이 많아지는 관계로 상호 작용은 직접 대면이 아니라 도구를 활용하게 되고, 이를 통합하기 위해 도구의 표준화는 강조됩니다. 이러한 변화는 조직 창의성을 낮추지만, 조직 생산성을 높이게 됩니다. 그리고 시장 변화를 인지하여 적용하는 프로세스에 걸리는 시간도 과거에 비해 길어지게 됩니다. 이는 다시 창의성이나 문제 해결 역량보다 생산성을 더 강화하는 요인으로 작용합니다.

 

그러므로 기업 전략 또는 조직과 성과라는 측면에서 보아도 외주 개발에서 일단 PM에 각 파트 PL, 리더가 있고 동일 기간 작업하는 개발자가 20명 이상 투입되는 개발 프로젝트가 애자일을 추구한다고 말하는 것은 삼성전자가 스타트업이라고 주장하는 것과 같다는 것입니다. 

 

자본주의와 기업이 생겨나고 성장했던 백여 년 넘는 기간 진행되었던 조직과 생산에 대한 연구 결과를 애자일과 외주 개발에 적용해 본다면 전략의 효과가 어떤 상황에서, 어떠한 포지션을 취할 때 더 효과적인지 알 수 있습니다.

 

여기에 실제 개발 프로젝트를 경험하면서 개발 조직 이론을 적용해서 분석해 보았다며 더 명확해질 것입니다.

 

그러므로 제가 이 글에서 결론적으로 말하고자 하는 것은 바로 이것입니다.

 

충분한 지식을 쌓고, 다양한 경험 속에서 이 지식을 활용해 본 후, 결과를 분석하고 재 구축하는 과정이 있어야 비로소 포메이션을 이해할 수 있다는 것입니다.

 

축구에서 수비형 전술을 가지고 공격만 하는 시합을 한다는 것은 말이 되지 않을 것입니다.

 

그러므로 계약하고 WBS 만들고, 수백 페이지 화면 설계를 한 후 개발하면서 애자일을 외치는 것은 수비형 전술로 공격만 하는 축구와 같은 것입니다.