실시간 채팅 Q&A — 선택지 7개, 실패 모드 10가지, 25문답

앞 네 편은 각각 하나의 질문에 답했다. 이 글은 그 답들을 한자리에 모아 고를 때 쓰는 표 · 터졌을 때 쓰는 표 · 설명해야 할 때 쓰는 문답 세 벌로 다시 짠다.

쓰임새가 갈린다. 아직 아무것도 정하지 않았다면 첫 표부터 보면 되고, 이미 돌아가는 채팅에서 메시지가 안 온다거나 연결이 자꾸 끊긴다면 두 번째 표의 증상 열에서 출발하는 편이 빠르다. 문답은 남에게 근거를 대야 할 때 쓴다.

선택지 7개 — 무엇을 얻고 무엇을 내주는가

표를 위에서 아래로 읽으면 제어를 내주고 표준을 얻는 순서로 배열돼 있다. 맨 위는 전부 직접 만들고 전부 통제하며, 아래로 갈수록 규약과 인프라에 맡기는 대신 그 규약이 정한 방식을 따르게 된다. 맨 아래 줄만 성격이 다르다 — SSE는 이 사다리의 어느 단계도 아니고, 애초에 사다리를 오르지 않는 선택이다.

실패 모드 10가지 — 증상에서 대응으로

첫 행이 가장 위험하다. 나머지 아홉은 예외나 지표로 드러나지만, 이것만은 시스템이 정상이라고 보고한다. 보낸 쪽에서는 성공했고 로그도 깨끗하며, 같은 서버에 붙은 사용자들에게는 실제로 도착한다. 사용자 신고로만 발견되는 유형이다.

증상에서 출발하면 순서가 있다

위 표는 원인별로 묶여 있지만 실무에서는 증상이 먼저 온다. "메시지가 안 온다"는 신고 하나에 위 표의 여러 행이 후보로 걸리므로, 갈라내는 순서를 정해 두는 편이 빠르다.

첫 분기가 가장 많은 것을 가른다. 전원이 못 받으면 전파 경로가 아니라 연결이나 구독의 문제이고, 일부만 못 받으면 그 일부가 어느 서버에 붙어 있는지부터 본다. 서버별로 갈리면 브로커, 사용자별로 갈리면 인가다.

전송과 프로토콜 5문답

1번부터 3번까지가 하나의 판단으로 이어진다. HTTP와의 차이를 아는 것은 무엇을 얻는가이고, 다섯 방식을 가르는 것은 무엇을 치르는가다. 3번의 답이 "양방향이 아니면 쓰지 않는다"로 끝나는 이유는, 얻는 것이 지연 감소인데 치르는 것은 인프라 전반의 제약이기 때문이다.

규약과 라우팅 3문답

7번은 인가 우회로 이어진다. /topic으로 직접 보낼 수 있으면 방 참여 여부 검사가 통째로 건너뛰어진다. 접두사 분리는 코드 정리가 아니라 보안 경계라는 것이 2편의 결론이었다.

인증 5문답

9번과 11번은 짝으로 읽어야 한다. 앞의 검사는 문을 잠그고 뒤의 검사는 안에 들어온 사람을 계속 확인하는데, 어느 하나만 두면 나머지 하나가 막던 것이 그대로 열린다. 10번에서 쿠키를 고른 경우에는 조건이 하나 더 붙는다 — WebSocket 핸드셰이크에 동일 출처 정책이 걸리지 않으므로 Origin을 직접 확인해야 한다.

도메인 2문답

15번의 전제가 3편에서 다룬 중간 엔티티다. 중간 테이블 생성을 JPA에 맡겨 버리면 읽음 지점을 적어 둘 컬럼을 붙일 곳이 사라지고, 그러면 이 기능 자체가 서지 않는다.

확장 5문답

19번이 이 시리즈에서 가장 자주 오해되는 지점이다. 세션을 꺼냈다고 서버가 완전히 가벼워진 것은 아니다 — 소켓은 그대로 남는다.

데이터베이스 5문답

22번과 24번의 일반적인 형태는 파티셔닝 전략과 샤딩과 관계형 데이터베이스와 NoSQL에 있다. 여기서 달라지는 것은 23번이다 — 접근 패턴이 방 단위로 고정돼 있다는 성질이 샤드 키를 거의 자동으로 정해 준다. 대부분의 서비스에서 샤드 키 선정이 어려운 이유가 접근 패턴이 여럿이기 때문인데, 채팅에는 그 문제가 없다.

Q. 3대로 늘렸더니 같은 방인데 어떤 사용자에게만 메시지가 간다. 에러 로그도 없다

원인은 Spring 내장 SimpleBroker가 자기 프로세스 메모리 안의 구독자만 알고 있기 때문이다.

WebSocket 연결은 TCP 소켓이라 특정 서버 프로세스에 물리적으로 묶여 있다. 사용자 A가 1번 서버에, 사용자 B가 3번 서버에 붙어 있으면 1번 서버의 브로커는 B의 구독을 아예 모른다. 그래서 "전달 실패"가 아니라 애초에 전달 대상으로 인식되지 않아 에러가 남지 않는다. 로그로는 잡히지 않고 사용자 신고로만 드러나는 유형이다.

해결은 서버 간 메시지 전파 경로를 만드는 것이다. Spring이라면 enableSimpleBroker()를 enableStompBrokerRelay()로 바꿔 외부 STOMP 브로커에 중계하면 된다. 모든 서버가 같은 브로커를 구독하므로 어느 서버로 들어온 메시지든 옳은 서버로 배달된다. 규모가 작다면 Redis Pub/Sub으로도 된다. 다만 Redis Pub/Sub은 전달 보장이 없어 구독자가 순간적으로 없으면 메시지가 사라진다는 점을 감수해야 한다.

여기서 함께 짚어야 할 것은, 브로커를 넣어도 연결의 서버 종속성 자체는 사라지지 않는다는 점이다. 브로커는 배달 문제만 푼다. 서버가 죽으면 그 서버에 붙어 있던 연결은 전부 끊기므로, 클라이언트 측 자동 재연결과 재연결 시 미수신 메시지 복구가 짝으로 필요하다. 복구는 마지막 수신 메시지 id를 기준으로 다시 조회하는 방식이 단순하고 확실하다.

Q. 세션을 Redis로 외부화하면 무상태 서버가 된다는데, 실제로는 무엇을 겪게 되나

세 가지가 순서대로 온다.

첫째는 직렬화 계약이다. 세션을 프로세스 밖에 두기로 한 순간, 거기 담아 둔 것들은 전부 바이트로 바뀌었다 돌아올 수 있어야 한다. 인증 주체는 물론 그것이 참조하는 회원 엔티티까지 Serializable이어야 하고, JPA 엔티티라면 지연 로딩 프록시가 함께 직렬화되려다 터지기도 한다. 그래서 세션에는 식별자와 권한만 넣고 나머지는 필요할 때 조회하는 쪽이 안전하다.

둘째는 버전 호환성이다. 세션 객체에 필드를 하나 추가하고 롤링 배포하면 구버전 인스턴스가 신버전이 쓴 세션을 역직렬화하지 못한다. 증상은 "가끔 로그아웃된다"로 나타나 원인 추적이 오래 걸린다. Java 기본 직렬화 대신 JSON으로 고정하면 이 문제가 크게 완화된다.

셋째는 Redis가 새로운 단일 장애점이 된다는 점이다. 모든 요청이 세션을 읽으므로 Redis가 멈추면 전 서비스가 인증 불가 상태가 된다. 센티넬이나 클러스터 구성, 그리고 Redis 장애 시의 성능 저하 시나리오를 미리 정해 둬야 한다.

가장 중요한 오해 하나를 덧붙이면, 세션 외부화는 HTTP 요청의 무상태화를 해결할 뿐 WebSocket 연결 문제는 손대지 못한다. 연결은 여전히 특정 서버에 묶여 있다.

Q. @Transactional(readOnly = true)만 붙였는데 모든 쿼리가 원본으로 간다

AbstractRoutingDataSource의 determineCurrentLookupKey()가 호출되는 시점이 문제다.

Spring의 트랜잭션 매니저는 트랜잭션을 시작할 때 커넥션을 먼저 획득한다. 그런데 읽기 전용 플래그가 TransactionSynchronizationManager에 세팅되는 것은 그 직후다. 즉 라우팅 키를 평가하는 순간에는 아직 플래그가 거짓이라 항상 기본값인 원본이 선택된다.

해결책이 LazyConnectionDataSourceProxy다. 이 프록시로 라우팅 데이터소스를 감싸면 커넥션 획득이 실제로 첫 쿼리가 나가는 시점까지 지연된다. 그때는 플래그가 이미 세팅돼 있으므로 복제본으로 정상 라우팅된다.

프록시를 붙였다고 끝나지 않는다. 이 구조는 애너테이션 하나를 빠뜨리면 조용히 무너지는데, 빠뜨린 쪽이 느려지는 것이 아니라 원본이 조금씩 더 바빠질 뿐이라 눈에 띄지 않는다. 그래서 검토 항목으로 명시해 두는 편이 낫다. 남은 하나는 지연이다 — 보낸 직후 목록을 다시 그리는 화면이라면 복제본이 아직 그 행을 못 받았을 수 있어, 그 조회만 예외로 원본에 보낸다.

Q. 실시간 알림 기능을 만들어 달라는 요구가 왔다. WebSocket으로 할 것인가

요구가 정말 알림 단방향이라면 SSE를 먼저 검토하는 편이 낫다.

이유는 비용 구조에 있다. WebSocket은 프로토콜이 HTTP를 떠나는 순간부터 기존 인프라와 어긋나기 시작한다. 로드밸런서의 Upgrade 통과 설정, idle timeout과 하트비트 조율, 인증 필터 체인 재구성, 배포 시 연결 유실과 재연결 폭주 — 이 비용이 전부 따라온다.

SSE는 그냥 HTTP다. 기존 인증·프록시·모니터링을 그대로 쓴다. 재연결과 마지막 이벤트 ID 기반 복구가 프로토콜에 들어 있어 클라이언트 코드도 적다.

WebSocket을 선택하는 기준은 클라이언트도 빈번하게 서버에 말을 거는가다. 채팅, 협업 편집, 게임처럼 양방향 저지연이 본질인 경우다. 알림은 대부분 그렇지 않다.

다만 이미 채팅용 WebSocket 인프라가 서 있는 조직이라면 판단이 달라진다. 그때는 알림을 별도 SSE로 두는 것보다 기존 연결에 얹는 편이 운영 대상을 하나로 줄여 유리할 수 있다. 판단의 기준은 프로토콜의 우열이 아니라 이미 무엇을 운영하고 있는가다.

정리

이 시리즈가 내린 판단을 네 줄로 줄이면 이렇다.

• 듣기만 하면 되는 기능에 양방향 채널을 열지 않는다. 열어 둔 연결의 값은 한 번 치르고 끝나지 않는다. 위 실패 모드 표의 절반이 그 청구서다.
• /app과 /topic의 구분은 보안 경계다. 브로커가 직접 받는 접두사는 서버 로직을 거치지 않아도 되는 목적지라는 선언이다.
• 인증은 두 지점에 걸어야 한다. 핸드셰이크는 연결을 막을 수 있지만 한 번뿐이고, 채널 인터셉터는 매번 검사하지만 연결은 이미 열린 뒤다.
• 연결은 외부화할 수 없다. 세션도 브로커도 밖으로 꺼낼 수 있지만 TCP 연결만은 그럴 수 없고, 그래서 클라이언트 재연결이 설계의 일부가 된다.