목차
안녕하세요, 케이트리솔루션입니다.
먼저 답부터 드리면, 외주를 맡기기 전에 고객이 완벽한 기획서를 만들어 올 필요는 없습니다. 누가 쓰는지, 어떤 일이 처리돼야 하는지, 언제까지 필요한지 이 세 가지만 정리돼 있으면 충분합니다. 나머지를 질문으로 끌어내 요구사항 정의서로 만드는 건 개발사의 몫입니다. 다만 그 문서가 계약 전에 확정되는지는 고객이 꼭 확인하셔야 합니다.
요구사항 정의서는 무엇인가?
요구사항 정의서는 “무엇을 만들고, 무엇은 만들지 않는지”를 글로 적어 고객과 개발사가 함께 서명하는 문서입니다. 디자인 시안이나 화면 캡처와는 다릅니다. 화면이 어떻게 생겼는지보다 그 화면에서 무슨 일이 일어나야 하는지를 적습니다.
예를 들어 “회원가입 기능”이라고만 적으면 사람마다 떠올리는 게 다릅니다. 요구사항 정의서에는 이렇게 풀어 씁니다.
- 가입 방법: 이메일, 카카오, 네이버 중 무엇을 지원하는가
- 필수 정보: 이름, 연락처, 생년월일 중 무엇을 받는가
- 승인: 가입 즉시 이용 가능한가, 관리자가 승인해야 하는가
- 탈퇴: 탈퇴하면 작성한 글과 결제 내역은 어떻게 되는가
한 줄짜리 기능이 네 줄로 늘어났습니다. 이 네 줄이 정해지지 않은 채 개발을 시작하면, 개발 중간에 하나씩 질문이 튀어나오고 그때마다 일정이 밀립니다.
왜 개발 전에 확정해야 할까?
외주 분쟁을 들여다보면 “이것도 해 주는 줄 알았다”와 “그건 계약 범위가 아니다”가 맞부딪히는 경우가 대부분입니다. 양쪽 다 거짓말을 한 건 아닙니다. 범위가 말로만 오갔기 때문에 서로 다르게 기억할 뿐입니다.
같은 질문이라도 언제 꺼내느냐에 따라 비용이 달라집니다.
| 질문을 발견한 시점 | 드는 비용 |
|---|---|
| 기획 단계 | 회의 30분, 문서 몇 줄 수정 |
| 개발 중간 | 이미 만든 화면과 데이터 구조를 고치는 데 며칠 |
| 오픈 이후 | 운영 중인 데이터를 옮기며 수정, 고객 불편까지 발생 |
그래서 케이트리솔루션은 모든 프로젝트를 요구사항 정의서와 기획 정책서를 확정한 뒤에 착수합니다. 문서 단계가 번거로워 보여도, 계약서의 지체보상 조항이 실제로 의미를 가지려면 “무엇을 기간 안에 만들기로 했는가”가 먼저 적혀 있어야 합니다.
미팅 전에 고객이 준비하면 좋은 것
거창한 문서가 아니어도 됩니다. 메모장에 아래 다섯 가지를 적어 오시면 첫 미팅의 밀도가 확 달라집니다.
- 사용자: 이 서비스를 쓰는 사람은 누구인가. 고객, 직원, 관리자처럼 역할을 나눠 적습니다.
- 핵심 업무: 사이트에서 실제로 처리돼야 하는 일. 예약, 주문, 결제, 승인, 정산 같은 동사로 적으면 좋습니다.
- 지금 방식: 그 일을 현재는 어떻게 하고 있는가. 엑셀, 전화, 카카오톡 단톡방이라도 괜찮습니다. 지금 방식에서 불편한 점이 곧 요구사항입니다.
- 참고 서비스: 비슷하게 동작하는 앱이나 사이트. “이 앱의 예약 화면처럼”이라는 한마디가 긴 설명보다 빠릅니다.
- 일정과 예산 범위: 오픈해야 하는 날짜가 정해져 있는지, 대략 어느 정도 규모를 생각하는지.
여기서 3번이 특히 중요합니다. 지금 엑셀로 관리하는 직원이 어디서 실수하는지, 전화 예약을 받다가 무엇이 꼬이는지를 들으면 꼭 필요한 기능과 있으면 좋은 기능이 저절로 갈립니다.
개발사와 함께 채워 가는 것
고객이 준비하기 어렵고, 경험 있는 개발사가 먼저 물어봐야 하는 영역도 있습니다.
- 예외 상황: 결제는 됐는데 주문 저장이 실패하면? 같은 버튼을 두 번 누르면? 인터넷이 끊기면?
- 권한: 관리자 중에서도 누가 무엇을 볼 수 있고 고칠 수 있는가. 직원이 퇴사하면 그 계정은?
- 데이터 보관: 탈퇴 회원의 정보와 결제 내역을 얼마나 보관하는가.
- 외부 연동: 결제, 알림톡, 지도, 기존에 쓰던 프로그램과 무엇을 연결해야 하는가.
- 운영: 오픈 이후 자주 바뀌는 내용을 관리자가 직접 수정해야 하는가.
이런 질문을 개발사가 먼저 꺼내는지 보면 그 업체가 운영을 해 본 곳인지 짐작할 수 있습니다. 케이트리솔루션 대표는 앱, 관리자 프로그램, 매장 키오스크를 묶은 무인 매장 운영 시스템과 행사 QR 체크인 시스템을 직접 개발하고 운영해 봤습니다. 그래서 기능 목록을 받으면 “이게 틀어지면 누가 곤란해지는가”부터 묻습니다.
요구사항 정의서 목차 예시
프로젝트마다 다르지만, 웹서비스라면 대체로 아래 틀에서 크게 벗어나지 않습니다.
- 프로젝트 개요: 목적, 대상 사용자, 오픈 목표일
- 사용자 역할: 비회원, 회원, 관리자 등 역할별 할 수 있는 일
- 기능 목록: 기능 이름, 설명, 우선순위(필수/선택)
- 기능 상세: 기능별 입력값, 처리 규칙, 예외 상황
- 관리자 기능: 운영자가 직접 관리할 항목
- 외부 연동: 결제, 알림, 외부 API 목록
- 범위 외 항목: 이번 계약에서 만들지 않는 것
- 인도물: 소스 코드, 문서, 계정 등 넘겨받을 것
7번 범위 외 항목을 꼭 넣으시길 권합니다. 무엇을 만들지 않는지 적어 두면 나중에 “그건 원래 들어가는 줄 알았다”는 말이 나올 틈이 줄어듭니다. 처음부터 모든 기능을 넣기보다 필수 기능만 먼저 만들고 반응을 보며 키우는 방식이라면, 선택 기능을 이 칸에 옮겨 두면 됩니다.
8번 인도물에는 도메인과 서버 계정의 명의도 함께 적어 두세요. 왜 중요한지는 홈페이지 외주 전 도메인과 서버 명의 확인하기에 정리해 두었습니다.
자주 묻는 질문
요구사항 정의서 작성 비용을 따로 내야 하나요?
업체마다 다릅니다. 기획만 별도 계약으로 떼는 곳도 있고 개발 계약에 포함하는 곳도 있습니다. 어느 쪽이든 견적을 받을 때 “요구사항 문서를 누가, 언제까지 만드는지”를 꼭 물어보세요. 견적이 업체마다 크게 다른 이유도 여기서 갈리는 경우가 많습니다. 자세한 내용은 홈페이지 제작 비용 이야기에 있습니다.
개발 중에 요구사항이 바뀌면 어떻게 하나요?
바뀌는 건 자연스럽습니다. 중요한 건 바뀐 내용을 말로 끝내지 않고 문서에 다시 적는 것입니다. 변경이 일정과 비용에 어떤 영향을 주는지도 그때 함께 합의해야 나중에 다툼이 없습니다.
홈페이지 하나 만드는데도 이런 문서가 필요한가요?
회사 소개 홈페이지라면 메뉴 구성과 페이지별 내용 정리 정도면 충분합니다. 회원, 결제, 관리자 화면이 들어가는 순간부터 위 목차가 필요해집니다. 둘의 차이는 플랫폼·솔루션 개발 외주 글에 정리해 두었습니다.
마치며
요구사항 정의서는 개발사를 위한 서류가 아니라 고객을 지키는 서류입니다. 무엇을 받기로 했는지 적혀 있어야 받지 못했을 때 말할 수 있습니다.
정리가 덜 된 아이디어라도 괜찮습니다. 메모 몇 줄만 들고 아래 문의 폼에 남겨 주시면, 질문을 드리며 함께 문서로 만들어 가겠습니다.