초록
홈페이지나 시스템을 만들려고 마음먹은 사람이 가장 자주 멈추는 지점은 예산도 업체도 아니고 "그래서 뭘 원하는지를 어떻게 적지" 입니다. 대부분 기능 목록을 쓰려다 막힙니다. 기능은 결과이지 출발점이 아니기 때문입니다. 이 글은 요구사항을 현행 업무 흐름에서 역산하는 네 단계로 정리합니다. ① 지금 어떻게 하고 있는지를 그대로 적고, ② 그 흐름에서 사람이 계속할 일과 사이트가 대신할 일을 가르고, ③ 남은 것을 "누가 무엇을 한다" 형태의 행동 문장으로 바꾸고, ④ 필수·권장·선택 3등급과 "아직 안 정해진 것" 을 표시합니다. 이 순서를 지키면 전문 용어를 몰라도 견적이 흔들리지 않는 문서가 나옵니다. 완성된 문서를 옮겨 담을 양식은 견적 요청서 1장 템플릿에 있습니다.
1. 왜 기능 목록부터 쓰면 손이 멈추나
"필요한 기능을 정리해서 보내주세요"라는 말을 듣고 빈 문서를 열면 대개 이런 것이 적힙니다.
- 회원가입
- 게시판
- 관리자 페이지
- 반응형
이 목록의 문제는 틀린 것이 아니라 아무것도 결정하지 못한다는 점입니다. 회원가입 하나만 해도 이메일만 받는지, 휴대폰 인증을 하는지, 사업자 정보를 받는지, 가입 후 관리자 승인이 필요한지에 따라 작업량이 몇 배로 갈립니다. 업체는 이 목록을 받으면 자기 기준으로 상상해서 견적을 냅니다. 세 곳에 보내면 세 가지 상상이 돌아옵니다.
기능이라는 단어가 함정입니다. 기능은 업무 흐름을 자동화한 결과물의 이름입니다. 결과부터 적으려니 손이 멈추는 게 정상입니다.
그래서 순서를 뒤집습니다. 지금 어떻게 일하고 있는지부터 적습니다. 이건 전문 지식이 필요 없고, 이미 매일 하고 있는 일이라 막힐 이유가 없습니다.
전체 변환은 네 단계입니다. 왼쪽은 누구나 쓸 수 있고, 오른쪽으로 갈수록 견적을 받을 수 있는 형태가 됩니다.
2. 1단계 — 지금 어떻게 하고 있는지를 그대로 적는다
만들려는 것과 관련된 업무를 처음부터 끝까지, 문장으로 적습니다. 다섯 문장이면 충분합니다.
예를 들어 예약을 받는 업체라면 이렇게 됩니다.
손님이 인스타그램 DM이나 전화로 문의한다. 담당자가 달력을 보고 가능한 날짜를 알려준다. 손님이 날짜를 고르면 계좌번호를 보내고 예약금을 받는다. 입금을 확인하면 엑셀에 이름·날짜·연락처를 적는다. 하루 전에 담당자가 문자로 안내를 보낸다.
그림으로 보면 이렇게 한 줄입니다. 이 줄이 요구사항 문서의 원본입니다.
여기서 지켜야 할 규칙이 두 가지 있습니다.
규칙 하나 — 이상적인 흐름이 아니라 실제 흐름을 적습니다. "원래는 이렇게 해야 하는데 지금은 대충 한다"면 대충 하는 쪽을 적으세요. 만들 물건은 실제 업무에 붙습니다.
규칙 둘 — 예외를 같이 적습니다. 취소는 어떻게 처리하는지, 두 명이 같은 날짜를 원하면 어떻게 하는지, 입금이 안 들어오면 언제까지 기다리는지. 예외 처리가 전체 개발비의 상당 부분을 차지하는데, 발주 문서에서 가장 자주 빠지는 부분이기도 합니다.
3. 2단계 — 사람이 계속할 일과 사이트가 대신할 일을 가른다
적어 놓은 흐름의 각 줄 옆에 표시를 합니다.
| 현행 업무 | 사이트가 대신 | 사람이 계속 |
|---|---|---|
| DM·전화로 문의를 받는다 | ○ (예약 폼) | |
| 가능한 날짜를 알려준다 | ○ (달력에서 마감된 날 회색 처리) | |
| 계좌번호를 보내고 입금을 받는다 | △ (카드 결제로 바꿀지 결정 필요) | |
| 입금 확인 후 엑셀에 적는다 | ○ (자동 기록) | |
| 하루 전 문자 안내 | △ (문자 발송은 별도 비용) | |
| 손님이 이상한 요청을 할 때 응대 | ○ |
아까 그린 한 줄 위에 그대로 얹으면 이렇게 됩니다. 같은 흐름인데 각 칸의 처리 주체가 달라졌습니다.
여기서 나오는 △가 견적을 가장 크게 흔드는 항목입니다. 결제를 붙이느냐 마느냐, 문자를 자동으로 보내느냐 마느냐는 각각 독립된 결정이고 비용도 별도입니다. 이 단계에서 확정하지 못해도 괜찮습니다. 확정하지 못했다는 사실 자체를 문서에 남기는 것이 요령입니다(4단계에서 다룹니다).
○로 표시한 줄만 모으면 그것이 곧 만들 범위입니다. 기능 목록을 상상해서 짜낸 게 아니라 업무에서 잘라낸 것이라 빠뜨릴 수가 없습니다.
4. 3단계 — 행동 문장으로 바꾼다
○ 표시된 줄을 "누가 무엇을 한다" 형태로 다시 씁니다. 주어를 반드시 넣는 것이 핵심입니다.
| 이렇게 쓰면 흔들립니다 | 이렇게 쓰면 고정됩니다 |
|---|---|
| 예약 기능 | 방문자가 날짜와 시간을 골라 예약을 신청한다 |
| 관리자 페이지 | 관리자가 예약 목록을 날짜순으로 보고, 확정·취소로 상태를 바꾼다 |
| 알림 | 예약이 들어오면 담당자 휴대폰으로 알림이 간다 |
| 게시판 | 관리자가 공지를 등록하고, 방문자는 목록과 본문을 읽는다 |
| 회원가입 | 방문자가 이메일과 휴대폰 번호로 가입하고, 관리자 승인 후 로그인할 수 있다 |
오른쪽 문장들은 읽는 사람이 다르게 해석할 여지가 거의 없습니다. 주어(방문자/관리자/시스템)와 동사가 있으면 화면 하나가 자동으로 결정되기 때문입니다.
주어를 넣는 순간 자연스럽게 드러나는 것이 하나 더 있습니다. 관리자 쪽 업무입니다. 발주 문서의 절반이 관리자 화면인 경우가 흔한데, 방문자 화면만 상상하면 통째로 빠집니다. 그리고 이건 나중에 "그건 견적에 없었습니다"로 돌아옵니다.
화면 목록으로 한 번 뒤집어 본다
행동 문장이 열 줄쯤 모이면, 이번엔 그것을 화면 단위로 묶어 봅니다.
방문자
□ 첫 화면 — 소개, 예약하기 버튼
□ 예약 화면 — 달력, 시간 선택, 이름·연락처 입력
□ 완료 화면 — 접수 번호 안내
관리자
□ 로그인
□ 예약 목록 — 날짜별, 상태 변경
□ 예약 상세 — 메모 남기기
□ 마감일 설정 — 특정 날짜 예약 막기
화면 개수는 견적의 기본 단위입니다. 이 목록이 있으면 업체가 "페이지 몇 개인가요" 라고 물었을 때 바로 답할 수 있고, 견적서를 받았을 때 어느 화면이 빠졌는지 대조할 수 있습니다.
5. 4단계 — 등급을 매기고, 안 정해진 것을 표시한다
모든 항목을 세 등급으로 나눕니다.
| 등급 | 뜻 | 판단 기준 |
|---|---|---|
| 필수 | 이게 없으면 오픈 못 함 | 빼고 오픈했다고 상상했을 때 업무가 멈추는가 |
| 권장 | 있으면 좋지만 한 달 뒤에 붙여도 됨 | 지금 사람이 해도 버틸 수 있는가 |
| 선택 | 예산이 남으면 | 없어도 아무도 불편하지 않은가 |
말로 하면 헷갈리므로 질문 두 개로 가릅니다.
등급을 매기는 진짜 이유는 예산이 초과됐을 때 어디를 잘라낼지 미리 정해 두는 것입니다. 예산 초과는 대부분의 프로젝트에서 일어나고, 그 시점에 무엇을 뺄지 협의하기 시작하면 일정이 밀립니다.
"아직 안 정해진 것"을 숨기지 않는다
발주자가 가장 자주 하는 실수는 결정하지 못한 항목을 모호한 문장으로 덮는 것입니다.
"결제는 상황에 맞게 적절히 처리해 주세요"
이 문장을 받은 업체가 할 수 있는 선택은 두 가지뿐입니다. 넉넉하게 잡아서 견적을 올리거나, 최소한으로 잡았다가 나중에 추가 비용을 청구하거나. 어느 쪽이든 발주자가 손해입니다.
대신 이렇게 적습니다.
[미정] 결제 방식
- 후보 A: 계좌 이체 안내만 (지금과 동일, 개발 없음)
- 후보 B: 카드 결제 연동
- 결정 시점: 계약 후 1주 이내
- 요청: A/B 각각의 금액을 나눠서 적어 주세요
미정을 미정이라고 적고 선택지별 금액을 따로 요청하면, 견적서가 곧 의사결정 자료가 됩니다. 이 항목 하나로 견적 비교의 정확도가 크게 올라갑니다. 견적서 자체를 비교 가능하게 정규화하는 방법은 견적이 세 배로 갈리는 이유에서 따로 다뤘습니다.
6. 자주 통째로 빠지는 여섯 가지
네 단계를 마친 문서에 아래 항목이 있는지 확인하세요. 업무 흐름에서 역산해도 잘 안 나오는 것들입니다.
콘텐츠는 누가 만드나 — 글, 사진, 회사 소개 문구. 개발 범위가 아닌 경우가 대부분인데 준비가 안 되면 오픈이 밀립니다. 실제로 일정 지연 원인 1위입니다.
기존 데이터를 옮기나 — 기존 사이트의 게시글, 회원, 주문 내역. 옮긴다면 몇 건인지, 어떤 형태로 갖고 있는지(엑셀/DB/화면만)를 적으세요. 형태에 따라 비용이 크게 다릅니다.
모바일에서 관리자도 쓰나 — 방문자 화면은 당연히 모바일 대응을 하지만, 관리자 화면까지 모바일로 만들면 작업량이 늘어납니다. 사장님이 폰으로 예약을 확인해야 한다면 미리 말해야 합니다.
알림을 어디로 받나 — 문자, 이메일, 카카오 알림톡, 텔레그램은 각각 비용과 절차가 다릅니다. 문자·알림톡은 별도 발송 요금과 사전 심사가 붙습니다.
외부 서비스 가입은 누가 하나 — 결제사(PG), 문자 발송사, 지도 API 등은 사업자 명의로 발주자가 직접 가입해야 하는 것이 많고 심사에 며칠 걸립니다. 개발이 끝나도 이게 안 끝나면 오픈을 못 합니다.
오픈 후 누가 고치나 — 직접 고칠 생각이면 관리자에서 수정 가능한 범위를 미리 지정해야 합니다. "문구 하나 바꾸는 데도 업체에 연락"하는 구조가 되면 매달 비용이 나갑니다. 이 부분의 상세는 홈페이지 유지보수, 월 얼마가 정상인가를 참고하세요.
7. 한 시간 진행표
혼자 또는 담당자 둘이서 아래 순서로 진행하면 한 시간 안에 끝납니다.
0~15분 · 현행 흐름 적기
□ 처음부터 끝까지 다섯 문장
□ 예외 상황 세 가지 (취소·중복·미입금 등)
15~25분 · 가르기
□ 각 줄에 ○(사이트가 대신) / △(결정 필요) / 공란(사람이 계속) 표시
25~45분 · 행동 문장으로 바꾸기
□ ○ 항목을 "누가 무엇을 한다"로 다시 쓰기
□ 관리자 쪽 문장이 있는지 확인
□ 화면 목록으로 묶어 보기
45~60분 · 등급과 미정 표시
□ 필수 / 권장 / 선택
□ [미정] 항목과 후보, 결정 시점
□ 빠지기 쉬운 여섯 가지 대조
끝나면 견적 요청서 1장 템플릿의 빈칸에 그대로 옮겨 담으면 됩니다. 양식을 먼저 열지 않은 이유가 여기 있습니다. 채울 내용이 없는 상태에서 양식을 열면 빈칸만 노려보게 되기 때문입니다.
8. 이 문서가 실제로 하는 일
요구사항 문서를 잘 쓴다고 개발이 싸지지는 않습니다. 대신 세 가지가 달라집니다.
첫째, 견적이 비교 가능해집니다. 같은 행동 문장 목록을 세 곳에 보내면 세 견적이 같은 것을 계산합니다. 차이가 나면 그 차이가 곧 정보입니다.
둘째, 추가 비용 협상이 줄어듭니다. 분쟁의 대부분은 "이건 포함이라고 생각했다"에서 시작합니다. 행동 문장 단위로 적혀 있으면 포함 여부가 문장 단위로 확인됩니다.
셋째, 업체를 판별할 수 있게 됩니다. 잘 쓴 요구사항을 받으면 경험 있는 업체는 되묻습니다. "예약이 겹치면 어느 쪽을 우선하나요", "취소 시 예약금은 어떻게 되나요" 같은 질문이 오면 문서를 읽은 것입니다. 되묻지 않고 금액표만 보내는 곳은 업체를 검증하는 7가지 확인에서 다룬 신호에 해당합니다.
대략의 비용 범위를 먼저 잡고 싶다면 외주 개발 비용 계산기에서 화면 수와 기능만 골라 보세요. 지금 만든 화면 목록을 그대로 넣으면 됩니다. 연락처 없이 결과를 볼 수 있습니다.