추측형 게이트가 멀쩡한 워크로드를 죽인 나흘
"몇 달 잘 돌던 런을 다시 돌리면 안 잡힌다." 며칠을 헤맸습니다. 런이 requested 상태에 머문 채 아무 일도 안 일어났습니다. 에러 메시지가 단 한 줄도 없었습니다. 단서가 없으니 디버깅이 막혔습니다.
범인 — 추측성 사전 차단 게이트
며칠 전, 안정성을 높이려는 의도로 dispatch 경로에 사전 검사 게이트가 여럿 추가됐습니다. 그중 하나가 "이 런이 GPU 메모리를 얼마나 쓸지 미리 추측해서, 부족할 것 같으면 막는" 게이트였습니다.
도식 렌더링 중…
문제는 GPU 메모리를 사전에 정확히 계산할 수 없다는 것입니다. "카메라당 4GB" 같은 허구의 계수로 추정하니, 카메라 여러 대 런이 25.5GB로 추정돼 24GB 노드에서 조용히 걸러졌습니다. 막힌 이유를 알려주는 로그조차 없었습니다.
이건 fail-loud의 정반대다
이 사건의 본질은 silent fail의 한 종류 — 그것도 가장 교묘한 형태입니다.
⚠️ "실행 전 추측해서 미리 막기"는 안티패턴 — 검증된 원칙은 실행하고, 진짜 실패하면 시끄럽게 드러내는 것(fail-loud)입니다. 추측성 사전 차단은 그 반대입니다 — 일어나지도 않은 실패를 가정해 멀쩡한 걸 막고, 게다가 silent라 단서도 안 남깁니다. "추측 pre-block"은 "실측 fail-loud"의 정확한 반대말입니다.
고침 — 게이트를 없애다
해결은 그 추측 게이트를 제거하는 것이었습니다. 그러면 어떻게 OOM(메모리 부족)을 막느냐고요?
💡 진짜 실패를 분류하라 — 런을 실제로 시작하고, 진짜로 메모리가 부족하면 크래시가 납니다. 그 크래시를 OOM으로 분류해 fail-loud로 알리면 됩니다. 거대 워크로드는 큰 GPU 노드로 보내는 타게팅으로 피하고요. "추측해서 미리 막기"가 아니라 "실행하고 진짜 실패를 명확히 알리기"입니다.
게이트를 없애자, 며칠간 막혀 있던 런들이 즉시 다시 잡혔습니다.
교훈
- silent skip이 가장 비싸다 — grep할 단서조차 없애 디버깅을 며칠 막는다.
- 추측으로 실행을 막지 마라 — 검증 못 한 예측은 멀쩡한 걸 거부한다.
- 안정화 작업이 안정성을 깰 수 있다 — "게이트를 더 추가"하려던 선의가 회귀를 만들었다.
한 줄 정리
📌 며칠간 "옛 런이 안 돈다"의 근본은, 추측성 VRAM 게이트가 허구의 계수로 멀쩡한 런을 silent reject한 것이었다 — 에러 0. "실행 전 추측 차단"은 fail-loud의 정반대다. 게이트를 없애고 진짜 OOM을 분류해 알리는 방식으로 바꾸니 즉시 풀렸다.