영업 속도 저하 없이 신뢰를 회복하는 CPQ 하이브리드

두 달 전, 한 고객사에서 챗봇이 하룻밤 사이에 갑자기 까다로워진 이유를 물어온 적이 있습니다. 그 전주까지만 해도 파워트레인을 자신 있게 추천하던 챗봇이 모델 업그레이드 후, 단계마다 확인 질문을 던지기 시작한 것입니다. 제품도, 규칙도 그대로인데 동작만 달라졌습니다. 이것이 바로 문제입니다. 영업 로직이 그날그날의 모델 버전에 따라 흔들려서는 안 된다는 뜻입니다.

복잡한 제품을 판매할 때, 정확성은 '있으면 좋은 것'이 아니라 필수입니다. 영업 부서는 빠른 답변을 원하지만, 운영 부서는 결과에 대한 보증을 필요로 합니다. 어느 한쪽을 포기할 수 없습니다. 순수한 규칙 기반 방식과 순수한 LLM 방식 사이에서 양자택일하려는 접근 자체가 잘못되었습니다.

지금이 왜 중요한 전환점인가

LLM은 대화, 설명, 패턴 발견에 탁월합니다. 구매자의 언어로 소통하고 시나리오를 이해시킵니다. 하지만 확률 기반으로 작동하기에 똑같은 입력에도 다른 결과를 낼 수 있고, 맥락이 부족하면 추측으로 답변을 만들어내기도 합니다.

반면 제약 기반 CPQ는 그 반대입니다. 완벽할 정도로 '지루하게' 정적입니다. 모든 결과가 결정론적(deterministic)이고, 테스트 가능하며, 릴리스가 바뀌어도 안정적입니다. 하지만 상호작용 방식이 경직되어 있고, 모든 추천과 설명을 규칙으로 해결하려 하면 유지보수 비용이 급증합니다.

결국 어느 한쪽을 선택하는 것이 아니라, 각자가 가장 잘하는 역할을 맡기는 것이 핵심입니다.

가트너 리서치에 따르면, 수많은 CPQ 프로젝트 실패의 근본 원인은 툴이 아니라 제품 데이터와 거버넌스에 있었습니다. 이는 핵심 병목 지점이 기능이 아니라, '지식을 표현하고, 변경을 통제하며, 의사결정을 사람에게 설명하는 방식'에 있음을 시사합니다.

판사와 조언자: 하이브리드 CPQ의 두 역할

저희는 이 패턴을 워크숍에서 'CPQ 추론(CPQ Reasoning)' 모델이라 부릅니다. 모든 견적 프로세스를 두 가지 역할이 순차적으로 처리한다고 생각하시면 쉽습니다.

• 판사(The Judge)는 심볼릭 엔진입니다. 금지/필수 요건을 코드화하고, 호환성을 검증하며, BOM을 생성하고, 결정론적으로 가격을 산출합니다. 절대 추측하지 않습니다.
• 조언자(The Advisor)는 LLM 인터페이스입니다. 고객과의 접점을 담당하며 시나리오 기반 질문을 던지고, 기본 옵션을 제안하며, 장단점을 설명하고, 왜 이 구성이 구매자에게 합리적인지 이야기합니다.

조언자는 제안하고, 판사는 결정합니다.

저희는 이 패턴을 트럭, 엘리베이터, 프로젝트 기반 서비스에 적용해 테스트했습니다. 조언자가 고객의 요구사항을 구조화된 선택지로 변환하고, 5년 총소유비용(TCO) 분석과 함께 사양을 제안합니다. 그러면 판사가 이를 검증하고, 유효하지 않은 항목은 거부합니다. 이후 조언자는 거부된 이유를 쉬운 말로 다시 설명합니다. 그 결과, 빠르면서도 책임질 수 있는 견적이 완성되었습니다.

하이브리드 CPQ 추론 아키텍처

1. 명시적인 제품 로직 계층

안정성이 보장되는 곳에서 시작해야 합니다. 제품을 모듈과 상호 배타적인 옵션으로 모델링하고, 명확한 ID, SKU, 속성, 가격을 부여하십시오. 절대적으로 필요한 경우가 아니라면 계층 구조를 최소화하고 단순하게 유지하십시오. 자주 사용되는 조합은 시나리오 모듈로 만드십시오. '선택 안 함(none-option)' 옵션을 의도적으로 포함시켜 제약조건 표현을 명확하게 해야 합니다. 테스트 스위트를 구축하여 상위 50개 견적 경로와 주요 예외 케이스를 항상 검증하십시오.

2. 상호작용 및 설명 계층

그 위에 LLM 기반 인터페이스를 배치합니다. 여기서는 채팅, 이메일, 제안요청서(RFP) 텍스트 같은 비정형적인 입력도 처리할 수 있습니다. 각 모듈별 장단점, 추천 시나리오, 비추천 시나리오 등을 담은 간결한 지식 베이스를 구축하여 LLM을 지원합니다. 조언자의 역할은 다음과 같습니다.

• 구매자의 언어로 시나리오 기반 질문을 던집니다.
• 장단점을 설명하고, 근거와 함께 기본 옵션을 제안합니다.
• 저비용 대안을 포함한 비교 옵션 초안을 작성합니다.
• 합의된 비용 요소를 사용해 TCO 분석을 제시한 후, 선택된 항목을 판사에게 넘겨 검증과 가격 책정을 요청합니다.

제안된 모든 선택 사항은 판사에 의해 검증된 후에야 견적에 포함됩니다. 만약 판사가 거부하면, 조언자는 사람이 이해할 수 있는 설명과 함께 유효한 대안을 가지고 돌아옵니다.

3. 오케스트레이션 및 가드레일

두 계층 사이에는 양쪽을 조율하는 역할(Orchestration)이 필요합니다. 자유 텍스트를 선택 가능한 후보로 변환하고, '판사'를 호출하며, 결정 과정을 기록합니다. 이 계층은 다음을 반드시 제공해야 합니다.

• 검증, 완성, 가격 책정을 위한 결정론적 API
• 거부 사유 코드와 사람이 읽을 수 있는 설명
• 동작을 감사할 수 있도록 로직과 모델 프롬프트의 버전 관리

여기서 LLM 모델을 통제합니다. 기반 모델이 변경될 때 벤치마크를 실행하고, 응답 시간이 기준을 초과할 때 사용할 대체 모델을 설정할 수 있습니다.

4. 데이터, 거버넌스, 학습 루프

모든 것을 측정하고 기록해야 합니다. 상위 20개 의사결정 경로, 이탈 지점, 수동 변경(override) 건수, 평균 견적 소요 시간을 파악하십시오. 조언자의 프롬프트와 판사의 결정을 함께 저장하여, 로직이나 모델이 변경될 때 견적을 다시 재현해볼 수 있어야 합니다. 비전문가도 제품 정보나 가격을 쉽게 수정할 수 있는 포맷을 사용하고, 누락된 SKU나 잘못된 속성 등을 자동으로 점검하는 체계를 갖추십시오.

시스템이 답변과 설명을 모두 할 수 있게 되면, 도입은 더 이상 변화 관리 프로젝트가 아니라 자연스러운 과정이 됩니다.

이 아키텍처가 실제로 해결하는 문제들

속도와 안정성. 조언자는 대화 시간을 단축시키고, 판사는 결과의 편차를 제거합니다. 사람처럼 빠른 상호작용과 기계 수준의 정확성을 동시에 얻게 됩니다.

현장에서의 신뢰. 영업 담당자는 '왜' 이 선택이 최적인지 시스템으로부터 직접 듣고 고객에게 설명할 수 있습니다. 구매 부서는 방어 가능한 근거 자료를 확보하게 됩니다.

유지보수의 용이성. 내러티브는 더 이상 복잡하게 얽힌 규칙 안에 존재하지 않습니다. 제품 담당자는 복잡한 코드가 아닌, 시나리오와 데이터 테이블을 업데이트합니다. 테스트 스위트는 현장에서 문제가 발생하기 전에 회귀 오류(regression)를 잡아냅니다.

설명 가능한 가격 결정. 조언자는 가격 변동 요인과 TCO를 설명하지만, 최종 가격 계산, 최저 가격 정책, 번들 조건 적용은 판사가 결정론적으로 처리합니다. '조용한' 가격 오류가 사라집니다.

반드시 지켜야 할 설계 원칙

• 로직으로 유효성을 보장하고, 언어로 시간을 압축하십시오.
• 완벽한 첫 릴리스가 아닌, 지속적인 변경을 염두에 두고 모델링하십시오. 영리하게 얽힌 규칙보다 모듈화된 데이터, 시나리오, 테스트를 우선시하십시오.
• 시스템이 스스로를 설명하게 만드십시오. 모든 거부, 기본값, 가격 조정에는 회의에서 말해도 어색하지 않을 이유가 있어야 합니다.
• 학습을 위해 모든 것을 측정하십시오. 견적이 어디서 막히는지, 가격이 왜 변하는지 볼 수 없다면, 데이터가 아닌 감에 의존해 개선하게 될 것입니다.

이번 분기, 당장 실행할 수 있는 것들

• 주요 견적 경로 분석. 영업 담당자들이 CPQ를 벗어나 엑셀이나 이메일에 의존하는 지점을 찾으십시오. 그 이유를 파악하고, 그 부분을 조언자 역할의 첫 번째 개선 범위로 삼으십시오.
• '금지'와 '추천' 분리. '의견'을 규칙에서 분리하십시오. 10개의 핵심 모듈에 대해 언제 선택하고, 언제 피해야 하며, 어떤 장단점이 있는지 짧은 내러티브를 만드십시오.
• '선택 안 함' 옵션 추가. 이 옵션은 제약조건을 명확하게 표현하고 테스트를 더 정직하게 만듭니다.
• 테스트 자동화 구축. 성공해야만 하는 '골든 케이스' 5개와 실패해야만 하는 케이스 5개를 정의하고, 변경 시마다 자동 테스트를 실행하십시오.
• 조언자 역할의 안전한 도입. 하나의 제품으로 시작하여, 조언자의 역할을 기본 옵션 제안과 설명으로 제한하십시오. 판사가 최종 결정권을 유지해야 합니다.
• 견적서에 설명 포함. 시스템이 스스로를 정당화하지 못하면, 결국 그 부담은 영업 담당자에게 돌아갑니다.

성공하는 팀과 도태되는 팀

제품 구조, 간결한 내러티브, 그리고 작지만 확실한 테스트 스위트에 투자하는 팀은 복리 효과와 같은 경쟁 우위를 확보하게 될 것입니다. 매주 업데이트를 배포하고, 클릭 한 번으로 '왜'라는 질문에 답하며, 엔지니어링팀의 도움 없이 신규 영업 인력을 교육할 수 있습니다.

반면, 취약한 로직 위에 챗봇을 급조해서 얹은 팀은 한 분기 동안은 그럴듯한 데모를 보여주겠지만, 결국 조용한 실패를 맞이할 것입니다. 견적 과정은 도움이 되는 것처럼 느껴지다가도, 현장에서 단 한 번의 오류가 발생하면 신뢰를 잃습니다. 그 후엔 다시 엑셀이 등장하고 시스템은 선반 위 장식품이 될 것입니다.

도태될 또 다른 그룹은 '규칙 만능주의자'들입니다. 정확성은 지키겠지만, 고객을 잃게 될 것입니다. 고객 여정의 더 많은 부분이 디지털 및 셀프서비스로 이동하는 지금, 설명과 추천은 더 이상 부가 기능이 아닙니다. 그것이 바로 인터페이스입니다.

진정한 성공 지표는 도입률(adoption)입니다. 화요일 오후에 영업 담당자가 스스로 사용하지 않는 시스템은 실패한 것입니다.

저는 2000년부터 CPQ의 모든 발전 단계를 현장에서 경험했습니다. 시대를 관통하는 성공 패턴은 단순합니다. 협상 불가능한 원칙은 테스트 가능한 형태로 코드화하고, 시스템이 최고의 제품 전문가처럼 말하게 만드는 것입니다. 전자는 리스크를 막아주고, 후자는 계약 성사율을 높입니다.

만약 현재 사용 중인 시스템이 스스로 추론하고 그 근거를 제시하지 못한다면, 영업 담당자들은 대체 무엇을 믿고 고객 앞에 서야 할까요?