본문으로 건너뛰기
샐링잇 Sailing-it

외주 견적서 항목 보는 법: 화면·기능·인프라·외부 비용 분리하기

총액형 견적서는 협상도 변경도 어렵습니다. 좋은 견적서는 화면·기능·인프라·외부 비용을 행으로 분리해 보여줍니다. 외주 견적서에서 꼭 확인할 4가지 분리 축과 받자마자 5분 안에 점검할 체크리스트까지 정리해드립니다.

약 8분 분량

지난주 미팅에서 발주사 분이 두 회사 견적서를 펼쳐놓고 이렇게 물어보셨습니다. “한쪽은 4,500만 원, 한쪽은 6,800만 원인데 같은 기능을 만들어준다고 하네요. 어디가 맞는 가격입니까?”

답은 간단합니다. 한 줄짜리 견적서끼리는 비교가 불가능합니다. 항목이 분해되어 있어야 같은 기능을 같은 단위로 비교할 수 있고, 어디서 줄이고 어디서 늘릴지 협상이 가능합니다.

오늘은 외주 견적서를 받으셨을 때 어떻게 봐야 하는지를 정리해드립니다. 견적서를 4가지 축(화면·기능·인프라·외부 비용)으로 분리해 읽는 법, 좋은 견적서와 위험한 견적서의 차이, 받자마자 5분 안에 점검할 4가지 항목까지 다룹니다. WBS란 무엇인가 글을 먼저 읽어두시면 흐름이 더 잘 보이실 겁니다.

총액형 견적서가 위험한 3가지 이유

“총 5,000만 원, 일정 4개월” 한 줄로 끝나는 견적서를 받으셨다면 다음 세 가지를 의심해보십시오.

첫째, 협상이 불가능합니다. 예산을 줄여야 할 때 “SNS 로그인을 빼면 얼마가 줄어듭니까?” 같은 질문에 답을 받을 수 없습니다. 분해가 없으니 계산도 없습니다.

둘째, 변경의 영향이 측정되지 않습니다. 개발 중 기능 하나를 추가하면 견적이 얼마나 늘어나야 하는지 기준선이 없습니다. 결국 “그건 추가 비용입니다”와 “그건 원래 있던 거 아닌가요” 의 다툼으로 흘러갑니다.

셋째, 진행률이 보이지 않습니다. 4개월짜리 프로젝트에서 한 달이 지났을 때 25%가 진행됐는지, 50%가 진행됐는지 발주사 분이 직접 확인할 방법이 없습니다.

이 세 가지를 모두 해결하는 한 가지 방법은 견적서를 4개 축으로 분리해 받는 것입니다.

좋은 견적서의 4가지 분리 축

좋은 견적서는 작업을 다음 네 가지 축으로 행이 나뉘어 있습니다. 각 축은 단가 계산 구조가 다르기 때문에 섞어서 보면 비교도, 협상도 불가능합니다.

1. 화면 단가 (디자인 + 프론트 구현)

화면은 디자인 시안 1장과 그 시안을 실제로 동작하게 만든 프론트엔드 구현 공수가 합쳐진 단위입니다. 보통 “회원가입 화면”, “상품 목록 화면”, “결제 화면” 식으로 행이 나뉩니다.

화면 단가는 디자인 0.51.5MD + 프론트 1.03.0MD 정도가 일반적인 범위입니다(난이도와 인터랙션 양에 따라 변동). 견적서에 디자인과 프론트가 같은 행에 묶여 있다면 분리해 달라고 요청하시는 편이 좋습니다. 디자인만 외주를 분리하거나, 시안 단계에서 한 번 끊고 보는 방식이 가능해지기 때문입니다.

2. 기능 단가 (백엔드 API + 비즈니스 로직)

기능은 화면 뒤에서 동작하는 서버 로직입니다. “회원가입 이메일 API”, “상품 검색 API”, “주문 생성 API” 식으로 행이 나뉩니다. 같은 “회원가입” 안에서도 이메일 가입과 카카오 로그인은 서로 다른 행으로 분리되어야 합니다.

기능 단가는 보통 백엔드 1.05.0MD 범위가 일반적입니다. 결제·정산·환불 같은 트랜잭션이 들어가는 기능은 단순 CRUD보다 23배 무겁다고 보시면 됩니다. 견적서에 “회원 관련 기능 일체”처럼 묶음으로 표기되어 있다면, 그 안에 어떤 API가 몇 개 들어가는지 풀어 달라고 요청하시는 편이 안전합니다.

3. 인프라 단가 (구축 + 월 운영비, 분리 표기)

인프라는 AWS·Supabase·도메인·CDN 같은 서버 비용입니다. 견적서에서 가장 자주 빠지거나 묶음으로 처리되는 항목이라 주의해서 보셔야 합니다.

인프라는 반드시 두 가지로 나누어 받으십시오. 하나는 초기 구축 공수(EC2/RDS/S3 세팅, CI/CD 파이프라인, 모니터링 알림 등) 이고, 다른 하나는 월 운영비(서버·DB·스토리지·트래픽 사용료) 입니다. 초기 구축은 일회성이라 견적서에 포함되지만, 월 운영비는 런칭 후 발주사가 매달 결제하기 때문에 견적서에는 안내 단가로만 적습니다.

특히 월 운영비가 견적서에 한 줄도 없으면 위험 신호입니다. 런칭 후에 “이 부분은 별도 비용인 줄 몰랐는데요”가 시작될 가능성이 큽니다.

4. 외부 비용 (라이선스·사용료, 견적 외 항목)

본인인증(PASS·NICE·KCP·토스), 결제 PG, 지도(Mapbox·Google Maps), OCR, 푸시(FCM), SMS, OpenAI API 같은 외부 서비스 사용료입니다. 라이선스비, 심사 기간, 월 사용료가 각각 다르기 때문에 견적서에 별도 행으로 표기되어야 합니다.

외부 비용은 견적 금액에 포함하지 않고 “발주사 직접 가입·결제, 외주사는 연동 공수만 청구” 식으로 분리하는 편이 표준입니다. 외주사 명의로 묶이면 정산·운영 인수 시점에 문제가 생깁니다.

견적서에서 외부 비용이 빠져 있다면 두 가지 중 하나입니다. 하나는 해당 기능이 견적에서 누락된 경우, 다른 하나는 외주사 명의로 묶여 들어간 경우. 어느 쪽이든 발주사 분이 직접 확인하시는 편이 좋습니다.

나쁜 견적서와 좋은 견적서 비교

같은 “회원가입 + 상품 검색 + 결제” 기능을 두 가지 형식으로 보면 차이가 분명합니다.

나쁜 예시

1. 회원가입 기능 일체      — 500만 원
2. 상품 검색 기능 일체      — 700만 원
3. 결제 기능 일체            — 1,200만 원
4. 디자인·인프라 등 기타  — 1,500만 원
                  합계 — 3,900만 원

이 견적서를 받으셨다면 다음 질문에 어느 하나 답하실 수 있는지 확인해보십시오.

“본인인증을 NICE에서 PASS로 바꾸면 얼마가 늘어납니까?” “SNS 로그인을 빼면 며칠 줄어듭니까?” “결제 환불 기능이 1,200만 원 안에 포함되어 있습니까?” “런칭 후 AWS 비용은 매달 얼마가 나옵니까?”

네 가지 모두 답을 받을 수 없습니다. 분해가 없으니 협상도, 변경도, 운영비 예측도 불가능합니다.

좋은 예시

같은 기능을 4가지 축으로 분리하면 다음과 같이 보입니다(숫자는 예시).

[화면]
1.1 회원가입 화면 (디자인 1.0 + 프론트 2.0MD)
1.2 상품 목록 화면 (디자인 1.5 + 프론트 3.0MD)
1.3 결제 화면 (디자인 1.0 + 프론트 2.5MD)

[기능]
2.1 회원가입 - 이메일 API (백 1.5MD)
2.2 회원가입 - SNS 로그인 (백 2.0MD)
2.3 상품 검색 API (백 3.0MD)
2.4 결제 - 주문 생성 API (백 2.5MD)
2.5 결제 - 환불 API (백 1.5MD)

[인프라]
3.1 AWS 초기 구축 (EC2/RDS/S3) (서버 3.0MD)
3.2 CI/CD 파이프라인 구축 (서버 1.5MD)
3.3 월 운영비 안내 — 약 25~40만 원/월 (트래픽 기준)

[외부 비용 — 발주사 직접 결제]
4.1 본인인증 NICE — 가입비 33만 원 + 건당 50원
4.2 결제 PG 토스 — 가입비 0원, 카드 수수료 2.9%
4.3 연동 공수만 청구 — 백 1.0MD

이 견적서에서는 위 네 가지 질문에 즉시 답을 받을 수 있습니다. 본인인증 교체는 4.1 행의 가입비 차이로, SNS 로그인 제외는 2.2 행의 2.0MD × 단가로, 환불 기능 포함 여부는 2.5 행으로, AWS 월 운영비는 3.3 행으로 모두 보입니다. 좋은 견적서는 협상의 도구입니다.

샐링잇 견적서가 어떤 컬럼 구조로 만들어지는지는 WBS란 무엇인가 글에서 양식 사진과 함께 자세히 다루어 두었습니다.

변경관리 절차 — 견적서가 살아있게 만드는 한 가지 장치

견적서를 4축으로 분리해 받으셨다면 그다음으로 확인하실 것은 변경관리 절차입니다. 외주 분쟁의 80% 이상이 이 절차의 부재에서 발생합니다.

저희가 모든 프로젝트에 명문화해두는 절차는 5단계입니다.

  1. 변경 요청: 발주사가 신규 요구사항을 문서·메신저로 명시 요청.
  2. 영향도 회신: 외주사가 영향받는 WBS 행과 공수·일정·비용 증감을 48시간 내 회신.
  3. 발주사 승인: 견적·일정 변경을 발주사 분이 서면(메신저 포함) 으로 승인.
  4. 신규 행 추가: 기존 행을 수정하지 않고 신규 행으로 WBS에 추가, 추가 일자·요청자 기록.
  5. 회고 반영: 다음 데모에서 변경 결과 확인, 누락 시 재계산.

이 다섯 줄이 계약서 또는 견적서 부속 문서에 들어가 있어야 합니다. 빠져 있다면 계약 전에 한 단락이라도 추가해 달라고 요청하시기를 권합니다. 변경관리는 견적서를 살아있게 만드는 한 가지 장치입니다.

받자마자 5분 안에 점검할 4가지

외주사로부터 견적서를 받으셨다면, 다음 네 가지를 차분히 점검해보십시오.

첫째, 화면·기능·인프라·외부 비용이 행으로 분리되어 있는지 확인하십시오. 한 묶음으로 표기되어 있다면 분리 요청부터 시작해야 합니다. 분리가 안 되면 비교도 협상도 어렵습니다.

둘째, 인프라 항목에 월 운영비 안내가 있는지 확인하십시오. 초기 구축비만 있고 월 운영비가 빠져 있다면 런칭 후 예상 못 한 비용이 등장할 가능성이 큽니다.

셋째, 외부 비용이 발주사 명의로 분리되어 있는지 확인하십시오. 외주사 명의에 묶여 있으면 정산·인수 시점에 문제가 됩니다.

넷째, 변경관리 절차가 명문화되어 있는지 확인하십시오. 견적서 또는 별도 문서에 5단계가 5줄 정도 들어가 있으면 충분합니다. 빠져 있다면 계약 전에 추가해 달라고 요청하십시오.

이 네 가지가 모두 통과한 견적서라면 비교·협상·변경 추적이 가능한 견적서입니다. 외주를 처음 맡기시는 분이라면 IT 외주 맡기기 전에 꼭 확인해야 할 7가지 글을 함께 보시면 계약 전 점검이 더 촘촘해집니다.

마지막으로

견적서는 외주의 첫 산출물입니다. 한 줄짜리 견적서는 합의가 아니라 일종의 추정치이고, 분해된 견적서는 변경이 발생해도 즉시 계산이 가능한 약속입니다. 시작할 때 견적과 끝날 때 비용이 같아야 외주입니다. 그 ‘같음’을 보장해주는 종이 한 장이 4축으로 분리된 견적서 + 변경관리 5단계입니다.

샐링잇은 모든 프로젝트에서 화면·기능·인프라·외부 비용을 분리한 WBS 견적서로 시작합니다. 견적서가 어떻게 작성되는지 직접 보고 싶으시다면 무료 견적 받아보기에서 요청해주십시오. 다음 글에서는 외주 분쟁의 80% 가 어디서 발생하는지, 변경관리 5단계를 어떻게 운영하는지 더 깊게 풀어드릴 예정입니다.