[한영자막] Grok Bot 같은 상시 작동 에이전트는 어떻게 작동할까요?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Grok Bot 같은 상시 작동 에이전트는 서버에 작업 상태와 기억을 보존하고 사건이 발생할 때 실행을 재개하며, 장애 복구·문맥 관리·안전 통제를 결합한 하네스로 작동한다.

📌 핵심 요점

1. 상시 작동의 기반은 상태 보존과 사건 기반 실행이다. 대화·기억·루틴을 저장하고 메시지나 예약 작업이 들어오면 깨어나며, 작업용 컴퓨터는 필요할 때 시작해 대기 비용을 줄인다.
2. 에이전트 루프와 작업용 컴퓨터를 분리한다. 서버가 입력 큐와 도구 호출을 관리하고, Firecracker 가상 머신이 Linux 작업 환경을 제공한다. Temporal 기반 내구성 워크플로는 장애 후 진행을 이어갈 기반이 된다.
3. 장기 작업에는 입력의 우선순위와 사용자 통제가 필요하다. 사용자의 직접 수정은 현재 실행을 멈추고 우선 처리하며, 다른 입력은 큐에 넣거나 묶는다. 되돌리기 어려운 행동에는 초안 확인과 승인 흐름을 둘 수 있다.
4. 기억과 문맥은 용도에 맞게 관리한다. 사용자 정보·일별 기록·임시 메모를 나누고, 스킬과 긴 출력은 파일로 보관한다. 무거운 실행은 서브에이전트에 위임하고 도구 정의는 필요할 때 불러온다.
5. 비용과 신뢰성은 지속적인 최적화 대상이다. 프롬프트 앞부분과 도구 순서를 안정적으로 유지해 캐시를 재사용하고, 실패 사례를 평가 항목으로 전환한다. 외부 입력의 신뢰 구분과 명령 실행 검토도 함께 설계해야 한다.

🧩 배경과 문제 정의

• 모델이 도구를 반복 호출하는 단순한 에이전트도 강력하지만, 개인 노트북의 터미널에서 실행하면 컴퓨터를 닫거나 프로세스가 종료될 때 작업이 멈춘다.
• 상시 작동 에이전트는 서버와 클라우드 컴퓨터, 지속되는 기억을 바탕으로 사용자 부재 중에도 작업하고, 메시지·이메일·예약 작업 같은 외부 사건에 반응하는 동료를 지향한다.
• 수주나 수개월에 걸친 작업은 목표에 해당한다. 이를 뒷받침하려면 장애 복구, 작업 우선순위, 문맥 관리, 사용자에게 알릴 시점의 판단, 안전한 도구 실행을 함께 설계해야 한다.
• 소개된 구조와 기능 일부는 SpaceX에서 개발 중이며, 모델의 발전만큼 이를 둘러싼 실행 구조인 하네스와 제품 설계가 중요하다.

🕒 시간순 섹션별 상세정리

1. 터미널의 도구 호출 루프를 지속되는 작업 환경으로 확장한다

• 모델이 도구를 반복 호출하는 구조는 다양한 작업을 가능하게 하지만, 노트북을 닫으면 실행이 멈춘다. 서버나 클라우드에서 실행하면 사용자 컴퓨터와 독립적으로 작동하고 재시작이나 장애에도 대응할 수 있다. [00:23]
• 에이전트 전용 클라우드 Linux 컴퓨터는 파일·브라우저·데스크톱을 제공한다. 파일을 저장하고 작업 이력과 사용자에 대한 기억을 축적해 이후 작업에 활용할 수 있다. [01:03]

2. 명령마다 승인하는 방식에서 작업 중 방향을 조정하는 방식으로 이동한다

• AI 개발 도구는 채팅 답변의 코드를 복사하는 단계에서 파일 수정과 셸 실행이 가능한 터미널 에이전트로, 다시 전용 앱과 병렬·클라우드 실행으로 발전했다. 다만 사용자가 모든 명령을 검토하는 동안에는 사람이 병목으로 남았다. [02:39]
• 상시 작동 에이전트는 자체 컴퓨터와 기억을 갖고 사용자가 자리를 비운 뒤에도 작업한다. 작업 지시 직후 실행 날짜를 바꾸는 메시지가 들어와도, 개선된 모델과 하네스는 두 메시지의 관계를 해석하며 진행 방향을 조정할 수 있다. [03:50]

3. 장기 지시 수행과 컴퓨터 사용 능력이 업무 위임의 범위를 넓힌다

• 문자 메시지처럼 익숙한 인터페이스를 통해 질문에 대한 답변을 받는 데서 나아가, 동료에게 맡기듯 긴 작업을 위임할 수 있다. 적절한 문맥 압축을 전제로 모델이 수시간이나 수일 동안 지시를 따르는 능력도 개선됐다. [05:42]
• 서브에이전트는 별도의 작업 문맥에서 토큰이나 도구 호출을 많이 사용하는 일을 처리하고 결과를 돌려준다. 주 에이전트의 작업 기억이 가득 차는 문제를 완화하는 수단이다. [06:44]

4. 파일이 사용자 기억·작업 기록·스킬·예약 실행의 기반이 된다

• 사용자 프로필은 말투 같은 선호를 매번 전달하는 데 쓰이고, 일별 작업 기록은 파일로 축적된다. 과거 작업을 물으면 에이전트가 셸 명령과 파일 검색으로 관련 기록을 찾아볼 수 있다. [08:31]
• 스킬은 특정 작업의 절차와 성공·실패 기준을 Markdown 파일로 정리한 것이다. 개인의 업무 지식뿐 아니라 기업과 개발자가 만든 작업 방법도 같은 방식으로 제공할 수 있다. [09:19]

5. 상시 작동은 계속 켜두는 대신 상태를 보존하고 필요할 때 깨우는 구조다

• 에이전트 서버와 작업용 컴퓨터는 대기 중 잠들어 있다가 메시지나 트리거가 들어오면 상태를 불러온다. 브라우저나 화면 조작이 필요할 때만 컴퓨터도 시작하고, 사용이 끝나면 다시 재울 수 있다. [10:14]
• 모든 사용자의 컴퓨터와 서버를 계속 실행하면 비용과 자원 부담이 커진다. 대화 기록·기억·루틴을 데이터베이스에 보존하면 실행 자원을 중지해도 이후 작업을 이어갈 기반이 남는다. [10:54]

6. Firecracker 가상 머신으로 작업 환경을 복원하고 여러 봇의 화면을 분리한다

• 작업용 Linux 환경은 Firecracker 가상 머신에서 실행된다. 머신 상태를 스냅샷으로 저장해 종료하고 복원하기 쉬우며, 사용자가 실시간 화면에 접속해 직접 제어할 수도 있다. [12:20]
• 개인 노트북 대신 별도로 보안이 설정된 환경에서 셸 명령을 실행할 수 있다. 여러 봇이 각각 브라우저를 사용해야 할 때는 가상 데스크톱으로 화면을 나누며, 컴퓨터 실행 기반은 공유한다. [12:44]

7. 에이전트 루프와 작업용 컴퓨터를 분리해 독립적으로 운영한다

• 서버는 입력을 큐에 넣고 모델이 도구를 반복 호출하는 에이전트 루프를 실행한다. 종료할 때는 상태를 저장하며, 이 작은 핵심 구조에 도구와 외부 서비스를 연결해 기능을 확장한다. [13:15]
• 얇은 클라이언트와 기능이 집중된 서버 구조는 앱스토어 배포 없이 에이전트 코드를 갱신하기 쉽다. 전사나 이미지 생성 같은 무거운 계산을 처리하고, 변동하는 트래픽에 맞춰 서버를 확장하는 데도 유리하다. [14:07]

8. 대화 동기화와 내구성 워크플로가 재시도에 따른 중복을 줄인다

• 메시지를 보낸 클라이언트는 즉시 접수를 확인하고, 서버는 모델과 도구의 실행 내용을 데이터베이스에 저장한다. 클라이언트는 변경 신호를 구독해 최신 정보를 가져오며, 재시도로 같은 메시지가 여러 번 표시되지 않도록 중복을 제거한다. [15:27]
• 일반 작업 큐에서는 여러 단계를 수행하다 장애가 나면 앞선 단계부터 다시 실행해야 할 수 있다. 내구성 워크플로는 진행 상태를 보존해 실패한 지점에서 이어갈 수 있도록 한다. [16:19]

9. 사용자의 직접 수정은 우선 처리하고 다른 입력은 순서대로 묶는다

• 사용자가 행사 날짜를 바꾸는 것처럼 직접 수정 지시를 보내면 현재 에이전트 루프를 멈추고 그 메시지를 우선 처리한다. 그룹 채팅·Slack 스레드·백그라운드 루틴의 입력에는 다른 우선순위를 적용한다. [17:25]
• 다른 입력은 큐 뒤에 추가하고, 짧은 시간에 연속으로 들어온 메시지들은 기준에 따라 하나의 턴으로 묶을 수 있다. 이후에는 각 턴을 순서대로 처리한다. [17:49]

10. 단일 통신 도구가 다양한 클라이언트와 서버 기능을 연결한다

• Grokbot 하네스는 클라이언트와 서버 사이의 통신을 send user라는 단일 도구로 단순화한다. 셸 실행·파일 읽기·클라우드 에이전트 호출·화면 녹화 같은 무거운 기능은 서버에 둔다. [18:08]
• 모바일·데스크톱·이메일·Slack 등 서로 다른 클라이언트도 같은 통신 방식을 사용한다. 각 클라이언트는 받은 내용을 로그인 양식, 비밀번호 관리 도구 연동, 결제 화면 등 상황에 맞는 인터페이스로 표현할 수 있다. [19:01]

11. 도구 정의는 필요할 때 불러와 대화에 쓸 문맥을 확보한다

• 도구 이름·스키마·설명을 모두 문맥에 넣으면, 커넥터가 늘어날수록 실제 대화와 작업에 사용할 공간이 줄어든다. 여러 MCP 서버를 연결할수록 이 부담이 커진다. [20:01]
• 동적 도구 탐색은 도구 이름만 먼저 제공하고, 모델이 필요한 도구를 선택하면 파일에서 상세 정보를 읽게 한다. 도구 정의가 차지하는 문맥과 그에 따른 비용·사용량을 줄일 수 있다. [20:49]

12. 저렴하고 신뢰할 수 있는 수단부터 시도하고 사용자 개입을 줄인다

• 작업 수단은 대화에 이미 있는 정보에서 시작해 플러그인·MCP·API, 웹 검색, 브라우저, 전체 데스크톱과 스크립트 실행으로 확장한다. 저렴하거나 신뢰할 수 있는 방법부터 시도하고, 해결되지 않을 때 사용자 입력이나 승인을 요청하는 원칙이다. [21:32]
• 컴퓨터에서 정보를 읽는 방법에는 스크린샷, HTML, 접근성 트리가 있다. 접근성 트리는 버튼·링크 같은 요소를 찾으면서 토큰 사용량을 줄이는 데 유용하다. [22:37]

13. 주 에이전트는 조율하고 서브에이전트는 무거운 실행을 맡는다

• 주 에이전트의 대화 문맥은 가능한 한 간결하게 유지한다. 많은 셸 명령과 비용이 큰 도구 호출은 서브에이전트에 맡기고 결과만 돌려받으면, 실행 세부 내용이 주 에이전트의 문맥을 채우는 일을 줄일 수 있다. [23:30]
• 모든 모델에는 문맥 한계가 있으므로 실제로 무한한 문맥이 생기는 것은 아니다. 위임과 문맥 관리, 관련 모델 훈련을 통해 긴 작업에서도 한계나 품질 저하가 덜 느껴지도록 하는 접근이다. [24:11]

14. 도구 설계의 작은 선택이 비용과 복구 능력에 영향을 준다

• 턴 도중 도구를 추가하거나 제거하는 일을 가급적 피하고, 긴 도구 설명과 스키마를 줄이는 편이 좋다. 정의가 차지하는 공간을 줄이면 문맥과 비용 부담도 감소한다. [25:14]
• 셸 실행 도구 하나로 많은 작업을 표현할 수 있지만, 특정 작업에 셸 사용이 집중된다면 전용 도구가 더 효율적일 수 있다. 실행 내용을 검토하는 사람도 동작을 이해하기 쉬워진다. [25:48]

15. 장기 자율 실행에는 입력 신뢰 구분과 비가역 행동의 통제가 필요하다

• 작업용 컴퓨터를 사용자 컴퓨터와 분리하더라도 실행 명령의 안전성 검토는 필요하다. 자동 검토 모델이 각 셸 명령을 실행 전에 확인하는 방식이 보호 수단이 된다. [26:30]
• 이메일이나 웹훅 같은 외부 입력은 사용자 지시와 구분해야 한다. 피싱 메일 등의 내용을 지시로 받아 실행하지 않도록 프롬프트 인젝션을 방어해야 하며, 이 영역에는 업계 차원의 추가 작업이 남아 있다. [26:54]

16. 고정된 프롬프트 앞부분을 유지해 캐시를 재사용한다

• 에이전트는 메시지가 추가될 때 기존 대화를 다시 전송하므로, 이상적으로는 사용 토큰의 상당 부분이 캐시에서 재사용된다. 캐시 토큰에는 큰 가격 할인이 있어 재사용을 오래 유지하는 것이 비용에 중요하다. [27:26]
• 도구 정의와 시스템 프롬프트를 호출 사이에 최대한 고정하면 캐시가 깨지는 일을 줄일 수 있다. 고정된 앞부분을 재사용하고 새 메시지만 추가하면, 이상적으로는 새로 들어온 부분에 대해서만 비캐시 토큰 비용을 부담한다. [28:18]

17. 긴 출력은 파일로 옮기고 문맥을 지속적으로 정리한다

• 주 에이전트는 아주 긴 대화 동안 문맥을 여러 차례 요약·압축할 수 있다. 긴 출력을 그대로 넣기보다 파일에 저장하고 필요할 때 읽게 하면 주 문맥을 작게 유지하는 데 도움이 된다. [28:47]
• 스크린샷이나 문맥 비용이 큰 작업은 서브에이전트에 위임해 주 에이전트의 문맥 부담을 줄인다. [29:22]

18. 프롬프트 순서 고정과 사전 준비로 캐시 활용을 높인다

• OpenClaw가 구독형 모델 서비스에서 인기를 얻던 당시에는 새로운 사용 패턴에 하네스가 충분히 최적화되지 않아 캐시 미스가 많았다. 계속 실행되는 에이전트에서는 이 문제가 누적되므로 프롬프트 캐시를 최대한 유지하도록 수정해야 했다. [30:02]
• 시스템 프롬프트나 도구를 추가할 때도 기존 프롬프트의 순서를 안정적으로 유지해야 한다. 구간별 해시와 고정 순서를 활용하면 A/B 테스트용 문구를 넣으면서 다른 사용자의 캐시까지 깨뜨리는 일을 줄일 수 있다. [30:38]

19. 캐시가 유효할 때 요약하고 기억을 용도별로 나눈다

• 예를 들어 문맥 창이 20만 토큰이어도 대화가 계속되면 결국 압축이 필요하며, 압축에는 정보 손실이 따른다. 중요한 세부사항을 잃지 않는 요약 알고리즘이 장기 실행의 핵심 과제다. [31:33]
• 10만 토큰을 넘긴 대화 뒤 사용자가 자리를 비웠다면, 제공업체의 캐시가 아직 유효할 때 요약하는 편이 저렴할 수 있다. 캐시 유지 시간이 10분일 수도, 60분일 수도 있으므로 그 안에 압축하면 사용자가 돌아왔을 때 짧은 요약부터 대화를 이어갈 수 있다. [32:03]

20. 모델 훈련과 추론을 에이전트의 역할에 맞춘다

• 사전학습은 대량의 텍스트 등으로 일반적인 세계 이해를 형성하고, 지도 미세조정은 채팅 도우미나 에이전트로서의 행동을 가르치며, 강화학습은 과제 수행을 개선하는 단계다. 상시 에이전트에는 지도 미세조정에서 하네스와 사용 가능한 도구의 예시를 익히게 하는 것이 도움이 된다. [34:27]
• 강화학습으로 지시 준수, 수백 개 스킬 중 적절한 스킬 선택, 브라우저 화면에서 올바른 위치 클릭 같은 능력을 개선할 수 있다. [35:21]

21. 실패를 평가로 전환해 제품 수정과 모델 학습에 반영한다

• 에이전트가 호출하면 안 되는 도구를 호출했다면 그 실패를 평가 항목으로 만들고, 하네스·프롬프트·추론 등의 원인을 수정한 뒤 평가로 해결 여부를 확인해야 한다. 버그 발견, 수정, 측정이 일상적인 제품 개선의 내부 순환을 이룬다. [36:06]
• 더 긴 주기의 외부 순환에서는 새 모델이 누적된 실패와 버그에서 학습하고 평가 성능을 높이는 것이 목표다. 새 모델의 능력 향상은 제품을 활용하는 새로운 방식도 가능하게 한다. [36:44]

22. 다음 세대 모델을 전제로 제품을 단순하게 설계한다

• ‘제품을 삭제한다’는 원칙은 현재 모델이 앞으로 가장 성능이 낮은 모델일 수 있다고 가정하는 것이다. 모델과 하네스 설계가 빠르게 발전하므로 6개월 뒤에는 UI를 전면 재구축해야 할 수도 있으며, 다음 세대 모델이 생각하고 행동할 수 있도록 최소한의 구현과 단순한 인터페이스를 지향한다. [37:45]
• 향후 6~12개월에는 에이전트의 작업 기간이 몇 시간이나 하루에서 수주·수개월로 늘어날 가능성이 드러난다. 과거 대화 회상도 개선될 것으로 예상하지만, 기억의 내부 표현은 그래프·파일 등 여러 연구 방향이 열려 있다. [38:36]

23. 장기 실행의 평가·보안·개입 기준은 미해결 과제다

• 한 달 동안 실행되는 에이전트를 평가해야 하는데 새 모델도 매달 출시된다면, 출시 전에 기대한 행동을 충분히 검증하기 어렵다. 더 나은 평가 방법을 찾거나 출시 속도를 늦춰야 하는 문제가 향후 업계의 과제로 제기된다. [40:20]
• 악의적인 행위자가 에이전트를 장악하지 못하도록 하네스와 주변 인프라의 보안을 강화해야 한다. 동시에 언제 조용히 있고 언제 사용자에게 개입할지 판단하는 기준도 미완성이다. 결석한 수업의 녹화와 필기를 먼저 제공하는 행동도 사용자에 따라 유용하거나 성가실 수 있다. [40:53]

24. 에이전트 기능과 기반 서비스가 제품의 공통 구성요소가 된다

• 사이드바와 채팅창이 비슷한 제품이 많다는 현상은 과거 웹 서비스가 서버·데이터베이스·CRUD 인터페이스를 공통으로 사용했던 것에 비유된다. 앞으로 제품은 에이전트 기능을 통합하거나 다른 에이전트가 활용하는 데이터와 기능의 공급원이 될 것이라는 관점이다. [42:05]
• 지속 실행 워크플로, 샌드박스, 클라우드 컴퓨터, 기억, 스킬, 외부 서비스 연결, 음성, 결제, 신원, 평가, 관측 가능성이 다음 세대 제품의 기반 구성요소로 드러난다. 이 요소들을 하네스 안에서 통합하는 데도 많은 개발 과제가 남아 있다. [42:48]

25. 엔지니어는 시스템 설계와 모델의 작동 원리를 함께 이해해야 한다

• 소프트웨어를 만들 때 전체 시스템 설계와 코드 아키텍처를 이해하는 일이 더욱 중요해진다. 설계 결정의 영향이 누적되므로, 작성되는 코드를 직접 살펴보며 어떤 구조를 제품으로 내보내는지 파악하는 것이 유용하다. [43:26]
• 하네스의 구성 원리를 익히려면 직접 작은 버전을 만들어 적용해 볼 수 있다. 샌드박스나 가상 머신 등을 조합해 실행 환경을 구성하는 실습이 각 요소의 작동 방식을 이해하는 데 도움이 될 수 있다. [43:54]

🧾 결론

• 상시 작동 에이전트의 핵심은 사용자 부재와 실행 중단을 견디면서 작업을 이어가는 구조다.
• 모델의 능력과 함께 상태 저장, 복구, 도구 연결, 기억, 승인 흐름을 묶는 하네스가 제품의 실용성을 좌우한다.
• 수주·수개월 동안의 자율 작업은 지향점이다. 강연은 그 기반 구조를 설명하지만 장기간의 안정적 수행이 충분히 검증됐다고 제시하지는 않는다.

📈 투자·시사 포인트

• 지속 실행 워크플로, 샌드박스, 클라우드 컴퓨터, 기억, 평가·관측 가능성은 에이전트 제품의 공통 기반으로 제시된다. 관련 서비스는 개별 기능뿐 아니라 통합과 운영 부담을 얼마나 줄이는지 살펴볼 필요가 있다.
• 토큰 사용이 늘어날수록 캐시 재사용, 문맥 압축, 동적 도구 탐색, 실행 자원의 휴면 설계가 비용 구조에 영향을 줄 수 있다. 실제 효과는 워크로드와 제공업체의 캐시 조건을 확인해야 한다.
• 조직의 업무 절차와 성공·실패 기준을 스킬로 문서화하는 능력이 업무 위임의 기반이 될 수 있다. 기업은 보유 지식을 에이전트가 실행할 수 있는 절차로 정리필요가 있다.
• 강연은 기술 구조와 제품 방향을 다룬다. 특정 기업의 매출·수익성·가치평가를 판단할 수 있는 수치는 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 소개된 구조와 기능 일부는 개발 중이다. 수주·수개월 작업과 향후 기억 개선은 목표나 전망으로 구분해야 하며, 강연 시점 기준의 향후 일정도 확정된 출시 계획으로 보기 어렵다.
• 자동 명령 검토가 사람보다 나은 경우가 대부분이라는 설명은 강연자의 평가다. 비교 조건, 오류율, 위험한 명령의 탐지 성능은 제시되지 않았다.
• 문맥 압축에는 정보 손실이 따른다. 파일 기억과 서브에이전트가 장기 작업의 중요한 제약을 얼마나 안정적으로 보존하는지는 별도 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작은 에이전트 실행 환경을 구성하고, 서버의 작업 상태와 작업용 가상 머신을 분리해 종료·복원 동작을 확인한다.
• 중간 장애와 중복 메시지를 넣어 진행 상태 복구, 메시지 중복 제거, 사용자 수정 지시의 우선 처리를 점검한다.
• 사용자 핵심 정보·일별 기록·임시 메모를 구분하고, 문맥 압축 후에도 중요한 지시를 유지하는지 확인한다.
• 이메일 전송 등 되돌리기 어려운 행동에 초안·수정·승인 절차를 마련하고, 외부 콘텐츠를 사용자 지시와 구분한다.

❓ 열린 질문

• 한 달 동안 실행되는 에이전트의 신뢰성을 모델 출시 전에 충분히 평가하려면 어떤 검증 방식이 필요한가?
• 문맥 압축과 파일 검색을 결합할 때 중요한 정보를 잃지 않았다는 사실을 어떻게 확인할 수 있는가?
• 에이전트가 조용히 작업할 때와 사용자에게 알리거나 승인을 요청할 때를 어떤 기준으로 구분해야 하는가?