콜시스템에서 AICC까지: CTI·옴니채널·AI를 연결하는 컨택센터 아키텍처

1장 콜센터는 왜 AICC로 바뀌고 있는가#

전통적인 콜센터를 생각하면 구조는 비교적 단순합니다.

고객이 전화를 걸면 교환기가 전화를 받고, IVR이 안내를 제공하고, ACD가 상담원을 찾아 전화를 연결합니다.

상담원은 CRM을 열어 고객정보를 확인하고 상담 결과를 기록합니다.

이를 단순화하면 다음과 같습니다.

flowchart LR
    A[고객] --> B[통신사업자]
    B --> C[IP-PBX]
    C --> D[IVR]
    D --> E[ACD]
    E --> F[상담원]

오랫동안 이 구조만으로도 콜센터를 운영할 수 있었습니다.

하지만 고객 접점이 전화 하나에서:

• 웹채팅
• 모바일앱
• SMS
• 이메일
• 메신저

등으로 확대되면서 기존 구조만으로는 고객 경험을 하나로 관리하기 어려워졌습니다.

여기에 STT, TTS, LLM, RAG, Voicebot 같은 AI 기술까지 등장하면서 콜센터 아키텍처 자체가 다시 설계되고 있습니다.

이러한 변화의 결과가 AICC, 즉 AI Contact Center입니다.

---

2장 기존 콜시스템의 기본 구조#

업로드된 원본에서는 기존 시스템의 예를 다음과 같이 설정합니다.

• 기존 IP-PBX
• IVR
• ACD
• CTI 미들웨어
• CRM
• 녹취 서버
• 상담원

그리고 기존 IP-PBX에는 노후화와 라이선스 부담, CTI에는 단방향 이벤트, CRM에는 상담이력 일부만 동기화라는 특징을 부여하고 있습니다.

이를 Mermaid로 다시 표현하면 다음과 같습니다.

flowchart TB
    A[고객<br/>PSTN · 모바일]
    B[통신사업자<br/>PSTN · PRI]
    C[기존 IP-PBX<br/>노후 · 라이선스 부담]
    D[IVR<br/>DTMF]
    E[ACD<br/>기본 분배]
    F[상담원<br/>소프트폰 · 하드폰]
    G[CTI 미들웨어<br/>단방향 이벤트]
    H[기존 CRM<br/>일부 이력 동기화]
    I[녹취 서버<br/>파일 저장]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

    C --> G
    G --> F
    H --> G
    C --> I

이 구조가 잘못된 것은 아닙니다.

문제는 각 시스템이 부분적으로만 연결되어 있다는 것입니다.

---

3장 기존 콜시스템의 첫 번째 문제는 시스템 분리다#

기존 콜센터를 보면 전화 시스템과 업무 시스템이 분리되어 있는 경우가 많습니다.

전화 영역에서는:

PBX
IVR
ACD

가 움직입니다.

업무 영역에서는:

CRM
상담이력
고객정보

가 움직입니다.

그리고 CTI가 그 사이를 일부 연결합니다.

flowchart LR
    subgraph 전화시스템
        PBX[IP-PBX]
        IVR[IVR]
        ACD[ACD]
        PBX --> IVR --> ACD
    end

    CTI[CTI 미들웨어]

    subgraph 업무시스템
        CRM[CRM]
        AGENT[상담원 화면]
    end

    ACD --> CTI
    CTI --> CRM
    CRM --> AGENT

CTI가 충분히 통합되어 있지 않으면 전화와 CRM 사이의 데이터가 제한적으로만 연결됩니다.

---

4장 두 번째 문제는 단방향 CTI다#

원본의 현재 시스템 예에서는 CTI를 단방향 이벤트 구조로 표현하고 있습니다.

CTI의 이상적인 구조는 양방향입니다.

전화 → CRM#

전화 상태가 업무 화면으로 전달됩니다.

Ringing
Established
Released

CRM → 전화#

상담원 화면에서 전화 시스템을 제어합니다.

Click-to-Call
Answer
Hold
Transfer
Hangup

따라서 목표 구조는 다음과 같습니다.

flowchart LR
    PBX[IP-PBX]
    CTI[CTI 미들웨어]
    CRM[CRM · 상담원 데스크]

    PBX -->|전화 이벤트| CTI
    CTI -->|Ringing · Established · Released| CRM

    CRM -->|발신 · 보류 · 전환 · 종료| CTI
    CTI -->|통화 제어 명령| PBX

CTI가 양방향이 되어야 전화 시스템과 상담업무 시스템이 하나의 사용자 경험으로 통합됩니다.

---

5장 세 번째 문제는 고객 접점이 전화에 집중되어 있다는 것이다#

기존 콜센터에서는 고객과 기업의 대표적인 접점이 전화였습니다.

하지만 현재 고객은 여러 채널을 사용합니다.

원본의 목표 시스템에는 다음 고객 접점이 포함되어 있습니다.

• 전화
• 웹채팅
• 카카오
• SMS
• 이메일
• 모바일앱
• 옴니 라우터

즉 고객센터의 입구가 하나가 아닙니다.

flowchart LR
    A[전화]
    B[웹채팅]
    C[카카오]
    D[SMS]
    E[이메일]
    F[모바일앱]

    O[옴니채널 라우터]

    A --> O
    B --> O
    C --> O
    D --> O
    E --> O
    F --> O

이것이 옴니채널 Omnichannel 구조의 출발점입니다.

---

6장 멀티채널과 옴니채널은 다르다#

전화와 채팅, 이메일을 모두 제공한다고 해서 반드시 옴니채널은 아닙니다.

각 채널이 따로 관리된다면 멀티채널에 가깝습니다.

flowchart TB
    C[고객]

    C --> P[전화 상담 이력]
    C --> W[웹채팅 이력]
    C --> E[이메일 이력]
    C --> M[메신저 이력]

    P --> PDB[(전화 DB)]
    W --> WDB[(채팅 DB)]
    E --> EDB[(메일 DB)]
    M --> MDB[(메신저 DB)]

이 경우 상담원은:

이 고객이 어제 채팅으로 문의했는가?

를 즉시 알기 어렵습니다.

옴니채널은 이 정보를 하나의 고객 컨텍스트로 연결합니다.

flowchart TB
    A[전화]
    B[웹채팅]
    C[카카오]
    D[SMS]
    E[이메일]
    F[모바일앱]

    O[옴니채널 라우터]
    CRM[통합 CRM]
    DB[(통합 상담이력)]

    A --> O
    B --> O
    C --> O
    D --> O
    E --> O
    F --> O

    O --> CRM
    CRM --> DB

핵심은 채널 수가 아니라 고객 컨텍스트가 이어지는가입니다.

---

7장 목표 AICC 아키텍처 전체 모습#

원본 목표 시스템은 기존 콜시스템을 다음 다섯 영역으로 확장합니다.

1. 고객 접점
2. 전화 인입
3. AI 플랫폼
4. 미들웨어·데이터
5. 사용자·업무

전체 구조를 Mermaid로 다시 구성하면 다음과 같습니다.

flowchart TB

    subgraph CHANNEL["고객 접점"]
        TEL[전화]
        WEB[웹채팅]
        KAKAO[카카오]
        SMS[SMS]
        MAIL[이메일]
        APP[모바일앱]
        OMNI[옴니채널 라우터]

        TEL --> OMNI
        WEB --> OMNI
        KAKAO --> OMNI
        SMS --> OMNI
        MAIL --> OMNI
        APP --> OMNI
    end

    subgraph CALL["전화 인입"]
        CARRIER[통신사업자]
        SBC[SBC]
        PBX[IP-PBX]
        IVR[IVR]
        ACD[ACD]
        VB[Voicebot]

        CARRIER --> SBC
        SBC --> PBX
        PBX --> IVR
        IVR --> ACD
        ACD --> VB
    end

    subgraph AI["AI 플랫폼"]
        STT[STT]
        TTS[TTS]
        LLM[LLM]
        RAG[RAG]
        AGENT[AI Agent]
        QA[품질평가]
        KB[지식베이스]
    end

    subgraph DATA["미들웨어 · 데이터"]
        CTI[CTI 미들웨어]
        API[API Gateway]
        MQ[메시지큐]
        CDB[(상담 DB)]
        DW[(분석 DW)]
        REC[(녹취)]
    end

    subgraph BIZ["사용자 · 업무"]
        DESK[상담원 데스크]
        SUP[슈퍼바이저]
        CRM[CRM]
        ERP[ERP]
        VOC[VOC · 리포팅]
        MON[모니터링]
    end

    OMNI --> API
    ACD --> CTI
    VB --> STT
    STT --> LLM
    LLM --> RAG
    RAG --> KB
    LLM --> TTS

    CTI --> DESK
    API --> CRM
    CTI --> CDB
    API --> MQ
    MQ --> CDB
    CDB --> DW
    CDB --> VOC
    REC --> QA
    DW --> MON

    CRM --> DESK
    SUP --> MON

원본 목표 구성에서도 전화 인입 영역에 통신사업자·SBC·IP-PBX·IVR·ACD·Voicebot을, AI 영역에 STT·TTS·LLM·RAG·Agent·품질평가·지식베이스를 배치합니다.

---

8장 AICC에서도 IP-PBX는 사라지지 않는다#

AI 기술이 도입된다고 기존 전화 기술이 사라지는 것은 아닙니다.

전화 고객이 존재하는 한 여전히:

통신사업자
SBC
IP-PBX
IVR
ACD

같은 구성요소가 필요합니다.

변화는 이 기존 통신 인프라 위에:

Voicebot
STT
TTS
LLM
RAG
AI Agent

가 추가된다는 것입니다.

즉 AICC는 기존 콜시스템을 폐기하고 AI로 바꾸는 구조라기보다 전화 인프라 위에 AI와 데이터 계층을 추가하는 구조로 이해하는 편이 정확합니다.

---

9장 SBC가 목표 구조에 들어가는 이유#

원본 목표 구조에서는 통신사업자와 IP-PBX 사이에 SBC가 추가되어 있습니다.

flowchart LR
    TELCO[통신사업자]
    SBC[SBC]
    PBX[IP-PBX]

    TELCO --> SBC --> PBX

SBC는 Session Border Controller입니다.

SIP 기반 외부 통신과 내부 전화 시스템 사이의 경계에서:

• 보안
• SIP 세션 제어
• 트래픽 정규화
• 외부·내부 네트워크 경계

역할을 담당할 수 있습니다.

AICC라고 해도 전화 인프라의 보안 경계가 사라지는 것은 아닙니다.

---

10장 Voicebot은 IVR을 어떻게 확장하는가#

기존 IVR은 일반적으로:

1번을 누르세요.
2번을 누르세요.

형태였습니다.

즉 DTMF 중심입니다.

AICC에서는 고객이 직접 말할 수 있습니다.

"고장 신고하려고요."

Voicebot은 이 음성을 처리하기 위해 AI 플랫폼과 연결됩니다.

sequenceDiagram
    participant 고객
    participant Voicebot
    participant STT
    participant LLM
    participant RAG
    participant TTS

    고객->>Voicebot: 음성 질문
    Voicebot->>STT: 음성 전달
    STT->>LLM: 텍스트 변환 결과
    LLM->>RAG: 관련 지식 검색
    RAG-->>LLM: 업무 지식 반환
    LLM->>TTS: 답변 텍스트
    TTS-->>Voicebot: 합성 음성
    Voicebot-->>고객: 음성 답변

이것이 전통적인 IVR과 AI Voicebot의 가장 큰 차이입니다.

---

11장 STT는 AICC의 귀다#

STT는 Speech-to-Text입니다.

음성을 텍스트로 변환합니다.

고객 음성
 ↓
STT
 ↓
텍스트

AICC에서는 이 텍스트가 매우 중요합니다.

텍스트가 만들어져야:

• LLM 분석
• 상담 요약
• 키워드 추출
• VOC 분석
• 품질평가
• 지식 검색

등을 수행할 수 있기 때문입니다.

---

12장 TTS는 AICC의 목소리다#

TTS는 Text-to-Speech입니다.

AI가 생성한 텍스트를 다시 음성으로 바꿉니다.

flowchart LR
    A[LLM 답변] --> B[TTS]
    B --> C[음성]
    C --> D[고객]

STT와 TTS를 함께 보면:

고객 음성
 ↓
STT
 ↓
텍스트
 ↓
AI
 ↓
텍스트
 ↓
TTS
 ↓
고객 음성 응답

구조가 됩니다.

---

13장 LLM은 무엇을 담당하는가#

LLM은 고객의 발화를 이해하고 답변을 생성하는 역할에 사용할 수 있습니다.

하지만 기업 고객센터에서는 LLM 자체 지식만 사용하는 것이 위험할 수 있습니다.

예를 들어 고객이:

환불은 며칠까지 가능한가요?

라고 질문했다고 하겠습니다.

기업의 실제 환불 정책을 확인하지 않고 모델이 자체 지식만으로 답하면 잘못된 안내가 발생할 수 있습니다.

이 문제를 줄이는 대표적인 구조가 RAG입니다.

---

14장 RAG는 기업 지식을 LLM과 연결한다#

RAG는 Retrieval-Augmented Generation입니다.

질문과 관련된 기업 내부 정보를 먼저 검색한 뒤 그 내용을 LLM에 제공합니다.

flowchart LR
    Q[고객 질문] --> R[RAG 검색]
    KB[(지식베이스)] --> R
    R --> L[LLM]
    L --> A[답변]

예를 들어:

고객 질문
"환불 기간이 어떻게 되나요?"

↓

RAG
환불 정책 검색

↓

지식베이스
"상품 수령 후 7일 이내"

↓

LLM
검색된 정책을 기반으로 답변 생성

구조입니다.

---

15장 지식베이스는 AI보다 먼저 준비되어야 한다#

원본 목표 구조에서는 AI 플랫폼 안에 지식베이스를 별도 구성요소로 배치합니다.

이는 매우 중요한 구조입니다.

AI가 아무리 좋아도 기업의:

• 업무 매뉴얼
• 상품정보
• 장애 대응 절차
• 환불 정책
• 상담 FAQ

가 정리되어 있지 않다면 정확한 상담 답변을 만들기 어렵습니다.

따라서 AICC에서 중요한 것은 LLM을 붙이는 것만이 아니라 기업 지식의 구조화입니다.

---

16장 AI Agent는 단순 답변을 넘어 행동으로 확장된다#

원본 목표 아키텍처에는 LLM과 RAG 외에 Agent가 별도로 포함되어 있습니다.

LLM이:

무엇을 답할 것인가?

를 담당한다면 Agent는 업무 시스템과 연결해:

무엇을 실행할 것인가?

까지 확장할 수 있습니다.

개념적으로:

flowchart LR
    U[고객 요청]
    L[LLM]
    A[AI Agent]
    API[API Gateway]
    CRM[CRM]
    ERP[ERP]

    U --> L
    L --> A
    A --> API
    API --> CRM
    API --> ERP

즉 AI가 단순 상담 답변을 넘어 실제 업무 프로세스와 연결될 수 있는 구조입니다.

---

17장 CTI는 AICC에서도 여전히 중요하다#

AI가 등장했다고 CTI의 역할이 없어지는 것은 아닙니다.

CTI는 여전히:

• 전화 이벤트 전달
• Screen Pop
• Click-to-Call
• 상담원 상태 연동
• 전화 제어
• CRM 연동

에서 중요한 역할을 합니다.

AICC에서는 CTI가 더 많은 시스템과 연결됩니다.

flowchart TB
    PBX[IP-PBX]
    ACD[ACD]
    CTI[CTI 미들웨어]
    CRM[CRM]
    DESK[상담원 데스크]
    DB[(상담 DB)]
    AI[AI 플랫폼]

    PBX --> ACD
    ACD --> CTI
    CTI --> CRM
    CTI --> DESK
    CTI --> DB
    DB --> AI

즉 CTI는 전통적인 전화 시스템과 AI·데이터 시스템 사이에서도 중요한 연결 지점이 될 수 있습니다.

---

18장 API Gateway가 추가되는 이유#

원본 목표 시스템의 미들웨어·데이터 영역에는 API Gateway가 포함되어 있습니다.

과거에는 시스템끼리 직접 연결하는 경우가 많았습니다.

CRM → ERP
CRM → CTI
CRM → AI
CRM → 상담 DB

시스템이 늘어날수록 연결도 복잡해집니다.

API Gateway를 두면:

flowchart LR
    CRM[CRM]
    ERP[ERP]
    AI[AI 플랫폼]
    APP[외부 서비스]

    API[API Gateway]

    CRM --> API
    ERP --> API
    AI --> API
    APP --> API

처럼 접근 경로를 통합할 수 있습니다.

---

19장 메시지큐가 필요한 이유#

AICC에서는 수많은 이벤트가 실시간으로 발생합니다.

예를 들어 전화 한 통에서도:

Ringing
Established
STT 생성
상담 이벤트
Released
상담 요약
품질평가
통계 적재

등 여러 이벤트가 발생할 수 있습니다.

모든 시스템을 직접 연결하면 시스템 간 결합도가 높아질 수 있습니다.

메시지큐를 사용하면:

flowchart LR
    CTI[CTI]
    CRM[CRM]
    STT[STT]

    MQ[(메시지큐)]

    DB[(상담 DB)]
    DW[(분석 DW)]
    AI[AI 분석]

    CTI --> MQ
    CRM --> MQ
    STT --> MQ

    MQ --> DB
    MQ --> DW
    MQ --> AI

처럼 이벤트를 중간에서 전달할 수 있습니다.

---

20장 상담 DB와 분석 DW를 분리하는 이유#

원본 목표 구조에서는:

• 상담 DB
• 분석 DW

를 별도로 두고 있습니다.

둘은 목적이 다릅니다.

상담 DB#

현재 상담 업무를 처리하기 위한 운영 데이터

분석 DW#

많은 상담 데이터를 모아 분석하기 위한 데이터

이를 구조로 보면:

flowchart LR
    A[상담원 / CRM]
    DB[(상담 DB)]
    DW[(분석 DW)]
    BI[리포팅 · 분석]
    AI[AI 분석]

    A --> DB
    DB --> DW
    DW --> BI
    DW --> AI

운영 트랜잭션과 분석 워크로드를 분리하는 구조입니다.

---

21장 녹취도 단순 파일 저장에서 데이터 자산으로 바뀐다#

원본의 현재 시스템은 녹취 서버를 파일 저장 중심으로 표현합니다.

하지만 목표 시스템에서는 녹취가 데이터 플랫폼의 일부입니다.

과거:

통화
 ↓
녹취
 ↓
파일 저장

AICC:

flowchart LR
    CALL[통화] --> REC[(녹취)]
    REC --> STT[STT]
    STT --> TEXT[(상담 텍스트)]
    TEXT --> QA[AI 품질평가]
    TEXT --> VOC[VOC 분석]
    TEXT --> SUM[상담 요약]
    TEXT --> DW[(분석 DW)]

즉 녹취가 단순 보관 대상에서 AI 분석을 위한 데이터 원천으로 변합니다.

---

22장 상담원 데스크도 달라진다#

기존 상담원 화면에서는 주로:

• 고객정보
• 전화 제어
• 상담이력

을 사용했습니다.

AICC에서는 여기에 AI 지원이 추가될 수 있습니다.

flowchart TB
    D[상담원 데스크]

    D --> C[고객정보]
    D --> H[상담이력]
    D --> T[전화 제어]
    D --> K[지식 검색]
    D --> R[AI 답변 추천]
    D --> S[실시간 상담 요약]

상담원은 더 이상 모든 정보를 직접 찾아야 하는 사람이 아니라 AI가 제공한 정보를 검토하고 판단하는 역할로 이동할 수 있습니다.

---

23장 슈퍼바이저의 역할도 데이터 중심으로 바뀐다#

원본 목표 시스템에는 상담원뿐 아니라 슈퍼바이저·VOC/리포팅·모니터링도 별도로 포함되어 있습니다.

기존에는 운영자가 몇 개의 대표 KPI를 확인하는 데 집중했다면 AICC에서는:

• 상담량
• 상담 대기
• 상담원 상태
• 고객 감정
• 반복 문의
• 상담 품질
• AI 답변 품질
• Voicebot 처리 결과

같은 정보를 함께 볼 수 있습니다.

즉 운영 역시 데이터 기반 운영으로 이동합니다.

---

24장 기존 시스템과 목표 시스템을 비교하면#

구분	기존 콜시스템	목표 AICC
고객 접점	전화 중심	전화·채팅·메신저·SMS·메일·앱
PBX	기존 IP-PBX	IP-PBX + SBC
IVR	DTMF 중심	IVR + Voicebot
콜 분배	기본 ACD	옴니채널·통합 라우팅
CTI	부분·단방향 연동	양방향·통합 미들웨어
CRM	일부 이력 연결	통합 고객 컨텍스트
녹취	파일 저장	STT·AI 분석 원천
AI	없음	STT·TTS·LLM·RAG·Agent
데이터	시스템별 분산	상담 DB + DW
연계	시스템 직접 연결	API Gateway + 메시지큐
운영	개별 시스템 중심	통합 모니터링·분석

원본에서도 기존 시스템의 문제를 노후 PBX·CTI 단방향·AI/옴니채널 부재, 목표 시스템을 AI·옴니채널·통합 이력·데이터 기반 운영으로 대비합니다.

---

25장 고객 전화 한 통이 AICC에서 처리되는 과정#

전체 구조를 실제 한 통의 전화로 따라가 보겠습니다.

sequenceDiagram
    participant C as 고객
    participant P as IP-PBX
    participant I as IVR / Voicebot
    participant A as ACD
    participant T as CTI
    participant R as CRM
    participant G as 상담원
    participant AI as AI 플랫폼
    participant DB as 상담 DB

    C->>P: 전화
    P->>I: 호 전달
    I->>C: 안내 또는 AI 응대
    I->>A: 상담원 연결 요청
    A->>T: 상담원 배정
    T->>R: 착신 이벤트 · ANI
    R->>G: 고객정보 Screen Pop
    C->>G: 상담
    G->>AI: 실시간 상담 지원
    AI-->>G: 지식 · 답변 추천
    T->>DB: 통화 이벤트
    R->>DB: 상담이력 저장
    AI->>DB: 요약 · 분석 결과

이 흐름 하나에:

• PBX
• IVR
• Voicebot
• ACD
• CTI
• CRM
• AI
• 상담 DB

가 모두 연결됩니다.

---

26장 비음성 채널에서는 흐름이 어떻게 달라질까#

웹채팅이나 모바일앱에서는 PBX를 거칠 필요가 없습니다.

flowchart LR
    A[웹채팅]
    B[카카오]
    C[모바일앱]
    D[이메일]

    O[옴니채널 라우터]
    API[API Gateway]
    CRM[CRM]
    DESK[상담원 데스크]
    AI[AI 플랫폼]

    A --> O
    B --> O
    C --> O
    D --> O

    O --> API
    API --> CRM
    CRM --> DESK
    CRM --> AI

즉 AICC의 핵심은 모든 채널을 무조건 전화 시스템에 넣는 것이 아닙니다.

전화는 전화 인프라를 이용하고 비음성 채널은 다른 경로를 이용하되 최종 고객 컨텍스트와 업무 데이터는 통합하는 것입니다.

---

27장 결국 중요한 것은 통합 이력이다#

고객 입장에서 채널은 중요하지 않을 수 있습니다.

어제는 채팅으로 문의하고 오늘은 전화할 수 있습니다.

하지만 상담원이:

이전 상담 내용이 없습니다.

라고 말한다면 고객은 같은 내용을 반복해야 합니다.

따라서 목표는:

flowchart TB
    PHONE[전화]
    CHAT[채팅]
    EMAIL[이메일]
    APP[앱]

    CUST[고객 ID]
    HISTORY[(통합 상담이력)]

    PHONE --> CUST
    CHAT --> CUST
    EMAIL --> CUST
    APP --> CUST

    CUST --> HISTORY

처럼 채널이 아니라 고객을 중심으로 상담 기록을 연결하는 것입니다.

원본 목표 시스템도 최종 효과를 통합 이력으로 명시하고 있습니다.

---

28장 AICC 구축을 AI 프로젝트로만 보면 안 된다#

AICC라는 이름 때문에 가장 먼저 LLM이나 Voicebot부터 생각하기 쉽습니다.

하지만 전체 아키텍처를 보면 AI는 일부입니다.

기반에는 여전히:

통신망
SBC
IP-PBX
IVR
ACD
CTI
API
CRM
데이터베이스
녹취

가 존재합니다.

그 위에:

STT
TTS
LLM
RAG
Agent
AI 품질평가

가 올라갑니다.

즉 AICC는 단순한 AI 챗봇 구축 프로젝트가 아니라 통신·업무·데이터·AI를 하나로 연결하는 통합 시스템 프로젝트에 가깝습니다.

---

29장 현실적인 고도화 순서는 어떻게 잡을까#

원본은 목표 아키텍처를 제시하지만 구축 순서를 직접 정의하지는 않습니다.

전체 구조를 기준으로 한다면 다음과 같이 단계적으로 접근할 수 있습니다.

flowchart LR
    A[1단계<br/>전화 인프라 안정화]
    B[2단계<br/>CTI · CRM 통합]
    C[3단계<br/>데이터 통합]
    D[4단계<br/>옴니채널]
    E[5단계<br/>STT · TTS]
    F[6단계<br/>LLM · RAG]
    G[7단계<br/>Agent · 자동화]

    A --> B --> C --> D --> E --> F --> G

AI를 가장 먼저 붙이는 것보다 기반 데이터와 연동 구조를 먼저 정리하는 접근이 시스템 전체를 이해하기 쉽습니다.

---

30장 1단계: 전화 인프라를 안정화한다#

첫 번째는 전화입니다.

확인해야 할 영역은 다음과 같습니다.

통신사업자
SBC
IP-PBX
IVR
ACD

전화 자체가 안정적이지 않다면 그 위에 AI를 추가해도 고객 경험이 좋아지기 어렵습니다.

---

31장 2단계: CTI와 CRM을 통합한다#

두 번째는 전화와 업무 화면을 연결하는 것입니다.

flowchart LR
    PBX[IP-PBX]
    CTI[CTI]
    CRM[CRM]

    PBX <-->|이벤트 · 명령| CTI
    CTI <-->|상담 컨텍스트| CRM

Screen Pop과 Click-to-Call, 상담원 상태, 상담이력 등을 통합합니다.

---

32장 3단계: 데이터를 하나로 모은다#

다음은 데이터입니다.

flowchart LR
    CTI[CTI]
    CRM[CRM]
    REC[녹취]
    STT[STT]

    DB[(상담 DB)]
    DW[(분석 DW)]

    CTI --> DB
    CRM --> DB
    REC --> STT
    STT --> DB
    DB --> DW

AI는 결국 데이터를 사용합니다.

따라서 AI 이전에 데이터 구조를 정리하는 것이 중요합니다.

---

33장 4단계: 고객 채널을 통합한다#

전화 중심 시스템에서:

전화 + 채팅 + 메신저 + 이메일 + 앱

구조로 확대합니다.

하지만 채널을 추가하는 것보다 더 중요한 것은 동일 고객을 하나의 상담 컨텍스트로 연결하는 것입니다.

---

34장 5단계: AI를 연결한다#

기반이 갖춰지면 AI를 연결할 수 있습니다.

flowchart LR
    CALL[통화]
    STT[STT]
    LLM[LLM]
    RAG[RAG]
    KB[(지식베이스)]
    AGENT[상담원]

    CALL --> STT
    STT --> LLM
    LLM --> RAG
    KB --> RAG
    RAG --> LLM
    LLM --> AGENT

상담원의 판단을 보조하는 방식부터 시작할 수 있습니다.

---

35장 6단계: AI Agent로 업무 실행까지 확장한다#

가장 높은 단계에서는 AI가 답변만 만드는 것이 아니라 실제 업무 시스템과 연결됩니다.

flowchart LR
    U[고객 요청]
    L[LLM]
    A[AI Agent]
    API[API Gateway]

    C[CRM]
    E[ERP]
    K[지식베이스]

    U --> L
    L --> A
    A --> API
    API --> C
    API --> E
    K --> L

이 단계에서는 AI의 답변 정확성뿐 아니라:

• 권한
• 감사로그
• 실행 승인
• 오류 복구

등도 함께 중요해집니다.

---

AICC 아키텍처 FAQ#

AICC란 무엇인가#

AICC는 AI Contact Center의 약자로 기존 콜센터 구조에 STT·TTS·LLM·RAG·Voicebot·AI Agent 같은 AI 기술을 결합한 컨택센터 구조입니다.

기존 콜센터와 AICC의 가장 큰 차이는 무엇인가#

기존 시스템이 전화와 상담원 중심이라면 AICC는 전화·채팅·메신저·메일·앱을 통합하고 AI와 데이터 플랫폼을 함께 사용한다는 점이 가장 큰 차이입니다.

AICC를 구축하면 PBX가 필요 없는가#

전화 채널을 사용하는 한 IP-PBX 같은 전화 인프라는 여전히 중요합니다. 목표 시스템 원본에도 SBC·IP-PBX·IVR·ACD가 그대로 포함되어 있습니다.

CTI는 AICC에서도 필요한가#

필요합니다. CTI는 전화 이벤트와 CRM·상담원 화면을 연결하는 역할을 하며 AICC에서는 데이터·AI 플랫폼과의 연결까지 확장될 수 있습니다.

Voicebot과 IVR의 차이는 무엇인가#

전통적인 IVR이 DTMF 기반 메뉴 선택 중심이라면 Voicebot은 STT·LLM·TTS 등을 이용해 자연어 음성 대화를 처리할 수 있습니다.

RAG는 왜 필요한가#

LLM이 기업의 실제 정책과 지식에 기반해 답변할 수 있도록 지식베이스에서 관련 정보를 검색해 제공합니다.

API Gateway는 왜 필요한가#

CRM·ERP·AI·외부서비스처럼 여러 시스템의 API 접근을 통합하고 인증·트래픽·연계 구조를 관리하기 위한 중간 계층으로 활용할 수 있습니다.

메시지큐는 왜 필요한가#

CTI·CRM·STT 등에서 발생하는 대량의 이벤트를 여러 시스템이 느슨하게 연결된 상태에서 전달할 수 있도록 해줍니다.

상담 DB와 분석 DW는 왜 분리하는가#

상담 DB는 현재 상담업무 처리가 중심이고 분석 DW는 장기간 축적된 데이터를 통계·리포팅·AI 분석에 활용하는 것이 중심입니다.

옴니채널이란 무엇인가#

전화·채팅·메신저·메일·앱 같은 여러 채널의 상담을 하나의 고객 컨텍스트와 이력으로 연결하는 구조입니다.

핵심 정리#

전통적인 콜시스템은 다음 구조로 이해할 수 있습니다.

flowchart LR
    CUSTOMER[고객]
    TELCO[통신사업자]
    PBX[IP-PBX]
    IVR[IVR]
    ACD[ACD]
    CTI[CTI]
    CRM[CRM]
    AGENT[상담원]

    CUSTOMER --> TELCO
    TELCO --> PBX
    PBX --> IVR
    IVR --> ACD
    ACD --> CTI
    CTI --> CRM
    CRM --> AGENT

AICC는 이 구조를 없애는 것이 아니라 확장합니다.

flowchart TB
    CHANNEL[옴니채널]
    CALL[IP-PBX · IVR · ACD]
    CTI[CTI · API Gateway]
    DATA[상담 DB · DW · 녹취]
    AI[STT · TTS · LLM · RAG · Agent]
    BIZ[CRM · 상담원 · VOC · 모니터링]

    CHANNEL --> CALL
    CHANNEL --> CTI
    CALL --> CTI
    CTI --> DATA
    DATA --> AI
    AI --> BIZ
    CTI --> BIZ

원본 목표 아키텍처 역시 고객 접점에 전화·웹채팅·카카오·SMS·이메일·모바일앱을 배치하고, 전화 인입 계층에 SBC·IP-PBX·IVR·ACD·Voicebot, AI 플랫폼에 STT·TTS·LLM·RAG·Agent·품질평가·지식베이스를 구성합니다.

또한 중간에는 CTI·API Gateway·메시지큐·상담 DB·분석 DW·녹취를 두고, 최종 업무 영역에 상담원 데스크·슈퍼바이저·CRM·ERP·VOC·모니터링을 배치합니다.

결국 콜센터 고도화의 핵심은 단순히 LLM 하나를 붙이는 것이 아닙니다.

전화 인프라를 안정화하고, CTI와 CRM을 연결하고, 데이터를 통합하고, 고객 채널을 하나의 컨텍스트로 묶은 뒤 그 위에 AI를 연결하는 것.

이 구조가 기존 콜센터에서 AICC로 넘어가는 핵심 아키텍처입니다.