Checklist

외주 개발을 맡기기 전에 확인할 15가지

작성 름랩2026-08-10 발행

외주 개발에서 문제가 생기는 지점은 대부분 "말로만 정한 것"입니다. 아래 15개는 계약 전에 문서로 남겨 두면 이후 논의가 크게 줄어드는 항목이고, 어느 개발사에 맡기든 그대로 쓸 수 있습니다. 항목마다 왜 필요한지와 준비가 없을 때 무엇이 늦어지는지를 함께 적었습니다.

1. 핵심 사용자와 목적

"누가, 무엇을 하러 오는 서비스인가"를 한 문장으로 적어 봅니다. 이 문장이 없으면 기능 목록이 계속 늘어나고 견적도 수렴하지 않습니다. 기획서는 없어도 되지만 이 문장은 있어야 범위 논의가 시작됩니다.

2. 1차 출시에 반드시 필요한 기능

있으면 좋은 기능과 없으면 서비스가 성립하지 않는 기능을 나눕니다. 후자만 1차 범위에 넣습니다. 이 구분이 비용과 기간을 가장 크게 줄입니다.

3. 사용자 역할 수

일반 사용자만 쓰는지, 사업자·운영자처럼 다른 화면을 쓰는 역할이 더 있는지 확인합니다. 역할이 늘면 화면 수가 그대로여도 권한 규칙과 테스트 경우의 수가 함께 늘어납니다. 화면 10개짜리 단일 역할 서비스가 화면 6개인 3역할 서비스보다 빨리 끝나는 일이 흔합니다.

4. 관리자 화면의 범위

관리자는 "있다/없다"가 아니라 범위의 문제입니다. 목록 조회만 되는 것과 권한 분리·승인·정산 집계까지 있는 것은 개발 분량이 다릅니다. 운영을 직접 하실 계획이라면 어떤 화면에서 무엇을 처리할지 견적 단계에서 적어 두세요.

5. 승인·상태 흐름

"신청 즉시 확정"과 "운영자가 승인해야 확정"은 사용자 화면이 비슷해 보여도 뒤쪽 설계가 다릅니다. 상태가 늘면 취소·반려·재신청 같은 예외 처리도 함께 늘어납니다.

로그인이 필요한지, 필요하다면 이메일·휴대폰·소셜 중 무엇을 쓸지 정합니다. 본인인증이 들어가면 별도 계약과 심사가 필요해 일정에 영향을 줍니다.

7. 결제 유무와 방식

단건 결제와 정기결제(구독)는 난이도가 다릅니다. 정기결제는 갱신·해지·환불 흐름과 실패 재시도까지 설계해야 합니다. PG 계약도 별도로 진행해야 하므로 결제를 넣을지부터 확정하세요.

8. 외부 연동 목록

지도, SNS 로그인, 문자·알림톡, 기존 ERP·CRM 등 연동할 대상을 적습니다. 각각 계약·심사·테스트 계정 발급이 필요하고, 이 대기 시간은 개발사가 앞당길 수 없습니다. 착수와 동시에 신청해 두면 전체 일정이 짧아집니다.

9. 알림 채널

푸시·문자·알림톡·이메일 중 무엇을 쓸지 정합니다. 채널마다 발송 비용과 사전 승인 절차가 다르고, 알림톡은 템플릿 심사가 있습니다.

10. 소스코드 이관 조건

이관 여부만이 아니라 "무엇을 이관하는가"를 확인합니다. 코드만 받고 실행·빌드·배포 문서가 없으면 다른 팀이 이어받기 어렵습니다. 이관 시점(중간/종료)과 형태(저장소 이전/압축 파일)도 적어 두세요.

11. 서버·도메인·스토어 계정 명의

개발사 계정에 만들어지면 나중에 서비스를 옮길 때 데이터부터 협상해야 합니다. 가능하면 처음부터 고객 명의로 생성하거나, 종료 시 고객 소유로 이전하는 조건을 계약에 넣는 편이 안전합니다.

12. 앱스토어 심사 일정

앱은 개발이 끝나도 App Store·Google Play 심사를 거쳐야 공개됩니다. 심사 기간과 반려 여부는 플랫폼 정책이라 개발사가 보장할 수 없습니다. 출시일을 못 박아야 한다면 반려 후 재제출까지 감안해 여유를 두세요.

13. 검수 방식과 담당자

누가 어떤 기준으로 확인할지 정합니다. 확인이 늦어지는 구간이 실제로 일정을 가장 자주 미룹니다. 확인 담당자를 한 명으로 정해 두면 이 구간이 눈에 띄게 짧아집니다.

14. 유지보수 조건

무상 대응 기간, 그 이후의 과금 방식, 대응 범위(버그 수정인지 기능 추가인지)를 문서로 확인합니다. 구두 약속은 담당자가 바뀌면 남지 않습니다. 월 고정비가 있는지, 실비만 드는지도 함께 확인하세요.

15. 범위 밖 작업의 처리 절차

개발 중에 새 기능이 필요해지는 일은 흔합니다. 중요한 것은 그때의 절차입니다. 진행 전에 비용과 일정을 안내하고 동의를 받는 구조인지, 작업 후에 청구되는 구조인지를 계약서에서 확인하세요.

위 15개는 어느 개발사에 맡기든 쓰실 수 있는 기준입니다. 참고로 름랩은 계약 범위의 전체 소스코드와 실행·빌드·배포 문서를 프로젝트 종료 시 이관하고, 서버·도메인·스토어 계정은 가능하면 고객 명의로 생성하거나 고객 소유로 이전하는 것을 원칙으로 합니다. 가격은 VAT 포함 정액으로 먼저 공개하며, 계약서에 확정된 범위는 추가 비용 없이 진행하고 범위 밖 기능은 진행 전에 비용과 일정을 안내합니다. 월 관리비는 없고 호스팅·도메인·푸시 발송비 정도만 실비로 발생합니다.

준비 여부에 따라 달라지는 것 — 항목별로 미리 정해 두면 무엇이 빨라지는가
확인 항목	준비되어 있을 때	정해지지 않았을 때
핵심 사용자·목적	첫 상담에서 범위 윤곽이 잡힘	기능 목록이 계속 늘어남
사용자 역할 수	권한 설계를 한 번에 진행	개발 중 화면 구조를 다시 잡게 됨
관리자 범위	견적에 그대로 반영	운영 단계에서 추가 개발이 필요해짐
외부 연동 목록	착수와 동시에 심사 신청	개발이 끝나고 연동 대기가 시작됨
계정 명의	종료 시 그대로 인수	이전 절차와 협조 요청이 필요
범위 밖 처리 절차	추가 요청 시 사전 합의	작업 후 비용 논쟁이 생김

자주 묻는 질문

15개를 다 준비해야 상담을 받을 수 있나요?

아닙니다. 1~2번(핵심 사용자와 필수 기능)만 있어도 상담을 시작할 수 있습니다. 나머지는 상담에서 함께 정리하는 항목이고, 이 목록은 무엇을 정하게 되는지 미리 알기 위한 것입니다.

이 체크리스트를 다른 개발사와의 상담에 써도 되나요?

그렇게 쓰시라고 만든 목록입니다. 특정 업체에 유리한 기준이 아니라, 견적서를 비교할 때 같은 조건으로 맞추기 위한 항목들입니다.

견적서에서 가장 먼저 봐야 할 항목은 무엇인가요?

개발 범위가 목록으로 적혀 있는지입니다. "앱 개발 일체" 같은 문구는 범위가 아니라서, 나중에 무엇이 포함이고 무엇이 추가인지 판단할 근거가 없습니다.

소스코드를 안 주는 곳도 있나요?

조건이 업체마다 다릅니다. 이관 자체를 하지 않는 경우, 별도 비용을 받는 경우, 코드만 주고 배포 문서를 주지 않는 경우가 모두 있습니다. 계약 전에 문서로 확인하시는 것이 좋습니다.