스타트업이나 비IT 기업에서 처음으로 개발 외주를 맡길 때, 많은 팀이 비슷한 문장으로 시작합니다. “대략 이런 서비스 만들고 싶은데, 얼마나 들까요?” 그 질문 자체는 잘못된 것이 아니지만, 답을 좁히려면 의뢰하는 쪽에서도 최소한의 ‘틀’이 있어야 합니다. 이 글은 특정 업체를 추천하거나 홍보하는 목적이 아니라, 의뢰자 입장에서 검색하며 찾을 만한 내용을 정리한 것입니다.
왜 “감으로만” 말하면 견적이 제각각인가
개발사는 같은 단어를 들어도 포함 범위를 다르게 해석할 수 있습니다. 예를 들어 “회원가입”이란 말만으로는:
- 이메일만 받을지, 휴대폰 본인인증까지 할지
- 소셜 로그인을 넣을지
- 관리자에서 회원을 직접 만들 수 있게 할지
까지 범위가 갈립니다. 범위가 열린 상태면 견적은 서로 다른 가정 위에 올라가고, 나중에 “추가 비용”이라는 말이 나오기 쉽습니다. 이는 나쁜 의도라기보다, 처음부터 경계가 명확하지 않았기 때문인 경우가 많습니다.
기술 문서가 없어도, 이렇게만 정리해 두면 좋다
전문적인 기술 명세서가 없어도 됩니다. 다만 아래는 있을수록 좋습니다.
1. 누가, 무엇을, 왜 쓰는지 한 페이지
- 주 사용자 (예: B2C 20대, 사내 직원만, 관리자 등)
- 핵심 행동 (예: “결제까지”, “문의만 받고”, “데이터 조회만”)
- 왜 지금 만들어야 하는지 (비즈니스 맥락 한두 문장)
이걸로 “우리가 진짜로 필요한 최소 기능”을 나중에 되돌아볼 기준이 생깁니다.
2. 꼭 있어야 하는 것 vs 나중에 해도 되는 것
- Must-have: 런칭 전에 없으면 서비스가 성립하지 않는 것
- Nice-to-have: 있으면 좋지만, 없어도 첫 버전은 나가는 것
처음엔 나누기 어렵다면, “절대 빼면 안 되는 것 세 가지”만 적어도 도움이 됩니다.
3. 연동·제약이 있으면 미리
- 반드시 써야 하는 결제·PG, 이미 쓰는 SaaS (CRM, 메일 등)
- 법·규제 (개인정보, 특정 업종의 인증)
- 호스팅·도메인이 이미 있는지
나중에 “이건 연동할 줄 몰랐다”는 이슈는 비용과 일정을 가장 흔하게 흔듭니다.
4. 일정·예산의 ‘형태’
“빨리”가 아니라 목표 날짜가 있으면 (예: 행사 전, 세금 계산 시즌 등) 그 이유와 함께 알려 주는 것이 좋습니다. 예산은 상한을 숨기지 않고 범위를 맞추는 방식도 있고, 역으로 기능을 줄여 맞추는 방식도 있습니다. 숫자 공개가 부담스러우면 “이번 단계에서 쓸 수 있는 개발 예산의 대략적인 구간”만이라도 의사결정에 도움이 됩니다.
의뢰자가 준비하면 좋은 ‘참고 자료’
- 경쟁사·유사 서비스 링크와 “이 부분은 우리와 비슷하면 좋겠다”는 설명
- 손으로 그린 스케치·플로우 메모도 충분히 유효합니다
- 이미 있는 브랜드 가이드·로고·문구 톤
완성된 기획서가 아니어도, 의도를 줄이는 데는 큰 도움이 됩니다.
정리하면
개발 외주는 견적서에 적힌 문장과 실제로 만들어야 할 것이 최대한 겹치도록, 처음부터 말로만이 아니라 범위와 우선순위를 짧게라도 글로 남기는 것이 유리합니다. 이는 “개발사를 잘 고르는 기술”만큼이나, 의뢰하는 쪽의 준비를 말하는 것입니다.
이미 비슷한 주제로 비용·시장·가이드 글을 쓴 적이 있습니다. 이 글은 그 중에서도 처음 의뢰할 때의 요구사항 스코프에만 초점을 맞춘 편이라, 검색해서 들어온 분이 자신의 상황에 맞는지 판단하기 쉽게 쓰려 했습니다.
다음에 다루면 좋을 주제: 외주 계약·유지보수 범위를 나누는 기준, 실제 협업 시 주간/스프린트 회의에서 무엇을 맞추면 좋은지 등.