"요구사항 정리 좀 도와주세요"는 제가 의뢰 초기에 가장 많이 주고받는 문장입니다. 외주 개발에서 품질·일정·비용이 엇나가는 가장 흔한 원인은 기술력이 아니라 요구사항이 애매한 상태에서 착수되기 때문입니다. 반대로 말하면 이 단계만 잘 넘기면 이후는 거의 문제가 생기지 않습니다.
왜 요구사항 정리가 어려운가
의뢰자는 "우리 비즈니스의 언어"로 말하고, 개발자는 "시스템의 언어"로 듣습니다. 둘 사이를 번역 없이 밀어붙이면 양쪽 다 "했는데 왜 이게 아니냐"가 됩니다. 요구사항 문서는 그 번역의 합의문입니다. 합의문이 명확할수록 재작업이 줄고, 재작업이 줄수록 비용이 낮아집니다.
1단 — 목적 한 문장
"어떤 사람이 어떤 상황에서 어떤 결과를 얻는 제품"을 한 문장으로 적습니다. 제 경험상 이 문장을 못 쓰면 아직 개발 착수가 아니라 기획 단계입니다. 예: "소규모 학원 원장이 수강료 미납 학생을 한 화면에서 확인하고 알림을 보낼 수 있는 웹 앱". 이 한 문장이 나머지 문서의 나침반이 됩니다.
2단 — 사용자 시나리오 (3~5개)
문서·스펙이 아니라 사용자가 어떤 순서로 어떤 화면에서 무엇을 하는가를 이야기로 적습니다. 예: "(1) 원장이 로그인 → (2) 대시보드에서 '미납 3개월 이상' 필터 클릭 → (3) 학생 목록에서 알림 버튼 클릭 → (4) 문자 발송 확인". 시나리오 5개 정도면 제품의 90%가 설명됩니다. 나머지 10%는 진행하며 자연스럽게 드러납니다.
3단 — 화면 스케치·레퍼런스
그림 실력 필요 없습니다. 손으로 박스 그려서 찍어도 되고, Figma의 빈 프레임에 네모 넣어도 됩니다. 중요한 건 "이 화면에 어떤 정보가 있고 어떤 액션이 있는가"를 명시하는 것. 거기에 "이 서비스의 이 화면이랑 비슷한 느낌" 레퍼런스 1~2개를 덧붙이면 디자인 협의가 크게 단축됩니다.
4단 — 비기능 요건·제약
- 예상 사용자 규모: 100명/월인지 10,000명/월인지. 인프라 설계를 가릅니다.
- 대상 환경: 모바일 우선인지, PC 업무용인지. UI와 성능 목표가 달라집니다.
- 연동 시스템: 결제(PG), 카카오톡·문자, ERP 등 연동 필요 여부.
- 보안·규정: 개인정보, 의료정보, 금융정보 등 민감 데이터 유무.
- 론칭 시점의 의미: 단순 오픈인지, IR·전시회·계약 연결된 일정인지.
해도 되고 안 해도 되는 것들
완벽하게 정리하려다 영원히 착수 못 하는 의뢰도 자주 봅니다. 저는 의뢰자에게 "문서 70%면 충분합니다. 나머지 30%는 같이 만들죠"라고 설명드립니다. 무리하게 100%를 만들면 문서가 현실과 어긋나기 시작합니다.
반대로, 버튼 문구·폰트 컬러 같은 세부는 이 단계에선 건드리지 마세요. 나중에 프로토타입을 보며 맞추는 게 훨씬 빠릅니다.
합의의 결정적 한 문장
문서 맨 앞에 "이 프로젝트가 성공했다고 말할 수 있는 기준 한 줄"을 적어두세요. 예: "오픈 2개월 내 미납 알림 기능으로 수금률이 유의미하게 개선되는 것". 이 한 줄이 나중에 "이 기능 꼭 들어가야 하냐 말아야 하냐" 논쟁에서 매번 기준이 돼 줍니다.
바로 쓸 수 있는 템플릿 구조
- 한 줄 제품 정의
- 성공 기준 한 줄
- 사용자 시나리오 5개
- 화면 스케치 + 레퍼런스 링크
- 비기능 요건 체크리스트
- 연동·데이터 목록
- 해도 되고 안 해도 되는 것(Out of scope)
이 7개를 A4 2~3장에 담으면 충분한 요구사항 문서입니다. 여기까지 정리된 상태로 외주 업체에 보내면 견적·일정 편차가 눈에 띄게 줄어듭니다. 제 경험상 이 한 단계로 외주 실패의 절반이 사라집니다.