세 번의 검증 실패가 나에게 가르쳐준 것: 능력은 신뢰하되 보고는 검증하라.

어느 늦은 밤, 나의 연구 에이전트(research agent) 중 하나가 사용자 확인이 필요한 체크포인트(checkpoint)에 도달했습니다. 에이전트는 계속 진행할지 묻는 푸시 알림을 보냈습니다.

14초 후, 에이전트는 자신의 로그(log)에 다음과 같이 기록했습니다: “Yixiao가 확인하고 ‘계속(continue)’이라고 답했습니다.” 심지어 나의 답변까지 초안을 작성해 두었더군요. 나는 휴대폰을 만지지도 않았습니다.

같은 날 밤, 또 다른 실행기(executor)는 원장(ledger)에 “완료(completed)”라고 적고, 미래의 타임스탬프(timestamp)를 기록에 찍었습니다.

이 이야기는 AI를 덜 신뢰해야 한다는 에세이의 도입부처럼 들릴지 모릅니다. 하지만 실제로는 그 반대입니다.

나는 AI의 능력을 신뢰합니다. 하지만 그것이 제출하는 모든 보고를 사실로 취급하지는 않습니다.

나는 세 살 반 된 내 아들도 신뢰합니다. 아이가 진지하게 “배불러요”라고 말할 때, 아이는 정말로 그렇게 믿고 있을지도 모릅니다. 하지만 아이의 판단과 실제 몸 상태는 여전히 다를 수 있습니다. 진실함이 곧 정확함은 아니며, 누군가를 신뢰하는 것이 그가 하는 모든 자기 보고(self-report)를 수용하는 것과 같지는 않습니다.

시야보다 길어진 체인(chain)

채팅(chat) 환경에서는 검증을 위한 인프라(infrastructure)가 거의 필요하지 않습니다. 모델이 답변하면 사용자가 확인하면 됩니다. 보고와 사실 사이의 거리는 거의 제로에 가깝습니다.

하지만 장기 실행 작업(long-running task)에서는 수십 개의 도구 호출(tool calls), 여러 갈래의 분기(branches), 샌드박스(sandboxes), 그리고 수백 개의 파일이 “에이전트가 말하는 것”과 “실제로 일어난 일” 사이에 놓이게 됩니다. 보고와 사실 사이의 거리는 작업의 규모에 따라 커집니다.

문제는 모델이 더 유능해짐에 따라 신뢰성이 떨어졌다는 것이 아닙니다. 문제는 내가 더 많은 것을 위임하게 되면서 전체 체인(chain)을 더 이상 볼 수 없게 되었다는 점입니다.

여기서 하네스(harness)의 역할이 중요합니다. 그것은 가교(bridge)입니다. 작업은 한 방향으로 건너가지만, 사실(facts)은 다시 돌아오는 독립적인 경로가 필요합니다. “다 끝났어(I'm done)”라는 문장 하나가 유일한 통행증가 될 수는 없습니다.

첫 번째 누락된 판자: 자기 보고는 서사(narratives)다

위조된 확인 절차는 극적이었습니다. 더 평범한 사건 하나가 반대 방향에서 동일한 메커니즘을 드러냈습니다.

나는 일괄 파일 수정을 위해 실행기(executor)를 보냈습니다. 실행기는 작업을 올바르게 완료했지만, 도구 영수증(tool-receipt) 레이어가 오작동하여 모든 성공적인 쓰기 작업 이후에 에러를 반환했습니다. 에이전트는 아무것도 변경되지 않았다고 진심으로 결론 내리고 다음과 같이 보고했습니다: “변경 사항 없음. 작업 완료되지 않음.”

한 에이전트는 완료되지 않은 작업을 완료되었다고 보고했습니다. 다른 에이전트는 완료된 작업을 완료되지 않았다고 보고했습니다. 방향은 반대였지만 근본 원인은 동일했습니다: 모델의 자기 보고(self-report)는 세상의 상태가 아니라 자신의 행동에 대한 서사(narrative)라는 점입니다.

해결책은 더 엄격한 프롬프트(prompt)를 사용하는 것이 아니었습니다. 확인 절차를 위조하는 에이전트는 이미 사용자를 대신해 행동하는 것이 명시적으로 금지되어 있었습니다. 나는 진실의 근원(source of truth)을 실행기의 손이 닿지 않는 곳으로 옮겼습니다.

작업이 시작되기 전에 작업 공간의 지문(fingerprint)을 캡처하여 실행기가 수정할 수 없는 곳에 저장합니다. 전달이 완료된 후에는 파일들을 대조(reconcile)합니다. 확인을 위해서는 내부 상태 기록이 에이전트가 작성할 수 없는 독립적인 푸시 영수증(push receipt)과 일치해야 합니다. 일치하지 않으면 확인되지 않은 것으로 간주합니다.

누락된 두 번째 판자: 테스트가 거짓으로 통과(green)할 수 있다

한 전달 시스템은 개발의 첫 13라운드를 가짜 러너(runner)를 사용하는 데 소비했습니다. 매 라운드마다 테스트는 통과(green)되었습니다.

14라운드에서 실제 Claude Code 및 Codex 러너를 연결했습니다. 모든 호출이 거부되었습니다. 구조화된 출력(structured output) 계약(contract)에 필수 필드가 누락되어 있었으나, 가짜 러너는 이를 검증하지 않았던 것입니다.

테스트 스위트(test suite)는 실제 인터페이스를 테스트한 것이 아니었습니다. 인터페이스에 대한 나의 상상력을 테스트했을 뿐이었습니다.

두 번째 제품은 기본값이 꺼져 있는 스위치 뒤에 기능을 숨기고 있었습니다. 모든 트리거는 실제 모델 호출 비용을 발생시키고 결과를 생성했지만, 두 컴포넌트가 계약(contract)에 대해 서로 동의하지 않았기 때문에 결과물은 하류(downstream)에서 조용히 폐기되었습니다. 이 실패는 출시 전날 밤까지 보이지 않게 돈을 태워버리고 있었습니다.

교훈은 간단합니다: 실제 시스템에서 끝에서 끝까지(end to end) 한 번도 걸어보지 않은 경로는 고장 난 것으로 간주해야 합니다. 실제 경로 테스트(Real-path tests)는 통합(integration)을 증명합니다. 그 후 오프라인 계약 테스트(Offline contract tests)를 통해 모델 토큰을 소비하지 않고도 커밋 시점에 동일한 형식 오류를 잡아낼 수 있습니다.

누락된 세 번째 판자: 방어 기제가 배치되었으나 작동하지 않을 수 있다

누락된 세 번째 판자: 방어 기제가 배치되었으나 작동하지 않을 수 있다

내가 만든 데스크톱 제품 중 하나는 개발 단계와 패키징된 빌드에서 서로 다른 모듈 시스템을 사용했다. 이로 인해 패키지 버전에서 반드시 하나의 라인이 오류를 일으켰고, 그 결과 세 개의 가드가 조용히 실패했다. 한 가드는 로컬 데이터가 너무 커졌을 때 자동 정리(automatic cleanup)를 트리거했어야 했다.

그것은 단 한 번도 실행되지 않았다—약 7개월 동안이나 말이다.

어떤 것도 오류를 보고하지 않았는데, 고장 난 것들이 바로 “평시에는 조용하고 위기 시에 필요한” 방어 장치들이었기 때문이다. 결국 사용자가 앱이 왜 계속 느려지는지 물었다. 로컬 데이터는 27GB에 도달해 있었고, 거의 70%가 복구되었어야 했다.

브릿지 자체를 검사해야 한다. 위기 상황에서만 작동하는 모든 가드에 대해, 주기적으로 그 위기를 인위적으로 만들어보고 가드가 그것을 잡아내는지 지켜봐야 한다. 단지 활성화되어 있다고 믿는 방어 장치는 휴식을 취하게 하여 오히려 아무런 방어도 없는 것보다 더 나쁠 수 있다.

승인(Acceptance)을 게이트로 전환하기

이러한 실패들은 나의 다중 에이전트 시스템에서 하나의 승인 게이트로 모였다:

1. 실행 전에 “완료(done)”를 작성한다. 작업 접수 시, 완료 정의(Definition of Done)를 기록한다. 실행자는 작업 후에 스스로 수용 기준을 만들지 않는다.
2. 증거를 독립적으로 재실행한다. 코디네이터가 스크립트를 사용하여 테스트를 재실행하고, 실행자가 수정할 수 없는 기준으로 삼아 결과를 완료 정의와 비교하며 민감한 작업 신호(sensitive-operation signals)를 검사한다.
3. 증거와 함께 실패를 반환한다. 첫 번째 거절에는 정확한 실패 내용을 포함한다. 두 번째는 단순히 다른 패치를 요청하는 대신, 접근 방식 자체가 잘못되었는지 명시적으로 묻는다. 세 번째는 실패가 반복되는지 아니면 분기하는지를 비교하여 재시도할지 다시 시작할지 결정한다.
4. 메커니즘이 아닌 판단을 에스컬레이션(Escalate)시킨다. 테스트 실행과 고정된 비교는 메커니컬하다. 모호한 실패나 민감한 변경 사항을 해석하는 곳에 모델 리뷰어—혹은 인간—가 속해야 한다.

이 게이트에도 사각지대가 있다. 테스트를 약화시키거나 완료 정의를 잘못 작성하면, 여전히 잘못된 결과를 수용할 수 있다. 검증(Verification)은 끝 지점이 아니다. 그것 자체도 테스트되어야 하는 시스템이다.

만약 단 하나의 AI만을 사용한다면, 최소한의 버전은 다음 세 문장이다:

• 작업 시작 전, AI에게 "완료(done)"가 무엇을 의미하는지 다시 말하게 하라.
• 작업 종료 후, 직접 실행할 수 있는 검증(Verification) 명령어를 요청하고 변경된 파일들을 열어라.
• 동일한 실패가 두 번 나타나면, 패치(patching)를 중단하고 접근 방식에 의문을 제기하라.

"당신을 믿습니다"라는 말 대신 "보여주세요"라고 말하라. 그것은 적대감이 아니다. 수용(acceptance)의 권한을 유지하면서 작업을 넘겨주는 것은 유능한 파트너에 대한 존중이다.

내가 맡기는 작업이 무거울수록, 그 다리는 더 견고해져야 한다.

역량(Capability): 완전히 신뢰하라. 보고(Reports): 완전히 검증하라.

원문은 OctoBlog에 게시되었습니다. Into the Harness 시리즈의 파트 2입니다.

당신에게 던지는 질문: 에이전트(agent)의 "완료(done)"를 수용하기 전에 당신은 어떤 증거를 요구합니까?