cloudflare2026년 8월 3일

에이전트에게 필요한 건 컨테이너가 아니라 컴퓨터입니다 — @cloudflare/computer 소개 (새 탭에서 열림)

가장 뛰어난 에이전트는 자체 컴퓨터처럼 사용할 수 있는 파일시스템, 셸, 도구, 실행 환경을 제공받는다는 것이 글의 핵심 주장입니다. Cloudflare는 이를 위해 `@cloudflare/computer`라는 에이전트 런타임을 공개 프리뷰로 제공하며, 격리 실행 환경(isolate)과 컨테이너를 하나의 공유 파일시스템 아래 결합합니다. 이를 통해 컨테이너만 사용하는 방식보다 비용과 확장성 문제를 줄이고, 수억~수십억 개의 동시 에이전트까지 확장하는 것을 목표로 합니다. ## 에이전트마다 컴퓨터를 제공하는 방식 - 코딩 에이전트는 파일시스템, 셸, 패키지, 실행 도구를 직접 사용하면서 환경을 조사하고 코드를 수정·실행·검증한다. - 이런 “컴퓨터”가 모델이 현실의 작업을 수행하는 익숙한 인터페이스가 된다. - `@cloudflare/computer`는 코드가 isolate, 컨테이너, 웹 브라우저 중 어디에서 실행되는지에 대한 세부 사항을 플랫폼이 처리하는 런타임이다. - 각 에이전트에 작업 공간과 실행 환경을 제공하면서 효율성과 확장성을 최적화한다. ## 컨테이너 중심 구조의 확장성 문제 - 초기에는 에이전트 전체를 컨테이너 안에서 실행하는 방식이 일반적이었다. - 최근에는 에이전트의 판단 루프와 실제 코드 실행 환경을 분리하고, 샌드박스를 도구로 호출하는 구조가 확산되고 있다. - 그러나 사용자마다 에이전트 전용 컨테이너를 제공하면 수억, 수십억 개의 동시 에이전트를 감당할 컴퓨팅 자원이 부족하다. - 이 때문에 에이전트 시스템에는 GPU뿐 아니라 막대한 양의 CPU 컴퓨팅 자원도 필요하다. ## Isolate와 컨테이너의 결합 - Cloudflare는 수년 전부터 빠르게 생성·삭제할 수 있고 수평 확장에 적합한 isolate를 핵심 컴퓨팅 단위로 개발해 왔다. - isolate는 다음과 같은 특성을 가진다. - 매우 빠른 시작과 종료 - 유휴 상태에서의 휴면 - 에이전트 상태 저장 - 신뢰할 수 없는 코드를 실행하기 위한 추가 isolate 생성 - 대규모 수평 확장 - Cloudflare의 기존 구조에서는 Durable Object 안에서 에이전트 루프를 isolate로 실행하고, 무거운 작업이 필요할 때만 연결된 컨테이너를 도구로 호출한다. - 즉, 가벼운 작업은 isolate에서 처리하고 Linux, npm, 네이티브 바이너리 등이 필요한 작업만 컨테이너에서 실행해 성능과 비용을 조절한다. - `@cloudflare/computer`는 개발자가 이 여러 컴퓨팅 요소를 직접 조합하지 않아도 되도록 더 단순한 추상화를 제공하려는 실험이다. ## 공유 파일시스템 기반 작업 공간 - 에이전트에게 작업에 필요한 파일과 실행 환경이 미리 준비된 내구성 있는 파일시스템을 제공한다. - 에이전트는 작업 성격에 따라 실행 환경을 선택할 수 있다. - 파일 조작, 데이터 처리, Git 저장소 관리는 isolate에서 실행 - Linux 명령, npm, 네이티브 바이너리가 필요한 작업은 컨테이너에서 실행 - isolate와 컨테이너는 동일한 파일을 사용하며, 변경 사항은 원본 파일시스템과 동기화된다. - 파일시스템은 Git 저장소, 스토리지 버킷, 임의의 파일을 대상으로 사용할 수 있다. - 파일 읽기·쓰기·수정은 Code Mode나 Bash 명령으로 수행할 수 있다. - 모든 작업은 다음 방식으로 관리된다. - 권한 제어 - 감사(audit) - 관찰 및 추적(observability) - 따라서 에이전트가 수행할 수 있는 변경 범위를 세밀하게 제한하고, 어떤 작업을 했는지 기록으로 남길 수 있다. ## 사용 방법과 에이전트 통합 - 패키지는 npm으로 설치한다. ```bash npm install @cloudflare/computer ``` - Durable Object에 `Workspace`를 생성해 가상 파일시스템과 실행 런타임을 연결한다. - `Workspace`는 Durable Object의 저장소를 이용해 에이전트별 상태와 파일을 지속적으로 보관한다. - 예시에서는 `@cloudflare/think` 기반 에이전트가 버그 트리아지를 수행하도록 구성한다. - 시스템 프롬프트를 통해 에이전트가 다음 작업을 수행하게 할 수 있다. - `/workspace/repo`의 프로젝트 조사 - 버그 재현 - 안전한 경우 집중적인 수정 - 검증 명령 실행 - 변경 내용과 실행한 명령, 검증 결과 보고 - `@cloudflare/computer`는 기본 실행 백엔드 외에도 개발자가 직접 백엔드를 작성할 수 있다. - 제공된 `CloudflareContainerBackend`를 사용하면 Workspace를 Cloudflare Container와 연결할 수 있다. - `withWorkspaceContainer` 같은 헬퍼를 통해 에이전트 Durable Object와 컨테이너를 결합한다. ## 실용적인 의미 - 가벼운 작업은 isolate로 처리하고 무거운 작업만 컨테이너로 넘기는 구조가 대규모 에이전트 서비스에 적합하다. - 에이전트별 전용 컨테이너를 항상 실행하는 방식보다 자원 사용량과 비용을 줄일 가능성이 크다. - 파일 변경 권한과 실행 기록을 통제할 수 있어 코드 수정 에이전트, 버그 트리아지, 자동화된 개발 작업에 유용하다. - 현재는 초기 공개 프리뷰이므로, 실제 도입 시 지원되는 백엔드와 API 안정성, 작업 격리 수준, 비용 구조를 확인하는 것이 좋다.

container-sandboxingtypescriptcloudflare-workersdurable-objects+3

figma2023년 10월 23일

서버 측 샌드박싱 (새 탭에서 열림)

컨테이너와 seccomp는 가상 머신보다 가볍게 서버 측 작업을 격리할 수 있지만, 기본 설정만으로 안전한 샌드박스가 되는 것은 아니다. 컨테이너 탈출 위험은 런타임 구현, 운영체제 커널 기능, 런타임 설정에 좌우되며, 침해된 컨테이너가 호스트나 다른 시스템에 미치는 영향까지 함께 제한해야 한다. Figma는 컨테이너의 OS 수준 격리 기능과 seccomp를 활용해 성능과 보안 사이의 균형을 맞추고 있다. ## 컨테이너와 가상 머신의 차이 - 가상 머신은 하이퍼바이저를 통해 운영체제 수준에서 격리한다. - 컨테이너는 호스트 OS의 커널 기능을 공유하며, 다음과 같은 기능을 이용해 격리한다. - Linux namespaces - cgroups - 권한 강등(privilege dropping) - seccomp - SELinux, AppArmor 같은 필수 접근 제어(MAC) - 컨테이너는 VM보다 가볍고 효율적이지만, 격리 수준을 사용자가 직접 세밀하게 설정해야 한다. - 설정 자유도가 높은 만큼 잘못된 구성으로 인해 보안 취약점이 발생할 가능성도 크다. ## 샌드박싱이 필요한 이유 - 이미지 처리와 데이터 파싱처럼 애플리케이션에 필수적인 기능은 외부 입력을 다루므로 취약점 위험을 포함한다. - 모든 보안 취약점을 사전에 제거하는 것은 비용이 많이 들고 현실적으로 어렵다. - 따라서 취약한 작업이 실행되더라도 호스트와 다른 시스템으로 피해가 확산되지 않도록 서버 측 샌드박싱, 즉 workload isolation을 적용한다. - 격리 설계에서는 두 가지 질문을 중심으로 보안성을 평가한다. - 악성 작업이 컨테이너에서 탈출해 호스트를 변경하거나 장악할 수 있는가? - 컨테이너를 탈출하지 못하더라도 컨테이너 권한으로 다른 시스템에 접근하거나 피해를 줄 수 있는가? ## 컨테이너에서 호스트로 이어지는 공격 표면 컨테이너 탈출 가능성은 컨테이너 자체보다 여러 구성 요소의 조합에 의해 결정된다. - 주요 공격 표면은 다음 세 가지다. - 컨테이너 런타임 구현의 버그 - 런타임이 사용하는 운영체제 커널 기능과 인터페이스 - 런타임 보안 설정 및 구성 오류 - Linux 환경에서 Docker는 일반적으로 runC 런타임을 사용한다. - runC와 Docker는 namespaces, cgroups, 권한 강등, seccomp, SELinux, AppArmor 등을 조합해 격리를 제공한다. - 커널 취약점이나 런타임 구현 오류, 잘못된 설정이 있으면 악성 작업이 다음과 같은 행위를 할 수 있다. - 호스트 파일 수정 - 호스트에서 코드 실행 - 컨테이너 탈출 - 컨테이너의 기본 설정이 과거보다 안전해졌더라도, 특정 샌드박싱 용도에 충분한지는 사용자가 직접 검증해야 한다. ## 침해된 컨테이너의 피해 제한 컨테이너 내부에서 작업이 침해되었다고 가정하고, 호스트뿐 아니라 주변 시스템에 대한 접근도 차단해야 한다. - 컨테이너 설정을 강화해 호스트 장악을 방지해야 한다. - 컨테이너에 다음 자원을 불필요하게 제공하지 않는 것이 중요하다. - 네트워크 장치 - 인증 자격 증명 - 다른 작업의 데이터 - 컨테이너를 별도의 격리된 네트워크에 배치할 수 있다. - 오케스트레이션 시스템을 사용해 입력은 통제된 채널로 전달하고, 출력도 검증·제한된 방식으로 수집한다. - 핵심은 “컨테이너가 침해되지 않을 것”이 아니라 “침해되더라도 피해 범위를 제한할 것”이라는 방어적 설계다. ## seccomp의 역할 - seccomp(secure computing mode)는 프로그램이 호출할 수 있는 시스템 콜을 제한하는 Linux 기능이다. - 시스템 콜을 허용 목록 또는 제한 정책으로 관리하면, 컨테이너 프로세스가 커널과 상호작용할 수 있는 범위를 줄일 수 있다. - 컨테이너 격리는 런타임, 커널 기능, 설정의 결합으로 구현되므로 seccomp 역시 다른 보안 기능과 함께 사용해야 한다. - 제공된 글 내용은 seccomp 보안 모델을 소개하는 부분에서 중단되어 있어, 이후 Figma의 구체적인 nsjail 구성과 운영 방식은 확인할 수 없다. 컨테이너를 서버 측 샌드박스로 사용할 때는 기본 설정을 그대로 신뢰하지 말고, 최소 권한·제한된 시스템 콜·격리된 네트워크·자격 증명 차단을 함께 적용하는 것이 좋다. 특히 컨테이너 탈출 방지와 침해 이후 피해 제한을 별개의 보안 목표로 보고 설계해야 한다.

container-sandboxingdockerseccompcgroups+4