[네트워크] 쿠키, 세션, 토큰 면접질문

최근 CS 기술 면접 대비에 시간을 많이 쓰고 있다.
여러 자료 + 이전 강의에서 본 내용을 보면서 GPT와 모의면접을 하고 있는데, 생각보다 시간이 엄청 쓰인다.

이렇게 시간을 많이 쓰는데 면접이 끝나고, 붙으면 좋겠지만 혹여 떨어지면 지금 준비하는 이 시간이 아무것도 안한 시간이 될까봐. 
그리고 분명히 작년 11월 즈음 면접 준비를 하긴 했는데, 기억에서 날라가버렸다..
뭐라도 남겨보자는 심정과 노션에 흩어진 글을 조금이라도 정제해보자는 마음으로 이 포스팅을 시작하였다.

주로 GPT + VSFe 님의 기술면접 질문 모음집을 참고하였다.
질문과 답변 모두 신입 개발자의 입장에서 쓰여진 것이니 오류나 말이 안 맞는 것이 있을 수 있다. 혹은 더 좋은 답변이 있을 수 있다.
이를 발견하여 제게 알려주신다면 커피..라도 한잔 사드리고 싶을 것 같다. 🙇🏻‍♂️

 

쿠키와 세션의 차이에 대해 설명해주세요.

차이점은 상태 정보의 저장 위치입니다. 세션도 결국 쿠키를 쓰지만, 사용자의 상태 정보 저장의 위치가 다릅니다.

쿠키는 클라이언트, 세션은 서버에 저장합니다.

그래서 쿠키는 세션보다 서버의 자원을 덜 사용합니다.(저장 관점에선 전혀 사용 안함. 연산은 하니까 덜)

 

쿠키와 세션은 클라이언트와 서버 간의 사용자의 상태를 관리하기 위한 방법입니다.

HTTP는 상태를 저장하지 않는 프로토콜이기 때문에, 클라이언트가 누구인지 매번 확인하는 것을 보완하고자 합니다.

 

세션 방식의 로그인 과정에 대해 설명해 주세요.

클라이언트가 로그인 → 서버가 해당 사용자에 대한 정보를 세션에 저장 → 세션 식별자를 통해 상태를 유지합니다.

전달받은 로그인 정보로 인증이 되면, 서버는 새로운 세션을 생성합니다.

서버는 세션 ID로 클라이언트에 set cookie 합니다. (쿠키 기반일때)

로그아웃하면 서버는 세션을 삭제합니다.

→ 여기서, 브라우저에서 쿠키만 삭제한다고 인증 상태가 삭제되지 않습니다. 서버 세션도 제거해야합니다.

 

왜 Stateless가 필요한가요?

음.. 먼저 서버 입장에서는 클라이언트 상태를 유지할 필요가 없어서 리소스를 줄이고 확장성이 뛰어납니다.

클라이언트도 단순히 요청, 응답만 하며 복잡한 연결 유지 없이 빠르게 리소스를 주고 받을 수 있습니다.

여기서 확장성이란, 상태를 저장하지 않아서 여러 서버에 쉽게 분산 처리가 가능하다고 알고 있습니다.
요청만 보기 때문에 설계와 유지 보수가 더 쉽겠죠.

 

또 RESTful에서의 6가지 제약 중 Stateless가 있스빈다.

이는 모든 요청이 독립적으로 처리되며, GET, PUT 요청은 그 자체로 완결된 정보를 포함해야합니다.

즉, 분산처리가 가능하고, 예측 가능한 방식으로 통신하며, 독립적으로 처리하여 실패해도 복원이 가능해야합니다.

 

하지만 지속적인 상호작용을 구현하기 위해 상태정보가 필요합니다.

 

HTTP의 특성인 Stateless에 대해 설명해 주세요.

각 요청이 서로 독립적으로 처리되며, 서버는 이전 요청에 대한 정보를 기억하지 않는 다는 의미입니다.

예를 들어, 로그인한 사용자를 서버는 기억하지 않고, 사용자가 서비스를 이용할 때마다 인증 정보를 매번 함께 보내야합니다.

 

그럼 토큰 방식은 무엇인가요?

세션보다 사용자의 인증 상태를 별도로 저장하거나 관리 안해도 됩니다. 따라서 확잠함에 따라 별도로 세션을 똑같이 공유하거나 하는 등의 추가적인 코스트가 없기 때문에 더 좋을 수 있습니다.

 

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

적절하지 않다기 보단 Stateless인 HTTP의 구조를 바꾸지 않고 애플리케이션 레벨에서 상태 유지를 위한 보충 기술이라고 할 수 있을 것 같습니다.

실무에선 보안이 중요하거나, 무효화가 편한 등 장점으로 사용합니다.

 

JWT는 정말 Stateless한가요? 

서비스를 하는 서버는 공개키 하나 정도 저장을 하고, 인증을 하고 인증 로직을 서비스 서버에서 분리시키는 것에서 의미가 있을 것 같습니다. (RSA기반으로 인증서버는 개인키로 header와 payload, 이둘을 서명한 signature를 주고, 서비스 서버는 공개키로 검증만 한다)

하지만 블랙리스트 등의 기능을 넣으면 Redis를 경유하며 상태가 생기는 느낌이 있습니다.

이는 보안과의 트레이드 오프인 것 같습니다. 상태를 어느정도 가지고 보안을 더 챙기거나 아니거나..

 

서버에서 인증을 할 때, 서버가 여러대면 복잡해진다.

쿠키에 간단한 정보를 저장하고 이를 바탕으로 RT를 확인해 AT를 재발급한다.

이렇게 하여 서버는 인증에서 분리시킨다.

 

JWT 의 리프레시 토큰이 탈취된다면?

RTT(Refresh token rotation)을 둡니다. 즉 AT가 만료될 떄, RT도 같이 교체해줍니다.

또는 블랙리스트가 있는데, 유저가 로그아웃하면 해당 AT로는 만료될때까지 블랙리스트로 등록해 서비스에 접근 못하고 이후 블랙리스트(Redis)에서 제거합니다. 

 

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

어떤 서버가 요청을 받아도 동일한 세션 상태를 참조할 수 있어야할 것입니다.

1. Sticky Sesstion
   로드밸런서에서 쿠키나 IP 등을 기반으로 특정 서버에 고정으로 라우팅 시킵니다. 즉, 같은 사용자의 요청이 항상 같은 서버로 가도록 고정시키는 방식입니다.
   이는 서버간 세션 공유를 하지 않아 구현은 간단하고, 기존 메모리 기반 세션 관리를 유지 가능합니다.
   하지만 서버에 장애가 생기면 하나에서 관리되던 세션은 삭제됩니다. 또 부하가 균등하게 분산되지 않을 수 있습니다.
   
   
2. 외부 세션 저장소를 도입합니다.
   공용 DB를 도입해 모든 서버는 세션 ID를 쿠키에서 읽고, 공용 DB에서 상태를 조회합니다.
   이는 서버 수가 많아도 상태 일관성을 유지할 수 있고, 서버간 공유가 필요 없어 확장성이 좋습니다. 스케일링도 가능합니다.
   하지만 이 저장소 자체가 병목이 될 수 있고, 세션 조회 속도 및 캐시 전략이 필요합니다. 만약 저장소가 장애 시에는 전체 인증 서비스가 영향을 받으니 HA(고가용성) 구성이 필수입니다. (여러 복제본을 두거나 분산처리)
   
   
3. JWT로 전환합니다.
   세션을 제거하고 토큰만 검증합니다.
   하지만 로그아웃이나 토큰 무효화가 어렵고, 블랙리스트, 리프레시 토큰 등으로 상태 일부 관리가 필요합니다.

TCP인데 연결이 지속되는거 아닌가?

TCP와 HTTP는 동시에 성립할 수 있습니다. 이 둘은 서로 다른 네트워크 계층의 역할을 담당합니다.

즉, 서로 다른 레벨에서 “상태”의 의미가 다르기에 충돌이 아닙니다.

 

TCP는 stateful 프로토콜이 맞습니다.

3way handshake로 연결을 수립하고 통신을 시작합니다.

클라이언트와 서버간 연결 상태를 유지합니다(시퀀스 번호, 포트, 윈도우 크기 등)

 

반면 HTTP는 stateless 프로토콜입니다.

각 요청은 독립적이고 이전의 맥락을 기억하지 않스빈다.

따라서 쿠키, 세션, 토큰 등의 응용계층 기법으로 상태를 별도로 관리해야합니다.

 

HTTP/2나 WebSocket에서는 상태 관리를 어떻게 하는가?

HTTP/2는 연결(TCP)는 지속하지만, HTTP 요청 자체는 stateless입니다.

HTTP/1은 요청응답이 순차적으로 처리해야 합니다.

하지만 2는 멀티플렉싱으로 하나의 연결에서 여러 요청을 하였습니다.
하지만 이는 전송계층의 변화이지 상태를 저장하지 않습니다.

 

웹소켓은 stateful합니다.

HTTP 핸드셰이크로 시작하여 업그레이드 합니다. 양방향 통신이 가능하며, 서로의 상태를 유지해 데이터를 주고 받습니다.

 

Authorization: Bearer의 의미

bearer는 인증 스킴의 일종으로 “이 토큰을 가진 자는 권한이 있다”는 의미입니다.

보통 Authorization 헤더의 일반 형식은 다음과 같습니다.

Authorization: <type> <credentials>

 

인증 방식(스킴)에는 Basic, Bearer, Digest등이 있고

credentials에는 실제 인증 정보가 들어갑니다.

 

추가적인 인증 수단 없이, 헤더에 이 토큰을 담으면 리소스에 접근 가능하다고 봅니다.

따라서 Bearer Token은 반드시 안전한 채널(HTTPS)로만 전송해야합니다. 탈취하면 누구나 사용 가능하기에..