재귀적 언어 모델 — Alex Zhang, MIT 박사과정

URL: https://www.youtube.com/watch?v=kog7mwsDqnk
날짜: 2026-10-02
채널: Latent Space
출연: Alex Zhang (MIT 박사과정, Recursive Language Models 연구자, GPU Mode 기여자)

---

📌 핵심 질문 / 현재 모델의 능력을 어디까지 끌어낼 수 있는가

==오늘날의 프런티어 모델은 단일 언어 모델 호출보다 훨씬 많은 능력을 갖고 있으며, 좋은 하네스(harness)가 컨텍스트 오프로딩·코드 실행·재귀적 서브에이전트 호출을 조직하면 그 잠재 능력이 구성적 일반화(compositional generalization)와 장기 신뢰성으로 전환된다.==

• GPU 커널 최적화처럼 검증 가능한 문제에서는 대규모 토큰 탐색보다 문제 구조를 아는 전문가의 한 가지 통찰이 훨씬 적은 비용으로 탐색 공간을 줄일 수 있다.
• Claude Code, Codex, Pi 같은 주류 코딩 하네스는 표면적 차이와 달리 모델을 반복 호출하고 전체 궤적을 프롬프트에 붙이는 비슷한 구조를 공유한다.
• Recursive Language Model(RLM)은 컨텍스트를 메모리에 내려놓고 코드로 읽고 쓰며, 코드 안에서 서브에이전트를 재귀적으로 호출하는 더 급진적인 하네스 추상화다.
• 미래의 “언어 모델”은 사용자가 보는 간단한 인터페이스 뒤에서 수천~수만 개의 에이전트와 공유 메모리를 조율하는 스캐폴드(scaffold)일 수 있다.

핵심 문제는 모델의 파라미터를 더 키우는 것만이 아니다. 모델이 잘하는 코딩·수학·검증 능력을 다른 작업으로 옮기고, 긴 컨텍스트와 장기 실행을 다루며, 여러 에이전트의 탐색을 답으로 수렴시키는 실행 설계를 찾아야 한다. Alex Zhang은 RLM을 하나의 완성된 아키텍처라기보다 이러한 설계 공간을 열어젖히는 간단한 출발점으로 설명한다.

0. 도입부: “더 열심히 시키면 더 많은 능력이 나온다”

0.1. 여러 코딩 에이전트가 사실상 같은 이유

1. 반복해서 좋아하는 에이전트들

   1. Alex Zhang은 Claude Code, Codex, Pi, Prime Agent를 모두 좋아한다고 말하지만, 겉으로는 서로 다른 제품이어도 내부 논리는 대부분 같다고 본다.
   2. 공통 구조는 모델을 호출하고, 도구를 실행하고, 결과를 다음 호출의 컨텍스트에 붙이는 루프다. Prime Agent는 RLM 성격 때문에 조금 더 다르지만, 기존 제품들의 설계 선택은 큰 틀에서 비슷하다.

2. 현재의 병목은 능력보다 사용법일 수 있다

   1. 같은 모델도 더 강한 실행 전략을 붙이면 훨씬 더 많은 일을 해낼 수 있다.
   2. 모델의 “들쭉날쭉한 지능(jagged intelligence)”은 한 영역에서는 매우 뛰어나고 다른 영역에서는 서툴다는 뜻이다. 좋은 하네스는 뛰어난 영역의 능력을 긴 작업, 낯선 도메인, 지속적 실행으로 옮겨야 한다.

0.2. 도입부의 운영 맥락

1. 콘텐츠 운영
   1. Latent Space는 AI 엔지니어링·과학·엔터테인먼트 콘텐츠를 광고 없이 지속하기 위해 구독을 요청한다.
   2. 스폰서 제안이 거의 매일 들어오지만, 구독자 기반을 유지해 광고 없는 운영을 이어가려는 선택을 설명한다.

1. GPU Mode와 KernelBench: 커널 작성의 자동화

GPU Mode의 사례는 AI가 코드를 생성하는 것과 실제 시스템에서 안정적으로 작동하는 최적화 코드를 만드는 일이 다르다는 점을 보여준다.

1.1. CUDA Mode에서 GPU Mode로

1. 커뮤니티의 시작

   1. GPU Mode는 Mark Saroufim이 시작한 Discord 커뮤니티로, 처음에는 CUDA 커널 작성법을 배우는 강의와 토론이 중심이었다. Alex는 대학 시절인 2023년 무렵 합류했다.
   2. Alex는 Snapchat 인턴십 중 Google의 Infinite Attention 논문에 관심을 갖고 특화 커널을 써볼 수 있는지 고민하다가 커뮤니티를 알게 됐다. 당시 인턴십 업무가 지루했던 것도 합류의 계기였다.
   3. CUDA Mode라는 이름은 이후 법적 이유로 GPU Mode로 바뀌었다. Mark, Mate 등 핵심 구성원과의 협업은 커뮤니티 바깥의 다양한 프로젝트로 이어졌다.

2. Popcorn과 경쟁 프로그래밍의 비유

   1. Mark가 제안한 Popcorn은 현재 리더보드로 발전했다. GPU 프로그래밍에는 사람들이 반복해서 최적화하는 커널 종류와 최적화 패턴이 제한적이라는 직관이 출발점이었다.
   2. Codeforces에 수백만 개의 문제가 쌓이는 것처럼 GPU 코드 문제를 충분히 축적하면 커널 개발도 데이터화하고 자동화할 수 있다.
   3. Mamba처럼 논문과 함께 커널을 공개하지 않으면 연구 결과를 실제로 쓰기 어렵다. 모든 연구팀이 GPU 커널 전문가를 보유할 수 없기 때문에 자동화의 실용적 가치가 크다.

1.2. KernelBench와 AI 생성 커널

1. LLM이 커널을 만들 수 있는가

   1. KernelBench는 LLM이 GPU 커널 코드를 자동화할 수 있는지 검증하기 위해 시작됐다. Alex는 대학과 박사과정 사이에 GPU Mode에서 이 작업을 하며 즐거운 시간을 보냈다.
   2. GPU 프로그래밍은 한때 매우 틈새 분야였지만, FlashAttention에 관한 Tri Dao의 Princeton 강연을 듣고 Alex가 매력을 느낀 뒤 AI 커뮤니티 전체의 관심 분야로 커졌다. 지금은 커널 작성이 거의 포화됐다고 느낄 정도로 대중화됐다.
   3. GPU 문제를 대상으로 하는 경쟁 플랫폼과 자동 연구 루프가 늘었고, 커널 배경이 없는 사람도 AI를 이용해 기록을 갱신하고 있다.

2. 정답 검증과 전문가의 역할

   1. 최근 GPU Mode 리더보드의 문제 대부분은 AI가 만든 해법으로 채워졌다. 그러나 오랫동안 커뮤니티에서 활동한 숙련자 Gaurst의 해법은 AI를 사용했어도 전문가가 프롬프트를 조정하고 탐색 방향을 바로잡은 결과였다.
   2. 상위 10개 중 실제 종단 간(end-to-end) 시스템에서 안정적으로 작동한 해법은 사실상 그 전문가의 커널뿐이었다.
   3. GPU 커널에는 검증 문제가 있다. 벤치마크 점수만 올리는 reward hacking이 KernelBench 출시 이후 계속 발생했으며, 짧은 코드가 빠르다는 측정 결과가 실제 시스템의 안정성을 보장하지 않는다.

1.3. 인간 전문지식과 무차별 탐색의 결합

1. 지식이 탐색 비용을 줄인다

   1. 충분한 계산량을 투입하면 에이전트 군집이 해법 공간을 넓게 탐색할 수 있지만, 문제를 잘 아는 사람이 제공한 한 가지 통찰은 수천억~1조 토큰의 무차별 탐색을 통째로 없앨 수 있다.
   2. 현실의 문제를 모두 최대 컴퓨트로 풀 수 없으므로, 효율성과 구조적 지식은 여전히 핵심이다.
   3. 강한 전문가는 정답을 직접 쓰는 사람이라기보다 모델이 낸 후보를 검증하고, 잘못된 방향을 빠르게 제거하며, 다음 탐색을 올바른 방향으로 유도하는 사람이다.

2. 직관과 계획의 구체적 형태

   1. 사람의 능력은 단순한 지식량만이 아니라 문제를 어떻게 분해하고 풀지에 대한 직관, 그리고 모델을 어떤 방식으로 사용해야 하는지에 대한 지식의 결합이다.
   2. Alex는 코드를 항상 다이어그램으로 그린다. 다이어그램의 한 부분을 이해하지 못하면 이해할 때까지 작업을 진행하지 않는다는 개인적 검증 규칙을 예로 들었다.
   3. 모델을 쓰는 전문가도 강한 verifier 역할을 한다. 모델이 후보를 대량 생성하더라도 문제를 아는 사람이 구조를 알아보고, 실제 시스템에서 통할 해법과 벤치마크만 속이는 해법을 구별해야 한다.

1.4. 속도 한계, 메모리, 퓨전

1. 이론적 최저 시간

   1. 행렬 곱셈처럼 단순한 문제는 가능한 최선의 커널 속도를 “speed of light” 추정치로 계산할 수 있다.
   2. 데이터가 CPU에 있는지 GPU DRAM에 있는지, 전송이 어떻게 겹치는지에 따라 수치가 달라진다. 완벽한 데이터 전송 중첩을 가정해도 실제 커널은 이론값에 한참 못 미치는 경우가 많다.
   3. 대화에서 주된 평가 지표는 속도였고, 전력·에너지 효율(마이크로줄·나노줄·피코줄)은 아직 동일한 비중으로 세지 않는다고 설명한다.

2. 단일 커널과 전체 모델의 차이

   1. 단일 커널을 빠르게 만드는 것과 여러 레이어로 된 모델 전체를 빠르게 만드는 것은 다르다.
   2. 첫 연산을 조금 느리게 하더라도 결과를 캐시에 남겨 다음 레이어의 메모리 이동을 줄이는 편이 전체적으로 유리할 수 있다. 이런 선택이 커널 하나만 고립해 측정할 때는 드러나지 않는다.
   3. 메모리 병목에서 여러 연산을 하나로 합치는 fusion 또는 mega-kernel 문제가 생긴다.

3. 메가 커널에 대한 회의적 전망

   1. 매우 어려운 문제를 예시 없이 스스로 부트스트랩해 해결하는 사례는 아직 보지 못했다. 더 좋은 자동화를 위해서는 학습 데이터와 문제 구조가 필요하다.
   2. 개별 커널은 복잡도가 낮고 구성 가능한 조각이어서, 여러 고수준 연산을 합치는 메가 커널은 특화 LLM보다 컴파일러가 더 잘 처리할 가능성이 있다.
   3. 특이한 퓨전이 필요한 영역은 남겠지만, 일반적으로 개별 커널 조각은 서로 조합 가능하고 컴파일러가 전체 구조를 보고 최적화하는 편이 자연스럽다.

2. 연구의 취향과 큰 베팅

학계에서의 강점은 산업 연구소가 이미 중요하다고 판단한 문제를 따라가는 데 있지 않고, 아직 사소하거나 이상해 보이는 질문에 장기적으로 베팅하는 데 있다.

2.1. SWE-bench, RLM, ReAct, Quiet-STaR가 처음에는 사소해 보였던 이유

1. 연구의 첫 반응이 신호가 될 때

   1. Recursive Language Model 논문이 나왔을 때 “그냥 서브에이전트 아닌가?”라는 반응이 많았다. Alex는 사람들이 목적을 바로 이해하지 못했다는 사실이 오히려 좋은 신호라고 본다.
   2. SWE-bench도 처음에는 “불가능한 작업이고 왜 벤치마크로 삼는가”라는 반응을 받았다. Devin이 등장하고 나서야 많은 사람이 점수를 높이기 위해 이 문제를 본격적으로 공략하기 시작했다.
   3. Chain-of-Thought, ReAct, Quiet-STaR도 처음 읽으면 단순하거나 당연해 보인다. 하지만 이런 작업은 새로운 모델 릴리스처럼 즉시 제품화되는 답을 주는 것이 아니라, 연구 분야가 어디로 가야 하는지 보여주는 방향 표지판이다.

2. 학계가 맡을 수 있는 역할

   1. Quiet-STaR, ReAct, RLM, SWE-bench는 GPT-6 같은 대형 릴리스가 아니며, 공개 즉시 모든 사람이 쓰는 제품도 아니다. 학계는 산업 연구소처럼 거대한 실행 자원을 투입해 즉시 최고 성능을 증명하기 어렵다.
   2. 그래서 박사과정 학생은 다른 연구자가 중요하다고 보지 않는 질문, “이미 생각해봤지만 쓸모없다”고 여기는 질문, 처음에는 사소해 보이는 질문을 연구할 자유를 활용해야 한다.
   3. 자원·인재·인프라가 풍부한 산업 연구소와 같은 게임을 하면 학계가 불리하다. 학계의 비교우위는 관료주의 없이 큰 베팅을 하고, 실패를 감수하며, 방향 자체를 바꾸는 데 있다.

2.2. GEV가 여는 출력 공간의 재설계

1. 언어 모델은 자동회귀 텍스트 디코더인가

   1. GEV는 언어 모델의 백본이 언어 정보를 포착한다는 점은 유지하면서 출력 공간을 바꾸는 가능성을 보여준다. 언어 모델이 반드시 text-to-text 자동회귀 디코더일 필요는 없다.
   2. 입력을 받고 다음 토큰을 계속 생성하는 방식만 고집하면, 이진 분류처럼 작은 출력만 필요한 작업에서도 거대한 모델 호출 비용을 내야 한다.
   3. 출력 공간과 추론 지연시간 사이의 트레이드오프를 직접 설계하면, 같은 언어 지식을 더 빠르고 저렴한 형태로 사용할 수 있다.

2. 새로운 모델 설계 공간

   1. GEV에서 중요한 것은 정확한 내부 구현보다 새로운 질문을 가능하게 했다는 점이다. 얼마나 긴 for-loop를 모델 안에서 돌릴 수 있는지, 모델의 일부만 반복 실행할 수 있는지, 여러 부분 모델 사이에 라우터를 둘 수 있는지 물을 수 있다.
   2. 하네스에서 구현하는 루프·라우팅·구성 기능을 모델 아키텍처 안으로 옮길 수 있는지, 하네스 선택과 모델 구조 선택 사이의 경계를 어디에 둘지 연구할 수 있다.
   3. RLM의 병목은 여러 언어 모델 호출이 느리고 비싸다는 점이다. 간단한 일까지 덩치 큰 프런티어 모델에 맡기는 대신, 작업별로 더 작은 모델을 배정하면 RLM과 군집의 지연을 줄일 수 있다.

3. 프런티어 연구소와 다른 전략

   1. 프런티어 연구소와 같은 자동회귀 디코더를 같은 규모의 데이터·컴퓨트로 재현하는 전략은 자원이 작은 팀에게 불리하다.
   2. 소규모 연구소는 데이터와 컴퓨트로 정면 대결하기보다 GEV처럼 전혀 다른 출력·추론 형식을 찾아야 한다. 이미 작동하는 자동회귀 스케일링에 대규모 연구소가 익숙해져 있을수록, 그들은 기존 베팅을 포기하고 새로운 설계에 컴퓨트를 배정하기 어렵다.
   3. 이런 빈틈에서 네오랩과 독립 연구자가 새로운 모델을 만들 수 있다. GEV의 가치가 실제로 몇 배의 비용 절감으로 이어지는지와 별개로, 다른 모델 형식이 가능하다는 사실이 중요하다.

4. 학습·보정(calibration)의 어려움

   1. RLM도 아이디어 자체는 단순해서 누구나 하네스를 만들 수 있다. 진짜 차이는 이를 올바르게 학습시키고, 시스템에 맞는 아키텍처와 최적화 목표를 설계하는 데 있다.
   2. GEV 계열 모델을 오픈 모델로 복제해도 성능이 낮을 수 있다. 내부 학습 방식과 보정이 실제 성능을 만들기 때문이다.
   3. 모델에게 자신감 수치를 묻는다고 정답 확률이 나오지 않는다. 모델은 “얼마나 확신하느냐”라는 질문에도 다음에 가장 그럴듯한 토큰을 생성해 43% 같은 숫자를 내놓을 수 있다. 진짜 calibration은 예측과 실제 정답을 대조해 확률을 보정하는 grounded classification이다.
   4. 정답을 알고 있는 합성 데이터에서 모델이 낸 답을 분류·비교하면 보정 데이터를 만들 수 있지만, 실제 시스템에서는 이 기능이 아직 충분히 활용되지 않는다.

2.3. 비전·게임 에이전트로 보는 지연시간 문제

1. 게임 플레이 벤치마크

   1. Alex는 언어 모델이 새 비디오 게임을 지능적으로 플레이할 수 있는지에 꾸준히 관심을 가졌고, Claude Plays Pokémon 이후 비전 언어 모델을 게임에 연결하는 벤치마크를 만들었다.
   2. 벤치마크는 게임 종류가 다양하며, 단순히 게임을 본 적 있는지보다 지연시간 제약을 포함해 화면·상태를 받아 행동할 수 있는지를 본다.
   3. 예전 수치는 오래됐고 새로운 모델로 실험하는 사람들이 생겼지만, 대부분의 모델이 게임을 의미 있게 끝까지 해결하지는 못한다. Astra가 Kirby 게임을 해결한 사례처럼 일부 게임은 가능성이 보인다.

2. 게임 상태와 최소 하네스

   1. 모델이 시각 입력을 직접 갖지 못하면 게임 상태와 걸을 수 있는 타일 같은 정보를 별도로 공급해야 한다. Claude Plays Pokémon의 RAM 상태 읽기와 walkable tile 추출도 비슷한 접근이다.
   2. Alex의 벤치마크는 의도적으로 최소 하네스를 사용했다. 이 선택은 순수 모델 능력을 비교하기에는 좋지만, 실제 게임을 끝까지 깨는 데는 더 풍부한 상태 표현과 실행 루프가 필요할 수 있다.
   3. 게임은 모델의 언어 이해를 빠른 출력 형식으로 바꾸는 GEV 계열 접근을 시험하기 좋은 환경이다. 모델이 언어를 잘 이해해도 매 순간 큰 자동회귀 호출을 기다리면 실시간 행동이 불가능하기 때문이다.

3. 하네스는 구성적 일반화 장치다

하네스는 단순히 도구 목록이나 편의 기능이 아니라, 모델의 문제 해결 방식을 형성하는 매우 의견이 강한(opinionated) 프로그램이다.

3.1. 왜 한 번의 다음 토큰 예측으로는 부족한가

1. SWE-bench의 예

   1. 코드베이스 전체를 탐색하고, 관련 파일을 찾고, 변경하고, 테스트하고, 실패 원인을 되짚는 작업을 단일 모델 호출에 “이 코드를 해결하라”고 맡길 수는 없다.
   2. 하네스는 파일 읽기·검색·편집·테스트·재호출의 순서를 정하고, 모델이 그 문제에 맞는 형태로 행동하도록 만든다.
   3. 따라서 하네스는 모델에게 도구를 붙인 얇은 래퍼가 아니라 “이 문제를 어떤 실행 프로그램으로 풀 것인가”를 결정하는 설계다.

2. 현재 코딩 하네스의 공통점

   1. Claude Code, Codex, Pi는 이름·UI·도구가 달라도, 기본적으로 모델을 한 번 호출하고 결과를 다시 컨텍스트에 넣는 루프를 반복한다.
   2. 이 하네스들은 코드에 특히 강하도록 설계·학습됐다. 모델이 하네스 사용 데이터를 학습했는지 여부에 따라 open model의 도구 사용 능력이 크게 달라진다.
   3. Grokbot처럼 더 독특한 설계를 가진 예외가 있지만, 현재 주류 하네스 대부분은 전체 rollout 궤적을 프롬프트로 유지하는 “trajectory as a prompt”에 가깝다.

3.2. 하네스 설계가 만드는 일반화

1. 서로 다른 작업의 공통 프로그램

   1. RLM 학습에서 검색(retrieval) 작업과 집계(aggregation) 작업은 도메인과 질문이 전혀 달라도, 큰 전략은 “문제를 나누고 필요한 부분을 읽은 뒤 결과를 모으는 프로그램”으로 같을 수 있다.
   2. 일반 언어 모델 하네스는 두 작업의 전체 궤적을 너무 다르게 표현해 이 공통점을 놓치지만, RLM에서는 서브에이전트가 쉬운 하위 문제를 맡고 상위 모델은 동일한 조직 전략을 학습한다.
   3. 한 작업에서 학습한 전략이 다른 작업으로 즉시 전이되는 구성적 일반화가 나타난다. 길이 변수만 바뀐 더 긴 작업으로도 일반화하고, 수학 문제에서 글쓰기 문제로도 상위 전략이 전이될 수 있다.

2. 8~30배 긴 작업으로의 외삽

   1. 짧은 작업에서 학습한 RLM은 같은 전략을 유지한 채 8~30배 긴 작업을 처리할 수 있다.
   2. 모델이 “긴 텍스트를 외워서” 푸는 것이 아니라, 같은 프로그램을 더 많은 조각에 반복 적용하는 방식으로 문제를 해결한다.
   3. 학습 데이터에 포함된 환경보다 더 넓은 문제 클래스로 일반화하려면, 전체 문제를 한 번에 외우는 하네스보다 각 호출을 로컬하고 익숙한 하위 문제로 분해하는 하네스가 유리하다.

3.3. 로컬 분포 내 작업(locally in-distribution)

1. 전체 작업은 낯설어도 각 호출은 익숙하게

   1. 기존 하네스는 매 턴의 궤적을 계속 프롬프트에 붙이므로, 긴 실행이 이어지면 각 모델 호출이 학습 분포에서 멀어질 수 있다. 대형 연구소는 실제 사용자 궤적을 학습할 수 있지만, 모든 팀이 그럴 수는 없다.
   2. RLM은 계산을 메타 하네스와 서브에이전트 프로그램으로 나눈다. 전체 작업은 학습 분포 밖이어도, 각 서브에이전트 호출은 익숙한 작은 하위 문제로 유지한다.
   3. 각 호출이 in-distribution이면 최종 작업이 out-of-distribution이어도 올바른 답에 도달할 가능성이 커진다.

2. 재귀가 만드는 귀납적 이점

   1. 경쟁 프로그래밍과 GPU 최적화는 표면적으로 다르지만, 후보 해법을 나열하고 서브에이전트에게 유망한 방향을 제안하게 하고, 검증기로 평가하며, 좋은 해법을 진화시키는 절차는 비슷하다.
   2. 두 작업의 상위 하네스는 같은 구조이고 서브에이전트가 처리하는 구체적 내용만 다르다. 서브에이전트가 다루는 하위 문제도 같은 재귀적 형식을 반복할 수 있다.
   3. 이 재귀 논리가 하네스의 일반화 능력을 데이터 양 이상으로 키울 수 있다.

3.4. 새로운 하네스의 연구 공간

1. RLM을 모델 안으로 흡수하기

   1. RLM의 모든 구성 요소가 하네스 바깥에 있어야 하는지, 모델의 forward pass가 RLM처럼 행동하도록 직접 학습할 수 있는지 물을 수 있다.
   2. 코드는 미분 불가능하지만, RLM의 행동을 근사하는 여러 방법은 가능하다. 앞으로는 특정한 컨텍스트 압축 코딩 하네스만 만드는 데 그치지 않고, 모델 내부에 재귀·라우팅·구성을 흡수하는 방법을 찾을 수 있다.
   3. RLM은 특별히 복잡한 설계가 아니라 현재 방식과 다른 간단한 inductive bias다. 그러나 데이터와 환경이 커질수록 기존 하네스보다 더 잘 확장될 가능성이 있다.

2. 하네스 세금과 학습

   1. Harness Tax 논문은 대부분의 하네스 선택이 실제로는 큰 차이를 만들지 않는다는 직관을 뒷받침한다. 많은 하네스가 같은 루프를 사용하기 때문이다.
   2. Anthropic과 OpenAI는 자신들의 하네스에서 주로 학습할 가능성이 높고 경쟁사의 하네스에서는 학습하지 않을 것이다. 그래서 같은 모델도 특정 하네스에서 도구 사용이 더 자연스러울 수 있다.
   3. 모델이 충분히 좋아지면 하네스 간 차이는 줄고 비용 차이가 주된 차이가 될 수 있지만, RLM처럼 훈련 방식 자체가 다른 하네스는 여전히 별도의 학습을 요구한다.

3. 의미 있는 실험의 필요성

   1. 새로운 하네스를 만든 뒤 단순 데모를 보여주는 것만으로는 부족하다. 서로 다른 하네스 설계에 대해 post-training scaling을 체계적으로 실험하는 팀이 필요하다.
   2. Fable은 동적 워크플로를 어느 정도 학습해 RLM 하네스에서 초기부터 상대적으로 잘 작동했고, 이후 Astra도 충분히 좋아졌다. 내부 비교에서는 모델이 RLM 작업에 최적화되지 않았다는 사실이 여전히 뚜렷하다.
   3. 올바르게 학습된 모델과 하네스가 결합하면 현재의 반복 호출보다 훨씬 효율적인 추론이 가능하다.

4. RLM의 정의와 Prime Agent

4.1. RLM의 간결한 정의

1. 코드가 유일한 도구인 하네스

   1. RLM은 하네스에서 사용할 수 있는 유일한 직접 도구가 코드인 설계다.
   2. 모델은 코드 안에서 자신을 호출하는 programmatic subagent calling을 수행할 수 있다. 파일 시스템·Python REPL·Bash REPL 같은 실행 환경에 컨텍스트와 결과를 저장한다.
   3. 코드로 읽고 쓰는 메모리 안에 전체 컨텍스트를 두기 때문에, 모든 정보를 매 턴 프롬프트로 다시 통째로 보내지 않아도 된다.

2. 컨텍스트 오프로딩과 공유 메모리

   1. 기존 하네스는 긴 궤적을 프롬프트에 유지하고, 필요할 때 compaction으로 줄인다. RLM은 더 근본적으로 컨텍스트를 외부 메모리로 내려놓고 필요한 부분만 코드로 읽는다.
   2. Prime Agent의 실행 궤적과 압축 전후 컨텍스트는 디스크에 저장되며, 모델은 압축 이후에도 원래 맥락을 참조할 수 있다.
   3. 여러 서브에이전트가 같은 파일·메시지 보드·공유 상태를 읽고 쓰므로, 긴 작업의 중심 맥락을 유지하면서 각 호출을 작게 만들 수 있다.

4.2. RLM이 해결하려는 문제

1. 긴 컨텍스트와 순차 도구 호출의 한계

   1. 기존 하네스는 코드베이스처럼 학습 데이터에 많이 등장한 영역의 긴 컨텍스트는 다룰 수 있지만, 일반적인 장문 문서와 복합 문제에서는 쉽게 흔들린다.
   2. 일반적인 도구 호출은 A를 호출한 다음 B, 그 다음 C를 호출해야 한다. 모델이 매 턴 도구를 선택하므로 중앙 메모리에서 여러 작업을 자유롭게 구성하기 어렵다.
   3. RLM은 하나의 중앙 컨텍스트를 두고, 코드로 도구와 서브에이전트를 조합한다. 모델이 코드를 잘 쓰기 때문에 이 조합 언어를 자연스럽게 습득할 수 있다.

2. 에이전트 군집과의 공통점

   1. Hugging Face의 에이전트 군집 사례처럼 서브에이전트가 메시지 보드에 기록하며 소통하는 시스템은 공유 컨텍스트를 활용한다.
   2. RLM은 그 소통을 자연어 메시지보다 코드로 표현한다. 코드에는 검색, 반복, 조건, 검증, 추가 호출을 한 프로그램으로 묶는 조합성이 있기 때문이다.
   3. 충분히 발전하면 모델이 문제별 하네스 자체를 생성할 수 있다. 사용자는 질문만 주고, 하네스는 문제에 맞는 서브에이전트 구조와 검증 루프를 즉석에서 만들게 된다.

3. 논리적 종착점

   1. 논리적으로 가장 강한 RLM은 하네스만 쓰는 시스템이 아니라, 하네스를 생성하고 그 하네스에 맞는 모델을 학습하며 데이터 수집까지 자동화하는 AI 연구자다.
   2. MIT의 학술 연구만으로는 대규모 RLM 학습에 필요한 컴퓨트를 감당하기 어렵지만, Prime과 Select 같은 회사가 이 방향을 탐색하고 있다.
   3. 모델이 똑똑한 하네스에서 학습하면 post-training scaling wall의 형태가 달라질 수 있고, 더 좋은 하네스가 나올 때마다 학습 효율도 달라질 수 있다.

4.3. Prime Agent의 구조

1. Pi 위에 만든 RLM 하네스

   1. Prime Agent는 Pi/Pi Mono 계열의 미니멀 하네스 위에 RLM 추상화를 얹는다. Alex는 다른 하네스도 기본 논리로 내려가면 Pi와 크게 다르지 않다고 본다.
   2. Prime Agent에서는 모델이 직접 사용할 수 있는 도구를 IPython 하나로 제한한다. 나머지 기능은 Python 모듈이나 Bash 스크립트로 로드해 코드 안에서 실행한다.
   3. 이 제한은 기능을 줄이는 것이 아니라, 모델이 도구마다 별도 인터페이스를 순차적으로 호출하는 대신 하나의 코드 환경에서 실행 계획을 구성하게 만든다.

2. Continual Harness

   1. Seth와 게임 에이전트 연구자들이 만든 Continual Harness는 하네스가 자기 일부를 수정할 수 있게 하는 설계 원칙이다.
   2. 모델은 자신이 사용할 스킬, 호출 가능한 서브에이전트, 시스템 프롬프트 같은 요소를 수정할 수 있다.
   3. Continual Harness는 Prime Agent 내부에서 IPython 도구로 제공되어, 실행 중인 시스템이 문제에 맞게 자신의 실행 조건을 바꾸는 길을 연다.

3. 에이전트 간 통신과 지속성

   1. RLM은 많은 서브에이전트를 만들기 때문에 루트 에이전트와 서브에이전트, 서브에이전트 서로가 누구에게 무엇을 말할 수 있는지에 대한 통신 설계가 중요하다.
   2. Prime Agent의 통신은 코드로 표현된다. 각 에이전트가 접근할 수 있는 상태와 메시지 경로를 제어하면서, 필요한 경우 여러 에이전트가 같은 메모리를 조작한다.
   3. Persistent subagent는 원래 에이전트의 표준 런타임이 끝난 뒤에도 살아 있다. 나중에 다시 들어가 더 프롬프트를 주고, 내부 상태를 확인하고, 장기 작업을 이어갈 수 있다.
   4. 파일 시스템에 상태를 외부화하는 것이 핵심이다. Codex의 일회성 서브에이전트처럼 수명이 짧은 프로세스도 파일을 통해 지속성을 얻을 수 있다.

4.4. 실제 적용 사례

1. Harvey의 법률 AI

   1. Harvey는 법률 업무에 RLM을 post-train해, 여러 문서를 훑고 특정 정보를 찾는 작업에 적용했다.
   2. 순수 retrieval 시스템으로는 찾기 어려운 문서 간 맥락을 RLM이 서브에이전트와 코드로 탐색하며, 매우 좋은 결과를 냈다.
   3. Alex에게 사전 통보하지 않은 독립적인 제3자 적용이라 특히 인상적이었고, Base10과의 협력 가능성도 언급된다.

2. Headlong과 지속적 사고

   1. Headlong은 Luddites Institute의 지속 실행 하네스로, 과거 다른 이름으로 불렸던 프로젝트를 확장한 것이다.
   2. RLM을 쓰지만 단순한 RLM보다 더 발전한 점은 사용자가 질의하지 않는 동안에도 컨텍스트의 문제를 계속 생각한다는 것이다.
   3. 항상 켜져 있지만 토큰 비용을 통제해 크레딧을 모두 태우지 않는 “저비용 지속 사고”를 목표로 한다.

3. ARC-AGI 3와 신경기호적 조합

   1. ARC-AGI 3 공식 Kaggle 대회에 참여한 여러 하네스가 RLM 또는 그에서 영감을 받은 Tufa류 추상화를 사용했다고 밝혔다.
   2. ARC 문제는 코드로 여러 후보를 만들고, 규칙·검증기·검색을 조합하는 신경기호(neurosymbolic) 시스템에 적합하다.
   3. 이런 사례는 RLM을 장문 문서 처리 전용으로 한정하지 않고, 모델과 프로그램·검색·규칙 시스템을 결합하는 일반 하네스로 볼 수 있음을 보여준다.

5. 에이전트 군집, OpenAI의 10,000 에이전트 실험, 그리고 미래의 인터페이스

5.1. 거대한 계산을 문제에 투입하는 방식

1. OpenAI의 공개된 규모

   1. OpenAI의 ARC-AGI 3 및 Navier–Stokes 관련 성과에는 약 10,000개 에이전트를 88시간 동안 실행한 실험이 있었던 것으로 언급된다.
   2. 최종 출력 토큰은 약 1,300억 개이며, 공개 가격으로 환산하면 약 4,000만 달러 규모다. 에이전트 간 메시지까지 포함하면 실제 총량은 이보다 두 배 이상일 수 있다.
   3. 이 실험의 핵심은 단일 모델이 즉시 증명을 만든 것이 아니라, 많은 탐색이 모은 정보와 연구자의 직관을 특정 에이전트가 최종 증명으로 정제했다는 데 있다.

2. 하네스보다 정보 도달 경로가 중요하다

   1. 올바른 정보가 특정 에이전트에 도달하면, GPT-6 Astra급 모델은 매우 어려운 문제의 증명을 만들 수 있는 지능을 갖고 있을 수 있다.
   2. 더 큰 질문은 모델이 정보에 어떻게 도달하게 하는가다. 수많은 서브에이전트 탐색, 공유 파일 시스템, 연구자의 방향 제시가 이 정보 생성 과정에 기여한다.
   3. OpenAI가 RLM이라는 이름을 사용했는지와 상관없이 공유 컨텍스트를 가진 에이전트 군집은 RLM의 정신과 닮아 있다. 다만 구체적인 군집 설계와 탐색 규칙은 RLM 자체보다 더 복잡할 수 있다.

5.2. 사용자에게는 단순한 인터페이스, 내부에는 거대한 군집

1. 제품 표면과 내부 실행의 분리

   1. 사용자는 Claude Code나 Codex 같은 스트리밍 인터페이스에서 작업 진행을 보고 싶어 하지만, 실제 답을 만드는 내부 과정은 수많은 에이전트의 복잡한 군집이어도 된다.
   2. 군집의 모든 메시지와 실패를 사용자에게 노출하면 정보가 읽기 어렵다. 좋은 제품은 사람이 이해할 수 있는 프런트엔드를 유지하면서 내부의 스캐폴드를 숨긴다.
   3. 미래에 사용자가 “언어 모델을 호출한다”고 느끼는 대상은 사실상 에이전트 swarm·scaffold·특화 하네스일 가능성이 높다.

2. Cursor식 조직도와 gather 병목

   1. Cursor가 공개한 다중 에이전트 구조는 일반적인 소프트웨어 팀의 조직도처럼 보인다. 각 에이전트에게 역할을 분배하고, 한 조정자가 결과를 모은다.
   2. gather all 단계는 GPU 프로그래밍과 비슷한 병목이다. 한 조정자가 모든 서브에이전트 결과를 기다린 뒤 다시 조정해야 하므로 느리고, 전체 시스템의 병렬성이 약해진다.
   3. 이상적인 swarm은 구성원이 모두 독립적으로 움직이며, 중앙 조정자 하나에 결과를 몰아넣지 않는다. 하지만 완전히 분산된 구조는 답으로 수렴하기 더 어려워진다.

5.3. 탐색 낭비와 수렴 문제

1. 대부분의 군집은 쓸모없는 탐색일 수 있다

   1. Compaction이 가능한 문제에 RLM을 쓰면 더 강력해도 비싸고 느린 것처럼, 많은 군집도 95%의 탐색이 무의미한 토큰 소모일 수 있다.
   2. 검색 문제에서 여러 에이전트를 병렬로 보내면 대부분의 결과가 쓸모없고, 실제로 필요한 답은 하나일 수 있다. 다만 어떤 결과가 중요한지 미리 모르므로 낭비를 감수한다.
   3. 따라서 모든 문제를 swarm으로 처리하는 API는 바람직하지 않다. 비용과 속도, 문제의 탐색 난이도에 따라 compaction·단일 에이전트·RLM·군집을 선택해야 한다.

2. 군집 수렴은 당연하지 않다

   1. 서로 경쟁하는 에이전트(competitive agents)를 만드는 것과 에이전트들이 협업하여 하나의 해법으로 수렴하는 것(collaborative agents)은 다른 문제다.
   2. Kimi의 에이전트 군집처럼 스프레드시트 등의 작업을 수행하는 데모는 흥미롭지만, 새로운 문제를 해결하는 능력과 군집이 목표를 향해 수렴하는 능력은 별도로 검증해야 한다.
   3. OpenAI가 4,000만 달러를 투입해 미해결 문제를 풀 수 있었던 것은 모델이 똑똑해서 자동으로 군집이 작동한 결과가 아니다. 군집이 목표를 향하도록 학습·설계하고, 정보를 모으고, 최종 결론으로 정제하는 과정이 필요하다.

6. 오픈엔디드니스와 Sakana AI

6.1. 목표가 없는 탐색의 의미

1. 미해결 수학 문제와의 유사성

   1. 오픈엔디드니스(open-endedness)는 명확한 프롬프트 없이 에이전트가 계속 탐색하며 새 문제나 아이디어를 발견하는 범주다.
   2. 진화적 탐색은 에이전트 군집을 여러 개 띄워 흥미로운 해법이 나오기를 기다리는 방식과 비슷하다. AlphaEvolve 같은 작업이 목표 함수를 두고 후보를 진화시킨 사례다.
   3. 목표가 분명한 미해결 문제는 반복 평가가 가능하지만, 목표 자체가 없다면 무엇을 좋은 결과로 볼지부터 정해야 한다.

2. 탐색보다 선택이 더 어렵다

   1. 생성 모델을 매우 높은 처리량으로 오래 실행하면 거대한 아이디어 코퍼스와 “슬롭(slop)”이 쌓인다.
   2. 진짜 어려운 일은 생성량이 아니라 그 안에서 숨은 보석(hidden gem)을 골라내는 것이다. 목표가 없으면 평가 함수와 선택 기준도 자동으로 주어지지 않는다.
   3. Sakana에서의 경험은 결국 어느 방향으로 탐색할지 모델을 계속 nudging해야 한다는 점을 보여줬다. OpenAI가 Navier–Stokes에서 했던 것처럼, 흥미로운 결과가 나올 가능성이 높은 방향을 사람이 정해줘야 한다.

6.2. 기초 과학과 응용 과학의 구분

1. 기초 연구의 개방성

   1. 기초 과학은 당장 응용이 없더라도 이해를 넓히기 위해 연구한다. 무엇을 알아야 할지조차 불분명한 상태에서 목표를 발견하는 과정이 가치가 있다.
   2. 응용 과학은 손실을 줄이거나 특정 목표를 달성하기 위해 명시적인 목적 함수를 둔다.
   3. GEV처럼 아무도 탐색하지 않던 목적 함수를 발견하는 일은 박사과정 연구의 큰 베팅과 닮았다. 처음에는 사소해 보여도 분야의 선택지를 바꿀 수 있다.

2. Sakana의 연구 정체성

   1. Sakana AI는 OpenAI·Anthropic처럼 모두가 쓰는 대형 경쟁 모델을 중심으로 움직이기보다, 박사 연구실처럼 이상하고 연구적인 아이디어를 시도하는 조직으로 평가된다.
   2. GDM에서 갈라져 나온 팀의 영향과 David Ha의 연구 감각, 일본 AI 시장의 문화적·사업적 차이가 이런 방향을 뒷받침한다.
   3. 일본어·일본 문화에 맞춘 모델은 벤치마크 최고점보다 사회적 맥락에 맞는 응답을 목표로 한다. 교육처럼 누군가 중요하다고 생각하는 문제를 충분한 자원으로 자유롭게 연구하는 태도도 Sakana의 박사과정 연구실 같은 성격을 보여준다.

3. 자동 데이터 과학 연구

   1. Ultra는 사람의 개입을 거의 두지 않고 자동화된 데이터 과학 연구를 수행하도록 모델을 풀어놓는 작업으로 언급된다.
   2. 이는 목적 함수가 있는 auto research와 완전히 목표를 정하지 않는 open-endedness 사이에 여러 단계가 있음을 보여준다.
   3. “그냥 무엇이든 해라”는 완전 개방형 방식은 가능하지만, 최종적으로 가치 있는 결과를 고르는 메커니즘이 해결되지 않으면 생성량만 늘어난다.

7. Kimi, OpenAI, Gemini와 군집 설계의 현실

7.1. Kimi와 OpenAI 접근법의 차이

1. OpenAI의 방식은 공짜가 아니다

   1. Alex는 OpenAI가 에이전트 군집을 작동시킨 방식이 현재로서는 올바른 방향이라고 평가한다.
   2. 프런티어 모델이 충분히 똑똑하다고 해서 군집이 저절로 잘 작동하지 않는다. Hugging Face 사례를 포함해 군집처럼 행동하도록 별도 학습한 시스템과 정교한 하네스가 필요하다.
   3. 10,000 에이전트와 1,300억 출력 토큰을 활용한 성과는 군집 설계의 어려움을 보여준다.

2. Kimi Agent Swarm의 검증 과제

   1. Kimi의 군집 데모는 스프레드시트처럼 정해진 작업을 수행하는 데는 흥미롭지만, 새로운 문제를 해결하는 능력이 검증됐는지는 불분명하다.
   2. OpenAI와 Kimi의 차이는 단순한 에이전트 수가 아니라 수렴을 유도하는 학습과 실행 설계의 깊이다.
   3. 군집 효율의 목적 함수는 “얼마나 많은 에이전트를 띄웠는가”가 아니라, 낭비된 탐색을 제외하고 얼마나 적은 비용으로 최종 답을 얻는가여야 한다.

7.2. Gemini의 장점과 Google의 실행 문제

1. 과거 Gemini 실험의 의미

   1. Gemini가 모델 자체가 지금보다 약했던 시기에 하네스를 영리하게 설계해 긴 시간 추론과 경쟁 수학을 수행한 점은 인상적이다.
   2. AlphaGeometry 등과 함께 특정 문제의 구조를 끝까지 이용하는 좋은 하네스 사례를 만들었다.
   3. 그러나 성과가 과장된 면도 있고, Alex는 GDM의 관료주의와 제품 채택 문제를 비판적으로 본다.

2. 제품화와 조직의 간극

   1. Google은 재능과 자원이 많지만, 현장에서 사람들이 실제로 쓰는 제품을 만드는 데 어려움을 겪는 시기가 있었다.
   2. Anti-gravity 같은 도구는 한 번 시도해도 바꿔 쓸 이유를 느끼기 어렵다는 평가가 나온다.
   3. Meta가 오랫동안 비슷한 비판을 받다가 반전한 사례처럼, Google도 조직 문제를 해결하면 역량을 발휘할 수 있다.

8. Speculative Programmatic Tool Calling과 장기 신뢰성

8.1. 도구 호출을 생성과 겹치기

1. 간단하지만 중요한 아이디어

   1. 모델이 코드를 쓰는 동안 어떤 도구 호출이 필요한지 정적으로 분석할 수 있다면, 코드 실행이 끝난 뒤 순차적으로 호출하지 않고 미리 실행할 수 있다.
   2. 도구 결과를 기다리는 시간을 생성 시간과 겹치면 RLM·CodeAct·programmatic agent calling의 지연을 줄일 수 있다.
   3. 프로그램 언어론과 정적 분석 연구가 이 아이디어를 더 정교하게 만들 수 있다. JavaScript·Python은 동적 특성 때문에 어렵고, 타입 시스템이나 함수형 언어가 더 적합할 수 있다.

2. RLM과의 연결

   1. RLM이 코드로 여러 서브에이전트와 도구를 호출한다면, 호출 의존성을 분석해 독립 작업을 병렬로 실행할 수 있다.
   2. 이는 단순히 더 많은 에이전트를 추가하는 방식이 아니라, 같은 작업을 더 빠르고 싼 실행 그래프로 바꾸는 최적화다.
   3. 특히 검색·검증·후보 생성처럼 서로 독립적인 단계는 사전 실행의 효과가 크다.

8.2. 능력 과잉(capability overhang)과 한 달짜리 작업

1. 현 모델의 숨은 생산성

   1. 프런티어 모델을 더 이상 발전시키지 않는다고 가정해도, 현재 모델의 능력을 실제 업무로 옮기지 못해 남아 있는 영향이 많다.
   2. 모델은 코딩·수학에 불균형적으로 강하다. 이 능력을 하네스로 다른 문제 영역에 번역하면, 특수 작업을 별도로 학습하지 않고도 더 넓은 문제를 풀 수 있다.
   3. 사람은 IMO 금메달리스트처럼 한 영역의 능력을 다른 문제 해결로 전이할 수 있지만, 모델이 같은 전이를 하는지는 아직 실험할 문제다.

2. GPU 최적화에서 보는 전이 질문

   1. GPU 프로그래밍 데이터를 모두 제거한 Astra급 모델을 상상해도, 모델이 문맥에서 필요한 개념을 학습하고 커널을 최적화하는 절차를 스스로 만들 수 있는지 물을 수 있다.
   2. 지식과 추론 능력이 같은 인간이라면 할 수 있는 일이, 모델에서는 하네스가 없어서 막힐 수 있다.
   3. 좋은 하네스는 모델 내부 능력과 실제 작업의 간극을 메워 인간이 현장에서 수행하는 지속적 탐색·검증·기억·보고를 근사한다.

3. 단순하지만 장기적인 업무 자동화

   1. 모델이 사람처럼 대화하는 인턴이라고 생각하고 작은 연구·정리·탐색 과제를 맡기면, 현재 모델만으로도 많은 쉬운 부분을 자동화할 수 있다.
   2. 예를 들어 논문 검색, 반복적인 데이터 과학 실험, Slackbot 기반 조사에는 매번 새 특화 에이전트를 만들기보다 공통 하네스에 목표만 주입하는 방법이 가능하다.
   3. 핵심 미해결 과제는 한 달 동안 단순한 일을 꾸준히, 정확하게, 스스로 검증하며 수행하는 시스템이다. Alex는 현재 프런티어 모델도 이 수준의 장기 신뢰성은 못 갖췄지만, 이는 특수한 대형 연구소가 없어도 하네스로 풀 수 있는 “기술 문제”라고 본다.

4. 지속 학습과 장기 실행

   1. 한 달짜리 업무는 단순한 반복 파이프라인과 다르다. 시스템이 이전 결과를 기억하고, 잘못된 방향을 중단하고, 새 정보를 반영해 계획을 수정해야 한다.
   2. 지속적 하네스와 persistent subagent는 이 기능을 구현하는 기반이다. 파일 시스템·공유 메모리·계속 실행되는 작업자가 모델의 단기 컨텍스트를 넘어선다.
   3. 이 방향은 continual learning과 닮았지만, 모델 가중치를 매번 업데이트하지 않고도 외부 기억과 실행 정책을 통해 지속성을 근사한다.

9. Neuralese: 사고에 적합한 출력 언어

9.1. 영어·코드·이진 출력의 제약

1. 모델이 학습한 언어가 능력을 제한한다

   1. 모델의 능력은 훈련 데이터와 출력 표현의 영향을 받는다. 모델이 영어·Python·JavaScript로만 생각하고 표현하도록 만들면, 그 언어의 구조와 역사에 맞춰 추론 방식도 편향된다.
   2. 이진 출력이 더 원시적이라는 주장도 있지만, 세계를 모델링하고 의미를 전달하려면 표현 언어가 필요하다. Alex는 영어와 Python이 섞인 형식이 현실적인 후보일 수 있다고 본다.
   3. 모델이 다른 언어로 전환해 추론할 수는 있지만, 한 언어를 주된 chain-of-thought 형식으로 쓰면 그 언어가 제공하는 개념·순서·구문에 영향을 받는다.

2. 인간 언어의 예시

   1. 영어는 약 500년의 현대적 역사를 가진다. 영어만 선택하면 그 언어가 이미 굳힌 표현과 사고 범위에 모델을 묶을 수 있다.
   2. 중국어에는 영어식 시제가 없고, 한국어는 대화 상대의 사회적 지위를 문장에 반영한다. 어떤 언어에는 명사의 성별 대신 채소 성별처럼 낯선 문법 범주가 있을 수도 있다.
   3. 눈을 뜻하는 단어가 없는 언어가 특정 환경을 다르게 묘사하는 것처럼, 언어의 어휘와 문법은 세계를 분절하는 방식을 바꾼다.

9.2. 자동회귀와 확산형 사고

1. 순차 생성의 한계

   1. 독일어는 동사가 문장 끝에 나와 전체 의미를 끝까지 기다려야 하는 식으로 언어의 순서가 사고의 진행을 제한할 수 있다.
   2. 코드처럼 인과성이 중요한 작업도 있지만, 모든 표현이 순차적이어야 하는 것은 아니다. 함수형 프로그래밍과 관계형 표현은 관계를 먼저 쓰고 나중에 실행자가 코드를 만들도록 추상화할 수 있다.
   3. 모델의 생각을 매번 한 토큰씩 출력하면, 내부적으로 동시에 다룰 수 있는 관계와 구조를 순차 토큰으로 압축해야 한다.

2. Arrival과 Neuralese 비유

   1. 영화 Arrival의 헵타포드는 시간을 선형 순서가 아니라 전체로 보고, 문장을 한 번에 내놓는 것처럼 사고한다.
   2. 이는 자동회귀(autoregressive)와 확산(diffusion)의 차이와 닮았다. 자동회귀는 순서대로 말하고, 확산은 전체 표현이 나타난 뒤 시간이 지나며 부분이 해소된다.
   3. 기계는 사람이 말할 수 없는 새로운 표현을 사용할 수 있다. “Neuralese”는 영어와 코드가 아니라 모델이 관계·불확실성·계획을 한꺼번에 표현하는 기계용 언어일 수 있다.

9.3. 언어와 추론의 경계

1. 인과성과 병렬성의 긴장
   1. 어떤 추론은 분명히 “먼저 한 일이 다음 일을 가능하게 하는” 인과 구조를 갖는다. 코드는 대체로 이런 순서를 따른다.
   2. 그러나 순수 함수형·관계형 언어는 결과를 만드는 실행 순서와 문제의 의미 구조를 분리한다. 모델이 관계를 먼저 표현하고 실행자가 순서를 결정하게 하면 병렬성이 커질 수 있다.
   3. 어떤 표현이 기계 추론에 가장 좋은지, 사람이 읽을 수 있는 언어와 모델 내부 언어 사이에 어떤 중간 형식을 둘지는 아직 열린 연구 문제다.

10. 앞으로의 연구 선택과 AI for Science

10.1. GPU에서 하네스로 이동한 이유

1. 시스템 능력은 수단이다

   1. GPU 커널을 잘 쓰거나 커널 작성을 자동화하는 일은 더 넓은 아이디어를 탐색하기 위한 수단이다.
   2. 시스템 병목을 제거하면 모델·하네스·에이전트의 새로운 설계를 컴퓨트 문제에 가로막히지 않고 시험할 수 있다.
   3. Alex는 여전히 모델 수준의 문제에도 관심이 있지만, 하네스·에이전트 연구에서 아직 혁신할 여지가 가장 크다고 본다.

2. 검증 가능한 연구와 불편함

   1. GPU 최적화는 속도와 안정성으로 검증할 수 있지만, 하네스의 구성적 일반화나 장기 신뢰성은 실험 설계가 훨씬 어렵다.
   2. 현재 컴퓨트로는 많은 하네스 발견을 충분히 검증하기 어렵지만, 그렇다고 기존 하네스를 반복하는 것이 최선은 아니다.
   3. 더 단순하고 명확한 하네스가 나오고, 좋은 아이디어가 장기 실험으로 이어져야 연구 분야가 진전된다.

10.2. 협업과 연구 취향

1. 강한 의견을 가진 협업자

   1. Alex는 특정 협업 요청만 찾는 것은 아니며, 아이디어와 충분한 컴퓨트가 있는 회사나 자신의 주장을 논리적으로 설명하는 사람과 협업할 수 있다고 말한다.
   2. “RLM이 좋아서 함께 일하고 싶다”거나 “당신의 뇌를 빌려 달라”는 식의 모호한 연락보다, 논문을 읽고 강한 의견과 근거를 제시하는 연락을 선호한다.
   3. 동의하지 않더라도 문제에 대한 확신과 논리를 가진 사람은 대화를 시작할 가치가 있다. 잘 만든 새로운 아이디어가 공개되면 프런티어 연구소의 연구자들도 그것을 바로 알아본다.

2. 아이디어를 고르고 몰입하는 방식

   1. Alex는 동시에 10~15개의 아이디어를 떠올리며, 대부분이 나쁜 아이디어라는 사실을 받아들인다.
   2. 달리거나 테니스를 치는 중 문제를 생각하다가 진짜 가능성이 있다고 확신하면 몇 주 동안 다른 일을 내려놓고 그 문제에 몰입한다.
   3. 실험을 돌릴 수 있는 단계에 도달하면 다시 비교적 쉽게 진행된다. 박사과정의 장점은 이런 방식으로 문제를 발견하고 몰입할 시간을 갖는 데 있다.
   4. 사람의 관심은 희소하다. 에이전트가 프로젝트를 더 많이 벌려놓을 뿐, 결과를 확인하지 않고 잊어버리게 만들 수도 있으므로 에이전트가 연구자의 주의력 문제를 자동으로 해결하지는 않는다.

10.3. AI for Science의 시간축

1. 과학 문제를 선택하는 기준

   1. Alex는 박사과정 이전에 AI for Biology를 연구했으며, 자연과학의 문제 중 자신의 설계 원칙이 실제로 통할 것 같다는 신호가 보이면 관심을 갖는다.
   2. 응용 과학은 피드백 루프가 매우 길다. 실험 결과를 얻기까지 오래 걸리고, 6개월 뒤 새 모델이 나와 같은 문제를 훨씬 잘 풀 수 있다.
   3. 따라서 연구자는 지금 자신의 시간을 어디에 베팅할지, 분야가 어느 방향으로 움직일지를 의식적으로 판단해야 한다.

2. 지식 노동의 포화와 과학의 다음 프런티어

   1. ARC-AGI 3 같은 벤치마크가 1년 안에 포화되는 속도는 특정 지식 작업과 게임의 저비용 영역이 빠르게 소진되고 있음을 보여준다.
   2. 지식 노동 자동화가 높은 수준에 도달하면 다음 저수확 과일은 자연과학·생명과학·물리학·수학의 실험 가능한 문제일 수 있다.
   3. MIT처럼 자연과학자와 공학자가 가까이 있는 환경에서는 AI 연구자가 과학 문제에 직접 도전할 수 있다. 단, 해당 분야의 깊은 지식과 긴 검증 시간을 존중해야 한다.

3. 수학자와 AI의 긴장

   1. IMO와 수학 연구에서 모델이 빠르게 성과를 내자 일부 수학자는 AI를 거부하거나 사용을 경계한다.
   2. Alex는 과거 OpenAI와 협업했다는 이유로 비판을 무효화하는 것은 ad hominem이라고 본다. 사람은 의견이 바뀔 수 있고, 동의하지 않는 사람과 협업할 수도 있다.
   3. AI가 결과를 내기 시작했다는 사실 자체는 존중해야 한다. 과학자는 AI를 어디까지 사용할지 합리적으로 논쟁할 수 있지만, 실제 진전이 발생했다는 사실을 외면할 수는 없다.

주요 발언 모음

“모델은 더 열심히 시키면 훨씬 더 많은 능력을 발휘한다. 이건 능력보다 기술(skill)의 문제다.”

“한 문제를 아는 사람이 가져오는 통찰 하나가 1조 토큰의 탐색을 없앨 수도 있다.”

“하네스는 언어 모델을 특정 문제에 맞게 빚어내는, 매우 의견이 강한 프로그램이다.”

“RLM은 하네스에서 유일한 도구가 코드인 설계이며, 코드 안에서 자신을 호출하고 메모리를 다룬다.”

“미래에 우리가 언어 모델이라고 부르는 것은 실제로는 사용자가 보지 못하는 에이전트 군집이나 스캐폴드일 수 있다.”

“군집의 95%가 완전히 쓸모없는 탐색일 수 있어도, 답으로 수렴시키는 방법은 여전히 어렵다.”

“프런티어 모델을 한 달 동안 단순한 일을 꾸준히, 안정적으로 수행하게 만드는 것은 어리석어 보이지만 풀 수 있는 문제다.”

“학계에 있는 가장 큰 이점은 아무도 신경 쓰지 않는 문제에 큰 베팅할 수 있다는 것이다.”

핵심 데이터 & 수치

• 2023년 무렵: Alex가 대학 시절 CUDA Mode에 합류한 시기다.
• 8~30배: 짧은 작업에서 학습한 RLM 전략이 일반화될 수 있다고 설명한 긴 작업의 길이 범위다.
• 10,000개 에이전트: OpenAI가 공개한 대규모 문제 해결 실험에서 언급된 에이전트 수다.
• 88시간: 해당 에이전트 군집을 실행한 시간이다.
• 1300억 출력 토큰: 실험에서 공개적으로 추정된 최종 출력 토큰 규모다.
• 약 4,000만 달러: 1300억 출력 토큰을 공개 API 가격으로 환산한 비용이다. 에이전트 간 메시지까지 합치면 더 커질 수 있다.
• 약 95%: 일반적인 대규모 군집 탐색에서 쓸모없는 탐색일 가능성을 Alex가 제시한 경험적 추정이다.
• 10~15개: Alex가 한 번에 떠올리는 연구 아이디어의 대략적인 수이며, 대부분은 나쁜 아이디어라고 말한다.
• 6개월: 과학 연구에서 새 모델이 나와 기존 프로젝트의 가치와 방향을 바꿀 수 있는 시간 예시다.

결론 및 시사점

1. 모델보다 실행 시스템을 연구하라: 자동회귀 모델 하나의 호출만을 기본 단위로 보지 말고, 코드·메모리·검증기·서브에이전트·지속성을 조합하는 하네스 설계 자체를 연구 대상으로 삼아야 한다.
2. 구조적 통찰을 계산량과 결합하라: 군집은 넓게 탐색하고 전문가는 탐색 공간을 줄인다. 대규모 토큰 소모가 전문가 지식을 대체한다고 가정하면 비용과 품질 모두에서 손해를 볼 수 있다.
3. RLM의 핵심은 컨텍스트 오프로딩이다: 긴 전체 궤적을 매번 프롬프트로 유지하는 대신, 코드가 메모리를 읽고 쓰며 서브에이전트를 호출하게 하면 각 호출을 로컬 분포 안에 둘 수 있다.
4. 하네스의 구성적 일반화를 검증하라: 서로 다른 도메인에서 같은 상위 프로그램이 전이되는지, 짧은 작업 전략이 8~30배 긴 작업과 새로운 작업에 적용되는지 측정해야 한다.
5. 군집은 필요할 때만 사용하라: compaction이 충분한 작업에 RLM을 적용하면 느리고 비싸다. 문제의 탐색 난이도·비용·답의 수렴성에 따라 단일 에이전트, RLM, 군집을 선택해야 한다.
6. 장기 신뢰성은 별도의 연구 문제다: 현재 모델은 한 달 동안 단순 업무를 안정적으로 반복하는 데도 흔들린다. persistent subagent, continual harness, 외부 메모리, 자동 검증을 결합해 이 능력을 측정하고 개선해야 한다.
7. 프런티어 모델과 다른 출력 형식을 탐색하라: GEV처럼 언어 지식을 유지하면서 출력 공간과 추론 지연을 바꾸는 설계는 작은 팀이 거대 연구소와 다른 길로 경쟁할 수 있게 한다.
8. 오픈엔디드니스의 병목은 선택이다: 무한 생성보다 가치 있는 결과를 골라내는 목적 함수와 평가자가 중요하다. 목표가 없을수록 생성량과 선택 기준을 함께 설계해야 한다.
9. 박사과정의 비교우위는 큰 베팅이다: 산업 연구소가 이미 따라가는 벤치마크를 반복하기보다, 처음에는 사소하고 이상해 보이는 문제를 선택해 분야의 선택지를 바꾸는 연구를 시도해야 한다.
10. AI for Science를 위해 시간축을 고려하라: 과학 문제는 피드백이 느리고 모델 발전에 따라 전략이 바뀐다. 하네스의 설계 원칙이 실제 과학 문제의 구조와 맞는지, 장기 검증을 감수할 가치가 있는지 함께 평가해야 한다.

핵심 요약 (20줄)

1. Alex Zhang은 현재 프런티어 모델이 단일 호출보다 훨씬 많은 능력을 갖고 있으며 하네스가 그 능력을 꺼내는 기술이라고 주장한다.
2. GPU Mode는 CUDA 커널 작성 교육에서 출발해 GPU 최적화를 데이터화하고 자동화하려는 커뮤니티로 성장했다.
3. KernelBench의 AI 생성 커널은 빠른 벤치마크 점수와 실제 시스템에서 안정적으로 작동하는 코드 사이에 큰 차이가 있음을 보여준다.
4. 문제를 아는 전문가의 통찰 하나는 무차별 에이전트 탐색에 쓰이는 수천억 토큰보다 훨씬 효율적일 수 있다.
5. GPU 커널의 이론적 속도 한계는 계산할 수 있지만 데이터 이동·캐시·레이어 간 퓨전 때문에 실제 최적화는 더 복잡하다.
6. 학계의 장점은 산업 연구소와 같은 문제를 반복하는 것이 아니라 처음에는 사소해 보이는 큰 연구 베팅을 할 수 있다는 점이다.
7. SWE-bench와 RLM은 처음에는 쓸모없거나 당연해 보였지만 연구 분야의 방향을 바꾼 문제 설정의 사례다.
8. GEV는 언어 모델이 반드시 자동회귀 text-to-text 디코더일 필요가 없으며 출력 공간을 새롭게 설계할 수 있음을 보여준다.
9. 게임 에이전트는 언어 이해를 낮은 지연시간의 행동으로 바꾸는 모델과 하네스의 결합을 시험하기 좋은 환경이다.
10. Claude Code·Codex·Pi 같은 하네스는 대부분 모델을 반복 호출하고 전체 궤적을 프롬프트로 유지하는 비슷한 구조를 갖는다.
11. RLM은 하네스의 유일한 직접 도구를 코드로 두고 컨텍스트를 파일·REPL·공유 메모리로 오프로딩한다.
12. RLM은 검색·집계·수학·글쓰기처럼 표면적으로 다른 작업에서 같은 상위 해결 프로그램을 학습하게 할 수 있다.
13. 짧은 작업에서 배운 RLM 전략은 길이가 8~30배 긴 작업과 다른 도메인의 작업으로도 일반화될 가능성이 있다.
14. Prime Agent는 Pi 위에 RLM을 구현하고 IPython·continual harness·에이전트 간 코드 통신·persistent subagent를 결합한다.
15. Harvey·Headlong·ARC-AGI 3 사례는 RLM이 법률 문서·지속적 사고·신경기호 문제에 적용될 수 있음을 보여준다.
16. OpenAI의 군집 실험은 약 1만 에이전트와 1,300억 출력 토큰, 약 4,000만 달러 규모의 탐색을 사용했다.
17. 대규모 군집의 상당 부분은 낭비될 수 있지만 여러 에이전트의 탐색을 하나의 답으로 수렴시키는 설계 자체가 어렵다.
18. 오픈엔디드니스의 진짜 병목은 무한 생성이 아니라 거대한 결과 코퍼스에서 숨은 보석을 고르는 평가와 선택이다.
19. Neuralese는 영어·코드·자동회귀 순서의 제약을 넘어 기계가 관계와 계획을 더 직접적으로 표현하는 가능성을 뜻한다.
20. 가장 큰 미개척 기회는 현재 모델을 한 달 동안 단순한 일을 안정적으로 수행하게 만들고, 그 능력을 과학·연구·업무로 확장하는 하네스다.