오픈소스 Kamailio 6개월 활용기 — Asterisk 대신 선택한 이유와 실전 운영 노하우

왜 Kamailio였나 — Asterisk와 FreeSWITCH 사이에서 6개월 고민한 결과

Kamailio는 오픈소스 SIP 서버입니다. SIP 시그널링(통화 연결, 등록, 라우팅)에 특화된 프록시이며, 미디어(음성·영상 데이터) 자체를 처리하지는 않습니다. 저는 6개월 동안 자체 VoIP 인프라를 구축하면서 Asterisk와 FreeSWITCH도 함께 검토했고, 결국 Kamailio + rtpengine 조합으로 안착했습니다. 이 글은 그 6개월의 솔직한 활용기입니다.

결론부터 말씀드리면 Kamailio는 "통화량은 많지만 통화 처리 로직은 단순한" 환경에 가장 강력합니다. 초당 수천 건의 SIP 메시지를 처리해야 하는 트렁크 SBC, 대규모 사용자 등록 처리, 멀티 도메인 SIP 라우팅 같은 시나리오입니다. 반면 IVR이나 회의실, 음성 인식 같은 미디어 기능이 핵심이면 Asterisk나 FreeSWITCH가 정답입니다.

셋의 차이를 한 표로 정리하면 이렇습니다.

항목	Kamailio	Asterisk	FreeSWITCH
주력 영역	SIP 시그널링 프록시	PBX, 미디어 처리	미디어 + 시그널링
동시 호 처리	수만~수십만	수백~수천	수천~수만
설정 언어	kamailio.cfg (C 유사)	extensions.conf, dialplan	XML + Lua/JS
러닝 커브	가파름 (1-2개월)	완만	중간
미디어 기능	없음 (rtpengine 별도)	풍부 (IVR, 회의)	매우 풍부
적합한 케이스	SBC, 등록 서버, 라우터	중소 PBX, 콜센터	대규모 미디어 처리

저의 요구는 월 활성 사용자 약 5,000명, 동시 호 평균 200건, 피크 800건 규모였습니다. 미디어 처리는 단순 P2P 연결이면 충분했고, 핵심은 NAT 환경에서 안정적인 SIP 라우팅과 등록 처리였습니다. Asterisk로 시도하면 동시 호 800에서 CPU가 한계에 가까워졌고, FreeSWITCH는 풍부한 기능 대비 운영 복잡도가 너무 높았습니다. Kamailio + rtpengine 조합이 가장 가벼웠습니다.

첫 설치와 가장 큰 좌절 — NAT 한 줄 때문에 3일을 날렸습니다

솔직하게 말하면 Kamailio 첫 셋업은 정말 어려웠습니다. Ubuntu 22.04에 패키지로 설치하는 것까지는 쉽습니다. 문제는 그 다음, kamailio.cfg를 열어보는 순간이었습니다. 약 1,200줄의 설정이 거의 C 언어처럼 생겨있고, 어떤 부분을 건드려도 되는지 처음에는 전혀 감이 안 잡혔습니다.

첫 주에 가장 시간을 잡아먹은 것은 NAT(Network Address Translation) 처리였습니다. 사내 테스트에서는 잘 되던 통화가 외부 네트워크에서는 음성이 한 방향으로만 흐르는 "one-way audio" 현상이 반복되었습니다. 결국 원인은 단순했습니다. SIP 메시지의 Contact 헤더를 NAT 경계에서 다시 써주는(fix_nated_contact) 호출 한 줄이 빠져있었던 것입니다.

최종적으로 동작한 NAT 처리 핵심 부분은 이렇습니다.

request_route {
    # 1) 기본 검사와 라우팅
    route(REQINIT);
    route(NATDETECT);

    # 2) 등록 요청 처리
    if (is_method("REGISTER")) {
        if (isflagset(FLAG_NATED)) {
            fix_nated_register();
            force_rport();
            setbflag(FLAG_NAT_REPLY);
        }
        route(REGISTRAR);
        exit;
    }

    # 3) 호 셋업 시 미디어 NAT 보정
    route(NATMANAGE);
    route(RELAY);
}

route[NATDETECT] {
    force_rport();
    if (nat_uac_test("19")) {
        if (is_method("REGISTER")) {
            fix_nated_register();
        } else {
            add_contact_alias();
        }
        setflag(FLAG_NATED);
    }
}

두 번째로 시간을 많이 쓴 것은 rtpengine 연동이었습니다. Kamailio가 SIP 시그널링만 처리하므로 미디어(RTP)는 별도 컴포넌트가 필요합니다. rtpengine은 sysvinit 서비스로 띄우고, Kamailio에서는 rtpengine 모듈을 통해 호출합니다. 핵심 설정은 modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:22222") 한 줄과, 호 라우팅 시 rtpengine_manage("replace-origin replace-session-connection"); 호출입니다.

운영하며 가장 자주 만진 설정 — 모듈 8개와 파라미터 4개

6개월 운영하면서 실제로 가장 자주 건드린 모듈과 파라미터를 정리합니다. 처음 설정할 때 "이건 알아두면 좋다"는 항목입니다.

핵심 모듈 8개입니다.

모듈	역할	왜 중요한가
`tm`	트랜잭션 관리	모든 SIP 요청·응답 처리의 기본
`rr` / `record_route`	다이얼로그 라우팅	호 중간에 Kamailio가 빠지지 않게 함
`auth` / `auth_db`	인증	등록·발신 시 사용자 검증
`usrloc` / `registrar`	사용자 위치 저장	등록된 디바이스 IP/포트 추적
`nathelper`	NAT 처리	외부 클라이언트 통화 안정성
`rtpengine`	미디어 프록시 연동	RTP 흐름과 코덱 제어
`siputils`	SIP 헤더 조작	메시지 분기 처리에 필수
`htable`	인메모리 KV 저장	레이트리밋, 임시 상태 저장

건드릴 만한 가치가 있는 파라미터 4개입니다. 첫째, children=8입니다. UDP 워커 프로세스 수로, CPU 코어 수의 1-2배가 적정입니다. 둘째, tcp_children=8입니다. TCP/TLS 사용 시 별도로 잡아야 합니다. 셋째, shm_mem_size=512입니다. 메모리 부족 에러가 자주 보이면 키워야 합니다. 넷째, pkg_mem_size=16입니다. 프로세스별 패키지 메모리로, 복잡한 cfg에서는 32-64까지 필요할 수 있습니다.

Docker로 운영하시는 분이라면 docker-compose 예시도 공유합니다.

services:
  kamailio:
    image: kamailio/kamailio:5.7-alpine
    network_mode: host  # SIP는 host 네트워크가 안전
    volumes:
      - ./kamailio.cfg:/etc/kamailio/kamailio.cfg:ro
      - ./tls:/etc/kamailio/tls:ro
    environment:
      - KAMAILIO_DBHOST=postgres
      - KAMAILIO_DBNAME=kamailio
    depends_on: [postgres, rtpengine]

  rtpengine:
    image: drachtio/rtpengine:latest
    network_mode: host
    command: --interface=10.0.0.5 --listen-ng=22222 --port-min=20000 --port-max=30000

  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: kamailio
      POSTGRES_USER: kamailio

6개월 동안 배운 운영 교훈 5가지

교훈 1. SIP 트레이스 없이는 디버깅 불가능합니다. 처음에는 syslog와 kamailio.log만 보면서 디버깅했는데, 절반은 추측에 가까웠습니다. sngrep을 설치하고부터 디버깅 시간이 5배 빨라졌습니다. sngrep은 ngrep 기반의 SIP 트레이스 도구로, 화면에서 호 단위로 SIP 메시지를 실시간 확인합니다. apt install sngrep 한 줄 설치, sngrep -d eth0 port 5060 실행으로 끝입니다.

교훈 2. Configuration as Code로 관리하지 않으면 무너집니다. 운영 한두 달 만에 kamailio.cfg가 1,500줄을 넘어갔고, 어떤 부분을 누가 언제 왜 추가했는지 기억나지 않았습니다. 모든 cfg를 Git으로 관리하고, 변경마다 커밋 메시지에 "왜"를 적는 습관을 들여야 합니다. include 지시자로 cfg를 도메인별·기능별 파일로 쪼개는 것도 강력히 추천합니다.

교훈 3. DB 백엔드 선택이 성능에 큰 영향을 줍니다. 처음에는 MySQL로 시작했다가 등록 사용자가 3,000명을 넘어가니 usrloc 동기화 지연이 보이기 시작했습니다. db_mode=1(write-back) 모드로 바꾸고, 더 나아가 인메모리 캐시(htable + dmq)로 옮기면서 등록 처리 지연이 90% 감소했습니다. PostgreSQL이나 Redis 백엔드도 옵션입니다.

교훈 4. 보안은 첫날부터 신경 써야 합니다. 인터넷에 SIP 5060 포트를 열어두면 6시간 안에 SIP 스캐너가 들어옵니다. 저도 첫 주에 일주일 동안 약 12,000건의 무차별 등록 시도를 받았습니다. pike 모듈로 레이트리밋, fail2ban 연동, sip_router_role로 명시적 화이트리스트를 처음부터 설정해야 합니다.

교훈 5. 모니터링과 메트릭이 안정성의 절반입니다. Kamailio는 kamcmd 명령으로 거의 모든 내부 상태를 조회할 수 있습니다. 이걸 Prometheus exporter로 노출하고 Grafana 대시보드로 본 뒤로 장애 인지 시간이 평균 30분 → 3분으로 줄었습니다. 핵심 지표는 동시 활성 다이얼로그, REGISTER 성공률, INVITE 응답 시간 분포 세 가지입니다.

솔직한 추천 정리입니다.

대상	추천 여부	이유
대규모 SIP 트렁크/SBC 운영	✅ 강력 추천	초당 수천 메시지 처리에 가장 가벼움
멀티테넌트 SIP 등록 서버	✅ 강력 추천	usrloc + dmq 조합이 강함
로드밸런서 / 라우터	✅ 강력 추천	Dispatcher 모듈이 단순하고 빠름
중소 PBX (수십~수백 사용자)	⚠️ 비추	Asterisk가 훨씬 쉽고 빠름
IVR·콜센터·녹취 중심	⚠️ 비추	FreeSWITCH나 Asterisk 필요
VoIP를 처음 시작하는 1인 개발자	⚠️ 비추	러닝 커브가 가파름. Asterisk부터 시작 권장

저처럼 학습 비용을 감수할 수 있고 트래픽이 많은 환경이라면 Kamailio가 결국 가장 가성비 좋은 선택입니다. 단일 인스턴스로 동시 호 1만 건도 처리 가능하고, RAM 1-2GB로 1만 사용자 등록을 유지할 수 있습니다. 클라우드 비용 관점에서 Asterisk 클러스터 대비 인프라 비용이 50-70% 낮아질 수 있습니다.

처음 시작하시는 분이라면 저는 다음 순서를 권합니다. 1) Asterisk나 FusionPBX로 SIP 개념 익히기(2-4주). 2) Kamailio 공식 문서의 "Kamailio Getting Started"와 "SIP Routing in Lua" 읽기(1주). 3) 작은 트래픽으로 Kamailio + rtpengine 셋업해보기(2주). 이 순서를 거치지 않고 바로 Kamailio부터 시작하면 한 달 동안 진도가 거의 안 나갑니다.

마지막으로, Kamailio를 도입할 때 가장 중요한 것은 "왜 이걸 쓰는가"를 명확히 하는 것입니다. "빠르다고 들어서"는 충분하지 않습니다. 트래픽 규모, 미디어 요구, 팀의 SIP 이해도를 함께 보고 결정해야 1년 뒤에 후회하지 않습니다.

자주 묻는 질문 FAQ

Q. Kamailio만 있으면 통화가 가능한가요? A. 시그널링은 가능하지만, 실제 음성·영상 데이터는 별도 미디어 처리기가 필요합니다. 가장 일반적인 조합은 Kamailio + rtpengine입니다. RTP 흐름 제어, 코덱 변환, 녹취 같은 미디어 기능은 모두 rtpengine 또는 Asterisk/FreeSWITCH 같은 미디어 서버에서 처리합니다.

Q. 학습 자료는 어디가 가장 좋나요? A. 공식 위키(kamailio.org/wiki)가 가장 정확하지만 처음 보면 어렵습니다. 입문서는 "Building Telephony Systems with Kamailio (Packt)"가 한국어 자료가 거의 없는 한국 시장에서 가장 체계적입니다. 실전 예제는 GitHub의 kamailio/kamailio-config-utils 저장소를 참고하시면 됩니다. YouTube에서는 "Daniel-Constantin Mierla"(메인 메인테이너) 강의가 깊이가 좋습니다.

Q. 한국에서 Kamailio 사용 사례가 있나요? A. 공개된 사례는 많지 않지만 통신사, 클라우드 컨택센터(CCaaS) 사업자, B2B SIP 트렁크 사업자들이 내부적으로 사용합니다. 인터넷 전화(VoIP) 기반 서비스를 운영하는 스타트업이라면 검토할 가치가 있습니다. 다만 한국어 커뮤니티가 작아서, 영어 문서를 읽고 GitHub Issues에 직접 질문하는 게 가장 빠른 학습 경로입니다.

이 글이 도움이 되셨다면 공유해 주세요.