답을 찾아 주던 봇이 일을 끝낸다, Agentic AICC

"보험금 청구 진행 상황은 앱에서 확인하실 수 있습니다." 봇이 이렇게 답하면 고객은 앱을 연다. 봇은 답을 찾아 준 것이고, 일은 고객이 한다. 올해 4월에 왜 지금 컨택센터를 다시 설계하는가를 쓰면서 나는 컨택센터의 세 단계를 연결, 이해, 행동이라고 불렀다. 

전화를 맞는 팀에 연결하는 단계가 IPCC이고, 고객이 무엇을 묻는지 알아듣는 단계가 AICC이고, 알아들은 뒤에 청구 건을 조회하고 서류를 안내하고 콜백을 잡는 단계가 그다음이다. 그다음 단계에 붙는 이름이 에이전틱 AICC(스스로 움직이는 인공지능 컨택센터, Agentic AICC)다. 

답을 찾는 단계에서 일을 끝내는 단계로 넘어가는 것, 그것이 이 말의 본질이다. 이 글은 그 봇이 전화의 길 위 어디에 서고, 안에서 무엇이 돌고, 어디에서 사람이 끼어드는지를 번호를 매겨 따라간다.

지난 글에서 챗봇의 한 턴은 말을 받고, 뜻을 고르고, 다음을 정하고, 답을 내는 네 상자였다. 일을 끝내는 봇은 그중 셋째 상자가 달라진다. 사람이 그려 둔 흐름도에서 다음 상자를 고르는 대신, 목표를 받아 스스로 계획을 세우고 도구를 부르고 결과를 보고 다시 계획한다. 전화가 지나는 길은 그대로다. 고객이 대표번호를 누르면 통신사 지능망과 교환기와 CTI를 지나 IVR에 닿고, IVR이 버튼 대신 말을 받기로 하면 게이트웨이를 거쳐 봇 엔진에 들어오고, 봇이 끝내면 종료하고 못 끝내면 상담사에게 돌아간다. 이 글에서는 그 길을 1부터 9로 두고, 봇 엔진 안쪽에 10부터 14를 더한다.

열네 단계, 봇 엔진 안에 다섯 단계가 더 생긴다

⑩ 봇 엔진 → 오케스트레이터. 봇이 고객의 말에서 뜻을 골랐다. 그런데 그 뜻이 안내 한 문장으로 끝나지 않는다. "실손 청구 서류를 냈는데 보완 요청이 왔어요"가 그런 말이다. 왜 보완 요청이 왔는지 조회해야 하고, 무엇이 빠졌는지 안내해야 하고, 다시 낼 서류를 접수해야 한다. 이때 봇 엔진은 시나리오의 다음 상자를 고르는 대신, 그 말을 목표 한 문장으로 바꿔 오케스트레이터(지휘자, orchestrator)에게 넘긴다. "이 고객의 청구 건에서 무엇이 부족한지 알아내고 다음 할 일을 끝내라." 지휘자가 필요한 이유는 간단하다. 시나리오는 사람이 미리 그려 둔 길만 간다. 조회해 봐야 할 일이 정해지는 목표는 길을 미리 다 그릴 수 없다.

⑪ 오케스트레이터 → 도구. 지휘자는 목표를 받으면 계획을 세우고 첫 칸을 정한다. 첫 칸은 대개 조회다. 그 조회를 실제로 하는 것이 도구다. 상담 프로그램이 API(응용 프로그램 접속 규격, application programming interface)로 열어 둔 조회와 처리 기능 하나하나가 도구이고, 청구 건 조회, 서류 접수 케이스 생성, 콜백 예약이 각각 도구 하나다. 지휘자가 도구를 부르는 것을 도구 호출(tool call)이라 부른다. 에이전트는 스스로 아무것도 하지 못한다. 할 수 있는 일은 열린 도구의 목록까지다. 그래서 봇을 들이기 전에 상담 프로그램의 어떤 기능이 API로 열려 있는지를 먼저 본다. 봇은 센터의 보안망 안으로 들어가지 않는다. 센터가 안에서 API를 만들어 규격을 주면 봇이 그것을 쓴다. 처음부터 API가 열리는 센터는 드물다. 그래서 파일을 올려 돌리는 시험 운영을 먼저 하고, 효과를 본 뒤에 연동으로 가는 두 단계가 흔하다.

⑫ 결과 확인 → 다시 계획. 도구가 답을 돌려주면, 또는 정해진 시간 안에 돌려주지 않으면 지휘자가 결과를 읽는다. 읽은 뒤에 계획의 다음 칸을 정한다. 조회한 청구 건에 서류가 빠져 있으면 다음 칸은 서류 안내다. 조회가 실패했으면 다른 조건으로 다시 조회하거나, 그 일을 포기하고 사람에게 넘기는 쪽으로 계획을 바꾼다. 이 되돌아오는 화살표가 시나리오와 에이전트를 가르는 선이다. 시나리오는 실패하면 멈추거나 폴백으로 간다. 에이전트는 실패를 읽고 다시 계획한다. 정해진 시간 안에 답이 없을 때 무엇으로 돌아갈지도 여기서 정해 둔다. 시나리오가 원래 하던 답으로 돌아가고, 그런 일이 얼마나 잦은지 기록한다.

⑬ 사람 승인 구간. 계획의 다음 칸이 되돌리기 어려운 일이면 지휘자는 실행하기 전에 멈춘다. 케이스를 만들고, 콜백을 잡고, 계약을 바꾸는 일이 그렇다. 고객에게 "추가 서류 접수 케이스를 만들고 담당자 콜백을 내일로 잡겠습니다, 맞으세요"라고 묻고 분명한 답을 받는다. 센터 안에서는 상담사가 승인하는 구간을 둘 수도 있다. 멈추는 이유는 알아듣는 것도 틀릴 수 있고 계획도 틀릴 수 있어서다. 승인 구간은 그 틀림을 사람이 잡는 자리다. 돈이 오가는 일을 봇의 판단만으로 실행하지 않는다는 것은 시나리오 봇에서나 에이전트에서나 같다.

⑭ 결과 보고 → ⑨로 합류. 계획의 마지막 칸이 끝났거나, 지휘자가 더 할 수 없다고 판단하면 결과를 돌려준다. 끝났으면 무엇을 했는지 고객에게 말하고 종료한다. 못 끝냈으면 지휘자가 한 일과 못 한 일의 목록을 들고 상담사에게 넘긴다. 넘기는 주체는 여전히 게이트웨이와 교환기다. 에이전트가 멈춰도 전화는 살아야 하기 때문이다. 그리고 상담사 화면에 에이전트가 조회한 것과 만든 것이 떠야 고객이 같은 말을 두 번 하지 않는다.

에이전틱이라는 말에 들어 있어야 하는 세 가지

올해 초 보고서를 쓰다가 에이전틱이라는 말을 어디까지 써도 되는지 정해야 했다. 봇에 큰 언어 모델을 붙이면 전부 에이전틱이라 부르는 자료가 많았다. 그때 내가 정한 기준은 셋이다. 추론(reasoning)이 있는가. 목표를 받아 지금 할 일을 스스로 고르는가. 재귀(recursive)가 있는가. 한 일의 결과를 다시 자기 입력으로 받는가. 루프(loop)가 있는가. 실패하면 스스로 다시 불러 재추론하고 재계획하는가. 셋 중 하나라도 없으면 그것은 큰 언어 모델을 붙인 시나리오 봇이지 에이전트가 아니다. 그리고 셋이 다 있어도 사람 승인 구간이 없으면 운영에 넣지 못한다.

시나리오 트리와 비교하면 차이가 분명하다. 트리는 사람이 그린 분기를 따라간다. 상자마다 할 말이 적혀 있고 화살표마다 조건이 적혀 있다. 조건에 없는 일이 생기면 폴백으로 간다. 에이전트는 상자가 아니라 목표와 도구를 받는다. 어느 도구를 어떤 순서로 부를지는 그때 정하고, 결과가 계획과 다르면 순서를 바꾼다. 트리가 나쁜 것이 아니다. 길이 정해진 일은 트리가 더 정확하고 더 싸다. 에이전트는 길을 미리 다 그릴 수 없는 일에만 쓴다.

가상 보험사에서 열네 단계가 도는 모습

보험사를 예로 드는 이유는 연결과 이해와 행동이 다 필요하기 때문이다. 고객의 말은 "교통사고가 났는데 접수부터 하고 싶어요", "실손 청구 서류를 이미 냈는데 왜 보완 요청이 왔는지 모르겠어요", "갱신 보험료가 왜 올랐는지 설명 듣고 싶어요"다. 버튼으로 끝나지 않는 말이다. 답을 찾아 주던 봇은 두 번째 고객에게 앱을 안내하고 끝났다. 일을 끝내는 봇은 이렇게 돈다. 봇이 말에서 "청구 보완"이라는 뜻을 고르고 지휘자에게 목표를 넘긴다(⑩). 지휘자가 청구 건 조회 도구를 부른다(⑪). 결과에 진단서가 빠져 있다. 다음 칸을 서류 안내로 정한다(⑫). 안내 뒤 고객이 "그럼 다시 내야 하나요"라고 묻는다. 지휘자가 추가 제출 케이스 생성과 담당자 콜백 예약을 계획하고, 실행 전에 고객에게 묻는다(⑬). 고객이 맞다고 하면 케이스 생성 도구와 콜백 예약 도구를 부르고, 둘 다 성공한 것을 확인한 뒤 무엇을 했는지 말하고 끊는다(⑭). 콜백 예약 도구가 실패하면 계획이 바뀐다. 케이스는 만들어졌고 콜백만 안 잡혔으니 그 상태 그대로 상담사에게 넘긴다. 상담사 화면에는 조회 결과와 만들어진 케이스 번호가 떠 있다. 이것은 가상의 예시이고 실제 센터의 흐름은 아니다.

2026년의 봇 구조에서 지휘자는 어디에 서는가

요즘 보이스봇을 뜯어 보면 세 덩어리로 나뉜다. 보이스 게이트웨이(voice gateway)는 소리를 받고, 말이 시작되고 끝나는 구간을 찾고, 음성인식과 음성합성을 돌린다. 의도 라우터(intent router)는 고객의 말에서 의도를 분류해 대화 엔진의 대화 API를 시작, 대화, 종료 순으로 부르고, "응", "그래요"처럼 흩어진 긍정과 부정을 네와 아니오로 표준화해 엔진에 넘긴다. 제품마다 이 자리를 다른 이름으로 부르지만 하는 일은 같다. 대화 엔진(dialog engine)은 시나리오를 돌린다. 의도 라우터가 의도를 분류하려면 시나리오 이름과 업무 설명과 예문이 필요하고, 대화 엔진은 바깥과 잇기 전에 혼자서 세션을 만들고 대화하고 끝낼 수 있어야 한다. 이 글의 ⑩에서 ⑭까지를 맡는 지휘자는 의도 라우터 위에 선다고 나는 본다. 여러 시나리오와 도구 위에서 목표를 들고 있는 자리이고, 현장에서는 이 자리를 따로 담당으로 두기 시작했다.

이 구조에서 겪은 실패 하나를 적는다. 전화망 없이 봇을 시연하려고 스마트폰 앱으로 소리를 보내는 클라이언트를 만든 적이 있다. 통화망 마이크가 아니라 스마트폰 마이크라 주변 소음이 그대로 들어왔고, 음성 쪽에서 소음을 거르려고 짧은 발화를 예외로 처리해 둔 상태였다. 그 결과 고객의 짧은 "네"가 대화 API로 전달되지 않았고, 봇은 묵음으로 판정해 재질문을 반복하다가 횟수를 넘겨 통화를 끝냈다. 음성인식은 "네"를 제대로 받아 적었는데 그 글자가 봇까지 가지 않은 것이다. 당장은 시연 발화를 긴 문장으로 바꿔 넘겼다. 고치는 법은 음성 쪽의 예외 규칙과 의도 라우터의 긍정·부정 표준화 규칙을 같은 표에 적어 두고, 짧은 긍정 답이 어디서 버려지는지를 단계마다 로그로 보는 것이다. 덩어리가 셋이면 글자가 사라지는 자리도 셋이다.

큰 언어 모델은 어느 상자에 들어가는가

큰 언어 모델(LLM, large language model)을 붙이면 봇이 에이전트가 되는 것이 아니다. 모델은 상자 하나에 들어가는 부품이고, 어느 상자에 넣는지가 설계다. 내가 모델을 넣는 상자는 둘이다. 뜻을 고르는 상자와 계획을 세우는 상자다. "예"와 "아니오"로 끝나지 않는 모호한 말, 예를 들어 "서류를 냈는데 왜 또 내라는 건지"를 해석하는 데 모델이 낫다. 목표를 받아 어느 도구를 먼저 부를지 정하는 데도 모델이 낫다. 넣지 않는 상자도 둘이다. 답을 내는 상자와 도구를 실행하는 상자다. 돈이 오가거나 규정이 있는 일의 답은 사람이 적어 둔 시나리오 문장으로 낸다. 모델은 없는 말을 지어낼 수 있고 정책을 어길 수 있다. 도구는 모델이 부르기로 정하는 것이지 모델이 실행하는 것이 아니다. 실행은 승인 구간을 지난 뒤 API가 한다. 음성 채널이라면 하나가 더 붙는다. 모델이 문장을 만들고 음성합성이 그것을 소리로 바꾸는 시간이 고객에게는 침묵이다. 그 침묵을 시나리오가 받아 주지 못하면 고객은 끊는다. 절차가 정해진 일은 시나리오로, 모호한 말의 해석은 모델로. 음성에서는 모델을 제한된 구간에만 둔다.

공개 문서가 에이전트를 나누는 방식도 같은 그림이다. 아마존커넥트(Amazon Connect) 관리자 안내서는 인공지능 에이전트를 네 유형으로 적고, 그중 에이전틱 셀프서비스는 오케스트레이터가 여러 단계를 거쳐 도구를 부르고 필요하면 사람에게 넘기는 방식이라고 설명한다. 출처는 AWS 공개 문서 Create AI agents와 Use agentic self-service다(2026-10-17 조회).

마무리 

올해 초에 세 단계를 연결, 이해, 행동이라고 쓸 때는 행동이 가장 먼 단계로 보였다. 6월에 AmazonConnect 개인 계정으로 인스턴스를 만들고 번호를 받아 첫 통화를 연결했을 때 나는 아직 첫 단계에 있었다. 지금은 행동 단계가 먼 것이 아니라 순서가 있는 것으로 보인다. 도구가 API로 열려 있는가, 승인 구간이 어디인가, 실패하면 무엇으로 돌아가는가. 이 셋이 정해지지 않은 센터에 모델을 붙이면 답을 더 길게 찾아 줄 뿐 일은 끝내지 못한다. 답을 찾아 주던 봇이 일을 끝내려면 모델이 아니라 이 셋이 먼저다.

다음 글들은 이 글의 상자 안으로 들어간다. 큰 언어 모델에 문서를 찾아 건네는 RAG(검색 증강 생성, retrieval-augmented generation)을 봇과 잇는 방법, 봇이 대화의 어디까지 왔는지 들고 있는 컨텍스트 하나만으로 한 편, 그리고 문서를 벡터로 바꾸고 벡터를 검색하고 실제로 쓴 사례까지. 하나씩 따로 쓴다.