장다윗_

• 전화로 인입되는 상담을 채널톡에서 통합 응대·관리하려는 니즈가 꾸준했고, 이를 위한 전화 연동 서비스 개발이 필요했습니다.
• 음질·지연 등 전화 품질을 직접 컨트롤하기 위해 로우 레벨부터 개발해야 하는 상황이었습니다.
• 초기 멤버로 합류해 메인 API 및 도메인 모델 설계·개발을 진행했습니다.
• SIP 프로토콜 리시빙/서빙 및 미디어 스트리밍을 위해 서버를 분리하고, 메인 API 서버와의 통신 규약을 protobuf로 정의했습니다.
• 핵심 기능 출시 후 유지보수·모니터링 시스템을 구축했고, 이후 STT·TTS·호 보류 등 부가 기능을 개발, IVR을 채널톡의 다이어그램 기반 상담 자동화 도구인 워크플로우와 연동해 개발했습니다.

• 채널톡 트래픽의 대부분은 메시지 전달입니다. 이를 중개하는 Redis pub/sub과 알림 서버를 모니터링하던 중, 실제 전달 용량보다 훨씬 많은 트래픽이 발생함을 인지했습니다.
• 디깅 결과 socket.io Redis adapter의 Pattern subscription에서 비효율적 비용이 발생함을 발견했습니다 — 모든 소켓 서버가 모든 chat의 publish를 수신하고 있었습니다.
• 채널톡 특성에 맞게 어댑터를 직접 재구현해 Pattern subscription을 제거하고, 클라이언트가 Room에 join할 때만 subscribe하도록 했습니다. (그룹챗·유저챗의 참여 특성 등 추가 최적화)

↗ 관련 기술 블로그 글

• 채널톡 소켓(알림) 서버는 하루 평균 1억 9천만 건, 분당 13만 건의 이벤트를 처리합니다.
• 기존에는 채널 단위로 수동 파티셔닝하여 각 파티션에 별개의 Redis·알림 서버를 두었으나, 채널별 사용량 편차와 특정 고객사의 집중으로 핫 파티션 문제가 발생했고 리밸런싱도 수동으로 복잡했습니다.
• Redis Clustering과 Redis 7의 Sharded Pub/Sub을 리서치해 구조를 개선했습니다. 당시 node-redis에 필요한 커맨드 구현이 없어 직접 컨트리뷰트하기도 했습니다.
• Cluster의 해시태그 기능으로 부하를 고루 분산하고, 메인 API 서버의 직접 Publish 구조를 제거해 무작위 알림 서버로 Broadcast하도록 결합도를 낮췄습니다.