14시간 세션, 490번 반복
이날은 검증 루프가 490번 반복한 원인을 찾고 고친 날이다.
원인은 검증자 프롬프트를 “교체”해서 맥락이 날아간 거였다.
해결은 “확장”으로 바꾸는 거였다.
교체가 아니라 확장. 이 원칙이 핵심이었다.
하나의 pi 세션이 14시간 동안 돌았다.
그중 검증 루프가 약 490번 반복했다.
무의미하게 같은 걸 반복한 거다.
처음에는 “전체가 무의미했다”고 생각하기 쉽다.
근데 3축 증거 분석을 해보니 이분형 구조였다.
14시간 중 약 10시간은 생산적이었다.
뒤의 4시간이 폭주였다.
폭주 로그만 보면 생산적 단계를 놓친다.
원인: 검증자가 안 돌았다
스폰 예산(40)을 초과해서 검증자가 실제로 안 돌았다.
근데 검증 결과가 없으면 “실패”로 판단한다.
검증자가 안 돌았는데 “제출 안 함”이라는 거짓 실패가 나온 거다.
그리고 에이전트가 수백 번 “기계적 수렴 불가능, 사용자 개입 필요”라고 선언했다.
근데 stall-recovery가 이 탈출 신호를 무시하고 계속 “계속해”라고 재프롬프트했다.
더 깊은 원인: 프롬프트를 교체했다
더 깊은 원인은 검증자 디스패치 코드에 있었다.
검증자 프롬프트를 할당할 때 message = prompt로 교체하고 있었다.
메인 에이전트의 라운드별 요청이 통째로 날아간 거다.
“교체”가 문제였다.
메인 에이전트가 “이번 라운드에서 이걸 확인해줘”라고 보낸 요청이, 검증자 프롬프트로 교체되면서 사라졌다.
검증자는 뭘 확인해야 하는지 모르는 상태에서 돌아간 거다.
교체가 아니라 확장이다
해결은 “교체”를 “확장”으로 바꾸는 거였다.
검증자 프롬프트를 정적 헤더 + 이전 검증 피드백 + 작업자 요청으로 분리해서 조립한다.
각 부분을 개별적으로 유지하면서 합친다.
메인 에이전트의 요청을 버리지 않고 확장하는 거다.
이건 일반적인 설계 원칙이다.
“A를 B로 교체”가 아니라 “A에 B를 추가”. 맥락을 버리면 정보가 손실된다.
맥락을 유지하면서 새 정보를 추가해야 한다.
orca 전면 폐기
Orca IDE를 전면 폐기했다.
5단계로 진행했다.
첫째, 9개 관련 항목을 인벤토리했다.
전역 스킬 3개, 확장 3개, 심볼릭 링크, 애플리케이션. 둘째, macOS 시스템 추적으로 전체 발자국을 찾았다.
라이브러리 10곳, launchd, 헬퍼 데몬. 셋째, 전부 정리했다.
넷째, 바이트 퍼펙트 복원. 이전 커밋에서 파일을 꺼내서 블롭 해시로 교차 검증했다.
다섯째, orca CLI 자체는 검증 루프 멈춤 감지용 진단 도구로 보존했다.
복원의 함정
복원한 추적되지 않은 파일의 git diff는 “삭제”로 나온다.
이건 함정이다.
실제로는 복원한 건데, git은 추적하지 않으니까 “삭제”로 보인다.
복원 후에는 반드시 git add로 추적을 다시 설정해야 한다.
법원경매 에이전트 3개에서 1개로
법원경매 서비스의 분석 에이전트를 3개에서 1개로 통합했다.
권리 분석, 리스크 평가, 조언 에이전트가 따로 있었다.
근데 리스크 에이전트가 권리 맥락을 못 봤다.
구조적 맹점이었다.
권리를 분석한 에이전트의 결과를 리스크 에이전트가 못 보니까, 리스크 평가가 정확할 수가 없었다.
결정론은 LLM 밖에, 판단은 LLM 안에
해결 원칙은 “결정론적 계산은 LLM 밖에 두고, 판단만 LLM에 맡긴다”였다.
권리 분석, 리스크 평가, 조언을 하나의 에이전트로 통합했다.
호출이 3분의 1로 줄었다.
중복 채점이 사라졌다.
그리고 10건 중 10건 분석 성공.
전문가 분할 정당성 테스트
에이전트를 분할하려면 정당성이 필요하다.
“역할이 다르니까 분할한다”가 아니라, “분할하지 않으면 구조적 맹점이 생긴다”는 증거가 있어야 한다.
리스크 에이전트가 권리 맥락을 못 보는 건 구조적 맹점이었지만 분할이 해결책이 아니었다.
통합이 해결책이었다.
파이프라인을 코드로
법원경매 배치 파이프라인을 리팩터했다.
기존에는 스케줄러 설정에 의존했다.
근데 설정을 까먹으면 단계가 빠진다.
실제로 “가격 단계를 깜빡한” 사고가 있었다.
해결은 파이프라인을 코드로 명시하는 거다.
순서가 코드에 적혀 있다.
설정을 까먹을 수 없다.
“설정에 의존하는 단계”가 “코드에 명시된 단계”로 바뀐다.
마무리
이날의 핵심은 “교체가 아니라 확장”이었다.
검증자 프롬프트를 교체해서 맥락이 날아갔다.
490번 반복의 원인이었다.
확장으로 바꾸니까 맥락이 유지되고 반복이 멈췄다.
이건 프롬프트뿐 아니라 모든 설계에 해당한다.
“기존 것을 버리고 새 것으로 교체”가 아니라, “기존 것을 유지하면서 새 것을 추가”. 정보 손실 없이 확장하는 게 올바른 설계다.
그리고 에이전트 분할에도 같은 원칙이 적용된다.
“역할이 다르니까 분할”이 아니라, “통합하면 더 정확하면 통합”.
분할의 정당성을 테스트해야 한다.
맥락이 단절되는 분할은 맹점을 만든다.