MSA에서 HttpSession을 사용하면 안 되는 이유

목적

회사 프로젝트의 코드를 살펴보던 중 Service에서 HttpSession을 사용해 RSA 키를 생성하고 관리하는 로직을 발견했다.
하지만 현재 프로젝트는 Microservices Architecture(MSA) 구조로 구성되어 있으며, MSA에서는 일반적으로 Stateless(무상태성)을 지향한다는 점에서 의문이 생겼다.

HttpSession은 특정 서버의 메모리에 사용자 상태를 저장하는 방식인데, 서버가 여러 대로 구성된 환경에서는 요청이 다른 서버로 전달될 수 있기 때문에 세션 기반 로직이 정상적으로 동작하지 않을 가능성이 있다.

이러한 의문을 계기로 다음과 같은 내용을 정리해보고자 한다.

1. MSA 환경에서 HttpSession 사용이 왜 문제가 될 수 있는지

2. 세션 기반 인증과 JSON Web Token(JWT) 기반 인증의 차이

3. MSA 환경에서 인증 및 암호화 키 관리 대안

4. RSA 키를 세션 단위로 생성하는 방식의 한계와 대안

이를 통해 현재 코드 구조가 어떤 환경을 가정하고 작성되었는지 이해하고, MSA 환경에서는 어떤 방식으로 개선할 수 있을지 정리해보고자 한다.

기술적 고민을 시작한 이유

현재 회사 코드를 살펴보면서 한 가지 공통적인 설계 방향을 발견할 수 있었다.

인터페이스 / Impl 분리
→ 구현체를 분리하여 유지보수와 확장성을 높이기 위한 객체지향 설계

MyBatis의 BaseVO / Interceptor 사용
→ 반복되는 로직을 줄이고 공통 기능을 재사용하기 위한 구조

Stateless 구조 지향
→ 서비스 확장성과 장애 대응을 고려한 MSA 아키텍처의 핵심 원칙

결국 이러한 기술적 선택들은 단순한 구현 방식의 차이가 아니라,
“어떻게 하면 시스템을 더 쉽게 유지보수하고, 안정적으로 확장할 수 있을까?”
라는 고민에서 출발한다고 볼 수 있다.

따라서 나도 동일한 관점을 갖고, 발전시키고 싶은 부분에 대해 고민을 시작하였다.

MSA 환경에서 HttpSession 사용이 왜 문제가 될 수 있는지

현재 Service 코드에서는 HttpSession을 사용하여 RSA 키를 생성하고 관리하고 있다.
하지만 현재 프로젝트는 Microservices Architecture(MSA) 구조로 구성되어 있으며, MSA는 기본적으로 Stateless(무상태성)을 지향한다.

Stateless 구조에서는 특정 서버가 사용자 상태를 기억하지 않는다.
즉, 어떤 서버가 요청을 처리하더라도 동일한 결과를 반환할 수 있어야 한다.

하지만 HttpSession은 서버 메모리에 사용자 상태를 저장하는 방식이기 때문에, 서버가 여러 대로 구성된 환경에서는 문제가 발생할 수 있다.
예를 들어, 사용자의 요청이 로드밸런서를 통해 다른 서버로 전달될 경우 해당 서버에는 기존 세션 정보가 존재하지 않기 때문에 인증이나 암호화 과정에서 오류가 발생할 수 있다.

이러한 이유로 MSA 환경에서는 HttpSession과 같은 서버 의존적인 상태 관리 방식보다는, JSON Web Token(JWT)이나 공통 저장소 기반의 상태 관리 방식을 사용하는 경우가 많다.
예를 들어 인증 정보나 암호화 키를 Redis와 같은 중앙 저장소에서 관리하면 어떤 서버가 요청을 처리하더라도 동일한 데이터를 참조할 수 있다.
또한 보안 키 관리가 필요한 경우에는 AWS Key Management Service(KMS)와 같은 키 관리 시스템을 사용하는 방법도 있다.

현재 코드에서 HttpSession을 사용하는 이유는 몇 가지 가능성을 생각해볼 수 있다.

1. 초기에는 단일 서버 환경을 가정하고 작성된 로직일 가능성

2. MSA로 전환되는 과정에서 레거시 코드가 그대로 유지되었을 가능성

MSA 환경에서 안정적으로 확장하기 위해서는 세션 기반 상태 관리보다는 공통 저장소 기반의 상태 관리 구조로 전환하는 것이 필요하다.

세션 기반 인증과 JSON Web Token(JWT) 기반 인증의 차이

SESSION은 서버에서 기억해야한다면, JWT는 클라이언트가 기억하는것이다.

MSA 환경에서 인증 및 암호화 키 관리 대안

예시 1. 서버 다중화 환경에서의 세션 문제

현재 서버가 다중화된 환경이라고 가정해보자.
단일 서버 환경이라면 세션에 RSA 키를 저장하더라도 언제든지 동일한 서버에서 해당 키를 사용할 수 있다.

하지만 Microservices Architecture(MSA) 환경에서는 상황이 달라진다.

예를 들어 1번 서버에서 generateRsaKey를 호출하여 세션에 RSA 키를 저장했다고 가정해보자.
이후 암호화 요청이 발생했을 때 로드밸런서에 의해 요청이 2번 서버로 전달될 수 있다.
이 경우 2번 서버에는 해당 세션 정보가 존재하지 않기 때문에 RSA 키를 찾을 수 없고, 인증 또는 복호화 과정이 실패할 수 있다.

이 문제를 해결하기 위해 다음과 같은 방법을 사용할 수 있다.

• Sticky Session

• Session Clustering

하지만 이러한 방식은 특정 서버에 요청이 고정되거나 세션 동기화가 필요해지기 때문에 MSA의 유연성과 확장성을 떨어뜨릴 수 있다.

예시 2. 서비스 간 세션 공유 문제

또 다른 문제는 서비스 간 세션 공유가 어렵다는 점이다.

예를 들어 인증 서비스에서 HttpSession에 RSA 키를 저장했다고 가정하자.
하지만 해당 키는 다른 서비스에서 접근할 수 없다.
각 서비스는 서로 다른 물리적 서버나 컨테이너에서 실행되기 때문이다.

결과적으로 서비스 간에 암호화된 데이터를 주고받아야 하는 상황에서는 세션 기반 키 관리 방식이 의미를 잃게 된다.

MSA에서 권장되는 방식

이러한 이유로 MSA에서는 서버 세션에 의존하는 방식 대신 무상태(Stateless) 구조를 지향한다.

무상태 구조에서는 서버가 사용자 상태를 기억하지 않기 때문에
어떤 서버가 요청을 처리하더라도 동일한 결과를 반환할 수 있어야 한다.

따라서 인증 및 상태 관리를 위해 다음과 같은 방식이 사용된다.

JSON Web Token(JWT)
→ 인증 정보를 서버 세션이 아닌 토큰 자체에 포함하여 클라이언트가 보관

Redis 기반 중앙 저장소
→ 인증 정보나 암호화 키를 모든 서버가 접근할 수 있는 공통 저장소에 관리

RSA 암호화가 필요한 경우

만약 서비스 로직에서 RSA 암호화가 필요한 경우에는
HttpSession 대신 공유 저장소 기반 구조를 사용하는 것이 바람직하다.

예를 들어 Redis 기반 공유 세션, 공통 데이터베이스 기반 키 저장 또는 Key Management System(KMS) 과 같은 방식을 활용하면 어떤 서버가 요청을 처리하더라도 동일한 키에 접근할 수 있다.

RSA 키를 세션 단위로 생성하는 방식의 한계와 대안

현재 코드에서는 HttpSession을 사용하여 RSA 키를 생성하고 세션에 저장하는 방식으로 암호화를 처리하고 있다.
하지만 이러한 방식은 MSA 환경에서는 여러 가지 한계를 가진다.

먼저, 세션 기반으로 RSA 키를 관리할 경우 특정 서버의 메모리에 키가 저장되기 때문에 서버가 여러 대로 구성된 환경에서는 동일한 키를 공유하기 어렵다.
사용자의 요청이 로드밸런서를 통해 다른 서버로 전달될 경우 해당 서버에는 기존 세션 정보가 존재하지 않기 때문에 암호화 또는 복호화 과정에서 문제가 발생할 수 있다.

또한 세션마다 RSA 키를 생성하는 방식은 성능 측면에서도 비효율적일 수 있다.
RSA 키 생성은 비교적 비용이 큰 연산이기 때문에 요청이 많아질수록 서버에 불필요한 부하가 발생할 수 있다.

실제 서비스 환경에서는 애플리케이션 레벨에서 RSA 암호화를 직접 처리하기보다는, HTTPS(SSL/TLS)와 같은 표준 보안 프로토콜을 활용하는 것이 일반적이다.
HTTPS는 전송 구간에서 이미 강력한 암호화를 제공하기 때문에 대부분의 경우 애플리케이션에서 별도의 RSA 키를 생성하여 관리할 필요가 없다.

만약 서비스 내부 로직에서 암호화 키 관리가 필요하다면 다음과 같은 방법을 고려할 수 있다.

공통 저장소 기반 키 관리
→ Redis와 같은 중앙 저장소를 활용하여 여러 서버가 동일한 키에 접근할 수 있도록 구성

키 관리 시스템(KMS) 활용
→ 보안 키를 전문적으로 관리하는 시스템을 통해 안전하게 키를 저장하고 사용할 수 있음

결과적으로, MSA 환경에서는 특정 서버의 세션에 의존하는 방식보다는 모든 서버가 동일한 정보를 공유할 수 있는 구조를 사용하는 것이 중요하다.
또한 가능하다면 애플리케이션 코드에서 직접 암호화를 구현하기보다는 인프라 레벨의 표준 보안 프로토콜을 활용하는 것이 더 안정적이고 효율적인 방법이라고 볼 수 있다.

정리

이번 내용을 정리해보면, MSA 환경에서는 서버 세션에 의존하는 방식이 확장성과 안정성 측면에서 한계를 가질 수 있다.
따라서 인증 정보나 암호화 키는 특정 서버에 종속되지 않는 방식으로 관리하는 것이 중요하며,
Redis와 같은 공통 저장소나 KMS와 같은 키 관리 시스템을 활용하는 방법을 고려할 수 있다.
또한 대부분의 경우 애플리케이션 레벨의 암호화보다는 HTTPS와 같은 표준 보안 프로토콜을 활용하는 것이 더 효율적인 선택이 될 수 있다.