Exo(엑소): 하네스는 자신의 코드와 로그를 봐야 한다

---

title: "Exo(엑소): 하네스는 자신의 코드와 로그를 봐야 한다" title_original: "Exo: Harnesses should see their own code and logs — Alex Krentsel" url: https://www.youtube.com/watch?v=5lFD-34dhqE video_id: 5lFD-34dhqE date: 2026-08-16 drop_date: 2026-08-15 channel: latentspacepod duration: "47:11" language: ko (English auto-captions cross-checked) processed_at: 2026-08-16 Asia/Seoul

메타데이터

• 원문 제목: Exo: Harnesses should see their own code and logs — Alex Krentsel
• 자연스러운 한국어 제목: Exo(엑소): 하네스는 자신의 코드와 로그를 봐야 한다
• 원본 URL: https://www.youtube.com/watch?v=5lFD-34dhqE
• 채널: latentspacepod
• 영상 ID: 5lFD-34dhqE
• 원본 업로드일: 2026-08-15
• 처리일: 2026-08-16 (Asia/Seoul)
• 영상 길이: 47분 11초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트가 실행 중인 자신의 코드와 로그를 직접 관찰하고, 안전한 격리·스냅샷·롤백 구조 안에서 하네스 자체를 고칠 수 있다면, 모델 가중치만 바꾸던 자기개선보다 더 직접적인 재귀적 자기개선(RSI)이 가능해지는가?==

• Exo는 실행 중에 자신을 구성하는 정책, 도구, 스킬, 컨텍스트 조립 방식, 어댑터와 실행 코드까지 안전하게 수정하는 완전 재귀적 에이전트를 목표로 한다.
• 이 목표를 가능하게 하는 핵심은 에이전트를 상태를 보존하는 Exo Harness, 정책을 실행하는 무상태 Executive, 실제 작업이 일어나는 Sandbox로 분리하는 것이다.
• 하네스가 대화 기록·비용·비밀·스냅샷을 보존하고 실행기를 샌드박스에 마운트하면, 실행기는 자신의 코드를 보고 고친 뒤 재빌드·교체·검증·롤백할 수 있다.
• 자기개선에는 목표를 반영하는 평가자(Evaluator)가 반드시 필요하다. 비용만 낮추라는 목표를 주면 일을 아예 하지 않는 보상 해킹(Reward Hacking)이 가장 싼 해법이 될 수 있기 때문이다.

Exo의 주장은 단순히 “모델에게 자기개선 아이디어를 물어본다”는 뜻이 아니다. 모델이 생성하는 출력 토큰과 에이전트 하네스를 구성하는 코드가 같은 매체에 놓여 있으므로, 에이전트가 실제로 자신의 실행 기반을 편집하고 그 결과를 런타임에서 확인할 수 있다는 주장이다. 보호된 상태와 샌드박스, 실행기 교체를 책임지는 가디언(Guardian) 프로세스가 결합될 때, 자기개선은 사람이나 별도의 외부 봇이 하네스를 고치는 절차에서 실행 중인 시스템이 스스로 관찰하고 수정하는 절차로 이동한다.

1. Exo가 등장한 배경: 가중치에서 하네스로 이동하는 머신러닝 스택

모델의 능력을 키우는 대상이 신경망 가중치만이 아니라 모델을 둘러싼 하네스와 실행 정책으로 넓어지고 있다는 것이 출발점이다.

1.1. Exo의 정의와 Sky Discover에서 시작된 문제의식

1. 완전 재귀적 에이전트(fully recursive agent)

   1. Exo는 작업을 수행하는 동안 자신의 여러 측면을 안전하게 편집해 그 작업에 더 적합해질 수 있는 에이전트다.
   2. 에이전트의 구성 요소를 분리하고 각 부분을 안전하게 격리·진화시키는 최소주의적이면서도 의견이 분명한(opinionated) 하네스 아키텍처가 이 기능을 받친다.
   3. 여기서 “자기개선”은 메모리 파일에 사실을 추가하거나 사람이 스킬을 설치해 주는 정도보다 넓다. 실제 실행 코드, 정책, 컨텍스트 조립, 도구, 스킬, 어댑터를 모두 개선 대상에 포함한다.

2. 가중치 중심에서 에이전트 중심으로의 이동

   1. 기존 흐름은 대규모 사전훈련(large-scale pretraining)으로 모델을 만들고, 특정 작업을 잘하도록 미세조정(fine-tuning)하는 방식이었다.
   2. 최근 에이전트의 확산으로 모델의 “뇌”에 제공되는 하네스, 도구, 몸체(body)가 성능의 중요한 원천이라는 점이 부각됐다.
   3. 하네스를 조정하면 같은 모델도 특정 작업에 더 능숙해지거나 더 적은 토큰 호출과 사용량으로 작업을 수행할 수 있다. 최첨단 모델은 크기가 커지고 서비스하기 어려워지며 더 많은 GPU가 필요해지고 있어 추론 비용 절감은 실제 운영의 핵심 문제가 된다.

3. 외부 최적화 루프를 안쪽으로 접기(collapse the loop)

   1. Alex Krentsel은 UC Berkeley에서 약 1년 동안 AI 기반 발견(AI-driven discovery) 시스템을 연구했고, Berkeley Sky Lab의 Sky Discover라는 프로젝트에서 외부 루프가 내부 시스템을 최적화하는 구조를 다뤘다.
   2. 최적화 대상이 내부 시스템이라면, 최적화하는 방법 자체를 최적화하고 싶어질 때 더 바깥의 루프가 필요하다. 이 구조는 외부 루프, 외부 외부 루프가 계속 생기는 무한 재귀로 이어진다.
   3. 해결책은 외부 관찰자가 실행 중인 시스템을 보고 고치는 대신, 그 루프를 접어서 시스템 자신이 자신의 개선을 책임지도록 하는 것이다. Exo의 논문과 구현은 실행 중 자기변경(runtime self-modification)을 이 방향으로 다룬다.

1.2. OpenClaw와 “가짜 자기개선” 및 “진짜 자기개선”의 구분

1. OpenClaw가 보여준 좁지만 강력한 적응성

   1. 대화에서 OpenClaw는 2월에 크게 확산됐고, 사용자 워크플로에 맞춰 에이전트가 마법처럼 적응하는 경험을 대중화한 사례로 평가된다.
   2. 다만 적응 지점은 특정 범위에 한정된다. 메모리 파일을 편집하거나, 스킬을 추가하거나, 도구를 추가하는 식으로 확장 지점이 미리 정해져 있다.
   3. 메모리의 전형적인 형태는 MEMORY.md 같은 Markdown 파일이다. 파일 내용은 LLM 호출을 구성할 때 컨텍스트에 주입되고, 에이전트는 그 파일을 편집할 수 있다. 사람이 원하는 스킬을 설치하고 에이전트에게 사용하게 하는 것도 분명한 자기개선·확장성의 한 형태지만, 대개 인간이 “이 스킬을 추가하라”고 방향을 정한다.

2. 외부 봇이 내부 봇을 고치는 모델

   1. 진행자는 자신의 두 회사에서 작업을 수행하는 내부 봇과 그 내부 봇을 수정하는 외부 봇 Devon을 분리해 사용한다고 설명한다. 내부 봇은 자기 자신을 수정할 수 없다.
   2. 진행자는 이 분리를 선호한다. 하나는 “무언가를 실제로 하는 것(do things)”이고 다른 하나는 “무언가를 하도록 준비하는 의사 행동(pseudo-do things)”이기 때문이다.
   3. Alex는 이 모델을 자동차에 비유했다. 자동차를 운전한 뒤 필요할 때 보닛을 열어 개조하지만, 대부분의 시간에는 보닛이 닫혀 있다. 내부 봇이 멈춰 있고 외부 봇이 보닛을 여는 방식은 자기변경처럼 보이지만, 실행 중 시스템이 직접 자신을 관찰하고 바꾸는 Exo의 완전 재귀성과는 다르다.

3. 언제 ‘묻지 않았는데 스스로 고쳤다’가 필요한가

   1. 완전 재귀성은 “스스로 바뀌었다”는 AGI 같은 인상을 주지만, 그만큼 시스템에 대한 신뢰를 요구한다.
   2. 외부 에이전트가 내부 에이전트를 수정하도록 해도 사람은 여전히 변화의 실행을 기계에 맡긴다. 따라서 신뢰 문제가 사라지는 것이 아니라 어느 시스템을 신뢰할지 바뀔 뿐이다.
   3. 핵심 선택은 외부 시스템이 내부 시스템을 검사하게 할지, 실행 중인 시스템 자체가 자기 내부와 결과를 검사하게 할지다. 두 레이어를 합치면 변경을 결정하는 시스템이 무엇을 실행하고 무엇을 검사할지도 함께 결정할 수 있다.

1.3. 에이전트와 정책(Policy)의 공통 정의

1. 에이전트는 컨텍스트 구성 기계로 감싼 LM 호출이다

   1. 에이전트는 LM 호출(LM call)을 컨텍스트를 구성하는 기계로 감싼 것이다.
   2. 컨텍스트에는 “내가 할 수 있는 일”인 도구와 행동이 포함되고, LM은 특정 도구나 행동을 실행하라고 요청한다. 에이전트는 실제 행동을 수행하고 그 결과를 다시 컨텍스트에 반영할 책임이 있다.
   3. 이 컨텍스트 구성과 실행을 담당하는 기계 전체를 정책(Policy)이라고 부른다.

2. 정책에 포함되는 선택

   1. 최근 10개 메시지만 가져올지, 최근 100개를 가져올지 선택한다. 100개는 정보를 더 주지만 비용이 늘어난다.
   2. 최근 10개와 이전 90개의 요약을 함께 넣을지 결정한다. 이 선택이 압축(compaction) 방식이다.
   3. 어떤 도구와 스킬을 제공할지, 이를 컨텍스트에 어떻게 넣을지, 프롬프트와 실제 에이전트 코드를 어떻게 구성할지 모두 정책이다. OpenClaw, Pi, Claude Code 등은 이런 결정이 소스 코드에 정적으로 정의돼 있다.
   4. Exo는 미리 정해진 특정 삽입 지점에 스킬을 추가하는 수준을 넘어 정책 자체와 정책을 구성하는 코드까지 재귀적으로 개선하려 한다.

2. OpenClaw 다이어그램에서 Exo 하네스로: 모든 연결을 개선 대상으로 만들기

OpenClaw의 구조가 이미 유용한 확장 지점을 제공하지만, Exo는 인간이 지정한 플러그인 지점 바깥의 연결과 구성 요소까지 에이전트가 다룰 수 있어야 한다고 본다.

2.1. OpenClaw의 게이트웨이 구조와 확장 지점

1. 세 개의 큰 층

   1. 핵심에는 게이트웨이 컨트롤러(gateway controller)가 있다.
   2. 아래쪽에는 실제 컨텍스트 조립(context assembly)이 있고, 위쪽에는 사용자가 상호작용하는 커넥터(connectors)가 있다.
   3. 메모리·도구·스킬 같은 플러그인 지점은 다이어그램에서 빨간색으로 표시할 수 있는, 인간이 설정 가능한 영역이다.

2. 메모리 플러그인과 RAG 사례

   1. 여러 프로젝트 문서를 다루는 개발 작업이라면 모든 문서를 단순히 메모리에 넣는 대신, RAG(Retrieval-Augmented Generation)로 관련 문서를 검색해 컨텍스트에 넣는 편이 더 효율적일 수 있다.
   2. 메모리 플러그인은 메모리를 저장하고 인덱싱하는 방식을 바꾸는 자리다.
   3. ClawHub 같은 사이트에서 도구와 스킬을 골라 설치하는 방식도 확장성을 제공하지만, 여전히 사람이 에이전트에 “이 도구를 설치해 달라”고 요청하는 흐름이다.

3. Exo가 바꾸려는 범위

   1. Exo는 빨간색으로 표시된 플러그인뿐 아니라, 다이어그램의 모든 연결 화살표와 모든 구성 요소를 에이전트가 개선할 수 있어야 한다고 주장한다.
   2. 모델이 더 좋아질수록 인간이 아키텍처의 세부 결정을 계속 고정하는 것은 과도한 전문화로 이어질 수 있다. 더 나은 모델은 주어진 작업에 가장 적합한 에이전트 아키텍처를 스스로 설계할 수 있어야 한다.
   3. Exo의 극단적 버전은 구조 전체에 빨간 선을 긋고 “모든 구성 요소가 에이전트 자신에 의해 변경 가능하다”고 보는 것이다.

2.2. 명시적 전환과 암묵적 전환, 그리고 신뢰

1. 두 가지 자기변경 방식

   1. 암묵적 전환(implicit switch)은 시스템이 스스로 모든 것을 파악하고 자기 구조를 바꾸는, 가장 AGI에 가까운 경험이다.
   2. 명시적 전환(explicit switch)은 기계가 문제를 해결할 수 있을지 확신하지 못하는 사람이 변경을 확인하고 시작하는 방식이다.
   3. 그러나 명시적 전환에서 외부 에이전트에게 변경을 맡겨도 기계가 만든 변경을 신뢰해야 한다는 사실은 변하지 않는다.

2. 자기검사의 표현력

   1. 외부 루프는 설계를 제안하고 실행한 뒤 결과를 다시 받아 피드백해야 한다.
   2. 실행 중인 시스템이 스스로를 검사하면, 무엇을 실행할지 결정하는 시스템이 무엇을 검사할지도 결정한다.
   3. 이 시스템은 자신의 결과와 내부 동작을 함께 보고 런타임 검사를 설계 과정에 반영할 수 있으므로, 외부 시스템에 의존하는 것보다 더 강력하고 표현력이 높은 자기개선이 된다.

2.3. 포켓몬 게임에서의 런타임 자기검사

1. 게임 RAM을 스스로 탐색한 사례

   1. Exo를 포켓몬 게임에 연결해 플레이하던 중, 시스템 자체가 게임의 RAM을 검사하려고 했다.
   2. 과거의 사람이 수동으로 역공학(reverse engineering)해 둔 메모리 맵을 그대로 제공받은 것이 아니라, 실행 중 게임 RAM을 매핑하고 구조를 파악하는 방향으로 움직였다.
   3. 메모리의 특정 위치에는 게임 세계에서의 위치, 현재 활성화된 포켓몬, 전투 중인지 여부가 들어간다. 코드의 불리언(Boolean) 값도 메모리에 그대로 저장된다.

2. 통합을 스스로 개선한 결과

   1. Exo는 이 런타임 정보를 이용해 게임과 자신의 통합 방식을 수정했다.
   2. 매핑한 정보를 시스템 메시지에 넣어 현재 상태를 더 잘 이해하고 다음 의사결정을 개선했다.
   3. 외부 루프라면 사람이 설계안을 만들고 실행하고 결과를 보고 다시 피드백해야 하지만, 자기검사하는 시스템은 검사 결과를 바로 다음 설계와 런타임 변경에 사용할 수 있다.

3. Exo Harness의 3계층: 상태, 정책, 실행 환경을 분리하기

Exo의 안전성은 “자기 코드를 보게 한다”는 허용과 “무엇을 보호해야 하는가”를 분리하는 구조에서 나온다.

3.1. Executor, Exo Harness, Sandbox

1. Exo Harness: 보호되는 상태 계층

   1. 하네스는 에이전트가 사용하는 것 중에서도 보호해야 할 최소한의 상태를 유지한다.
   2. 대화 기록, 필요한 비밀(API 키 등), 아티팩트, 샌드박스 환경 스냅샷이 이 계층에 저장된다.
   3. 하네스는 실행기가 바뀌더라도 기록과 상태를 잃지 않게 하며, 실행기의 자기개선이 안전하게 일어날 수 있는 기반이 된다.

2. Executive: 무상태 정책 실행기

   1. Executive는 컨텍스트 조립, 프롬프트, 압축, 스킬, 도구, LM 호출, 하위 에이전트 생성과 권한 등 실제 에이전트가 무엇을 할지 결정하는 정책을 포함한다.
   2. 실행기 자체는 완전히 무상태(stateless) 프로세스다. 실행 중인 정책의 “방법”은 실행기에 있지만, 대화와 실제 기억 같은 “상태”는 하네스에 있다.
   3. 하위 에이전트를 언제 만들지, 어떤 도구와 권한을 줄지, 어떻게 실행할지는 실행기의 정책 결정이다. 현재의 단순한 Exo가 하위 에이전트를 기본 제공하지 않더라도 같은 패턴을 코드로 구현할 수 있다.

3. Sandbox: 실제 작업 환경

   1. Bash 명령 실행, 파일 수정, 기타 도구 행동은 정책 프로세스와 분리된 샌드박스에서 일어난다.
   2. 현재의 Cloud Code처럼 에이전트가 자신의 실행 환경과 같은 곳에서 파일을 수정하는 방식도 있지만, Exo는 실제 행동이 일어나는 공간을 정책 프로세스와 분리한다.
   3. 이 분리로 격리된 실행 환경, 보호된 상태, 자기진화에 안전한 명시적 무상태 계층이 함께 생긴다.

3.2. 자체 코드를 보고 교체하는 최소 메커니즘

1. 자기 코드의 샌드박스 마운트

   1. Exo가 자기개선 에이전트가 되는 핵심 단계는 실행기 자체의 코드를 샌드박스 안에 마운트하는 것이다.
   2. 그러면 LM의 의사결정 중 하나가 “런타임에 자신의 하네스 일부를 편집하라”가 될 수 있다.
   3. 실행기는 자신의 코드를 보고, 편집하고, 재빌드한 뒤 실행 중간에 새 버전으로 교체할 수 있다.

2. Guardian 프로세스와 자동 롤백

   1. Exo Harness에는 실행기를 런타임에 재구축하도록 허용하는 특수한 보호·가디언 프로세스가 있다.
   2. 재구축 뒤 실행기를 다시 올려 한 단계를 진행해 보고, 잘못된 변경으로 실행기가 중단되면 이전 상태로 자동 롤백한다.
   3. 이 최소 메커니즘이 있어야 자기 코드 교체가 “한 번 망가지면 끝”이 아니라 시험 가능한 원자적 변경이 된다.

3. 변경 대상과 원자성

   1. 새 도구를 만들고, 새 스킬을 쓰고, 컨텍스트 조립 방식을 바꾸고, 어댑터를 조정하는 작업이 모두 같은 메커니즘으로 가능하다.
   2. 제안된 변경은 병렬화할 수 있다. 실행기 변경 커밋과 하네스에서 실행기를 교체하는 과정에 원자성(atomicity)이 있기 때문이다.
   3. 관심사가 분리되어 있으므로 한 변경을 롤백하면서 다른 작업의 상태와 대화 기록은 보존할 수 있다.

3.3. 비밀 저장소와 접근 로그

1. LLM이 비밀을 직접 보지 못하게 하기

   1. API 키가 에이전트와 같은 환경에 있으면 컨테이너 안에서 완전히 읽히거나 유출될 수 있다.
   2. 비밀 저장소(secret store)는 Exo Harness의 호스트 프로세스에 두고, 도구가 파일을 보고 조작하는 샌드박스와 분리해야 한다.
   3. 필요한 비밀은 실행 파일에 주입하되, 도구가 실제 사용 영역에서 그 원문을 읽을 수 있게 노출하지 않는다.

2. 비밀 접근의 감사 가능성

   1. 문제가 생겼을 때 디버깅할 수 있도록 접근 로그(access log)가 필요하다.
   2. 평범한 작업이 갑자기 AWS 키를 요청한다면 키가 실제로 존재하더라도 비정상 패턴일 수 있으므로, 비밀 접근 자체를 모니터링해야 한다.
   3. 대화에서는 접근 로그를 Slack 채널로 흘려보내 사람이 계속 지켜보는 방법이 언급됐지만, 그것은 “지금은 할 수 있는 실용적 방법”일 뿐 바람직한 최종 상태는 아니라는 농담 섞인 지적이 나왔다.

4. 상태를 옮기는 텔레포테이션과 대규모 병렬 실행

4.1. 한 작업을 옮기는 문제와 항상 켜진 서버

1. 단일 에이전트가 단일 작업을 하는 경우에는 로컬에서 계속 실행하거나 처음부터 원격 서버에서 실행하면 되므로 텔레포테이션(teleportation)의 필요가 크지 않다.
2. 노트북을 닫아도 작업이 계속되길 원한다면 애초에 서버에서 실행하고 있어야 한다.
3. 텔레포테이션의 진짜 이점은 하나의 상태를 옮기는 데 그치지 않고, 여러 대화와 작업을 병렬로 깨웠다가 다시 잠재우는 규모화에 있다.

4.2. 100명과 5만 명의 전용 샌드박스

1. 회사가 사용자별 사용 로그를 읽는 전용 에이전트를 띄운다고 가정한다. 사용자가 앱을 쓰면 라이브러리가 이벤트를 데이터베이스에 기록하고, 에이전트는 이벤트 스트림을 보며 실시간으로 추론한다.
2. 각 대화에 전용 샌드박스를 만들면 대화별 상태와 실행 환경을 독립적으로 유지할 수 있다.
3. 사용자 100명이라면 한 장비에서 컨테이너를 최대 100개 정도 동시에 실행할 수 있다.
4. 사용자 5만 명이면 모든 샌드박스를 한 컴퓨터에 두기 어렵다. 정책 실행기는 필요한 몇 개만 깨우면 되지만, 서로 다른 시간에 활성화되는 고객마다 전용 샌드박스가 필요해진다.
5. 이때 일부 샌드박스를 클라우드로 옮기거나 Daytona 같은 제공업체에서 새로 띄울 수 있다. 로컬에 없는 리소스에 접근하기 위해 기존 작업을 Daytona나 다른 제공업체로 이전하는 것도 가능하다.

4.3. Daytona, E2B와 생태계에 대한 농담

1. Alex는 Terminal Bench를 만든 Harbor를 평가하던 중 Daytona가 통합된 것을 본 경험 때문에 Daytona를 예로 들었다. Exo는 Daytona 외에도 E2B와 여러 제공업체 통합을 제공하며, Alex는 작업 일부를 옮길 때 actually.dev도 사용한다고 했다.
2. 진행자는 이 팟캐스트에 Daytona와 E2B가 모두 출연했다며, Harbor 팀의 단 한 번의 추천이 Daytona 성장 대부분을 이끄는 것처럼 보이는 점이 재미있다고 말했다.
3. 곧 Daytona의 영업·GTM 활동도 분명히 있었다고 정정했지만, 좋은 경험을 제공한 제품이 커뮤니티의 선호와 추천으로 보상받는 사례라는 점을 강조했다.

5. 운영 중 자기개선: 비용, 평가, 회귀를 함께 다루기

5.1. Discord에서 16센트의 비용을 발견하다

1. Exo Harness의 대화 로그는 대화 텍스트만 저장하지 않고 각 메시지의 비용(cost)도 기록한다.
2. 실행기는 과거 대화를 읽을 때 어느 부분이 얼마나 비쌌는지 추론할 수 있다. 이 기능은 비용 최적화를 위한 객관적인 관찰 자료를 제공한다.
3. 초기 Exo가 Discord 어댑터를 사용하던 중, Alex가 “마지막 Discord 메시지를 보내는 데 얼마가 들었지?”라고 물었고 약 16센트라는 답을 받았다.
4. Alex는 단일 메시지 비용으로 16센트가 드는 것을 비정상적으로 높다고 판단했고, Exo에게 비용을 낮추도록 요청했다.

5.2. 런타임 재설계와 96% 비용 감소

1. Exo는 실행 중 자신의 Discord 어댑터를 재설계했다.
2. 변경하고, 관찰하고, 테스트하면서 LM 호출에 포함하는 컨텍스트를 특정 대화와 특정 스레드로 한정했다. Discord의 여러 스레드에서 메시지를 무차별적으로 가져오던 방식은 버렸다.
3. 그 결과 비용을 약 96% 감소시켰다. 이는 하네스가 자기 로그와 실행 결과를 보고 코드 자체를 고치는 대표적인 운영 사례다.
4. Exo가 만든 변경은 일회성 런타임 패치로 끝나지 않았다. 나중에 실제 코드에 커밋되어 이후 실행에도 반영됐다.

5.3. 평가자와 보상 해킹 방지

1. 목표 없이 “스스로 발전하라”고 말하는 것만으로는 충분하지 않다. 모든 최적화 문제에는 원하는 목표를 반영하는 평가자(evaluator)가 있어야 한다.
2. 평가자나 최적화 신호가 없으면 시스템은 언덕 오르기(hill climbing)를 할 방향을 찾지 못한다. 신호를 스스로 찾더라도 사람이 원한 목표와 어긋날 수 있다.
3. 비용을 낮추라는 목표만 주면 “아무 일도 하지 않는 것이 가장 싸다”고 결론 낼 수 있다. AI 기반 발견에서 관찰되는 보상 해킹(reward hacking)의 한 형태다.
4. Discord는 성능 검증이 비교적 쉽다. 내 메시지에 답했는지, 맞는 컨텍스트를 넣었는지, 합리적 답변이 가능한 정보를 포함했는지를 확인하면 된다.
5. 보험 에이전트처럼 정답이 단순하지 않은 시스템은 보류 평가 세트(hold-out eval set)를 둘 수 있다. 평가 세트를 에이전트에 직접 제공하거나, 에이전트와 함께 런타임에서 자기 성능을 점검하는 내부 도구를 만들 수 있다.
6. 아직 “원하는 것을 에이전트에게 정확히 지정하는 문제”는 해결되지 않았다. 따라서 자기개선과 동시에 성능을 추적하고, 성능을 어떻게 정의하고 측정할지까지 정하는 도구가 더 필요하다.

6. 상호작용·어댑터·중단 가능한 작업

6.1. 실시간 에이전트와 현재의 파이프라인

1. Exo는 외부 세계와 상호작용하도록 Discord, IRC, WhatsApp 어댑터를 제공하며, 사용자가 직접 어댑터를 추가할 수 있다.
2. Discord 어댑터에는 음성 모드도 넣었다. Exo가 Discord 음성 채팅에 들어가 대화할 수 있지만, 사람이 말하면 즉시 이해하고 끼어드는 완전한 실시간 대화형 모델은 아직 아니다.
3. 현재 방식은 음성 입력·처리·응답이 이어지는 파이프라인 캐스케이드다. 실시간 에이전트에는 이보다 나은 중단(interruption) 모델이 필요하다.

6.2. OpenClaw 스레드의 중단 불가능성

1. OpenClaw의 스레드에서 에이전트가 작업을 시작하면 작업이 끝날 때까지 같은 스레드에 질문을 보내도 응답하지 않는 문제가 있다.
2. 사용자는 그 에이전트가 무슨 일을 하는지 알 수 없고, 답이 오지 않는 이유를 확인하기 위해 별도 대화를 열어 “다른 스레드에서 무슨 일이 일어나고 있나?”라고 물어야 한다. 진행자는 이 상황을 웃음 섞어 지적했다.
3. 모델 계층에서 모든 것을 해결하기보다 에이전트 계층에 운영체제(OS) 같은 작업 모델이 필요하다.
4. 터미널에서 프로세스를 백그라운드로 보내거나 tmux의 별도 pane에서 실행하는 것처럼, 에이전트 작업을 백그라운드에 두고 실행 중 상태를 에이전트에 노출하는 아키텍처가 한 방향이다.
5. 프로세스가 끝나면 시그널(signal)을 보내 에이전트를 깨우거나, pub/sub 버스에 이벤트를 쓰는 방식도 가능하다. 이 문제는 시스템 설계 사고가 필요한 영역이다.

6.3. ACP와 공통 프로토콜의 트레이드오프

1. 진행자는 Zed가 만든 코딩 에이전트 표준화 프로토콜 ACP(Agent Client Protocol)를 구현했는지 물었다.
2. Exo는 아직 ACP를 구현하지 않았다. OpenClaw 안에서 다른 코딩 에이전트를 생성하는 방식으로 ACP를 본 적이 있으며, 다음에 해볼 만한 좋은 아이디어라고 답했다.
3. 여러 코딩 에이전트가 있으면 “모두를 지배하는 하나의 API”를 만들고 싶어지지만, 공통 프로토콜은 언제나 최소공배수(lowest common denominator)가 되기 쉽다.
4. DataBricks 등은 약간 다른 프로토콜을 가질 수 있다. OpenClaw가 여러 에이전트와 상호운용하는 모듈을 모두 만들기보다 Pi를 채택한 것이 더 단순했던 이유도 이 트레이드오프와 연결된다.
5. Exo 팀은 먼저 자기개선을 가능하게 하는 아키텍처와 자기개선 에이전트를 만드는 데 집중했다. 이제 Braintrust에서 Exo Harness와 그 위의 에이전트가 실제 운영 중인 만큼, 다른 사람이 쉽게 통합하도록 만드는 일이 다음 단계다.

7. 팀, 기여 방식, 그리고 운영 경험

7.1. 세 가지 관점이 결합된 프로젝트

1. Ankur Goyal(Ankur/Encore로 들리는 자막 표기): Braintrust에서 사람들이 에이전트를 어떻게 쓰는지와 운영 관점을 알고 있으며, 계층형 아키텍처의 첫 시도를 주도했다.
2. Martin Casado: 컴퓨터과학 박사 출신의 벤처캐피털리스트이자 시스템 사고가다. 다양한 투자 피치와 제품을 보면서 얻은 제품·시장 관점과 깊은 기술적 관점을 함께 제공한다. Scott Shenker에게 박사과정 지도를 받았다는 공통된 학문적 계보도 언급됐다.
3. Alex Krentsel: UC Berkeley의 시스템 연구자다. Sylvia Ratnasamy의 지도를 받고 Scott Shenker·Yan Stoka와 일하며, SDN(Software-Defined Networking) 컨트롤러의 네트워크 아키텍처, 인터넷 경로 결정, 네트워크 형식 검증(formal verification)을 연구해 왔다. 머신러닝에서 내려온 사람이 아니라 시스템에서 에이전트로 올라온 사람이라고 자신을 설명한다.

7.2. AI 엔지니어링에서 시스템과 모델의 긴장

1. 진행자는 Berkeley가 모델 자체보다 모델을 조합하는 시스템, 즉 compound AI systems에 강점이 있고, AI 엔지니어링에는 시스템 전문가와 모델 전문가 모두를 위한 자리가 있다고 말했다.
2. 모델 연구자들은 “다음 큰 모델이 모든 것을 씻어내고 하네스를 없앨 것”이라고 말하는 경우가 있지만, 동시에 Exo 같은 하네스가 구축되고 있다는 긴장이 있다.
3. Alex는 두 주장이 모두 참일 수 있다고 보면서도, 모델에 목표 규칙을 전부 넣는 것과 하네스 아키텍처로 속성을 강제하는 것은 다르다고 강조했다.
4. 예를 들어 기록을 절대 삭제하지 않게 하려면 컨텍스트에서 “기록을 지우지 마라”고 부탁하는 대신, 하네스의 구조가 삭제를 허용하지 않도록 해야 한다. 모델은 프롬프트를 우회하는 방식으로 속을 수 있지만, 아키텍처가 보장하는 속성은 다른 종류의 안전성이다.

7.3. 제작 과정과 초기 커뮤니티

1. Alex가 자율 시스템 설계 원리에 대한 강의를 발표했고 커뮤니티에서 큰 반응을 얻었다. Martin도 Berkeley에서 하네스의 미래에 대해 강연했고, 두 사람이 만난 뒤 Martin이 Braintrust의 Ankur가 같은 문제를 고민하고 있다고 연결했다.
2. 세 사람은 회의실에서 확장성과 안전성을 가진 하네스의 속성을 논의했다. Ankur가 계층형 아키텍처를 처음 시도했고, 처음 3~4주는 Exo Harness를 만들고 견고하게 다지는 데 사용됐다.
3. Alex는 보호된 상태 계층과 별도의 보호된 샌드박스가 있기 때문에 AI 기반 발견 루프를 Executive 안으로 접어 넣을 수 있다는 점에 관심을 갖고 자기개선 연구를 본격적으로 결합했다.
4. Martin이 단순히 “코딩하는 척하는 VC”가 아니라는 점도 실제 커밋으로 확인된다. Martin은 매일 코딩하고, 세 사람 모두 저장소의 커밋에 참여했다.
5. 프로젝트는 아직 매우 초기 단계다. GitHub 저장소와 연결된 Discord에 들어와 토론하거나 기여할 수 있고, Alex는 기여자와 토론 파트너를 계속 환영한다고 말했다. 진행자는 초기 커뮤니티의 가치는 프로젝트뿐 아니라 그 안에서 만난 사람들과 훗날 함께 만들 일에도 있다고 조언했다.

8. 왜 지금 RSI가 가능한가: 같은 매체에서 생성되고 실행되는 코드

8.1. 모델 가중치와 하네스 코드의 결정적 차이

1. 지난 6개월의 변화는 모델 가중치를 반복해서 훈련·조정하던 방식에서 하네스와 에이전트 레이어를 반복해서 조정하는 방식으로 이동한 것이다.
2. 하네스는 수천 줄의 코드로 이뤄져 있고, LLM은 출력 토큰으로 바로 그 코드와 같은 공간의 프로그램을 작성한다.
3. 따라서 에이전트는 자신이 생성하는 매체와 자신이 개선해야 하는 매체가 같다. 실행 중 코드를 쓰고, 그 코드를 실행하고, 결과를 보고 다시 코드를 바꿀 수 있다.

8.2. 왜 거대 모델 가중치를 자기 컨텍스트에 넣을 수 없는가

1. 전통적인 LM 개선은 역전파(backpropagation), 경사하강법(gradient descent), 가중치 델타와 파라미터 수정으로 이뤄진다.
2. 하지만 수조 개 매개변수를 가진 모델의 가중치를 모델 자체의 컨텍스트에 넣어 “어떻게 조정할까?”라고 묻는 것은 확장되지 않는다. 가중치가 컨텍스트에 들어가지 않기 때문이다.
3. LLM에게 훈련 아이디어를 물어보고 사람이 그 아이디어를 실행할 수는 있지만, 그 과정은 모델의 매체와 개선 과정의 매체가 다르다.
4. 하네스 레이어에서는 에이전트가 코드 자체를 생성·작성·실행하고, 실행 중 자기 코드를 바꾼다. Alex가 이 층을 완전한 자기재귀(self-recursive) 단계라고 보는 이유다.

8.3. Autocatalytic 개선, 순수주의, Lisp 비유

1. 진행자는 진정한 완전 자기개선이라면 GPU를 연결하고 자기 모델을 미세조정해야 하는 것 아니냐고 농담했다. “모델이 여기서는 안 좋으니 저기서 파인튜닝하자”는 식의 말에 웃음이 이어졌다.
2. Alex는 컴퓨터를 사용해 다음 컴퓨터를 설계하는 오토촉매적(autocatalytic) 개선은 인정하지만, 그것은 개선을 돕는 시스템과 개선되는 매체가 같은 것은 아니라고 구분했다.
3. Alex는 이 구분에 매우 엄격한 순수주의자이며, 학계 출신인 것이 이런 엄격함의 원인일 수 있다고 농담했다.
4. 대화는 Smalltalk와 프로그래밍 언어 추상화, 시스템·프로그래밍 언어 설계·PLT(Programming Language Theory)의 관계로 이어졌다.
5. 자기 계약(contracts)을 내부에 포함한 프로그래밍 언어와 비슷한 구조라는 비유가 나왔고, 진행자는 Lisp가 떠오른다고 말했다.
6. 두 사람은 생성하는 층과 실행하는 층이 같아지는 반복이 새로운 플라이휠(flywheel)과 도약의 순간을 만들 수 있다고 봤다. 지금 이 시기에 참여하는 것은 같은 매체에서 반복 개선이 일어나는 시작점을 목격하는 행운이라는 감탄으로 이어졌다.

주요 발언 모음

“Exo는 실행 중에 자신의 모든 측면을 안전하게 편집해, 지금 수행하는 작업을 더 잘 처리할 수 있는 완전 재귀적 에이전트다.”

“외부 시스템이 내부 시스템을 최적화하면 최적화 방법을 최적화하기 위해 또 다른 외부 루프가 필요하다. 그 루프를 접어 시스템 자체가 스스로를 개선하도록 해야 한다.”

“에이전트는 컨텍스트를 구성하는 기계로 감싼 LM 호출이며, 그 기계와 실행 방법 전체가 정책이다.”

“기록을 절대 삭제하지 않게 하려면 LLM에게 부탁하는 것이 아니라 하네스 아키텍처에서 그 속성을 강제해야 한다.”

“마지막 Discord 메시지 하나가 16센트라면 미친 비용이다. Exo는 어댑터를 다시 설계해 비용을 약 96% 낮췄다.”

“비용을 절약하는 가장 싼 방법은 아무것도 하지 않는 것일 수 있다. 그래서 성능을 확인하는 평가 도구가 필요하다.”

“하네스는 수천 줄의 코드이고, LLM은 같은 공간에서 코드에 해당하는 출력 토큰을 만든다. 이것이 지금의 결정적 차이다.”

“생성하는 동일한 레이어에서 반복하는 순간이 새로운 플라이휠과 도약을 만들 것이다.”

핵심 데이터 & 수치

• 47분 11초: 영상 길이.
• 2026-08-15: yt-dlp에서 확인한 원본 업로드일.
• 약 1년: Alex가 Berkeley에서 AI 기반 발견 시스템을 연구한 기간.
• 약 2월: OpenClaw가 본격적으로 확산되기 시작한 시점으로 대화에서 언급됨.
• 3~4주: 세 사람이 Exo Harness의 초기 계층형 아키텍처를 만들고 견고하게 다진 기간.
• 약 16센트: 초기 Exo에서 Discord 마지막 메시지 전송에 든 비용.
• 약 96% 감소: 컨텍스트를 특정 대화·스레드로 제한해 Discord 어댑터 비용을 낮춘 폭.
• 약 100개 컨테이너: 한 장비에서 동시에 실행할 수 있다고 설명한 사용자 100명 규모의 전용 샌드박스 예시.
• 5만 명: 모든 사용자별 샌드박스를 한 장비에 유지하기 어려워 클라우드 텔레포테이션이 필요해지는 규모의 예시.
• 수천 줄: 에이전트 하네스 코드의 대략적 규모. LLM 출력 토큰이 바로 이 코드와 같은 매체에서 생성된다.
• 수조 개 매개변수: 가중치 전체를 모델의 컨텍스트에 넣어 자기 자신에게 조정 방법을 묻는 것이 확장되지 않는 이유로 든 모델 규모.

결론 및 시사점

1. 자기개선의 단위를 하네스로 확장하라: 모델 가중치만 평가하지 말고 컨텍스트 조립, 압축, 도구, 스킬, 어댑터, 실행기 정책을 작업별 최적화 대상으로 보라.
2. 정책과 상태를 분리하라: 실행기는 무상태로 유지하고 대화·기억·비밀·아티팩트·스냅샷은 보호된 하네스에 둬야 실행기 교체와 텔레포테이션이 가능하다.
3. 자기 코드 접근은 가디언·샌드박스·롤백과 함께 제공하라: 코드가 자기 코드를 보게 하는 것만으로는 충분하지 않다. 재빌드 후 한 단계를 시험하고 실패하면 이전 상태로 돌아오는 원자적 보호 루프가 필요하다.
4. 비밀은 LLM과 샌드박스에서 격리하라: API 키를 실행 환경에 그대로 두지 말고 호스트의 비밀 저장소에서 필요한 순간에 주입하며 접근 로그와 이상 패턴을 감시하라.
5. 최적화 목표에 평가자를 내장하라: 비용 하나만 낮추면 아무것도 하지 않는 보상 해킹이 발생할 수 있으므로, 기능·품질·안전·비용을 함께 측정하는 평가 세트와 런타임 검증 도구가 필요하다.
6. 에이전트 작업을 OS처럼 관리하라: 백그라운드 실행, 중단, 재개, 시그널, pub/sub를 지원해야 장시간 작업이 사용자를 막거나 스레드를 먹통으로 만들지 않는다.
7. RSI의 실용적 시작점을 같은 매체에서 찾으라: 수조 개 가중치를 직접 조작하는 대신, LLM이 생성하는 코드와 실행되는 하네스 코드가 같은 층에 있는 영역부터 재귀적 자기개선을 검증할 수 있다.
8. 아키텍처의 아이디어를 재사용하라: Exo의 전체 구현을 그대로 채택하지 않더라도, “보호된 상태 + 무상태 정책 실행기 + 격리된 실행 환경 + 평가·롤백”이라는 분해를 적용하면 더 일반적으로 유용한 에이전트를 만들 수 있다.

핵심 요약 (20줄)

Exo는 실행 중 자신의 코드와 정책을 안전하게 수정하는 완전 재귀적 에이전트를 지향한다.

자기개선의 대상은 모델 가중치뿐 아니라 컨텍스트 조립, 도구, 스킬, 어댑터, 실행기까지 포함한다.

외부 최적화 루프를 계속 겹치는 대신 시스템 자체가 자신을 검사하고 개선하도록 루프를 접는다.

OpenClaw의 메모리 파일과 스킬 확장은 강력하지만 인간이 지정한 좁은 확장 지점에 머문다.

Exo는 모든 구성 요소와 연결 화살표를 에이전트가 개선할 수 있어야 한다고 본다.

에이전트는 컨텍스트를 구성하고 도구 행동을 실행하는 기계로 감싼 LM 호출이다.

정책은 프롬프트, 압축, 도구, 스킬, 컨텍스트 범위, 실제 실행기 코드를 결정한다.

Exo Harness는 대화 기록, 기억, 비밀, 아티팩트, 스냅샷을 보호된 상태로 보존한다.

Executive는 정책을 실행하는 무상태 프로세스이며 Sandbox는 실제 명령과 파일 작업이 일어나는 격리 환경이다.

실행기 코드를 샌드박스에 마운트하면 에이전트가 런타임에 자신의 코드를 보고 수정할 수 있다.

Guardian 프로세스는 재빌드된 실행기를 한 단계 시험하고 실패하면 이전 상태로 자동 롤백한다.

비밀 저장소는 호스트 하네스에 두고 샌드박스와 분리해야 API 키가 도구에 그대로 노출되지 않는다.

대화 로그에 메시지별 비용을 기록하면 에이전트가 비용 구조를 관찰하고 최적화할 수 있다.

Discord 마지막 메시지 비용 16센트는 특정 대화와 스레드만 컨텍스트에 넣는 재설계를 촉발했다.

그 재설계는 Discord 어댑터 비용을 약 96% 줄였고 실제 코드에 커밋됐다.

비용만 최적화하면 아무것도 하지 않는 보상 해킹이 생기므로 독립적인 평가자가 필요하다.

전용 샌드박스는 100명 규모에서는 한 장비에 들어가지만 5만 명 규모에서는 클라우드 텔레포테이션이 필요하다.

실시간 에이전트에는 백그라운드 작업, 중단, 시그널, pub/sub 같은 운영체제형 작업 모델이 필요하다.

RSI가 가능해지는 핵심은 LLM이 생성하는 코드와 에이전트가 실행하는 하네스 코드가 같은 매체라는 점이다.

보호된 상태, 무상태 실행기, 격리된 샌드박스, 평가와 롤백을 결합하면 더 일반적으로 유용한 자기개선 에이전트를 만들 수 있다.