숨겨진 왕복 호출이 페일오버를 막고 있었다
멀티리전 아키텍처를 운영하다 보면 리전 장애 발생 시 빠른 페일오버가 핵심 요건이 된다. 그런데 실제 장애가 연속으로 발생하고 나서야, 팀은 페일오버 속도를 저해하는 원인이 외부 인프라가 아니라 클라이언트 세션 흐름 안에 수년째 숨어 있던 사전 탐색(pre-flight discovery) 호출이었음을 발견했다.
이 pre-flight 호출은 처음 설계 당시 "유일한 선택지"로 추가된 것이었다. 클라이언트가 실제 API 요청을 보내기 전에 엔드포인트 또는 라우팅 정보를 동적으로 조회하는 방식으로, 당시에는 합리적인 결정이었다. 문제는 이 호출이 매 클라이언트 세션마다 암묵적으로 수행되고 있었다는 점이고, 리전 장애 상황에서는 이 탐색 호출 자체가 실패하거나 지연되어 페일오버 전체가 블로킹되는 구조였다.
왜 이런 설계가 오래 살아남는가
이런 형태의 숨겨진 왕복(hidden round trip)이 장기간 발견되지 않는 이유는 명확하다. 평상시에는 문제가 드러나지 않기 때문이다. 모든 리전이 정상 동작하는 상황에서 수십 밀리초의 추가 지연은 모니터링 대시보드에서 노이즈로 묻힌다. 리뷰나 온콜 알럿에서도 "느리지만 동작하는" 케이스는 우선순위에서 밀리기 마련이다.
4년차 이상 개발자라면 익숙한 패턴이 있다. 초기 설계 결정이 "기술 부채"로 레이블링되지 않은 채 코드베이스에 녹아들면, 그것이 실제로 문제를 일으키기 전까지는 건드릴 이유를 찾기 어렵다. 특히 아래와 같이 매 세션마다 호출이 발생하는 구조는 트래픽이 많을수록 영향이 커진다.
// 세션 초기화 시 암묵적으로 수행되던 패턴 (단순화 예시)
public Session createSession() {
Endpoint endpoint = discoveryClient.fetchEndpoint(); // pre-flight 호출
return new Session(endpoint);
}
이 코드가 정상 환경에서는 무해하지만, discoveryClient가 장애 리전을 바라보는 순간 세션 생성 자체가 막히는 구조가 된다.
제거 작업이 실제로 수반하는 비용
pre-flight 호출을 제거하기로 결정한 이후, 팀은 단순한 코드 삭제가 아닌 상당한 설계 변경이 필요함을 알게 됐다. 엔드포인트 정보를 동적으로 가져오던 로직을 사전 구성(pre-configuration) 또는 캐싱 방식으로 전환해야 했고, 이는 클라이언트 라이브러리, 서버 사이드 라우팅 로직, 배포 파이프라인 전반에 걸친 수정을 의미했다.
롤아웃 과정에서도 비용이 발생했다. 기존 클라이언트와의 하위 호환성을 유지해야 했고, 점진적 배포(canary/blue-green) 중에 두 방식이 공존하는 기간 동안의 정합성 문제도 다뤄야 했다. 실무에서 "제거하면 되지 않나?"라고 생각하기 쉬운 변경이 실제로는 몇 배의 공수가 드는 작업이 되는 전형적인 사례다.
// 개선 후: 엔드포인트를 사전 설정으로 주입
public Session createSession(EndpointConfig config) {
return new Session(config.getPrimaryEndpoint());
// 페일오버는 별도 healthcheck/라우팅 레이어에서 처리
}
핵심은 페일오버 책임을 세션 초기화 경로에서 분리하는 것이다.
정리
- 멀티리전 페일오버 병목은 인프라보다 클라이언트 세션 흐름 내 숨겨진 네트워크 왕복에서 발생할 수 있다
- 초기 설계 시점의 "유일한 선택지"는 추후 아키텍처 제약이 되므로, 세션 생성 경로의 외부 의존성은 주기적으로 재검토해야 한다
- 숨겨진 round trip 제거는 코드 한 줄 수정이 아니라 설계·배포·호환성 전반의 비용을 수반한다는 점을 초기 계획에 반영해야 한다