고객 상담이 에이전트 도입의 최전선이 된 이유
AI 에이전트를 실제 서비스에 넣으려는 조직이 가장 먼저 손대는 영역은 대개 고객 상담입니다. 이유는 기술적 난이도가 낮아서가 아니라 투자 수익률(ROI, Return on Investment) 을 계산하기 쉬워서입니다. 응답이 빨라지면 전환율이 오르고, 사람 상담원에게 넘기는 건수가 줄면 문의 1건당 비용이 내려가고, 문제를 끝까지 해결한 비율이 높아지면 고객이 남습니다. 세 지표 모두 기존 콜센터 운영에서 이미 측정하던 것이라, 에이전트를 붙이기 전과 후를 같은 자로 비교할 수 있습니다.
문제는 그다음입니다. 데모를 만드는 일과 매달 수십만 건의 실제 대화를 처리하는 시스템을 운영하는 일은 성격이 전혀 다릅니다. 프로덕션에 올라간 순간부터 과제는 "에이전트를 어떻게 만드는가"에서 "에이전트가 어떻게 동작하고 있는지를 어떻게 알아내고 고치는가"로 옮겨 갑니다. 실제 대화에서 배우고, 행동을 다듬고, 어떤 대화는 자유로운 추론(reasoning)에 맡기고 어떤 대화는 결정론적 워크플로우로 고정할지를 결정해야 합니다.
LangChain이 2026년 8월 4일 공개한 글(작성자 Jess Ou)은 이 단계에 도달한 세 회사의 운영 기록을 정리한 것입니다. LangChain은 LangGraph로 에이전트의 제어 흐름을 그래프로 기술하고, LangSmith로 그 실행을 추적하고 평가하는 도구를 만드는 회사입니다. 원문은 여기에 장기 과제를 다루는 Deep Agents까지 포함해 지속적 개선을 받치는 구성 요소로 열거합니다. 이 글에 등장하는 세 팀은 모두 그 조합 위에서 시스템을 운영합니다. 여기서 다루는 회사는 다음과 같습니다.
- Lyft: 비개발 직군인 운영팀과 프로덕트 매니저가 직접 상담 에이전트를 설정하고 배포할 수 있는 셀프서브 플랫폼을 구축했습니다
- Fastweb과 Vodafone: 고객을 직접 응대하는 Super TOBi와 콜센터 상담원을 지원하는 Super Agent를 함께 만들었습니다
- LATAM Airlines: 여행 지원 에이전트 Concierge와, 비정형 대화를 구조화된 신호로 바꾸는 Compass를 운영합니다
이번에 소개하는 글의 관점은 에이전트를 "제품"이 아니라 프로덕션 시스템 으로 다룬다는 점에서 일관됩니다. 지속적인 테스트, 배포, 관측, 반복 개선이 필요한 대상이라는 뜻이고, LangChain은 이 흐름을 에이전트 개발 수명주기(Agent Development Lifecycle)라는 이름으로 정리해 두었습니다. 에이전트를 감싸는 여러 겹의 루프라는 관점은 PyTorchKR에도 LangChain의 루프 엔지니어링 정리로 소개된 바 있습니다.
고객경험 에이전트에서 반복해서 나타나는 다섯 가지 패턴
LangChain이 여러 고객사에서 관찰한 유형은 다섯 가지로 정리됩니다. 원문은 각 패턴을 나열하는 데 그치지 않고, 그것이 어떤 조건에서 등장하는지를 함께 적어 두었습니다.
소비자 대면 셀프서비스 에이전트(Consumer-facing Self-service Agent): 가장 눈에 잘 보이는 출발점입니다. 채팅이나 음성으로 고객과 직접 대화하면서 요금 청구, 계정 접근, 보상 청구, 예약 일정 관리 같은 업무를 처리합니다. 성과 측정이 쉽다는 점이 도입 명분을 만들어 줍니다. Podium의 AI Employee는 자동차 딜러, 냉난방 설비 업체 같은 지역 사업자를 대신해 인바운드 리드에 응답하는데, 5분 안에 응답하면 1시간 뒤에 응답하는 경우보다 리드 전환율이 46% 높다는 수치가 그 자체로 도입 근거가 됩니다.
현장 직원과 상담원 코파일럿(Frontline and Rep Copilot): 고객과 직접 대화하지 않고 사람 상담원 옆에서 다음에 할 일을 제시하는 유형입니다. LangChain은 이쪽이 오히려 지렛대 효과가 더 크다고 봅니다. Cisco의 고객경험 조직은 네트워크 엔지니어를 대상으로 이 방식을 쓰는데, 수천 개의 진단 결과 후보를 정말 중요한 몇 개로 좁혀 주기 때문에 "도와주세요" 처럼 막연한 요청이 들어와도 적절한 문제로 연결됩니다.
셀프서브 플랫폼(Self-serve Platform): 엔지니어링 조직이 모든 에이전트를 직접 만들 수 없는 시점에 등장합니다. Lyft에서는 운영팀과 프로덕트 매니저가 프롬프트와 설정 파일만 작성하면 머신러닝 엔지니어를 거치지 않고 새 상담 에이전트를 배포할 수 있습니다. Podium도 사내에서 쓰던 것과 같은 구성 요소로 유사한 시스템을 만들어, 하나의 아키텍처로 자동차 판매부터 냉난방 설비 보증 상담까지 폭넓은 사용 사례를 지원합니다.
의미 기반 라우팅과 분류(Semantic Routing and Triage): 고객 요청이 불완전하거나 모호할 때 결정적으로 중요해집니다. LATAM Airlines의 Concierge는 초기에 전체 메시지의 13%를 처리 범위 밖으로 분류했는데, 그 대화를 직접 열어 보니 95%가 체크인과 수하물 문의처럼 승객에게 실제로 필요한 요청이었고 에이전트가 아직 담당 범위로 설계되지 않았을 뿐이었습니다. 고객 지원 전문 에이전트를 하나 추가하자 이 비율이 13%에서 1%로 내려갔습니다.
공통 언어로서의 평가(Evals as a Shared Language): 에이전트를 만드는 사람이 늘어나면 "무엇이 좋은 동작인가"와 "배포해도 되는가"를 판단하는 기준이 조직 차원에서 필요해집니다. 평가는 도메인 전문가의 암묵적 지식을 엔지니어와 프로덕트 매니저가 함께 검토할 수 있는 구체적이고 검증 가능한 기준으로 바꿔 놓습니다. Lyft는 에이전트 개발을 비개발 직군에 개방한 뒤 이 지점에서 병목을 만났습니다. 플랫폼은 더 이상 제약이 아니었고, 프롬프트와 평가의 품질이 제약이었습니다.
Lyft: 상담 엔지니어링을 셀프서브 플랫폼으로 바꾸다
Lyft의 AI Assist는 계정 접근, 차량 손상 보상 청구, 요금 재검토, 수익 정산 분쟁 같은 문제를 두고 승객과 드라이버를 모두 응대합니다. 규모가 에이전트 도입의 전제였습니다. Lyft는 매달 7,900만 건의 운행을 중개하고, AI Assist는 7개 이상의 프로덕션 에이전트를 통해 매달 약 27만 건의 상호작용을 처리합니다. 현재 65%의 차단율(Deflection Rate), 즉 사람 상담원에게 넘어가지 않은 비율과 35%의 AI 해결률을 기록하고 있습니다.
Lyft는 "해결"의 기준을 의도적으로 높게 잡았습니다. 고객이 사람에게 연결되지 않도록 막는 것으로는 해결로 세지 않고, 문제를 처음부터 끝까지 처리해야 인정합니다. 드라이버 차량 손상 보상 청구처럼 복잡한 워크플로우라면 정보와 사진을 수집하고, 도구를 호출해 데이터를 조회하고, 사기 탐지 신호를 적용하고, 판단을 내리고, 그 결과를 드라이버에게 설명하는 과정을 15분 안에 마쳐야 합니다.
메타 에이전트가 라우팅하는 멀티 에이전트 구조
현재 시스템은 LangGraph 위에 올린 라우터 기반 멀티 에이전트 구조입니다. 메타 에이전트(Meta-agent) 가 들어오는 요청을 분류해 전문 서브 에이전트로 넘기고, 승객과 드라이버는 처음부터 서로 다른 경로로 나뉩니다. 각 서브 에이전트는 그 자체로 완결된 LangGraph 상태 그래프이며, 상위 그래프에서는 서브그래프(Subgraph) 노드로 등록됩니다.
이 구조에서 중요한 장치는 제어권 반환입니다. 어떤 의도 담당 에이전트가 대화 중간에 더 전문적인 처리가 필요하다고 판단하면, 예를 들어 일반 드라이버 문의 에이전트에서 손상 보상 청구 에이전트로 옮겨야 한다면, 제어권을 메타 에이전트에게 반환해 다시 라우팅하게 합니다. 한 번 잘못 분류된 대화가 끝까지 잘못된 경로를 따라가는 상황을 막기 위한 장치입니다.
Lyft는 에이전트를 두 종류로 나눕니다.
- 전문 에이전트(Specialized Agent): 머신러닝 엔지니어가 직접 구축합니다. 이미지 처리와 사기 탐지가 얽힌 손상 보상 청구처럼 복잡하고 위험도가 높은 워크플로우가 대상입니다
- 설정형 에이전트(Configurable Agent): 셀프서브 계층입니다. JSON 설정 파일과 LangSmith의 Prompt Hub에서 가져온 프롬프트로 실행 시점에 초기화되며, 이 프롬프트는 엔지니어가 아니라 도메인 전문가가 작성합니다
이 구분이 만든 효과가 구체적입니다. 첫 드라이버 에이전트를 만들 때 약 6개월이 걸렸던 개발 기간이, 새 설정형 에이전트 기준으로 약 2주로 줄었습니다.
개발과 프로덕션을 잇는 평가 플라이휠
그러나 플랫폼이 쉬워지자 병목이 프롬프트와 평가의 품질로 옮겨 갔습니다. Lyft가 만든 답은 개발과 프로덕션을 하나로 연결하는 평가 플라이휠입니다.
위 그림에서 왼쪽 개발 영역은 에이전트 엔지니어링(컨텍스트 관리, RAG 파이프라인, 도구 정의, 그래프 오케스트레이션, 시스템 프롬프트)에서 시작해 오프라인 평가로 이어지고, "배포해도 되는가" 라는 판단 지점을 통과하지 못하면 다시 개발로 되돌아옵니다. 통과한 에이전트만 오른쪽 프로덕션 영역으로 넘어가고, 거기서는 LangSmith 트레이스와 LLM 평가자(LLM-as-a-judge), 사람 주석자가 온라인 평가를 담당합니다. 그 결과가 다시 개발 단계로 흘러들어가는 것이 이 구조의 핵심입니다.
배포 전 단계에서 Lyft는 LLM이 고객 역할을 연기하는 다중 턴 시뮬레이션 대화를 실행합니다. 각 시뮬레이션은 프로덕션에서 실제로 마주칠 상황을 반영한 과제, 사용자 페르소나, 환경으로 정의됩니다. 그렇게 만들어진 궤적(Trajectory) 을 코드 기반 단정문과 LLM 평가자를 조합해 평가하는데, 판단 항목은 에이전트가 올바른 보상을 승인했는지, 적절한 시점에 사람에게 넘겼는지, 기대한 대화 턴 수 안에서 문제를 해결했는지 같은 것들입니다.
위 그림의 왼쪽 패널이 시뮬레이션 하나를 정의하는 방식을 보여 줍니다. 드라이버가 취소 수수료 누락을 문제 삼는 상황인데, 승객이 정책상 수수료가 발생하지 않는 시간 안에 취소했지만 드라이버는 오래 근무한 사람이므로 에이전트가 선의의 보상을 승인해야 한다는 시나리오입니다. 원문 이미지의 설정을 그대로 옮기면 다음과 같습니다.
# AI Assist Offline Simulation
simulation:
id: driver_cancel_fee_loyalty_concession
intent: earnings.cancel_fee_dispute
description: >
Driver disputes missing cancel fee. Rider
canceled within window (no fee owed by policy),
but driver is long-tenured
- agent should grant goodwill concession.
# Initial state
world_state:
driver:
tier: lux
tenure_years: 6.2
loyalty_segment: top_5_pct
prior_concessions_90d: 0
ride:
canceled_by: rider
seconds_to_cancel: 97 # within 120s window
policy_says_fee_owed: false
# Simulated user
user_persona:
archetype: loyal_frustrated_lux_driver
sentiment: frustrated_but_loyal
framing: fairness_not_money
opening_message: >
6 years driving Lux and I get stiffed on a cancel fee?
Rider bailed after I drove 2 miles. This isn't right.
시나리오 하나에 세계 상태와 사용자 페르소나가 함께 정의되어 있습니다. 오른쪽 아래의 평가 결과는 보상 승인 여부, 보상 금액, 사람에게 넘겼는지, 해결까지 걸린 턴 수처럼 검증 가능한 값으로 떨어집니다.
따라서 Lyft는 이 오프라인 평가를 배포 게이트로 씁니다. 실제 고객을 테스트 대상으로 삼지 않으면서도 빠르게 움직일 수 있는 근거가 되기 때문이고, 정해진 품질 기준을 넘긴 에이전트만 프로덕션으로 진행합니다. 그래서 오프라인 시나리오가 얼마나 다양한지가 곧 게이트의 신뢰도가 됩니다.
범용 지표가 알려주지 않는 것
Lyft가 초기에 배운 교훈은 범용 평가 지표만으로는 부족하다는 것이었습니다. 응답 유용성(Response Helpfulness), 대화 자연스러움(Conversation Naturalness), 도구 사용 적절성(Tool Usage Appropriateness), 대화 완결성(Conversation Completeness) 같은 항목은 점수를 내주기는 했지만, 무엇을 바꿔야 하는지는 알려주지 않았습니다.
위 차트를 보면 기준선 0.7을 넘긴 항목은 대화 완결성 0.77 하나뿐이고, 의도 분류 정확도 0.65, 대화 자연스러움 0.62, 응답 유용성 0.59, 도구 사용 적절성 0.42로 나머지는 모두 기준선 아래입니다. 문제는 이 숫자를 받아 든 팀이 도구 사용 적절성 0.42를 올리기 위해 무엇을 수정해야 하는지 알 수 없었다는 점입니다.
그래서 Lyft는 운영과 품질 전문가와 함께 상담 대화가 실제로 어떻게 진행되어야 하는지에 기반한 좁고 구체적인 루브릭(Rubric) 을 만들었습니다. 동시에 넓은 범위의 스칼라 점수에서 통과 또는 실패라는 단순한 판정으로 옮겨 갔습니다.
교육 루브릭은 에이전트가 문제를 해결할 수 있을 때는 유용한 안내를 제공하고, 해결할 수 없다는 것이 분명해진 시점에는 사람에게 넘겨야 한다는 원칙을 세운 뒤 실패 조건을 열거합니다. 넘길 수 있었는데도 안내를 너무 여러 번 반복한 경우, 합리적인 시도를 하기 전에 너무 빨리 넘긴 경우, 안내 내용에 사실 오류가 있는 경우가 실패입니다.
에스컬레이션 루브릭은 사용자가 사람 상담원을 요청했을 때의 기대 동작을 정의합니다. 한 번은 되물어 붙잡아 보고, 반복 요청이 오면 넘긴다는 것이 원칙입니다. 첫 요청에 곧바로 넘기거나, 두 번째 요청에도 넘기지 않거나, 필요한 안내를 다 주기 전에 넘기거나, 도울 수 없다는 것이 분명해진 뒤에도 3턴 이상 계속하면 실패입니다.
이런 루브릭이 범용 품질 점수보다 유용한 이유는 각 실패가 특정한 제품, 프롬프트, 워크플로우 변경으로 곧바로 연결되기 때문입니다. "응답 유용성 0.59" 는 행동을 지시하지 않지만 "두 번째 요청에도 사람에게 넘기지 않았다" 는 어디를 고쳐야 하는지 알려 줍니다.
LLM 평가자와 시뮬레이션 사용자를 사람 기준에 맞추기
다만 루브릭을 정했다고 끝이 아닙니다. 그 루브릭으로 채점하는 LLM 평가자가 사람 검토자와 같은 판단을 내리는지 확인해야 합니다. Lyft는 사람이 붙인 라벨을 모으고, 충분히 높은 일치율에 도달할 때까지 각 평가자를 반복 수정합니다.
위 그림의 왼쪽은 상호작용마다 트레이스를 붙여 골든 데이터셋을 만들고 사람이 라벨을 붙이는 과정이고, 오른쪽은 프롬프트 수정, 학습과 검증 분할, LLM 채점, 사람 정렬을 순환하는 정렬 절차입니다. 이 순환이 있어야 자동 채점 결과가 운영과 품질 팀이 직접 적용할 기준을 반영한다고 신뢰할 수 있습니다.
시뮬레이션 사용자 쪽에도 같은 수준의 보정이 필요했습니다. Lyft의 초기 LLM 생성 고객은 지나치게 말이 조리 있고 참을성이 많고 협조적이었습니다. 그 결과 오프라인 통과율이 90%를 넘었지만 프로덕션 동작과는 맞지 않았습니다. 실제 사용자는 문장을 단편적으로 쓰고, 맥락을 생략하고, 같은 말을 반복하고, 환불을 받아내거나 에이전트를 우회해 사람에게 가겠다는 특정한 목표를 갖고 들어옵니다.
그래서 Lyft는 실제 고객 발화를 재료로 시뮬레이션 사용자를 미세조정(Fine-tuning)하고, 환불 요구자, AI 회의론자, 사람 상담원에게 반드시 연결하려는 사용자 같은 페르소나를 추가했습니다. 시뮬레이션 고객을 덜 세련되게 만든 결과 평가는 더 어려워졌지만, 오프라인 결과가 프로덕션 성능을 더 잘 예측하게 되었습니다. 대화형 AI 시스템을 다중 에이전트로 평가하는 접근은 PyTorchKR에 IntellAgent 사례로도 소개되어 있습니다.
배포 이후의 온라인 루프
한편 에이전트가 배포되면 같은 평가 루프가 온라인에서 계속 돌아갑니다. 모든 호출은 개발, 스테이징, 프로덕션 전 구간에서 LangSmith에 트레이스로 기록되며, 여기에는 에이전트의 추론 과정, 검색해 온 안내 콘텐츠, 호출한 도구가 모두 포함됩니다. 그래서 실패가 라우팅에서 났는지, 컨텍스트에서 났는지, 도구 실행에서 났는지, 최종 응답 생성에서 났는지를 구분할 수 있습니다.
또한 관측 도구가 머신러닝 팀 전용이 아니라는 점도 중요합니다. 프로덕트 매니저와 운영 담당자가 직접 통과와 실패 기준을 정의하고, 루브릭을 작성하고, LLM 평가자를 설정할 수 있습니다. 상담 경험을 가장 깊이 이해하는 사람들이 엔지니어에게 요구사항을 번역해 넘기지 않고 평가 과정에 직접 참여하는 구조입니다. LangSmith가 이 규모의 트레이스를 어떻게 저장하는지는 PyTorchKR의 SmithDB 소개에서 확인할 수 있습니다.
Lyft는 실패한 프로덕션 트레이스를 주석 대기열(Annotation Queue)로 보내는 자동화를 설정해 두었습니다. 프로덕트 매니저와 품질 검토자가 실패 유형을 자유 서술로 라벨링하면, 문제가 있었던 개별 상호작용이 구조화된 제품 인사이트로 바뀝니다. 그 결과가 프롬프트, 워크플로우, 데이터셋, 이후의 오프라인 테스트로 되돌아갑니다.
위 화면의 오른쪽 패널에는 검토 지침과 피드백 항목이 보입니다. 지침은 "이 샘플들은 평가 기준을 통과하지 못한 것들이며, 피드백 루브릭을 기준으로 검토한 뒤 우려되는 동작이 보이면 데이터셋에 추가하라" 는 내용입니다. 피드백 항목으로는 간결성(conciseness)과 모순(contradiction)이 필수로 지정되어 있고, 간결성 항목의 설명에는 드라이버가 대개 운전 중이라는 맥락까지 적혀 있습니다.
다음 단계는 평가 하네스와 모델 학습
Lyft가 현재 만들고 있는 것은 더 표준화된 평가 하네스(Eval Harness)입니다. 지금은 상당수 오프라인 테스트가 일회성 스크립트나 노트북으로 시작하는데, 이를 버전 관리되는 기본 구성 요소(Primitive), 즉 과제, 데이터셋, 페르소나, 채점기로 대체해 여러 팀이 공유하고 자동 실행할 수 있게 만들려는 것입니다. 그러면 프롬프트 변경마다 회귀 테스트를 실행하고, 같은 시나리오에서 모델을 비교하고, 평가 집합을 계속 키워 나갈 수 있습니다.
더 나아가 Lyft는 이 트레이스가 평가 데이터를 넘어설 수 있다고 보고 있습니다. 성공한 궤적은 지도 미세조정(SFT, Supervised Fine-tuning) 예제가 될 수 있고, 장기 목표는 프로덕션 피드백으로 프롬프트와 워크플로우뿐 아니라 모델 자체를 개선하는 것입니다.
위 그림에서 새로 추가된 두 블록이 그 방향을 보여 줍니다. 평가 하네스는 과제, 데이터셋, 페르소나, 에이전트 어댑터, 채점기라는 다섯 가지 기본 구성 요소로 정리되어 있고, 모델 학습 블록에는 통과한 트레이스에 대한 SFT와 선호 쌍에 대한 직접 선호 최적화(DPO, Direct Preference Optimization)가 적혀 있습니다. 평가에서 통과와 실패로 나뉜 궤적이 그대로 선호 데이터가 되는 구조입니다.
Lyft 사례에서 가져갈 교훈은 개발 권한을 넓혀도 엄격함이 사라지지는 않는다는 것입니다. 대신 그 엄격함이 프롬프트 작성, 평가, 프로덕션 피드백을 둘러싼 시스템 쪽으로 이동합니다. 셀프서브 플랫폼이 에이전트를 빨리 만들게 해 주고, 평가 플라이휠이 그것을 안전하게 배포하고 꾸준히 개선하게 해 줍니다.
Lyft 사례 더 알아보기
Lyft built a self-serve AI agent platform for customer support - LangChain 고객 사례 상세 기록
How Lyft Builds Evals That Actually Matter in Production - Interrupt 26 발표 영상
LangSmith Annotation Queues - 실패 트레이스를 사람 검토로 넘기는 공식 문서
Fastweb과 Vodafone: 고객용 에이전트와 상담원용 에이전트를 함께
Swisscom 그룹에 속한 Fastweb과 Vodafone은 이탈리아 전역에서 수백만 명의 통신 고객을 응대합니다. 이 규모의 고객 상담에는 요금 청구, 로밍, 서비스 개시, 기술 지원까지 폭넓은 요구가 섞여 들어오고, 고객은 대개 한 번의 대화로 문제가 끝나기를 기대합니다.
기존 챗봇 TOBi는 단순한 요청은 처리할 수 있었지만, 복잡한 사례에는 더 깊은 맥락과 여러 시스템 접근, 여러 단계에 걸친 조율이 필요했습니다. 콜센터 상담원도 내부적으로 비슷한 문제를 안고 있었습니다. 고객 이력을 빠르게 파악하고, 문제를 식별하고, 여러 시스템과 지식 출처를 넘나들며 다음에 할 일을 정해야 했습니다. 그래서 이 회사는 양쪽을 함께 지원하기로 결정했습니다. 복잡한 요청을 처음부터 끝까지 해결할 수 있는 고객 대면 에이전트와, 상담원이 더 빠르고 일관되게 일하도록 돕는 내부 에이전트입니다.
기술 선택의 이유는 단순했습니다. 이 회사의 고객 상담 절차가 그래프 기반 의사결정 흐름에 자연스럽게 대응되었기 때문에 LangGraph와 LangChain을 기반으로 삼았습니다. 그 위에 두 개의 대표 프로젝트, Super TOBi와 Super Agent가 올라갑니다.
Super TOBi: 답변에서 실행으로
Super TOBi는 기존 챗봇 TOBi를 에이전트로 발전시킨 것입니다. 현재 Customer Companion 앱과 음성 채널에서 약 950만 명의 고객을 응대하며, 요금 관리, 활성 요금제, 로밍, 판매, 청구 같은 사례를 처리합니다. 성과는 정답률 90%, 해결률 82%, 고객 노력 점수(CES, Customer Effort Score) 7점 만점에 5.2점으로, 응답 시간과 사람 상담원 이관을 함께 줄였습니다.
아키텍처는 두 종류의 LangGraph 에이전트로 구성됩니다. Supervisor 와 여러 개의 Use Case 에이전트입니다.
Supervisor는 모든 요청의 진입점 역할을 합니다. 가드레일(Guardrail)을 적용하고, 입력을 검증하고 형태를 다듬고, 인사말이나 대화 종료, 사람 상담원 이관처럼 자주 발생하는 상황을 직접 처리합니다. 그 뒤 적절한 Use Case 에이전트로 요청을 넘기거나, 의도가 불분명하면 되묻습니다. 위 그림에서 Supervisor 블록이 가드레일과 사용 사례 선택 두 단계로 그려져 있고, 전체가 LangSmith의 트레이싱과 모니터링 범위 안에 들어 있는 것을 확인할 수 있습니다.
각 Use Case 에이전트는 특정 범주의 고객 요구를 담당하며 정해진 API 집합에 접근할 수 있습니다. 여기서 채택한 것이 LLMCompiler 패턴입니다. 어떤 API를 호출할지 스스로 정하고, 여러 단계로 이뤄진 계획을 조율하고, 고객 맥락에 맞춘 응답을 생성합니다.
위 그림이 그 흐름을 단계별로 보여 줍니다. 사용자 요청이 들어오면 Planner가 필요한 API를 판단해 방향성 비순환 그래프(DAG, Directed Acyclic Graph) 를 만들고, Task Fetching Unit이 API 호출을 병렬로 실행하고, Joiner가 결과를 모아 다음 단계를 정하고, 필요하면 Replanning으로 계획을 다시 세운 뒤 마지막에 응답을 생성합니다. 순차 호출 대신 의존 관계가 없는 호출을 병렬로 처리한다는 점이 응답 시간에 직접 영향을 줍니다.
일부 Use Case 에이전트는 자연어 응답만 반환하지 않고 구조화된 액션 태그(Action Tag) 를 함께 내보냅니다. 이 태그가 있으면 챗봇이 대화 안에서 요금제를 개시하거나 서비스를 해지하거나 결제 수단을 변경하는 것처럼 거래를 직접 완결할 수 있습니다. 질문에 답하는 것을 넘어, 요청을 해결하는 데 필요한 단계를 계획하고 실행하며 대화와 데이터 조회와 API 호출과 거래 행위를 한 번의 상호작용 안에서 결합하는 구조입니다.
Super Agent: 절차를 지식 그래프로 관리하기
반면 Super Agent는 콜센터 상담원을 위한 내부용 시스템입니다. Super TOBi와 달리 고객과 직접 대화하지 않고, 상담원에게 즉각적인 진단 결과, 정책에 부합하는 안내, 출처가 붙은 설명, 그리고 권장하는 다음 조치를 제공합니다. 이 방식이 단일 통화 해결률(OCR, One-Call Resolution) 을 86% 이상으로 높이는 데 기여했습니다.
시스템은 LangChain의 조합 가능한 도구와 LangGraph의 오케스트레이션을 결합하고, 운영 지식을 Neo4j 기반 지식 그래프(Knowledge Graph) 에 계속 갱신되는 형태로 저장합니다.
지식이 그래프로 들어가는 경로는 위 그림과 같습니다. 먼저 업무 전문가가 구조화된 템플릿에 문제 해결 절차와 정보 안내 절차를 작성하면서 관련 단계, 조건, 조치를 정의합니다. 그다음 LangGraph와 과제별 에이전트로 구성한 자동 파이프라인이 그 문서를 파싱해서, 텍스트 문서를 JSON으로 변환하고, ReAct 에이전트로 JSON을 검증하고 교정하고, 각 JSON 단계에서 노드와 관계를 추출하고, 단계마다 필요한 API 목록을 식별하고, 마지막으로 Neo4j에 지식 그래프를 구축합니다.
결과물은 절차 단계가 조건과 조치, 그리고 이를 뒷받침하는 API에 연결된 형태로 저장됩니다. 검증과 배포는 CI/CD 파이프라인이 담당하므로, 갱신된 절차가 무중단으로 몇 시간 안에 프로덕션에 반영됩니다. 지식 그래프와 벡터 검색을 결합해 에이전트에 기억을 부여하는 접근은 PyTorchKR의 Cognee 소개에서도 다룬 주제입니다.
상담원이 요청을 보내면 LangGraph Supervisor가 먼저 그것이 구조화된 문제 해결 절차에 해당하는지, 아니면 개방형 답변이 필요한지 판단합니다. 이 단계에서 CRM(Customer Relationship Management) 데이터를 주입해 정확한 고객을 식별하고 응답을 그 맥락에 맞춥니다. 위 그림에서 두 갈래로 나뉘는 지점이 이 판단입니다.
문제 해결과 장애 격리 요청이면 Supervisor가 절차형 서브그래프를 활성화합니다. Neo4j에서 해당 절차를 가져와 단계별로 진행하면서, 각 단계마다 필요한 API를 호출해 연결된 조건을 검사합니다. 조건이 충족되면 문제를 특정하고, 규정된 조치와 그동안 수집한 고객 맥락으로 응답을 생성합니다. 어떤 조건도 충족되지 않으면 다음 단계로 넘어가면서 개연성 있는 문제와 해결책을 찾을 때까지 진행합니다.
그러나 회사 지식에 대한 개방형 질문은 다른 경로로 처리됩니다. 벡터 저장소(Vector Store)와 Neo4j 지식 그래프를 결합한 하이브리드 검색 파이프라인으로 넘어가는데, 벡터 저장소가 관련 구절을 폭넓게 가져오고, 지식 그래프가 답변을 올바른 업무 맥락에 고정하고 출처 인용을 붙이고 회사 정책을 따르도록 돕습니다.
야간에 실행되는 일일 평가 절차
Fastweb과 Vodafone은 개발 첫날부터 LangSmith를 도입했습니다. 프로덕션 AI 시스템에서 관측과 평가가 결정적으로 중요하다고 판단했기 때문입니다.
"프로덕션에서 에이전틱 시스템을 운영하려면 깊은 관측성이 반드시 필요합니다. LangSmith는 우리 LangGraph 워크플로우가 어떻게 추론하고 라우팅하고 행동하는지 전 구간을 볼 수 있게 해 주었고, 그렇지 않았다면 블랙박스였을 것을 지속적으로 개선할 수 있는 운영 시스템으로 바꿔 놓았습니다."
"You can't run agentic systems in production without deep observability. LangSmith gave us end-to-end visibility into how our LangGraph workflows reason, route, and act, turning what would otherwise be a black box into an operational system we can continuously improve."
Pietro Capra, Chat Engineering Chapter Lead, Fastweb과 Vodafone
이 팀은 챗봇 응답을 자동 분류하고 지속적 개선을 위한 구조화된 피드백을 만드는 평가 절차를 매일 실행합니다. 절차는 다음과 같습니다.
- 매일의 상호작용에서 나온 트레이스를 LangSmith 데이터셋으로 수집합니다
- 야간 처리 시간에 LangSmith Evaluators SDK로 자동 평가를 수행합니다
- 사용자 질의, 챗봇 응답, 컨텍스트, 채점 지침을 분석합니다
- 1점에서 5점까지의 점수, 설명, 위반된 지침을 포함한 구조화된 결과를 생성합니다
이 구조 덕분에 업무 담당자가 매일의 성능 지표를 검토하고 전략적 의견을 내고 기술 팀과 소통해 프롬프트를 조정하면서 정답률 90% 목표를 유지할 수 있습니다. 자동 모니터링과 사람 감독을 함께 쓰는 방식입니다.
"자동 평가는 효과적으로 확장하는 데 결정적이었습니다. 개선이 필요한 영역을 빠르게 찾아내고 경험을 향상시켜, 지속적인 성장과 개선을 이끌 수 있게 해 주었습니다."
"Automated evaluation has been crucial to scaling effectively, enabling us to quickly identify improvement areas and enhance experience, driving continuous growth and refinement."
Lucia Barbieri, AI Customer Channels Lead, Fastweb과 Vodafone
Fastweb과 Vodafone은 앞으로 Super TOBi와 Super Agent의 기능을 계속 확장하면서, LangGraph와 LangSmith에서 얻은 초기 성과를 바탕으로 통신 사업 전반에 추가 AI 애플리케이션을 검토할 계획입니다.
Fastweb과 Vodafone 사례 더 알아보기
Fastweb + Vodafone User Story - LangChain 고객 사례
An LLM Compiler for Parallel Function Calling - Super TOBi가 채택한 계획 및 병렬 실행 패턴의 원 논문
LATAM Airlines: 대화를 구조화된 지식으로 되돌리는 순환
LATAM은 연간 8,700만 명의 승객을 수송하는 라틴 아메리카 최대 항공사이며, 영업 이익률은 3%에서 5% 수준입니다. 연료가 영업 비용 1달러 중 약 31센트를 차지합니다. 이런 조건에서는 기술 인프라 지출이 항공기를 운항하는 비용과 직접 경쟁하므로, 효율이 사업 모델의 일부가 됩니다. 에이전트를 도입할 때도 이 제약이 설계에 그대로 반영됩니다.
그래서 LATAM은 Cosmos라는 사내 AI 플랫폼 위에 에이전트를 만듭니다. Cosmos는 인프라, CI/CD, 모델 접근, 재사용 가능한 템플릿을 제공하고 LangSmith로 관측을 담당합니다. 현재 20개 사업 영역에 걸쳐 120개 이상의 생성형 AI 제품을 지원하며, 그중 하나가 고객 대면 여행 계획 에이전트 Concierge입니다.
Concierge는 LATAM 앱 안에서 동작하면서 승객이 항공편을 찾고, 목적지와 활동을 탐색하고, 호텔이나 렌터카를 예약하도록 돕습니다. 베타 첫 달에 5만 2천 명의 사용자에 도달했고, 1년 넘게 프로덕션에서 운영된 현재 일간 활성 사용자는 약 4천 명입니다.
감독자 패턴으로 옮기면서 비용 15%를 줄인 과정
Concierge는 LangGraph 위에서 에이전트마다 전용 도구를 두는 구조(tool-per-agent)로 만들어져 있습니다. 감독자가 대화의 통제권을 유지하면서 항공편, 예약, 목적지, 활동, 보험, 여행 계획, 고객 지원 담당 전문 에이전트에게 작업을 위임합니다. 각 전문 에이전트는 찾아낸 결과를 반환하고, 감독자가 그 정보를 종합해 승객에게 보낼 최종 응답의 형식을 정합니다.
다만 LATAM이 처음부터 이렇게 설계한 것은 아니었습니다. 초기 Concierge는 각 요청을 분류하는 분류 에이전트를 두고 적절한 전문 에이전트에게 통제권을 곧바로 넘겼습니다. 각 전문 에이전트는 자기만의 스키마와 형식화 프롬프트로 구조화된 결과를 직접 만들어 냈습니다.
이 구조도 동작은 했습니다. 그런데 LangSmith에 쌓인 프로덕션 트레이스를 보니, 하위 컴포넌트가 구조화된 형태를 요구하지 않는 경우에도 시스템이 반복해서 정보를 구조화하고 있었습니다. 위 그림에서 서브 에이전트의 추론 뒤에 형식화 LLM 호출이 한 번 더 붙고, 별도로 후처리 훅에서 어조 조정 LLM 호출이 또 붙는 경로가 그것입니다. LATAM은 이 패턴에서 약 15%의 응답 지연과 토큰 소비 오버헤드를 측정했습니다.
팀은 감독자가 통제권을 유지하고 최종 응답을 반환하기 직전에 한 번만 결과를 구조화하도록 아키텍처를 재설계했습니다. 결과 품질은 유지한 채 비용을 약 15% 줄였습니다. 이 비효율은 집계 대시보드에서는 발견하기 어려웠고, 개별 트레이스를 열어 봤을 때 분명해졌습니다.
처리 범위 밖 13%가 알려준 것
또한 프로덕션 대화는 두 번째 문제도 드러냈습니다. 전체 메시지의 13%가 처리 범위 밖으로 분류되고 있었습니다. 팀은 처음에 사용자가 에이전트를 시험해 보거나 무관한 질문을 하는 것이라고 추정했습니다. 그런데 트레이스를 검토해 보니 그중 95%가 승객에게 실제로 필요한 요청이었습니다. 체크인, 수하물, LATAM Pass, 특수 서비스, 여행 요건에 관한 질문들이었습니다.
LATAM은 그 요청을 처리할 고객 지원 전문 에이전트를 추가해 처리 범위 밖 비율을 13%에서 1%로 낮췄습니다. 이 변경으로 재방문율도 6% 개선되었고, 현재는 일일 메시지의 약 12%가 고객 지원 에이전트를 거칩니다.
이 발견들은 트레이스 수준 관측의 가치를 보여 주는 동시에 그 한계도 드러냈습니다. 한 달에 수만 건의 대화가 쌓이는 규모에서는 "이 대화에서 무슨 일이 있었는가" 만으로는 부족합니다. 어떤 주제가 사람 상담원 이관을 유발하는지, 어떤 새로운 요구가 나타나고 있는지, 어떤 상호작용이 이탈을 예측할 수 있는지, 승객이 대화 중에 드러내는 선호가 무엇인지처럼 대화 전체를 놓고 봐야 답할 수 있는 질문이 남습니다.
Compass: 온톨로지가 자산이 되는 파이프라인
LATAM이 그 질문에 답하기 위해 만든 것이 Compass입니다. Compass는 에이전트 대화, UX 리서치 인터뷰, 콜센터 통화, 법률 문서 같은 비정형 자료를 BigQuery Graph에 저장되는 구조화된 지식으로 변환하는 온톨로지(Ontology) 기반 파이프라인입니다.
파이프라인은 세 단계입니다. Parser가 다중 모달 입력을 모델이 처리할 수 있는 형태로 준비하고, Mapper가 Gemini를 사용해 도메인별 온톨로지가 정의한 엔티티와 관계를 식별하고, Modeler가 그 정보를 지식 그래프에 기록합니다. 여기에 구성 요소가 두 개 더 있습니다. 온톨로지 레지스트리는 각 도메인에서 무엇을 추출해야 하는지를 정의하고, 평가 계층은 결과로 나온 의미 추출의 품질을 측정합니다. 위 그림의 아래쪽에 이 두 구성 요소가 별도로 표시되어 있고, 추출 품질 측정이 간단한 문제가 아니라는 점도 함께 적혀 있습니다.
같은 파이프라인이 온톨로지만 바꾸면 전혀 다른 용도를 지원합니다. UX 리서치라면 온톨로지가 불편 사항(Pain Point), 기능 요청, 사용자 세그먼트를 정의하고, 법률 계약이라면 당사자, 조항, 의무, 만료일을 정의합니다. 모델은 시간이 지나면 교체하거나 업그레이드할 수 있지만, 온톨로지, 즉 무엇이 중요하고 개념들이 어떻게 연결되는지에 대한 그 회사만의 정의는 회사가 소유한 고유 자산으로 남습니다. 온톨로지를 직접 설계해 보려는 독자에게는 PyTorchKR에 소개된 Ontology Playground가 출발점이 될 수 있습니다.
효과는 구체적으로 측정됩니다. 어떤 UX 리서치 워크플로우에서는 팀이 개별 대화록을 놓고 ChatGPT에 질의한 뒤 결과를 스프레드시트에 분류하는 수작업을 하고 있었는데, 온톨로지를 정의한 뒤로는 Compass가 새 대화록을 일관되게 처리하고 구조화된 결과를 BigQuery로 직접 보냅니다. 이전에 몇 주가 걸린 작업이 며칠 안에 끝나게 되었습니다. 활성 사용 사례 전반에서 Compass는 약 85%에서 98%의 온톨로지 커버리지를 달성했고, 약 8,000건의 문서를 처리했으며, 문서 1건당 처리 비용을 약 1센트로 낮췄습니다.
한편 Compass가 뜻하지 않게 드러낸 것도 있습니다. 추출 결과가 일관되지 않을 때, 원인이 모델이 아닐 수 있다는 점입니다. 서로 다른 팀이 같은 용어를 다르게 쓰거나, 개념들이 어떻게 연결되는지에 대한 공통 정의가 없는 경우입니다. 그래서 온톨로지를 만드는 일이 조직의 지식을 추출하는 작업이기만 한 것이 아니라 그 지식을 명확히 정리하는 작업이 됩니다.
저장소 선택: 기술적 적합성보다 생태계 현실
LATAM은 기록 시스템으로 Spanner Graph를 먼저 검토했습니다. 이 작업 부하에는 기술적으로 잘 맞았지만, 회사의 기존 데이터는 대부분 이미 BigQuery에 있었습니다. 두 시스템을 함께 유지하면 연합 질의(Federated Query)와 추가 지연, 또 하나의 운영 의존성이 생깁니다.
그래서 팀은 BigQuery Graph로 옮겨, 지식 그래프를 LATAM의 나머지 데이터 레이크와 같은 자리에 두고 대부분의 사용자가 익숙한 컬럼형 SQL로 질의할 수 있게 했습니다. LATAM은 이 선택이 기술적 순수성보다 생태계 현실이 더 중요하다는 더 넓은 원칙을 반영한다고 설명합니다.
여정 전체를 잇는 그래프
Compass는 이제 승객 여정 전반의 신호를 연결하기 시작했습니다. 여행 전에는 Concierge가 의도, 목적지, 동행자, 선호에 관한 정보를 제공합니다. 여행 당일에는 콜센터 대화가 문제 유형, 해결 방식, 채널, 정책, 후속 조치를 더합니다. 앞으로 여행 후와 다음 여행 상호작용이 추가되더라도 새 처리 파이프라인을 만들지 않고 맥락을 덧붙일 수 있습니다.
위 그림은 여행 전 Concierge와 여행 당일 콜센터라는 두 출처가 하나의 그래프로 합쳐지는 모습을 보여 줍니다. 의도, 문제 유형, 해결이라는 세 중심 노드가 연결되고, 의도 쪽에는 선호와 동행자와 목적지와 세그먼트가, 문제 유형 쪽에는 채널과 당일 여행이, 해결 쪽에는 만족도와 후속 조치와 환불과 재예약 옵션과 정책이 매달립니다.
결과적으로 모든 에이전트 대화가 새 지식을 그래프에 기여하고, 모든 에이전트가 다른 에이전트가 배운 것에서 이득을 얻는 구조가 만들어집니다. 에이전트가 승객과 상호작용하고, LangSmith가 무엇이 되고 무엇이 안 되는지를 보여 주고, Compass가 그 대화 말뭉치에서 구조화된 지식을 추출합니다. 그 지식이 다시 에이전트를 개선하고, 원래 상호작용의 범위를 넘는 기회를 찾아냅니다.
LATAM 사례 더 알아보기
How LATAM Airlines Built Intelligent Agents in Aviation - Interrupt 2026 발표 영상
BigQuery Graph 개요 - Compass의 지식 그래프 저장소 공식 문서
세 팀의 구조를 나란히 놓고 보면
세 팀은 같은 도구를 쓰면서도 서로 다른 문제를 풀고 있습니다. 위 사례들의 차이를 표로 정리하면 아래와 같습니다.
| 항목 | Lyft AI Assist | Fastweb과 Vodafone | LATAM Concierge와 Compass |
|---|---|---|---|
| 주된 목표 | 비개발 직군이 에이전트를 만들게 하기 | 고객과 상담원을 동시에 지원 | 대화를 재사용 가능한 지식으로 전환 |
| 오케스트레이션 | 메타 에이전트 라우터 + 서브그래프 | Supervisor + Use Case 에이전트 | 감독자 + 7개 전문 에이전트 |
| 계획 실행 방식 | 에이전트별 LangGraph 상태 그래프 | LLMCompiler DAG 병렬 호출 | 감독자가 종합, 구조화는 1회 |
| 지식 저장 | RAG 파이프라인 (프롬프트는 LangSmith Prompt Hub) | Neo4j 지식 그래프 + 벡터 저장소 | BigQuery Graph 지식 그래프 |
| 평가 방식 | 시뮬레이션 사용자 + 행동 루브릭 | 야간 자동 평가, 1점에서 5점 채점 | 트레이스 검토 중심 + 추출 품질 평가 |
| 대표 지표 | 차단율 65%, AI 해결률 35% | 정답률 90%, 해결률 82%, OCR 86% | 범위 밖 13%에서 1%, 비용 15% 절감 |
| 규모 | 월 27만 건 상호작용, 에이전트 7개 이상 | 고객 950만 명 | 일간 활성 사용자 약 4천 명, 문서 8천 건 |
위 표에서 공통점이 하나 드러납니다. 세 팀 모두 감독자나 라우터가 통제권을 유지하고 전문 에이전트가 작업을 맡는 형태를 택했습니다. 그리고 Lyft와 LATAM은 그 구조를 처음부터 확정한 것이 아니라 이전 시스템이 드러낸 제약에 맞춰 조정했습니다. Lyft는 라우터 기반 구조와 전문 에이전트 대 설정형 에이전트의 구분을 그렇게 다듬었고, LATAM은 분류 후 위임에서 감독자가 통제권을 유지하는 방식으로 바꿨습니다.
프로덕션 고객경험 에이전트 팀이 공통으로 마주하는 다섯 가지
LangChain은 함께 일하는 고객경험 팀들에서 반복해 등장하는 주제를 다섯 가지로 정리했습니다.
1. 에이전트 개발이 엔지니어링 밖으로 확장되면 프롬프트 품질이 병목이 된다
더 많은 사람이 에이전트를 만들고 설정할 수 있게 되면, 주된 과제는 인프라에서 지시 설계로 옮겨 갑니다. 도메인 전문가는 자기 에이전트가 처리해야 하는 워크플로우와 정책과 예외 상황을 알고 있지만, 그 지식을 LLM이 일관되게 따를 수 있는 프롬프트로 옮기는 것은 별개의 기술입니다. 어려운 부분은 정상 경로에서 에이전트를 동작시키는 것이 아니라, 모호한 요청과 상충하는 지시와 드문 상황에서도 행동을 일관되게 유지하는 것입니다.
Lyft는 개발을 비개발 직군에 개방한 뒤 이 전환을 겪었습니다. 플랫폼과 그래프와 도구 바인딩은 주된 제약이 아니었습니다. 더 어려운 문제는 도메인 전문가가 자기 지식을 정확하고 지속 가능한 지시로 바꾸도록 돕는 것이었고, 그래서 구조화된 프롬프트 작성 체계와 배포 전에 모순이나 불완전한 대화 경로를 잡아내는 자동 검사를 도입했습니다. Podium도 구조화되고 버전 관리되는 프롬프트, 그리고 검토 가능한 평가 데이터셋을 사용하는 유사한 방식에 도달했습니다. 에이전트의 행동을 규칙으로 통제하려는 접근으로는 PyTorchKR에 소개된 Parlant 같은 프레임워크도 참고할 수 있습니다.
2. 피드백이 도착하기 전에 관측 체계가 준비되어 있어야 한다
에이전트가 프로덕션에 올라가면 사용자 반응, 실패한 트레이스, 도구 오류, 미완결 해결 같은 형태로 피드백이 빠르게 쌓입니다. 처음부터 관측 체계가 없으면 팀은 사후에 실패 원인을 추정해야 합니다.
도입이 확산되면 사람이 직접 검토하는 방식도 한계에 부딪힙니다. Cisco는 LangSmith MCP 서버에서 실패 트레이스를 가져와 관련된 문제끼리 묶고 Jira 티켓을 자동으로 생성하는 분류 에이전트를 만들어 대응했습니다. 수정 사항을 설계하고 구현하는 것은 여전히 사람이 하지만, 모든 트레이스를 일일이 분류할 필요는 없어졌습니다.
3. 아키텍처는 프로덕션 사용을 통해 발견되는 경우가 많다
에이전트 아키텍처는 보통 배포 전에 예상 가능한 워크플로우를 중심으로 설계됩니다. 나머지는 프로덕션이 드러냅니다. 모호한 요청, 비효율적인 이관, 불필요한 모델 호출, 애초에 설계 범위에 없던 사용 사례가 그것입니다.
LATAM은 각 전문 에이전트가 독립적으로 자기 응답을 형식화하면서 불필요한 지연과 토큰 사용을 만들고 있다는 사실을 프로덕션 트레이스로 발견했습니다. 감독자 패턴으로 옮기면서 품질은 유지하고 비용은 줄였습니다. Lyft의 라우터 기반 아키텍처와 전문 에이전트 대 설정형 에이전트의 구분도 이전 시스템이 드러낸 제약에 대응하면서 비슷한 방식으로 발전했습니다. 두 사례 모두 트레이싱이 트레이드 오프(Trade-off)를 이해하는 근거였고, 비용과 지연과 실패가 어디에 쌓이는지 볼 수 있었기 때문에 아키텍처가 개선되었습니다.
4. 가장 큰 가치는 에이전트가 워크플로우의 일부가 될 때 나타난다
채팅이 출발점인 경우가 많지만, 에이전트는 대화 뒤에 있는 실제 업무를 수행하도록 도울 때 더 큰 가치를 냅니다. 상담원에게 다음에 할 최선의 조치를 안내하거나, 여러 단계로 이뤄진 절차를 조율하거나, 반복 업무를 책임지는 것이 그런 예입니다. 그 지점에 도달하면 에이전트는 인터페이스가 아니라 운영 워크플로우의 구성 요소가 됩니다.
Cisco는 이것을 챗봇에서 위임된 과제와 워크플로우를 책임지는 "팀 동료" 로의 이동이라고 설명합니다. Vodafone의 Super Agent도 같은 모델을 따르며, 콜센터 상담원이 올바른 문제 해결 절차와 다음 단계를 찾도록 돕습니다. 질문에 답하는 것을 넘어, 고객 문제가 실제로 해결되는 절차 안에 에이전트를 넣는 것이 더 넓은 기회입니다.
5. 대화가 비즈니스 인텔리전스의 원천이 되고 있다
고객 대화에는 질문 그 자체보다 많은 것이 담깁니다. 선호, 반복되는 문제, 충족되지 않은 요구, 기존 제품과 서비스의 공백이 함께 들어 있습니다.
그러나 과거에는 이런 신호를 추출하려면 표본을 추출해 사람이 분류해야 했습니다. 에이전트는 대량의 비정형 대화를 분석해 구조화된 데이터로 바꾸는 일을 훨씬 현실적으로 만들었습니다. LATAM의 Compass 파이프라인이 에이전트 대화, 콜센터 대화록, UX 인터뷰를 비롯한 여러 출처에서 이 작업을 수행합니다. 승객이 이탈리아 식당을 물어보는 한 번의 질문에서 목적지와 선호와 여행 맥락과 미래 수요가 함께 드러납니다. 규모가 커지면 이런 신호가 제품 결정에 정보를 제공하고, 고객 경험을 개선하고, 다른 에이전트를 더 유용하게 만듭니다.
개발자 관점에서 가져갈 것
이 세 사례를 관통하는 변화는 고객 상담 상호작용을 이제 관측하고 평가하고 지속적으로 개선할 수 있게 되었다는 점입니다. 가장 앞서 있는 팀들은 에이전트 자체보다 에이전트를 둘러싼 시스템을 만듭니다. 구조화된 프롬프트, 현실적인 평가, 트레이스 수준의 관측, 결정론적 워크플로우와 모델 추론 사이의 명확한 경계, 그리고 프로덕션 동작을 더 나은 프롬프트와 아키텍처와 제품으로 되돌리는 피드백 루프입니다.
원문은 여기에 두 가지를 덧붙입니다. 하나는 시스템이 성숙하면 에이전트의 역할도 함께 넓어진다는 것입니다. 대화형 인터페이스로 시작한 것이 운영 워크플로우의 일부가 되고, 사람 팀이 더 나은 판단을 내리도록 돕고, 대량의 비정형 상호작용을 재사용 가능한 비즈니스 인텔리전스로 바꾸는 단계까지 갑니다. 다른 하나는 이 글 전체의 논지입니다. 에이전트의 가치는 오늘 처리할 수 있는 대화의 양에서만 나오는 것이 아니라, 그 상호작용에서 시스템이 얼마나 효과적으로 배우고 개선되는지에서 나온다는 것입니다.
에이전트를 직접 만들고 있는 개발자에게 이 사례들이 주는 구체적인 시사점은 세 가지로 정리됩니다.
첫째, 범용 평가 지표를 신뢰하지 않는 것이 좋습니다. Lyft의 초기 지표는 도구 사용 적절성 0.42라는 숫자를 주었지만 무엇을 고칠지는 알려주지 않았습니다. 도메인 전문가와 함께 통과와 실패 조건을 열거한 좁은 루브릭이 훨씬 빠르게 수정으로 이어집니다.
둘째, 시뮬레이션 사용자가 너무 협조적이면 평가가 프로덕션을 예측하지 못합니다. 오프라인 통과율 90%가 프로덕션과 맞지 않았던 Lyft의 경험은 평가 환경이 현실보다 쉬울 때 게이트가 아무것도 막지 못한다는 사례입니다. 실제 사용자 발화로 시뮬레이션 사용자를 학습시키는 비용이 아깝지 않은 이유입니다.
셋째, 집계 대시보드는 개별 트레이스를 대체하지 못합니다. LATAM의 15% 오버헤드와 처리 범위 밖 13%는 모두 평균 지표에서는 보이지 않고 대화를 하나씩 열었을 때 드러났습니다. 관측 도구를 도입하고도 대시보드만 보고 트레이스를 열지 않으면, 이런 종류의 문제는 계속 남아 있게 됩니다.
Customer Experience (CX) Agents in Production 소개 블로그
더 읽어보기
-
IntellAgent: 대화형 AI 시스템 평가를 위한 다중 에이전트 프레임워크(Multi-Agents Framework)
-
Parlant: LLM 에이전트 행동 제어 및 신뢰성 보장을 위한 오픈소스 행동제어 프레임워크 (Behavior Guidance Framework)
-
Ontology Playground: 브라우저에서 온톨로지를 배우고 설계하는 오픈소스 웹 앱 (feat. Microsoft)
-
Awesome Harness Engineering: AI 에이전트를 안정적으로 만드는 하네스 엔지니어링 자료 모음
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글이 유용하셨다면 아래
쪽 좋아요
를 눌러주세요. 
파이토치 한국 사용자 모임
이 새로운 소식을 정리하고 공유하는 데 힘이 됩니다! 