하이브리드 환경의 인증 파편화와 클라이언트 토큰 보관의 위험
웹 브라우저와 네이티브 앱 내부 웹뷰를 단일 프론트엔드 코드베이스로 운영할 때 가장 까다로운 장벽 중 하나는 인증 토큰의 유입과 보관 방식이 서로 다르다는 점입니다. 일반 웹 브라우저는 HTTP 요청 시 자동으로 전송되는 쿠키를 중심으로 동작하지만, 네이티브 앱은 기기 내부 저장소에 세션을 보관하고 웹뷰 브릿지를 거쳐 값을 전달합니다.
여기어때 서비스웹개발팀에 따르면, 화면 단위에서 각 환경에 맞춰 분기 코드를 작성하면 액세스 토큰이 컴포넌트 변수와 함수 인자로 전달되며 클라이언트 자바스크립트 전역에 노출되는 구조적 문제가 발생합니다. 토큰을 브라우저 로컬 스토리지나 메모리에 직접 보관해 요청 헤더에 첨부하는 방식 역시 자바스크립트가 직접 값을 읽어야 하므로, 외부 스크립트나 XSS 취약점 발생 시 토큰 탈취에 매우 취약해지는 문제를 안게 됩니다.
세 갈래 유입 경로를 통합하는 서버 액션과 HttpOnly 쿠키 단일화
여기어때 개발팀이 분석한 토큰 진입 경로는 크게 세 가지입니다. 첫째는 웹 환경에서 SSR 시점에 서버가 즉시 읽어 들이는 웹 쿠키이며, 둘째는 앱 웹뷰 환경에서 브릿지를 통해 앱 저장소를 조회하는 경로입니다. 셋째는 로그인 직후 앱 저장소의 상태 동기화 지연으로 구버전이나 빈 값이 반환될 때 앱에 직접 토큰을 재요청하는 보완(Fallback) 경로입니다.
개발팀은 이처럼 유입 경로가 셋으로 갈리더라도 최종 종착지는 서버 측 'HttpOnly 쿠키' 하나로 모으는 아키텍처를 구현했습니다. 네이티브 앱 브릿지로 전달받은 토큰은 화면 코드에 오래 머물지 않고 곧각 Next.js 서버 액션을 거쳐 서버 측에서 HttpOnly 쿠키로 재설정됩니다. 이후 사용자 프로필 조회는 앱이 넘겨주는 가변적인 데이터 대신, 웹과 완전히 동일한 단일 API(getMyInfo)를 호출해 데이터 규격 불일치를 원천 방지했습니다.
IETF 표준 관점에서 살펴본 보안 효과와 방어 한계
개발팀은 토큰을 HttpOnly 쿠키에 담음으로써 자바스크립트를 통한 XSS 탈취 경로를 차단했다고 밝혔습니다. IETF RFC 6265 표준(Section 4.1.2.6)과 OWASP 보안 가이드에 따르면, HttpOnly 속성은 document.cookie API를 통한 클라이언트 스크립트의 접근을 명시적으로 제한하여 공격자가 토큰 문자열 자체를 오프라인으로 빼돌리는(Exfiltration) 행위를 방어하는 데 실질적인 효과를 제공합니다.
하지만 HttpOnly 속성이 XSS 취약점 자체를 완전히 무력화하는 만능 대책은 아닙니다. 만약 웹 애플리케이션 내에 악성 스크립트가 실행될 수 있는 환경이 잔존한다면, 공격자가 토큰 값을 직접 읽지 못하더라도 브라우저 실행 맥락 내에서 인증된 사용자 권한으로 비인가 비동기 요청을 직접 수행할 수 있습니다. 따라서 쿠키 기반 통합 구조가 실질적인 보안을 담보하려면 SameSite 속성 적용, CSRF 방어 토큰 결합, 콘텐츠 보안 정책(CSP) 설정이 병행되어야 합니다.
프레임워크 비의존 라이브러리 격리와 무한 렌더링 방지 설계
인증 인터페이스를 공용 라이브러리로 분리하는 과정에서 발생할 수 있는 의존성 결합 문제도 다루어졌습니다. 개발팀은 인증 코어 훅(useAuthCore)이 Next.js 프레임워크 기능에 직접 의존하지 않도록, 회원 조회나 쿠키 등록 같은 구체적 실행 로직을 외부에서 주입받는 인터페이스 패턴으로 설계했습니다.
또한 전역 인증 상태를 감싸는 React 훅의 특성상 의존성 배열(deps) 관리에 엄격한 규칙을 적용했습니다. 액션 객체 전체를 deps에 포함할 경우 얕은 복사 문제로 인한 무한 렌더링 루프가 발생할 수 있어, 실제로 실행되는 세부 함수 단위(actions.getMyInfo)로 의존 대상을 한정했습니다. 이를 통해 화면 렌더링은 유지되면서 백그라운드에서 불필요한 회원 조회 요청이 끊임없이 반복되는 리소스 낭비를 차단했습니다.
실무 적용 시 고려해야 할 사용자 경험과 상태 동기화 트레이드오프
이번 아키텍처는 서버 사이드 렌더링(SSR) 단계에서 쿠키를 활용해 비로그인 상태에서 로그인 상태로 전환될 때 생기는 레이아웃 흔들림(Flickering)을 크게 줄였습니다. 하지만 앱 웹뷰 진입 시점에는 브릿지를 통해 토큰을 받아 서버 액션으로 쿠키를 굽는 과정이 완료될 때까지 화면을 비워두는 빈 화면(Blank Screen) 노출 전략을 채택했습니다. 이는 로그인 상태 전환의 어색함은 막지만, 초기 페인트 시점의 체감 지연 시간을 늘릴 수 있는 명확한 UX 트레이드오프입니다.
아울러 네이티브 앱 저장소의 타이밍 어긋남을 프론트엔드에서 2회 연속 요청으로 흡수한 처리는 신속한 실무적 우회책(Workaround)이지만, 네트워크 왕복 지연을 가중시키는 요인이 됩니다. 또한 본 발표 자료에서는 토큰 만료 시 리프레시 토큰을 네이티브 앱과 어떻게 재동기화하는지, 그리고 서버 액션을 경유하는 데 따른 정량적 지연 시간(TTFB) 수치가 제시되지 않았으므로 대규모 도입 시 성능 검증이 추가로 요구됩니다.
출처
여기어때 기술블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
항공 프론트엔드 구축기 (8/10): 토큰이 세 군데서 온다 (새 창)
