노노니 | 실전 서비스 기획자의 인사이트 블로그

외주 프로젝트에서 문서화는 선택이 아니라 필수입니다. 말로만 합의하고 넘어가면 나중에 "이렇게 하기로 했다", "아니다 저렇게 하기로 했다"는 분쟁이 발생합니다. 문서화는 실패 방지를 위한 시작입니다.

 

문서화하는 외주사가 실패하지 않는다

실패하지 않는 외주사는 절차를 지키고 최대한 문서화를 합니다.

절차와 문서화의 관계

체계적인 외주사는 정해진 절차에 따라 프로젝트를 진행하며, 각 단계마다 문서를 생성합니다. 기획 단계에서는 기획서를, 디자인 단계에서는 디자인 파일을, 개발 단계에서는 일정표와 테스트 결과를 만듭니다. 이런 문서는 단순히 형식을 갖추기 위한 것이 아니라, 발주사와 외주사가 같은 내용을 이해하고 있는지 확인하는 도구입니다. 문서가 없으면 오해가 생기고, 오해는 실패로 이어집니다.

책임의 명확화

문서화는 책임을 명확하게 만듭니다. "이 기능은 이렇게 구현하기로 합의했다"는 기록이 있으면, 나중에 결과물이 다르게 나왔을 때 누구의 책임인지 분명해집니다. 외주사가 합의와 다르게 작업했다면 외주사의 책임이고, 발주사가 중간에 요구사항을 바꿨다면 발주사가 추가 비용을 부담해야 합니다. 문서가 없으면 이런 판단이 불가능하고 감정 싸움만 남습니다.

 

말로 좋은 게 좋다고 넘어가지 않는다

문서화를 제대로 하는 외주사는 말로써 좋은 게 좋다고 얼렁뚱땅 넘어가지 않습니다.

구두 합의의 위험

"대충 이해했으니까 진행하겠습니다", "그 정도는 당연히 포함된 거 아닌가요?"같은 애매한 대화로 넘어가면 반드시 문제가 생깁니다. 발주사는 A를 생각하고 외주사는 B를 생각하는데, 서로 같은 것을 이야기한다고 착각합니다. 몇 주 후 결과물을 보고 나서야 서로 다른 것을 이해하고 있었다는 사실을 알게 되고, 그때는 이미 많은 시간과 비용이 낭비된 후입니다.

문서로 확인하는 습관

좋은 외주사는 회의가 끝나면 반드시 회의 내용을 문서로 정리해서 공유합니다. "오늘 회의에서 논의된 내용입니다. 이렇게 이해한 것이 맞나요?"라고 확인합니다. 발주사도 문서를 받으면 꼼꼼히 읽고 잘못 이해된 부분이 있으면 즉시 수정을 요청해야 합니다. 이런 과정이 번거롭게 느껴질 수 있지만, 나중에 발생할 큰 분쟁을 예방하는 가장 확실한 방법입니다.

 

서비스 기획 단계의 문서화

서비스 기획은 기획 기간 내내 매주마다 결과물의 리뷰가 이루어집니다. 서비스 기획이 8주 진행되었다면 8번의 진행 중 결과물과 매주 회의록, 최종 스토리보드가 작성됩니다.

주간 결과물

서비스 기획은 한 번에 완성되는 것이 아니라 점진적으로 구체화됩니다. 1주차에는 주요 기능 목록, 2주차에는 사용자 흐름도, 3주차에는 화면 구성안처럼 단계적으로 결과물이 나옵니다. 매주 결과물을 받아 리뷰하고 피드백을 주면서 기획이 점점 정교해집니다. 8주 동안 8번의 결과물이 쌓이면 최종 기획서는 자연스럽게 완성됩니다.

매주 회의록

주간 미팅마다 회의록을 작성해야 합니다. 회의록에는 논의된 내용, 결정된 사항, 다음 주까지 해야 할 작업, 보류된 이슈가 포함됩니다. 회의록은 외주사가 작성해서 발주사에게 공유하고, 발주사는 24시간 내에 검토해서 수정 사항이 있으면 알려줍니다. 이렇게 쌓인 회의록은 프로젝트 진행 과정의 기록이 되고, 나중에 분쟁이 생기면 증거 자료가 됩니다.

최종 스토리보드

기획 단계가 끝나면 최종 스토리보드가 완성됩니다. 스토리보드는 모든 화면의 구성과 기능을 문서로 정리한 것입니다. 각 화면에 어떤 요소가 있고, 버튼을 누르면 어떤 일이 일어나며, 어떤 데이터가 표시되는지 상세히 기술됩니다. 스토리보드는 디자인과 개발의 기준이 되므로, 발주사가 승인하기 전에 모든 내용을 꼼꼼히 확인해야 합니다. 스토리보드에 없는 기능은 디자인이나 개발 단계에서 추가 비용이 발생합니다.

 

디자인 단계의 문서화

디자인은 시안, 디자인 스타일 가이드, 페이지 디자인이 피그마로 작성됩니다.

디자인 시안

본격적인 디자인 작업 전에 2개의 시안을 만들어 방향을 정합니다. 발주사는 시안을 보고 설명을 들으며 색상, 레이아웃, 분위기 중 어떤 방향으로 갈지 선택합니다. 시안 단계에서 방향을 명확히 정해야 나중에 "생각했던 것과 다르다"는 문제를 예방할 수 있습니다.

디자인 스타일 가이드

디자인 방향이 정해지면 스타일 가이드를 만듭니다. 스타일 가이드에는 사용할 색상, 폰트, 버튼 스타일, 아이콘 스타일 같은 기본 규칙이 정리됩니다. 이 가이드를 기준으로 모든 페이지를 디자인하므로, 일관된 느낌의 서비스가 완성됩니다. 스타일 가이드는 나중에 새로운 페이지를 추가하거나 디자인을 수정할 때도 기준이 됩니다.

피그마 페이지 디자인

모든 페이지의 디자인은 피그마로 작성되어야 합니다. 피그마는 웹 기반 디자인 도구로, 발주사가 언제든 접속해서 디자인을 확인하고 댓글로 피드백을 줄 수 있습니다. 각 페이지마다 화면 상태별로 디자인이 있어야 합니다. 예를 들어 로그인 화면이라면 일반 상태, 입력 중 상태, 오류 발생 상태의 디자인이 모두 있어야 개발자가 정확히 구현할 수 있습니다. 피그마 파일은 최종적으로 발주사에게 전달되어 향후 수정이나 추가 작업 시 활용됩니다.

 

개발 단계의 문서화

개발 작업에는 일정표와 진행 상황 문서화가 필요합니다.

개발 일정표

개발이 시작되기 전에 상세한 일정표를 받아야 합니다. 전체 개발 기간을 주 단위로 나누고, 각 주에 어떤 기능을 개발할 것인지 명시합니다. 예를 들어 "1주차: 로그인/회원가입 기능, 2주차: 게시판 목록 및 상세 화면, 3주차: 게시글 작성 및 수정 기능"처럼 구체적이어야 합니다. 일정표가 있어야 매주 계획 대비 실제 진행 상황을 비교하고 지연을 조기에 발견할 수 있습니다.

스토리보드가 있다면 스토리보드의 화면 단위로 일정표를 작성할 수 있습니다.

테스트 결과 문서

개발 중에 테스트를 할 때마다 결과를 문서로 남겨야 합니다. 어떤 기능을 테스트했고, 어떤 문제를 발견했으며, 외주사가 어떻게 수정했는지 기록합니다. 스크린샷과 함께 "로그인 화면에서 비밀번호 8자 미만 입력 시 오류 메시지가 표시되지 않음 → 수정 완료 (2024.11.15)"처럼 정리하면, 같은 문제가 재발하는지 확인하고 최종 검수 시에도 활용할 수 있습니다.

 

계약서와 변경 관리 문서

프로젝트 진행 중 변경 사항은 반드시 문서화해야 합니다.

요구사항 변경 기록

프로젝트를 진행하다 보면 기능을 추가하거나 수정하는 경우가 생깁니다. 이런 변경은 구두로 합의하지 말고 문서로 기록해야 합니다. "11월 10일 회의에서 결제 기능에 카드 결제 외에 계좌이체 추가 요청 → 추가 비용 100만원, 일정 1주 연장"처럼 변경 내용과 그에 따른 비용, 일정 변동을 명확히 기록합니다. 이 문서는 계약서의 부록이 되어 최종 정산 시 기준이 됩니다.

 

문서화의 실전 팁

효과적인 문서화를 위한 구체적인 방법입니다.

도구 활용

문서는 이메일이나 메신저에 흩어지지 않도록 한곳에 모아야 합니다. 구글 드라이브, 노션, 컨플루언스 같은 협업 도구를 사용하면 모든 문서를 체계적으로 관리하고 필요할 때 빠르게 찾을 수 있습니다. 외주사와 같은 도구를 사용하면 실시간으로 문서를 공유하고 댓글로 피드백을 주고받을 수 있어 효율적입니다.

승인 절차

중요한 문서는 발주사의 명시적 승인을 받아야 합니다. 단순히 "확인했습니다"가 아니라 "기획서 v3.0을 검토했으며 내용에 동의합니다. 이 버전으로 디자인을 진행해주세요"처럼 명확한 승인 의사를 문서로 남겨야 합니다. 이메일이나 문서에 서명 기능을 활용하면 법적 효력도 높아집니다.

외주 실패를 방지하는 가장 확실한 방법은 철저한 문서화입니다. 기획 단계의 주간 결과물과 회의록, 최종 스토리보드, 디자인 시안과 스타일 가이드와 피그마 파일, 개발 일정표와 진행 보고서를 체계적으로 관리하면 오해를 줄이고 책임을 명확히 하며 품질을 확보할 수 있습니다.