인증 상태에 따라 입구를 바꿔
세션 쿠키를 보고 로그인하지 않은 사용자를 보호 경로에서 로그인 화면으로 보내거나, 이미 로그인한 사용자를 /login에서 앱으로 돌려보낼 수 있어. 이 단계는 사용자 경험을 위한 빠른 문지기이고 최종 권한 검사는 아니야.
첫 방문의 지역과 실험군을 정해
호스팅 환경이 제공하는 국가·지역·도시 정보를 바탕으로 첫 요청을 locale 경로로 보낼 수 있어. A/B 테스트라면 첫 방문에 variant 쿠키를 만들고 이후 요청에서 같은 값을 읽어, 별도 서버 상태 없이 내비게이션 뒤에도 실험군을 유지할 수 있어.
아래쪽 코드가 읽을 헤더를 보강해
보안 헤더, 요청 ID, feature flag처럼 이후 라우트와 로그가 함께 써야 할 값을 추가하거나 재작성할 수 있어. 요청 ID를 한 번 부여하면 서버 로그와 오류 추적을 같은 흐름으로 묶기 쉬워져.
matcher로 범위를 좁혀
정적 자산과 이미지 최적화 요청까지 매번 Proxy를 거치게 하면 불필요한 비용이 생겨. 실제로 판단이 필요한 경로만 matcher에 넣고, 네트워크 입구에서 끝낼 수 있는 가벼운 결정만 수행해.
Proxy 규칙마다 입력 신호, 출력 변화, 만료 조건을 적어. 인증 쿠키는 redirect, A/B 쿠키는 안정된 bucket, 요청 ID는 하류 헤더로 이어져야 해. curl로 쿠키 유무와 여러 경로를 조합해 시험하고 정적 파일이 matcher에서 빠지는지도 확인해.
지리 정보나 User-Agent는 완벽한 신원 정보가 아니고 privacy proxy와 bot 때문에 틀릴 수 있어. 첫 locale 제안과 분석 분류에는 쓸 수 있지만 결제 통화나 법적 권한을 단독으로 결정하지 마. 사용자가 수정할 길과 서버의 더 강한 검증이 필요해.
로그인 쿠키, locale 신호, A/B 쿠키, 요청 ID를 조합한 표를 만들고 각 요청의 redirect·rewrite·header를 curl로 검증해. 첫 방문과 후속 방문의 bucket이 유지되는지, 사용자가 locale을 바꾼 뒤 자동 추정이 선택을 덮지 않는지도 확인해. 이 규칙이 많아지면 Proxy를 거대한 조건문으로 키우지 말고 작은 순수 결정 함수로 나눠 표 기반 테스트를 붙여. 네트워크 경계는 얇게 유지하되 그 안의 정책은 입력과 출력이 분명하게 보여야 해.
실험군과 locale 선택은 쿠키가 없거나 잘못됐을 때도 결정적이어야 해. 첫 방문과 재방문에서 같은 입력이 같은 경로를 고르는지 기록해.