OpenCompute 소개
Walker Hildebrand, Sherry Bai - 2026년 10월 14일 - 7분 분량
제품
공유
에이전트가 당신이 잠든 사이에도 일할 수 있는 세상에서, 우리는 어떻게 이들이 여러분의 인프라에서 실행되도록 할 수 있을까요?
에이전트가 채팅 창에 있을 때 답은 간단합니다. 해당 세션을 위해 설정한 머신에서 실행됩니다. 하지만 에이전트가 알림을 조사하고, 비동기 요청에 응답하고, 예약된 Automations를 실행하고, 하루 종일 이슈를 처리한다면 문제는 온디맨드 컴퓨트가 됩니다. 이제 단순히 에이전트를 실행할 곳만 필요한 것이 아니라, 작업량을 따라잡을 수 있는 컴퓨트 플릿이 필요합니다.
오늘 저희는 OpenCompute, 즉 여러분이 선택한 런타임에서 에이전트 샌드박스를 위한 Factory의 셀프호스티드 오케스트레이터를 프라이빗 프리뷰로 공개합니다.
OpenCompute 는 고객이 관리하는 인프라에 온디맨드 프로비저닝과 라이프사이클 관리를 제공하며, Environments, Automations, 그리고 Remote Control전반에 걸친 Factory 경험과 통합됩니다. 에이전트는 필요할 때 컴퓨터를 제공받고, 그 컴퓨터가 어디서 실행될지는 여러분이 선택합니다.
이는 하나의 확신을 바탕으로 만들어졌습니다. 자율 소프트웨어 개발을 도입하는 것이 인프라의 열쇠를 다른 누군가에게 넘겨주는 일이 되어서는 안 된다는 것입니다.
그렇다면 우리는 어떻게 6주 만에 맞춤형 온프레미스 환경에 이틀 만에 배포할 수 있는 것을 만들었을까요?
Remote Control 기반으로 구축하기
2026년 4월, 우리는 Droid Computers를 소개했습니다. Droid를 오케스트레이션하기 위한 지속적인 머신입니다. 고객은 Factory의 클라우드에서 컴퓨터를 생성하거나 Remote Control을 통해 자신의 머신을 등록할 수 있었습니다.
Remote Control 경험은 컴퓨트 계층과 무관하게 Factory와의 통합을 가능하게 합니다. 어떤 머신에서든 Droid를 실행하고, Factory에 연결하고, 원격으로 작업할 수 있습니다. 그 머신은 워크스테이션, 클라우드 VM, 또는 사설 네트워크 내부의 서버일 수 있습니다. 에이전트 실행 루프가 해당 머신에서 실행되기 때문에, Droid는 내부 환경의 프라이빗 저장소, 패키지 레지스트리, 서비스와 함께 작업할 수 있습니다. 고객은 에이전트가 이용할 수 있도록 이러한 시스템을 외부에 공개할 필요가 없습니다. BYOK 및 셀프호스티드 추론 지원은 데이터 주권에 대한 추가적인 통제를 제공합니다.
Remote Control은 이 모델의 가치를 증명했으며, 업계 전반도 같은 방향으로 움직였습니다. 그러나 우리는 또 하나의 명확한 공백을 발견하기 시작했습니다. 엔터프라이즈 고객들은 한 번에 한 대의 컴퓨터가 아니라 컴퓨터 플릿을 관리할 수 있는 솔루션을 필요로 했습니다.
머신은 플릿이 아니다
Remote Control은 개별 사용자 또는 서비스에 한정된 지속적인 머신, 즉 구성된 워크스테이션, 개발 VM, 또는 특수 하드웨어를 갖춘 박스에 적합합니다. 이것이 답하는 질문은 이렇습니다. 가장 필요한 곳으로 에이전트를 어떻게 데려갈 수 있을까?
하지만 우리는 조직 전체의 요구를 충족하는 컴퓨트, 즉 대화형 세션을 지원하는 동시에 작업이 발생하면 에이전트가 독립적으로 동작할 수 있는 컴퓨트가 필요했습니다.
알림이 누군가 먼저 VM을 프로비저닝하지 않고도 조사를 시작할 수 있어야 합니다. Slack 위임이 몰려도 팀이 가용 머신 수를 세고 있게 해서는 안 됩니다. 완료된 작업이 유휴 리소스를 무기한 실행 상태로 남겨두어서도 안 됩니다.
저희의 관리형 오퍼링은 이미 그 라이프사이클의 일부를 처리하고 있었습니다. 셀프호스티드 머신에는 동일한 네이티브 프로비저닝, 일시 중단 및 재개 통합이 없었습니다. 고객은 원하는 곳에서 Droid를 실행할 수 있었지만, 플릿 운영은 직접 해야 했습니다.
곳곳의 샌드박스
저희는 고객들의 클라우드 인프라에서 폭넓은 다양성을 보았습니다. 일부는 기존 Kubernetes 클러스터에서 에이전트를 실행하기를 원했고, 일부는 특수 하드웨어를, 또 일부는 개발자들이 이미 의존하던 내부 플랫폼을 원했습니다. 새로운 microVM 인프라를 도입 중이거나 솔루션을 찾아보고 있는 고객도 있었습니다.
저희의 목표는 단순히 고객에게 샌드박스 플릿을 제공하는 것이 아니었습니다. 어떤 인프라에서든 플릿 관리가 작동하도록 만들어야 했습니다. 우리는 모든 고객을 저희 환경으로 데려오는 것이 아니라, 오케스트레이션을 고객의 환경으로 가져가야 했습니다.
에이전트를 위한 샌드박스 환경 작업은 끊이지 않고 진행되고 있습니다. 서드파티 클라우드 샌드박스 플랫폼으로는 E2B, Daytona, Modal이 있습니다. Kubernetes Agent Sandbox, Google의 Agent Substrate, AWS Lambda MicroVMs 같은 프로젝트들도 bring-your-own-cloud 및 bring-your-own-infrastructure 솔루션에 대한 수요가 커지고 있음을 보여줍니다.
각 플랫폼은 격리, 지속성, 시작 속도, 운영 단순성, 배포 유연성 사이에서 서로 다른 트레이드오프를 만듭니다. 수명이 짧은 작업에 적합한 백엔드가 지속적인 개발 환경에는 적합하지 않을 수 있습니다. 스타트업에 잘 맞는 서비스가 규제를 받는 기업의 네트워크 내부에서는 사용할 수 없을 수도 있습니다. 그리고 6개월 후의 최선의 선택지는 오늘의 최선의 선택지와 다를 수 있습니다.
우리는 컴퓨팅 인프라 위에 하나의 계층을 만들기로 했습니다. OpenCompute는 공통 라이프사이클, 즉 컴퓨터 요청, 원하는 상태로 만들기, 활동 추적, 정책 및 공급자 역량에 따른 일시 중지 또는 종료를 담당합니다. 공급자는 이러한 작업을 가능하게 하는 인프라 메커니즘을 담당합니다. 이를 통해 우리는 제품의 기반을 교체할 때까지 고객을 기다리게 하지 않고도 생태계 전반의 개선으로부터 혜택을 얻을 수 있습니다.
인터페이스가 그 일을 하도록 만들기
OpenCompute 개발은 처음부터 에이전트 네이티브 방식으로 진행되었으며, 개념을 입증하기 위한 Mission 으로 시작했습니다. 우리의 임무는 경계를 정의하고, 동작을 명시하고, 정확성을 테스트 가능하게 만드는 것이었습니다. 나머지는 Droid가 인간의 지도 아래 처리했습니다.
그 덕분에 인터페이스 설계가 특히 중요했습니다. "이 프로바이더에 대한 지원을 구축하라"는 것은 개방형 과제입니다. "이 계약을 구현하고 이 적합성 테스트를 통과하라"는 것은 에이전트에게 범위가 한정된 문제와 검증 가능한 성공의 정의를 제공합니다.
OpenCompute를 고객에게 유연하게 만든 동일한 분리 구조가 개발을 다루기 쉽게 만들었습니다. 새 드라이버, 즉 프로바이더별 통합은 플릿 관리를 재작성하지 않고도 자신의 프로바이더에 집중할 수 있었습니다. 공유 컨트롤 플레인은 또 다른 클라우드 API를 학습하지 않고도 개선될 수 있었습니다.
이 접근 방식 덕분에 우리는 AWS Lambda MicroVMs, Kubernetes, EC2, Agent Sandbox, Agent Substrate 및 기타 실험적 프로바이더에 걸쳐 통합을 개발하고 평가할 수 있었습니다. 이것들은 동일한 구현도, 동등하게 성숙한 백엔드도 아니었습니다. 그것이 바로 요점이었습니다. 아키텍처가 각각을 별도의 제품으로 만들지 않고도 차이를 수용할 수 있었다는 것입니다.
첫 배포까지 6주
가장 분명한 시험은 첫 고객 배포에서 나왔습니다. 고객은 자체 프로바이더 인터페이스를 갖춘 맞춤형 온프레미스 환경 안에 OpenCompute가 필요했습니다. 고객을 만나러 비행기에 타기 직전, 우리는 가지고 있던 정보를 바탕으로 해당 환경용 초기 드라이버를 구축하는 Mission을 시작했습니다.
착륙할 때쯤에는 드라이버가 완성되어 있었습니다. 현장에서 이틀을 보낸 후, 고객은 OpenCompute를 통해 첫 샌드박스를 프로비저닝했습니다. 사용자 관점에서는 관리형 Droid Computer를 만드는 것처럼 보였지만, 그 샌드박스는 고객의 데이터 센터에서 실행되고 있었습니다. 우리는 그 고객을 위해 새로운 아키텍처를 발명할 필요가 없었습니다. 이미 정의해 둔 인터페이스에 고객의 인프라를 연결하기만 하면 되었습니다.
초기 프로토타입부터 첫 고객 배포까지: 6주.
그 첫 통합이 엔지니어링 작업의 끝은 아니었습니다. 영속성, 복구, 배포 도구, 운영 강화는 그 이후에도 계속되었습니다. 하지만 중심 베팅은 검증되었습니다. 새 프로바이더 통합은 플랫폼 재작성이 아니라 드라이버 문제가 될 수 있다는 것이었습니다.
아키텍처 개요
OpenCompute는 Factory 백엔드를 고객의 기반 컴퓨트 플레인에 연결하는 셀프 호스티드 서비스입니다.
외부로 연결하고, 내부에서 실행
OpenCompute는 사용자 환경에서 실행되며 Factory로의 아웃바운드 TLS 보안 WebSocket 연결을 설정합니다. Factory는 그 연결을 통해 승인된 컴퓨트 요청을 보냅니다. 사용자는 공개 OpenCompute 엔드포인트를 노출하거나 Factory를 위한 인바운드 방화벽 포트를 열 필요가 없습니다.
등록 시, 사용자의 OpenCompute 배포는 Factory에 공개 키를 등록합니다. 연결 시, 새로운 챌린지에 서명함으로써 해당 개인 키의 소유를 증명합니다. 개인 키는 사용자의 통제 하에 유지되며 지원되는 클라우드 KMS에 둘 수 있습니다.
OpenCompute가 프로비저닝하는 각 샌드박스는 오늘날 원격 제어 컴퓨터와 정확히 같은 방식으로 Factory에 자체 아웃바운드 연결을 설정합니다. 내부 저장소와 서비스는 비공개로 유지될 수 있습니다. Droid는 사용자 네트워크 내부에서 그것들에 접근합니다.
데이터 배치에 대한 참고 사항: 컴퓨트 배치는 추론 라우팅 및 세션 저장과 분리되어 있습니다. 세션 데이터를 완전히 로컬에 유지하는 것은 사용자의 추론 및 동기화 구성에 따라 달라집니다.
의도를 기록한 다음 조정
프로비저닝은 단일한 신뢰할 수 있는 API 호출이 아닙니다. 특히 익숙하지 않은 프로바이더를 다룰 때 그렇습니다. 연결은 사라지고, 프로바이더는 처리량을 제한하고, 프로세스는 요청이 성공한 후 응답이 도착하기 전에 재시작될 수 있습니다. OpenCompute는 선언적 라이프사이클 모델로 이를 해결합니다. Go로 작성된 컨트롤 플레인은 사용자 환경에서 실행 중인 Postgres 데이터베이스에 원하는 상태와 관찰된 컴퓨터 상태를 기록합니다. 리컨실러는 컴퓨터를 요청된 상태로 만들기 위해 지속적으로 작업합니다.
컴퓨터 생성은 프로바이더가 완료할 때까지 요청을 열어 두는 대신 영속적인 의도를 기록합니다. 리컨실러는 프로비저닝과 관찰을 처리하고, 복구 가능한 실패를 재시도하며, 지원되는 라이프사이클 전환을 수행합니다. 의도가 영속적이기 때문에 컨트롤 플레인 재시작이 미완료 작업을 지우지 않습니다.
컴퓨터는 불변(immutable) Build에서 시작되며, 환경 준비와 머신 생성을 분리합니다. S3 호환 스토리지가 빌드 아티팩트와 스냅샷 페이로드를 보관합니다. 활동 신호와 컴퓨터별 라이프사이클 설정이 컨트롤 플레인에 컴퓨터를 언제 실행 상태로 유지하고 언제 라이프사이클 조치를 취할지 알려줍니다.
인프라가 아니라 동작을 표준화
각 프로바이더 통합은 독립형 gRPC 드라이버로 실행됩니다. 드라이버는 공통 작업을 컴퓨터 생성, 관찰, 명령 실행, 삭제에 대한 백엔드의 네이티브 메커니즘으로 변환합니다.
프로바이더별 동작은 컨트롤 플레인의 데이터베이스와 조정 로직 밖에 유지됩니다. 드라이버는 하나의 필수 게스트 에이전트를 채택하는 대신 자신의 백엔드에 적합한 전송 및 런타임을 사용할 수 있습니다.
하지만 공통 인터페이스는 차이에 대해 정직할 때만 유용합니다. 모든 백엔드가 컴퓨터를 일시 중단하거나, 디스크를 스냅샷하거나, 포크할 수 있는 것은 아닙니다. 따라서 OpenCompute는 필수 Core 적합성 프로필과 선택적 Suspend, Snapshot, Fork 프로필을 정의합니다. 블랙박스 테스트가 드라이버가 지원한다고 주장하는 동작을 검증합니다. 지원되지 않는 요청은 영속 상태를 변경하기 전에 거부되며, 프로비저닝 도중에 오류로 나타나지 않습니다.
이 계약은 벤더 중립적이기도 합니다. Factory는 OpenCompute의 가능한 클라이언트 중 하나일 뿐이며, 드라이버는 Factory 고유 기능에 비종속적입니다. OpenCompute는 자체 API, CLI, 관리 패널을 제공합니다. 컴퓨트를 관리하는 이 계층은 처음에 그것을 요청한 제품과 독립적으로도 유용해야 하기 때문입니다.
다음 단계
우리는 OpenCompute를 오픈소스로 공개할 계획입니다. 목표는 단순히 구현체를 공개하는 것이 아니라, 에이전트 시스템을 구축하는 사람들에게 계약(contract), 적합성 테스트, 드라이버 모델이 유용하게 쓰이도록 하는 것입니다.
또한 이것이 Factory의 미래를 위한 기반이라고 생각합니다. 대화형 세션, 예약된 Automations, 장애 조사, 위임된 작업 각각이 별도의 인프라 이야기를 필요로 해서는 안 됩니다. Factory가 운영하든 고객이 운영하든, 동일한 라이프사이클 계층을 통해 필요한 환경을 요청할 수 있어야 합니다.
우리는 그 기반을 더 많은 사람들의 손에 쥐여 주고, 사람들이 다음으로 어떤 공급자를 연결하는지 지켜보기를 기대합니다.
에이전트 워크로드의 미래는 한 회사의 클라우드에 있는 한 종류의 머신에서 실행되지 않을 것입니다. OpenCompute는 그 미래를 위해 우리가 구축하려는 방식입니다.
OpenCompute는 현재 프라이빗 프리뷰 상태입니다. OpenCompute를 탐색하는 데 관심이 있으시면 Factory의 담당 계정 관리자에게 문의하시기 바랍니다.