AICC란 무엇인가 — 구성 요소로 보는 개념 정리

AICC 견적서를 두 곳에서 받아 보면 항목이 서로 안 겹치는 경우가 많습니다. 같은 단어를 쓰는데 파는 물건이 다르기 때문입니다.

1. AICC는 제품 이름이 아니라 묶음의 이름입니다

AICC(AI Contact Center)는 하나의 소프트웨어를 가리키는 말이 아닙니다. 전화를 받고, 말을 알아듣고, 답하고, 업무 시스템과 주고받고, 그 결과를 남기는 일련의 기능을 한 덩어리로 부를 때 쓰는 이름입니다.

그래서 "AICC를 도입한다"는 문장만으로는 무엇을 사는지가 정해지지 않습니다. 상담 화면만 바꾸는 것도 AICC 도입이라고 부르고, 전화망부터 통째로 옮기는 것도 AICC 도입이라고 부릅니다. 견적이 안 겹치는 진짜 이유가 이것입니다.

묶음의 이름을 제품 이름으로 읽으면 견적 비교가 성립하지 않습니다.

2. 다섯 층으로 갈라 놓으면 헷갈릴 것이 줄어듭니다

한 덩어리로 두면 비교가 안 되니, 통화가 지나가는 순서대로 층을 나눕니다.

층을 나누면 «어디까지 사는가»를 문장이 아니라 경계로 적을 수 있습니다.

연결층은 통화 자체를 다룹니다. 회선, 대표번호, 그리고 걸려 온 통화를 어느 대기열로 보낼지 정하는 분배(ACD)가 여기 들어갑니다. 이 층이 없으면 나머지가 다 있어도 전화가 안 울립니다.

인식층은 음성과 글자를 서로 옮깁니다. 말을 받아 적는 쪽(STT)과 글자를 읽어 주는 쪽(TTS)이 한 쌍입니다. 한국어 고유명사와 숫자에서 성능이 갈리는 자리가 여기입니다.

대화층은 무엇을 물어보고 어떻게 답할지를 정합니다. 예전의 ARS 시나리오와 요즘의 음성봇이 같은 자리에 놓입니다. 도입 논의가 대부분 이 층 이야기로 시작하는데, 실제로 일이 터지는 곳은 대개 위아래 층입니다.

연동층은 업무 시스템과 값을 주고받습니다. 고객이 누구인지 조회하고, 처리 결과를 다시 써 넣는 자리입니다. 이 층의 전통적인 이름이 CTI입니다.

기록층은 통화가 끝난 뒤에 남는 것을 다룹니다. 녹취, 요약, 품질 평가, 대기열별 리포트가 여기 모입니다. 도입 논의에서 제일 늦게 이야기되고, 계약이 끝날 때 제일 문제가 되는 층이기도 합니다.

다섯이라는 숫자가 정답은 아닙니다. 벤더에 따라 인식층과 대화층을 하나로 묶어 부르기도 하고, 기록층을 품질관리와 리포팅으로 다시 쪼개기도 합니다. 중요한 건 층의 개수가 아니라 각 층이 지금 누구 것인지 말할 수 있느냐입니다.

3. 벤더가 한 덩어리로 파는 것은 사실입니다

층으로 나눠 놓으면 "그럼 다섯 개를 따로 사야 하나" 싶지만, 실제 시장은 묶어서 팝니다. Genesys Cloud의 자사 소개 문서만 봐도 인바운드·아웃바운드 음성, IVR과 콜백, 디지털 채널, 인력 운영 관리(WEM), 음성 텍스트 변환, 상담원 보조(Agent Copilot), API 호출량이 한 소개 페이지 안에 나란히 적혀 있습니다. (Genesys, Overview of Genesys Cloud, 2026-08-10 확인)

묶음으로 사는 것 자체는 문제가 아닙니다. 한 벤더가 여러 층을 맡으면 층 사이 책임 떠넘기기가 줄고, 통합 비용도 아낍니다. 문제는 묶음 안에서 어느 층이 이미 우리 것이고 어느 층이 새로 들어오는지를 안 적은 채 계약하는 경우입니다. 이때 견적서는 벤더가 파는 단위로 적혀 있고, 우리 쪽 현황은 그 단위로 정리돼 있지 않습니다. 대조가 안 되니 겹치는 칸이 안 보입니다.

4. 솔루션 하나로 착각하면 층이 겹쳐 들어옵니다

실무에서 제일 자주 걸리는 함정입니다. AICC를 단일 제품으로 이해하면 이미 갖고 있는 층 위에 같은 층이 한 번 더 얹힙니다.

전형적인 모양은 이렇습니다. 기존 콜센터에 ARS 시나리오와 CTI 연동이 이미 돌고 있는데, AICC 플랫폼을 들이면서 그쪽 IVR과 그쪽 커넥터가 같이 들어옵니다. 그러면 시나리오가 두 벌이 됩니다. 어느 쪽이 먼저 받는지, 전환할 때 어느 쪽 값을 믿는지가 안 정해진 채로요.

문제는 이게 계약 시점에 안 보인다는 점입니다. 기능표에는 양쪽 다 «있음»으로 찍히니까요. 겹침은 대개 병행 운영 기간에 드러납니다. 같은 고객이 두 번 본인 확인을 하게 되는 식으로요.

• 이미 있는 층: 지금 어느 시스템이 그 일을 하고 있는지 이름으로 적습니다
• 새로 오는 층: 새 플랫폼의 어느 기능이 그 자리를 대신하는지 적습니다
• 겹치는 층: 둘 중 무엇을 끄는지, 언제 끄는지를 적습니다

세 번째 줄을 안 적으면 안 끄게 됩니다. 끄는 날짜가 없으면 «일단 둘 다 켜 두고 안정화되면 정리하자»가 되고, 그 상태가 그대로 정상 운영이 됩니다. 두 벌로 굳어진 시나리오를 나중에 한 벌로 합치는 비용은 처음에 한 벌로 만드는 비용보다 훨씬 큽니다.

5. "AICC 도입"이 가리키는 범위를 문장으로 적습니다

층을 나눴으면 범위를 문장이 아니라 경계로 적을 수 있습니다.

범위를 적는 목적은 벤더 비교가 아니라 겹침과 공백을 미리 찾는 것입니다.

여기서 자주 빠지는 것이 공백입니다. 겹침은 병행 운영에서 티라도 나는데, 아무도 안 맡은 층은 개통 직전까지 조용합니다. 기록층이 자주 그렇습니다. 녹취는 기존 장비가 하고 있었는데 새 플랫폼으로 옮기면서 그 통화만 녹취가 안 남는 식입니다.

공백은 대개 «당연히 그쪽이 하겠지»에서 생깁니다. 기존 장비 담당자는 새 플랫폼이 가져간 줄 알고, 새 플랫폼 쪽은 기존 장비가 계속 하는 줄 압니다. 그래서 층별 표에는 «있다/없다»가 아니라 담당 시스템 이름을 적는 편이 낫습니다. 이름을 못 적는 칸이 공백입니다.

6. 지표가 나쁠 때 어느 층을 봐야 하는지도 달라집니다

층을 나눠 두면 숫자를 해석하는 방식도 바뀝니다. 연결률이 낮다고 할 때, 원인이 회선과 분배(연결층)에 있는지, 알아듣지 못해 되묻다 끊긴 것(인식층)인지, 시나리오가 길어서 중간에 끊긴 것(대화층)인지는 전혀 다른 문제입니다.

연결률이라는 지표 자체를 어떻게 읽는지는 AICC 환경에서 보이스 AI가 연결률을 어떻게 바꾸는가에서 따로 다뤘습니다. 이 글은 그 지표가 «어느 층에서 깨졌는지»를 묻기 위한 지도에 가깝습니다.

층별로 볼 수 있으려면 각 층에서 무엇을 재는지도 미리 정해 둬야 합니다. 연결층은 대기열별 인입과 포기, 인식층은 되묻기 횟수, 대화층은 시나리오 단계별 이탈 지점, 연동층은 조회 실패율, 기록층은 녹취 누락 건수쯤이 시작점입니다. 완벽한 목록일 필요는 없고, 층마다 최소 하나씩만 있어도 원인을 좁힐 수 있습니다.

층을 안 나누면 지표 하나에 원인이 다섯 개 붙습니다. 그러면 회의가 길어지고 결론은 대개 "좀 더 지켜보자"가 됩니다.

7. 이 방법이 통하지 않는 경우

솔직히 말하면 이렇게 층을 나누는 게 과한 자리도 있습니다.

• 콜센터라 부를 만한 것이 아직 없는 조직. 대표번호 하나에 휴대폰으로 착신 전환해 쓰고 있다면 나눌 층이 없습니다. 이 경우엔 층 설계가 아니라 통화 기록부터 남기는 것이 먼저입니다
• 전화가 주 채널이 아닌 조직. 문의가 대부분 채팅과 메일로 들어오면 연결층·인식층 논의가 거의 비어 있게 됩니다. 같은 예산이면 채팅 쪽 자동화가 먼저입니다
• 한 벤더에 전부 맡기기로 이미 정한 경우. 층별 책임 소재를 나눠 적는 실익이 줄어듭니다. 다만 이때도 기록층만은 따로 확인하시기를 권합니다 — 계약 종료 시 녹취와 이력을 어떤 형식으로 돌려받는지가 여기서 정해집니다

정리: AICC는 제품이 아니라 연결·인식·대화·연동·기록 다섯 층의 묶음 이름입니다. 도입 범위를 적을 때는 새로 오는 층보다 이미 있는 층과 겹치는 층을 먼저 적으십시오. 겹침은 병행 운영에서 드러나지만, 아무도 안 맡은 층은 개통 직전까지 조용합니다.