전문 제작업체를 고를 때 보는 5가지 (플랫폼 발주와 비교)
같은 “앱 만들어 주세요” 요청에도, 중개 플랫폼 입찰가와 전문 제작업체 제안가는 크게 벌어지는 경우가 많습니다. 담당자는 자연스럽게 묻습니다. 왜 이렇게 다르죠. 비싼 쪽이 좋은 건가요.
가격 차이만 보면 판단이 흔들립니다. 비교하는 단위가 다르기 때문입니다. 플랫폼 발주는 매칭된 수행 단위의 작업 패키지에 가깝고, 전문 제작 계약은 제품 책임·진행 방식·오픈 이후까지를 포함한 제안인 경우가 많습니다.
이 글은 전문 제작업체를 고를 때 볼 다섯 가지 축을 정리합니다. 플랫폼 발주와 무엇이 다른지도 공정하게 나란히 둡니다. 어느 한쪽이 항상 정답은 아닙니다.

한눈에 보면 이런 차이가 납니다
| 비교 축 | 플랫폼 발주에서 자주 보이는 모습 | 전문 제작 계약에서 기대하는 모습 |
|---|---|---|
| 요구사항 | 게시글·채팅으로 조금씩 변함 | 킥오프·범위 문서·변경 관리 |
| 역할 | 수행하는 사람 중심 | 기획·디자인·개발·운영 역할 명시 |
| 품질 | 포트폴리오·리뷰에 의존 | 시나리오 검수·인수 기준 |
| 책임 | 마일스톤 완료 중심 | 오픈 후 하자·운영 경계 명시 |
| 잘 맞는 과제 | 범위가 명확한 소규모 | 복합·장기 운영 |
전문 업체를 볼 때 다섯 가지
1) 범위를 “페이지 수”로만 세는가, “시나리오”로 말하는가
페이지 수만 세는 제안은 비교하기 쉽습니다. 대신 예외 흐름이 빠지기 쉽습니다. 전문 업체라면 최소한 아래를 질문이나 문서로 다룹니다.
- 사용자가 실제로 하는 핵심 흐름 (가입, 구매, 예약, 문의 등)
- 관리자가 매일 하는 운영 흐름
- 실패·취소·권한 없음 같은 예외
- 1차에 넣을 것과 다음 단계로 미룰 것
플랫폼에서도 잘하는 파트너는 이렇게 일합니다. 다만 그 방식이 기본값인지, 개인 역량에 달린 예외인지를 확인해야 합니다.
2) 역할과 소통 리듬이 보이는가
누가 결정을 받고, 주간 보고는 어떤 형식이며, 디자인 확정 후 개발 중 변경은 어떻게 처리하는지. 전문 조직은 이 리듬이 상품의 일부인 경우가 많습니다. 단건 플랫폼 계약에서는 발주자가 리듬을 만들어야 하는 경우가 많습니다.
확인할 질문 예시는 이렇습니다.
- 창구가 한 사람(또는 한 역할)으로 정해져 있는가
- 의사결정이 늦어지면 일정이 어떻게 공유되는가
- 산출물이 어디에 쌓이는지(이슈, 디자인 툴, 저장소) 계약에 있는가
3) 화면 말고 운영 전제를 말할 수 있는가
포트폴리오가 화려한지보다, 아래를 말로 설명할 수 있는지 봅니다.
- 개발·시험·운영 환경 분리
- 개인정보·권한·결제 처리 원칙
- 로그·백업·모니터링 최소 범위
- 앱 스토어 심사·푸시·인증서 같은 운영 요소
- 인수인계 때 넘기는 목록
“최신 기술” 나열보다, 운영 중 문제가 났을 때 어떤 순서로 보는지 설명하는 편이 실질적입니다.
4) 변경이 생겼을 때 견적이 어떻게 바뀌는가
프로젝트 중 요구는 바뀝니다. 중요한 것은 변경을 막는 일이 아닙니다. 영향과 비용을 투명하게 산정하는 일입니다.
변경 요청 절차, 영향 분석, 일정 재계획이 있어야 합니다. “다 해 드립니다”만 반복하는 제안은 후반에 분쟁 소지가 큽니다.
5) 오픈 이후가 제안서에 있는가
오픈은 시작입니다. 아래가 없으면 총비용 비교가 불완전합니다.
- 무상 하자 범위와 기간
- 유지보수 월 비용에 포함·제외되는 항목
- 기능 추가 시 단가 또는 산정 방식
- 소스·계정 소유와 이관 일정
플랫폼 거래에서도 이 항목을 계약에 넣을 수 있습니다. 다만 기본 화면이 거래 완료 중심이라, 발주자가 항목을 강제하지 않으면 빠지기 쉽습니다.
언제 플랫폼이, 언제 전문 계약이 유리한가
플랫폼이 유리할 수 있는 경우입니다.
- 산출물이 한 장·한 모듈로 명확하다
- 내부에 검수할 사람이 있다
- 실패해도 사업 타격이 제한적이다
- 예산·일정이 실험 수준이다
전문 제작 계약이 유리할 수 있는 경우입니다.
- 결제·회원·재고·예약처럼 상태가 복잡하다
- 앱·웹·관리자를 같이 운영한다
- 오픈 후에도 계속 개선이 전제다
- 내부에서 일정·조율을 맡을 여력이 부족하다
- 보안·개인정보·브랜드 리스크가 크다
가격을 비교하는 올바른 방법
- 같은 범위 문서(시나리오 포함)로 다시 견적을 받는다
- 인수인계·환경·로그·유지보수 포함 여부를 표로 맞춘다
- 내부에서 조율·검수에 쓸 시간을 비용으로 환산해 더한다
- 12개월 총비용(초기+유지+예상 변경)으로 본다
- “가장 싼 1차 견적”이 아니라 “가장 설명 가능한 견적”을 고른다
제안서를 읽을 때 한 번 더 묻는 문장
아래 문장이 근거 없이 반복되면 추가 질문을 합니다.
- “최신 트렌드 기술로 확장성 있게” → 어떤 확장 시나리오인지 구체화
- “완벽한 맞춤” → 1차 범위 경계를 요구
- “무제한 수정” → 기간·범위·응답 시간 숫자를 요구
- “보안 철저” → 권한·로그·개인정보 처리의 실제 항목을 요구
- “빠른 일정” → 범위 축소 목록과 리스크 여유를 요구
좋은 제안서는 자신감과 함께, 못 하는 것·나중으로 미루는 것·발주자가 준비해야 하는 것을 명시합니다. 침묵된 전제가 많을수록 실행 중 비용이 커집니다.
플랫폼 견적서와 전문 제안서를 나란히 둘 때도, 가격 칸보다 “빠진 전제” 칸을 먼저 채우면 비교가 공정해집니다. 영업 미팅 분위기와 실행 품질은 별개입니다. 가능하면 실무 리더가 한 번은 직접 질문에 답하는 자리를 요청해 보세요.
이렇게 준비하면 좋아요
- □ 다섯 가지 축으로 비교표를 만들고 점수를 매긴다
- □ 최저가 한 칸만으로 선정하지 않는다
- □ 오픈 후 하자·유지보수·계정 소유를 같은 표에 넣는다
- □ 내부 조율 시간을 숨은 비용으로 계산한다
- □ 침묵된 전제를 질문 목록으로 남긴다
축 없이 최저가만 고르면, 차액은 보통 내부 야근·긴급 수정·재선정·고객 클레임으로 이전됩니다. 전문 업체가 항상 정답은 아닙니다. 다섯 가지 축을 통과하지 못하는 비싼 제안도 있습니다. 가격이 아니라 축으로 걸러야 합니다.
LB Contents는 앱·홈페이지·쇼핑몰 제작과 운영 구조를 함께 설계합니다. 플랫폼 견적과 전문 제안을 같은 기준으로 비교하고 싶을 때, 요구사항이 완전히 굳기 전 단계부터 상담할 수 있습니다.