외주 개발 프로세스와 현장에서 느낀 문제점

외주 개발은 고객사가 개발사에게 개발을 맡겨서 시스템이 만들어지는 것을 의미합니다. SI나 웹에이전시 기업들의 사업 모델을 말합니다.

저는 프리랜서 PM도 했지만 주로 기획자로 외주 개발 프로젝트에서 일을 했습니다. 원래 IT 신규 사업, 마케팅을 하다가 서비스에 대한 개발도 참여하게 된 것이라 자연스럽게 전통적인 화면 중심 기획 뿐 아니라 IT 비즈니스 전략, 서비스 구조 설계, 로직 설계 등을 하게 되었습니다.

이렇게 다양한 영역에서, 다양한 관점의 기획/설계 업무를 담당했던 경험을 바탕으로 외주 개발이 진행되는 프로세스와 실무적으로 단계적 IT 수행과 성공 및 실패라는 측면에서 느낀 문제점을 정리해 보겠습니다.

외주 개발 일반 프로세스 요약

계약이 이루어진 이후 외주 개발은 다음의 프로세스로 진행됩니다. 세부적으로 다른 과정이 추가 될 수 있겠지만 다음의 1~6 단계를 거치는 것이 일반적이라 생각합니다.

1. 프로젝트 착수(킥오프): 수행 계획 수립, 초기 팀 구성, 인프라 및 개발 환경 등을 구축하는 단계입니다.

2. 분석: As-Is 현행 시스템이 있는 경우 As-Is 분석과 함께 계약 요구사항을 분석.구체화 진행힙니다. As-Is가 없는 신규 시스템의 경우 요구사항을 분석합니다. 이를 통해 계약이 목적한 구체적 시스템을 내용과 범위를 정의합니다.

3. 설계: 흔히 뒤에 A가 분은 인력들이 투입되어 작업을 하는 단계입니다. 대표적인 설계자로 BA, TA/SA, DA, AA 등이 있습니다. As-Is가 있는 경우 분석 단계에서부터 작업을 하기도 합니다. 보통 PM과 PL이 분석/설계 단계를 리딩합니다. 설계 단계의 마지막에는 화면 설계가 진행됩니다.

4. 개발: 계약된 시스템을 개발하는 시기로 가장 많은 인력이 투입되고 기간을 차지하는 단계입니다. 본격적 코딩을 통해 확인 가능한 산출물이 나오기 시작합니다.

5. 테스트: 일반적으로 테스트 단계라 하면 개발이 완료되어 통합 테스트를 진행하는 시기를 의미합니다. 사용성 테스트가 이루어지며 성능/부하 테스트, 보안 취약점 점검 등이 이루어집니다. 테스트 기본 사항은 요구사항 항목들의 개발 구현이 됩니다.

6. 배포 및 안정화: 개발 완료 후 테스트까지 통과하면 배포와 고객사 이관을 진행합니다. 계약에 따라 일정 기간 안정화와 하자 보수 진행을 하기도 합니다.

최근 외주 개발은 애자일 방식의 진행을 취하기도 하지만 실질적인 진행은 위의 6단계 처럼 명확한 선형 단계와 구체적 산출물을 기반으로 전형적인 폭포수 방식을 보이고는 합니다. 이유는 외주 개발이 '계약'과 '요구 사항'이라는 구체성에 기반하여 프로젝트가 진행되기 때문입니다.

또한 수행사 입장에서 관리 리스크를 줄이기 위해 명확한 업무 구분과 산출물을 요구하기도 합니다. 이러한 문서들을 기반으로 고객 컨펌 과정을 거치므로 후반에 발생하는 프로젝트 리스크를 햇징하려는 의도도 실질적 애자일 방식의 진행을 어렵게 합니다.

외주 개발 현장에서 느낀 문제점

외주 개발 프로젝트를 하면서 느낀 문제점 (그림생성-제미나이)

모든 프로젝트가 그런 것은 아니지만 외주 개발 현장의 조직 구성 및 업무가 상당히 형식적으로 진행된다는 것입니다.

작게는 인력 투입에서 외주 개발 현장에 반드시 존재하는 주간 회의에서부터, 크게는 계약 시스템 구성에 대한 설계에 이르기까지 형식적인 산출물 작성 및 개발 행위를 했다는 것에 포커스를 둔다는 느낌을 받는 경우가 많았습니다.

마치 고객사 비즈니스에 맞는 시스템을 개발하는 것이 목적이 아닌 계약 수행 근거를 만드는 작업으로 주간 회의, 요구 사항 문서, 설계, 코딩 등을 형식적으로 작업한다는 느낌이었습니다.

국내 기업 조직의 고질적인 문제이기도 한 형식주의 및 과거 경험 패턴에 의해 업무를 진행하고, 이를 근거로 책임을 회피하는 문화를 최근으로 올수록 외주 개발 현장에서 자주 그리고 강하게 느끼게 됩니다.

이러한 결과 제 기준 프로젝트에 실패하는 외주 개발 현장이 늘어나고 있다고 봅니다. 물론 산출물을 다 제출하면 성공이라 생각하는 프로젝트도 있었고, 일단 완료되면 성공이라 보는 듯한 현장도 있었습니다. 하지만 이런 현장은 제 기준으로는 실패입니다. 고객사 불만으로 계획된 프로젝트가 최소 되고, 추가 개발로 인해 기간이 연장되고, 추가 인력을 개발사가 부담하여 투입해야 하는 상황도 제 기준으로는 실패입니다.

그리고 최근 이렇게 실패 현장이 외주 개발 계약에서 증가한 것은 다음의 문제 때문이라 생각합니다.

• 계약 분석 역량 저하

• 설계 부실

여기서 설계는 화면 설계를 의미하는 것은 아닙니다. 화면 설계는 과거에 비해 작업 툴과 경험 인력의 증가로 오히려 스킬이 더 나아진 면이 존재합니다.

말하고자 하는 설계는 화면 설계 이전 프로젝트를 정의하고 구체적 개발 내용을 설계하는 BA 작업을 의미합니다.

외주 개발 프로세스 과정의 경로 의존성

외주 개발 현장의 문제점 1: 분석 역량 저하

저의 경우 자주 외주 개발 프로젝트에 중간 투입 되었습니다. 저는 경력 상 외주 개발 기획자는 아니기 때문입니다. 서비스 기업과 창업을 통해 기획자로 작업을 하다가 사정으로 외주 개발 프리랜서 기획자를 하게 되었습니다. 이 때문에 많은 경우 프로젝트 수행 계획에 따라 투입되는 기획자가 아닌 기 투입 기획자 대체로 중간 투입되는 경우가 많았습니다.

제가 중간 투입 되는 경우 크게 3유형이었습니다.

• 기존 기획자 철수: 기존 기획자가 소정의 문제로 철수하여 투입되는 경우입니다. 일반적으로 가장 많을 것입니다.

• 초기 단계 투입: 케이스는 작지만 프로젝트 초기 분석/설계를 위해서 입니다. 킥오프 후 몇 달 동안 프로젝트가 진행이 안되고 있는 경우입니다. 보통 외주 개발에서 분석/설계 시 기획자가 투입되는 경우는 거의 없으므로 많지는 않습니다.

• 후기 중간 투입: 프로젝트 끝날 무렵 투입되는 경우입니다. 이 경우도 많지는 않습니다. 저의 경우 프로젝트는 개발 사항과 기획서가 맞지 않아 개발 사항과 기 작성된 기획서를 크로스 분석하여 현행화 하는 롤로 투입된 적이 있었습니다.

프로젝트 초기 중간 투입 외주 개발 현장의 문제점

프로젝트 초기 기존 인력 교체나 추가로 중간 투입된다는 것은 매우 심각한 신호입니다. 그러나 후기 중간 투입에 비해서는 그래도 더 나은 상황이라 할 수 있습니다. 최소한 대응할 남은 시간이 있기 때문입니다.

이 케이스 상황의 프로젝트에 투입되어 인수인계를 받으면서 상황을 분석해 보면 킥오프 이후 정확한 프로젝트 범위와 내용에 대한 정의, 여기서 이어지는 목적 시스템의 설계가 진행되고 있지 않음을 확인하게 됩니다.

그렇다고 작업 된 내용이 없는 것도 아니고, 고객이 설명을 잘 안 해준 것도 아닙니다. 고객과 수행사 투입 개발자들과 함께 회의를 해 보면 현행 시스템에 대해서는 고객보다 더 많이 알고 있습니다. 심지어 고객사는 여러 부서 담당자가 나누어 아는 내용을 수행사 분석 담당자는 모두 알고 있기도 했었습니다.

그런데 계약에 의해 정의된 목적 시스템이 무엇인지에 대한 분석은 제대로 되어 있지 않습니다.

고객사가 외주 개발을 맡기는 이유는 자신의 시스템 내용을 몰라서가 아닙니다. 이미 기존 레거시 시스템으로 비즈니스를 하고 있기 때문입니다. 레거시 시스템이 수동이든, 부실하든 일단 비즈니스는 작동되고 있다는 점에서 비즈니스 시스템을 고객이 모르는 것은 아닙니다. 단지 이 비즈니스 시스템을 더 편하고 유용한 프로그램 시스템으로 어떻게 개발할 지 모르는 것일 뿐입니다. 그래서 외주 개발을 계약한 것이라 저는 생각합니다.

고객사가 외주 개발사에 비용을 부담하면서 개발을 맡긴 이유는 더 나은 시스템, 더 편리한 작업, 기존에 없었지만 필요한 로직의 구현 등을 원하기 때문입니다.

한 마디로 프로그램 시스템 관점에서 고객사 문제를 파악하고 이에 대한 해결 방안을 제시하는 과정이 이루어지지 않고 있는 것입니다.

업무 분석을 해 보면 이런 상황이 만들어진 원인은 간단했습니다. 고객사 비즈니스가 아닌 이전 수행사 또는 분석/설계자가 경험하고 배운 지식대로 작업을 하기 때문입니다. 그러기에 산출물은 나오지만 해당 프로젝트 분석/설계는 부실화 되는 것입니다.

다양한 많은 양의 산출물은 나옵니다. 그러나 이 산출물은 이 프로젝트 개발에 쓸 수가 없습니다. 어디에나 맞을 수 있는 분석/설계 문서인데, 특정 프로젝트에는 쓸 수 없는 그냥 일반론 또는 다른 프로젝트 케이스 문서인 것입니다.

결국 이는 분석 능력이 없다는 것을 의미합니다. 단지 외우거나 경험에 의해 기억한 내용을 고객사 비즈니스와 요구와 상관 없이 산출물을 위해 문서화 한 것일 뿐입니다.

외주 개발 현장의 문제점 2: 설계 역량 부실

재밌는 사실은 분석이 안되었는데 설계가 진행된 것을 확인할 수 있다는 점입니다. 이는 작업 형식주의에 대표적인 모습입니다. 특정 행위를 한 자체로 완료되었다 인정하는 것입니다. 보통 형식주의는 되었는지 안되었는지 파악할 수 있는 전문성이 떨어질 때 발현합니다. 그리고 이러한 형식주의는 결국 프로젝트 팀 내 정치적 관계를 형성하여, 업무 진행이 아닌 책임 떠 넘기기에 몰두하게 만들게 되는 것을 경험한 적도 있습니다.

제가 중간 투입된 한 프로젝트는 고객사 비즈니스에 대한 파악과 정리 없이 화면 설계가 진행되기도 했습니다. 정책과 비즈니스 로직의 분석과 설계가 없다보니 참고 사이트와 앱을 보고서 스토리보드를 작성하고 있었습니다.

이렇게 작업되는 화면 설계는 엄밀히 화면 디자인과 많은 부분 겹칩니다. 그래서 단순히 화면 구성과 UI를 설계하는 경우 해외의 경우 앱/웹 디자인 작업으로 구분하기도 합니다.

화면에 로직과 플로우, 일반/예외 케이스과 피드백, I/O 데이터 등 상세히 정리되어 있지 않다면, 단지 기획 툴로 작성되었다고 해서 앱/웹 디자인이 아닌 기획/설계서라 할 수 없습니다.

이런 설계는 요구 사항 분석 및 상세화에 이어지는 정책, 기능 정의, 프로세스 설계 등을 거쳐 화면 정의서/목록이 나와야 정리될 수 있습니다. 특히 프로젝트 규모가 커질 수록 이런 기획의 체계화가 중요해집니다. 사람의 뇌의 기억력과 정리 능력이 생각보다 뛰어나지 않기 때문입니다.

그런데 외주 개발 프로젝트 중 규모가 큰 것에 속하는 금융 시스템 차세대에서 조차 이런 분석에 이어진 설계 없이 바로 화면 설계를 하는 것을 보았습니다.

이 경우 화면 설계 과정에서 예상하지 못한 케이스의 로직과 화면들이 마구 나타나게 됩니다. 결국 1000개의 화면을 예상했는데 1500 넘는 작업 화면이 나오게 될 수 있습니다. 당연히 화면 ID 관리는 안되고 작업을 하면 할 수록 프로젝트는 혼란과 혼동에 빠지게 됩니다.

이는 설계를 잘 못한다를 넘어 설계를 어떻게 하는지 모른다라고 할 수 있습니다. 화면 설계는 업무에 '설계'가 있으니까 설계라 말하는 것과 같습니다.

분석은 설계를 위한 베이스입니다. 분석이 없는 설계는 단순한 흉내 또는 모방입니다. 그러므로 이러한 설계는 오리지널이 아니고 어떤 것을 따라 그린 것에 지나지 않게 됩니다. 이 결과 고객사 비즈니스를 수행하는 시스템이 아니게 됩니다.

설계자는 분석의 중요성을 잘 압니다. 그러므로 분석을 잘 못하는 것은 설계를 할 줄 모르는 것과 같습니다. 분석과 설계는 벡터의 시작과 끝과 같기 때문입니다.

분석/설계 없이 화면 설계가 진행되는 것은 업무 속도가 빠른 것이 아닙니다. 단지 분석/설계를 할 지 모르는 것입니다. 그러므로 개발된 앱과 웹 사이트는 고객사 비즈니스 타당성과 멀어지는 것은 물론 결함과 버그로 프로젝트가 혼란에 빠지게 됩니다.

외주 개발에서 점점 분석/설계가 부실해지는 이유

외주 개발 기획 프리랜서 생활을 하며 만난 외주 개발 시장에서 뼈가 굵어진 개발자 분과 나눈 대화 중 이런 것이 있습니다. 일단 생각나는 대로 정리해 보겠습니다.

"만약 외주 개발에 100명이 투입된다면, 50명은 기본도 못하는 또는 안 하는 인력이다. 그리고 30명은 자기 맡은 역할 딱 그 정도만 할 수 있는 사람, 나머지 20명이 50명 일까지 한다. 그런데 받는 단가는 똑같다."

이 이야기는 외주 개발 비즈니스가 운영되는 원리를 말하고 있습니다. 그리고 그 속에서 실행 역량 중요한 분석/설계가 왜 부실화 될 수 밖에 없는지 제 생각을 정리해 보겠습니다.

• 맨먼스 비용 산정: 맨먼스 기준 비용 산정 또는 증빙은 역량과 실력이 아니라 투입 인력 수가 중요함.

• 산출물 중심주의: 기능 단위에서 산출물 자체가 중요한 기준이 됨. 산출물의 프로젝트 타당성은 서로 다른 기능 부문 간 협업 시 문제가 되어도 관리 입장에서 큰 문제는 아님.

• 경력 중심 단가 체계: 경력으로 고급을 지향할 뿐 실력의 고급은 지양하게 됨.

현재의 개발사 관점 외주 개발 비즈니스의 두 중심 축은 맨먼스와 요구사항 개발입니다. 그리고 맨먼스는 등급과 개발은 화면과 코드에 기준을 둡니다. 고객이 컨펌하는 경력의 소유자라면 일단 투입하고, 화면 컨펌 과정을 거쳐 개발된 버그 없는 코드라면 최종 산출물로 문제 없습니다. 개발 프로젝트 현장에서 비지니스 로직은 고객사 책임입니다. 개발사는 이를 코드화 해 주면 됩니다.

문제는 이러한 프로젝트가 반복되면서 자연스럽게 분석/설계 능력이 퇴화하게 된다는 것입니다. 인터넷이나 컨설팅 문서에 있는 관련 비즈니스 구조도와 프로ㅔ스 문서로 형식적인 설계서를 완성합니다. 고객사와 회의를 하면서 컨펌 받은 화면 설계서를 만들고 개발을 진행하면 이후 문제가 생겨도 컨펌이라는 대책이 있으므로 어떻게든 해결이 됩니다. 어차피 개발적인 분석/설계는 고객도 모르기에 문제 삼지 못한다는 것을 경험 학습 되었습니다.

프로젝트 초기 분석/설계는 상대적으로 높은 수준의 기술 역량을 의미합니다. 하지만 맨먼스 및 경력 중심 단가 체계에서 이런 인력의 고 단가는 프로젝트 운영에 부담이라고 생각하는 것 같습니다. 어차피 많은 기획, 개발 인력이 투입되는 화면 설계, 개발 단계에서 코딩으로 해결할 수 있다 생각합니다. 아니면 많은 고급 개발자 중 누군가 해결할 것이라 기대하는 듯 보였습니다.

그러나 이는 공학 시스템(프로젝트)이 갖는 경로 의존성에 대하여 모르기에 그러는 것입니다. 왜 일론 머스크 조차 생산과 자동화에 앞서 설계의 단순화와 최적화를 말했을까요?

잘못된 분석과 설계를 방치할 경우 나타나는 복잡성의 작용으로 뒤에 이를 해결하는 것이 너무 어렵습니다. 변수가 많아질수록 카오스 현상이 가속화되는 현상 때문입니다. 우리는 이를 이미 넷플릭스 드라마 '삼체'를 통해 확인하였습니다.

결국 분석/설계의 부실은 개발 단계에서 수정하기 매우 어렵습니다. 그럼에도 왜 분석/설계 단계를 형식적으로 산출물 생성과 프로젝트 수익률을 높이는데 활용할까요?

이는 모르기 때문이라고 저는 생각합니다. 실제 모든 프로젝트는 아니지만 상당히 많은 프로젝트의 선투입되어 분석/설계를 해야 하는 인력들이 기본적인 분석/설계 R&R을 모르는 것을 보았습니다.

당연히 문제가 생기면 추가적인 분석/설계 인력을 투입합니다. 이 경우에도 비용을 아끼려는 개발사의 모습을 볼 수 있습니다. 이 때문에 추가 투입에도 실패를 하게 됩니다. 1~2명 정도의 분석/설계 비용을 아끼려고 프로젝트를 카오스로 만드는 것입니다. 이는 마치 나비의 날개 짓이 태평양 반대편의 태풍을 만드는 나비 효과의 시작을 보는 듯 합니다.

외주 개발에서 분석/설계 부실의 결과

제가 중간 투입 사례 중에는 프로젝트 종료 시점도 있습니다. 이 경우 해당 프로젝트는 이미 큰 문제가 가시화 된 것입니다. 그런데 프로젝트 산출물과 개발 사항을 모아 크로스 분석해보면 처음 킥오프 이후 이 프로젝트 범위와 내용에 대한 분석, 계약 된 시스템을 개발하기 위한 설계에서부터 이미 완전히 잘못되어 있다는 것을 발견했습니다.

마치 60층 건물로 계약을 하였는데 설계는 2층 건물이고 작업은 50층을 넘게 올린 것입니다. 당연히 문제가 생겼고 이를 해결하려 하는데 해결이 안 되니 계속 팀만 교체하고 있었습니다. 팀이 여러 번 교체되다 보니 기획과 개발의 연속성이 없는 상태였습니다.

분석/설계 부실은 결국 개발된 시스템 부실로 이어집니다. 이것은 다양한 기능이 유기적으로 상호작용하여 작동되어야 하는 시스템 공학의 필연입니다.

그리고 분석/설계의 부실은 적절한 인력 투입이 아니라 단지 형식적 인력 투입, 맨먼스를 채우기 위한 투입을 했기 때문입니다.

프로젝트 경로 의존성

서울에서 부산을 가기 위해서는 경부 고속도로를 타거나 경부선 기차를 타야 합니다. 서해 고속도로를 타고 가면서 부산이 왜 안 보이냐고 하면 안됩니다.

이러한 경로 의존성은 업무에 있어서도 중요합니다.

여러 회사와 다양한 프로젝트를 경험하면서 경로 의존성은 분명한 결과를 형성합니다. 물론 서해 고속도로를 탔다고 해서 부산에 도착하지 못하는 것은 아닙니다.단지 돌아서 가기에 더 긴 시간이 걸릴 뿐입니다.

이를 어떤 수행사는 성공이라 말 하기도 합니다. 단지 수행사는 자신이 비용을 내고 더 긴 시간 개발을 해야 했을 뿐입니다. 계약으로 받은 금액보다 더 많은 돈을 써서 더 긴 시간 개발을 했지만 고객이 인수 했으므로 성공이라 합니다.

과연 그럴까요? 고객사가 만족했을까요?

이 고객은 이어서 두 번째 계약을 할까요?