웹소켓 연결에서 쿠키가 없어 보였던 이유

상황

웹소켓 연결 테스트를 하던 중 프론트엔드 팀원에게 아래와 같은 메시지를 받았다.

요청 헤더에 쿠키가 없는데 웹소켓 연결이 되고, 채팅 메세지도 잘 보내지네?

무슨 말이지? 웹소켓에 기반한 채팅은 로그인된 사용자만 가능하다. 따라서 로그인 여부를 확인하기 위해 토큰을 통한 인증 과정을 거친다. 이때 토큰은 쿠키에 담겨 요청 헤더에 실린다.

 

그런데, 클라이언트 측에서 웹소켓 연결을 하던 중 쿠키가 없는데 웹소켓 연결이 잘 되고, 메시지도 잘 보내진다고 한다. 

 

프로젝트의 웹소켓 인증 흐름

---

클라이언트가 서버로 웹소켓 연결 요청을 보내면 서버의 HandshakeInterceptor가 요청에 담겨있는 쿠키를 꺼내어 토큰으로 사용자 인증을 진행한다. 토큰이 유효하지 않거나, 만료된 토큰이라면 예외를 반환하고, 토큰이 유효하다면 계속 진행한다.

즉, 토큰이 없다면 예외가 발생해야 정상이다. 그런데 위의 메세지는 헤더에 쿠키가 없는 상태인데, 어떻게 연결이 정상적으로 이루어진 걸까?

 

디버깅에서 본 이상한 현상

---

요청을 보냈을 때의 요청 헤더를 보면 정말로 쿠키가 보이지 않는다.

 

핸드셰이크를 진행하는 단계에서 브레이크 포인트를 찍고 쿠키가 존재하는지 확인해 봤다.

웹소켓 접속 요청을 보냈을 때 request를 보면 cookies = null 을 확인할 수 있다. 그럼 진짜 null인가?

아니다. 쿠키가 null이라면 예외가 발생한다. 조금 더 실행해 보자.

request에서 getCookies()를 실행한 후에 갑자기 null이었던 쿠키가 생겼다. 그리고 필요한 토큰이 들어있는 것을 확인할 수 있다.

분명 처음엔 null이었는데 어떻게 값이 추가된 걸까? 그래서 getCookies()의 내부 구현을 살펴봤다.

 

getCookies()를 호출하자 쿠키가 생긴 이유

---

SecurityUtil.isPackageProtectionEnabled()가 false라고 하는데, 왜 false인지 궁금해서 찾아봤다.

public static boolean isPackageProtectionEnabled() SecurityManager를 반환합니다만, Security가 활성화되어 있고 package protection 메커니즘이 활성화되어 있을 때만 반환합니다.

라고 한다. package protection은 톰캣의 내부 개념으로, 서블릿 코드가 같은 톰캣 내부 패키지에 접근하는 것을 제한하기 위한 목적의 개념이다. 하지만 현대의 서버에서는 대부분 리턴값이 false라고 하는데, Java 17 이후 SecurityManager deprecated 되었다고 한다.

 

내부로 더 들어가 보자.

Tomcat의 getCookies() 내부 구현을 따라가 보면 cookiesConverted라는 플래그가 나온다.

이 값은 요청에 들어온 쿠키가 Servlet API의 Cookie[] 객체로 변환되었는지를 나타낸다. 대략적인 흐름은 아래와 같다.

getCookies()
  -> cookiesConverted 확인
  -> false라면 convertCookies() 실행
  -> 내부 쿠키 표현을 Servlet Cookie 객체로 변환
  -> Cookie[] 반환

 

톰캣은 요청이 들어오는 순간부터 무조건 Cookie[]를 만들어두지 않는다. 필요한 시점, 즉 getCookies()가 호출되는 시점에 변환한다. 그래서 디버깅에서 처음에는 cookies = null로 보였던 것이다. 아직 변환이 실행되지 않았기 때문이다.

getCookies()를 호출하면 그때 내부적으로 convertCookies()가 실행되고, 요청에 포함되어 있던 쿠키들이 Cookie[] 형태로 변환된다.

결론적으로 쿠키가 갑자기 생긴 것이 아니라, 원래 요청에는 쿠키가 있었고, 톰캣이 그 쿠키를 나중에 객체로 변환한 것이다.

cookiesConverted 가 false라면 convertCookies()가 실행된다. 그리고 요청의 모든 쿠키를 반환하여 하나씩 Cookie 객체에 추가한다.

이제 null 이었던 cookies에 토큰이 들어간 것을 확인할 수 있다.

 

톰캣은 Cookie[] 객체 변환을 lazy 하게 수행한다.

---

톰캣은 요청이 들어올 때 모든 값을 즉시 객체로 변환하지 않고, 필요 시점까지 파싱을 미룬다.

 

왜 요청이 들어온 즉시 쿠키를 파싱 하지 않을까?

쿠키를 사용하지 않는 요청도 많다. 그런데 모든 요청마다 무조건 쿠키 문자열을 파싱하고 Cookie 객체를 만들면 불필요한 비용이 생긴다.

이 문제를 방지하기 위해서 톰캣은 늦게 파싱 하는 것 같다.

 

웹소켓 핸드셰이크와 쿠키

---

그럼 근본적으로 웹소켓 요청에 쿠키가 붙는 것이 맞을까? 웹소켓은 처음부터 웹소켓 프로토콜로 시작되지 않는다. 처음에는 일반 HTTP 요청으로 시작한 뒤, HTTP Upgrade 과정을 통해 웹소켓 연결로 전환된다.

GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13
Cookie: accessToken=...
Origin: https://example.com

 

서버가 이 요청을 받으면 101 Switching Protocols 응답을 반환한다. 그 이후부터 웹소켓 연결이 시작된다.

즉, 웹소켓 연결의 시작점은 HTTP 핸드셰이크다. 그래서 이 단계에서는 일반 HTTP 요청처럼 헤더, 쿠키, Origin 등을 다룰 수 있다. 

 

브라우저의 표준 웹소켓 API는 보안상의 이유로 Authorization 같은 임의의 HTTP 헤더를 직접 추가할 수 없다.

그래서 브라우저 기반 웹소켓 인증에서는 보통 다음 방식 중 하나를 사용한다.

• 쿠키 기반 인증
• Query Parameter 토큰 전달
• STOMP CONNECT 프레임에 토큰 전달

이번 프로젝트에서는 HTTP 핸드셰이크 단계에서 쿠키를 통해 인증을 처리하고 있었다.

 

그럼 왜 브라우저의 개발자 도구에는 쿠키가 안 보였던 걸까?

---

처음에는 Chrome 개발자 도구의 웹소켓 요청 헤더에 쿠키가 보이지 않았기 때문에, 브라우저가 쿠키를 보내지 않았다고 생각했다.

하지만 서버에서 `request.getHeader("Cookie")` 와 `request.getCookies()`를 확인해 보니, 실제로는 인증 토큰 쿠키가 요청에 포함되어 있었다. 즉, 쿠키가 없는 것이 아니라, 개발자 도구 상에서 확인되지 않았던 것이다.

정확히 왜 Chrome 개발자 도구에서 요청 쿠키가 보이지 않았는지는 확인하지 못했지만, 브라우저가 쿠키를 보내지 않은 것이 아니라, 개발자 도구에서 보이지 않았던 것에 가까웠다.

 

정리

---

요청 헤더에 쿠키가 보이지 않아 브라우저가 쿠키를 보내지 않았다고 생각했지만, 실제 요청에는 인증 쿠키가 포함되어 있었다. 이 과정을 디버깅하며 톰캣이 쿠키를 즉시 파싱하지 않고, getCookies() 호출 시점에 지연 변환한다는 내부 동작까지 확인할 수 있었다.

 

AI로 이정도 문제의 원인을 찾는 것은 딸깍으로 할 수 있지만, 이렇게 직접 흐름을 추적하며 내부 구현을 확인한 과정 자체가 의미있는 학습이었다고 생각한다.