에이전트의 자신감 넘치는 오답이 로그에 안 찍히는 이유: 복합 실패 패턴

와, 진짜 공감되네. 나도 비슷한 문제 겪었는데, 에이전트가 검증 단계를 아예 건너뛰고 SQL 쿼리 결과가 성공했다고 환각을 일으키더라고. 체인이 그냥 자기 갈 길을 행복하게 계속 가버릴 때, 우리가 얼마나 로그의 오류 기록에 의존하고 있었는지 깨닫게 됨.

SQL 검증 건너뛰는 건 완벽한 예시지. 오류도 없고 트레이스상 모순도 없는데, 그냥 에이전트가 잘못된 데이터를 가지고 자신 있게 계속 진행하는 거니까. 이런 패턴이 프로덕션에서 제일 비용이 많이 드는 이유가, 하위 시스템에서 뭔가 터지기 전까지는 아무도 눈치를 못 채기 때문임.

혹시 그 트레이스를 탐지기에 돌려보고 싶으면, 내가 이걸 위해 특별히 만든 도구가 있음: https://6jovkucbyygcamzbeksa67.streamlit.app

맞음. 이게 진짜 무서운 유형인 게, 트레이스 관점에서는 '실패'한 게 하나도 없거든.

내 생각엔 빠진 게 로그가 아니라 '기대 행동 불변성(expected-action invariant)'인 것 같음. 작업이 예약, 결제, DB 쓰기, 티켓 업데이트 등을 요구한다면, 실행 기록에 그 작업이 실제로 일어났는지 증거와 함께 남겨야 함.

이게 바로 가드 레이어가 단순히 독성 텍스트나 나쁜 프롬프트를 점수 매기는 것 이상을 해야 하는 이유임. 가드 레이어는 '어떤 전환이 주장되고 있는가?', '어떤 도구 증거가 이를 뒷받침하는가?', '영향 범위는 어디까지인가?'를 질문해야 함.

확실히 그 불변성 체크가 있으면 골치 아픈 일을 많이 줄일 수 있을 듯. 많은 시스템이 결과를 검증하지도 않고 그냥 다 잘 됐겠거니 가정하는 게 참 신기함. 탄탄한 가드 레이어가 있으면 그런 침묵의 실패들이 걷잡을 수 없이 커지기 전에 확실히 잡아낼 수 있을 거야.