🛒 Backend Engineering · 5/9 · 약 8분

Backend Engineering 시리즈 전체 보기

개발 환경에서는 로그인이 자연스럽게 이어졌지만 실행 인스턴스를 늘리면 사용자 맥락이 간헐적으로 사라질 수 있다. 요청이 항상 같은 프로세스로 향한다고 가정한 채 세션을 로컬 메모리에만 둔 것이 원인이다.

가상의 주문 서비스를 기준으로 세션의 소유권과 수명을 다시 나눠 보았다. 핵심은 특정 저장 기술을 고르는 일이 아니라, 어느 인스턴스가 요청을 받아도 같은 인증 판단에 도달한다는 불변식을 지키는 일이다.

#Backend · #Session · #DistributedSystem · #Authentication

이 글에서 다룰 것

• 로컬 메모리 세션이 다중 인스턴스에서 깨지는 이유
• 공유 세션과 무상태 토큰의 상태 소유 방식
• 만료·폐기·장애 대응을 포함한 선택 기준

프로세스의 기억을 서비스의 기억으로 볼 수 없는 이유

단일 인스턴스에서는 첫 요청이 만든 세션을 다음 요청도 같은 메모리에서 찾는다. 이 조건에서는 로컬 세션이 단순하고 빠르게 동작한다. 하지만 인스턴스가 둘 이상이면 요청 분배기가 다음 요청을 다른 프로세스로 보낼 수 있다.

따라서 지켜야 할 불변식은 요청이 도착한 위치와 인증 결과가 무관해야 한다는 것이다. 로컬 메모리는 프로세스가 재시작되면 사라지고, 장애 조치로 요청 위치가 바뀌어도 공유되지 않는다. 인스턴스 고정 라우팅은 증상을 줄일 수 있지만 상태의 소유권 문제를 없애지는 못한다.

다음 흐름은 로컬 세션이 깨지는 지점을 보여 준다.

로그인 요청 → 인스턴스 A가 세션 생성
다음 요청   → 인스턴스 B가 수신
            → A의 메모리를 조회할 수 없음
            → 로그인 맥락을 찾지 못함

이 흐름을 그려 보니 확장 자체가 문제라기보다, 확장 가능한 서비스가 프로세스 내부 상태를 공유 상태처럼 사용한 것이 문제였다.

공유 세션과 무상태 토큰은 무엇을 다르게 소유할까

공유 세션 방식에서는 클라이언트가 짧은 세션 식별자를 보내고 서버가 실제 맥락과 만료 정보를 중앙 저장소에서 관리한다. 모든 인스턴스가 같은 저장소를 바라보므로 요청 위치가 바뀌어도 일관된 결과를 얻는다. 로그아웃이나 강제 폐기를 즉시 반영해야 할 때도 중앙 통제가 쉽다.

무상태 토큰 방식에서는 요청이 서명된 인증 맥락을 운반하고 각 인스턴스가 이를 독립적으로 검증한다. 매 요청의 공유 조회를 줄일 수 있지만 발급 뒤 권한 변경과 즉시 폐기를 별도 전략으로 다뤄야 한다. 저장소 조회가 줄었다고 상태 수명 관리가 사라지는 것은 아니다.