3)외주 개발 시 구조화 설계 필요성에 대하여

이전 작성 한 '서비스 기업 자체 개발 시 구조화 필요성'에 이어서 외주 개발 시 구조화 필요성에 대하여 정리해 보겠습니다.

많은 기업이 서비스 할 앱과 웹을 개발할 때 자체 개발과 외주 개발을 함께 진행합니다.

그러나 외주 개발은 자체 개발과 완전히 다른 작업 프로세스로 진행됩니다. 자체 개발처럼 짧은 기간 개발과 테스트, 검증이 반복되는 애자일 방식으로 진행할 경우 심각한 혼란에 빠지게 됩니다.

이는 외주 개발이라는 작업이 자체 개발과 완전히 다릅니다. 이에 따라 프로젝트 진행과 관리를 위한 거버넌스가 달라져야 합니다. 이에 따라 구조화 설계의 필요성에도 차이가 발생합니다.

외주 개발 시 구조화 설계 필요성 설명 이미

1.외주 개발의 목적 및 환경

앱과 웹을 개발하는 언어, 프레임워크, 라이브러리, 코드, 데이터, 인프라 등 개발 실행 측면의 요소는 외주 개발과 서비스 기업 자체 개발은 똑같습니다.

그러나 개발의 목적성과 직업 환경에서의 완전한 차이로 인해 외주 개발의 구조화 설계는 자체 개발 때와는 다르게 됩니다.

• 서비스 기업이 아닌 외부 다른 기업이 진행하는 개발

• 계약 기반 개발

1-1.외주 개발은 서비스 소유 기업이 아닌 외부 기업이 하는 개발

외주 개발은 근본적으로 다른 기업 또는 서비스 기업 직원이 아닌 개발자의 작업입니다. 그러므로 내부 업무의 처리 프로세스나 서비스 유저 가치 충족을 위한 개발이 원칙적으로 아닙니다.

더하여 외주 개발 프로젝트의 경우 하나의 개발사가 전체 프로젝트를 다 작업할 수도 있지만, 하청 개발사와 다수의 프리랜서를 활용하여 진행되기도 합니다. 이들 또한 서비스 기업 내부 직원이 아닙니다.

바로 이 사실은 외주 개발 계약에서 나타납니다.

1-2.계약 기반 개발

외주 개발은 계약으로 시작됩니다. 그러므로 이 블로그에서 많이 이야기 한 계약의 형태가 작업의 방식에 영향을 주는 '구조 결정론적 환경'의 영향을 받습니다.

이 사실은 계약에 기반한 외주 개발이 대상이 미래의 서비스 이용 유저가 아님을 분명히 한 것입니다. 외주 개발의 대상은 계약에 따른 고객사인 것입니다. 이는 개발 테스트 및 검수 통과의 주체를 통해서 확인할 수 있습니다.

단지, 고객사는 SI와 같은 외주 개발사에게 계약에 따른 개발 요구 사항을 제공할 수 있으며, 이 요구 사항의 내용에 서비스 유저 가치 요소를 넣어 제공하게 됩니다.

그러나 외주 개발 프로젝트 운영/관리 구조가 하청과 프리랜서로 이루어진 경우,

하위 하청업체와 프리랜서의 경우 고객사 요구가 아닌 고객사 요구를 해석한 외주 개발사의 개발 요구 영향을 더 많이 받습니다.

2.외주 개발 구조화 설계

외부 기업과 계약에 의한 개발이라는 점은 외주 개발 구조화 설계가 근본적으로 서비스 기업의 자체 개발과 달라야 하는 이유입니다.

• 기간

• 요구

• 비용

외주 개발 환경의 주요 요소는 기간, 요구, 비용입니다.

이중 기간과 비용은 계약 시 확정됩니다. 그러나 개발 요구는 대략적인 사항만 계약서에 첨부되지 구체적 부분은 프로젝트 시작 시 확정해야 합니다.

그런데 구체적 요구 사항 확정에 따라 물리적인 개발 기간과 필요 투입 인력에 따른 비용 변동이 있을 수 있습니다.

바로 요구 사항 구체화가 중요한 이유입니다. 그리고 외주 개발의 구조화 설계는 요구 사항 상세화에서 시작됩니다.

2-1.외주 개발이 목적 적합한 구조화 설계에 대한 의견

외주 개발의 요구 사항 기반 구조화 설계는 크게 두 가지 관점을 고려하여 통합적으로 진행되어야 합니다.

1. 고객사 관점: 고객사 요구 사항 상세화

2. 개발사 관점: 프로젝트 수익성 확보

여러 외주 개발 프로젝트를 경험하면서 이 두 관점이 통합적으로 설계되지 못한 경우 대부분 고객사의 개발 결과물에 대한 불만족이나 외주 개발사의 손실 문제를 가지고 프로젝트가 종결되었습니다.

2-1-1.고객사 관점의 외주 개발 구조화 설계

고객사가 실제로 원하는 계약의 목적 프로그램의 확정을정말합니다. 그리고 이는 비즈니스 전략적 부분과 내부 자원(사용 중인 시스템과 조직, 인력 등)을 고려하여 구조 설계가 되어야 합니다.

이를 달성하기 위해 서비스 시스템 구조, 정책, 작업 처리 규칙 등을 반영한 개발 기능과 프로세스 설계를 통해 구체화 됩니다.

구체적 구조화 방법에 대한 것과 예시는 이후 글에서 추가 정리됩니다.

2-1-2.개발사 관점 구조화 설계

많은 경우 계약 이후 분석/설계자가 투입된 이후 요구 사항 구체화 과정에서 개발 범위가 무작정 확정되는 경우가 있습니다. 이를 무작정 수용할 경우 고객사와 관계는 좋게 되겠지만, 개발사는 손실을 보게 됩니다.

이에 따라 계약 관점에서 수용할 부분과 추가 계약으로 넘길 부분으로 분리하여 시스템 설계, 기능 정의, 프로세스 설계를 진행해야 합니다.

2-2.구조화 설계가 부실한 외주 개발 프로젝트의 결말

이런 이유로 외주 개발 프로젝트의 구조화는 '갑'인 고객사 담당자와 일어날 수 있는 갈등 관리, 개발할 시스템의 설계 역량이라는 어려움이 있는 작업입니다.

그러나 제가 참여하여 작업한 많은 프로젝트가 고객사 갈등 관리 측면에 집중하는 반면 개발 시스템 설계 역량 부분은 부족한 경우가 많았습니다.

이 경우 외주 개발 프로젝트 초반 팀의 분위기는 좋습니다. 그러나 중반을 거쳐 후반으로 갈 수록 고객사의 요구와 실제 개발 된 시스템의 오차가 커지면서 업무 갈등으로 번지게 됩니다.

이러한 관계 갈등 완화에 집중하고 업무 갈등은 외면하는 것은 국내 조직 문화적 현상인 것 같습니다. 과거 외주 개발에서는 실력보다는 태도를 더 중요시 하는 문화도 있었습니다. 그래서 업무를 빠르고 정확하게 처리하는 것보다 일은 못해도 매일 야근하고 일찍 출근하는 개발자를 더 좋게 평가하고는 했습니다.

그렇다보니 외주 개발 시 문서로 제출되는 산출물은 깔끔한데 실제 유저가 이용하는 서비스 프로그램의 코드는 복잡한 경우가 많았습니다.

3.외주 개발 구조화 설계 시 주의점

서비스 기업이 아닌 계약에 의한 외부 기업 또는 개발자의 개발이라는 상황 때문에 형식적 기능과 화면 구현에 포커스 되는 경향이 있습니다.

이 때의 문제는 서비스 차별점 및 비즈니스 전략이 반영되지 않은 평균적인 앱과 웹이 개발된다는 점입니다.

이렇게 되는 이유는 구조화 설계가 고객사 비즈니스에서 진행되는 것이 아닌 확인 가능한 시장 대표 서비스 벤치마킹 또는 설계자의 과거 작업한 다른 기업의 프로젝트에 기반하여 설계되기 때문입니다.

매번 다른 고객사에 맞추어 개발하는 것보다 커머스나 은행 등 프로젝트가 많이 이루어지는 일반적인 개발 방식으로 구조화 하는 것이 편리하고 쉽습니다.

아무리 어려운 비즈니스 도메인 영역이라도 과거 개발 작업한 경험을 바탕으로 반복하는 것은 그리 어렵지 않습니다. 그리고 난해한 고객사의 비즈니스와 시스템을 이해할 필요가 없습니다.

이렇게 작업한 시스템 설계도, 기능 정의 및 프로세스 설계도의 모습은 그럴듯 해 보입니다. 그리고 단위 기능을 개발할 때도 문제가 없어 보입니다.

그렇지만 개발된 단위 기능들을 연결하고 고객사가 운영하고 있는 시스템과 연동하고 비즈니스에 적용하는 순간 '단위 기능 테스트' 단계에서 보이지 않았던 문제가 '시스템 통합 테스트' 단계에서 버그로 나타나기 시작합니다.

그러므로 경험에 기반한, 일반적 시스템에 기반한 피상적 구조화 설계는 하지 말아야 합니다. 초반이 어렵더라도 고객사 비즈니스와 정책, 연동이 필요한 기존 운영 시스템에 대한 이해를 바탕으로 구조화 설계를 진행해야 합니다.