견적서 작성법 양식 — PM이 알아야 할 가격 설계와 협상 실전

1. 견적서는 숫자가 아니라 논리다

Created by Copilot

 

견적서 작성법이나 양식, 견적 협상이 막막해서 검색해서 들어오셨다면 잘 찾으셨다. 문제는 대부분 계산이 틀린 게 아니라 논리가 없기 때문이다. 원가, 시장, 클라이언트 예산 — 세 가지를 동시에 보는 견적 설계법과 협상 테이블에서 절대 양보하면 안 되는 것들을 실무 기준으로 정리했다.

 

많은 PD/PM이 견적서를 "비용 합산표"로 만든다. 인건비 얼마, 외주 얼마, 장비 얼마 — 이것들을 더해서 총액을 적는 방식이다. 문제는 클라이언트가 그 숫자를 보고 "왜 이렇게 비싸냐"는 질문을 던지는 순간, 설명할 논리가 없다는 것이다.

 

견적서는 숫자보다 논리가 먼저다: 이 프로젝트에 왜 이 비용이 필요한지를 납득시키는 문서가 되어야 한다. 숫자는 그 논리의 결과물이다.

 

범위 정의가 먼저다: 견적서를 쓰기 전에 프로젝트의 범위를 명확히 정의해야 한다. 자동차 컨피규레이터 프로젝트라면 색상 옵션이 몇 가지인지, 플랫폼이 WebGL인지 클라우드 스트리밍인지, 납품 포맷이 무엇인지 — 이것들이 확정되지 않은 상태에서 숫자를 적으면 나중에 반드시 문제가 생긴다.

 

가정을 명시하라: 견적서에는 반드시 "이 견적은 다음 조건을 가정합니다"라는 항목이 있어야 한다. 3D 에셋은 클라이언트가 제공, 수정 횟수는 3회, 납기는 12주 — 이런 가정들이 명시되어야 나중에 범위가 바뀌었을 때 추가 견적을 요청할 근거가 생긴다. 필자가 초반에 가장 많이 한 실수가 바로 이 가정을 빠뜨린 것이었다.

 

 

2. 숫자를 설계하는 방법

​Created by Gemini - Nano Banana 2

 

견적의 숫자는 세 가지 방향에서 동시에 검증해야 한다.

 

원가 기반: 실제로 드는 비용을 먼저 계산한다. 내부 인건비, 외주 업체 비용, 소프트웨어 라이선스, 서버 비용, 예비비 — 이것들을 합산한 후 목표 마진을 더한 것이 최소 견적이다. 이 숫자 아래로 내려가면 프로젝트를 할수록 손해다.

 

시장 기반: 비슷한 규모와 스펙의 프로젝트가 시장에서 어느 정도에 수주되는지를 파악해야 한다. 우리 숫자가 시장 평균보다 현저히 높으면 이유를 설명할 수 있어야 하고, 현저히 낮으면 오히려 품질에 대한 의심을 살 수 있다. 필자가 경험한 바로는 지나치게 낮은 견적이 클라이언트의 신뢰를 오히려 떨어뜨린 경우가 있었다.

 

클라이언트 예산 기반: 사전 미팅에서 예산 범위를 파악했다면 그것을 반영한다. 클라이언트의 예산이 우리 원가보다 낮으면 범위를 줄이거나 방식을 바꿔서 맞추는 방법을 제안해야 한다. 예산을 무시하고 우리 기준으로만 견적을 쓰면 미팅 테이블에 올라가지도 못한다.

 

 

3. 견적서의 구조 — 클라이언트가 읽는 방식으로

Created by Copilot

​​

견적서도 제안서처럼 읽히는 순서가 있다. 클라이언트는 대부분 총액을 먼저 보고, 그 다음 세부 항목을 본다. 이 순서를 알고 구성해야 한다.

 

요약 페이지: 첫 페이지에는 프로젝트 개요, 범위 요약, 총액만 담는다. 의사결정권자는 이 페이지만 보는 경우가 많다.

 

세부 항목 페이지: 각 항목이 왜 필요한지 한 줄 설명과 함께 비용을 적는다. "Unreal Engine 개발 — 실시간 렌더링 파이프라인 구축 및 인터랙션 구현"처럼 항목명만 있는 것보다 이유가 한 줄 붙어있으면 훨씬 설득력이 높아진다.

 

조건 및 가정 페이지: 앞서 말한 가정들을 명시한다. 이 페이지가 나중에 추가 견적의 법적 근거가 된다. 실제로 필자의 팀은 이 페이지 덕분에 대형 OEM 프로젝트에서 범위 변경에 따른 추가 수주를 만들어낸 경험이 있다.

 

 

4. 가격 협상에서 양보하는 법

​Created by Gemini - Nano Banana 2

 

견적을 제출하면 대부분 가격 협상이 온다. "좀 깎아줄 수 없냐"는 요청은 거의 항상 온다고 봐야 한다. 이때 어떻게 대응하느냐가 중요하다.

 

숫자를 낮추기 전에 범위를 줄여라: "가격을 낮추려면 이 항목을 빼야 합니다"라는 방식으로 대응해야 한다. 그냥 숫자를 깎으면 같은 일을 더 싸게 하는 것이고, 결국 품질이 떨어지거나 수익이 줄어든다. 범위를 줄이면 논리적으로 가격이 낮아지는 것이고, 나중에 클라이언트가 빠진 항목을 다시 요청할 때 추가 수주의 기회가 생긴다.

 

양보할 수 있는 항목을 미리 준비해라: 처음 견적을 쓸 때 협상 여지가 있는 항목을 의도적으로 하나 정도 넣어두는 것도 전략이다. 협상 테이블에서 그 항목을 빼주면 클라이언트는 협상에서 이겼다는 만족감을 느끼고, 우리는 원하는 마진을 지킨다.

 

 

5. 리얼타임 콘텐츠 견적의 특수성

Created by Copilot

 

일반 영상 제작 견적과 리얼타임 콘텐츠 견적은 구조가 다르다. 이 차이를 이해하지 못하면 클라이언트와의 기대 불일치가 생긴다.

 

기술 스택에 따른 비용 차이: WebGL 기반 컨피규레이터와 Unreal Engine 기반 클라우드 스트리밍 컨피규레이터는 개발 비용이 수배 차이가 날 수 있다. 클라이언트가 "비슷한 거 아닌가요?"라고 물어올 때 그 차이를 명확하게 설명할 수 있어야 한다.

 

유지보수 비용을 반드시 포함하라: 리얼타임 콘텐츠는 한 번 납품하고 끝이 아니다. Unreal Engine 업데이트, 서버 유지, 신차 모델 에셋 교체 — 이런 것들이 지속적으로 발생한다. 초기 견적에 유지보수 비용을 함께 제안하면 장기 계약으로 이어지는 경우가 많다. 필자가 속한 팀의 장기 클라이언트 중 상당수는 이 방식으로 관계가 시작됐다.

 

보안 관련 비용: 자동차 OEM 프로젝트는 보안 요구사항이 높다. 별도 보안 서버, NDA 관리, 에셋 접근 권한 관리 — 이런 항목들이 견적에 반영되어야 한다. 보안 비용을 빠뜨리면 나중에 클라이언트 요청으로 추가할 때 마찰이 생긴다.

 

 

결론

Created by Grok

 

견적서는 숫자를 적는 문서가 아니라 신뢰를 설계하는 문서다. 논리가 명확한 견적서는 가격 협상에서도 흔들리지 않고, 프로젝트가 시작된 후에도 범위 분쟁을 막아준다. 원가, 시장, 클라이언트 예산 — 세 가지를 동시에 보는 눈을 갖추는 것이 견적의 시작이다.

 

 

 

---

 

 

다음 강에서는 대부분의 PD/PM이 가장 긴장하는 순간을 다룬다. 계약서를 앞에 두고 협상 테이블에 앉았을 때 — 무엇을 반드시 확인해야 하고, 어디서 양보하면 안 되는지를 짚는다.