exoharness/exo 딥다이브
— 자기 소스코드를 런타임에 고쳐 가며 진화하는 AI 에이전트 하네스

1프로젝트 한 줄 요약

먼저 하네스라는 말부터 풀자. 요즘 "AI 에이전트"라고 부르는 것은 사실 두 덩어리다. 하나는 모델(GPT·Claude 같은 LLM), 다른 하나는 그 모델을 실제로 일하게 만드는 바깥 껍데기다. 껍데기는 프롬프트를 조립하고, 툴 목록을 넘기고, 모델이 "이 함수 불러줘"라고 하면 진짜로 실행해 주고, 결과를 다시 넣어 준다. 이 껍데기를 하네스라고 부른다.

거의 모든 하네스는 사람이 손으로 짜서 고정해 놓는다. 프롬프트, 툴 목록, 컨텍스트 관리 방식이 코드에 박혀 있고, 모델은 그 안에서만 움직인다. 에이전트가 "자기개선"이라고 하는 것도 대개 메모리에 사실을 하나 적어 두거나, 스킬 파일을 하나 추가하는 정도다.

exo의 주장은 이렇다. 모델이 계속 똑똑해진다면, 하네스를 사람이 고정해 두는 것 자체가 병목이 된다. 그러니 에이전트에게 자기 하네스의 소스코드를 통째로 넘겨 주고, 고치고 다시 빌드해서 재시작하게 하자. 실제로 canonical 설정에서 exo의 소스 트리는 에이전트 샌드박스 안 /workspace/exo에 마운트되어 있고, 에이전트는 그걸 shell 툴로 직접 편집한다.

그래서 코드베이스가 두 덩어리로 칼같이 갈라져 있다. 이게 exo를 이해하는 데 필요한 사실상 유일한 개념이다.

공식 문서의 표현이 정확하다 — "히스토리를 저장하는 놈과 프롬프트를 결정하는 놈이 같으면, 에이전트가 프롬프트를 안전하게 다시 쓰게 둘 수 없다. 잘못된 변경 하나가 히스토리까지 날려 버리기 때문이다."(website/docs-src/concepts/exoharness-and-executor.md)

2왜 지금 주목받는가

① 만든 사람이 "AI 평가(eval) 인프라" 쪽 사람이다

LICENSE 파일의 저작권자는 Ankur Goyal이다. LLM 평가·관측 플랫폼 Braintrust의 창업자다. 그 흔적이 의존성에 그대로 남아 있다 — Cargo.toml이 braintrust-sdk-rust, lingua(멀티프로바이더 메시지 포맷), braintrust-llm-router를 git 의존성으로 직접 가져온다.

이게 왜 중요하냐면, exo의 설계가 "에이전트를 만드는 사람"이 아니라 "에이전트를 관찰하고 평가하는 사람"의 관점에서 나왔다는 뜻이기 때문이다. 그래서 아키텍처의 중심에 프롬프트 엔지니어링이 아니라 이벤트 로그와 재현성이 놓여 있다. 실행 트레이싱(execution_tracing.rs)도 처음부터 1급 시민이다.

② "RSI"라는 단어를 진지하게 다시 정의했다

그리고 여기서 exo가 던지는 통찰이 하나 있다. 프로그래밍 언어의 재귀 함수도 런타임 지원이 있어야 성립한다 — 콜 스택과 스코프가 없으면 재귀 함수는 자기 상태를 유지하지 못한다. 마찬가지로 에이전트의 재귀적 자기개선에도 런타임 지원이 필요하고, exo에서 그 역할을 하는 게 지워지지 않는 이벤트 로그다. 콜 스택은 아니지만 "완전한 실행 이력"이다.

③ 실행자(executor)를 통째로 갈아끼울 수 있다

exo 위에서 돌아가는 에이전트는 exo 기본 턴 루프를 쓸 수도 있지만, Codex CLI · Claude Code SDK · Cursor SDK를 실행자로 꽂아 쓸 수도 있다. examples/typescript/codex-harness.ts(1,330줄)는 샌드박스 안에서 codex app-server --listen stdio://를 띄우고 그 알림을 exo 이벤트로 변환한다. claude-code-harness.ts는 아예 Claude Agent SDK의 프로세스 spawn을 가로채서 샌드박스 안 바이너리를 대신 띄운다.

즉 "어떤 코딩 에이전트를 쓰느냐"와 "히스토리·시크릿·샌드박스를 누가 소유하느냐"를 분리했다. 실행자를 바꿔도 에이전트의 정체성과 기억은 그대로다. 이건 지금 시장에서 꽤 드문 포지셔닝이다.

④ 설치가 진짜 한 줄이다

curl -fsSL https://raw.githubusercontent.com/exoharness/exo/main/setup.sh -o setup.sh
bash setup.sh

setup.sh가 git·Docker 유무를 확인하고, 없으면 설치를 제안하고, mise로 Node 22.15.0 / pnpm 10.26.2 / Rust 1.95를 버전 고정해 깔고, 빌드하고, API 키를 물어본 뒤 ./exo.sh 명령을 알려 준다. "Rust 프로젝트라 빌드가 험할 것"이라는 진입장벽을 의도적으로 무너뜨렸다.

⑤ 숫자로 본 현황 — 그리고 그 숫자를 어떻게 읽을 것인가

3기술 스택 전체 지도

왜 Rust와 TypeScript를 섞었는가

이 조합에는 명확한 역할 분담이 있다. Rust는 "절대 안 죽어야 하는 것" — 이벤트 로그, 시크릿 암호화, 샌드박스 프로세스 관리, 어댑터 감독. TypeScript는 "자주 바뀔 것" — 프롬프트 조립, 툴 정의, 어댑터 프로토콜 구현.

그리고 이게 자기수정 설계와 직결된다. 에이전트가 가장 자주 손댈 부분(프롬프트·툴)은 TypeScript라 재컴파일 없이 파일만 고치면 되고, 신뢰층은 Rust라 고치려면 cargo build를 거쳐야 한다. 수정 난이도 자체가 안전장치다.

주요 외부 의존성

4아키텍처 심화 분석 — 신뢰층과 정책층을 가른 한 줄

4-1. 데이터 모델 — 대화는 "메시지 목록"이 아니라 "이벤트 로그"다

보통 챗봇을 만들면 대화를 messages: [{role, content}, ...] 배열로 저장한다. exo는 그러지 않는다. 저장하는 건 이벤트(event)이고, 메시지는 그중 한 종류일 뿐이다.

// crates/exoharness/src/types.rs — EventData는 22종 태그드 enum
pub enum EventData {
    ConversationCreated { .. }, ConversationForked { .. },
    SessionStarted { .. },      SessionEnded { .. },
    TurnStarted { .. },         TurnEnded { .. },
    Messages { messages, usage: Option<Box<UsageRecord>> },
    ToolRequested { .. },       ToolResult { .. },
    ArtifactWritten { .. },     SandboxCreated { .. }, ...
    Custom { event_type, payload }   // 탈출구
}

이 설계의 요점은 Custom이라는 탈출구다. 예를 들어 "컨텍스트 압축(compaction)"을 생각해 보자. 보통은 프레임워크가 압축을 1급 개념으로 넣는다. exo는 넣지 않는다. 대신 정책층이 "내가 만든 요약본은 여기에 있다"는 커스텀 이벤트를 로그에 append하면 끝이다. 신뢰층은 압축이 뭔지 알 필요가 없다.

계층 구조는 Agent → Conversation → Session → Turn 네 단계다.

Rust 코드에서는 이게 4단계 상속 트레잇으로 나타난다. 재미있는 건 TurnHandle을 따로 둔 점이다 — 진행 중인 턴에서 이벤트를 쓰면 세션/턴 ID가 자동으로 태깅돼서, 나중에 "이 이벤트가 어느 턴 소속이었나"를 잃어버리지 않는다.

// 실제 메서드 이름 (TS 쪽에서는 camelCase로 래핑됨)
trait ConversationHandle: SandboxHandle {
    async fn begin_turn(..)   -> Arc<dyn TurnHandle>;   // 핫패스
    async fn get_events(..)   -> GetEventsResult;        // 커서 스캔
    async fn watch_events(..) -> EventStream;            // 스트리밍 구독
    async fn fork(..)         -> Arc<dyn ConversationHandle>;
}
trait TurnHandle: SnapshotHandle {
    async fn add_events(data: Vec<EventData>) -> AddEventsResult;
    async fn finish() -> EventId;
}

4-2. 저장 계층 — 놀랍게도 데이터베이스가 없다

Cargo.toml에 sqlx·sqlite·postgres가 선언돼 있어서 당연히 DB를 쓸 거라 생각하기 쉽다. 그런데 기본 백엔드(BasicExoHarness)를 열어 보면 DB를 전혀 쓰지 않는다. 이벤트 하나가 파일 하나다.

그럼 동시성은 어떻게 처리할까? 두 겹이다.

• 1겹: 프로세스 전역 쓰기 락 — write_lock: AsyncMutex<()> 하나로 모든 쓰기를 직렬화한다.
• 2겹: CAS(compare-and-swap) 헤드 체크 — ConversationRecord.latest_event_id가 대화의 "머리"를 가리키고, 턴이 이벤트를 쓸 때마다 "내가 알던 머리가 아직도 머리인가"를 비교한다. 다르면 "turn is stale and cannot be resumed" 에러.

4-3. 타임 트래블 — 되감기와 분기

"에이전트의 전체 상태 = 이벤트 로그의 버전"이라는 불변식이 성립하기 때문에, 로그의 임의 지점으로 되감기(rewind)하거나 분기(fork)할 수 있다.

4-4. 샌드박스 — 프로바이더 7종과 크로스 클라우드 스냅샷

샌드박스는 에이전트가 명령을 실행하는 격리 환경이다. exo는 공통 트레잇 두 개(ManagedSandboxHandle / ManagedSandboxBackend)로 추상화하고 7종을 구현했다.

4-5. 시크릿 — 이벤트 스키마에 아예 필드가 없다

자기 코드를 고칠 수 있는 에이전트에게 API 키를 어떻게 안 들키나? exo의 답이 인상적이다.

시크릿은 AES-256-GCM으로 암호화해 저장하고, 마스터 키는 macOS Keychain 또는 ~/.config/exo/master.key(권한 0600)에 둔다. 이 위치는 harness 데이터 루트와도, git 저장소와도 별개다. 에이전트가 소스를 아무리 고쳐도 이미 암호화된 시크릿을 풀 키에 닿지 못한다.

그런데 진짜 핵심은 다른 데 있다. 샌드박스에서 프로세스를 띄울 때 시크릿은 환경변수로 주입된다. 그럼 그게 로그에 남지 않을까? 남지 않는다 — 필터링하는 게 아니라, 이벤트 타입에 env 필드 자체가 없다.

// SandboxProcessStarted 이벤트가 기록하는 것
sandbox_id, process_id, name, command, cwd, mode,
stdin, output, lifecycle, status, provider_state
//  ↑ env 필드가 아예 존재하지 않음 ←←← 이게 격리의 실체

4-6. 자기수정의 실제 실행 경로 — guardian

이제 하이라이트다. 에이전트가 자기 코드를 고쳤다. 그 다음은?

실패하면? 전용 롤백 툴은 없다. 원시 도구를 조합한다 — 코드는 git revert, 파일시스템은 rewind_sandbox, 설치한 툴은 uninstall_agent_tool, 어댑터는 disable_adapter. 문서가 권하는 루틴은 "빌드 전 스냅샷 → 빌드 → status/logs 확인 → 그 다음에 커밋"이다. 참고로 저장소 문서는 "클론된 샌드박스에서 카나리 검증하는 기능은 아직 없다"고 스스로 밝히고 있다.

4-7. 턴 루프와 어댑터·스케줄러

실제 한 턴이 도는 모습은 이렇다.

// crates/executor/src/basic.rs — 라운드 반복의 뼈대
for round in 0u32.. {
    if round > max_tool_round_trips { return; }       // 무한루프 방지
    let messages = materialize_prompt_history(..);        // 로그 → 프롬프트
    let response = complete_model_round(..);              // LLM 호출
    let events   = interpret_model_response(response);    // 툴콜 파싱
    turn.add_events(events).await?;                       // 로그에 기록
    let reqs = collect_tool_requests(&events);
    if reqs.is_empty() { return; }                       // 툴콜 없으면 종료
    turn.add_events(execute_tool_round(..)).await?;       // 툴 실행 후 기록
}

TypeScript 하네스는 어떻게 붙는가. Rust가 JS 엔진을 내장한 게 아니라, node --import tsx runner.ts <하네스경로>로 Node 자식 프로세스를 띄우고 stdin/stdout 위 NDJSON RPC로 대화한다. 핵심은 권한 분리다 — TypeScript는 "무엇을 호출할지"만 결정하고, 실제 셸·파일시스템 접근은 Rust 호스트가 수행한다.

어댑터(adapter)는 외부 채팅 채널과의 장기 연결을 담당하는 호스트 프로세스다. ExoChat·IRC·Discord·Slack·WhatsApp·Signal·agent-cli 7종이 있다. 여기서도 프로토콜은 소켓이 아니라 stdin/stdout 위 줄바꿈 구분 JSON이고, 워커는 별도 프로세스 그룹으로 spawn된다(손자 프로세스까지 정리하려고). 재연결은 지수 백오프(5초 → 최대 300초, 60초 이상 안정되면 리셋)로 프로세스를 통째로 재기동하는 방식이다.

스케줄러는 "매 시간 뉴스 헤드라인 가져오기" 같은 반복 작업을 돌린다. 이름과 달리 진짜 cron이 아니다 — @every 5m이나 */N * * * *만 받아 내부적으로 interval_ms(고정 간격)로 정규화한다. 동시성 제어는 파일 락이 아니라 시간 기반 리스(lease, 기본 10분)라, 워커가 죽어도 리스가 만료되면 다른 워커가 자동으로 집어 간다. 작업이 끝나면 결과 요약으로 대화를 "깨워서"(wakeup) 새 턴을 시작시킨다.

4-8. RLM — 셸이 아니라 JS REPL 안에서 "생각하는" 하네스

crates/executor/src/rlm.rs(808줄)는 좀 별종이다. 코드 안 프롬프트에 "You are a subquery model inside a recursive language model"이라고 적혀 있다. 이 하네스에는 셸도 샌드박스도 없다. 대신 대화 전체를 문자열로 평탄화해 순수 Rust JS 엔진(boa)에 넣고, 툴을 딱 3개만 준다 — repl_execute, subquery, subquery_variable.

5디렉토리 구조 해부

6학습 포인트 — 설계 교훈 6가지와 솔직한 한계

가져갈 만한 설계 교훈

솔직한 한계

7하드웨어 / 시스템 요구사항

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

1단계 — 이벤트 소싱(Event Sourcing)

exo의 뼈대는 사실 새로운 발명이 아니라 이벤트 소싱이라는 오래된 패턴이다. "현재 상태를 저장"하는 대신 "상태를 바꾼 사건들을 저장"하고, 현재 상태는 사건을 재생해서 얻는다. 금융 시스템이 오래 써 온 방식이다. Martin Fowler의 Event Sourcing 글과 CQRS 개념을 먼저 보면 exo의 get_events / materialize_prompt_history 짝이 왜 그렇게 생겼는지 바로 이해된다.

2단계 — 신뢰 경계(Trust Boundary)와 능력 기반 보안

"에이전트가 코드를 고칠 수 있는데 시크릿은 못 본다"는 구조는 보안 설계의 고전적 주제다. capability-based security, principle of least privilege, confused deputy problem을 찾아보길 권한다. 특히 guardian의 allowlist 방식이 왜 "임의 셸 실행 + 검증"보다 강한지가 이 개념들로 설명된다.

3단계 — 컨테이너 격리와 스냅샷

docker commit / docker save가 실제로 무엇을 하는지, OverlayFS 레이어가 어떻게 쌓이는지 알면 exo의 스냅샷 크기와 속도 특성이 예측 가능해진다. 더 나아가면 E2B·Daytona 같은 클라우드 개발 샌드박스 서비스들의 CRIU 기반 체크포인트 기술이 있다.

4단계 — 에이전트 하네스 비교

exo 저장소 자체에 docs/coding-agent-harnesses.md가 있다. 그리고 Codex CLI, Claude Code, Cursor의 실제 동작을 exo의 대체 하네스 코드로 역추적해 볼 수 있다 — 각각을 어떻게 붙였는지가 그 도구들의 인터페이스를 드러낸다. 남이 만든 어댑터 코드는 그 대상 시스템의 가장 정직한 문서다.

5단계 — RSI 담론 자체

Rich Sutton의 The Bitter Lesson(exo가 명시적으로 인용한다)을 읽고, 그 다음 "하네스를 사람이 짜는 것도 결국 hand-engineering 아닌가"라는 exo의 주장을 스스로 검증해 보자. 반론도 만만치 않다 — 모델이 자기 하네스를 고칠 만큼 신뢰할 수 있는가, 평가(eval) 없이 개선을 어떻게 측정하는가. 저자가 평가 플랫폼 창업자라는 사실이 여기서 다시 의미를 갖는다.

10핵심 키워드 사전

11참고 링크