외주 개발 맡기기 전 기획 체크리스트 — 견적 요청 전에 정할 13가지

외주 전 기획 체크리스트는 개발사에 견적을 요청하기 전에 범위·화면·예산·검수 기준을 종이로 고정할 때 쓰는 점검표예요.

기획서를 서른 장 쓰라는 말이 아니에요. 견적서를 받기 전에 대표가 직접 정해야 하는 결정 열세 개를 빈칸 없이 채우는 일이에요. 빈칸은 개발사가 가정으로 채우고, 그 가정이 견적 차이와 계약 뒤 범위 조정의 시작점이 돼요.

이 글은 개발 미팅 질문 10개보다 앞 단계예요. 질문을 들고 가기 전에, 견적을 요청하는 문서 자체를 점검하는 글이에요.

외주 전 체크리스트는 왜 견적 요청 전에 채워야 하나요?

견적은 개발사가 상상한 화면의 개수에서 나와요. 같은 아이디어를 말로만 전하면 세 곳이 세 개의 다른 앱을 상상하고, 견적도 세 갈래로 벌어져요. 문서가 같아야 견적 차이가 비교 가능한 차이가 돼요.

계약 뒤에 정하면 늦는 항목도 있어요. 산출물 소유권, 검수 기준, 관리자 화면 범위는 견적서에 없으면 나중에 「그건 별도예요」로 돌아와요. 그때는 이미 일정이 흘러간 뒤예요.

그래서 순서는 하나예요. 체크리스트를 채우고, 같은 문서를 세 곳에 보내고, 그다음에 미팅 질문을 꺼내요. 기획 없이 개발부터 열면 반복되는 패턴은 기획 없이 개발하면 화면을 다시 그립니다에 정리돼 있어요.

견적 요청 전에 정해야 할 13가지는 무엇인가요?

하나씩 확인하고, 답이 있는 항목만 체크하세요. 답이 「나중에」면 체크하지 않은 거예요.

• 되는 일과 안 되는 일 — 이번 1차에서 서비스가 하는 일과, 명확히 안 하는 일을 각각 적었나요. 안 하는 일이 비어 있으면 범위가 고정되지 않아요.
• 화면 목록 — 번호·화면명·목적 한 줄로 화면을 셀 수 있나요. 만드는 절차는 개발 미팅용 화면 목록 만드는 법에 있어요.
• 핵심 흐름 한 줄기 — 이용자가 돈을 내거나 서비스 약속이 성립하는 구간을 화면 순서로 적었나요.
• 역할과 권한 — 이용자·운영자·관리자가 각각 보는 화면과 할 수 있는 일을 나눴나요. 역할이 섞이면 화면 수가 뒤늦게 늘어요.
• 운영·관리자 화면 — 1차에 실제로 만들 관리자 화면과, 당분간 엑셀이나 수작업으로 버틸 구간을 정했나요.
• 예산 범위 — 상한과 하한을 적었나요. 1차 예산과 다음 차 예산을 분리했나요.
• 일정 범위 — 출시 목표일과 양보할 수 있는 폭, 중간 시연을 받을 시점을 정했나요.
• 데이터와 연동 — 결제·로그인·알림·지도처럼 밖에서 빌려 쓰는 서비스와, 이미 있는 데이터를 옮길지 여부를 적었나요.
• 예외와 실패 케이스 — 결제 실패, 빈 목록, 중복 클릭처럼 1차에 반드시 막을 것을 골랐나요. 전부가 아니라 사고로 이어지는 것부터예요.
• 검수 기준 — 무엇을 보면 「완료」로 인정할지 화면 단위로 적었나요. 기준이 없으면 검수는 취향 논쟁이 돼요.
• 산출물 소유권 — 소스코드, 디자인 파일, 도메인·앱스토어·결제 계정의 명의와 인수 방식을 견적 조건에 넣을 건가요.
• 유지보수와 이후 수정 — 출시 뒤 수정을 월 단위로 받을지 건당으로 받을지, 응답 기준을 견적서에 포함하도록 요구할 건가요.
• 결정자 — 범위가 흔들릴 때 누가 최종 결정하는지 한 사람으로 정했나요.

열세 개 중 앞의 다섯은 화면 이야기고, 뒤의 여덟은 돈·시간·책임 이야기예요. 화면만 정리하고 견적을 받으면 뒤의 여덟이 계약 뒤에 나타나요.

체크리스트와 기획서, 화면 목록은 무엇이 다른가요?

이름이 비슷해서 자주 섞여요. 쓰는 시점과 읽는 사람이 달라요.

체크리스트는 결정 문서고, 화면 목록은 그 결정 중 하나를 숫자로 바꾼 종이예요. 개발사를 정한 뒤 넘기는 문서는 개발사에 넘길 기획서 최소 패키지에서 다뤄요.

체크리스트를 채우는 순서는 어떻게 되나요?

열세 개를 위에서부터 채우면 예산에서 막혀요. 화면이 없으면 예산을 정할 근거가 없기 때문이에요. 이 순서를 권해요.

1. 안 하는 일부터 적어요 — 되는 일보다 안 되는 일이 범위를 고정해요. 세 개 이상 적히면 다음으로 가요.
2. 핵심 흐름 한 줄기를 화면 순서로 바꿔요 — 여기서 화면 목록이 나와요. 스무 장을 넘으면 아직 범위가 아니에요.
3. 역할·관리자 화면·연동을 붙여요 — 이용자 화면 뒤에 숨은 관리자 화면과 외부 연동을 세요. 견적이 갈리는 자리가 대부분 여기예요.
4. 예산·일정·검수·소유권·유지보수를 정해요 — 화면 수가 보이면 이 다섯 개를 정할 근거가 생겨요. 견적 조건으로 문서 끝에 붙여요.
5. 같은 문서를 세 곳에 보내요 — 설명은 덧붙이지 않고, 화면 번호별 포함·제외 표시를 요청해요. 비교 방법은 앱 개발 견적이 두 배 벌어지는 이유에 있어요.

다섯 단계가 끝나면 미팅에 질문 10개를 들고 가요. 문서가 먼저고 질문은 그다음이에요.

밸류랩스는 이 체크리스트에서 어디를 맡나요?

밸류랩스는 아이디어를 IA(메뉴·화면 구조표)와 화면설계로 고정한 뒤 눌러보는 견본을 만들어요. 열세 개 중 화면 쪽 다섯 개가 우리가 맡는 자리예요.

• 아이디어 인터뷰 — 질문에 답하는 동안 되는 일·안 되는 일과 핵심 흐름 한 줄기가 문장으로 남아요.
• IA — 이용자·운영자·관리자 역할별 메뉴와 화면 구조가 표로 나와요. 관리자 화면이 몇 장인지 여기서 보여요.
• 화면설계 — 화면 목록이 그림이 되고, 빈 화면·실패 같은 예외 상태가 어디 필요한지 드러나요.
• 눌러보는 견본 — 개발사가 말이 아니라 같은 화면을 보고 견적을 내게 돼요.

예산·일정·소유권·유지보수·결정자는 대표가 정하는 일이에요. 우리는 화면 수를 먼저 보이게 해서 그 결정에 근거를 만들어요. 계약서 문구나 법률 판단은 이 글과 우리 범위 밖이에요.

자주 묻는 질문

기획서가 없는데 체크리스트만으로 견적을 받을 수 있나요?

받을 수 있어요. 열세 개가 채워진 문서와 화면 목록 한 장이면 개발사는 가정 없이 견적을 내요. 서른 장짜리 기획서는 개발사를 정한 뒤 필요해요.

열세 개를 다 채우지 못하면 어떻게 하나요?

빈칸을 그대로 두고 보내지 마세요. 「미정」이라고 적고, 그 항목은 견적에서 제외하거나 별도 조건으로 표시해 달라고 요청하세요. 빈칸은 가정으로 채워지고, 미정은 조건으로 남아요.

개발사가 기획도 해 준다는데 이 체크리스트가 필요한가요?

필요해요. 개발사가 기획을 맡아도 안 하는 일, 예산 범위, 소유권, 결정자는 대표만 정할 수 있어요. 이 네 개가 없는 기획은 개발사 기준으로 범위가 정해져요.

열세 개 중 화면 쪽 다섯 개가 막히면 상담에서 범위를 같이 봐요. 혼자 먼저 채워 보고 싶으면 아이디어 인터뷰에서 되는 일·안 되는 일과 핵심 흐름부터 문장으로 남겨 보세요. 아이디어 한 줄이면 시작돼요.

이 글은 밸류랩스가 2026년 9월 15일에 쓴 점검표예요. 범위는 앱·웹 서비스 1차 개발을 외주로 맡기기 전 준비까지이고, 특정 고객 사례나 비용 수치는 담지 않았어요. 계약서 문구와 법률 조언은 다루지 않아요.