Omnigent 사용법: 여러 에이전트 CLI 통합 관리

Omnigent란 무엇인가

Omnigent는 오픈 소스 메타 하네스(meta-harness)입니다. 이는 이미 설치된 에이전트 명령줄 도구(CLI)를 구동하는 단일 오케스트레이션 계층입니다. Claude Code, Codex, Cursor, OpenCode, Hermes 또는 Pi를 대체하지 않습니다. Omnigent는 이들을 시작하고, 각각에 작업을 할당하며, 단일 정책 세트를 사용하여 하나의 세션 내에서 결과를 감독합니다. Databricks는 2026년 6월에 Apache 2.0 라이선스로 이 저장소를 공개했으며, 첫 페이지에는 여전히 Status: alpha라고 명시되어 있습니다.

이 도구의 실질적인 이점은 명확하며, 다음과 같이 간단히 설명할 수 있습니다. YAML 파일에 에이전트를 한 번 정의하고, 이를 실행할 하네스 이름을 지정합니다. 그 한 줄만 변경하면 동일한 에이전트가 다른 벤더의 CLI에서 실행됩니다. Omnigent는 에이전트 '내부'의 루프가 아니라 에이전트 '상위'의 루프를 제어하므로, 설정을 변경할 필요가 없습니다.

메타 하니스(meta-harness)란 무엇이며, 프레임워크와는 어떻게 다른가?

하니스는 모델을 루프 안에서 감싸는 프로그램입니다. 하니스는 프롬프트를 읽고, 도구를 호출하며, 파일을 수정하고, 결과를 보고합니다. Claude Code는 하니스입니다. Codex도 하니스입니다. 설치하고 로그인하면 스스로 작동합니다.

프레임워크는 코드를 작성할 때 사용하는 라이브러리입니다. 프레임워크를 import하고 Python으로 단계를 정의하면, 작성한 프로그램이 에이전트가 됩니다. 이 경우 벤더를 변경하려면 코드를 수정해야 합니다. 벤더의 클라이언트가 프로그램 내부에 연결되어 있기 때문입니다.

메타 하니스는 이 두 가지보다 한 단계 위에 위치합니다. 메타 하니스는 하니스를 자식 프로세스로 실행하는 관리자입니다. Omnigent는 벤더 CLI를 시작하고, 작업을 전달하며, 반환되는 결과를 읽습니다. 사용자는 이미 설치한 CLI를 그대로 유지하며, 이미 결제 중인 구독이나 API(application programming interface) 키도 그대로 사용합니다. 이것이 전체적인 차이점이며, 이 차이가 이 도구의 사용 대상을 결정합니다. 즉, 이미 여러 에이전트 CLI를 사용 중이며, 터미널 하나하나를 직접 조작하는 것에 지친 사람들을 위한 도구입니다.

오케스트레이션 계층은 어떤 문제를 해결하는가?

• 벤더 교체 비용이 한 줄로 줄어듭니다. 에이전트 정의에 harness와 model이 데이터로 포함되므로, 역할을 한 벤더에서 다른 벤더로 옮길 때 YAML 파일을 수정하기만 하면 되며 전체를 다시 작성할 필요가 없습니다.
• 벤더를 넘나드는 검토가 가능합니다. 한 모델이 작성한 diff를 다른 회사의 모델이 읽을 수 있습니다. 같은 계열의 모델은 동일한 사각지대를 공유하는 경향이 있으므로, 같은 벤더의 모델로부터 받는 두 번째 의견은 가치가 떨어집니다.
• 정책을 한곳에서 관리합니다. 지출 한도와 승인 프롬프트는 에이전트 파일에 선언되며, 그 아래의 모든 하위 에이전트에 적용됩니다.
• 세션이 특정 도구보다 오래 지속됩니다. 하나의 기록(transcript)이 여러 CLI에서 수행된 작업을 포괄하므로, 4개의 스크롤백을 이어 붙일 필요 없이 무슨 일이 있었는지 다시 읽을 수 있습니다.

비용은 계층 그 자체입니다. Omnigent의 모든 버그는 이제 사용자와, 이전에는 독립적으로 작동하던 에이전트 사이에 존재하는 버그가 됩니다. 알파 단계에서는 이것이 이론적인 문제가 아니라 실질적인 비용입니다.

멀티 에이전트 하네스가 단일 에이전트 도구와 공존하는 방식

아직 서버에서 에이전트를 하나도 실행해 본 적이 없다면, 그 단계부터 시작하십시오. VPS에서 코딩 에이전트 실행하기 가이드는 단일 에이전트 환경을 처음부터 끝까지 다루고 있으며, Omnigent는 이미 해당 환경이 구축되어 있다고 가정합니다. 자체 호스팅 AI 에이전트 분야는 에이전트 자체를 선택하는 영역이며, 여기서 사용되는 용어가 생소하다면 에이전트의 실제 작동 원리 학습을 먼저 진행하는 것이 좋습니다.

Omnigent는 커넥터 계층과는 다른 축에 위치합니다. 에이전트에 자체 데이터 소스 접근 권한 부여와 같은 작업은 에이전트가 무엇에 접근할 수 있는지에 관한 것입니다. 반면 Omnigent는 어떤 에이전트를, 어떤 순서로, 어떤 제한 내에서 실행할지를 다룹니다. 두 가지 모두 필요할 수 있으며, 이들은 서로 겹치지 않는 영역입니다.

설치 전 준비 사항

• Python 3.12 이상. 배포된 패키지는 requires-python >= 3.12을 명시합니다.
• tmux. 터미널 하네스가 이 안에서 실행되기 때문입니다.
• 최소 하나 이상의 벤더 CLI. 이미 설치되어 있고 로그인된 상태여야 합니다.
• Node.js 22. git 체크아웃에서 직접 빌드하는 경우에만 필요합니다. PyPI의 wheel 패키지에는 빌드된 웹 에셋이 포함되어 있으므로, 일반적인 설치 시에는 Node.js가 전혀 필요하지 않습니다.

main 대신 특정 릴리스 버전 설치하기

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

sh -s -- 부분은 장식이 아닙니다. 이 부분이 없으면 sh은 --version을 자체 옵션으로 인식해 버립니다. 그러면 설치 프로그램은 해당 플래그를 전달받지 못하고, 그날 배포된 최신 버전을 설치하게 됩니다. 몇 주마다 파괴적인 변경 사항(breaking changes)이 포함된 릴리스가 나오는 저장소 환경에서는, 이 차이가 재현 가능한 서버를 만들 것인지 아니면 예기치 못한 오류를 겪을 것인지를 결정합니다.

설치 프로그램은 Astral의 Python 패키지 관리자인 uv를 사용하며, uv가 설치되어 있지 않으면 먼저 설치할 것을 제안합니다. uv가 이미 설치되어 있다면 스크립트 실행을 건너뛰십시오:

uv tool install --force --python 3.12 "omnigent==0.7.0"

추가 기능(extras)도 같은 패턴을 따르며 플래그를 반복해서 사용합니다. 스크립트에는 --extra e2b --extra kubernetes를, uv를 직접 사용할 때는 "omnigent[e2b,kubernetes]"을 사용하십시오. Git 태그는 v0.7.0인 반면 PyPI의 패키지 버전은 0.7.0라는 점에 유의하십시오.

uv는 uv tool dir --bin이 보고하는 디렉터리(보통 ~/.local/bin)에 바이너리를 배치하며, 설치 프로그램은 해당 경로를 셸 프로필에 추가할지 묻습니다. 새로 설치한 직후 명령어를 찾을 수 없다면 이 경로 문제일 가능성이 큽니다. 설치된 버전을 확인하십시오:

omni upgrade --check

이 명령은 설치된 버전과 최신 게시 버전을 비교하여 업그레이드 가능 여부를 알려주며, 실제 업그레이드는 수행하지 않습니다. omni과 omnigent는 동일한 프로그램을 가리키는 두 가지 이름입니다.

모델 제공자 지정

omni setup

마법사는 환경에 이미 존재하는 자격 증명을 탐색하고, 누락된 항목을 입력하라는 메시지를 표시합니다. API 키, 공급업체 구독, OpenRouter나 Ollama 같은 게이트웨이, 그리고 Databricks 워크스페이스를 처리합니다. 동일한 머신에서 이미 Ollama를 사용한 로컬 모델 서버를 실행 중이라면, 게이트웨이를 해당 서버로 지정하십시오. 그러면 트래픽이 외부로 나가지 않습니다.

최소 다중 에이전트 실행

예제 에이전트는 저장소에 포함되어 있습니다. main 대신 설치한 것과 동일한 태그를 클론하십시오.

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly는 저장소와 함께 제공되는 다중 에이전트 코딩 오케스트레이터입니다. 설정 파일에는 claude_code, codex, opencode, cursor, hermes, pi라는 이름의 하위 에이전트가 선언되어 있으며, 이 전체 과정을 실행할 가치가 있게 만드는 규칙이 하나 있습니다. 바로 구현자와 다른 벤더가 항상 검토를 수행한다는 점입니다. Polly는 직접 코드를 작성하지 않습니다. 계획을 세우고, 목표를 작업 단위로 분할하여 위임하며, 각 diff를 다른 벤더의 검토자에게 전달합니다.

무언가를 위임하기 전에 Polly는 기기에 어떤 하위 에이전트 CLI가 실제로 존재하는지 사전 점검을 수행합니다. 벤더 CLI가 하나만 설치되어 있으면 diff를 전달할 대상이 없으므로, 결과를 평가하기 전에 최소 두 개 이상을 설치하십시오. 함께 제공되는 또 다른 예제인 Debby는 두 개의 머리(Claude 하나와 GPT 하나)를 가진 토론 에이전트입니다.

omni debby

두 공급자가 모두 응답해야 작동하므로, 두 공급자가 올바르게 설정되었는지 확인하는 간단한 방법입니다.

서브 에이전트는 도구로 선언됩니다

에이전트 파일은 YAML 형식입니다. executor은 하네스, 모델, 인증 정보를 지정합니다. tools은 MCP(Model Context Protocol) 서버, Python 함수, 서브 에이전트를 포함합니다. 서브 에이전트는 type: agent와 자체 실행기를 갖춘 도구이며, 이것이 위에서 언급한 모든 기능의 기반이 되는 메커니즘입니다.

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

해당 모델 ID는 프로젝트 자체의 docs/AGENT_YAML_SPEC.md 예제에서 가져온 것이며, Databricks에서 호스팅하는 이름입니다. harness과 model는 사용자의 환경에 맞게 omni setup으로 설정된 값으로 교체하십시오. 사양에 포함된 다른 하네스 값으로는 범용 프로토콜을 사용하는 모든 항목에 대해 antigravity, copilot, kimi, qwen, acp:<slug>이 있습니다. 또한 이 사양은 서브 에이전트에서 pass_history: true를 지원하며, 이를 통해 상위 대화 내용을 전달할 수 있습니다. 이는 위임할 때마다 토큰 비용이 발생하므로, 주어진 작업만 수행하면 되는 서브 에이전트에는 이 설정을 비활성화하십시오.

장기 실행 오케스트레이션이 VPS에 적합한 이유

멀티 에이전트 실행은 2분 만에 끝나는 명령이 아닙니다. 계획 수립, 위임, 병렬 git 작업 트리 대기, 검토, 수정 과정이 포함됩니다. 노트북 덮개를 닫으면 이 모든 작업이 중단됩니다. VPS(가상 사설 서버)는 항상 켜져 있고 네트워크를 유지하므로, 사용자가 지켜보지 않는 동안에도 세션이 생존합니다.

omnigent server --background
omnigent server status

서버는 6767 포트에서 웹 사용자 인터페이스를 호스팅합니다. omnigent server status은 실행 여부를 보고하며, omnigent stop은 이를 종료합니다. v0.7.0 이전 릴리스에서는 omni server start를 사용했으나 현재는 제거되었으므로, 이전 문서나 스크린샷은 현재 터미널 동작과 일치하지 않을 수 있습니다.

6767 포트를 공인 IP 주소에 직접 노출하지 마십시오. 두 가지 안전한 방법이 있습니다. 방화벽에서 해당 포트를 닫아두고 ssh -N -L 6767:localhost:6767 you@your-server을 사용하여 SSH로 포트 포워딩한 뒤, 로컬 머신의 http://localhost:6767에서 웹 인터페이스를 엽니다. 또는 앞단에서 TLS(전송 계층 보안)를 종료하고 인증을 활성화하십시오.

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

방화벽 설정은 일반적인 작업이며 VPS를 위한 ufw 방화벽 기초에서 다룹니다. 만약 서버가 이미 여러 Docker Compose 앱 앞단의 Traefik 뒤에서 컨테이너를 실행 중이라면, Omnigent도 동일한 패턴의 서비스로 추가하면 됩니다.

컨테이너 배포의 경우, 저장소의 deploy/ 디렉터리에 Compose 설정이 포함되어 있습니다. ./bootstrap.sh은 비밀 값을 .env로 생성하며, docker compose up -d은 Omnigent와 Postgres를 6767 포트에서 시작합니다. DATABASE_URL는 Postgres 또는 SQLite를 선택하며, OMNIGENT_AUTH_ENABLED은 컨테이너 내부에서 기본적으로 1을 사용합니다. 이는 외부에서 접근 가능한 모든 서비스에 적합한 기본값입니다.

서버 사양의 경우, 배포 노트에서는 서버의 작업 세트를 대략 512 MB에서 1 GB로 권장하며, Fly.io 설정은 1 GB로 고정되어 있습니다. 이 수치는 슈퍼바이저 단독 기준입니다. 모든 하위 에이전트는 자체 체크아웃과 모델 클라이언트를 보유한 별도의 프로세스이므로, 에이전트 수에 맞춰 서버 사양을 결정하십시오. 서버가 준비되면 omnigent login https://your-host에 이어 omnigent host https://your-host을 실행하여 노트북을 서버에 등록하고, omnigent attach <session_id>를 통해 다른 기기에서 실행 중인 세션을 다시 불러올 수 있습니다.

서브 에이전트를 떠나기 전에 샌드박스화하십시오

Omnigent는 Omnibox라는 운영 체제 수준의 샌드박스를 제공합니다. Linux 환경에서는 bubblewrap 네임스페이스와 seccomp를 사용하므로, 에이전트의 프롬프트가 아닌 커널이 직접 경계를 강제합니다. 프롬프트 인젝션 공격을 받은 에이전트라도 커널 규칙을 우회하여 탈출할 수는 없습니다. 먼저 의존성을 설치하십시오:

sudo apt install bubblewrap

설정은 에이전트 파일 내 os_env 아래에 위치합니다:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

작업 디렉터리는 write_paths에 명시하기 전까지 읽기 전용으로 유지되므로, 오작동하는 에이전트가 작업 공간 외부로 파일을 쓸 수 없습니다. cwd_allow_hidden에 이름을 지정하지 않으면 도트파일은 숨겨진 상태로 유지됩니다. 즉, 광범위한 읽기 권한을 부여하더라도 .ssh이나 .aws가 조용히 노출되지 않습니다. egress_rules을 설정하면 모든 HTTP 및 HTTPS 트래픽이 기본 거부 프록시를 통과하며, 각 규칙은 "METHODS host/path-glob" 형식으로 작성됩니다. credential_proxy는 한 단계 더 나아갑니다. 에이전트는 항상 플레이스홀더만 가지고 있으며, 요청이 나갈 때 프록시가 실제 비밀값으로 교체하므로 기록이 유출되더라도 사용할 수 있는 정보는 남지 않습니다. 멀티 하니스 설정에서는 각 서브 에이전트가 agents/ 아래의 자체 설정 파일에 샌드박스 블록을 포함하므로, 구현자에게는 네트워크를 허용하면서 검토자에게는 차단하는 식의 제어가 가능합니다.

문서에 명시된 제한 사항은 중요합니다. OS 샌드박스는 sys_os_* 도구 호출과 터미널에 적용됩니다. MCP 서버나 Omnigent 슈퍼바이저 프로세스 자체에는 적용되지 않습니다. 사용자가 시작한 MCP 서버는 샌드박스 외부에서 사용자의 권한으로 실행됩니다. 이러한 간극 때문에 에이전트당 일회용 머신을 하나씩 사용하는 것이 더 강력한 패턴이며, 이는 일회용 VM에서 코딩 에이전트 실행하기에서 다룹니다. 작업의 나머지 절반은 자격 증명 관리이며, 6개의 서브 에이전트가 하나의 호스트를 공유할 때 에이전트가 접근할 수 없는 곳에 비밀값 보관하기는 더욱 어려워집니다.

지출 한도는 동일한 파일에 선언하는 정책입니다:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

한 벤더로 계획하고 두 번째 벤더로 구현하며 세 번째 벤더로 검토하는 작업은 세 곳에서 동시에 비용을 발생시킵니다. 따라서 첫 번째 청구서를 받은 후가 아니라, 첫 번째 무인 실행을 시작하기 전에 한도를 설정하십시오. 내장 기능에는 파일 및 셸 작업 전 승인을 요청하는 max_tool_calls_per_session와 ask_on_os_tools도 포함되어 있습니다. VPS에서 AI 에이전트 비용 제어하기에 대한 당사의 지침은 여기에 직접 적용되며, 병렬 서브 에이전트가 비용 소모 속도를 가속화하므로 더욱 엄격하게 적용해야 합니다.

이 저장소는 얼마나 빠르게 업데이트됩니까?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

위 날짜는 2026년 8월 3일에 프로젝트 자체 릴리스 페이지에서 확인한 공식 릴리스 날짜입니다. 2026-06-19와 2026-07-27 사이에 7개의 태그된 릴리스가 배포되었으며, 릴리스 간 가장 긴 간격은 11일이었습니다. v0.5.1는 이전 릴리스와 같은 날에 배포되었습니다. 2026년 6월 16일에 발표된 첫 번째 릴리스인 0.1.1은 이전 태그와의 간격을 측정할 수 없으므로 차트에서 제외되었습니다.

이 릴리스 중 두 건은 기존 가이드에 문서화된 명령어를 변경했습니다. v0.7.0에서는 omni server start이 제거되고 omni server --background로 대체되었습니다. v0.6.0에서는 omnigent[memory] 엑스트라가 omnigent[hindsight]으로 이름이 변경되었으므로, 6월에 작성된 문서의 설치 명령어를 그대로 사용하면 7월 빌드에서 실패합니다. 이것이 스타일 선호의 문제가 아니라 설치 명령어에 --version을 사용하고 git clone에 태그를 지정해야 하는 이유입니다.

아직 신뢰하기 어려운 부분

2026년 8월 기준으로 이 저장소는 약 8.1k개의 스타와 1.2k개의 포크, 그리고 약 350개의 열린 이슈를 보유하고 있으며, 첫 공개 릴리스가 나온 지 7주가 지났습니다. 스타는 관심을 나타낼 뿐 성숙도를 의미하지는 않습니다. 프로젝트는 스스로를 알파 버전이라 명시하고 있으며, 위에서 언급한 릴리스 기록은 이를 뒷받침합니다.

• 샌드박스가 MCP 서버나 슈퍼바이저를 보호하지 않으므로, 프로덕션 자격 증명이 저장된 호스트에서는 실행하지 마십시오.
• 세 개의 공급자가 동시에 비용을 청구할 수 있고 이를 막을 다른 수단이 없으므로, cost_budget 정책 없이 무인 상태로 실행하지 마십시오.
• OMNIGENT_AUTH_ENABLED 설정과 앞단에 TLS 구성 없이 서버를 공인 IP 주소에 노출하지 마십시오.
• 에이전트 YAML이 마이너 버전 간에 안정적이라고 보기 어려우므로, 버전을 고정하고 업그레이드 전 릴리스 노트를 확인하십시오.

예기치 못한 상황을 방지하기 위해 알아두어야 할 점이 하나 더 있습니다. v0.6.0부터 익명화된 사용 통계(telemetry) 기능이 추가되었으며, 프로젝트는 이를 전용 통계 페이지에 문서화하고 있습니다. 해당 페이지를 읽어보고, 만약 해당 장비에서 고객 업무를 처리 중이라면 신중하게 결정하십시오.

현재 Omnigent가 확실하게 잘하는 것은 본래 설계 목적에 부합하는 기능입니다. 이미 사용 중인 3~4개의 에이전트 CLI가 있고, 그중 하나가 작성하고 다른 하나가 검토하도록 구성하고 싶다면, 현재 Linux 환경의 실제 샌드박싱을 통해 해당 기능을 사용할 수 있습니다. 그 외의 모든 기능은 아직 유망하지만 미완성 상태라고 간주하십시오.

FAQ

Omnigent은 에이전트입니까, 아니면 에이전트를 실행하는 도구입니까?

에이전트를 실행하는 도구입니다. Omnigent는 메타 하네스(meta-harness)입니다. 이미 설치된 Claude Code, Codex, OpenCode와 같은 벤더 CLI를 시작하고, 각각에 작업을 할당하며, 하나의 세션에서 결과를 감독합니다. 자체 모델을 포함하지 않습니다. 이는 Python 라이브러리를 사용하여 직접 프로그램을 작성하고 그것이 에이전트가 되는 프레임워크와 다른 점입니다.

Omnigent을 사용하려면 Claude Code와 Codex가 미리 설치되어 있어야 합니까?

최소 하나 이상의 벤더 CLI가 설치되어 있고 로그인된 상태여야 합니다. Omnigent는 해당 프로그램을 대체하는 것이 아니라 구동하는 역할을 하기 때문입니다. 제공되는 Polly 예제를 사용하려면 서로 다른 벤더의 CLI가 2개 이상 필요합니다. Polly의 규칙상 구현자와 리뷰어는 항상 서로 다른 벤더여야 하므로, CLI가 하나만 있으면 diff를 보낼 두 번째 벤더가 존재하지 않게 됩니다.

최신 버전이 아닌 특정 Omnigent 버전을 설치하려면 어떻게 해야 합니까?

설치 스크립트에 --version를 사용하여 sh -s --을 전달하십시오. 예시는 sh -s -- --version 0.7.0과 같습니다. -s --이 없으면 해당 플래그는 sh 자체에서 소비되며 스크립트는 최신 릴리스를 설치합니다. uv가 이미 설치되어 있다면 uv tool install --force --python 3.12 "omnigent==0.7.0"으로도 동일한 작업을 수행할 수 있습니다. Git 태그는 v0.7.0이며 PyPI 버전 문자열은 0.7.0입니다.

Omnibox 샌드박스는 에이전트를 무인으로 실행하기에 충분합니까?

적용 범위 내에서는 강력하며, 그렇지 않은 부분에 대해서도 명확히 정의하고 있습니다. Linux 환경에서는 bubblewrap과 seccomp를 사용하여 커널 수준에서 파일 및 네트워크 제한을 강제하므로 에이전트가 이를 우회할 수 없습니다. 문서에 따르면 이는 sys_os_* 도구 호출 및 터미널에 적용되며, MCP 서버나 Omnigent 감독 프로세스는 포함하지 않습니다. 따라서 MCP 서버는 사용자의 일반 권한으로 실행되므로, 무인 작업을 위해서는 에이전트당 일회용 가상 머신을 사용하는 것이 더 강력한 격리 방법입니다.

VPS에서 Omnigent 서버를 운영하려면 메모리가 얼마나 필요합니까?

프로젝트 배포 노트에 따르면 서버의 작업 세트(working set)는 대략 512 MB에서 1 GB이며, Fly.io 설정은 1 GB로 고정되어 있습니다. 이는 포트 6767에서 실행되는 감독 프로세스와 웹 인터페이스만을 위한 용량입니다. 각 하위 에이전트는 자체 작업 복사본과 모델 클라이언트를 가진 별도의 프로세스이며, Polly 방식의 실행은 병렬 git worktree를 사용하므로 RAM과 디스크 용량은 서버 기준이 아니라 동시에 실행할 에이전트 수에 맞춰 산정해야 합니다.