Give your agent its own computer

💡 한 줄 요약

AI 에이전트가 실제 일을 하려면 추론만으로는 부족하며, 파일시스템·셸·패키지 관리자·지속 상태를 갖춘 독립적인 컴퓨터가 필요하지만 이를 안전하게 제공하는 것이 핵심 과제다.

📌 핵심 요약

글은 LLM이 추론할 수는 있지만, 실제 작업을 완수하려면 코드를 실행하고 오류를 확인하며 다시 고치는 실행 환경이 필요하다고 설명한다.
에이전트가 사용할 컴퓨터는 파일시스템, 셸, 패키지 관리자, 지속 상태를 갖춰야 하지만, 이를 사용자의 실제 인프라나 노트북에 직접 연결하는 것은 위험하다고 지적한다.
코딩 보조, 데이터 분석, CI 자동화, 리서치, 콘텐츠 파이프라인, 평가·강화학습 환경처럼 에이전트가 실행 능력을 가질 때 가능한 작업 범위가 크게 넓어진다.
하지만 에이전트가 실행하는 코드는 모델, 사용자 프롬프트, 복제한 저장소, 설치 패키지 등에서 올 수 있어 본질적으로 신뢰하기 어렵고, 단순 Docker 컨테이너만으로는 충분한 격리가 되지 않는다고 주장한다.
LangSmith Sandboxes는 각 에이전트에 하드웨어 가상화된 microVM을 제공해 빠른 시작, 지속 상태, 안전한 격리를 동시에 제공하려는 해법으로 제시된다.

🧩 주요 포인트

글은 LLM이 추론할 수는 있지만, 실제 작업을 완수하려면 코드를 실행하고 오류를 확인하며 다시 고치는 실행 환경이 필요하다고 설명한다.
에이전트가 사용할 컴퓨터는 파일시스템, 셸, 패키지 관리자, 지속 상태를 갖춰야 하지만, 이를 사용자의 실제 인프라나 노트북에 직접 연결하는 것은 위험하다고 지적한다.
코딩 보조, 데이터 분석, CI 자동화, 리서치, 콘텐츠 파이프라인, 평가·강화학습 환경처럼 에이전트가 실행 능력을 가질 때 가능한 작업 범위가 크게 넓어진다.
하지만 에이전트가 실행하는 코드는 모델, 사용자 프롬프트, 복제한 저장소, 설치 패키지 등에서 올 수 있어 본질적으로 신뢰하기 어렵고, 단순 Docker 컨테이너만으로는 충분한 격리가 되지 않는다고 주장한다.
LangSmith Sandboxes는 각 에이전트에 하드웨어 가상화된 microVM을 제공해 빠른 시작, 지속 상태, 안전한 격리를 동시에 제공하려는 해법으로 제시된다.

🧠 상세 정리

1. 추론만으로는 충분하지 않은 에이전트

글은 LLM이 reasoning, 즉 추론을 할 수 있다는 점을 인정하면서도 그것만으로는 많은 일이 실제로 끝나지 않는다고 말한다. 단순 채팅 인터페이스는 답을 생성할 수 있지만, 코드를 실행하고 결과를 확인하며 오류를 수정하는 반복 루프를 갖기 어렵다. 저자는 에이전트가 실질적인 작업자가 되려면 파일시스템, 셸, 패키지 관리자, 지속 상태를 포함한 ‘진짜 컴퓨터’가 필요하다고 본다. 문제는 그런 실행 능력을 주는 순간 사용자의 인프라를 위험에 노출할 수 있다는 점이다.

2. 각 에이전트에게 필요한 독립된 작업 공간

저자는 사람이 한 대의 노트북을 쓰는 것과 달리, 에이전트는 수백만 개의 작업을 동시에 수행할 수 있고 각 작업마다 별도의 컴퓨터가 필요하다고 설명한다. 여기서 핵심은 에이전트가 단순히 토큰을 주고받는 존재가 아니라 실제로 무언가를 설치하고, 실행하고, 수정하고, 상태를 이어가는 작업 주체라는 점이다. Satya Nadella의 “Every agent needs a computer”라는 표현도 이 관점을 강조하는 근거로 인용된다. 따라서 논점은 에이전트에게 컴퓨터를 줄지 여부가 아니라, 어떤 형태의 컴퓨터를 어떻게 안전하게 줄 것인가로 이동한다.

3. 실행 가능한 에이전트가 여는 작업 범위

글은 Cursor, Claude Code, ChatGPT의 code interpreter 같은 도구를 예로 들며, 실행 환경이 있는 에이전트가 평범한 채팅보다 왜 유용한지 설명한다. 이런 도구들은 답을 제안하는 데서 멈추지 않고 코드를 실행하고, 에러를 보고, 수정하고, 다시 실행해 동작하는 결과물을 만든다. 같은 방식으로 코딩 assistant는 수정안을 적용하고 테스트까지 돌릴 수 있으며, 데이터 분석 에이전트는 CSV를 가져와 Python으로 처리한 뒤 보고서를 만들 수 있다. CI 에이전트, 리서치 에이전트, 콘텐츠 파이프라인, 평가나 강화학습용 harness도 모두 실행 가능한 작업 공간이 있을 때 가능해진다.

4. 로컬 실행과 직접 인프라 접근의 위험

저자는 초기 프로토타입 단계에서는 에이전트에게 로컬 코드 실행 권한을 주거나 Docker 컨테이너를 쓰는 방식이 흔하지만, 프로덕션에서는 곧 한계에 부딪힌다고 말한다. 첫 번째 이유는 에이전트가 실행하는 코드가 본질적으로 신뢰할 수 없는 코드이기 때문이다. 코드의 출처는 모델이 생성한 스크립트, 사용자 프롬프트, 복제한 저장소, 설치된 패키지 등 다양하며, 사용자가 직접 작성하지 않았고 완전히 검증하기도 어렵다. 글은 npm 패키지 생태계에서 발생한 Shai-Hulud 사례를 언급하며, 설치 과정에서 실행되는 악성 코드가 에이전트 워크플로에 그대로 노출될 수 있다고 경고한다.

5. Docker 컨테이너만으로는 부족한 격리

두 번째 한계는 컨테이너가 충분한 보안 경계가 아니라는 점이다. 글은 Docker가 웹 서버나 백그라운드 작업처럼 이미 알고 있고 검증된 애플리케이션 코드를 격리하는 데는 유용하다고 인정한다. 그러나 에이전트처럼 임의의 의존성을 설치하고, 모델이 생성한 스크립트를 실행하며, 긴 세션 동안 상태를 유지하는 작업자에게는 설계 목적이 맞지 않는다고 본다. 특히 컨테이너는 호스트와 커널을 공유하기 때문에 커널 취약점이 발생하면 경계를 넘어설 수 있으며, 저자는 Copy Fail 취약점 사례를 들어 하드웨어 수준의 분리가 필요하다고 주장한다.

6. LangSmith Sandboxes가 제시하는 해법

글의 해법은 에이전트마다 독립된 sandbox를 제공하는 것이다. 저자는 sandbox가 서버리스 함수처럼 즉시 시작될 수 있어야 하면서도, 동시에 전체 머신처럼 상태를 유지할 수 있어야 한다고 설명한다. 에이전트는 무상태 요청 처리자가 아니라 세션 중간에 의존성을 설치하고 파일을 수정하며 이전 작업을 이어가는 작업자이기 때문이다. LangSmith Sandboxes는 컨테이너가 아니라 자체 커널을 가진 하드웨어 가상화 microVM으로 설명되며, 이를 통해 에이전트가 패키지를 설치하고 스크립트를 실행하고 로컬 서버를 띄우면서도 프로덕션 인프라나 다른 에이전트의 환경에는 닿지 않도록 한다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 에이전트의 성능 문제가 모델 추론 능력만이 아니라 실행 환경의 설계 문제와도 연결되어 있다는 점이다.
프로덕션 에이전트에서 ‘코드를 실행할 수 있다’는 기능은 편의 기능이 아니라 보안, 격리, 상태 관리, 확장성을 함께 요구하는 인프라 문제로 다뤄져야 한다.
컨테이너가 익숙한 선택지라 해도, 신뢰할 수 없는 모델 생성 코드와 임의 패키지 설치를 전제로 하는 에이전트 워크로드에는 더 강한 격리 모델이 필요하다는 주장이 글의 중심 근거다.