개발 외주 준비 체크리스트 | 발주 전 정리할 7가지

핵심 요약 — 발주 전에 정리할 건 일곱 가지예요. 목적과 성공 기준, 기능 범위, 예산과 일정, 담당자와 결정 권한, 기존 시스템과 데이터, 받을 산출물, 그리고 오픈 이후 계획이에요. 이 일곱 칸을 채우고 나면 여러 곳에서 받은 견적을 같은 기준으로 비교할 수 있게 돼요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“기획서 없이도 견적 나오나요?”

나오긴 해요. 문제는 그 견적이 무엇을 계산한 값인지 나중에 아무도 모른다는 거예요. 업계에서는 외주 분쟁의 상당수가 “나는 이렇게 말했는데 결과물은 저렇게 나왔다”에서 시작한다고 이야기해요. 그 간극이 대부분 착수 전 며칠에서 만들어져요.

오늘은 발주 전에 채워두면 좋은 칸을 한 장으로 정리해볼게요.

---

1. 준비 없이 견적을 받으면 무엇이 어긋날까요

비교할 기준이 안 생겨요.

같은 설명을 세 곳에 보내도 견적은 서로 다른 걸 계산해서 돌아와요. 한 곳은 기획을 포함해 잡고, 한 곳은 개발만 잡고, 한 곳은 디자인을 뺀 값을 보내요. 총액만 보면 마지막 곳이 가장 싸 보이는데 실제로는 가장 적게 포함한 것뿐이에요.

소프트웨어 외주개발 견적을 비교할 때 봐야 할 건 금액이 아니라 어디까지 포함했는가예요. 그런데 그걸 보려면 우리 쪽에서 먼저 범위를 적어둬야 해요. 기준이 없으면 견적서끼리 비교하게 되고, 그러면 항상 싼 쪽이 이겨요.

준비가 부족할 때 실제로 벌어지는 일은 이래요.

• 착수 후에 기능이 하나씩 추가되면서 일정이 밀려요
• 추가된 게 원래 범위였는지 아닌지를 두고 이야기가 길어져요
• 검수 단계에서 “이건 말씀하신 거랑 다른데요”가 나와요

2. 무엇을 왜 만드는지 한 문장으로 적어보셨나요

기능 목록보다 이게 먼저예요.

“예약 앱을 만들어주세요”는 요청이지 목적이 아니에요. 목적은 그 앱으로 무엇이 달라져야 하는가예요. 전화로 받던 예약을 앱으로 옮겨서 응대 시간을 줄이려는 건지, 노쇼를 줄이려는 건지에 따라 만들어야 할 게 달라져요. 앞쪽이면 예약 흐름을 다듬어야 하고 뒤쪽이면 결제와 알림에 손이 더 가요.

이 한 문장이 있으면 개발사가 대안을 제안할 수 있어요. 없으면 시키는 것만 만들게 되고, 그건 발주자 입장에서도 손해예요.

같이 적어두면 좋은 게 하나 더 있어요. 성공 기준이에요. 오픈하고 나서 무엇이 어떻게 되면 잘된 건지를 숫자로 적어보세요. 예약 전화가 절반으로 줄어드는 것인지, 관리자가 매일 쓰던 30분이 사라지는 것인지요. 이게 있으면 검수 기준도 자연스럽게 정해져요.

용어 정리 — 요구사항 정의서(SRS) 무엇을 만들지 항목으로 적은 문서예요. 화면 그림이 아니라 “무엇이 되어야 하는가”를 문장으로 씁니다. 실무에선 이 문서가 견적서의 근거가 되고, 나중에 검수할 때 판정 기준으로도 쓰여요. 자세한 작성 방법은 요구사항 정의서 작성 가이드에 따로 정리해뒀어요.

3. 기능 목록은 어느 수준까지 써야 견적이 맞아질까요

동작이 보이는 수준까지요.

“로그인이 된다”는 문장은 견적을 못 만들어요. 카카오와 네이버 소셜 로그인을 붙이는 것인지, 이메일 가입만 받는 것인지, 중복 가입을 막아야 하는지에 따라 작업량이 몇 배 차이 나거든요. 같은 한 줄인데 안에 든 게 달라요.

이렇게 적어보시면 돼요.

이렇게 적으면 견적이 흔들려요	이렇게 적으면 견적이 좁혀져요
로그인이 된다	카카오·네이버 소셜 로그인, 중복 가입 차단
결제 기능이 있다	카드·간편결제, 부분 취소 가능, 영수증 발급
관리자가 통계를 본다	일·월 단위 매출과 예약 수, 엑셀 내려받기
알림을 보낸다	예약 1시간 전 앱 푸시, 실패 시 문자 재발송

전부 이렇게 쓸 필요는 없어요. 우선순위 상위 열 개 정도만 이 수준으로 적어도 견적 편차가 눈에 띄게 줄어요. 나머지는 “있으면 좋음”으로 따로 묶어두시면 돼요.

운영사 Tip — 저희는 요구사항을 받으면 기능 수보다 그 기능이 출시 후 얼마나 자주 바뀔지를 먼저 봐요. 자주 바뀔 자리는 처음부터 고치기 쉽게 만들어두지 않으면 나중에 수정 비용이 개발비를 넘어서요.

4. 예산과 일정은 미리 알려주면 손해일까요

알려주시는 편이 결과가 좋아요.

예산을 말하면 그 금액에 맞춰 부른다고 걱정하시는 경우가 많아요. 그런데 예산을 모르면 개발사는 범위를 좁힐 수가 없어요. 3천만 원짜리 설계와 8천만 원짜리 설계는 아예 다른 구조로 시작하거든요. 금액을 숨기고 받은 견적은 대체로 예산을 크게 넘거나, 넘지 않으려고 중요한 걸 빼고 계산해서 와요.

범위로 말씀하셔도 충분해요. “이 정도 안에서 가능한 선을 알고 싶어요”면 돼요.

참고할 만한 시장 자료는 이 정도예요. 프로젝트마다 다르니 방향만 잡는 용도로 봐주세요.

공식·시장 공개 자료 기준 (참고용, VAT 별도)

유형	대략 범위
홈페이지(자체 개발·맞춤)	500만～2,000만 원+
모바일 앱(크로스플랫폼)	800만～5,000만 원
매칭·예약 플랫폼	3,000만 원 이상 (규모에 따라 억 단위)
MVP·PoC	500만～3,000만 원

인건비 기준은 한국소프트웨어산업협회(KOSA) 공표 자료를 참고할 수 있어요. 2024년 응용소프트웨어 개발자 월 평균임금이 약 712만 원, IT 프로젝트 관리자가 약 953만 원이에요. 실제 외주 단가는 여기에 관리 비용이 붙어서 결정되니 그대로 대입하시면 안 되고 추정 기준으로만 보세요.

일정도 같이 적어주세요. 특정 날짜에 반드시 열어야 하는 이유가 있다면 그게 설계를 바꿔요. 전시회나 계약 만료처럼 못 미루는 날이 있으면 미리 말씀하시는 게 좋아요.

5. 우리 쪽 담당자와 결정 권한은 정해져 있나요

이 칸이 비어 있으면 일정이 조용히 밀려요.

개발이 시작되면 결정할 게 계속 생겨요. 이 화면을 두 단계로 나눌지, 이 항목을 필수로 받을지 같은 것들이요. 그때 답을 줄 사람이 정해져 있지 않으면 개발사는 기다리게 돼요. 기다리는 동안에도 일정은 흘러가고요.

정해두면 좋은 건 세 가지예요.

• 연락 창구 한 명 — 여러 명이 각자 다른 요청을 보내면 우선순위가 무너져요
• 결정 권한의 범위 — 어디까지 담당자가 정하고, 어디부터 윗선 확인이 필요한지
• 응답 기한 — 질문에 며칠 안에 답할 수 있는지

세 번째를 계약서에 적는 경우도 있어요. 발주자 회신이 늦어서 생긴 지연은 개발사 책임이 아니라는 조항이 들어가기도 하거든요. 서로 공평한 장치라서 넣어두시는 걸 권해요.

6. 지금 쓰는 시스템·데이터·계정은 정리돼 있나요

여기서 막혀서 착수가 미뤄지는 경우가 정말 많아요.

새로 만드는 프로젝트여도 회사에 이미 있는 것과 연결되는 경우가 대부분이에요. 기존 홈페이지, 쓰던 ERP, 결제 대행사 계약, 도메인, 문자 발송 서비스 같은 것들이요. 이게 어디에 있고 누구 이름으로 계약돼 있는지 모르면 개발이 중간에 멈춰요.

착수 전에 확인해두면 좋은 목록이에요.

• 도메인과 서버가 누구 계정으로 되어 있는지
• 기존 데이터를 옮겨야 하는지, 그 데이터를 내려받을 수 있는지
• 결제·문자·지도처럼 외부 서비스를 쓰고 있다면 그 계약자 이름
• 이전 개발사가 있었다면 소스코드와 접근 권한을 받아둘 수 있는지

흔한 실수 — 마지막 항목이 제일 자주 걸려요. 이전 업체와 사이가 나빠진 뒤에 소스코드를 요청하면 시간이 오래 걸리거나 못 받기도 해요. 새 프로젝트를 시작하기 전에 먼저 받아두시는 게 안전해요. 운영을 넘겨받을 수 있는 구조인지 확인하는 방법은 운영 이관 구조 확인법에 자세히 적어뒀어요.

7. 한 장으로 정리한 발주 전 체크리스트

여기까지를 표로 모으면 이렇게 돼요. 그대로 옮겨 적고 칸을 채우시면 돼요.

#	항목	채울 내용	안 채우면 생기는 일
1	목적·성공 기준	이 프로젝트로 무엇이 달라지는가, 숫자로	대안 제안 없이 시킨 것만 만들어져요
2	기능 범위	우선순위 상위 10개를 동작 수준으로	견적 편차가 몇 배로 벌어져요
3	제외 범위	이번엔 안 하는 것	착수 후 범위 다툼이 생겨요
4	예산·일정	범위로 표기, 못 미루는 날짜	예산을 넘는 설계가 와요
5	담당자·권한	창구 1명, 결정 범위, 응답 기한	결정 대기로 일정이 밀려요
6	기존 시스템·계정	도메인·서버·외부 서비스 계약자	착수 후 개발이 멈춰요
7	받을 산출물	소스코드 외에 받을 문서 이름	다른 곳으로 못 옮겨요

일곱 번째 칸을 조금 더 볼게요. 소스코드만 적어두면 나중에 곤란해져요. 업계에서 최소한으로 권하는 산출물은 데이터베이스 구조를 적은 테이블 정의서, API 명세서, 설치 가이드, 운영 매뉴얼 네 가지예요. 이 네 개가 있어야 다른 업체로 옮기거나 직접 운영할 수 있어요.

직접 운영해보니 — 저희는 자체 SaaS 4종을 직접 운영하고 있어서 이 문서들이 없을 때 어떤 일이 생기는지 자주 봐요. 사람이 바뀌면 아무도 그 시스템을 못 건드리게 돼요. 코드는 남아 있는데 어디를 어떻게 고쳐야 하는지 아는 사람이 없는 상태요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하는 이유예요.

이 표에서 채우기 어려운 칸이 있어도 괜찮아요. 오히려 그 칸이 지금 프로젝트의 리스크가 어디 있는지 알려주는 신호예요. 어느 칸부터 정리하는 게 좋을지 같이 짚어드릴게요 →

8. 자주 묻는 질문 (FAQ)

개발 외주 맡기는 절차 5단계는 무엇인가요?

준비, 업체 탐색, 견적·비교, 계약, 착수 순서예요. 첫 단계를 건너뛰면 나머지 네 단계가 전부 흔들려요. 같은 문서를 여러 곳에 보내야 견적을 같은 기준으로 비교할 수 있어요.

개발 외주 계약서 핵심 조항은 무엇인가요?

개발 범위와 산출물, 검수 기준과 기한, 지연 처리, 소스코드와 저작권 귀속, 유지보수 범위, 대금 지급 시점이에요. 발주자가 가장 자주 놓치는 건 산출물 목록이에요. 받을 문서 이름을 하나씩 적어두세요.

개발 외주 유지보수는 어떻게 진행되나요?

무상 하자보수 기간이 끝나면 별도 계약으로 넘어가요. 월 정액이나 연 단위 요율로 잡는 경우가 많고, 장애가 났을 때 몇 시간 안에 대응할지를 함께 정해요. 오픈 직후에 협상하면 선택지가 적어지니 착수 전에 정해두세요.

개발 외주 업체는 어디서 찾고 무엇으로 걸러야 하나요?

개발 외주 플랫폼, 검색, 소개가 흔한 경로예요. 외주 플랫폼을 쓰든 직접 찾든 거르는 기준은 같아요. 비슷한 업종의 예쁜 결과물보다 비슷한 운영 문제를 풀어본 경험을 보세요. 걸러내는 기준은 개발 외주 업체 선택 체크리스트에 항목별로 정리해뒀어요.

9. 마무리 — 채우기 어려운 칸이 신호예요

이 체크리스트의 목적은 문서를 잘 만드는 게 아니에요. 어디가 아직 안 정해졌는지 드러내는 것이에요.

일곱 칸을 채워보시면 대개 한두 칸에서 손이 멈춰요. 그 칸이 지금 프로젝트에서 가장 흔들리는 지점이에요. 그대로 두고 착수하면 그 자리에서 일정이 밀리거나 비용이 늘어요. 반대로 그 칸만 먼저 정리해도 받는 견적의 질이 달라져요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 만들어서 넘기는 일만 해왔다면 이 체크리스트에 산출물이나 계정 이야기는 안 적었을 거예요. 넘겨받고 이어서 운영해본 쪽에서 자주 막히는 자리들이라 넣었어요. 지금 준비 중인 프로젝트에서 어느 칸이 비어 있는지 궁금하시면 편하게 물어보세요 →

관련 글

• 개발 외주 업체 선택 체크리스트 7가지
• 요구사항 정의서, 어디까지 써야 견적이 맞아질까요
• 요구사항 한 줄이 견적을 바꿔요 | 롯데·캐논·코닥 사례