구글이 침묵 오류를 잡는 방식은 더 정교한 로깅이 아니었다. 이상한 스텝을 그냥 한 번 더 돌리는 것이었다. 같은 답이 나오면 데이터 문제, 다른 답이 나오면 칩 문제. 이 단순한 이분법이 강력한 이유는, 재실행이 “결정론”이라는 축을 하나 추가해 원인 공간을 절반으로 잘라내기 때문이다.
근거
로그는 시스템이 스스로 이상하다고 인지한 것만 기록한다. 침묵 오류는 정의상 그 인지를 통과해버리므로, 로그를 아무리 두껍게 쌓아도 잡히지 않는다. 반면 재실행은 시스템의 자기보고에 의존하지 않고 결과를 두 번 관측한다.
층마다 그래디언트를 감시하다가 튀는 값이 보이면 그 스텝을 자동으로 다시 돌림. 같은 답이 나오면 데이터 탓, 다른 답이 나오면 칩이 범인임.
이 구조는 두 부분으로 나뉜다. 앞단의 그래디언트 감시는 어디를 다시 볼지 고르는 저비용 트리거이고, 뒷단의 재실행은 원인을 확정하는 고비용 판별기다. 전수 이중 실행은 비용이 두 배지만, 트리거로 후보를 좁히면 비용은 무시할 수준이 된다.
LLM 작업에도 그대로 옮겨진다. 같은 프롬프트를 두 번 돌려 답이 갈리면 모델의 비결정성 문제이고, 일관되게 같은 오답이 나오면 프롬프트나 컨텍스트 설계의 문제다. 나는 그동안 이상한 출력을 만나면 프롬프트부터 고쳤는데, 순서가 틀렸다. 고치기 전에 한 번 더 돌려서 원인 축부터 확정해야 한다.
연결된 생각
- 20260810-silent-data-corruption-in-large-scale-training — 이 진단 절차가 나온 원래 문제
- 20260718-self-correcting-ai-loop-architecture — 감지-검증-교정을 루프로 구조화한 상위 패턴
- 20260609-validation-gate-is-key-to-agent-reliability — 검증 루프가 감각적 튜닝을 대체한다는 같은 논지