앱·웹 외주 개발 맡기기 전 꼭 알아야 할 것 — 요구사항 정리부터 견적서·계약서 보는 법까지

"이 정도 앱 만드는 데 얼마나 들어요?" 외주 개발 상담에서 가장 먼저 듣는 질문입니다. 그런데 이 질문에 바로 정확한 답을 드릴 수 있는 개발자는 없습니다. 무엇을 만들지가 정해지지 않았기 때문입니다.

외주 개발이 실패하는 가장 흔한 이유는 개발 실력이 아니라 처음에 서로 생각한 것이 달랐기 때문입니다. 이 글에서는 22년 동안 여러 프로젝트를 수행하며 본 경험을 바탕으로, 외주를 맡기기 전에 준비할 것과 견적서·계약서에서 확인할 것을 정리했습니다.

1. MVP부터 생각하세요: "꼭 필요한 것 3가지"

MVP(Minimum Viable Product)는 아이디어를 검증할 수 있는 최소한의 제품입니다. 처음부터 모든 기능을 넣으면 비용과 기간이 몇 배로 늘어나고, 정작 고객이 원하는 것이 무엇인지 확인하기도 전에 예산이 바닥납니다.

외주를 맡기기 전에 이 질문에 답해 보세요.

• 이 서비스를 쓰는 사람은 누구인가요?
• 그 사람이 겪는 가장 큰 불편은 무엇인가요?
• 그 불편을 해결하는 데 꼭 필요한 기능 3가지는 무엇인가요?

나머지 기능은 "다음 단계" 목록으로 따로 적어 두세요. 첫 버전을 써 본 고객의 반응을 보고 우선순위를 정하는 것이 훨씬 효율적입니다.

2. 요구사항 문서, 이렇게 쓰면 충분합니다

거창한 기획서는 필요 없습니다. 아래 항목을 한두 장으로 정리하면 견적의 정확도가 크게 올라갑니다.

항목	예시
목적	동네 학원의 수강 신청과 결제를 온라인으로 받기
사용자 종류	학부모, 원장(관리자)
핵심 기능	수업 목록 보기, 신청·결제, 관리자 신청 현황 확인
이번에 안 하는 것	출결 관리, 앱 푸시 알림
참고 서비스	"○○ 앱의 신청 화면처럼" + 화면 캡처
기기	휴대폰 웹 우선, 앱은 나중에
희망 일정·예산	3개월 이내, ○○만 원 내외

특히 "이번에 안 하는 것" 을 적는 것이 중요합니다. 범위 밖의 일을 미리 정해 두면, 진행 중에 "이것도 당연히 되는 줄 알았다"는 갈등을 크게 줄일 수 있습니다.

3. 견적서에서 꼭 확인할 7가지

견적서는 금액만 비교하면 안 됩니다. 같은 금액이라도 무엇이 포함되었는지에 따라 실제 비용은 크게 달라집니다.

1. 기능별로 나뉘어 있나요? "앱 개발 일식 ○○원"보다 기능별 금액이 적힌 견적이 나중에 범위를 조정하기 쉽습니다.
2. 디자인이 포함되었나요? 화면 디자인을 별도로 맡겨야 하는지 확인하세요.
3. 서버·도메인·외부 서비스 비용은 누가 내나요? 운영 비용은 대부분 매달 발생하며 보통 의뢰인 부담입니다. 대략 얼마인지 물어보세요.
4. 검수 기간과 수정 횟수는? 납품 후 며칠 동안, 어디까지 수정해 주는지 확인하세요.
5. 하자보수 기간은? 납품 후 발견된 버그를 무상으로 고쳐 주는 기간입니다.
6. 소스코드와 권리는 누구에게 가나요? 잔금을 치르면 소스코드 전체를 받을 수 있는지 반드시 확인하세요.
7. 유지보수는 별도인가요? 기능 추가나 운영 지원 비용이 어떻게 책정되는지 미리 알아 두세요.

너무 싼 견적은 대부분 이유가 있습니다. 범위가 빠져 있거나, 기존 템플릿을 그대로 쓰거나, 납품 후 지원이 없는 경우가 많습니다. 금액만 보지 말고 위 항목을 함께 비교하세요.

4. 계약서에 반드시 들어가야 할 조항

말로 한 약속은 기억이 서로 다릅니다. 계약서에는 최소한 다음 내용이 들어가야 합니다.

• 과업 범위: 요구사항 문서나 견적서를 계약서에 첨부
• 일정: 주요 단계별 일정과 최종 납품일
• 대금 지급 조건: 착수금·중도금·잔금의 비율과 시점
• 검수 기준과 기간: 무엇이 되면 "완료"로 볼지
• 하자보수: 무상 수정 기간과 범위
• 지식재산권: 결과물과 소스코드의 소유권
• 비밀유지: 프로젝트 중 알게 된 정보의 보호
• 계약 해지: 중간에 그만둘 때의 정산 방법

정부가 공개한 소프트웨어 표준계약서를 참고하면 빠뜨리기 쉬운 조항을 확인할 수 있습니다. 요즘은 전자계약 서비스로 온라인에서 바로 서명하고 서명 이력까지 보관할 수 있어 편리합니다.

5. 진행 중에는 "자주, 작게" 확인하세요

계약이 끝났다고 결과물이 나올 때까지 기다리기만 하면 위험합니다.

• 1~2주마다 동작하는 화면을 직접 보세요. 문서나 말보다 실제 화면이 훨씬 정확합니다.
• 변경 요청은 글로 남기세요. 메신저 대화도 괜찮습니다. 나중에 범위와 비용을 조정할 때 근거가 됩니다.
• 결정은 빠르게 내려 주세요. 의뢰인의 답이 늦어지면 일정도 함께 늦어집니다.

6. 좋은 외주 개발자를 알아보는 신호

• 기능을 무조건 "다 됩니다"라고 하기보다, 더 간단한 방법을 제안합니다.
• 질문이 많습니다. 질문은 요구사항을 정확히 이해하려는 노력입니다.
• 견적과 일정의 근거를 설명할 수 있습니다.
• 납품 후의 운영과 유지보수까지 이야기합니다.

마치며

외주 개발은 결국 신뢰를 쌓아 가는 과정입니다. 의뢰인은 원하는 것을 분명히 정리하고, 개발자는 할 수 있는 것과 없는 것을 솔직하게 말할 때 좋은 결과가 나옵니다.

Springuptech는 요구사항 정리부터 함께합니다. 아직 아이디어 단계라도 괜찮습니다. 무엇이 가능하고, 얼마나 걸리고, 어디서부터 시작하면 좋을지 같이 정리해 드리겠습니다.