지난번까지 Omnigent를 실제로 구동하여 Polly의 크로스 리뷰를 스모크 테스트 (Smoke Test)로 통과시켰습니다. 하지만 구동하는 동안 "결국 어떤 컴포넌트가 어디서 동작하는지"가 이해하기 어렵다고 느꼈습니다. 특히 "샌드박스 (Sandbox)"라는 단어가 두 가지 서로 다른 것을 가리키고 있어 혼란의 원인이 됩니다.

이 기사에서는 Omnigent의 구성 요소를 하나씩 쌓아 올리며 이해하고, 마지막으로 로컬 실행과 Databricks Managed에서 배치가 어떻게 달라지는지까지 순서대로 따라가 보겠습니다. 1단계마다 부품을 하나씩 추가하므로, 끝까지 읽으면 전체상을 머릿속에 그려낼 수 있을 것입니다.

먼저 토대 확인입니다. 하네스 (Harness)란 모델을 감싸 에이전트 (Agent)로 만드는 층을 말합니다. 파일을 읽고, 터미널 명령을 실행하며, 도구 (Tool)를 호출할 수 있도록 합니다. Claude Code, Codex, Pi는 모두 하네스입니다.

메타 하네스 (Meta-Harness)는 그 한 단계 위에 위치하며, 각각의 하네스를 교체 가능한 부품으로 취급합니다. 이것이 가능한 이유는 내부 구현은 다르더라도 모든 하네스가 사용자 관점에서는 동일한 인터페이스를 갖기 때문입니다. 메시지와 파일이 입력되고, 텍스트 스트림과 도구 호출이 출력됩니다. 이 공통 인터페이스 덕분에 단일 층에서 임의의 하네스를 감쌀 수 있습니다. 아래에서 살펴볼 컴포넌트들은 이 "공통 층"을 실현하기 위한 부품이라고 생각하고 읽어주세요.

당신이 처음 접하는 것은 UI입니다. CLI, Web UI (localhost:6767), 모바일, 데스크톱 앱. 여기서 중요한 사실이 하나 있습니다. 이러한 UI는 모두 서버와 통신하며, 후술할 러너 (Runner)와는 직접 주고받지 않습니다.

서버는 중앙 조정자입니다. 관리하는 것은 세션 히스토리 (Session History, 모든 대화·메시지·도구 호출을 Postgres 또는 SQLite에 영속화), 결과물 (파일 및 업로드), 카탈로그 (등록된·내장된 에이전트 정의), MCP 프록시 및 정책 강제, 스킬, 인증 (내장 계정 또는 OIDC/SSO)입니다. 그리고 Web UI를 전달하며, WebSocket으로 통신합니다.

즉 서버는 "상태와 입구"를 가진 층입니다. 무엇이 일어났는지에 대한 기록도, 누가 액세스할 수 있는지도, 어떤 UI에서 보이는지도 여기에 집약됩니다.

서버는 기록과 전달을 담당하지만, 실제로 코드를 실행하는 것은 별개의 부품입니다. 여기서 호스트 (Host)와 러너가 등장합니다.

호스트 (데몬, Daemon)는 코드 실행이 실제로 일어나는 머신에서 동작합니다. 노트북이든 클라우드의 컨테이너든 상관없습니다. 서버로의 안전한 터널을 구축하고, 러너를 기동하며, 그 라이프사이클을 관리합니다. omnigent host가 바로 이것입니다.

러너는 세션마다 실행되는 프로세스입니다. Omnigent의 루프를 실행하고, 하네스 (Claude Code, Codex, Claude SDK 등)를 관리하며, 도구를 구동하고, 이벤트를 WebSocket으로 서버에 보냅니다. 서버가 호스트 상에서 러너를 기동하는 관계입니다.

이 호스트/러너의 분리가 "수중에 있는 Claude Code나 Codex가 그대로 동작하는" 이유입니다. 노트북 상에서 기동된 러너는 해당 머신의 도구·파일·인증 정보에 직접 액세스할 수 있기 때문입니다.

러너의 내부를 한 단계 더 열어보겠습니다. 러너가 관리하는 하네스야말로 지금까지 "뇌 (Brain)"라고 불러온 것의 실체입니다. Polly의 경우, 뇌는 claude-sdk 하네스로 동작하는 오케스트레이터 (Orchestrator)입니다.

Polly와 같은 오케스트레이터는 스스로 코드를 작성하지 않고, 서브 에이전트 (Sub-agent: claude_code / codex / pi)에게 일을 맡깁니다. 각 서브 에이전트는 각각 전용 git worktree에서 동작합니다. 이를 정리하면, 뇌는 러너 내에서 동작하는 지휘 역할의 하네스, 서브 에이전트는 뇌가 기동하는 별도의 CLI 프로세스라는 관계가 됩니다. 지난번 스모크 테스트에서 본 "claude_code가 subtract를, codex가 multiply를, 별도의 worktree에서 병렬 구현"한 것은 바로 이 층에 대한 이야기였습니다.

여기서 첫 번째 샌드박스가 등장합니다. Omnibox는 Databricks의 보안 팀이 만든 OS 레벨의 샌드박스입니다.

작동 방식은 커널 레벨의 강제(Kernel-level enforcement)입니다. Linux에서는 bubblewrap + seccomp를, macOS에서는 Seatbelt를 사용하여 파일 시스템 액세스를 잠그고(lockdown), 외부 통신은 egress 프록시 계층에서 가로챕니다. 실제 효과로서, 에이전트는 GitHub 토큰과 같은 비밀 정보를 직접 볼 수 없습니다. 토큰은 승인된 통신 시에만 프록시 측에서 주입됩니다. 이는 프롬프트로 "인증 정보를 공유하지 마라"고 지시하는 것과는 근본적으로 다르며, OS 계층에서 강제된다는 점이 핵심입니다.

그리고 중요한 것은, 이것이 로컬에서도 항상 작동하고 있다는 점입니다. 지난번 스모크(smoke)에서도 당신의 Mac에서는 Seatbelt가 claude_code / codex의 각 터미널을 감싸고 있었습니다.

부품이 모두 갖춰졌으므로, omni run으로 실행된 로컬 실행의 배치를 한 장의 그림으로 정리합니다. 단 하나의 명령어로 서버, 호스트, 러너(Runner)가 모두 당신의 Mac 위에 올라가며, localhost:6767에 Web UI가 열리고, 동일한 세션이 브라우저나 스마트폰에도 동기화됩니다.

위의 그림이 로컬 실행의 전체 모습입니다. 당신의 Mac 안에 서버(SQLite에 세션 기록과 파일 저장. 지난번에 발견한 mlflow.db는 트레이스(trace)용 별도 DB), Web UI, 호스트 데몬(Host daemon), 러너가 탑재됩니다. 러너 안에는 뇌(Polly의 오케스트레이터)가 있으며, 그 아래의 Omnibox 안에서 서브 에이전트(Sub-agent)가 워크트리(worktree)별로 동작합니다. Mac 밖으로 나가는 것은 모델 호출뿐이며, 이번에는 로컬의 claude / codex 구독을 경유했습니다.

여기까지가 "전부 당신의 Mac 위"라는 정직한 구성입니다.

두 번째 샌드박스는 완전히 별개의 것입니다. 클라우드 샌드박스 호스트(Cloud sandbox host)는 러너를 노트북에서 원격 컨테이너로 옮기는 메커니즘입니다. 노트북을 닫아도 에이전트가 계속 동작하며, 클라우드의 계산 자원을 가진 격리된 환경에서 실행됩니다. Modal, Daytona, 그리고 후술할 Databricks Sandbox 등이 이에 해당합니다.

문서 자체에서도 이 두 가지를 명확히 구분하고 있습니다. 클라우드 샌드박스 호스트 페이지에는 "에이전트가 파일 시스템이나 네트워크에서 무엇에 액세스할 수 있는지를 제한하고 싶다면, 그것은 Omnibox입니다"라는 주석이 있습니다. 정리하자면 다음과 같습니다.

Omnibox는 에이전트가 "무엇을 만질 수 있는지"를 제한합니다. OS 레벨에서 로컬이든 클라우드든 항상 작동합니다. 클라우드 샌드박스는 러너가 "어디에서 동작하는지"를 결정합니다. 즉, 원격 실행 환경, 즉 위치에 대한 이야기입니다. 이 두 가지를 혼동하지 않는 것이 Omnigent의 구성을 이해하는 가장 큰 요령입니다.

마지막으로, Databricks Managed에서 배치가 어떻게 변하는지 살펴보겠습니다. 결론부터 말씀드리면, 로컬에서는 전부 Mac 위에 있었던 부품 중 서버와 러너가 Databricks 측으로 이동합니다.

Databricks는 풀 매니지드(Full-managed) 버전을 제공하며, 워크스페이스의 ID 제공자(ID Provider)와 통합된 Databricks 운영 Omnigent 서버, Foundation Model API와 AI Gateway를 통한 모델 액세스, 그리고 안전한 협업을 위한 Databricks Sandbox가 포함됩니다.

위의 그림이 이에 해당합니다. 사용자 측은 브라우저(/omnigent)만 사용하게 되며, 실질적으로는 UI 클라이언트가 됩니다. Databricks 측에는 Databricks 운영 Omnigent 서버(SSO 연동)와 Web UI가 있으며, 러너의 위치는 두 가지 선택지가 있습니다. Databricks Sandbox(Databricks가 제공하는 매니지드 클라우드 호스트. 격리되고 재현 가능한 환경으로, 노트북이 슬립 모드에 들어가도 계속 동작함)를 host picker에서 선택하거나, 자신의 머신(노트북 또는 Databricks VM)을 호스트로 등록하는 것입니다.

모델 액세스 방식도 달라집니다. 워크스페이스의 Foundation Model API를 AI Gateway를 통해 자동으로 라우팅하므로, 관리해야 할 API 키가 없으며 모델 이용은 AI Gateway의 거버넌스(Governance)와 제어(Control)를 계승합니다. 다만 제약 사항도 있습니다. Databricks Sandbox 호스트는 항상 AI Gateway를 통해 모델에 액세스하며, 고유한 모델 API 키를 가져올 수 없습니다. 내장된 컨텍스트 정책(Context Policy)만 지원하며, 커스텀 YAML 정책은 사용할 수 없습니다. Unity AI Gateway 지원 리전과 워크스페이스에서의 Sandbox 프리뷰 활성화가 전제 조건입니다.

Omnigent의 구성은 다음 지도를 머릿속에 그려두면 길을 잃지 않습니다.

구성 요소 자체(서버 / 호스트 / 러너 / UI / Omnibox)는 로컬(Local)이든 매니지드(Managed)이든 동일합니다. 변하는 것은 단 두 가지, "위치"와 "모델로 들어가는 입구"입니다. 로컬에서는 모든 것이 사용자의 Mac 위에 있으며, 모델은 로컬 CLI 구독을 통해 접근합니다. 매니지드에서는 서버와 러너가 Databricks 측으로 이동하며, 모델은 AI Gateway를 통해 접근하게 됩니다.

그리고 "샌드박스(Sandbox)"라는 용어는 두 가지 서로 다른 것을 지칭합니다. Omnibox는 에이전트가 무엇을 만질 수 있는지를 제한하는 OS 레벨의 안전장치로, 항상 작동하고 있습니다. 클라우드 (Databricks) 샌드박스는 러너가 어디에서 동작할지를 결정하는 실행 환경입니다. 이 두 가지를 구분해서 생각한다면, 로컬에서 매니지로 시점을 옮기더라도 어떤 부품이 어디에 있는지 놓치지 않을 수 있습니다.

• Omnigent on Databricks | Databricks 문서
• Omnigent Quickstart | Databricks 문서
• Deploy overview (server / runner / host)| Omnigent 공식
• Cloud Sandbox Host | Omnigent 공식
• omnigent-ai/omnigent (GitHub)