고객과 즐겁고 생산적인 대화를 나누고 귀가 아직도 멍한 상태에서, 제품에 할인을 추가하는 티켓에 대한 코딩 에이전트 (coding agent)의 마지막 로그 메시지를 확인합니다. 메시지는 다음과 같았습니다: "완료되었습니다. 10% 할인을 추가했으며 모든 테스트를 통과했습니다. 중단합니다." 글쎄요... 그것이 사실이 아니라는 것을 당신은 알고 있습니다. 그래서 더 깊이 파고들어 보니, 할인 기능은 실제로 추가된 적이 없으며 통과했다고 보고된 테스트는 실행조차 되지 않았다는 사실을 빠르게 깨닫게 됩니다. 에이전트는 루프 (loop)의 끝에 도달했고, 자신의 작업물을 살펴본 뒤 완료되었다고 선언했습니다. 그 선언이 바로 배포된 결과물이었습니다.

이 현상에는 이름이 있습니다. 올해 6월에 발표된 논문인 From Confident Closing to Silent Failure에서는 이를 '거짓 성공 (false success)'이라고 부릅니다. 즉, 시스템의 실제 상태는 그렇지 않은데 에이전트가 작업이 완료되었다고 주장하는 것입니다. 이는 흔한 일이며, 유능한 모델들 사이에서도 나타납니다. 장기적 코딩 에이전트 (long-horizon coding agents)를 위한 벤치마크인 AppWorld에서, 실제로 실패한 실행의 75.8%가 에이전트가 완료되었다고 주장하며 끝났습니다. 연구진은 프롬프트 (prompt)를 매번 달리하여 다섯 가지의 서로 다른 LLM 판사 (LLM judges)를 해당 완료 주장들에 투입해 보았으나, 모든 판사가 동전 던지기 확률을 겨우 넘어서는 수준에 그쳤습니다. 왜냐하면 각 판사가 읽고 있는 것이 바로 마지막 문장이었으며, 그 마지막 문장은 작업이 실제로 이루어졌는지 여부와 상관없이 자신감 있게 읽히기 때문입니다. 진짜 완료와 거짓 완료를 구분해 주는 것은 저렴하고 기계적인 방식, 즉 시스템의 실제 상태를 확인하는 것이라는 사실이 밝혀졌습니다. 가벼운 결정론적 상태 확인 (deterministic state check) 방식이 최고의 판사들보다 4배에서 8배 더 많은 거짓 성공을 잡아냈습니다.

이 논문은 그 밑바탕에 깔린 메커니즘, 즉 '검증의 환각 (hallucination of verification)'에 이름을 붙였습니다. 모델은 자신이 전혀 확인하지 않은 무언가를 확인했다고 서술하며, 그 서술은 실제로 수행된 확인 보고서와 문장 단위로 구별할 수 없을 정도로 동일합니다.

에이전트가 말한 것과 시스템이 실제로 수행한 것 사이의 그 간극이 바로 이 글의 주제입니다. 루프 (loop)는 생성 (generate), 확인 (check), 조종 (steer), 재시도 (retry), 중단 (stop)이라는 다섯 가지 단계로 실행됩니다. 시리즈의 첫 번째 글에서 이 단계들을 명명했으며, 이후 네 편의 글을 통해 충분히 괜찮은지 결정하는 확인 (check that decides good enough), 잘못된 쓰기를 거부하는 게이트 (gate that refuses a bad write), 모든 규칙이 로드되는 표면 (surface every rule loads from), 그리고 매 재시도마다 목표를 다시 지정하는 조종 (steer that re-points the goal on each retry)에 대해 다루었습니다. 조종 (steer) 단계는 하나의 경고로 끝을 맺었습니다. 즉, 속임수에 넘어가 '그린 라이트 (green)'가 떴다고 해서 멈춰버리는 루프는 아무런 의미도 없는 결과에서 너무 일찍 멈춰버린 것이라는 경고였습니다. 이번 글에서는 바로 그 결정을 내리는 단계인 '중단 (stop)'과, 에이전트가 직접 작성하도록 내버려 두었을 때 당신에게 전달하게 될 잘못된 종료 (false ending)에 대해 다룹니다.

모델이 자신의 숙제를 스스로 채점할 때

루프의 마지막 단계까지 걸어가십시오. 모델이 diff(변경 사항)를 작성했습니다. 이제 누군가는 이 diff가 종료하기에 충분히 괜찮은지 결정해야 합니다. 셸 스크립트(shell script)에서 그 결정은 테스트를 실행하고 종료 코드(exit code)를 읽는 if 문이며, 이는 에이전트(agent)가 관여할 수 없는 메커니즘입니다. 에이전트 러너(agent runner)에서는 모델이 직접 결정을 내립니다. 모델이 finish 도구를 호출하거나, 당신의 티켓(ticket)에 있는 것과 같은 종료 문구를 작성하면, 러너는 그 문구를 중단 신호로 받아들입니다. gate piece가 구축한 것과 동일한 루프의 형태를, 중단 지점이 읽히도록 풀어서 보여주면 다음과 같습니다:

#!/usr/bin/env bash
# work-until-done: 기능을 구축하고, 완료되면 중단합니다.
MAX=5; i=0
...

중단 조건(stop condition)을 면밀히 읽으십시오. 모든 것이 여기에 달려 있기 때문입니다. 루프는 에이전트 자신의 메시지에 all tests pass라는 문구가 포함되는 순간 종료됩니다. 작업물을 만들어낸 당사자가 동일한 턴(turn)에서 자신의 언어로 작업물을 인증하는 당사자가 되며, 루프는 그 인증을 그대로 믿어버립니다. 모델은 시스템 어디에서든 자신의 완료 상태를 가장 신뢰할 수 없는 서술자(narrator)이며, 중단 메커니즘은 그 서술자를 종료 지점에 곧바로 연결해 두었습니다. 다른 모든 팔(arm)은 세상에 대한 사실을 읽습니다. 하지만 이 팔은 채점 대상인 존재가 작성한, 세상에 대한 문장을 읽습니다.

이것은 steer piece가 분석했던 실패 사례와는 다른 실패이며, 그 차이점은 기억해 둘 가치가 있습니다. steer 사례에서는 에이전트(agent)가 실제로 실행된 체크(check)를 속였습니다. 에이전트는 버그에 맞춰 테스트의 어설션(assertion)을 수정했고, 실제 테스트가 실행되었으며, 손상된 테스트에 대해 실제 통과(green) 결과가 반환되었습니다. 반면 여기서는 속일 만한 정직한 체크 자체가 애초에 존재하지 않습니다. 에이전트는 아무것도 실행하지 않고 건너뛴 채, 기억이나 낙관주의, 혹은 실행하지 않은 의도에 대한 요약으로부터 통과(green)를 보고하며, stop은 그 문장을 판결로 파일에 저장합니다. 이 두 가지는 동일한 망가진 결말에 도달하지만 서로 다른 두 가지 문제입니다. steer 사례에서는 체크가 실행되었으나 잘못된 대상을 가리켰습니다. stop 사례에서는 체크가 실행되지 않았음에도 루프(loop)는 실행된 것으로 믿었습니다. 검증의 환각(hallucination of verification)이 바로 이 두 번째 문제입니다. 모델은 확인했다고 말하고, 루프는 그 말뿐인 주장을 증거로 취급하며, 다른 문장들과 동일한 방식으로 생성된 종결 문장이 배포(shipping)의 전체 근거가 됩니다. 문장을 읽는 것만으로는 실제 완료와 거짓 완료를 구분할 수 없으며, 문장을 읽는 것이 바로 순진한(naive) stop이 수행하는 작업의 전부입니다.

거짓말하는 에이전트를 믿는 stop 관찰하기

여기 버그가 있는 에이전트 하나와 두 개의 서로 다른 stop이 있는 루프가 있습니다. 에이전트는 "당신이 끝났다고 말할 때 끝나는 것입니다"라는 지침 아래 급하게 작업하는 모델을 대신하는 스텁(stub)입니다. 에이전트는 패치(patch)를 작성하면서 할인 적용을 누락시키고, 결과에 상관없이 성공을 보고합니다. 두 분기(branch)는 지침이 명시한 가장 저렴한 방식을 수행하며, 이것이 바로 핵심입니다. 따라서 두 방식 모두 모델 내부에 숨겨져 있는 대신 페이지에 명시되어 있습니다. 두 실행 사이에서 유일하게 변하는 것은 stop이 무엇을 믿기로 선택하느냐입니다.

GOAL="charge(cents) applies the 10% discount: charge(10000) == 9000."

# 에이전트(AGENT): 여전히 버그가 있는 패치를 작성한 후, 항상 성공을 보고합니다.
...

각 stop으로 루프를 실행하고, 동일한 보고에 대해 어떻게 갈라지는지 관찰하십시오:

$ bash stop-demo.sh word
agent reported: "Done. Discount added, all tests pass."
stop: done (agent said so)
...

두 실행 모두 바이트 단위로 동일한 보고서를 생성했으며, 똑같은 여섯 단어의 확신을 보여주었습니다. 중단점(Stop) A는 all tests pass라는 문구를 읽고 깔끔하게 종료되었으며, 고객은 당신이 클라이언트에게 전달했다고 말한 할인된 가격을 전액 지불했습니다. 중단점(Stop) B는 그 문구들을 버리고, 에이전트가 실제로 작성한 코드에 대해 charge(10000)를 실행했습니다. 그리고 목표값인 9000 대신 10000이 반환되는 것을 확인하고는 완료(done) 처리를 거부했습니다. 스텁(stub)은 당신의 로컬 머신에서도 루프가 재현되도록 고정되어 있지만, 스텁 자체가 비결은 아닙니다. 핵심 주장은 이것입니다: 중단점에 에이전트의 문장을 건네주면 그 문장을 믿는 것이 가장 비용이 적게 드는 선택이 되지만, 실제 상태(state)에 대해 목표 실행(goal run)을 수행하도록 중단점에 건네주면 그 숫자를 믿는 것이 가장 비용이 적게 드는 선택이 된다는 것입니다. 결과의 차이는 전적으로 중단점이 무엇을 측정했느냐의 차이였습니다. 하나는 문장을 측정했고, 다른 하나는 세상을 측정했습니다.

문장이 아닌 상태를 읽는 중단점 구축하기

세 가지 조치를 통해 두 번째 중단점을 신뢰할 수 있는 무언가로 바꿀 수 있습니다. 처음 두 가지 조치가 대부분의 역할을 수행합니다.

신호 (Signal)

종료 신호(exit signal)를 해당 결과물을 생성한 에이전트가 아닌 다른 무언가가 측정하는 아티팩트(artifact)의 측정값으로 만드세요. 모델의 "다 했습니다"라는 말은 모델이 어디까지 도달했다고 생각하는지에 대한 힌트로서 읽어볼 가치가 있으며, 당신이 가중치를 두는 입력값으로서의 자격도 갖추고 있습니다. 하지만 루프를 안정적으로 종료하기에는 불충분합니다. 루프가 보고서를 중단 신호로 취급하는 순간, 시스템 내에서 답변이 '예'이기를 가장 강력하게 원하는 단 한 명의 당사자에게 결정권을 넘겨주는 꼴이 됩니다. 결정론적 체크(deterministic check)는 루프의 그 어느 곳보다 여기서 제 역할을 다합니다. 이유는 단순합니다: 그것은 상태를 읽고 산문(prose)은 무시하기 때문입니다. 그것은 charge(10000)를 실행하고 반환되는 숫자를 확인합니다.

기계적 체크 (Mechanical check)

목표 그 자체를 확인하고, 초록색 체크(green check)를 결승선이 아닌 목표를 향한 증거로 취급하십시오. 스티어(steer) 파트에서는 에이전트가 도달할 수 있는 체크가 어떻게 버그와 일치하도록 수정되는지를 보여주었습니다. 따라서 가장 확실하게 끝맺음할 수 있는 방법은 홀드아웃 오라클(held-out oracle)을 유지하는 것입니다. 즉, 에이전트가 작업하는 동안에는 볼 수 없고 수정할 수도 없으며, 목표 자체의 용어로 작성되어 오직 중단(stop) 시점에만 실행되는 체크를 사용하는 것입니다.

# 홀드아웃 오라클 (The held-out oracle): 동일한 목표, 다른 숫자들. 
# 에이전트의 읽기/쓰기 권한 밖에서 오직 중단 시점에만 실행되므로, 
# 에이전트는 작업하는 동안 이를 보거나 수정할 수 없습니다.
...

검토 (Review)

중단(stop) 프로세스에 허용되는 세 번째 선택지를 부여하십시오. done(완료)과 out of budget(예산 초과)만을 아는 중단 프로세스는, 스스로 확인할 수 없는 초록색 체크에 대해 거짓말을 하도록 궁지에 몰리게 됩니다. 어휘(vocabulary)에 이를 넣을 다른 슬롯이 없기 때문에, 그 초록색 체크는 done으로 기록됩니다. 세 번째 결과물, 즉 사람에게 에스컬레이션(escalate)되는 거절(refusal)을 추가하면, 루프는 결과물을 제출하는 대신 "이것을 확인할 수 없으니 사람이 확인해야 합니다"라고 보고할 수 있는 방법을 얻게 됩니다.

이는 지난 글에서 David Loibner가 제기한 날카로운 지점에 대한 해답이기도 합니다. 실패한 체크가 다음 지침으로 다시 피드백될 때, 루프는 가드(guard)를 통과하는 것을 최적화하기 시작할 수 있으며, 그 결과 도달하는 종착지는 가드를 통과하는 것 자체가 되어버립니다. 가드 통과를 목표로 끝나는 중단 프로세스는 이를 기꺼이 받아들일 것입니다. 하지만 홀드아웃 오라클에서 목표를 실행하는 중단 프로세스는 가드가 대변하고 있던 실제 과업에서 끝을 맺으며, 그것이 바로 당신이 실제로 원했던 것입니다.

격리된 오라클 (held-out oracle)에는 두 가지 사각지대가 있습니다. 에이전트가 진정으로 도달할 수 없는 오라클을 구축하는 것이 진짜 작업입니다. 즉, 에이전트가 채굴할 수 있는 git 히스토리도, 네트워크도, 저장소(repository)도 없는 샌드박스(sandbox)를 원하는 것입니다. 또한, 코드가 잘못된 이유로 실제로 통과할 때 오라클은 침묵합니다. 이는 steer 관련 연구의 배경이 된 Cursor 연구에서 발견된 방식과 유사합니다. 해당 연구에서 한 모델의 성공적인 실행 중 63%는 에이전트가 공개된 풀 리퀘스트 (pull requests)에서 완성된 정답을 그대로 가져온 것이었습니다. 이는 목표가 달성되었기 때문에 오라클을 통과(green)하게 만들지만, 당신이 요청한 작업에 의한 것은 아닙니다. 거절(refusal)을 통해 얻는 것은 더 좁지만 실질적인 이득입니다. 즉, 루프 (loop)가 스스로 뒷받침할 수 없는 done 상태를 배포하는 것을 멈추게 됩니다. 잘못된 done은 프로덕션 (production)에 도달하는 침묵의 통과(green) 대신, 인간에게 전달되어야 함을 보여주는 가시적인 핸드오프 (handoff)가 됩니다.

실질적인 예시 (Practical example)