요구사항 정의서 어디까지 써야 하나요 | 견적 오차를 줄이는 11개 항목
요구사항정의서가 부실하면 개발 견적서도 업체마다 달라지고, 나중에 분쟁이 생겨도 기준을 가리기 어려워져요. 프로젝트 개요부터 성능·보안 조건까지 필수 항목 6가지와 RFP·MVP까지 헷갈리는 개념을 운영해본 개발사 기준으로 정리했어요.
요구사항 정의서는 견적의 근거이자, 나중에 분쟁이 생겼을 때 옳고 그름을 가리는 기준이 돼요. 화면 단위 기능, 데이터 항목, 외부 연동, 성능·보안 조건까지 구체적으로 적을수록 업체마다 이해하는 범위가 같아져요. RFP(제안요청서)와는 목적이 다르고, MVP(최소기능제품) 단계에서도 최소한의 정의서는 필요해요. 직접 만들고 운영해본 개발사 기준으로 어디까지 써야 하는지 정리했어요.
“분명 같은 프로젝트를 설명했는데 업체마다 견적이 왜 이렇게 다르죠?” 개발 외주를 알아보면서 여러 개발외주업체에서 개발 견적서를 받아본 분들이라면 한 번쯤 해봤을 질문이에요. 이유는 대부분 요구사항 정의서에 있어요. 화면 하나 기능 하나를 얼마나 구체적으로 적었는지에 따라 개발사가 상상하는 작업 범위 자체가 달라지거든요.
1. 요구사항 정의서가 없으면 견적은 왜 흔들릴까요
요구사항이 모호하면 개발사는 리스크를 감안해 견적에 여유분을 넣거나 반대로 낮게 잡아둔 뒤 진행 중에 추가 비용을 요청하는 쪽으로 움직여요. 같은 프로젝트라도 정의서 수준에 따라 견적 편차가 커지는 이유예요. 화면 목록, 데이터 항목, 외부 연동까지 미리 정리해두면 외주개발 프로젝트에서 이런 편차부터 줄어들어요.
2. 요구사항 정의서에는 어떤 항목이 들어가야 할까요
최소한 아래 항목은 문서 하나에 담겨 있어야 해요.
- 프로젝트 개요·목적: 왜 이 시스템이 필요한지
- 화면·기능 목록: 어떤 화면에서 무엇을 할 수 있어야 하는지
- 데이터 항목: 어떤 정보를 저장·조회·수정하는지
- 외부 연동 대상: 결제·지도·ERP 등 붙여야 할 외부 서비스
- 성능·보안 조건: 동시 접속자 수, 응답 속도, 개인정보 처리 기준
- 우선순위: 꼭 필요한 기능과 있으면 좋은 기능 구분
3. 기능 요구사항과 비기능 요구사항은 어떻게 다를까요
기능 요구사항은 시스템이 “무엇을 해야 하는지”예요. 로그인, 주문 처리, 게시글 작성 같은 동작이 여기 들어가요. 비기능 요구사항은 “어떻게 동작해야 하는지”를 정해요. 응답 속도 1초 이내, 동시 접속 500명 처리, 데이터 암호화 같은 조건이에요. 발주자는 보통 기능 요구사항만 신경 쓰는데, 견적과 일정을 실제로 움직이는 건 비기능 요구사항인 경우가 많아요.
4. RFP와 요구사항 정의서, 무엇이 다른가요
RFP(제안요청서)는 여러 업체에 제안을 요청할 때 목적·예산·일정·평가 기준을 담아 배포하는 문서예요. 반면 요구사항 정의서는 “무엇을 만들 것인가”를 더 구체적으로 풀어낸 실무 문서예요. 공공·중견 SI개발에서는 RFP 안에 요구사항 정의서 수준의 별첨이 들어가는 경우가 흔하고 민간 소규모 프로젝트는 요구사항 정의서 하나로 견적을 받는 경우가 많아요.
5. 요구사항 정의서, 어디까지 구체적으로 써야 견적이 맞을까요
화면 이름만 나열하는 수준으로는 부족해요. “회원가입 화면”이 아니라 “이메일·전화번호 인증, 소셜 로그인 2종, 약관 동의 항목 3개”처럼 항목 단위까지 적어야 개발사마다 같은 그림을 그릴 수 있어요.
공식 기준 — 요구사항 유형 구분(소프트웨어공학 표준)
| 유형 | 정의 | 예시 |
|---|---|---|
| 기능 요구사항 | 시스템이 수행해야 할 동작 | 로그인, 주문 처리, 검색 |
| 비기능 요구사항 | 성능·보안 등 품질 조건 | 응답 속도, 동시 접속, 암호화 |
자사 실무 기준 — 견적 요청 전 확인하는 항목
| 항목 | 왜 확인하나요 |
|---|---|
| 화면 단위 기능 목록 | 화면별로 빠진 기능이 없는지 |
| 데이터 항목 정의 | 저장·조회 범위가 견적에 반영됐는지 |
| 외부 연동 대상 | 결제·지도 등 연동이 견적에 포함됐는지 |
| 우선순위 표기 | 1차 출시 범위와 이후 범위가 구분됐는지 |
6. 자주 헷갈리는 용어부터 정리해볼까요
RFP(제안요청서)는 업체 선정을 위해 프로젝트 개요·예산·일정·평가 기준을 담아 배포하는 문서예요. MVP(최소기능제품)는 핵심 기능만 먼저 만들어 시장 반응을 검증하는 초기 버전이고요. 실무에선 “RFP로 업체를 고르고, 요구사항 정의서로 계약 범위를 확정한 뒤, MVP개발 단계는 기능을 최소화한 버전으로 정의서를 따로 작성한다”는 흐름이 흔해요.
7. 운영까지 보면 요구사항 정의서에 무엇을 더 넣어야 할까요
운영사 Tip — 저희는 요구사항 정의서를 받을 때 화면·기능만큼 “출시 이후 무엇을 바꿀 가능성이 큰지”도 함께 물어봐요. 회원 등급이 늘어날 예정인지, 결제 수단이 추가될 예정인지처럼요. 초기 설계 단계에서 이런 변화 가능성을 알고 있으면, 나중에 구조를 갈아엎지 않고도 확장할 수 있거든요. 자체 SaaS 4종을 직접 운영하며 반복해서 확인한 지점이에요.
8. 요구사항 정의서를 쓸 때 흔히 놓치는 것들
- 예외 상황 누락: “정상 흐름”만 적고 오류·실패 상황을 안 적으면, 개발 중 범위 다툼이 생겨요.
- 관리자 화면 생략: 사용자 화면만 정의하고 운영자가 쓸 관리자 기능을 빼먹는 경우가 많아요.
- 기존 시스템 연동 조건 미기재: 레거시 시스템이나 API 연동이 있다면 별도로 명시해야 견적에 반영돼요.
납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 요구사항 정의서도 마찬가지고요. 화면 개수보다, 출시 이후 무엇이 바뀔지를 함께 적어둔 문서가 실제 비용을 더 정확하게 예측하게 해줘요.
9. 자주 묻는 질문
요구사항 정의서는 누가 작성해야 하나요?
발주자가 초안을 작성하고 개발사와 함께 다듬는 방식이 가장 흔해요. 개발사에 기획부터 맡기는 경우도 있지만, 그럼 별도 기획 비용이 붙는 경우가 많아요.
요구사항이 프로젝트 도중 바뀌면 어떻게 하나요?
바뀔 수 있다는 전제로 우선순위와 변경 절차를 정의서에 미리 적어두면 좋아요. 변경 시 재견적 기준을 계약서에 함께 명시하는 게 안전해요.
MVP개발 단계에서도 정의서가 꼭 필요한가요?
네, 범위가 작을수록 오히려 더 필요해요. MVP는 “무엇을 뺄 것인가”를 정하는 작업이라, 뺀 범위까지 문서로 남겨야 나중에 오해가 없어요.
10. 정리하며
저희는 같은 기능 수보다, 출시 후 얼마나 자주 수정될지부터 봐요. 요구사항 정의서를 볼 때도 마찬가지예요. 화면과 기능 목록이 촘촘한지보다, 운영 이후의 변화까지 담겼는지를 먼저 확인해요. 자체 SaaS 4종을 11년 넘게 직접 운영하며 이런 문서를 수없이 검토해왔어요.
관련해서 함께 보면 좋은 글이에요.