Why The Harness Matters More Than The Model | YC Paper Club

URL: https://www.youtube.com/watch?v=n9xKblqyQ28
날짜: 2026-09-07
채널: Y Combinator
발표·대담: Seth Karten, Jon Saad-Falcon, Josh France, Regan Bell

---

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

==같은 모델 가중치라도 어떤 하네스(harness)를 씌우느냐에 따라 성능·비용·자율성·안전성이 크게 달라지는 이유는 무엇인가?==

• 모델은 입력 토큰을 출력 토큰으로 바꾸는 신경망이지만, 실제 에이전트는 도구·파일·메모리·하위 에이전트·실행 환경과 연결되어야 한다.
• 발표에서 소개한 ARC-AGI 사례는 같은 가중치가 단순한 실행 틀에서는 약 30%를 기록하고 더 풍부한 하네스에서는 95% 수준까지 올라갈 수 있다고 주장한다.
• 좋은 하네스는 프롬프트를 길게 만드는 기술이 아니라, 모델이 관찰하고 행동하고 결과를 평가하고 다시 시도할 수 있는 표현력 있는 실행 시스템이다.
• 장기 작업에서는 모델의 지능만큼이나 컨텍스트 관리, 상태 저장, 도구 인내심, 평가 루프, 샌드박스 권한과 인간 검토가 결과를 좌우한다.

이 영상은 세 사례를 이어 붙인다. Seth Karten의 Prime Agent는 재귀적 언어 모델(RLM)과 지속 상태를 이용해 스스로 하네스를 개선하는 연구 시스템이다. Jon Saad-Falcon의 OpenJarvis는 모델·에이전트·도구·메모리·학습으로 구성된 개인용 AI 스택을 로컬 기기에서 운영하려는 시도다. Josh France와 Regan Bell의 YC 내부 QM은 이 원리를 실제 조직의 업무 자동화에 적용한 사례다. 세 사례가 공통으로 보여주는 것은 “더 좋은 모델을 기다리는 것”보다 “모델이 일할 수 있는 환경과 피드백 루프를 설계하는 것”이 먼저라는 점이다.

1. 하네스는 장식용 프롬프트가 아니라 연구 대상이다

1.1. 시작부터 제시된 성능 차이

1. 같은 가중치, 다른 결과

   1. 영상의 소개는 같은 모델 가중치가 ARC-AGI에서 단순한 하네스와 개선된 하네스 사이에 큰 점수 차이를 낼 수 있다고 말한다. 모델을 바꾸지 않고 실행 구조를 바꾸는 것만으로 약 30%에서 95% 수준까지 올라갈 수 있다는 사례다.
   2. 이 수치는 모델 벤치마크 점수를 모델의 고정된 능력으로만 해석할 수 없다는 뜻이다. 무엇을 보고, 어떤 도구를 호출하고, 실패를 어떻게 기록하고, 언제 다시 시도하는지가 점수에 포함된다.

2. 하네스를 하찮게 보는 오해

   1. 도입부에서 하네스는 단순한 scaffolding, 단순한 prompt engineering, 진짜 연구가 아닌 것으로 취급되곤 한다는 견해가 소개된다.
   2. 발표자들은 이에 동의하지 않는다. 모델이 실제 문제를 해결할 때 필요한 외부 상태, 실행·관찰 루프, 평가와 복구를 설계하는 일은 모델 가중치를 만드는 일과 다른 종류의 연구 문제일 뿐, 덜 중요한 문제가 아니다.

1.2. 프레임과 하네스의 차이

1. 정적인 프레임

   1. 초기 언어 모델은 시스템 프롬프트와 입력을 받아 출력을 내놓는 직렬 프로세서로 다뤄졌다. 모델 가중치는 고정되어 있고, 외부 세계를 읽거나 바꾸는 표준 경로가 없었다.
   2. 이 방식에서는 모델이 계산을 틀리거나 맥락을 놓쳐도 스스로 확인할 수 없다. 프롬프트 안에 지시를 더 많이 넣는 것이 유일한 개선 수단처럼 보인다.

2. 표현력 있는 하네스

   1. 하네스는 모델에 도구 호출, 파일 읽기·쓰기, Python REPL, 계산, 장기 메모리, 하위 에이전트, 메시지 교환, 평가기와 재시도 루프를 제공한다.
   2. 모델은 단일 답변을 내는 대신 계획하고, 실행하고, 결과를 보고, 잘못된 부분을 고치고, 다음 작업에 상태를 남길 수 있다. 이때 하네스는 모델의 지능을 대신하는 것이 아니라 지능이 발휘될 공간을 만든다.

2. 자동 연구자를 만들려던 것이 아닌데 하네스가 되었다

2.1. 아이디어에서 평가 시스템으로

1. 초기 아이디어

   1. 발표자는 여러 초기 아이디어를 에이전트 팀에 주고, 앙상블 크기·분할 방식·실행 횟수·평가 지표를 바꿔가며 실험하려 했다.
   2. 한 에이전트는 논문·리뷰·GitHub 저장소를 찾고, 다른 에이전트는 연구를 맡고, 또 다른 에이전트는 구현과 전파를 맡는다. 사람은 목표와 피드백을 주고 전체 진행을 확인한다.

2. 관찰 가능한 실행

   1. 에이전트의 진행 상황을 보기 위해 제어판과 원격 접속을 만들었다. Tailscale을 통해 어디서든 세션과 작업 상태를 확인하고, 진행 상황을 직접 보고받을 수 있게 했다.
   2. 여러 개의 H100 노드와 대규모 모델을 단순히 실행하는 것보다, 작업이 어떤 단계에 있고 어떤 결과를 내는지 관찰하는 인터페이스가 더 중요했다. 결과가 괜찮아 보이는 것만으로는 실행 과정의 누락을 알 수 없기 때문이다.

2.2. 성능을 설명하는 것은 모델 하나가 아니다

1. 실행 틀의 누적 효과

   1. 같은 모델이 3월과 4월에는 좋지 않은 글이나 연구 결과를 냈다가, 이후에는 여러 아이디어를 병렬로 처리하고 도구와 검증기를 사용하며 개선됐다.
   2. 발표자는 이 변화를 새 가중치 하나의 효과로 설명하지 않는다. 연구자·리뷰어·작성자 에이전트, 상태를 보는 대시보드, 반복 실행, 사람의 개입이 합쳐진 결과다.

2. 평가가 하네스를 다시 만든다

   1. 목표를 명확하게 쓰고, 여러 실행을 비교하고, 실패 로그를 읽는 과정에서 평가 시스템 자체가 커졌다.
   2. 처음에는 “과정이 어떻게 진행되는지 보고 싶다”는 요구였지만, 곧 어떤 결과가 좋은지 측정하고, 평가에 따라 다음 실행을 조정하는 자동 연구 루프가 됐다.

3. 하네스의 짧은 역사: 정적 프롬프트에서 재귀 시스템으로

3.1. GPT-2와 GSM8K 스타일의 정적 실행

1. 초기 프레임워크

   1. 발표에서는 2019년 무렵의 초기 GPT-2 스타일 프레임워크를 출발점으로 삼는다. 시스템 프롬프트와 문제를 넣으면 모델이 정해진 형식의 답을 출력한다.
   2. GSM8K 같은 수학 예시에서는 “수학 선생님”이라는 역할과 문제를 시스템 프롬프트에 넣고, 출력의 최종 정답이 맞는지를 측정한다. 틀리면 점수가 낮아지지만 모델이 왜 틀렸는지 스스로 탐색하는 통로는 없다.

2. 맥락을 추가하는 방식의 한계

   1. 몇 개의 예시를 추가하는 in-context learning(ICL)은 처음에는 성능을 올리지만, 예시를 40~50개쯤 넣으면 포화될 수 있다.
   2. 그 다음 선택지는 LoRA나 SFT 같은 학습 방식으로 보이지만, 영상의 관점에서는 학습만이 해답이 아니다. 실행 중에 계산·검색·검증·재시도를 제공하면 가중치를 바꾸지 않고도 문제 해결 능력을 확장할 수 있다.

3.2. 도구와 외부 상태의 등장

1. Toolformer와 WebGPT

   1. 모델이 계산을 가중치에서 직접 꺼내는 대신 Python 함수나 외부 도구를 호출하도록 하면, 5-2 같은 단순한 연산도 확실한 계산 경로로 보낼 수 있다.
   2. 도구 호출은 JSON 객체와 매개변수만 추가하는 것처럼 보이지만, 모델이 언제 도구를 써야 하는지, 결과를 어떻게 읽어야 하는지, 실패하면 어떻게 다시 요청할지를 함께 설계해야 한다.

2. MemGPT와 Voyager

   1. MemGPT는 컨텍스트를 읽고 외부 기록을 관리하는 메모리 개념을 전면에 둔다. 모델의 고정 입력창 밖에 있는 정보를 필요할 때 가져오고, 오래된 맥락을 정리해 다시 저장한다.
   2. Minecraft의 Voyager는 도구와 기술(skill)을 축적한다. 파일에 저장된 skills.md 같은 절차를 찾아 읽고, 한 번 배운 작업 방식을 다음 시도에 재사용한다.

3.3. ReAct, 다중 에이전트와 RLM

1. 행동과 반성의 루프

   1. ReAct, 자기 정제(self-refinement), 반성(reflection)은 생각만 이어가는 대신 행동하고 결과를 본 뒤 오류를 다시 평가하는 패턴을 만든다.
   2. 여러 에이전트가 서로 다른 역할을 맡으면 한 모델의 맥락에 모든 판단을 욱여넣지 않아도 된다. 한 에이전트가 평가하고 다른 에이전트가 결과를 비판하면 오류를 발견할 기회가 늘어난다.

2. 재귀적 언어 모델

   1. RLM은 언어 모델이 Python REPL 같은 실행 환경에서 다른 언어 모델 호출을 프로그램적으로 만들 수 있게 한다. 부모 모델은 문제를 여러 하위 호출로 나누고, 하위 결과를 다시 모아 다음 판단을 한다.
   2. 이 구조에서는 “에이전트 하나”가 고정된 챗봇이 아니다. 오케스트레이터가 필요할 때 하위 에이전트를 만들고, 작업 완료 후 보고를 받고, 지속 상태를 업데이트한다.

3. Harness V1의 구성

   1. 시스템 프롬프트, 허용된 도구 목록, 허용된 기술 목록, 하위 에이전트 목록, 세션 관리와 컨텍스트 컴파일이 첫 하네스를 이룬다.
   2. 하네스는 매 실행마다 모든 것을 컨텍스트에 넣지 않는다. 무엇을 활성화하고 무엇을 파일이나 메모리로 밀어낼지 결정하는 것이 컨텍스트 관리의 핵심이다.

4. Prime Agent: 스스로 개선되는 RLM 하네스

4.1. 모델 위에 실행 시스템을 쌓기

1. 기본 모델에서 에이전트로

   1. 원시 LLM은 입력 토큰을 받아 출력 토큰을 내놓는 신경망이다. Prime Agent는 여기에 지속 상태, 파일, 도구, 계산, 하위 에이전트와 피드백을 추가한다.
   2. 에이전트는 자기 컴퓨터나 실행 환경에서 프로그램을 시작하고, 결과를 읽고, 새로운 호출을 만들고, 긴 작업을 계속한다. 모델의 추론 능력은 이 주변 환경을 통해 행동으로 바뀐다.

2. 계속 실행되는 세션

   1. 하위 에이전트는 특정 작업을 맡은 뒤 부모에게 보고하고 대기 상태로 전환된다. 부모는 필요하면 나중에 메시지를 보내 작업을 재개시킬 수 있다.
   2. 에이전트가 노트북을 닫거나 세션에서 로그아웃해도 백그라운드 작업이 계속되도록 영속적인 REPL과 데몬을 사용한다. 장기 작업에서 이 지속성은 단순한 편의가 아니라 작업 자체의 일부다.

4.2. L1·L2·L3 컨텍스트 캐시

1. L1: 활성 컨텍스트

   1. 당장 모델이 봐야 하는 짧고 빠른 정보다. 모델이 자주 꺼내는 작업 지침과 현재 문제를 토큰으로 제공한다.
   2. 모든 정보를 L1에 넣으려 하면 컨텍스트가 넘치고 비용이 커진다. 따라서 어떤 정보를 지금 모델 앞에 둘지 선택해야 한다.

2. L2: 실행 상태와 REPL

   1. Python 셸이나 Jupyter 노트북의 변수처럼, 이미 계산한 결과와 중간 상태를 실행 환경에 남긴다.
   2. 모델이 이전 결과를 다시 긴 텍스트로 입력받는 대신, 프로그램과 변수를 통해 필요한 부분을 읽는다. 이 방식은 토큰을 절약하고 복잡한 장기 작업을 이어가게 한다.

3. L3: 장기 메모리와 외부 저장소

   1. 오래된 대화, 기술, 작업 이력과 결과는 파일·데이터베이스·메모리 시스템에 저장한다. 컨텍스트 창 밖으로 나간 정보도 나중에 다시 찾아올 수 있어야 한다.
   2. 메모리는 무조건 쌓는 기록이 아니다. 생성(create), 읽기(read), 업데이트(update), 삭제(delete)를 통해 낡은 상태와 기술을 정리해야 한다. 상태가 길이 제한을 넘으면 요약·압축·정리가 필요하다.

4.3. 하위 에이전트와 메시지 교환

1. 역할별 분업

   1. 연구, 검색, 구현, 평가를 서로 다른 에이전트에 맡기면 각자가 더 좁은 맥락에서 일할 수 있다.
   2. 부모·자녀·형제 관계를 가진 에이전트끼리 직접 메시지를 주고받으면, 중앙 오케스트레이터가 매번 모든 내용을 다시 복사하지 않아도 된다.

2. 생성된 하네스의 재사용

   1. 여러 하네스 조합을 실행하고 효율을 평가한 뒤, 좋은 결과를 낸 시스템 프롬프트·도구·에이전트 구성을 아카이브에 남긴다.
   2. 다음 실행은 이 아카이브에서 더 나은 조합을 선택한다. 하네스가 자기 자신을 바꾸고, 메타 하네스가 다른 하네스를 만드는 구조로 확장된다.

4.4. ARC-AGI와 에뮬레이터 벤치

1. 정답보다 적응을 측정하는 ARC-AGI

   1. ARC-AGI의 핵심은 본 적 없는 새로운 문제에 얼마나 빨리 적응하는가다. 따라서 단순 암기나 특정 데이터셋에 맞춘 훈련보다 유연한 지능과 실행 과정이 중요하다.
   2. 발표에서는 Prime Agent가 일반적인 평가 프레임과 자체 도구를 이용해 높은 결과를 낸 사례를 제시한다. 모델·하네스·평가 설정이 뒤섞이지 않도록 게임별 결과와 실행 로그를 분리해 봐야 한다.

2. 에뮬레이터 벤치

   1. Program Bench의 대안으로 에뮬레이터 벤치를 소개한다. 목표는 에뮬레이터, 예를 들면 Game Boy Color 같은 컴퓨터 시스템을 직접 구현하고 실제로 작동시키는 것이다.
   2. RLM에 REPL을 주면 모델은 코드 작성만 하는 것이 아니라 외부 실험 사이클을 돌릴 수 있다. 아이디어를 구현하고, 에뮬레이터를 실행하고, 결과를 보고, 다시 코드를 고치는 흐름이 가능해진다.

3. 장기 실험

   1. nanoGPT 자기 탐색 실험에서는 일정한 GPU 자원을 장기간 배정하고, 값비싼 주 실험에 들어가기 전에 작은 외부 실험으로 설정과 하이퍼파라미터를 점검한다.
   2. Factorio 사례에서는 7일 동안 633개 에이전트와 약 2,300만 소스 토큰을 사용해 기술 트리와 공장 진행을 계속 이어갔다. 연구·자원 수집·시설 건설·설계·개선에 하위 에이전트를 나눠 쓴 것이 핵심이다.

5. 좋은 하네스를 만드는 기준: 표현력, 상태, 평가

5.1. 표현력은 기능 목록이 아니다

1. 최소 기능의 의미

   1. 에이전트가 Python REPL을 호출하고 프로그램을 시작할 수 있어야 한다. 그렇지 않으면 매번 완성된 답변만 기다려야 하고, 실행 결과를 확인할 수 없다.
   2. 파일과 데이터베이스를 읽고 쓸 수 있어야 한다. 외부 상태를 수정할 권한은 제한되어야 하지만, 읽기·계산·기록의 경로가 없으면 장기 작업은 불가능하다.

2. 하위 에이전트와 피드백

   1. 에이전트 생성·호출·메시지·결과 수집 기능이 있으면 작업을 분해하고 독립적으로 진행할 수 있다.
   2. 평가기나 사람의 피드백을 결과에 연결해야 한다. 도구를 많이 주는 것만으로는 품질이 올라가지 않으며, 어느 행동이 목표 달성에 기여했는지 관찰해야 한다.

5.2. 스케일링은 토큰 양이 아니라 실행 설계다

1. 더 많은 시험 시간의 장점

   1. Prime Agent 발표는 모델에 더 많은 실행 시간·토큰 예산을 주면 연구 보고서와 코드 결과의 품질이 좋아질 수 있다고 말한다.
   2. 다만 단순히 모델을 오래 돌리는 것이 아니다. 중간 상태를 저장하고, 하위 작업으로 나누고, 실패를 평가하고, 다음 시도에서 이전 경험을 활용해야 한다.

2. 비용과 생산성의 비율

   1. 에이전트가 매번 더 많은 토큰을 쓰면 작은 성능 향상은 얻지만, 장기 생산성은 정체될 수 있다. 따라서 작업 완료 품질과 사용 자원 사이의 비율을 측정해야 한다.
   2. 외부 실험으로 저렴한 설정을 먼저 확인하면 H200 같은 고가 자원을 본 실험에 낭비하지 않을 수 있다. 하네스는 성능을 올리는 동시에 실험 비용을 통제하는 장치다.

6. OpenJarvis: 개인용 AI를 로컬 스택으로 옮기기

6.1. 클라우드 중심 개인 AI의 문제

1. 비용과 지연

   1. 현재 개인 비서는 대체로 클라우드 LLM에 의존한다. 여러 요청을 보내면 연간 수천~수만 달러의 API 비용이 발생할 수 있고, 모든 요청이 네트워크를 왕복한다.
   2. 장시간 작업과 다단계 에이전트는 호출 횟수와 에너지 사용량을 더 키운다. 사용자는 결과만 받지만, 데이터와 실행 과정은 클라우드에 계속 전달된다.

2. 개인정보와 통제권

   1. 메일, 파일, 일정, 업무 기록처럼 가장 사적인 데이터를 클라우드 모델로 보내야 하는 구조는 프라이버시와 보안의 부담을 만든다.
   2. 로컬 AI는 모든 문제를 즉시 해결하는 만능 대안이 아니지만, 어떤 데이터를 밖으로 내보낼지 스스로 통제하고 지연을 줄일 수 있다는 점에서 중요한 방향이다.

6.2. 로컬 모델 격차와 하드웨어 변화

1. 좁아지는 성능 격차

   1. 발표자는 로컬 모델이 최고급 클라우드 모델보다 몇 달 뒤처져 있었지만, 그 간격이 빠르게 줄어들고 있다고 설명한다. 특정 작업에서는 Qwen 3.8 27B 같은 모델이 과거의 고급 모델과 비슷한 생산성을 보일 수 있다는 사례가 언급된다.
   2. 모든 업무에서 로컬 모델이 충분하다는 주장은 아니다. 애매한 문제, 고난도 추론, 복잡한 에이전트 작업에서는 여전히 큰 클라우드 모델과 차이가 남아 있다.

2. 가속기와 실행 엔진

   1. Apple Silicon과 NVIDIA 가속기가 개인용 컴퓨터와 워크스테이션으로 내려오면서 로컬 추론의 실용성이 높아진다.
   2. Ollama, llama.cpp, vLLM, SGLang 같은 실행 엔진은 하드웨어와 모델에 맞춰 추론을 수행한다. 개인용 AI의 품질은 모델 파일만이 아니라 이 실행 계층의 선택에도 달려 있다.

6.3. 개인용 AI 스택의 다섯 기본 요소

1. 모델과 에이전트 로직

   1. 모델은 언어·추론 능력을 제공하고, 에이전트 로직은 목표를 작업으로 나누고 도구를 호출하며 결과를 확인한다.
   2. 같은 모델이라도 어떤 에이전트 루프를 씌우느냐에 따라 단순 채팅과 장기 업무 수행 사이의 차이가 생긴다.

2. 도구와 메모리

   1. 파일·웹·터미널·캘린더·데이터베이스 같은 도구는 에이전트를 현실의 업무와 연결한다. MCP 같은 표준 프로토콜은 도구를 일관된 방식으로 노출하는 방법이 된다.
   2. 메모리는 대화 기록만이 아니다. 개인의 선호, 작업 이력, 결과, 기술과 지속 실행 상태를 저장해 다음 요청에서 재사용하는 시스템이다.

3. 학습과 최적화

   1. 프롬프트와 DSPy 같은 방법으로 작업 흐름을 최적화할 수 있고, GRPO·SFT·LoRA 같은 학습 방법으로 특정 업무에 맞는 성능을 개선할 수 있다.
   2. 영상의 다섯 요소는 서로 분리된 부품이 아니다. 모델이 약하면 에이전트 루프와 도구가 보완하고, 도구가 부족하면 메모리와 학습의 효과도 제한된다.

6.4. 클라우드 모델을 로컬 스택의 최적화자로 사용하기

1. 클라우드를 최종 실행자가 아니라 설계자로

   1. OpenJarvis는 클라우드 모델에게 로컬 구성 파일과 작업 결과를 진단하게 하고, 어떤 로컬 모델·실행 엔진·도구 조합이 나은지 제안하게 한다.
   2. 최종 개인정보 작업과 반복 추론은 로컬에서 처리하고, 더 강한 클라우드 모델은 로컬 스택을 분석하고 개선하는 역할을 맡을 수 있다.

2. 800배 비용 절감 주장

   1. 발표에서는 최적화된 로컬 스택이 클라우드 실행보다 약 800배 저렴해질 수 있다고 말한다. 이 수치는 특정 모델·하드웨어·작업량·호출비용을 전제로 한 사례다.
   2. 중요한 결론은 숫자 자체보다 스택 전체를 최적화하면 비용, 지연, 프라이버시를 동시에 개선할 여지가 있다는 점이다. 로컬 모델 하나를 선택하는 것만으로는 같은 효과가 나오지 않는다.

6.5. 익숙한 인터페이스와 지속 실행

1. 사람이 이미 아는 사용 방식

   1. 데스크톱 인터페이스와 채팅을 통해 사용자는 ChatGPT나 Claude를 쓰듯 개인용 AI와 대화할 수 있다. 복잡한 내부 구성은 사용자가 매번 직접 조작하지 않도록 숨긴다.
   2. 동시에 사용자는 다양한 지속성 에이전트를 실행할 수 있다. 크론 작업처럼 매일 돌아가는 에이전트와 한 번의 질문에 답하는 에이전트를 같은 스택에서 다룬다.

2. 비용·에너지·프라이버시의 함께 보기

   1. 로컬 실행은 API 비용과 네트워크 지연을 낮추지만, 하드웨어 구입·전력·모델 성능·관리 비용이 사라지는 것은 아니다.
   2. 따라서 “모든 것을 로컬로 옮기자”가 아니라, 어떤 정보와 작업을 로컬에 두고 어떤 고난도 작업만 클라우드에 보낼지 선택하는 구조가 현실적인 목표다.

7. YC의 QM: 연구 시스템에서 조직 업무로

7.1. QM이 해결하려 한 문제

1. 모든 직원의 개인 비서

   1. QM은 YC 직원이 Slack과 웹 인터페이스에서 사용할 수 있는 개인 업무 보조 에이전트다. 각 사용자에게 파일·크론·샌드박스가 있는 작업 환경을 제공한다.
   2. 업무 범위는 이메일 정리, 법무·재무 프로세스, 내부 데이터베이스에서 정보 추출, 내부 웹 앱 조작, 일정과 이벤트 계획처럼 넓다.

2. 범용성과 개인화의 균형

   1. QM은 특정 기능 하나만 수행하는 봇이 아니라 YC에서 누군가가 매일 만날 수 있는 넓은 범위의 작업을 처리하도록 만들어졌다.
   2. 개인마다 필요한 도구와 데이터 권한이 다르므로, 공통 인터페이스 위에 사용자별 샌드박스와 권한을 결합해야 했다.

7.2. 2025년부터 이어진 내부 에이전트의 진화

1. 2025년 초: 단순한 범용 에이전트

   1. 첫 내부 에이전트는 시스템 프롬프트, 도구, 실행 루프를 가진 단순한 범용 에이전트였다.
   2. 구조는 단순했지만 데이터에 관한 질문에 답하는 데는 놀랄 만큼 효과적이었다. 이후 모델이 좋아지면서 같은 틀의 능력도 확장됐다.

2. 2025년 중반: 코드 에이전트와 가상 머신

   1. 엔지니어들은 Claude Code와 유사한 코드 에이전트를 사용하기 시작했고, 가상 머신을 만들고 Slack에 연결했다.
   2. 코드 변경을 CI와 개발·테스트 환경으로 보내는 작은 피드백 사이클을 마련했다. 사람은 오류나 원하는 작업을 설명하고, 봇은 코드를 바꾸고 실행했다.

3. 2026년 초: OpenClaw와 에이전트 플릿

   1. YC 파트너들이 OpenClaw를 사용하면서, 각자 자신의 컴퓨터를 가진 에이전트가 조직 업무에 들어왔다.
   2. 50개가 넘는 Hermes 에이전트를 가상 머신에 배치한 실험은 유용했지만 관리가 어려웠다. SSH로 여러 시스템에 들어가 복사하고 고치는 일은 “두더지 잡기”처럼 반복됐다.

7.3. 에이전트 플릿의 관리 문제

1. 도구를 주는 것만으로는 부족하다

   1. 에이전트에게 강력한 도구와 컴퓨터를 주면 할 수 있는 일은 많아지지만, 각 사용자가 직접 설정하지 않으면 실질적인 이익으로 이어지지 않는다.
   2. 배포된 에이전트가 너무 이르게 포기하거나, 자신이 어디에 있는지 착각하거나, 데이터베이스에 위험한 변경을 하는 문제가 나타났다.

2. 짧은 피드백과 문서화

   1. 봇이 무엇을 보고 어떤 상태에 있는지 확인하는 짧은 루프를 넣고, 코드베이스의 agent.md 같은 파일에 환경과 운영 규칙을 기록했다.
   2. 사람이 처음에는 도구의 모든 행동을 꼼꼼하게 확인하다가, 시스템이 안정되면 점차 에이전트를 신뢰하는 방식으로 운영 수준을 높였다.

8. 샌드박스는 감옥이 아니라 에이전트의 자원이다

8.1. 고정 샌드박스의 문제

1. 모든 에이전트를 같은 컴퓨터에 가두기

   1. 각 에이전트가 자기 컴퓨터를 가지면 격리와 권한 관리는 쉬워 보이지만, 여러 세션의 상태와 파일을 통합하기 어렵다.
   2. 한 에이전트의 중요한 맥락이 다른 에이전트의 샌드박스에 갇히면, 전체 작업을 조정하는 루트 세션이 정보를 다시 복사해야 한다.

2. 중앙화와 공유

   1. YC는 에이전트 대화와 운영 상태를 중앙 PostgreSQL에 내려놓고, 필요한 에이전트가 축적된 전체 맥락을 볼 수 있는 구조를 실험했다.
   2. 샌드박스는 에이전트가 사는 고립된 장소가 아니라, 필요할 때 연결할 수 있는 자원으로 해석된다. 에이전트의 환경과 회사의 공유 시스템을 분리하되 서로 접근 가능한 경계를 만든다.

8.2. 작업에 맞춰 샌드박스와 모델을 선택하기

1. 어려운 일에는 더 많은 자원

   1. 에이전트가 어려운 AI 연구나 사이버 보안 작업을 수행하면 더 강한 기계와 더 많은 자원을 선택할 수 있다.
   2. 단순한 작업에는 저렴하고 가벼운 샌드박스와 모델을 선택한다. 이 결정을 사람이 매번 지정하지 않고 에이전트가 스스로 고르게 하는 것이 목표다.

2. 실패한 환경에서 빠져나오기

   1. 특정 모델이나 샌드박스가 작업에 맞지 않으면 에이전트가 다른 공급자나 실행 환경으로 전환할 수 있어야 한다.
   2. 이 기능은 도구 하나를 추가하는 것보다 중요하다. 실패한 환경 안에서 같은 명령을 반복하는 대신, 실패 원인을 보고 전체 실행 조건을 바꿀 수 있기 때문이다.

9. 권한과 사회적 맥락: 하네스의 가장 어려운 부분

9.1. 에이전트가 직원처럼 일하려면

1. 개발자 경험과 실제 직원 경험의 일치

   1. 에이전트가 회사 자원을 사용하려면 명령 인터페이스뿐 아니라 기기 인증, OAuth, API 키, 데이터 접근 권한이 필요하다.
   2. QM은 에이전트의 경험을 일반 직원의 노트북 경험과 비슷하게 만들려 한다. 다만 권한은 기본적으로 좁게 주고, 데이터베이스는 읽기 전용으로 시작한다.

2. 계획-검토-적용

   1. 데이터베이스를 바꿔야 할 때 에이전트는 먼저 변경 계획을 제안하고, 사람이 내용을 확인한 뒤 적용하도록 한다.
   2. 검증된 특정 변경만 허용하면 예측할 수 없는 대규모 수정은 막고, 반복 업무의 속도는 유지할 수 있다. 자동화의 핵심은 무제한 권한이 아니라 검토 가능한 권한 위임이다.

9.2. 사회적 맥락을 이해하지 못하는 에이전트

1. 사람 사이의 암묵적 공유

   1. 사람이 동료에게 어떤 말을 하면, 상대는 말하지 않은 배경과 관계를 어느 정도 알고 있다고 가정할 수 있다.
   2. 에이전트는 이 암묵적 맥락을 자동으로 이해하지 못한다. 개인 정보가 포함된 대화를 너무 넓은 공간에 공유하거나, 권한이 없는 사람이 볼 수 있는 곳에 기록할 수 있다.

2. 신뢰성의 상한은 권한 시스템이다

   1. 에이전트의 “두뇌”가 아무리 똑똑해도, 무엇을 읽고 누구에게 보낼 수 있는지 제어하는 권한 시스템이 약하면 전체 시스템의 신뢰성은 낮다.
   2. YC는 수년 동안 구축해 온 소프트웨어 권한 체계를 활용해 에이전트의 접근을 제한한다. 모델의 사회적 판단을 믿기 전에 시스템 수준에서 정보 흐름을 제한해야 한다.

9.3. 에이전트의 조기 포기와 도구 인내심

1. Tool patience

   1. 최근 한 달 동안 YC는 에이전트가 작업을 너무 일찍 포기하지 않도록 시간 또는 토큰 예산을 목표에 연결하는 실험을 했다.
   2. 작업을 몇 분 안에 포기하게 하는 대신, 목표 완료까지 몇 시간 또는 특정 토큰 수를 쓸 수 있게 하면 연구 보고서와 결과물의 품질이 좋아진다.

2. 사무 업무에도 적용

   1. 이런 예산은 자동 연구에만 필요한 것이 아니다. 문서 작성, 데이터 정리, 내부 조사 같은 일반 사무 업무도 충분한 탐색 시간이 주어질 때 좋아질 수 있다.
   2. 다만 예산이 곧 무제한 실행을 뜻하지는 않는다. 목표·중단 조건·비용·권한을 함께 정하고, 결과를 평가할 수 있어야 한다.

10. 세 사례가 합쳐지는 설계 원칙

10.1. 모델을 교체하기 전에 루프를 점검하라

1. 실패의 원인 분해

   1. 모델이 틀렸다는 결론을 내리기 전에 필요한 도구가 없었는지, 맥락이 잘렸는지, 샌드박스가 제한됐는지, 평가기가 잘못됐는지 확인해야 한다.
   2. Prime Agent의 로그와 에뮬레이터 벤치는 이 분해를 가능하게 한다. 최종 점수만 보면 모델 문제와 하네스 문제를 구별할 수 없다.

2. 모델과 하네스의 공동 최적화

   1. OpenJarvis는 로컬 모델 자체뿐 아니라 실행 엔진·도구·메모리·학습 방법을 함께 최적화한다.
   2. QM은 모델을 조직의 권한·파일·크론·Slack·CI와 연결한다. 실전의 생산성은 모델 벤치마크 점수와 실행 환경의 곱으로 결정된다.

10.2. 장기 에이전트의 평가 단위

1. 한 번의 답변에서 궤적으로

   1. 짧은 질문의 정답률만으로 장기 에이전트를 평가할 수 없다. 계획, 도구 사용, 상태 업데이트, 실패 복구, 권한 준수, 최종 결과까지의 궤적을 함께 봐야 한다.
   2. ARC-AGI·에뮬레이터·Factorio 같은 작업은 이 긴 궤적을 드러낸다. 좋은 하네스는 단순 정답뿐 아니라 그 정답에 도달한 과정도 기록한다.

2. 비용과 안전의 동시 측정

   1. 토큰·GPU 시간·API 비용·지연·에너지 사용량을 결과 품질과 함께 기록해야 한다.
   2. 권한 오류, 정보 유출, 샌드박스 탈출, 조기 포기 같은 실패도 정확도와 같은 수준의 운영 지표가 되어야 한다.

10.3. 인간은 당분간 시스템 안에 남는다

1. 자동화 루프 속의 사람

   1. 사람은 목표를 정하고, 평가 기준을 만들고, 민감한 권한을 승인하고, 사회적 맥락을 보충한다.
   2. 에이전트가 더 자율적으로 일할수록 사람이 모든 행동을 직접 클릭하는 방식은 유지되지 않는다. 대신 사람이 개입해야 하는 경계와 확인할 증거를 설계해야 한다.

2. 최종 목표

   1. 하네스는 사람을 완전히 제거하는 장치가 아니다. 사람이 모델의 실행을 신뢰할 수 있도록 상태·근거·권한·복구 경로를 제공하는 조직 운영 시스템이다.
   2. 모델 능력이 더 좋아져도 하네스의 역할은 사라지지 않는다. 더 강한 모델일수록 더 넓은 도구와 권한을 요구하고, 그만큼 평가와 안전 설계가 중요해지기 때문이다.

주요 발언 모음

“Harnesses get dismissed as just scaffolding, just prompt engineering, and not real research. But that couldn't be farther from the truth.”

“The same model weights that score 30% on ARC-AGI score 95% with a better harness.”

“무엇을 바꿀 수 있는가”보다 “어떤 실행 환경에서 무엇을 관찰하고 다시 시도할 수 있는가”가 장기 에이전트의 능력을 결정한다. — 영상 전체 논지의 의역

“한 번의 답변”을 기다리는 모델에서 “계속 실행되고 상태를 남기며 다른 에이전트와 협력하는 시스템”으로 확장해야 한다. — Prime Agent·QM 사례의 공통 취지

핵심 데이터 & 수치

• ARC-AGI 약 30% → 95%: 같은 모델 가중치에 더 표현력 있는 하네스를 적용하면 성능이 크게 달라질 수 있다는 소개 사례다.
• 40~50개 ICL 예시: 맥락 예시를 계속 추가하는 방식은 일정 지점에서 포화될 수 있다는 설명이다.
• 약 800배 저렴: OpenJarvis가 최적화된 로컬 스택의 비용 우위를 설명하며 제시한 사례 수치다. 하드웨어·모델·작업량에 의존한다.
• H100 노드 8개: 자동 연구자를 실험하던 초반 사례에서 언급된 규모다.
• H200 주간 할당: nanoGPT와 장기 외부 실험에서 값비싼 본 실험 전에 반복 검증을 수행한 사례다.
• 7일·633개 에이전트·약 2,300만 소스 토큰: Factorio에서 기술 트리와 공장 진행을 장기적으로 유지한 실험 규모다.
• 50개 이상 에이전트: YC 내부에서 가상 머신 기반 Hermes 에이전트를 다수 배치했을 때 관리 부담이 드러난 사례다.
• 시간·토큰 예산: Tool patience 실험은 에이전트의 조기 포기를 줄이기 위해 목표별 실행 예산을 둔다.

결론 및 시사점

1. 모델 벤치마크를 실행 환경과 분리해 해석하지 마라. 동일한 모델이라도 도구·메모리·평가·샌드박스가 바뀌면 결과가 달라진다.
2. 프롬프트를 늘리기 전에 컨텍스트 계층을 설계하라. 활성 정보는 L1, 실행 상태는 L2, 장기 기억과 이력은 L3로 분리하면 비용과 맥락 손실을 줄일 수 있다.
3. 하네스의 최소 기능은 도구 호출이 아니다. 실행·관찰·평가·복구·상태 저장이 하나의 루프를 이뤄야 한다.
4. 하위 에이전트는 역할을 좁히고 메시지로 연결하라. 모든 일을 한 모델의 단일 컨텍스트에 넣으면 장기 작업과 검증이 어려워진다.
5. 표현력 있는 환경은 에이전트가 실패한 가설을 직접 시험하게 한다. REPL, 에뮬레이터, 파일과 외부 프로그램이 실험의 일부가 된다.
6. 로컬 AI의 경쟁력은 모델 하나의 크기로 결정되지 않는다. 실행 엔진, 하드웨어, 도구, 메모리와 학습 방법을 함께 최적화해야 한다.
7. 클라우드 모델은 로컬 스택을 개선하는 설계자로 활용할 수 있다. 민감한 반복 실행은 로컬에 두고, 강한 모델은 구성 진단과 최적화에 사용할 수 있다.
8. 샌드박스는 격리와 공유 사이의 설계 문제다. 에이전트를 가두기만 하면 맥락이 단절되고, 모두 열어두면 권한과 개인정보 문제가 커진다.
9. 권한은 모델 지능보다 먼저 시스템으로 강제하라. 읽기 전용, 승인된 변경, OAuth 범위, 정보 흐름 제한이 필요하다.
10. 에이전트의 사회적 맥락 이해를 과대평가하지 마라. 사람이 당연하게 공유한다고 생각하는 정보도 에이전트는 무단으로 확장할 수 있다.
11. 조기 포기는 하네스의 운영 실패일 수 있다. 목표·시간·토큰 예산과 중단 조건을 함께 설계해야 한다.
12. 장기 에이전트는 정답률이 아니라 궤적으로 평가하라. 계획부터 최종 결과, 비용, 복구와 권한 준수까지 기록해야 한다.
13. 가장 먼저 개선할 부분은 모델이 아니라 관찰 가능성일 수 있다. 로그·대시보드·실행 상태가 없으면 실패 원인을 모델 탓으로 돌리게 된다.
14. 좋은 하네스는 자기 개선의 기반이다. 실행 결과를 아카이브하고 다음 하네스 구성에 재사용해야 한다.
15. 자율성은 권한의 반대말이 아니다. 에이전트가 스스로 모델과 샌드박스를 선택하더라도 승인·감사 경계는 남아 있어야 한다.
16. 조직 도입의 병목은 모델이 아니라 운영 시스템일 수 있다. 파일·CI·Slack·데이터베이스·인증을 에이전트가 안전하게 다루도록 연결해야 한다.
17. 사람은 클릭하는 운영자에서 경계를 설계하는 운영자로 이동한다. 무엇을 자동화하고 무엇을 검토할지 결정하는 일이 핵심이 된다.
18. 더 강한 모델일수록 더 좋은 하네스가 필요하다. 능력이 높아질수록 행동 범위와 권한이 커지기 때문이다.
19. 비용·지연·에너지·프라이버시는 품질과 함께 최적화해야 한다. 단일 최고 점수만으로 실전 시스템을 선택할 수 없다.
20. 에이전트 제품의 차별화는 모델 API가 아니라 실행 시스템에서 나온다.

핵심 요약 (40줄)

• 하네스는 단순한 프롬프트 포장지가 아니라 모델의 연구·실행 능력을 결정하는 시스템이다.
• 같은 모델 가중치도 하네스의 표현력에 따라 ARC-AGI 결과가 크게 달라질 수 있다.
• 원시 LLM은 입력 토큰을 출력 토큰으로 바꾸지만 실제 에이전트는 외부 상태와 도구가 필요하다.
• 정적 시스템 프롬프트만으로는 모델이 자신의 계산과 행동 결과를 검증하기 어렵다.
• 도구 호출은 계산·검색·파일 작업을 모델의 가중치 밖 실행 경로로 옮긴다.
• Toolformer와 WebGPT는 모델이 외부 도구를 호출하는 흐름을 초기부터 보여준 사례다.
• MemGPT는 컨텍스트 창 밖의 메모리를 읽고 쓰는 문제를 전면에 놓았다.
• Voyager는 Minecraft에서 기술과 절차를 파일에 축적하고 다음 작업에 재사용했다.
• ReAct·자기 정제·반성은 행동과 결과 평가를 연결하는 반복 루프를 만든다.
• 여러 에이전트가 역할을 나누면 연구·구현·평가를 독립적으로 진행할 수 있다.
• RLM은 언어 모델이 REPL에서 하위 언어 모델 호출을 프로그램처럼 조정하게 한다.
• Prime Agent는 재귀 호출·지속 상태·도구·하위 에이전트를 묶은 RLM 하네스다.
• 지속적인 REPL과 백그라운드 세션은 긴 작업을 중단 없이 이어가게 한다.
• L1 컨텍스트는 당장 필요한 정보를, L2는 실행 상태를, L3는 장기 기억을 담는다.
• 메모리는 무한히 쌓는 기록이 아니라 생성·읽기·업데이트·삭제되는 운영 상태다.
• 부모·자녀·형제 에이전트 간 메시지는 맥락을 복사하지 않고 협업하게 한다.
• 하네스 구성과 실행 결과를 아카이브하면 메타 하네스가 다음 시스템을 선택할 수 있다.
• ARC-AGI는 본 적 없는 문제에 적응하는 유연한 지능과 실행 구조를 시험한다.
• 에뮬레이터 벤치는 에이전트가 코드를 쓰고 실행하고 수정하는 외부 실험 루프를 측정한다.
• 장기 nanoGPT 실험은 작은 외부 실험으로 비싼 GPU 실험의 실패를 줄인다.
• Factorio 실험은 633개 에이전트와 2,300만 토큰 규모의 장기 분업을 보여준다.
• OpenJarvis는 모델·에이전트 로직·도구·메모리·학습을 개인 AI의 핵심 스택으로 본다.
• 클라우드 개인 비서는 API 비용·지연·에너지·개인정보 전송 문제를 안고 있다.
• 로컬 모델과 가속기의 발전은 개인 기기에서 실행 가능한 작업 범위를 넓힌다.
• 로컬 모델이 모든 고난도 업무를 대체하는 것은 아니며 작업별 선택이 필요하다.
• Ollama·llama.cpp·vLLM·SGLang은 모델과 하드웨어를 연결하는 실행 계층이다.
• MCP는 개인용 AI가 도구를 표준 방식으로 연결하는 기반이 될 수 있다.
• 클라우드 모델을 로컬 스택의 진단·최적화자로 쓰면 역할을 분리할 수 있다.
• OpenJarvis는 최적화된 로컬 실행의 비용이 클라우드보다 크게 낮아질 수 있다고 주장한다.
• QM은 YC 직원이 Slack과 웹에서 쓰는 개인 업무 에이전트 플랫폼이다.
• QM은 이메일·법무·재무·내부 데이터·웹 앱·일정 등 넓은 업무를 다룬다.
• YC의 내부 에이전트는 단순 루프에서 코드 에이전트·가상 머신·에이전트 플릿으로 진화했다.
• 50개 이상 가상 머신 에이전트는 유용했지만 설정과 관리의 복잡성을 드러냈다.
• 샌드박스는 에이전트를 가두는 장소이면서 필요할 때 제공하는 실행 자원이어야 한다.
• 에이전트가 작업에 맞춰 더 강한 샌드박스와 다른 모델을 선택하면 실패 환경을 벗어날 수 있다.
• 데이터베이스는 읽기 전용으로 시작하고 변경 계획을 사람이 검토한 뒤 적용하는 방식이 안전하다.
• 에이전트는 사람이 당연하게 아는 사회적 맥락과 정보 공유 범위를 자동으로 이해하지 못한다.
• 최종 신뢰성은 모델 지능보다 권한 시스템과 정보 흐름 통제에 의해 제한될 수 있다.
• Tool patience는 시간·토큰 예산으로 에이전트의 조기 포기를 줄이는 운영 실험이다.
• 좋은 에이전트 제품은 모델 API보다 실행 루프·상태·도구·평가·권한을 함께 설계한다.