Engineers… Your Software Factory NEEDS Agent Sandboxes to SCALE (exe.dev)

URL: https://www.youtube.com/watch?v=SEI_qIW4o2c
날짜: 2026-08-13
채널: IndyDevDan
영상 길이: 약 37분 14초
영상 ID: SEI_qIW4o2c

메타데이터

• 원문 제목: Engineers… Your Software Factory NEEDS Agent Sandboxes to SCALE (exe.dev)
• 발표자/채널: IndyDevDan
• 발행일: 2026-08-13
• 원문 URL: https://www.youtube.com/watch?v=SEI_qIW4o2c
• 핵심 주제: 소프트웨어 팩토리(software factory)를 에이전트 샌드박스(agent sandbox) 안에 배치해 격리(isolation)·확장(scale)·자율성(autonomy)을 확보하는 아키텍처
• 데모 도구: exe.dev, Herder 터미널 멀티플렉서(terminal multiplexer), Claude Code 계열 오케스트레이터(orchestrator), pi agent SDK, Super Simple Software Factory(SSF), OpenRouter provisioned key
• 데모 애플리케이션: Inkwell이라는 단순 글쓰기 애플리케이션
• 분석 기준: 자동 생성 영어 자막을 시간순으로 정리했으며, 자막에서 모델명·도구명이 뭉개진 부분은 화면/문맥상 식별 가능한 표현을 병기했다.

---

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

==소프트웨어 팩토리는 에이전트 샌드박스 안에 들어가야 비로소 에이전트의 컴퓨트·코드·워크플로우를 안전하게 확장하고, 인간을 루프의 병목에서 끌어낼 수 있다.==

• 에이전트를 내 컴퓨터의 작은 구석이나 하나의 컨테이너에 가두면 어느 정도 격리는 되지만, 컴퓨트 확장(scale)과 자율 실행(autonomy)은 제한된다.
• VM 단위의 에이전트 샌드박스는 에이전트에게 개발자 장치(developer device) 전체를 주고, 그 안에 오케스트레이터·에이전트 팀·코드·애플리케이션을 함께 배치한다.
• Best of N 패턴은 하나의 프롬프트를 여러 모델+하네스(harness)+코드 조합에 동시에 보내고 결과를 비교해 가장 좋은 미래를 선택하게 한다.
• 핵심 단위는 단일 에이전트가 아니라 에이전트와 결정론적 코드(deterministic code)를 결합한 소프트웨어 개발 생명주기(software developer life cycle)다.

이 영상은 out-of-sandbox orchestrator → in-sandbox orchestrator → software factory/ADW agents → application이라는 3계층 구조를 실제 데모로 보여준다. 한 대의 컴퓨터에서 에이전트가 내 작업을 방해하도록 두는 대신, exe.dev의 내구성 있는 VM 여러 개에 각각 소프트웨어 팩토리를 만들고 동일한 요구사항을 병렬 실행한다. 그 결과 인간은 처음의 계획·프롬프트와 마지막의 검토·검증에 집중하고, 에이전트는 자신만의 개발 장치에서 지속적으로 일할 수 있다.

1. 문제 제기: 에이전트가 어디에서 실행되어야 하는가

1.1. 에이전틱 엔지니어링의 병목은 실행 공간이다

1. 소프트웨어 팩토리의 잠재력

   1. 에이전트 중심(agentic) 소프트웨어 팩토리는 지금까지의 엔지니어링 결과를 전례 없는 수준으로 끌어올릴 수 있다.
   2. 그러나 어느 시점이 되면 모든 에이전틱 엔지니어가 같은 질문에 부딪힌다. 에이전트와 에이전트가 실행하는 코드가 실제로 어디에서 실행되어야 하는가라는 질문이다.
   3. 많은 엔지니어는 자신의 컴퓨터에서 아주 작은 영역을 에이전트에게 내주거나, CI/CD 파이프라인이나 컨테이너(container)에 과도하게 의존한다.

2. 에이전트에게 더 많은 컴퓨트를 주어야 하는 이유

   1. 대규모 AI 연구소에서 가장 강력한 워크로드를 처리하는 엔지니어들은 에이전트를 노트북의 한쪽 구석에서만 돌리지 않는다.
   2. 더 자율적이고 안전한 에이전트일수록 인간을 위험에 빠뜨리지 않으면서 더 많은 일을 맡을 수 있다.
   3. 발표자가 여러 에이전틱 엔지니어링 영상에서 반복해온 원칙은 scale your compute to scale your impact다.
   4. 여기서 컴퓨트(compute)는 GPU 컴퓨트뿐 아니라 CPU 컴퓨트, 즉 전통적인 베어메탈(bare metal) 자원까지 포함한다.

1.2. 샌드박스가 제공하는 세 가지 이점

1. 에이전트 샌드박스의 정의

   1. 에이전트 샌드박스(agent sandbox)는 에이전트를 배치하기 위한 가장 적합한 작업 공간이다.
   2. 단순히 컨테이너를 띄우고 문제가 끝났다고 할 수 없는 이유는 샌드박스가 컨테이너보다 더 큰 실행 단위를 제공하기 때문이다.

2. 세 가지 핵심 이점

   1. 진정한 격리(true isolation): 에이전트가 인간의 작업 공간이나 운영 시스템에 직접 간섭하지 않는다.
   2. 엄청난 확장(insane scale): 하나의 에이전트가 아니라 여러 VM과 여러 팩토리를 동시에 띄울 수 있다.
   3. 자율성(agency/autonomy): 에이전트가 자신만의 컴퓨터를 소유하고 필요한 파일·프로세스·도구를 이용해 끝까지 결과를 만들 수 있다.

3. 루프 안에 있는 인간의 병목

   1. 발표자는 “If you are inside the loop, you are the bottleneck”이라고 규정한다.
   2. 인간이 매 단계마다 에이전트를 지켜보고 다음 프롬프트를 넣어야 한다면 에이전트의 처리량이 아니라 인간의 응답 속도가 시스템 전체의 상한이 된다.
   3. 이 영상의 목표는 소프트웨어 팩토리 자체를 에이전트 샌드박스 안으로 옮겨 인간이 루프 밖으로 나올 수 있는 지점을 보여주는 것이다.

2. 데모의 기술 스택과 전체 설계

2.1. 도구보다 목적을 먼저 선택한다

1. 데모 스택

   1. 발표자는 터미널 멀티플렉서로 Herder를 사용한다. 이를 통해 에이전트를 관찰하고, 작업을 시작하고, 임의의 셸 명령을 실행한다.
   2. 샌드박스의 소프트웨어 팩토리 안쪽에는 Claude Code 계열의 최상위 오케스트레이터를 사용한다. 자동 자막에서는 이름이 뭉개져 들리지만, 핵심은 특정 제품보다 오케스트레이션 역할이다.
   3. 에이전트 SDK로는 pi를 사용한다. 발표자는 하나의 에이전틱 코딩 도구에 자신을 제한하지 말라고 강조한다.
   4. 샌드박스 제공자로는 exe.dev를 사용한다. 발표자가 소개하는 핵심 문구는 “Computers for developers and agents”, 즉 개발자와 에이전트를 위한 컴퓨터다.

2. 도구 선택의 원칙

   1. 영상에서 반복되는 메시지는 도구 자체에 집착하지 말고 목적에 맞는 최선의 도구를 선택하라는 것이다.
   2. 사용하는 도구가 곧 가능하다고 믿는 작업의 범위를 제한한다. 특정 코딩 에이전트 하나만 알면 가능한 아키텍처도 그 도구의 기능 안으로 축소된다.
   3. 그러므로 모델·하네스·도구·코드를 조합할 수 있는 층을 확보해야 한다.

2.2. 3계층 아키텍처

1. 샌드박스 바깥의 오케스트레이터(out-sandbox orchestrator)

   1. 개발자의 로컬 머신에서 실행되며, 사용자의 단일 요구사항을 받아 여러 샌드박스를 생성하고 각 샌드박스 안쪽 오케스트레이터를 시작한다.
   2. 이 계층은 여러 후보 실행을 관리하는 지휘자이며, 실제 애플리케이션 코드를 직접 작성하는 주체가 아니다.

2. 샌드박스 안의 오케스트레이터(in-sandbox orchestrator)

   1. 각 VM 내부에서 실행되고, 그 안에 설치된 Super Simple Software Factory(SSF)를 시작한다.
   2. 자체적으로 소프트웨어 개발 생명주기(계획·빌드·테스트·리뷰·문서화)를 돌리며 해당 샌드박스의 에이전트 구성을 선택한다.
   3. 바깥 오케스트레이터가 실행만 지시하고 안쪽 오케스트레이터가 작업을 실제로 조율하도록 분리하면 제어권과 재사용성이 좋아진다.

3. ADW 에이전트와 소프트웨어 팩토리

   1. 소프트웨어 팩토리는 스카우터(scouter), 플래너(planner), 빌더(builder), 테스터(tester) 같은 에이전트 원자(atom)를 결정론적 코드와 연결한다.
   2. 영상에서 ADW는 실제 에이전트 작업 상태와 산출물을 기록하는 디렉터리/시스템으로 설명된다. 중요한 것은 에이전트 호출의 나열이 아니라 재현 가능한 워크플로우 상태다.
   3. 이 층은 모델 하나가 아니라 “어떤 모델이 어떤 코드와 도구를 사용해 어떤 개발 단계에 참여하는가”를 명시한다.

4. 애플리케이션 계층(application layer)

   1. 각각의 VM에는 에이전트 팩토리와 실제 애플리케이션이 함께 있다.
   2. 데모에서는 Inkwell이라는 간단한 글쓰기 앱을 사용한다. 앱 자체의 기능보다 다섯 팩토리가 동일한 앱을 어떻게 서로 다르게 개선하는지가 관찰 대상이다.

2.3. exe.dev의 샌드박스 특성

1. 내구성 있는 개발자 장치

   1. exe.dev는 빠르고 안전하며 공유 가능한(durable, fast, secure, sharable) 샌드박스를 제공한다.
   2. 다른 서비스가 24시간 또는 며칠 뒤 VM을 없애는 것과 달리, 필요한 동안 유지하고 원할 때 내렸다 올릴 수 있는 VM을 제공한다.
   3. SSH로 접근할 수 있고, 애플리케이션용 공개 포트와 팩토리용 비공개 포트를 분리할 수 있다.

2. 격리 단위와 blast radius

   1. 에이전트가 개인 컴퓨터의 작은 구석에서 일하면 에이전트와 인간이 서로의 파일·프로세스·주의력을 침범한다.
   2. VM 샌드박스 안에서는 에이전트가 컴퓨터 전체를 소유하며, 잘못된 동작의 blast radius가 해당 박스 안으로 제한된다.
   3. AWS·GCP 같은 중요한 인프라에 접근할 수 있는 권한도 박스 수준에서 제거하거나 제한할 수 있다.

3. Best of N: 한 요구사항을 여러 팩토리로 확장하기

3.1. 동일한 프롬프트, 다섯 개의 독립 실행

1. 실험 목표

   1. 데모 애플리케이션 Inkwell의 첫 화면은 버튼과 핫키가 너무 많고 기능이 바깥으로 드러나 있어 산만했다.
   2. 요구사항은 “quiet room”이라는 디자인 원칙에 맞춰 인터페이스를 더 단순하고 명확하게 만드는 것이다.
   3. 이 단일 프롬프트를 한 에이전트에 한 번 보내는 대신 다섯 개의 에이전트 샌드박스에 동시에 전달한다.

2. 다섯 가지 모델+하네스 구성

   1. Default 구성은 여러 고성능 모델을 조합한 기본 에이전트 팀이다.
   2. Frontier 구성은 최첨단(state-of-the-art) 모델을 중심으로 한다.
   3. Deepest Seek 구성은 DeepSeek V4 Flash 계열 모델만 사용하는 경제적인 워크호스(workhorse) 실험이다.
   4. Open Weights 구성은 폐쇄형 연구소 모델 없이 순수 오픈 웨이트(open weights) 모델로 구현한다.
   5. Top Speed 구성은 비용과 지연시간보다 빠른 결과를 우선하는 구성이다.
   6. 각 구성은 별도의 VM과 별도의 URL을 가지며, VM 안에 소프트웨어 팩토리 화면과 실제 Inkwell 애플리케이션 화면이 각각 열린다.

3. Best of N의 의미

   1. N개의 후보를 만든 뒤 가장 좋은 결과를 선택하는 방식이다.
   2. 후보들은 단순히 서로 다른 모델이 아니라, 모델·시스템 프롬프트·사용자 프롬프트·하네스·도구·개발 워크플로우가 결합된 서로 다른 팩토리다.
   3. 하나의 방향이 확실하지 않을 때 여러 잠재적 미래를 실제로 실행해보고, 결과와 비용을 비교해 다음 방향을 선택한다.

3.2. 소프트웨어 개발 생명주기를 병렬 실행한다

1. 단순 호출이 아닌 AI 개발자 워크플로우

   1. 팩토리는 에이전트를 띄우는 데서 끝나지 않고 전체 소프트웨어 개발 생명주기를 수행한다.
   2. 데모에서 관찰한 단계는 요청 수신, 계획(plan), 구현(build), 테스트(test), 리뷰(review), 문서화(document)다.
   3. 버그 수정이나 핫픽스(hot fix), 지원 요청(support request)에도 같은 구조를 적용할 수 있다.

2. 관찰 가능성과 결정론적 게이트

   1. 각 실행에는 요청, 계획 워크플로우, 모델의 사고/호출, 게이트 통과 상태가 기록된다.
   2. 비결정론적(nondeterministic) 에이전트 시스템 위에 결정론적(deterministic) 게이트 검사를 둔다.
   3. 예를 들어 JSON 형식이 깨지면 게이트가 실패하고 에이전트가 JSON 오류를 수정한 뒤 다음 단계로 진행한다.
   4. 발표자는 이를 에이전트 호출을 그냥 지켜보는 것이 아니라 실제 시스템의 상태를 관찰하는 “에이전트 관찰 가능성 시스템(agent observability system)”으로 설명한다.

3. 하네스 엔지니어링(harness engineering)

   1. 각 실행은 코딩 에이전트, 모델, 사고 수준(thinking level), 도구를 명시적으로 선택한다.
   2. 도구는 pi 기반의 커스텀 에이전트 하네스에서 제공된다.
   3. 커스텀 하네스가 없으면 에이전트가 무엇을 할지 통제하거나 시스템을 전문화하기 어렵다.
   4. 따라서 소프트웨어 팩토리란 “에이전트와 코드에 대한 완전한 제어권”이라는 정의가 가능하다.

3.3. 실행 결과와 실패도 데이터로 취급한다

1. Open Weights의 실패

   1. 데모 중 Open Weights 실행은 실패했다.
   2. 원인은 Kimi K3가 JSON 형식을 제대로 출력하지 못한 것으로 표시됐고, 상세 오류를 관찰 화면에서 확인할 수 있었다.
   3. 발표자는 이 실패가 Best of N 패턴의 이유라고 설명한다. 하나의 실행에 모든 기대를 걸지 않고 여러 후보를 동시에 돌리면 한 후보의 실패가 전체 결과를 막지 않는다.

2. Frontier의 지연

   1. Frontier 구성도 촬영 시점에 아직 완료되지 않았고 Kimi K3가 계속 작업 중이었다.
   2. 최첨단 모델은 높은 사고 수준을 사용하고 계획 단계에 13분가량 걸릴 수 있어, 항상 최선의 선택인 것은 아니다.
   3. 모델의 성능뿐 아니라 지연시간과 비용까지 함께 봐야 한다.

3. Top Speed의 완료

   1. Top Speed 구성은 전체 실행을 약 14분에 완료했고 약 2 million tokens를 사용한 것으로 화면에 표시됐다.
   2. 빠른 모델로 Gemini 3.6 Flash, DeepSeek V4 Flash 0731, GPT-5.6 Luna가 언급됐다.
   3. 결과는 전반적으로 좋았지만 화면 요소가 Deepest Seek보다 조금 더 산만했고, 그래도 푸터 핫키·? 단축키·쓰기 뷰·저장 확인·확대/축소 컨트롤을 제공했다.

4. 모델 스택: 단일 최강 모델에서 조합 가능한 컴퓨트로

4.1. 세 계층의 모델 전략

1. State-of-the-art

   1. 가장 높은 지능과 복잡한 오케스트레이션 능력이 필요한 작업에 사용한다.
   2. 데모에서 Claude Opus 5가 계획 단계에서 높은 사고 수준으로 동작하며 토큰과 비용을 많이 소비하는 모습이 보였다.

2. Workhorse

   1. 최첨단은 아니지만 일상 업무의 약 90%를 맡는 강력한 모델 계층이다.
   2. 새로 등장한 DeepSeek V4 Flash 0731이 이 계층의 핵심 사례로 소개된다.
   3. DeepSeek V4 Flash는 builder와 worker 역할을 동시에 수행하고, 가격 대비 성능이 매우 뛰어나며, 발표자의 평가로는 이전 DeepSeek Flash의 B tier에서 A tier로 올라온 모델이다.

3. Lightweight

   1. 이전 세대 GPU 노드나 통합 메모리가 충분한 Mac에서 직접 실행할 수 있는 모델 계층이다.
   2. 가벼운 작업에 낮은 비용으로 배치할 수 있어 전체 팩토리의 경제성을 높인다.

4.2. 성능·비용·속도의 삼각형

1. 모델 선택의 기준

   1. 발표자는 성능(performance), 비용(cost), 속도(speed)라는 세 요소를 계속 교환(trade-off)해야 한다고 말한다.
   2. “어떤 모델이 제일 좋은가”가 아니라 “어떤 모델+코드 조합이 이 작업에 필요한가”를 물어야 한다.
   3. 모델 하나를 고정해 선택하는 것이 아니라 필요에 따라 컴퓨트를 조합(combine compute)해야 한다.

2. 벤치마크를 동적으로 사용한다

   1. DeepSeek V4 Flash는 Artificial Analysis의 비용 대비 작업(task) 벤치마크에서 매우 낮은 비용과 준수한 속도를 보여주는 모델로 언급된다.
   2. 발표자는 A tier를 대략 intelligence index 50 이상, state-of-the-art를 대략 56 이상인 구간으로 설명하지만, 이는 고정된 규칙이 아니라 거친 기준이다.
   3. 공개 벤치마크와 모델 스택은 계속 바뀌므로 자신의 워크로드 결과를 측정하면서 동적으로 비교해야 한다.

3. 기다리고 있는 모델

   1. 발표자는 DeepSeek V4 Pro가 state-of-the-art 영역에 들어갈지, 아니면 더 경제적인 Pro 모델이 될지 관심을 보인다.
   2. 또한 Qwen 3 계열의 약 30B 파라미터 모델과 12B·50B 가능성에 주목하며, 온디바이스나 B300 같은 노드에서 매우 빠르게 실행되기를 기대한다.
   3. 중요한 것은 특정 모델의 팬이 되는 것이 아니라 새 컴퓨트가 나올 때 팩토리에 배치할 선택지를 충분히 갖는 것이다.

4.3. 데모 결과의 비교

1. Default 결과

   1. 제목과 글쓰기 공간이 명확해지고, 기존의 산만한 핫키와 열린 사이드바가 정리됐다.
   2. 사이드바를 완전히 없애지 않고 편집·삭제·게시 기능과 전체 단어 수를 유지했다.

2. Deepest Seek 결과

   1. 사이드바와 우측 상단 메뉴를 유지하면서도 화면이 단순해졌다.
   2. 확대·축소가 가능하고 글쓰기 공간이 조용해져 “quiet room”이라는 요구사항을 잘 반영했다.
   3. 발표자는 상대적으로 매우 낮은 비용과 빠른 실행을 보면서 DeepSeek V4 Flash를 매일 쓰는 90% 업무용 A-tier workhorse로 평가한다.

3. Top Speed 결과

   1. 빠른 실행에도 충분히 좋은 글쓰기 뷰와 저장 확인 기능을 만들었다.
   2. 다만 Default나 Deepest Seek보다 화면이 조금 더 시끄럽고 요소가 남아 있었다.

4. Open Weights와 Frontier

   1. Open Weights는 JSON 출력 문제로 실패했으므로 결과 비교에서 제외됐다.
   2. Frontier는 촬영 중에도 계속 실행돼 지연시간과 비용을 확인할 수 있는 사례가 됐다.
   3. 결과가 모두 성공해야 하는 것이 아니라, 후보별 성공·실패·비용·품질을 함께 축적하는 것이 실험의 가치다.

5. 에이전틱 엔지니어링과 vibe coding의 차이

5.1. 에이전트에게 맡기되 생각을 외주화하지 않는다

1. 완전한 시스템을 소유한다

   1. 이 데모는 단일 에이전트, 단순한 서브에이전트 위임, 내부 동작을 알 수 없는 클라우드 코드 워크플로우가 아니다.
   2. 엔지니어가 소프트웨어 개발 생명주기를 템플릿화하고, 그 안에 AI를 추가하고, 팩토리로 감싼 시스템이다.
   3. 에이전트가 어떤 모델·코드·도구를 사용하고 어떤 게이트를 통과하는지 엔지니어가 설명할 수 있어야 한다.

2. 외부 AI 서비스에 사고를 맡기지 않는다

   1. 발표자는 엔지니어링을 AI 연구소·서드파티 리소스·보조 도구에 얼마나 넘기는지 주의하라고 말한다.
   2. 자동화된 결과를 받더라도 시스템에 대한 사고(thinking)는 직접 소유해야 한다.
   3. 핵심은 에이전트를 신뢰하지 않는 것이 아니라, 너무 잘 이해해 매번 들여다보지 않아도 되는 수준으로 시스템을 설계하는 것이다.

5.2. 두 작업 방식은 겉보기와 내부 사고가 다르다

1. Vibe coding

   1. 자신이 만든 시스템이 무엇을 하는지 모른 채 에이전트에게 코드를 맡기고 결과를 확인하지 않는 방식이다.
   2. 코드가 돌아가는 것처럼 보여도 백 번째·천 번째 실행에서 어떤 일이 일어날지 알 수 없다.

2. Agentic engineering

   1. 시스템이 무엇을 하는지 충분히 이해하므로 매번 직접 확인하지 않아도 되는 방식이다.
   2. 엔지니어는 한 번의 프롬프트가 아니라 시스템의 반복 실행, 관찰 가능성, 재사용성, 격리, 확장성을 생각한다.
   3. 에이전트가 개발자 장치를 가지고 인간보다 더 잘 수행하도록 만드는 것이 목표다.

3. 전문화가 제품의 경쟁력이다

   1. 경쟁 우위는 범용 에이전트를 그대로 사용하는 데서 나오지 않는다.
   2. 특정 제품·클라이언트·운영 환경에서 아주 잘 작동하는 전문화된 시스템을 만들고, 그 시스템의 토큰 경제성(tokonomics)과 결과 품질을 최적화하는 데서 나온다.
   3. Super Simple Software Factory는 이런 제품·클라이언트·프로덕션 워크로드용 팩토리를 만들기 위한 템플릿이다.

5.3. 인간이 들어가야 하는 예외와 빠져야 하는 구간

1. 루프 안에 있어야 하는 작업

   1. 에이전트 시스템을 만드는 작업, 즉 “시스템을 만드는 시스템(building the system that builds the system)”에는 인간의 전문성과 직접적인 프롬프트 상호작용이 필요하다.
   2. 새로운 애플리케이션 레이어를 설계하거나 안전 경계를 정의하는 초기 작업도 인간이 직접 수행해야 한다.

2. 루프 밖으로 위임해야 하는 작업

   1. 반복적인 플래닝·빌드·테스트·문서화, 다수의 변형 구현, 일반적인 지원 요청과 핫픽스는 에이전트 팀에게 넘길 수 있다.
   2. 인간은 시작 부분의 계획·요구사항·프롬프트와 마지막의 리뷰·검증에 등장하는 것이 이상적이다.
   3. 발표자는 에이전트가 애플리케이션 레이어를 직접 수정하도록 쓰는 경우가 대부분 낭비라고 강하게 말한다. 다만 시스템을 설계하고 새 시스템을 만드는 소수의 예외는 있다.

6. 직접 조작 가능한 샌드박스와 에이전트 액세스

6.1. Herder로 다섯 VM에 접속하기

1. 수동 관찰

   1. 발표자는 자신의 데모 프롬프트에서 셸 액세스를 요청하고, Herder에 다섯 개의 창(pane)을 띄운다.
   2. 각 창은 Default, Frontier, Open Weights, Top Speed, Deepest Seek 샌드박스 중 하나에 대응한다.
   3. SSH 액세스를 부팅해 모든 VM에 연결하고, 각 박스에서 상태와 로그를 확인한다.

2. 관찰 명령과 ADW 상태

   1. 상태(status)와 로그(log)를 조회해 “quiet room” 리디자인에서 정확히 어떤 변경이 만들어졌는지 확인한다.
   2. 각 팩토리는 ADW state, 즉 실제로 완료된 에이전트 작업을 읽고 변경 내용을 요약한다.
   3. 발표자의 핵심 원칙은 “측정하지 않으면 개선할 수 없다”이며, 박스에 들어갈 수 없으면 제대로 만지고 개선할 수도 없다는 것이다.

6.2. 샌드박스 내부 오케스트레이터와 상호작용하기

1. 두 번째 액세스 계층

   1. 단순히 VM의 셸만 여는 것에서 한 단계 더 나아가, 각 VM 내부에서 이미 실행을 마친 오케스트레이터 에이전트와 직접 대화한다.
   2. 이것은 박스 위에 대화형 클라우드 코딩 에이전트를 얹는 Workflow B에 해당한다.
   3. 바깥의 오케스트레이터가 동일한 작업을 다섯 안쪽 오케스트레이터에 전달하도록 자동화할 수도 있지만, 데모에서는 일부를 수동으로 실행한다.

2. 정책과 위험 경고

   1. 내부 에이전트에 연결할 때 정책(policy)과 dangerous mode 경고가 나타난다.
   2. 이는 에이전트가 샌드박스 안에서 높은 권한으로 작업하고 있음을 보여주며, 위험을 박스 내부로 제한하는 설계와 연결된다.
   3. 샌드박스라고 해서 무조건 안전하다고 가정하는 것이 아니라, 권한·키·포트·정책을 명시적으로 관리해야 한다.

3. 반복 작업의 자동화

   1. 각 박스에 “변경 내용을 bullet로 요약하라” 같은 요청을 보내 결과를 수집할 수 있다.
   2. 발표자는 이 작업을 손으로도 할 수 있지만, 같은 작업을 에이전트에게 맡기는 것이 자신의 전체 논지라고 설명한다.
   3. 접근 계층 자체도 에이전트가 사용할 수 있어야 에이전트의 속도로 시스템을 운영할 수 있다.

7. 보안·수명·비용 관리

7.1. 샌드박스는 임시이면서 필요하면 지속된다

1. 생성부터 폐기까지

   1. 오케스트레이터는 샌드박스를 호스팅하고 VM 안에서 실행 환경을 설치한 뒤 에이전트를 시작한다.
   2. 바깥 관찰 도구로 실행 상태와 애플리케이션을 확인한다.
   3. 작업이 끝나면 모든 샌드박스를 teardown한다. 필요할 때는 VM을 계속 유지할 수도 있다.

2. 두 가지 운영 방식

   1. 일회성 실험·여러 후보 비교에는 ephemeral sandbox로 생성하고 폐기한다.
   2. 반복적으로 사용하는 팩토리·프로덕션에 가까운 작업에는 내구성 있는 VM을 유지한다.
   3. exe.dev의 가치가 “24시간 뒤 자동 삭제되는 임시 컨테이너”가 아니라 원하는 수명으로 관리하는 개발자 장치라는 데 있다.

7.2. API 키와 예산 제한

1. OpenRouter provisioned key

   1. 데모의 pi 코딩 에이전트들은 OpenRouter에서 발급한 provisioned key를 사용한다.
   2. 이 키에는 50달러 한도를 설정했다.
   3. 샌드박스를 teardown할 때 키도 폐기해, 실험이 끝난 뒤 남은 자격 증명이 계속 비용을 발생시키거나 재사용되지 않도록 한다.

2. 비용 통제 원칙

   1. 모델을 여러 개 동시에 돌리는 Best of N은 비용을 크게 늘릴 수 있지만, 한 번의 실패나 잘못된 방향에 전체 시간을 쓰는 위험을 줄인다.
   2. state-of-the-art 모델이 정말 필요한지, workhorse 모델로 충분한지, 빠른 모델로 먼저 후보를 만들 수 있는지를 실제 작업 데이터로 판단한다.
   3. 모델별 토큰·시간·성공률·결과 품질을 관찰해야 “가장 비싼 모델=가장 좋은 시스템”이라는 착각을 피할 수 있다.

8. 최종 아키텍처와 확장 패턴

8.1. 논리적 구성

1. 전체 흐름

   1. 사용자가 하나의 프롬프트를 out-of-sandbox orchestrator에 전달한다.
   2. 바깥 오케스트레이터가 N개의 exe.dev 샌드박스를 만들고 각각의 in-sandbox orchestrator를 시작한다.
   3. 각 안쪽 오케스트레이터가 원하는 모델+코드 구성을 가진 소프트웨어 팩토리를 실행한다.
   4. 팩토리는 ADW 에이전트를 통해 계획·구현·테스트·리뷰·문서화하고 애플리케이션을 수정한다.
   5. 관찰 계층이 각 결과·비용·실패·상태를 모아 Best of N 선택에 사용한다.

2. 포트와 접근

   1. 실제 Inkwell 애플리케이션은 공개 포트로 제공할 수 있다.
   2. 소프트웨어 팩토리 뷰는 비공개 포트에 둘 수 있으며, exe.dev에 로그인해야 접근하도록 한다.
   3. 이 분리는 외부 사용자가 앱을 볼 수 있어도 팩토리의 제어 화면과 에이전트 권한은 노출하지 않도록 한다.

8.2. 제어권을 단순하게 유지하는 선택

1. 직접 연결 방식

   1. 필요하다면 바깥 오케스트레이터가 곧바로 ADW 소프트웨어 팩토리 시스템을 호출할 수 있다.
   2. 이 방식은 계층이 적고 단순하지만 안쪽 팩토리가 오케스트레이션까지 맡게 되어 제어권이 줄어든다.

2. 분리 방식

   1. 바깥 오케스트레이터는 샌드박스 생성과 작업 시작만 담당한다.
   2. 안쪽 오케스트레이터는 팩토리를 실행하는 역할만 담당한다.
   3. 계층을 더 두면 복잡성이 증가하지만 책임이 분리되고, 각 박스의 실행을 독립적으로 관찰·재시도·교체하기 쉬워진다.
   4. 발표자는 원칙적으로 단순함을 유지하되, 샌드박스 내부에 팩토리를 둘 때 얻는 제어권과 확장성이 그 추가 계층을 정당화한다고 설명한다.

8.3. Best of N을 넘어서는 적용처

1. 제품의 여러 미래 탐색

   1. 같은 요구사항을 여러 팩토리로 구현해 실제 사용자 경험의 후보들을 나란히 비교한다.
   2. 디자인 방향이 하나로 확정되지 않았을 때 대화만으로 토론하는 대신 여러 결과를 빠르게 보고 결정한다.

2. 운영 작업의 확장

   1. 새 기능의 계획·구현·테스트·문서화뿐 아니라 프로덕션 핫픽스와 지원 요청에도 적용한다.
   2. 한 팀의 엔지니어가 순차적으로 처리하던 작업을 여러 샌드박스에서 병렬 처리한다.
   3. 10배, 100배로 같은 문제를 던졌을 때 무엇을 발견하고 무엇을 만들 수 있는지 실험한다.

9. 발표자의 최종 메시지

9.1. 소프트웨어 팩토리가 중요한 이유

1. 에이전트와 코드의 결합

   1. 소프트웨어 팩토리는 비결정론적 에이전트와 결정론적 코드를 결합해 두 세계의 장점을 취한다.
   2. 에이전트가 계획·판단·생성을 담당하고, 코드·게이트·상태 머신이 반복성과 검증을 담당한다.

2. 소프트웨어 엔지니어링의 다음 형태

   1. 언젠가는 에이전틱 엔지니어링이 소프트웨어 엔지니어링이라고 불릴 만큼 에이전트가 개발 방식에 스며들 것이다.
   2. 지금은 전통적인 소프트웨어 엔지니어링과 구분해 시스템의 동작을 의식적으로 설계해야 한다.
   3. 프롬프트 한 번이나 터미널 에이전트 하나를 쓰는 수준을 넘어, 계획·빌드·테스트·리뷰·문서화가 묶인 개발자 워크플로우를 제품화해야 한다.

9.2. 에이전트 샌드박스가 중요한 이유

1. Isolation

   1. 에이전트를 애플리케이션과 인프라에서 분리해 잘못된 명령이 프로덕션을 망가뜨리지 않게 한다.
   2. AWS·GCP 등의 권한과 키를 박스 안에서 제한한다.

2. Scale

   1. 한 명의 바깥 오케스트레이터가 다섯 개 이상의 샌드박스를 동시에 띄우고, 각 샌드박스가 다시 여러 에이전트의 팩토리를 실행한다.
   2. Best of N은 여러 결과를 보고 미래의 후보를 선택하는 방법이며, 샌드박스는 이 병렬 컴퓨트를 제공한다.

3. Autonomy

   1. 에이전트에게 노트북의 일부가 아니라 개발자 장치 전체를 제공한다.
   2. 인간은 언제든 박스에 들어가 확인할 수 있지만, 매 단계에서 붙잡고 있지 않아도 에이전트가 일을 끝낼 수 있다.

9.3. 인간의 역할과 앞으로의 레버리지

1. 입력·실행·합성·출력

   1. 발표자는 엔지니어를 함수처럼 설명한다. 입력을 받고, 실행하고, 결과를 합성하고, 출력을 전달하는 역할이다.
   2. 컴퓨트가 풍부해지는 시대에는 이 함수의 실행을 혼자 순차적으로 수행하기보다, 좋은 입력과 판단 기준을 주고 많은 컴퓨트를 활용해야 한다.

2. 일과 삶의 선택

   1. 기술을 이용해 일을 더 빨리 끝내고 남은 시간에 실제 삶으로 돌아갈 수도 있다.
   2. 반대로 경쟁자보다 앞서기 위해 같은 시간에 더 많은 문제를 풀 수도 있다.
   3. 발표자는 생산성 극대화 자체가 목적이라고 주장하는 것이 아니라, 레버리지를 통해 선택권을 넓히는 것이 중요하다고 덧붙인다.

3. 레버리지의 다음 단계

   1. 이제 많은 사람이 터미널 에이전트·코워크 도구·클라우드 코딩을 사용하므로, 낮은 수준의 레버리지는 평준화되고 있다.
   2. 다음 수준은 초기 투자와 작업이 필요한 소프트웨어 팩토리, 하네스, 샌드박스, 관찰성 시스템을 구축하는 것이다.
   3. 발표자는 이 구조를 매주 공개해 고급 에이전틱 엔지니어링을 소수의 특권이 아니라 최대한 넓게 확산시키려 한다.

주요 발언 모음

“Scale your compute to scale your impact.”

“If you are inside the loop, you are always the bottleneck.”

“The agent sandbox is a developer device for your agents.”

“The blast radius is zero. The blast radius is the box.”

“Don’t outsource your thinking. Stay close to the engineering.”

“Vibe coding is not knowing what your system does and not looking. Agentic engineering is knowing what your system does so well you don’t have to look.”

“Combine compute. Don’t select compute.”

“Great agentic engineering is about showing up at the beginning and the end: the planning, the reviewing, the prompting, and the validating.”

“The next level of leverage is going to take work. It’s going to take upfront investment.”

“Stay focused and keep building.”

핵심 데이터 & 수치

• 약 37분 14초: 영상 전체 길이.
• 5개 샌드박스: Default, Frontier, Deepest Seek, Open Weights, Top Speed 구성을 각각 독립 VM에서 실행했다.
• 3계층 아키텍처: out-sandbox orchestrator, in-sandbox orchestrator, software factory/ADW agents로 분리했다.
• 약 13분: 고사고 수준(high thinking)의 Claude Opus 5가 계획 단계에서 사용한 시간으로 화면에 표시됐다.
• 약 14분: Top Speed 구성의 전체 실행 시간으로 화면에 표시됐다.
• 약 2 million tokens: Top Speed 실행에서 사용된 토큰 수로 화면에 표시됐다.
• 50달러 한도: OpenRouter provisioned key에 실험용 지출 제한을 설정했다.
• 3가지 모델 계층: state-of-the-art, workhorse, lightweight로 모델 스택을 나눴다.
• 3가지 샌드박스 가치: isolation, scale, autonomy다.
• Artificial Analysis 지수의 거친 기준: 발표자는 A tier를 약 50 이상, state-of-the-art를 약 56 이상으로 설명했지만 고정된 분류가 아니라고 했다.

핵심 요약 (20줄)

1. 소프트웨어 팩토리는 에이전트·코드·개발 생명주기를 결합한 시스템이며 단일 에이전트 호출과 다르다.

2. 에이전트를 개인 컴퓨터의 작은 구석이나 컨테이너에만 두면 격리는 얻지만 확장성과 자율성은 충분히 얻지 못한다.

3. 에이전트 샌드박스는 에이전트에게 자신만의 개발자 장치 전체를 제공한다.

4. 샌드박스의 핵심 이점은 진정한 격리, 컴퓨트 확장, 에이전트 자율성이다.

5. 영상의 구조는 바깥 오케스트레이터, 샌드박스 안 오케스트레이터, 소프트웨어 팩토리의 3계층이다.

6. exe.dev는 빠르고 안전하며 공유 가능하고 필요하면 계속 유지할 수 있는 VM 샌드박스로 소개된다.

7. 데모는 Inkwell 글쓰기 앱에 동일한 “quiet room” 리디자인 프롬프트를 다섯 팩토리로 보낸다.

8. 다섯 구성은 Default, Frontier, Deepest Seek, Open Weights, Top Speed이며 각각 독립 VM을 소유한다.

9. Best of N은 여러 모델·하네스·코드 조합을 실행해 최선의 결과와 미래를 선택하는 패턴이다.

10. 팩토리는 계획, 빌드, 테스트, 리뷰, 문서화까지 소프트웨어 개발 생명주기를 수행한다.

11. 결정론적 게이트는 JSON 오류 같은 문제를 검출해 비결정론적 에이전트의 실행을 제어한다.

12. Open Weights가 JSON 출력 오류로 실패해도 다른 후보가 계속 실행되므로 전체 실험은 유효하다.

13. DeepSeek V4 Flash 0731은 저렴하고 빠른 일상용 workhorse 모델로 강조된다.

14. 모델 선택은 성능·비용·속도의 균형이며 단일 최강 모델보다 모델 스택이 중요하다.

15. 에이전틱 엔지니어링은 시스템을 이해한 채 자동화하는 것이고 vibe coding은 시스템을 모른 채 맡기는 것이다.

16. 커스텀 하네스와 관찰성 없이는 에이전트와 코드에 대한 완전한 제어를 확보하기 어렵다.

17. OpenRouter provisioned key에 50달러 제한을 걸고 샌드박스 폐기 시 키를 제거해 비용과 권한을 관리한다.

18. 인간은 계획·프롬프트·리뷰·검증에 나타나고 반복 작업은 에이전트 팀에게 위임해야 한다.

19. 샌드박스 안의 팩토리는 여러 제품 방향, 핫픽스, 지원 요청을 병렬로 실행하는 기반이 된다.

20. 다음 레버리지는 프롬프트 하나가 아니라 전문화된 팩토리·하네스·샌드박스·관찰성에 대한 선행 투자에서 나온다.

결론 및 실행 포인트

1. 작업을 단일 에이전트 호출로 정의하지 않는다. 요구사항을 계획·구현·테스트·리뷰·문서화로 쪼개고 각 단계에 에이전트와 결정론적 코드를 배치한다.
2. 작은 실험용 샌드박스부터 만든다. 애플리케이션, 팩토리, 로그, 상태를 하나의 VM에 넣고 SSH·포트·정책을 제한한다.
3. 한 가지 모델에 종속되지 않는다. state-of-the-art·workhorse·lightweight 계층을 만들고 성능·비용·속도를 실제 작업별로 기록한다.
4. Best of N을 적용한다. 동일한 프롬프트를 여러 모델+하네스 구성에 보내고 결과 품질·실패율·토큰·지연시간을 비교한다.
5. 실패를 시스템 데이터로 남긴다. JSON 게이트, 테스트, 상태, 로그를 통해 실패 원인을 파악하고 후보 전체가 아닌 실패한 구성만 재시도한다.
6. 관찰 가능성을 먼저 만든다. 에이전트가 무엇을 했는지, 어떤 파일을 바꿨는지, 어떤 모델과 도구를 썼는지 언제든 확인할 수 있어야 한다.
7. 권한과 비용을 박스 단위로 관리한다. 제한된 provisioned key를 사용하고 작업 종료 후 키와 VM을 폐기한다.
8. 인간을 시작과 끝에 배치한다. 새 시스템을 설계할 때는 직접 루프에 들어가되, 반복적인 애플리케이션 작업은 팩토리에 맡긴다.
9. 전문화된 시스템을 경쟁력으로 삼는다. 범용 에이전트를 그대로 쓰는 대신 자신의 제품과 워크플로우에 맞춘 하네스를 만든다.
10. 단계적으로 확장한다. 한 박스의 팩토리에서 시작해 여러 박스의 Best of N으로 확장하고, 결과가 입증될 때만 복잡한 오케스트레이션을 추가한다.