개발 slecs

구 세션 쿠키로 홈 렌더가 깨지는 문제를 안전한 인증 처리로 해결

목차

구 세션 쿠키가 남아있을 때 JWTSessionError가 처리되지 않아 홈 렌더가 실패하는 문제를 겪었다. currentUserId 로직을 safeAuth 패턴으로 변경해서 에러를 안전하게 처리하도록 개선했다.

문제의 맥락

사용자가 서비스를 쓰다가 세션이 만료되거나 인증 방식이 변경되면, 브라우저에 남은 구 형식의 쿠키가 문제가 된다. 새로운 JWT 검증 로직이 그 구 쿠키를 읽으려 하면 JWTSessionError 를 던지는데, 이 예외가 제대로 처리되지 않으면 홈페이지 렌더 자체가 깨진다. 그렇게 되면 사용자는 로그인 페이지로도, 설정으로도 갈 수 없다. 치명적이다.

실제로는 이런 상황이 꽤 자주 생긴다:
- 배포 후 인증 구조 변경
- 쿠키 만료 정책 업데이트
- 사용자가 오래된 탭을 재방문할 때
- 브라우저 캐시 무효화 기간

홈페이지(진입점)는 안정성이 가장 중요한 지점이다. 어떤 상황에서든 "뭔가" 렌더링되어야 한다.

safeAuth 패턴의 역할

safeAuth는 인증 관련 예외를 명시적으로 처리하는 래퍼 함수다. "안전한 인증" 이라는 뜻이지만, 더 정확히는 에러 바운더리 역할을 한다.

관점 기존 방식 safeAuth 방식
에러 발생 시 예외가 그대로 위로 전파 예외를 잡아서 fallback 값 반환
렌더 안정성 에러 → 렌더 실패 에러 → 안전한 기본값(null/undefined) → 렌더 진행
로직 복잡도 호출처에서 try-catch 필요 함수 내부에서 처리 완료
홈페이지 UX 완전 백지 상태 "로그인해주세요" 같은 정상 fallback

코드 레벨에서는 이렇게 동작한다:

// 기존: 예외가 상위로 전파되면 렌더 실패
const userId = getCurrentUserId(); // throws JWTSessionError

// 개선: 안전하게 예외를 내부에서 처리
const userId = safeAuth.getCurrentUserId(); // returns null | string
if (!userId) {
  // 로그인 페이지 보여줌, 렌더 진행
}

왜 지금 고쳤나

개발팀에서 "홈페이지 렌더가 가끔 깨진다"는 이슈를 받았고, 재현해보니 구 세션 환경에서만 발생했다. 몇몇 사용자는 오래된 탭을 재방문할 때 이 상태에 빠졌고, 브라우저 개발자도구로 쿠키를 지울 때까지 벗어날 수 없었다. 그렇다면 우리가 먼저 처리해야 할 책임이었다.

결정 포인트는 간단했다:
- 심각도: 홈페이지가 렌더 안 됨 (P0)
- 재현율: 특정 환경(구 쿠키 남음)에서 확정적
- 해결책: 이미 있는 safeAuth 래퍼를 currentUserId 에도 적용하기만 하면 됨
- 영향: 렌더 로직 변경 없음, 예외 처리만 추가

이런 타입의 fix는 사실 보안 vs 가용성의 트레이드오프를 담고 있다. 잘못된 인증을 조용히 통과시키면 보안 문제가 될 수 있다. 하지만 safeAuth는 "에러를 버리는 것"이 아니라 "에러를 로그하고 안전하게 처리"하는 패턴이므로, 양쪽을 모두 지킬 수 있다.

인증 영역에서 배운 것

이 작업을 하면서 느낀 몇 가지:

  • 진입점 안정성: 홈/대시보드 같은 주요 페이지는 "어떤 상황이든 렌더"를 원칙으로 설계해야 한다. 세부 기능은 에러를 던져도 괜찮지만, 진입점은 다르다.
  • 레거시 세션의 생명주기: 사용자들이 탭을 오래 열어두는 경향이 있다. 세션 구조를 바꾸면 구 형식이 얼마나 오래 살아있을 것인가를 고려해야 한다.
  • 에러 처리 계층: 모든 곳에 try-catch를 넣는 것보다, 신뢰할 수 있는 래퍼(safeAuth)를 만들고 일관되게 쓰는 게 유지보수가 쉽다.
  • 팀 커뮤니케이션: "왜 홈이 안 렌더되나?" 이슈는 한두 명만 겪는 게 아니라, 곧 더 많은 사용자에게 영향을 줄 가능성이 높다. 초기 신호를 놓치지 않기.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.