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

Omnigent란 무엇인가

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

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

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

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

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

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

오케스트레이션 계층 하나로 어떤 문제를 해결할 수 있습니까?

• 벤더를 바꾸는 데 한 줄만 수정하면 됩니다. 에이전트 정의에 harness 및 model이 데이터로 포함되므로, 한 벤더에서 다른 벤더로 역할을 옮길 때 코드를 다시 작성하지 않고 YAML 파일만 수정하면 됩니다.
• 벤더를 가로질러 검토할 수 있습니다. 한 모델이 작성한 diff를 다른 회사의 모델이 읽습니다. 같은 제품군의 모델 2개는 같은 사각지대를 공유하는 경향이 있으므로, 같은 벤더에서 두 번째 의견을 받는 것보다 다른 벤더에서 의견을 받는 편이 더 가치 있습니다.
• 정책을 한 곳에서 관리할 수 있습니다. 예산 임계값과 승인 프롬프트를 에이전트 파일에 선언하면 그 아래의 모든 하위 에이전트에 적용됩니다.
• 세션이 특정 도구 하나에 종속되지 않습니다. 하나의 transcript에 여러 CLI에서 수행한 작업이 기록되므로, 4개의 스크롤백을 이어 붙이지 않고도 어떤 일이 있었는지 다시 확인할 수 있습니다.

대가는 계층 자체입니다. 이제 Omnigent의 모든 버그는 원래 독립적으로 작동하던 에이전트와 사용자 사이에 놓인 버그가 됩니다. alpha 단계에서는 이것이 이론적인 비용이 아니라 실제 비용입니다.

멀티 에이전트 하네스가 단일 에이전트 도구와 함께 사용되는 방식

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

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

설치 전 준비 사항

• Python 3.12 이상. 배포된 패키지는 requires-python >= 3.12를 명시합니다.
• tmux. 터미널 하네스가 이 안에서 실행되기 때문입니다.
• 이미 설치되어 있고 로그인까지 완료된 벤더 CLI 최소 1개.
• Node.js 22 이상 및 npm. Claude, Codex, Pi 하네스에서 필요로 합니다. 설치 프로그램은 Node 22.10 이상이 설치되어 있는지 확인하며, 해당 버전이 없으면 경고를 표시합니다. Omnigent 자체는 Node를 필요로 하지 않습니다. PyPI의 휠(wheel)에는 빌드된 웹 에셋이 포함되어 있으며, git 체크아웃을 통해 직접 빌드하는 경우에만 Node가 필수 요구 사항이 됩니다.

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을 자신의 옵션으로 인식하여 설치 프로그램이 전혀 실행되지 않습니다. sh가 Bash인 경우, Bash 자신의 버전을 출력하고 성공적으로 종료되므로 아무것도 설치되지 않으며 경고 메시지도 나타나지 않습니다. -s --을 사용하면 sh은 파이프를 통해 스크립트를 읽고 --version 0.7.0를 설치 프로그램으로 전달합니다. 몇 주마다 주요 변경 사항이 포함된 릴리스가 나오는 저장소에서는, 이 차이가 재현 가능한 환경과 예기치 못한 오류를 가르는 기준이 됩니다.

2026년 10월 29일 기준으로 릴리스 0.7.0이 PyPI에 게시되어 있지만, 2026년 11월 5일 기준 최신 릴리스는 0.21.0입니다. 이전 릴리스인 0.19.1은 새로운 기능 없이 보안에 집중한 패치 버전입니다. 이 버전은 eMudhra 중간 인증 기관 침해 사고 이후 의존성을 업데이트한 버전이므로 프로젝트 측에서는 업그레이드를 권장합니다. 중요한 것은 버전 번호가 아니라 고정(pin) 그 자체입니다. 테스트를 마친 버전을 고정하고, 버전을 올리기 전에 릴리스 노트의 주요 변경 사항을 확인하십시오. 버전을 고정했다고 해서 보안 릴리스를 건너뛰어서는 안 되며, 보안 릴리스가 나오면 버전을 업데이트해야 합니다.

설치 프로그램은 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]"를 사용합니다. 스크립트는 --no-databricks을 전달하지 않는 한 databricks 추가 기능을 자동으로 포함하지만, 위의 uv 명령줄은 해당 기능을 제외하고 패키지를 설치합니다. 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이 있습니다. main의 현재 사양에는 모든 Agent Client Protocol 서버를 위한 acp:<slug>도 문서화되어 있으나, v0.7.0 사양에는 명시되어 있지 않으므로 이를 사용하기 전에 고정된 버전에서 작동하는지 확인하십시오. 또한 사양은 서브 에이전트에서 pass_history: true를 지원하며, 이를 통해 상위 대화 내용을 전달할 수 있습니다. 위임할 때마다 토큰이 소모되므로, 당면한 작업만 수행하면 되는 서브 에이전트에는 이 설정을 비활성화하십시오. prompt을 통해 작동하는 가장 작은 변경을 수행하도록 지시받은 코더는 검토자에게 실제로 읽을 수 있을 만큼 짧은 diff를 전달하며, 이는 어떤 모델을 선택하느냐보다 훨씬 중요합니다.

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

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

omnigent server --background
omnigent server status

서버는 6767 포트에서 웹 사용자 인터페이스를 호스팅합니다. omnigent server status는 실행 중인 인스턴스가 있는지 보고하며, omnigent stop는 이를 종료합니다. v0.7.0에서는 omni server start이 삭제되고 omni server --background로 대체되었으나, v0.9.0에서 다시 폐기 예정(deprecated) 별칭으로 복구되었습니다.

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

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

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

컨테이너 배포의 경우, 저장소의 deploy/docker/ 디렉터리에 Compose 설정이 포함되어 있습니다. ./bootstrap.sh는 비밀 값을 .env으로 생성하며, docker compose up -d는 6767 대신 8000 포트에서 서버를 실행하여 Omnigent와 Postgres를 시작합니다. OMNIGENT_PORT는 해당 호스트 포트를 변경합니다. Compose는 DATABASE_URL을 자동으로 계산하며(다른 배포 대상에서는 동일한 변수가 Postgres 또는 SQLite를 선택함), OMNIGENT_AUTH_ENABLED은 컨테이너 내부에서 기본값으로 1을 사용합니다. 이는 외부에서 접근 가능한 모든 서비스에 적합한 기본값입니다.

서버 사양과 관련하여, 배포 노트에 따르면 서버의 유휴 메모리 사용량은 약 275 MB RSS이며, Fly.io 설정은 1 GB 머신을 기준으로 합니다. 유휴 측정값은 슈퍼바이저 단독 기준이며, 1 GB는 할당된 머신 메모리입니다. 하위 에이전트는 os_env: inherit를 통해 샌드박스를 포함한 부모의 작업 디렉터리와 환경을 공유할 수 있습니다. 별도의 git worktree는 오케스트레이션 선택 사항이므로, 동시에 실행할 하네스와 에이전트 규모에 맞춰 서버 사양을 결정하십시오. 서버가 준비되면 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에 명시하기 전까지 읽기 전용으로 유지되므로, 문제가 발생한 에이전트가 작업 공간 외부로 데이터를 쓸 수 없습니다. 작업 디렉터리 최상위의 도트 파일과 각 read_paths 루트는 cwd_allow_hidden에 명시되지 않는 한 숨겨진 상태로 유지됩니다. 즉, 광범위한 읽기 권한을 부여하더라도 최상위 .ssh 또는 .aws 디렉터리가 자동으로 노출되지 않습니다. 중첩된 도트 파일은 기본적으로 계속 보이지만, cwd_hidden_scan_recursive: true를 설정하면 트리 전체에서 이를 숨길 수 있습니다. 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]

cost_budget 정책은 소프트 임계값에 도달하면 승인을 요청하며, 기본적으로 max_cost_usd에 도달하면 모든 모델의 사용을 차단합니다. expensive_models 목록을 비워두지 않고 설정하면 제한 사항이 다운그레이드 게이트로 전환되어, 해당 목록에 없는 모델은 계속 지출할 수 있습니다. 한 공급업체로 계획하고, 두 번째 업체로 구현하며, 세 번째 업체로 검토하는 작업은 세 곳에서 동시에 지출이 발생하므로, 첫 번째 청구서가 나오기 전에 미리 임계값을 설정하십시오. 내장 기능에는 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은 이전 릴리스와 같은 날에 나왔다. PyPI의 첫 2개 릴리스인 2026년 6월 13일의 0.1.0과 2026년 6월 16일의 0.1.1은 GitHub 릴리스 페이지에 항목이 없으므로 차트에서 제외했다. v0.2.0에 표시된 3일은 0.1.1부터 계산했다.

이 릴리스 중 2개는 가이드에서 이미 문서화한 명령을 변경했다. v0.7.0은 omni server start을 제거하고 omni server --background을 사용하게 했다. v0.6.0은 omnigent[memory] extra의 이름을 omnigent[hindsight]로 바꾸었지만, 0.10.0까지 계속 작동한 호환성 별칭으로 memory을 유지했다. 2026년 8월 25일에 릴리스된 0.11.0부터는 이 별칭이 없어졌다. 따라서 6월에 작성된 문서에서 설치 명령을 복사하면 더 이상 Hindsight 클라이언트가 설치되지 않는다. 그러므로 설치 명령에 --version을 지정하고 git clone에 태그를 사용해야 한다. 이는 스타일 선택이 아니다.

이 글을 확인한 뒤에도 업데이트 속도는 느려지지 않았다. 2026년 10월 29일 기준으로 PyPI에는 10월 28일에 릴리스된 0.20.0이 등록되어 있다. 이는 0.7.0 이후 13개의 마이너 릴리스가 나온 것이다. 또한 프로젝트의 릴리스 노트에는 여러 릴리스에서 호환성이 깨지는 변경 사항이 있었다고 명시되어 있다. 이 페이지의 내용을 복사하는 경우 중요한 변경 사항은 2개다. v0.12.0부터 bare omni은 Polly agent 대신 백그라운드 호스트를 시작한다. 기본 agent는 이제 omni run으로 실행한다. 또한 v0.13.0부터 관리형 터미널에는 tmux 3.3 이상이 필요하다.

아직 신뢰하기 어려운 부분

2026년 10월 27일 기준으로 해당 저장소는 약 11k개의 스타, 1.8k개의 포크, 약 910개의 열린 이슈를 보유하고 있으며, 첫 공개 릴리스가 나온 지 4개월이 조금 넘었습니다. 스타는 관심을 나타낼 뿐 성숙도를 의미하지는 않습니다. 프로젝트는 스스로를 알파 버전이라 명시하고 있으며, 위 릴리스 기록은 그 의미가 알파임을 보여줍니다.

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

예기치 못한 상황을 방지하기 위해 알아두어야 할 점이 하나 더 있습니다. v0.6.0에서 익명화된 사용 원격 측정(telemetry) 기능이 추가되었으며, README에 따르면 기본적으로 수집됩니다. 프로젝트는 전용 원격 측정 페이지를 통해 수집 거부 방법을 포함한 관련 내용을 문서화하고 있습니다. 해당 머신이 클라이언트 업무를 처리한다면, 해당 페이지를 읽고 신중하게 결정하십시오.

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

FAQ

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

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

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

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

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

sh -s -- --version 0.7.0와 같이 sh -s --을 사용하여 설치 스크립트에 --version를 전달하십시오. -s --가 없으면 sh은 --version를 자신의 옵션으로 받아들이고 설치 프로그램은 실행되지 않습니다. 예를 들어 Bash는 자신의 버전을 출력하고 종료합니다. 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 서버는 어느 정도의 메모리가 필요합니까?

프로젝트 배포 노트에 따르면 유휴 상태에서 약 275 MB RSS를 사용하며, Fly.io 설정에서는 1 GB 머신을 할당합니다. 이 유휴 상태 측정값은 서버 자체에 대한 것이며 하위 에이전트는 포함하지 않습니다. 하위 에이전트는 os_env: inherit를 통해 샌드박스를 포함한 부모의 작업 디렉터리와 환경을 공유할 수 있으며, 별도의 작업 복사본이 보장되지는 않습니다. Polly 방식의 실행은 병렬 git worktree를 사용하므로, 서버 기준이 아닌 동시에 실행할 에이전트 수에 맞춰 RAM과 디스크 용량을 산정하십시오.