소개
AI 코딩 에이전트에게 AI 코딩 에이전트에 관한 논문을 읽어달라고 했습니다. 그런데 논문은 제가 그 요청을 입력하고 있던 도구를 상당한 분량에 걸쳐 분석하고 있었습니다.
말장난이 아닙니다. 논문은 Wavestone AI Lab의 Paul Barbaste, Tristan Darrigol, Germain Vu, Tom Wiltberger가 2026년 7월 소스 코드를 분석한 Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (arXiv:2609.00006)입니다. 분석 대상 11개 시스템 중 하나가 제가 매일 쓰는 하네스 Pi입니다. 또 다른 대상은 제가 한국어 README 수정에 기여한 플러그인 oh-my-opencode-slim의 호스트인 OpenCode입니다.
그래서 논문의 분석이 맞는지 직접 확인해봤습니다. Pi의 로컬 문서를 열고, 논문이 Pi에 관해 제시한 주장 세 가지를 원문 자료와 대조했습니다. 두 가지는 숫자까지 정확히 일치했습니다. 세 번째는 그보다 더 흥미로웠습니다.
논문이 무엇을 발견했는지, 도구를 쓰거나 만드는 사람에게 어떤 의미가 있는지, 그리고 분석자의 주장을 직접 검증하면서 무엇을 알게 됐는지 정리했습니다.
연구 방법
이 논문은 시스템의 구조와 현황을 기술하는 연구이지, 성능 경쟁이 아닙니다. 저자들은 벤치마크를 돌리거나 순위를 매기지 않았습니다. 소스 코드를 읽었습니다.
- 2026년 7월 릴리스로 버전을 고정한 하네스 11개: Claude Code(Anthropic), Codex CLI(OpenAI), Gemini CLI(Google), Mistral Vibe(Mistral), OpenHands, Aider, Mini-SWE-Agent, Hermes, Pi, OpenCode, OpenClaw.
- 열두 번째 시스템인 Omnigent(Databricks)는 ‘메타 하네스’로 분석했습니다. 하나의 API 뒤에서 11개 벤더의 하네스를 구동하는 오케스트레이션 레이어입니다.
- Python, TypeScript, Rust 코드 약 400만 줄을 의존성 명세 파일과 import 문까지 살펴봤습니다.
- 2026년 4월판 연구에 포함된 시스템 중 8개는 대상을 바꾸지 않고 분석 버전만 갱신했습니다. 덕분에 동일한 코드베이스의 90일간 변화를 비교하는 분석도 포함됐습니다.
결과물은 시스템 전반에 걸친 관찰 13개, 반복해서 나타나는 설계 패턴 29개, 설계 권고 18개, 그리고 Python 약 90줄로 작성한 최소 기능 하네스 예제입니다.
논문을 읽기 전에 알아둘 사항이 두 가지 있습니다. 첫째, 성능 수치 대부분은 각 시스템의 유지보수자가 직접 보고한 값입니다. 둘째, 저자들은 감사의 글에서 Claude Code의 도움을 상당 부분 받아 논문을 작성했다고 밝혔습니다. Claude Code가 분석 대상 11개 중 하나라는 점에서 알아둘 만한 정보입니다.
주요 발견
논문에는 13개의 관찰이 나옵니다. 그중 제 컴퓨터에서 쓰는 도구를 바라보는 관점을 바꾼 네 가지를 골랐습니다.
1. 에이전트는 모델과 하네스의 합이다. 제품은 하네스다.
논문은 한 줄짜리 식으로 시작합니다. Agent = Model + Harness. 하네스(harness)는 모델을 제외한 모든 것입니다. 루프, 도구, 컨텍스트 관리, 안전장치, 오케스트레이션, 확장 인터페이스가 여기에 들어갑니다.
이어 100줄짜리 연구용 기준 구현인 Mini-SWE-Agent부터 Claude Code까지, 모든 시스템이 다음 일곱 하위 시스템에 대해 설계 입장을 정해야 한다고 주장합니다.
- 에이전트 루프
- 대규모 언어 모델(LLM) 통합
- 메모리와 컨텍스트
- 도구와 액션 시스템
- 안전과 권한
- 확장성(스킬, 훅, 플러그인, MCP)
- 멀티 에이전트 오케스트레이션
‘구현하지 않는다’도 하나의 입장입니다. Pi에 샌드박스가 없는 것은 단순한 기능 누락이 아닙니다. 논문은 Pi가 이를 명시적인 설계 원칙으로 삼고, 자체 문서에서 그 이유를 설명한다고 기록합니다. 분석 대상 전반에서 이런 패턴이 나타납니다. 의도적으로 넣지 않은 기능도 구현한 기능만큼 꼼꼼하게 문서화합니다.
같은 소수의 최첨단 모델을 쓰는데도 도구마다 느낌이 다른 이유입니다. 모델은 공유하지만, 사용자가 직접 접하는 것은 하네스입니다.
2. 공통으로 없었던 두 가지
예상하지 못한 발견입니다.
코드 400만 줄과 실제 운영에 쓰이는 시스템 11개를 살펴본 결과:
- 범용 에이전트 프레임워크를 import하는 시스템은 없었습니다. LangChain, LangGraph, AutoGen, CrewAI, LlamaIndex, Pydantic AI, Semantic Kernel 모두 없었습니다. Gemini CLI도 Google의 자체 프레임워크인 Genkit과 ADK를 쓰지 않습니다.
- 코드 검색에 벡터 임베딩을 쓰는 시스템도 없었습니다. 대신 ripgrep, tree-sitter, glob, 그리고
AGENTS.md처럼 자동으로 찾아 읽는 Markdown 컨텍스트 파일을 사용합니다.
저자들은 몇 주 동안 반례를 찾았습니다. 분석 대상 코드의 규모를 세 배로 늘린 뒤 다시 검색해도 결과는 같았습니다. 모든 시스템이 각 언어의 기본 기능으로 루프를 직접 구현했습니다. asyncio, Tokio, Promise 같은 것들입니다. 도구 레지스트리도 모두 자체 구현입니다. 프롬프트 템플릿은 일반 Markdown이나 문자열 연결로 작성합니다.
논문의 각주에는 묘한 역설도 나옵니다. _하네스 엔지니어링_이라는 용어를 명명하고 정의한 곳은 LangChain이지만, 정작 연구 대상의 런타임 코드에서는 LangChain 라이브러리를 찾을 수 없었습니다.
다만 이 발견에 반론을 제기하기 전에 적용 범위를 구분해야 합니다. OpenClaw에는 임베딩이 있고 기본으로 활성화돼 있습니다. 하지만 대화 기록을 회상하는 용도이지, 소스 트리를 읽는 용도가 아닙니다. Aider도 선택적 추가 패키지로 llama-index를 설치할 수 있습니다. 이것 역시 자체 문서에 검색 증강 생성(RAG)을 적용하는 용도이며, 에이전트 루프 안에서는 쓰지 않습니다.
3. 루프의 복잡성으로 성능을 예측할 수는 없다
논문은 이 점을 여러 차례 강조합니다. Mini-SWE-Agent의 선형 루프는 약 50줄입니다. 유지보수자가 보고한 SWE-Bench Verified 점수는 74% 이상입니다.
반면 Codex의 워크스페이스는 한 분기 만에 거의 두 배로 커졌습니다. Rust 코드가 62만 1,000줄에서 약 112만 줄로 늘었고, 크레이트는 89개에서 126개로 늘었습니다. 루프가 바뀌어서 커진 것이 아닙니다. 샌드박스, 승인 절차, 메모리 파이프라인, 플러그인 마켓플레이스처럼 루프 주변의 기능이 늘어난 결과입니다.
논문의 결론은 이렇습니다. 아키텍처의 복잡성은 에이전트의 점수를 예측하지 못하지만, 실제 운영에 얼마나 준비돼 있는지는 보여줍니다. 안전성, 신뢰성, 확장 인터페이스가 여기에 해당합니다. 최근에는 클라이언트/서버 구조와 통신 레이어의 비중도 커졌습니다. 대형 하네스의 코드 대부분이 이제 이 영역에 집중돼 있습니다.
저자들은 이를 뒷받침하는 구현 예제도 제시합니다. 코드 예제 3(Listing 3)은 약 90줄의 Python으로 선형 루프, 도구 네 개(bash, read, write, search_replace), 루트부터 하위 디렉터리까지의 AGENTS.md 탐색, 임계값 기반 컨텍스트 압축을 구현합니다. 샌드박스, 멀티 에이전트 오케스트레이션, MCP, 스킬은 의도적으로 뺐습니다. 이 영역에서는 시스템마다 설계 선택이 갈리기 때문입니다. 조언도 명확합니다. 여기서 시작하고, 측정하고, 실제로 관찰한 실패 유형을 해결하는 데 필요한 최소한만 추가하라는 것입니다.
4. 표준 경쟁이 정리되자 서로의 구현을 가져오기 시작했다
연구 기간 동안 두 가지 형식 경쟁의 방향이 정해졌습니다.
스킬의 채택률이 MCP를 앞섰습니다. SKILL.md 기반 스킬은 11개 중 9개 시스템이, 모델 컨텍스트 프로토콜(MCP)은 8개 시스템이 사용합니다. 논문은 Pi가 스킬을 구현하면서 MCP는 명시적으로 거부한 선택이 이 차이를 만들었다고 설명합니다. 이후 스킬 레이어에는 공급망도 생겼습니다. 레지스트리, 신뢰 등급, 출처 검증, 벤더 간 스킬 탐색이 등장했습니다. OpenCode는 Claude Code의 스킬 디렉터리를 읽습니다. 분석 대상에서는 에이전트가 직접 작성한 스킬도 처음으로 나타났습니다.
ACP는 새로운 역할을 얻었습니다. 에이전트 클라이언트 프로토콜(Agent Client Protocol, ACP)은 11개 중 6개 시스템에 탑재돼 있습니다. 원래는 에디터와 에이전트를 연결하려고 설계했지만, 논문은 본래 목적을 넘어선 쓰임을 기록합니다. 바로 _하네스 호스팅_입니다. OpenHands는 자체 인터페이스 뒤에서 Claude Code, Codex, Gemini CLI를 서로 교체 가능한 백엔드로 실행할 수 있습니다.
계속 생각하게 되는 대목은 90일간의 코드 변화입니다. 4월판에서는 각 시스템이 독립적으로 비슷한 설계를 발견하며 수렴했습니다. 7월에는 그 수렴이 어디서 시작됐는지 추적할 수 있었습니다. Codex는 Claude Code의 훅 이벤트 명칭을 그대로 채택했고, Claude Code의 세션과 설정을 가져오는 도구도 제공했습니다. OpenHands는 Claude Code의 플러그인 명세 형식을 채택했습니다. 설계 패턴이 분석 대상 전반으로 퍼지는 과정이 코드에 드러났습니다.
논문의 평가에 따르면, 이 분야에서 경쟁 우위를 만드는 차별점의 반감기는 현재 몇 주 단위로 측정할 수 있습니다.
사용자와 개발자에게 주는 의미
코딩 에이전트를 사용한다면
모델 탓이라고 생각했던 동작 중 일부를 이 연구로 설명할 수 있습니다.
- 긴 세션에서 에이전트의 답변이 모호해지는 것은 컨텍스트 압축 때문일 수 있습니다. Claude Code는 남은 토큰 여유가 13K 아래로 내려가면 압축하고, 이후 파일을 다시 복원합니다. Gemini CLI는 컨텍스트 사용률 50%에서 압축하며 마지막 30%는 원문 그대로 보존합니다. Pi는
contextWindow − 16,384에서 압축을 시작하고 최근 20,000토큰을 유지합니다. - 저장소를 ‘기억’하지 않고 계속 다시 읽는 에이전트는 임베딩을 쓰지 않습니다. 기능이 빠진 것이 아니라 의도적인 선택입니다.
- 즐겨 쓰는 프레임워크를 사용하지 않는 에이전트에 의존성이 누락된 것은 아닙니다. 이 분야 전체가 같은 선택을 하고 있습니다.
- 도구 수는 생각보다 중요합니다. 논문에 따르면 도구가 대략 15개를 넘으면 프롬프트가 지나치게 커져, 시스템들이 도구 로딩을 필요한 시점까지 미루기 시작합니다. Claude Code의 지연 로딩 플래그는 초기 프롬프트를 약 40% 줄인다고 보고됐습니다.
에이전트를 만든다면
핵심은 16절입니다. 설계 권고 18개가 각각 실제 시스템의 사례와 명시적인 트레이드오프에 근거합니다. 특히 기억에 남은 권고는 다음과 같습니다.
- 선형 루프와
bash도구 하나로 시작하세요. 실제 실패 유형을 관찰한 뒤에만 도구를 추가하세요. - 턴마다 적용할 독립적인 정책이 세 개 이상일 때 미들웨어 파이프라인으로 전환하세요. 그전에는 필요하지 않습니다.
- 코드에 RAG를 구축하지 마세요. 코드에는 의미적 유사성으로 대체할 수 없는 명확한 구조가 있고, 분 단위로 바뀝니다.
- 안전 규칙은 절차형 코드가 아니라 데이터나 정책 파일로 정의하세요. YOLO 모드를 제공하더라도 최소한의 안전선은 남겨두세요.
- 병렬로 분리한 컨텍스트가 순차 탐색보다 확실히 유리한 특정 단계를 짚을 수 있을 때까지는 단일 에이전트를 유지하세요.
직접 검증한 내용
제 컴퓨터에 있는 Pi 문서를 열어 논문의 주장과 원문 자료를 대조했습니다.
주장 1: Pi는 contextWindow − 16,384에서 압축하고 최근 20K 토큰을 유지하며, 매번 처음부터 다시 요약하지 않고 기존 요약을 반복적으로 병합한다. 판정: 정확히 일치합니다. docs/compaction.md에는 reserveTokens의 기본값이 16384, keepRecentTokens의 기본값이 20,000으로 나옵니다. 요약 단계에서는 ‘이전 요약을 반복 갱신을 위한 컨텍스트로’ 전달한다고 설명합니다.
주장 2: session_before_compact 훅을 통해 확장 프로그램이 압축을 취소하거나 압축 결과를 대체할 수 있다. 판정: 정확히 일치합니다. 문서에 명시된 이벤트입니다.
주장 3: Pi는 분석 대상 중 유일하게 안전 인프라를 두지 않은 이유를 설계상의 논거로 문서화한다. 판정: Pi 문서도 같은 입장을 더 쉬운 말로 밝힙니다. docs/security.md에는 다음 문장이 있습니다.
“대화 기록을 지켜보고, 프로젝트 신뢰 설정을 사용하고, 변경 사항을 검토하는 것만으로는 보안 경계가 만들어지지 않습니다.”
계속 곱씹게 되는 것은 세 번째 확인입니다. 논문은 제가 매일 쓰는 도구의 설계 철학을 설명했습니다. 저는 그 철학이 이렇게 직접적으로 명시돼 있다는 사실을 몰랐습니다. 원문 문서는 학술적인 완곡 표현도 없이 같은 이야기를 했습니다. 이후 논문의 나머지 부분을 읽는 관점이 달라졌습니다. 저를 대신해 rm -rf를 실행할 수 있는 터미널에서 ‘안전하다’는 것이 무엇을 뜻하는지도 다시 생각하게 됐습니다.
한계
논문은 연구의 한계를 신중하게 밝힙니다. 독자도 이를 염두에 두어야 합니다.
- 시스템의 구조와 현황을 기술하는 연구입니다. 저자들은 벤치마크나 순위를 제시하지 않는다고 명시합니다. ‘발견’을 ‘승자’로 읽으면 안 됩니다.
- 성능 수치 대부분은 유지보수자가 직접 보고한 값이며, 독립적으로 재현한 결과가 아닙니다.
- Claude Code는 공개 저장소가 아니라 유통된 소스 코드 스냅샷을 바탕으로 분석했습니다. 다른 열 개 시스템과는 근거 자료의 성격이 다릅니다.
- 초안 작성에 AI의 도움을 받았고, 그중 하나는 연구 대상 시스템 중 하나와 밀접한 관계가 있습니다.
- 일부 주장은 시간이 지나면 유효성을 잃습니다. 저자들은 몇 주 만에 낡을 수 있는 현황에 관한 주장(도구 수, 기능 비교표의 항목, 고정 버전)과 비교적 오래 유지되는 것으로 확인된 구조에 관한 주장(루프 분류, 하위 시스템 구성, 공통으로 없었던 두 가지)을 구분하고, 각 주장이 어느 쪽에 속하는지 표시합니다.
총평
논문의 가장 큰 주장은 코딩 에이전트가 2026년 상반기에 도구에서 플랫폼으로 바뀌었다는 것입니다. 근거는 모두 소스 코드에 있습니다. 하네스는 import 가능한 SDK로 배포되고, 프레임워크 벤더는 하네스를 출시합니다. 벤더 간 세션 가져오기 도구, 마켓플레이스, 레지스트리, 기업용 거버넌스 레이어가 등장했습니다. 메타 하네스는 자신이 구동하는 하네스들을 서로 교체할 수 있게 만듭니다.
논문의 관찰 12는 이렇게 정리합니다.
“이 분야에서 경쟁의 단위는 더 이상 에이전트 루프가 아니라, 그 주변 생태계가 제공하는 접점이다.”
이 도구들을 매일 쓴다면 곱씹어볼 만한 발견입니다. 경쟁은 더 이상 루프에서 벌어지지 않습니다. 그리고 그 주변의 플랫폼은 사용자가 계속 머물도록 만들어지고 있습니다.
직접 확인해보기
논문을 직접 읽어보세요. Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents의 HTML 버전으로도 전문을 읽을 수 있습니다.
그다음에는 제가 한 것처럼 해보세요. 쓰고 있는 하네스를 골라 문서를 열고, 논문의 주장을 확인해보세요. 차이를 발견한다면 이 글보다 더 좋은 블로그 글감이 될 것입니다.
이런 도구로 에이전트를 만든다면 16절과 코드 예제 3의 90줄짜리 구현부터 시작해보세요.