서핑베어
홈 › 블로그 › 요구사항 정의서 작성
요구사항 정의서, 개발사가 견적을 낼 수 있게 쓰는 방법
견적이 회사마다 크게 다를 때, 원인은 대개 개발사가 아니라 요구사항 문서입니다. 같은 문서를 읽고 서로 다른 범위를 상상하면 견적도 다르게 나옵니다.
6개 필수 항목 흔한 누락 견적 편차 줄이기
결론부터
요구사항 정의서의 목적은 "우리가 원하는 것을 설명하는 것"이 아니라 "읽는 사람이 같은 범위를 떠올리게 하는 것"입니다. 이 차이가 견적 편차의 대부분을 만듭니다.
그래서 잘 쓴 문서의 특징은 화려한 설명이 아니라 경계가 분명한 것입니다 — 무엇을 포함하고 무엇을 포함하지 않는지, 데이터가 어디서 오는지, 무엇을 성공으로 볼지.
6개 필수 항목
가장 흔한 누락 — 견적을 흔드는 다섯 가지
| 누락 항목 | 견적에 생기는 일 |
|---|---|
| 비기능 요건 (동시 사용자, 응답 시간) | 개발사가 임의로 가정하고, 나중에 성능 문제로 재작업 |
| 데이터 이전 범위 | 기존 데이터 이전이 별도 견적으로 추가됨 |
| 운영·유지보수 기간 | 납품 후 대응이 계약에 없어 매번 추가 비용 |
| 검수 절차와 기간 | 검수가 길어져 잔금 지급 시점이 불명확해짐 |
| 제외 범위 | 기대했던 기능이 "범위 밖"으로 처리됨 |
제외 범위를 적는 것이 포함 범위보다 중요하다
문서에 "이번 범위에 포함하지 않는 것" 절을 따로 두세요. 디자인 신규 제작, 기존 데이터 정리, 모바일 앱, 다국어, 외부 시스템 신규 개발 같은 항목이 흔한 후보입니다.
이 절이 있으면 두 가지가 좋아집니다. 견적 편차가 줄고, 프로젝트 중간에 "이건 당연히 포함이라고 생각했다"는 분쟁이 줄어듭니다. 분쟁은 대개 악의가 아니라 서로 다른 기본 가정에서 생깁니다.
그리고 제외한 항목에는 "이번에는 제외, 2차에서 검토"처럼 시점을 붙이세요. 영구 제외와 후속 검토는 개발사의 설계 판단을 바꿉니다.
AI를 어디에 쓰면 좋은가
초안 구조를 잡는 데는 적합합니다. 위 6개 항목을 채울 질문 목록을 만들게 하고, 답을 정리하는 방식이 빠릅니다.
반대로 기능 목록을 AI가 상상해서 채우게 하면 위험합니다. 실제로 필요하지 않은 기능이 목록에 들어가고, 그 기능이 견적에 포함되어 비용이 늘어납니다. 기능은 업무를 아는 사람이 정합니다.
완료 기준도 사람이 정해야 합니다. 확인 가능한 숫자는 현재 업무량에서 나오고, 그 숫자는 문서 밖에 있습니다.
자주 묻는 질문
요구사항을 다 정하고 시작해야 합니까?
전부 확정할 필요는 없습니다. 다만 필수 기능과 제외 범위, 완료 기준은 확정하는 편이 좋습니다. 이 셋이 흔들리면 일정과 비용이 계속 움직입니다.
문서가 길수록 좋습니까?
아닙니다. 읽는 사람이 같은 범위를 떠올리는 것이 목적이므로, 경계가 분명한 짧은 문서가 장황한 문서보다 낫습니다. 화면 설명이 많은 문서보다 데이터·연동·완료 기준이 분명한 문서가 견적을 정확하게 만듭니다.
견적이 회사마다 3배씩 다릅니다.
대개 문서에서 범위가 열려 있다는 신호입니다. 우선순위, 제외 범위, 연동 대상 API 유무를 추가하고 다시 받아보면 편차가 크게 줄어듭니다.
RFP와 요구사항 정의서는 다릅니까?
RFP는 제안을 요청하는 문서로 회사 소개, 일정, 평가 기준, 계약 조건이 함께 들어갑니다. 요구사항 정의서는 그 안에서 "무엇을 만드는가"를 담는 부분입니다.
RFP 초안
요구사항을 문서 형태로 뽑으세요
RFP 생성기로 배경·기능·데이터·완료 기준이 들어간 요청 문서 초안을 만들 수 있습니다. 무료이고 회원가입이 필요하지 않습니다.