Code as Agent Harness: 코드를 AI 에이전트의 운영 기반(하네스)으로 보는 서베이 논문

9bow · 6월 29, 2026, 6:30오전

Code as Agent Harness 소개

처음으로 규모가 큰 소프트웨어 프로젝트를 맡았던 순간을 떠올려 봅시다. 머릿속으로 멋진 설계를 떠올리는 것만으로는 아무 일도 일어나지 않습니다. 코드를 직접 작성해 실행해 보고, 테스트가 빨간불을 내면 원인을 추적하고, 로그를 뒤지고, 작은 수정을 반복하면서 비로소 동작하는 시스템에 도달합니다. 우리가 일을 해내는 진짜 무대는 머릿속이 아니라 파일, 터미널, 테스트, 실행 환경이 모여 있는 작업 공간입니다.

이 서베이는 최근의 AI 에이전트에게도 똑같은 일이 벌어지고 있다고 주장합니다. Code as Agent Harness(코드를 에이전트의 하네스로) 는 코드를 더 이상 대형 언어 모델(Large Language Model, LLM)이 만들어 내는 최종 산출물로만 보지 않고, 에이전트가 추론하고, 행동하고, 환경을 표현하고, 실행 결과로 스스로를 검증하는 운영 기반(operational substrate)으로 보자는 통합적 관점입니다. 이 글은 University of Illinois Urbana-Champaign(UIUC), Meta, Stanford University의 연구자 45명이 공동으로 작성한 102페이지, 450편 이상의 논문을 인용한 대형 서베이 Code as Agent Harness를 정리한 것입니다.

여기서 핵심 개념은 하네스(harness) 입니다. 하네스란 LLM을 도구, API, 샌드박스, 메모리, 검증기(validator), 권한 경계, 실행 루프, 피드백 채널로 둘러싸서, 상태가 없는 모델(stateless model)을 장시간 과제를 수행할 수 있는 기능적 에이전트로 바꿔 주는 소프트웨어 계층을 말합니다. 마구(馬具)가 말의 힘을 마차에 연결해 실제로 쓸 수 있게 만드는 것처럼, 하네스는 모델의 출력을 실제 행동과 지속적인 상태에 연결합니다. 이 관점에서 자율성의 병목은 단지 기반 모델의 추론 능력만이 아니라, 모델 출력을 장기적 행동과 상태로 안정적으로 이어 주는 시스템의 신뢰성입니다.

모델 능력, 하네스 인프라, 에이전트가 만든 코드를 구분하기

저자들은 장시간 동작하는 에이전트 시스템을 세 가지 요소로 구분합니다. 이 구분이 서베이 전체를 관통하는 출발점입니다.

모델 내부 능력(model-internal capabilities): 추론, 지각, 계획, 시뮬레이션, 평가 같은 모델 자체의 능력입니다.
시스템이 제공하는 하네스 인프라(system-provided harness infrastructure): 미리 정의된 도구, API, 샌드박스, 메모리 시스템, 검증기, 권한 경계, 텔레메트리(telemetry), 워크플로우 등 모델 출력을 외부 행동과 피드백에 연결하는 토대입니다. 이른바 하네스 엔지니어링(harness engineering)의 주된 대상이기도 합니다.
에이전트가 만든 코드 산출물(agent-initiated code artifacts): 에이전트가 과제 수행 루프 안에서 직접 생성하고, 실행하고, 관찰하고, 수정하고, 저장하고, 공유하는 상호작용 가능한 코드 객체들입니다. 회귀 테스트(regression test), 임시 도구, DSL 프로그램, 실행 가능한 워크플로우, 재사용 가능한 스킬, 중간 프로그램 상태 등이 여기에 해당합니다.

기존 서베이들이 대체로 코드를 "LLM의 결과물"로만 다뤄 온 것과 달리, 이 서베이는 상대적으로 덜 탐구된 세 번째 요소, 즉 에이전트가 능동적으로 코드를 만들어 환경과 상호작용하며 진화시키는 과정에 초점을 맞춥니다. Claude Code, Codex, LangChain, 여러 엔터프라이즈 에이전트 플랫폼이 바로 이런 방식으로 장시간 과제에서 적응적 행동을 만들어 내는 대표 사례입니다.

왜 하필 코드인가

모델과 과제 환경을 연결하는 매체로 왜 자연어가 아니라 코드여야 할까요? 저자들은 코드가 자연어와 달리 세 가지 결정적 성질을 동시에 가진다고 정리합니다.

실행 가능성(executable): 모델 출력이 형식적으로 검증 가능한 결과를 내는 연산이 됩니다. 하네스가 "모델이 의도한 바가 실제로 무엇인지"를 실행해서 확인할 수 있습니다.
검사 가능성(inspectable): 중간 계산 과정이 하네스가 읽고, 저장하고, 반응할 수 있는 구조화된 트레이스(trace)로 노출됩니다. 실패를 진단하고 다시 피드백으로 돌릴 수 있습니다.
상태 보존성(stateful): 진화하는 프로그램이 과제 진행 상황을 지속적이고 수정 가능한 형태로 표현합니다. 단계 사이에 상호작용 이력이 사라지지 않습니다.

중요한 것은 이 성질들이 코드를 단순한 표기법이 아니라 하네스 인터페이스로서 기능하게 만든다는 점입니다. 다만 저자들은 코드를 비유적으로 쓰지 않는다고 분명히 못 박습니다. 여기서 코드란 프로그램, 스크립트, 형식 명세, 증명 스크립트, API 스키마, 도구 정의, 테스트, 저장소, 시뮬레이터, 설정 파일, 그리고 실행 시스템이 만들어 내거나 소비하는 트레이스와 로그 같은 실행 가능하거나 기계가 검사할 수 있는 산출물을 가리킵니다. 반대로 원시 지각, 물리적 상태, 인간의 의도, 모델 내부의 잠재 추론 자체는 코드가 아닙니다. 코드는 이것들을 대체하는 것이 아니라, 그중 일부를 에이전트 루프 안에서 실행 가능하고 검사 가능하며 상태를 가진 형태로 만들어 주는 인터페이스입니다.

이 관점에서 서베이는 코드가 에이전트 루프 안으로 들어오는 순서를 따라 세 개의 연결된 레이어로 구성됩니다. 먼저 코드는 추론, 행동, 환경 표현을 위한 하네스 인터페이스로 진입하고(레이어 1), 다음으로 계획, 메모리, 도구 사용, 실행, 수정을 시간에 걸쳐 관리하는 하네스 메커니즘을 떠받치며(레이어 2), 마지막으로 여러 에이전트가 저장소, 테스트, 트레이스, 워크플로우, 실행 상태를 공유하며 협력하는 공유 산출물로 확장됩니다(레이어 3). 맨 위 그림이 이 세 레이어의 전체 분류 체계입니다.

레이어 1: 하네스 인터페이스 (Code for Reasoning, Acting, Environment)

하네스가 던지는 가장 근본적인 설계 질문은 "무엇이 모델을 과제 환경에 연결하는가?" 입니다. 레이어 1은 코드가 이 인터페이스 역할을 맡는 세 가지 방식, 즉 추론을 위한 코드, 행동을 위한 코드, 환경 모델링을 위한 코드를 다룹니다.

추론을 위한 코드 (Code for Reasoning)

순수한 사고 사슬(Chain-of-Thought, CoT) 프롬프팅은 추론과 계산을 모두 자연어라는 하나의 잠재적 텍스트 과정 안에서 처리합니다. 그런데 언어 모델은 추론 단계를 제안하는 데에는 능하지만, 기호적이거나 논리적이거나 산술적인 계산을 충실히 수행하는 데에는 여전히 불안정합니다. 더 중요한 문제는 순수 텍스트 추론이 하네스에게 중간 상태를 검증하거나, 실행 동작을 검사하거나, 계산 진행 상황을 단계 사이에 보존할 능력을 거의 주지 못한다는 점입니다.

추론을 위한 코드는 모델과 하네스 사이에 코드를 실행 인터페이스로 끼워 넣어 이 문제를 풉니다. 모델은 고수준 추론(절차 제안)을 담당하고, 하네스는 저수준 계산(실행, 관찰, 중간 상태 저장)을 담당하도록 분리하는 것입니다. 저자들은 이 분야를 세 갈래로 정리합니다.

첫째, 프로그램 위임 추론(program-delegated reasoning) 입니다. 모델이 자연어 대신 코드를 생성하고 외부 인터프리터가 이를 실행해 형식적으로 근거 있는 출력을 만듭니다. PAL(Program-Aided Language models) 과 Program-of-Thoughts(PoT) 가 이 패러다임을 체계화했고, MathCoder, CodeI/O 등이 실행 충실도와 도메인 특화를 끌어올렸습니다. 계산을 프로그램에 위임하는 것만으로도 중간 추론이 구조화되고 검증 가능한 실행 트레이스로 바뀌면서 신뢰성이 크게 향상됩니다.

둘째, 형식 검증과 기호 추론 인터페이스(formal verification and symbolic reasoning) 입니다. 유연한 언어 기반 추론과 구조화된 기호 계산을 결합하되, 프로그램을 단순히 생성된 텍스트가 아니라 지속되는 중간 표현으로 다룹니다. 특히 Lean, Isabelle, Coq 같은 증명 보조기(proof assistant)는 각 유도 단계를 검증기가 검사할 수 있는 형식 증명 언어를 제공합니다. DeepSeek-Prover, Kimina-Prover, Goedel-Prover-V2 같은 시스템이 심층 증명 탐색과 자기 수정, 반복적 증명 생성 및 검증으로 이 과정을 개선해 왔고, 최근에는 물리학(Lean4Physics), 코드 검증(VERINA), 그리고 에이전트 워크플로우 자체를 Lean4로 모델링하고 검증하는 Lean4Agent로까지 확장되고 있습니다. 하네스 관점에서 형식 언어는 추론 도구일 뿐 아니라 에이전트 행동을 제약하고 인증하며 감사하는 실행 가능한 계약(executable contract) 으로 작동합니다.

셋째, 반복적 코드 근거 추론(iterative code-grounded reasoning) 입니다. 추론을 한 번에 끝내는 과정이 아니라 생성, 실행, 검증, 수정이 맞물린 닫힌 루프로 봅니다. NExT는 모델이 프로그램 트레이스를 추론하며 실행 동작을 예측하도록 학습시키고, CodePRM과 ORPS는 실행 결과로 중간 추론 궤적을 평가하고 다듬습니다. CodeRL 계열과 RLEF는 단위 테스트나 실행 피드백을 보상 신호로 삼아 강화 학습(Reinforcement Learning)으로 추론 정책을 최적화합니다. 이 방향은 다음 토큰 예측이 아니라 런타임 피드백으로 추론을 이끈다는 점에서 본질적으로 다릅니다.

행동을 위한 코드 (Code for Acting)

추론을 넘어, 에이전트는 결정이 실제 실행 효과를 내는 외부 환경에도 모델을 연결해야 합니다. 이 단계에서 코드는 계산의 매체가 아니라, 모델 출력을 도구 호출, 로봇 제어 정책, GUI 동작, 소프트웨어 명령 같은 근거 있는 연산으로 바꾸는 행동 인터페이스가 됩니다. 핵심 난점은 근거화(grounding)입니다. 추상적인 언어 출력을 대상 환경의 제약(신체적 한계, 인터페이스 API, 환경 동역학, 안전 요구사항)을 존중하는 실행 가능한 행동으로 매핑해야 하기 때문입니다. 인터프리터가 정확성을 직접 검증할 수 있는 추론용 코드와 달리, 행동 실행은 부분적으로만 관측되고 동적으로 변하는 환경에서 일어나며, 실패가 명시적 예외 없이 잘못된 상태 전이나 지연된 피드백으로 조용히 드러나기도 합니다. 예를 들어 로봇이 도달 불가능한 위치의 물체를 잡으려 시도하면서도 런타임 예외를 내지 않을 수 있습니다.

저자들은 이 영역을 세 갈래로 정리합니다.

근거 기반 스킬 선택(grounded skill selection): 미리 정의된 스킬 라이브러리에서 환경에서 실행 가능한 행동을 고릅니다. 대표적으로 SayCan 은 LLM이 제안한 계획을 어포던스(affordance), 즉 물리적 실현 가능성에 연결해 "할 수 있는 행동"으로 좁힙니다.
프로그램형 정책 생성(programmatic policy generation): 행동을 고르는 대신 행동 자체를 코드로 생성합니다. Code as Policies 는 계층적 파이썬 코드로 반응형 로봇 제어 정책을 만들어 내고, Code-BT는 코드를 행동 트리(behavior tree)로 옮겨 규칙 제약을 부과합니다.
평생 학습형 코드 에이전트(lifelong code-based agents): 성공한 행동을 재사용 가능한 스킬로 축적합니다. Voyager 는 Minecraft에서 실행 가능한 스킬 라이브러리를 자율적으로 키워 나가는 대표 사례이고, UI-Voyager, SkillsCrafter 등이 GUI와 조작 영역에서 같은 발상을 잇고 있습니다.

특히 AutoHarness는 이 관점을 명시적으로 보여 줍니다. LLM과 환경 사이를 중개하면서 실행 전에 유효하지 않은 행동을 걸러 내는 코드 하네스를 자동으로 합성합니다. 코드는 실행될 행동일 뿐 아니라, 모델의 의도를 지각, 어포던스, 컨트롤러, API, 액추에이터, 안전 제약에 연결하는 실행 가능한 경계이기도 하다는 것입니다.

환경 모델링을 위한 코드 (Code for Environment)

에이전트는 상호작용하는 환경에 대한 명시적 표현도 유지해야 합니다. 그런 표현이 없으면 환경은 텍스트 관찰이나 API 반환값, 희소한 피드백을 통해 간접적으로만 노출되고, 환경 상태는 암묵적이고 일시적이며 검증하기 어려운 채로 남습니다. 환경 모델링을 위한 코드는 시뮬레이터, 저장소, 테스트, 실행 트레이스, 로그, 상태 전이 프로그램 같은 계산 산출물로 환경의 구조와 동역학을 구체화합니다. 이렇게 하면 두 가지 큰 이점이 생깁니다. 첫째, 실행 가능한 환경은 검증 가능한 상태 전이를 노출하므로, 에이전트가 모호한 자연어 판단이 아니라 실행으로 상호작용 결과를 평가할 수 있습니다. 둘째, 코드 기반 환경은 지속적이고 수정 가능해서 에이전트가 질의하고, 시뮬레이션하고, 편집하고, 다듬을 수 있습니다.

저자들은 이 분야를 네 갈래로 나눕니다. 구조화된 세계 표현(예: 실내 환경을 재사용 가능한 "방 프로그램"으로 모델링하는 FactoredScenes, GUI 상태 예측을 렌더링 가능한 HTML 생성으로 재구성한 Code2World), 실행 트레이스 세계 모델링(예: 프로그램 트레이스로부터 예측적 세계 모델을 학습하는 Code World Model(CWM), 에이전트가 파이썬 프로그램으로 세계 모델을 직접 쓰고 갱신하는 WorldCoder), 코드 근거 평가 환경(예: 코딩 과제를 상호작용 실행 환경으로 재구성한 InterCode, 실제 저장소 단위 테스트로 평가하는 SWE-bench), 그리고 검증 가능한 환경 구축(예: 기존 코드베이스에서 저장소 단위 과제와 실행 환경을 대량 생성하는 SWE-smith)입니다. 마지막 갈래가 특히 흥미로운데, 환경 인터페이스 자체를 구축의 대상으로 삼아, 코드가 에이전트가 무엇을 편집하고 실행하는지뿐 아니라 상태 전이, 도구 어포던스, 성공 여부를 결정하는 검증기까지 명세하도록 만듭니다.

레이어 2: 하네스 메커니즘 (Planning, Memory, Tool Use, Control, Optimization)

인터페이스가 코드를 에이전트 루프 안으로 들였다면, 메커니즘 레이어는 코드 기반 에이전트가 단 한 번의 생성 단계를 넘어 신뢰성 있게 동작하도록 만드는 중앙 시스템 계층입니다. 코드가 루프에 들어오면 소프트웨어 생성은 더 이상 프롬프트에서 올바른 프로그램을 만드는 문제가 아니라, 모델과 가변 과제 상태, 인간이 설계한 하네스 인프라 사이의 상호작용이 됩니다. 모델은 판단을 제공하고(목표 분해, 행동 선택, 피드백 해석, 수정 시점 결정), 가변 상태는 저장소 증거와 작업 맥락과 실행 트레이스를 기록하며, 하네스 인프라는 도구를 노출하고 상태를 압축하고 권한으로 행동을 제약하며 각 상태 전이가 수용 가능한지 검증합니다. 저자들은 이 다섯 메커니즘을 차례로 다룹니다.

계획 수립 (Planning)

실제 소프트웨어 과제는 자연어 의도에서 올바른 구현으로 한 번에 매핑되는 일이 거의 없습니다. 하네스 관점에서 계획은 단순히 LLM의 내부 추론 능력이 아니라 하네스 제어(harness control) 의 한 형태입니다. 즉 의도를 실행 가능한 단계로 외부화하고, 코드 산출물 및 도구와의 상호작용을 일정에 맞춰 배치하며, 추론과 실행과 수정의 궤적을 시간에 걸쳐 조절하는 일입니다. 저자들은 제어가 실현되는 주된 위치에 따라 계획을 네 가지로 분류합니다.

선형 분해 계획(linear decomposition): 먼저 명시적이고 실행 가능한 단계 순서를 만든 뒤 그 분해를 따라 생성합니다. 경량 선조는 ReAct 로, 사고와 행동과 관찰을 직렬 궤적으로 엮습니다. 최근에는 이 선형 골격이 일회용 프롬프트를 넘어 지속적 하네스 객체로 격상됩니다. 장기 코딩 워크플로우에서 PLAN.md, Implement.md, 상태 로그 같은 파일이 마일스톤, 수용 기준, 검증 명령, 복구 규칙을 기록해, 컨텍스트 리셋이나 여러 세션에 걸쳐 진행 상황을 다시 불러오고 갱신하고 검증하게 합니다. 계획이 사람이 검토하고 Git으로 버전 관리되며 하위 에이전트가 소비하는, 파일 시스템에 백업된 제어 객체가 되는 것입니다. 다만 단일 분해 궤적에 일찍 고정되면 탐색이 제한된다는 한계가 있습니다.
구조 근거 계획(structure-grounded): 자유 형식 프롬프트가 아니라 의존성 그래프, 저장소 그래프, 회로 그래프, 지식 그래프 같은 명시적 구조에 계획을 근거시킵니다. CodePlan은 편집 의무에 대한 계획 그래프를 만들어 의존성 분석과 변경 영향 전파로 새 단계를 도출하고, VerilogCoder는 Task and Circuit Relation Graph에 각 하위 작업을 신호와 전이로 근거시킵니다. AGENTS.md, 아키텍처 노트, API 명세, 테스트 가이드처럼 프로젝트 지식을 지속적이고 검사 가능하며 버전 관리되는 산출물로 만드는 에이전트 친화적 관행도 같은 원리로, 빌드 명령과 디렉토리 경계와 코딩 규약을 행동 이전에 드러냅니다.
탐색 기반 계획(search-based): 단일 계획에 고정하는 대신 추론 시점 연산을 들여 여러 후보 경로를 탐색하고 평가하고 선택합니다. 탐색은 사고 공간(구현 전에 고수준 전략을 분기), 궤적 공간(전략 선택, 구현, 디버깅, 수정의 분기 과정), 코드 공간(이웃 프로그램을 변이로 탐색)에서 이뤄집니다. SWE-Search는 몬테카를로 트리 탐색(MCTS)을 소프트웨어 에이전트와 결합하고, CodeTree는 전략 탐색과 생성과 정제를 하나의 트리로 조직하며, Meta-Harness는 이 발상을 하네스 코드 자체를 탐색하는 수준까지 끌어올립니다. 즉 탐색 기반 계획은 모델의 샘플링 전략일 뿐 아니라, 후보를 보존하고 증거를 노출하며 어느 분기에 연산을 더 쓸지 결정하는 하네스 수준의 상태 관리 문제입니다.
오케스트레이션 기반 계획(orchestration-based): 계획 기능을 시스템 수준 조율을 위한 하네스 설계로 실현합니다. 실패를 감지하고 해석해 되먹이는 피드백 중심 조율, 이해, 검색, 계획, 코딩, 디버깅을 명시적 단계로 나누는 단계형 워크플로우 조율, 그리고 라우팅 기질 자체에 계획을 심는 컨트롤러 중심 조율로 나뉩니다. 가장 일반적인 형태는 역할, 단계, 계약, 상태 규약, 실패 분류를 편집 가능한 자연어로 쓰고 Intelligent Harness Runtime이 이를 런타임에 해석해 제약과 예산과 도구 인터페이스 아래 실행 단계로 바꾸는 Natural-Language Agent Harness입니다.

저자들은 계획의 이점이 실행 환경, 피드백 품질, 도구 접근, 궤적 예산에 크게 좌우된다는 점을 짚습니다. 실행 신호가 약하거나 벤치마크가 장기 의존성 관리를 제대로 압박하지 못하면 보고된 계획 성능 향상이 진짜 개선이 아닐 수 있으므로, 계획은 방법 설계 문제일 뿐 아니라 에이전트와 환경 사이의 하네스 문제이기도 하다는 것입니다.

메모리와 컨텍스트 엔지니어링 (Memory and Context Engineering)

실제 소프트웨어 과제는 본질적으로 장기적이고 상태 집약적입니다. 요구사항 이해, 코드 위치 파악, 증거 검색, 여러 파일 편집, 테스트 실행, 버그 수정, 회귀 검증이 여러 라운드에 걸쳐 서로 얽힙니다. 여기서 모델의 제한된 컨텍스트 창과 계속 불어나는 중간 상태 사이에 근본적 긴장이 생깁니다. 하네스 관점에서 메모리는 더 큰 컨텍스트 창이나 벡터 데이터베이스가 아니라, 어떤 정보를 활성 컨텍스트에 남기고 무엇을 요약으로 압축하며 무엇을 지속적 외부 저장소로 덜어 낼지 결정하는 상태 관리 계층입니다. 마치 사람이 단기 기억, 메모장, 오래된 노트, 팀 위키를 상황에 맞게 나눠 쓰는 것처럼, 하네스도 정보의 수명과 공유 범위에 따라 저장 계층을 나눕니다.

저자들은 메모리를 기능에 따라 다섯 유형으로 정리합니다. 현재 궤적의 상태를 유지하는 작업 메모리(working memory)는 무엇을 얼마나 보관할지가 아니라 다음 행동에 어떤 정보가 가장 유용한지를 다룹니다(SWE-agent, RepairAgent, 예산이 정해진 슬롯으로 다단계 편집을 안정화하는 CodeMem). 저장소를 질의 가능한 증거 공간으로 바꾸는 의미 메모리(semantic memory)는 단순히 더 많이 검색하는 것이 아니라 프로그램 구조에 맞춰(AST 기반 청킹, 반복적 질의 재작성) 검색하는 것이 핵심입니다(AutoCodeRover, RepoCoder, CodeRAG). 과제를 가로질러 재사용 가능한 경험을 쌓는 경험 메모리(experiential memory)에서는 저장된 경험의 양보다 질이 더 중요하다는 점이 강조됩니다. 통제되지 않은 기록은 의미적 노이즈와 오류 전파를 낳기 때문입니다(ExpeL, MemGovern). 장기 메모리(long-term memory)는 용량이 아니라 언제 쓰고 언제 압축하고 언제 검색하고 어떻게 오염을 피할지라는 거버넌스 문제로 옮겨 갑니다(MemGPT, MemoryOS, 검증된 커밋을 지속 메모리로 쓰는 MemCoder). 마지막으로 멀티 에이전트 메모리는 상태 관리를 개별 에이전트에서 공유 하네스로 확장해, 공유 블랙보드나 협력 상태 그래프에 가까워집니다(MIRIX, G-Memory).

여섯 번째 축인 컨텍스트 압축과 상태 오프로딩(context compaction and state offloading)은 별도 범주라기보다 활성 컨텍스트와 지속적 과제 상태 사이의 경계를 통제하는 횡단 메커니즘입니다. 빌드 로그, 실행 트레이스, 저장소 diff, 테스트 출력 같은 대용량 산출물을 프롬프트에 그대로 넣으면 컨텍스트가 폭발합니다. 압축은 예컨대 실패한 테스트 보고서를 테스트 이름, 핵심 스택 프레임, 의심 파일, 전체 로그 링크 로 줄이고(LongCodeZip, SWE-Pruner), 오프로딩은 원본 산출물을 파일이나 트레이스 저장소, MCP 스타일 리소스 인터페이스 같은 활성 창 밖에 보존한 뒤 에이전트에게는 요약과 리소스 식별자만 건넵니다. 이렇게 결정에 필요한 맥락과 지속적 증거를 분리해, 메모리를 확장 가능하고 감사 가능하며 실행 시점 검증과 양립하게 만듭니다.

도구 사용 (Tool Use)

도구 사용은 코드 에이전트 하네스의 행동과 관찰 계층입니다. 코드가 루프에 들어오면 모델은 텍스트를 생성하는 데 그치지 않고 저장소를 검색하고, 코드를 편집하고, 테스트를 실행하고, API를 호출하고, 중간 결과를 검증해야 합니다. 저자들은 도구를 단순한 보조 기능이 아니라 모델 의도와 외부 시스템 사이의 거버넌스가 적용된 인터페이스로 봅니다. 신뢰할 수 있는 하네스는 어떤 도구를 노출할지, 스키마를 어떻게 드러낼지, 각 도구에 어떤 권한을 줄지, 실행이 어디서 일어날지, 결과를 어떻게 정제하고 압축할지, 위험한 행동에 언제 인간 승인을 요구할지를 결정합니다. 도구가 맡는 주된 하네스 기능에 따라 네 갈래로 정리됩니다.

함수 지향 도구 사용(function-oriented): API, 라이브러리, 문서 같은 외부 지식으로 모델의 빈틈을 메웁니다. ToolCoder는 코드 모델이 API를 환각하거나 부적절한 함수를 고르는 병목에서 출발해, API 검색 도구를 생성 과정에 통합하고 언제 질의하고 어떤 API를 고를지 학습시킵니다. 핵심은 더 나은 문법 생성이 아니라 더 나은 지식 획득과 API 근거화로, 롱테일 API나 사설 SDK에 특히 유용합니다.
환경 상호작용 도구 사용(environment-interaction): 도구를 저장소, 개발 산출물, 실행 환경 안에서 행동하는 통로로 씁니다. CodeAgent는 실제 저장소에서 파일 위치 파악, 의존성 이해, 문서 검사, 수정, 테스트 검증을 수행하고, SWE-agent는 셸 명령, 파일 편집, 테스트 실행을 주된 상호작용 채널로 삼는 에이전트-컴퓨터 인터페이스를 형식화합니다. 저장소 단위 생성과 이슈 해결, 열린 소프트웨어 엔지니어링 과제에 핵심적입니다.
검증 주도 도구 사용(verification-driven): 도구를 하네스의 결정론적 센서로 다룹니다. 외부 검색이나 광범위한 저장소 탐색보다, 테스트와 컴파일러 오류와 런타임 트레이스와 타입 검사기와 정적 분석기 피드백을 코드 품질 개선의 주된 신호로 씁니다. AgentCoder는 프로그래머, 테스트 설계자, 테스트 실행자 에이전트로 생성, 테스트 구성, 실행, 정제의 닫힌 루프를 만듭니다. 관건은 길고 노이즈가 많은 로그를 파싱하고 요약해 다음 행동으로 되먹이는 일입니다.
워크플로우 오케스트레이션 도구 사용(workflow-orchestration): 여러 도구, 역할, 제어 정책을 일관된 워크플로우로 조직합니다. 관건은 도구를 더 추가하는 것이 아니라 각 도구를 언제, 어떤 권한으로, 어떤 맥락에서 호출하고 그 결과가 하네스 상태를 어떻게 갱신할지 결정하는 것입니다. MapCoder는 예제 회상, 계획, 코드 생성, 디버깅에 에이전트를 배정해 어려운 문제를 조율된 하위 문제로 분해합니다.

최근 에이전트 SDK와 소프트웨어 에이전트 플랫폼은 타입이 있는 도구 스키마, 세션 상태, 작업 공간, 가드레일(guardrail), 핸드오프, 추적을 재사용 가능한 하네스 부품으로 묶어 이 경계를 명시화합니다. 특히 생명주기 훅(lifecycle hook) 이 중요한데, 실행 전 훅은 인자를 검증하고 권한 정책을 강제하며 위험한 명령을 차단하고, 실행 후 훅은 출력을 정제하고 긴 로그를 압축하며 메모리를 갱신하거나 후속 검증을 촉발합니다. 핵심은 모델이 도구를 부를 수 있느냐가 아니라, 하네스가 도구 사용을 안전하고 감사 가능하며 장기 실행에 유용하게 만들 수 있느냐입니다.

Plan-Execute-Verify 루프와 사이버네틱 거버너

서베이에서 가장 통찰력 있는 부분 중 하나입니다. 저자들은 반복적 디버깅을 Plan-Execute-Verify(PEV) 루프, 즉 계획, 실행, 검증의 단일 하네스 제어 과정으로 재해석합니다. 하네스가 먼저 의도한 변경과 검증 기준을 외부화하고(Plan), 그 변경을 샌드박스화되고 권한이 부여된 환경에서 실행하며(Execute), 결과 상태를 결정론적 센서와 인간 검토 게이트로 검증합니다(Verify).

이 관점에서 하네스는 사이버네틱 거버너(cybernetic governor), 즉 에이전트 행동의 효과를 관찰하고 이후 상태 전이를 조절하는 제어 계층으로 작동합니다. 단순히 오류 메시지를 모델에 전달하는 것이 아니라, 린터(linter), 파서, 컴파일러, 타입 검사기, 단위 테스트, 통합 테스트, 정적 분석기, 퍼저(fuzzer), 런타임 모니터, CI 파이프라인 같은 결정론적 센서를 통해 저장소와 실행 환경을 관찰합니다. 이 센서들은 코딩 궤적을 통과/실패 결과, 진단, 실패 트레이스, 커버리지 공백, 보안 경고, 자원 한계, 정책 위반 같은 검사 가능한 신호로 바꿉니다. 그러면 하네스는 실행을 계속할지, 패치를 수정할지, 맥락을 더 요청할지, 다른 모듈로 보낼지, 권한을 낮출지, 인간 검토자에게 에스컬레이션할지를 결정합니다.

실행 단계에서 특히 중요한 것이 다중 등급 권한 모델(multi-tier permission model) 입니다. 저자들은 위험도에 따라 세 등급을 구분합니다. 저장소 탐색, 검색, 정적 검사, 로그 분석을 지원하는 읽기 전용 등급, 격리된 작업 공간 안에서 로컬 패치와 테스트 실행과 임시 의존성 설치를 지원하는 샌드박스 편집 등급, 그리고 네트워크 접근, 자격 증명, 배포 명령, 패키지 게시, 파괴적 파일 시스템 연산, Git 히스토리 변경을 포함하는 완전 접근 등급입니다. 마지막 등급의 행동은 결과가 샌드박스를 넘어설 수 있으므로 반드시 인간 개입(Human-in-the-Loop, HITL) 게이트로 보호해야 합니다. 검증 단계 역시 모델의 자신감이 아니라 검증으로 종료를 결정해야 합니다. 필요한 검사가 통과하거나, 추가 시도가 더 이상 상태를 개선하지 못하거나, 위험 등급이 바뀌거나, 인간 검토가 필요할 때 루프가 멈춥니다. 저자들은 "신뢰성은 더 나은 수정 프롬프트가 아니라 통제된 상태 전이에서 나온다" 고 강조합니다.

Agentic Harness Engineering: 하네스를 스스로 최적화하기

Agentic Harness Engineering(AHE) 는 한 걸음 더 나아가, 언어 모델을 코딩 에이전트로 바꾸는 소프트웨어 기반 자체를 측정하고 개선하는 문제를 다룹니다. 프롬프트 엔지니어링이 지시문을, 컨텍스트 엔지니어링이 모델에 제시되는 증거를 바꾼다면, AHE는 운영 환경 그 자체, 즉 도구 스키마, 계획 산출물, 메모리 정책, 검색 전략, 샌드박스 설정, 검증 센서, 권한 등급, 라우팅 규칙, 멀티 에이전트 워크플로우, 인간 검토 게이트를 분석 대상으로 삼습니다. 코드 에이전트의 많은 실패가 모델 생성 자체가 아니라 빠진 저장소 맥락, 취약한 도구 인터페이스, 약한 검증기, 과도한 토큰 비용, 부실한 재시도 정책, 어긋난 권한 경계에서 비롯되기 때문입니다.

AHE의 중심 토대는 딥 텔레메트리(deep telemetry) 입니다. 얕은 로그가 최종 답이나 통과/실패만 기록한다면, 딥 텔레메트리는 프롬프트와 검색된 맥락, 토큰 사용량과 비용, 지연 시간, 도구 인자, 권한 요청, 편집된 파일, 샌드박스 스냅샷, 명령 출력, 테스트 결과, 스택 트레이스, 분기 결정, 거부된 대안, 인간 개입까지 의사결정 과정을 상세히 기록합니다. 이렇게 하면 하네스 수정이 일화적 디버깅에서 비교 가능한 진단으로 바뀝니다.

이 텔레메트리를 활용하는 주체가 진화 에이전트(Evolution Agent) 입니다. 대상 저장소를 편집하는 과제 에이전트와 달리, 진화 에이전트는 이후 과제 에이전트들이 동작하는 운영 조건 자체를 편집합니다. 입력은 궤적 모음이고, 출력은 수정된 프롬프트 템플릿, 검색 정책, 더 정밀한 도구 스키마, 추가된 검증기, 변경된 권한 규칙, 워크플로우 토폴로지 조정, 새 회귀 테스트가 될 수 있습니다. 진화 에이전트의 루프는 관찰, 진단, 제안, 평가, 승격의 다섯 단계를 거치며, 신뢰성이나 비용이나 안전을 개선하면서 이미 풀린 사례를 퇴행시키지 않는 변경만 승격합니다.

다만 저자들은 AHE를 무제약 자기 수정과 혼동해서는 안 된다고 경고합니다. 진화 에이전트는 이후 에이전트를 통제하는 하네스를 바꾸므로 일반 코드 수정보다 강한 거버넌스가 필요합니다. 후보 변경은 샌드박스 안에서 평가하고, 고정된 회귀 스위트와 비교하며, 감사 가능한 근거와 함께 기록해야 합니다. 권한 경계, 네트워크 접근, 자격 증명 처리, 배포 동작, 인간 검토 요구를 바꾸는 변경은 활성화 전에 HITL 승인을 거쳐야 합니다. 진화 에이전트 자신도 PEV 루프의 적용 대상이 되는 셈입니다.

레이어 3: 하네스 확장 - 멀티 에이전트 오케스트레이션

함수 단위 합성에서 저장소 단위 시스템 엔지니어링으로 과제가 복잡해지면 단일 에이전트의 근본적 한계가 드러납니다. (1) 컨텍스트 창 제약 때문에 코드베이스 전체와 긴 상호작용 이력과 실행 트레이스를 한 에이전트의 작업 메모리에 담을 수 없고, (2) 계획, 합성, 테스트, 검토, 디버깅을 하나의 만능 에이전트로 처리하는 것은 비효율적이며, (3) 독립적인 조율과 검증 채널이 없으면 에이전트가 장기 실행 중 자기 오류를 안정적으로 잡아내지 못합니다.

멀티 에이전트 시스템은 이 책임들을 전문화된 역할로 분산함으로써 하네스 자체를 더 모듈화하고 검사 가능하며 적응적으로 만듭니다. ChatDev, MetaGPT, AgentCoder 같은 초기 시스템이 아키텍트, 프로그래머, 테스터, 리뷰어, 실행자 같은 역할로 소프트웨어 개발 책임을 나눈 것이 출발점입니다. 저자들은 이를 역할 전문화, 공유 프로그램 상태에 근거한 상호작용 방식, 워크플로우 토폴로지의 세 차원으로 정리합니다.

역할 분담, 상호작용, 토폴로지: 협업의 세 차원

역할 전문화 는 인간 개발 조직을 본떠 에이전트에 기능을 나눕니다. 코드를 생성하고 수정하는 합성 에이전트(가장 흔함), 코드의 의미를 해석하는 이해 에이전트, 테스트를 만들거나 정적 분석을 돌리는 검증 에이전트, 런타임과 직접 맞닿는 실행 에이전트, 과제를 하위 작업으로 쪼개 배정하는 계획 에이전트입니다. 세밀한 설계가 신뢰성을 좌우합니다. 예컨대 AgentCoder의 테스트 설계자는 코드와 무관하게 테스트를 만들어 편향된 테스트가 자기 버그를 통과시키는 순환 논증을 피하고, 테스트 실행자는 LLM이 아니라 결정론적 파이썬 스크립트라서 피드백을 객관적 프로그램 동작에 묶습니다. EvoMAC은 프로그램이 아니라 시스템 자체를 다루는 메타 역할을 도입합니다. 실행 로그를 읽어 어떤 에이전트가 실패를 유발했는지 찾는 Gradient Agent와, 그에 맞춰 프롬프트와 워크플로우 DAG를 고치는 Updating Agent입니다.

상호작용 방식 은 자유 형식 메시지가 아니라 공유 코드 산출물에 근거합니다. 두 에이전트가 페어 프로그래밍처럼 함께 구성하는 협력 합성(PairCoder의 내비게이터-드라이버), 검증 에이전트가 구조화된 피드백을 주고 합성 에이전트가 고치는 비평-수리(문헌 전반의 지배적 방식), 퍼저가 크래시 입력으로 코드를 적극적으로 깨뜨리는 적대적 검증(AutoSafeCoder, MAGE의 파형), 그리고 명세 해석을 두고 논쟁한 뒤 합의에 이르는 추론 토론(ChatDev의 소통형 탈환각, 세 패널리스트의 다수결을 쓰는 CANDOR)으로 나뉩니다.

워크플로우 토폴로지, 즉 누가 누구와 어떤 순서로 몇 번 소통하는지는 가장 결정적인 설계 선택입니다. 미리 정해진 휴리스틱 토폴로지는 대개 소프트웨어 개발 생명주기(SDLC)를 본뜹니다. 설계에서 코딩, 테스트로 단방향으로 흐르는 체인(폭포수) 토폴로지(ChatDev, MetaGPT, 세 SDLC 모델을 비교하는 FlowGen), 검증 피드백으로 코드를 되돌리는 역방향 간선을 둔 순환 토폴로지(AgentCoder는 5 회로 제한), 매니저 아래 워커를 두는 계층 토폴로지(MAGIS, 자식 에이전트를 재귀 생성하는 SoA), 허브가 병렬 워커를 조율하는 스타 토폴로지(CANDOR, MetaGPT의 발행-구독 풀)가 있습니다. 반대로 토폴로지 자체를 최적화 대상으로 보는 적응형 토폴로지도 빠르게 늘고 있습니다. 과제 복잡도에 따라 에이전트 수를 늘리는 동적 풀 확장(SoA, 하위 에이전트 선택을 밴딧 최적화로 푸는 BOAD), 실행 피드백으로 DAG 자체를 재구성하는 EvoMAC, 워크플로우 명세를 통째로 진화시키는 SEW가 대표적입니다.

실행 피드백과 공유 상태 동기화

코드 중심 멀티 에이전트를 다른 협업 시스템과 구별 짓는 결정적 특징은, 공유 기반이 실행 가능해서 환각에 오염되지 않는 객관적 오라클 신호를 만들어 낸다는 점입니다. 저자들은 어떤 실행 피드백이 쓰이는지를 여섯 가지로 정리합니다. 런타임 이전에 구조적 오류를 잡는 컴파일러와 문법 피드백, 가장 흔한 테스트 통과/실패 신호, 구체적인 실패 입력을 건네는 퍼저 크래시 트레이스, CWE 취약점 분류에 연결되는 정적 분석 경고, 실행 시간과 메모리와 FLOPS를 재는 성능 프로파일링, 그리고 매 클록 에지의 신호 값을 기록하는 세밀한 시뮬레이션 피드백입니다.

여기서 특히 도발적인 결과가 QualityFlow의 상상 실행(Imagined Execution) 입니다. LLM이 파이썬 인터프리터를 단계별로 시뮬레이션해 코드를 실제로 돌리지 않고도 MBPP에서 98\% 이상의 정밀도와 재현율로 테스트 결과를 예측합니다. 정반대 극단에는 MAGE가 있습니다. 테스트벤치의 통과 여부만 보고하는 대신 첫 실패 클록 주변의 파형(waveform) 창을 디버그 에이전트에게 넘겨, 하위 테스트 단위의 정밀 수리를 가능하게 합니다. 한편 가장 흔한 동기화 방식인 순차 핸드오프(sequential handoff)는 프로그램 상태를 파이프라인의 최신 산출물 형태로만 유지하므로, 여러 에이전트가 병렬로 코드를 수정하는 상황에서 보이지 않는 상태 분기를 만듭니다. 코드는 더 풍부한 조율 기질이지만, 채널 대역폭 한계, 요약에 따른 압축 손실, 노이즈가 섞인 로그, 낡은 캐시 같은 분산 시스템의 제약을 없애 주지는 못합니다.

공유 코드 중심 하네스 기반: 형식화의 네 단계

나아가 저자들은 다음 세대 멀티 에이전트 지능을 위한 새로운 입장을 제안합니다. 바로 공유 코드 중심 하네스 기반(shared code-centric harness substrate) 입니다. 핵심 공백은 에이전트들이 반복에 걸쳐 질의하고 갱신할 수 있는 공유 코드 상태의 형식적이고 지속적인 표현이 없다는 점입니다. 저자들은 기존 시스템이 공유 상태를 표현하는 방식을 형식화 정도에 따라 네 단계로 구분합니다.

암묵적/파일 전용 표현: 가장 흔하고 가장 덜 형식화된 방식으로, 공유 하네스를 그저 현재 코드 파일로 보고 매 호출마다 대화 이력에서 상태를 암묵적으로 재구성합니다(ChatDev, MetaGPT, MapCoder, CodeCoR 등). 에이전트의 믿음이 실제 상태와 어긋나는 상태 분기를 감지할 방법이 없습니다.
저장소 기반 표현: 공유 하네스를 디렉토리 구조, 파일 간 의존성 그래프, 호출 계층, 버전 이력을 갖춘 탐색 가능한 저장소로 봅니다. MAGIS는 git diff로 파일 요약을 증분 갱신하고, HyperAgent는 저장소 탐색 도구를 제공하며, SyncMind는 저장소를 정답 상태 S_k 로 정의하고 에이전트의 믿음 B_k 와의 분기 |B_k - S_k| 를 정량화한 유일한 연구입니다.
실행 기반 표현: 코드가 어떻게 보이는지가 아니라 무엇을 하는지로 상태를 표현합니다. 컴파일 여부, 통과하는 테스트, 퍼저가 드러낸 취약점, 실행 속도가 곧 상태이며, 환각에 흔들리지 않는 객관적 오라클을 제공합니다(AgentCoder, AutoSafeCoder, MAGE 등).
블랙보드/공유 상태 표현: 모든 에이전트가 읽고 쓰는 명시적 전역 자료 구조로, 문헌에서 형식적 하네스 기반에 가장 근접한 방식입니다. L2MAC는 의미 있는 경로를 가진 지속적 파일 저장소를 Control Unit으로 관리해 각 호출이 보는 상태 조각을 명시적으로 통제합니다.

핵심 공백은 분명합니다. 대다수 연구가 암묵적/파일 전용 범주에 머물러 공유 기반의 형식적 모델을 갖지 못합니다. 프로그램은 멀티 에이전트 영역 중 유일하게 실행되는 산출물이라 객관적 신호로 형식적 공유 기반을 떠받칠 수 있는데도, 대부분의 시스템이 이 성질을 아키텍처 수준에서 활용하지 못하고 자연어만으로 코드 품질을 따지는 데 머문다는 것입니다.

그리고 멀티 에이전트 하네스가 언제 반복을 멈추고 현재 상태를 결과로 받아들일지, 즉 수렴(convergence) 도 실행 가능성 덕분에 대화상의 합의가 아니라 객관적 행동 신호에 근거시킬 수 있습니다. 저자들은 여섯 가지 수렴 패턴을 식별합니다. 모든 테스트가 통과하면 종료하는 정확성 수렴(가장 원리적이고 널리 쓰임), CWE 경고와 크래시가 사라지면 종료하는 보안 수렴(AutoSafeCoder), 런타임과 메모리 임계치를 만족하면 종료하는 성능 수렴(MACRO), 정량 품질 점수로 멈추는 점수 기반 수렴, 여러 리뷰어의 다수결로 판정하는 합의 수렴(QualityFlow는 품질 검사기 하나로 문제의 75~84\% 를 첫 생성에서 조기 종료), 그리고 객관적 기준 없이 고정 횟수로 끝내는 암묵적 수렴입니다. 저자들은 마지막 암묵적 수렴이 가장 흔하면서도 이 분야의 가장 큰 공백이라고 지적합니다. ChatDev가 10 라운드 후 종료하거나 MetaGPT가 고정 SOP 단계 후 종료하는 식인데, 형식적 공유 기반이 없으니 수렴의 원리적 기준도 없는 것입니다.

서베이가 짚어 낸 구조적 패턴들

레이어 3에서 가장 값진 부분은 여러 시스템을 가로질러 추출한 구조적 교훈들입니다. 단순 나열이 아니라 현재 시스템의 공통 병목과 더 강건한 설계 원칙을 함께 짚습니다.

암묵적 하네스 상태의 제약: 조사된 대다수 시스템(ChatDev, MetaGPT, MapCoder 등)은 공유 코드 하네스의 명시적 표현 없이, 매 호출마다 대화 이력에서 상태를 암묵적으로 재구성합니다. 함수 단위 과제에서는 통하지만, 형식적 공유 기반이 없으면 에이전트는 자신의 내부 이해가 실제 프로그램 상태와 언제 어긋났는지 안정적으로 감지할 수 없습니다. 저자들은 이 암묵적 상태 의존이 확장성의 편의가 아니라 시스템 취약성의 기술적 뿌리라고 봅니다.
실행 피드백은 언어적 추론과 형식적 추론을 잇는 다리: 흥미로운 발견이 하나 있습니다. Self-Collaboration과 QualityFlow는 LLM이 코드를 실제로 실행하지 않고 시뮬레이션한 실행만으로도 실제 결과 예측에서 98\% 이상의 정밀도와 재현율을 달성할 수 있음을 보였습니다. 이는 실행 피드백의 가치가 모든 실패 유형에서 균일하지 않음을 시사합니다. 실행은 런타임 충돌, 자원 고갈, 경계 조건 오류, 성능 퇴행처럼 언어적 시뮬레이션이 구조적으로 상상할 수 없는 코너 케이스를 잡는 데 탁월하지만, 많은 수정 가능한 버그에는 시뮬레이션 추론으로도 충분할 수 있습니다. 성숙한 하네스라면 언어적 추론을 빠른 경로로 쓰고, 꼭 필요한 실패 유형에만 실행을 검증 오라클로 위임할 것입니다.
토폴로지 복잡도는 하네스 상태의 형식성과 반비례: 명시적이고 형식적인 공유 기반을 가진 시스템(예: 지속적 파일 저장소를 가진 L2MAC)은 단순한 순차 체인을 쓰는 반면, 형식적 공유 상태가 없는 시스템은 복잡한 동적 DAG, 워크플로우 변형, 에이전트 풀 확장 같은 정교한 토폴로지를 우회책으로 동원합니다. 즉 토폴로지 복잡도는 부분적으로 증상입니다. 기반이 형식적으로 표현되고 질의 가능하면 에이전트는 단순하고 투명한 프로토콜로 조율할 수 있습니다.
컨텍스트 관리는 암묵적 공유 상태가 물리는 세금: 많은 시스템이 정교한 컨텍스트 관리 메커니즘을 발전시킨 이유는 정확히 형식적 공유 기반이 없기 때문입니다. 어느 컨텍스트 창에도 다 들어가지 않는 코드 하네스를 에이전트에게 일관되게 보여 주는 같은 문제에 대한 서로 다른 응답들인 셈입니다.

남은 두 패턴은 공유 기반을 어떻게 표현할지와 직결됩니다.

구조 표현과 실행 표현은 상호 보완적: 문헌은 개념적으로 직교하는 두 관점을 드러냅니다. 무엇이 무엇을 호출하고 의존성이 어떻게 흐르는지를 보는 저장소 기반 표현과, 실행 시 무엇이 일어나고 상태가 어떻게 변하는지를 보는 실행 기반 표현입니다. MAGIS와 HyperAgent는 전자에, AgentCoder와 MAGE는 후자에 치우쳐 있고, 둘을 하나의 기반으로 온전히 통합한 시스템은 아직 없습니다. "어떤 컴포넌트가 느린가"(호출 그래프와 프로파일링이 모두 필요)나 "이 리팩터링이 외부 의존 API를 깨뜨리는가"(정적 분석과 동적 테스트가 모두 필요) 같은 질문에 답하려면 두 관점이 함께 있어야 합니다.
에이전트 전문화가 공유 상태의 중요도를 끌어올린다: 코더-테스터 쌍을 넘어 아키텍트, 매니저, 내비게이터, 실행자, 검증자로 역할이 늘수록 공유 상태에 대한 일관된 이해의 필요성이 절박해집니다. 공유 이해가 없으면 계획 에이전트는 낡은 코드베이스 스냅샷으로 작업을 분해하고, 실행 에이전트는 합성 에이전트가 의도한 것과 다른 버전에서 테스트를 돌릴 수 있습니다. 역할의 증식은 단순한 설계 선택이 아니라 더 성숙한 공유 하네스를 요구하는 강제 함수(forcing function)입니다.

코드를 하네스로 쓰는 다섯 응용 분야

서베이는 이 패러다임이 구체적인 응용 영역에서 어떻게 구현되는지도 폭넓게 살핍니다.

코드 어시스턴트(Code Assistants) 는 코드 중심 에이전트의 가장 명확한 상용화 사례입니다. 초기의 인라인 자동완성이나 단일 턴 생성과 달리, 최근 어시스턴트는 저장소를 작업 공간으로 삼아 편집, 도구 사용, 검증, 풀 리퀘스트 상호작용이 닫힌 루프를 이룹니다. SWE-agent, OpenHands 같은 연구 시스템과 Claude Code, Codex, GitHub Copilot 코딩 에이전트, DeepAgents 같은 제품이 모델을 저장소 접근, 파일 편집, 명령 실행, 승인 경계, 로깅, 검증을 통제하는 관리형 개발 루프로 감쌉니다. 이 루프는 점차 Model Context Protocol(MCP) 같은 열린 프로토콜로 매개되어 도구와 맥락, 리소스를 표준화된 방식으로 노출합니다. 흥미로운 개념이 유기성(organicity) 입니다. 보이는 테스트를 통과해도 저장소의 아키텍처와 코딩 스타일에 어긋나는 패치는 유지보수자가 거부하므로, 좋은 패치는 잠재된 개발자 의도와 프로젝트 관례까지 추론해야 합니다.

2026년의 주목할 흐름은 하네스가 학습 데이터의 원천이자 최적화 대상 이 되었다는 점입니다. Cursor의 Composer는 실제 사용 트레이스로 온라인 강화 학습되고, OpenAI의 codex-1과 GPT-5-Codex는 하네스 루프를 본뜬 장기 다중 턴 상호작용으로 명시적으로 학습됩니다. 생산 규모의 데이터도 쌓이는데, 알리바바 클라우드에 자율 배포된 이슈 해결 에이전트 LingmaAgent는 사내 이슈의 16.9\% 를 완전 자율로, 43.3\% 를 수작업 개입과 함께 해결한다고 보고됩니다. 다만 남은 과제도 분명합니다. 단위 테스트를 넘어선 검증, 그리고 장기 루프에서의 실패 귀인이 그것입니다. 여러 연구가 보고한 단계별 실패 귀인 정확도는 아직 14~53\% 수준에 머뭅니다.

GUI/OS 에이전트 에서 저자들은 환경을 부분 관측 마르코프 결정 과정(Partially Observable Markov Decision Process, POMDP)으로 모델링합니다. 잠재 상태는 브라우저의 전체 DOM과 자바스크립트 힙, 안드로이드의 액티비티 스택 같은 프로그램 상태이고, 에이전트는 이를 직접 보지 못한 채 네 가지 코드 정의 관찰 중 하나를 받습니다. 직렬화된 DOM/HTML, 접근성 트리(AXTree), Set-of-Mark 좌표가 표시된 스크린샷, 또는 이들을 섞은 하이브리드입니다. 행동 역시 코드라서 DOM 호출이나 OS 수준 키보드/마우스 명령으로 컴파일되고, 전이 함수는 학습되는 것이 아니라 브라우저 엔진이나 OS가 결정론적으로 실행 합니다. 평가조차 코드입니다. 성공 여부를 학습된 보상 모델이 아니라 행동 후 시스템 상태를 검사하는 평가 스크립트가 판정합니다. 즉 코드가 환경을 만들고, 코드가 에이전트의 행동이며, 코드가 결과를 판정합니다. 이 동일한 입출력 계약 덕분에 Claude Computer Use, OpenAI Operator, Google Project Mariner, UI-TARS처럼 시뮬레이터에서 곧장 제품으로 넘어갈 수 있었습니다.

자율 신체 에이전트(Embodied Agents) 에게 코드는 두 가지 경계를 동시에 맡습니다. 고수준 의도를 신체 제약을 존중하는 명령으로 옮기는 근거화 인터페이스이자, 실행 시점에 허용 가능한 행동만 남기는 안전 경계입니다. 물리 세계에서는 도달 불가능한 위치를 잡으려는 시도처럼 위반이 조용히 실패하므로, 정확성의 부담이 런타임이 아니라 행동 생성 시점으로 옮겨집니다. 저자들은 의미 추론(파운데이션 모델), 허용 경계(타입이 있는 로봇 API와 모션 플래너), 지각(상태 추정), 물리 제어를 분리하는 계층형 하네스를 제시합니다. 나아가 같은 실행 가능한 형식이 행동을 검증 가능하게 만드는 동시에 저장하고 재사용 가능하게 만들기 때문에, 신체 에이전트의 메모리는 자연스럽게 다시 실행할 수 있는 스킬 라이브러리가 됩니다. Voyager가 이 패러다임을 열었고, 과제는 스킬 생성에서 망각과 추상화를 다루는 라이브러리 거버넌스로 옮겨 갔습니다.

과학적 발견 에이전트(Scientific Discovery) 는 코드를 하네스로 보는 관점이 가장 자연스럽게 들어맞는 영역입니다. 가설은 미분방정식이나 프로그램으로, 실험 프로토콜은 XDL이나 Opentrons 스크립트로, 분석은 Jupyter 노트북으로 표현되어 추론, 행동, 환경이 하나의 실행 가능한 프로그램 그래프가 됩니다. AI Scientist는 ML 논문 한 편 전체를 단일 실행 트레이스로 표현해, 코드를 쓰고 실행하고 그림을 비전 모델로 읽고 그 그림을 담은 LaTeX 원고를 출력합니다. 실제 검증된 성과도 인상적입니다. Virtual Lab은 LLM 책임연구원 에이전트와 하위 과학자 에이전트들이 92 종의 SARS-CoV-2 나노바디를 설계해 그중 둘이 JN.1과 KP.3 변종에 결합하는 것을 실험으로 확인했고, 버클리의 자율 실험실 A-Lab은 목표 58 종 중 41 종의 신규 무기 화합물을 17 일 연속 가동으로 합성했습니다. 수학 영역에서는 AlphaProof가 Lean 증명기를 실행 환경으로 삼아 각 증명 단계를 검증하고, AlphaEvolve는 코드 편집을 실행하고 채점하는 진화 루프로 새로운 행렬 곱셈 알고리즘을 찾아냅니다. 이를 측정하는 벤치마크도 빠르게 등장해, ScienceAgentBench는 동료 심사 논문에서 가져온 102 개 과제의 산출물을 모두 자체 완결적 파이썬 프로그램으로 통일했습니다.

개인화와 추천(Personalization) 은 환경이 소프트웨어 시스템일 뿐 아니라 의도가 부분적으로만 관측되는 인간 사용자라는 점에서 독특합니다. 사용자는 진짜 관심이 아니라 편의로 클릭하기도 하고 세션마다 목표가 바뀌기도 하므로, 에이전트에게는 노이즈 섞인 신호를 흡수하면서도 해석과 수정이 가능한 명시적 선호 상태가 필요합니다. 코드 중심 표현은 선호를 불투명한 임베딩이 아니라 자연어로 고칠 수 있는 편집 가능한 구조화 메모리로 만들어, 사용자가 저장된 선호를 바로잡으면 시스템이 이후 추천 전에 그 상태를 갱신하게 합니다. 다만 이 영역의 난점은 더 날카롭습니다. 코드 어시스턴트의 테스트나 GUI 에이전트의 인터페이스 상태와 달리 개인화에는 진짜 사용자 만족을 알려 주는 믿을 만한 오라클이 없고, 장기 사용자 모델은 민감한 행동 패턴을 담아 프라이버시와 거버넌스 위험을 키우며, 플랫폼과 창작자와 사용자의 목표가 충돌하는 다중 이해관계자 문제를 안고 있습니다.

미해결 과제와 "하네스 엔지니어링이라는 학문"

코드를 하네스로 보는 관점은 에이전트 AI의 중심 난제를 고립된 모델 생성에서 완전한 실행 루프의 신뢰성으로 옮깁니다. 저자들이 꼽는 핵심 미해결 과제는 다음과 같습니다.

하네스 수준 평가와 오라클 적절성: 대부분의 평가가 최종 과제 성공만 측정하지만, 이는 기반 모델 능력, 하네스 품질, 도구 신뢰성, 피드백 정보량, 환경 난이도를 뒤섞어 버립니다. 에이전트가 약한 테스트를 악용해 보이는 테스트만 통과할 수도 있습니다. 저자들은 궤적 효율, 검증 강도, 복구 능력, 상태 일관성, 안전 준수, 재현 가능성 같은 하네스 수준 지표가 필요하다고 봅니다.
실행 피드백을 넘어선 의미 검증: 실행 피드백은 오히려 거짓 확신을 줄 수 있습니다. 에이전트는 초록색 테스트를 보지만, 초록색 테스트가 전체 명세는 아닙니다. 저자들은 각 검증 산출물이 무엇을 검증하고 무엇을 검증하지 못하며 어느 정도 신뢰를 주는지 선언하는, 명시적 범위를 가진 검증 스택을 제안합니다. 수용된 모든 행동이 실행한 검사, 보존한 가정, 검증하지 못한 영역, 남은 위험을 담은 증거 묶음(evidence bundle)을 지니도록 하자는 것입니다.
퇴행 없는 자기 진화 하네스: 자동 하네스 진화는 이미 진행 중이지만, 진짜 어려운 문제는 과적합하거나 안전을 약화하거나 비용을 늘리거나 실패를 숨기거나 드물지만 중요한 과제를 퇴행시키지 않으면서 스스로 개선하는 것입니다. 하네스 변경을 안전 필수 런타임에 대한 코드 변경처럼 다뤄, 어떤 구성요소를 바꾸고 어떤 실패 유형을 겨냥하며 어떤 불변식을 보존하고 어떻게 롤백하는지 명시하는 변경 계약(change contract)을 붙이자고 제안합니다.
트랜잭션 공유 프로그램 상태와 의미 충돌 해소: 멀티 에이전트가 코드베이스를 공유 기반으로 쓰면 동기화만으로는 트랜잭션 의미나 가정 수준의 일관성이 보장되지 않습니다. 각 행동이 읽기 집합, 쓰기 집합, 가정, 버전 의존성, 검증 의무, 충돌 정책을 선언하고, 충돌을 파일 diff뿐 아니라 계획, 테스트, 검색 증거, 권한, 메모리, 잠재된 사용자 요구 수준에서 감지해야 합니다.
하네스 상태로서의 인간 개입 안전과 책임성: 안전은 기반 모델에 위임하거나 자연어 지시로만 인코딩할 수 없습니다. 하네스는 행동을 위험도로 분류하고, 권한 등급을 강제하며, 하드 제약을 위반하는 행동을 거부하고, 되돌릴 수 없거나 외부에 영향을 주는 전이에는 인간 승인을 요구하는 안전 거버너로 기능해야 합니다. 모든 승인과 거부는 감사 가능한 상태 전이가 되어야 합니다.
멀티모달 코드 하네스 시스템: 대부분의 하네스가 여전히 텍스트 상태(프롬프트, 파일, 로그, 테스트, 트레이스)를 중심으로 설계되지만, GUI 에이전트의 스크린샷, 신체 에이전트의 자기중심 이미지와 촉각 신호, 과학 에이전트의 플롯과 현미경 이미지처럼 결정적 상태가 멀티모달인 환경이 늘고 있습니다. 멀티모달 컨텍스트 압축, 시각적 근거화, 멀티모달 검증 스택이 핵심 과제로 떠오릅니다.

저자들은 이 모든 과제가 하나의 방향을 가리킨다고 봅니다. 바로 하네스 엔지니어링이라는 학문(a science of harness engineering) 입니다. 연구의 중심 대상이 더 이상 모델이나 생성된 프로그램만이 아니라, 맥락, 메모리, 도구, 실행, 피드백, 안전, 조율, 평가를 아우르는 완전한 닫힌 루프 시스템이라는 것입니다. 그리고 가장 중요한 미래 시스템은 다음 네 가지 성질을 결합할 것이라고 전망합니다.

실행 가능성(executable): 결정을 코드, 도구, 테스트, 환경에 근거시킵니다.
검사 가능성(inspectable): 계획과 상태와 출처와 실패 원인을 노출합니다.
상태 보존성(stateful): 긴 궤적과 여러 에이전트에 걸쳐 과제 정보를 보존합니다.
거버넌스(governed): 자율성을 권한과 검증과 책임성으로 제약합니다.

코드를 단지 에이전트가 생성하는 무언가가 아니라, 에이전트가 실행하고 적응하고 조율하는 런타임 매체로 바라볼 때, 우리는 비로소 신뢰할 수 있는 장기 자율 AI 시스템으로 가는 통합 로드맵을 손에 쥐게 됩니다. 이 서베이가 제안하는 가장 큰 발상의 전환은, 에이전트의 신뢰성을 끌어올리는 다음 무대가 더 큰 모델이 아니라 모델을 둘러싼 하네스의 설계일 수 있다는 점입니다.

Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems 논문

Code as Agent Harness 프로젝트 홈페이지

Awesome-Code-as-Agent-Harness-Papers GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~