Grok Bot 같은 상시 작동 에이전트의 구조와 작동 원리

• 원문 제목: [한영자막] Grok Bot 같은 상시 작동 에이전트는 어떻게 작동할까요? | SpaceX 엔지니어 Lee Robinson의 스탠퍼드 강연
• 원문 URL: https://www.youtube.com/watch?v=N8gD8ebFlMI
• 공개 강연 원문 참고 URL: https://www.youtube.com/watch?v=L1OBRtfPS34
• 날짜: 2026-10-13
• 채널: Tech Bridge
• 발표: Lee Robinson, SpaceX AI 팀
• 영상 길이: 45분 18초
• 주제: AI 에이전트, agent harness, persistent agent, context engineering, distributed systems

---

📌 핵심 질문 / 상시 작동 에이전트를 가능하게 만드는 핵심 논점

==상시 작동 에이전트(always-on agent)는 모델 하나가 아니라, 장기 실행을 견디는 워크플로·서버·클라우드 컴퓨터·메모리·도구·보안·평가 시스템의 결합으로 만들어진다.==

• 모델은 도구를 호출하는 반복 루프를 통해 단순한 채팅을 넘어 실제 업무를 수행한다.
• 서버와 영속 워크플로(durable workflow)가 에이전트의 실행 상태를 보존하므로 사용자가 컴퓨터를 닫거나 장애가 발생해도 작업을 재개할 수 있다.
• 클라우드의 Linux 컴퓨터, 브라우저, 파일, 스킬(skill), 루틴(routine)이 에이전트에게 사람처럼 일할 수 있는 작업 환경을 제공한다.
• 동적 도구 탐색(dynamic tool discovery), 서브에이전트(sub-agent), 압축(compaction), 프롬프트 캐싱(prompt caching)이 제한된 context window를 장기 작업에 맞게 확장한다.
• 신뢰할 수 있는 에이전트는 모든 이벤트에 답하지 않고 중요할 때만 알리며, 되돌릴 수 없는 작업과 외부 입력에는 별도의 안전장치를 적용한다.

터미널에서 사용자가 메시지를 보낼 때마다 반응하는 단기 harness는 강력하지만 노트북을 닫으면 실행이 멈춘다. 상시 작동 에이전트는 실행 위치를 서버와 클라우드로 옮기고, 자체 컴퓨터와 영속 상태를 부여하며, Slack 메시지·이메일·회의·예약된 루틴 같은 사건을 입력으로 받아 며칠·몇 주·몇 달 동안 동료처럼 일하는 방향으로 harness를 확장한다.

1. 개발자와 AI의 네 시대

1.1. 복사·붙여넣기에서 도구 호출로

1. ChatGPT 코드 복사 단계

   1. 개발자는 ChatGPT가 작성한 코드를 복사해 자신이 선택한 편집기에 붙여 넣었다.
   2. 불과 몇 년 전의 방식이지만 현재 관점에서는 수십 년 전처럼 느껴질 만큼 빠르게 낡았다.

2. 터미널 harness 단계

   1. 모델이 파일 편집과 shell command 실행을 수행할 수 있게 되면서 사용자는 터미널에서 모델과 협업하기 시작했다.
   2. 모델이 질문에 답하는 데서 벗어나 파일을 고치고 명령을 실행하며 더 적극적인 작업을 맡을 수 있게 됐다.

1.2. 여러 에이전트와 상시 작동 에이전트

1. 전용 앱과 병렬 에이전트 단계

   1. 코딩 에이전트는 전용 애플리케이션으로 발전했고, 여러 에이전트를 동시에 실행하거나 클라우드에서 실행하는 방식이 등장했다.
   2. 사용자는 여전히 에이전트가 실행하는 모든 shell command를 검토하고 승인해야 했으므로 사람 자신이 병목이었다.

2. 상시 작동 단계

   1. 모델·harness·제품의 개선으로 에이전트는 사용자가 자리를 비운 동안에도 자신의 컴퓨터와 메모리를 사용해 백그라운드에서 일할 수 있게 됐다.
   2. 사용자는 에이전트에 매일 프롬프트를 넣는 대신 “이 스레드를 확인해”라고 지시하고, 이어서 “목요일에 실행해”라고 덧붙일 수 있다.
   3. 최신 모델은 즉시 이어지는 두 지시가 서로 관련된다는 점을 파악한다. 과거 모델은 두 번째 지시가 첫 번째 지시를 덮어쓰는 상황에서 쉽게 혼란스러워했다.
   4. 사람이 수백 개의 명령을 지켜보며 피로해지는 것보다 별도의 AI가 실행 명령을 점검하는 autoreview가 더 안전할 수 있다. 명령의 의도와 위험을 일관되게 확인하기 때문이다.

1.3. 문자 메시지처럼 단순해진 인터페이스

1. 친구에게 문자를 보내는 사용감

   1. 대부분의 사람은 문자 메시지를 보내는 방법을 이미 알고 있으므로 복잡한 AI 작업 환경보다 채팅형 인터페이스에 쉽게 적응한다.
   2. 봇은 Q&A 답변만 하는 것이 아니라 동료에게 넘길 법한 긴 작업을 수행한다.

2. 봇이라는 제품 형태

   1. 상시 작동 에이전트는 항상 응답하는 챗봇이 아니라 필요한 때 조용히 있고 중요한 업데이트가 생겼을 때 돌아오는 디지털 동료다.
   2. 인터페이스가 단순해진 것은 기능이 줄어서가 아니라 모델과 harness가 내부 복잡성을 떠안았기 때문이다.

2. 모델의 능력 변화가 만든 기반

2.1. 장기 작업과 협업 능력

1. 긴 지시를 따르는 능력

   1. 최근 1~2년 동안 모델은 긴 시간 동안 지시를 유지하며 실수나 혼란을 덜 일으키게 됐다.
   2. 적절한 압축과 보존을 적용하면 모델이 몇 시간 또는 며칠 동안 계속 실행될 수 있다.

2. 서브에이전트로의 위임

   1. 주 에이전트의 working memory는 결국 가득 차므로, 모델은 새 working memory를 가진 서브에이전트에게 작업을 넘길 수 있다.
   2. 서브에이전트가 토큰과 도구를 많이 소비하는 작업을 수행한 뒤 결과만 보고하면 주 에이전트는 사실상 무한한 context를 가진 것처럼 작동한다.

2.2. 강력한 도구와 컴퓨터 사용

1. 도구 호출의 안정화

   1. 초기 모델은 도구를 잘 호출하지 못하고 자주 hallucination을 일으켰지만, 도구 호출 자체는 이제 대부분 해결된 문제에 가까워졌다.
   2. shell command와 파일뿐 아니라 완전한 Linux 컴퓨터, 화면 클릭, 데모 영상 제작까지 도구로 제공할 수 있다.

2. Computer use와 API 바깥의 세계

   1. 모델은 사람처럼 화면을 클릭하는 computer use를 통해 API나 MCP server를 제공하지 않는 SaaS와 웹사이트도 headless하게 사용할 수 있다.
   2. 정보는 파일에 저장할 수 있고, 모델은 Linux command로 파일을 검색하는 데 능숙하므로 과거 기록을 다시 찾을 수 있다.

3. 작업을 재사용 가능한 지식으로 변환

   1. 사용자가 특정 작업을 수행하는 방법을 보여주면 에이전트는 그것을 skill, memory, routine으로 저장해 다음 작업에 재사용할 수 있다.
   2. 스킬은 성공·실패를 가르는 구체적 절차를 Markdown 파일에 인코딩한 것이다.
   3. Grok Bot의 plugin 시스템은 도구를 설치할 수 있게 하고, 각 plugin은 skill이나 server를 제공한다.
   4. routine은 cron job과 비슷하게 특정 프롬프트를 일정에 따라 실행한다.

2.3. 사용자 프로필과 작업 로그

1. 항상 포함되는 사용자 프로필

   1. 사용자가 소문자 메시지를 선호한다면 그 사실을 프로필에 기록하고 모든 프롬프트에 포함할 수 있다.
   2. 이 규칙을 잊으면 같은 동료가 갑자기 대문자를 쓰는 것처럼 일관성이 깨진다.

2. 시간에 따른 작업 기록

   1. 에이전트는 동료가 매일 업무 노트를 쓰듯 작업 로그를 파일에 누적한다.
   2. “지난주에 내가 무엇을 했지?”라는 질문이 오면 shell command로 로그를 검색해 답할 수 있다.

3. 상시 작동 에이전트의 생명주기

3.1. 잠듦·기상·작업·절전

1. 초기 상태

   1. 서버와 에이전트가 사용할 컴퓨터는 평소 잠든 상태일 수 있다.
   2. 사용자의 메시지나 다른 trigger가 들어오면 서버가 에이전트 상태를 불러오고 실행을 시작한다.

2. 컴퓨터의 기동

   1. 브라우저를 열거나 화면을 클릭해야 할 때 에이전트는 자신에게 할당된 컴퓨터도 시작한다.
   2. 작업이 끝나면 서버와 컴퓨터를 다시 절전 상태로 만들 수 있다.

3. 상태의 영속화

   1. 서버에는 대화 로그, memory, routine 같은 상태가 저장된다.
   2. 모든 사람에게 컴퓨터와 서버를 계속 켜 두면 비용과 자원 부족이 발생하므로, 필요할 때 깨우고 상태를 저장하는 구조가 효율적이다.

3.2. 입력 trigger와 알림 판단

1. 다양한 입력원

   1. 사용자가 직접 보낸 메시지가 에이전트를 깨울 수 있다.
   2. Slack의 mention, 이메일, 전화나 회의, 예약된 routine, 오래 걸린 백그라운드 작업의 완료가 모두 trigger가 될 수 있다.
   3. SpaceX에서는 회의에 참석하지 못한 직원을 대신해 봇이 회의에 들어가 메모를 작성하고 결과를 돌려주는 사례가 늘고 있다.

2. 라우터와 조용함의 heuristic

   1. 여러 입력은 router가 중복 제거(deduplication)하고 하나의 대화 흐름에 배치한다.
   2. 에이전트는 모든 진행 상황을 알리지 않고 사용자를 깨워야 할 만큼 중요한지 판단한다.
   3. 동료가 작업할 때 작은 진전마다 찾아오면 성가신 것처럼, 작업에 따라 하루 한 번 정도의 상태 보고만 필요한 경우가 있다.

3. 장기 실행의 목표

   1. 상시 작동 에이전트는 몇 시간이나 며칠이 아니라 몇 주 또는 몇 달 동안 작업하는 것을 목표로 한다.
   2. 이 시간 규모를 감당하려면 단순한 채팅 루프를 영속 워크플로, 메모리, 압축, 장애 복구와 결합해야 한다.

4. 에이전트의 클라우드 컴퓨터와 서버 구조

4.1. Firecracker VM과 독립 작업 공간

1. 가상 컴퓨터

   1. 에이전트의 Linux machine은 Firecracker virtual machine 위에서 실행된다.
   2. Firecracker는 기계 상태를 snapshot으로 저장하고 빠르게 종료·재기동하기 쉽다.

2. 사람의 컴퓨터와 분리된 환경

   1. 에이전트는 개인 노트북이 아니라 자신의 desktop, files, browser, 필요하다면 3D application을 가진다.
   2. 작업 파일과 shell command를 별도 환경에서 실행하면 개인 컴퓨터를 오염시키지 않고 보안 경계를 만들 수 있다.

3. 여러 에이전트의 병렬 실행

   1. 각 봇에 서로 다른 virtual desktop을 제공하면 5개 또는 10개의 봇이 각자 브라우저를 사용할 수 있다.
   2. 컴퓨터 자원은 공용 인프라로 관리하되, 각 봇의 화면·파일·실행 상태는 분리한다.

4.2. 얇은 클라이언트와 두꺼운 서버

1. 서버에 agent loop를 둔 이유

   1. 클라이언트에 업데이트를 배포하려고 매번 app store 업데이트를 기다리는 대신 서버 코드만 빠르게 교체할 수 있다.
   2. transcription이나 image generation처럼 무거운 계산은 기기보다 서버에서 처리하는 편이 빠를 수 있다.
   3. 서버는 변동하는 트래픽과 성장에 맞게 확장하는 검증된 방법을 갖고 있다.

2. VM과 agent server의 분리

   1. agent loop를 VM 안에 넣으면 VM을 독립적으로 끄거나 교체할 수 없다.
   2. 서버에 agent 상태를 보관하면 VM에서 critical zero-day Linux update가 발생했을 때 VM만 재구축하고 전체 에이전트 루프의 중단은 피할 수 있다.

3. 클라이언트가 제공하는 표현 계층

   1. 모바일 앱, 데스크톱 앱, 이메일, Slack 등 어떤 클라이언트도 서버와 통신하는 공통 경로를 사용한다.
   2. 클라이언트는 같은 서버 결과를 사용자에게 맞는 rich UI로 표현한다.
   3. 로그인 요청이면 sign-in form과 1Password 연동을 보여주고, 결제라면 Stripe Link·X Money 같은 서비스를 연결할 수 있다.
   4. 이메일이나 Slack 전송처럼 되돌릴 수 없는 작업이면 초안을 보여주고 사용자의 수정·승인을 기다린다.
   5. 실제 메시지를 보낼 필요가 없으면 사용자는 emoji reaction만 남길 수도 있다.

4.3. 메시지 전달과 분산 시스템

1. 단일 클라이언트 도구

   1. Grok Bot의 thin client는 send user라는 하나의 도구로 서버와 통신한다.
   2. shell command, file access, cloud agent 호출, 화면 녹화, demo 제작 같은 무거운 도구는 서버에 둔다.
   3. 클라이언트가 모바일이든 데스크톱이든 Slack이든 동일한 경로로 서버를 사용할 수 있다.

2. 확인 응답과 구독

   1. 사용자가 send를 누르면 클라이언트는 메시지를 즉시 인식하고 acknowledge해야 한다.
   2. agent turn 동안 모델 호출과 tool call 결과를 database에 저장하고, 클라이언트는 서버의 변경 신호를 subscription으로 감시한다.
   3. 신호가 오면 클라이언트가 최신 정보를 가져오며, retry로 동일 메시지가 여러 번 나타나지 않도록 deduplication을 적용한다.

3. Job queue와 durable workflow의 차이

   1. 일반 job queue에서 1·2·3단계 작업 중 인프라 장애가 생기면 재시작 때 1·2·3단계를 모두 replay해야 할 수 있다.
   2. durable workflow는 실패 후 재시작할 때 완료된 단계를 건너뛰고 3단계부터 이어간다.
   3. Temporal 같은 open-source workflow 도구를 사용하면 이 복잡한 분산 시스템 기능을 처음부터 다시 만들지 않아도 된다.

4. 우선순위와 batching

   1. 개인이 직접 보낸 메시지는 group chat·Slack thread·background routine보다 높은 우선순위를 가진다.
   2. 사용자가 “이벤트 날짜를 바꿔”라고 말하면 진행 중인 다른 작업을 멈추고 새 요청을 먼저 처리한다.
   3. 짧은 시간에 들어온 메시지 3~4개는 하나의 turn으로 batch 처리해 불필요한 모델 호출을 줄일 수 있다.

5. Harness 설계와 도구 선택

5.1. 동적 context와 도구 탐색

1. 모든 도구를 한꺼번에 넣는 문제

   1. context window는 모델의 working memory이며 token 수에 제한이 있다.
   2. 각 도구에는 이름·schema·세부 설명이 있으므로 Google Drive, Gmail, YouTube 등 MCP connector를 모두 넣으면 도구 설명만으로 context가 가득 찬다.
   3. 도구 설명이 차지한 공간은 모델이 실제 대화와 작업에 사용할 공간을 줄인다.

2. Dynamic context / tool search tool

   1. 매 요청에는 도구 이름만 노출하고, 모델이 실제로 사용하려는 도구의 상세 정보를 파일이나 검색 도구를 통해 가져오게 한다.
   2. 필요한 순간에 필요한 설명만 로드하면 context 사용량·비용·모델의 작업 공간을 절약할 수 있다.
   3. 파일 시스템을 통해 도구 정의를 탐색하는 방식은 모델이 Linux 파일을 검색하는 능력과 잘 맞는다.

3. 도구 선택의 사다리

   1. 가장 먼저 현재 대화에 이미 있는 정보와 모델이 알고 있는 내용을 사용한다.
   2. 다음으로 plugin·MCP server·API를 호출한다. 예를 들어 Plaid에서 은행 정보를 가져올 수 있다.
   3. API가 없으면 web search를 사용한다. Cubs 경기 결과를 확인하는 작업이 그 예다.
   4. 검색만으로 부족하면 브라우저를 열어 사이트를 조작한다.
   5. 마지막으로 Linux desktop에서 script·command·build를 실행한다.
   6. 이 모든 방법이 실패할 때만 사용자에게 추가 정보나 승인을 요청한다.

5.2. 브라우저와 컴퓨터 사용의 정보 계층

1. 저비용 정보 접근

   1. 화면 전체 screenshot보다 HTML을 읽는 편이 효율적일 수 있다.
   2. HTML보다 accessibility tree를 사용하면 버튼·링크·입력 요소를 적은 token으로 찾을 수 있다.

2. 예외 상황 처리

   1. modal이나 dialog처럼 구조화된 정보로 접근하기 어려운 요소는 pixel click이 필요할 수 있다.
   2. 2FA code·CAPTCHA처럼 모델이 처리하면 안 되거나 처리할 수 없는 단계에서는 사용자에게 돌아간다.

5.3. 주 에이전트와 서브에이전트

1. 주 에이전트의 역할

   1. 주 에이전트는 사용자와의 대화를 간결하게 유지하는 orchestrator다.
   2. 직접 모든 shell command와 도구 결과를 대화에 쌓지 않고, 작업을 helper에게 위임한다.

2. 서브에이전트의 역할

   1. 각 helper는 독립된 skill을 가진 durable workflow로 동작한다.
   2. 영상 처리·대규모 파일 작업·많은 도구 호출처럼 비용이 큰 일을 수행한 뒤 요약된 결과만 주 에이전트에 돌려준다.
   3. helper가 memory를 많이 사용하거나 crash해도 workflow가 진행 상황을 보존한 채 재시작할 수 있다.

3. 팀 확장 모델

   1. 주 에이전트는 동료 팀의 manager처럼 to-do list를 관리한다.
   2. 사용자는 helper의 상태를 확인하고 메시지를 보내거나 중지할 수 있다.
   3. 복잡한 엔지니어링 문제를 여러 전문 팀원이 나눠 처리하는 방식이 agent harness 안에서 재현된다.

5.4. Harness를 개선하는 작은 선택

1. 도구 정의의 크기와 안정성

   1. 한 turn 중간에 도구를 추가하거나 제거하면 context와 prompt cache가 흔들릴 수 있으므로 도구 목록을 안정적으로 유지한다.
   2. 지나치게 긴 tool schema는 token·비용·작업 공간을 낭비하므로 최소화한다.

2. 범용 도구와 전용 도구

   1. 한 도구가 shell command 하나로 무엇이든 할 수 있다는 설계는 많은 기능을 표현할 수 있다.
   2. 모델이 특정 작업의 90%를 shell command로 처리한다면 전용 도구로 분리하는 편이 더 효율적이고, 사람이 제품 동작을 검토하기도 쉽다.

3. 에이전트를 위한 오류 메시지

   1. 사람에게 유용한 오류 메시지는 실패 원인과 다음 행동을 구체적으로 알려준다.
   2. 에이전트도 같은 정보를 활용하므로 “링크를 클릭하라” 또는 “다음에 무엇을 하라” 같은 상세한 오류가 복구 능력을 높인다.

6. 보안과 신뢰

6.1. 실행 명령과 외부 입력

1. Autoreview

   1. 에이전트가 별도의 Linux machine에서 실행되더라도 shell command를 실행하기 전에 다른 모델이 검토하도록 할 수 있다.
   2. 장기 실행을 맡기려면 사용자의 정보와 실행 환경을 안전하게 다룬다는 신뢰가 필요하다.

2. Prompt injection 방어

   1. 이메일 본문이나 webhook payload는 공격자가 만든 untrusted input일 수 있다.
   2. 이를 사용자의 직접 지시처럼 모델에 전달하면 prompt injection으로 에이전트가 공격자의 목표를 수행할 수 있다.
   3. 외부 입력과 사용자 지시를 구분하고, 실행 전에 의미와 권한을 검증해야 한다.

3. 되돌릴 수 없는 작업

   1. 이메일·Slack 메시지 전송처럼 취소하기 어려운 작업은 사용자에게 먼저 승인받는다.
   2. 비밀번호와 민감 정보는 모델 대화에 그대로 넣지 않고 제품의 별도 보안 흐름에 보관한다.

6.2. 격리만으로 충분하지 않은 이유

1. 환경 분리의 장점

   1. 에이전트 전용 VM은 개인 노트북의 파일과 실행 환경을 직접 오염시키지 않는다.
   2. VM snapshot과 재구축은 장애 복구와 보안 패치에 유리하다.

2. 남는 위험

   1. 에이전트가 접근할 수 있는 서비스와 계정이 많아질수록 prompt injection·권한 오용·외부 데이터 유출 위험도 커진다.
   2. 따라서 sandbox, identity, approval, secret isolation, observability를 harness의 기본 구성 요소로 다뤄야 한다.

7. Context engineering과 장기 기억

7.1. Prompt caching

1. 캐시가 중요한 이유

   1. 긴 대화에서 새 메시지 하나를 추가할 때 전체 대화를 다시 모델에 보내는 경우가 많다.
   2. 대부분의 token이 이미 본문에 있으므로 cached token으로 처리되면 비용이 크게 낮아진다.

2. 정적인 prefix 유지

   1. system prompt, tool definition, 고정된 지시를 호출 사이에 가능한 한 동일하게 유지해야 prompt cache가 깨지지 않는다.
   2. 고정된 부분을 앞에 두고 마지막에 새 메시지라는 delta만 붙이면 uncached token 비용을 줄일 수 있다.
   3. A/B test나 새 도구를 추가할 때 prompt section을 hash하고 순서를 일정하게 유지하면 다른 사용자까지 cache miss를 겪는 일을 줄일 수 있다.

3. Cache warm-up

   1. 사용자가 채팅창을 열어 타이핑하는 동안 서버가 다음 prompt를 미리 준비할 수 있다.
   2. 웹사이트에서 링크에 hover할 때 다음 페이지를 prefetch하는 것과 같은 방식으로 cache를 데운다.
   3. 장기 실행 에이전트에서는 이런 작은 최적화가 누적되어 token 효율과 지능을 좌우한다.

7.2. 출력 분리와 대화 정원 관리

1. 긴 출력의 파일화

   1. 긴 command 결과를 context에 그대로 넣는 대신 파일에 저장한다.
   2. 모델은 필요할 때 파일을 읽어 오므로 주 대화의 크기를 유지할 수 있다.

2. 비싼 작업의 위임

   1. screenshot 분석이나 기타 큰 출력을 만드는 작업은 helper에게 위임한다.
   2. 주 에이전트에는 결과만 돌아오므로 원본 데이터가 main context를 부풀리지 않는다.

3. Context gardening

   1. 작업 중 불필요한 정보를 계속 정리·삭제·요약한다.
   2. 이는 비용뿐 아니라 recall과 모델 성능을 위해서도 필요하다.
   3. cache miss는 단순한 비용 증가가 아니라 harness 설계상의 버그로 볼 수 있다.

7.3. Compaction과 기억의 네 층

1. 압축의 불가피성

   1. 200,000 token context window를 가진 모델도 대화가 계속되면 한계에 도달한다.
   2. 모든 compression은 정보를 잃는 lossy process이므로 무엇을 보존할지 결정하는 알고리즘이 중요하다.
   3. cache가 10분 또는 60분 동안 따뜻하게 유지된다면 사용자가 돌아오기 전에 compaction을 수행하는 편이 싸다.
   4. 미리 만든 요약에서 대화를 재개하면 다음 메시지부터 더 적은 비용으로 작업할 수 있다.

2. 핵심 사용자 사실

   1. 말투·형식·지속적으로 적용되는 선호처럼 매번 필요한 사실은 모든 prompt에 포함한다.
   2. 중요도가 낮아진 사실은 garbage collection하듯 제거할 수 있다.

3. 날짜가 있는 로그

   1. 과거 대화와 업무 기록은 dated log로 저장한다.
   2. 현재 prompt에 넣지 않아도 모델이 파일 검색으로 필요할 때 다시 찾을 수 있다.

4. 임시 scratchpad

   1. 지금 진행 중인 작업의 작은 메모는 다음 30분이나 1시간에만 필요한 ephemeral scratchpad에 둔다.
   2. 작업이 끝나면 scratchpad는 사라져 오래된 정보가 현재 context를 오염시키지 않는다.

5. 파일 기반 장기 기억

   1. 즉시 필요한 사실·최근 기록·임시 메모를 제외한 정보는 파일에 저장한다.
   2. 모델이 Linux command로 파일을 검색할 수 있다는 점이 사실상 무한한 외부 기억을 제공한다.
   3. 사람의 뇌가 현재 대화와 관련된 정보만 의식에 유지하고 나머지는 기억에서 꺼내 오는 방식과 비슷한 구조다.

8. 모델·제품·평가의 선순환

8.1. 모델 학습의 세 단계

1. Pre-training

   1. 대규모 인터넷 텍스트와 사내 데이터에서 세계에 대한 일반적 이해를 학습한다.

2. Supervised fine-tuning(SFT)

   1. 대화 도우미나 에이전트처럼 특정 방식으로 행동하도록 가르친다.
   2. harness의 예시와 사용 가능한 도구를 보여주면 모델이 해당 환경에서 일하는 법을 익힐 수 있다.

3. Reinforcement learning(RL)

   1. 게임을 플레이하며 실력을 높이는 것처럼 지시를 잘 따르고 올바른 행동을 선택하도록 학습한다.
   2. 수백 개의 skill 중 적절한 skill을 선택하거나 브라우저에서 정확한 위치를 클릭하는 능력도 RL의 대상이 된다.

8.2. 주 에이전트와 helper의 추론 최적화

1. 주 에이전트

   1. 사용자와 대화하는 주 에이전트는 낮은 latency와 빠른 응답이 중요하다.
   2. harness와 inference를 빠른 답변에 맞게 조정한다.

2. Helper

   1. 며칠 동안 작업하는 helper는 10분과 12분의 차이가 상대적으로 작다.
   2. 따라서 helper는 속도보다 장기 안정성·도구 사용·메모리·복구에 더 많은 계산을 배정할 수 있다.

8.3. Inner loop와 outer loop

1. 제품 팀의 inner loop

   1. 에이전트가 잘못된 도구를 호출하면 그 실패를 evaluation으로 만든다.
   2. harness·bug·prompt·inference 중 원인을 고치고, eval에서 실제로 개선됐는지 확인한 뒤 제품에 배포한다.
   3. 팀은 매일 실패를 발견하고 수정하며 중요한 행동의 점수를 높인다.

2. 모델 팀의 outer loop

   1. 몇 달 주기로 새로운 모델을 학습해 제품의 실패와 bug에서 배운다.
   2. 새 모델을 제품에 넣고 기존 eval에서 능력이 상승했는지 측정한다.

3. 새로운 행동 양식

   1. 그룹 채팅에서 여러 봇이 서로 대화하는 방식은 과거에 학습 데이터가 거의 없던 emergent behavior다.
   2. Moltbook이나 Hugging Face incident 같은 사례는 multi-agent 상호작용이 잘못될 수 있음을 보여준다.
   3. 서로 다른 봇이 대화하는 상황에서 언제 말하고 언제 침묵할지까지 모델에 학습시켜야 한다.

9. 제품을 지우고 다음 모델을 설계하기

9.1. “Delete the product” 원칙

1. 현재 모델이 최악이라는 가정

   1. 오늘의 모델은 앞으로 등장할 모델보다 항상 부족하다고 가정해야 한다.
   2. 6개월 뒤에는 모델 능력에 맞춰 UI 전체를 다시 만들어야 할 수 있다.

2. 기능보다 단순한 인터페이스

   1. 모델이 스스로 생각하고 행동할 수 있다면 제품이 모든 흐름을 복잡한 UI로 고정할 필요가 없다.
   2. 최소한의 인터페이스와 강력한 harness로 다음 세대 모델의 능력을 받아들이는 편이 낫다.

9.2. 향후 6~12개월의 변화

1. 작업 시간의 연장

   1. 현재 에이전트가 몇 시간 또는 하루 일한다면 곧 몇 주 또는 몇 달 일하게 될 가능성이 높다.
   2. 장기 실행 모델의 학습·평가·메모리·보안이 새로운 연구 과제가 된다.

2. 기억의 발전

   1. 모델은 과거 대화의 정보를 더 잘 회수하게 될 것이다.
   2. 내부 표현은 graph, files 또는 다른 형태가 될 수 있으며 어떤 알고리즘이 가장 좋은지는 아직 열려 있다.

3. 사람에게 제공되는 모든 도구

   1. 디지털 동료에게 실제 사람을 온보딩할 때 제공하는 도구를 모두 제공하는 방향으로 갈 수 있다.
   2. 조직이 자체 업무 절차를 명시적으로 문서화하면 에이전트가 bespoke process를 읽고 실행하기 쉬워진다.

4. 대화 방식의 다양화

   1. 일부 사용자는 text 대신 speech-to-speech로 봇과 계속 대화할 수 있다.
   2. 하루 종일 말할 수 있는 개인 장치가 등장하면 에이전트의 인터페이스는 더 단순해질 수 있다.

5. 토큰 경제성

   1. 1년 뒤에는 세계에서 처리되는 token 양이 크게 늘어날 가능성이 높다.
   2. inference·모델·harness를 최적화해 token 사용량을 낮추는 일이 중요해진다.

9.3. 풀어야 할 문제

1. 장기 실행 모델의 평가

   1. 한 달 동안 실행되는 에이전트를 평가하려는데 모델이 매달 새 버전으로 바뀌면 동일한 행동을 끝까지 검증하기 어렵다.
   2. 더 나은 eval을 만들거나 모델 배포 속도를 늦추는 선택이 필요할 수 있다.

2. 메모리 알고리즘

   1. 어떤 사실을 영구 보존하고 어떤 내용을 삭제할지 결정하는 알고리즘은 여전히 발전 중이다.
   2. graph·file·기타 표현 중 어느 것이 장기 기억에 적합한지 비교해야 한다.

3. 보안 인프라

   1. harness와 그 주변 인프라가 공격자에게 점령되지 않도록 sandbox·identity·secret·권한을 설계해야 한다.
   2. 상시 작동과 광범위한 도구 권한은 편리함과 공격 표면을 동시에 키운다.

4. 침묵과 선제성의 균형

   1. 에이전트가 “어제 수업을 빠졌기에 녹화본을 확인하고 노트를 만들어 두었다”고 알려주는 것은 유용할 수도 있고 간섭처럼 느껴질 수도 있다.
   2. 언제 먼저 제안하고 언제 조용히 있어야 하는지에 대한 heuristic은 아직 완성되지 않았다.

9.4. 에이전트가 새로운 소프트웨어 기본 요소가 되는 이유

1. 모든 앱의 agentic layer

   1. 2005년의 앱이 server·database·CRUD interface를 공통으로 갖췄던 것처럼, 앞으로의 앱은 agentic side를 갖게 될 수 있다.
   2. 어떤 제품은 에이전트를 직접 통합하고, 어떤 제품은 다른 에이전트가 사용할 수 있는 headless data가 된다.

2. 새로운 인프라 원시 요소

   1. durable workflow, cloud sandbox, computer, memory, skill, 외부 서비스 연결, voice, payment, identity, eval, observability가 새로운 제품의 building block이 된다.
   2. 각 영역에는 이미 수많은 startup과 대규모 venture capital이 몰리고 있으며, 이 요소들이 하나의 harness 안에서 결합해야 한다.

주요 발언 모음

“상시 작동 에이전트는 동료와 더 비슷하다. 항상 즉시 메시지를 보내지 않고, 조용히 있어야 할 때를 안다.”

“모델을 위한 무한한 context는 실제로 존재하지 않는다. 다만 서브에이전트와 파일, 압축을 이용하면 context 한계에 부딪히는 감각을 없앨 수 있다.”

“가장 저렴하거나 가장 신뢰할 수 있는 선택지를 먼저 시도하고, 실패할 때만 더 비싼 선택지로 올라가라.”

“사람에게 좋은 오류 메시지는 에이전트에게도 좋다.”

“모델이 오늘 최악의 상태라고 가정하고, 다음 세대 모델을 위해 가능한 한 적게 만들어라.”

“모델이 실제로 어떻게 작동하는지에 대한 직관을 가지면 어떤 역할을 맡든 훨씬 좋은 위치에 설 수 있다.”

핵심 데이터 & 수치

• 영상 길이: 45분 18초(2,718초)다.
• 강연 타임라인: 2:35 ‘여기까지 온 과정’, 6:13 ‘모델에서 바뀐 점’, 10:06 ‘상시 작동 에이전트 내부’, 18:07 ‘harness’, 27:26 ‘context engineering’, 34:26 ‘향후 방향’으로 구성된다.
• 작업 기간: 상시 작동 에이전트는 단기 응답을 넘어 몇 시간·며칠·몇 주·몇 달의 작업을 목표로 한다.
• Context 예시: 200,000 token context window도 계속되는 대화 앞에서는 결국 compaction이 필요하다.
• Prompt cache 예시: 모델 제공자의 cache window가 10분 또는 60분이라면 따뜻한 동안 compaction하는 편이 비용 효율적이다.
• 병렬성: 한 머신에서 5개 또는 10개의 봇이 각자의 virtual desktop과 브라우저를 사용할 수 있다.
• 도구 선택 사다리: 대화 기록 → plugin/MCP/API → web search → browser → Linux desktop → 사용자 요청 순서로 비용과 개입을 점진적으로 높인다.
• 전용 도구 판단 기준: 특정 작업의 약 90%를 shell command가 차지하면 전용 도구가 효율적일 수 있다.
• 시간 범위: 현재의 모델·제품 개선은 매일의 inner loop와 몇 달 단위의 outer loop로 구성된다.
• 예측 범위: 향후 6~12개월 안에 주 단위·월 단위 에이전트, 더 나은 기억 회수, speech-to-speech 인터페이스가 확산될 가능성이 있다.

20줄 핵심 요약

1. 상시 작동 에이전트는 모델·harness·서버·클라우드 컴퓨터·메모리를 결합한 장기 실행 시스템이다.

2. 터미널 harness는 모델이 도구를 반복 호출하게 하지만 노트북을 닫으면 프로세스가 멈춘다.

3. 서버 기반 에이전트는 컴퓨터를 닫거나 장애가 발생해도 상태를 보존하고 작업을 재개한다.

4. 에이전트 전용 Linux machine은 파일·브라우저·desktop과 독립된 작업 공간을 제공한다.

5. Slack·이메일·회의·routine·완료 이벤트가 사용자의 직접 입력 없이도 에이전트를 깨운다.

6. router는 여러 입력을 중복 제거하고 중요한 사건만 사용자에게 전달한다.

7. Firecracker VM은 에이전트 컴퓨터를 snapshot하고 절전·복구하기 쉽게 만든다.

8. durable workflow는 장애가 나도 완료한 단계를 반복하지 않고 중단 지점부터 이어간다.

9. thin client는 send user 하나로 서버와 통신하고 무거운 도구는 thick server에 둔다.

10. dynamic context는 모든 도구 설명을 미리 넣지 않고 필요한 도구만 검색해 context를 절약한다.

11. 정보 접근은 대화 기록·API·검색·브라우저·desktop 순으로 신뢰성과 비용을 고려해 선택한다.

12. accessibility tree는 screenshot보다 적은 token으로 브라우저의 버튼과 링크를 찾게 한다.

13. 주 에이전트는 서브에이전트에게 비싼 작업을 위임해 대화 context를 작게 유지한다.

14. prompt caching은 고정된 system prompt와 tool definition을 유지해 장기 작업 비용을 낮춘다.

15. compaction은 긴 대화를 요약하며 핵심 사실·날짜 로그·임시 메모·파일 기억을 분리한다.

16. 외부 이메일과 webhook은 prompt injection이 될 수 있으므로 사용자 지시와 분리해 검증해야 한다.

17. 이메일 발송과 같은 비가역 작업은 초안·승인 절차와 secret isolation을 거쳐야 한다.

18. 제품 팀은 매일 실패를 eval로 바꾸고 harness를 고치며 모델 팀은 새 학습으로 장기 개선을 수행한다.

19. 앞으로 에이전트는 몇 주 또는 몇 달 일하고 음성·스킬 학습·기억 회수까지 수행할 가능성이 높다.

20. durable workflow·sandbox·memory·identity·eval·observability가 차세대 소프트웨어의 핵심 원시 요소가 된다.

결론 및 시사점

1. 제품 설계: 사용자가 모든 명령을 승인하는 화면을 늘리기보다 에이전트가 스스로 처리할 수 있는 범위를 넓히고, 정말 위험한 행동에만 승인 절차를 집중해야 한다.
2. 시스템 설계: 장기 실행을 지원하려면 모델 호출보다 workflow durability, 상태 저장, 재시작, 우선순위, 중복 제거를 먼저 설계해야 한다.
3. Context 설계: 모든 정보를 prompt에 쌓지 말고 핵심 사실·최근 로그·임시 scratchpad·검색 가능한 파일을 분리해야 한다.
4. 도구 설계: 범용 shell command만 제공하지 말고 반복적으로 사용되는 작업에는 설명 가능하고 검증 가능한 전용 도구를 제공해야 한다.
5. 보안 설계: VM 격리만으로 충분하지 않으며 prompt injection, secret, identity, 비가역 행동, 외부 입력을 별도 경계로 다뤄야 한다.
6. 조직 운영: 사람의 업무 절차를 문서화할수록 에이전트가 그것을 skill과 routine으로 흡수해 디지털 동료로 전환할 수 있다.
7. 학습 방향: 모델의 내부 동작과 inference·context 한계를 이해하는 것은 AI 제품을 만드는 모든 역할의 기본 역량이 된다.
8. 미래 전략: 모델이 빠르게 좋아지는 상황에서 거대한 고정 UI를 만드는 대신, 다음 세대 모델을 받아들일 수 있는 최소 인터페이스와 강한 harness를 구축해야 한다.