"이런 서비스를 만들고 싶은데 얼마나 나올까요?"로 시작하는 문의를 받으면, 개발사는 먼저 머릿속으로 빈칸을 채워요. 회원가입은 이메일만인지 소셜까지인지, 결제는 붙는지, 관리자 화면은 있는지, 알림은 어디까지인지. 발주자가 정해주지 않은 빈칸은 개발사가 상상으로 메우고, 상상한 범위가 넓을수록 견적은 올라가요.
그래서 같은 아이디어를 세 곳에 문의했는데 견적이 두 배 넘게 벌어지는 일이 생겨요. 실력 차이라기보다 각자 상상한 범위가 다른 경우가 많아요. 게다가 불확실성이 클수록 개발사는 안전마진을 얹어요. 착수한 뒤에 "그건 견적에 없던 건데요"로 부딪히는 것보다 미리 얹어두는 편이 서로 덜 아프거든요. 결국 범위를 정하지 않은 대가는 발주자가 금액으로 내게 돼요.
시작한 다음에 범위가 늘면 더 비싸져요. 이미 만든 화면 구조를 바꿔야 하고, 재견적과 일정 재협상이 붙고, 그 사이 개발은 멈춰요. 범위 확정은 개발이 시작되기 전에 끝나야 하는 일이에요.
이 글은 개발사에 문의하기 전에, 혼자 앉아서 범위를 확정하는 절차만 다뤄요. 금액과 기간의 감을 먼저 잡고 싶다면 MVP 개발 기간과 비용을 정리한 글을, 업체 선택과 계약 조건은 외주 계약 전 체크리스트를 따로 보세요.
순서와 각 단계에서 손에 남는 산출물이에요. 마지막 산출물인 범위 문서를 그대로 견적 요청에 붙이는 게 목표예요.
설명이 추상적으로 흐르지 않게 예시를 하나 정하고 끝까지 끌고 갈게요. 동네 공방의 원데이 클래스를 예약하는 서비스예요. 처음 섭외한 공방은 5곳, 열리는 클래스는 20개 남짓이라고 가정할게요.
범위는 가설에서 내려와요. 첫 문장이 흐릿하면 뒤의 네 단계가 전부 흐릿해지니까, 여기에 시간을 가장 많이 쓰는 게 맞아요. 문장 틀은 이걸 쓰세요.
[누가] [어떤 상황에서] [어떤 행동을 한다] + [무엇을 보면 맞았다고 할지]
예시 서비스에 넣으면 이렇게 돼요. "퇴근길 30대 직장인은 주말 원데이 클래스를 스마트폰에서 3분 안에 예약한다. 2주 동안 클래스 상세를 연 사람 중 예약 완료까지 간 비율이 10%를 넘으면 맞았다고 본다." 뒤쪽 숫자는 업계 평균 같은 게 아니라 내가 직접 그은 합격선이에요. 근거가 없어도 괜찮아요. 중요한 건 출시 후에 "그래서 맞았어, 틀렸어?"를 말할 수 있게 미리 선을 그어두는 것이에요.
자주 나오는 실패는 세 가지고, 고치는 방법도 정해져 있어요.
기능을 Must·Should·Could·Won't로 나누는 MoSCoW 구분은 MVP 개발 완전 가이드에 정리해 뒀으니 여기서 다시 설명하지 않을게요. 이 글이 다루는 건 그 구분표를 채우기 전에 무엇을 후보로 올릴지 정하는 단계예요.
가설 문장을 사용자가 하는 행동 동사로 쪼개요. 기능 이름이 아니라 동사여야 해요. "예약 관리 기능"이 아니라 "예약을 넣는다"로요. 이름으로 적는 순간 그 안에 뭐가 들었는지가 다시 안 보이거든요. 예시 가설을 쪼개면 이렇게 나와요.
이제 행동마다 질문을 하나씩 던져요. "이게 빠지면 가설을 확인할 수 없나, 아니면 불편하기만 한가?" 불편하기만 하다면 뺍니다.
남은 행동을 화면 단위로 묶으면 클래스 목록 / 클래스 상세와 날짜 선택 / 예약 정보 입력 / 예약 완료 네 개예요. 여기서 숫자 세 개가 나와요. 화면 4개, 사용자 역할 1개(예약하는 사람만. 공방 사장님은 아직 앱을 쓰지 않아요), 외부 연동 0개. 이 세 숫자는 5단계 견적 요청서에 그대로 들어가요. 개발사가 견적을 낼 때 실제로 세는 단위가 딱 이것들이거든요.
2단계에서 걸러지지 않고 "이건 넣어야 하나 말아야 하나" 싶은 게 꼭 남아요. 그때는 아래 세 질문을 순서대로 던져요.
질문 3이 중요한 이유는, 앞의 둘이 "얼마나 중요한가"를 묻는 데 반해 이건 되돌리는 비용을 묻기 때문이에요. 중요도는 낮은데 지금 정해두지 않으면 나중에 값을 크게 치르는 항목이 있어요.
여기서 '정한다'와 '만든다'는 다르다는 점을 기억하세요. 질문 3의 답은 대체로 지금 만들라가 아니라 지금 자리를 비워두라예요. 견적 요청서에 "이건 이번 범위 밖이지만 다음 버전에 붙을 예정이니 그걸 전제로 설계해 달라"고 한 줄 적어주는 것으로 충분한 경우가 많아요.
실무에서 발이 묶이는 기능은 대체로 정해져 있어요. 위 세 질문을 자주 나오는 일곱 가지에 적용한 결과를 표 1에 정리했어요. 표에서 실제로 봐야 할 칸은 마지막 대체 수단이에요. "빼세요"는 조언이 못 되지만 "관리자 화면 대신 스프레드시트를 쓰세요"는 오늘 실행할 수 있는 지시니까요. 초기 사용자 규모에서는 사람이 손으로 대신할 수 있는 항목이 생각보다 많아요.
다만 일곱 번째 줄만 성격이 달라요. 사용자 행동 로그는 대체 수단이 없고, 빼면 안 돼요. 1단계에서 "무엇을 보면 맞았다고 할지"를 정해뒀는데 그 숫자를 셀 장치가 없으면, 출시하고 나서도 가설이 맞았는지 틀렸는지 말할 수 없어요. 화면 하나를 포기하더라도 이건 남기세요. 구글 애널리틱스(GA4) 같은 무료 도구를 붙이고 핵심 행동 두세 개에만 이벤트를 심으면 돼요. 예시 서비스라면 클래스 상세 열람, 예약 시작, 예약 완료 세 개면 1단계에서 그은 합격선을 그대로 셀 수 있어요.
표 1을 다 지나면 제외 목록이 손에 남아요. 뺀 항목을 반드시 적어 두세요. 머릿속으로만 뺀 기능은 2주 뒤에 아무 일 없었다는 듯 다시 들어와요. 이어지는 표 2는 그렇게 남은 목록을 견적 요청서 문장으로 옮길 때 쓰는 대조표라, 5단계를 읽고 다시 보면 돼요.
3단계의 세 질문을 실무에서 자주 막히는 일곱 가지 기능에 적용한 결과예요. 마지막 칸이 핵심이에요. 대체 수단이 있으면 그 기능은 이번 범위에서 빼고 제외 목록으로 옮기면 돼요.
| 기능 | MVP에 넣어야 할 때 | 빼도 되는 때 | MVP 단계의 대체 수단 |
|---|---|---|---|
| 회원가입·로그인 | 사용자별로 데이터가 쌓여야 가설을 확인할 수 있을 때(내 예약, 내 기록) | 한 번의 행동으로 검증이 끝날 때 | 이름·연락처만 받는 입력 폼. 계정 없이 예약만 받기 |
| 결제 | 지불 의향 자체가 검증할 가설일 때 | 검증 대상이 사용 의향일 때 | 계좌이체·현장 결제·수기 인보이스, 결제 링크 수동 발송 |
| 관리자 화면 | 운영자가 처리할 건수가 사람 손으로 감당이 안 될 때 | 운영 건수가 하루 수십 건 이하일 때 | 스프레드시트 + 조회 전용 화면 하나. 초기엔 개발사가 DB를 직접 조회해 주기도 해요 |
| 푸시·이메일 알림 | 알림이 재방문을 만드는 게 가설의 핵심일 때 | 알림 없이도 사용자 행동이 완결될 때 | 운영자가 문자·메신저로 수동 발송 |
| 검색·필터 | 항목이 수백 개 이상이라 목록으로는 못 찾을 때 | 항목이 수십 개 이하일 때 | 목록 정렬 고정 + 카테고리 탭 2~3개 |
| 파일 업로드 | 사용자가 올린 파일이 곧 서비스의 내용물일 때 | 파일이 운영 편의용일 때 | 이메일·메신저로 받아 운영자가 대신 등록 |
| 사용자 행동 로그 | 항상 | 없음 | 없음. 지표를 못 모으면 가설 검증 자체가 성립하지 않아요 |
'빼도 되는 때'에 해당하면 그 자리에서 제외 목록에 옮겨 적으세요. 머릿속으로만 뺀 기능은 개발 도중에 다시 들어와요.
같은 기능도 어떻게 적느냐에 따라 견적이 달라져요. 왼쪽은 발주자가 흔히 쓰는 문장, 오른쪽은 개발사가 곧바로 셀 수 있게 다시 쓴 문장이에요.
| 흔히 쓰는 모호한 문장 | 견적이 흔들리는 이유 | 다시 쓴 문장 |
|---|---|---|
| "회원 관리 기능이 필요해요" | 가입 수단·비밀번호 찾기·탈퇴·회원 목록 화면까지, 상상할 수 있는 범위가 너무 넓어요 | "이메일 가입/로그인 1종. 소셜 로그인·탈퇴·회원 목록 화면은 이번 범위 아님" |
| "결제 붙여주세요" | PG(결제대행)사 선택, 정기결제 여부, 부분 취소·환불 정책에 따라 금액이 크게 갈려요 | "국내 카드 단건 결제 1종, PG사는 개발사 추천안 채택. 정기결제·부분 환불은 이번 범위 아님" |
| "관리자 페이지 필요해요" | 통계·권한 분리·검색까지 붙으면 사용자 화면보다 커질 수 있어요 | "예약 목록 조회 화면 1개, 상태 변경만 가능. 통계·권한 분리는 이번 범위 아님" |
| "알림 기능도요" | 푸시·문자·이메일·인앱 중 무엇인지, 발송 조건이 몇 개인지가 안 보여요 | "예약 완료 시 이메일 1종 자동 발송. 푸시·문자는 이번 범위 아님" |
| "반응형 지원해 주세요" | 대응 기기와 최소 해상도가 없으면 검수 기준을 잡을 수가 없어요 | "모바일 웹 우선, 최소 폭 360px 기준. PC는 레이아웃 깨짐만 없으면 됨. 태블릿 전용 레이아웃은 이번 범위 아님" |
다시 쓴 문장의 공통점은 두 가지예요. 숫자가 들어가 있고, '이번 범위 아님'이 붙어 있어요. 이 둘만 지켜도 견적서 사이의 편차가 눈에 띄게 줄어요.
개수를 먼저 정하면 그 숫자를 채우게 돼서 오히려 위험해요. 검증할 가설 한 문장에서 역산하는 게 맞아요. 가설을 사용자 행동 동사로 쪼개고, '이게 빠지면 가설을 확인할 수 없나, 불편하기만 한가'를 물어 불편한 것들을 빼면 남는 게 곧 범위예요. 이 글의 예시(원데이 클래스 예약)에서는 그렇게 추리니 화면 4개, 사용자 역할 1개, 외부 연동 0개가 남았어요.
사용자별로 데이터가 쌓여야 가설을 확인할 수 있다면 필요하고(내 예약, 내 기록처럼요), 한 번의 행동으로 검증이 끝난다면 이름·연락처만 받는 폼으로 충분해요. 다만 로그인은 되돌리기 비용이 큰 항목이라 주의가 필요해요. 이번에 안 넣더라도 견적 요청서에 '다음 버전에 계정이 붙을 예정'이라고 한 줄 적어 그걸 전제로 설계해 달라고 하세요.
검증하려는 게 '돈을 낼 의향'이라면 넣어야 하지만, '쓸 의향'이라면 뺄 수 있어요. 지불 의향은 계좌이체나 현장 결제, 수기 인보이스, 결제 링크 수동 발송으로도 확인돼요. 실제로 돈이 오가는지만 보면 되니까요. PG(결제대행) 연동은 정기결제와 부분 환불 여부에 따라 금액이 크게 갈리는 항목이라, 뺄 수 있다면 견적을 줄이는 효과도 커요.
운영 건수로 판단하세요. 하루에 처리할 일이 수십 건 이하라면 스프레드시트로 충분한 경우가 많아요. 현실적인 타협은 '조회 전용 화면 하나'예요. 목록을 보고 상태만 바꿀 수 있으면 되고, 통계와 권한 분리는 제외 목록으로 넘기세요. 관리자 화면은 요구가 쌓이면 사용자 화면보다 커지기 쉬워서 처음부터 문장으로 한계를 못 박아두는 게 좋아요.
화면 수, 사용자 역할 수, 외부 연동 수 중 하나라도 늘면 대개 다시 나와요. 그래서 처음부터 변경 처리 규칙을 범위 문서에 한 줄 넣어두는 게 좋아요. 실무에서는 먼저 같은 규모를 빼는 교환으로 처리해 보고, 뺄 게 없으면 그때 일정과 금액 변경으로 문서에 남기고 서면 합의하는 순서를 권해요. 말로만 넘어간 추가 요청이 나중에 다툼으로 이어져요.
기술적으로 무엇이 무거운지, 무엇을 나중에 붙이면 다시 짜야 하는지는 개발사가 훨씬 잘 알아요. 그 부분은 적극적으로 물어보세요. 다만 '무엇을 검증할 것인가'와 '무엇을 보면 맞았다고 할 것인가'는 발주자만 정할 수 있어요. 이게 없으면 개발사도 기준 없이 기능을 쌓을 수밖에 없어요. 가설 한 문장과 제외 목록만 들고 가도 첫 미팅의 질이 크게 달라져요.
여기까지 나온 걸 한 장으로 묶어요. 거창한 양식은 필요 없고 네 블록이면 돼요.
네 블록 중 견적 편차를 실제로 줄이는 건 제외 목록이에요. 견적이 벌어지는 이유는 적힌 것을 다르게 읽어서가 아니라 안 적힌 것을 각자 다르게 상상해서거든요. "회원 관리"라고만 쓰면 어떤 곳은 이메일 가입 하나를 떠올리고, 어떤 곳은 소셜 로그인 세 종류에 비밀번호 찾기, 탈퇴, 회원 목록 화면까지 떠올려요. 제외 목록은 그 상상에 뚜껑을 덮는 장치예요. 분쟁도 대개 여기서 갈려요. 적어둔 것은 다툴 일이 없고, 안 적어둔 것만 다투게 되니까요.
포함 목록도 문장을 바꿔야 해요. 앞에 붙인 표 2는 자주 쓰이는 모호한 문장이 왜 견적을 흔드는지, 어떻게 다시 쓰면 되는지를 대조한 거예요. 규칙은 하나예요. 숫자를 넣으세요. 화면 몇 개, 역할 몇 개, 연동 대상은 어디. 개발사가 세는 게 그것뿐이라 숫자가 들어간 문장은 곧바로 금액으로 번역돼요.
문서를 넘기고 개발이 시작되면 요청이 들어와요. 투자자가 한마디 하고, 초기 사용자가 아쉬운 걸 말하고, 공동창업자가 좋은 아이디어를 가져와요. 여기서 범위가 무너지면 앞의 다섯 단계가 통째로 무의미해지는데, 문제는 대부분 그 자리에서 대답해버려서 무너진다는 거예요.
운영 규칙 세 개면 막을 수 있어요.
상대에 따라 말하는 방식은 조금씩 달라요.
5단계에서 만든 문서를 개발사에 넘길 때 그대로 쓰는 형태예요. 가운데 칸이 이 표의 핵심이에요. 설명 대신, 예시 서비스(동네 공방 원데이 클래스 예약)에 실제로 적은 문장을 그대로 넣었어요. 자기 서비스의 단어로 바꿔 다섯 줄만 채우면 범위 문서는 끝나요.
| 블록 | 예시 서비스에 그대로 적은 문장 | 이 블록이 비면 생기는 일 |
|---|---|---|
| 가설과 성공 판정 지표 | "퇴근길 30대 직장인은 주말 원데이 클래스를 스마트폰에서 3분 안에 예약한다. 2주 동안 클래스 상세를 연 사람 중 예약 완료까지 간 비율이 10%를 넘으면 맞았다고 본다" | 개발 중 애매한 상황에서 개발사가 스스로 판단할 근거가 없어, 사소한 것까지 매번 되물어요 |
| 포함 행동 목록 | "클래스 내용과 가격을 본다 / 날짜와 시간을 고른다 / 예약을 넣는다" | 기능 이름으로만 적히면 그 안에 무엇이 들었는지를 서로 다르게 읽어요 |
| 규모 숫자 3개 | "화면 4개, 사용자 역할 1개, 외부 연동 0개" | 개발사가 실제로 세는 단위가 없어 금액이 넓은 범위로만 나와요 |
| 명시적 제외 목록 | "검색·필터, 온라인 결제, 예약 내역 화면, 관리자 화면은 이번 범위 아님. 운영은 스프레드시트로 처리" | 안 적힌 칸을 업체마다 다르게 상상해서 견적 편차가 벌어져요 |
| 변경 처리 규칙 | "제외 목록의 항목이 개발 중 추가되면 별도 견적과 일정 조정 후 서면으로 합의한다" | 추가 요청이 말로만 오가서, 몇 주 뒤에 무엇을 합의했는지 서로 다르게 기억해요 |
본문 5단계의 네 블록 중 '포함 행동 목록'에 붙는 규모 숫자만 따로 떼어 다섯 줄로 적었어요. 다 합쳐도 A4 한 장이에요. 양식을 다듬는 것보다 다섯 칸이 다 찼는지 확인하는 게 중요해요.
범위를 고정한 뒤에도 요청은 들어와요. 그 자리에서 대답하지 말고 위에서부터 순서대로 질문을 던지세요. 대부분은 세 줄 안에서 끝나고, 4번 아래까지 내려오는 요청은 실제로 드물어요.
| 순서 | 던지는 질문 | '예'일 때 | '아니오'일 때 |
|---|---|---|---|
| 1 | 이번에 검증할 가설을 확인하는 데 꼭 필요한가요? | 2번으로 넘어가요 | 이번 범위에서는 빼요. 3번으로 내려가 자리만 비워둘지 정해요 |
| 2 | 지금 사용자 규모에서 사람이 손으로 대신할 수 있나요? | 운영으로 처리하고 개발은 다음 버전에 넣어요. 손이 아파지면 그때 만들면 돼요 | 이번에 만들어야 하는 요청이에요. 4번으로 넘어가요 |
| 3 | 다음 버전에 붙일 때 이미 만든 걸 다시 짜야 하나요? | 만들지는 말고, 자리만 비워두는 설계를 개발사에 한 줄로 요청해요 | 다음 버전 목록에 적어두고 여기서 끝내요 |
| 4 | 같은 규모로 뺄 것이 있나요? 화면 1개가 들어오면 화면 1개가 나가요 | 교환하고 범위 문서의 포함·제외 목록을 그 자리에서 고쳐요 | 5번으로 넘어가요 |
| 5 | 일정이 밀리고 금액이 오르는 걸 감수할 수 있나요? | 범위 확대예요. 별도 견적과 일정 조정을 거쳐 서면으로 합의해요 | 1번으로 돌아가 '꼭 필요한가'를 다시 답해 보세요. 거기서 아니오가 나오면 처음부터 필요한 요청이 아니었어요 |
판정한 뒤에는 요청한 사람에게 결과만 알리지 말고 '어느 목록에 넣었는지'를 같이 알려주세요. 거절이 아니라 위치를 알려주는 대답이라, 같은 요청이 며칠 뒤에 다시 오는 일이 줄어요.
다섯 단계를 다 밟아도 손에 남는 건 A4 한 장이에요. 대신 그 한 장이 있으면 개발사가 상상으로 채울 빈칸이 사라지고, 견적에는 실력과 방식의 차이만 남아요. 비교할 수 있는 견적을 받는다는 건 그런 뜻이에요.
포텐랩은 이 한 장을 같이 만드는 것부터 시작해요. 기능 목록을 받아 금액부터 뽑는 대신, 검증하려는 가설이 무엇이고 이번에 무엇을 빼도 되는지를 먼저 맞춰요. 뺄 것을 같이 찾아줄 사람이 필요하시면 편하게 문의 주세요.