💥 직렬화된 Session이 나를 죽일 줄이야 – Redisson과 세션 역직렬화 이슈 정리

최근 정말 당황스러운 경험을 했습니다. 평소처럼 Java 서버를 운영하고 있었고, 사용자 세션을 Redis에 저장하기 위해 Redisson을 사용하고 있었어요. 그런데 갑자기 서버가 터졌습니다. 이유는 바로 직렬화된 객체가 변경되었는데, 역직렬화가 실패하면서 발생한 대규모 장애 때문이었습니다.

오늘은 이 이슈를 중심으로 직렬화/역직렬화, Redisson 설정, 실제 장애 상황, 그리고 이를 어떻게 해결했는지를 공유합니다.

---

🧠 Redisson이란?

Redisson은 Java에서 Redis를 마치 로컬 Java 객체처럼 사용할 수 있도록 해주는 Redis 클라이언트입니다. Redis를 단순한 캐시 서버를 넘어서 분산 락, 세션 저장소, pub/sub, 원격 서비스 등 다양한 기능으로 활용할 수 있게 해줍니다.

특히 Redisson은 Java 객체를 Redis에 저장할 때 자동으로 직렬화/역직렬화를 처리하는데, 여기서 문제의 시작이 있었습니다.

---

🔄 직렬화와 역직렬화 간단 정리

개념	설명
직렬화(Serialization)	Java 객체를 바이트 배열로 변환하여 파일, 네트워크, Redis 등에 저장할 수 있게 만드는 과정
역직렬화(Deserialization)	저장된 바이트 배열을 다시 Java 객체로 복원하는 과정

보통 Java 객체가 Serializable을 구현하고 있으면 직렬화/역직렬화에 문제가 없습니다. 그러나... 그건 어디까지나 기본 직렬화 방식을 사용할 때 이야기입니다.

---

😱 문제의 원인: Redisson Codec + 클래스 변경

Redisson은 기본적으로 Java 직렬화 방식을 따르지 않습니다. 대신 Codec이라는 설정을 통해 데이터를 어떻게 직렬화할지를 선택합니다. 예를 들어:

config.setCodec(new JsonJacksonCodec());

이렇게 JsonJacksonCodec이나 KryoCodec 같은 코덱을 사용하게 되면, 클래스 구조가 변경되었을 때도 Java의 기본 serialVersionUID 체크가 작동하지 않습니다. 즉, Redisson 입장에선 "기존에 저장된 데이터가 어떤 구조였는지"를 몰라버리는 거죠.

그래서 객체에 필드를 하나만 추가해도 역직렬화가 실패합니다. 예외는 대개 이런 식으로 발생합니다:

com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "newField"

---

☠️ 장애 상황: 세션 객체 역직렬화 실패 → 서버 터짐

문제는 여기서 끝이 아닙니다. 서버는 사용자의 세션을 Redis에서 꺼내오면서 이 역직렬화 예외가 수십, 수백 번 발생했고, 우리는 그걸 무심코 try-catch로 감쌌습니다.

try {
  Session session = redissonClient.getBucket("session-key").get();
} catch (Exception e) {
  logger.error("Session fetch failed", e);
}

하지만 사용자 수가 많다 보니 예외가 계속 발생했고, JVM에서 Exception 객체가 계속 생성되고 GC되지 않으면서 메모리 누수가 생겼습니다. 결국 서버가 OOM(Out Of Memory) 로 죽어버렸습니다.

---

🧹 해결 전략: 과감한 flush로 초기화 처리

문제의 원인이 기존에 Redis에 저장되어 있는 직렬화된 세션 객체였기 때문에, 안전한 방법은 다음과 같았습니다:

1. 기존 세션 데이터 전부 삭제 (flushdb)
2. 클래스 구조 안정화 후 재배포
3. 직렬화 변경 시 미리 flush 작업 또는 데이터 마이그레이션 고려

우리는 과감하게 flushdb를 적용했고, 새롭게 저장된 구조부터는 역직렬화에 실패하지 않았습니다.

---

✅ 예방을 위한 팁

• 직렬화 코덱의 특성을 반드시 이해하고 사용해야 합니다.
• 클래스 구조를 바꿀 땐 가능한 한 호환성을 유지하거나, 버전 마이그레이션 로직을 작성해야 합니다.
• 예외는 무조건 try-catch로 감싸지 말고, 루프성 호출 또는 요청 필터링 전 전략적으로 차단해야 합니다.
• 사용자가 많거나 반복 호출되는 영역이라면 GC 부하까지 고려한 예외 관리가 필수입니다.

---

🔚 마무리하며

이번 장애는 "그깟 필드 하나 추가했을 뿐인데..."라는 방심에서 시작된 대참사였습니다.

특히 Redisson처럼 외부 코덱을 쓰는 환경에서는 Java 기본 직렬화처럼 동작하지 않는다는 걸 꼭 기억하세요.

직렬화는 기술이 아니라 약속입니다.

변경이 있을 땐 반드시 그 약속을 지키고, 지킬 수 없다면 새로운 약속을 만들 준비가 필요합니다.

👉 코드를 바꾸기 전에, 저장된 객체가 어디에 있는지, 어떻게 직렬화되어 있는지를 먼저 확인해보는 습관이 필요합니다.