고객이 MTR을 못 준다 — 그 다음 단계는 어떻게 짜야 하나

해외 사용자 비중이 큰 게임 서비스에서 지연 시간이 갑자기 튀었습니다. 평소 200~~300ms 수준이던 것이 **2,000~~3,000ms로 10배** 폭증했습니다. 새로운 L4 Proxy 도입 시점과 정확히 겹쳤다는 것이 고객측 인상이었습니다.

이런 상황에서 운영팀이 가져야 할 사고 흐름을 정리해봤습니다.

1차 가설 — “Proxy 노드가 문제”

가장 먼저 떠오르는 의심은 새 L4 Proxy 노드 자체였습니다. 그래서 노드측 메트릭부터 봤습니다.

노드는 깨끗했습니다. 그런데 사용자가 체감하는 지연은 폭증이었습니다. 그렇다면 문제 구간은 사용자 ↔ Proxy 노드 사이, 즉 공중망(Public Internet) 구간 이라는 결론이 나옵니다.

공중망 문제라는 가설을 입증하려면 사용자 단말에서 측정한 네트워크 데이터가 필요합니다. 가장 흔한 것이 MTR입니다.

mtr --report --report-cycles 100 -i 0.5 <노드 IP>

각 홉(hop)별 패킷 손실률·지연을 보여주니, 어디서 깨지는지 구간을 특정할 수 있습니다.

그래서 고객사에 요청했습니다.

여러 이유가 있습니다. 흔히는:

이것이 운영의 현실입니다. 측정 도구가 있어도 받아들 손이 없으면 못 씁니다.

이때 운영팀이 가지고 있는 카드는 두 가지입니다.

직접 MTR이 없어도 간접적인 신호는 있습니다.

이것을 모아서 “노드는 정상이고, 특정 지역의 공중망 경로가 악화됐다” 라고 합리적 결론에 이를 수 있습니다.

원인 입증과 별개로 사용자 체감을 회복하는 액션도 병행해야 합니다.

10배 폭증이던 것이 평상시 수준 + α 정도로 잦아드는 효과를 볼 수 있습니다.

이 케이스의 최종 결론은 고객측 공중망 경로 이슈였습니다. 노드 정상 + 우회 측정으로 특정 지역 손실 패턴 확인 → “제품 자체 결함은 없음, 사용 방식 또는 외부 네트워크 환경 영향” 으로 사유 분류했습니다.

이 결론은 단순히 “우리 잘못 아닙니다” 가 아닙니다. 정확하게는:

제품·서비스 측은 정상 동작 범위 안에 있고, 측정 가능한 우리측 메트릭에서 이상 없음. 다만 사용자 체감 회복을 위해 connection 재사용·라우팅 워밍 등 운영적 워크어라운드를 적용 중.

이렇게 적어두면, 비슷한 케이스가 또 왔을 때 누가 봐도 사고의 흐름을 따라갈 수 있습니다.

처음에는 “MTR 안 주면 어떻게 분석하나” 가 막막했습니다. 그런데 클라우드 운영을 하면서 점점 익숙해진 것이 — 외부에서 측정 데이터를 못 받는 상황이 사실 흔하다는 점입니다.

그래서 평소부터 자체 메트릭을 잘 모아두고, 간접 신호로 추론하는 훈련을 해두는 것이 중요합니다. 직접 데이터가 없어도 합리적인 결론에 이르는 능력 이 운영팀의 진짜 자산입니다.

다음에 비슷한 상황이 오면 카드를 더 일찍 꺼낼 수 있을 것 같습니다.