상용에서만 되던 nginx 세션 고정, 1.29.6부터 오픈소스로 풀렸습니다

같은 사용자를 같은 서버로 — 세션 고정이 필요한 이유

서버 여러 대 앞에 nginx를 두고 트래픽을 나누면, 기본적으로 요청은 서버들 사이에 골고루 분산됩니다. 문제는 세션을 각 서버가 자기 메모리·디스크에 들고 있는 경우입니다. 로그인 정보나 장바구니가 A 서버에 저장됐는데 다음 요청이 B 서버로 가면, 사용자는 갑자기 로그아웃되거나 담아둔 상품이 사라집니다.

그래서 같은 사용자의 요청을 계속 같은 서버로 보내는 세션 고정이 필요합니다. nginx에서 이걸 구현하는 방법은 몇 가지가 있는데, 각각 동작 원리와 한계가 다릅니다. 하나씩 보겠습니다.

오픈소스의 전통적 방법 ip_hash와 hash

예전부터 오픈소스 nginx가 무료로 제공해 온 방법은 두 가지입니다. 둘 다 upstream 블록 안에 넣습니다.

첫째, ip_hash입니다. 클라이언트 IP를 키로 삼아 같은 IP를 같은 서버에 고정합니다. 공식 문서에 따르면 IPv4 주소는 앞 3옥텟만 해싱 키로 쓰고, IPv6는 전체 주소를 씁니다. 여기서 한계가 나옵니다. 같은 회사·기관의 NAT 뒤에 있는 수많은 사용자가 같은 앞 3옥텟을 공유하면, 이들이 전부 한 서버로 쏠릴 수 있습니다. 또 서버를 잠깐 빼야 할 때는 그냥 지우지 말고 down으로 표시해야 나머지 클라이언트의 분배가 유지됩니다.

둘째, hash입니다. IP가 아니라 쿠키 값 같은 임의의 키로 분배할 수 있습니다. 예컨대 애플리케이션 세션 쿠키를 키로 쓰면 같은 세션을 같은 서버로 보낼 수 있죠. 단, 기본 해시는 서버가 추가·제거되면 대부분의 키가 다른 서버로 재매핑됩니다. 이때 consistent 옵션(ketama 방식)을 주면 재매핑되는 키를 최소화할 수 있습니다.

두 방법 모두 '고정'은 되지만, 브라우저에 고정용 쿠키를 직접 심어 관리하는 진짜 세션 어피니티와는 다릅니다. 그리고 바로 그 쿠키 기반 기능이 오랫동안 오픈소스에는 없었습니다.

1.29.6의 변화 상용 전용이던 sticky가 오픈소스로

쿠키 기반 세션 고정인 sticky 디렉티브는 그동안 상용 제품인 nginx Plus 구독에서만 쓸 수 있었습니다. 공식 문서도 이를 분명히 적어 두었습니다.

1.29.6 버전 이전에는, 이 디렉티브는 상용 구독(commercial subscription)의 일부로만 제공되었다. (ngx_http_upstream_module 문서, sticky 항목)

그런데 2026년 3월 10일 출시된 nginx 1.29.6에서 상황이 바뀌었습니다. 변경 이력(CHANGES)에 "세션 어피니티 지원 — http 모듈 upstream 블록의 sticky 디렉티브"가 새 기능으로 명시되며, sticky가 오픈소스에 정식 편입됐습니다. 이제 무료 nginx에서도 다음 세 가지 방식을 쓸 수 있습니다.

• sticky cookie — nginx가 응답에 고정용 쿠키를 심고, 이후 요청을 같은 서버로 보냅니다. 만료·도메인·경로·httponly·secure·samesite 같은 속성을 지정할 수 있습니다. HTTPS 환경이라면 secure·httponly를 함께 줘 쿠키 노출·탈취 위험을 줄이는 편이 안전합니다.

• sticky route — 미리 정한 라우트 값으로 서버를 고정합니다.

• sticky learn — 애플리케이션이 만든 세션 식별자를 nginx가 학습해 매핑합니다.

한 가지 주의할 점이 있습니다. sticky learn의 여러 nginx 인스턴스 간 존 동기화(sync) 옵션은 여전히 상용 전용입니다. 즉 "이제 sticky의 모든 것이 무료"는 아니고, 단일 인스턴스에서 쓰는 기본 기능이 풀린 것으로 이해하면 정확합니다.

같은 1.29.6에서 server 디렉티브의 route·drain 파라미터도 함께 오픈소스로 풀렸습니다. 특히 drain은 이미 그 서버에 묶인(세션이 붙은) 요청만 계속 보내고 새 사용자는 다른 서버로 분산하도록 해, 세션을 유지한 채 점검·배포할 때 유용합니다. 앞서 ip_hash에서 서버를 down으로 표시하던 것과 함께, 무중단 운영에 쓸 수 있는 도구가 늘어난 셈이죠.

그래도 sticky가 만능은 아닙니다 외부 세션 스토어

세션 고정은 분명 유용하지만, 본질적으로는 "세션이 특정 서버에만 있다"는 제약을 안고 가는 방식입니다. 고정된 서버가 죽으면 그 서버에 묶인 세션도 함께 날아가고, 트래픽도 한쪽으로 쏠리기 쉽습니다.

그래서 더 근본적인 방향은 세션을 서버 로컬이 아닌 바깥에 두는 것입니다. 공유 세션 스토어(예: Redis·Valkey 같은 인메모리 캐시)에 세션을 저장하거나, 토큰(JWT)처럼 세션 상태를 클라이언트가 들고 다니게 만들면, 어느 백엔드로 가도 세션이 유지됩니다. 그러면 로드밸런서의 sticky 의존 자체가 사라지고, 서버를 자유롭게 늘리고 줄여도 사용자 경험이 흔들리지 않습니다.

다만 이는 nginx 공식 문서가 특정 제품을 권하는 내용이 아니라 일반적인 아키텍처 방향입니다. 당장 스테이트풀 구조를 바꾸기 어렵다면 sticky로 버티고, 중장기적으로는 무상태화를 검토하는 단계적 접근이 현실적입니다.

버전부터 확인하세요

세션 고정 방법을 고를 때 출발점은 의외로 단순합니다. 쓰고 있는 nginx 버전을 먼저 확인하는 것입니다.

• 1.29.6 미만이라면 오픈소스 네이티브로는 ip_hash 또는 hash $cookie_... consistent로 고정합니다.

• 1.29.6 이상이라면 sticky cookie로 쿠키 기반 고정을 무료로 쓸 수 있습니다. (다만 최신 안정 버전 사용을 권장하며, 현재 최신은 mainline 1.31.1·stable 1.30.2입니다.)

• 장기적으로는 외부 세션 스토어로 무상태화해 고정 의존을 줄이는 방향을 검토합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)