대기업 PoC를 뚫는 제안서 구조와 협상 포인트
키는 무엇인가.
바쁘신 분들을 위한 5초 요약
대기업 PoC는 “기술 검증”이 아니라 “조직 내 의사결정과 리스크 관리”를 통과하는 과정으로 보는 순간 제안서의 우선순위가 바뀐다.
제안서는 문제 정의와 기대효과를 앞에 두고, 보안·법무·구매가 요구하는 증빙을 한 번에 통과시키는 패키지로 설계해야 한다.
PoC 범위는 작을수록 좋지만, 성공 기준과 의사결정 일정, 상용 전환 조건까지 계약 수준으로 고정하지 않으면 ‘성공했는데 도입이 안 되는’ 상태가 길어진다.
가격 협상은 할인율이 아니라 파일럿 비용 처리 방식, 본계약 전환 크레딧, 기간과 범위, 지불 조건 같은 구조적 레버로 풀면 마진을 지키면서도 합의를 만들 수 있다.
대기업과의 PoC(Proof of Concept)는 스타트업이 ‘좋은 제품’을 증명하는 자리이기도 하지만, 실제로는 대기업 내부의 여러 부서가 위험을 관리하고 책임을 회피하지 않아도 되는 의사결정 체계를 완성하는 과정에 가깝다. 그래서 제안서의 핵심은 기능 설명이 아니라 “누가, 어떤 근거로, 어떤 조건에서, 도입을 결재할 수 있는가”를 문서로 만들어 주는 데 있다.
이번 글에서는 대기업 PoC를 통과시키는 제안서의 기본 구조와, 마지막에 가격만 남기지 않기 위해 미리 설계해야 하는 협상 포인트를 정리한다.
제안서의 첫 장은 ‘기능’이 아니라 ‘의사결정 언어’로 시작한다
대기업이 PoC를 요청할 때 표면적으로는 “우리 환경에서 돌아가는지”를 보려는 것처럼 말하지만, 실제 의사결정자는 보통 다음 질문에 답을 원한다.
첫째, 이 PoC가 끝나면 무엇이 달라지는가.
둘째, 실패했을 때 책임과 리스크는 어디에 남는가.
셋째, 성공했을 때 다음 단계가 무엇인지 이미 정해져 있는가.
따라서 제안서는 보통의 제품 소개서처럼 시작하면 초반부터 불리해진다. 첫 장에서부터 ‘사용 시나리오’가 아니라 ‘비즈니스 케이스’를 제시해야 한다.
권장하는 첫 장의 구성은 다음 4요소다.
현상과 문제 정의: 현재 프로세스의 병목, 비용, 리스크를 한 문단으로 요약한다.
목표: PoC에서 검증할 딱 한 가지 핵심 가설을 명확히 적는다.
기대효과: 성과를 비용 절감, 시간 절감, 오류 감소, 컴플라이언스 강화 같은 지표로 번역한다.
의사결정 요청: PoC 승인에 필요한 범위, 기간, 담당자 참여 수준을 한 줄로 요구한다.
대기업 내부에서는 “유용해 보인다”만으로 예산과 인력을 쓰기 어렵다. 문서가 의사결정자의 언어로 번역될수록, 챔피언이 내부 설득 자료로 그대로 복사해 쓸 수 있다.
PoC 설계는 ‘작게’가 아니라 ‘결정 가능하게’가 기준이다
PoC는 작은 규모로 리스크를 줄이는 활동이라는 점이 일반적으로 강조된다. 하지만 스타트업 입장에서는 ‘작은 실험’으로만 남으면 안 된다. PoC가 “학습”으로 끝나면 대기업은 다음 라운드를 요구하기 쉽고, 스타트업은 리소스만 소모한다.
그래서 제안서에는 다음 항목이 반드시 들어가야 한다.
범위: 대상 부서, 사용자 수, 데이터 범위를 숫자로 제한한다.
성공 기준: 성과 지표와 기준선을 포함해, 합격/불합격을 구분할 수 있게 정의한다.
실행 계획: 킥오프, 중간 점검, 최종 리뷰 일정과 산출물을 명시한다.
의사결정 미팅: 최종 리뷰에서 무엇을 결정하는지(상용 전환 여부, 확장 범위, 예산 요청)를 문장으로 적는다.
PoC가 길어질수록 “검증 항목 추가”가 자연스럽게 발생한다. 이를 막는 방법은 범위를 더 줄이는 것이 아니라, 처음부터 ‘이 PoC의 목적은 무엇이며 무엇은 목적이 아닌지’를 계약처럼 박아두는 것이다.
보안·법무·구매를 한 번에 통과시키는 ‘증빙 패키지’를 앞단에 넣는다
대기업 PoC가 막히는 지점은 현업이 아니라 지원 조직인 경우가 많다. 특히 SaaS, 데이터, AI가 들어가면 보안과 법무는 “기술 검증”보다 “사고 책임”을 먼저 본다.
제안서 본문 또는 부록에 다음 항목을 ‘체크리스트 형태로 선제 제공’하면, 검토 루프를 크게 줄일 수 있다.
데이터 거버넌스: 어떤 데이터가 어디에 저장되고, 누가 접근하며, 보관·삭제 정책이 무엇인지.
보안 요구사항: 침해 사고 대응, 통지 의무, 감사 권리, 준수 규정 등을 계약 조항 수준으로 어떤 방식으로 반영 가능한지.
계약 구조: PoC 계약과 본계약의 관계, 책임 제한, SLA의 적용 범위.
라이선스와 비용 명세: 무엇이 과금 단위이며, PoC에서 유료/무료 범위가 어디까지인지.
대기업은 크로스펑셔널 구매 프로세스를 갖고 있고, IT·재무·보안·법무·현업이 각자 다른 기준으로 승인한다. 제안서가 ‘각 부서의 질문을 미리 답해주는 자료’가 되면, 스타트업이 매번 같은 설명을 반복하는 시간을 줄일 수 있다.
협상은 ‘가격’이 아니라 ‘구조’에서 시작한다
PoC 협상은 흔히 “무료로 해달라” 또는 “성공하면 본계약을 검토하겠다” 같은 형태로 시작한다. 이때 단가 할인만으로 대응하면, 파일럿이 끝난 뒤에도 추가 할인 요구가 반복된다.
대신 협상 테이블을 구조로 옮겨야 한다. 대표적인 레버는 다음과 같다.
유료 PoC + 본계약 전환 크레딧
PoC 비용을 받되, 상용 전환 시 첫 해 계약금에서 100% 차감해 주는 방식은 대기업의 내부 결재를 만들면서도 ‘공짜 테스트’로 취급되는 것을 막는다. PoC 자체의 목적이 “결정”이라는 점을 문서로 고정할 수 있다.
제한된 범위의 유료 구현
전사 도입이 아니라 한 부서, 한 프로세스만 유료로 먼저 적용하고, 성과가 나오면 확장하는 형태로 구조를 잡으면 예산 부담을 줄이면서도 사업성을 확보할 수 있다.
일정과 의사결정 권한 고정
PoC 시작 전에 의사결정권자와 최종 승인 라인을 문서에 포함시키고, 최종 리뷰 미팅에서 ‘도입 여부’를 결정하도록 합의해야 한다. 성공 이후에도 새로운 이해관계자가 들어오면 평가가 다시 시작되기 때문이다.
가격이 아닌 총가치(상업 조건)로 거래하기
할인 대신 기간(멀티이어), 적용 범위, 지불 조건, 갱신 조건, 리스크 분담 같은 항목을 교환하면, 고객이 원하는 실익을 주면서도 스타트업의 마진을 지킬 수 있다.
이 구조를 제안서에 미리 넣어두면, 협상이 ‘깎는 게임’이 아니라 ‘합의 가능한 설계’로 전환된다.
결론
대기업 PoC를 뚫는 제안서는 제품 설명서가 아니라 의사결정 패키지다. 문제 정의와 기대효과를 의사결정자의 언어로 번역하고, PoC의 범위·성공 기준·결정 일정을 문서로 고정하면 ‘검증이 끝나도 도입이 안 되는’ 상황을 줄일 수 있다.
또한 보안·법무·구매의 질문을 선제적으로 처리할 증빙 패키지를 포함해야 한다. 마지막으로 협상은 단가 할인보다 구조적 레버를 우선시해야 한다. 유료 PoC의 크레딧 설계, 범위 제한, 의사결정 권한 고정, 상업 조건 교환이 준비되어 있을수록, PoC는 실험이 아니라 계약으로 이어지는 단계가 된다.
출처
• Sumedian, A Procurement Framework for SaaS Security
• Zylo, Understanding SaaS Procurement Best Practices
• Todd Caponi, Negotiating a Pilot / Proof of Concept
• Monetizely, How to Structure Enterprise Pilot Program Pricing
• Red Bear Negotiation, Negotiating Total Enterprise Value (Not Just Price)
• How to Run a Procurement Pilot Program: A Step-by-Step Guide
• CISPE, 공공 부문의 클라우드 서비스 구매 (2022년 2월)
작성: Venture Digest 인사이트팀
문의: connect@abyplus.com
더 많은 정보 확보하기: https://venturedigest.lovable.app/