실시간 채팅에 WebSocket이 꼭 필요할까? Polling으로 다시 만든 라이브 채팅

들어가며

안녕하세요. 프롬 백엔드 개발자 이도연입니다.

프롬의 라이브 방송에는 아티스트와 팬이 실시간으로 대화할 수 있는 라이브 채팅이 있습니다. 원래는 서드파티 채팅 솔루션을 쓰고 있었는데요. 안정적인 SDK와 다양한 기능을 빠르게 사용할 수 있다는 장점이 있었지만, 저희가 실제로 쓰는 기능은 솔루션이 제공하는 전체 중 일부에 불과했습니다.

방송이 끝나면 채팅 기록을 오래 보관할 필요도 없었고, 방송 중에는 최신 흐름을 잘 보여주고 운영 이벤트—채팅 얼리기, 뮤트, 밴 같은 것들—를 빠뜨리지 않는 게 더 중요했습니다.

결국 저희에게 필요한 건 범용 메신저가 아니라, 라이브 방송의 특성에 맞는 일회성 채팅 시스템이었습니다.

처음엔 “실시간 채팅을 직접 만든다”고 하면 자연스럽게 WebSocket을 떠올렸습니다. SSE도 서버에서 클라이언트로 Push할 수 있으면서 HTTP 기반이라 유력한 후보였고요. 그런데 요구사항을 다시 들여다보니 굳이 연결을 유지해야 할 이유가 없었습니다. 1~2초 정도의 지연은 허용할 수 있었고, 클라이언트가 주기적으로 상태를 가져오는 방식으로도 충분히 사용자 경험을 유지할 수 있었거든요.

이 글에서는 외부 채팅 솔루션을 자체 Polling 서비스로 재구축하면서 어떤 기준으로 기술을 선택했는지, 메시지 우선순위와 조회 정책을 어떻게 설계했는지, 그리고 부하 테스트 중에 발견한 cursor 지연 문제를 어떻게 해결했는지 공유해보겠습니다.

요구사항부터 다시 정의하기

자체 구축을 검토하면서 가장 먼저 한 건 “기존 외부 솔루션을 그대로 복제하자”가 아니라, 라이브 채팅에 정말 필요한 게 뭔지 다시 정리하는 거였습니다.

구분	요구사항
동시 접속	하나의 라이브 채팅방에 수천~1만 명이 참여할 수 있어야 함
체감 실시간성	1~2초 정도의 메시지 수신 지연 허용
아티스트 메시지	모든 참여자에게 전달되어야 함
팬 메시지	트래픽이 몰려도 최신 채팅 흐름을 안정적으로 유지해야 함
운영 이벤트	삭제, 얼리기, 뮤트, 밴은 모든 참여자에게 전달되어야 함
저장	방송 종료 후 영구 보관할 필요 없음
조회	응답 크기와 지연 시간을 예측 가능한 범위로 유지해야 함

정리하고 나니 한 가지 사실이 눈에 들어왔습니다.

모든 메시지가 같은 중요도를 갖지 않는다는 것이었습니다.

아티스트 메시지는 팬 모두가 꼭 봐야 하지만, 팬 메시지는 짧은 시간에 급격히 늘어날 수 있습니다. 화면과 API가 최신 흐름을 잘 보여주려면 처리량을 어느 정도 제어해야 했고요.

그렇다면 서버도 모든 메시지를 똑같이 다룰 필요가 없었습니다. 강한 전달 보장이 필요한 데이터와 트래픽 변동이 큰 데이터를 나누면 시스템이 훨씬 단순해질 수 있었습니다.

WebSocket, SSE, Polling 비교하기

WebSocket은 양방향 통신과 낮은 지연이 중요한 채팅 서비스에 잘 맞습니다. 다만 연결을 계속 유지해야 하다 보니 재연결, 서버 확장, 세션 분산 같은 운영 복잡도가 따라옵니다. 저희는 메시지 전송 자체는 HTTP API로 처리할 수 있었고, 수신만을 위해 양방향 연결을 유지하는 건 좀 과했습니다.

그래서 WebSocket만 검토하진 않았습니다. SSE와 Polling도 함께 살펴보면서 실제 PoC와 부하 테스트까지 진행했습니다.

방식	장점	고려할 점
WebSocket	양방향 통신, 낮은 지연	연결 분산, 재연결, 세션 관리가 필요함
SSE	HTTP 기반의 단방향 Push, 뛰어난 실시간성	장기 연결을 유지할 서버와 재연결 후 상태 복구가 필요함
Polling	Stateless REST API, 장애 복구와 확장이 단순함	빈 요청이 발생하며 Polling 주기만큼 지연됨

SSE PoC는 ECS가 Redis Pub/Sub를 구독하고 연결된 클라이언트에 이벤트를 Push하는 구조였습니다. 앱이 백그라운드에 다녀오거나 네트워크가 끊겼을 때를 위해 Redis Stream과 복구 API도 함께 설계했습니다.

낮은 부하에서 SSE는 수 ms 수준으로 메시지를 전달해 실시간성만 따지면 가장 좋았습니다. 하지만 5,000명 이상의 고부하 시나리오에서는 지연이 급격히 늘었고 재연결도 발생하기 시작했습니다. 연결 수에 맞춰 ECS 용량을 계획해야 했고, 배포할 때마다 연결 재설정과 상태 복구도 신경 써야 했습니다.

Polling은 메시지가 없어도 요청이 발생하고 1~2초의 지연이 있었지만, 부하가 늘어나도 지연을 예측하기 어렵지 않았습니다. 요청이 Stateless하니까 네트워크가 잠깐 끊겨도 다음 Polling에서 자연스럽게 복구되고, 서버 재시작이 클라이언트 연결에 영향을 주지 않았습니다.

비용도 Polling이 유리했습니다. SSE는 라이브가 없는 시간에도 ECS 인스턴스를 유지해야 하지만, Polling은 Lambda 기반이라 실제 요청이 없으면 컴퓨팅 비용이 거의 없습니다. 실제 라이브 횟수와 평균 시청 인원을 기준으로 추산해봤을 때도 Polling이 가장 저렴했습니다.

결국 선택 기준은 “가장 빠른 방식”이 아니었습니다. 서비스가 허용하는 지연 안에서 운영 복잡도와 비용이 가장 낮은 방식을 골랐고, 다음 조건들이 Polling과 잘 맞아떨어졌습니다.

• 1~2초의 지연을 허용할 수 있다.
• 응답 데이터를 작게 유지할 수 있다.
• 메시지를 영구 저장하지 않아도 된다.
• 응답 크기와 조회 범위를 일정하게 제한할 수 있다.
• 서버리스 인프라를 이용해 요청량에 따라 확장할 수 있다.

메시지 조회와 방 상태 조회의 주기도 따로 나눴습니다.

Polling 대상	주기	이유
호스트의 메시지 조회	1초	방송 진행자가 팬 반응을 빠르게 확인해야 함
시청자의 메시지 조회	2초	체감 실시간성을 유지하면서 요청 수를 줄임
방 상태	5초	좋아요, 얼리기, 뮤트, 밴은 메시지보다 낮은 조회 빈도로 충분함

모든 데이터를 1초마다 요청하는 대신, 변화 빈도와 중요도에 따라 주기를 나눠 불필요한 부하를 줄였습니다.

전체 아키텍처

라이브 채팅 Polling 서비스의 메시지 전송 및 조회 구조

전체 시스템은 API Gateway, Lambda, SQS, Redis를 중심으로 구성했습니다.

일반 팬 메시지는 API Gateway에서 바로 SQS로 전달합니다. 이 경로에는 Lambda를 따로 두지 않았는데요. API Gateway의 AWS 서비스 직접 통합을 사용해 JWT Authorizer를 통과한 요청 본문을 SQS-SendMessage로 전달하고, 이후 Lambda Consumer가 메시지를 검증해 Redis에 저장하는 방식입니다.

일반 메시지는 팬 수에 비례해 가장 많은 요청이 발생하는 경로입니다. API Gateway -> Lambda -> SQS로 구성하면 Lambda는 큐에 넣는 짧은 작업만 반복하게 됩니다. 이를 API Gateway -> SQS로 줄이면 Lambda 호출과 동시성 사용을 없앨 수 있고, 비용과 장애 지점도 함께 줄어듭니다. 요청이 몰리는 순간에는 SQS가 버퍼 역할을 해서 Consumer가 감당할 수 있는 속도로 처리하게 됩니다.

반면 아티스트와 운영자 메시지는 별도의 Lambda를 통해 Redis에 바로 저장합니다. 일반 메시지 큐 트래픽 때문에 중요한 메시지가 늦어지는 걸 막기 위해 경로를 분리한 겁니다.

일반 메시지: Client -> API Gateway -> SQS -> Lambda -> Redis
중요 메시지: Client -> API Gateway -> Lambda -> Redis
메시지 수신: Client -> API Gateway -> Lambda -> Redis

좋아요도 모든 클릭을 즉시 동기화할 필요는 없어서, 클라이언트에서 일정 시간 동안 증가량을 모아 전송하고 SQS와 Lambda를 통해 Redis 카운터에 반영하도록 했습니다.

Redis Sorted Set과 Cursor

라이브 채팅 데이터는 방송 중에만 필요합니다. RDB에 영구 저장하고 조회하는 것보다 Redis에 짧게 보관하는 편이 요구사항에 훨씬 잘 맞았습니다.

메시지는 Redis Sorted Set에 저장했습니다. score에는 서버가 메시지를 저장한 시각을, member에는 메시지 데이터를 JSON으로 저장합니다.

Key: live_chat:{roomId}:messages:{priority}
Score: createdAt
Member: { messageId, content, userId, nickname, createdAt }
TTL: 24시간

클라이언트는 마지막으로 확인한 cursor를 다음 요청에 포함합니다.

GET /live-chat/{roomId}/messages?cursor=1710000000000

서버는 cursor 이후에 저장된 메시지를 조회하고, 응답에 다음 cursor를 함께 내려줍니다. 클라이언트는 응답이 성공한 경우에만 cursor를 갱신합니다. 일시적인 네트워크 오류가 생기면 기존 cursor를 유지한 채 다음 Polling에서 다시 요청하니까 별도의 연결 복구 프로토콜이 필요하지 않습니다.

우선순위에 따라 조회 정책은 달리 가져갔습니다.

우선순위 높은 메시지

아티스트와 운영자의 메시지는 cursor 이후 데이터를 모두 조회합니다.

ZRANGEBYSCORE live_chat:{roomId}:messages:high cursor+1 +inf

중요 메시지는 수가 많지 않고 전달이 보장되어야 해서 누락 없이 반환합니다.

일반 메시지

일반 메시지는 트래픽 변동이 크기 때문에 조회 범위에 상한을 두고 최신 구간을 기준으로 응답을 구성했습니다.

조회 기준: cursor 이후 데이터
정렬 기준: 최신 구간 우선
응답 기준: 고정된 pageSize 안에서 구성

조회 결과는 시간순으로 다시 정렬한 뒤 우선순위 높은 메시지와 합쳐 반환합니다. 트래픽이 급증해도 응답 크기와 Lambda 처리량이 예측 가능한 범위 안에 머물도록 했습니다.

메시지 삭제 이벤트도 별도의 Sorted Set에 deletedAt을 score로 저장했습니다. 메시지와 삭제 이벤트를 함께 조회한 후 가장 최신 시각을 다음 cursor로 사용하여, 삭제 이벤트만 발생한 Polling에서도 cursor가 정상적으로 전진하도록 했습니다.

30초 전 메시지가 도착한 이유

부하 테스트 중에 가상 클라이언트를 500명에서 1,000명으로 늘리자 이상한 현상이 나타났습니다. Polling API 응답 시간은 정상인데, 클라이언트가 자신이 보낸 메시지를 다시 수신하기까지의 Round Trip이 점점 길어지더니 30초를 넘어갔습니다.

처음엔 메트릭 설정을 의심했습니다. 그런데 측정 구간을 늘려보니 테스트가 진행될수록 지연이 선형적으로 증가하고 있었습니다. API가 느린 게 아니라 클라이언트의 cursor가 현재 시각을 따라잡지 못하고 있던 겁니다.

당시 일반 메시지는 cursor 직후 구간부터 순서대로 따라가는 방식이었습니다.

기존: cursor 직후 구간부터 순차 조회

트래픽이 순간적으로 조회 한도를 넘으면 클라이언트는 이미 오래된 구간을 계속 따라가게 됩니다. 새 메시지가 쌓이는 속도를 처리 속도가 따라가지 못하니, cursor는 영원히 현재 시점을 따라잡을 수 없게 됩니다.

처음 시도한 건 cursor 이후 범위를 넓게 조회한 뒤 다음 cursor를 최신 시점으로 바로 이동하는 방법이었습니다. 지연은 줄었지만, 트래픽이 커지면 Redis에서 읽어오는 데이터와 Lambda 메모리가 늘어날 수 있었습니다.

최종적으로는 조회 방향을 뒤집었습니다.

변경: 최신 구간 기준 조회

최신 구간을 기준으로 조회하면 데이터 양을 제한하면서도 cursor를 현재 시점으로 빠르게 이동시킬 수 있습니다. 수정 후 동일한 조건에서 Round Trip이 5초 이내로 줄었고, 3,000명·5,000명 조건에서도 같은 범위 안에서 동작하는 걸 확인했습니다.

이 문제를 겪으면서 cursor는 단순히 “마지막으로 반환한 데이터의 위치”가 아니라, 시스템이 어디까지 처리했다고 간주할 것인지에 대한 정책이라는 걸 알게 됐습니다. 트래픽이 큰 실시간 화면에서는 오래된 구간을 순서대로 따라가는 것보다, 최신 상태를 안정적으로 유지하는 cursor 정책이 더 중요할 수 있습니다.

앱에서는 기존 구조를 최대한 유지하기

서버를 교체하는 동안 앱의 라이브 화면 전체를 뒤엎고 싶지 않았습니다. 기존 앱에는 채팅 데이터소스 인터페이스 뒤에 외부 솔루션 구현체가 연결되어 있었기 때문에, 같은 인터페이스를 따르는 Polling 구현체를 추가했습니다.

if chatProvider == .fromm {
    liveChatDataSource = PollingLiveChatDataSource(apiService: liveChatAPIService)
} else {
    liveChatDataSource = ExternalLiveChatDataSource()
}

메시지 수신은 SDK의 이벤트 스트림 대신 Polling 결과를 기존 스트림 형태로 변환해 전달했습니다. UI와 비즈니스 로직은 데이터가 어디서 왔는지 알 필요가 없게 됐습니다.

점진적 전환을 위해 App Config에 전체 적용 여부와 대상 아티스트 목록도 뒀습니다.

{
  "apply_all": false,
  "apply_target_list": ["artist-id"]
}

처음엔 내부 테스트 대상에만 Polling을 적용하고, 이후 일부 라이브를 거쳐 전체로 확대했습니다. 문제가 생기면 앱 업데이트 없이 기존 외부 솔루션으로 되돌릴 수 있다는 점도 마이그레이션 과정에서 큰 안전망이 됐습니다.

백그라운드에서는 불필요한 Polling을 중단하고, 포그라운드로 돌아오면 다시 시작하도록 라이프사이클과도 연결했습니다. 재개할 때 기존 cursor를 사용해 중단된 동안의 중요 메시지와 이벤트를 복구하도록 했습니다.

마치며

실시간 기능이라고 해서 꼭 WebSocket이나 SSE가 정답은 아니었습니다.

어떤 프로토콜이 더 실시간처럼 보이느냐보다, 서비스가 실제로 요구하는 지연 시간과 전달 보장 수준을 먼저 정의하는 게 중요했습니다. 저희 라이브 채팅에서는 아티스트 메시지와 운영 이벤트를 우선 보호하고, 영구 저장 대신 짧은 TTL을 쓰고, 연결 관리 대신 예측 가능한 HTTP 요청을 선택할 수 있었습니다.

물론 완전한 메시지 순서 보장이나 아주 낮은 지연, 양방향 통신이 핵심이라면 WebSocket이 더 적합합니다. 서버에서 클라이언트로 빠르게 Push하는 게 중요하다면 SSE도 충분히 좋은 선택이고요. 하지만 요구사항이 허용한다면 Polling은 충분히 단순하고 확장 가능하며 비용 효율적인 선택지가 될 수 있습니다.

이번 작업에서 가장 크게 배운 건, 기술을 교체할 때 기존 솔루션을 그대로 따라 만드는 것보다 우리 서비스가 실제로 보장해야 하는 것이 무엇인지 다시 묻는 과정이 먼저라는 점입니다.

읽어주셔서 감사합니다!