요구사항 정의서 작성법, 비개발자용 7항목 템플릿

요구사항 정의서 작성법의 핵심은 개발 지식이 아니라 정리 순서다. 만들고 싶은 것을 화면·기능·데이터·예외 네 갈래로 나눠 적으면, 비개발자도 업체가 바로 견적을 낼 수 있는 문서를 만든다. 이 글은 발주자용 7항목 템플릿과 함께, 항목마다 어디까지 구체적으로 써야 견적 오차가 줄어드는지를 예시 문장으로 보여준다.

핵심 요약

• 요구사항 정의서는 만들 것을 항목별로 적은 문서로, 견적·일정·검수 세 가지의 기준이 된다.
• 비개발자는 개요·사용자·화면·기능·데이터·예외·제약 7항목 순서로 채우면 충분하다.
• "빠르게" 같은 모호한 표현 대신 "2초 이내"처럼 확인 가능한 문장으로 적는다.
• 문서가 없으면 업체마다 다른 범위를 상상하고 견적을 내기 때문에 금액 비교 자체가 어려워진다.
• 형식보다 빠짐없음이 중요하다. 항목이 차 있으면 메모 수준이어도 업체가 정식 문서로 다듬어 준다.

요구사항 정의서가 견적 오차를 줄이는 이유

견적은 결국 작업량 추정이다. 무엇을 만드는지 적힌 문서가 없으면 업체는 상담 몇 마디로 범위를 상상해야 하고 상상의 폭만큼 금액이 벌어진다. 같은 요청인데 견적이 두세 배 차이 나는 상황의 상당수는 업체의 폭리가 아니라 서로 다른 범위를 계산한 결과다. 견적서를 같은 기준으로 줄 세우는 방법은 견적 비교 글에서 다뤘다. 이 글은 그 전 단계인 "같은 기준을 만드는 문서"를 다룬다.

외주 상담을 하다 보면 요구사항 문서 없이 참고 사이트 하나로 시작하는 발주가 많다. 그렇게 받은 견적은 업체마다 포함 범위가 달라 비교가 안 된다. 개발 중반에 "그건 견적에 없던 작업"이라는 말이 나오면 추가 비용과 일정 지연으로 이어지곤 한다. 이랜서 블로그도 요구사항 정의서를 작성하지 않으면 프로젝트 기간이 지연되고 비용이 초과될 수 있다고 짚는다.

문서의 또 다른 역할은 개발 중간의 의사결정 기준이다. 위시켓 블로그에 따르면 프로젝트 개요와 목적이 명확하면 중간에 기능 추가 요청이 나올 때 판단 기준이 된다.

비개발자용 7항목 템플릿

아래 순서대로 한글 문서나 엑셀에 채우면 된다. 전문 양식은 필요 없다. 항목이 비지 않는 것이 중요하다.

1. 프로젝트 개요 — 왜 만드는지, 무엇이 되면 성공인지 한 문단으로 적는다. 예: "전화로만 받던 수강 문의를 홈페이지 예약으로 받는다."
2. 사용자 — 누가 쓰는지 적고 손님이 보는 화면과 운영자가 쓰는 관리 화면을 구분한다.
3. 화면 목록 — 메뉴를 기준으로 필요한 페이지를 전부 나열한다. 홈, 소개, 가격, 예약, 공지처럼 이름만 적어도 된다.
4. 기능 목록 — 화면마다 일어나는 동작을 문장으로 쓴다. 반드시 필요한 기능과 있으면 좋은 기능을 나눠 표시한다.
5. 데이터 항목 — 저장할 정보를 나열한다. 예약이라면 이름·연락처·희망 날짜·요청 사항처럼 실제 항목 단위로 적는다.
6. 예외 상황 — 잘못 입력했을 때, 취소·변경할 때, 마감됐을 때처럼 평소와 다른 흐름을 적는다. 견적 단계에서 가장 많이 빠지는 부분이다.
7. 제약·참고 — 예산 범위, 희망 오픈 시기, 참고 서비스 두세 개와 각각 마음에 드는 점을 적는다.

문서를 보낼 때는 이 한 문장을 붙이면 된다. "이 문서에 적힌 범위로 견적을 부탁드리고, 문서 밖 작업이 나오면 진행 전에 추가 견적으로 알려 주세요." 범위와 변경 절차를 처음부터 못 박는 말이라, 나중의 비용 다툼을 크게 줄여 준다. 문서 이전에 모아 둘 자료가 궁금하다면 발주 전 준비물 글을 먼저 보면 된다.

모호한 문장과 견적 가능한 문장

같은 요구도 문장이 얼마나 구체적이냐에 따라 견적 정확도가 달라진다. 아래 표처럼 "확인할 수 있는 문장"으로 바꾸는 것이 작성법의 절반이다.

모호한 문장	견적 가능한 문장
회원 기능 넣어 주세요	이메일로 가입하고, 로그인하고, 비밀번호를 찾을 수 있어야 한다
속도는 빠르게요	첫 화면이 3초 안에 떠야 하고, 응답 시간은 2초 이내여야 한다
관리는 편하게요	운영자가 예약 목록을 날짜별로 보고, 예약을 취소 처리할 수 있어야 한다
모바일 되게요	스마트폰 화면에서 메뉴·예약·결제가 전부 동작해야 한다

왼쪽 문장으로는 업체가 각자 다른 수준을 상상한다. 오른쪽 문장으로는 누가 읽어도 같은 작업량이 나온다. 이랜서 블로그가 흔한 실수로 꼽는 것도 같은 지점이다. "응답 시간은 빠르게"보다 "응답 시간은 2초 이내로"처럼 확인 가능한 기준을 적으라는 것. 위시켓 블로그의 비기능 요구사항 예시인 "100명까지 동시 접속해도 느려지지 않아야 함"도 같은 원리다. 검수할 때 통과·미달을 판정할 수 있는 문장이 견적서에서도 힘을 갖는다.

자주 하는 오해 세 가지

첫째, "전문 양식을 갖춰야 한다"는 오해다. 실제로는 항목이 채워져 있으면 한글 문서든 엑셀이든 메일 본문이든 상관없다. 형식을 다듬는 일은 업체 몫이고 내용이 빠지지 않게 하는 일은 발주자 몫이다.

둘째, "한 번 쓰면 끝"이라는 오해다. 요구사항은 상담을 거치며 바뀌기 마련이라, 고칠 때마다 날짜와 버전을 남겨야 한다. 이랜서 블로그도 버전 관리를 하지 않는 것을 흔한 실수로 꼽는다. 어느 판이 기준인지 애매해지면 검수 때 다툼이 된다.

셋째, "자세히 쓰면 견적이 비싸진다"는 오해다. 구체적으로 쓴다고 없던 작업이 생기는 게 아니라, 숨어 있던 작업이 견적 단계에서 드러날 뿐이다. 같은 작업이 개발 중반에 발견되면 추가 비용에 일정 지연까지 얹어서 치르는 경우가 많다.

덧붙여 상황별 기준도 다르다. 페이지 네댓 장짜리 소개형 사이트라면 화면 목록과 참고 서비스만 적어도 견적이 크게 어긋나지 않는다. 반면 예약·결제·회원처럼 데이터가 오가는 서비스라면 7항목을 전부 채우는 편이 안전하다. 소개형은 홈페이지 제작, 기능형은 웹 서비스 개발 페이지에서 유형별 진행 방식을 확인할 수 있다.

가상 예시 — 필라테스 스튜디오 예약 홈페이지

다음은 이해를 돕기 위한 가상 예시다. 필라테스 스튜디오 원장이 회원 상담에 지쳐 예약 홈페이지를 발주하기로 했다. 문서 없이 세 업체에 문의했더니 금액이 크게 벌어져 비교가 안 됐다. 그래서 저녁 두 번을 들여 7항목을 채웠다. 화면은 홈·소개·수업 안내·예약·공지 다섯 개, 기능은 "수업별 잔여 자리 표시"와 "예약 시 문자 알림"을 필수로, "정기권 결제"는 희망으로 표시했다. 데이터 항목에는 이름·연락처·수업 회차를, 예외 상황에는 당일 취소와 정원 마감을 적었다.

다시 받은 견적은 세 곳 모두 같은 범위를 계산했고 금액 차이는 관리 화면의 수준 차이로 설명이 됐다. 원장은 "필수 기능만 먼저, 정기권 결제는 2차로"라는 결정을 문서 위에서 내렸다.