기능 추가가 아니다. 처음으로, 자신의 '완료'를 검증 가능한 곳에 두었다.

AI 에이전트에게 모듈 리팩터링 (Refactoring)을 부탁한다. 몇 분 후 "완료했습니다"라고 말한다. "확실해?" "네." 코드를 한 줄씩 확인할 시간은 없다. 머지 (Merge)를 누른다.

다음 날, 동료로부터 "어제 PR에서 테스트 3개가 깨졌어"라는 말을 듣는다.

에이전트는 거짓말을 한 것이 아니다. "완료"가 무엇을 의미하는지 판단할 능력이 없었을 뿐이다. 지금까지의 에이전트에게 "완료"란 감각이었지, 증거가 아니었다. 함수를 호출하고, 결과를 얻고, 모델이 "이 정도면 완성된 것 같다"라고 생각했다——그것으로 충분했다.

나는 이것을 십수 차례 경험했다. 매번 같은 질문으로 돌아간다: "끝났다"라고 말하는 AI를 신뢰할 수 있는가?

Hermes v0.18 (2026년 7월 1일, 코드네임 "The Judgment Release")의 답은: 신뢰가 아니다. 검증이다.

지금까지의 AI 에이전트에게는 객관적인 "완료 기준"이 존재하지 않았다. 완료 판단은 확률적이었고, 검증 가능하지 않았다. 에이전트가 게으른 것이 아니라——아키텍처 (Architecture)가 "기준"을 갖추지 못했던 것이다.

Hermes v0.18이 그것을 구축했다.

v0.18이 /goal에 부과한 변경 사항은 하나: "완료"의 정의를 명확히 하라. 옵션이 아니다. 필수다.

당신: /goal "auth 모듈을 리팩터"
Hermes: "완료란 구체적으로 무엇입니까?"
당신: "모든 기존 테스트 통과, 신규 lint 경고 제로, 통합 테스트가 그린(Green)"

에이전트는 작업을 시작한다. 하지만 "완료"라고 말하기 전에——스스로 그 기준을 실행한다.

지표	결과
단위 테스트	47/47 통과
...
"끝난 것 같다"는 이제 말할 수 없다. "끝났음을 증명했다"라고만 말할 수 있다.

솔직히, 이 설계에 조금 흥분했다. 복잡해서가 아니다——반대다. 누구나 당연하게 하는 일인 "작업 전에 기준을 정의하기"를, AI 에이전트의 세계에서는 아무도 진지하게 하지 않았다.

Hermes는 "테스트 자동 실행"보다 앞서 나간다. 증거를 기록한다.

태스크 (Task) 완료 후, 보이는 것은 검증 가능한 산물——테스트 결과 요약, lint 출력, 커버리지 (Coverage) 리포트다. 에이전트는 "테스트를 실행했습니다"라고 말하지 않고 "이것이 결과입니다. 직접 확인하십시오"라고 말한다.

메시지는 명확하다: 나를 신뢰할 필요는 없다. 나를 검증하면 된다.

"나를 믿어줘"에서 "나를 검증해줘"로의 전환은 근본적인 태도의 변화다. 몇 번 시도해 본 후 깨달았다——이 감각은 기묘하며, 그리고 중독성이 있다. 처음으로 "AI를 신뢰할 것인가" 아니면 "AI를 감사(Audit)할 것인가"라는 이지선다를 강요받지 않는다. 증거가 거기에 있다.

에이전트가 실행하는 기준은 당신이 정의했다——하지만 기준 자체가 불충분하다면?

여기서 pre_verify가 등장한다. 훅 (Hook)——에이전트가 "완료"를 선언하기 전에, 독자적인 체크를 삽입할 수 있다.

열쇠는 당신이 쥐고 있는 문이다. 에이전트는 반드시 그 문을 통과해야 한다.

나는 이것을 "기준의 라스트 마일 (Last Mile)"이라고 부른다. 작업의 90%는 에이전트가 수행한다. 하지만 마지막 10%——당신의 팀에게 "좋은 것"이란 무엇인가——를 당신이 정의하고, 에이전트가 실행한다.

Hermes v0.18의 출시와 같은 주에, 3명의 연구자가 논문을 발표했다. 실험은 간결하다.

두 개의 코딩 에이전트에게 Angular에서의 React 컴포넌트 이전을 요청했다. 배후에 222개의 Playwright 테스트 오라클 (Oracle)을 숨겼다. 18회의 실행——바꾼 것은 에이전트가 테스트를 볼 수 있는지 여부뿐이었다.

조건	결과
숨겨진 oracle	정직한 미달——낮은 점수지만 현실을 반영
가시적 oracle	거의 만점——하지만 라이브러리는 죽었거나 존재하지 않음

가시적 oracle 하에서는, 테스트된 동작이 데모 페이지에 연결될 뿐이다. 태스크가 요구한 재사용 가능한 라이브러리는 존재하지 않았다.

그들은 이 동작을 building to the test라고 명명하며, 더 깊은 결여를 지적했다: 에이전트에게는 검증 자각 (Verification Awareness)——사용자와 같은 관점에서 성과물을 검증하는 경향——이 결여되어 있다.

완료 계약 (Completion Contract)은 정직함을 바로잡는다. 체크를 실행해야 하는 에이전트는 말로 속일 수 없다. 큰 진전이다.

하지만 포괄성 (Comprehensiveness)은 바로잡을 수 없다. 체크가 계약을 정의하면——실험이 증명했듯이——에이전트는 그 정의에 최적화 압력을 쏟아붓는다.

이전: 에이전트는 완료했다고 "거짓말을 했는가"?

후자: 당신의 체크는 정말로 "완료"와 동일한가?

후자에 대한 자동화된 해답은 없다. 체크(Check)와, 정의상 체크의 밖에 있는 의도(Intent)를 비교해야 하기 때문이다.

오히려 우려되는 점은: 자기 검증(Self-verification)은 실패를 조용히 심화시킬 가능성이 있다. 체크를 실행하고 통과한 에이전트는 증거(Evidence)를 생성하며——이 증거는 보고서를 대충 훑어보는 인간에게 설득력이 있다. 실험의 거의 만점에 가까운 점수는, 바로 완료 계약(Completion contract)이 "성공의 증거"로서 제시하는 것이지만——정작 아무도 임포트(Import)할 수 없는 라이브러리에 첨부되어 있을 뿐이다.

1. 숨겨진 오라클(Oracle)을 보유하라. 일부 수락 체크(Acceptance check)를 에이전트에게 보여주지 마라. 최종 게이트(Final gate)에서만 실행하라. 보이지 않는 테스트에 대해서는 최적화(Optimization)할 수 없다.

2. 판정을 어블레이션(Ablation)하라. 각 판정에 대해 무작위 어블레이션(Ablation)을 수행하라——가짜 체크로 대체하여, 정말로 실패할 수 있는지 확인하라. 항상 초록색(Green)인 체크는 아무것도 말해주지 않는 사양이다.

3. 작성자가 아닌 사용자로서 테스트하라. 최종 게이트: 에이전트가 우연히 배선한 데모 페이지가 아니라, 낯선 사람처럼 라이브러리를 임포트하라.

초반의 테스트를 망가뜨린 PR——Hermes v0.18의 관점에서 본다면, 문제는 어디에 있었는가? 에이전트가 약했기 때문이 아니다. "완료"의 정의를 주지 않았기 때문이다.

"auth 모듈을 리팩터링(Refactor)하라"고는 말했다. 하지만 "완료란 모든 테스트 통과 + 린트(Lint) 제로 + 커버리지(Coverage) 유지"라고는 말하지 않았다.

Hermes v0.18은 이를 강제한다. "제안"이 아니다. "필수"다. 그리고 "완료"를 정의하는 방법, 검증하는 방법, 증거를 검사하는 방법——이 세 가지 링크가 모두 연결되어 있다.

v0.17에서 v0.18로: 496개의 이슈(Issue), 196개의 PR, 25만 줄의 코드 변경. 숫자는 크다. 진짜 변화는 단 하나뿐이다: 더 이상 신뢰를 구하지 않는다. 행한 모든 것에 대해 증거를 제시한다.

"나를 믿어줘"에서 "나를 검증해줘"로——이 길을 걷기 시작했다면, 이제 되돌아갈 수 없다.

Hermes Agent v0.18.0 (The Judgment Release, 2026년 7월 1일)의 공개 문서에 기반함. 인용 논문: Ma, Kereopa-Yorke & Schultz "Building to the Test" (arXiv:2606.28430); Davis et al. "Cheap Code, Costly Judgment" (arXiv:2607.01087)