프리미엄 고객이 결제 관련 질문을 하면, 그 고객이 유료 플랜을 쓰고 있다는 사실을 이미 반영한 답변을 받습니다. 계정에 플래그가 지정된 사용자는 헤매거나 엉뚱한 곳으로 빠지지 않고 정확히 맞는 복구 절차로 안내됩니다. 대규모 브랜드 포트폴리오 중 한 브랜드에 문의한 고객은 바로 옆 계열 브랜드의 정책을 들을 일이 없습니다. 이 고객들 중 누구도 답변이 왜 그렇게 잘 맞았는지 알지 못합니다. 바로 그것이 핵심입니다.
이런 순간을 가능하게 하는 것이 Segments입니다. Maven 플랫폼에서 가장 눈에 띄지 않으면서도 가장 중요한 역할을 맡은 기능 중 하나입니다. 그래서 제품 시리즈의 첫 번째 글은 보통의 발표가 다루지 않는 영역을 다룹니다. 바로 에이전트가 말을 꺼내기 전에 어떤 지식 문서에 접근할 수 있는지를 결정하는 대상 정의입니다.
Segments란 무엇인가
Segments는 특정 유형의 대화나 사용자를 설명하는, 이름이 붙은 재사용 가능한 정의입니다. 프리미엄 계정, 차단된 계정, 이메일 채널의 대화, 이미 본인 인증을 마친 사용자 등이 그 예입니다. 한 번 작성하고 알아보기 쉬운 이름을 붙인 뒤 필요한 곳에 연결하면 됩니다. 같은 정의 하나로 지식 베이스, 액션, 워크플로 전체를 제어할 수 있으며, 매번 다시 작성할 필요가 없습니다.
Segment는 대상에 대한 정의입니다. 누구인지, 어떤 채널을 이용하는지, 무엇을 볼 수 있는지를 규정합니다. 놓치기 쉬운 점은 Segments가 제품의 결정론적 구성 요소이며, 모델이 추론하기 전에 실행된다는 것입니다. 모델이 운 좋은 날에만 따르는 프롬프트 속 권고가 아닙니다. 관문입니다. 에이전트는 먼저 정의를 평가해 무엇이 허용되는지 판단하고, 그 관문을 통과한 것만을 대상으로 추론합니다. 세그먼트 범위를 벗어난 지식이나 액션은 단순히 사용이 권장되지 않는 정도가 아니라, 아예 고려 대상에 들어오지 않습니다.
이 순서가 설계의 전부입니다. 다른 브랜드의 가격 정보를 무시해 달라고 정중히 요청하면 모델은 대개 따릅니다. 하지만 '대개'는 기업이 책임질 수 있는 기준이 아닙니다. 세그먼트는 이 문제 자체를 없앱니다. 잘못된 콘텐츠는 처음부터 검색 대상이 될 수 없기 때문입니다.
고객이 모르는 사이에 세그먼트를 만나는 곳
세그먼트는 기능처럼 보이지 않기 때문에 릴리스 노트에 언급되는 일이 드뭅니다. 문제가 없는 상태로 드러날 뿐입니다. 세그먼트가 조용히 작동하는 몇 가지 사례는 다음과 같습니다.
등급별 계정
일반 사용자와 유료 사용자는 같은 질문을 해도 서로 다른 답변이 필요할 수 있습니다. 계정 상태를 기준으로 한 세그먼트가 각 사용자에게 맞는 지식을 허용하므로, 에이전트가 맥락 단서로 고객의 등급을 추측할 필요가 없습니다. 고객은 자신의 플랜에 맞는 답변을 받기만 하면 됩니다.
브랜드 및 사업부 분리
한 Maven 고객사는 하나의 에이전트로 여러 소비자 브랜드 포트폴리오를 운영합니다. 브랜드의 보이스, 정책, 제품 정보가 경계를 넘어 섞이면 안 되므로 각 브랜드의 지식은 서로 철저히 분리되어야 합니다. Segments는 이 분리를 결정론적으로 보장하므로, 하나의 에이전트가 여러 브랜드를 지원하면서도 어느 브랜드도 다른 브랜드의 답변을 가져다 쓰지 않습니다. 브랜드 간 정보 혼선도, 브랜드별로 별도 에이전트를 관리할 필요도 없습니다.
내부 지식과 고객용 지식
지원팀은 에이전트가 상담원을 도울 때는 내부 런북을 활용하되, 고객과 대화할 때는 절대 사용하지 않기를 원하는 경우가 많습니다. 대화가 Copilot 모드인지 여부에 연결된 Segment를 사용하면 상담원용 자료는 필요한 곳에서만 사용되고, 그렇지 않은 곳에서는 보이지 않습니다. 고객은 내부 메모를 볼 수 없고, 상담원은 언제나 볼 수 있습니다.
인텐트 기반 라우팅
플랫폼이 사용자의 의도를 파악할 수 있으면, Segment가 해당 대화를 목적에 맞게 설계된 경로로 보낼 수 있습니다. 계정 생성 인텐트와 접근 복구 인텐트는 첫 메시지만 보면 비슷하지만 처리 방식은 크게 다릅니다. Segments를 사용하면 에이전트가 희망 섞인 추측이 아닌 결정론적 규칙에 따라 올바른 워크플로를 선택합니다.
왜 '모델이 추론하기 전'이 핵심인가
여기서 Segments는 더 큰 그림과 연결됩니다. Maven의 에이전트는 Graph of Record를 바탕으로 추론합니다. Graph of Record는 고객, 고객의 이력, 그리고 그 뒤에 있는 신뢰할 수 있는 시스템을 하나로 통합한 정보입니다. 그래프에는 에이전트가 활용할 수 있는 모든 것이 담겨 있습니다. 세그먼트는 추론이 시작되기 전에 이번 대화에서 그중 어느 부분을 사용할지 결정합니다.
지능을 위한 접근 제어라고 생각하면 됩니다. Graph of Record는 지식이고, Segments는 누가 언제 그 지식의 어느 부분을 사용할 수 있는지에 대한 결정론적 정의입니다. 이러한 역할 분담 덕분에 하나의 에이전트가 리스크가 되지 않으면서 기업 전체를 아우를 수 있습니다. 전체적으로는 방대한 지식을 갖추면서도, 매 순간 엄격하게 범위가 제한되기 때문입니다.
이것이 오버레이 모델과 충돌하지 않고 잘 맞는 이유이기도 합니다. Maven은 기업이 이미 운영 중인 헬프데스크, CRM, 지식 소스 위에서 작동합니다. Segments는 이처럼 폭넓은 연결을 모든 대화에 무분별하게 쏟아붓는 대신 체계적으로 관리하는 방법입니다. 에이전트는 많은 것에 연결되어 있지만, 한 번에 허용되는 것은 의도적으로 아주 적습니다.
대규모 자율 해결에 중요한 이유
목표는 자율 해결입니다. 에이전트가 단순히 문의를 라우팅하거나 회피하는 것이 아니라 실제로 문제를 해결하는 것입니다. 하지만 신뢰할 수 있는 해결은 에이전트가 대부분이 아니라 매번 올바른 지식과 올바른 액션을 선택하는 데 달려 있습니다. Mastermind는 이러한 기반 위에서 6주 만에 93%의 자율 해결률을 달성했습니다. 높은 해결률은 에이전트가 엄격하게 범위가 지정된 정확한 입력값을 바탕으로 추론할 때에만 안전합니다.
걸린 문제는 구체적입니다. 범위 지정이 잘못되면 그 실패는 추상적이지 않습니다. 고객이 잘못된 정책을 안내받고, 차단된 계정이 신규 계정처럼 처리되며, 한 브랜드가 다른 브랜드의 보이스로 답변하게 됩니다. 이 하나하나가 신뢰를 조금씩 무너뜨리며, 신뢰야말로 AI 에이전트가 지켜야 할 대상입니다. Segments는 화려하지는 않지만 이런 일이 일어나지 않게 하는 핵심 요소입니다.
핵심 정리
가장 신뢰할 수 있는 AI 고객 서비스는 더 똑똑한 모델만으로 만들어지지 않습니다. 모델이 볼 수 있는 범위를 철저히 통제할 때 만들어집니다. Segments가 바로 그 통제입니다. 단 한 마디의 추론이 시작되기 전에, 에이전트가 누구와 대화하고 있으며 그 상대가 무엇을 알아야 하는지 이미 정해 둔 정의입니다. 고객은 Segments에 대해 묻지 않을 것입니다. 그저 자신에게 꼭 맞는 답변을 계속 받게 될 뿐입니다.
귀사의 실제 대화로 확인하세요.
맞춤형 무료 데모를 신청하세요.
