하네스 인터페이스와 3계층 구조의 정의

이번 연구에서 정의한 '코드 애즈 에이전트 하네스(Code as Agent Harness)'의 핵심은 코드를 단순한 LLM(대규모 언어 모델)의 출력물이 아니라, 에이전트가 추론하고 행동하며 상태를 저장하고 피드백을 검증하는 '운영 기반(Operational Substrate)'으로 보는 관점이다. UIUC, Meta, Stanford 연구진이 arXiv(https://arxiv.org/abs/2605.18747)에 공개한 이 서베이 논문은 에이전트 시스템을 세 가지 기술 계층으로 분류해 분석한다.

첫 번째 계층인 '하네스 인터페이스(Harness Interface)'는 코드가 에이전트를 외부 환경과 연결하는 방식을 다룬다. 여기에는 추론 과정을 코드로 외부화해 실행하고 검증하는 Program-of-Thoughts 방식, 생성된 프로그램이 정책(Policy)으로 작동해 GUI나 로봇을 제어하는 방식, 그리고 코드베이스와 트레이스(Trace), 시뮬레이터 자체가 환경을 표현하는 방식이 포함된다.

두 번째 계층인 '하네스 메커니즘(Harness Mechanisms)'은 에이전트의 장기 실행을 유지하는 제어 시스템이다. 계획(Planning) 단계에서는 단순한 작업 분해를 넘어 `PLAN.md`와 같은 파일 시스템 기반의 지속적 계획 수립 방식으로 진화하고 있으며, 메타-하네스(Meta-Harness)는 하네스 설계 자체를 탐색 공간(Search Space)으로 설정해 최적화한다. 메모리 구조는 워킹(Working), 시맨틱(Semantic), 경험적(Experiential), 장기(Long-term), 멀티 에이전트 메모리로 세분화하며, 이를 단일 벡터 DB가 아닌 통합된 상태 관리 계층으로 처리한다.

마지막 '하네스 스케일링(Scaling the Harness)' 계층은 여러 에이전트가 코드라는 공유 매체를 통해 협업하는 구조를 분석한다. 연구진은 공유 상태 표현이 미성숙할 때 시스템의 토폴로지 복잡성이 증가하는 현상을 '세금(Tax)'으로 정의했다. 즉, 상태 설계가 정교한 시스템은 단순한 구조로도 작동하지만, 암묵적 상태에 의존하는 시스템은 이를 보완하기 위해 복잡한 토폴로지를 구축하게 된다는 분석이다.

PEV 루프와 상태 관리의 작동 메커니즘

에이전트의 실행 제어는 '계획-실행-검증(Plan $\rightarrow$ Execute $\rightarrow$ Verify, PEV)' 루프로 작동하며, 이는 사이버네틱 거버너(Cybernetic Governor)의 역할을 수행한다. 특히 실행 단계에서는 보안과 안정성을 위해 3단계 권한 모델을 적용한다. 가장 낮은 단계인 '읽기 전용(Read-only)'에서 시작해, 격리된 환경에서 수정을 허용하는 '샌드박스 편집(Sandbox-edit)', 그리고 사람이 개입하는 HITL(Human-in-the-Loop) 방식의 '전체 접근(Full-access)' 권한으로 확장하는 구조다.

상태 관리 측면에서는 컨텍스트 윈도우의 한계를 극복하기 위한 '컨텍스트 압축(Context Compaction)'과 '상태 오프로딩(State Offloading)' 메커니즘이 핵심이다. 모든 데이터를 컨텍스트에 넣는 대신, 의사결정에 필요한 요약 정보만 활성 컨텍스트(Active Context)에 유지하고 전체 데이터는 MCP(Model Context Protocol) 스타일의 프로토콜을 통해 외부로 오프로딩하는 방식이다.

검증 단계에서는 LLM의 자체 비평(Critique)보다 결정적 센서(Deterministic Sensor)를 활용하는 것이 더 신뢰할 수 있는 제어 신호가 된다고 분석했다. 구체적으로 린터(Linter), 타입 체커(Type Checker), 테스트 케이스, 퍼저(Fuzzer)와 같은 도구들이 제공하는 결정적 피드백을 통해 에이전트의 행동을 교정한다. 이러한 메커니즘을 측정하고 최적화하는 메타 계층을 AHE(Agent Harness Evaluation)라고 정의했다.

하네스 설계 관점의 실패 분석과 실무 적용점

실무자가 에이전트를 구축할 때 주목해야 할 점은 시스템 실패의 주된 원인이 모델의 지능 부족이 아니라 하네스 설계의 결함에 있다는 사실이다. 논문은 에이전트 실패의 주요 원인을 다음 다섯 가지 축으로 짚었다.

1. 부족한 저장소 컨텍스트(Insufficient Repository Context)

2. 깨지기 쉬운 도구 인터페이스(Fragile Tool Interfaces)

3. 약한 검증기(Weak Verifiers)

4. 과도한 토큰 비용(Excessive Token Costs)

5. 잘못된 재시도 정책(Incorrect Retry Policies)

따라서 개발자는 모델을 교체하기보다 검증기를 결정적 도구로 대체하고, 상태 관리 프로토콜을 정교화하는 방향으로 접근해야 한다. 특히 멀티 에이전트 환경에서는 여러 에이전트가 동시에 코드를 수정할 때 발생하는 충돌을 해결하기 위한 '트랜잭셔널 공유 상태(Transactional Shared State)' 구현이 핵심 과제로 남는다.

평가 지표 또한 최종 성공 여부만 따지는 방식에서 벗어나, 중간 트레이스(Intermediate Trace), 복구 시도 횟수, 안전성 체크 통과 여부 등을 1급 지표로 관리해야 한다. 또한 실패 사례에서 학습하면서도 기존의 정상 동작을 깨뜨리지 않는 '회귀 없는 하네스 개선' 방법론이 실무적인 도입 기준이 되어야 한다.

관련 상세 내용은 공식 웹페이지(https://code-as-harness.github.io/code-as-harness-webpage/)와 관련 논문 모음 GitHub(https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers)에서 확인할 수 있다.