통화 트랜스크립트에서 “무제한”이라는 단어를 검색하면, “사실상 한도가 없어요”라고 말한 담당자를 놓치게 됩니다. “48개월”을 검색하면, “4년 동안 보장돼요”라고 말한 담당자를 놓치게 됩니다. 키워드 매칭은 미리 찾도록 지정된 단어만 포착합니다. 실제로 무엇이 주장되었는지를 이해하는 것은 아닙니다.
이것이 바로 많은 세일즈 콜 분석 AI 도구가 전사(轉寫)에서 검증으로 넘어가려는 순간 부딪히는 한계입니다. 그리고 그 밑바탕에 있는 엔지니어링 과제 — 클레임 추출(주장 추출) — 이 익숙한 문구를 트랜스크립트에서 찾아내는 것과는 근본적으로 다른 종류의 작업인 이유이기도 합니다.
클레임 추출이란 실제로 무엇인가
클레임 추출이란, 즉흥적이고 자연스러운 발화를 개별적으로 확인 가능한 일련의 명제로 변환하는 과정입니다 — 각각이 진실의 원천과 대조해 독립적으로 참, 거짓, 또는 확인 불가로 판정할 수 있을 만큼 구체적인 진술이어야 합니다.
이는 그저 말한 내용을 기록하는 전사 작업과도 다르고, 의미를 이해하지 않은 채 패턴만 찾는 키워드 검색이나 감정 분석과도 다릅니다. 트랜스크립트는 어떤 단어가 쓰였는지 알려줍니다. 클레임 추출은 실제로 무엇이 주장되었는지 — 그리고 하나의 주장이 어디서 끝나고 다음 주장이 어디서 시작되는지 — 를 알려줍니다.
왜 이것이 보이는 것보다 훨씬 어려운가
담당자가 실제 통화에서 할 법한 다음과 같은 한 문장을 생각해 보세요.
“저희 엔터프라이즈 플랜은 기본적으로 지원이 무제한이고, 전담 담당자와 24시간 대응도 함께 제공됩니다.”
사람이 이 말을 들으면 즉시 최소 세 가지의 별개 주장이 담겨 있다는 것을 이해합니다 — 지원이 무제한이라는 것, 전담 담당자가 제공된다는 것, 그리고 24시간 대응이 가능하다는 것. 이 각각은 독립적으로 참일 수도, 거짓일 수도 있습니다 — 어쩌면 지원에 한도가 있을 수도 있고, 전담 담당자는 상위 등급에만 적용될 수도 있으며, “24시간 대응”이 실제로는 세 개 시간대의 업무 시간 내 대응만을 의미할 수도 있습니다.
키워드 검색은 이 문장을 분해할 방법이 없습니다. 하나로 이어진 단어 뭉치로 인식할 뿐입니다. 여기서 세 개의 독립적이고 각각 검증 가능한 주장을 추출하려면, 문장 구조를 이해하고, “함께”와 “24시간 대응”이 실제로 무엇을 수식하는지 파악하고, 하나의 주장이 어디서 끝나고 다음 주장이 어디서 시작되는지 판단해야 합니다 — 그중 어느 것도 패턴 매칭이 아닙니다.
실제 대화는 이를 한층 더 어렵게 만듭니다.
- 다른 표현 — 같은 사실이 통화마다 열 몇 가지 다른 방식으로 말해지며, 그중 어느 것도 고정된 키워드 목록과 일치하지 않음
- 완곡한 표현 — “포함되어 있다고 생각해요,” “그건 보장될 거예요” — 이것들도 엄연한 주장이지만, 담당자 본인조차 인지하지 못할 수 있는 불확실성에 감싸여 있을 뿐임
- 복합·조건부 발언 — “연간 계약이면 지원이 무제한이에요”는 조건 자체를 주장 안에 담고 있으며, 그 조건을 놓치면 실제로 검증해야 할 내용 자체가 달라짐
- 암묵적 주장 — “경쟁사 도구와 똑같이 작동해요”라고 말하는 담당자는 검증 가능한 사실을 하나도 직접 언급하지 않은 채 비교에 기반한 주장을 하고 있음
트랜스크립트 검색은 이 모든 것을 구조화되지 않은 텍스트로 취급합니다. 클레임 추출은 이를 구조화된, 확인 가능한 단위로 바꿔야 합니다 — 그리고 그 경계를 정확히 나눠야 합니다. 그러지 못하면 이후의 모든 단계가 그 오류를 그대로 물려받습니다.
왜 추출 품질이 이후 모든 것을 좌우하는가
이것은 보이는 것보다 훨씬 중요합니다. 클레임 추출이 검증보다 앞선 상류 단계에 위치하기 때문입니다. 어떤 시스템이 세 개의 주장을 하나로 합쳐버리면, 본래 세 개의 별개 답이 필요했던 것에 대해 판정 하나 — 지원, 모순, 혹은 그 시스템이 사용하는 어떤 판정 체계든 — 만 내릴 수 있습니다. 암묵적이거나 완곡한 주장을 통째로 놓치면, 그 주장은 아예 확인조차 되지 않은 채 끝나버립니다. 그 주장이 도달한 이후의 검증 로직이 아무리 훌륭해도 소용없습니다.
다시 말해, 팩트 기반 검증 엔진의 성능은 그것에게 주어진 주장의 질을 넘어설 수 없습니다. 추출 오류는 더 나은 검증으로 나중에 잡아낼 수 있는 것이 아닙니다 — 그저 잘못된 질문에 대해 자신감 있고 출처까지 갖춘 답을 만들어낼 뿐입니다.
이는 또한 단발성 데모로 짐작하기보다는 벤더에게 직접 물어볼 만한 타당한 질문이기도 합니다. 담당자가 한 문장에 두세 개의 주장을 묶어 말했을 때, 그 시스템은 이를 확실하게 별개의, 독립적으로 확인 가능한 항목으로 취급하는가 — 아니면 그 분리가 그날 그 특정 문장을 모델이 어떻게 해석했는지에 따라 달라지는가? 우수한 시스템조차 아직 이를 일관되게 보장하지 못할 수 있습니다. 그 질문에 대한 정직한 답변은, 벤더가 제시하는 어떤 정확도 수치보다도 그 플랫폼 뒤에 있는 엔지니어링의 성숙도를 더 잘 말해줍니다.
첫 단계만이 아니라 검증 아키텍처 전체를 확인해 보세요. 저희의 12페이지 리포트 『Beyond Roleplay: The Rise of the Sales Knowledge Engine』에서는 클레임 추출, 팩트 기반 검증, 그리고 어떤 벤더에게든 그들의 파이프라인이 실제로 어떻게 작동하는지 물어볼 가치가 있는 질문들을 다룹니다. [화이트페이퍼 다운로드 →]
훌륭한 추출이 실제로 만들어내야 하는 것
이상적으로, 클레임 추출 단계의 결과물은 하이라이트된 트랜스크립트가 아닙니다. 그것은 구조화된 목록입니다 — 각 항목이 독립된 하나의 주장으로 분리되고, 그 의미를 좌우하는 조건은 유실되지 않고 보존된 채, 진실의 원천과 대조해 독립적으로 확인할 수 있는 상태입니다.
이는 일관되게 달성하기가 정말로 어려운 기준입니다. 완곡한 표현, 조건이 얽힌 문장, 복합 문장은 모두 시스템이 본래 분리해야 할 주장을 하나로 합쳐버리거나, 실제로 검증되는 내용을 바꾸는 수식어를 놓치기 쉽게 만듭니다. 위의 예시 문장의 경우, 이상적인 결과물은 세 개의 별개 레코드입니다 — 무제한 지원 하나, 전담 담당자 하나, 24시간 대응 하나. 어떤 시스템이 하나로 합쳐진 주장이 아니라 확실하게 세 개의 레코드를 만들어내는지는, 실무적으로 업계 대부분에게 여전히 미해결의 엔지니어링 과제이지, 이미 해결된 문제가 아닙니다.
이 구조는 이후의 리포팅을 의미 있게 만드는 데도 중요합니다. “담당자 10명 중 8명이 전담 담당자 조건을 잘못 말한다”는 문장을 시스템이 만들어낼 수 있는 것은, 전담 담당자 관련 주장이 애초에 지원 관련 주장, 대응 관련 주장과 정확히 분리되어 있었을 때뿐입니다. 이것들을 하나로 합쳐버리면, 그 패턴은 잡음 속으로 사라져 버립니다.
이것이 나타내는 엔지니어링상의 전환
AI 세일즈 트레이닝 시장의 대부분은 이와는 다른, 더 이른 단계의 문제 — 현실적인 대화를 생성하는 것 — 를 해결해 왔습니다. 이는 언어 모델의 잘 이해된 응용 분야이며, 그렇기에 지금은 업계 전반에서 흔한 기능이 되었습니다. 클레임 추출은 이와는 다른 종류의 문제입니다 — 구조화되도록 설계되지 않은 언어에서, 실제로 무엇이 주장되었는지를 정확하고 빠짐없이 파싱해내는 문제입니다.
이는 또한 한 번 해결하면 끝나는 문제도 아닙니다. 담당자가 이전에 말한 적 없는 새로운 표현, 새로운 완곡어법, 새로운 복합 문장이 나올 때마다, 추출 단계는 이를 올바르게 처리해야 하는 새로운 사례에 직면합니다. 이 지속적인 엔지니어링 작업 — 이미 많은 플랫폼이 공유하고 있는 롤플레이 생성이 아니라 — 이야말로, 실제 대화를 검증할 수 있는 시스템과 대화가 어떻게 들렸는지만 채점할 수 있는 시스템을 가르는 지점입니다.
자사 문서가 그대로 지식 점검이 되는 순간을 확인하세요. EOS는 귀사의 제품 문서를 실전 연습과 증명 가능한 지식으로 바꿉니다 — 주장 추출, 팩트 기반 검증, 그리고 영업 담당자가 실제로 무엇을 아는지 보여주는 자동 생성 퀴즈까지. app.akaeos.com에서 최대 5석까지 무료로 시작하거나, **[화이트페이퍼 전체 다운로드]**해 보세요.
Leave a Reply