AI 생성 이미지
AI 에이전트의 역할이 답변 생성에서 작업 수행으로 넓어지고 있습니다. 코드를 실행하고, 파일을 만들고, 프로세스를 띄우고, 여러 시도를 병렬로 비교하는 식입니다. 이 단계에서 필요한 것은 단순한 코드 실행기가 아니라, 에이전트가 안전하게 사용할 수 있는 독립 실행 환경입니다.
Daytona가 말하는 Agent-Native Compute는 이 문제를 겨냥합니다. Daytona는 AI 생성 코드 실행과 에이전트 워크플로를 위한 보안·탄력형 인프라 런타임이며, 그 중심에는 프로그래밍 방식으로 제어되는 샌드박스가 있습니다.1
에이전트에게 필요한 것은 ‘작은 컴퓨터’다
Daytona 샌드박스는 단순 격리 프로세스가 아니라, 격리된 전체 컴퓨터처럼 동작합니다. 각 샌드박스는 전용 커널, 파일시스템, 네트워크 스택을 갖고, 할당된 vCPU·RAM·디스크를 포함합니다.1
이 구조가 중요한 이유는 에이전트의 작업 방식 때문입니다. 에이전트는 단순히 코드를 한 번 평가하는 데 그치지 않습니다. 패키지를 설치하고, 파일을 수정하고, 프로세스를 실행하고, 결과를 확인한 뒤 다음 행동을 이어가야 합니다. 즉 “코드를 실행할 공간”보다 “작업을 계속할 수 있는 환경”이 필요합니다.
Daytona는 Python, TypeScript, JavaScript 코드 실행을 지원하고, OCI 및 Docker 호환성을 기반으로 환경을 구성합니다.1 또한 SDK, API, CLI를 통해 샌드박스의 생명주기 관리, 파일시스템 조작, 프로세스 실행, 코드 실행, 런타임 구성을 프로그래밍 방식으로 제어할 수 있게 합니다.1
속도 수치보다 중요한 것은 워크로드의 성격이다
Daytona는 샌드박스 시작 시간을 약 60ms로 제시했고, 75초 동안 5만 건의 스타트업을 처리했으며, 하루 약 85만 건의 실행을 처리한다고 밝혔습니다.2 눈에 띄는 숫자지만, 핵심은 단순히 “빠르다”가 아닙니다.
에이전트 워크로드는 전통적인 개발 환경과 다릅니다. 사람이 하나의 환경에서 오래 작업하는 방식보다, 짧은 실행을 대량으로 만들고, 실패한 경로는 버리고, 유망한 경로만 이어가는 방식에 가깝습니다. 따라서 시작 속도, 격리, 병렬 실행, 상태 보존이 함께 설계되어야 합니다.
Daytona의 상태 저장 환경 스냅샷은 이 지점과 연결됩니다. 에이전트가 세션을 넘겨 작업을 이어가거나, 특정 시점의 환경을 다시 사용할 수 있게 해주기 때문입니다.1 이는 일회성 실행 샌드박스보다 에이전트형 워크플로에 더 적합한 접근입니다.
도입 여부를 판단할 때 볼 것
Daytona를 검토할 때는 성능 수치만 볼 것이 아니라, 에이전트가 실제로 어떤 실행 환경을 필요로 하는지부터 봐야 합니다.
단순 텍스트 생성이나 짧은 코드 평가가 전부라면 독립 샌드박스는 과할 수 있습니다. 반대로 다음과 같은 요구가 있다면 Agent-Native Compute 접근을 검토할 만합니다.
AI가 생성한 코드를 안전하게 실행해야 한다
파일 조작, 프로세스 실행, 런타임 설정이 필요하다
여러 실행 경로를 병렬로 실험해야 한다
세션 간 작업 상태를 유지해야 한다
격리된 환경에서 에이전트 워크플로를 운영해야 한다
Daytona 플랫폼은 인터페이스 플레인, 컨트롤 플레인, 컴퓨트 플레인으로 구성되며, 인터페이스 플레인은 클라이언트 인터페이스를 제공합니다.1 이는 사용자가 접근하는 계층과 실제 샌드박스를 운영하는 계층을 나눠 다루는 구조로 이해할 수 있습니다.
결국 Daytona Agent-Native Compute가 던지는 메시지는 분명합니다. 에이전트는 더 이상 모델 호출만으로 완성되지 않습니다. 실제 작업을 수행하는 에이전트 제품을 만들려면, 모델 성능만큼이나 빠르고 안전하며 지속 가능한 실행 환경이 중요해집니다.
1daytona module - github.com/daytonaio/daytona - Go Packages
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.