멀티테넌시 파트너 요청에 시스템 컨텍스트를 서버에서 강제 보장

특정 호스트로 진입하는 트래픽에 대해 sysId를 강제로 주입하는 로직을 추가했다.

왜 이 작업이 필요했나

멀티테넌시 구조에서 파트너별로 시스템 컨텍스트를 구분하는 방식은 여러 가지가 있다. 쿼리 파라미터로 sysId를 넘기거나, 헤더에 담거나, 혹은 호스트(도메인) 자체로 판단하거나. 이번 케이스는 apple 호스트를 통해 /partner/** 경로로 들어오는 요청이라면 무조건 sysId=apple로 강제 override 해야 하는 상황이었다.

문제의 출발점은 간단했다. 해당 파트너 진입 경로에서 sysId가 누락되거나, 다른 값으로 들어오거나, 아예 전달 자체가 안 되는 케이스가 산발적으로 발생하고 있었다. 클라이언트 쪽에서 파라미터를 "항상 잘 보내줄 것"이라는 전제를 깔고 설계했을 때 생기는 고전적인 취약 지점이다. 파트너 연동에서 이런 전제는 거의 항상 깨진다.

결국 "호스트가 apple이고, /partner/** 하위로 진입하는 요청이라면, sysId는 무조건 apple이다"라는 규칙을 서버 레벨에서 보장하도록 했다.

구현 위치와 접근 방식

변경 파일은 utl 패키지 하위의 내부 클래스다. 전형적인 eGovFramework 기반 프로젝트 구조에서 utl은 유틸리티성 공통 처리 로직이 모이는 곳이다. 요청 컨텍스트 조작, 파라미터 가공, 공통 식별자 처리 같은 것들이 여기에 위치한다.

이 레이어에서 override를 처리하는 패턴은 대략 이런 모양이다.

// 요청 호스트 + 경로 조합으로 sysId 강제 주입 예시 (일반 패턴)
String host = request.getServerName();
String uri  = request.getRequestURI();

if (host.contains("apple") && uri.startsWith("/partner/")) {
    request.setAttribute("sysId", "apple");
    // 혹은 HttpServletRequestWrapper로 파라미터 override
}

직접 setAttribute로 처리하느냐, HttpServletRequestWrapper로 파라미터 자체를 덮어쓰느냐는 후속 로직이 어디서 sysId를 읽느냐에 따라 달라진다. 파라미터로 읽는 구조라면 Wrapper가 필요하고, attribute로 읽는 구조라면 setAttribute가 더 단순하다. 이 판단은 코드리뷰에서 짚어봐야 할 지점 중 하나였다.

이 변경이 가져오는 트레이드오프

이런 강제 override 방식은 명확한 장점이 있다.

반면 주의할 것도 있다.

• 암묵적 규칙 증가: 호스트 기반 override 규칙이 코드 곳곳에 흩어지면 나중에 온보딩한 팀원이 "왜 sysId가 자동으로 바뀌지?" 하고 혼란스러워할 수 있음
• 테스트 환경 분리: 로컬/스테이징에서 호스트가 달라지면 override가 안 타는 케이스가 생겨 실환경과 동작이 달라질 수 있음
• 규칙 확장 시 복잡도: 파트너가 늘어날수록 이 패턴을 어디에 어떻게 추가할지 명시적인 규약이 없으면 흩어짐

이 부분은 팀 내에서 "이 규칙은 어디에 선언한다"는 컨벤션을 만들어두는 게 장기적으로 훨씬 중요하다. 당장의 fix는 간단해도, 이런 규칙이 하나씩 쌓이면 결국 암묵지가 된다.

짧은 회고

파트너 연동에서 sysId 같은 컨텍스트 식별자는 항상 "누가 보장하는가"를 명확히 해야 한다. 클라이언트에게 맡기면 언젠가는 빠진다. 이번처럼 호스트 + 경로 조합으로 서버가 직접 보장하는 방식은 실용적인 선택이었다고 본다. 다만 이 패턴이 반복될 것이 예상되면 설정 기반으로 외부화하거나, 최소한 한 곳에 모아두는 구조를 미리 잡아두는 편이 낫다. 지금은 괜찮아 보여도, 세 번째 파트너쯤 되면 반드시 후회한다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.