Code as Agent Harness로 설계하는 실행·검증·상태 보존 에이전트

코드를 에이전트의 실행 기반으로 삼는 Code as Agent Harness의 구조와 상태 관리, 검증 게이트, 도구 통합 및 적용 기준을 다룬다.

2026-08-14 · 최초 발행 2026-08-02

코드는 결과물이 아니라 에이전트 런타임이다

UIUC·Meta·Stanford 연구진의 대규모 서베이는 코드 생성의 역할을 다시 규정한다. 코드는 에이전트가 마지막에 내놓는 목표 출력물에 머물지 않는다. 추론을 행동으로 옮기고, 환경을 조작하며, 실행 결과를 검증하고, 다음 반복에 필요한 상태를 보존하는 운영 기반이 된다.

이 관점을 서베이는 Code as Agent Harness로 묶는다. 자연어로 표현된 계획과 판단을 프로그램, 도구 호출, 테스트, 셸 명령처럼 실행 가능한 형태로 바꾸고 그 결과를 다시 에이전트의 판단에 연결하는 시스템이다.

근거가 된 arXiv 2605.18747은 2026년 5월 공개됐으며, Xuying Ning, Katherine Tieu, Dongqi Fu, Tianxin Wei, Lingming Zhang 등을 포함한 저자 42인의 협업 결과다. 서베이가 제시하는 목표는 실행 가능하고 검증 가능하며 상태를 보존하는 에이전트 시스템을 하나의 로드맵으로 설명하는 데 있다.

장기 과제를 수행하는 에이전트에는 다음 네 가지 속성이 요구된다.

  • 실행 가능성(Executable): 판단이 도구 호출이나 스크립트, 테스트, 셸 명령으로 구체화되고 실제로 동작해야 한다.
  • 검사 가능성(Inspectable): 계획, 실행 트레이스, diff, 실패 기록을 사람이 읽고 감사할 수 있어야 한다.
  • 상태 보존(Stateful): 메모리, 리포지토리, 체크포인트, 실행 이력이 컨텍스트 초기화와 세션 전환 이후에도 남아야 한다.
  • 통제 가능성(Governed): 권한 계층, 샌드박스, 검증 게이트, 휴먼 리뷰를 통해 자율 실행의 범위를 제한해야 한다.

기존 코드 생성 연구가 정답 코드를 한 번에 산출하는 문제에 집중했다면, 이 프레임에서는 코드가 계속 실행되고 관측되며 수정되는 매개체가 된다. 추론 결과를 기록하는 동시에 환경을 바꾸는 수단이자 검증 기준으로도 기능한다.

이 차이는 수십~수백 단계 동안 리포지토리를 수정하고 테스트를 통과시켜야 하는 장기 과제에서 선명해진다. Claude Code·Codex·Cursor 같은 코딩 에이전트가 실무에서 채택한 구조를 학술적 관점에서 일반화했다는 점도 이 서베이의 특징이다. 실무 도구에서 먼저 나타난 작동 방식을 하나의 이론적 프레임으로 정돈한 셈이다.

인터페이스에서 멀티 에이전트 협응까지

서베이가 설명하는 harness는 세 개의 연결된 계층으로 구성된다.

첫 번째 계층인 Harness 인터페이스는 에이전트의 추론·행동·환경 모델링을 코드와 연결한다. 자연어 의사결정을 도구 호출, 스크립트, 테스트처럼 실행할 수 있는 산출물로 변환하는 경계다.

두 번째 계층인 Harness 메커니즘은 실제 작업을 지속시키는 기능을 맡는다. 계획은 장기 과제를 나누고 전략을 세우며, 메모리는 파일·리포지토리·체크포인트에 진행 상태를 기록해 컨텍스트 밖으로 내보낸다. 도구 실행 계층은 호출 경로와 실패 처리를 관리한다. 실행 결과는 피드백 제어를 통해 다시 입력으로 돌아가 이후 판단을 수정한다.

세 번째 계층인 Harness 스케일링에서는 단일 에이전트 구조를 멀티 에이전트 협응으로 확장한다. 이때 해결해야 할 중심 문제는 여러 에이전트가 사용하는 공유 상태를 일관되게 유지하는 것이다.

파일에 남긴 상태가 장기 과제를 이어 준다

상태 보존 런타임은 각 반복을 깨끗한 컨텍스트에서 시작할 수 있게 하면서도 이전 작업을 잃지 않는다. 에이전트는 직전 컨텍스트 자체에 의존하는 대신 파일시스템에 기록된 상태를 읽어 작업을 재개한다. 이 구조가 여러 세션에 걸친 자율 실행의 토대가 된다.

완료 게이트는 모델이 작업을 너무 일찍 끝내려 할 때 개입한다. 훅이 종료 시도를 가로채고 원본 프롬프트를 새 컨텍스트에 다시 주입해 완료 목표에 도달할 때까지 실행을 이어 가게 한다.

판단의 타당성은 설명이 아니라 실제 실행으로 확인한다. 테스트와 셸 결과가 실행 기반 검증의 진리 신호가 된다. 계획, 트레이스, diff, 실패 로그도 파일로 남기므로 에이전트와 사람이 같은 산출물을 기준으로 실행 과정을 감사할 수 있다. 블랙박스에 머물던 추론이 검사 가능한 실행 이력으로 바뀌는 지점이다.

권한은 파일 읽기·쓰기, 네트워크 접근, 셸 실행처럼 위험도에 따라 나눈다. 비가역적이거나 위험도가 높은 행위는 휴먼 승인 또는 샌드박스 격리를 거치게 한다.

harness 자체를 개선할 때는 회귀 방지도 필요하다. 새로운 동작을 추가한 뒤 기존에 통과하던 과제가 깨지지 않도록 평가 셋과 체크포인트를 비교해야 한다. 회귀 없는 개선은 여전히 풀어야 할 난제로 남아 있다.

아니오아니오에이전트 추론: 계획 수립Harness 인터페이스:코드/도구 호출 생성상태 보존 런타임: 샌드박스실행실행 검증 통과?체크포인트 저장:파일/리포지토리실패 트레이스 기록 + 재시도과제 완료?메모리 로드 + 다음 단계휴먼 리뷰 게이트: 비가역 행위승인

실행 가능한 단위로 워크플로우를 설계한다

도입의 출발점은 자연어 판단을 실행 가능한 단위로 바꾸는 인터페이스다. 스크립트, 테스트, 셸 명령으로 환원되지 않은 결정은 실제 환경에서 확인하기 어렵다. ReAct의 reason → act → observe 반복도 컨텍스트 관리, 도구 라우팅, 실패 처리, 종료 판정을 담당하는 harness 인프라와 결합해야 안정적으로 지속된다.

생성 코드에는 테스트, 정적 분석, 실행 결과를 묶은 품질 게이트를 배치한다. 최종 과제의 성공 여부만 보지 않고 중간 트레이스와 diff까지 검사하면 품질 신호를 여러 층에서 확보할 수 있다.

메모리는 모델 컨텍스트에만 두지 않는다. 파일시스템, 리포지토리, 체크포인트로 상태를 외부화하면 컨텍스트 한계를 우회하고 세션 사이의 진행 이력을 보존할 수 있다. 장기 과제를 중단 지점에서 다시 시작할 수 있고 감사 추적성도 함께 얻는다.

도구 연동은 MCP(Model Context Protocol) 같은 표준화된 인터페이스로 호출과 관측을 일원화한다. 도구 실행에서 발생하는 부작용은 권한 계층과 샌드박스로 격리한다. 실패가 발생하면 트레이스를 파일에 남겨 다음 반복의 원인 분석에 사용한다. 다만 불완전한 피드백 환경에서의 검증과 회귀 없는 harness 개선은 별도의 설계 과제로 남는다.

단계적으로 적용한다면 다음 순서로 진행할 수 있다.

  1. 인터페이스 정립: 자연어 결정과 실행 산출물 사이의 사상 규칙을 정하고, 도구 스키마와 셸 실행 경로를 표준화한다.
  2. 검증 게이트 결합: 코드 생성 직후 테스트와 정적 분석을 실행하고, 실패하면 곧바로 재시도할 수 있게 한다.
  3. 상태 외부화: 체크포인트와 실행 이력을 파일과 리포지토리에 영속화해 장기 과제 재개와 감사 추적을 지원한다.
  4. 거버넌스 강화: 권한 계층과 휴먼 리뷰 게이트로 비가역 행위를 통제하고, 멀티 에이전트 환경에서는 공유 상태의 일관성을 점검한다.

ReAct와 Function Calling 사이에서 선택하기

Code Harness, ReAct, Function Calling은 서로 다른 실행 범위와 운영 부담을 가진다.

구분 Code Harness 에이전트 ReAct 에이전트 Function Calling 에이전트
실행 단위 코드·스크립트·테스트·셸 추론-행동-관측 루프 구조화 JSON 도구 호출
상태 보존 파일·리포지토리·체크포인트 외부화 컨텍스트 윈도 내 누적 호출 단위, 상태 비보존 경향
검증 방식 실행 기반 검증(테스트·셸 결과) 관측 텍스트 해석 반환값 스키마 검증
장기 과제 다중 세션 자율 실행 강점 컨텍스트 한계로 제약 단발성·예측 가능 과제 적합
통제·안전 권한 계층·샌드박스·휴먼 게이트 루프 종료 판정 의존 호출 화이트리스트 수준
비용·속도 인프라 오버헤드 큼 다단계로 토큰 소모 빠르고 토큰 절약, 단순

Function Calling은 예측 가능한 단일 도구 호출과 빠른 응답, 토큰 절약이 필요한 작업에 맞는다. ReAct는 여러 단계의 추론과 동적 판단이 필요하지만 하나의 컨텍스트 범위에서 끝낼 수 있는 과제에 적합하다.

Code Harness는 리포지토리를 수정하고 테스트를 통과시키는 작업처럼 여러 세션에 걸친 자율 실행과 실제 실행 결과에 의한 검증이 필요한 경우에 유리하다. ReAct를 대체하는 개념이라기보다 그 루프에 코드 실행, 상태 외부화, 검증 게이트를 덧씌운 상위 인프라로 이해할 수 있다. 메인 루프는 여전히 추론-행동-관측을 따르지만 컨텍스트 관리, 도구 라우팅, 실패 처리, 종료 판정은 별도 계층이 담당한다.

그만큼 비용과 복잡도도 커진다. 샌드박스, 체크포인트, 검증 게이트를 운영해야 하는 대신 비가역 행위를 통제하고 실행 과정을 추적할 수 있다. 단순한 과제에 이 구조를 그대로 적용하면 인프라 부담이 이점보다 커질 수 있다.

거버넌스와 복구 설계가 harness의 성숙도를 가른다

정보관리 관점에서 권한 계층과 검증 게이트는 ISMS-P 및 내부통제에서 다루는 비가역 행위 통제와 연결된다. 체크포인트와 실행 이력은 트랜잭션 복원력과 감사 추적성에 대응하며, 실행 기반 검증은 정보시스템 감리의 산출물 검증과 품질보증(QA) 체계에 맞닿아 있다.

위험도가 높은 행위에 더 강한 게이트를 배치하는 방식은 자산 위험도에 따른 차등 통제와 같은 발상이다. 상태를 영속화하는 구조는 백업·복구 절차의 RPO·RTO 설계와도 이어진다. 장애가 발생하더라도 저장된 체크포인트와 이력을 이용해 중단 지점부터 작업을 다시 시작할 수 있기 때문이다.

2026년의 과제로는 최종 성공률을 넘어서는 평가 지표, 불완전한 피드백 아래에서의 검증, 기존 성능을 훼손하지 않는 harness 개선이 제시된다. 멀티 에이전트의 공유 상태 일관성, 안전 임계 행위에 대한 휴먼 감독, 멀티모달 환경으로의 확장도 함께 다뤄야 한다.

Code as Agent Harness의 핵심은 에이전트가 코드를 생성한다는 사실 자체가 아니다. 인터페이스와 메모리, 실행 검증, 권한 통제를 하나의 구조로 묶어 장기 과제를 이어 가면서도 그 과정을 검사하고 복구할 수 있게 만드는 데 있다.

Sources

AI 에이전트에이전트 하네스상태 관리실행 기반 검증도구 통합