루프가 멈춘다, 원인은 4개다
이날은 같은 증상의 4개 독립 원인을 추적한 날이다.
자율 검증 루프가 반복적으로 멈췄다.
원인을 하나씩 추적하니 4개의 독립된 근본 원인이 있었다.
전부 다른 계층에 있었다.
그리고 디자인 검토자가 핵심 도구를 9번 중 0번 호출한 것도 발견했다.
자율 검증 루프가 반복적으로 멈췄다.
일시정지 상태로 빠지는 거다.
같은 증상이 반복됐는데, 원인을 추적하니 4개의 독립된 근본 원인이 있었다.
첫째, 상태 동기화 문제였다.
todo 카운터가 실제 저장소랑 어긋났다.
실패 처리를 하면 카운터만 리셋하고 저장소는 남겨둬서 2차 수정에서 재사용된 todo가 “0개 생성됨”으로 보였다.
그래서 검증자가 안 배정됐다.
둘째, 타이머 가드 문제였다.
무활동 가드가 “대기 중인 액션이 발사 못 한 상태”를 “루프 포기”로 오판했다.
코드는 주석과 달리 idle 검사를 안 하고 있었다.
셋째, 코어 동시성 문제였다.
체크와 실행 사이에 await 경계가 있어서 그 갭에 외부 트리거가 상태를 뒤집으면 메시지가 잘못 라우팅됐다.
확장 수준에서 완전히 닫을 수 없는 race였다.
넷째, 인프라 실패였다.
검증자 중 일부가 429 에러로 결과 파일을 안 만들면, 판단을 못 하고 멈췄다.
같은 증상에 4개의 다른 계층
핵심은 4개가 전부 다른 계층에 있었다는 거다.
상태 동기화, 타이머 가드, 코어 동시성, 인프라. 같은 증상(루프 멈춤)이 4개의 독립된 원인이 있었다.
이걸 “원인을 찾았다”고 하나만 고치면 나머지 3개가 남는다.
같은 증상이 반복되면, 같은 원인이 아니라 다른 원인일 수 있다.
하나를 고치고 “해결됐다”고 단정하면 안 된다.
디자인 검토자가 도구를 안 부른다
디자인 검토자 서브에이전트의 9번의 실행을 전수 분석했다.
핵심 측정 도구를 9번 중 0번 호출했다.
전부 눈대중으로 판단했다.
프롬프트에는 “반드시 이 도구를 써라”라고 강제어가 있었다.
근데 강제어가 도구 호출 자체가 아니라 “스킬을 로드하고 루프를 따르라”는 간접 위임에만 붙어 있었다.
모델이 스킬을 얕게 읽고 회피한 거다.
강제성은 행위에 직접
해결은 강제어를 도구 호출 지점에 직접 붙이는 거였다.
“호출 없으면 무조건 실패”를 에이전트 정의에 넣었다.
간접 위임이 아니라 직접 행위에 강제성을 붙인 거다.
이게 핵심 교훈이다.
강제어는 가능한 한 호출 지점에 가까워야 모델이 회피하지 못한다.
“스킬을 읽고 따르라”는 간접 지시로는 충분하지 않다.
모델이 스킬을 안 읽거나 얕게 읽으면 강제성이 무력화된다.
조용한 저하가 가장 위험하다
이날 발견한 여러 문제가 전부 “조용한 저하” 패턴이었다.
에이전트 확장 경로가 버전업으로 바뀌면, 서브에이전트가 해당 도구를 조용히 잃는다.
에러 없이 기능이 빠진 채로 실행된다.
스킬 디렉토리 이름이 스킬 참조랑 안 맞으면, 스킬이 안 발견된다.
근데 에러가 안 난다.
그냥 “스킬이 없다”로 처리된다.
완료 가드가 읽기 전용 에이전트를 오탐한다.
정상적으로 계획을 만들어도 “편집 0건”으로 실패 처리된다.
에이전트는 자기 일을 잘 했는데, 가드가 잘못 판단한 거다.
조용한 저하를 잡으려면
에러가 안 나니까 발견이 늦다.
“안 되는 거 같은데”라는 막연한 느낌에서 시작해서 전수 분석으로 0건 호출을 발견한다.
조용한 저하를 잡으려면, “실행됐을 것이라고 믿는 것”을 직접 확인해야 한다.
도구를 호출했는지, 스킬이 발견됐는지, 가드가 올바르게 판정했는지. 믿음을 확인으로 바꿔야 한다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날의 교훈은 세 가지다.
첫째, 같은 증상에 여러 원인이 있을 수 있다.
하나를 고치고 “해결”이라고 하지 마라. 다른 원인이 남아있을 수 있다.
둘째, 강제성은 행위에 직접 붙여라. 간접 위임으로는 모델이 회피한다.
도구 호출 지점에 강제성을 붙여야 회피할 수 없다.
셋째, 조용한 저하가 가장 위험하다.
에러 없이 기능이 빠지면 발견이 늦어진다.
“실행됐을 것”이라는 믿음을 직접 확인으로 바꿔야 한다.