리뷰어가 매번 실패를 반환하면
이날은 검증 루프의 무한 루프를 발견하고 고친 날이다.
리뷰어가 매번 실패를 반환하면 영원히 멈추지 않았다.
스톨 카운터가 “평결 없음”만 세고 “실패” 평결은 세지 않았기 때문이다.
그리고 캐시 적중이 절약이라는 믿음도 깨졌다.
캐시 적중은 손익분기점이었다.
검증 루프에 스톨 카운터가 있었다.
일정 횟수 이상 멈추면 루프를 종료한다.
안전장치였다.
근데 무한 루프에 빠졌다.
텔레메트리를 확인하니까, 리뷰어가 매 라운드마다 실패 평결을 내리고 있었다.
왜 스톨 카운터가 안 올랐는가
스톨 카운터는 “평결이 없는” 라운드만 센다.
근데 리뷰어가 매번 “실패” 평결을 내렸다.
평결이 있다.
그래서 스톨 카운터가 올라가지 않았다.
“평결 없음”과 “실패 평결”은 다르다.
스톨 카운터는 전자만 잡는다.
후자는 잡지 못한다.
리뷰어가 영원히 “실패”를 반환하면, 루프도 영원히 돈다.
리뷰어의 실패가 항상 옳은 건 아니다
리뷰어가 매번 실패를 반환한 이유를 확인했다.
실패의 내용이 전부 타당한 건 아니었다.
정당한 지적도 있었지만 범위 밖 요구도 있었다.
리뷰어가 “목표 범위 밖”을 요구하면서 실패를 반환한 거다.
해결: 분류 구조를 강제했다
리뷰어 피드백을 세 가지로 분류하도록 강제했다.
“수정할 것”은 타당한 결함이다.
“이의 제기”는 리뷰어가 틀렸거나 과장한 것이다.
“범위 밖”은 원래 목표에 없는 것이다.
리뷰어가 매번 실패를 반환해도, 이제 분류 구조를 채워야 한다.
“범위 밖”으로 분류된 건 무시된다.
“이의 제기”로 분류된 건 반박하면 된다.
“수정할 것”만 실제로 수정한다.
그리고 최대 반복 횟수를 안전망으로 둔다.
40번을 넘기면 강제 종료한다.
교착 상태 감지기를 따로 만들지 않는다.
단순한 안전망이 충분하다.
캐시 적중이 절약이라는 믿음이 깨졌다
프롬프트 캐시를 쓰면 비용이 절약된다고 생각했다.
캐시에 적중하면 입력 비용의 10%만 내니까. 근데 캐시를 “따뜻하게” 유지하려면 비용이 든다.
캐시 쓰기 프리미엄
캐시에 쓸 때 1.25배 프리미엄을 낸다.
일반 입력의 1.25배다.
5분 안에 다시 읽으면 0.1배로 읽는다.
5분 안에 안 읽으면 다시 전체를 쓴다.
20분 동안 캐시를 유지하려면 4분마다 다시 써야 한다.
4번 쓰고 4번 읽는다.
쓰기 4번 × 1.25배 + 읽기 4번 × 0.1배 = 계산해보면 절약이 된다.
근데 이건 “캐시를 유지하는” 비용이다.
“캐시를 안 유지하고 매번 새로 쓰는” 비용과 비교해야 한다.
사서 에이전트의 캐시 적중은 손익분기점이다
지속적인 사서 컨텍스트를 유지하면 캐시가 따뜻하다.
근데 변경분을 쓸 때 1.25배 프리미엄을 낸다.
반면 매번 새로 고침하면 1.0배로 쓴다.
변경분만 놓고 보면, 지속 경로가 더 비싸다.
캐시 적중 절약은 손익분기점이다.
진짜 절약은 “재주입 회피”와 “품질(중복 제거, 연속성)“에서 온다.
스크래치패드가 충분하다
비싼 인프라를 만들 필요가 없다.
몇 킬로바이트짜리 요약 파일을 읽고 완료하면 갱신한다.
이 스크래치패드가 캐시의 이점의 대부분을 5% 비용으로 잡는다.
인프라도, 생명주기 관리도 필요 없다.
도구 비활성화가 서브에이전트에서 안 통한다
도구 비활성화 확장이 있었다.
에이전트별로 특정 도구를 차단한다.
정적 분석에서 “작동하지 않을 수 있다”고 경고가 나왔다.
경험적으로 확인했다
리뷰어 서브에이전트를 파견했다.
“비활성화된” 도구를 사용하라고 지시했다.
차단이 발동하지 않았다.
서브에이전트에서 도구 비활성화는 신뢰할 수 없다.
보안 경계로 쓰면 안 된다
도구 비활성화가 확률적으로 작동하면 안전 경계로 부족하다.
“보통은 차단된다”가 아니라 “항상 차단된다”가 필요하다.
보안 경계는 강제여야 한다.
해결은 네이티브 권한 시스템으로 이동하는 거다.
가시성 허용 목록과 정책(허용/확인/거부)의 2계층 모델을 쓴다.
확장에 의존하지 않고 시스템 수준에서 강제한다.
401이 인증 실패가 아닐 수 있다
서브에이전트 포크에서 401 인증 에러가 났다.
인증 키를 바꿔도 같았다.
메인 세션은 정상이었다.
원인은 인증이 아니었다.
현재 요금제가 해당 모델을 256킬로토큰까지만 지원했다.
그 이상을 보내면 401을 반환한다.
근데 응답 본문에 요금제 메시지가 들어 있다.
에러 코드로 원인을 가정하지 마라
401은 “인증 실패”다.
근데 이 경우에는 “요금제 한계”였다.
에러 코드가 원인을 완전히 설명하지 않는다.
응답 본문을 읽어야 진짜 원인을 안다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날의 핵심은 “분류하고 검증하라”였다.
리뷰어의 실패를 전부 같은 취급하면 무한 루프에 빠진다.
“타당한 지적”, “틀린 지적”, “범위 밖”을 분류해야 한다.
분류하지 않으면, 범위 밖 요구가 루프를 영원히 돌린다.
캐시 적중도 분류가 필요하다.
“캐시 적중 = 절약”이라는 단순한 믿음이 깨졌다.
쓰기 프리미엄과 읽기 할인을 정확히 계산해야 한다.
캐시가 항상 절약인 건 아니다.
도구 비활성화도 경험적으로 검증해야 한다.
정적으로 “작동한다”고 보이더라도, 실제로 서브에이전트에서 발동하는지 확인해야 한다.
보안 경계는 경험적 검증으로 확정해야 한다.
그리고 에러 코드로 원인을 가정하지 마라. 401이 항상 인증 실패는 아니다.
응답 본문을 읽어라.