기업 통화망은 사내 사설 교환기(PBX) 중심 구조와 IP 패킷으로 음성을 전달하는 VoIP(Voice over Internet Protocol) 구조를 함께 사용합니다.
특히 센트릭스(Centrex)는 기업 내부에 복잡한 교환 장비를 직접 두지 않고, 통신사의 클라우드 교환 기능을 임대해 사용하는 방식입니다. 기업은 전화기와 내부 네트워크를 관리하고, 교환 기능과 부가 서비스는 중앙 플랫폼에서 제공받습니다.
이 변화의 장점은 분명합니다. 초기 장비 비용을 줄일 수 있고, 내선 증설이나 자리 이동이 쉬워지며, 지사 확장 시에도 동일한 번호 체계와 부가 서비스를 유지하기 쉽습니다. 하지만 VoIP와 Centrex를 단순히 “통신비 절감 솔루션”으로만 보면 중요한 위험을 놓칩니다.
기업용 인터넷 전화의 품질은 통신사 구간뿐 아니라 SIP 보안, RTP 품질, 내부망 QoS, Voice VLAN과 모니터링 체계의 영향을 함께 받습니다. 이 글에서는 VoIP와 Centrex의 기술 구조를 실무 관점에서 정리하고, 도입 시 확인할 보안과 품질 관리의 맹점을 함께 분석합니다.
검증 범위. 이 글은 특정 기업의 통화 캡처, R-Factor 원본이나 장애 로그를 제시하는 사례 보고서가 아닙니다. 실제 도입과 장애 판정에는 같은 통화 시각의 SIP 신호, 양방향 RTP·RTCP, 스위치 큐와 회선 품질 기록이 필요합니다.
1. VoIP와 Centrex는 PBX를 클라우드로 옮기는 것에서 출발합니다
전통적인 기업 전화망은 사내 PBX를 중심으로 구성되었습니다. 내선 번호, 당겨받기, 착신전환, 대표번호 라우팅, 외부 발신 제어 같은 기능을 기업 내부 장비가 처리했습니다. 이 구조는 통제권이 명확하다는 장점이 있지만, 장비 구매비, 유지보수, 증설 작업, 장애 대응 부담이 모두 기업 내부에 남습니다.
Centrex는 이 교환 기능을 클라우드 서비스처럼 사용하는 방식입니다. 기업은 IP 전화기나 소프트폰을 네트워크에 연결하고, 호 제어와 부가 서비스는 중앙 교환 플랫폼에서 처리합니다. 자리 이동이 잦은 사무실, 지점 확장이 많은 조직, 전화 운영 인력이 부족한 중소·중견 기업에는 상당히 현실적인 선택지입니다.
하지만 Centrex가 모든 기업에 무조건 맞는 것은 아닙니다. 대규모 콜센터, 복잡한 CTI(Computer Telephony Integration) 연동, 자체 CRM이나 ERP와의 API 통합이 필요한 환경에서는 플랫폼이 제공하는 정책과 연동 범위가 제약이 될 수 있습니다. 초기 구축 비용이 줄어드는지는 장비·회선·라이선스·연동과 운영 비용을 같은 기간으로 비교해 판단해야 합니다.
따라서 Centrex 도입 여부는 단순 요금 비교가 아니라 다음 기준으로 판단해야 합니다.
| 판단 기준 | Centrex에 유리한 경우 | 별도 설계 검토가 필요한 경우 |
|---|---|---|
| 조직 규모 | 중소 규모 사무실, 다지점 영업망 | 대규모 콜센터, 복합 교환 정책 |
| 운영 인력 | 통신 장비 전담자가 부족한 조직 | 자체 통신 운영팀이 있는 조직 |
| 부가 서비스 | 내선, 당겨받기, 착신전환 중심 | CTI, 녹취, CRM 연동, 맞춤 라우팅 중심 |
| 비용 구조 | 초기 장비 투자 축소가 중요한 경우 | 장기 사용량과 연동 비용이 더 중요한 경우 |
| 통제권 | 표준 기능 중심 운영 | 자체 정책과 API 통합이 핵심인 운영 |
핵심은 장비를 없앴다고 통신 운영 책임이 사라지는 것이 아니라는 점입니다. PBX 장비의 물리적 부담은 줄어들지만, 내부망 품질과 보안 정책을 설계할 책임은 여전히 기업에게 남습니다.
2. SIP와 RTP/RTCP는 신호와 음성을 분리해 처리합니다
VoIP 기술의 중심에는 SIP(Session Initiation Protocol)와 RTP(Real-time Transport Protocol)가 있습니다. IETF RFC 3261은 SIP를 세션 생성, 수정과 종료를 위한 응용 계층 제어 프로토콜로 정의합니다.
반면 RTP는 실제 음성 데이터를 전달합니다. SIP가 “누구와 통화할 것인가”를 정한다면, RTP는 “실제 음성을 어떤 흐름으로 보낼 것인가”를 담당합니다. IETF RFC 3550은 RTP 데이터 전송과 RTCP 품질·참여자 정보를 함께 정의합니다.
아래 표는 등록 서버를 사용하는 기본 호 처리 흐름의 한 예입니다. 모든 구성에서 REGISTER가 필수인 것은 아니며, provisional response를 이용한 early media와 지연 offer/answer 여부에 따라 미디어 협상과 RTP 시작 시점도 달라질 수 있습니다. RFC 3264는 일반 offer/answer 모델을 정의하고, RFC 3261은 초기 INVITE에 offer가 없을 때 최종 2xx 응답의 offer와 ACK의 answer로 교환하는 SIP 흐름을 설명합니다. RFC 3960은 최종 응답 전 early media 처리 모델과 위험을 별도로 다룹니다.
| 단계 | 주요 동작 | 실무 의미 |
|---|---|---|
| REGISTER | registrar 등록을 사용하는 구성에서 단말이 현재 연락 주소를 알립니다. | 등록을 쓰지 않는 호 구성도 있으므로 필수 단계로 단정하지 않습니다. |
| INVITE | 발신 단말이 통화를 요청합니다. | 호 설정이 시작됩니다. |
| 100 Trying | 요청 처리 중임을 알립니다. | 중복 요청과 타임아웃을 줄입니다. |
| 180 Ringing | 수신 측의 착신 진행 상태를 알립니다. | 링백톤을 어느 쪽에서 생성하는지는 구성에 따라 다릅니다. |
| 200 OK | INVITE에 대한 최종 2xx 응답으로 통화 수락을 알립니다. | offer/answer는 앞서 끝났거나 지연 offer이면 ACK에서 마무리될 수 있습니다. |
| ACK | 발신 측이 INVITE의 2xx 최종 응답을 확인합니다. | RTP는 early media로 먼저 흐르거나 offer/answer 완료 뒤 시작될 수 있습니다. |
| BYE | 어느 한쪽이 통화를 종료합니다. | 세션과 리소스가 정리됩니다. |
이 구조는 효율적이지만 보호 구간을 구분해야 합니다. RFC 3261은 SIP의 SIPS URI와 TLS 사용을 설명하지만, TLS 보호는 각 홉의 구성과 신뢰 정책에 의존하므로 이를 통화 전체의 종단 간 암호화로 단정할 수 없습니다. 암호화와 인증 없이 운용하는 신호·미디어 구간은 도청, 자격 증명 악용과 비정상 발신 위험을 키울 수 있습니다.
실무자는 최소한 다음 항목을 도입 전 체크리스트로 확인해야 합니다.
| 보안 항목 | 점검 내용 | 누락 시 위험 |
|---|---|---|
| TLS | 단말부터 서비스까지 각 SIP 홉의 TLS·인증서 검증 범위 | 보호되지 않은 홉의 신호 정보 노출 가능성 |
| SRTP | 미디어 양 끝의 SRTP와 키 관리 방식 | 보호되지 않은 RTP 음성의 도청 가능성 |
| SBC | 경계 제어가 필요한 구성인지와 실제 활성 기능 | 필요한 접근 제어·NAT 연동·비정상 세션 통제가 빠질 가능성 |
| 인증 정책 | 단말 등록 인증과 비밀번호 정책 | 불법 단말 등록과 과금 피해 |
| 접근 제어 | 관리 포트와 SIP 포트 제한 | 외부 스캐닝과 무차별 대입 공격 |
RFC 3711은 SRTP가 선택한 보안 서비스와 키 관리에 따라 RTP·RTCP의 기밀성, 메시지 인증과 재전송 공격 보호를 제공하도록 정의합니다. RFC 5853과 RFC 7092는 SBC가 경계 방어, 접근 제어, 토폴로지 은닉과 NAT 연동 등의 기능을 수행할 수 있지만 실제 기능은 배치와 제품에 따라 달라짐을 보여 줍니다. 따라서 SBC 설치 여부만으로 안전을 판정하지 않고 활성 정책과 로그를 확인합니다.
3. VoIP 품질은 지연, 지터, 패킷 손실이 결정합니다
VoIP 통화 품질은 단순 대역폭만으로 결정되지 않습니다. 예를 들어 표시 속도가 1Gbps인 인터넷 회선도 내부 혼잡 구간에서 음성 패킷이 지연되거나 손실되면 통화 품질이 나빠질 수 있습니다. 여기서 1Gbps는 충분한 대역폭처럼 보이는 상황을 설명하는 가상 예이지 합격 기준이 아닙니다.
실무에서 가장 중요한 품질 지표는 지연(Delay), 지터(Jitter), 패킷 손실(Packet Loss), 에코(Echo)입니다.
| 품질 요소 | 의미 | 체감 증상 |
|---|---|---|
| 지연 | 음성이 상대방에게 도착하기까지 걸리는 시간 | 말이 늦게 들리고 대화가 겹칩니다. |
| 지터 | 패킷 도착 간격이 불규칙하게 흔들리는 현상 | 음성이 찌그러지거나 끊겨 들립니다. |
| 패킷 손실 | 음성 패킷 일부가 중간에서 사라지는 현상 | 말소리가 비거나 순간적으로 무음이 생깁니다. |
| 에코 | 자신의 목소리가 다시 들리는 현상 | 통화 집중도가 떨어지고 피로감이 커집니다. |
지연이 커질수록 자연스러운 대화가 어려워질 수 있습니다. ITU-T G.114은 종단 간 단방향 전송 시간의 영향을 다루며, 대화형 서비스는 일반 계획 상한보다 훨씬 낮은 지연에서도 영향을 받을 수 있다고 설명합니다. 합격 기준은 계약한 서비스와 코덱·망 구성에 맞춰 정해야 합니다.
통화 품질 문제는 외부 회선, 사내 LAN, 보안 장비, 단말과 서비스 플랫폼 중 어느 구간에서도 발생할 수 있습니다. 어느 한쪽을 먼저 원인으로 정하지 말고 같은 통화 시각의 양방향 지표를 비교해야 합니다.
예를 들어 업무 시간에 대용량 파일 다운로드, 클라우드 백업, 영상 회의, 보안 업데이트, NAS 복제 트래픽이 동시에 몰리면 음성 패킷은 일반 데이터 패킷과 경쟁하게 됩니다. 이때 내부 스위치와 라우터에서 음성 패킷을 우선 처리하지 않으면 VoIP 품질은 쉽게 무너집니다.
RFC 4594는 통신 음성과 신호를 서로 다른 DiffServ 서비스 클래스로 다루는 지침을 제시합니다. 실제 마킹과 큐 정책은 장비 지원, 사업자 경계의 재마킹 여부와 혼잡 시험 결과에 맞춰 다음 항목에서 선택합니다.
| 설계 항목 | 목적 | 실무 포인트 |
|---|---|---|
| Voice VLAN | 데이터망과 음성망을 논리적으로 분리합니다. | IP 전화기와 PC 트래픽을 같은 정책으로 처리하지 않습니다. |
| DSCP/CoS 마킹 | 음성 트래픽 우선순위를 표시합니다. | RTP 음성 패킷과 SIP 신호 패킷을 구분해 정책화합니다. |
| QoS 큐잉 | 혼잡 시 음성 패킷을 먼저 처리합니다. | 단순 대역폭 증설보다 우선순위 정책이 중요합니다. |
| 지터 버퍼 | 패킷 도착 흔들림을 완충합니다. | 너무 작으면 끊기고, 너무 크면 지연이 늘어납니다. |
| 트래픽 모니터링 | 장애 발생 전 품질 변화를 감지합니다. | NMS나 로그 기반으로 추이를 봐야 합니다. |
정리하면, VoIP 품질은 통신사가 일방적으로 제공하는 결과물이 아닙니다. 외부 회선 품질, 내부 스위치 설정, 단말 구성, VLAN 설계, QoS 정책이 함께 맞아야 완성됩니다.
4. R-Factor 측정은 개통 당일 한 번으로 끝나면 안 됩니다
VoIP 품질을 평가할 때 R-Factor(R값)를 활용할 수 있습니다. ITU-T G.107은 전송 계획을 위한 E-model을 정의합니다. R값을 단독 합격표로 쓰지 말고 코덱, 지연, 손실과 실제 통화 시험 조건을 함께 기록해야 합니다.
문제는 많은 기업이 개통 당일의 초기 품질만 확인하고 이후에는 거의 측정하지 않는다는 점입니다. 네트워크는 고정된 구조물이 아닙니다. 사용자가 늘고, 장비가 교체되고, 보안 장비 정책이 바뀌고, 클라우드 트래픽이 증가하면 VoIP 품질도 계속 변합니다.
특히 다음 변화가 생겼다면 R-Factor와 지터, 손실률을 다시 확인해야 합니다.
- 사무실 인원 또는 IP 전화기 수가 크게 늘어난 경우.
- 신규 보안 장비, 방화벽, UTM, SD-WAN 장비를 도입한 경우.
- 클라우드 백업, 영상 회의, VDI, 그룹웨어 트래픽이 증가한 경우.
- 스위치 교체 또는 VLAN 정책 변경이 있었던 경우.
- 특정 시간대에 통화 끊김 민원이 반복되는 경우.
R-Factor는 단순 보고서용 숫자가 아니라, 통화 품질 변화를 추적하기 위한 운영 지표로 써야 합니다. 개통 시점의 “정상”만 확인하는 방식은 사후 약방문에 가깝습니다. 최소한 주요 지점, 콜센터, 고객 응대 부서에서는 주기적인 품질 측정과 로그 기반 추세 분석이 필요합니다.
5. Centrex 도입 전 실무 체크리스트
기업용 인터넷 전화와 Centrex 도입을 검토한다면 아래 항목을 계약 전부터 확인해야 합니다. 이미 도입한 조직이라도 장애가 반복된다면 같은 기준으로 역점검할 수 있습니다.
| 점검 영역 | 확인 질문 |
|---|---|
| 회선 구성 | 음성 트래픽과 일반 데이터 트래픽이 같은 회선을 공유하는지 확인했는가. |
| 내부망 설계 | Voice VLAN을 분리하고 IP 전화기 포트를 별도 정책으로 관리하는가. |
| QoS 정책 | SIP 신호와 RTP 음성 패킷에 우선순위 정책을 적용했는가. |
| 보안 구조 | TLS, SRTP, SBC, 접근 제어 정책을 계약서 또는 설계 문서로 확인했는가. |
| 단말 관리 | IP 전화기 펌웨어, 관리자 비밀번호, 등록 계정 정책을 관리하는가. |
| 장애 대응 | 통화 끊김 발생 시 회선, 내부망, 단말, 서버 로그를 구분해 확인할 수 있는가. |
| 확장성 | 콜센터, 녹취, CRM, ERP 연동이 필요한 경우 API와 연동 범위를 확인했는가. |
| 품질 측정 | R-Factor, 지터, 패킷 손실을 개통 후에도 주기적으로 측정하는가. |
이 체크리스트의 목적은 공급사를 의심하자는 것이 아닙니다. 역할과 책임을 명확히 하자는 것입니다. Centrex는 중앙 교환 기능을 서비스로 제공하지만, 기업 내부의 네트워크 품질과 보안 운영까지 자동으로 해결해 주지는 않습니다.
6. PSTN에서 가져올 운영 원칙
병합한 PSTN 원고의 핵심은 오래된 장비를 유지하자는 주장이 아니라, 음성 서비스의 경로·전원·장애 영역을 명확히 하자는 데 있습니다.
| 운영 관점 | 회선 교환식 PSTN | 패킷 기반 VoIP에서 확인할 항목 |
|---|---|---|
| 경로 | 통화 동안 설정된 회선 경로를 사용합니다. | SIP 신호 경로와 양방향 RTP 경로를 각각 추적합니다. |
| 자원 | 통화 자원을 회선 단위로 배정합니다. | 공유 링크의 QoS 큐, 대역폭과 동시 통화 수를 확인합니다. |
| 전원 | 전통 단말은 가입자 선로의 전원을 사용할 수 있었습니다. | ONT, 라우터, PoE 스위치, IP 전화기와 플랫폼의 전원 의존성을 목록화합니다. |
| 장애 영역 | 가입자선, 교환기와 중계 회선으로 나눕니다. | 단말, 액세스 스위치, 방화벽·SBC, WAN과 서비스 플랫폼으로 나눕니다. |
| 종료 검증 | 통화 연결과 음성 품질을 확인합니다. | 발신·착신, 양방향 음성, 긴급·대표번호와 장애 우회 절차를 시험합니다. |
전통 전화 단말의 선로 전원 특성을 현재의 모든 전화 서비스에 그대로 적용할 수는 없습니다. 미국 FCC의 백업 전원 안내 명령도 전원을 별도로 공급받는 IP 기반 음성 서비스는 정전 때 백업 전원이 없으면 동작하지 않을 수 있음을 설명합니다. 실제 연속성은 ONT, 라우터, PoE 스위치, IP 전화기와 서비스 플랫폼 경로 중 어느 장비가 UPS 보호를 받는지와 시험한 유지 시간으로 판단합니다. 통화 품질 추세는 NMS 기반 네트워크 안정성 전략과 연결해 관리하고, 편통화나 NAT 가설은 망 분리와 패킷 분석 가이드의 캡처 절차로 검증합니다.
7. 한 통화의 SIP와 RTP를 묶는 재현 기록지
RFC 3261은 SIP 대화 식별에 Call-ID와 양쪽 태그를 사용하고, RFC 3550은 RTP의 시퀀스 번호·타임스탬프·SSRC와 RTCP 보고 구조를 정의합니다. 장애를 재현할 때는 SIP 화면과 RTP 통계를 따로 저장하지 말고 같은 시험 통화 ID로 연결합니다.
전화번호와 사용자 이름은 원본을 공개하지 않습니다. 운영팀 내부 식별자나 일관된 마스킹 값으로 바꾸되, 같은 단말을 다시 찾을 수 있는 대응표는 접근이 제한된 위치에 따로 보관합니다.
| 재현 항목 | 독자가 채울 값 |
|---|---|
| 시험 통화 ID | TEST-________ |
| 발신·착신 단말 | 발신 단말 ____ / 착신 단말 ____ / 번호 마스킹 ____ |
| 시작·종료 시각 | ____-__-__ __:__:__ ~ __:__:__ / UTC____ |
| 액세스 경로 | 발신 스위치·포트·VLAN ____ / 착신 ____ |
| SIP 대화 | Call-ID ____ / From tag ____ / To tag ____ |
| 최종 SIP 결과 | REGISTER ____ / INVITE 응답 ____ / BYE 주체 ____ |
| SDP 협상 | 코덱 ____ / 송수신 주소·포트 ____ / 방향 속성 ____ |
| RTP 송신 | SSRC ____ / 패킷 ____ / 손실 ____ / 지터 ____ |
| RTP 수신 | SSRC ____ / 패킷 ____ / 손실 ____ / 지터 ____ |
| 망 품질 근거 | RTCP ____ / 큐 드롭 ____ / 인터페이스 오류 ____ |
| 사용자 증상 | 무음·편통화·끊김·지연·에코 ____ |
지연과 R-Factor는 계산 도구의 결과만 옮기지 않습니다. ITU-T G.114과 ITU-T G.107의 적용 범위를 확인하고, 측정 방향, 코덱과 도구 버전을 함께 기록합니다.
증상별 판정은 다음과 같이 시작합니다.
- 등록 자체가 실패하면 DNS, 단말 시간, TLS 인증서, 계정과 REGISTER 응답 코드를 확인합니다.
- 등록은 되지만 착신 벨이 울리지 않으면 INVITE의 경로와 최종 SIP 응답, 번호 라우팅 정책을 확인합니다.
- 통화는 연결되지만 양쪽 모두 무음이면 SDP 주소·포트와 방화벽·SBC의 RTP 허용 범위를 확인합니다.
- 한쪽만 들리면 발신·착신 양쪽에서 같은 RTP 스트림의 송신과 수신 패킷 수를 비교해 사라지는 경계를 찾습니다.
- 음성이 끊기면 시퀀스 손실, 지터, 인터페이스 드롭과 QoS 큐 카운터를 같은 시간축에 놓습니다.
- 대화가 늦거나 에코가 나면 방향별 지연 측정법, 지터 버퍼, 단말 음향 경로와 에코 제어 상태를 분리합니다.
| 구성 | 실패 모드 | 구분에 필요한 증거 |
|---|---|---|
| 인터넷 기반 Centrex | 일반 인터넷 경로와 사업자 플랫폼 사이 어느 구간인지 모호합니다. | 내부 게이트웨이, 사업자 경계와 서비스 로그의 동일 Call-ID·시각 |
| SBC 경유 | SIP 주소는 변환되지만 SDP·RTP 주소가 의도와 다릅니다. | SBC 앞뒤 SIP·SDP와 미디어 릴레이 세션 ID |
| IP폰 PC 패스스루 | 전화와 PC가 같은 포트에서 Voice·Data VLAN을 다르게 사용합니다. | LLDP·VLAN 적용 상태와 전화기 양쪽 링크 정보 |
| Wi-Fi 소프트폰 | RF 로밍과 SIP 재등록·RTP 손실이 겹칩니다. | AP 전환 시각, 단말 Wi-Fi 로그와 RTP 시퀀스 |
| 아날로그 게이트웨이 | IP 구간은 정상이어도 FXO·FXS 신호와 임피던스에서 문제가 납니다. | 게이트웨이 포트 이벤트, 신호·코덱 설정과 IP 캡처 |
| 녹취·CTI 연동 | 통화는 되지만 복제 스트림이나 이벤트 전달만 실패합니다. | 원 통화 ID, 연동 세션 ID와 수신 애플리케이션 로그 |
재현이 끝나면 조치 전과 같은 번호 경로, 코덱, 단말과 시간대에서 다시 통화합니다. 조건이 달라졌다면 해결이 아니라 다른 조건에서 미재현으로 기록합니다.
결론. 성공적인 VoIP 전환은 장비 교체가 아니라 전략 설계입니다
기업용 인터넷 전화 VoIP와 Centrex는 구성에 따라 초기 장비와 내선 운영 부담을 줄일 수 있습니다. 실제 비용과 확장성은 계약, 연동 범위와 내부망 운영 책임을 포함해 비교해야 합니다.
하지만 도입의 편리함이 품질과 보안을 자동으로 보장하지는 않습니다. SIP가 암호화 없이 운용되면 통화 신호가 노출될 수 있고, RTP가 보호되지 않으면 음성 데이터가 위험해질 수 있습니다. 내부망에서 Voice VLAN과 QoS가 빠지면 충분한 대역폭을 확보해도 통화 품질은 쉽게 흔들립니다.
결국 성공적인 VoIP 전환은 어떤 상품을 선택했느냐보다 기업이 스스로의 네트워크 통제권을 얼마나 깊게 이해하고 있느냐에 달려 있습니다. TLS·SRTP·SBC·Voice VLAN·QoS·품질 측정의 적용 여부와 범위는 위협 모델, 서비스 계약, 단말 호환성과 망 구성에 따라 정하고, 설정과 시험 결과로 검증해야 합니다.
VoIP와 Centrex는 하드웨어를 줄이는 기술이 아니라, 통신 운영 방식을 바꾸는 전략입니다. 비용 절감 효과는 그 전략이 제대로 설계되었을 때 비로소 안정적인 품질과 함께 실현됩니다.