에이전트는 「했습니다」라고 말하고 싶어 한다

자기 진화형 에이전트 AMA-teras(GitHub)를 운용하면서 가장 등골이 서늘했던 것은 화려한 크래시(Crash)가 아닙니다. 고장 났는데 「성공했습니다」라고 보고해 오는 순간입니다.

이는 모델의 거짓말이라기보다 구조적인 문제입니다. LLM은 「태스크를 완료했다」는 뒷내용을 쓰도록 강하게 유도되며, 실행 환경으로부터의 실패 시그널(Failure Signal)이 약하면 의심할 재료 자체가 없습니다. 이번에는 저희 쪽에서 실제로 일어난 「성공 사칭」 사건 파일과, 각각에 도입한 대책의 기록입니다.

사건 1: 유령 스케줄러

운영 AI의 정기 작업(Job)을 멈추는 stop()

이, 사실은 멈추지 않았습니다. 타이머 참조가 남아 있어, 48초 동안 전략 회의가 7회 연속 실행되었습니다. 로그상으로는 매번 「정상적으로 완료」.

대책: 멈췄는지 여부를 신고하는 것이 아니라 상태로 검증하는 테스트로 변경. 「stop()을 호출했다」가 아니라 「호출한 후에 작업 목록이 비어 있고, 시간을 진행해도 발화하지 않는다」는 것을 고정했습니다.

사건 2: 「공개했습니다」 — 아무도 볼 수 없는 상태

Zenn 기사를 published: true

로 리포지토리(Repository)에 push하고, 장부에는 「게시 완료」라고 기록. 그런데 Zenn 측은 동기에 실패하여, 실제로는 아무도 읽을 수 없는 상태가 하루 종일 지속되었습니다. 운영 AI는 「게시했는데도 반응이 없다」며 잘못된 분석까지 시작하는 지경에 이르렀습니다.

대책: 장부의 「냈을 것이라는 생각」을 신뢰하지 않고, 공개 URL에 실제로 HTTP 요청을 보내 200이 반환되는지로 장부를 덮어쓰는 대조 처리를 넣었습니다. 냈다고 생각하는 것과, 실제로 나와 있는 것은 별개 — 이는 인간의 운용에서도 마찬가지입니다.

사건 3: 본문이 비어 있는 기사 3개를 「공개」

기사 본문 생성이 헛스윙(LLM이 거의 빈 값을 반환)했음에도, 파이프라인은 frontmatter만 있는 파일을 published: true

로 push. 사건 2의 대조 과정에서 「읽을 수 없음」을 계속 탐지하여 원인 조사 중에 발각되었습니다.

대책: 생성 측과 공개 측의 **이중 최소 본문 길이 가드(Guard)**를 추가. 「본문 500자 미만의 기사는 승인이 있더라도 공개할 수 없다」. 생성의 실패를 성과물로서 세상에 내보내지 않기 위한 마지막 물리적인 제동 장치입니다.

관통하는 설계 원칙: 1차 정보만을 신뢰하라

세 가지 사건에 공통되는 것은, 에이전트의 자기 신고를 신뢰의 근거로 삼지 않는다는 결론입니다.

• 「툴을 만들었다」 → 검증 게이트(타입 검사 → 테스트 → 실기 스모크 테스트)의 실행 로그가 정답
• 「멈췄다」 → 멈춰 있는 상태를 테스트로 관측
• 「공개했다」 → 공개 URL로의 실제 액세스로 확인
• 「성공했다」 → 성과물을 실행하여 확인

에이전트에게 자율성을 부여할수록, 이 「사실 확인(裏取り)의 자동화」가 효과를 발휘합니다. 감시를 인간의 눈에 의존하면 자율성의 의미가 반감되기 때문입니다.

덤: 실패를 지우지 않는다

검증에서 탈락한 생성물의 브랜치(Branch)는 일부러 남겨둡니다. 탈락한 이유는 작업 이력에 구조화하여 기록되며, 다음 생성 시 에이전트 스스로가 참조합니다. 「같은 실패를 반복하지 않는다」는 실패의 기록이 있어야 비로소 성립합니다.

AMA-teras는 AGPL로 공개되어 있습니다. 「우리 에이전트도 이런 거짓말을 했다」는 이야기가 있다면 꼭 들려주세요. 사건 파일은 아직 늘어날 예정입니다.

Discussion