2026년 5월 18일, arXiv에 "Code as Agent Harness" (arXiv:2605.18747)라는 서베이 (Survey) 논문이 공개되었습니다. Xuying Ning 등이 참여한 42명의 공동 저작이며, 카테고리는 cs.CL (Computation and Language)과 cs.AI (Artificial Intelligence)입니다.
논문의 주장을 한마디로 요약하면 다음과 같습니다.
Code as the executable and inspectable medium through which agents reason, act, and adapt.
"코드는 에이전트가 추론하고, 행동하고, 적응하기 위한
실행 가능하고 관찰 가능한 매개체(=실행하여 결과를 확인할 수 있는 매개체)이다"
――이것이 논문을 관통하는 핵심 문구(Key phrase)입니다.
코드를 "LLM의 최종 출력"으로 파악하는 기존의 관점에서, 코드를 **operational substrate (동작의 토대)**로 파악하는 관점으로 전환하면 에이전트의 설계가 한 단계 정리하기 쉬워진다는 주장입니다.
이 기사에서는 논문이 제시하는 3층 프레임워크 (Harness Interface / Harness Mechanisms / Scaling the Harness)를 중심으로, Code as Agent Harness의 윤곽과 관련 대표 시스템까지 정리해 나갑니다. Claude Code나 Codex와 같은 기존 코딩 에이전트를 사용해 본 적이 있으며, 그 내부 설계의 정리 축을 원하는 엔지니어를 위한 내용입니다.
논문을 읽기 전에 두 가지 기본 용어를 짚고 넘어가겠습니다. 두 용어 모두 논문 내에서 명확하게 정의되어 있습니다.
An agent harness refers to the software layer that surrounds an LLM with tools, APIs, sandboxes, memory, validators, permission boundaries, execution loops, and feedback channels, thereby turning a stateless model into a functional agent capable of long-running task execution.
하네스(Harness)는 **순수 LLM (stateless model = 상태를 가지지 않는 모델)을 둘러싸는 소프트웨어 계층 (Software layer)**입니다. 도구(Tools), API, 샌드박스(Sandboxes), 메모리(Memory), 검증기(Validators), 권한 경계(Permission boundaries), 실행 루프(Execution loops), 피드백 채널(Feedback channels)과 같은 부품을 주변에 배치함으로써, 단발성 응답 기계에 불과했던 LLM을 장시간의 태스크를 수행할 수 있는 에이전트로 변모시키는 역할을 담당합니다.
이 도식의 포인트는 "LLM 단체"와 "LLM을 에이전트로 만드는 소프트웨어 계층"을 명확히 나누어 생각하는 것입니다. Claude Code나 Codex의 실체는 LLM 그 자체가 아니라, 후자인 하네스 측의 총체입니다. LLM은 그 중심에 놓인 뇌에 해당합니다.
We term this view code as agent harness: code as the executable and inspectable medium through which agents reason, act, and adapt.
논문은 여기서 코드 그 자체를 하네스의 중심에 두는 관점을 제안합니다. 프롬프트나 대화 이력이 아니라, 코드(프로그램, 스크립트, 실행 트레이스, 리포지토리)가 agentic AI의 중심적인 매개체가 되고 있다는 주장입니다. 그 근거는 초록(Abstract)에 기술되어 있습니다.
In emerging agentic systems, code is no longer only a target output. It increasingly serves as an operational substrate for agent reasoning, acting, environment modeling, and execution-based verification.
요점은 "코드는 이제 단순한 출력 대상이 아니라, 추론·행동·환경 모델링·실행 기반 검증을 위한 operational substrate (동작의 토대)로서 기능하고 있다"는 것입니다.
논문은 Code as Agent Harness를 서로 연관된 3개의 계층으로 정리합니다. 이것이 Figure 1의 taxonomy (분류 체계)입니다.
3개 계층은 「인터페이스 (사용법의 입구) → 메커니즘 (작동 원리) → 스케일링 (확장 방법)」 순으로 읽으면 자연스럽게 이해됩니다. 우선 코드를 무엇을 위한 입구로 사용할 것인가(Layer 1), 그것을 작동시키기 위해 어떤 메커니즘이 필요한가(Layer 2), 마지막으로 그것을 복수 에이전트에게 확장하면 어떻게 되는가(Layer 3)라는 흐름입니다.
논문의 결론은 다음 문장으로 마무리됩니다.
By centering code as the harness of agentic AI, this survey provides a unified roadmap toward executable, verifiable, and stateful AI agent systems.
「코드를 agentic AI의 하네스(harness)로 설정함으로써, 실행 가능(executable)·검증 가능(verifiable)·상태를 유지(stateful) 하는 AI 에이전트 시스템을 향한 통합적인 로드맵을 제공한다」는 것이 논문의 목표 선언입니다.
Layer 1은 코드를 「어떤 인터페이스로 사용할 것인가」를 3가지 축으로 정리합니다. 논문의 §2에 대응하며, Figure 2가 개관도입니다.
이 그림의 핵심은 하나의 코드 생성물이 「추론」 「행동」 「환경 모델링」의 3가지 목적으로 분류된다는 점입니다. 동일한 프로그램이라도 무엇을 위해 실행하느냐에 따라 의미가 달라진다는 정리입니다.
에이전트의 추론을 자연어가 아닌 코드를 통한 검증 가능한 계산 (verifiable computation) 으로 외부화하는 방식입니다. 프로그램, symbolic solver (기호적으로 해를 도출하는 솔버, 예: Lean 등의 정리 증명기), execution traces (실행 흔적)를 통해 추론을 실행을 통해 확인할 수 있는 형태로 대체합니다.
대표적인 예로는 DeepSeek-Prover나 Lean4Agent와 같이 수학 정리를 형식 언어로 증명하게 하는 시스템군이 있습니다. Table 1에 「reasoning substrate (추론 토대)로서 code가 기능하는 시스템」이 정리되어 있습니다.
생성된 프로그램이 embodied (신체성을 가진) / GUI / software 환경에 대한 실행 정책 (executable policy = 실행 가능한 행동 지침) 으로 직접 작동하는 방식입니다.
Voyager (Minecraft 내에서 코드를 작성하여 행동), SayCan, RoboCodeX, Code-BT, BOSS 등이 대표적인 예로挙げられています. 자연어 지시를 텍스트로 남겨두는 것이 아니라, 실행 가능한 프로그램으로 변환하여 환경에 투입한다는 공통점이 있습니다. Table 2에 이 「action interface (행동 인터페이스)로서 코드가 기능하는 시스템」이 나열되어 있습니다.
프로그램의 상태, 리포지토리, 실행 트레이스 등이 환경의 상태와 다이내믹스(dynamics)를 표현하는 매체로 기능하는 방식입니다. 에이전트가 조작하는 대상(코드베이스, 파일 시스템, API 상태) 자체가 에이전트가 바라보는 「세계 모델 (world model)」이 된다는 관점입니다.
OpenHands나 Claude Code, Codex와 같은 코딩 에이전트는 리포지토리 자체를 환경 표현으로 다루는 전형적인 사례입니다.
Layer 2는 에이전트의 실행을 지속시키기 위한 기구들을 정리합니다. 논문의 §3에 대응하며, 5가지 요소로 구성됩니다.
각 서브섹션의 원문 제목은 다음과 같습니다.
| § | 원문 제목 |
|---|
| 3.1 | Planning for Agent Harness |
| ... | |
논문이 특히 지면을 많이 할애하고 있는 부분이 Planning과 Memory이므로, 그 두 가지를 깊이 있게 살펴보겠습니다.
에이전트의 태스크 분해 (planning) 기법을 논문은 4가지로 분류하고 있습니다.
| 분류 | 내용 |
|---|
| Linear Decomposition | 순차적인 단일 계열의 분해 |
| Structure-grounded | 계층이나 그래프 구조를 가진 분해 |
| Search-based | 탐색을 통한 해 후보의 생성 및 선별 |
| Orchestration-based | 복수 에이전트 및 컴포넌트 간의 협업을 통한 분해 |
이 그림의 핵심은, Planning(계획)이 단일 기술이 아니라 4가지 서로 다른 전략의 집합체라는 점입니다. 태스크의 형태에 따라 선형 분해(Linear decomposition)로 충분한지, 구조적으로 분해해야 하는지, 탐색(Search)이 필요한지, 혹은 다수의 협업이 필요한지를 구분하여 사용하게 됩니다.
§3.2의 정식 명칭은 「Memory and Context Engineering for Agent Harness」로, 메모리 관리뿐만 아니라 컨텍스트 설계까지 범주에 포함하고 있습니다. Memory(메모리) 측면은 다음 5가지 타입으로 정리됩니다.
| 타입 | 내용 |
|---|
| Working memory | 태스크 실행 중의 일시적인 상태 |
| Semantic memory | 개념·사실·지식 베이스 |
| Experiential memory | 과거 시도의 경험 |
| Long-term memory | 영구적으로 유지되는 정보 |
| Multi-agent memory | 복수 에이전트 간에 공유되는 상태 |
'메모리'라고 한마디로 말해도 5개의 층이 있으며, Working과 Long-term뿐만 아니라 Semantic(지식)·Experiential(경험)·Multi-agent(공유)를 독립적인 축으로 설계할 여지가 있다는 것이 논문의 정리 방식입니다.
💡 자신이 운영하고 있는 하네스(Harness)를 이 5가지 타입에 대입하여 점검해 보면, "Experiential이 빠져 있다", "Multi-agent용 채널이 없다"와 같은 누락을 발견할 수 있는 유용한 정리 방식입니다.
남은 3가지 요소는 다음과 같은 역할을 담당합니다.
§3.3 Tool Use for Agent Harness: 도구 호출(Tool call) 설계 (어떤 도구를 언제 호출할 것인가) -
§3.4 Harness Control through the Plan, Execute, and Verify Loop: 계획(Plan) → 실행(Execute) → 검증(Verify) 루프를 통한 실행 흐름 제어 -
§3.5 Agentic Harness Engineering for Adaptive Harness Optimization: 하네스 자체를 운용하면서 최적화해 나가는 엔지니어링
이것들은 Memory와 더불어, 코드 하네스를 "계속 구동하고 개선하기 위한 메커니즘"으로 위치시킵니다.
Layer 3는 하네스를 단일 에이전트 (Single agent) 에서 복수 에이전트 (Multi-agent) 로 확장하는 scaling(스케일링)에 관한 정리입니다.
논문 §4의 정식 명칭은 「Scaling the Harness: Multi-Agent Orchestration over Code」이며, 끝부분의 "over Code"가 코드를 공유 매체로 삼은 멀티 에이전트 협업에 초점을 맞춘 논문의 논점을 상징합니다.
이 그림의 핵심은 scaling의 중심이 **"공유된 코드 아티팩트(Code artifact)를 통한 협업"**에 있다는 정리입니다. 복수 에이전트가 대화적으로 주고받을 뿐만 아니라, 수정 가능한 코드 자산(리포지토리·공유 파일·상태)을 통해 간접적으로 협업한다는 측면이 강조됩니다.
대표적인 예로, 논문에서는 MetaGPT와 같은 멀티 에이전트 시스템을 듭니다. 에이전트마다 역할(Engineer / Architect / PM 등)을 부여하고, 공통의 문서와 코드를 통해 협업하는 패턴이 코드 하네스의 관점에서 재정리되어 있습니다.
논문에서 언급되는 Code as Agent Harness의 각 레이어를 구현하는 시스템을 용도별로 나열해 둡니다.
| 카테고리 | 대표적인 시스템 |
|---|
| 추론 하네스 (reasoning substrate) | DeepSeek-Prover, Lean4Agent |
| ... | |
이들은 서로 배타적인 그룹이 아니라, 예를 들어 Claude Code는 "execution shell"이면서 "리포지토리를 환경 표현으로 다루는" 방식이고, Voyager는 "reasoning substrate"이면서 "action interface"인 것처럼 여러 역할을 겸하는 시스템이 많습니다.
💡 자신이 다루고 있는 에이전트가 이 표의 어느 카테고리에 해당하는지 살펴보면, 해당 하네스 설계의 "어디에 무게 중심이 놓여 있는지"를 파악하기 쉬워집니다.
논문이 기존의 서베이(Survey) 그룹들과 차별화되는 점을 3가지로 정리합니다.
코드를 "LLM의 최종 생성물 (artifact)"로 취급하는 관점에서, 에이전트의 동작 기반 (operational substrate)으로 취급하는 관점으로의 전환이 본 논문 프레이밍의 핵심입니다.
Interface / Mechanisms / Scaling의 3개 층을 명시적인 분류 체계 (taxonomy)로 제시하고 있는 것이 특징입니다. 기존의 서베이(Survey)들은 "LLM의 능력"이나 "에이전트의 응용 영역"을 축으로 정리하는 경우가 많으며, 코드 하네스 (code harness)의 내부 구조에 초점을 맞춘 정리는 신규성이 있습니다.
논문은 사전에 프롬프트에 대해 생성된 code뿐만 아니라, 실행 중에 에이전트 스스로가 동적으로 생성 및 개정하는 code에 강력하게 초점을 맞추고 있습니다. Voyager와 같은 시스템이 시간이 흐름에 따라 스킬 라이브러리를 축적해 나가는 프로세스나, Claude Code가 작업 중에 보조 스크립트를 작성하는 동작을 하네스 설계의 중심 문제로 재정의하는 관점입니다.
논문은 3가지 요소를 구분하는 것도 강조하고 있습니다 (원문 표기에 가깝게 표시합니다).
Model-internal capabilities (모델 자체의 능력) -
System-provided harness infrastructure (시스템 기반 인프라) -
Agent-initiated code artifacts (에이전트가 실행 중에 만드는 코드 결과물)
이 세 가지를 혼동하지 않고 각각을 독립된 연구 축으로 다루자는 것이 논문의 태도입니다. 특히 세 번째인 "agent-initiated code artifacts"는 논문 전체의 키 프레이즈인 "code as ..."와 직결되는 용어이므로, "code"를 빠뜨리지 않고 파악하는 것이 중요합니다.
논문의 §5 「Emerging Fields and Open Problems」에서는 Code as Agent Harness의 향후 과제가 논의되고 있습니다. 초록(Abstract) 및 서론(Introduction)에서 읽어낼 수 있는 주요 논점을 정리해 둡니다.
| 과제 | 내용 |
|---|
| Verifiability | 생성 및 실행되는 코드의 검증 가능성을 어떻게 담보할 것인가 |
| Stateful execution | 장기적인 상태 유지 및 업데이트 설계 |
| Safety / Sandboxing | 실행 기반 에이전트가 부작용(side effect)을 가질 수 있는 환경에서의 안전성 |
| Multi-agent scaling | 공유 코드 아티팩트 (code artifact)를 통한 협업의 규율 |
| Optimization | 하네스 자체의 자동 최적화 |
실무적인 관점에서 말하자면, 여기서 언급된 과제들은 각각 기존 시스템들이 부분적으로 다루고 있는 영역이기도 합니다. sandboxing은 Docker나 Firecracker를 통한 격리, stateful execution은 벡터 스토어(vector store)나 세션 DB의 활용, multi-agent scaling은 MetaGPT와 같은 패턴을 통해 부분적으로 해결되어 왔습니다.
논문의 공헌은 이것들을 **"코드를 중심으로 세운 하네스"**라는 공통된 틀 안에서 논의할 수 있도록 정리된 체계를 제공했다는 점에 있습니다.
⚠️ 논문은 서베이(Survey)이므로, 개별 기법의 신규성이 아니라 "분야 전체의 정리 축"을 제공하는 것이 목적입니다. 새로운 기술을 직접 가져오는 것이 아니라, 기존 기술의 조감도로 읽는 것이 올바른 활용법입니다.
"Code as Agent Harness"라는 키 프레이즈를 통해 논문이 전달하고자 하는 것은 하나로 집약될 수 있습니다.
코드는 에이전트의 최종 생성물이 아니라, 에이전트가 작동하기 위한 실행 기반이다라는 관점입니다.
이 관점이 정립되면, Claude Code나 Voyager처럼 언뜻 보기에는 별개의 것으로 보이는 시스템들을 동일한 분류 체계 (taxonomy) 위에서 비교할 수 있게 됩니다.
본 기사 범위 내에서 기억해 두면 도움이 될 점은 3가지입니다.
| # | 핵심 메시지 |
|---|
| ① | Harness의 정의는 "LLM을 tools / sandbox / memory / validator / loops로 둘러싸는 소프트웨어 계층"이다. LLM 단독 모델과 Harness를 분리하여 생각해야 한다 |
| ② | Code as Agent Harness는 3개 계층으로 정리된다: Interface (추론 / 행동 / 환경 모델화) → Mechanisms (Planning / Memory / Tool Use / Control / Optimization) → Scaling (Multi-agent) |
| ③ | 본 논문의 기여는 code를 "artifact"에서 "operational substrate"로 재정의한 프레이밍(framing)과, interface / mechanisms / scaling의 명시적인 분류 체계 (taxonomy)에 있다 |
논문에는 GitHub의 Awesome 리스트(YennNing/Awesome-Code-as-Agent-Harness-Papers)도 함께 제공되므로, 관련 논문을 추적하고 싶다면 이곳을 기점으로 삼는 것이 효율적입니다.
- arXiv:2605.18747 / Code as Agent Harness ― 본 기사의 기반이 된 arXiv preprint (2026-05-18 공개, CC BY 4.0)
- arXiv HTML 버전 ― 구조화된 브라우저 열람용
- Awesome-Code-as-Agent-Harness-Papers (GitHub) ― 논문 부속 리포지토리
