AI 콜봇 멀티콜이 안 되던 날 — SIP 트렁크 Bridge 모드 vs B2BUA(IVR) 모드

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

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

0. 핵심 명제 — "누가 발신 주체인가"가 트렁크 셋업 모드를 결정한다

같은 SIP 트렁크 장비라도 셋업 모드(Bridge vs B2BUA)에 따라 동작이 완전히 다르다. 외부에 PDS 같은 발신 장비가 따로 있으면 Bridge 모드로 충분하지만, AI 콜봇처럼 "시스템이 직접 발신하는" 구조에서는 반드시 B2BUA(현장에서 'IVR 모드'로 부름)여야 멀티콜이 정상 작동한다.

흔한 오해와 정정:

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

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

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

SIP 주요 메시지

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

이 둘의 차이는 음성 데이터를 미리 흘려보내느냐 여부입니다.

180은 단순한 "울리는 중" 시그널입니다. 발신자 폰에서 들리는 "뚜루루루"는 발신자 측 장비가 자체적으로 만듭니다.

183은 음성 채널을 미리 열어서 수신자 측의 특별한 소리를 발신자에게 들려주고 싶을 때 씁니다. 한국 통신망에서 흔히 듣는 케이스:

• 컬러링 ("아이유의 좋은날~")
• 통화중 안내음 ("지금 거신 번호는...")
• 콜센터 안내방송

모두 early media로 전달됩니다. 한국에서는 컬러링 문화 때문에 183을 매우 자주 사용합니다.

핵심: 180이든 183이든 "아직 안 받음" 상태입니다. "받았음"을 확정하는 건 오직 200 OK.

이걸 모르면 뒤에서 다룰 "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 ══════════════│
        (별개 다이얼로그 / 별개 Call-ID / 별개 미디어 세션)

Proxy와의 결정적 차이:

기업용 IP-PBX 대부분은 이런 부가 기능 때문에 B2BUA로 구현되어 있습니다. 이번 글의 "IVR 모드 트렁크" 역시 B2BUA로 구현된 사업자 장비의 한 동작 모드입니다.

SIP의 친구 프로토콜

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

INVITE의 메시지 바디에 SDP가 실리고, SDP가 협상한 포트로 RTP가 흐릅니다. (자세한 시그널링·미디어 평면 분리는 #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. 프로토콜 변환 — 인터넷의 SIP를 통신망의 ISUP/SS7으로 변환 (또는 반대)
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 시스템입니다. 콜을 받으면 자기가 안내를 띄우고, 필요할 때 다른 곳으로 transfer/dial하고, 콜 상태를 끝까지 관리. 현장에서 "IVR 모드"라고 부르는 이유는, 자동응답시스템(IVR)이 이 B2BUA 구조의 대표적인 예시이기 때문입니다. 정확한 업계 용어는 B2BUA지만 두 표현은 같은 모드를 가리킵니다.

왜 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 관리

각 콜이 별도 객체로 운영되니 9개, 10개도 동시 처리 가능합니다.

한눈에 비교

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

등장 인물 (익명)

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

실제 시스템 구조

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

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

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

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

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

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

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

2단계: 멀티콜 실패

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

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

해석: Bridge 모드 장비가 들어온 INVITE에 자동으로 200 OK를 응답해버려서, AI가 "받았다"고 인식하고 greeting을 시작해버리는 상황. 실제 사용자는 받지도 않았는데.

Bridge 모드가 멀티콜에서 깨지는 4가지 메커니즘

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

INVITE (call 1) ──┐
INVITE (call 2) ──┼──► Bridge Mode 트렁크
INVITE (call 3) ──┘         ↓
              "어? 나는 PDS가 앞에 있다고 설정됨"
              "PDS가 이미 세션 관리하는 줄 알았는데"
              "여러 INVITE가 동시에 오면 누가 주도권?"
                            ↓
                ❌ 세션 충돌 / 라우팅 실패 / 드롭

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

B2BUA 모드로 전환하면 이 4가지가 한 번에 풀리는 이유:

핵심: Bridge 모드는 "내가 가운데 다리"라는 정체성, B2BUA는 "내가 양쪽 호의 주인"이라는 정체성. 발신 주체가 시스템 내부에 있을 때 다리는 멀티콜을 견디지 못합니다.

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에 그대로 기록됐습니다.

해결 방향: AI 보이스 에이전트 측에서 voicemail 감지 옵션(예: end_call_on_voicemail = true)을 활성화. voicemail 감지 시 자동 hangup. [NEEDS VERIFICATION — 플랫폼별 정확한 파라미터 이름은 사용 중인 SDK 문서 확인 필요]

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

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

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

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

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

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

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

2. Bridge ≠ B2BUA(IVR)

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

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

AI 콜봇처럼 시스템이 직접 발신하고 콜 상태를 능동적으로 다루는 구조에서는 반드시 B2BUA(IVR) 모드여야 합니다.

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

• 200 OK = "받았다"의 확정 신호
• ringing 단계에서는 180 또는 183이어야 함
• 한국 통신망은 컬러링 때문에 183 + early media를 자주 씀

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

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

AI 콜봇은 사람과 음성사서함을 구분 못 합니다. 플랫폼 차원에서 voicemail 감지 옵션을 반드시 활성화해야 합니다. 이게 없으면 transcript가 음성사서함 안내문으로 가득 찹니다.

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

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

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

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

7. 의사결정 체크리스트

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

이 7가지를 사전에 합의했다면, 트러블슈팅이 며칠짜리에서 몇 시간짜리로 줄어듭니다.

마치며

SIP 트렁크는 표준 프로토콜이지만, 벤더 장비의 셋업 모드와 시그널링 동작은 케이스마다 다릅니다. AI 음성 에이전트가 늘어나면서 "직접 발신하는 시스템"이 일반화되고 있고, 이런 환경에서는 Bridge 모드가 아닌 B2BUA 모드의 트렁크 셋업이 표준이 되어야 합니다.

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

관련 글

• #32 시그널링과 미디어의 분리 — RTSP / SIP vs RTP의 통제 평면
• #36 VoIP 푸시 인프라 완전 가이드
• #35 iOS VoIP 통합의 4-레이어 모델

참고 자료

• RFC 3261 — SIP: Session Initiation Protocol — UAC/UAS, 다이얼로그, 메시지 포맷 정의
• RFC 3550 — RTP / RTCP — 미디어 전송과 품질 피드백
• RFC 4566 — SDP: Session Description Protocol — 코덱·포트·미디어 파라미터 협상
• RFC 7118 — SIP over WebSocket — 브라우저에서 SIP를 쓸 때의 전송 계층
• B2BUA 개념 및 IP-PBX 아키텍처 한국어 정리: NExpert — SIP Overview