AI 코딩 에이전트에 대한 4백만 줄 분량의 연구를 읽다. 그 연구는 내 도구를 설명했다.

서론

나는 AI 코딩 에이전트에게 AI 코딩 에이전트에 관한 논문을 읽게 했다. 이 논문은 내가 입력하고 있던 정확한 도구에 상당 부분을 할애하여 해부했다.

이것은 수수께끼가 아니다. 이 논문은 Paul Barbaste, Tristan Darrigol, Germain Vu, 그리고 Tom Wiltberger가 Wavestone AI Lab에서 2026년 7월에 발표한 소스코드 연구인 Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (arXiv:2609.00006)이다. 이 논문이 해부하는 열한 개의 시스템 중 하나는 내가 매일 사용하는 harness인 Pi이고, 다른 하나는 oh-my-opencode-slim 플러그인을 위한 호스트인 OpenCode이며, 나는 이 플러그인에 한국어 README 수정을 보냈다.

그래서 나는 논문이 초대한 일을 했다. 그 숙제를 확인했다. Pi의 로컬 문서를 열고, Pi가 자신에 대해 주장하는 세 가지 내용을 주요 출처와 비교했다. 두 개는 정확히 일치했다. 나머지 하나는 어느 쪽보다 더 흥미로웠다.

이 연구가 발견한 것, 이 도구들을 사용하든 직접 구축하든 의미하는 바, 그리고 내가 감사자(auditors)를 감사했을 때 무슨 일이 벌어졌는지에 대해 알려주겠다.

연구 과정

이것은 비교(competition)가 아닌 기술적 설명(descriptive study)이다. 저자들은 어떤 것도 벤치마크하거나 순위를 매기지 않는다. 그들은 소스 코드를 읽는다.

• 2026년 7월 버전으로 고정된 열한 개의 harness: Claude Code (Anthropic), Codex CLI (OpenAI), Gemini CLI (Google), Mistral Vibe (Mistral)와 더불어 OpenHands, Aider, Mini-SWE-Agent, Hermes, Pi, OpenCode, 그리고 OpenClaw.
• 열두 번째 시스템인 Omnigent (Databricks)은

이러한 내용에서 13가지의 교차 분석 관찰(cross-cutting observations)을 얻었고, 이는 29개의 반복적인 설계 패턴 목록, 18개의 설계 권장 사항, 그리고 Python으로 작성된 약 90줄 분량의 최소 기능 구현 골격(minimum-viable-harness scaffold)을 포함합니다.

이 내용을 읽는 방식에 영향을 미치는 두 가지 고지 사항이 있습니다. 첫째, 논문에 제시된 대부분의 성능 수치는 해당 시스템 자체 유지보자들이 자가 보고한 것입니다. 둘째, 이 논문은 감사의 글(acknowledgments section)에 명시되었듯이 Claude Code의 상당한 도움을 받아 작성되었으며, 이는 연구 대상 11개 시스템 중 하나이므로 알아둘 가치가 있습니다.

주요 발견 사항 (Key Findings)

이 논문에는 열세 가지 관찰 내용이 담겨 있습니다. 이 중 네 가지는 제가 제 자신의 장치에서 도구들을 바라보는 방식을 변화시켰습니다.

1. 에이전트는 모델에 하네스(harness)가 더해진 것입니다. 하네스가 제품입니다.

The canonical anatomy of a coding-agent harness

논문은 한 줄짜리 방정식으로 시작합니다: 에이전트 = 모델 + 하네스(Agent = Model + Harness). 하네스는 모델을 제외한 모든 것입니다. 루프, 도구들, 컨텍스트 관리, 안전 제어 장치, 오케스트레이션, 확장 표면 등이 포함됩니다.

논문은 Mini-SWE-Agent의 백 줄짜리 연구 기준선부터 Claude Code에 이르기까지 모든 시스템이 동일한 7가지 하위 시스템에 대해 입장을 취해야 한다고 주장합니다:

1. 에이전트 루프 (Agent loop)
2. LLM 통합 (LLM integration)
3. 메모리와 컨텍스트 (Memory and context)
4. 도구 및 액션 시스템 (Tool and action system)
5. 안전 및 권한 (Safety and permissions)
6. 확장성 (Extensibility) (스킬, 훅, 플러그인, MCP)
7. 다중 에이전트 오케스트레이션 (Multi-agent orchestration)

'입장 없음(no position)'조차도 하나의 입장으로 간주됩니다. Pi가 단순히 샌드박스를 누락한 것이 아닙니다. 논문은 그 부재 자체가 명시된 설계 원칙이며, 자체 문서에서 주장되고 있음을 기록합니다. 이것이 전체 코퍼스에 걸친 패턴입니다: 의도적인 거부는 기능만큼이나 신중하게 문서화됩니다.

이것이 바로 동일한 소수의 최첨단 모델을 실행할 때 도구들이 매우 다르게 느껴지는 이유입니다. 모델은 공유됩니다. 실제로 사용자가 만지는 모든 것이 하네스인 것입니다.

2. 쌍둥이의 부재 (The twin absences)

2. 쌍둥이의 부재 (The twin absences)

이것은 제가 예상하지 못했던 발견입니다.

4백만 줄과 11개의 프로덕션 시스템에 걸쳐:

• 일반 목적 에이전트 프레임워크를 가져오는 사례가 없습니다. LangChain도, LangGraph도, AutoGen도, CrewAI도, LlamaIndex도, Pydantic AI도, Semantic Kernel도 아닙니다. Gemini CLI는 Google 자체 프레임워크인 Genkit이나 ADK 어느 것도 사용하지 않습니다.
• 코드 검색을 위해 벡터 임베딩을 사용하는 사례가 없습니다. 대신 ripgrep, tree-sitter, glob, 그리고 AGENTS.md와 같은 자동 발견 Markdown 컨텍스트 파일을 사용합니다.

저자들은 몇 주 동안 반례를 찾았고, 코퍼스를 세 배로 늘린 후 스윕(sweep)을 재실행했으며, 그 결과는 유지되었습니다. 모든 루프는 호스트 언어의 네이티브 프리미티브(asyncio, Tokio, Promises 등)로 직접 구현됩니다. 모든 도구 레지스트리는 커스텀이며, 모든 프롬프트 템플릿은 일반 Markdown 또는 문자열 연결입니다.

자신만의 아이러니를 음미하는 각주가 있습니다. 바로 'harness engineering'이라는 용어가 연구의 런타임 코드에는 전혀 나타나지 않는 프레임워크 공급업체인 LangChain 내부에서 명명되고 정의되었다는 것입니다.

이 발견에 대해 논하기 전에 그 미묘한 차이를 아는 것이 중요합니다. 임베딩은 OpenClaw에서 기본적으로 나타나기는 하지만, 채팅 회상(chat recall)을 위해서일 뿐 소스 트리 읽기에는 사용되지 않습니다. Aider는 llama-index를 선택적 추가 기능으로 설치할 수 있지만, 자체 문서에 대한 RAG(Retrieval-Augmented Generation)를 실행하기 위함이지 에이전트 루프 내부에서 사용하는 것은 아닙니다.

3. 루프의 정교함이 성능을 예측하지 못한다

논문은 이 지점으로 반복해서 돌아옵니다. Mini-SWE-Agent의 선형 루프는 대략 50줄입니다. 자체 보고된 SWE-Bench Verified 점수는 74% 이상입니다.

반면, Codex의 작업 공간(workspace)은 단 한 분기에 거의 두 배로 증가했습니다. 621,000줄에서 약 112만 줄에 달하는 Rust 코드가 89개에서 126개의 크레이트(crates)에 걸쳐 늘어난 것입니다. 그 성장은 루프가 바뀌어서가 아닙니다. 루프 주변의 모든 것, 즉 샌드박싱, 승인 절차, 메모리 파이프라인, 플러그인 마켓플레이스 등 모든 것이 성장한 것입니다.

논문의 결론은 다음과 같습니다: 아키텍처의 복잡성이 에이전트가 얼마나 잘 작동할지 예측하지는 못하지만, 프로덕션 준비 상태(production readiness)는 예측합니다. 여기에는 안전성(safety), 신뢰성(reliability), 확장 표면(extension surfaces), 그리고 점점 더 클라이언트/서버 및 전송 계층(transport layers)이 포함되는데, 이 영역에 가장 큰 규모의 하네스들이 대부분의 질량을 담고 있습니다.

저자들은 이를 스캐폴드(scaffold)로 뒷받침합니다. 목록 3은 선형 루프를 구현하는 약 90줄의 Python 코드, 네 가지 도구(bash, read, write, search_replace), 루트에서 리프로 이동하는 AGENTS.md 디스커버리(discovery), 그리고 임계값 압축을 포함합니다. 이 코드는 의도적으로 샌드박싱(sandboxing), 다중 에이전트 오케스트레이션(multi-agent orchestration), MCP, 스킬즈를 생략했는데, 이는 코퍼스에서 실제 의견 불일치가 존재하기 때문입니다. 그들의 조언은 직설적입니다: 여기서 시작하고, 측정하며, 관찰된 실패 모드(failure modes)가 요구하는 최소한의 것만 추가하라는 것입니다.

4. 표준이 확립되고 모두가 서로를 복사하다

연구 기간 동안 두 가지 포맷 싸움이 일단락되었습니다.

스킬즈(Skills)가 MCP를 이겼습니다. SKILL.md 스킬즈는 11개 시스템 중 9개에서 사용되었고, MCP는 8개에서 사용되었습니다. 논문은 Pi가 MCP를 전면 거부하면서도 스킬즈를 구현함으로써 승부를 결정지었다고 평가합니다. 이후 스킬즈 계층은 레지스트리(registries), 신뢰 등급(trust tiers), 출처 검증(provenance verification), 크로스 벤더 디스커버리(cross-vendor discovery) (OpenCode가 Claude Code의 스킬즈 디렉토리를 읽는 방식), 그리고 코퍼스 최초의 에이전트 작성 스킬즈라는 공급망을 구축했습니다.

ACP가 두 번째 역할을 찾았습니다. Agent Client Protocol은 11개 시스템 중 6개에서 배포되었습니다. 이는 편집기-에이전트 경계(editor-to-agent boundary)를 위해 설계되었지만, 이 연구는 원래의 목적 범위를 벗어난 역할, 즉 _하네스 호스팅(harness hosting)_을 문서화합니다. OpenHands는 자체 인터페이스 뒤에서 Claude Code, Codex, 또는 Gemini CLI를 상호 교체 가능한 백엔드로 실행할 수 있습니다.

그리고 제가 계속 생각하는 것이 바로 90일 차이입니다. 4월 판에서는 시스템들이 독립적인 재발견을 통해 수렴했습니다. 7월까지는 그 수렴 과정이 추적 가능해졌습니다. Codex는 Claude Code의 후크 이벤트 어휘(hook event vocabulary)를 문자 그대로 채택하여 자신의 세션 및 설정을 위한 임포터(importer)를 배포했습니다. OpenHands는 Claude Code의 플러그인 매니페스트 형식(plugin manifest format)을 채택했습니다. 패턴들이 코퍼스 전반에 걸쳐 눈에 띄게 확산되었습니다.

논문이 평가한 내용: 이 분야에서 경쟁 우위의 반감기는 현재 몇 주 단위로 측정 가능합니다.

이것이 당신에게 의미하는 바

코딩 에이전트를 사용하는 경우

이 연구는 여러분이 모델 탓으로 돌렸을 만한 행동들을 설명해 줍니다.

• 긴 세션 후에 모호해지는 에이전트는 압축(compacting)하고 있는 것입니다. Claude Code는 13K 토큰 버퍼 이하에서 압축을 실행하고 파일을 복원합니다. Gemini CLI는 50%에서 압축하며 가장 최근의 30%를 원문 그대로 보존합니다. Pi는 contextWindow − 16,384에서 작동하여 가장 최근의 20,000 토큰을 유지합니다.
• 저장소(repo)를 '기억'하는 대신 계속 읽어들이는 에이전트는 임베딩(embeddings) 기능이 없는 것입니다. 그리고 이것은 누락된 기능이 아니라 의도적인 설계입니다.
• 가장 좋아하는 프레임워크 사용을 거부하는 에이전트는 종속성(dependency)을 놓치고 있는 것이 아닙니다. 이 분야 전체의 흐름을 따르고 있는 것입니다.
• 도구(Tool) 개수가 생각보다 중요합니다. 논문에 따르면, 대략 15개의 도구를 넘어서면 프롬프트가 과부하(prompt bloat)되어 사용이 어려워지고 시스템은 지연된 도구 로딩(deferred tool loading)으로 전환됩니다. Claude Code의 지연 플래그는 초기 프롬프트를 약 40% 줄인다고 보고되었습니다.

에이전트를 구축하는 경우

섹션 16이 핵심입니다: 관찰된 시스템과 명시적인 트레이드오프(trade-off)에 기반한 18가지 권장 사항들이 있습니다. 저에게 인상 깊었던 것들은 다음과 같습니다:

• 선형 루프와 하나의 bash 도구로 시작하세요. 관찰된 실패 모드에 대응할 때만 더 많은 도구를 추가하세요.
• 독립적인 턴 레벨 정책(turn-level policies)이 세 개 이상 있을 때 미들웨어 파이프라인으로 발전시키세요. 그 이전에는 아닙니다.
• 코드 위에 RAG를 구축하지 마세요. 코드는 의미적 유사성(semantic similarity)으로는 재현할 수 없는 결정론적 구조를 가지고 있으며, 매분마다 변화합니다.
• 안전 규칙을 명령형 코드(imperative code)가 아닌 데이터나 정책 파일로 코디파이(codify)하세요. 그리고 YOLO 모드를 출시한다면 그 아래에 안전장치(floor)를 유지하세요.
• 병렬 컨텍스트 격리(parallel context isolation)가 순차적 검색(serial search)보다 명확하게 우수하다고 지적할 수 있을 때까지는 단일 에이전트(single-agent)로 머무르세요.

제가 직접 확인한 내용

Pi의 문서는 제 기기에 있으므로, 논문의 주장을 주요 출처와 비교했습니다.

Claim 1: Pi는 contextWindow − 16,384에서 압축(compacts)하며, 최근 기록 20K를 유지하고, 처음부터 다시 요약하는 대신 요약을 반복적으로 병합합니다. 판정: 정확히 일치합니다. docs/compaction.md에는 reserveTokens 기본값이 16384, keepRecentTokens 기본값이 20k이며,

이 연구의 가장 큰 주장은 코딩 에이전트가 2026년 상반기에 도구(tools)의 역할을 넘어 플랫폼(platforms)이 되었다는 것입니다. 그 증거는 모든 소스에 있습니다: 하네스(harnesses)를 가져와서 임포트 가능한 SDK로 배포하는 것과 프레임워크 공급업체가 하네스를 배포하는 것; 여러 공급업체 간의 세션 임포터(cross-vendor session importers); 마켓플레이스, 레지스트리, 그리고 엔터프라이즈 거버넌스 레이어; 그리고 자체적인 하네스를 상호 교환 가능하게 만드는 메타-하네스(meta-harness)가 존재합니다.

혹은 논문이 관찰 12에서 언급했듯이: "이 분야의 경쟁 단위는 더 이상 에이전트 루프(agent loop)가 아닙니다. 그것은 그 주변을 둘러싼 생태계 표면(ecosystem surface)입니다."

만약 여러분이 이 도구들을 매일 사용한다면, 이것이 주목해야 할 발견입니다. 경쟁의 장소는 더 이상 루프가 아닙니다. 그리고 그 주변 플랫폼이 여러분을 담기 위해 구축되고 있습니다.

행동 유도(Call-to-Action)