코드를 에이전트의 “집”으로: 아주 쉽게 읽는 버전

원본 정리 노트: Code as Agent Harness - Toward Executable, Verifiable, and Stateful Agent Systems

먼저, 한 줄 결론 — 이 논문이 말하는 “하네스(harness)“란?

이 논문은 “하네스”를 AI가 그 안에서 살면서 일하는 집이라고 봅니다.

조금 더 풀어 볼게요.

AI(여기서는 글을 잘 쓰는 똑똑한 프로그램, LLM)는 혼자서는 생각만 할 수 있어요.
그런데 생각을 진짜 “행동”으로 바꾸려면, 그 생각을 실제로 해보고, 틀리면 고치고, 결과를 기억할 장소가 필요해요.
그 장소가 바로 하네스예요.

이 논문의 가장 중요한 깨달음은 이거예요.
“코드(컴퓨터 프로그램)는 AI가 만들어 내는 ‘결과물’이 아니라, AI가 그 위에서 사는 ‘집’이다.”

지금까지 사람들은 코드를 “AI가 마지막에 뱉어내는 답”이라고만 생각했어요.
하지만 이 논문은 생각을 뒤집어요.
코드는 답이 아니라, AI가 그 안에서 생각하고, 움직이고, 세상을 이해하고, 자기가 한 일을 검사하는 바닥이자 집이라는 거예요.

그래서 좋은 집(좋은 하네스)은 네 가지를 갖춰야 해요.
하나, 실행 가능(executable) — 기계가 진짜로 돌려볼 수 있어야 해요.
둘, 들여다보기 가능(inspectable) — 안에서 무슨 일이 일어나는지 볼 수 있어야 해요.
셋, 상태 유지(stateful) — 방금 한 일을 기억해야 해요.
넷, 통제됨(governed) — 규칙과 안전장치로 잘 다스려져야 해요.

이 논문은 마지막에 이렇게 말해요.
“AI를 더 똑똑하게 만드는 것(더 큰 모델)보다, AI가 사는 집을 잘 짓는 것(하네스 공학)이 다음 큰 도약을 만든다.”

이제부터 이 한 줄 결론을 천천히, 빠짐없이 풀어서 설명할게요.

이 논문이 왜 쓰였나 (배경)

요즘 AI는 코드를 정말 잘 짜요.
간단한 프로그램부터 큰 회사의 복잡한 소프트웨어까지 척척 만들어요.

그런데 문제가 하나 있어요.
“방금 짠 코드를 실제로 돌려보고, 실패하면 스스로 고치고, 그 결과를 기억해서 다음 행동에 이어가는” 일은 아직 잘 못 해요.
이렇게 오래, 여러 단계에 걸쳐 혼자 일하는 능력을 장기 자율성이라고 불러요.
이 장기 자율성이 아직 불안정해요.

저자들은 그 이유를 콕 집어요.
문제는 AI가 멍청해서가 아니에요.
문제는 AI의 생각(출력)을 오랜 행동과 기억으로 안정적으로 이어주는 **시스템의 믿음직함(신뢰성)**이 부족해서예요.

쉽게 말하면, 머리는 똑똑한데 그 머리가 살 집이 허술한 거예요.
그래서 저자들은 “집을 제대로 짓자”고 말하는 거예요.

흐름 한눈에 보기 (이 논문의 척추)

이 논문은 “코드가 AI의 집(하네스)이 되는 과정”을 순서대로 따라가요.
그 순서가 곧 논문의 뼈대예요.

먼저 §2에서, 코드가 AI의 집으로 **들어오는 문(인터페이스)**을 설명해요.
코드는 AI가 생각하고, 움직이고, 세상을 이해하는 통로가 돼요.

다음 §3에서, 그 집을 시간이 지나도 **튼튼하게 유지하는 장치(메커니즘)**를 설명해요.
계획 세우기, 기억하기, 도구 쓰기, 검사하기, 그리고 집 자체를 고치기 같은 장치들이에요.

그다음 §4에서, **여러 AI가 한 집을 함께 쓰는 법(스케일 업)**을 설명해요.
여러 친구가 같은 코드를 같이 보고 고치면서 협동하는 거예요.

마지막 §5에서, 이 생각을 다섯 가지 실제 분야에 적용해 보고, 아직 못 푼 숙제 7개를 보여줘요.

이 모든 걸 관통하는 한 문장은 이거예요.
“실행되고, 들여다볼 수 있고, 기억하고, 통제되는 프로그램 하나가 — 생각·행동·세상 이해·피드백·검사를 모두 하나로 묶어준다.”

1장. 들어가며 — 코드를 “집”으로 다시 정의하기

이 장은 논문 전체의 출발점이에요.

지금까지 코드는 AI가 만들어 내는 결과물이었어요.
하지만 이제 코드의 역할이 바뀌고 있다고 선언해요.
코드는 AI가 생각하고, 행동하고, 세상을 그려보고, 진짜로 돌려서 확인하는 운영의 바닥이 되었어요.
이 바닥을 어려운 말로 **운영 기질(operational substrate)**이라고 불러요.
“기질”은 그 위에서 무언가가 자라는 바탕이라는 뜻이에요. 마치 식물이 자라는 흙처럼요.

저자들은 이 새로운 관점에 이름을 붙여요.
바로 **에이전트 하네스(agent harness)**예요.
하네스는 AI를 둘러싼 소프트웨어 껍데기예요.
이 껍데기 안에는 도구, API, 안전한 실험실(샌드박스), 기억 장치, 검사기, 권한의 울타리, 반복 루프, 그리고 피드백 통로가 들어 있어요.

저자들은 다시 강조해요.
AI가 혼자 잘 일하지 못하는 진짜 병목은 모델의 똑똑함만이 아니에요.
모델의 생각을 오랜 행동과 변하지 않는 기억으로 이어주는 시스템의 믿음직함도 함께 봐야 해요.

코드의 역할을 또렷이 하려고, 저자들은 세 가지를 구분해요.

하나, 모델 안의 능력(model-internal capabilities).
이건 AI 머릿속에 있는 능력이에요. 생각하고, 계획하고, 스스로 평가하는 힘이죠.

둘, 시스템이 미리 깔아준 인프라(system-provided harness infrastructure).
이건 누군가 미리 만들어 둔 도구, API, 샌드박스 같은 거예요. AI가 바깥세상과 연결되는 통로죠.

셋, AI가 스스로 만든 코드 산출물(agent-initiated code artifacts).
이게 이 논문의 진짜 주인공이에요.
AI가 일하다가 직접 만들고, 돌리고, 고치고, 친구와 나누는 코드들이에요.
예를 들어 다시 검사하는 테스트(회귀 테스트), 잠깐 쓰는 도구, 작은 전용 언어 프로그램(DSL), 다시 쓸 수 있는 기술(스킬), 그리고 프로그램이 일하다 멈춘 중간 상태 같은 것들이죠.

지금까지의 다른 정리 논문들은 주로 첫째와 둘째만 다뤘어요.
이 논문의 새로움은 셋째, 즉 AI가 스스로 만든 코드에 집중한 데 있어요.
이렇게 보면 코드는 단순한 답이 아니라, 통로이자 능력이자 여러 AI를 묶는 중심 축이 돼요.

저자들이 이 논문에서 새로 한 일 (기여)

첫째, 생각의 틀을 새로 짰어요(개념적 재틀짜기).
“코드는 AI의 집(하네스)이다”라는 생각을 또렷이 세웠어요.
코드를 결과물에서, 실행되고·검증되고·기억하는 운영 바닥으로 다시 정의했어요.

둘째, 분류표를 만들고 정리했어요(분류 체계와 종합).
코드를 집으로 보는 관점을 세 층으로 나눴어요.
집의 문(인터페이스) / 집의 장치(메커니즘) / 여러 명이 함께 쓰는 집(스케일).
그리고 대표적인 방법들을 차곡차곡 모았어요.

셋째, 현실에 연결하고 숙제를 제시했어요(응용과 향후 과제).
이 분류표를 실제 분야들(코딩 도우미, 컴퓨터 화면 조작, 과학 발견, 개인 맞춤, 로봇)에 이었어요.
그리고 아직 풀어야 할 중요한 문제들(평가·검증·안전·협동)을 짚었어요.

2장. 집으로 들어가는 문 — 코드는 생각·행동·세상의 통로

이 장은 논문의 핵심 주장을 증명하는 곳이에요.
주장은 “코드가 AI를 움직이는 집(하네스)으로 작동한다”는 거예요.
이걸 세 가지 역할로 나눠서 보여줘요. 생각하기, 행동하기, 세상 이해하기.

2.1 생각을 위한 코드 (Code for Reasoning)

AI가 말로만 생각하면 한계가 있어요.
예를 들어 복잡한 계산을 머릿속으로만 하면 자꾸 틀려요.
그래서 코드를 생각의 통로로 써요.
이걸 다시 세 가지로 나눠요.

하나, 계산을 바깥에 맡기는 방식(Program-Delegated Reasoning).
어려운 계산은 직접 안 하고, 코드를 짜서 계산기(인터프리터)에게 맡겨요.
PAL, PoT, CodeI/O 같은 방법들이 여기에 들어가요.

둘, 수학적으로 딱 증명하는 방식(Formal Verification and Symbolic Reasoning).
Lean이나 Coq 같은 “증명 도우미”와 SMT 솔버라는 도구를 써요.
이 도구들은 생각의 한 단계 한 단계가 정말 맞는지 기계처럼 꼼꼼히 검사해요.

셋, 돌려보고 고치기를 반복하는 방식(Iterative Code-Grounded Reasoning).
만들고 → 돌려보고 → 검사하고 → 고치고를 빙글빙글 반복해요.
실제로 돌렸을 때 남는 기록(실행 트레이스)과 보상(잘했을 때 주는 점수)으로 생각을 다듬어요.
CodePRM, RLEF 같은 방법들이에요.

2.2 행동을 위한 코드 (Code for Acting)

AI는 “이렇게 하고 싶다”는 큰 뜻을 가져요.
코드는 그 뜻을 진짜로 할 수 있는 행동으로 바꿔주는 조종 통로예요.
이것도 세 가지로 나눠요.

하나, 할 수 있는 기술 중에서 고르기(Grounded Skill Selection).
미리 만들어 둔 기술 모음에서, 지금 환경에서 진짜 할 수 있는 행동을 골라요.
SayCan, KnowNo 같은 방법이에요.

둘, 행동 프로그램을 직접 짜기(Programmatic Policy Generation).
AI가 파이썬 코드나 행동 트리(behavior tree, 행동을 나뭇가지처럼 짜둔 것)를 스스로 만들어요.
CaP, RoboCodeX, Code-BT 같은 방법이에요.

셋, 평생 기술을 쌓아가는 AI(Lifelong Code-Based Agents).
Voyager처럼, 쓸 수 있는 기술들을 오래오래 모으고 점점 발전시켜요.

2.3 세상을 위한 코드 (Code for Environment)

AI는 세상이 어떻게 생겼고 어떻게 변하는지를 알아야 해요.
코드는 이 세상을 프로그램, 시뮬레이터, 실행 기록, 테스트로 또렷이 그려줘요.
그러면 AI가 세상을 물어보고, 고치고, 확인할 수 있어요.
여기에도 네 갈래가 있어요.

하나, 세상을 구조로 표현하기(Structured World Representations). ViStruct, PoE-World 같은 것.
둘, 실행 기록으로 세상 모델 만들기(Execution-Trace World Modeling). WorldCoder, CWM 같은 것.
셋, 코드 기반 평가 환경(Code-Grounded Evaluation Environments). SWE-bench, InterCode 같은 것.
넷, 검증 가능한 환경 만들기(Verifiable Environment Construction). SWE-smith, EnvScaler 같은 것.

여기서 “코드”란 정확히 무엇일까 (범위 정하기)

이 논문이 말하는 “코드”는 분명한 선이 있어요.
코드란 돌려볼 수 있거나 기계가 검사할 수 있는 것들이에요.
프로그램, 스크립트, 형식 명세, API 스키마, 테스트, 시뮬레이터, 실행 기록 같은 거죠.

반대로 코드가 아닌 것도 정해요.
눈으로 보는 날것의 감각, 몸의 물리적 상태, 사람의 속마음, AI 머릿속의 숨은 생각.
이것들은 그 자체로는 코드가 아니에요.
물론 코드라는 통로를 거쳐서 느끼고, 적고, 검사할 수는 있어요.
하지만 코드와 헷갈리면 안 돼요.

3장. 집을 튼튼히 유지하는 장치들 — 계획·기억·도구·검사·자기수리

2장에서 만든 통로(문)는 한 번 쓰고 끝나면 안 돼요.
AI가 오래 일하는 동안 계속 튼튼하게 유지돼야 해요.
그래서 이 장은 다섯 가지 장치를 설명해요.
이 장치들은 나중에 4장(여러 AI가 함께 쓰기)의 바탕이 돼요.

3.1 계획 세우기 (Planning)

계획은 AI가 어디로 갈지 정하는 조종간이에요.
저자들은 계획을 네 종류로 나눠요.

하나, 줄 세우기(선형 분해). 할 일을 차례대로 한 줄로 늘어놓아요.
둘, 구조에 기대기(구조 기반). 코드의 의존 관계나 저장소 지도 같은 바깥 구조에 발을 딛고 계획해요.
셋, 여러 길을 찾아보기(검색 기반). 답을 내기 전에 여러 후보를 두루 탐색해요.
넷, 여럿을 지휘하기(오케스트레이션 기반). 누가 무슨 역할을 할지, 어떤 순서로 갈지, 피드백을 어디로 보낼지 시스템 전체를 조율해요.

3.2 기억과 맥락 다루기 (Memory & Context Engineering)

AI가 한 번에 볼 수 있는 양(활성 컨텍스트 창)은 정해져 있어요.
그런데 할 일은 점점 길어져요.
이 둘 사이의 팽팽한 줄다리기를 풀어야 해요.
그래서 기억을 다섯 층으로 나눠서 관리해요.

하나, 작업 기억. 지금 고치고 있는 흐름을 붙잡아 둬요.
둘, 의미 기억. 저장소 구조에 맞춰 필요한 증거를 찾아와요.
셋, 경험 기억. 여러 일에 다시 쓸 수 있는 고치는 요령을 모아둬요.
넷, 장기 기억. 검증을 통과한 결과(커밋, 해답)를 오래 보관해요.
다섯, 여러 AI 기억. 친구들끼리 함께 보는 공용 칠판(블랙보드)을 둬요.

또 두 가지 기술로 기억을 조율해요.
맥락 압축(context compaction) — 내용을 줄여서 담아요.
상태 떼어두기(state offloading) — 지금 안 쓰는 상태는 바깥 저장소로 옮겨둬요.

3.3 도구 쓰기 (Tool Use)

도구는 AI의 뜻과 바깥 시스템을 잇는, 잘 다스려진 연결이에요.
네 종류가 있어요.

하나, 기능 중심. API를 부르고 문서를 찾는 데 집중해요.
둘, 환경과 직접 상호작용. 저장소, 셸, 샌드박스 안에서 직접 손을 대요.
셋, 검사 주도. 테스트, 린터(코드 검사기), 정적 분석기를 결정론적 센서로 써요.
여기서 “결정론적 센서”란, 운에 맡기지 않고 통과/실패를 딱 잘라 판정하는 검사기를 말해요.
넷, 작업 흐름 지휘(워크플로 오케스트레이션). 생명주기 훅, 권한 정책, 사람의 승인 문(게이트)으로 이 모든 걸 조율해요.

3.4 계획-실행-검증 루프 (Plan-Execute-Verify, PEV)

이건 이 논문에서 아주 중요한 장치예요.
AI가 코드를 고치는 과정을 빙글빙글 도는 조종 루프로 바꾼 거예요.
세 단계로 이루어져요.

계획 단계.
“무엇을 바꿀지, 무엇은 절대 안 바뀌어야 하는지(불변 조건), 어떤 명령으로 검사할지, 잘못되면 어디로 되돌릴지”를 미리 적어둬요.
이걸 어려운 말로 **상태 전이 계약(state-transition contract)**이라고 해요.
즉, “이런 약속대로 상태를 바꾸겠다”는 계약서예요.

실행 단계.
바깥과 떨어진 안전한 실험실(격리된 샌드박스) 안에서 바꿔봐요.
권한도 단계별로 줘요. 처음엔 읽기만, 그다음 샌드박스 안에서 고치기, 마지막에 전체 접근.
이걸 **다중 계층 권한(multi-tier permission)**이라고 해요.

검증 단계.
컴파일러, 타입 검사기, 단위 테스트, CI 파이프라인 같은 결정론적 센서로 새 상태를 약속과 비교해요.
그 결과에 따라 세 갈래로 정해요.
계속 갈지(continue), 고칠지(revise), 아니면 사람에게 넘길지.
사람에게 넘기는 걸 **HITL(Human-in-the-loop, 사람이 끼어드는 것)**이라고 해요.

3.5 집 자체를 고치는 AI (Agentic Harness Engineering, AHE)

여기서는 집(하네스) 그 자체를 더 좋게 만드는 일을 다뤄요.
세 가지가 서로 도와요.

하나, 깊은 기록 모으기(deep telemetry).
프롬프트, 토큰 비용, 도구에 넣은 값, 샌드박스 사진(스냅샷), 테스트 결과를 하나의 기록으로 엮어요.
그러면 집을 고치는 일이 그때그때 땜질이 아니라, 비교해서 진단하는 일이 돼요.

둘, 진화 에이전트(Evolution Agent).
이 기록을 받아서 집의 부품들을 개선 후보로 내놓는 한 단계 위의 AI예요.
프롬프트 틀, 검색 정책, 도구 스키마, 권한 규칙, 작업 흐름 모양 같은 걸 바꿔보자고 제안하고, 평가하고, 채택해요.

셋, 통제된 집 고치기(governed harness mutation).
중요해요. 진화 에이전트조차도 PEV 루프 안에 가둬요.
그래서 집을 바꾸는 모든 일은 격리된 곳에서 돌려보고 검증해야 해요.
특히 권한의 울타리나 사람 검토 규칙을 건드리면, 반드시 사람의 승인(HITL)을 받아야 해요.
이렇게 해서 AI가 끝없이 자기 마음대로 자기를 바꾸는 걸 막아요.

3장 정리

다섯 장치는 이렇게 손을 잡아요.
모델의 판단(계획), 변하는 일의 상태(기억), 실제로 돌아가는 행동(도구), 빙글빙글 도는 조종(PEV 루프), 그리고 집 자체를 재고 고치기(AHE).
이 다섯이 합쳐져서, 코드를 단순한 결과물이 아니라 울타리가 있고, 들여다볼 수 있고, 고칠 수 있는 집으로 운영하는 완성된 바탕을 만들어요.

4장. 집을 키우기 — 여러 AI가 코드 위에서 함께 일하기

이 장은 큰 전환점이에요.
지금까지는 AI 한 명이었어요.
이제 여러 AI가 함께 일하는 경우로 넓혀요.
핵심은 공유 코드를 하나의 공통 바닥(기질)으로 삼는 것이에요.
그러면 집을 부품처럼 나누고, 또 들여다볼 수 있게 만들 수 있어요.

4.1 함께 일하는 세 가지 방법

여러 AI가 협동하는 방식을 세 가지 잣대로 나눠요.

하나, 역할 나누기(기능 역할 특화).
프로그램 짜기, 이해하기, 검증하기, 실행하기, 계획하기 — 이렇게 역할을 나눠 맡아요.

둘, 공유 코드 위에서 상호작용하는 방식.
같이 만들기, 비판하고 고치기, 서로 깐깐하게 검증하기, 논리로 토론하기.

셋, 작업 흐름의 모양(토폴로지).
미리 정해둔 모양들이 있어요. 사슬, 고리, 계층, 별 모양 같은 거예요.
반대로 실행 피드백을 보고 흐름도(DAG)를 그때그때 다시 그리는, 목표 지향적이고 잘 적응하는 방식도 있어요.
EvoMAC, SEW, FlowReasoner 같은 것들이에요.

4.2 코드라서 생기는 “정답 신호”들과 공유 장치

코드는 진짜로 돌릴 수 있어요.
그래서 객관적인 정답 신호(오라클)를 얻을 수 있어요.
“오라클”은 실행 결과로 맞고 틀림을 알려주는 신호예요.

이런 신호들이 있어요.
컴파일러나 문법 오류, 테스트 통과/실패, 퍼저(fuzzer, 마구 입력을 넣어 망가뜨려 보는 도구)가 잡은 충돌 기록, 정적 분석 경고(CWE 보안 약점), 성능 측정, 그리고 MAGE의 시계 한 칸 단위 파형 시뮬레이션까지요.

그리고 여러 AI가 발을 맞추는 공유 장치도 있어요.
모두가 읽고 쓰는 공용 칠판(블랙보드), 따로 작업한 가지들을 합치기(병렬 브랜치 병합), 맥락을 정리해서 나눠주기, 계층 기억, AI 일꾼 늘리기 같은 거예요.

4.3 저자들의 주장: “공유 코드 중심의 집을 짓자”

여기서 저자들은 자기 입장(포지션)을 또렷이 밝혀요.
“여러 AI가 함께 쓰는, 코드 중심의 공유 집을 만들자”는 거예요.

지금 시스템들이 공유 집을 표현하는 방식을 네 단계로 줄 세워요.
가장 약한 것부터요.
하나, 묵시적/파일만(implicit/file-only) — 어디에도 안 적고 그냥 짐작.
둘, 저장소 기반(repository-based).
셋, 실행 기반(execution-based).
넷, 칠판/공유 상태(blackboard/shared-state).

그리고 큰 빈틈(central gap)을 진단해요.
대부분의 시스템이 가장 약한 “묵시적·파일만” 단계에 머물러 있어요.
공유 집의 상태를 제대로 적어둔 공식 모델이 없어요.
코드는 진짜로 돌릴 수 있는데도, 그 정답 신호를 시스템 구조 차원에서 제대로 못 쓰고 있어요.

또 여러 AI가 “이제 그만하자”고 끝내는 기준(수렴)을 여섯 가지로 나눠요.
하나, 정확성으로 끝(테스트 통과).
둘, 보안으로 끝(CWE·퍼저 기준).
셋, 성능으로 끝(시간·메모리 한계).
넷, 점수로 끝(시뮬레이션이 얼마나 어긋났나).
다섯, 합의로 끝(여러 명의 다수결).
여섯, 그냥 끝(정해진 횟수만 돌고 멈춤).
저자들은 마지막 “그냥 끝”이 흔하다는 것 자체가, 공식 바닥이 없다는 증거라고 말해요.

4.4 여기서 드러나는 공통 패턴들

저자들이 여러 사례에서 공통 패턴을 뽑아내요.

첫째, 묵시적인 공유 상태가 약점의 뿌리예요. 안 적어두고 짐작하면 시스템이 약해져요.
둘째, 파일·테스트·로그 같은 코드 통로를 써도, 협동의 병목이 완전히 사라지진 않아요.
셋째, 실행 피드백은 말로 하는 추론과 형식적 검증 사이의 다리예요.
AI의 시뮬레이션이 꽤 정확할 때도 있어요.
하지만 런타임 충돌이나 자원 고갈 같은 구석진 경우에는, 진짜로 돌려보는 게 꼭 필요해요.
넷째, 저장소 기반(정적인 구조)과 실행 기반(움직이는 행동)은 서로 보완해요.
하지만 아직 둘을 하나의 바닥으로 합친 시스템은 없어요.
다섯째, 흐름의 복잡함과 집의 형식성은 반비례해요.
즉, 공유 바닥이 또렷하고 잘 정해져 있을수록, 협동 구조는 단순해도 충분하다는 경향이 보여요.

5장. 새로 떠오르는 분야와 7가지 숙제

이 장은 두 가지를 해요.
먼저, “코드는 AI의 집”이라는 생각을 다섯 가지 실제 분야에 비춰봐요.
그다음, 모두가 함께 안고 있는 풀리지 않은 숙제 7개를 늘어놓아요.

5.1 다섯 가지 분야 (프로그램 세계)

이 다섯 분야는 모두 **프로그램 세계(program world)**로 다시 그려져요.
“프로그램 세계”란, 상태도 행동도 변화 규칙도 전부 코드로 정해진 환경이에요.
다만 한눈에 다 보이지는 않는, 일부만 보이는 세계예요(부분 관찰).

하나, 코드 도우미(code assistants).
저장소, 테스트, CI/CD 파이프라인을 집으로 삼아요.
그래서 소프트웨어를 스스로 만드는 일을 빙글빙글 반복해요.

둘, 컴퓨터 화면·운영체제 조작 AI(GUI/OS 에이전트).
화면 구조(DOM), 접근성 트리, 스크린샷을 눈으로 받아요.
그리고 파이썬이나 자바스크립트 행동을 실행해요.
여기서는 변화 규칙 자체가 브라우저 엔진이나 운영체제예요.

셋, 몸을 가진 로봇 AI(autonomous embodied agents).
물리 시뮬레이터와 층층이 쌓은 집을 써요.
의미를 정하는 계획층 → 코드 안전 울타리 → 로봇 조종기 순서예요.
이렇게 해서 다시 쓸 수 있는 기술 모음을 쌓아가요.

넷, 과학 발견 AI(agents for scientific discovery).
가설, 실험 방법, 분석을 전부 돌릴 수 있는 프로그램으로 바꿔요.
그래서 스스로 실험하는 실험실(self-driving laboratory)과, 만들고-돌리고-피드백받는 닫힌 루프를 만들어요.

다섯, 개인 맞춤 AI(personalization agents).
사용자의 취향을 고칠 수 있는 구조화된 상태로 보관해요.
하지만 고유한 약점이 있어요.
사람이 얼마나 좋아하는지를 자동으로 재는 지표(참여 지표)가 못 믿을 만하다는 거예요.

5.2 아직 못 푼 7가지 숙제

이 일곱 가지 문제는 다섯 분야 모두에 공통으로 나타나요.

하나, 집 단위 평가와 정답기의 적정성(oracle adequacy).
돌려보는 검사기가, 우리가 정말 원하는 걸 충분히 잡아내는지 묻는 문제예요.

둘, 실행을 넘어선 의미 검증(semantic verification).
테스트를 통과했다고 완전히 맞는 건 아니에요.
그래서 어디까지 검증했는지 범위를 밝힌, 여러 겹의 검증 묶음이 필요해요.

셋, 퇴보 없이 스스로 진화하는 집(self-evolving harnesses without regression).
집을 고치는 일 자체를, 안전이 걸린 중요한 코드 변경처럼 조심히 다뤄야 해요.

넷, 거래처럼 다루는 공유 상태와 의미 충돌 풀기(transactional shared program state).
여러 AI가 계획·테스트·기억을 함께 쓸 때, 단순한 파일 차이를 넘어 가정(assumption) 수준의 충돌까지 풀어야 해요.

다섯, 사람 개입의 안전과 책임을 상태로 남기기(HITL safety and accountability).
승인, 거부, 정책 예외 같은 일을 그때그때 흘려보내지 말고, 집의 상태 변화로 또렷이 기록해야 해요.

여섯, 여러 감각을 쓰는 코드-집 시스템(멀티모달).
눈으로 보는 피드백, 몸으로 느끼는 피드백을 잘 보정된 증거로 다뤄야 해요.
그래야 오래 혼자 일할 수 있어요.

일곱, 집 짓는 과학을 세우기(science of harness engineering).
연구 대상을 “모델 하나”가 아니라 “닫힌 루프 전체 시스템”으로 옮겨야 해요.
그래서 실행 가능·들여다보기 가능·상태 유지·통제됨이라는 네 가지를 한꺼번에 만족하는 설계 원칙을 세워야 해요.

비슷한 연구들과 비교해 보기

저자들은 2026년에 나온 비슷한 논문 네 편과 이 논문을 비교해요.
네 편 모두 “에이전트 하네스” 이야기에서 곧바로 갈라져 나온 동시대 논문이에요.

AutoHarness — Gemini-2.5-Flash가 환경 피드백을 보며 반복해서 코드 집을 자동으로 만들어 줘요. 규칙 위반 행동을 미리 막고, 정책 전체를 코드로 짜요. (방법 논문, 실험 있음, 코드 공개 O)
What Makes a Harness a Harness (de Macedo) — “하네스가 무엇인가”의 필요충분 조건을 또렷이 정의해요. 실제 하네스 6개(Claude Code, Codex CLI, Aider, Cline, OpenHands, SWE-agent)에 “이건 하네스인가” 시험을 적용해요. (정의 논문, 실험 없음, 코드 공개 X)
RHO — 과거 기록만 가지고 스스로 집을 더 좋게 만들어요. 정답표 없이도 자기 선호로 피드백을 대신해요. SWE-Bench Pro에서 59%→78%로 한 라운드 만에 올랐어요. (방법 논문, 코드 공개 O)
MemCoder — 커밋 기록에서 “의도→코드”를 뽑아내는 구조적 기억으로 코드 AI를 강하게 해요. SWE-bench Verified에서 최고 성적, DeepSeek-V3.2보다 +9.4%. (방법 논문, 코드 공개 O)

그럼 이 논문은 어디에 있을까요?

방법 논문들(AutoHarness, RHO, MemCoder)은 각각 “어떻게(how)“를 보여줘요.
정의 논문(de Macedo)은 “하네스가 무엇인지”를 묻지만, “왜 하필 코드가 좋은 바닥인지”는 따지지 않아요.

이 논문 “Code as Agent Harness”는 이 흩어진 조각들을 하나로 묶어요.
세 층(문 → 장치 → 여러 AI)으로 전체를 정리하면서, “코드가 왜 좋은 공유 바닥인지”를 또렷이 논증해요.
즉, 다른 논문들이 “어떻게”를 보여줄 때, 이 논문은 “왜 코드인가”와 “전체 그림은 무엇인가”를 동시에 보여줘요.
그래서 지금 비어 있던 이론적 접착제 역할을 해요.

핵심 깨달음 4가지 (한 개념씩)

1. 코드는 AI의 결과물이 아니라 AI가 사는 집이다

코드를 “AI가 마지막에 뱉는 답”으로 보던 시각을 뒤집어요.
코드는 AI가 생각하고, 행동하고, 세상을 그리고, 검사하는 일을 모두 그 위에서 하는 **집(운영 기질)**이에요.
핵심은 세 가지를 구분하는 거예요.
모델 안의 능력 / 시스템이 깔아준 인프라 / AI가 스스로 만든 코드.
기존 연구는 앞의 둘에 가까웠고, 이 논문의 독창성은 셋째에 있어요.

언제 맞는 말일까: “코드”는 돌릴 수 있고 검사할 수 있는 것에 한해요. 날것의 감각, 몸, 사람 속마음, 숨은 생각은 “코드 아님”으로 뺐어요.
어떻게 쓸까: AI 시스템을 설계할 때 “이 능력은 모델 안인가, 인프라인가, AI가 만든 건가”를 가르는 진단 틀로 써요.

2. 진짜 병목은 모델의 똑똑함이 아니라 시스템의 믿음직함이다

AI가 혼자 오래 일하지 못하는 진짜 이유는 “더 똑똑해지면 풀릴 추론력 문제”가 아니에요.
모델의 생각을 오랜 행동과 지속되는 기억으로 안정적으로 잇는 시스템 신뢰성 문제예요.
그래서 다음 도약의 손잡이를 “더 큰 모델”에서 “집 짓는 과학(harness engineering)“으로 옮겨요.
좋은 집의 네 속성(실행·검사·상태·통제)을 갖추는 게 핵심 목표가 돼요.

언제 맞는 말일까: 오래, 여러 단계, 기억이 필요한 자율 AI에 해당해요. 한 번 묻고 답하는 경우엔 진단이 달라요.
어떻게 쓸까: 돈과 노력을 “모델 키우기”와 “집 인프라(검증·기억·통제)” 중 어디에 쓸지 정하는 근거로 삼아요.

3. 계획-실행-검증 루프는 결정론적 센서로 믿음을 만든다

PEV 루프에서 계획은 단순한 지시가 아니라 “상태를 이렇게 바꾸겠다는 계약”이에요.
실행은 샌드박스 안에서 단계별 권한으로 격리돼요.
검증은 운에 맡기는 LLM 자기평가가 아니라, 결정론적 센서(컴파일러·테스트·퍼저·정적분석)로 계속할지/고칠지/사람에게 넘길지 정해요.
핵심은 검사를 AI 자기 판단이 아니라, 통과/실패를 딱 잘라주는 기계 신호에 맡기는 거예요.

언제 맞는 말일까: 컴파일러·테스트 같은 또렷한 정답기가 있는 분야(코드, 구조화된 환경)에서 강력해요. 실행만으로 못 가리는 의미 검증은 아직 숙제예요(5장).
어떻게 쓸까: “어느 단계에 어떤 결정론적 센서를 끼울 수 있나”를 설계 체크리스트로 삼아요.

4. 여러 AI의 약점은 “묵시적인 공유 상태”에서 온다

여러 AI가 협동할 때 공유 상태의 표현 수준은 이렇게 줄 세워져요.
묵시적 → 파일만 → 저장소 기반 → 실행 기반 → 칠판.
가장 아래 “묵시적” 상태, 즉 어디에도 안 적고 그냥 짐작하는 상태가 약점의 뿌리예요.
또 협동 구조가 복잡해질수록 공유 바닥이 덜 형식화되는 경향(반비례)이 보여요.
정적 구조와 움직이는 행동을 하나로 합친 공식 바닥이 없다는 게 가장 큰 빈틈(central gap)이에요.

언제 맞는 말일까: 여러 AI가 협동하는 경우에 해당해요. AI 한 명에게는 이 빈틈 진단이 곧바로 적용되진 않아요.
어떻게 쓸까: 묵시적 상태를 또렷하고·돌릴 수 있고·거래처럼 다룰 수 있는 공유 바닥으로 끌어올리는 걸 우선 과제로 삼아요.

어려운 말 쉽게 사전

용어	쉬운 설명
에이전트 하네스(Agent harness)	AI가 그 안에서 생각·행동·세상이해·검사를 다 하는 집. 코드를 “결과물”이 아니라 “사는 곳”으로 보는 생각.
Code as agent harness	코드를 AI의 마지막 답이 아니라, AI 살림의 중심 바닥으로 다시 정의한 이 논문의 핵심 주장.
실행·검사·상태·통제(Executable/Inspectable/Stateful/Governed)	좋은 집의 네 조건: 진짜 돌릴 수 있고 / 들여다볼 수 있고 / 기억하고 / 규칙으로 다스려짐.
AI가 만든 코드(Agent-initiated code artifacts)	AI가 스스로 만든 코드들 — 회귀 테스트, 임시 도구, 작은 전용 언어, 다시 쓸 기술, 중간 상태. 이 논문이 새로 주목한 것.
계획-실행-검증 루프(PEV)	계획(상태 바꾸기 계약) → 실행(샌드박스·단계별 권한) → 검증(결정론적 센서로 계속/고침/사람개입 결정)을 반복하는 조종 루프.
결정론적 센서(Deterministic sensors)	운에 안 맡기고 통과/실패를 딱 잘라주는 검사기(컴파일러·테스트·퍼저·정적분석). PEV의 검증을 받쳐줌.
집 고치는 AI(Agentic Harness Engineering)	AI가 자기 집을 진화시키는 장치: 깊은 기록 → 진화 에이전트 → 통제된 집 고치기(고치는 일도 PEV·사람개입으로 통제).
진화 에이전트(Evolution Agent)	기록을 받아 집을 더 좋게 바꾸는, 한 단계 위의 AI. “퇴보 없는 자기 진화”는 아직 숙제(5장).
공유 코드 중심 바닥(Shared code-centric harness substrate)	여러 AI가 함께 쓰는 코드 중심 바닥. 표현 수준이 묵시적→파일만→저장소→실행→칠판 순.
끝내는 기준(Harness-state convergence)	여러 AI가 “이제 그만”이라고 정하는 6가지: 정확성/보안/성능/점수/합의/그냥.
큰 빈틈(Central gap)	정적 구조와 움직이는 행동을 하나로 합친 공식 바닥이 없는, 여러 AI 협동의 핵심 빈틈.
프로그램 세계(Program world)	AI가 환경을 프로그램으로 그리고 다루는 분야 — 코드 도우미, GUI/OS, 로봇, 과학 발견, 개인 맞춤 5개.
사람 개입(HITL, Human-in-the-loop)	검사 결과에 따라 사람이 끼어들어 승인하거나 고치는 안전장치. 그 안전·책임을 집의 상태로 남기는 게 숙제.

코드를 에이전트의 “집”으로: 아주 쉽게 읽는 버전

코드를 에이전트의 “집”으로: 아주 쉽게 읽는 버전

먼저, 한 줄 결론 — 이 논문이 말하는 “하네스(harness)“란?

이 논문이 왜 쓰였나 (배경)

흐름 한눈에 보기 (이 논문의 척추)

1장. 들어가며 — 코드를 “집”으로 다시 정의하기

저자들이 이 논문에서 새로 한 일 (기여)

2장. 집으로 들어가는 문 — 코드는 생각·행동·세상의 통로

2.1 생각을 위한 코드 (Code for Reasoning)

2.2 행동을 위한 코드 (Code for Acting)

2.3 세상을 위한 코드 (Code for Environment)

여기서 “코드”란 정확히 무엇일까 (범위 정하기)

3장. 집을 튼튼히 유지하는 장치들 — 계획·기억·도구·검사·자기수리

3.1 계획 세우기 (Planning)

3.2 기억과 맥락 다루기 (Memory & Context Engineering)

3.3 도구 쓰기 (Tool Use)

3.4 계획-실행-검증 루프 (Plan-Execute-Verify, PEV)

3.5 집 자체를 고치는 AI (Agentic Harness Engineering, AHE)

3장 정리

4장. 집을 키우기 — 여러 AI가 코드 위에서 함께 일하기

4.1 함께 일하는 세 가지 방법

4.2 코드라서 생기는 “정답 신호”들과 공유 장치

4.3 저자들의 주장: “공유 코드 중심의 집을 짓자”

4.4 여기서 드러나는 공통 패턴들

5장. 새로 떠오르는 분야와 7가지 숙제

5.1 다섯 가지 분야 (프로그램 세계)

5.2 아직 못 푼 7가지 숙제

비슷한 연구들과 비교해 보기

핵심 깨달음 4가지 (한 개념씩)

1. 코드는 AI의 결과물이 아니라 AI가 사는 집이다

2. 진짜 병목은 모델의 똑똑함이 아니라 시스템의 믿음직함이다

3. 계획-실행-검증 루프는 결정론적 센서로 믿음을 만든다

4. 여러 AI의 약점은 “묵시적인 공유 상태”에서 온다

어려운 말 쉽게 사전

태그