OpenRig: Claude Code와 Codex 세션들을 저장하고 불러올 수 있도록 하는 멀티 에이전트 하네스

9bow · 9월 29, 2026, 11:00오후

OpenRig 소개

코딩 에이전트를 여러 개 함께 쓰다 보면 에이전트보다 세션 관리가 먼저 문제가 됩니다. 터미널 탭을 하나씩 늘려 가며 오케스트레이터, 리뷰어, 리서치 에이전트를 띄우고 tmux로 서로 연결해 두면, 며칠 뒤에는 어느 세션이 어떤 역할이었는지, 작업 디렉토리가 어디였는지를 기억하기 어려워집니다. OpenRig 개발자 Mike Schwarz는 이 상태에서 컴퓨터를 재부팅하면 에이전트 구성을 되살리는 데 30분 정도가 걸렸고, 존재를 잊어버린 에이전트는 그대로 잃었다고 설명합니다. 그래서 재부팅을 미루게 되는 상황이 OpenRig를 만든 출발점입니다. 이번에 소개하는 OpenRig는 Claude Code와 Codex 세션을 YAML로 정의한 하나의 팀으로 띄우고, 저장했다가 같은 이름으로 다시 불러올 수 있게 해 주는 멀티 에이전트 하네스(Multi-agent Harness) 입니다.

OpenRig는 개별 에이전트가 아니라 에이전트들이 함께 만드는 시스템을 관리 대상으로 삼습니다. 프로젝트는 이 관계를 "A harness wraps a model. A rig wraps your harnesses." 라는 문장으로 설명합니다: 모델을 감싸는 것이 Claude Code나 Codex 같은 하네스라면, 그 하네스들을 다시 감싸는 층이 리그(Rig)라는 것입니다. 사용자는 리드 에이전트 한 명과 대화하고, 리드 에이전트가 다른 전문 에이전트에게 일을 나눠 준 뒤 결과와 결정이 필요한 사항을 가져옵니다. 각 에이전트는 dev-owner@first-project 같은 고정된 주소의 시트(Seat) 에 앉아 있어서, 그 자리를 차지한 대화 세션이 바뀌어도 역할과 누적된 맥락은 같은 주소에 남습니다.

OpenRig는 TypeScript로 작성된 로컬 데몬, CLI, 터미널 UI(TUI), MCP 서버로 구성되어 있고, 에이전트 세션은 모두 tmux 위에서 실행됩니다. 지원하는 런타임은 Claude Code와 Codex, 터미널 프로세스, 그리고 Pi 코딩 에이전트용 어댑터입니다. 실행 환경은 macOS와 Linux이며 Node.js 20, 22, 24와 tmux가 필요합니다. 별도의 호스팅 서비스 없이 사용자의 머신에서 동작하고, 모델 사용 비용은 각자 로그인한 Claude와 Codex 계정에서 그대로 발생합니다. 개발자는 Cursor 시절부터 에이전트 세션이 서로 작업을 이어받게 하는 자체 하네스를 만들어 썼고, 그 경험을 토폴로지(Topology) 관리 도구로 옮긴 것이 OpenRig라고 밝히고 있습니다.

OpenRig vs. Claude Code 서브에이전트와 Agent Teams

여러 Claude 세션을 함께 쓰는 방법은 Claude Code 안에도 이미 있습니다. 개발자가 직접 작성한 OpenRig 비교 페이지와 Claude Code 공식 문서를 기준으로 가장 가까운 두 기능과의 차이를 정리하면 다음과 같습니다:

항목	OpenRig	Claude Code 서브에이전트	Claude Code Agent Teams
기본 단위	YAML로 정의한 리그(실행 중인 에이전트 토폴로지)	리드 Claude가 작업을 위임하는 전문 작업자	리드 Claude Code 세션과 팀원 인스턴스
실행 위치	로컬 데몬, SQLite, 사용자의 tmux 세션	Claude Code 내부	Claude Code 내부
런타임 범위	Claude Code, Codex, 터미널 프로세스, Pi	Claude 전용	Claude 전용
에이전트 간 소통	tmux 기반 `rig send`, `rig broadcast`, `rig chatroom`과 작업 큐	호출한 쪽에 결과 반환 (이름을 붙인 서브에이전트끼리는 `SendMessage`로 메시지 가능)	`SendMessage`와 공유 작업 목록
재부팅 후 유지	`rig down`으로 스냅샷, `rig up <name>`으로 복원	리드의 워크플로우 범위 안에서 유지	팀은 세션 하나에 묶이고, 세션을 재개해도 in-process 팀원은 복원되지 않음 (작업 목록은 유지)

표에서 OpenRig와 가장 가까운 것은 Agent Teams입니다. Agent Teams는 기본으로 꺼져 있는 실험 기능으로, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 설정해야 쓸 수 있습니다. 둘 다 독립된 컨텍스트를 가진 여러 세션이 서로 메시지를 주고받지만, Agent Teams는 Claude Code 안에서 Claude끼리 협업하는 기능이고 OpenRig는 Claude Code 바깥에서 Claude Code와 Codex를 함께 관리합니다. 개발자는 두 방식이 겹치지 않는 층에 있다고 보고, OpenRig의 한 시트로 띄운 Claude Code 세션이 내부적으로 서브에이전트나 Agent Teams를 그대로 쓸 수 있다고 설명합니다. 클라우드에서 에이전트를 API로 호출하는 Claude Managed Agents와는 운영 주체가 다릅니다. Managed Agents는 애플리케이션 코드가 API로 에이전트를 부르는 호스팅 런타임이고, OpenRig는 터미널 앞의 개발자가 직접 운영하는 로컬 제어 평면(Control Plane)입니다.

작업 티켓을 기반으로 에이전트를 조율하는 도구들과도 접근이 다릅니다. 개발자는 Paperclip이나 Emdash 같은 도구를 오케스트레이터가 티켓 시스템으로 일회성 작업자에게 일을 나누는 하나의 토폴로지로 분류하고, OpenRig는 특정 패턴을 고정하지 않고 그런 구성 자체를 RigSpec 파일로 정의할 수 있게 하는 것을 목표로 한다고 밝힙니다.

OpenRig를 사용하면 좋을 사용자

이미 tmux에서 Claude Code와 Codex 세션 여러 개를 역할별로 나눠 쓰고 있고, 그 구성을 매번 손으로 다시 만드는 데 지친 개발자라면 OpenRig가 해결하려는 문제를 그대로 겪고 있는 셈입니다. rig discover와 rig adopt로 이미 실행 중인 세션을 가져올 수 있고, Claude와 Codex를 한 팀에 섞는 구성을 기본으로 지원하므로 리뷰어를 다른 모델로 두고 싶은 경우에도 맞습니다. 개발자는 Claude를 설계와 계획에, Codex를 디버깅과 코드 리뷰에 더 맞는 쪽으로 보고, 두 하네스를 함께 운영하는 부담을 감수할 만하다고 설명합니다. 반면 Windows 네이티브 환경은 아직 지원하지 않고 WSL2는 테스트되지 않았습니다. 또한 OpenRig는 실행 과정에서 Claude Code와 Codex의 설정 파일에 훅(Hook)과 신뢰 설정을 기록하므로, 에이전트 설정 파일을 엄격하게 관리해야 하는 환경이라면 아래 변경 사항을 먼저 검토한 뒤 도입하는 것이 안전합니다. 제품 안에서 API로 에이전트를 호출하려는 경우에는 OpenRig보다 Managed Agents 같은 호스팅 서비스가 맞는 선택지입니다.

OpenRig의 핵심 개념: 리그, 파드, 시트

OpenRig에서 팀 구성은 RigSpec이라는 YAML 파일로 선언합니다. RigSpec은 여러 개의 파드(Pod)로 나뉘고, 파드는 관련된 시트를 묶어 공통 지침과 맥락을 공유합니다(컨텍스트 창은 에이전트마다 따로 둡니다). 개발자는 코드 리뷰처럼 좁은 역할을 오래 맡은 에이전트일수록 그 일을 더 잘하게 된다는 경험에서 이렇게 역할별로 나누는 구성을 택했다고 설명합니다. 각 시트가 쓸 에이전트는 AgentSpec으로 정의하며, 여기에 스킬, 지침, 훅, 시작 시 전달할 파일이 들어갑니다. 팀 전체의 협업 규범은 CULTURE.md 파일에 적어 두는데, 개발자는 리서치용 리그에는 탐색적인 문화를, 구현용 리그에는 보수적으로 검증하는 문화를 두는 식으로 쓴다고 설명합니다.

아래는 OpenRig가 첫 사용용으로 제공하는 first-project 리그의 RigSpec입니다. Codex 시트 두 개가 구현 담당(owner)과 검증 담당(check)으로 나뉘어 있습니다:

version: "0.2"
name: first-project
summary: >
  Two Codex seats in your repository: an outcome owner and an independent
  checker. Give the owner one bounded change; follow the durable result and
  continue at the same address. See docs/reference/getting-started.md.

culture_file: CULTURE.md

pods:
  - id: dev
    label: Project
    members:
      - id: owner
        agent_ref: "local:../../../agents/development/implementer"
        runtime: codex
        model: gpt-6-astra
        profile: default
        cwd: "."
      - id: check
        agent_ref: "local:../../../agents/development/qa"
        runtime: codex
        model: gpt-6-astra
        profile: default
        cwd: "."
    edges:
      - kind: delegates_to
        from: owner
        to: check

edges: []

시트 사이의 관계는 엣지(Edge)로 표현합니다. 엣지 명세에 따르면 delegates_to, spawned_by, can_observe, collaborates_with, escalates_to 다섯 종류가 있는데, 실제 동작에 영향을 주는 것은 부팅과 복원 시 실행 순서를 정하는 delegates_to와 spawned_by 두 가지뿐입니다. 나머지는 토폴로지 그래프와 rig whoami --json 출력에 표시되는 정보용입니다. 특히 엣지는 메시지 경로를 제한하거나 권한을 강제하지 않는다고 명시되어 있으므로, 엣지를 접근 제어 수단으로 기대해서는 안 됩니다.

이 밖에 리그를 다른 머신으로 옮기기 위한 RigBundle 형식도 있습니다. RigBundle은 사용한 AgentSpec을 함께 묶고 SHA-256 무결성 정보를 담은 아카이브로, 팀원이 같은 토폴로지를 자신의 머신에서 그대로 띄울 수 있게 합니다.

OpenRig의 에이전트 간 소통과 작업 큐

OpenRig에서 에이전트끼리의 대화는 별도의 통신 채널 없이 터미널로 이뤄집니다. 개발자는 Claude와 Codex를 함께 쓰는 이유를 다룬 글에서, tmux로 각 터미널에 이름을 붙이고 send-keys로 다른 터미널에 텍스트를 입력하면 에이전트 사이의 메시지 전달이 된다는 점에서 출발했다고 설명합니다. OpenRig는 이를 감싸서 rig send로 다른 시트의 프롬프트에 메시지를 보내고, rig capture로 현재 화면을 읽고, rig transcript로 그 시트의 기록을 읽을 수 있게 합니다.

OpenRig는 메시징 문서에서 이 명령들이 보장하는 범위를 구체적으로 밝히고 있습니다. rig send --verify는 텍스트가 대상 패널에 나타났는지만 확인할 뿐 에이전트가 읽었다는 뜻은 아니며, 대상 시트가 권한 확인 프롬프트에 멈춰 있으면 전송을 거부해서 다른 에이전트의 승인 프롬프트에 대신 답하는 일을 막습니다:

rig send dev-impl@my-rig "the file you want is src/auth.ts" --verify
rig capture dev-impl@my-rig --lines 50
rig transcript dev-impl@my-rig --grep "decision|architecture"

메시지만으로는 에이전트가 늘어날수록 요청이 대화 기록에 묻힙니다. 그래서 OpenRig는 해야 할 일을 작업 큐(Queue)에 따로 기록합니다. 코디네이션 문서에 따르면 큐 항목은 담당 시트, 본문, 상태, 추가만 가능한 변경 이력(Append-only History)을 가진 데이터베이스 행입니다. 담당 시트가 컨텍스트를 압축하거나 다른 세션으로 교체되어도 항목은 남고, rig queue handoff는 기존 항목을 닫고 다음 담당자의 항목을 여는 과정을 하나의 트랜잭션으로 처리해 작업이 중간에 사라지지 않게 합니다:

rig queue create --destination dev-impl@my-rig --body-file brief.md --mission search-experience --slice 01-search-page
rig queue claim qitem-20260901100000-abcd1234
rig queue handoff qitem-20260901100000-abcd1234 --to build-checker@my-rig --note "candidate ready; keyboard path per requirement 2"

항목을 완료로 닫을 때는 handed_off_to, blocked_on, denied, canceled, no-follow-on, escalation 중 하나의 종료 사유를 반드시 적어야 합니다. OpenRig는 닫힌 항목을 결과물 승인으로 취급하지 않고, 승인 여부는 다음 단계 담당자가 자신의 항목에 기록하는 것으로 구분합니다.

OpenRig의 스냅샷과 복원

OpenRig가 처음 해결하려던 재부팅 문제는 스냅샷과 복원 명령이 맡습니다. rig down --snapshot으로 리그를 내리면서 토폴로지를 저장하고, rig up <name>으로 같은 이름의 리그를 가장 최근 스냅샷에서 다시 띄웁니다. 연속성(Continuity) 문서에 따르면 복원 결과는 시트마다 따로 보고되며, 기존 세션을 재개(resumed)했는지, 산출물로 재구성(rebuilt)했는지, 새로 시작(fresh)했는지, 사람의 결정을 기다리는지, 실패(failed)했는지 등을 구분합니다. OpenRig는 새로 시작한 시트를 복구에 성공한 것처럼 표시하지 않는다는 점을 설계 원칙으로 밝히고 있습니다. 기본 명령은 다음과 같습니다:

rig down my-rig --snapshot
rig restore-check --rig my-rig
rig up my-rig
rig up my-rig --fresh dev.qa

rig restore-check는 복원 전에 무엇이 돌아올 수 있는지를 확인하는 명령으로, 복원 가능하면 0, 불가능하면 1, 판단할 수 없으면 2를 반환합니다. 컨텍스트가 가득 찬 시트는 rig handover로 주소, 엣지, 받은 작업을 그대로 둔 채 새 세션으로 교체할 수 있습니다. 이 명령은 --dry-run을 붙였을 때만 계획을 보여 주고 붙이지 않으면 바로 실행되므로, 처음에는 --dry-run으로 확인하는 편이 좋습니다.

OpenRig의 아키텍처와 터미널 UI

OpenRig는 로컬에서 실행되는 데몬을 중심으로 CLI, TUI, MCP 서버가 같은 상태를 공유하는 구조로 설계되어 있습니다. OpenRig가 제시하는 구성은 다음과 같습니다:

CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters

데몬은 Hono 기반 HTTP 서버이며, 상태는 SQLite에 저장하고 세션은 tmux로 관리합니다. CLI는 사람과 에이전트가 함께 쓰도록 만들어져 있어서, 에이전트도 팀을 실행하고 상태를 조회하고 메시지를 보낼 수 있습니다. MCP 서버는 rig_up, rig_ps, rig_send, rig_chatroom_send 같은 도구를 제공해 에이전트가 자신이 속한 토폴로지를 직접 조작할 수 있게 합니다. 예전에 제공하던 React 웹 UI는 현재 유지보수 모드로 전환되었고, 주 화면은 TUI입니다.

TUI는 리그와 파드, 시트를 표와 그래프로 보여 주고 각 시트의 런타임, 모델, 컨텍스트 사용량, 상태를 확인할 수 있게 합니다. 아래 화면은 OpenRig 저장소가 인터랙티브 데모에서 가상의 프로젝트 데이터로 캡처한 토폴로지 그래프로, product, dev, qa 세 파드에 속한 시트들이 연결되어 있습니다:

실제 에이전트 터미널은 herdr나 cmux ( cmux: AI 코딩 에이전트를 위해 설계된, Ghostty 기반의 네이티브 macOS 터미널 앱) 같은 터미널 도구에 타일로 띄워 함께 볼 수 있습니다. rig terminal open first-project --provider herdr처럼 제공자를 지정하며, 세션 자체는 여전히 tmux로 접근할 수 있습니다. 아래는 저장소가 공개한 10초 분량의 실제 녹화 화면으로, 리그를 그래프로 본 뒤 시트 표와 개별 시트의 상세 화면으로 이동하는 과정을 보여 줍니다:

OpenRig TUI에서 리그 그래프, 시트 표, 시트 상세 화면을 차례로 보여 주는 실제 녹화

OpenRig 설치와 사용

OpenRig는 npm 패키지 @openrig/cli로 배포됩니다. Apple Silicon Mac에서는 알려진 호환성 문제 때문에 Node.js 22를 쓰라고 안내하고 있습니다. 설치 후에는 rig setup --dry-run으로 설정 계획부터 확인합니다:

npm install -g @openrig/cli
rig setup --dry-run

rig setup은 tmux, cmux, Claude Code, Codex 등 필요한 도구의 설치를 시도한 뒤 무엇이 실제로 성공했는지 보고하고, 이후 문제가 생기면 rig doctor로 시스템 상태를 진단합니다. 두 명령 모두 --json 출력을 지원하므로 에이전트가 결과를 읽고 남은 설정을 마무리할 수도 있습니다.

첫 사용 경로인 first-project는 tmux와 로그인된 Codex만 있으면 동작합니다. 사전 요구 사항을 확인한 뒤, 작업할 저장소에서 실행 계획을 먼저 살펴보고 리그를 띄웁니다:

tmux -V
codex --version
codex login status

cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared

시트가 준비되면 rig ps --nodes --rig first-project로 상태를 확인하고, 구현 담당 시트에 범위가 정해진 작업 하나를 맡깁니다. 메시지를 보내는 것만으로 큐 항목이 생기지는 않으며, 담당 시트가 직접 작업을 큐에 기록합니다:

rig send dev-owner@first-project 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-owner@first-project --limit 1000

더 큰 구성으로는 오케스트레이터 둘과 구현, QA, 디자인, 독립 리뷰어 둘로 이뤄진 product-team, 접수, 계획, 구현, 리뷰 네 시트에 Claude Code와 Codex를 섞은 conveyor가 있습니다. 그 밖에 implementation-pair, adversarial-review, research-team, 그리고 전문 에이전트가 HashiCorp Vault 인스턴스를 운영하는 secrets-manager도 함께 제공되며, 전체 목록은 rig specs ls로 볼 수 있습니다. 서비스를 포함하는 secrets-manager 같은 리그에는 Docker가 필요합니다.

OpenRig가 로컬 환경에서 변경하는 설정

OpenRig는 설치와 실행 과정에서 사용자의 머신에 여러 설정을 기록하며, OpenRig 개발자는 실행 전에 관련 파일을 백업하라고 권고합니다. 주요 변경 사항은 다음과 같습니다:

rig setup: ~/.tmux.conf에 마우스 지원과 스크롤백 설정 블록을 추가하고, macOS에서는 cmux를 설치하고 자동화 소켓 제어를 켤 수 있습니다.
데몬 시작: ~/.openrig 아래에 인스턴스 상태와 데이터베이스를 만들고, ~/.claude/skills와 ~/.agents/skills에 openrig-skills 스킬을 설치합니다. 기본 설정에서는 리그를 띄우기 전에도 Codex 훅 설정과 신뢰 기록을 작성합니다.
Claude Code: ~/.claude.json에 워크스페이스 신뢰 설정을 기록하고, 워크스페이스의 .claude/settings.local.json에 상태 표시줄 명령과 활동 훅을 추가합니다. 공유 설정 리소스를 선택하면 permissions.defaultMode가 acceptEdits로 바뀌고 Exa와 Context7 MCP 항목이 켜집니다.
Codex: ~/.codex/config.toml에 훅과 활동 전달 명령, 해당 명령의 신뢰 해시를 기록하고, 시트를 시작할 때 워크스페이스를 신뢰 대상으로 추가합니다.

관리형 실행에서 Claude Code는 --permission-mode acceptEdits로, Codex는 -s workspace-write로 실행됩니다. 모든 권한 확인을 건너뛰는 YOLO 모드는 기본으로 꺼져 있고, OPENRIG_YOLO=1을 명시하거나 시트 정책으로 지정해야만 켜집니다. 활동 훅이 데몬으로 보내는 정보에는 이벤트 종류, 시트 식별자, 타임스탬프가 포함되지만 프롬프트 본문과 도구 인자는 포함되지 않습니다. 기존 훅은 유지되지만 신뢰 항목과 Claude Code의 기존 상태 표시줄 명령은 덮어쓸 수 있으며, OpenRig 프로젝트는 이것이 완전한 보존이나 롤백을 보장하지 않는다고 밝히고 있습니다.

OpenRig의 라이선스

OpenRig 프로젝트는 Apache-2.0 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

OpenRig 공식 홈페이지

OpenRig 문서

OpenRig 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~