커뮤니티가 커질수록 음성 채팅은 왜 어려워질까?

디스코드의 기술 블로그에는 음성 인프라를 확장하며 겪은 고민과 해결 과정이 담겨 있습니다. 겉으로는 “음성 채널에 접속한다”는 단순한 기능처럼 보이지만, 실제로는 연결·라우팅·미디어 처리·장애 대응이 모두 맞물린 복잡한 시스템입니다.

헤이즐을 운영하는 커뮤니티 운영자라면, 규모가 커질수록 비슷한 문제를 만나게 됩니다. 이번 글에서는 디스코드의 음성 인프라 확장 사례에서 커뮤니티 서비스에 적용해볼 만한 핵심 원칙을 정리했습니다.

음성 채팅은 메시지보다 훨씬 까다롭습니다

텍스트 메시지는 잠시 지연되거나 순서가 조금 바뀌어도 대부분 다시 처리할 수 있습니다. 하지만 음성은 다릅니다.

• 아주 짧은 지연도 대화의 어색함으로 이어지고
• 패킷 손실은 끊김이나 로봇 같은 소리를 만들며
• 서버 한 곳의 장애가 여러 사용자의 대화에 동시에 영향을 줍니다

특히 커뮤니티가 성장하면 한 서버에 모든 음성 연결을 몰아넣는 방식은 빠르게 한계에 도달합니다. 중요한 건 단순히 서버 수를 늘리는 것이 아니라, 음성 시스템의 구조 자체를 확장 가능하게 만드는 일입니다.

1. 연결을 담당하는 영역과 음성을 처리하는 영역을 나누기

대규모 서비스에서는 사용자의 로그인이나 채널 입장을 처리하는 영역과 실제 음성 데이터를 전달하는 영역을 분리하는 것이 중요합니다.

쉽게 말하면 다음과 같습니다.

• “어느 음성 채널에 들어갈지”를 결정하는 서버
• “실제 음성 데이터를 주고받는” 미디어 서버

두 역할을 분리하면 한쪽의 부하가 다른 쪽으로 번지는 것을 줄일 수 있습니다. 사용자가 채널에 입장하는 요청이 몰리더라도 이미 연결된 음성 통화가 바로 영향을 받지 않게 만들 수 있죠.

헤이즐 같은 커뮤니티 서비스에서도 모든 기능을 하나의 서버와 프로세스에 넣기보다, 트래픽 특성이 다른 기능부터 분리해두면 이후 확장이 훨씬 수월해집니다.

2. 사용자와 가까운 서버에 연결하기

음성 품질에서 물리적 거리는 생각보다 큰 영향을 줍니다. 사용자가 서울에 있는데 음성 서버가 멀리 떨어져 있다면 지연 시간이 늘어나고, 네트워크 상태에 따라 음질도 불안정해질 수 있습니다.

그래서 대규모 음성 서비스는 사용자의 위치와 서버 상태를 함께 고려해 연결할 곳을 선택합니다.

여기서 중요한 기준은 단순한 거리만이 아닙니다.

• 현재 서버의 연결 수
• CPU와 네트워크 사용량
• 특정 지역의 장애 여부
• 예상되는 트래픽 변화

즉, “가장 가까운 서버”보다 “지금 가장 안정적으로 처리할 수 있는 가까운 서버”를 선택해야 합니다.

3. 평균보다 순간적인 트래픽을 봐야 합니다

커뮤니티 트래픽은 일정하게 움직이지 않습니다. 평소에는 조용하다가도 다음과 같은 순간에 사용자가 급증할 수 있습니다.

• 인기 스트리머의 방송 직후
• 이벤트나 온라인 모임이 시작되는 시간
• 새 기능이 공개된 직후
• 특정 커뮤니티에서 이슈가 발생한 순간

이때 평균 사용량만 기준으로 서버를 준비하면 갑작스러운 접속 증가를 감당하기 어렵습니다.

음성 인프라를 운영할 때는 평균값보다 다음 지표를 함께 살펴야 합니다.

• 최대 동시 음성 연결 수
• 분당 신규 연결 수
• 연결 실패율
• 음성 패킷 손실률
• 지연 시간과 끊김 발생 빈도

커뮤니티 운영자 입장에서는 “서버가 살아 있는가”보다 “사용자가 대화하기에 충분히 안정적인가”가 더 중요한 기준입니다.

4. 장애가 나도 전체가 멈추지 않게 만들기

대규모 시스템에서 장애를 완전히 없애는 것은 현실적으로 어렵습니다. 대신 장애가 발생했을 때 영향 범위를 작게 만드는 것이 중요합니다.

예를 들어 특정 음성 서버에 문제가 생겼다면:

1. 신규 사용자를 해당 서버로 보내지 않고
2. 정상 서버로 연결을 유도하며
3. 기존 연결은 가능한 한 유지하고
4. 복구 후 트래픽을 단계적으로 되돌리는 방식입니다

이런 구조를 만들려면 서버 상태를 지속적으로 확인하고, 연결 배정 로직이 상태 변화에 빠르게 반응해야 합니다.

커뮤니티 서비스에서도 모든 사용자가 같은 서버나 같은 데이터 흐름에 의존하지 않도록 분산해두면, 한 부분의 문제가 전체 서비스 중단으로 이어지는 것을 막을 수 있습니다.

5. 숫자보다 사용자의 경험을 측정하기

CPU 사용량이 낮다고 해서 음성 품질이 좋은 것은 아닙니다. 서버는 여유로운데 특정 통신사의 네트워크에서만 음성이 끊길 수도 있고, 일부 지역 사용자에게만 지연이 발생할 수도 있습니다.

따라서 인프라 지표와 함께 사용자 경험 지표를 봐야 합니다.

• 음성 연결까지 걸리는 시간
• 통화 중 재연결이 발생한 비율
• 음성 패킷 손실률
• 평균 지연 시간
• 사용자가 통화를 종료한 시점과 장애 발생 시점의 관계

특히 평균값만 보면 문제가 가려질 수 있습니다. 상위 1% 또는 0.1% 사용자가 겪는 최악의 지연 시간도 함께 확인해야 합니다.

6. 한 번에 바꾸지 않고 조금씩 옮기기

기존 음성 시스템을 새로운 구조로 바꾸는 일은 위험합니다. 모든 사용자를 한 번에 새로운 시스템으로 옮기면 작은 문제가 큰 장애로 이어질 수 있습니다.

안전한 전환은 보통 다음과 같은 순서로 진행됩니다.

• 내부 테스트 환경에서 검증하기
• 일부 지역이나 일부 사용자에게만 적용하기
• 기존 시스템과 새 시스템의 지표 비교하기
• 문제가 없을 때 적용 범위 넓히기
• 언제든 이전 시스템으로 돌아갈 수 있게 준비하기

새로운 기술을 도입하는 것보다 중요한 건, 문제가 생겼을 때 빠르게 되돌릴 수 있는 구조입니다.

헤이즐 커뮤니티 운영자가 가져갈 수 있는 것

디스코드의 사례는 거대한 글로벌 서비스에만 해당하는 이야기가 아닙니다. 커뮤니티 규모와 서비스 형태에 맞게 작게 적용할 수 있습니다.

커뮤니티가 아직 작다면

• 기능별로 장애 영향을 분리하기
• 접속자 수와 피크 시간 기록하기
• 음성·채팅·알림 서버의 역할 구분하기

커뮤니티가 성장하고 있다면

• 지역별 서버 배치 검토하기
• 동시 접속자와 연결 실패율 모니터링하기
• 트래픽 급증 시 자동으로 대응할 방법 마련하기
• 특정 서버 장애 시 우회 경로 준비하기

여러 커뮤니티를 운영한다면

• 커뮤니티별 리소스 사용량을 분리해서 보기
• 한 커뮤니티의 이벤트가 다른 커뮤니티에 영향을 주지 않게 하기
• 공통 인프라와 커뮤니티별 설정을 구분하기

결국 핵심은 ‘확장 가능한 경험’입니다

음성 인프라 확장은 서버를 더 많이 구매하는 문제가 아닙니다. 사용자가 늘어나도 안정적으로 대화할 수 있도록 연결 구조, 서버 배치, 장애 대응, 모니터링을 함께 설계하는 일입니다.

디스코드의 사례에서 가장 인상적인 점은 기술 자체보다 문제를 나누는 방식입니다.

• 연결과 미디어 처리를 분리하고
• 사용자와 가까운 곳에서 처리하며
• 순간적인 트래픽을 대비하고
• 장애의 범위를 제한하고
• 사용자 경험을 기준으로 개선하는 것

커뮤니티가 커질수록 운영자는 “기능을 어떻게 추가할까?”뿐 아니라 “사용자가 늘어도 같은 경험을 제공할 수 있을까?”를 고민해야 합니다.

헤이즐도 커뮤니티가 오래, 편하게, 안정적으로 대화할 수 있는 환경을 만들기 위해 이런 문제들을 계속 고민하겠습니다.

---

추천 제목
커뮤니티가 커질수록 음성 채팅은 왜 어려워질까?

메타 설명
디스코드의 음성 인프라 확장 사례를 바탕으로, 커뮤니티 운영자가 알아두면 좋은 음성 서비스의 확장·장애 대응·모니터링 원칙을 쉽게 정리했습니다.

출처
Discord Engineering Blog, “How We Scaled Voice Infrastructure”
https://discord.com/blog/how-we-scaled-voice-infrastructure