도메인 간 언어오염과 Middleware 패턴
도메인마다 지원 언어가 달라 생긴 404를 Middleware 패턴으로 중재하기
주어진 요구사항 - GNB 통일과 다국어 지원
파편화된 서브도메인 서비스를 하나의 통합된 브랜드 경험으로 묶기 위해 공통 GNB를 적용하는 작업이었다. 그러면서 스페인어까지 지원을 넓히기로 했다.
기존에는 /en 으로 언어가 고정되어 있었는데, 이를 제거하고 사용자에게 맞는 언어를 제공하도록 바꾸는 것이 함께 주어진 요구사항이었다.
문제 상황 - 도메인 간 지원 언어의 불일치
메인 도메인은 6개 언어를, 서브도메인은 3개 언어를 지원하고 있어 지원 언어 세트에 격차가 있었다. 그런데 두 곳이 같은 상위 도메인을 쓰다 보니 언어 쿠키는 그대로 공유되었다.
그래서 메인에서 서브도메인이 지원하지 않는 언어를 고른 채 넘어오면 404 에러를 만나게 되었다.
단순한 GNB 통합 작업인 줄 알았지만, 언어 정책까지 함께 통일되어야 하는 일이었다.
초기 해결책 - Next.js Proxy 기반의 언어 Fallback
어디서 처리할까 - page.tsx vs proxy.ts
- 방법 1: 메인 도메인에서 넘어오는 페이지가 하나뿐이니, 그 페이지에서 처리한다
- 방법 2: Next.js의 proxy 파일에서 모든 요청을 검증하고 처리한다
추후에 메인 도메인에서 넘어오는 페이지가 늘어날 여지가 있어서 proxy에서 처리하기로 했다. 그런데 페이지마다 분기를 두지 않고 요청을 한곳에서 가로채 처리하는 이 방식이 곧 Middleware 패턴이라, 어떤 패턴인지 먼저 짚고 넘어간다.
Middleware 패턴이란
개별 컴포넌트 간의 직접 통신을 중앙 중재자로 일원화하고, 요청이 목적지에 닿기 전에 횡단 관심사를 가로채어 처리하는 패턴이다. 비즈니스 로직과 시스템의 결합도를 떼어 놓는 데 쓰인다.
- 다대다 관계의 컴포넌트 결합을 일대다로 단순화해 의존성을 중앙에 모은다
- 요청과 응답 사이에서 검사, 변환, 단축, 리다이렉트 같은 전처리를 수행한다
- 언어 감지, 라우팅, 인증 같은 공통 관심사를 페이지 컴포넌트에서 완전히 걷어낼 수 있다
- Next.js의 Proxy(구 Middleware)가 모든 페이지 전환에서 동작하는 Middleware 패턴의 예다
미들웨어에서 영어로 폴백
개별 페이지를 고치지 않고, Next.js 미들웨어에서 진입 요청을 가로채 처리하도록 구현했다. 미지원 언어로 들어온 요청을 기본 언어인 영어 en 으로 강제 매핑해 404를 막았다.
추가 문제 - 표시 언어를 고치려다 선택 언어까지 덮었다
404는 막았지만 다른 문제가 생겼다. 언어를 en 으로 격하하면서 공통 쿠키까지 덮어써 버렸고, 그 상태로 메인 사이트에 돌아가면 원래 고른 언어가 아닌 영어로 보이게 되었다.
원래는 GNB가 달라 메인으로 돌아갈 경로 자체가 없었는데, GNB를 통합하면서 새로운 사용자 플로우가 생긴 탓이었다.
화면에 무엇을 보여 줄지 보정하는 일과, 사용자가 무엇을 고를지 그 의도를 보존하는 일은 엄격히 분리되어야 한다는 걸 여기서 알게 되었다.
요구사항은 만족했지만 처음에 내세운 고객 가치, 하나의 통합된 브랜드 경험은 오히려 달성되지 않은 셈이었다.
추가 해결책 - 언어 분리 운영
사용자의 선택 언어와 화면의 표시 언어를 갈라 두고, 쿠키는 미들웨어 파이프라인에서 중재하도록 재설계했다.
언어를 바꾸는 모달은 공용 컴포넌트라 지원하지 않는 언어까지 포함하고 있다. 그래서 메인에서 넘어온 언어 쿠키가 이 도메인에서 지원하지 않는 언어이더라도 덮어쓰지 않고, 화면만 지원 언어로 그리도록 했다.
결론
미들웨어 패턴으로 언어 오염 문제를 해결하고, 통합된 브랜드 경험도 지킬 수 있었다.
이후 스프린트 회고 자리에서 이 해결 과정을 공유했는데, 6개 언어를 모두 지원하는 편이 더 좋은 경험일 것 같다는 의견이 나왔고 결국 모든 언어를 지원하게 되었다. 미지원 언어라는 전제 자체가 사라진 것이다.
그럼에도 미들웨어 로직은 그대로 두기로 했다. 메인 도메인에 새로운 언어 세트가 추가되면 같은 문제가 다시 생길 수 있기 때문이다.
느낀점
단순한 작업 같았지만 사용자 플로우가 새로 생기면서 예외 상황이 따라왔다. 이때 분기를 한곳에서 통제하는 미들웨어 패턴이 유용했다.
요구사항을 만족했는지만 볼 것이 아니라, 정말 고객 가치를 달성했는지를 함께 점검해야 한다는 것을 배웠다.
