Octopus Superintelligence OS 딥다이브
— 에이전트를 ‘루프’가 아니라 ‘운영체제’로 설계하면

1프로젝트 한줄 요약

Octopus는 “산출물(artifact)이 선언된 인터페이스를 건널 때마다 정책을 새로 계산하고 장부에 기록하는” 작은 Rust 커널 위에, 모델 제공자·도구·에이전트(worker)·작업 공간을 JSON 폴더로 붙이는 에이전트 운영체제입니다. 데스크톱 클라이언트(Electron)와 터미널 클라이언트(./octopus)가 같은 Home(~/.octopus)을 공유합니다. 저장소 라이선스는 MIT, 상태는 README가 직접 “research preview”라고 밝힙니다.

README의 표현으로 “self-evolving”은 에이전트가 목표·트리거·도구·작업자·컨텍스트 같은 미래 작업의 조건을 정책 안에서 바꿀 수 있다는 뜻입니다. 반면 “self-improvement”(실제로 더 좋아지는가)는 아직 연구 목표로 분리해 적어 두었습니다.

1-1. README가 약속하는 일곱 가지 표면

2왜 주목받는가

GitHub API 확인 기준(2026-10-25) 저장소는 2026-10-09에 생성됐고 최근 push는 10-24입니다. 스타 118개·포크 10개로 규모는 아직 작지만, 생성 2주 만에 TrendShift 목록 18위에 올랐습니다. 순위 이유를 저장소가 설명해 주지는 않으므로 아래는 소스와 문서에서 확인되는 특징입니다.

2-1. 에이전트 ‘루프’를 아키텍처로 끌어내린다

docs/architecture.md는 에이전트 루프가 런타임 안의 메커니즘이 아니라 산출물의 흐름에서 따라 나오는 결과라고 설명합니다. 커널은 페이로드를 해석하지 않고("blind"), 어떤 제공자·채널·도구도 이름으로 알지 못합니다. AGENTS.md의 제1원칙도 “커널은 작고 눈이 멀었다”입니다.

2-2. 정책을 저장하지 않고 매 도착마다 계산한다

권한은 저장된 목록이 아니라 worker 천장 ∩ EE 체인 ∩ run의 바인딩의 교집합으로 산출물이 도착할 때마다 형성됩니다. 모델이 run 기록에 뭘 써도 권리가 되지 않는다는 점이 보안 문서의 핵심 주장입니다.

2-3. 경쟁 접근과의 차이

3기술 스택 전체 지도

커밋 c44cede의 git ls-files 기준입니다. 줄 수는 확장자별 물리 줄이며 테스트·주석·생성물이 섞여 있어 “순수 코드량”이 아닙니다.

패키지 스크립트에서 볼 수 있는 흥미로운 점은 check:public-source, export:package, verify:publication처럼 공개 배포용 소스 검사와 패키지 내보내기가 별도 명령으로 분리돼 있다는 것입니다. 레지스트리 패키지를 “설치 가능한 단위”로 다루려는 설계 흔적입니다.

3-1. 서술자(registry)의 종류

registry/
  interface/              86개  모델 제공자·채널·에이전트(system_worker_*)·방의 문(door)
  worker_environment_kind/ 12개  filesystem_workspace, git_worktree, browser_session,
                                 code_mode, container_session, desktop_session,
                                 process_session, mcp_stdio_session, remote_exec_server ...
  tool/                  192개  browser.click, coder.apply_patch, coder.exec ...
  verifier/               15개  build_success, ocr_text_contains, operator_approval ...
  ee_template/             9개  existence, operator_space, project, self_improvement ...
  artifact/              35개  역할·가이드·스킬 같은 선언된 컨텍스트
  mark/                   14개  coder.build.ok 등

폴더 수는 각 디렉터리의 직속 하위 폴더를 센 값이며, 이후 커밋에서 늘어날 수 있습니다. 한 도구 서술자(browser.click/tool.json)에는 실행 바이너리, 읽기·쓰기·실행 권한 슬롯, 네트워크/로컬 IPC 허용 여부, 지원하는 방 종류, 인자 JSON Schema가 한꺼번에 선언돼 있습니다.

4아키텍처 심화 분석

4-1. 전체 구조도

4-2. 여덟 프리미티브 한눈에

4-3. 정책 형성: 교집합과 “더 좁은 쪽이 이긴다”

docs/architecture.md가 요약한 식은 아래와 같습니다.

grant = worker-interface ceiling  ∩  the EE chain the run lives in  ∩  the run's authored bindings

이 식이 코드에서 어떤 모양인지 crates/octopus-policy/src/lib.rs에서 확인할 수 있습니다. 집합형 권한은 CapSet::intersect(BTreeSet 교집합)로, 읽기/수정/생성/삭제 같은 산출물 권리는 ArtifactRights::intersect로 각 항목을 AND 합니다. 그리고 masked_by_verbs의 주석은 “바인딩이 더 넓게 적어도 천장이 허용하지 않은 권리는 제거된다 — 좁은 쪽이 이긴다, 넓히는 것은 불가능”이라고 적고 있습니다. 한 줄로 정리하면 권한은 합쳐질수록 줄어든다는 것이 이 정책 모델의 불변식입니다.

// crates/octopus-policy/src/lib.rs (발췌 — 주석은 요약)
pub fn intersect(&self, other: &Self) -> Self {
    Self {
        read:   self.read   && other.read,
        change: self.change && other.change,
        create: self.create && other.create,
        delete: self.delete && other.delete,
    }
}

정책 변수는 선언부(InterfacePolicyDeclaration)에서 reduce 방식을 정의하고, form_interface_policy가 worker 층과 EE 층을 받아 boundary(집행용)와 context(모델에게 보여줄 컨텍스트) 두 가지로 값을 만듭니다. POLICY.md가 말하는 “정책의 두 소비자 — 런타임/방은 집행 경계로, 모델은 컨텍스트로 소비”가 함수 반환 타입(FormedInterfacePolicy { boundary, context })에 그대로 대응됩니다.

4-4. 한 턴이 지나가는 길

README의 시퀀스를 줄이면 이렇습니다: 사람이 Home에서 메시지 입력 → 채팅 인터페이스가 산출물을 커널에 전달 → 커널이 grant 형성·승인·기록 → 모델 제공자 인터페이스가 도구 호출 산출물을 돌려줌 → 작업 공간 방의 문(door)이 grant를 검사하고 도구 실행 → 결과 산출물 → 모델 응답 → 사람에게 렌더링. 커널은 아무것도 먼저 밀어넣지 않고(push 없음), 각 인터페이스가 자기 ‘움직임(movement)’을 읽는 살아있는 프로세스입니다.

4-5. 장부(ledger)가 기록하는 것

crates/octopus-ledger/src/lib.rs에는 움직임 종류와 거부 사유가 열거형으로 정의돼 있습니다.

거부 사유가 열 가지로 타입화돼 있다는 점이 설계의 핵심입니다. 문서가 말하는 “거부도 장부의 한 행이며 조용한 누락(silent drop)은 없다”가 이 열거형으로 구현됩니다. verifier가 실패해도 ‘도착’과 ‘검증 실패’는 영속 행으로 남고, mark(성공 표시)만 찍히지 않습니다.

4-6. 방(Worker environment)과 이중 방어

방은 종류(kind) + 문(door) 인터페이스 + 형성된 정책으로 구성됩니다. 예로 git_worktree의 서술자는 substrate_family: process_exec, 기능 filesystem, process_exec, git, 읽기 루트(repo_root, tool_cache_root, toolchain_root)와 쓰기 루트(git_common_root, worktree_root 등)를 선언합니다.

보안 문서는 두 겹의 독립 방어를 구분합니다. 정책은 “run이 무엇을 요청할 수 있는가”를 정하고, 프로세스 권한은 “프로세스가 물리적으로 무엇을 건드릴 수 있는가”를 정합니다. 기본 sandbox_mode: "enforced"에서는 도구·verifier·인터페이스 프로세스가 환경 변수를 비운 채 deny-by-default macOS sandbox-exec 안에서 시작합니다. 단, 서술자가 sandbox_mode: "disabled"를 고르면 그 프로세스는 OS 샌드박스 없이 돕니다. 문서도 “정책 허용을 물리적 격리와 같다고 보지 말라”고 명시합니다.

4-7. 체크포인트 + verifier 예시

{
  "id": "c1",
  "run": "run_web",
  "epoch": 0,
  "interface_binding": { "interface": "world_provider_codex" },
  "required_verified_artifacts": [
    {
      "mark": "ocr.text.contains",
      "artifact_label": "screen.captured",
      "verifier": "ocr_text_contains",
      "params": { "expected_text": "OCTOPUS" }
    }
  ]
}

(docs/contracts/VERIFIERS.md의 예시입니다.) 이 체크포인트는 screen.captured 산출물이 도착하고 OCR verifier가 “OCTOPUS” 문자열을 확인해야만 닫힙니다. 모델이 “화면을 확인했다”고 말하는 것은 mark가 되지 못하고, 검사를 통과한 산출물만 장부에 성공으로 남는다는 점이 이 구조의 핵심 계약입니다.

5디렉토리 구조 해부

5-1. 읽는 순서 제안

1. README.md → docs/architecture.md: 용어와 그림.
2. docs/contracts/POLICY.md: 설계 목표(“동시 1,000개 EE에서도 각 worker가 자기 권한을 정확히 안다”)와 형성 원리.
3. crates/octopus-policy/src/lib.rs (997줄): 교집합·마스킹 구현.
4. crates/octopus-ledger/src/lib.rs: 움직임·거부 사유 타입.
5. registry/interface/system_worker_coder/{interface,policy}.json: 에이전트가 ‘두 파일’이라는 말의 실물.

5-2. 에이전트의 실물: system_worker_coder

interface.json은 "interface_type": "system", "role": "worker" 같은 몇 줄뿐이고, policy.json의 ceiling이 접근 상한을 담습니다. 이 저장소의 coder worker 상한은 인터페이스 37개, 도구 33개(coder.apply_patch, coder.write_file, coder.exec, coder.build 등), 방 종류 3개(filesystem_workspace, git_worktree, system_room)입니다. 새 역할을 만든다는 것은 이 폴더를 복사해 id와 목록을 고치는 일이며, 커널 코드를 바꾸지 않는다는 것이 AGENTS.md의 두 번째 원칙(“능력은 레지스트리에 산다”)입니다.

6학습 포인트 (기술별)

6-1. 비판적으로 읽을 지점

• 규모 주장과 실측. README는 커널이 “약 45,000줄의 Rust”라고 하지만, crates/ 아래 .rs 파일을 합치면 58,785줄입니다(테스트 파일명이 들어간 경로를 제외하면 51,144줄). 산정 범위가 달라 생긴 차이로 보이며, 정확한 ‘커널 범위’ 정의는 저장소에 없습니다.
• “수천 개의 서술자”는 지향. AGENTS.md는 “Thousands of JSON descriptors are intended”라고 적습니다. 지금 registry/의 폴더는 수백 개 수준이며, 위 표의 값은 이 커밋에서 센 값입니다.
• 코딩 성능 근거 없음. 성능 벤치마크나 자기개선 측정 결과는 확인되지 않았고, README가 “self-improvement는 연구 목표”라고 분리합니다.

7하드웨어 / 시스템 요구사항

아래는 docs/getting-started.md와 README에 적힌 소스 빌드 조건입니다. 이 글은 설치·빌드를 실행하지 않고 소스를 읽어 작성했으므로, 실제 빌드 시간·메모리 사용량은 확인하지 못했습니다.

8직접 해볼 수 있는 실습 과제

git clone https://github.com/miuuyy/Octopus-SI-OS.git
cd Octopus-SI-OS
git checkout --detach c44cede5f5c884cdcaff17ac7a422a76f49fd8cc
python3 - <<'PY'
import json
for w in ("coder", "planner", "reviewer"):
    c = json.load(open(f"registry/interface/system_worker_{w}/policy.json"))["ceiling"]
    print(w, {k: len(v) for k, v in c.items() if isinstance(v, list)})
PY

export OCTOPUS_HOME="$HOME/.octopus-preview"   # 짧은 경로 권장(유닉스 소켓 경로 길이 제한)
npm ci --prefix app
npm --prefix app run build:cli
./octopus --home "$OCTOPUS_HOME"

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

11-1. 저장소 문서

• miuuyy/Octopus-SI-OS — 저장소 홈
• README.md · AGENTS.md — 제품 표면과 설계 원칙
• docs/architecture.md — System/World와 프리미티브
• docs/contracts/POLICY.md · VERIFIERS.md — 정책 형성, 검증과 mark
• docs/security-model.md — 신뢰 경계와 알려진 위험
• docs/getting-started.md · docs/cli.md — 빌드와 터미널 클라이언트
• docs/scenarios.md — 설계 의도를 보여 주는 시나리오(검증된 기능 목록이 아님)

11-2. 본문에서 특히 중요한 소스

• crates/octopus-policy/src/lib.rs — 교집합·마스킹·정책 형성
• crates/octopus-ledger/src/lib.rs — MovementKind, RefusedReason
• system_worker_coder/policy.json — worker 천장의 실물
• Cargo.toml — 워크스페이스 구성과 rust-version

11-3. 관련 기술의 공식 학습 자료

• The Rust Programming Language — 크레이트·워크스페이스 기초
• BTreeSet 문서 — 정책 집합 연산의 기반 타입
• Understanding JSON Schema — 서술자·도구 인자 검증
• Electron 공식 문서 · Node.js 릴리스 일정 — 클라이언트 쪽 기반

외부 문서는 바뀔 수 있습니다. 이 글의 구조·수치 설명은 커밋 c44cede에 맞춘 것이며, 연구 프리뷰의 저장 형식은 이후 빌드에서 달라질 수 있습니다.

현재 상태 (2026-10-25 확인)