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

URL: https://www.youtube.com/watch?v=N8gD8ebFlMI 날짜: 2026-10-13 채널: Tech Bridge 원문 제목: [한영자막] Grok Bot 같은 상시 작동 에이전트는 어떻게 작동할까요? | SpaceX 엔지니어 Lee Robinson의 스탠퍼드 강연 발표자: Lee Robinson, SpaceX ML 엔지니어 강연 맥락: Stanford CS146S

자막 처리 메모: 원본 영상 N8gD8ebFlMI는 회원 전용 접근으로 yt-dlp 자동 자막 추출이 차단됐다. 같은 Stanford CS146S 강연의 공개 업로드와 공개 슬라이드를 대조해 전체 발화 흐름을 번역·정리했다. 원본의 한영 자막 표기와 일부 편집 차이는 있을 수 있으나 강연의 논점·사례·수치·설계 원칙은 빠짐없이 반영했다.

---

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

==상시 작동 에이전트(always-on, proactive, persistent agent)는 단순히 더 오래 답하는 챗봇이 아니라, 서버·전용 컴퓨터·내구성 워크플로·파일 기반 메모리·도구 하네스(harness)를 결합해 사용자가 자리를 비운 뒤에도 일을 계속하고, 중요할 때만 말을 거는 새로운 소프트웨어 제품이다.==

• 기존 주차 1 에이전트는 messages = [system_prompt, user_message]에서 시작해 모델이 도구를 호출하는 동안만 실행되며 터미널을 닫으면 끝난다.
• 상시 작동 에이전트는 서버에서 살아 있고, 자체 Linux 컴퓨터·브라우저·파일·로그인을 가지며, 충돌·배포·노트북 종료에도 상태를 복구한다.
• 입력은 사용자의 채팅뿐 아니라 일정·웹훅·Slack·이메일·전화·회의·다른 에이전트의 작업 완료 이벤트에서도 들어온다.
• 모델의 긴 컨텍스트 한계를 파일, 스킬(skill), 루틴(routine), 하위 에이전트(sub-agent), 요약·압축(compaction), 프롬프트 캐시로 우회한다.
• 제품의 핵심 UX는 모든 단계의 승인 버튼이 아니라 사용자가 자연어로 방향을 바꾸는 조종(steering)이며, 위험한 작업은 별도 자동 검토 모델과 사용자 승인으로 보호한다.

상시 작동 에이전트의 본질은 “항상 프로세스가 돌아간다”가 아니다. 아무 일도 없을 때는 서버와 가상 머신이 잠들어 비용을 아끼고, 중요한 상태만 저장해 둔 뒤 트리거가 오면 필요한 부분을 복원해 한 번의 작업을 수행한다. 따라서 제품의 차별점은 모델 자체만이 아니라 모델이 장기간 안전하고 저렴하게 일하도록 만드는 아키텍처와 하네스에 있다.

1. 터미널 에이전트에서 상시 작동 동료로

1.1. 주차 1 하네스의 출발점

1. 모델-도구 루프가 기본 단위다

   1. 시스템 프롬프트와 사용자 메시지를 넣고, 모델이 답변 또는 도구 호출을 반환한다.
   2. 도구 호출이 있으면 실행 결과를 다시 메시지 목록에 넣고 모델을 반복 호출한다.
   3. 도구 호출이 없으면 텍스트 답변을 출력하고 루프가 종료된다.

2. 기존 방식의 경계

   1. 에이전트는 사용자의 터미널에서 실행되므로 노트북을 닫거나 터미널을 종료하면 프로세스가 멈춘다.
   2. 상태는 주로 메시지 목록에 남고, 자체 컴퓨터·지속 메모리·장기 작업 큐가 없다.
   3. 모델이 명령을 하나 실행할 때마다 사용자가 확인하는 방식이라, 사람이 모든 작업의 병목이 된다.

3. 확장해야 하는 방향

   1. 실행 위치를 서버와 클라우드로 옮겨 노트북 종료·충돌·배포 이후에도 계속 실행한다.
   2. 에이전트에 별도의 Linux 컴퓨터, 데스크톱, 브라우저, 파일 시스템을 준다.
   3. 작업 상태와 사용자의 작업 방식이 시간이 지나며 축적되도록 메모리·스킬·루틴을 저장한다.

1.2. 개발자가 AI를 사용하는 네 시대

1. 2022~2023년: 복사·붙여넣기(copy and paste)

   1. 브라우저의 ChatGPT 같은 채팅 창에 코드를 붙여 넣고 답변을 수동으로 에디터에 복사했다.
   2. 모델은 질문에 답했지만 파일을 직접 고치거나 실행 환경에서 검증하지 못했다.

2. 2024~2025년: 터미널 에이전트(agents in the terminal)

   1. 모델이 파일 편집과 셸 명령 실행을 루프 안에서 수행하기 시작했다.
   2. 생산성은 높아졌지만 사람이 각 셸 명령을 승인하고 계속 지켜봐야 했다.

3. 2025~2026년: 에이전트용 앱(apps built for agents)

   1. 여러 에이전트를 병렬로 실행하고 클라우드·백그라운드에서 작업하게 하는 전용 앱이 생겼다.
   2. 사용자는 모든 명령을 직접 승인하기보다 완성된 변경 사항을 검토하는 쪽으로 이동했다.

4. 현재: 상시 작동 에이전트(always-on agents)

   1. 사용자는 에이전트에게 자체 컴퓨터·도구·메모리를 주고 잠시 떠날 수 있다.
   2. 에이전트는 몇 시간·며칠을 넘어 장기적으로 일하고, 완료·예외·중요한 판단이 있을 때만 돌아온다.
   3. 대화형 채팅보다 문자 메시지를 주고받는 느낌에 가까워진다. 누구나 텍스트 메시지를 보낼 줄 알기 때문에 복잡한 IDE보다 진입장벽이 낮다.

1.3. 승인(approval)에서 조종(steering)으로

1. 과거의 상호작용

   1. 사용자가 프롬프트를 보내면 에이전트가 작업하고, 각 단계에서 “승인할까요?”라고 멈췄다.
   2. 사용자는 셸 명령 수백 개를 확인해야 했고, 인간의 피로가 안전성과 생산성을 동시에 떨어뜨렸다.

2. 현재의 상호작용

   1. 에이전트가 일하는 동안 사용자는 “Slack 스레드도 확인해”, “아니, 목요일로 바꿔”, “준비되면 초대장을 보내”처럼 자연스럽게 방향을 수정한다.
   2. 최신 모델은 뒤늦게 들어온 메시지가 새 업무인지 기존 업무의 정정인지 파악하고 맥락을 이어간다.
   3. 장시간 작업은 에이전트가 계속 수행하고, 사용자는 조타수처럼 방향을 잡는다.

3. 자동 검토(auto-review)

   1. 이메일·Slack 발송처럼 위험한 명령은 별도의 AI 모델이 실행 전에 검토한다.
   2. 맹목적으로 수백 개 명령을 사람이 승인하는 것보다 자동 검토 모델이 더 일관되게 위험을 찾을 수 있으며, 발표자는 블라인드 테스트에서 대부분 모델 검토가 사람보다 나았다고 설명한다.
   3. 위험한 작업을 자동 승인할 수 있는 경우에는 사용자를 다시 깨우지 않고 진행하되, 제품 정책이 허용하는 범위 안에서만 작동한다.

2. 상시 작동 시스템의 생명주기와 세 부분 구조

2.1. “항상 켜져 있음”은 항상 실행 중이라는 뜻이 아니다

1. 잠듦-복원-실행-저장-재수면 사이클

   1. 아무 일이 없으면 에이전트 서버와 에이전트의 컴퓨터는 잠든다.
   2. 메시지나 트리거가 들어오면 서버가 대화·메모리·루틴·스킬 상태를 불러온다.
   3. 에이전트는 모델 호출과 도구 호출을 반복하며 한 번의 turn을 수행한다.
   4. 각 단계와 결과를 저장하고, 일정 시간 유휴 상태가 되면 프로세스와 컴퓨터를 다시 재운다.
   5. 중요한 것은 계속 실행되는 프로세스가 아니라 언제든 재구축할 수 있는 저장된 상태다.

2. 비용을 낮추는 유휴 실행 정책

   1. 모든 사용자의 VM과 서버를 24시간 켜 놓으면 비용이 크고, 세상에 충분한 컴퓨터도 없다.
   2. 가벼운 서버 상태는 항상 유지하되, 도구 사용이 필요할 때만 컴퓨터를 깨운다.
   3. 슬라이드에서는 마지막 활동 뒤 몇 분 후, 강연 설명에서는 유휴 2분 후 에이전트 프로세스가 멈추는 예를 든다.
   4. 작업 중간에는 절대 잠들지 않으며, 저장·스냅샷을 마친 뒤에만 수면으로 들어간다.

3. 트리거의 종류

   1. 사용자가 어느 앱에서든 메시지를 보낸다.
   2. 오전 8시 루틴, 스케줄, cron, 웹훅이 실행을 요청한다.
   3. Slack 멘션·DM·스레드, 이메일, 전화·회의 이벤트가 에이전트를 깨운다.
   4. 다른 에이전트가 작업을 끝냈거나, 장시간 백그라운드 작업의 결과가 나와 후속 처리가 필요해진다.
   5. 에이전트가 정기적으로 상태를 확인하는 check-in도 트리거가 될 수 있다.

2.2. 라우터와 대화 큐

1. 입력 라우터(entry point/router)

   1. 여러 앱에서 들어온 이벤트의 출처를 기록한다. 사용자의 직접 요청인지, 루틴인지, 외부 서비스인지 알아야 우선순위와 응답 방식을 결정할 수 있다.
   2. 이미 처리한 이벤트의 중복 ID를 제거한다.
   3. 어느 대화에 넣을지 결정하고, 대화별 큐로 넘긴다.

2. 한 대화에 한 turn

   1. 한 대화에서는 한 번에 하나의 에이전트 turn만 실행해 상태 경쟁을 줄인다.
   2. 직접 보낸 1:1 메시지는 줄 앞에서 실행되며 현재 turn을 중단할 수 있다. “실제로는 목요일로 바꿔” 같은 정정이 대표 사례다.
   3. 그룹 채팅·Slack 스레드·루틴·헬퍼 완료 보고서는 보통 큐 뒤에 들어간다.
   4. 짧은 시간 안에 들어온 여러 메시지는 한 묶음으로 배치해 한 turn에서 처리할 수 있다.

3. 말할지 말지 결정하는 휴리스틱(heuristic)

   1. 에이전트가 조금 진척할 때마다 사용자에게 알리면 동료가 매번 “업데이트가 생겼다”고 찾아오는 것처럼 성가시다.
   2. 따라서 모든 상태 변경은 저장하되, 중요한 결과·막힘·승인 요청·완료 시점에만 메시지를 보낸다.
   3. 업무에 따라 하루 한 번 정도 상태를 보내거나, 백그라운드에서 조용히 일한 뒤 최종 결과만 보낼 수 있다.

2.3. 세 부분으로 나뉘는 시스템

1. 앱과 채널(apps and channels)

   1. 데스크톱·모바일·웹·Slack·이메일·웹훅·전화·회의가 사용자와 시스템의 진입점이 된다.
   2. 각 앱은 같은 대화를 보여주고, 서버의 변경 신호를 받으면 최신 데이터를 가져온다.

2. 서버(server)

   1. 입력을 검사·라우팅하고 대화별 큐를 유지한다.
   2. 모델과 도구를 반복 호출하는 에이전트 루프를 실행한다.
   3. 대화·메모리·루틴·스킬과 각 단계의 결과를 데이터베이스와 스토리지에 저장한다.

3. 에이전트의 컴퓨터(agent's computer)

   1. 셸·파일·스크린샷·클릭·브라우저를 실행하는 도구 환경이다.
   2. 앱 커넥터, 클라우드 에이전트, 웹 검색, 이미지 생성, 화면 녹화 등도 이 계층에서 호출할 수 있다.
   3. “서버가 에이전트를 실행하고 에이전트는 자기 컴퓨터에서 도구를 쓰며 모든 앱은 같은 대화를 보여준다”가 전체 구조의 요약이다.

2.4. Firecracker VM과 수면·복원

1. 가상 컴퓨터의 구성

   1. 사용자마다 Firecracker 가상 머신을 하나 두고 유휴 시 디스크에 저장한다.
   2. 내부에는 supervisor가 유지하는 Linux(Debian) 컨테이너가 있다.
   3. 파일 서버는 파일·앱 연결·실시간 데스크톱 뷰를 제공한다.
   4. command runner는 셸 명령·파일·스크린샷·클릭을 처리한다.
   5. Screen 1은 자체 Chrome이 있는 가상 디스플레이이며, 활동 중인 에이전트마다 Screen 2, 3처럼 화면을 추가할 수 있다.
   6. 파일·설치한 도구·브라우저 로그인은 세션 사이에 유지된다.

2. 잠들 때

   1. 마지막 활동 뒤 몇 분이 지나고 turn이 끝난 뒤 파일을 클라우드 스토리지에 동기화한다.
   2. 메모리와 디스크를 스냅샷으로 저장한다.
   3. VM을 멈춘다.

3. 깨어날 때

   1. 다음 도구 호출이 오면 스냅샷을 원래 위치에 복원한다.
   2. 로그인과 설치 도구를 그대로 사용할 수 있다.
   3. 대화 상태는 서버에서 가져온다.

4. 서버에 상태를 두는 이유

   1. thin client–thick server 구조면 노트북을 닫아도 작업이 지속되고 컴퓨터·휴대폰을 오갈 수 있다.
   2. 서버 코드를 배포할 때 앱스토어 심사를 기다리지 않아도 된다.
   3. 전사·이미지 생성 같은 무거운 계산을 서버로 넘길 수 있고, 가변 트래픽과 급격한 성장에 익숙한 방식으로 확장할 수 있다.
   4. 에이전트 루프를 VM과 분리하면 VM에 치명적인 Linux 보안 업데이트가 필요할 때 VM만 재구축할 수 있다. 애플리케이션 전체를 멈추거나 루프를 잃지 않는다.
   5. 따라서 모든 대화·메모리·루틴·스킬·진행 상태는 서버에 저장하고 VM은 언제든 다시 만들 수 있게 한다.

3. 모델의 변화가 가능하게 만든 여섯 가지 능력

3.1. 더 긴 작업과 하위 에이전트

1. 수 시간에서 수일 동안 지시 따르기

   1. 최근 1~2년 사이 모델은 긴 시간 지시를 따라가며 혼동·실수를 덜 하게 됐다.
   2. 적절한 압축·요약(compaction)을 적용하면 수 시간 또는 며칠 동안 작업을 계속할 수 있다.

2. 하위 에이전트로 위임하기

   1. 메인 에이전트의 작업 메모리는 결국 차지만, sub-agent는 새 작업 메모리로 시작한다.
   2. 메인 에이전트는 토큰과 도구 호출이 비싼 일을 헬퍼에게 넘기고, 짧은 보고만 받아 사실상 무한 컨텍스트처럼 느끼게 한다.
   3. 하나의 컨텍스트 창에 모든 작업을 밀어 넣지 않고 여러 독립 작업을 병렬화할 수 있다.

3.2. 실제 도구와 컴퓨터 사용

1. 도구 호출의 신뢰성 향상

   1. 과거 모델은 도구 호출을 잘못하거나 환각하는 경우가 많았지만, 발표자는 도구 사용과 환각 문제가 대체로 해결 단계에 왔다고 평가한다.
   2. 셸과 파일뿐 아니라 팀원에게 컴퓨터를 주듯 전체 Linux 컴퓨터를 제공할 수 있다.

2. Computer use

   1. 화면을 보고 사람처럼 클릭하면 API나 MCP 서버를 제공하지 않는 SaaS와 웹사이트도 자율적으로 사용할 수 있다.
   2. 브라우저·가상 데스크톱·화면 녹화·데모 제작 같은 기능까지 작업 범위가 넓어진다.

3.3. 파일로 지식 저장하기

1. 프로필과 작업 로그

   1. 사용자가 모든 메시지를 소문자로 써 달라는 선호처럼 항상 지켜야 할 프로필을 매 프롬프트에 넣는다.
   2. 매일 한 일을 날짜별 로그 파일에 남기고, “지난주에 무엇을 했지?”라는 질문이 오면 모델이 파일을 검색한다.
   3. 모델은 Linux 셸의 grep 같은 검색·정리 명령을 잘 사용하므로 평문 파일이 사람과 에이전트 모두에게 읽기 쉬운 공유 메모리가 된다.

2. 스킬(skill)

   1. 특정 업무를 성공적으로 수행하는 절차와 주의점을 Markdown 파일로 기록한다.
   2. 좋은 이메일을 보내는 법, API를 만드는 법 등 개발자·회사·생태계가 만든 스킬을 설치해 재사용한다.
   3. Grok Bot에는 원하는 도구를 플러그인으로 설치하는 체계가 있고, 플러그인은 스킬 또는 서버를 활용한다.

3. 루틴(routine)

   1. cron job처럼 정해진 시간에 프롬프트를 실행한다.
   2. 아침 브리핑·주간 지표·주기적 모니터링처럼 사용자가 매번 요청하지 않아도 되는 작업을 맡긴다.

4. 핵심 관점

   1. “Everything is computer”라는 관점에서는 기억·스킬·루틴·도구·앱 연결을 모두 에이전트가 읽고 쓰는 컴퓨터 자원으로 다룬다.
   2. 모델이 새 작업을 배우면 해당 절차를 파일로 남겨 다음 실행의 지능으로 만든다.

4. 메시지·분산 시스템·내구성 워크플로

4.1. 전송 버튼 뒤에서 일어나는 일

1. 보내기와 즉시 표시

   1. 앱은 사용자가 보낸 메시지를 먼저 화면에 보여주고 고유 ID와 함께 로컬에 저장한다.
   2. 서버는 이미 본 ID를 버리므로 재시도해도 중복 메시지가 쌓이지 않는다.

2. turn 실행

   1. 메시지가 대화 큐에 들어가고, 에이전트는 모델 호출·도구 호출·결과 저장을 반복한다.
   2. 각 단계는 데이터베이스에 기록되어 다른 앱이 같은 상태를 볼 수 있다.

3. 변경 신호와 순서

   1. 서버는 데이터 자체가 아니라 “무언가 바뀌었다”는 작은 알림을 보낸다.
   2. 앱은 신호를 받으면 데이터베이스에서 최신 메시지와 상태를 다시 가져온다.
   3. 모든 업데이트에는 41, 42, 43 같은 순서 번호가 붙는다.
   4. 하나가 빠지면 앱은 데이터베이스에서 다시 로드한다. 신호를 하나 잃어도 실제 데이터는 서버에 있으므로 복구할 수 있고, 모든 앱은 결국 같은 상태가 된다.

4.2. 작업 큐가 아니라 내구성 워크플로

1. 일반 job queue의 문제

   1. 에이전트가 1단계·2단계·3단계를 진행하다 서버가 충돌하면 큐가 처음부터 다시 시작할 수 있다.
   2. 이미 끝난 작업을 반복하면 중복 이메일·중복 결제·중복 파일 변경 같은 문제가 생긴다.

2. durable workflow의 해결

   1. 모든 단계를 기록해 새 서버가 마지막으로 성공한 지점부터 재개한다.
   2. 3단계에서 충돌하면 1·2단계를 다시 하지 않고 3단계에서 계속한다.
   3. 각 단계는 두 번 실행되어도 문제가 없도록 멱등적(idempotent)으로 설계한다.
   4. 타이머·취소·상태 점검을 제공하는 오픈소스 Temporal 같은 엔진을 사용하면 분산 시스템의 복잡한 기반을 직접 재구현하지 않아도 된다.

4.3. 우선순위와 배치

1. 정정 메시지는 앞선다

   1. 1:1 채팅에서 사용자가 현재 작업을 정정하면 실행 중인 turn을 멈추고 새 지시를 우선한다.
   2. 사용자의 의도와 직접 충돌하지 않는 그룹 대화·Slack 스레드·루틴·헬퍼 보고서는 뒤에 둔다.

2. 빠른 메시지는 합친다

   1. 짧은 시간에 들어온 세네 개의 메시지를 하나의 turn에서 처리한다.
   2. 대화별로 한 번에 한 batch만 실행해 경쟁 조건과 불필요한 모델 호출을 줄인다.

5. 하네스(harness): 하나의 대화 도구와 많은 작업 도구

5.1. 클라이언트와 서버 사이에는 SendToUser 하나만 둔다

1. 얇은 클라이언트

   1. 데스크톱·모바일·웹·이메일·Slack 등 어떤 클라이언트도 서버와 통신할 때는 사용자에게 보내는 단일 도구를 사용한다.
   2. 셸·파일·브라우저·클라우드 에이전트·앱 커넥터·화면 녹화·이미지 생성은 서버 쪽의 작업 도구다.
   3. 새로운 클라이언트를 추가해도 서버 하네스와 도구를 다시 만들 필요가 없다.

2. 클라이언트의 풍부한 표시

   1. 서버가 로그인 필요 상태를 보내면 클라이언트는 목적에 맞는 로그인 폼과 1Password 연결을 보여준다.
   2. 결제 요청이면 금액·상품·서비스 계획을 보여주고 Allow 또는 Deny를 선택하게 한다.
   3. 되돌릴 수 없는 이메일·Slack 발송은 전체 초안을 보여주고 Send 또는 Discard를 선택하게 한다.
   4. 단순한 답변에는 텍스트 대신 이모지 반응만 남기는 UX도 가능하다.
   5. 비밀번호 자체는 모델에 전달하지 않고 전용 자격 증명 도구가 로그인 폼을 채운다.

5.2. 동적 도구 발견(dynamic context/tool search)

1. 도구를 모두 넣을 때의 문제

   1. 각 도구에는 이름·스키마·설명·매개변수가 있어 Google Drive·Gmail·YouTube 같은 MCP 커넥터를 계속 추가하면 컨텍스트 창이 도구 정의로 가득 찬다.
   2. 모델이 실제 대화와 작업에 사용할 공간이 줄고 비용·지연·실수가 늘어난다.

2. 이름은 먼저, 상세는 필요할 때

   1. 매 호출에는 도구 이름 목록만 넣고, 모델이 특정 도구가 필요하다고 판단할 때 검색 도구로 설명과 스키마를 불러온다.
   2. 파일 시스템 안에 파일이 있고 모델이 필요할 때 읽는 것처럼, 도구 정보도 필요할 때만 가져온다.
   3. 사용 가능한 도구가 많아져도 메인 컨텍스트를 안정적으로 유지한다.

5.3. 가장 싸고 안정적인 수단부터

1. 정보 탐색의 계단식 선택

   1. 이미 대화와 메모리에서 알고 있는 정보가 있는지 먼저 확인한다.
   2. 없으면 앱 API·MCP 커넥터를 사용한다. 예를 들어 은행 정보는 Plaid 같은 API에서 가져온다.
   3. 커넥터가 없으면 웹 검색을 사용한다. “어젯밤 Cubs 경기 점수” 같은 정보를 찾는 경우다.
   4. 웹 검색으로 부족하면 브라우저를 열고 웹페이지를 탐색한다.
   5. 마지막으로 전체 데스크톱에서 셸·스크립트·파일을 사용한다.
   6. 이 모든 방법이 실패할 때만 사용자를 깨워 질문하거나 승인을 받는다.

2. 커넥터가 고장 났을 때의 원칙

   1. 전용 커넥터가 고장 났다고 브라우저로 우회하면 더 느리고 위험하며 사용자가 예상하지 못한 동작이 될 수 있다.
   2. 에이전트는 “커넥터를 사용할 수 없다”고 분명히 알리고 사용자의 지시를 받아야 한다.

5.4. 컴퓨터를 사용하는 세 가지 방식

1. 페이지 구조와 접근성 트리(accessibility tree)

   1. HTML·접근성 트리에서 버튼·링크·입력 필드 목록을 읽고 직접 클릭한다.
   2. 스크린샷 전체를 읽는 것보다 빠르고 토큰을 덜 사용하며 안정적이다.

2. 픽셀 클릭(pixel-level computer use)

   1. 1280×800 화면의 마우스·키보드처럼 동작한다.
   2. 데스크톱 앱·시스템 대화상자·사이트 모달처럼 구조화된 API가 없는 화면에 필요하다.
   3. 브라우저와 데스크톱 클릭 작업은 별도 컴퓨터 사용 헬퍼에게 맡겨 스크린샷이 메인 컨텍스트를 채우지 않게 한다.

3. 사람에게 묻기(ask a person)

   1. 로그인·인증 코드·CAPTCHA·결제처럼 비밀 또는 최종 책임이 필요한 단계에서는 멈춘다.
   2. 에이전트가 현재 위치와 필요한 조치를 설명하고 화면을 사용자에게 넘긴다.

5.5. 메인 에이전트 하나와 전문 헬퍼들

1. 역할 분리

   1. 메인 에이전트는 사용자와 빠르게 대화하고 전체 작업을 조율한다.
   2. 셸·웹·앱 커넥터를 쓰는 일반 헬퍼, 브라우저·데스크톱을 조작하는 computer-use 헬퍼, 영상을 보고 검토하는 video 헬퍼, 자기 VM에서 코드를 바꾸는 cloud coding agent를 둘 수 있다.
   3. 메인은 완전한 작업 설명을 넘기고, 헬퍼는 결과 보고를 짧게 돌려준다.

2. 팀처럼 운영하기

   1. 각 헬퍼는 독립된 durable workflow이므로 실패·메모리 부족·프로세스 충돌 이후에도 진행 지점에서 복구한다.
   2. 메인 에이전트는 할 일 목록으로 요청을 추적하고 헬퍼 상태를 확인하거나, 메시지를 보내거나, 중지할 수 있다.
   3. 복잡한 문제를 여러 엔지니어 팀에 나누는 방식과 같은 구조다.

5.6. 하네스 도구 설계 규칙

1. 안정적인 도구 목록

   1. turn 사이에 도구를 추가·삭제하지 않는다. 현재 사용할 수 없는 도구는 목록에서 사라지게 하기보다 명확한 오류를 반환한다.
   2. 배포가 진행 중이면 실행 중 대화에는 새 도구 설명을 덮어쓰지 말고 변경 알림을 남긴다.

2. 작은 설명과 전용 도구

   1. 도구 설명과 스키마는 각각 4,000자 이하로 유지한다.
   2. 상태 저장은 셸 명령으로 몰래 처리하지 말고 전용 저장 도구로 만들어 무엇이 바뀌는지 검토할 수 있게 한다.
   3. 한 작업의 90%를 셸 명령으로 처리한다면 반복 셸 호출을 전용 도구로 만들면 더 효율적이고 사람이 읽기도 쉽다.

3. 다음 행동을 알려주는 오류

   1. “실패했다”보다 “컴퓨터가 잠들었다. Shell 또는 Read로 깨운 뒤 다시 시도하라”처럼 다음 조치를 적는다.
   2. 사람을 위한 좋은 DX가 에이전트에게도 좋은 도구 설계가 된다.

6. 보안·승인·신뢰 경계

6.1. 자동 검토와 사용자 승인

1. 별도 모델이 위험한 셸 명령과 비가역적 작업을 실행 전에 검사한다.
2. 검토 모델이 차단하면 사용자에게 승인 요청을 보내며, 슬라이드 예시에서는 15초 안에 답이 없으면 차단 상태로 둔다.
3. 이메일·메시지 발송·결제처럼 외부에 영향을 주는 작업은 먼저 사용자의 요청이 있었는지 확인한다.
4. 사용자의 로컬 노트북에서 수행하는 작업은 별도 승인 대상으로 둔다.

6.2. 입력의 출처를 추적한다

1. 이메일·웹훅·웹페이지 텍스트는 사용자의 지시가 아니라 조작을 유도하는 untrusted input일 수 있다.
2. 모델에게 전달할 때 “외부에서 온 정보”로 표시하고, 그 안의 문장을 시스템 명령처럼 따르지 않게 한다.
3. 메모리도 사실·정보일 뿐 지시(instruction)가 아니라고 모델에 명시한다.
4. 장기 실행 에이전트가 웹과 이메일을 읽는 순간 prompt injection 방어가 핵심 인프라 문제가 된다.

6.3. 비밀을 모델 컨텍스트 밖에 둔다

1. 비밀번호는 모델 메시지에 넣지 않고 환경 변수나 전용 인증 저장소에 둔다.
2. 1Password 같은 도구가 로그인 폼을 채우며, 모델은 실제 비밀번호를 보지 않는다.
3. 결제는 상품·금액·내역을 별도 UI로 보여주고 승인·거절을 받는다.

7. 컨텍스트 엔지니어링(context engineering)

7.1. 프롬프트 캐시를 깨뜨리지 않는 구조

1. 고정된 앞부분

   1. 도구 정의, 시스템 프롬프트, 메모리·루틴 스냅샷, 환경 정보와 도구 이름을 프롬프트 앞에 둔다.
   2. 대화 기록은 새 메시지를 끝에만 추가하고, 최신 시각·변경 요약·사용자 메시지는 마지막에 둔다.
   3. 제공업체는 최근 요청과 같은 앞부분을 캐시해 다시 계산하지 않으므로 응답이 빨라지고 비용이 내려간다.

2. 캐시 미스는 버그로 취급한다

   1. 상시 에이전트는 모든 요청에서 긴 프롬프트를 재전송하므로 캐시 미스가 곧 비용·지연·품질 문제다.
   2. 각 섹션을 해시하고 고정된 순서로 정렬해 어떤 부분이 바뀌었는지 정확히 추적한다.
   3. A/B 테스트나 새 도구를 추가할 때 전체 순서를 흔들지 않으며, 변경된 대화에는 새 설명을 넣기보다 “배포가 바뀌었다”는 알림만 남긴다.
   4. 도구의 추가·삭제로 앞부분이 이동하지 않게 하고, 쓸 수 없는 도구는 오류로 응답한다.
   5. 사용자가 채팅을 열거나 입력을 시작할 때 서버가 프롬프트를 미리 준비해 캐시를 데운다. 웹사이트에서 링크에 마우스를 올리면 다음 페이지를 미리 가져오는 것과 같다.

7.2. 메인 컨텍스트를 작게 유지하기

1. 긴 도구 결과는 대화에 그대로 넣지 말고 파일로 저장한 뒤 파일 경로만 남긴다.
2. 큰 스크린샷·비싼 분석은 헬퍼에게 보내고 결과 요약만 받는다.
3. 오래된 메시지는 짧은 요약으로 압축하고, 원래 내용은 검색 가능한 파일에 보존한다.
4. 실행 지침은 긴 프롬프트가 아니라 필요할 때 읽는 스킬 파일의 한 줄 포인터로 둔다.
5. 메인 에이전트의 컨텍스트가 작으면 매 호출이 빠르고 저렴하며, 헬퍼를 써서 작업 규모를 늘려도 대화 품질이 덜 떨어진다.

7.3. 압축(compaction)과 캐시 창

1. 200,000토큰 컨텍스트라도 계속 대화하면 언젠가 한계에 도달하며, 압축은 필연적으로 일부 정보를 잃는 손실 압축이다.
2. 따라서 무엇을 보존할지, 어떤 알고리즘으로 요약할지 자체가 고난도 연구 문제가 된다.
3. 10만 토큰이 넘는 긴 turn이 끝나고 사용자가 자리를 비우면 모델 제공업체의 캐시가 10분 또는 60분 정도 유지될 수 있다.
4. 캐시가 따뜻할 때 약 10분 이내에 압축을 실행하면 긴 원문을 다시 읽는 비용을 줄일 수 있다.
5. 사용자가 30분 후 돌아오면 짧은 요약에서 이어가므로 새 메시지를 추가하는 비용이 낮아진다.
6. 백그라운드 작업이 곧 깨어날 예정이면 불필요한 압축을 건너뛸 수 있고, turn이 너무 길면 중간에도 압축할 수 있다.

7.4. 메모리의 층위

1. 프로필(profile)

   1. 사용자의 핵심 사실을 항상 프롬프트에 넣는다.
   2. 예시 설계는 최대 100개 사실, 4,000자 이내다.

2. 로그(log)

   1. 날짜가 붙은 과거 사건과 대화 기록이다.
   2. 최근 관련성이 높은 30개 정도를 프롬프트에 올리고, 나머지는 파일 검색으로 가져온다.

3. 노트(notes)

   1. 지금 당장 필요한 단기 작업 세부사항을 저장한다.
   2. 30분 또는 한 시간 뒤에는 사라져도 되는 scratchpad 성격이다.

4. 나머지 파일(everything else)

   1. 오래된 정보·상세 기록·스킬은 평문 파일에 저장한다.
   2. 모델은 필요할 때 검색 도구와 Linux 명령으로 찾아온다.

5. 갱신·공유 규칙

   1. 각 turn 뒤 별도 패스가 새 사실을 추가하고 오래된 사실을 교체한다.
   2. 이 패스는 현재 전달받은 정보만 삭제할 수 있어 보지 못한 사실을 임의로 지우지 않는다.
   3. 사용자에 관한 핵심 사실은 모든 에이전트가 공유하지만, 각 에이전트는 자기 작업 파일을 쓴다.
   4. 메모리는 정보이지 명령이 아니라고 모델에 알려 prompt injection 위험을 줄인다.
   5. 중요한 사실은 높은 순위로 유지하고, 오래된 사실은 서서히 순위를 낮춘다. 사람의 기억이 현재 대화와 관련된 사실을 우선 떠올리는 방식에서 영감을 얻었다.

8. 제품과 모델이 함께 개선되는 플라이휠

8.1. 모델 학습의 세 단계

1. 사전 학습(pre-training)

   1. 인터넷 텍스트와 사내 데이터에서 언어·코드·세상에 대한 일반 지식을 학습한다.

2. 지도 미세 조정(supervised fine-tuning, SFT)

   1. 이상적인 답변, 도구 형식, 하네스 안에서의 행동 예시를 보여준다.
   2. 사용할 수 있는 도구와 메모리·스킬을 이해하고 어떤 응답을 내야 하는지 익힌다.

3. 강화 학습(reinforcement learning, RL)

   1. 실제 에이전트 작업을 연습하고, 긴 지시를 잘 따르는지 보상한다.
   2. 수백 개 스킬 중 적절한 것을 고르는 법, 브라우저에서 올바른 지점을 클릭하는 grounding, 여러 봇과 협력하는 법을 훈련한다.

4. 추론과 작업별 최적화

   1. 메인 에이전트는 사용자가 기다리는 동안 몇 초 안에 답하도록 낮은 지연시간을 우선한다.
   2. 헬퍼는 10분과 12분의 차이가 크지 않으므로, 수 시간 동안 안정적으로 끝내고 컴퓨터를 빠르게 조작하는 쪽으로 조정한다.

8.2. 매일 도는 내부 루프와 몇 달 단위 외부 루프

1. 내부 루프(inner loop)

   1. 에이전트가 잘못된 도구를 호출하거나 잘못된 프롬프트·추론 경로를 사용하면 그 실패를 평가 항목(eval)으로 만든다.
   2. 하네스·버그·프롬프트·추론을 고치고 평가에서 실제로 개선됐는지 확인한다.
   3. 수정 사항을 제품에 배포하고, 팀은 이 과정을 매일 반복한다.

2. 외부 루프(outer loop)

   1. 매달 또는 몇 달마다 다음 모델을 학습한다.
   2. 제품에서 모은 실패와 평가를 학습에 반영하고, 새 모델을 제품에 넣어 관심 지표가 나아졌는지 확인한다.

3. 새 사용 방식이 다시 평가가 된다

   1. 새 모델이 나오면 제품을 예전보다 새로운 방식으로 사용하게 된다.
   2. 여러 봇이 있는 그룹 채팅처럼 학습 데이터가 아직 충분하지 않은 사용 방식이 생긴다.
   3. 서로 다른 봇이 대화하는 다중 에이전트 환경은 잘못 설계하면 문제가 커질 수 있으므로, Moltbook·Hugging Face 관련 사례처럼 예상치 못한 실패를 평가와 훈련에 반영해야 한다.
   4. “작동하지 않는 모든 봇은 새로운 eval이 된다”는 원칙이 오늘의 제품과 내일의 모델을 함께 개선한다.

9. 앞으로의 제품과 해결해야 할 문제

9.1. “제품을 삭제하라(Delete the product)”

1. 모델은 지금보다 계속 좋아질 것이므로 오늘의 UI와 복잡한 우회 계층을 영원히 유지한다고 가정하지 않는다.
2. 6개월 뒤에는 모델 능력이 크게 바뀌어 UI와 하네스를 다시 만드는 편이 나을 수 있다.
3. 가능한 한 적게 만들고 단순한 인터페이스만 제공해 모델이 생각하고 행동할 공간을 남긴다.
4. 제품 팀의 경쟁력은 코드량이 아니라 다음 모델에 맞춰 아키텍처를 빠르게 바꾸는 능력에 있다.

9.2. 앞으로 6~12개월의 전망

1. 더 긴 프로젝트: 몇 분짜리 한 작업이 아니라 하나의 프로젝트를 몇 주 또는 몇 달 동안 맡는다.
2. 더 강력한 도구: 컴퓨터에서 사람이 할 수 있는 일을 더 빠르고 안정적으로 처리한다.
3. 더 나은 메모리: 사용자와 팀이 일하는 방식을 기억하고 사용할수록 개선한다. 구현은 그래프·파일·다른 표현 중 무엇이든 될 수 있다.
4. 훈련되지 않은 업무를 현장에서 학습: 더 나은 메모리·스킬·지시 따르기와 모델의 원시 지능을 결합해 새로운 업무를 배운다.
5. 단순한 인터페이스: 지금은 문자 메시지가 중심이고, 다음에는 음성 대화만 선호하는 사용자도 생긴다.
6. 조직 지식의 문서화: 사람과 회사가 맞춤형 업무 절차를 더 잘 글로 남겨 에이전트가 사용할 수 있게 된다.
7. 비용·토큰 효율: 다음 해에는 세계적으로 처리되는 토큰이 크게 늘 것이므로 추론·모델·하네스가 토큰 사용량을 줄이는 일이 중요해진다.

9.3. 새로운 소프트웨어 기본 블록

1. 기존 웹 앱의 서버·데이터베이스·캐시·CRUD 인터페이스에 대응해 에이전트 제품은 durable workflow, 메모리·스킬, 컴퓨터 사용, 트리거·예약 작업, 커넥터·인증, 텍스트·음성 채널, 결제·신원, 평가·관측성을 갖춘다.
2. 모든 제품이 비슷한 박스를 갖더라도 각 박스의 구현은 달라질 수 있고, 각 영역에서 특화된 최상급 제품의 긴 꼬리가 생긴다.
3. 앱은 에이전트 기능을 통합하거나, 다른 에이전트가 사용할 headless 데이터 조각이 되어야 한다.
4. 발표자는 이 각각의 영역에 수십 개의 스타트업과 수십억 달러 규모의 VC 자본이 몰릴 것이라고 말한다.

9.4. 아직 열린 문제

1. 장기 실행 평가: 한 달 일하는 에이전트를 평가하는 동안 모델이 매달 새 버전이 되면, 장기 동작을 어떻게 충분히 검증할지 어렵다.
2. Prompt injection과 보안: 이메일·웹의 공격성 텍스트가 에이전트를 탈취하지 않도록 하네스와 인프라를 보호해야 한다.
3. 다중 에이전트 조정: 여러 에이전트가 한 컴퓨터와 메모리를 공유하면 전통적인 분산 시스템의 경쟁·일관성·교착 문제가 생긴다.
4. 정확한 메모리: 낡은 사실을 교체하고, 삭제 요청을 잊지 않으며, 없는 사실을 만들어내지 않아야 한다.
5. 언제 말할지: 너무 자주 알리면 소음이고, 너무 조용하면 사용자가 무엇을 하는지 알 수 없다. 선제성과 성가심 사이의 균형이 아직 완성되지 않았다.
6. 비용: 상시 작동 제품은 유휴 에이전트가 거의 무료이고 활동 중인 에이전트도 충분히 저렴해야 성립한다.

10. 실천적 결론과 Q&A

10.1. 엔지니어가 가져갈 세 가지 원칙

1. 아키텍처가 복리로 작동한다

   1. 코드 작성 비용이 내려갈수록 어떤 시스템으로 연결하고 저장·복구·확장하는지가 더 중요해진다.
   2. 발표자는 여전히 자신이 쓴 코드를 읽는다. 코드의 모든 줄을 외우는 것보다 출시하는 아키텍처를 이해하는 일이 중요하다.

2. 직접 만들어 본다

   1. 주차 1의 단순 모델-도구 루프에서 출발한다.
   2. 서버, 전용 컴퓨터, 메모리, 루틴, 내구성 워크플로를 차례로 붙여 자신의 상시 작동 에이전트를 만든다.
   3. 오픈소스 always-on agent를 포크하고 sandbox·VM·간단한 UI를 조합하는 것이 구조를 배우는 좋은 방법이다.

3. LLM의 기본 원리를 배운다

   1. 머신러닝 연구자가 되지 않아도 사전 학습·SFT·RL·추론·컨텍스트 한계를 이해하면 무엇이 가능한지 판단할 수 있다.
   2. 웹 앱을 만들 때 데이터베이스 작동 원리를 알아야 하듯, 에이전트 제품에서는 모델과 하네스의 상호작용을 알아야 올바른 제품·인프라 결정을 내릴 수 있다.

10.2. 강연의 마무리와 Q&A

강연은 상시 작동 에이전트의 구조·하네스·컨텍스트·미래 전망을 정리한 뒤, 청중 질문을 받을 수 있다고 안내하고 박수로 끝난다. 제공된 녹화 구간에는 별도의 질문과 답변 대화가 이어지지 않는다.

주요 발언 모음

“상시 작동 에이전트는 동료에 가깝다. 항상 즉시 메시지를 보내지 않고, 조용히 일하다가 중요한 업데이트가 있을 때 돌아온다.”

“모든 것이 컴퓨터다(Everything is computer).”

“캐시 미스는 시스템의 버그처럼 다뤄야 한다(Treat a cache miss like a bug).”

“제품을 삭제하라(Delete the product). 모델이 훨씬 좋아질 것을 가정하고, 모델이 더는 필요로 하지 않는 것은 제거하라.”

“코드가 싸게 작성될수록 올바른 아키텍처가 모두보다 빠르게 계속 움직이게 한다.”

“작동하지 않는 모든 봇은 오늘의 제품과 내일의 모델을 개선하는 eval이 된다.”

핵심 데이터·수치·사실

• 강연 챕터 타임스탬프: 2:35 ‘How we got here’, 6:13 ‘What changed in the models’, 10:06 ‘Inside an always-on agent’, 18:07 ‘The harness’, 27:26 ‘Context engineering’, 34:26 ‘Where this is going’.
• 개발의 네 시대: 2022~2023 복사·붙여넣기, 2024~2025 터미널 에이전트, 2025~2026 에이전트용 앱, 현재 상시 작동 에이전트.
• VM: 사용자당 Firecracker VM, Debian Linux 컨테이너, supervisor, 파일·명령 실행 서버, 활동 중인 에이전트별 가상 화면.
• 유휴 동작: 마지막 활동 뒤 몇 분 후 또는 설명에 제시된 예시로 유휴 2분 후 저장·스냅샷·정지하며, 실행 중인 turn 중간에는 잠들지 않는다.
• 메모리 예시: 항상 프롬프트에 넣는 프로필 최대 100개 사실·4,000자, 프롬프트에 올리는 관련 로그 약 30개, 나머지는 검색 도구로 불러온다.
• 도구 설계: 도구 설명과 스키마는 4,000자 이하를 권장하며, 사용 불가 도구는 삭제 대신 명확한 오류를 반환한다.
• 컨텍스트 예시: 200,000토큰 창도 장기 대화에서 가득 차며, 100,000토큰이 넘는 turn은 캐시가 따뜻한 약 10분 또는 제공업체에 따라 60분 안에 압축하는 편이 유리하다.
• 안전 UX: 자동 검토에 15초 동안 응답이 없으면 위험 작업을 차단하는 설계 예시가 제시된다.
• 이벤트 정합성: 변경 신호는 데이터가 아니라 “무언가 바뀌었다”는 알림이며, 업데이트는 41·42·43 같은 순서 번호로 재정렬한다.
• 제품 전망: 현재 수 시간~하루인 작업이 수 주~수개월 프로젝트로 늘어나며, 각 에이전트 기본 블록 영역에 다수의 스타트업과 수십억 달러 규모 자본이 몰릴 수 있다.

결론 및 시사점

1. 상시 작동 에이전트는 LLM 하나가 아니라 서버·큐·내구성 워크플로·VM·브라우저·파일 메모리·도구 하네스의 결합이다.
2. 프로세스를 24시간 켜 두는 대신 상태를 저장하고 필요할 때 복원해야 지속성과 비용 효율을 동시에 얻는다.
3. 한 대화의 컨텍스트를 키우는 것보다 파일·하위 에이전트·요약·검색으로 메인 컨텍스트를 작게 유지하는 편이 장기 품질에 유리하다.
4. 모든 도구를 한 번에 설명하지 말고 이름을 먼저 노출한 뒤 필요한 상세만 동적으로 불러오면 모델의 작업 공간과 프롬프트 캐시를 지킬 수 있다.
5. 에이전트에게 가능한 한 실제 컴퓨터를 주되, 커넥터·API·접근성 트리·픽셀 클릭을 비용·신뢰성 순서로 사용하고 사람에게 묻는 단계는 마지막에 둔다.
6. 이메일·결제·로그인·외부 입력은 자동 검토·출처 표시·비밀 분리·사용자 승인으로 신뢰 경계를 명확히 해야 한다.
7. 장기 실행을 가능하게 하는 durable workflow와 멱등 단계가 없으면 서버 장애가 작업 중복과 데이터 손상으로 이어진다.
8. 제품 팀은 매일 실패를 eval로 만들고 하네스를 고치며, 몇 달 단위로 새 모델을 훈련하는 안팎의 플라이휠을 운영해야 한다.
9. 모델이 빠르게 좋아질수록 복잡한 고정 UI보다 단순한 인터페이스와 교체 가능한 아키텍처가 오래 간다.
10. 실무자는 작은 터미널 에이전트에 서버·컴퓨터·메모리를 하나씩 붙여 보고, 동시에 LLM의 학습·추론·컨텍스트 원리를 공부해야 한다.

20줄 핵심 요약

상시 작동 에이전트는 터미널을 닫아도 서버에서 살아 있는 장기 작업 동료다.

기존 주차 1 에이전트는 모델과 도구를 루프로 연결하지만 터미널이 닫히면 작업도 멈춘다.

개발 흐름은 복사·붙여넣기에서 터미널 에이전트와 전용 앱을 거쳐 상시 작동 방식으로 이동했다.

상시 작동 에이전트는 자체 Linux 컴퓨터와 브라우저·파일·로그인을 갖고 충돌 뒤 상태를 복원한다.

사용자 메시지뿐 아니라 일정·웹훅·Slack·이메일·전화·회의·다른 에이전트가 작업을 깨운다.

라우터는 중복 이벤트를 제거하고 대화별 큐를 만들어 한 번에 하나의 turn을 실행한다.

직접 보낸 정정 메시지는 현재 작업을 멈추고 그룹 대화와 루틴 보고서보다 높은 우선순위를 가진다.

에이전트는 모든 진척을 알리지 않고 중요한 결과·예외·승인 요청이 있을 때만 조용히 돌아온다.

Firecracker VM은 유휴 시 파일·메모리·디스크·로그인을 스냅샷으로 저장하고 필요할 때 복원한다.

서버와 VM을 분리하면 앱스토어 배포 없이 업데이트하고 VM 보안 패치도 작업 루프와 독립해 처리한다.

내구성 워크플로는 서버 충돌 뒤 완료된 단계를 반복하지 않고 마지막 단계부터 재개한다.

메인 에이전트는 사용자와 빠르게 대화하고 셸·브라우저·영상·코딩 헬퍼에게 큰 작업을 넘긴다.

도구는 이미 아는 정보, API·MCP, 웹 검색, 브라우저, 데스크톱 순으로 가장 싸고 안정적인 수단을 먼저 쓴다.

접근성 트리와 페이지 구조는 스크린샷보다 효율적이며 로그인·CAPTCHA·결제는 사람에게 넘긴다.

도구 이름만 먼저 주고 상세 스키마를 필요할 때 불러오면 컨텍스트 공간과 비용을 아낄 수 있다.

프로필·날짜별 로그·단기 노트·검색 가능한 파일을 계층화하면 긴 대화도 작은 컨텍스트로 유지된다.

프롬프트 앞부분을 고정하고 캐시를 데우며 200,000토큰 한계 전에 압축해야 장기 작업이 저렴하고 안정적이다.

외부 텍스트는 신뢰할 수 없는 입력으로 표시하고 비밀번호는 모델 밖에 두며 위험 작업은 자동 검토한다.

실패한 행동은 매일 eval로 전환되고 새 모델은 그 평가를 학습해 제품과 모델을 함께 개선한다.

엔지니어는 작은 에이전트에 서버·컴퓨터·메모리를 붙여 보며 아키텍처와 LLM 기본 원리를 함께 익혀야 한다.