AI 콜봇 멀티콜 장애 분석 — SIP Trunk와 B2BUA

"단일콜은 그럭저럭 되는데, 동시에 여러 명한테 거니까 콜 상태가 꼬여요". AI 보이스 에이전트로 outbound 발신 시스템을 구축하다 보면 SIP 트렁크 사업자와 협업할 일이 생깁니다. 어느 날 멀티콜이 안 된다는 이슈가 터졌고, 원인을 추적하다 보니 결국 SIP 시그널링과 트렁크 사업자 장비의 동작 모드를 정확히 이해해야 풀리는 케이스였습니다.

이 글은 그 과정에서 정리한 내용입니다. SIP 기초부터 PDS·Bridge 모드·B2BUA 차이까지, 그리고 실제 트러블슈팅 흐름과 교훈까지 다룹니다.

0. 먼저 확인할 것 — 발신 주체와 사업자 장비의 실제 동작

같은 SIP 트렁크라도 사업자 장비가 프록시처럼 메시지를 전달하는지, B2BUA로 각 통화 leg를 종단하는지에 따라 책임 범위가 달라진다. 다만 Bridge·IVR 모드는 표준 SIP 용어가 아니라 사업자별 설정명이다. 멀티콜 가능 여부도 모드 이름만으로 판단하지 말고 실제 call flow와 동시 채널 설정을 확인해야 한다.

흔한 오해와 정정:

1. SIP 기초 — 시그널링과 미디어는 다른 평면

전화 한 통이 걸릴 때 두 가지 흐름이 동시에 움직입니다.

옛날 PSTN 시절에도 둘은 분리되어 있었지만, 인터넷 전화로 넘어오면서 분리가 더 명확해졌습니다. 인터넷 전화의 시그널링 표준이 SIP(Session Initiation Protocol) — 인터넷용 "전화 거는 언어"입니다. (시그널링·미디어 평면 분리에 대한 더 자세한 내용은 #32 참고.)

SIP 주요 메시지

180 Ringing vs 183 Session Progress — 헷갈리는 핵심

둘은 상태 의미가 다르지만, 응답 코드만으로 미디어 유무를 단정할 수는 없습니다.

180은 수신 UA가 사용자에게 알림을 시도하고 있음을 뜻합니다. UAC는 이를 바탕으로 로컬 ringback을 만들 수 있습니다.

183은 다른 임시 응답으로 분류되지 않는 진행 정보를 전달합니다. SDP가 함께 오고 early media 정책이 허용되면 안내음이나 네트워크 ringback을 전달할 수 있습니다.

• 컬러링
• 통화중 안내음 ("지금 거신 번호는...")
• 콜센터 안내방송

다만 실제 전달 방식과 응답 코드는 통신망·SBC 설정에 따라 다릅니다.

핵심: 180과 183은 임시 응답이고 200은 성공 최종 응답입니다. 이것이 곧 사람의 음성 응답을 보장하지는 않으므로, B2BUA에서는 하위 leg의 answer supervision과 상위 leg의 200 시점을 맞춰야 합니다.

이걸 모르면 뒤에서 다룰 "AI가 ringback에 대고 말하는 현상"의 원인을 못 찾습니다.

1-2. SIP 아키텍처 컴포넌트 — UA / UAC / UAS / B2BUA

Bridge vs B2BUA 차이를 정확히 이해하려면 SIP의 역할 모델을 먼저 잡아야 합니다. RFC 3261 기준 핵심만 정리합니다.

UA = UAC + UAS

같은 장비가 호별로 UAC가 되기도, UAS가 되기도 합니다. 한 통의 통화에서 누가 UAC이고 누가 UAS인지 파악하는 게 SIP 디버깅의 출발점.

서버 컴포넌트 (3종)

대규모 망에서는 분리, 일반 IP-PBX는 한 박스에 통합:

B2BUA — Proxy의 한계를 넘는 능동 장비

B2BUA(Back-to-Back User Agent) = UAS 역할로 다이얼로그를 종단한 다음, UAC 역할로 새 다이얼로그를 생성하는 장비.

   [발신 단말]              [B2BUA]              [수신 단말]
       │                      │                      │
       │── INVITE ───────────►│   (UAS로 받음)       │
       │                      │   ← 다이얼로그 A 종단 │
       │                      │                      │
       │                      │── 새 INVITE ────────►│   (UAC로 새로 보냄)
       │                      │   ← 다이얼로그 B 생성 │
       │                      │                      │
       │◄── 200 OK ───────────│◄── 200 OK ───────────│
       │                      │                      │
       │═ RTP A ══════════════│═ RTP B ══════════════│
       (논리적으로 분리된 두 다이얼로그/leg)

Proxy와의 결정적 차이:

이번 사례의 사업자는 IVR 모드라는 이름으로 B2BUA 방식의 call-leg 관리를 제공했습니다. 다른 사업자에서는 명칭과 기능 범위가 다를 수 있습니다.

SIP의 친구 프로토콜

SIP는 시그널링만 담당. 한 통의 통화를 완성하려면 짝꿍이 필요:

INVITE와 응답의 바디에 SDP가 실릴 수 있고, RFC 3264의 offer/answer 절차로 사용할 미디어 파라미터를 합의합니다. (자세한 시그널링·미디어 평면 분리는 #32 참고.)

2. PDS — 콜센터의 자동 발신기

왜 PDS가 필요한가

여론조사 회사가 1만 명에게 설문 전화를 돌려야 한다고 해봅시다. 상담원이 직접 다이얼하면:

1번 → 안 받음 → 끊음
2번 → 받음 → 통화
3번 → 음성사서함 → 끊음
...

응답률이 20%면 80%의 시간이 다이얼링과 대기로 날아갑니다. 비효율의 끝판왕.

PDS의 동작

PDS(Predictive Dialer System) 는 이 문제를 자동화하는 장비입니다.

[운영자]
   │
   │  ① 전화번호 리스트 1만 개 업로드
   ▼
[PDS]
   │  ② 동시에 50통 자동 발신
   │  ③ 각 콜 결과 자동 판별:
   │     - 안 받음    → 다음 번호
   │     - 음성사서함  → 끊고 다음
   │     - 통화중      → 끊고 다음
   │     - 사람이 받음 → 상담원에게 연결
   ▼
[상담원]
   "여보세요?"가 들리는 콜만 받음

핵심 포인트는 PDS가 발신의 주체라는 것. 콜센터, 여론조사, 텔레마케팅의 표준 장비입니다.

"PDS에 번호 1만 개를 넣어둠" = PDS의 데이터베이스에 발신 리스트 등록 (엑셀 업로드 같은 것). PDS가 그 리스트를 보고 자동으로 발신 사이클을 돌립니다.

3. SIP 트렁크와 벤더의 역할

SIP 트렁크가 뭔가

회사 시스템(IP-PBX, AI 콜봇, PDS 등)이 인터넷으로 일반 전화망(PSTN, 모바일)에 연결할 수 있게 해주는 회선입니다.

[회사 시스템] ←── SIP ──→ [SIP 트렁크 사업자] ←── 전화망 ──→ [수신자 핸드폰]

옛날에는 회사가 통신사로부터 물리적 회선(E1, T1)을 임대받아 PBX에 연결했습니다. SIP 트렁크는 이걸 인터넷 기반으로 대체한 것 — 비용도 싸고 동시 통화 채널도 유연하게 늘릴 수 있습니다.

벤더 장비의 역할

SIP 트렁크 사업자(벤더)의 핵심 장비는 보통 SBC(Session Border Controller) 또는 IP-PBX 입니다. 두 가지 일을 합니다:

1. 경계 처리 — 보안·NAT·정책을 적용하고, PSTN 경계 구성에 따라 SIP와 다른 신호 체계를 연동
2. 콜 처리 — 들어오는/나가는 콜을 어떻게 라우팅하고 관리할지 결정

여기서 결정적인 사실: 같은 장비라도 어떻게 셋업하느냐에 따라 동작이 완전히 달라진다. 그 셋업 모드가 이번 케이스의 핵심입니다.

4. Bridge 모드 vs B2BUA(IVR) 모드 — 같은 장비, 다른 동작

Bridge 모드 — 수동 중계자

한 줄 정의: 들어온 콜을 받아서 다른 쪽으로 그냥 연결만 해주는 모드.

[발신자] ──INVITE──► [벤더 장비] ──INVITE──► [수신자]
                       (그냥 통과시킴)

벤더 장비는 들어온 INVITE를 거의 그대로 다음 단계로 forward합니다. 콜 상태에 깊게 개입하지 않습니다.

비유하자면 옛날 전화 교환원과 같습니다. "교환원, B씨한테 연결해주세요" → 교환원이 케이블 꽂아서 두 사람을 연결 → 자기는 빠짐. 그 후 두 사람이 무슨 얘기 하는지, 누가 먼저 끊는지 신경 안 씁니다.

적합한 시나리오: 발신 주체가 따로 있고(예: PDS), 벤더는 단순히 통로 역할만 하면 충분할 때.

[고객 PDS] ──발신──► [벤더 (Bridge)] ──► [캐리어] ──► [사용자]

이런 그림에서는 PDS가 발신을 알아서 다 합니다. 벤더는 그저 PDS가 만든 콜을 캐리어로 흘려보내면 됩니다. 단순 다리 역할로 충분.

B2BUA(IVR) 모드 — 능동 콜 매니저

한 줄 정의: 벤더 장비가 콜을 받은 다음, 자기가 새로운 콜을 만들어서 다음 단계로 발신하는 모드.

[발신자] ──INVITE──► [벤더 장비] ──(자기가 새 콜 생성)──INVITE──► [수신자]
                       (능동적으로 콜 운영)

벤더 장비가 들어온 콜을 받고 → 자기 안에서 콜 상태를 관리하면서 → 새로운 콜을 outbound로 만듭니다. 두 콜을 자기가 가운데서 통제합니다. 이걸 기술적으로는 B2BUA(Back-to-Back User Agent) 라고 부릅니다.

콜센터 IVR처럼 B2BUA를 사용하는 시스템은 한쪽 leg를 받은 뒤 다른 쪽 leg를 새로 만들고 두 상태를 연계할 수 있습니다. 다만 IVR과 B2BUA는 동의어가 아닙니다. IVR은 서비스 기능이고 B2BUA는 SIP 다이얼로그를 처리하는 방식입니다.

이번 사업자 구성에서 B2BUA 모드가 필요했던 이유

각 콜을 독립적으로 만들고 관리하기 때문입니다.

AI 콜봇: "전화 걸어줘 — 010-1111, 010-2222, 010-3333..."

벤더 (B2BUA 모드):
  Call 1: 010-1111용 outbound leg 생성, 상태 추적
  Call 2: 010-2222용 outbound leg 생성, 상태 추적
  Call 3: 010-3333용 outbound leg 생성, 상태 추적
  ...
  각 콜이 독립적으로 ringing → answer → talk → hangup 관리

각 콜을 별도 leg로 관리할 수 있지만, 실제 동시 처리량은 채널 라이선스·세션 용량·상대망 정책으로 검증해야 합니다.

한눈에 비교

5. 케이스 스터디 — AI 콜봇 멀티콜 트러블슈팅

등장 인물 (익명)

• AI 보이스 에이전트 플랫폼 — outbound 발신 트리거. 발신 주체.
• SIP 트렁크 사업자 (벤더) — SIP ↔ 전화망 게이트웨이 운영.
• 고객사 (여론조사 운영사) — AI 보이스 에이전트를 사용해 AI 여론조사를 돌리는 고객.
• 캐리어 — 통신사.
• 사용자 — 여론조사 대상자.

실제 시스템 구조

[AI 보이스 에이전트 채널] ──INVITE──► [벤더 PBX] ──► [캐리어] ──► [사용자들]
        (발신 주체)

테스트 시나리오: AI 채널에서 프롬프트를 트리거하면 → 여러 명에게 동시에 outbound 전화를 거는 구조.

1단계: 벤더의 초기 가정 (틀린 가정)

벤더 측은 "여론조사 회사 = PDS 쓸 것"이라는 일반적인 가정을 했습니다.

[고객사 PDS] ──발신──► [벤더 (Bridge)] ──► 캐리어 ──► 사용자
                          ↓
                  AI는 옆에서 음성만 처리

이 가정대로면 벤더는 단순 통로니까 Bridge 모드로 셋업하면 충분합니다.

"여기는 PDS라고 해서 앞에서 전화를 걸어주는 장비가 따로 있어요. 전화 걸어가지고서 우리가 연결해주면 그쪽에서는 AI만 터뜨리는 걸로 알고 있었는데..." — 벤더 측

2단계: 멀티콜 실패

테스트해보니 멀티콜이 안 됐습니다. 단일콜은 그럭저럭 됐지만, 동시에 여러 번호로 발신하니 콜 상태가 꼬이는 현상.

"처음에 했을 때는 Bridge라고 해서 그쪽에서 전화가 들어오면 바깥쪽으로 나가는 전화를 연결해드렸는데, 저희 쪽에서 전화를 받아버리고 다음을 진행을 해서 문제가 됐어요." — 벤더 측

관측된 신호 흐름에서는 하위 발신 leg가 응답하기 전에 상위 leg에 200 OK가 반환됐고, AI가 통화 성립으로 판단해 greeting을 시작했습니다. 로그만으로 이를 모든 Bridge 장비의 표준 동작으로 일반화할 수 없으며, 해당 사업자 설정·중계 장비·라우팅 정책을 함께 확인해야 합니다.

이 사업자 설정에서 확인한 실패 지점

AI 보이스 에이전트가 동시에 3개 INVITE를 발송했을 때 Bridge 모드 트렁크에서 일어나는 일:

INVITE (call 1) ──┐
INVITE (call 2) ──┼──► Bridge Mode 트렁크
INVITE (call 3) ──┘         ↓
              PDS가 앞단에 있다는 전제로 구성된 라우팅
                            ↓
                세션 매핑 실패 / 라우팅 실패 / 드롭

구체적 실패 원인을 정리하면:

B2BUA는 두 call leg를 분리해 제어할 수 있지만, 모드 전환만으로 아래 문제가 자동 해결되지는 않습니다. 사업자 설정에서 확인할 항목은 다음과 같습니다.

이 문제는 SIP 프록시의 일반적 한계가 아니라, 실제 발신 구조와 사업자 설정이 맞지 않아 발생했습니다. SIP 프록시 자체는 RFC 3261에 정의된 parallel forking으로 여러 요청 대상을 처리할 수 있습니다.

3단계: 원인 파악과 모드 변경

벤더 측이 원인을 파악:

1. 사실 PDS는 없었다.
2. AI 보이스 에이전트가 직접 발신 주체였다.
3. 이 구조에서는 벤더 장비가 능동적으로 outbound leg을 만들어줘야 한다.
4. Bridge 모드로는 안 된다. B2BUA(IVR) 모드가 필요.

벤더가 셋업을 B2BUA 모드로 변경했고, 멀티콜이 정상 동작하기 시작했습니다. 9콜 동시 발신까지 확인 완료.

4단계: 두 가지 추가 이슈 발견

B2BUA 모드로 바꾸고 멀티콜은 됐지만, 또 다른 문제가 보였습니다.

이슈 A — 200 OK 타이밍 문제

벤더 PBX가 캐리어로 outbound leg을 거는 즉시 AI에 200 OK를 보냈습니다. 사용자가 받기도 전인데. AI는 "받았다"고 인식해서 greeting을 시작했고, 그동안 ringback tone이 early media로 흘러들어왔습니다.

결과: AI가 ringback에 대고 인사하는 꼴.

잘못된 흐름:
[AI] ──INVITE──► [벤더] ──INVITE──► [캐리어 → 사용자 폰 울리는 중]
[AI] ◄──200 OK── [벤더]   (사용자는 아직 안 받음!)
[AI] "안녕하세요, 여론조사입니다..."
[AI] ◄══ ringback "뚜루루루~" ══ (early media로 들어옴)

해결 방향: 벤더는 ringing 단계에서 180 Ringing 또는 183 Session Progress를 보내야 합니다. 200 OK는 사용자가 진짜 받은 후에만.

올바른 흐름:
[AI] ──INVITE──► [벤더] ──INVITE──► [캐리어]
[AI] ◄──180 Ringing── [벤더]   (이때 AI는 대기)
                                   사용자가 진짜 받음
[AI] ◄──200 OK── [벤더]
[AI] "안녕하세요, 여론조사입니다..."   ← 이때 시작

이슈 B — 음성사서함이 사용자로 인식됨

사용자가 안 받으면 캐리어 음성사서함이 받았습니다. AI는 이걸 사람으로 오인하고 greeting + STT를 진행. 결과는 AI가 음성사서함에 인사하고 음성사서함의 안내 메시지를 STT로 transcribe하는 상황. AI vs AI 통화가 transcript에 그대로 기록됐습니다.

해결 방향: 사용 중인 음성 플랫폼이 자동응답기 감지 기능을 제공하는지 확인하고, 감지 결과에 따라 통화를 종료하도록 설정합니다. 옵션명과 오탐·미탐 특성은 해당 플랫폼의 공식 문서와 실제 통화 테스트로 확인해야 합니다.

5단계: 통신 환경의 구조적 문제

기술 이슈와 별개로, 트러블슈팅이 길어진 이유 중 하나는 고객사가 운영 서버에서만 테스트했다는 것입니다. dev/staging 환경 없이 production에 직접 AI 에이전트를 붙여서 테스트하다 보니, 벤더가 설정을 변경할 때마다 고객사 서버를 재시작해야 했고, 그 재시작은 업무 시간 외에만 가능했습니다. 이게 모든 troubleshooting cycle의 병목이 됐습니다.

[설정 변경 한 번 사이클]
벤더가 셋업 변경 (5분)
  ↓
고객사가 운영 서버 재시작 (업무 시간 외만 가능 → 24시간 대기)
  ↓
테스트 (5분)
  ↓
결과 공유 (수 시간)
  ↓
다음 변경 ...

한 번의 셋업 변경 검증에 하루가 걸리는 구조.

6. 교훈 — SA가 사전에 강제해야 할 것

1. SIP 트렁크 도입 시 "누가 발신 주체인가"를 먼저 합의해야 한다

발신 주체가 누구냐에 따라 트렁크 셋업 모드가 완전히 달라집니다. 이 합의 없이 셋업하면 벤더가 자기 가정대로 설정하고, 나중에 다 뒤집어야 합니다.

2. Bridge ≠ B2BUA(IVR)

같은 SIP 장비라도 모드에 따라 동작이 완전히 다릅니다.

• Bridge — 단순 통로 (수동 중계자)
• B2BUA — 능동 콜 매니저

시스템이 두 call leg를 독립적으로 제어해야 한다면 B2BUA 구성이 적합할 수 있습니다. 실제 선택은 사업자 call flow와 기능 문서를 기준으로 합니다.

3. SIP 시그널링의 정확한 의미를 알아야 디버깅이 가능하다

• 200 OK = INVITE 성공 최종 응답
• 180·183 = 임시 응답이며, early media 유무는 SDP와 망 정책까지 함께 확인
• B2BUA에서는 하위 leg의 응답 상태와 상위 leg의 200 시점을 대조

이걸 모르면 "왜 AI가 ringback에 대고 말하지?"의 원인을 못 찾습니다.

4. 음성사서함은 항상 별도로 처리해야 한다

사람과 음성사서함 구분은 확률적입니다. 자동응답기 감지를 제공하는 플랫폼이라면 오탐·미탐을 측정하고, 종료 정책과 상담원 이관 같은 예외 처리를 함께 설계해야 합니다.

5. dev/staging 환경 없이 production만으로 트러블슈팅하면 모든 사이클이 느려진다

운영 서버를 재시작해야 설정 변경이 반영되는 환경에서는 디버깅 한 번에 며칠이 걸립니다. SIP 트렁크 같은 인프라 통합 프로젝트에서는 별도 테스트 환경 확보가 필수.

6. 사전 아키텍처 정렬이 트러블슈팅 시간을 결정한다

이번 케이스에서 양쪽이 처음부터 콜 플로우(누가 발신하고, 누가 받고, 어디서 음성 처리하는지)를 합의했다면 며칠짜리 디버깅을 안 해도 됐습니다. 솔루션 아키텍트의 역할 중 하나는 이런 사전 정렬을 강제하는 것입니다.

7. 의사결정 체크리스트

SIP 트렁크 + AI 보이스 에이전트 통합 프로젝트 초반에 양쪽이 같이 답해야 할 질문:

이 항목을 사전에 합의하면 설정 변경과 재시험 횟수를 줄일 수 있습니다.

마치며

SIP 트렁크는 표준 프로토콜을 사용하지만, 사업자 장비의 설정명과 시그널링 동작은 제품마다 다릅니다. 직접 발신하는 AI 음성 시스템을 연동할 때는 모드 이름보다 실제 call flow, answer supervision, 동시 세션 정책을 먼저 확인해야 합니다.

이 글이 비슷한 트러블슈팅을 겪을 누군가에게 시간을 아껴주길.

관련 글

• #32 시그널링과 미디어의 분리 — RTSP / SIP vs RTP의 통제 평면
• #36 iOS VoIP Push 구성 — APNs, PushKit, CallKit
• #35 iOS VoIP 통합의 4-레이어 모델

참고 자료

• RFC 3261 — SIP: Session Initiation Protocol — UAC/UAS, 다이얼로그, 메시지 포맷 정의
• RFC 7092 — B2BUA Taxonomy — B2BUA의 역할과 기능 범위
• RFC 3264 — Offer/Answer Model — SDP 기반 미디어 파라미터 합의
• RFC 3960 — Early Media and Ringing Tone — 180/183과 early media 처리
• RFC 3550 — RTP / RTCP — 미디어 전송과 품질 피드백
• RFC 4566 — SDP: Session Description Protocol — 코덱·포트·미디어 파라미터 협상
• RFC 7118 — SIP over WebSocket — 브라우저에서 SIP를 쓸 때의 전송 계층