웹소켓을 붙일 때 HTTP 감각을 그대로 가져가면 자꾸 꼬이는 이유

2026년 4월 1일 | 개발 공부

---

웹소켓을 처음 붙일 때 제일 자주 하는 착각은, 이걸 그냥 오래 살아 있는 HTTP 요청 정도로 보는 것이다. 나도 예전에는 그렇게 생각한 적이 있었다. 어차피 연결을 열고 데이터를 주고받는 거니까, 익숙한 요청-응답 감각을 조금만 늘리면 된다고 본 것이다. 그런데 실제로는 그 작은 차이가 생각보다 크다. HTTP에서는 요청 하나가 끝나면 맥락도 같이 정리되지만, 웹소켓에서는 연결 자체가 상태가 되고, 그 상태를 어떻게 다룰지가 설계의 중심으로 올라온다.

이 차이를 이해하지 못하면 초반에는 잘 붙는 것처럼 보여도 금방 꼬인다. 채팅이든 실시간 대시보드든 알림 시스템이든, 웹소켓은 결국 "누가 지금 연결돼 있는가", "이 연결은 어떤 권한과 문맥을 갖는가", "끊겼다가 다시 붙으면 무엇을 복구해야 하는가" 같은 질문을 같이 데려온다. 즉, 단순한 전송 채널이 아니라 세션을 오래 들고 가는 통신 모델로 봐야 한다.

1. HTTP에서는 요청이 끝나면 많은 문제가 같이 사라진다

HTTP의 좋은 점은 경계가 분명하다는 데 있다. 클라이언트가 요청을 보내고, 서버가 응답을 돌려주면 한 사이클이 끝난다. 인증이나 캐시, 멱등성 같은 고민이 물론 있지만, 그래도 기본 구조는 비교적 깔끔하다. 실패해도 다시 같은 요청을 보내면 되고, 서버는 각 요청을 독립적으로 처리하기 쉽다.

• 요청과 응답의 시작점과 끝점이 명확하다.
• 에러가 나도 개별 요청 단위로 재시도하기 쉽다.
• 서버 입장에서는 무상태 설계에 가깝게 가져가기 편하다.

그래서 HTTP에 익숙해지면 대부분의 문제를 "요청 하나 더 보내면 되지"라는 식으로 풀게 된다. 그런데 웹소켓은 그 감각이 자주 통하지 않는다. 한 번 연결이 열린 뒤에는 매 메시지가 독립적인 요청이 아니라, 이미 열린 세션 위를 흐르는 이벤트가 되기 때문이다.

2. 웹소켓에서는 연결 관리가 곧 기능 설계가 된다

웹소켓을 붙이면 처음에는 메시지 포맷에만 눈이 간다. JSON 필드 이름을 어떻게 할지, 이벤트 타입을 몇 개 둘지 같은 문제 말이다. 그런데 조금만 운영해 보면 더 중요한 건 포맷보다 연결 수명주기라는 걸 금방 느끼게 된다. 사용자가 탭을 새로고침했을 때, 모바일 네트워크가 순간적으로 끊겼을 때, 서버를 재배포했을 때 연결이 어떤 상태로 복구되는지가 서비스 품질을 더 크게 좌우한다.

특히 실시간 시스템은 "연결은 됐는데 상태는 어긋나 있는" 순간이 가장 피곤하다. 클라이언트는 방에 들어가 있다고 생각하는데 서버는 이미 세션을 잊었거나, 서버는 구독이 남아 있다고 생각하는데 클라이언트는 화면을 닫아버린 경우가 생긴다. 이런 엇갈림은 단순한 HTTP 호출보다 디버깅이 더 어렵다. 눈에 보이는 건 메시지 누락인데, 원인은 세션 경계 설계에 있는 경우가 많기 때문이다.

3. 결국 핵심은 메시지보다 상태 동기화다

웹소켓을 안정적으로 쓰려면 "무슨 데이터를 보낼까"보다 "서로 같은 상태를 보고 있다는 걸 어떻게 확인할까"를 먼저 생각해야 한다. 예를 들어 접속 직후 현재 방 목록이나 마지막 이벤트 시퀀스를 먼저 동기화하고, 이후에는 증분 업데이트만 받는 식의 구조가 훨씬 덜 흔들린다. 이걸 빼먹으면 연결은 살아 있는데 화면만 이상한 상태가 오래 남는다.

• 재연결 시 초기 상태를 다시 내려줄 기준이 있어야 한다.
• 이벤트 순서를 보장할 최소한의 번호 체계가 있으면 디버깅이 쉬워진다.
• 연결이 살아 있다는 사실과 상태가 맞다는 사실은 다르다는 걸 구분해야 한다.

나는 그래서 웹소켓을 볼 때 이제 전송 방식보다 세션 모델을 먼저 본다. 연결, 인증, 구독, 재연결, 상태 복구를 어떻게 설명하는지까지 이해돼야 그 위에 올라가는 기능도 덜 흔들린다. HTTP 감각이 나쁜 건 아니지만, 그 감각을 그대로 늘리면 실시간 시스템의 핵심을 자꾸 놓치게 된다.

4. 아주 짧게 정리하면

HTTP는 개별 요청 단위 사고가 잘 맞고, 웹소켓은 연결 수명과 상태 동기화 사고가 더 중요하다. 이 차이를 초기에 받아들이면 구현이 훨씬 덜 꼬인다. 반대로 그 차이를 무시하면 코드보다 운영 단계에서 더 크게 흔들린다. 결국 웹소켓은 단순한 전송 채널이 아니라, 오래 살아 있는 상호작용을 어떻게 관리할지 묻는 설계 문제에 가깝다.