구매 링크 도메인을 설정값으로 분리해 운영팀 셀프 변경 실현

발단

파트너 포털에서 구매자에게 보내는 구매 링크 기능 점검하다가 이상한 걸 발견함. 도메인이 코드에 그냥 문자열로 박혀있었음. 스테이징/운영 환경이 다르고, 화이트라벨 파트너마다 노출 도메인이 갈리는데도 한 줄로 고정되어 있던 상황.

배포 환경이 늘어날 때마다 분기가 같이 늘어나는 구조였고, 신규 파트너 도메인 하나 붙이려면 코드 수정 + 재배포가 필요했음. 결국 운영팀에서 도메인 한 글자 바꾸겠다고 매번 개발팀을 호출하는 상황까지 오게 됨.

접근 방식

이미 환경 설정용 저장소가 있었고, 다른 운영 변수들도 거기서 읽고 있었음. 도메인 키 하나 추가해서 컨트롤러가 조회하도록 바꿨음.

• Before: 메서드 안에서 문자열 상수 반환
• After: 설정 저장소 조회 → 캐시 → 반환
• 폴백: 캐시/조회 실패 시 기본 도메인 (서비스 중단 방지)

링크 생성 요청
   ↓
도메인 설정 조회 (캐시 우선)
   ↓
프로토콜 + 도메인 + 경로 조합
   ↓
파트너 응답

막혔던 지점

단순 치환으로 끝날 줄 알았는데 캐시 무효화에서 한 번 걸림. 운영팀이 도메인을 바꿔도 캐시 TTL 만료 전까지는 옛 도메인이 그대로 나갔음. 설정 변경 시점에 해당 캐시 키를 명시적으로 비우는 훅을 추가해서 정리.

회고

외부에 노출되는 URL 은 하드코딩 순간부터 빚이 됨. 고객 응대 진입점이나 결제대행사 콜백처럼 환경/파트너별로 갈리는 값은 처음부터 설정으로 빼는 게 답이라는 걸 또 한 번 확인.

캐시는 도입할 때 무효화 경로까지 같이 설계해야 한다는 것도 다시 새겼음. 빠른 응답을 얻은 만큼 일관성 부담을 떠안는 거고, 그 부담을 운영자가 모르는 채로 굴러가면 결국 "왜 안 바뀌냐" 문의로 돌아옴.

작아 보이는 fix 였는데, 운영팀이 직접 만질 수 있는 영역이 한 칸 늘었다는 점에서 체감 효과가 컸음. 이런 류는 티켓 한 장이 줄어드는 게 아니라, 앞으로 생길 티켓 수십 장을 사전에 지운다는 의미.

다음