코드를 에이전트 하네스로: 실행 가능·검증 가능·상태 유지 에이전트 시스템을 향하여

📌 한입 요약
Context — LLM 에이전트가 코드를 짜는 능력은 빠르게 좋아졌지만, “방금 짠 코드를 실제로 돌려보고, 실패하면 고치고, 그 결과를 기억해 다음 행동에 잇는” 장기·다단계 자율성은 여전히 불안정하다. 저자들은 그 병목이 모델의 추론력이 아니라, 모델 출력을 지속 상태·장기 행동으로 잇는 시스템 신뢰성에 있다고 본다.

Insight — 기존 서베이는 코드를 LLM의 최종 산출물(output)로만 봤다. 이 논문의 깨달음은 코드가 산출물이 아니라 에이전트가 추론·행동·환경모델링·검증을 수행하는 운영 기질(operational substrate, 에이전트가 그 위에서 살아 움직이는 실행 기반) 즉 agent harness라는 것이다 — 코드를 “에이전트가 거주하는 집”으로 보는 관점 전환이다. 특히 model-internal 능력이나 시스템이 깔아준 인프라와 구분되는 agent-initiated code artifacts(에이전트가 스스로 만든 회귀테스트·임시 도구·재사용 스킬·중간 프로그램 상태)에 초점을 맞춘다.

Solution — 이 관점에서 좋은 harness란 executable(기계가 실행)·inspectable(들여다봄)·stateful(상태 유지)·governed(통제됨)한 프로그램이며, 에이전트는 계획을 상태전이 계약으로 삼아 샌드박스에서 실행하고 **결정론적 센서(deterministic sensors, 컴파일러·테스트·퍼저처럼 확률 없이 통과/실패를 판정하는 검증기)**로 continue/revise/HITL(human-in-the-loop, 사람 개입)을 결정하는 Plan-Execute-Verify 루프를 돈다.

Evidence — 단일 실험이 아닌 서베이로서, 코드를 (i) 추론·(ii) 행동·(iii) 환경 인터페이스로 보는 3층 taxonomy(§2)와 계획·메모리·도구·PEV·Agentic Harness Engineering의 메커니즘 층(§3), 다중에이전트 스케일 층(§4)으로 문헌을 조직하고, code assistants/ GUI·OS/ embodied/ scientific discovery/ personalization의 5개 program-world 응용 도메인과 7대 open problem으로 마무리한다. 다중에이전트에서 표현 수준을 implicit→file-only→ repository→ execution→ blackboard 4단계로 정렬하고, “묵시적 harness 상태가 취약성의 근원이며 토폴로지 복잡도가 harness 형식성과 반비례한다”는 패턴을 제시한다.

Implication — 자율 에이전트의 다음 도약을 더 큰 모델이 아니라 “harness engineering의 과학”으로 재프레이밍한다 (arXiv:2605.18747).

흐름 따라 읽기

논지 흐름(throughline): 코드가 에이전트 루프에 들어오는 순서가 곧 논증의 척추다 — §2 코드는 추론·행동·환경을 실행/검사/상태화하는 harness 인터페이스로 진입한다 → §3 그 인터페이스를 시간축에서 신뢰성 있게 유지하는 harness 메커니즘(계획·메모리·도구·Plan-Execute-Verify·Agentic Harness Engineering) → §4 단일을 넘어 공유 코드 산출물 위에서 조율·검증하도록 harness를 스케일(shared code-centric harness substrate, central gap) → §5 5개 program-world 응용에서 구체화되며 공통 난제(harness engineering의 과학)를 드러낸다. 관통 명제: executable+inspectable+stateful(+governed) 프로그램이 추론·행동·환경·피드백·검증을 하나의 기질로 통합한다.

1. Introduction — 코드를 운영 기질로 재정식화

이 섹션은 논문 전체의 출발점으로서, LLM 에이전트 시스템에서 코드의 역할이 단순 생성 산출물(generated artifact)을 넘어 추론·행동·환경 모델링·실행 기반 검증을 가능하게 하는 운영 기질(operational substrate)로 전환되고 있음을 선언하고, “code as agent harness”라는 통합 시각과 서베이의 3층 분석 체계를 도입한다. 기존 LLM은 competitive programming부터 repository 수준 소프트웨어 엔지니어링까지 코드를 강력히 생성·이해해 왔으나, 에이전트 시스템에서는 프로그램이 중간 계산을 외부화(externalize)하는 추론 매체, 로봇·GUI 환경과의 상호작용을 위한 실행 정책(executable policy), 그리고 환경 상태와 역학(dynamics)을 구조적으로 표현하는 수단으로 확장되고 있다. 이러한 전환을 개념화하기 위해 저자들은 agent harness — 즉 LLM을 도구·API·샌드박스·메모리·검증기·권한 경계·실행 루프·피드백 채널로 감싸는 소프트웨어 계층 — 라는 시스템 수준 렌즈를 도입하고, 자율성의 병목이 기반 모델의 추론 능력만이 아니라 모델 출력을 장기 행동과 영속 상태에 연결하는 시스템 신뢰성에도 있다고 강조한다. 코드의 역할을 명확히 하기 위해 저자들은 세 결합 요소를 구분한다: (1) model-internal capabilities(모델 내부 추론·계획·평가 능력), (2) system-provided harness infrastructure(사전 정의된 도구·API·샌드박스 등 외부 행동 연결 계층), (3) agent-initiated code artifacts(에이전트가 태스크 실행 루프 안에서 직접 생성·실행·수정·공유하는 회귀 테스트·임시 도구·DSL 프로그램·재사용 가능 스킬 같은 상호작용 코드 객체). 기존 서베이들이 코드를 주로 LLM의 최종 산출물로 취급한 것과 달리, 이 논문은 agent-initiated code artifacts에 초점을 맞추어 코드가 인터페이스·에이전트 능력·다중 에이전트 조율의 조직 중심(organizing center)으로 기능하는 방식을 탐구한다.

저자 기여(Contributions)

개념적 재틀짜기(Conceptual framing): “code as agent harness”를 정식화하여 코드를 생성 산출물에서 실행 가능하고(executable) 검증 가능하며(verifiable) 상태를 보유하는(stateful) AI 에이전트 시스템의 운영 기질(operational substrate)로 재정의한다.
분류 체계 및 종합(Taxonomy and synthesis): code as agent harness를 세 연결 층(harness interfaces / harness mechanisms / scaling harness)으로 조직하고 대표 방법론들을 체계적으로 종합한다.
응용 및 향후 과제(Applications and future agenda): 분류 체계를 coding assistance, GUI/OS 자동화, 과학적 발견, 개인화, 구현(embodied) 에이전트 등 실세계 응용 도메인에 연결하고, 평가·검증·안전성·조율 측면의 핵심 미해결 과제를 제시한다.

2. Harness Interface — 코드: 추론·행동·환경 인터페이스

§2는 이 서베이의 핵심 논지, 즉 “코드가 에이전트의 운영 기질(harness, 에이전트를 구동하는 실행 틀)로 기능한다”는 주장을 세 역할—추론(Reasoning)·행동(Acting)·환경(Environment)—으로 분해하여 실증하는 섹션으로, 이후 §3의 하네스 메커니즘 논의를 위한 인터페이스 계층을 정의한다. §2.1 Code for Reasoning은 순수 자연어 추론의 한계를 극복하기 위해 코드를 모델과 하네스 사이의 실행 인터페이스로 도입하며, 세 패러다임으로 세분된다: 외부 인터프리터에 연산을 위임하는 Program-Delegated Reasoning(PAL, PoT, CodeI/O 등), Lean·Coq 같은 증명 보조기(proof assistant)와 SMT 솔버를 활용해 각 추론 단계를 기계적으로 검증하는 Formal Verification and Symbolic Reasoning, 그리고 생성-실행-검증-수정의 폐루프(closed loop)를 반복하며 실행 트레이스(execution trace, 런타임 실행 기록)와 강화학습 보상으로 추론을 정제하는 Iterative Code-Grounded Reasoning(CodePRM, RLEF 등). §2.2 Code for Acting은 코드를 고수준 언어 의도를 실행 가능한 행동으로 변환하는 제어 인터페이스로 사용하며, 사전 정의된 스킬 라이브러리에서 환경 실현 가능성(affordance)을 고려해 행동을 선택하는 Grounded Skill Selection(SayCan, KnowNo), 언어 모델이 Python 정책 코드나 행동 트리(behavior tree)를 직접 생성하는 Programmatic Policy Generation(CaP, RoboCodeX, Code-BT), 그리고 Voyager처럼 실행 가능한 스킬 라이브러리를 장기적으로 축적·진화시키는 Lifelong Code-Based Agents로 구성된다. §2.3 Code for Environment는 환경 상태와 전이 동역학을 프로그램·시뮬레이터·실행 트레이스·테스트로 구체화하여 에이전트가 쿼리·편집·검증할 수 있게 하며, ViStruct·PoE-World의 Structured World Representations, WorldCoder·CWM의 Execution-Trace World Modeling, SWE-bench·InterCode의 Code-Grounded Evaluation Environments, SWE-smith·EnvScaler의 Verifiable Environment Construction으로 분류된다. 이 서베이의 **스코프 경계(scope boundary)**는 다음과 같다: “코드”는 프로그램·스크립트·형식 명세·API 스키마·테스트·시뮬레이터·실행 트레이스 등 실행 가능하거나 기계 검증 가능한 아티팩트를 뜻하며, 원시 지각(raw perception)·물리적 신체 상태·인간 의도·모델 내부 잠재 추론은 그 자체로 코드가 아니다—이것들은 코드 인터페이스를 통해 감지·직렬화·검증될 수 있지만 코드와 혼동해서는 안 된다.

3. Harness Mechanisms — 계획·메모리·도구·제어·최적화

§3은 §2에서 정의한 코드-as-harness 인터페이스를 단일 생성 단계를 넘어 장기 실행 중에도 신뢰성 있게 유지하기 위한 5개 조정 메커니즘을 다루며, 이 메커니즘들이 §4 다중에이전트 스케일의 기반을 형성한다. 먼저 **3.1 플래닝(Planning)**은 목표를 선형 분해(single explicit step sequence), 구조 기반(dependency·repo graph 등 외부 구조에 그라운딩), 검색 기반(inference-time compute를 활용한 다중 후보 탐색), 오케스트레이션 기반(역할·단계·피드백 라우팅을 통한 시스템 수준 조율)의 네 유형으로 외재화하여 에이전트 행동 궤적을 제어하는 하니스 제어 레이어로 정의한다. **3.2 메모리 및 컨텍스트 엔지니어링(Memory & Context Engineering)**은 활성 컨텍스트 창과 확장 일로의 태스크 상태 사이의 근본적 긴장을 해소하기 위해 작업 메모리(현재 수리 궤적 유지), 의미 메모리(저장소 구조에 정렬된 증거 검색), 경험 메모리(태스크 간 재사용 가능한 수리 전략 축적), 장기 메모리(검증된 커밋·솔루션의 지속 보존), 다중에이전트 메모리(역할 간 공유 블랙보드) 다섯 유형으로 상태를 계층 관리하며, 컨텍스트 압축(context compaction)과 상태 오프로딩(state offloading)으로 활성 컨텍스트와 내구 저장 간 경계를 조율한다. **3.3 도구 사용(Tool Use)**은 모델 의도와 외부 시스템 간의 통제된 인터페이스로서, API·문서 검색 중심의 기능 지향(function-oriented), 저장소·셸·샌드박스 내에서 직접 행동하는 환경 상호작용(environment-interaction), 테스트·린터·정적 분석기 등을 결정론적 센서(deterministic sensors)로 삼는 검증 주도(verification-driven), 그리고 라이프사이클 훅(lifecycle hook)·권한 정책·인간 승인 게이트로 이 모든 것을 조율하는 워크플로 오케스트레이션(workflow-orchestration)으로 분류된다. **3.4 Plan-Execute-Verify(PEV) 루프(계획-실행-검증 제어 루프)**는 코드 에이전트의 반복적 디버깅을 하니스 수준 제어 과정으로 재구성하며, 세 단계로 구성된다: 계획 단계는 의도한 변경 사항·불변 조건·검증 명령·롤백 지점을 명시한 상태 전이 계약(contract over intended state transition)을 형성하고, 실행 단계는 읽기 전용→샌드박스 편집→전체 접근의 다중 계층 권한(multi-tier permission) 하에 격리된 샌드박스 환경에서 변경을 적용하며, 검증 단계는 컴파일러·타입 체커·단위 테스트·CI 파이프라인 등 결정론적 센서를 통해 새 상태를 제약 조건과 비교하고 그 결과에 따라 계속·수정·인간 검토 에스컬레이션(HITL, Human-in-the-loop) 여부를 결정한다. **3.5 에이전틱 하니스 엔지니어링(AHE, Agentic Harness Engineering)**은 하니스 자체를 최적화 대상으로 삼는 세 가지 보완적 접근으로 구성된다: 딥 텔레메트리(deep telemetry)는 프롬프트·토큰 비용·도구 인자·샌드박스 스냅샷·테스트 결과 등을 구조화된 추적 기록으로 연결하여 하니스 수정을 일화적 디버깅에서 비교 진단으로 전환하고, 에볼루션 에이전트(Evolution Agent)는 이 텔레메트리를 입력 삼아 프롬프트 템플릿·검색 정책·도구 스키마·권한 규칙·워크플로 위상 등 하니스 구성요소를 개정 후보로 제안·평가·승격하는 메타 수준 에이전트이며, 통제된 하니스 변이(governed harness mutation)는 에볼루션 에이전트 자체도 PEV 루프 안에 두어 모든 하니스 변경이 격리 평가 환경에서 실행·검증되고 권한 경계나 인간 검토 요구 사항을 변경하는 경우 반드시 HITL 승인을 거치도록 강제함으로써 무제한 자기수정을 방지한다. 결과적으로 §3의 다섯 메커니즘은 모델 판단(계획), 가변 태스크 상태(메모리), 실행 기반 행동(도구), 사이버네틱 제어(PEV 루프), 하니스 자체의 측정·개선(AHE)을 유기적으로 연결하여, 코드를 단순 출력물이 아닌 경계·관찰 가능·수정 가능한 하니스 매체로 운용하는 완결된 제어 기반을 형성한다.

4. Scaling the Harness — 코드 위의 다중에이전트 조율

§4는 논문 thesis(“코드=agent harness”)를 단일 에이전트에서 다중 에이전트 체제로 확장하는 핵심 전환부로, 공유 코드 산출물을 단일 기질(substrate, 에이전트들이 공통으로 읽고 쓰는 토대)로 삼아 harness 자체를 모듈화·검사 가능하게 만드는 방법을 체계화한다. 4.1에서는 다중 에이전트 협업의 세 차원—기능 역할 특화(program synthesis·understanding·verification·execution·planning 역할 분리), 공유 프로그램 상태에 기반한 상호작용 모드(collaborative synthesis·critique-and-repair·adversarial validation·reasoning debate), 워크플로 토폴로지(체인·사이클·계층·스타 등 사전 정의 방식과, 실행 피드백으로 DAG를 동적 재구성하는 EvoMAC·SEW·FlowReasoner 같은 목표 지향·적응형 방식)—을 분류한다. 4.2는 코드의 실행 가능성에서 비롯되는 객관적 오라클(oracle, 실행 결과로 정답을 판별하는 신호) 신호들—컴파일러·문법 오류, 테스트 pass/fail, 퍼저(fuzzer) 크래시 트레이스, 정적 분석 경고(CWE 취약점), 성능 프로파일링, MAGE의 클록 에지(clock-edge) 단위 파형 시뮬레이션—을 유형화하고, 공유 harness 동기화 메커니즘으로 공유 블랙보드(blackboard, 모든 에이전트가 읽고 쓰는 전역 상태 저장소)·병렬 브랜치 병합·구조화된 컨텍스트 스케줄링·계층 메모리·에이전트 풀 확장을 서술한다. 4.3은 논문의 포지션(position, 저자 주장 제안)으로 “공유 코드 중심 harness 기질”을 제안하며, 기존 시스템이 공유 harness를 표현하는 방식을 네 수준—묵시적/파일 전용(implicit/file-only), 레포지토리 기반(repository-based), 실행 기반(execution-based), 블랙보드/공유 상태(blackboard/shared-state)—으로 분류한다. 이어서 “central gap”을 진단하는데, 문헌의 대다수 시스템이 묵시적·파일 전용 표현에 머물러 공유 harness 상태의 공식 모델이 없으며, 코드가 실행 가능한 아티팩트임에도 그 객관적 신호를 아키텍처 수준에서 활용하지 못하고 있다고 지적한다. harness 상태 수렴(convergence, 반복 종료 조건) 패턴은 여섯 가지—정확성 수렴(test-gated), 보안 수렴(CWE·퍼저 기준), 성능 수렴(실행 시간·메모리 임계치), 점수 기반 수렴(시뮬레이션 불일치 스코어 등), 합의 수렴(다수결 패널), 묵시적 수렴(고정 반복 횟수 종료)—으로 유형화되며, 묵시적 수렴의 만연 자체가 공식 기질 부재의 직접적 귀결임을 논증한다. 4.4는 교차하는 설계 패턴을 도출한다: 묵시적 harness 상태는 시스템 취약성의 기술적 근원이며, 코드 매개 채널(파일·테스트·로그 등)도 조율 병목을 제거하지 못하고, 실행 피드백은 언어적 추론과 형식적 검증 사이의 가교이며(LLM 시뮬레이션이 높은 정밀도를 보이는 경우도 있으나 런타임 크래시·자원 고갈 같은 코너 케이스에서는 실제 실행이 필수), 레포지토리 기반(정적 구조)과 실행 기반(동적 행동) 표현은 상보적이지만 어떤 시스템도 둘을 단일 기질로 통합하지 못했으며, 토폴로지 복잡도는 harness 기질의 형식성과 반비례하여 공식 기질이 명확할수록 단순한 토폴로지로 충분하다는 경향이 관찰된다.

5. Emerging Fields and Open Problems — Program World와 7대 난제

§5는 코드=agent harness라는 논문 전체 thesis를 5개 구체적 응용 도메인에 투영해 그 실체성을 입증하고, 이어서 패러다임이 공통적으로 안고 있는 7대 미해결 난제를 열거함으로써 “harness engineering의 과학”을 정립할 것을 촉구한다. 5.1의 다섯 도메인은 각각 부분관찰 가능한 실행 세계(program world, 즉 상태·행동·전이함수가 모두 코드로 정의되는 환경)로 재서술된다: 코드 어시스턴트(code assistants)는 저장소(repository)·테스트·CI/CD 파이프라인을 harness 삼아 자율 소프트웨어 엔지니어링 루프를 형성하고; GUI/OS 에이전트는 DOM·접근성 트리(accessibility tree)·스크린샷을 관측으로 받아 Python/JavaScript 액션을 실행하며 전이함수 자체가 브라우저 엔진이나 OS인 프로그램 세계에서 동작하고; 자율 구현 에이전트(autonomous embodied agents)는 물리 시뮬레이터와 계층화된 harness(의미 계획층 → 코드 안전 경계 → 로봇 컨트롤러)를 통해 재사용 가능 스킬 라이브러리를 축적하며; 과학 발견 에이전트(agents for scientific discovery)는 가설·프로토콜·분석을 모두 실행 가능한 프로그램 객체로 전환해 자율실험실(self-driving laboratory)과 폐쇄형 생성-실행-피드백 루프를 구현하고; 개인화 에이전트(personalization agents)는 사용자 선호를 편집 가능한 구조화 상태(editable preference state)로 유지하되, 자동화 참여 지표(engagement proxy)의 신뢰성 부재라는 고유 한계를 안는다. 5.2의 7대 open problem은 이 모든 도메인에 공통적으로 출현한다: (1) harness 수준 평가 및 oracle 적정성(oracle adequacy) — 실행 가능한 검증기가 의도한 명세를 충분히 포착하는지 묻는 문제; (2) 실행 너머 의미 검증(semantic verification beyond executable feedback) — 테스트 통과가 완전한 정확성을 보장하지 않으므로 범위가 명시된 다중 검증 스택이 필요하다는 문제; (3) 회귀 없는 자기진화 harness(self-evolving harnesses without regression) — harness 수정 자체를 안전 임계 코드 변경으로 다뤄야 한다는 문제; (4) 트랜잭션 공유 프로그램 상태(transactional shared program state)와 의미적 충돌 해결 — 다중 에이전트가 계획·테스트·메모리를 공유할 때 파일 diff를 넘어 가정(assumption) 수준의 충돌을 처리해야 한다는 문제; (5) 인간-참여 안전성과 책임(human-in-the-loop safety and accountability)의 harness 상태화 — 승인·거부·정책 예외가 지속 가능한 harness 상태 전이로 기록되어야 한다는 문제; (6) 멀티모달 코드-harness 시스템 — 시각·물리 피드백을 교정된 증거(calibrated evidence)로 다루어 장기 자율성을 확보해야 한다는 문제; (7) harness engineering의 과학(science of harness engineering) 정립 — 모델이 아닌 완전한 폐쇄 루프 시스템을 연구 대상으로 삼아 실행 가능(executable)·검사 가능(inspectable)·상태 유지(stateful)·거버넌스 준수(governed)라는 4대 속성을 동시에 충족하는 설계 원칙을 수립해야 한다는 문제다.

축	본 논문 [Code as Agent Harness, 2605.18747, survey]	AutoHarness [2603.03329, alternative/method]	What Makes a Harness a Harness [2606.10106, direct/conceptual]	RHO [2606.05922, alternative/method]	MemCoder [2603.13258, base/method]
(1) 논문 유형	서베이/포지션 페이퍼 (실험 없음)	방법론/실험 논문	개념 분석 (정의 논문, 실험 없음)	방법론/실험 논문	방법론/실험 논문
(2) 핵심 아이디어	코드를 LLM 에이전트의 운영 기반(harness)으로 프레이밍; harness interface → mechanism → multi-agent scaling 3계층으로 정리; “shared code-centric harness substrate” 포지션 제안	Gemini-2.5-Flash가 환경 피드백 기반 반복 정제로 코드 하네스를 자동 합성; illegal move를 사전 차단하는 구조적 강제 + 전체 정책을 코드로 생성	”agent harness”의 필요충분 조건을 구성적으로 정의; 계보 추적 + 6개 실제 하네스(Claude Code, Codex CLI, Aider, Cline, OpenHands, SWE-agent)에 포함/제외 테스트 적용	과거 궤적만 활용한 자기지도 하네스 최적화(RHO); ground-truth validation set 없이 자기선호(self-preference)로 피드백 대체	커밋 히스토리에서 intent→code 매핑을 증류하는 구조적 메모리로 코드 에이전트를 강화; 자기 정제(self-refinement) 통합
(3) 하네스 범위	전범위: interface + mechanism + multi-agent scaling	Interface 층 중심 (illegal action 방지, 정책 코드화)	정의·계보 층 (harness 개념 자체의 경계 획정)	Mechanism 층 중심 (최적화·자기개선 루프)	Mechanism 층 중심 (메모리·지식 증류)
(4) 하네스 자기개선?	미적용 (조망·분류만)	부분적 — 환경 피드백 기반 반복 합성(iterative synthesis)	해당 없음 (정의 논문)	핵심 기여 — 과거 궤적 기반 자기지도 최적화 1라운드로 SWE-Bench Pro 59%→78%	자기 정제 루프 포함 (생성 후 검증·재시도)
(5) 실증 평가 / 벤치마크	없음 (서베이)	145개 TextArena 게임; illegal move 완전 차단; 더 큰 모델 대비 비용 효율 우위	없음 (사례 분석 6건)	SWE-Bench Pro: 59% → 78% (1라운드)	SWE-bench Verified SOTA; DeepSeek-V3.2 대비 +9.4%
(6) 코드 공개	❌ (서베이)	✅	❌	✅	✅
(7) 본 논문과의 관계	— (본 논문)	본 논문 프레임의 “interface/mechanism” 층을 구체화하는 방법 논문; 하네스 자동 합성이라는 새 방향을 예시	본 논문과 동일 개념 공간을 다루는 정의 논문 — “무엇이 harness인가(de Macedo) + 왜 코드가 harness여야 하는가(본 논문)” 쌍	본 논문 “mechanism” 층의 최적화 시나리오를 실증	본 논문 “mechanism” 층의 메모리·지식 관리 시나리오를 실증

원자적 인사이트 (Zettelkasten)

💡 코드는 LLM의 산출물이 아니라 에이전트의 운영 기질(harness)이다

코드를 LLM이 뱉는 최종 결과물로 보던 관점을, 에이전트가 추론·행동·환경모델링·검증을 모두 그 위에서 수행하는 운영 기질(operational substrate=agent harness)로 뒤집는다. 핵심은 세 가지를 구분하는 것이다: 모델 내부 능력(model-internal capabilities), 시스템이 제공한 인프라(system-provided harness infrastructure), 그리고 에이전트가 스스로 만든 코드 아티팩트(agent-initiated code artifacts — 회귀테스트·임시 도구·DSL·재사용 스킬·중간 프로그램 상태). 기존 서베이가 다룬 것은 첫째·둘째에 가깝고, 이 논문의 독창성은 셋째에 초점을 둔 데 있다.

조건/맥락: 코드는 실행 가능·기계 검증 가능한 아티팩트(프로그램·명세·API 스키마·테스트·시뮬레이터·트레이스)로 한정 — 원시 지각, 물리적 신체, 인간 의도, 내부 잠재 추론은 명시적으로 “코드 아님”으로 배제.
활용: 에이전트 시스템을 설계·평가할 때 “이 능력은 모델 안인가, 인프라인가, 에이전트가 생성한 아티팩트인가”를 분류하는 진단 프레임.

💡 자율성의 병목은 모델 추론력이 아니라 시스템 신뢰성이다

에이전트 자율성을 막는 진짜 한계는 모델이 더 똑똑해지면 풀리는 추론력 문제가 아니라, 모델 출력을 장기 행동과 지속 상태로 안정적으로 잇는 시스템 신뢰성에 있다는 재프레이밍이다. 이로써 다음 도약의 레버를 “더 큰 모델”에서 “harness engineering의 과학”으로 옮긴다 — harness가 executable(실행)·inspectable(검사)·stateful(상태)·governed(통제) 4속성을 갖추는 것이 핵심 설계 목표가 된다.

조건/맥락: 장기·다단계·상태 유지가 필요한 자율 에이전트에 해당. 단발성 질의응답에는 병목 진단이 다르게 적용된다.
활용: 성능 개선 투자를 모델 스케일업 vs harness 인프라(검증·상태관리·거버넌스) 중 어디에 둘지 결정하는 논거.

💡 Plan-Execute-Verify 루프는 결정론적 센서로 신뢰를 만든다

PEV 루프에서 계획은 단순 지시가 아니라 “상태전이 계약(state-transition contract)“으로 취급되고, 실행은 샌드박스 안에서 다계층 권한으로 격리되며, 검증은 확률적 LLM 판정 대신 결정론적 센서(deterministic sensors — 컴파일러·테스트·퍼저·정적분석)로 continue/revise/HITL을 결정한다. 핵심은 검증을 LLM 자기평가가 아닌 기계가 통과/실패를 단정하는 오라클에 맡겨, 에이전트 행동에 검증 가능성(verifiability)을 주입하는 것이다.

조건/맥락: 컴파일러·테스트처럼 결정론적 오라클이 존재하는 도메인(코드·구조화 환경)에서 강력. 의미적 정합성처럼 실행만으로 판정 안 되는 검증은 open problem(§5).
활용: 에이전트 워크플로에 “어떤 결정론적 센서를 어느 단계에 끼울 수 있는가”를 설계 체크리스트로 삼아 신뢰성 있는 루프 구성.

💡 다중에이전트의 취약성은 묵시적 harness 상태에서 온다

여러 에이전트가 협업할 때 공유 상태(shared harness state)의 표현 수준은 implicit→file-only→repository-based→execution-based→blackboard로 정렬되는데, 가장 아래의 묵시적(implicit) 상태 — 어디에도 명시적으로 기록되지 않고 암묵적으로 가정되는 상태 — 가 시스템 취약성의 근원이다. 더 나아가 토폴로지 복잡도와 harness 형식성(formality)이 반비례하는 패턴, 즉 협업 구조가 복잡해질수록 공유 기질이 덜 형식화되는 경향이 관찰된다. 정적 구조와 동적 행동을 통합한 공식 기질의 부재가 “central gap”으로 지목된다.

조건/맥락: 다중에이전트 협업(역할 특화·적응형 토폴로지) 맥락. 단일 에이전트에는 central gap 진단이 직접 적용되지 않는다.
활용: 멀티에이전트 신뢰성을 높이려면 묵시적 상태를 명시적·실행 가능·트랜잭션 가능한 공유 기질로 끌어올리는 것을 우선 과제로.

핵심 용어 정리

용어	정의
Agent harness	에이전트가 추론·행동·환경모델링·검증을 그 위에서 수행하는 운영 기질(operational substrate). 코드를 에이전트의 산출물이 아니라 “거주 환경”으로 보는 개념.
Code as agent harness	코드를 LLM의 최종 산출물이 아닌, 에이전트 인프라의 중심 기질로 정식화한 본 논문의 핵심 명제.
Executable / Inspectable / Stateful / Governed	좋은 harness가 갖춰야 할 4속성: 기계가 실행 가능 / 들여다보고 검사 가능 / 상태를 지속 유지 / 거버넌스로 통제됨.
Agent-initiated code artifacts	에이전트가 스스로 생성한 코드 산출물 — 회귀테스트, 임시 도구, DSL, 재사용 스킬, 중간 프로그램 상태. 본 논문이 새로 초점을 둔 범주.
Plan-Execute-Verify (PEV) loop	계획(상태전이 계약)→실행(샌드박스·다계층 권한)→검증(결정론적 센서로 continue/revise/HITL 결정)을 반복하는 에이전트 제어 루프.
Deterministic sensors	확률적 LLM 판정 대신 통과/실패를 단정하는 결정론적 검증기(컴파일러·테스트·퍼저·정적분석). PEV의 검증 단계를 떠받침.
Agentic Harness Engineering	에이전트가 자신의 harness를 진화시키는 메커니즘: deep telemetry→Evolution Agent→통제된 harness mutation(변경도 PEV 루프·HITL 통제 하).
Evolution Agent	텔레메트리를 받아 harness를 개선·변형하는 메타 수준 에이전트. 회귀 없는 자기진화가 미해결 과제로 남음(§5).
Shared code-centric harness substrate	다중에이전트가 공유하는 코드 중심 기질. 표현 수준이 implicit→file-only→repository→execution→blackboard 4단계로 정렬됨.
Harness-state convergence	다중에이전트가 공유 harness 상태에서 수렴하는 6종 기준: correctness / security / performance / score / consensus / implicit.
Central gap	정적 구조와 동적 행동을 하나로 통합한 공식 기질이 부재한 다중에이전트의 핵심 공백.
Program world	에이전트가 프로그램으로 환경을 표현·조작하는 응용 영역 — code assistants, GUI/OS, embodied, scientific discovery, personalization 5개 도메인.
HITL (Human-in-the-loop)	검증 결과에 따라 사람이 개입해 승인·수정하는 안전 장치. 그 안전성·책임성을 harness 상태로 다루는 것이 open problem.

BibTeX

@article{ning2026code,
  title={Code as Agent Harness --- Toward Executable, Verifiable, and Stateful Agent Systems},
  author={Ning, Xuying and others},
  journal={arXiv preprint arXiv:2605.18747},
  year={2026},
  url={https://arxiv.org/abs/2605.18747},
  eprint={2605.18747},
  archivePrefix={arXiv},
  primaryClass={cs.CL}
}

코드를 에이전트 하네스로: 실행 가능·검증 가능·상태 유지 에이전트 시스템을 향하여

코드를 에이전트 하네스로: 실행 가능·검증 가능·상태 유지 에이전트 시스템을 향하여

흐름 따라 읽기

1. Introduction — 코드를 운영 기질로 재정식화

2. Harness Interface — 코드: 추론·행동·환경 인터페이스

3. Harness Mechanisms — 계획·메모리·도구·제어·최적화

4. Scaling the Harness — 코드 위의 다중에이전트 조율

5. Emerging Fields and Open Problems — Program World와 7대 난제

관련 연구 비교 매트릭스

원자적 인사이트 (Zettelkasten)

💡 코드는 LLM의 산출물이 아니라 에이전트의 운영 기질(harness)이다

💡 자율성의 병목은 모델 추론력이 아니라 시스템 신뢰성이다

💡 Plan-Execute-Verify 루프는 결정론적 센서로 신뢰를 만든다

💡 다중에이전트의 취약성은 묵시적 harness 상태에서 온다

핵심 용어 정리

관련 연구

태그

BibTeX