[kt cloud TECH UP] Next.js와 Spring Boot, 인증(Auth)의 책임은 누구에게 있는가?

2026. 2. 12.
Next.jsSpring BootAuthenticationNext-Authkt cloud TECH UP

kt cloud TECH UP 실무 통합 프로젝트 멘토링 회고 4편입니다. 이번 포스팅에서는 백엔드와 프론트엔드 개발자 사이의 가장 뜨거운 감자였던 **"그래서 로그인(인증) 관리는 누가, 어떻게 주도할 것인가?"**에 대한 아키텍처 토론 과정을 공유합니다.만 믿으면 망하는 이유](../kt-cloud-tech-up-marathon-auto-scaling-trap))

1. 프론트엔드의 무기: Next.js와 Next-Auth

현대 웹 개발에서 프론트엔드는 단순한 화면 그리기를 넘어 강력한 SSR(Server Side Rendering) 기능을 갖춘 서버(Next.js) 역할을 수행합니다. 우리 팀의 프론트엔드 파트 역시, 사용자 세션과 토큰(JWT) 관리를 위해 프론트엔드 진영의 강력한 무기인 Next-Auth 라이브러리를 도입하고자 했습니다.

초기 제안 (Next-Auth 중심 설계):

  1. 사용자가 로그인을 시도하면 Next.js 서버가 백엔드(Spring)와 통신하여 Access/Refresh Token을 받아옵니다.
  2. Next-Auth가 이 토큰들을 암호화하여 브라우저의 쿠키(Cookie)에 안전하게 구워줍니다.
  3. 브라우저는 쿠키만 들고 Next.js 서버와 소통하며 로그인 유지를 보장받습니다.

여기까지는 프론트엔드 입장에서 완벽하고 안전한 아키텍처였습니다. 하지만 대규모 트래픽이라는 마라톤 티켓팅의 비즈니스 요구사항과 부딪히며 백엔드 팀(세현님)의 날카로운 반론이 시작되었습니다.

2. 백엔드의 반론: "트래픽 병목과 SSR 통신의 한계"

백엔드 파트는 이 Next-Auth 중심 설계에서 두 가지 치명적인 문제점을 지적했습니다.

문제 1. Next.js 서버의 트래픽 병목 현상

마라톤 티켓팅이 시작되어 15,000명의 API 요청이 폭주할 때, 만약 클라이언트 브라우저 -> Next.js 서버 -> 백엔드(API Gateway) 순서로 모든 요청이 거쳐 간다면 어떻게 될까요? 가뜩이나 화면 렌더링(SSR)에 바쁜 Next.js 서버 Node.js 스레드들이, 그 엄청난 API 중계(Proxying) 부하를 견디지 못하고 터져버릴 위험(병목 현상)이 컸습니다. 백엔드 측은 "로그인 과정만 Next.js 서버를 거치고, 그 이후 수만 건의 무거운 티켓팅 요청은 브라우저에서 직접 백엔드 API Gateway로 직행해야 트래픽이 분산된다"고 주장했습니다.

문제 2. 브라우저가 없는 서버 간(S2S) 인증 (SSR 딜레마)

만약 브라우저에서 백엔드로 직접 API를 쏜다면, 브라우저가 자동으로 실어 보내주는 쿠키(withCredentials)를 사용할 수 있습니다. 하지만, Next.js의 핵심 기능인 SSR(Server Component) 화면을 그리기 위해 프론트엔드 서버가 백엔드 서버로 데이터를 미리 요청(Fetching)할 때는 브라우저라는 중개자가 없습니다. 서버 대 서버(S2S) 통신이므로 쿠키가 자동으로 넘어가지 않아, Next.js 서버가 쿠키 저장소를 직접 뒤져서 값을 꺼내 헤더(Header)에 일일이 세팅해 주어야 하는 번거롭고 취약한 로직이 추가되어야 했습니다.

3. 멘토님의 중재: 딜레마의 돌파구

현업의 멘토님은 프론트엔드의 세션 관리 편의성(Next-Auth)과 백엔드의 트래픽 분산 논리를 모두 인지하고 명쾌한 가이드를 주셨습니다.

  1. 트래픽 직행 노선 확정: 백엔드의 주장대로, 티켓팅과 같은 고부하 로직은 Next.js 서버를 중계하지 않고 클라이언트(브라우저)에서 백엔드로 직접 호출하는 것이 대용량 트래픽 처리의 정석입니다.
  2. Next-Auth 사용에 대한 고찰:
    • Next.js 환경에서 브라우저 세션/토큰 관리가 복잡해진다면 Next-Auth 도입은 확실한 장점(보안, 편리성)이 있습니다.
    • 다만, SSR 환경에서의 서버 통신(withCredentials 불가) 이슈는 회피할 수 없으므로, **Next.js 서버가 쿠키에서 토큰을 추출해 백엔드 API 호출 시 수동으로 주입하는 모듈(Interceptor 등)**을 단단하게 설계해야 한다고 조언하셨습니다.

4. 완벽한 아키텍처는 없다, 트레이드오프(Trade-off)만 있을 뿐

결론적으로 우리는 **"Next-Auth를 통해 편안하고 안전한 세션 관리를 취하는 대신, SSR Fetching 과정에서 토큰을 수동 세팅하는 개발 공수(귀찮음)를 프론트엔드가 짊어진다. 동시에, 티켓팅 API는 브라우저 ↔ 백엔드 직접 통신으로 완전히 뚫어(Bypass) 트래픽 병목을 방지한다"**는 타협점에 도달했습니다.

이번 멘토링과 기술 토론을 통해, 보안(Auth)과 성능(Traffic), 그리고 개발 편의성(Next.js) 사이에는 모든 조건을 100% 만족시키는 아키텍처는 존재하기 어렵다는 점을 확인했습니다. 오직 비즈니스 상황에 맞는 가장 합리적인 '기회비용(Trade-off)'을 선택하고, 그 선택의 단점을 꼼꼼하게 막아내는 개발자의 역량만이 시스템을 단단하게 만든다는 사실을 명심하게 되었습니다.

다음 시리즈의 마지막 포스팅에서는 코드 밖의 이야기, 17명이라는 대규모 팀의 커뮤니케이션 비용(소모)을 획기적으로 낮춰준 DSU(Daily Stand-Up) 이야기를 남겨보겠습니다.