CTI 서버 장애가 발생하면 전화는 왜 되고 화면은 안 뜰까?

1장 전화는 되는데 화면이 안 뜬다#

콜센터 장애 중 가장 헷갈리는 상황이 있습니다.

상담원에게 전화는 정상적으로 들어옵니다.

고객과 통화도 됩니다.

그런데 평소라면 자동으로 나타나던 고객정보 화면이 뜨지 않습니다.

상담원은 이렇게 말할 수 있습니다.

전화는 되는데 고객 화면이 안 떠요.

처음 접하면 이상하게 느껴집니다.

전화 시스템에 장애가 났다면 전화도 안 되어야 할 것처럼 보이기 때문입니다.

하지만 CTI 구조를 이해하면 이유는 비교적 명확합니다.

원본 자료에서는 CTI 서버 장애 시 전화는 되지만 화면 연동이 끊길 수 있다고 설명합니다.

핵심은 전화 통화 자체와 컴퓨터 화면 연동이 서로 다른 역할을 담당한다는 것입니다.

2장 CTI 서버는 어디에 위치하는가#

원본 자료에서 CTI 서버는 PBX와 CRM 사이에 위치합니다.

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

PBX
 ↕
CTI 서버
 ↕
CRM / 상담원 UI

각 시스템의 역할은 다릅니다.

PBX#

전화 호를 처리합니다.

CTI 서버#

PBX의 전화 이벤트를 CRM에 전달하고 CRM의 통화 제어 명령을 PBX로 전달합니다.

CRM#

고객정보와 상담업무 화면을 관리합니다.

따라서 CTI 서버가 중간에서 장애를 일으키면 PBX 자체가 정상이어도 CRM과 전화 시스템 사이의 연결이 끊길 수 있습니다.

3장 전화는 누가 처리하는가#

전화 자체는 PBX 또는 IP-PBX가 처리합니다.

전체 콜시스템 흐름에서도 전화는 다음과 같은 경로를 거칩니다.

고객
 ↓
통신사업자
 ↓
IP-PBX
 ↓
IVR
 ↓
ACD
 ↓
상담원

CTI는 이 흐름에서 전화 통화 자체를 대신하는 것이 아니라 전화 상태를 컴퓨터 업무 시스템과 연결합니다.

따라서 PBX·회선·ACD·상담원 단말이 정상이라면 CTI 서버 장애와 별개로 통화가 가능할 수 있습니다.

4장 화면은 누가 처리하는가#

상담원 화면은 CRM 또는 상담원 애플리케이션에서 처리합니다.

하지만 CRM은 PBX 내부에서 전화가 어떻게 움직이고 있는지 기본적으로 알 수 없습니다.

그래서 CTI가 필요합니다.

예를 들어 고객 전화가 들어오면:

PBX
 ↓
CTI 이벤트
 ↓
CTI 서버
 ↓
CRM
 ↓
Screen Pop

의 흐름을 통해 상담원 화면이 자동으로 변경됩니다.

CTI 서버가 장애를 일으키면 중간 연결이 끊어집니다.

결과적으로:

PBX → 상담원 전화
정상

PBX → CTI → CRM
장애

상태가 될 수 있습니다.

5장 전화 경로와 데이터 경로를 분리해서 봐야 한다#

CTI 장애를 이해할 때 가장 중요한 개념입니다.

콜센터에는 크게 두 흐름이 있습니다.

전화 흐름#

실제 고객 음성과 전화 호가 이동하는 경로

데이터 흐름#

전화 상태와 고객정보가 컴퓨터 시스템 사이에서 이동하는 경로

개념적으로 보면:

전화 경로
고객 → PBX → 상담원

데이터 경로
PBX → CTI → CRM

입니다.

전화 경로는 정상인데 데이터 경로만 장애가 날 수 있습니다.

그래서:

전화는 되는데 화면은 안 뜨는 현상

이 발생합니다.

6장 CTI 장애에서 Screen Pop이 먼저 눈에 띄는 이유#

Screen Pop은 CTI 연동을 상담원이 가장 직접적으로 체감하는 기능입니다.

정상 상태에서는:

전화 착신
 ↓
CTI
 ↓
ANI / DNIS
 ↓
CRM
 ↓
고객정보 자동 표시

로 동작합니다.

CTI 서버가 장애 상태라면 CRM까지 전화 이벤트가 전달되지 않을 수 있습니다.

그 결과:

전화는 울림
상담원은 전화 받음
고객정보는 자동으로 안 뜸

이라는 현상이 발생합니다.

원본 Screen Pop 자료에서도 전화 착신 후 CTI가 ANI 또는 DNIS를 CRM으로 전달하고 고객정보 화면을 표시하는 구조를 설명합니다.

7장 CTI 서버 장애 시 영향을 받을 수 있는 기능#

원본 자료에서 CTI는 전화 이벤트와 컴퓨터 업무 시스템을 연결합니다.

따라서 CTI 서버 장애 시 다음과 같은 기능이 영향을 받을 수 있습니다.

Screen Pop#

고객정보 자동 표시가 안 될 수 있습니다.

상담원 상태 표시#

Ready·Not Ready·ACW 같은 상태가 CRM에 정상 반영되지 않을 수 있습니다.

Click-to-Call#

CRM에서 번호를 클릭해 발신하는 기능이 동작하지 않을 수 있습니다.

통화 제어#

Answer, Hold, Transfer, Hangup 같은 화면 기반 제어가 영향을 받을 수 있습니다.

통화 이벤트 기록#

착신·연결·종료 같은 이벤트가 CRM으로 전달되지 않을 수 있습니다.

통화시간 연동#

통화 시작·종료 이벤트가 누락되면 CRM의 통화시간 기록에도 영향을 줄 수 있습니다.

8장 CTI 서버의 핵심 역할을 보면 장애 영향이 보인다#

원본 자료에서는 CTI 서버의 역할을 다음과 같이 설명합니다.

PBX 이벤트 수신·정규화
상담원 단말 매핑
명령 라우팅
재접속·세션 복구
장애 시 Failover

이 기능 중 하나라도 제대로 동작하지 않으면 전화와 CRM의 상태가 서로 어긋날 수 있습니다.

9장 PBX 이벤트 수신 장애#

CTI 서버는 PBX에서 발생하는 전화 이벤트를 받아야 합니다.

예를 들어:

Ringing
Established
Released
Held
Transferred

같은 이벤트입니다.

CTI 서버가 PBX와 연결되지 못하면 이런 이벤트를 받을 수 없습니다.

그러면 CRM에서는:

전화가 들어왔는지
통화가 연결됐는지
통화가 끝났는지

알 수 없게 됩니다.

전화는 실제로 움직이지만 화면은 멈춰 있는 상태가 됩니다.

10장 Ringing 이벤트가 안 들어오면#

Ringing은 호 착신을 의미합니다.

이 이벤트가 CRM까지 전달되지 않으면 Screen Pop의 시작 조건을 놓칠 수 있습니다.

정상:

Ringing
 ↓
CTI
 ↓
CRM
 ↓
고객정보 표시

장애:

Ringing
 ↓
CTI 장애
 X
CRM

결과적으로 상담원은 전화를 받지만 고객 화면은 자동으로 나타나지 않을 수 있습니다.

11장 Established 이벤트가 안 들어오면#

Established는 통화 연결을 의미합니다.

이 이벤트가 누락되면 CRM에서는 실제 통화가 연결되었는지 판단하기 어려울 수 있습니다.

그 결과:

통화 시작 시각
통화 상태 표시
상담이력 연결

등이 실제 통화 상태와 어긋날 수 있습니다.

12장 Released 이벤트가 안 들어오면#

Released는 통화 종료를 의미합니다.

이 이벤트가 CRM까지 전달되지 않으면 실제 전화는 끝났는데 화면에서는 계속 통화 중으로 표시될 수 있습니다.

예:

실제 전화
통화 종료

CRM
통화 중

또 통화 종료 이후 실행되어야 하는 상담 후처리 흐름이 시작되지 않을 수도 있습니다.

13장 상담원 상태도 어긋날 수 있다#

CTI는 전화 상태뿐 아니라 상담원 상태도 전달합니다.

예를 들어:

Ready
Not Ready
After Call Work
Login
Logout

등입니다.

CTI 연결이 끊기면 실제 ACD 상태와 상담원 화면의 상태가 다르게 보일 수 있습니다.

예:

실제 ACD
Ready

CRM 화면
Not Ready

또는 그 반대일 수도 있습니다.

14장 상태 불일치는 왜 위험한가#

상담원 상태는 단순 표시가 아니라 ACD의 콜 분배와도 관련됩니다.

예를 들어 실제로 상담원이 Ready인데 CRM에서는 Not Ready로 표시된다면 운영자가 잘못된 판단을 할 수 있습니다.

반대로 화면은 Ready인데 실제 ACD에서는 Not Ready라면 상담원은:

Ready인데 왜 전화가 안 오지?

라고 느낄 수 있습니다.

따라서 CTI 장애에서는 실제 전화 시스템 상태와 화면 표시 상태를 분리해서 확인해야 합니다.

15장 Click-to-Call도 영향을 받을 수 있다#

원본 CRM 연동 자료에서는 상담원 명령이 다음 흐름으로 전달된다고 설명합니다.

상담원 명령
 ↓
CTI
 ↓
PBX

따라서 CTI 서버가 장애 상태라면 CRM에서:

010-1234-5678 [전화]

를 클릭해도 발신 명령이 PBX까지 전달되지 않을 수 있습니다.

하지만 상담원이 전화기에서 직접 번호를 누르면 PBX 자체 기능으로 발신이 가능할 수도 있습니다.

이 역시:

전화는 되는데 CTI 기능은 안 되는 현상

의 대표적인 예입니다.

16장 통화 전환도 영향을 받을 수 있다#

CTI를 통해 CRM 화면에서 Transfer 명령을 실행하는 환경이라면 CTI 서버 장애 시 화면 기반 호 전환도 영향을 받을 수 있습니다.

구조는:

CRM
 ↓
Transfer 명령
 ↓
CTI
 ↓
PBX

입니다.

CTI가 중간에서 명령을 전달하지 못하면 CRM 버튼은 정상적으로 보여도 실제 전화 시스템에서 동작하지 않을 수 있습니다.

17장 전화기 버튼과 CTI 버튼은 다르게 볼 필요가 있다#

예를 들어 통화 종료 기능을 생각해보겠습니다.

전화기 자체의 종료 버튼은 PBX와 직접 연결된 기능일 수 있습니다.

반면 CRM 화면의 Hangup 버튼은:

CRM
 ↓
CTI
 ↓
PBX

경로를 사용합니다.

따라서 CTI 장애가 발생하면:

전화기 종료 버튼
정상

CRM Hangup 버튼
실패

같은 차이가 나타날 수 있습니다.

구축 방식에 따라 실제 동작은 달라질 수 있지만 장애 분석에서는 이 두 경로를 분리해서 보는 것이 중요합니다.

18장 "전화는 되는데 CTI만 안 된다"는 말의 의미#

현장에서 흔히 표현할 수 있는 문장입니다.

정확히 풀어보면:

음성 통화와 PBX의 기본 전화 기능은 정상인데 PBX와 CRM 사이의 컴퓨터 연동 기능에 장애가 있다.

는 의미에 가깝습니다.

즉 CTI 장애는 반드시 전체 전화 장애를 의미하지 않습니다.

19장 CTI 서버 자체 장애#

가장 직접적인 원인은 CTI 서버 자체가 정상 동작하지 않는 경우입니다.

원본에서도 CTI 서버 장애 시 전화는 되지만 화면 연동이 끊길 수 있다고 명시합니다.

이 경우 영향을 받을 수 있는 범위는 CTI 서버가 담당하는 기능에 따라 달라집니다.

20장 PBX와 CTI 사이 연결 장애#

CTI 서버 프로세스 자체는 살아 있지만 PBX와 연결이 끊어진 경우도 생각할 수 있습니다.

구조는:

PBX
 X
CTI 서버
 ↓
CRM

입니다.

CRM에서는 CTI 서버와 연결되어 있는 것처럼 보여도 실제 전화 이벤트가 들어오지 않을 수 있습니다.

따라서 단순히:

CTI 서버 프로세스가 살아 있다.

는 것만으로 정상이라고 판단하면 부족합니다.

21장 CTI와 CRM 사이 연결 장애#

반대 상황도 가능합니다.

PBX
 ↓
CTI 서버
 X
CRM

CTI 서버는 PBX 이벤트를 정상적으로 받고 있지만 CRM에 전달하지 못하는 경우입니다.

이때 CTI 로그에는 이벤트가 기록되는데 상담원 화면에서는 아무 변화가 없을 수 있습니다.

따라서 장애 범위를 찾을 때 연결 구간을 나눠야 합니다.

22장 상담원 단말 매핑 장애#

원본에서 CTI 서버의 핵심 역할 중 하나는 상담원 단말 매핑입니다.

즉:

상담원 A ↔ 내선 2101
상담원 B ↔ 내선 2102

같은 관계를 관리합니다.

매핑이 잘못되면 전화 이벤트 자체는 정상인데 올바른 상담원 CRM으로 전달되지 않을 수 있습니다.

예를 들어 전화는 상담원 A에게 왔는데 Screen Pop은 상담원 B에게 뜨는 문제가 발생할 수 있습니다.

23장 특정 상담원만 화면이 안 뜬다면#

모든 상담원이 아니라 한 명 또는 일부 상담원에게만 문제가 발생한다면 전체 CTI 서버 장애와 다른 문제일 수 있습니다.

구조적으로 다음을 확인할 수 있습니다.

상담원 로그인#

정상 세션인지

내선 매핑#

올바른 단말과 연결되어 있는지

CRM 세션#

정상적으로 로그인되어 있는지

해당 단말 이벤트#

CTI가 정상 수신하고 있는지

원본은 이러한 개별 장애 진단 절차까지 제시하지 않지만 상담원 단말 매핑이 CTI 서버의 핵심 역할이라는 점은 명확하게 제시합니다.

24장 모든 상담원이 동시에 안 된다면#

여러 상담원에게 동시에 같은 문제가 발생한다면 중앙 구성요소를 확인할 필요가 있습니다.

예를 들어:

전체 상담원 Screen Pop 중단

이라면 개별 PC보다 다음과 같은 중앙 경로를 먼저 구분해볼 수 있습니다.

PBX
 ↓
CTI 서버
 ↓
CRM 연동

원본 역시 CTI 서버가 전체 이벤트 라우팅의 중앙 역할을 수행한다고 설명합니다.

25장 CTI 장애 진단의 가장 기본적인 질문#

CTI 문제를 분석할 때 가장 먼저 다음 질문을 던질 수 있습니다.

전화도 안 되는가?

또는:

전화는 되는데 화면만 안 되는가?

이 질문 하나로 장애 범위를 크게 나눌 수 있습니다.

전화도 안 됨#

회선·PBX·IVR·ACD·단말 등 전화 경로까지 확인 필요

전화는 됨#

PBX와 실제 통화 경로가 정상일 가능성이 있음

화면만 안 됨#

CTI·CRM 연동 구간 확인 필요

26장 장애 구간을 단계별로 나누면#

다음 순서로 확인할 수 있습니다.

1단계: 전화가 정상적으로 들어오는가#

PBX와 전화 경로 확인

2단계: PBX에서 CTI 이벤트가 발생하는가#

착신·연결·종료 이벤트 확인

3단계: CTI 서버가 이벤트를 받는가#

PBX ↔ CTI 연결 확인

4단계: 상담원 매핑이 정상인가#

내선과 상담원 관계 확인

5단계: CTI가 CRM으로 이벤트를 전달하는가#

CTI ↔ CRM 확인

6단계: CRM이 이벤트를 처리하는가#

Screen Pop과 고객 DB 조회 확인

이렇게 단계별로 보면 장애 범위를 좁히기 쉽습니다.

27장 CTI 로그가 중요한 이유#

CTI는 여러 시스템 사이에 위치합니다.

따라서 장애가 발생하면 어느 시스템이 문제인지 한눈에 알기 어렵습니다.

개념적으로 로그에서 확인할 수 있는 정보는 다음과 같습니다.

PBX 이벤트 수신 여부
 ↓
상담원 매핑 결과
 ↓
CRM 전달 여부

원본은 구체적인 로그 포맷까지 제시하지 않지만 CTI 서버가 이벤트 수신·정규화와 명령 라우팅을 담당하므로 각 처리 단계의 정상 여부를 추적하는 것이 중요합니다.

28장 자동 재연결이 필요한 이유#

네트워크는 순간적으로 끊길 수 있습니다.

PBX와 CTI 서버 사이 연결이 잠깐 끊어졌다고 해서 운영자가 매번 수동으로 서버를 재시작해야 한다면 안정적인 서비스라고 보기 어렵습니다.

그래서 원본 자료에서는 자동 재연결 정책이 운영에 매우 중요하다고 설명합니다.

즉 CTI는 연결이 끊어졌을 때 다시 정상 연결을 시도하는 구조가 필요합니다.

29장 재접속과 세션 복구는 같은 것인가#

비슷해 보이지만 개념적으로 구분하면 좋습니다.

재접속#

끊어진 네트워크 연결을 다시 맺는 것

세션 복구#

연결 이후 기존 상담원·단말·통화 관련 상태를 다시 정상적으로 맞추는 것

원본에서는 CTI 서버 역할로 재접속·세션 복구를 함께 제시합니다.

즉 단순히 TCP 연결 하나를 다시 맺는 것만으로 장애 복구가 끝나는 것은 아닐 수 있습니다.

30장 재연결됐는데 화면 상태가 이상할 수 있는 이유#

예를 들어 CTI 연결이 끊긴 동안 다음 이벤트가 발생했다고 하겠습니다.

Established
 ↓
통화
 ↓
Released

하지만 CTI가 Released 이벤트를 놓쳤다면 연결이 복구된 뒤 CRM은 여전히 통화 중이라고 생각할 수 있습니다.

그래서 복구 이후 현재 실제 상태와 CRM 상태를 다시 맞추는 과정이 중요합니다.

원본 CRM 연동 자료에서도 네트워크 단절 후 재동기화를 중요한 설계 포인트로 제시합니다.

31장 재동기화란 무엇인가#

재동기화는 서로 다른 시스템의 상태가 어긋났을 때 다시 일치시키는 과정입니다.

예를 들어:

PBX
통화 종료

CRM
통화 중

이라면 복구 후:

PBX
통화 종료

CRM
통화 종료

로 맞춰야 합니다.

전화와 CRM 상태가 장시간 다르게 유지되면 이후 상담이력이나 상태 관리까지 영향을 받을 수 있습니다.

32장 장애 임계치가 필요한 이유#

원본에서는 장애 임계치도 운영에서 중요하다고 설명합니다.

네트워크가 한 번 순간적으로 느려졌다고 즉시 전체 장애로 판단할 수는 없습니다.

반대로 연결이 지속적으로 실패하는데도 정상 상태로 표시해서도 안 됩니다.

따라서 운영에서는 어느 수준부터 장애로 판단할 것인지 기준이 필요합니다.

원본에는 구체적인 임계치 수치까지는 제시되어 있지 않습니다.

33장 알람이 중요한 이유#

CTI 장애는 상담원 전화 자체가 계속 동작할 수 있기 때문에 운영자가 늦게 알아차릴 가능성이 있습니다.

예를 들어:

전화 정상
Screen Pop 장애

상태가 지속되면 상담원은 고객정보를 매번 수동으로 조회해야 합니다.

따라서 원본에서는 알람 정책이 중요하다고 설명합니다.

장애가 발생했을 때 운영자가 빠르게 인지할 수 있어야 합니다.

34장 CTI 서버가 SPOF가 될 수 있다#

SPOF는 Single Point of Failure의 약자입니다.

하나의 구성요소가 장애 나면 전체 기능이 중단되는 지점을 의미합니다.

예를 들어 모든 상담원의 CTI 이벤트가 서버 한 대를 통해서만 전달된다고 하겠습니다.

PBX
 ↓
CTI 서버 1대
 ↓
전체 상담원 CRM

이 CTI 서버가 장애를 일으키면 전체 상담원의 화면 연동이 중단될 수 있습니다.

원본에서는 이러한 CTI 단일 장애점을 피하기 위해 이중화 구성을 권장합니다.

35장 CTI 서버 이중화란 무엇인가#

CTI 서버를 한 대가 아니라 복수로 구성해 한 서버에 문제가 발생해도 다른 서버가 역할을 이어받을 수 있도록 하는 구조입니다.

개념적으로는:

          PBX
        ↙     ↘
CTI Server A  CTI Server B
        ↘     ↙
          CRM

형태를 생각할 수 있습니다.

원본은 구체적인 제품별 이중화 방식까지 설명하지 않지만 SPOF 방지를 위해 이중화가 권장된다는 점을 명확하게 제시합니다.

36장 Failover란 무엇인가#

Failover는 현재 서비스를 담당하던 시스템에 장애가 발생했을 때 다른 시스템이 역할을 이어받는 구조입니다.

원본에서는 CTI 서버 역할 중 하나로 장애 시 Failover를 제시합니다.

예를 들어:

CTI Server A
정상 운영
 ↓
장애 발생
 ↓
CTI Server B
서비스 인계

같은 구조입니다.

37장 서버가 두 대 있다고 이중화가 끝나는 것은 아니다#

단순히 CTI 서버를 두 대 설치했다고 장애 대응이 완성되는 것은 아닙니다.

원본에서 재접속·세션 복구와 Failover를 함께 언급하는 이유도 중요합니다.

장애 이후에도:

상담원 세션
단말 매핑
현재 전화 상태

등이 정상적으로 이어져야 실제 서비스 복구라고 볼 수 있습니다.

원본은 구체적인 상태 복제 방식까지는 제시하지 않습니다.

38장 Failover 이후 상태가 맞지 않으면#

예를 들어 장애 전 상담원 A가 고객과 통화 중이었다고 하겠습니다.

상담원 A
통화 중

CTI 서버가 전환된 뒤 새 서버가 상담원 A를 Ready 상태라고 잘못 판단하면 실제 전화 상태와 업무 시스템 상태가 어긋납니다.

따라서 Failover 이후에는 연결 복구뿐 아니라 상태 복구도 중요합니다.

39장 CTI 서버 장애와 CRM 서버 장애는 다르다#

화면이 안 뜬다고 모두 CTI 장애는 아닙니다.

CTI 장애#

PBX 이벤트가 CRM까지 전달되지 않음

CRM 장애#

CTI가 이벤트를 정상 전달했지만 CRM이 처리하지 못함

구조로 보면:

PBX
 ↓
CTI
 ↓
CRM

중 어느 지점이 문제인지 구분해야 합니다.

40장 CRM 장애에서는 어떤 현상이 생길까#

CTI가 정상적으로 이벤트를 수신하고 있는데 CRM 애플리케이션에 문제가 있다면 다음 현상이 가능할 수 있습니다.

고객 DB 조회 실패
화면 전환 실패
상담이력 화면 오류

이 경우 CTI 로그에는 이벤트가 정상적으로 존재할 수 있습니다.

따라서:

Screen Pop이 안 된다 = CTI 서버 장애

라고 바로 단정하면 안 됩니다.

41장 PBX 장애와 CTI 장애도 구분해야 한다#

PBX 자체에 문제가 있다면 전화 착신이나 통화 자체가 영향을 받을 수 있습니다.

반면 CTI 서버 장애에서는 원본 설명처럼 전화는 유지되면서 화면 연동만 끊길 수 있습니다.

따라서 증상 비교가 중요합니다.

증상	확인할 영역
전화 자체가 안 됨	회선·PBX·ACD·단말
전화는 되는데 화면이 안 뜸	CTI·CRM
특정 상담원만 안 됨	세션·단말 매핑
전체 Screen Pop 중단	중앙 CTI·CRM 연동

실제 원인은 구축 환경에 따라 달라질 수 있으므로 이 표는 장애 범위를 좁히기 위한 구조적인 기준으로 보는 것이 좋습니다.

42장 전체 콜 흐름을 보면 CTI의 위치가 더 명확하다#

원본 전체 콜시스템 구조에서는 다음 순서를 제시합니다.

고객
 ↓
통신사업자 / SBC
 ↓
IP-PBX
 ↓
IVR
 ↓
ACD
 ↓
CTI
 ↓
상담원 CRM
 ↓
녹취

여기서 CTI는 전화 흐름 전체를 만드는 유일한 시스템이 아닙니다.

이미 앞단의:

통신사업자
PBX
IVR
ACD

가 전화 처리를 담당합니다.

CTI는 그 결과를 업무 시스템과 연결합니다.

그래서 CTI 장애와 전체 전화망 장애를 동일하게 보면 안 됩니다.

43장 CTI 장애에서 상담원의 업무는 어떻게 달라질까#

전화가 정상인데 Screen Pop만 안 된다면 상담원은 고객과 통화는 할 수 있습니다.

하지만 평소 자동으로 이루어지던 업무가 수동으로 바뀔 수 있습니다.

예를 들어:

정상
전화 착신
→ 고객 자동 조회

CTI 장애
전화 착신
→ 상담원이 직접 고객 검색

처럼 될 수 있습니다.

즉 전화 서비스는 유지되더라도 상담 효율은 크게 떨어질 수 있습니다.

44장 CTI 장애를 단순한 화면 장애로 보면 안 되는 이유#

처음에는 단순히 고객 화면이 안 뜨는 문제처럼 보일 수 있습니다.

하지만 CTI는:

통화 이벤트
상담원 상태
통화 제어
CRM 연동

을 담당합니다.

따라서 장애가 장시간 지속되면 단순 UI 불편을 넘어 데이터 상태와 실제 전화 상태가 달라질 수 있습니다.

특히 통화 종료 이벤트나 상담원 상태 이벤트가 누락되면 CRM 데이터에도 영향을 줄 수 있습니다.

45장 CTI 장애 대응에서 가장 중요한 운영 요소#

원본 자료가 직접 강조하는 운영 요소는 다음과 같습니다.

장애 임계치#

언제 장애로 판단할 것인가

알람#

장애를 빠르게 운영자에게 알림

자동 재연결#

연결이 끊겼을 때 자동 복구 시도

재접속·세션 복구#

연결뿐 아니라 상담원 상태와 세션 복구

Failover#

주 시스템 장애 시 대기 시스템으로 전환

이중화#

CTI 서버 자체가 단일 장애점이 되지 않도록 구성

46장 CTI 장애 대응 흐름을 단순화하면#

운영 관점에서 개념적으로 다음과 같이 볼 수 있습니다.

CTI 연결 이상 감지
 ↓
장애 임계치 판단
 ↓
알람
 ↓
자동 재연결
 ↓
세션 복구
 ↓
정상 여부 확인

복구 실패
 ↓
Failover
 ↓
대기 CTI 서버 전환

원본은 구체적인 자동화 절차까지 제시하지 않지만 장애 임계치·알람·자동 재연결·Failover를 주요 운영 요소로 제시합니다.

47장 CTI 장애를 한 문장으로 설명하면#

가장 쉽게 설명하면 다음과 같습니다.

CTI 서버는 전화 자체를 연결하는 PBX가 아니라 전화 상태와 CRM 화면을 연결하는 중간 시스템이기 때문에 CTI가 장애 나도 PBX가 정상이라면 통화는 가능하지만 Screen Pop 같은 화면 연동 기능은 중단될 수 있다.

이 문장이 CTI 장애 구조의 핵심입니다.

CTI 서버 장애 FAQ#

CTI 서버가 장애 나면 전화도 끊기는가#

반드시 그렇지는 않습니다. 원본 자료에서는 CTI 서버 장애 시 전화는 되지만 화면 연동이 끊길 수 있다고 설명합니다.

왜 전화는 되는데 고객정보 화면은 안 뜨는가#

전화 자체는 PBX에서 처리하고 Screen Pop은 PBX 이벤트가 CTI를 거쳐 CRM으로 전달되어야 동작하기 때문입니다.

CTI 서버는 어디에 위치하는가#

원본에서는 PBX와 CRM·상담원 UI 사이에 위치하는 구조로 설명합니다.

CTI 서버의 주요 역할은 무엇인가#

PBX 이벤트 수신·정규화, 상담원 단말 매핑, 명령 라우팅, 재접속·세션 복구, Failover입니다.

전화는 되는데 Screen Pop만 안 되면 어디를 확인해야 하는가#

PBX → CTI → 상담원 매핑 → CRM → 고객 DB 순으로 구간을 나누어 확인할 수 있습니다.

특정 상담원만 Screen Pop이 안 되면 무엇을 확인해야 하는가#

상담원 세션과 내선·단말 매핑을 확인할 필요가 있습니다. 원본에서도 상담원 단말 매핑을 CTI 서버의 핵심 역할로 제시합니다.

모든 상담원의 화면 연동이 동시에 안 되면 무엇을 확인해야 하는가#

중앙 CTI 서버와 PBX 연결, CRM 연결 같은 공통 구간을 확인할 필요가 있습니다.

자동 재연결이 왜 필요한가#

순간적인 네트워크 장애 후 수동 조작 없이 CTI 연결을 복구하기 위해 중요합니다. 원본도 자동 재연결 정책을 중요하게 제시합니다.

세션 복구란 무엇인가#

연결이 다시 이루어진 뒤 상담원·단말·전화 관련 상태를 정상 상태로 맞추는 과정으로 이해할 수 있습니다.

SPOF란 무엇인가#

Single Point of Failure로, 하나의 시스템 장애가 전체 기능 중단으로 이어지는 단일 장애점을 의미합니다.

CTI 서버는 왜 이중화해야 하는가#

원본에서는 CTI 단일 장애점을 피하기 위해 이중화 구성을 권장합니다.

Failover란 무엇인가#

주 CTI 서버에 장애가 발생했을 때 다른 서버가 역할을 이어받도록 하는 장애 대응 구조입니다. 원본에서도 CTI 서버 역할 중 하나로 Failover를 제시합니다.

핵심 정리#

CTI 서버는 PBX와 CRM 사이에서 전화 이벤트와 제어 명령을 전달하는 중간 시스템입니다.

기본 구조는 다음과 같습니다.

PBX
 ↕
CTI 서버
 ↕
CRM / 상담원 UI

원본에서는 CTI 서버의 주요 역할을 다음과 같이 제시합니다.

PBX 이벤트 수신·정규화

상담원 단말 매핑

명령 라우팅

재접속·세션 복구

장애 시 Failover

그리고 가장 중요한 장애 특성을 다음과 같이 설명합니다.

CTI 서버 장애 시 전화는 되지만 화면 연동은 끊길 수 있다.

이유는 전화와 화면의 경로가 다르기 때문입니다.

전화 경로
고객 → PBX → 상담원

화면 연동 경로
PBX → CTI → CRM

따라서 장애 분석에서는 먼저:

전화 자체가 안 되는가

또는

전화는 되는데 CTI 화면 연동만 안 되는가

를 구분해야 합니다.

또한 원본은 CTI 운영에서 장애 임계치·알람·자동 재연결 정책이 중요하다고 강조하며, CTI 서버가 SPOF가 되지 않도록 이중화 구성을 권장합니다.

가장 짧게 기억하면 다음과 같습니다.

PBX는 전화를 연결하고 CTI는 전화와 화면을 연결한다. 그래서 CTI가 멈춰도 PBX가 정상이라면 전화는 될 수 있지만 화면 연동은 멈출 수 있다.