요구사항 정의서, 어디까지 써야 할까 — 발주 전에 정리할 6가지

외주 개발을 준비하면서 가장 많이 받는 질문이 이것입니다. “요구사항 정의서를 어디까지 써야 하나요?” 화면 설계까지 그려야 하는지, 기능 목록만 있으면 되는지, 아니면 개발사가 알아서 정리해 주는지 판단이 서지 않는 상태에서 견적부터 받아 보는 경우가 많습니다.

디비컨설팅은 삼성물산 홈닉, GS건설 엘리시안 리조트, 직방 호갱노노, LS일렉트릭 테크스퀘어 등 100건이 넘는 프로젝트를 수행했습니다. 그 과정에서 확인한 것은 분명합니다. 프로젝트의 성패는 개발이 시작된 뒤가 아니라 요구사항 정의서가 어느 수준까지 정리됐는지에서 이미 상당 부분 결정됩니다. 이 글에서는 발주 전에 어디까지 써야 하는지, 그리고 쓰지 못했을 때 무엇이 어떻게 비용으로 돌아오는지를 정리했습니다.

요구사항 정의서가 없으면 견적 자체가 성립하지 않습니다

“회원가입 기능”이라는 한 줄을 세 개 개발사에 보내면 세 개의 다른 금액이 돌아옵니다. 부정직해서가 아니라, 각자 다른 것을 계산했기 때문입니다.

• A사는 이메일 가입만 계산했습니다
• B사는 소셜 로그인 4종과 본인인증을 포함했습니다
• C사는 여기에 휴면 계정 처리, 탈퇴 후 재가입 정책, 개인정보 동의 이력 보관까지 넣었습니다

세 견적을 나란히 놓고 “A사가 제일 싸다”고 판단하면, 빠진 항목은 개발 중반에 추가 계약으로 돌아옵니다. 견적을 비교하려면 비교 대상이 같아야 하고, 그 기준을 만드는 문서가 요구사항 정의서입니다. 이 구조는 모바일 앱 개발 견적이 회사마다 다른 이유에서도 같은 형태로 나타납니다.

발주 전에 반드시 정리해야 할 6가지

완성된 기획서가 필요한 것이 아닙니다. 아래 여섯 가지만 문서로 있으면 개략 견적과 일정 산출이 가능합니다.

1. 해결하려는 문제

기능이 아니라 문제부터 씁니다. “예약 시스템이 필요하다”가 아니라 “전화 예약을 직원 두 명이 하루 4시간씩 받고 있고 중복 예약이 주 3~4건 발생한다”가 요구사항입니다. 문제가 명확하면 개발사가 더 싼 해법을 제안할 수 있습니다.

2. 사용자 유형과 각자의 권한

일반 사용자, 관리자, 파트너사, 내부 운영자 중 누가 쓰는지 나눕니다. 사용자 유형이 하나 늘면 화면과 권한 로직이 함께 늘어나므로, 비용에 가장 직접적으로 반영되는 항목입니다.

3. 필수 기능과 나중 기능의 구분

모든 기능에 “필수”를 붙이면 우선순위가 없는 것과 같습니다. 1차 오픈에 반드시 있어야 하는 것 5개 이내, 그 외는 2차로 미룹니다. 이 구분이 없으면 예산이 초과됐을 때 무엇을 뺄지 협의할 근거가 없습니다.

4. 연동해야 할 외부 시스템

PG 결제, 본인인증, 지도, 사내 ERP, 그룹웨어 중 무엇과 붙어야 하는지 적습니다. 외부 연동은 심사와 계약에 각각 수 주가 걸리고, 우리 개발 속도로 단축되지 않습니다. 발주 시점에 알고 있어야 병렬로 착수할 수 있습니다.

5. 데이터 보관 및 보안 요건

개인정보를 다루는지, 망분리 환경인지, 데이터를 국내에 둬야 하는지를 미리 확정합니다. 이 조건은 나중에 붙이면 구조를 다시 짜야 하는 항목이라, 뒤늦게 발견될수록 비용이 급격히 올라갑니다.

6. 예산 범위와 희망 일정

예산을 밝히면 비싸게 부를까 걱정하는 경우가 많지만, 실제로는 반대입니다. 범위를 알려주면 그 안에 들어오도록 기능을 조정한 안을 받을 수 있습니다. 숨기면 예산의 두 배짜리 제안서를 받고 처음부터 다시 협의하게 됩니다.

여기까지는 개발사가 해야 하는 일입니다

반대로 발주사가 직접 쓸 필요가 없는 것도 분명히 있습니다. 이 구분을 모르면 필요 없는 작업에 몇 주를 씁니다.

• 화면 설계서(와이어프레임) — 기능이 정해지면 개발사가 그립니다
• DB 스키마와 API 명세 — 설계 산출물이지 요구사항이 아닙니다
• 기술 스택 선정 — 요건에 맞춰 개발사가 제안하는 영역입니다
• 공수 산정 — 발주사가 계산할 수 있는 항목이 아닙니다

그래서 요구사항 정의는 누가 맡아야 하는가

여기가 실제로 프로젝트 비용을 가르는 지점입니다. 선택지는 세 가지뿐입니다.

구분	국내 개발사	해외 직접 발주	한국인 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사가 직접	한국인 PM
정의서 작성 언어	한국어	영어	한국어
고객사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 저렴하지 않음	실질 절감

해외에 직접 발주하면 단가는 확실히 내려갑니다. 다만 요구사항 정의, 일정 관리, 품질 검수라는 세 가지가 그대로 고객사에게 넘어갑니다. 영어로 명세를 쓰고, 시차를 두고 확인하고, 산출물을 직접 검수할 내부 인력이 없다면 단가에서 아낀 금액은 재작업과 내부 인건비로 상쇄됩니다. 한국 기업이 해외 IT 외주에서 실패하는 5가지 패턴에서 다룬 구조가 대부분 여기서 시작됩니다.

디비컨설팅이 요구사항 정의를 다루는 방식

디비컨설팅의 IT 아웃소싱은 한국인 PM이 요구사항 정의부터 검수까지 책임지고, 실제 구현은 검증된 글로벌 개발팀이 수행하는 구조입니다. 국내 채용 대비 비용을 평균 40~60% 절감할 수 있으며, 프로젝트 요구사항에 따라 2~4주 내 전담팀을 구성합니다.

1. 상담 및 요구사항 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 앞의 6가지가 정리되지 않은 상태로 오셔도 이 단계에서 함께 정리합니다.
2. 개발팀 구성 — 확정된 요건에 맞는 전담팀을 2~4주 내에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행 상황을 투명하게 공유합니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 품질을 확인한 뒤 배포합니다.
5. 운영 및 유지보수 — 산출물을 문서와 함께 인계하고, 장기 운영을 지원합니다.

현재 50개 이상의 글로벌 파트너사와 협업하고 있으며, 고객 만족도는 98%입니다. 실제 수행 사례는 포트폴리오에서 확인하실 수 있습니다. 웹 개발 외주와 앱 개발 외주 모두 동일한 순서로 진행됩니다.

이런 기업에 적합합니다

• 아이디어와 예산은 있지만 요구사항을 문서로 정리할 내부 인력이 없는 기업
• 여러 개발사에서 받은 견적의 편차가 커서 판단이 어려운 기업
• 이전 외주에서 “말한 것과 다른 결과물”을 받아 본 경험이 있는 기업
• 해외 외주를 검토했지만 영어로 명세를 주고받을 자신이 없는 기업

다만, 이런 경우에는 저희가 맞지 않을 수 있습니다

• 망분리 등 물리적 보안 요건상 국내 상주 개발이 의무인 공공·금융 프로젝트
• 2주 안에 결과물이 필요한 초단기 건 — 전담팀 구성에만 2~4주가 필요합니다
• 요구사항을 정리하는 과정 자체를 건너뛰고 곧바로 착수만 원하시는 경우 — 기획서가 없는 것은 괜찮지만, 정리 과정을 생략하면 어떤 개발사와 진행하셔도 일정과 비용이 초과됩니다

자주 묻는 질문

요구사항 정의서는 몇 페이지 정도가 적당한가요?

분량은 기준이 아닙니다. 앞의 6가지가 담겨 있으면 5페이지로도 충분하고, 빠져 있으면 50페이지여도 견적을 낼 수 없습니다. 화면 설명을 길게 쓰는 것보다 사용자 유형과 우선순위를 명확히 하는 편이 훨씬 유용합니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 희망 일정과 예산 범위만 정리되어 있으면 가견적을 산출할 수 있습니다. 문서 형태가 아니라 대화로 정리해도 됩니다.

요구사항 정의만 따로 의뢰할 수 있나요?

가능합니다. 정의 단계만 진행한 뒤 그 산출물로 여러 개발사에서 견적을 비교하셔도 됩니다. 같은 기준으로 비교할 수 있게 되는 것만으로도 견적 편차가 크게 줄어듭니다.

개발 중에 요구사항이 바뀌면 어떻게 되나요?

바뀌는 것은 정상이며, 문제는 변경 자체가 아니라 변경을 기록하지 않는 것입니다. 무엇을 언제 왜 바꿨는지 남겨 두면 일정과 비용 조정을 근거를 두고 협의할 수 있습니다. 기록이 없으면 납품 시점에 서로 다른 기억으로 부딪칩니다.

산출물과 소스코드의 소유권은 누구에게 있나요?

고객사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서를 함께 인계하므로 이후 다른 팀이 이어받더라도 재분석 비용이 발생하지 않습니다.

정리

요구사항 정의서는 개발사에게 제출하는 서류가 아니라, 견적을 비교할 수 있게 만들고 재작업을 미리 없애는 도구입니다. 화면까지 그릴 필요는 없습니다. 문제, 사용자, 우선순위, 연동, 보안, 예산 — 이 여섯 가지만 정리되어 있으면 그 다음은 개발사의 몫입니다.