최근 저는 코딩 에이전트가 승인된 구현(implementation)을 시작하기를 거부하는 모습을 목격했습니다.

작업 계획(work plan)에는 다음과 같은 내용이 포함되어 있었습니다:

## WorkPlan Review

- **Status**: approved (2026-08-02)

에이전트는 해당 라인을 찾아냈고 approved라는 단어를 이해했습니다. 하지만 워크플로우가 Implementation Approval.Status라는 이름의 필드를 기대했기 때문에, 에이전트는 승인을 다시 요청했습니다.

실질적으로 누락된 것은 아무것도 없었습니다. 라벨(label)이 틀렸을 뿐입니다.

에이전트는 제가 요구사항, 설계, 리뷰, 계획, 구현을 거쳐 변경 사항을 반영하도록 설계한 저장소 상주 워크플로우(repository-resident workflow)를 따르고 있었습니다. 저는 상태 필드, 핸드오프 계약(handoff contracts), 리뷰 게이트(review gates), 재시도 규칙(retry rules), 에스컬레이션 경로(escalation paths)를 추가하는 데 수개월을 보냈습니다. 각각의 추가 사항은 제가 실제로 목격했던 실패 사례들을 해결하기 위한 것이었습니다. 이들이 모여 워크플로우는 사소한 제목 하나에도 멈춰버릴 만큼 취약(brittle)해졌습니다.

저는 다음과 같은 오래된 질문을 중심으로 시스템을 구축해 왔습니다: 어떻게 하면 모델이 경로를 놓치는 것을 방지할 수 있을까?

이제 모델은 경로를 따라갈 수 있게 되었습니다. 제 경로가 문제가 된 것입니다.

두 가지 종류의 제약 사항

이번 승인 사건은 제가 놓쳤던 차이점을 드러냈습니다.

**경계 제약(boundary constraint)**은 솔루션 공간(solution space)을 줄입니다:

• 퍼블릭 API 계약(public API contract)을 준수할 것.
• 권한 없이 되돌릴 수 없는 외부 작업을 수행하지 말 것.
• 확인된 요구사항을 구현하고, 기록된 비목표(non-goals)는 범위(scope)에서 제외할 것.
• 요구되는 동작이 관찰될 때만 작업을 완료된 것으로 간주할 것.

**작업 생성 제약(work-generating constraint)**은 의무를 생성합니다:

• 항상 세 가지 대안을 생성할 것.
• 모든 기능에 대해 단위 테스트(unit test), 통합 테스트(integration test), 엔드 투 엔드 테스트(end-to-end test)를 요구할 것.
• 모든 리스크에 대해 완화 작업(mitigation task), 담당자, 롤백 계획(rollback plan), 승인 기록을 요구할 것.
• 계속 진행하기 전에 모든 리뷰 결과(review finding)를 해결할 것.
• 선택적 필드가 없거나 예상치 못한 라벨을 사용하는 경우 중단할 것.

두 가지 모두 안전장치처럼 보일 수 있습니다. 하지만 모델이 이를 수행할 능력을 갖추게 되면, 이들은 매우 다르게 작동합니다.

경계 제약 조건(Boundary constraints)은 에이전트가 어디에서 작동할 수 있는지를 알려줍니다. 작업 생성 제약 조건(Work-generating constraints)은 요청된 작업으로 해석됩니다. 신뢰할 수 있는 에이전트라면 이들이 암시하는 추가적인 산출물(artifacts), 테스트, 추상화(abstractions) 및 중단 조건(stop conditions)을 안정적으로 생성할 것입니다.

그것은 제가 이제 에이전트 워크플로우를 변경할 때 사용하는 원칙을 제시해 주었습니다:

경계와 증거(evidence)에 대해서는 엄격하라. 그 사이의 경로에 대해서는 유연하라.

이 문제가 지금 나타난 이유

이 이면에 있는 능력의 변화(capability shift)는 실재하지만, 대중적인 측정치는 사람들이 실제로 사용하는 모델의 발전 속도를 따라가지 못하는 경우가 많습니다.

METR의 작업 완료 시간 지평(task-completion time horizon)은 에이전트가 완료할 수 있는 소프트웨어 작업의 난이도가 역사적으로 강력하게 증가했음을 보여줍니다. 또한 METR은 벤치마크가 잘 정의된 작업들을 다루고 있으며, 능력치가 여전히 들쭉날쭉(jagged)하고, 새로운 모델 출시가 몇 주 동안 측정되지 않거나 완전히 누락될 수 있다고 경고합니다. 8월 2일 기준으로 해당 공개 페이지는 여전히 5월 8일자로 되어 있었으며, 최근 측정되지 않은 모델 목록조차 이후의 출시 모델들을 따라잡지 못한 상태였습니다.

실제 사용 양상 또한 더 긴 실행 시간(longer execution)을 향해 이동했습니다. 약 400,000건의 코딩 에이전트 세션을 분석한 결과, 명확한 분업 구조가 발견되었습니다. 즉, 사람은 대부분의 계획 결정(planning decisions)을 내리는 반면, 에이전트는 대부분의 실행 결정(execution decisions)을 내린다는 것입니다. 저자들은 이를 사람은 무엇을 만들지 결정하고, 에이전트는 그것을 어떻게 만들지 결정하는 것이라고 설명합니다.

두 출처 모두 오늘날의 모델이 제 워크플로우에서 어떻게 행동하는지를 증명하지는 않습니다. 여기서 설명된 실패 사례와 관련된 모델 제품군들은 제가 찾은 측정 및 벤치마크 이후에 출시되었습니다. 저는 해당 모델들에 대한 공개적인 재측정 결과를 찾지 못했습니다.

이러한 타이밍은 FixedBench의 경우에 가장 중요합니다. 2026년 5월, 연구진은 당시 최신이었던 5개의 코딩 모델을 코드가 이미 수정된 200개의 이슈에 대해 테스트했습니다. 에이전트들은 여전히 35%에서 65%의 사례에서 바람직하지 않은 변경을 수행했습니다. 이는 해당 세대의 모델들에 행동 편향(action bias)이 존재했다는 유용한 증거입니다. 다만 이것이 현재의 실패율은 아닙니다.

더 흥미로운 결과는 연구진이 지침(instruction)을 변경했을 때 발생했습니다. 에이전트들에게 먼저 검증하고 기권(abstention)을 성공으로 간주하라고 지시하자, 이미 올바른 코드에 대한 수정(edits)이 줄어들었습니다. 반면 부분적으로 수정된 코드의 경우, 동일한 지침이 더 많은 작업이 필요함에도 불구하고 에이전트들이 기권하게 만들었습니다. 프롬프트 엔지니어링 (Prompt engineering)이 행동 편향 (action bias)을 수동성 (passivity)으로 맞바꾼 것입니다.

그것이 바로 제가 제 워크플로우에서 만들어낸 함정이었습니다. 모델이 한 번 실패하자, 저는 그 반대되는 행동을 보편적인 규칙으로 인코딩했습니다. 모델이나 작업이 바뀌어도 그 보상책은 그대로 남아 있었습니다.

여기서 가장 강력한 증거는 제가 현재 사용하는 모델들에서 이 워크플로우가 보여준 실패 이력에서 나옵니다. 이 연구들은 왜 그러한 실패들이 그럴듯한지, 그리고 왜 단순한 프롬프트 수정이 효과를 잃는지(decay)를 설명해 줍니다. 그것들은 시스템 자체를 관찰하는 것을 대체할 수 없습니다.

신뢰성이 어떻게 작업을 제조하기 시작했는가

엄격한 승인 필드는 가장 눈에 띄는 실패 사례였을 뿐입니다.

또 다른 실행에서는 외부 회계 증거, 문서 승인 기록, 정확한 릴리스 명령, 그리고 상세한 E2E (End-to-End) 환경 가정을 찾을 수 없다는 이유로 구현(implementation) 단계 전에 워크플로우가 중단되었습니다. 저장소(repository), 로컬 서비스, 테스트 도구들은 사용 가능한 상태였습니다. 구현의 대부분은 진행될 수 있었습니다. 워크플로우가 유용한 계획 컨텍스트(planning context)를 필수적인 준비 관문(readiness gates)으로 변환한 뒤, 누락된 모든 관문을 사용자의 결정 사항으로 취급해 버린 것입니다.

문서들도 확장되었습니다. 제품 요구사항(Product requirements)과 설계 문서(design docs)는 이해관계자 승인, 라이브 서비스 액세스, 릴리스 절차, 대시보드, 그리고 운영 증거들을 수집하기 시작했습니다. 데이터 내보내기 변경을 위한 작업 계획에는 요청된 결과물이 구현 단계에서 끝남에도 불구하고 계정 설정과 운영 관련 사항들이 포함되었습니다.

리뷰(Review)는 확장을 더 악화시켰습니다. 동일한 계획 흐름(planning flow) 중에, 리뷰어는 결정론적인(deterministic) 20,000행의 증명(proof)을 요청했습니다. 플래너(planner)는 해당 증명이 어떤 결정을 바꿀 것인지, 혹은 더 저렴한 경계 검사(boundary check)로 충분할지에 대해 묻지 않고 그 요청을 수락했습니다. 이후 리뷰어는 제안된 증명 데이터가 기존의 집계 계약(aggregation contract)과 모순된다는 것을 발견했고, 이는 또 다른 수정(revision)을 촉발했습니다. 모든 단계는 기술적으로 방어 가능했습니다. 루프(loop) 자체에는 경제적 판단이 없었습니다.

나는 리뷰어를 권위 있게 만들었고, 작성자를 복종하게 만들었습니다. “승인될 때까지 리뷰하라”는 “리뷰어가 아이디어가 고갈될 때까지 작업을 추가하라”로 변질되었습니다.

이것은 수렴(convergence)이 아닙니다. 이것은 래칫(ratchet, 한 방향으로만 움직이는 장치)입니다.

내가 변경한 것

나는 모든 규칙을 삭제함으로써 이 문제를 해결하지 않았습니다. 대신 워크플로우(workflow)가 엄격하게 적용되는 지점을 변경했습니다.

솔루션을 설계하기 전에 결과를 결정하라

사용자의 요청은 더 이상 자동으로 유효한 구현 범위(implementation scope)로 수용되지 않습니다. 설계 전에 워크플로우는 다음 사항들을 기록합니다:

• 관찰 가능한 결과(observable outcome);
• 현재 요구되는 사항;
• 현재 상태, 원하는 미래, 또는 추측을 설명하는 것;
• 명시적인 비목표(non-goals);
• 구현 비용 및 구조적 영향에 대한 대략적인 관점.

비용 평가는 대략적인 상태로 유지되는데, 이는 이것이 상세한 추정(estimation)이 아니라 요구사항 정의 작업이기 때문입니다. 이 작업의 목적은 범위(scope)를 제거하는 비용이 여전히 저렴할 때, 나쁜 트레이드오프(tradeoff)를 가시화하는 것입니다.

“변경 없음”과 “기존에 존재하는 것을 재사용함”은 유효한 결론이지만, 둘 다 기본값(default)은 아닙니다. 에이전트(agent)는 결과가 이미 충족되었는지, 부분적으로 충족되었는지, 아니면 여전히 구현이 필요한지를 결정하기 위해 충분한 증거를 조사해야 합니다. 이를 통해 FixedBench의 행동 편향(action bias)이 그 거울 이미지로 변하는 것을 방지합니다.

이는 또한 사용자가 전달해야 하는 소통 방식도 변화시킵니다. 유용한 요청은 단순히 원하는 기능의 목록이 아니라, 현재 결과의 경계(boundary)를 포함해야 합니다. “공개 응답 계약(public response contract)을 변경하지 않고 기존 인증 경로를 확장하라”는 요청은 긴 구현 규칙 목록보다 더 가치 있습니다. 이는 결과와 더불어 설계가 재검토되어야 하는 지점을 동시에 명시하기 때문입니다.

모델에게 예측된 경로가 아닌 결정을 제공하라

기존의 워크플로우는 완전한 경로를 기술했습니다. 즉, 하나의 에이전트를 실행하고, 모든 필드를 채우고, 다른 에이전트를 실행하고, 누락된 입력이 있으면 중단하고, 직렬화된 상태(serialized state)가 나타날 때까지 반복하는 방식이었습니다.

이제 저는 각 단계에 다음 네 가지를 제공하려고 노력합니다:

• 해당 단계가 책임지는 목적;
• 결정을 바꿀 수 있는 증거;
• 다음 행동을 선택하기 위한 기준;
• 다음 소비자에게 필요한 최소한의 결과물.

“모든 테스트 레인을 실행하라”는 경로를 예측하는 것입니다. 반면 “필요한 경계를 관찰하는 가장 좁은 테스트를 사용하라”는 결정 기준을 제공합니다. 소프트웨어가 응답을 파싱(parsing)하는 곳에서는 여전히 정확한 스키마(schema)가 중요합니다. 하지만 사람이 읽는 작업 계획(work plan)은 두 개의 헤딩(heading)이 동일하게 승인된 상태를 표현한다고 해서 실패할 필요는 없습니다. 저는 승인 확인(approval check) 방식을, 하나의 헤딩만을 요구하는 대신 의미론적으로 동등한(semantically equivalent) 증거를 수용하도록 변경했습니다.

메인 에이전트는 가벼운 해결(lightweight resolution) 권한도 가집니다. 에이전트는 의미론적으로 동등한 상태를 해석하고, 저장소 로컬의 모호함을 해결하며, 새로운 증거로 재시도하고, 영향을 받지 않는 작업을 계속할 수 있습니다. 사용자 에스컬레이션(User escalation)은 사용자의 영역에 속하는 결정, 즉 변경된 제품 결과, 새로운 요구사항, 주요 승인 설계 변경, 권한 부재, 또는 되돌릴 수 없는 외부 작업의 경우에만 남겨둡니다.

리뷰 결과가 거부될 수 있도록 하라

이제 리뷰의 수신자는 세 가지 선택지를 갖게 됩니다:

• 승인된 요구사항, 수락된 설계, 저장소 규칙(repository rule) 또는 관찰 가능한 정확성(observable correctness)에 모순되는 발견 사항을 **적용(Apply)**합니다.
• 범위를 추가하거나, 제외 사항을 뒤집거나, 증명을 중복하거나, 선택적인 강화(hardening)를 요청하거나, 관찰 가능한 효과보다 더 많은 비용이 드는 발견 사항은 **거부(Decline)**합니다.
• 해결책이 제품의 결과나 주요 승인된 결정 사항을 변경하는 경우에는 **사용자의 결정을 위해 반환(Return for user decision)**합니다.

거부(Decline) 시에는 증거를 포함하여 검토자(reviewer)에게 다시 전달됩니다. 해당 증거가 있음에도 결과가 여전히 부정확하거나 검증 불가능하다면 검토자는 발견 사항을 유지할 수 있습니다. 새로운 증거 없이 동일한 선호도를 반복하는 것은 워크플로우를 차단하지 않습니다.

유용한 리뷰 프로세스는 기본적인 엔지니어링 기술, 즉 기술적으로 타당한 제안이라 할지라도 구현하지 않기로 결정하는 능력을 보존합니다.

내가 다시 되돌려 놓아야 했던 제약 사항

규칙을 제거하는 것은 규칙을 추가하는 것만큼이나 부주의할 수 있습니다. 나는 이번 재작성(rewrite) 과정에서 이를 증명했습니다.

기획 흐름(planning flow)은 통합 테스트 및 E2E(End-to-End) 테스트 스켈레톤(skeleton)을 생성하여, 첫 번째 수직 슬라이스(vertical slice)가 가능한 한 빨리 실제 경계(boundary)를 가로지르는 수락 기준(acceptance criterion)을 증명할 수 있도록 했습니다.

인계(handoff) 과정을 단순화한 후, 플래너(planner)는 생성된 테스트 스켈레톤을 관련 없는 파일로 취급하고 프로젝트 후반부에 새로운 E2E 테스트를 계획했습니다. 산출물(artifact)은 여전히 존재했기에 워크플로우는 완전해 보였습니다. 하지만 그것이 존재해야 할 이유는 사라져 버렸습니다.

나는 플래너에서 스켈레톤의 목적을 복구했습니다: 해당 경계를 실행 가능하게 만들 수 있는 가장 이른 작업에서 생성된 파일을 정확히 소비하도록 하는 것입니다. 공유 인프라(shared infrastructure)는 그것 없이는 어떤 수락 기준도 작동할 수 없는 경우에만 가장 먼저 올 수 있으며, 오직 그 첫 번째 슬라이스에 필요한 인프라만이 그곳에 속해야 합니다.

이것은 유지할 가치가 있는 경계 제약(boundary constraint)입니다. 이는 계획된 구현을 관찰 가능한 증명과 연결하며, 모든 컴포넌트가 구축될 때까지 통합 리스크가 연기되는 것을 방지합니다. 이를 제거하자 워크플로우는 더 작아졌지만 신뢰성은 떨어졌습니다.

여전히 엄격하게 유지되는 것들

몇 가지 제어 장치들은 여전히 그 비용을 들일 가치가 있습니다:

• 제품 요구 사항 및 주요 설계 결정에 대한 사용자 승인 (User approval).
• 되돌릴 수 없는 작업에 대한 명시적 권한 및 기계적 격리 (Mechanical containment).
• 실제로 기계가 소비하는 경계에서의 정확한 스키마 (Exact schemas).
• 실제 의존성 (Dependencies)이 있는 작업에 대한 계획.
• 수용된 결과에 대한 조기 수직적 증명 (Early vertical proof).
• 완료 전 관찰 가능한 검증 (Observable verification).
• 별도의 관점이 잘못된 확신을 잡아낼 수 있는 독립적인 검토 (Independent review).

위험한 작업의 경우, 샌드박스 (Sandboxes), 제한된 자격 증명 (Restricted credentials), 격리된 파일 시스템 (Isolated filesystems), 그리고 네트워크 제어는 긴 프롬프트 지침보다 더 강력합니다. 이러한 방식은 판단이 불완전할 때조차 폭발 반경을 제한합니다 (limit the blast radius). 반복적인 승인 프롬프트는 더 취약한 대체제입니다. 한 구현 보고서에 따르면 승인율은 높지만 주의력은 감소하고 있다고 기술되어 있으며, 이에 대한 대응책으로 일상적인 프롬프트를 줄이기 위해 자동화된 판단을 사용합니다 (using automated judgment to reduce routine prompts).

동일한 원칙이 워크플로우 전체에도 적용됩니다. 가능한 경우 내구성이 있는 경계를 기계적으로 강제하십시오. 모델이 그 내부에서 되돌릴 수 있는 작업들 사이를 선택하도록 하십시오. 에이전트 우선 엔지니어링 환경에 대한 설명에서도 유사한 원칙을 사용합니다: 최상위 지침을 백과사전이 아닌 목차로 취급하십시오 (treat the top-level instructions as a table of contents rather than an encyclopedia).

내가 현재 던지는 네 가지 질문

나는 이제 기존 규칙을 검토할 때 네 가지 질문을 사용합니다: