Stanford CS146S: How always-on agents work

메타데이터

• 강연 제목: How Always-On Agents Work
• URL: https://youtu.be/L1OBRtfPS34
• 발행일: 2026-10-11
• 처리일: 2026-10-25
• 채널: Lee Robinson / leerob
• 발표자: Lee Robinson
• 영상 길이: 45분 17초
• 자막 언어: 영어 자동 자막. 겹쳐 나오는 캡션 조각을 문맥에 따라 합쳐 읽었으며, 일부 타임스탬프는 샘플링 과정의 흔적으로 정확한 시간 표기로 사용하지 않았다.
• 강연 맥락: Stanford CS146S 강의. 발표자는 SpaceX에서 진행 중인 작업을 포함해 상시 실행형 에이전트의 아키텍처와 구현 원리를 설명한다.

---

📌 핵심 질문: 에이전트를 ‘요청할 때만 답하는 도구’에서 ‘계속 일하는 동료’로 만들려면 무엇이 필요한가?

기본적인 에이전트 하네스(harness)는 모델이 도구를 호출하고 결과를 받아 다시 행동하는 루프다. 그러나 이를 노트북의 터미널 안에만 두면 컴퓨터를 닫을 때 프로세스가 멈춘다. Lee Robinson은 에이전트를 클라우드 서버와 별도 Linux 컴퓨터에서 실행하고, 외부 이벤트로 깨우며, 기억과 파일, 스킬, 내구성 워크플로를 제공해 사용자가 자리를 비운 동안에도 일하고 필요할 때만 보고하는 디지털 동료로 확장하는 방법을 설명한다.

핵심 설계는 모델 하나를 더 크게 만드는 데만 있지 않다. 오케스트레이터와 서브에이전트의 분업, 서버와 컴퓨터의 분리, 메시지 우선순위와 알림 판단, 파일 기반 기억, 동적 도구 발견, 프롬프트 캐시·컨텍스트 압축, 안전 검토, 장기 실행 평가를 함께 설계해야 한다. 시스템의 실제 능력은 모델과 하네스, 제품 인터페이스, 인프라가 결합되면서 결정된다.

• 기본 도구 호출 루프는 강력하지만, 장시간 지속·실패 복구·이벤트 대응·상태 기억에는 별도 구조가 필요하다.
• 상시 실행형은 항상 서버와 가상 머신을 켜 두는 구조가 아니라, 필요할 때 깨우고 상태를 저장한 뒤 다시 잠재울 수 있어야 한다.
• 사용자는 매 명령을 승인하는 병목에서 벗어나 에이전트를 대화로 조정하고, 시스템은 중요도에 따라 조용히 일하거나 확인을 요청해야 한다.
• 무한 컨텍스트는 실제로 존재하지 않으므로, 필요한 정보를 보존하면서 비용·캐시·기억 품질을 관리하는 컨텍스트 엔지니어링이 필수다.
• 에이전트가 오래 일할수록 권한·프롬프트 인젝션·비가역 행동·장기 평가가 핵심 제품 및 보안 문제로 커진다.

1. 터미널 도구 호출 루프에서 상시 실행형 에이전트까지

1.1. 도구를 반복 호출하는 하네스는 작지만 강력한 기본 단위다

1. 모델은 도구를 호출하고, 결과를 받아 다음 행동을 정한다.

   1. 강연 첫 부분에서 발표자는 수강생들이 이전 주에 만든 간단한 하네스를 상기시킨다. 모델이 도구를 호출하는 루프만으로도 모델이 직접 파일을 다루거나 일을 진행하는 능력이 크게 확장된다.
   2. 하지만 초기 형태는 터미널 세션과 사용자의 컴퓨터에 묶여 있다. 노트북을 닫으면 프로세스도 멈춰 이후의 작업이나 외부 이벤트에 반응하지 못한다.

2. 상시 실행형은 에이전트에게 독립된 실행 환경과 시간적 지속성을 준다.

   1. 에이전트는 사용자의 터미널 대신 서버·클라우드에서 실행될 수 있다. 사용자가 컴퓨터를 닫아도 계속 작동하고, 프로세스나 머신이 실패한 뒤 다시 시작할 수 있다.
   2. 에이전트는 개인 노트북을 공유하는 대신 자체 Linux 컴퓨터를 갖는다. 이 컴퓨터에는 데스크톱, 파일, 브라우저, 앱 등이 있고, 파일을 저장하며 작업 진척과 사용자의 작업 방식을 기억할 수 있다.
   3. 목표 시간도 짧은 질의응답에서 몇 시간·며칠을 넘어 몇 주·몇 달로 길어진다. 이를 위해서는 단일 프롬프트 루프 이상의 상태 보존과 복구 아키텍처가 필요하다.

3. 에이전트는 빠르게 답하는 것과 조용히 백그라운드에서 일하는 것을 구분한다.

   1. 매 메시지에 즉시 응답하는 터미널 봇과 달리, 상시 실행형은 동료처럼 항상 알림을 보내지 않고 조용히 작업할 수 있어야 한다.
   2. 중요한 진척이나 완료 시점에 업데이트를 주고, 사용자의 직접 입력 외에도 Slack 메시지, 이메일, 전화, 회의, 정기 루틴 같은 사건이 에이전트를 깨울 수 있다.
   3. 사용자는 긴 작업을 맡기고 다른 일을 하거나 잠들 수 있으며, 에이전트는 적절한 시점에 결과를 돌려준다.

1.2. 개발자와 AI가 일하는 방식은 네 단계로 이동했다

1. 1단계 — 복사·붙여넣기: ChatGPT가 만든 코드를 복사해 선택한 편집기에 넣는 방식이다. 발표자는 이 방식이 오래전처럼 느껴져도 실제로는 불과 몇 년 전의 일이라고 짚는다.
2. 2단계 — 터미널 하네스: 모델이 파일을 수정하고 셸 명령을 실행한다. 단순한 도구 인터페이스가 생기며 AI가 능동적으로 더 많은 일을 맡기 시작했다.
3. 3단계 — 에이전트 전용 앱과 병렬 작업: 에이전트를 전용 제품으로 감싸고 여러 에이전트를 동시에 실행하거나 클라우드에 둘 수 있게 됐다. 그러나 사용자는 매 셸 명령을 검토하고 승인해야 해 여전히 병목이었다.
4. 4단계 — 상시 실행형 에이전트: 에이전트가 자체 컴퓨터·기억·스킬을 가지고 백그라운드에서 지속적으로 일한다. 사용자는 명령을 한 줄씩 승인하기보다 진행 중인 에이전트의 방향을 대화로 조정한다.

1.3. 명령 승인에서 자연어로 조정하고, 안전은 별도 검토 계층으로 보완한다

1. 에이전트와의 대화는 한 번에 완성된 명령보다 이어지는 생각을 받아들인다.

   1. 사용자는 스레드에 대한 요청을 말하다가 “아, 그건 목요일에 해”라고 덧붙일 수 있다. 이전 세대 모델은 연달아 들어오는 말을 서로 무관한 명령으로 오해하기 쉬웠지만, 최근 모델과 하네스는 사람이 친구에게 말하듯 이어지는 지시를 함께 해석할 수 있다.
   2. 따라서 명령을 큐에 쌓아 두는 것뿐 아니라, 진행 중인 작업의 계획을 자연어로 수정하고 방향을 바꾸는 사용자 경험이 가능해진다.

2. Auto review는 실행 명령을 별도 모델이 확인하는 방식이다.

   1. 셸 명령이나 이메일·Slack 발송처럼 외부에 영향을 미칠 수 있는 행동을 별도의 AI 모델이 검토하도록 할 수 있다.
   2. 발표자는 사람이 수백 개 명령을 지켜보며 승인하는 데서 오는 피로보다 별도 모델의 검토가 더 안전할 수 있다고 주장한다. 자신이 언급한 블라인드 비교에서는 대부분의 경우 모델이 더 잘 검토했다고 설명하지만, 이는 강연자의 경험적 주장이지 보편적으로 입증된 안전 보장은 아니다.
   3. 모델이 좋아질수록 인터페이스는 오히려 단순해질 수 있다. 사용자는 명령줄 대신 문자 메시지로 에이전트에게 일을 맡기는 방식에 익숙해지고, 질문 답변이 아니라 동료에게 넘길 법한 긴 업무를 요청하게 된다.

2. 장시간 지속을 가능하게 하는 모델·도구·기억의 변화

2.1. 발표자가 꼽은 모델 및 하네스 역량의 변화

1. 더 긴 시간 동안 지시를 유지한다.

   1. 최근 1~2년간 모델은 오랫동안 지시를 따르며 혼란과 실수를 줄이는 능력이 좋아졌다고 발표자는 평가한다.
   2. 컨텍스트 압축과 요약이 적절히 이루어지면 몇 시간 또는 며칠 동안 작업을 이어갈 수 있다. 장기간 실행의 성능은 모델 능력만이 아니라 기억을 압축하고 다시 불러오는 하네스에도 달려 있다.

2. 서브에이전트(sub-agent)에 일을 넘긴다.

   1. 주 에이전트의 작업 기억은 언젠가 컨텍스트 한계에 닿는다. 큰 셸 작업이나 비용이 큰 도구 호출을 별도 도우미에게 맡기면, 그 도우미는 새로운 작업 기억으로 일을 수행한다.
   2. 도우미는 필요한 작업을 마친 뒤 결과만 주 에이전트에 보고한다. 이렇게 하면 주 대화가 도구 출력으로 부풀지 않아 사실상 더 넓은 작업 공간이 생기지만, 모델의 컨텍스트 창 자체가 무한해지는 것은 아니다.

3. 도구 호출 신뢰성과 컴퓨터 사용 능력이 좋아진다.

   1. 과거에는 모델이 도구를 제대로 호출하지 못하고 자주 환각했다고 회고한다. 발표자는 현재는 환각이 대부분 해결된 문제처럼 다뤄진다고 말하지만, 여기서도 “대부분”이라는 본인의 낙관적인 평가로 이해해야 한다.
   2. 에이전트에게 셸·파일뿐 아니라 전체 Linux 컴퓨터를 제공할 수 있다. 화면을 보고 클릭하며 사람처럼 컴퓨터를 조작하는 computer use가 발전하면서 API나 MCP 서버를 제공하지 않는 SaaS와 웹사이트도 브라우저·데스크톱을 통해 자동화할 수 있다.
   3. 데모 영상 제작처럼 여러 도구를 묶어 수행하는 작업도 가능해진다. 컴퓨터를 직접 다루는 범위가 넓어질수록 격리·권한·보안 설계가 더 중요해진다.

4. 파일은 검색 가능한 장기 기억과 절차 지식의 저장소가 된다.

   1. 사용자의 선호·프로필처럼 매번 참고할 정보를 기록하고, 날짜별 작업 일지를 저장할 수 있다. 사용자가 “지난주에 무엇을 했지?”라고 물으면 모델은 파일을 검색해 필요한 맥락을 찾는다.
   2. 모델은 Linux 명령을 사용해 파일을 grep하고 탐색할 수 있으므로, 모든 기록을 매 프롬프트에 넣지 않아도 된다.
   3. 특정 작업의 절차와 성공·실패 요인을 Markdown 문서로 인코딩하면 재사용 가능한 스킬이 된다. 강연자는 이메일 작성이나 API 구축 같은 스킬 생태계와, 스킬 또는 서버를 설치해 도구를 연결하는 플러그인 사례를 언급한다.
   4. cron과 같은 스케줄로 프롬프트를 실행하는 루틴도 반복 업무를 처리하는 수단이다. 모델이 그 자리에서 아는 내용, 파일에 저장된 기억, 스킬, 주기 실행 루틴이 함께 에이전트의 역량을 구성한다.

2.2. 문자 대화 뒤에 있는 서버·에이전트·컴퓨터의 수명주기

1. ‘항상 켜져 있음’은 자원을 항상 켜 둔다는 뜻이 아니다.

   1. 다이어그램의 시작 상태에서는 서버와 에이전트용 컴퓨터가 모두 잠들어 있다. 사용자의 메시지나 외부 트리거가 들어오면 서버가 에이전트 상태를 불러와 실행하고, 작업에 브라우저나 데스크톱이 필요할 때만 컴퓨터도 켠다.
   2. 작업이 끝나면 서버와 컴퓨터를 다시 잠재울 수 있다. 모든 사용자의 가상 컴퓨터를 24시간 켜 두면 비용이 크고, 필요한 자원을 전부 상시 가동하기도 어렵기 때문이다.
   3. 대화 로그, 기억, 루틴 등 상태는 데이터베이스나 스토리지에 저장된다. 즉 상시성은 지속 가능한 상태와 재개 능력에 있고, 전산 자원의 연속 가동에 있지 않다.

2. 트리거 라우터는 여러 사건을 합치고 알림의 필요성을 판별한다.

   1. 직접 메시지 외에도 Slack 멘션, 이메일, 전화, 회의 참여, 시간이 오래 걸린 백그라운드 작업, 예약 루틴 등이 에이전트를 깨울 수 있다. SpaceX에서 직원 대신 회의에 참여해 기록을 남기는 봇 사례도 소개한다.
   2. 라우터는 중복 이벤트를 제거하고 대화를 어디에 넣을지 결정한 뒤, 사용자를 지금 깨워야 하는지 판단한다. 동료가 일이 조금 진척될 때마다 알림을 보내면 성가시듯, 에이전트도 모든 진행 상황을 보고해서는 안 된다.
   3. 작업에 따라 하루 한 번 정도의 상태 보고가 적절할 수 있지만, 간격은 업무와 사용자의 필요에 따라 달라진다. 침묵과 개입의 기준은 아직 정답이 확정된 문제가 아니다.

3. 에이전트용 컴퓨터는 Firecracker 가상 머신으로 격리하고 재사용한다.

   1. 발표자는 별도 Linux 환경을 Firecracker VM으로 실행하는 예를 든다. VM 상태를 스냅샷해 끄고 다시 켤 수 있고, 파일·명령 실행·Chrome 브라우저를 제공하며, 사용자가 원하면 실시간 화면을 확인하거나 직접 제어할 수 있다.
   2. 에이전트마다 브라우저가 따로 필요한 경우를 위해 가상 데스크톱을 나눌 수 있다. 봇 5개나 10개가 각각 다른 화면을 사용하도록 하는 식이며, 여러 에이전트가 공용 컴퓨팅 인프라를 호출한다.
   3. 개인 노트북과 별도인 잠금된 환경에서 작업하는 것은 실수나 오염을 사용자 장치에서 격리하는 장점이 있다. 격리는 보안의 한 계층이지, 다른 안전 장치가 불필요하다는 뜻은 아니다.

2.3. 얇은 클라이언트와 두꺼운 서버를 분리한다

1. 서버가 에이전트 루프와 상태를 맡고, 클라이언트는 입력과 표현을 맡는다.

   1. 여러 앱이나 Slack·이메일 같은 이벤트가 서버를 깨우고, 서버는 큐를 통해 에이전트 루프로 요청을 보낸다. 모델은 도구를 호출해 일을 한 뒤 상태를 데이터베이스에 저장한다.
   2. 사용자 앱은 서버에 구독을 걸고 변경 신호를 받으면 최신 상태를 다시 가져온다. 재시도 때문에 같은 메시지가 중복으로 보이지 않도록 중복 제거를 할 수도 있다. 발표자는 메시지를 보냈을 때 클라이언트가 즉시 접수 사실을 보여 주고, 이후 서버 상태와 동기화하는 분산 시스템 설계의 예를 간단히 언급한다.
   3. 에이전트 루프를 VM 안에 넣으면 VM을 독립적으로 종료·교체하기 어렵다. 서버 쪽에 루프와 장기 상태를 두면 Linux VM에 긴급 업데이트가 필요할 때 VM만 다시 만들고 앱 전체의 다운타임을 줄일 수 있다.

2. 두꺼운 서버는 배포·연산·확장에 유리하다.

   1. 에이전트 코드를 바꾸려고 매번 모바일 앱스토어 업데이트를 배포하는 것보다 서버 코드를 빠르게 업데이트하는 편이 편리하다.
   2. 음성 전사나 이미지 생성처럼 무거운 연산은 장치에 따라 서버가 더 빠를 수 있다. 서버는 변동하는 트래픽과 성장에 대응해 확장하는 검증된 방식이 있다.
   3. 발표자는 시스템을 트리거 영역, 중앙 서버, 오른쪽의 에이전트 컴퓨터로 나누어 설명한다. 컴퓨터는 파일·명령·브라우저를 제공하고, 서버는 상태·큐·모델 루프·서비스 통합을 담당한다.

3. 내구성 워크플로는 실패 뒤 처음부터 재생하지 않게 한다.

   1. 단순 작업 큐는 단계 1→2→3으로 진행하던 중 인프라 문제가 생기면 재시작할 때 이전 단계를 다시 실행해야 할 수 있다. 이미 보낸 요청이나 완료한 계산이 다시 수행되면 중복·비용 문제가 발생한다.
   2. 내구성 워크플로(durable workflow)는 진행 상태를 저장해 실패 후 재시작 시 완료된 지점을 건너뛰고 다음 단계부터 이어간다. 발표자는 이를 직접 처음부터 구현하는 대신 오픈소스 Temporal을 사용한다고 말한다.
   3. 각 요청 유형에는 우선순위를 둘 수 있다. 사용자가 진행 중인 에이전트에게 직접 “일정 날짜를 바꿔”라고 말하면 그 요청이 다른 작업보다 우선하도록 루프를 멈추거나 방향을 바꾼다.
   4. 그룹 채팅, Slack 스레드, 정기 루틴 등 나머지 이벤트는 큐 뒤에 놓을 수 있다. 메시지 3~4개가 빠르게 연속 도착하면 내용을 묶어 한 턴으로 처리하는 방식도 가능하며, 구체적인 우선순위와 묶음 규칙은 제품이 정할 수 있다.

3. 사용자 경험과 도구를 설계하는 하네스

3.1. 클라이언트와 서버 사이의 대화 통로를 하나로 단순화한다

1. 클라이언트가 사용하는 단일 도구는 send to user다.

   1. 강연에서 소개하는 하네스는 클라이언트와 서버 사이에 여러 기능별 통신 도구를 두기보다, 서버가 사용자에게 메시지를 보내는 단일 통로를 둔다.
   2. 무거운 작업은 서버 도구가 맡는다. 셸 명령과 파일 읽기뿐 아니라 클라우드 에이전트 실행, 화면 녹화, 데모 제작 등 여러 능력을 연결할 수 있다.
   3. 같은 서버를 모바일 앱, 데스크톱 앱, 이메일, Slack 등 서로 다른 클라이언트에서 사용할 수 있다. 클라이언트가 해야 할 일은 서버와 메시지를 주고받는 단순한 기능으로 줄어든다.

2. 응답 표현은 클라이언트가 상황에 맞게 풍부하게 구성한다.

   1. 로그인 요청이면 일반 텍스트 대신 전용 로그인 폼을 보여 주고 1Password 같은 도구와 연결할 수 있다.
   2. 결제 상황에는 Stripe Link, XMoney 등 서비스에 연결하는 사용자 인터페이스를 제시할 수 있다.
   3. 이메일이나 Slack 메시지 발송처럼 되돌리기 어려운 행동은 초안을 보여 주고 사용자가 수정·승인하게 할 수 있다. 반응만 남겨도 충분한 상황이라면 이모지 버튼처럼 간단히 처리할 수도 있다.
   4. 같은 send to user 결과라도 클라이언트가 로그인·결제·승인 등 상호작용 형태로 바꾸므로, 서버의 단순한 대화 통로가 다양한 제품 경험을 지원한다.

3.2. 동적 도구 발견으로 컨텍스트 창을 도구 설명에 잠식당하지 않게 한다

1. 가능한 모든 도구 설명과 스키마를 매 요청에 다 넣으면 작업 공간이 줄어든다.

   1. 모델의 컨텍스트 창은 작업 기억의 한계가 있다. Google Drive, Gmail, YouTube 같은 커넥터와 MCP 서버를 계속 추가하면서 모든 도구의 이름·스키마·설명을 보내면 상당량의 컨텍스트가 대화에 쓰이지 못한다.
   2. 도구 설명이 길수록 사용량과 비용이 늘고, 모델이 실제 문제를 해결하는 데 쓸 수 있는 공간이 감소한다.

2. 도구 이름을 먼저 알리고 필요한 세부 정보만 나중에 불러온다.

   1. 동적 컨텍스트(dynamic context) 방식에서는 매번 도구의 이름 정도만 제공하고, 모델이 특정 도구를 선택했을 때 세부 정보를 파일이나 파일 시스템에서 읽게 한다.
   2. 도구가 많아도 사용 중인 것만 컨텍스트에 넣을 수 있으므로 토큰 사용과 비용을 줄이고 실제 작업에 더 많은 여유를 준다.
   3. 강연의 표기에는 “MTP server”로 들리는 부분이 있으나, 문맥상 여러 서비스 도구를 제공하는 “MCP server”를 가리키는 것으로 정리했다.

3. 가능하면 가장 저렴하거나 신뢰도 높은 정보 접근 방식부터 단계적으로 시도한다.

   1. 첫째, 대화 안에 이미 있는 정보와 에이전트가 현재 기억하는 맥락을 사용한다.
   2. 둘째, 플러그인·서버·API를 통해 필요한 서비스를 조회한다. 예를 들어 Plaid 연결로 은행 정보를 가져올 수 있다.
   3. 셋째, 정보가 없다면 웹 검색을 한다. 예를 들어 전날 Cubs 경기 점수를 찾는다.
   4. 넷째, API나 검색만으로 부족하면 에이전트 컴퓨터에서 브라우저를 열어 웹페이지를 사용한다.
   5. 다섯째, 스크립트·셸 명령·전체 데스크톱 조작이 필요한 경우에만 컴퓨터를 직접 사용한다.
   6. 마지막으로 위 방법이 실패하거나 사용자만 제공할 수 있는 정보·승인이 필요할 때 사용자에게 묻는다. 동료에게 맡긴 일처럼, 가능한 일을 먼저 시도해 보고 꼭 필요한 경우에만 사용자를 방해하는 원칙이다.

3.3. 브라우저와 데스크톱을 읽는 세 가지 방법

1. 화면 전체 스크린샷은 직관적이지만 시각 정보가 많아 토큰과 분석 비용이 커질 수 있다.
2. HTML 구조를 읽으면 페이지 요소와 내용을 얻을 수 있지만, 모든 웹사이트의 구조가 일관된 것은 아니다.
3. **접근성 트리(accessibility tree)**는 버튼·링크 등 상호작용 요소를 간결히 찾도록 해 토큰을 아끼고 클릭 대상을 정하는 데 유용하다.
4. 픽셀 클릭은 앞선 정보만으로 해결되지 않을 때 쓰는 마지막 자동화 수단이다. 모달·대화상자처럼 특정 위치를 클릭해야 하는 페이지도 있기 때문이다.
5. 2단계 인증·CAPTCHA 등 자동화가 넘기 어려운 벽이 나오면 사용자에게 돌아가 코드 입력이나 승인을 요청해야 한다. 이는 도구 선택 사다리의 마지막 단계다.

3.4. 주 에이전트의 컨텍스트는 간결하게, 비싼 작업은 도우미에게 넘긴다

1. 주 에이전트는 오케스트레이터이고, 서브에이전트는 작업 전문 도우미다.

   1. 주 에이전트 대화는 가능한 한 간결하게 유지하고, 셸 명령을 많이 실행하거나 비용이 큰 도구를 쓰는 일은 별도의 도우미에 맡긴다.
   2. 도우미가 많은 중간 출력과 작업 과정을 가져가고 최종 결과만 돌려주면 주 에이전트의 컨텍스트가 불필요하게 커지지 않는다. 제품은 무한 컨텍스트처럼 느껴질 수 있지만 모델의 실제 컨텍스트 창에는 여전히 한계가 있다.

2. 도우미도 실패 후 재개할 수 있는 내구성 워크플로로 운영한다.

   1. 각 도우미는 자기 스킬과 별도 실행 상태를 가진다. 영상 도우미가 메모리 부족 등으로 중단되어도 진행을 보존하고 이어서 할 수 있다.
   2. 주 에이전트는 동료처럼 할 일 목록을 관리한다. 사용자는 진행 상황을 확인하고 메시지를 보내거나 도우미를 중지할 수 있다.
   3. 이 구조는 복잡한 문제를 맡은 엔지니어 팀을 확장하는 방식과 유사하다. 역할을 나누되 오케스트레이터가 전체 목표와 결과를 관리한다.

3. 범용 셸 도구와 전용 도구 사이에는 효율·가독성의 절충이 있다.

   1. 셸 명령 하나로 많은 기능을 구현할 수 있지만, 특정 작업에서 모델 시간의 90%가 같은 셸 작업에 쓰인다면 일부를 전용 도구로 분리하는 편이 더 효율적일 수 있다.
   2. 전용 도구는 사람이 제품 동작을 검토할 때도 더 읽기 쉽다. 어떤 추상화가 좋은지는 호출 비중과 검토 가능성을 함께 보고 결정해야 한다.
   3. 에러 메시지를 사람에게 자세히 설명하면 사람뿐 아니라 모델에게도 도움이 된다. 실패 원인과 다음 행동을 설명하는 오류 메시지는 에이전트의 복구 능력을 개선하는 개발자 경험(DX)의 일부다.

4. 장기 실행을 위한 신뢰·보안·외부 행동 승인

4.1. 사용자 기기와 격리된 컴퓨터를 주더라도 안전이 자동으로 해결되지는 않는다

1. 별도 VM은 작업 영역을 분리하지만, 에이전트 권한 자체는 계속 통제해야 한다.

   1. 사용자의 컴퓨터를 오염시키지 않는 별도 머신은 중요한 격리 계층이다.
   2. 그렇더라도 장기간 일하는 봇에게 정보 접근과 명령 실행을 맡기려면, 어떤 명령이 실제로 실행되는지 검토하는 장치가 필요하다. 발표자는 셸 명령마다 auto review를 적용하는 예를 든다.

2. 외부 입력과 사용자 지시는 같은 신뢰 수준으로 취급하지 않는다.

   1. 받은 이메일이나 웹훅에는 피싱 또는 악의적 문구가 있을 수 있다. 이를 모델에게 전달할 때 사용자 지시인 것처럼 해석하면 프롬프트 인젝션(prompt injection)에 취약해질 수 있다.
   2. 이메일·웹페이지의 텍스트는 우선 불신 가능한 데이터로 취급하고, 실제 사용자 명령과 분리하는 방어가 필요하다. 발표자는 업계에 이 문제를 해결할 일이 여전히 많다고 강조한다.

3. 되돌릴 수 없는 행동과 비밀정보에는 별도 경계를 둔다.

   1. 이메일·Slack 발송처럼 되돌릴 수 없는 행동은 사용자에게 초안을 보여 주고 확인을 받는 흐름이 적절하다.
   2. 비밀번호 등 비밀 값은 모델 대화에 직접 노출되지 않도록 제품 내부의 별도 절차로 처리할 수 있다.
   3. 보안은 상시 실행형 에이전트가 신뢰받기 위한 지속 과제다. 사용자 승인, 별도 모델 검토, 비밀정보 격리, 입력 신뢰도 구분을 함께 고려해야 한다.

5. 컨텍스트 엔지니어링: 프롬프트 캐시와 압축·기억

5.1. 프롬프트 캐시는 장시간 대화의 비용과 지연을 좌우한다

1. 새 메시지를 보낼 때 대화의 상당 부분은 다시 전달된다.

   1. 에이전트에 새 메시지 하나를 덧붙여도 모델 호출에는 이전 대화와 시스템 프롬프트, 도구 설명을 함께 보내는 형태가 된다.
   2. 이미 처리한 토큰을 캐시할 수 있으면 모델 가격이 크게 낮아질 수 있다. 따라서 긴 대화에서는 프롬프트 캐시(prompt cache)를 가능한 오래 따뜻한 상태로 유지하는 것이 중요하다.

2. 고정된 프롬프트 접두부가 캐시를 살린다.

   1. 도구 정의와 시스템 프롬프트 등 반복되는 부분을 요청 사이에 최대한 동일하게 유지하고, 새로 들어오는 메시지만 바뀌게 한다. 그러면 캐시되지 않은 비용은 새 메시지의 차이에 집중된다.
   2. 턴 진행 도중 새 도구를 넣거나 빼지 않고, 긴 도구 스키마를 줄이는 편이 좋다. 시스템 프롬프트에 새 항목을 넣을 때도 섹션 순서를 고정하고 버전·해시를 관리해 캐시가 불필요하게 깨지지 않게 할 수 있다.
   3. 채팅 창을 열거나 사용자가 입력을 시작할 때 서버가 프롬프트를 미리 준비해 캐시를 데우는 방법도 있다. 웹페이지 링크 위에 마우스를 올렸을 때 다음 페이지를 미리 가져오는 프리페치와 비슷한 발상이다.

3. 캐시 미스는 장기 에이전트의 비용을 키우는 운영상 버그처럼 다룬다.

   1. 발표자는 그해 1월 OpenClaw 사용이 모델 제공자의 구독 플랜과 결합해 확산되던 때를 언급한다. 상시 에이전트라는 새 사용 패턴을 기존 제공자와 하네스가 충분히 최적화하지 못해 캐시 미스가 많았고, 이를 줄이기 위한 수정이 필요했다고 설명한다.
   2. 그래서 프롬프트의 고정 순서, 안정적인 도구 목록, 사전 캐시 워밍 같은 여러 작은 최적화를 더한다. 이런 최적화는 각각 작아도 장시간 토큰 사용량과 모델 응답 품질에 누적 효과를 낸다.
   3. ‘OpenClaw’의 대소문자·제품 표기는 자동 자막에 분절되어 있었으나, 이 부분은 문맥상 해당 이름으로 읽었다. 강연은 당시의 구체적 날짜 연도를 별도로 명시하지 않으므로 “그해 1월”로만 기록한다.

5.2. 컨텍스트 압축은 손실이 있는 정보 선택 문제다

1. 긴 대화는 언젠가 요약·압축해야 한다.

   1. 예를 들어 모델 컨텍스트 창이 20만 토큰이어도 대화를 계속 이어가면 한계에 도달한다. 대화가 10만 토큰을 넘은 상황도 가정한다.
   2. 장기 작업에서는 대화를 줄이는(compaction) 일이 반복된다. 모든 압축은 정보를 잃으므로, 어떤 사실을 보존하고 무엇을 버릴지 결정하는 알고리즘이 어렵다. 발표자는 이 문제만으로도 박사 학위 연구가 가능할 만큼 까다롭다고 말한다.

2. 가능하면 캐시가 따뜻할 때 압축을 실행한다.

   1. 제공자별 캐시 유지 시간은 10분일 수도, 60분일 수도 있다고 설명한다. 긴 대화 직후 사용자가 다른 일을 하러 가기 전에 압축하면, 캐시가 유효한 동안 계산해 다음 세션의 시작 비용을 줄일 수 있다.
   2. 사용자가 30분 뒤 돌아오면 전체 원문보다 압축된 요약부터 대화를 이어간다. 장기 대화 요약의 품질과 비용을 함께 관리하는 실무 팁이다.

3. 기억은 지속성·회상 빈도에 따라 층위를 나눈다.

   1. 핵심 사실: 사용자의 지속적인 선호처럼 매번 적용되어야 하는 정보다. 예를 들어 사용자가 항상 소문자 메시지를 원한다면 매 요청에 반영되어야 한다.
   2. 날짜가 붙은 기록: 과거 대화와 작업의 이력을 보관한다. 특정 질문이 관련될 때 검색해 회상한다.
   3. 임시 스크래치패드: 지금 진행 중인 일처럼 다음 30분이나 한 시간 정도만 필요한 내용을 적고, 중요성이 사라지면 버린다.
   4. 그 외의 자세한 지식은 파일에 저장해 필요할 때 찾아본다. 인간의 기억이 현재 문맥과 장기 기억을 구분하는 것처럼, 하네스도 정보를 모두 매번 넣지 않고 관련성에 맞춰 유지해야 한다.

4. 긴 출력과 비싼 작업은 파일과 서브에이전트로 컨텍스트 밖에 둔다.

   1. 긴 도구 출력을 주 대화에 통째로 넣기보다 파일로 저장하고, 모델이 필요할 때 그 파일을 읽게 한다.
   2. 스크린샷 분석처럼 비용이 큰 작업은 서브에이전트로 넘기고 요약만 가져온다.
   3. 대화 중 불필요한 정보를 계속 정리하는 ‘컨텍스트 가드닝’은 비용뿐 아니라 회상 정확도와 성능 유지에도 중요하다.

6. 학습·평가 플라이휠과 제품의 빠른 재설계

6.1. 모델 학습의 각 단계가 에이전트 사용 능력에 기여한다

1. **사전학습(pre-training)**은 대규모 인터넷 텍스트나 다른 데이터에서 일반적인 세계 지식을 학습하는 단계다.
2. **지도 미세조정(SFT)**은 대화 도우미나 에이전트처럼 특정 방식으로 행동하는 예를 보여 주는 단계다. 하네스 안에서 사용할 수 있는 도구를 이해하도록 예시를 학습시키는 것이 도움이 된다.
3. **강화학습(RL)**은 과제를 수행하고 더 나은 결과를 내는 행동을 익히는 단계다. 장기 지시를 따르고, 수백 개의 스킬 중 적절한 것을 고르며, 브라우저에서 클릭할 위치를 정하는 능력을 훈련할 수 있다.
4. 추론(inference) 운영도 제품 설계 변수다. 사용자와 대화하는 주 에이전트는 빠른 응답이 중요하지만, 장시간 작업을 맡은 도우미는 10분과 12분의 차이가 상대적으로 작을 수 있다. 용도에 따라 지연·품질·비용의 최적점을 다르게 정할 수 있다.

6.2. 매일의 제품 수정과 주기적인 모델 학습이 서로를 개선한다

1. 내부 루프 — 실패를 평가 항목으로 바꾸고 제품을 고친다.

   1. 에이전트가 실행하면 안 되는 도구를 호출하는 등 실패를 발견하면 이를 평가(evaluation) 사례로 만든다.
   2. 팀은 하네스 버그, 프롬프트, 도구 연결 또는 추론 문제를 수정하고, 평가에서 실제로 고쳐졌는지 확인한 다음 배포한다.
   3. 제품팀은 매일 버그를 찾고 수정하고 평가하는 루프를 돌려, 해당 제품에서 중요한 행동을 조금씩 개선한다.

2. 외부 루프 — 다음 모델이 누적된 실패에서 배운다.

   1. 매달 또는 몇 달마다 새 모델을 훈련해 기존 실패와 평가 사례를 반영하고, 중요 지표가 좋아졌는지 확인한다.
   2. 개선된 모델은 제품에서 전에는 어려웠던 사용 방식을 가능하게 할 수 있다. 예를 들어 여러 봇이 그룹 채팅에서 대화하는 방식은 새로운 사용 형태여서, 서로 대화하는 에이전트의 적절한 행동을 학습하고 평가해야 한다.
   3. 발표자는 이 다중 봇 사용에서 잘못된 사례로 “Multibook” 또는 “Hugging Face incident”로 들리는 사례를 거론하지만, 자막에는 이름과 사건 내용이 충분히 분명하지 않다. 구체적인 사고 원인이나 세부를 추정하지 않는다.

6.3. “제품을 지워라”: 현재 모델의 한계를 미래의 고정 조건으로 만들지 않는다

1. 현재 모델이 앞으로 가장 성능이 낮은 모델일 수 있다고 가정한다.

   1. 발표자는 Cursor에서, 그리고 현재 SpaceX에서 공유하는 원칙으로 “delete the product”를 소개한다. 모델의 능력이 발전하면 지금의 사용자 인터페이스와 제품 가정이 맞지 않게 될 수 있다는 뜻이다.
   2. 강연자가 설명한 하네스·컨텍스트 엔지니어링도 6개월 전 또는 1년 전과 비교해 크게 달라졌다. 그래서 6개월 뒤에는 화면을 상당 부분 다시 만들어야 할 수도 있다.

2. 다음 세대 모델을 위해 가능한 한 단순한 인터페이스를 만든다.

   1. 제품은 모델이 생각하고 행동하도록 돕되, 지금 모델의 단점만을 전제로 복잡한 UI를 쌓아 두지 않아야 한다.
   2. 모델이 다음 단계로 나아갈 때 적은 비용으로 고치거나 없앨 수 있도록, 제품 설계는 단순함과 변경 가능성을 중시해야 한다.

7. 앞으로의 방향과 아직 풀리지 않은 문제

7.1. 몇 주·몇 달 일하는 디지털 동료로 확장된다

1. 현재의 몇 시간·하루 작업이 몇 주·몇 달로 늘어날 수 있다.

   1. 발표자는 향후 몇 달에서 1년 사이 에이전트가 훨씬 긴 기간 일할 수 있다고 전망한다.
   2. 과거 대화에서 필요한 정보를 더 잘 회상하는 모델, 그래프·파일 등 개선된 기억 표현, 사람을 온보딩하듯 도구를 모두 연결하는 디지털 동료가 가능성으로 제시된다.
   3. 조직이 에이전트에게 사람에게 주는 수준의 도구 접근을 허용하는 데는 신뢰와 보안 문제가 있으므로, 기업이 받아들이기까지 더 많은 작업이 필요하다.

2. 인터페이스는 더 쉬워지고, 음성 대화가 선택지로 늘 수 있다.

   1. 일부 사용자는 봇과 텍스트보다 음성 대 음성(speech-to-speech)으로 대화하고 싶어 할 수 있다.
   2. 발표자는 하루 종일 말할 수 있는 미래형 개인 기기를 가정하며 “Johnny Ive device”를 언급한다. 이는 구체적으로 발표된 제품이라기보다 음성 인터페이스 가능성을 설명하는 가벼운 예측이다.

3. 현장 업무를 스킬로 바꾸고 기업의 암묵지를 문서화한다.

   1. 모델과 제품은 일하면서 새로운 스킬을 배우고 이를 파일·지시·스킬 문서로 기록하는 능력이 좋아질 수 있다.
   2. 기업과 사람도 자기 조직의 특수한 절차(bespoke process)를 더 잘 문서화해 에이전트가 읽고 재사용할 수 있도록 만들 필요가 있다. 원시 모델 지능만으로는 조직 고유의 일을 수행할 수 없으며, 지식이 읽을 수 있는 절차로 바뀌어야 한다.

7.2. 장기 에이전트의 평가와 보안은 모델 출시 속도와 긴장 관계에 있다

1. 한 달짜리 에이전트와 매달 배포되는 모델은 검증 주기가 맞지 않을 수 있다.

   1. 에이전트가 한 달 동안 일하는데 모델이 매달 교체된다면 새 모델이 장기 작업 전체에서 안전하고 정확한지 배포 전에 충분히 평가하기 어렵다.
   2. 업계는 더 나은 장기 평가 방법을 만들거나, 평가가 따라잡을 때까지 모델 출시 속도를 늦추는 선택을 고민해야 한다. 발표자는 이를 앞으로 해결해야 할 문제로 본다.

2. 에이전트 인프라의 보안에는 여전히 큰 공백이 있다.

   1. 기억 시스템뿐 아니라 하네스와 실행 인프라를 공격자가 장악하지 못하도록 보호하는 연구와 엔지니어링이 필요하다.
   2. 특히 외부 이메일·웹훅의 프롬프트 인젝션을 차단하고, 자격 증명을 보호하며, 작업 공간을 격리하는 일은 에이전트가 오래 작동할수록 더 중요해진다.

3. 능동성과 성가심 사이의 경계를 정해야 한다.

   1. 수업에 빠진 사용자를 위해 회의 녹음을 남기고 노트를 정리해 두었다가 알려 주는 것은 유용할 수도 있지만, 원치 않는 개입으로 느껴질 수도 있다.
   2. 언제 조용히 기다리고 언제 먼저 알려야 하는지 정하는 휴리스틱은 아직 완벽하지 않다. 유용한 선제성(proactivity)과 과도한 알림 사이의 균형을 제품이 학습해야 한다.

4. 토큰 사용량이 커지는 만큼 추론·모델·하네스 효율이 중요해진다.

   1. 발표자는 다음 해에 전 세계 토큰 사용량이 크게 늘어날 것이라고 전망한다.
   2. 더 많은 모델 호출을 감당하려면 추론 비용, 모델 효율, 도구 호출, 컨텍스트 사용을 함께 최적화해야 한다.

7.3. 에이전트 구성요소가 차세대 제품의 새로운 기반이 된다

1. 모든 앱이 비슷한 채팅 UI에 머무르지는 않는다.

   1. OpenRouter의 Alex가 X에 올린 견해로 소개되는 비유는 2005년의 웹 앱과 현재의 에이전트 앱을 비교한다. 2005년에는 모두 서버·데이터베이스·CRUD 화면을 만들었지만, 그것이 이후 제품의 공통 기반이 된 것처럼 지금은 에이전트가 새 공통 구성요소가 될 수 있다는 설명이다.
   2. 새 제품은 자체 에이전트 기능을 포함하거나, 다른 에이전트가 읽고 쓸 수 있도록 헤드리스 데이터 서비스가 될 수 있다.

2. 여러 인프라·제품 카테고리가 하나의 하네스로 결합된다.

   1. 내구성 워크플로, 샌드박스, 클라우드 컴퓨터, 기억, 스킬, 외부 서비스 연결, 음성, 결제, 신원 확인, 평가, 관측 가능성이 각각 에이전트 제품을 구성하는 기반 요소다.
   2. 발표자는 각 요소마다 수십 개의 스타트업과 큰 투자 기회가 있으며, 새로운 회사와 제품을 위한 프리미티브가 되고 있다고 강조한다. “각 항목에 수십억 달러, 어쩌면 조 단위”라는 표현은 시장 규모의 전망이며, 검증된 집계 수치로 제시된 것은 아니다.

8. 엔지니어에게 주는 마무리 제안

8.1. 모델 호출 코드뿐 아니라 시스템 아키텍처를 읽는다

1. 설계 결정의 누적 효과를 고려한다. 에이전트 제품에서는 모델 자체뿐 아니라 서버·상태·도구·권한·UI·기억을 어떻게 배치하는지가 결과를 좌우한다. 넓은 시스템 설계와 코드 아키텍처를 이해하는 일이 과거보다 더 중요해졌다는 것이 발표자의 결론이다.
2. 발표자는 여전히 코드를 직접 읽는 편을 지지한다. 코드의 모든 줄을 직접 작성하지 않더라도, 실제로 배포할 아키텍처를 이해하려면 어떤 코드가 동작하는지 살펴야 한다.

8.2. 작은 에이전트 하네스를 직접 만들고 LLM의 작동 원리를 익힌다

1. 수강생에게 지난주에 실험한 하네스를 바탕으로 샌드박스와 VM을 붙여 개인용 에이전트 버전을 직접 만들어 보라고 권한다. 자막에서는 공개 코드의 이름이 “Grokbot”으로 들리지만, 브랜드 표기가 정확한지는 불확실하므로 그대로 단정하지 않는다.
2. 머신러닝 연구자가 되지 않아도 LLM의 학습 과정을 이해하는 것이 도움이 된다. 웹 앱 개발자가 데이터베이스의 기본 원리를 알아야 설계를 잘하듯, 모델의 특성과 학습 방식에 대한 직관은 제품·하네스 설계 선택을 더 잘하게 한다.
3. 강연의 최종 메시지는 모델이 더 유능해질수록 시스템 수준의 결정이 더 큰 차이를 만든다는 것이다. 엔지니어는 작은 도구 호출 루프를 넘어서 장기 실행, 상태·기억, 복구, 비용, 보안, 사용자 경험을 함께 설계해야 한다.

주요 발언 모음

“It knows when to be quiet.” — 에이전트는 조용히 있어야 할 때를 안다.

“You can steer the agent.” — 사용자는 에이전트의 진행 방향을 조정할 수 있다.

“Try the cheapest option or the most reliable option first.” — 가장 저렴하거나 신뢰도 높은 방법부터 시도한다.

“Infinite context is not a real thing.” — 무한 컨텍스트는 실제로 존재하지 않는다.

“Delete the product.” — 현재 모델의 한계에 고정된 제품이라면, 필요할 때 제품을 지우고 다시 설계할 준비를 하라.

“The models today are the worst they’ll ever be.” — 오늘의 모델은 앞으로 만날 모델 중 가장 성능이 낮을 수 있다.

핵심 데이터 & 수치

• 4개 개발 시대: ChatGPT 코드 복사·붙여넣기 → 파일·셸 도구를 쓰는 터미널 하네스 → 전용 앱과 병렬 에이전트 → 자체 컴퓨터·기억을 가진 상시 실행형 에이전트.
• 1~2년: 모델이 장시간 지시를 따르고 도구를 다루는 능력이 크게 발전했다고 발표자가 평가한 기간.
• 몇 시간·며칠에서 몇 주·몇 달로: 상시 에이전트가 이미 수행할 수 있거나 향후 수행할 것으로 보는 작업 지속 시간의 범위.
• 5개 또는 10개 봇: 각자 별도 브라우저·가상 데스크톱이 필요한 상황을 설명한 예시 수.
• 3~4개 연속 메시지: 빠르게 도착한 사용자 요청을 한 턴으로 합쳐 처리할 수 있다는 큐잉 사례.
• 90%: 한 작업에서 모델 실행 시간의 대부분(예시로 90%)이 셸 명령에 쓰인다면 일부 기능을 전용 도구로 만드는 편이 효율적일 수 있다는 가정.
• 10만·20만 토큰: 긴 대화의 컨텍스트 크기와 모델 컨텍스트 창의 예시. 실제 제품의 고정 한계를 말하는 수치로 제시된 것은 아니다.
• 캐시 10분 또는 60분: 모델 제공자별 따뜻한(prompt cache warm) 구간이 다를 수 있다는 예시.
• 30분 뒤 재접속: 캐시가 따뜻할 때 미리 압축해 두면 사용자가 돌아왔을 때 요약으로 저렴하게 이어갈 수 있다는 사례.
• 6개월·1년 / 향후 6~12개월: 모델 능력 변화 속도와 다음 세대 제품을 설계해야 한다는 전망 기간.
• 10분 대 12분: 장시간 작업을 맡은 서브에이전트에서는 몇 분의 지연 차이가 주 에이전트의 빠른 응답보다 덜 중요할 수 있다는 설명.
• 매일 / 매월 또는 몇 달마다: 제품·하네스의 버그 평가·수정 내부 루프와 새 모델 학습 외부 루프의 대략적 주기.
• 한 달짜리 실행과 매월 모델 출시: 장기 에이전트의 안전성 검증 기간이 모델 업데이트 주기를 따라가지 못할 수 있다는 평가 문제.
• 다음 해의 토큰 사용량: 발표자는 크게 증가할 것으로 전망하며, 추론과 하네스 효율 개선을 강조한다.
• 수십 개 스타트업·수십억 달러 이상: 에이전트 제품의 기반 카테고리를 설명하며 언급한 발표자의 시장 전망. 검증된 투자 통계가 아니라 강연 중의 추정·강조 표현이다.

자막상 불확실한 표현과 해석 원칙

• 자막은 여러 시점에서 앞선 문구가 반복되는 샘플링 형태였고, 일부 타임스탬프도 흐름과 맞지 않았다. 본문은 시간 숫자보다 자막 문장의 논리적 순서를 기준으로 재구성했다.
• 서비스 도구 프로토콜은 자막에 “MTP”로 들리는 부분이 있으나, 문맥상 “MCP”를 의미하는 것으로 정리했다.
• 자체 하네스·플러그인 제품 이름은 자막에 “Grokbot”으로 들리는 부분이 있다. 정확한 표기 여부가 확인되지 않아 노트에서는 자막에 들린 이름으로만 언급하고 제품 세부를 보태지 않았다.
• 다중 봇 사례는 “Multibook”과 “Hugging Face incident”로 들리지만, 사건명과 구체적 내용이 불명확하다. 따라서 위험 사례가 있다는 발표자의 요점만 기록하고 사고 내용을 추정하지 않았다.
• auto review가 사람보다 더 잘 검토했다거나 현재 모델의 환각이 대부분 해결됐다는 표현은 발표자의 경험과 평가로 귀속했다. 일반적으로 입증된 사실 또는 안전 보장으로 확장하지 않았다.
• “각 요소마다 수십억 달러”라는 시장 언급과 다음 해 토큰 사용량 증가 전망은 발표자의 전망·강조이지, 자막에서 근거가 제시된 공식 통계가 아니다.

결론 및 시사점

1. 상시 실행형 에이전트는 지속 가능한 하네스의 문제다. 모델 루프를 클라우드 서버, 별도 컴퓨터, 외부 트리거, 저장된 상태, 내구성 워크플로와 결합해야 오래 일하고 실패에서 복구할 수 있다.
2. 항상 켜 두는 대신 필요한 때만 켜고 상태를 남긴다. 서버와 VM의 수면·기동, 스냅샷, 저장을 지원하면 비용과 자원 사용을 관리하면서도 지속성을 제공할 수 있다.
3. 주 에이전트는 오케스트레이션에 집중하고 도우미는 긴 작업을 맡는다. 중간 출력을 분리하고 최종 결과만 회수해 컨텍스트 품질과 회상 가능성을 지킨다.
4. 컨텍스트는 모든 것을 넣는 저장소가 아니다. 핵심 선호, 날짜별 기록, 임시 메모를 층위화하고, 장기 정보는 파일에서 검색하며, 도구 설명은 필요할 때만 동적으로 불러와야 한다.
5. 프롬프트 캐시·압축·도구 스키마는 제품 성능과 비용의 일부다. 안정된 프롬프트 접두부, 도구 순서 고정, 캐시 워밍, 손실을 고려한 요약 전략이 장시간 대화의 효율을 좌우한다.
6. 도구는 가장 가벼운 경로부터 사용하고 사용자 개입은 마지막에 요청한다. 대화 맥락→API/플러그인→검색→브라우저→전체 데스크톱→사용자 확인의 사다리는 비용·신뢰도·방해 수준을 함께 최적화한다.
7. 자율성이 커질수록 신뢰 경계를 명확하게 해야 한다. VM 격리만으로 충분하지 않으며, 외부 입력과 사용자 지시의 분리, 프롬프트 인젝션 방어, 비밀정보 격리, 비가역 행동의 사용자 승인, 명령 검토가 필요하다.
8. 평가 주기는 장기 에이전트의 수행 기간과 맞아야 한다. 매달 바뀌는 모델이 몇 주·몇 달 작업에서 올바르게 행동하는지 검증하는 문제는 아직 해결되지 않은 연구·제품 과제다.
9. 현재 모델에 맞춰 제품을 과도하게 굳히지 않는다. 모델이 빠르게 발전하므로 단순하고 바꿀 수 있는 인터페이스를 만들고, 제품을 다시 설계할 가능성을 열어 둔다.
10. 엔지니어의 역할은 모델 호출을 넘어 시스템 설계로 확장된다. 코드와 데이터베이스, 분산 시스템, 상태 관리, 비용·보안·제품 경험을 함께 이해하는 직관이 다음 세대 에이전트 제품을 만드는 기반이다.

핵심 요약 (20줄)

1. 상시 실행형 에이전트는 도구 호출 루프를 서버·기억·이벤트와 결합해 사용자가 자리를 비워도 일하는 디지털 동료다.
2. 자체 Linux 컴퓨터와 파일·브라우저를 제공하면 사용자 노트북과 분리된 환경에서 작업을 이어갈 수 있다.
3. 에이전트는 매번 알리는 대신 백그라운드에서 일하고, 중요한 때만 보고하도록 설계해야 한다.
4. AI 개발 방식은 코드 복사·붙여넣기, 터미널 하네스, 전용 에이전트 앱, 상시 실행형 에이전트로 발전해 왔다.
5. 별도 AI가 실행 명령을 검토하는 auto review는 사람의 승인 피로를 줄일 수 있지만, 발표자의 경험적 평가이지 보안 보장은 아니다.
6. 장기 지시 수행, 서브에이전트 위임, 도구 호출·컴퓨터 사용, 파일 기억, 스킬과 루틴이 상시 에이전트의 기반 역량이다.
7. 서버와 VM은 필요할 때 깨우고 작업 후 잠재우며, 이벤트 라우터는 중복을 제거하고 사용자 알림 여부를 판단한다.
8. Firecracker VM은 스냅샷과 재시작을 지원하며, 여러 봇에 별도 브라우저와 가상 데스크톱을 제공할 수 있다.
9. 얇은 클라이언트와 두꺼운 서버를 분리하면 다양한 앱이 단일 메시지 통로로 연결되고, 클라이언트는 승인·결제 UI를 제공한다.
10. 내구성 워크플로와 Temporal은 실패 후 완료한 단계부터 재개하며, 요청 우선순위와 메시지 묶음도 관리한다.
11. 동적 도구 발견은 필요한 도구 설명만 컨텍스트에 넣어 비용을 줄이고 실제 대화에 쓸 공간을 확보한다.
12. 정보 접근은 대화 기억, API·플러그인, 웹 검색, 브라우저, 데스크톱, 사용자 확인 순으로 가볍게 시도한다.
13. 브라우저 조작은 스크린샷·HTML·접근성 트리·픽셀 클릭을 활용하며, 2단계 인증이나 CAPTCHA는 사용자에게 요청한다.
14. 주 에이전트는 오케스트레이션에 집중하고, 서브에이전트는 긴 작업을 맡아 중간 결과로 주 컨텍스트를 부풀리지 않는다.
15. VM 격리만으로는 충분하지 않으며, 프롬프트 인젝션 방어·비밀정보 격리·비가역 행동 승인과 명령 검토가 필요하다.
16. 프롬프트 캐시를 유지하려면 시스템 프롬프트와 도구 순서를 안정화하고, 긴 출력은 파일로 옮기며 캐시 워밍을 활용한다.
17. 컨텍스트 압축은 손실이 있으므로 핵심 사실, 날짜별 기록, 임시 메모를 나누고 필요한 정보만 회상해야 한다.
18. 제품팀은 실패를 평가로 바꿔 매일 하네스를 개선하고, 새 모델 학습 주기에도 평가를 반영하는 플라이휠을 만든다.
19. 에이전트가 몇 주·몇 달 일하게 되면 장기 평가, 보안, 알림의 적정성, 토큰 효율이 중요한 미해결 과제가 된다.
20. 엔지니어는 모델뿐 아니라 시스템 아키텍처를 이해하고, 현재 모델에 고정되지 않는 단순하고 변경 가능한 제품을 설계해야 한다.