자체 온라인 서비스를 개발하면서 직접 개발자와 함께 개발도 해 보고 외주 개발도 진행해 보았습니다. 또 SI나 웹에이전시 프리랜서 기획자로 작업도 하였습니다. 그러면서 이래서 외주로 좋은 온라인 서비스가 개발될 수 없다는 것을 절실히 느꼈습니다.
외주 개발의 역설
외주 개발은 내부에 개발 역량이 부족할 때 주로 이루어집니다. 이 말인즉 온라인 서비스에 대해 잘 모르고 있다는 것을 의미합니다. 개발 의뢰를 하는 클라이언트는 SI나 웹에이전시가 온라인 서비스 전문가라고 생각하고 의뢰를 하게 됩니다. 그래서 많은 경우 클라이언트의 요구 사항은 포괄적이고 구체적이지 못한 경우가 많습니다.
외주 개발을 담당하는 SI나 웹에이전시는 의뢰를 하는 클라이언트의 요구사항에 맞추어 온라인 서비스를 개발해 줍니다. 스스로 생각한 서비스를 개발하지는 않습니다. 불필요하게 개발 제작물에 대한 책임을 질 필요가 없고 개발 의뢰에 맞는 개발 결과를 전달하면 되기 때문입니다. 이 기준이 바로 요구사항인 것입니다. 결국 SI나 웹에이전시는 서비스를 떠나 의뢰 클라이언트의 요구사항에 맞는 개발을 해 주면 되는 것입니다. 좁게 보면 SI나 웹에이전시는 온라인 서비스가 아닌 온라인에서 사용 가능한 제품을 만들어 납품하는 것입니다.
SI나 웹에이전시는 서비스 개발사가 아닌 온라인 제품 개발사라는 것이 되므로 당연히 온라인 서비스에 대한 내용은 알 필요도 없고 알지도 못합니다. 온라인 서비스와 관련된 것은 개발 의뢰 클라이언트가 기획하여 개발이 필요한 요구사항에 포함시켜 제시하면 SI나 웹에이전시는 요구 사항과 개발 금액, 기간을 보고 보고 참여할지 안 할지를 결정하여 클라이언트에 회신합니다. 클라이언트는 참여할 개발사 중에 선정하여 외주 개발을 진행하면 됩니다.
이러다 보니 종종 온라인 서비스를 개발하는 데 온라인 서비스 기획이 없는 경우가 발생합니다. 개발 의뢰 클라이언트는 SI나 웹에이전시가 전문가이고 수많은 개발 프로젝트를 했으므로 알아서 서비스를 기획/개발해줄 것으로 생각하고, SI나 웹에이전시 기업은 클라이언트 요구사항에 맞추어 개발해준다 생각하기 때문에 서비스 기획 내용은 없게 되는 온라인 서비스 외주 개발의 역설이 발생하게 됩니다.
외주 개발 기획 프로세스
외주 의뢰 클라이언트 RFP를 기반으로 제안서를 넣어 선정되면 SI나 웹에이전시 같은 외주 개발사의 업무가 시작됩니다. 프로젝트마다 작성 및 제출해야 하는 기간별 산출물이 있어 개발 스케줄에 따라 지정 산출물을 제출합니다. 외주 개발 기획 부분에 있어 최종 산물물은 스토리보드가 되기는 하지만 이외에도 개발이 진행 진행되기 위한 단계에 따라 완료해야 하는 기본 산출물이 필요합니다.
먼저 개발이 진행되면 클라이언트의 요구사항을 상세화하는 작업이 필요합니다. 많은 경우 클라이언트의 요구사항이 포괄적이고 불분명한 경우가 많습니다. 이렇게 불 불명한 요구사항의 의미를 클라이언트 미팅을 통해 정확한 의미와 요구사항의 내용을 정리해야 합니다. 이 작업이 없는 대부분의 개발은 종료 시점 분쟁이 발생할 가능성이 매우 큽니다. 이때 클라이언트 온라인 서비스의 정책과 기능에 대한 부분도 파악하여 문서화합니다.
정리하면 외주 개발이 시작되면 요구사항을 상세화한 요구사항 정의서, 온라인 서비스 정책서, 주요 기능 정의서를 작성합니다. 이를 기반으로 주요 기능의 유저 프로세스를 작성합니다. 이런 내용은 보통 기획 PL과 같은 리더급에서 작성합니다. 이렇게 작성된 요구사항 정의서, 서비스 정책서, 주요 기능 정의서, 주요 기능 유저 프로세스 문서를 기반으로 해서 와이어프레임 작업을 합니다. 프로세스 문서가 잘되어 있는 경우 와이어프레임까지 필요 없을 수 있습니다. 그러나 규모가 큰 서비스인 경우 와이어프레임으로 통해 구조와 흐름을 정리해 두면 여러 기획자의 스토리보드 작업 시 통일성을 유지할 수 있습니다.
와이어프레임 작업까지 한 작업 문서들을 바탕으로 일반 PA 기획자들이 스토리보드를 작성하게 됩니다. 요구사항 정의서, 서비스 정책서, 주요 기능 정의서, 프로세스 문서 또는 와이어프레임이 없을 시 스토리보드 작업이 어렵습니다. 스토리보드 작업의 기준이 없기 때문입니다.
종종 기획 경험이 없는 PL과 PM 사전 문서 없이 스토리보드를 요구하는 경우가 있습니다. 대부분 이전 작업했던 유사 업무를 바탕으로 스토리보드 작업을 요구하기도 합니다. 예를 들면 쇼핑몰 개발 프로젝트의 경우 이전 쇼핑몰 경험 기획자를 뽑아 과거 작업한 것을 바탕으로 스토리보드를 만들라 요구하는 것 같은 경우입니다.
외주 개발사의 목적과 수익성
SI, 웹에이전시 같은 외주 개발사는 클라이언트가 요구하는 것을 약정한 기간 내에 버그 없는 상태로 전달하는 것으로 개발 금액을 전달받습니다. 보통 선금, 잔금 또는 선금, 중도금, 잔금 형태로 개발 비용을 받기 때문에 최소 30% ~ 50% 정도의 금액은 개발이 완료되어 전달된 후 검수 후 문제가 없다는 클라이언트의 확인 후 금액을 받게 됩니다. 여기서 개발이 다 되었다 안되었다는 요구사항을 기준으로 하며 완료된 내요을 QA/QC, 테스트를 통해 개발 품질을 확인합니다.
만약 외주 개발사가 약속한 개발 기간을 못 맞춘다거나, 요구사항 내용이 빠져 있다거나, 개발 완료 품질에 문제가 있다면 개발 잔금을 못 받기도 하고 때로는 오히려 보상금을 내어 주어야 하는 경우도 생깁니다. 개발사는 클라이언트가 지불하는 개발 금액보다 적은 비용을 들여 약속된 기간에 버그 없이 요구사항 내용을 개발해 전달하면 되는 것이지 다른 문제를 만들 이유가 없습니다. 아무리 더 좋은 서비스 내용이라도 요구사항에 포함되지 않은 것을 이야기할 필요는 없고 정확한 요구사항을 파악하기만 하면 됩니다. 개발도 검증된 방식으로 진행하여 버그 가능성을 낮추는 것이 중요하지 더 효율적인 새로운 방식의 적용은 중요하지 않습니다.
외주 개발사 입장에서 자신이 서비스하지도 않을 온라인 서비스에 대한 대한 고민보다 개발에 더 신경 쓰게 되는 것입니다. 그리고 외주 진행 이전에 클라이언트도 PI 또는 BPR을 통해 온라인 서비스 관련한 컨설팅을 진행하기도 하기에 SI나 웹에이전시와 같은 외주 개발 기획과 서비스 기획이 같다고 보기도 어렵습니다. 또 SI와 웹에이전시는 진행 작업의 성격이 달라 SI 프로젝트의 기획자와 웹에이전시 프로젝트의 기획자는 완전히 다릅니다. 과거 SI와 웹에이전시 모두에서 기획자로 작업한 경험으로 웹에이전시 기획자가 진행한 프로젝트의 문제를 해결하러 투입된 적이 있었습니다. 경험한 두 분야 기획자의 차이 이야기는 다음 글에서 정리해 보도록 하겠습니다.
댓글