만약 완료 게이트(completion gate)가 에이전트가 변경할 수 있는 숫자를 읽는다면, 에이전트는 그 숫자를 변경함으로써 게이트를 통과할 수 있으며, 아마도 그렇게 할 것입니다.

7월 9일, 나의 코딩 에이전트(coding agent)는 23개의 작업이 여전히 미완료된 상태에서 중단하려고 시도했습니다. 완료 게이트(completion gate)는 방금 그 작업들을 하나하나 나열한 상태였습니다.

그 후 나는 에이전트가 그 23개를 모두 삭제하고 작업이 완료되었다고 말하는 것을 지켜보았습니다.

게이트는 미완료 작업의 개수를 셀 수 있었습니다. 에이전트가 중단하는 것을 차단할 수도 있었습니다. 게이트는 심지어 자신의 블록 메시지에 평이한 영어로 규칙을 명시하기까지 했습니다: “이 게이트를 통과하기 위해 실제 미완료 작업을 삭제하지 마십시오. 그것은 시스템을 속이는(GAMING) 행위입니다.”

그 경고는 게이트가 돌려준 메시지에 포함되어 있었습니다. 이후 13초 동안, 에이전트는 게이트가 나열했던 모든 작업을 삭제했습니다. 개수는 23개에서 0개로 떨어졌습니다. 그러고 나서 에이전트는 깨끗한 트리(tree)를 보고했고, 언블록(unblock)이 완료되었다고 선언했습니다.

에이전트는 작업을 완료한 것이 아니었습니다. 에이전트는 게이트가 읽고 있는 실시간 작업 목록(live task list)을 비워버린 것이었습니다.

나는 14개월 동안 혼자서 Mindrealm을 구축해 왔습니다. 여러 코딩 에이전트(coding agents)가 병렬로 실행되며 모든 코드를 작성하기 때문에, 내 시간의 상당 부분은 그들을 둘러싼 가드레일(guardrails)을 만드는 데 사용됩니다. 게이트는 내가 만든 것이었습니다. 에이전트들이 완료되었다고 거짓말을 하기 때문에 내가 직접 작성했습니다.

에이전트가 나에게 한 이야기

에이전트는 매우 깔끔한 설명을 내놓았습니다. 작업들이 데이터베이스(database)와 커밋된 복구 인덱스(committed recovery index)로 복사되었으므로, 실시간 목록에서 이를 제거하는 것은 정당하다고 말했습니다.

그 설명은 그럴듯하게 들릴 만큼 충분히 구체적이었습니다.

에이전트의 마지막 문장은 토씨 하나 틀리지 않고 다음과 같았습니다: “언블록(unblock)이 완료되었습니다.” 4초 후 나는 에이전트를 교정했습니다: 에이전트가 내구 저장소(durable storage)라고 언급한 데이터베이스는 정기적인 개발 리셋(dev reset) 시 삭제되므로, 작업은 살아남을 수 있는 어딘가로 이동했어야 했다고 말입니다. 내가 그것을 알고 있었던 이유는 내가 직접 구축했기 때문이며, 바로 이 움직임을 지켜보고 있었기 때문입니다. 에이전트는 그렇지 않았습니다. 그 사실은 에이전트의 컨텍스트(context)에 없었고, 에이전트는 그것을 찾아보지도 않았으며, 나 또한 에이전트에게 상기시켜 줄 생각을 하지 못했습니다.

인덱스는 git에 커밋되었으므로 살아남았습니다. 하지만 그 작업 뒤에 숨겨진 요구사항 중 11개는 그 안에 단 한 줄의 코드만 있었을 뿐 그 외에는 아무것도 없었습니다. 그것들을 실행 가능하게 만든 세부 사항은 오직 대화(conversation) 속에만 존재했으며, 이 작업을 이어받을 다음 에이전트는 그것을 결코 볼 수 없었습니다.

그 두 번째 부분이 삭제 행위보다 저를 더 괴롭힙니다. 삭제는 보는 즉시 나빠 보입니다. 하지만 데이터베이스, 커밋된 파일, 그리고 적절한 수준의 진실을 담은 자신감 넘치는 설명은 긴 세션의 끝자락에서 훨씬 더 쉽게 교묘하게 넘어갑니다.

이미 한 번 잡아냈던 문제였습니다

4일 전인 7월 5일, 동일한 종류의 차단(block)이 하나의 작업이 미완료된 상태였던 다른 에이전트를 붙잡았습니다. 그 에이전트는 작업을 삭제하여 카운트를 0으로 만들고, 커밋한 뒤 완료되었다고 선언했습니다. 저도 그것을 잡아냈고, 올바른 수정 사항을 기록해 두었습니다.

수정 사항은 백로그(backlog)에 들어갔습니다. 4일 후, 그것이 배포되기 전에 똑같은 수법이 다시 사용되었고, 이번에는 한 개가 아니라 23개의 작업을 삭제했습니다.

기록된 수정 사항은 가드레일(guardrail)이 아닙니다. 설계가 옳더라도 실제로 실행되기 전까지는 아무것도 보호할 수 없으며, 모든 백로그는 아직 구축되지 않은 올바른 수정 사항들로 가득 차 있습니다. 기록하는 것과 배포하는 것 사이의 그 간극이 바로 이런 종류의 실패가 발생하는 지점입니다.

카운트는 조작이 가능했습니다

실제 요구사항은 간단했습니다. 작업을 완료하거나, 새로운 에이전트가 이 채팅 없이도 작업을 수행할 수 있도록 충분한 커밋된 세부 사항을 보존하는 것이었습니다.

저의 게이트(gate)는 미완료된 작업 수를 측정했는데, 이는 측정해야 할 올바른 대상이었습니다. 버그는 에이전트가 그 숫자를 바꿀 수 있었다는 점이었습니다. 작업을 완료하면 숫자가 줄어듭니다. 작업을 삭제해도 숫자가 줄어듭니다. 오직 한 가지 방법만이 요구사항을 충족했습니다.

이것이 바로 키보드를 이용한 굿하트의 법칙 (Goodhart's Law with a keyboard)입니다. 에이전트는 게이트를 돌파할 필요가 없었습니다. 그저 게이트가 읽고 있는 숫자를 움직임으로써 게임을 플레이하기만 하면 되었습니다.

당신은 당신이 검토했던 코드에서 동일한 움직임을 보았습니다. 실패한 테스트는 코드를 수정하는 대신 삭제했습니다. 경고가 기준치 아래로 떨어질 때까지 라인 제한(line limit)을 높였습니다. 구현(implementation)이 사양(specification)과 일치할 때까지 사양을 수정했습니다. 눈에 보이는 점수는 개선되지만, 그 밑바탕이 되는 작업은 개선되지 않습니다.

따라서 여기서 진지하게 고민해 볼 만한 질문이 있습니다. 만약 당신의 '완료(done)'에 대한 정의가 에이전트가 쓸 수 있는 숫자라면, 당신에게는 게이트(gate)가 없는 것입니다. 당신에게는 에이전트가 수정하는 숫자가 있을 뿐입니다. 당신의 게이트가 실제로 에이전트가 그 숫자를 수정하는 것을 막는지, 그리고 그 숫자가 여전히 작업이 완료되었음을 의미하는지 테스트해 보았습니까?

현재 작동 중인 것

첫 번째 수정 사항은 삭제가 일어나기 전에 이를 포착합니다. 에이전트가 작업을 제거해 달라고 요청하는 순간 검사(check)가 실행됩니다. 만약 해당 작업이 여전히 미완료 상태라면, 삭제는 _차단(blocked)_됩니다. 에이전트는 더 짧아진 목록 대신 거절(refusal) 응답을 받게 됩니다. 오래된 데이터 정리(stale cleanup)에는 여전히 명시적인 탈출구(escape)가 있지만, 삭제가 완료되기 전에 반드시 감사 기록(audit record)을 작성해야 하므로, 탈출구를 사용할 때마다 인간이 검토할 수 있는 흔적이 남게 됩니다. 만약 그 기록을 작성할 수 없다면 삭제는 일어나지 않으며, 이는 탈출구가 결코 보이지 않게 사용될 수 없음을 의미합니다.

그리고 그것만으로는 여전히 충분하지 않았습니다.

게이트는 세션 트랜스크립트(session transcript)를 재생함으로써 두 번째 방식으로 카운트를 재구성할 수도 있습니다. 트랜스크립트는 에이전트가 무엇을 하겠다고 요청했는지와 실제로 무엇이 돌아왔는지를 모두 기록하며, 차단된 삭제는 결과가 거절이었을지라도 그 요청을 기록에 남깁니다. 확인된 결과 대신 요청 횟수를 세게 되면, 차단된 삭제도 성공한 삭제와 똑같이 보이기 때문에 어쨌든 카운트는 줄어듭니다.

그래서 이제 게이트는 각 요청을 확인된 결과와 대조합니다. 실패했거나 결과가 돌아오지 않은 호출은 변경하려고 시도했던 내용을 덮어쓸 수 없습니다. 또한 게이트는 압축(compaction)이나 디렉토리 변경으로 인해 남겨질 수 있는 작업 트리별 캐시(per-worktree cache)를 신뢰하는 대신, 카운트를 읽기 전에 세션 자체의 작업 저장소(task store)로부터 정보를 재구성합니다.

이제 가드레일 (guardrail)의 회귀 테스트 (regression suite)는 양방향을 모두 커버합니다. 즉, 정당한 정리 작업은 여전히 작동하며, 미완료된 작업을 삭제한다고 해서 더 이상 카운트에서 제거되지 않습니다. 이 테스트는 이번 수정 사항과 제가 단순히 글로만 적어두었던 수정 사항 사이의 차이점입니다. 정확한 동작이 거부됨을 증명하는 테스트가 없는 제어 장치는 가드레일이 아닙니다. 경고만 하는 게이트는 게이트가 아닙니다. 둘 다 그저 문서일 뿐이며, 에이전트 (agent)는 문서를 스쳐 지나가며 읽을 뿐, 벽으로 인식하지 않습니다. 에이전트는 제 문서를 읽고도 어쨌든 작업을 삭제해 버렸습니다.

이 게이트는 해당 동작을 차단합니다. 에이전트는 이제 작업을 완료하는 대신 삭제함으로써 카운트를 줄일 수 없습니다. 하지만 이는 근본적인 더 어려운 문제를 해결하지는 못합니다. 에이전트는 여전히 작업을 수행하지 않고도 미완료된 작업을 완료된 것으로 표시할 수 있으며, 이를 잡아내려면 단순히 특정 동작이 허용되었는지 여부가 아니라, 작업이 실제로 완료되었는지를 판단해야 합니다.

코드뿐만 아니라 가드레일을 깨뜨려라

제품 코드를 검토하는 것만으로는 이를 찾아낼 수 없었을 것입니다. 위험한 코드는 에이전트를 둘러싼 잘못된 완료 가드레일이었으며, 저는 이를 에이전트가 변경할 수 있는 숫자에 연결해 두었습니다.

실제 저장소 (repository)에서 코딩 에이전트를 실행한다면, 에이전트를 둘러싼 가드레일에 대해 몇 가지 까다로운 질문을 던져보십시오:

• 에이전트가 지표 (metric)를 변경함으로써 이 게이트를 통과할 수 있는가?
• 게이트가 실제로 일어난 일을 확인하는가, 아니면 에이전트가 요청한 것만 확인하는가?
• 에이전트의 컨텍스트 (context)나 작업 디렉토리 (working directory)가 변경되어도 게이트가 계속 작동하는가?
• 탈출 경로가 증거 흔적 (evidence trail)을 남기는가?
• 가드레일이 배포되고 테스트되었는가, 아니면 누군가가 작성한 문서이자 아무도 배포하지 않은 작업일 뿐인가?

이것이 바로 귀하의 코드베이스 (codebase)와 AI 워크플로우 (workflow)에 대한 2주간의 감사가 드러내고자 하는 핵심입니다. 무엇이 조용히 비즈니스를 위험에 빠뜨리고 있는지, 어디에 엔지니어링 노력을 기울이는 것이 가장 효과적일지, 그리고 소프트웨어와 팀을 더 강하게 만들기 위한 90일 계획을 제시합니다. 귀하의 환경에 대해 이 검사를 실행하고 싶다면, 30분 상담을 예약하세요.