스크랩
코드는 더 이상 LLM의 '결과물'이 아니다 — 에이전트의 실행 기반으로 보는 102페이지 서베이
한눈에 보는 핵심
UIUC, Meta, Stanford가 함께 쓴 102페이지짜리 서베이 논문 **"Code as Agent Harness"**가 던지는 메시지는 한 문장으로 요약됩니다.
코드는 LLM이 만들어내는 산출물이 아니라, 에이전트가 추론하고·행동하고·상태를 저장하고·피드백을 검증하는 '실행 기반(operational substrate)'이다.
쉽게 말하면, 코드는 단순한 .py 파일이 아니라 에이전트가 살아 움직이는 세계 그 자체라는 관점입니다. 이걸 논문은 code as agent harness라고 부릅니다.
에이전트 시스템을 3계층으로 해부하기
논문은 에이전트 시스템을 세 개의 레이어로 나눠서 분석합니다.
① Harness Interface — 코드가 에이전트와 환경을 잇는 방식
- Program-of-Thoughts처럼 추론 과정을 코드로 외부화(externalize)해 실행하고 검증
- 생성된 프로그램이 GUI·로봇 제어의 **정책(policy)**으로 작동
- 코드베이스, 트레이스, 시뮬레이터가 곧 환경 자체를 표현
② Harness Mechanisms — 장기 실행을 지속시키는 제어 시스템
장시간 돌아가는 에이전트를 떠받치는 네 가지 축입니다.
- Planning(계획): 단순한 작업 분해를 넘어
PLAN.md같은 파일시스템 기반 지속 계획으로 진화 중. Meta-Harness는 harness 설계 자체를 탐색 공간(search space)으로 삼습니다. - Memory(메모리): working / semantic / experiential / long-term / multi-agent + context compaction으로 구분. 핵심은 *"메모리는 단일 벡터DB가 아니라 통합된 상태 관리 계층"*이라는 것.
- PEV Loop: Plan → Execute → Verify 사이클을 **cybernetic governor(사이버네틱 조절기)**로 재정의. 실행 권한은
read-only → sandbox-edit → full-access(HITL)의 3단계 모델로 설계됩니다. - AHE: harness 자체를 측정하고 최적화하는 메타 계층.
③ Scaling the Harness — 멀티에이전트의 협업 방식
여러 에이전트가 코드라는 공유 매체 위에서 협업하는 방식을 다룹니다. 여기서 가장 흥미로운 통찰이 나옵니다.
"토폴로지 복잡성은 공유 상태 표현의 미성숙함이 만든 세금이다."
상태를 잘 설계한 시스템은 단순한 구조로도 잘 돌아가고, 암묵적 상태에 의존하는 시스템은 그 결핍을 복잡한 토폴로지로 메꾼다는 이야기입니다.
바로 써먹을 수 있는 실전 인사이트
- Context Compaction + State Offloading: 컨텍스트 윈도우에 모든 걸 욱여넣지 말고, 결정에 필요한 요약만 active context에 두고 전체 데이터는 MCP 스타일 프로토콜로 오프로드하라 — 실무 꿀팁입니다.
- 검증을 결정적 센서로: 린터·타입 체커·테스트·퍼저 같은 결정적(deterministic) 피드백이 LLM의 비평(critique)보다 더 신뢰할 수 있는 제어 신호입니다.
- 실패의 원인은 모델이 아니라 harness에 있다: "대부분의 에이전트 실패는 부족한 저장소 컨텍스트, 깨지기 쉬운 도구 인터페이스, 약한 검증기, 과도한 토큰 비용, 잘못된 재시도 정책에서 온다."
아직 풀리지 않은 문제들
논문이 남긴 7가지 오픈 문제 중 눈에 띄는 세 가지입니다.
- 최종 성공 외의 평가: 중간 트레이스, 복구 시도, 안전성 체크도 1급 지표로 다뤄야 한다
- 회귀 없는 harness 개선: 실패에서 배우되 기존 동작을 깨뜨리지 않는 방법
- 멀티에이전트 간 트랜잭셔널 공유 상태: 여러 에이전트가 동시에 코드를 수정할 때의 충돌 해결
정리하며
이 서베이의 진짜 가치는 *"좋은 모델을 쓰면 되겠지"*라는 막연한 기대를 **"좋은 harness를 설계해야 한다"**는 구체적 엔지니어링 문제로 바꿔놓는 데 있습니다. 에이전트를 만들고 있다면, 모델 성능을 탓하기 전에 저장소 컨텍스트·도구 인터페이스·검증기·상태 관리를 먼저 점검해 보는 게 어떨까요?