문제는 단순했다. 평소엔 90ms이던 API가 12시 10분만 되면 1초를 넘겼다. 서버는 죽지 않았지만 고객은 기다렸다.
팀은 새 인프라를 들이기보다 요청이 어디서 밀리는지 먼저 봤다. Go 서비스의 장점은 이 분석을 코드와 운영 지표가 거의 같은 말로 설명해 준다는 점이었다.
사고 전후 숫자
원인은 과한 동시성이었다
외부 매장 시스템 호출이 느려질 때마다 내부 워커 수를 늘려 버리면서, 오히려 전체 큐 체류 시간이 길어졌다.
Go의 간결함은 여기서 힘을 발했다. channel 경로와 timeout 지점을 눈으로 빠르게 확인할 수 있었고, 합의도 빨랐다.
수정 원칙
- 동시성 수를 CPU가 아니라 외부 의존성 속도 기준으로 정한다.
- 모든 외부 호출은 timeout을 명시한다.
- 큐가 밀릴 때는 실패를 빨리 반환하고 재시도 정책을 분리한다.
운영팀이 남긴 문장
- Go의 장점은 빠름 자체보다 운영 구조를 단순하게 유지해 주는 데 있다.
- 지연 문제는 워커를 늘리는 방식으로는 자주 해결되지 않는다.
- 플랫폼 팀은 “몇 개를 동시에 돌릴지”를 코드 규칙으로 남겨야 한다.