Cross-Domain에서 Same-Domain Multi-Zone으로 쿠키 공유 문제 해결하기

TL;DR

세 개의 다른 프론트엔드(Next.js, Nuxt.js, PHP)가 도메인이 달라 쿠키를 공유하지 못하는 문제가 있었음
Next.js의 Multi-Zone + Rewrites 기능을 활용해 단일 도메인 하에 통합
인증 쿠키 공유, 데이터 분석 정확도 개선, 사용자 경험 개선 등 다양한 효과
특히 GA 트래킹 문제(not set)를 해결하고, 데이터 기반 의사결정이 가능해짐

새로운 회사에 합류하고 가장 먼저 마주친 문제는 로그인이었다. 한 번 로그인하려면 여러 도메인을 거쳐야 하고, 개발할 때마다 쿠키 때문에 골치가 아팠다. 처음엔 그냥 불편한 정도로 생각했는데, 알고 보니 이게 우리 조직 전체의 개발 속도를 늦추고 사용자 경험까지 망가뜨리는 심각한 문제였다.

어쩌다 이렇게 됐을까

우리 서비스의 프론트엔드는 시간이 지나면서 자연스럽게 여러 개가 생겼다. 옛날 시스템을 완전히 갈아엎기보다는 새로운 기술로 새 기능을 만들어가다 보니, 결국 3개의 서로 다른 프론트엔드가 공존하게 된 거다.

우리 서비스의 역사

PHP (2024년 이전) 가장 오래된 레거시 시스템이었다. 운영팀이 가장 익숙한 기술이었기에 운영 관리 페이지를 담당했고, PHP 세션 기반으로 인증을 처리했다.

Nuxt.js (2024년) 2024년 초에 새로 만든 시스템으로, 기존 Vue 기반에서 발전시킨 버전이었다. 기존 기능들을 담당했으며, 브라우저 쿠키 기반으로 인증을 구현했다.

Next.js (2025년) 2025년에 레거시를 정리하려고 만든 신규 시스템이다. React 기반으로 점진적 이전을 시작했고, 새로운 기능들을 담당하면서 HttpOnly 쿠키로 인증을 처리했다.

각자 나름의 이유가 있었지만, 결과적으로는 3개의 완전히 다른 시스템이 됐다.

URL에 토큰을 넘기는 방식의 문제들

토큰 관리의 복잡성 URL로 토큰을 주고받다 보니 상태 관리가 엉망이 됐다. 여러 도메인 간에 토큰 동기화도 안 되고, 보안상 취약점도 발생할 수 있었다.

사용자 경험 저하 URL이 길어지고 주소창에 이상한 파라미터들이 주르륵 붙었다. 브라우저 히스토리도 지저분해져서 사용자 경험이 크게 저하됐다.

개발 생산성 저하 각 도메인마다 토큰 처리하는 코드를 따로 작성해야 했고, 디버깅할 때 복잡한 리다이렉트 흐름을 따라가기도 힘들었다. 테스트 코드 작성도 어려워졌다.

고려했던 해결 방안들

CDN으로 해보자 CDN Behavior 설정으로 라우팅하는 방법을 생각해봤다. 애플리케이션 코드는 거의 안 건드려도 되고, 각 존별로 독립적인 캐싱도 가능했다. CDN 엣지에서 처리하니 속도도 빨랐다. 하지만 CDN 설정이 너무 복잡하고 디버깅이 어려웠으며, 비용도 많이 들었다.

프록시 서버로 해보자 Nginx 같은 프록시 서버로 라우팅하는 방법도 검토했다. 세밀한 라우팅 제어가 가능하고 헤더와 쿠키도 마음대로 조작할 수 있었다. 로드밸런싱까지 할 수 있어 좋았지만, 인프라 관리 포인트가 늘어나고 단일 실패 지점이 생기는 게 문제였다. 응답 속도도 느려질 수 있었다.

두 방법 다 "너무 할게 많다"는 결론에 도달했다.

Zone 구성과 라우팅 전략

Next.js의 Multi-Zone 구성은 세 개의 주요 영역으로 나뉘었다. Zone A는 Next.js로 만든 메인 앱과 새 기능들을, Zone B는 Nuxt.js로 된 기존 기능들을, Zone C는 PHP로 된 운영 관리 도구를 담당했다.

라우팅은 두 가지 방식으로 구현했다. Hard Navigation은 Zone 간 이동할 때 사용했는데, 페이지 전체를 새로고침하면서도 쿠키와 세션 정보는 유지했다. Soft Navigation은 각 Zone 안에서의 이동을 담당했고, 클라이언트 사이드 라우팅으로 부드러운 페이지 전환을 구현했다.

Next.js의 Rewrites 기능을 쓰면 Multi-Zone 마이크로 프론트엔드를 만들 수 있었다.

Zone 구성

Zone A: Next.js - 메인 앱 겸 새 기능들
Zone B: Nuxt.js - 기존 기능들
Zone C: PHP - 운영 관리 도구

라우팅을 두 가지로 나눔

Hard Navigation:

Zone 간 이동할 때 사용
페이지 전체가 새로고침됨
쿠키와 세션 정보는 그대로 유지

Soft Navigation:

각 Zone 안에서의 이동
클라이언트 사이드 라우팅
부드럽게 페이지 전환

Next.js Rewrite로 구현

핵심은 이거다: 사용자가 보는 URL은 그대로인데, 실제로는 다른 서버로 요청을 보내는 것.

고려해야 했던 것들

정적 파일들과 Path 규칙을 미리 파악해야 했다:

Nuxt.js 정적파일들과 라우팅 규칙
PHP 정적파일들과 라우팅 규칙

const multiZoneConfig = {
  async rewrites() {
    const nuxtRewriteConfig = [
      {
        source: '/_nuxt/:path*',
        destination: `${env.NUXT_JS_URL}/_nuxt/:path*`,
      },
      {
        source: '/app/user/podo/:path*',
        destination: `${env.NUXT_JS_URL}/app/user/podo/:path*`,
      },
    ];

    const phpRewriteConfig = [
      {
        source: '/js/:path*',
        destination: `${env.PHP_URL}/js/:path*`,
      },
      {
        source: '/css/:path*',
        destination: `${env.PHP_URL}/css/:path*`,
      },
      {
        source: '/img/:path*',
        destination: `${env.PHP_URL}/img/:path*`,
      },
      {
        source: '/app/android/:path*',
        destination: `${env.PHP_URL}/app/android/:path*`,
      },
    ];

    return [...nuxtRewriteConfig, ...phpRewriteConfig];
  },
};

Next.js가 검사하는 순서

헤더 확인하고 적용
리디렉션 규칙 확인
정적 파일 처리
- beforeFiles (정적파일보다 우선 처리)
- 정적파일 검사 (public/, _next/static)
- afterFiles (정적파일이 없을 때 대부분 사용)
- fallback (최종 백업)
최종 응답 처리

쿠키 문제 해결

// Next.js에서 쿠키 설정
Set-Cookie: access_token=xxx; SameSite=None; Secure; HttpOnly

이제 모든 요청에 쿠키가 자동으로 포함돼서 각 존에서 인증 상태를 공유할 수 있게 됐다.

4개월간의 삽질

하지만 이 과정이 4개월이나 걸린 이유는 단순히 기술적 구현만의 문제가 아니었다.

데이터 기반 의사결정의 중요성

우리 팀은 모든 결정을 데이터에 기반해서 한다. 마케터들은 GA 데이터를 보고:

어떤 채널에서 유저가 많이 들어오는지 분석
효과 좋은 광고에 예산을 더 투입
프로덕트 로드맵도 유입 채널별 성과를 보고 결정

그런데 도메인이 여러 개로 나뉘어 있다 보니 GA 트래킹이 제대로 안 됐다.

12월부터 시작된 GA 지옥

문제의 시작: (not set) 폭증

12월부터 GA에서 세션 소스가 (not set)으로 뜨는 비율이 75%까지 치솟았다. 마케터 입장에서는 재앙이었다.

어떤 광고가 효과 있는지 모르겠음
유저가 어디서 오는지 추적 불가
데이터 기반 의사결정이 불가능해짐

크로스 도메인의 한계

도메인이 다르다 보니 내부 사이트끼리 이동하는 것도 외부 유입으로 잡혔다. 예를 들어:

유저가 광고를 통해 메인 페이지(service-a.example.com)에 진입
로그인 후 앱 페이지(service-b.example.com)로 이동
GA에서는 이 과정이 "광고 유입 → 이탈 → 다이렉트 유입"으로 기록

결과적으로:

실제 광고 효과 측정 불가
유저 여정 추적 단절
ROI 계산 부정확

이런 상황이 지속되면서 마케팅팀의 고민은 깊어졌다:

"광고비를 늘려야 할지, 줄여야 할지 판단이 안 돼요. 유저가 어디서 오는지도 모르는데, 어떻게 예산을 배분하죠?"

GA 문제 해결을 위한 삽질기

1차 시도: GTM으로 도메인 간 추적

크로스 도메인 트래킹 설정
linker 파라미터 추가
결과: 더 많은 노이즈 발생

2차 시도: 서버 사이드 트래킹

백엔드에서 세션 정보 전달
Measurement Protocol 활용
결과: 구현 복잡도만 높아짐

3차 시도: 쿠키 공유 시도

document.domain 조작
CORS 설정 변경
결과: 브라우저 보안 정책과 충돌

이런 시도들을 거치면서 깨달은 것은, 근본적인 문제 해결 없이는 안 된다는 것이었다.

Same-Domain Multi-Zone으로의 전환

Next.js Multi-Zone 도입 후 GA 트래킹이 정상화되기 시작했다:

1) 도메인 통합 효과

모든 서비스가 단일 도메인 아래로 통합
내부 이동이 실제로 "내부 이동"으로 인식됨
세션 단절 문제 해결

2) 데이터 품질 개선

not set 비율 75% → 21%로 감소
유입 채널별 기여도 정확히 측정
광고 성과 분석 가능

3) 마케팅 의사결정 정상화

채널별 ROAS 측정 가능
A/B 테스트 신뢰도 상승
예산 배분의 과학화

처음에는 단순히 '불편한' 문제라고 생각했던 것이 실제로는 회사의 성장을 가로막는 심각한 기술 부채였다. 하지만 이를 해결하는 과정에서 깨달은 것은, 기술 부채를 해결하는 것이 단순히 코드를 깔끔하게 만드는 것이 아니라는 점이다.

진정한 기술 부채 해결은 비즈니스 가치를 창출하고, 조직의 생산성을 향상시키며, 사용자 경험을 개선하는 것이다. 이 세 가지가 균형을 이뤄야 했다.

2. 팀 간 협업의 중요성

이 프로젝트는 개발팀만의 성과가 아니었다. 여러 부서와의 긴밀한 협업이 있었기에 가능했다.

개발팀과 마케팅팀은 주간 미팅을 통해 GA 데이터 정합성을 체크하고, 새로운 기능 출시 시 트래킹 포인트를 협의했다. A/B 테스트 설계부터 결과 분석까지 함께 진행했다.

개발팀과 운영팀은 장애 대응 프로세스를 간소화하고, CS 응대 시간을 단축했다. 시스템 모니터링 포인트도 함께 정립했다.

개발팀과 제품팀은 사용자 행동 데이터를 기반으로 기능의 우선순위를 설정했다. 퍼널 분석을 통해 UX 개선포인트를 도출하고, 신규 기능 기획 시 기술적 제약사항을 사전에 검토했다.

3. 기술 선택의 교훈

Next.js Multi-Zone을 선택한 것은 단순한 기술 선택이 아닌, 전략적 선택이었다.

먼저, 점진적 개선이 가능한 솔루션이라는 점이 중요했다. 한 번에 모든 것을 바꾸지 않아도 되고, 각 팀의 개발 자율성을 보장하면서 리스크를 분산시킬 수 있었다.

운영 복잡도도 크게 감소했다. 하나의 도메인으로 통합되면서 인증 흐름이 단순화되었고, 모니터링 포인트도 줄었다.

비즈니스 측면에서도 큰 임팩트가 있었다. 데이터 기반 의사결정이 가능해졌고, 마케팅 효율이 개선되었으며, 사용자 경험도 크게 향상되었다.

4. 앞으로의 과제

이 프로젝트를 통해 많은 것을 해결했지만, 아직 가야할 길이 남아있다.

기술적으로는 레거시 코드의 점진적 마이그레이션이 필요하다. 성능 최적화와 번들 사이즈 관리도 계속되어야 하며, 테스트 자동화 범위도 확대해야 한다.

조직적으로는 개발 프로세스 표준화가 필요하다. 기술 문서화와 지식 공유를 체계화하고, 신규 입사자를 위한 온보딩 시스템도 구축해야 한다.

비즈니스 측면에서는 데이터 기반 의사결정 문화를 더욱 공고히 해야 한다. 신규 비즈니스 확장 시 아키텍처 확장성을 검증하고, 글로벌 시장 진출을 위한 기술적 기반도 마련해야 한다.

5. 마치며

이 프로젝트는 단순한 기술 전환이 아닌, 조직의 성장 과정이었다. 기술 부채를 해결하면서도 비즈니스 가치를 창출할 수 있다는 것을 증명한 소중한 경험이었다.

특히 세 가지 교훈이 깊이 남았다. 기술 부채는 반드시 비즈니스 관점에서 해결해야 하고, 조직 전체가 공감할 수 있는 해결책을 찾아야 하며, 완벽한 해결책보다는 점진적으로 개선할 수 있는 방법을 선택해야 한다는 것이다.

이제 우리 팀은 이 경험을 바탕으로, 새로운 도전을 준비하고 있다. 기술과 비즈니스의 균형을 맞추면서, 더 나은 제품을 만들어가는 여정을 계속할 것이다.

핵심 정리

항목	전(before)	후(after)
도메인 구조	cross-domain	same-domain multi-zone
쿠키 공유	불가	가능
GA/GTM 세션 추적	not set 문제	유입 추적 가능
마케팅 데이터	광고 최적화 어려움	캠페인 성과 분석 가능
인증 흐름	혼란스러움	통합됨

이 아키텍처 변화는 단순한 기술 개편이 아니라, 제품, 마케팅, 데이터 조직 전체에 임팩트를 준 변화였다. 기술부채를 해결하는 건 단순히 코드를 정리하는 게 아니다. 조직의 비즈니스가 계속 돌아가도록 해야 한다는 걸 배우고 실천해본 경험이었다.