모델 성능이 좋으면 에이전트 성과도 좋을 것이라는 가정은 이미 반증됐습니다.

채널코퍼레이션의 AI 에이전트 ‘알프’는 월 100만 건이 넘는 상담을 자동으로 처리하고, 해결률 80%를 달성하고 있습니다. 이 숫자가 인상적인 이유는 특별히 강한 모델을 썼기 때문이 아닙니다. 11년간 축적한 상담 데이터와, 그 위에 얹은 룰 베이스 가드레일 때문입니다.

경쟁 축이 이동하고 있습니다. 이제는 “어느 모델이 더 똑똑한가”가 아니라 “얼마나 깊은 도메인 데이터를 가졌는가”와 “그것을 얼마나 신뢰할 수 있는 구조로 운영하는가”가 버티컬 에이전트의 진짜 경쟁력입니다.

왜 모델 성능이 충분하지 않은가

지금 시장에 나와 있는 프런티어 모델들의 성능 격차는 빠르게 좁혀지고 있습니다. 같은 태스크를 여러 최신 모델에 던져보면 결과가 비슷합니다. “우리가 A 모델을 썼기 때문에 잘 된다”는 설명이 더 이상 먹히지 않습니다.

반면, 도메인 데이터는 복사되지 않습니다. 11년간 고객 상담 데이터를 쌓아온 채널코퍼레이션이 경쟁사보다 유리한 건, 그 데이터를 경쟁사가 하루아침에 확보할 수 없기 때문입니다. 에이전트가 해결하는 문제의 질과 범위는 결국 학습 데이터의 깊이에 비례합니다.

삼성SDS AX센터가 발표한 수치를 보면, 한국 대기업의 에이전트 도입률은 “고작 5%“입니다. 도입을 망설이는 이유는 대부분 “어떤 모델을 써야 할지 모른다”가 아닙니다. “어떤 데이터를 어떻게 준비해야 할지 모른다”와 “에이전트가 틀렸을 때 누가 책임지는가”입니다. 이것이 거버넌스 문제입니다.

거버넌스가 신뢰를 만든다

알프가 80% 해결률을 달성하면서 기업 신뢰를 얻을 수 있었던 것은 룰 베이스 가드레일 덕분입니다. 에이전트가 무엇을 할 수 있고 무엇을 해선 안 되는지를 명확히 정의한 것입니다.

이것은 PM이 설계해야 하는 영역입니다. 모델이 스스로 결정할 수 없는 것들 — 특정 상황에서는 무조건 사람에게 넘긴다, 개인정보가 포함된 응답은 한 번 더 검수한다, 환불이나 계약 관련 요청은 에이전트 단독 처리를 금지한다 — 이런 경계를 누군가가 정해야 합니다.

그 누군가는 엔지니어가 아닙니다. PM입니다.

거버넌스가 없는 에이전트는 온보딩이 안 된 신입 직원이 혼자 고객 응대를 하는 것과 같습니다. 능력은 있을지 몰라도, 조직의 기준과 예외 처리 방식을 모릅니다. 그 간극이 80% 해결률과 50% 해결률의 차이를 만듭니다.

도메인 깊이를 설계하는 세 가지 방법

도메인 깊이는 저절로 생기지 않습니다. 세 가지를 의도적으로 설계해야 합니다.

첫째, 데이터 구조화. 과거 데이터를 많이 보유하는 것만으로는 부족합니다. 에이전트가 활용할 수 있는 형태로 구조화돼야 합니다. 채널코퍼레이션의 11년 상담 데이터가 효과를 발휘하는 이유는 상황 유형별로 분류·레이블링돼 있어 에이전트가 유사 사례를 빠르게 참조할 수 있기 때문입니다.

둘째, 도메인 용어 정의. 에이전트는 “환불”과 “교환”을 헷갈릴 수 있습니다. 산업마다, 회사마다 용어의 정의가 다릅니다. 이 정의를 명확히 해주지 않으면 에이전트는 범용 LLM의 이해 수준에서만 작동합니다.

셋째, 실패 루프 설계. 에이전트가 틀렸을 때 그 케이스를 어떻게 수집하고 다시 반영하는가가 도메인 깊이를 지속적으로 개선하는 루프입니다. 이 루프가 없으면 에이전트는 출시 시점의 성능에서 멈춥니다.

# 에이전트 실패 로그 구조 예시
failure_log = {
    "query": "원래 고객 질문",
    "agent_response": "에이전트의 답변",
    "expected_response": "올바른 답변",
    "failure_type": "wrong_category | hallucination | rule_violation",
    "reviewed_by": "담당자 이름",
    "timestamp": "2026-08-28T10:30:00Z"
}

이 로그를 체계적으로 쌓는 것이 도메인 깊이를 만드는 실질적 작업입니다.

PM이 지금 당장 해야 할 질문

에이전트 도입을 논의할 때 모델 선택 회의에 가장 많은 시간을 쓰고 있다면, 우선순위가 잘못된 것입니다.

더 중요한 질문은 이것입니다:

  • 우리 도메인에서 에이전트가 처리해야 하는 상황 유형을 정의했는가?
  • 에이전트가 절대로 단독 처리해선 안 되는 케이스를 정의했는가?
  • 에이전트가 틀렸을 때 그것을 감지하고 사람에게 넘기는 체계가 있는가?
  • 지금까지 쌓인 데이터 중 에이전트 학습에 활용할 수 있는 것은 무엇인가?

채널코퍼레이션 알프의 80% 해결률은 11년의 데이터와 명확한 룰 가드레일이 만든 결과입니다. 에이전트 도입이 5%에 머물러 있는 한국 대기업들이 넘어야 할 것은 더 좋은 모델이 아닙니다. 도메인 데이터 준비와 거버넌스 설계입니다.

이 두 가지를 선점한 버티컬이 에이전트 시장에서 해자를 갖게 됩니다.

당신의 팀은 어떤 도메인 데이터를 얼마나 깊이 갖고 있나요?