Code as Agent Harness: 실행을 묶는 코드

코딩 에이전트를 만드는 개발자는 모델이 테스트를 통과했다고 답해도 그 테스트가 최종 코드에서 실행됐는지 확인해야 한다. 여러 번 수정하고 도구를 실행하는 동안 코드·기억·검증 결과를 어떻게 같은 상태에 묶을까? Code as Agent Harness는 코드를 계산 결과뿐 아니라 실행과 상태를 조직하는 매체로 보는 분류를 제시하고 이 문제를 설계할 때 살필 경계를 정리한다.

Xuying Ning 외의 Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems, 2026년 arXiv v1을 기준으로 읽는다. 여러 연구와 시스템을 분류한 서베이이며 새 구현을 동일 조건으로 실행한 성능 벤치마크 논문은 아니다. Code as Agent Harness 원문

코드가 답안에서 실행의 매체로 바뀐다

다음은 설명용 가상 상황이다. 사용자가 CSV 합계 계산기를 고쳐 달라고 요청한다. 에이전트는 합계 함수를 수정하고 작은 테스트를 만든다. 다른 에이전트는 테스트 통과 기록을 보고 완료를 선언한다. 그런데 그 사이 첫 에이전트가 빈 행 처리 코드를 다시 바꿨다면 통과 기록은 최종 버전의 근거가 아니다.

채팅에 “테스트 통과”라는 문장을 더 남기는 것으로 이 간격은 없어지지 않는다. 어떤 코드에서 어떤 입력을 실행했는지 기록하고 코드를 바꾼 뒤 그 기록을 계속 사용할 수 있는지 판정해야 한다.

논문에서 하네스(harness)는 모델 주위에서 도구, 실행 환경, 기억, 검증, 권한과 반복 실행을 연결하는 소프트웨어 층이다. 저자들은 모델 내부의 능력, 시스템이 미리 제공한 기반, 에이전트가 작업 중 만드는 코드 산출물을 구분한다. 테스트·임시 도구·실행 가능한 작업 흐름은 세 번째에 속한다. 모델이 만든 코드는 최종 답안인 동시에 다음 행동을 확인하고 조정하는 재료가 될 수 있다.

세 층을 같은 가상 작업에 대입하기

원문의 분류는 인터페이스, 작동 메커니즘, 다중 에이전트 확장의 세 층이다. 아래 표는 원문 Figure 1과 서베이 범위 설명을 가상 CSV 작업에 대입한 자체 설명이다. 제품별 우열이나 성능 비교 표가 아니다.

원문 v1의 분류를 재구성한 자체 표. 서베이의 분류

인터페이스 안에서도 코드의 역할은 다르다. 추론용 코드는 중간 계산을 런타임이나 기호 계산기에 맡긴다. CSV 행의 값을 더하는 절차는 모델이 제안하고 실제 덧셈은 프로그램이 수행한다. 행동용 코드는 그 의도를 파일 쓰기나 API 호출로 바꾼다. 환경 표현용 코드는 저장소, 테스트, 실행 기록, 시뮬레이터를 통해 현재 상태와 변화 규칙을 다룬다.

프로그램으로 계산을 옮겨도 입력 열을 잘못 골랐다면 합계는 잘못된다. 파일 쓰기를 함수로 표현해도 그 파일을 수정할 권한이 생기지는 않는다. 실행 가능한 형태가 된 것과 올바른 문제를 풀도록 제약한 것은 별개의 조건이다. 원문도 행동용 코드를 인식·제어·안전 구성요소의 대체물로 취급하지 않는다. 코드 인터페이스의 역할

이 분류의 가치는 역할을 세 칸에 배타적으로 나누는 데 있지 않다. 같은 회귀 테스트는 실행 결과를 관찰하는 인터페이스이고 다음 수정을 결정하는 검증 메커니즘이며 검토자가 공유하는 산출물이기도 하다. 세 층은 하나의 코드를 서로 다른 설계 질문으로 보게 한다. 이를 서로 독립적인 구성요소 목록으로 읽으면 같은 상태의 관계를 놓칠 수 있다.

새로운 알고리즘의 기여와 개념적인 기여도 구분해야 한다. PAL 원문은 모델이 문제를 프로그램으로 바꾸고 실제 계산은 인터프리터에 맡긴다. 코드를 실행해 계산을 맡기는 아이디어 자체는 이렇게 선행 연구에 있었다. 이 서베이가 더하는 관점은 작업 중 생성한 테스트·임시 도구·흐름을 지속적으로 관찰하고 수정하고 공유하는 대상으로 묶는 것이다. 그 관점이 설계를 이해하는 데 유용하다는 것과 이 분류를 따른 시스템이 더 좋은 성능을 낸다는 것은 다른 주장이다.

계획·실행·검증은 다음 상태를 허용하는 절차다

논문은 계획–실행–검증(Plan–Execute–Verify, PEV)으로 실행 통제를 설명한다. 계획은 작업 목록뿐 아니라 수정할 파일, 보존할 조건, 검증 명령, 위험한 행동을 드러낸다. 실행은 격리되고 권한이 정해진 환경에서 상태를 바꾼다. 검증은 새 상태가 조건을 만족하는지 검사해 계속할지, 수정할지, 멈출지 정한다.

가상 계산기에 “빈 행은 무시하고 잘못된 숫자는 오류로 알린다”는 요구가 있다고 하자. 빈 행과 잘못된 숫자를 모두 0으로 처리한 코드는 예외 없이 실행될 수 있다. 정상 CSV의 합계만 검사한 테스트도 통과한다. 하지만 요구 중 두 번째 조건을 검사한 것은 아니다.

이 표는 측정 결과가 아니라 검증 범위를 설명하는 가상 예제다. 검증 도구를 추가하는 이유는 같은 초록불을 여러 번 받기 위해서가 아니다. 다른 조건을 살피는 근거를 얻기 위해서다.

원문이 말하는 검증 신호에는 컴파일러, 타입 검사, 테스트, 정적 분석, 퍼저, 실행 로그 등이 있다. 모델의 설명과 비평은 이 신호를 해석하는 데 쓸 수 있다. 다만 모델의 자신감으로 실제 검사를 대체하거나 아무 오류가 없었다는 이유로 검증하지 않은 동작까지 승인하면 경계가 무너진다. 계획·실행·검증 통제

실행할 수 있는 검증기가 올바른 기준인지는 누가 확인하나

코드로 표현한 검사는 같은 입력과 상태에서 반복 실행하기 쉽고 실패를 다음 행동에 연결할 수 있다. 그러나 실행 결과가 결정적이어도 검사 기준은 틀릴 수 있다. CSV 계산기가 잘못된 숫자를 0으로 처리하고 에이전트가 그 구현에 맞춰 기대값도 0으로 적었다면 테스트는 안정적으로 통과하면서 사용자의 요구를 어긴다. 반복 가능한 검증과 요구에 맞는 검증은 다르다.

이 상황에서 같은 에이전트에게 테스트를 더 쓰게 하는 것만으로는 독립된 근거가 생기지 않는다. 요구에서 기대값을 정한 사례, 기존 계약, 별도로 유지하는 평가 입력이 필요하다. 특히 하네스가 자신의 검증기를 수정할 수 있다면 산출물의 개선과 합격 기준의 완화를 나눠 봐야 한다. 원문의 oracle adequacy와 하네스 회귀 문제를 같은 예제에 연결한 이 리뷰의 해석이다. 검증 기준과 하네스 회귀

따라서 이 서베이에서 가져올 만한 핵심은 “모든 것을 코드로 만들자”보다 상태 변화와 검증 근거를 함께 다루는 설계 질문이다. 실행 결과를 얻기 어려운 인간의 선호나 외부 환경에서는 이 루프가 확인할 수 있는 범위도 좁아진다. 여러 도메인을 묶은 분류는 설계 후보를 찾는 지도이고 각 도메인에서 합격 기준이 충분한지는 별도로 판단해야 한다.

기억과 공유 파일만으로는 상태가 맞지 않는다

서베이는 기억을 대화 기록의 확대보다 상태 관리로 설명한다. 현재 판단에 필요한 작업 기억, 코드 구조에 관한 지식, 과거 문제 해결 경험, 장기 정보, 여러 에이전트가 공유하는 기억은 맡는 역할이 다르다. 긴 로그를 요약해 문맥에 남기고 원본은 외부에 보관하는 방식도 다룬다.

가상 작업에서 검증자에게 “CSV 테스트가 통과했다”만 요약해 넘기면 코드 버전이 사라진다. 원본 로그를 저장하더라도 요약에서 그 로그를 찾을 수 없으면 검증자는 대응 관계를 복원하기 어렵다. 따라서 버전과 검사 범위를 유지하는 것이 단순히 긴 기억을 갖는 것보다 중요하다는 판단을 이 사례에서 얻을 수 있다.

다중 에이전트 부분은 파일만 공유하는 방식, 탐색 가능한 저장소, 실행 기반 상태, 명시적인 공유 저장소인 블랙보드를 구분한다. 각각 관찰할 수 있는 것이 다르다. 파일은 현재 텍스트를 보여 주지만 누가 어떤 버전에서 테스트했는지는 별도 기록이 필요하다. 테스트 결과는 동작을 보여 주지만 확인하지 않은 계약은 담지 않는다. 블랙보드는 기록을 유지하지만 어느 값이 권위 있는 최신 상태인지 결정해야 한다.

저자들은 동기화만으로 트랜잭션이나 의미적 충돌 해결이 생기지 않는다고 지적한다. 작성자와 검증자의 변경이 서로 다른 줄에 있어 Git 병합이 성공하더라도 검증자가 전제한 입력 형식이 작성자의 변경과 충돌할 수 있다. 이 문제에 대해 읽은 상태·쓴 상태·버전 의존성·검증 의무를 선언하고 병합 뒤 다시 확인하는 방향을 제안한다. 완성된 범용 해결책을 실험으로 증명한 결과는 아니다. 공유 상태의 표현 · 의미적 충돌이라는 열린 문제

하네스를 고쳐도 검증 기준은 유지해야 한다

서베이는 실행 기록을 분석해 도구 설명, 문맥 구성, 검증기, 작업 흐름을 바꾸는 하네스 개선도 다룬다. 작업 에이전트가 CSV 코드를 고치는 것과 개선 에이전트가 앞으로 사용할 테스트·권한·재시도 규칙을 바꾸는 것은 영향 범위가 다르다.

가상 작업에서 검사 단계를 없애면 완료 시간은 줄어들 수 있다. 그러나 오류 입력을 검출하지 못하게 됐다면 성공률 개선으로 해석할 수 없다. 저자들은 하네스 변경을 격리 환경에서 평가하고 별도 평가 과제와 회귀 검사로 확인하며 권한이나 외부 행동의 경계를 바꾸는 변경에는 사람의 승인을 요구하는 방향을 설명한다. 하네스의 통제된 개선

이 분류로 설계 후보를 찾을 수는 있지만 특정 하네스가 더 빠르거나 안전하다고 결론 내릴 수는 없다. 논문은 서로 다른 연구와 제품의 메커니즘을 종합한다. 같은 모델·과제·도구 예산·판정 기준으로 모두 비교한 새 실험이 없다. 원문이 남긴 큰 문제도 판정 기준의 충분성(oracle adequacy)이다. 테스트 통과가 사용자 의도를 얼마나 표현하는지, 하네스 개선이 특정 평가에만 맞춰지지 않는지 아직 확인해야 한다. 평가와 검증의 열린 문제

작은 단일 함수 작업이라면 공유 상태 기반이나 여러 역할을 새로 만들 필요는 없다는 것이 이 글의 적용 판단이다. 가상 CSV 작업에서도 먼저 남길 것은 최종 패치와 그 패치에서 실행한 검사의 대응 관계다. 작업이 길어지고 사람이든 에이전트든 참여자가 늘어날 때 그 관계를 잃지 않도록 계획·기억·권한·검증을 확장한다. 새로운 역할 수보다 어떤 상태에 대해 무엇을 확인했는가가 설계의 출발점이 된다.

원문

Xuying Ning, Katherine Tieu, Dongqi Fu 외. Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems. arXiv:2605.18747, v1, 2026. 고정 판본 원문.