이 문제는 await를 더 붙인다고 해결되지 않습니다. 문제의 본질은 상태를 확인하는 동작과 상태를 변경하는 동작이 하나의 원자적(atomic) 연산으로 묶여 있지 않다는 점에 있습니다. asyncio 환경에서는 await 지점마다 제어권이 이벤트 루프로 돌아가고, 그사이에 다른 코루틴(coroutine)이 실행될 수 있습니다. 즉, is_pod_available()와 assign_request() 사이에는 다른 요청이 끼어들 수 있는 여지가 항상 존재합니다.

용이는 이 로직을 라운드 로빈이라고 생각했습니다. 하지만 실제로는 라운드 로빈의 전제와 상태 기반 분배의 전제가 모두 끝까지 지켜지지 않은 채 섞여 있었습니다. 이것이 이 코드의 논리 오류였습니다. 문법의 문제도 아니고, 단순한 구현 실수도 아니었습니다. 비동기 시스템에서의 실행 순서와 타이밍을 동기 코드처럼 이해한 것이 특정 파드에 요청이 몰리는 현상의 근본 원인이었습니다.