코드는 결과물이 아니라 ‘실행 기반’이다 — Code as Agent Harness 서베이

▲ 이미지: Unsplash (무료 저작권, 상업 이용 가능)

---

102페이지 서베이가 던지는 한 가지 질문

2026년 5월 18일, arXiv에 올라온 논문 하나가 AI 개발자 커뮤니티에서 빠르게 회자됐다. 제목은 간결하다 — “Code as Agent Harness”(arXiv:2605.18747). 저자는 43명, 분량은 102페이지. UIUC, Meta, Stanford 등 주요 기관 연구진이 합류한 이 서베이는 LLM 에이전트 연구의 중심축을 흔드는 주장을 내놓는다.

논문의 초록은 이렇게 시작한다: “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)으로 기능하고 있다는 것이다.

이 한 문장이 질문을 바꾼다. “AI가 코드를 얼마나 잘 쓰는가”에서 “코드라는 실행 기반을 얼마나 잘 설계했는가”로.

에이전트 하네스란 무엇인가

‘하네스(harness)’는 말 그대로 마구(馬具)다. 말의 근육이 힘이라면, 하네스는 그 힘을 원하는 방향으로 제어하는 구조다. 에이전트 시스템에서 LLM이 ‘근육’이라면, 하네스는 그 추론 능력을 실제 작업으로 연결하는 코드 기반 인프라 전체를 뜻한다. 프롬프트 구성, 도구 호출, 중간 상태 저장, 오류 피드백 루프, 결과 검증까지 — 모두 하네스의 영역이다.

논문은 에이전트 하네스의 필수 속성 네 가지를 제시한다:

• 실행 가능성(Executability): 추론이 실제 동작으로 이어질 것
• 검사 가능성(Inspectability): 로그, 추적, 중간 결과물이 외부에서 관찰 가능할 것
• 상태 유지(Statefulness): 이전 단계의 맥락과 메모리가 지속될 것
• 제어 가능성(Controllability): 권한, 정책, 샌드박스로 행동 범위를 제한할 것

이 네 가지가 갖춰지지 않으면, 아무리 강력한 모델도 “권한을 기다리는 비싼 사고(expensive autocomplete waiting for permission)”에 불과하다고 논문은 지적한다.

서베이가 제시하는 3계층 구조

논문은 코드 기반 에이전트 하네스를 세 개의 계층으로 체계화한다.

1계층: 하네스 인터페이스

코드가 에이전트를 외부 환경에 연결하는 방식이다. 함수 호출, API 래퍼, 도구 정의 — 에이전트가 어떤 ‘손’을 갖는지를 결정한다. 같은 모델도 인터페이스 설계에 따라 할 수 있는 작업의 범위가 완전히 달라진다.

2계층: 하네스 메커니즘

계획(planning), 메모리, 도구 활용, 피드백 기반 제어가 이 계층에 속한다. 특히 논문이 강조하는 것은 Plan-Execute-Verify 루프다. 단순히 실행하는 것을 넘어, 린터·테스트·실행 결과 같은 결정론적 피드백이 LLM 자기평가보다 훨씬 신뢰할 수 있는 제어 신호가 된다는 것이다. “Deterministic feedback outperforms LLM critique as control signals” — 이 한 줄이 많은 팀이 자체 평가 루프에 집중하는 이유를 설명한다.

3계층: 하네스 확장

단일 에이전트를 넘어 다중 에이전트 시스템으로 확장할 때, 공유 코드 아티팩트가 조율과 검증의 기반이 된다. 코드 저장소, 공유 상태 파일, 로그 — 이 모두가 멀티에이전트 협업의 공통 언어가 된다. 논문은 “Topological complexity taxes immature state representation design”이라고 경고한다. 구조 없이 에이전트를 늘리면 오히려 혼란만 가중된다.

왜 하네스가 모델보다 중요한가

같은 시기 발표된 또 다른 논문이 이 주장을 실증적으로 뒷받침한다. “Stop Comparing LLM Agents Without Disclosing the Harness”(arXiv:2605.23950, Yunbei Zhang 외)는 이른바 ‘바인딩 제약 정리(Binding Constraint Thesis)’를 제시한다: 장기 수행 작업에서 하네스가 유발하는 성능 분산이 모델 자체의 분산을 실질적으로 초과할 수 있으며, 심지어 모델 순위가 역전되기도 한다는 것이다.

논문의 결론은 명확하다: “leaderboard comparisons for long-horizon agents should be treated as incomplete” — 하네스 명세를 공개하지 않은 리더보드 비교는 불완전한 정보다. A 모델이 B 모델보다 낫다는 벤치마크 결과가, 사실은 A의 하네스가 더 잘 설계됐을 뿐일 수 있다.

“Code as Agent Harness” 논문도 같은 맥락의 진단을 내린다: “Most agent failures stem from harness limitations, not model deficiency.” 에이전트 실패의 대부분은 모델이 부족해서가 아니라, 하네스가 부실해서다.

실전 적용 영역: 서베이가 정리한 7개 분야

논문은 코드 기반 에이전트 하네스가 실제로 적용되는 영역을 일곱 가지로 분류한다. 이미 개발팀이 마주치고 있는 과제들이다:

• 코딩 어시스턴트: 단순 자동완성을 넘어 저장소 수준의 소프트웨어 엔지니어링
• GUI/OS 자동화: 클릭, 입력, 화면 탐색 — 코드로 GUI를 제어하는 에이전트
• 구현 에이전트(Embodied Agents): 물리적 또는 시뮬레이션 환경에서의 실행 기반 추론
• 과학 발견: 실험 설계·데이터 분석·가설 검증 자동화
• 개인화·추천: 사용자 컨텍스트를 상태로 유지하며 적응하는 시스템
• DevOps: 빌드·배포·모니터링 파이프라인의 에이전트화
• 엔터프라이즈 워크플로: 복수 시스템을 가로지르는 업무 자동화

이 목록에서 눈에 띄는 것은 범위의 폭이다. ‘코딩을 도와주는 AI’를 한참 넘어서, 실행·검증·상태 유지가 가능한 코드 구조 위에서라면 어떤 업무도 에이전트화할 수 있다는 시각이다.

미해결 과제: 논문이 솔직하게 인정한 것들

서베이는 낙관론으로 마무리하지 않는다. 하네스 엔지니어링의 열린 도전 과제를 여섯 가지로 정리한다:

• 최종 작업 성공 이상의 평가 체계 부재 — 중간 과정 품질을 어떻게 측정할 것인가
• 불완전한 피드백 하에서의 검증 — 실행 결과가 불명확할 때 에이전트는 어떻게 판단하나
• 하네스 개선 시 회귀(regression) 없는 업데이트 — 한쪽을 고치면 다른 쪽이 망가지는 문제
• 다중 에이전트 간 일관된 공유 상태 유지
• 안전 중요 행동에 대한 인간 감독(human oversight) 설계
• 멀티모달 환경으로의 확장 — 텍스트를 넘어 이미지·음성·센서 데이터를 다루는 하네스

GeekNews 댓글에서 한 개발자(baeba)는 “논문은 깔끔한 이론을 제시하지만, 실제 개발에는 모호한 요구사항, 레거시 시스템, 조직 제약이 있다”고 지적했다. 논문 자체도 이를 인식하고 있으며, 이 목록이 그 정직한 자기 고백이다.

중소기업·개발팀을 위한 실전 시사점

이 서베이가 현장에 주는 가장 실용적인 교훈을 정리하면 다음과 같다:

• 모델 선택보다 하네스 설계 먼저: GPT-4o냐 Claude냐보다, 실행·검증·상태 구조를 어떻게 만들 것인지가 성패를 가른다.
• 결정론적 피드백을 활용하라: 테스트, 린터, 실행 로그 — LLM의 자기평가보다 이쪽이 훨씬 신뢰할 수 있는 제어 신호다.
• 상태를 코드로 명시화하라: 프롬프트 안에 맥락을 구겨 넣는 대신, 코드·파일·DB로 상태를 외재화하면 에이전트가 더 긴 작업을 안정적으로 수행한다.
• 하네스 없이 에이전트를 늘리지 마라: 멀티에이전트 구조는 공유 상태 설계가 먼저다. 구조 없이 에이전트만 추가하면 복잡도만 늘어난다.
• 벤치마크 순위를 맹신하지 마라: 동일 모델도 하네스에 따라 성능이 크게 달라진다. 자신의 업무 맥락에서 직접 검증하는 것이 유일한 답이다.

---