oxi 생태계 해부도

Rust를 고른 건 취향이 아니라 이 프로젝트가 풀어야 하는 문제 자체가 요구한 선택에 가깝습니다. oxios는 여러 에이전트를 프로세스처럼 fork/exec/wait/kill 하면서 동시에 굴리고, 그 상태를 EventBus·StateStore로 계속 공유해야 하는 상시 구동 시스템입니다. TypeScript/Node 계열(Claude Code, opencode, OpenClaw)이 흔히 쓰는 싱글 스레드 이벤트 루프 + GC 조합은 요청 하나 처리하고 끝나는 짧은 프로세스에서는 전혀 문제가 안 되지만, 수십 개 에이전트를 몇 시간이고 물고 있는 데몬에서는 GC 정지 시간과 메모리 상승 곡선이 그대로 운영 리스크가 됩니다. Rust는 가비지 컬렉터 없이 컴파일 타임에 메모리 소유권을 검증하니, 오래 떠 있어도 메모리 사용량이 예측 가능하고 GC로 인한 지연 스파이크가 없습니다. 게다가 13개(oxicode)+6개(oxios) 크레이트로 나눈 워크스페이스는 이 규모의 시스템을 오래 유지보수한다는 전제를 깔고 있는데, Rust의 강한 타입 시스템과 트레이트 기반 포트 계약(oxicode-sdk의 15개 포트, oxios의 KernelHandle 22개 API)은 그 크레이트 경계를 컴파일러가 강제해줍니다. TypeScript도 타입은 있지만 런타임에 보장되는 게 아니라서, 이 정도로 많은 경계를 안전하게 유지하기는 더 어렵습니다.

물론 공짜는 아닙니다. Rust는 학습 곡선이 가파르고 개발 속도 자체는 TypeScript보다 느립니다 — 오너십·라이프타임 문제로 씨름하는 시간이 분명 있습니다. 컴파일 시간도 무시 못 합니다(oxios가 dev 프로필에서 opt-level을 일부러 1로 낮춰둔 것도 이 컴파일 시간 문제를 완화하려는 조치입니다). 채용 가능한 개발자 풀도 TypeScript보다 작고요. oh-my-pi가 Rust 코어에 TypeScript 패키지를 섞은 하이브리드로 남아있는 것도 아마 이 트레이드오프를 절충한 결과일 겁니다 — oxicode/oxios는 그 절충 없이 순수 Rust로 끝까지 밀어붙인 쪽이고, 그 대가로 개발 속도보다 장기 운영 안정성을 택한 셈입니다.

단일 바이너리는 Rust를 고른 데서 자연스럽게 따라온 결과이기도 하지만, 그 자체로 독립적인 장점이 있습니다. opencode는 Bun/Node 런타임이 있어야 돌고, Claude Code는 npm install이 전제입니다 — 사용자 머신에 "이미 맞는 런타임이 깔려 있다"는 가정을 까는 겁니다. oxicode/oxios는 curl | bash 한 줄이면 끝입니다. 정적으로 링크된 바이너리 하나 안에 의존 라이브러리가 전부 고정돼 들어가니, node_modules 트리가 통째로 안고 있는 버전 충돌·서플라이체인 리스크도 구조적으로 사라집니다. 시작 속도도 다릅니다 — 인터프리터 워밍업이나 JIT 컴파일 없이 바로 실행되니, CLI처럼 자주 스폰되는 프로그램에서는 이 차이가 체감됩니다. 배포 대상도 넓어집니다 — 컨테이너 이미지에 Node 런타임 레이어를 얹을 필요가 없으니 oxios 같은 데몬을 도커에 넣어도 이미지가 가볍고, 서버든 온프레미스든 실행 파일 하나 복사하면 끝입니다.

대신 단일 바이너리는 유연성을 조금 내줍니다. 실행 중에 코드를 갈아끼우는 동적 플러그인 로딩이 스크립트 언어보다 번거롭습니다 — 실제로 oxicode도 한때 OS 레벨 동적 라이브러리(.so/.dylib)로 익스텐션을 로드하는 방식을 문서에 남겨뒀다가, 결국 WASM 기반 익스텐션 로딩으로 갈아탔습니다. 정적 링크가 주는 안정성은 그대로 가져가면서 확장성 문제를 풀려다 보니 나온 선택이었을 겁니다. 바이너리 자체 크기도 스크립트 하나짜리 npm 패키지보다는 커지고요. "단일 바이너리"와 "그래도 재사용 가능한 SDK 크레이트로는 쪼갠다"는 두 요구를 동시에 만족시키려니, 크레이트 경계 설계에 더 신경 써야 했던 것도 이 형태가 치른 비용입니다.

oxios가 CLI 한 번 실행하고 끝나는 도구가 아니라 계속 떠 있는 데몬인 이유는, 상태를 유지해야 하는 일들이 애초에 요청 단위로는 풀리지 않기 때문입니다. CronScheduler가 예약 작업을 처리하려면 뭔가는 계속 깨어있어야 하고, 여러 채널(Web/CLI/Telegram)이 같은 세션·같은 에이전트 상태를 공유하려면 그 상태를 들고 있는 프로세스가 하나 필요합니다. 매 요청마다 새로 뜨는 서버리스 모델이었다면 EventBus·StateStore를 매번 다시 조립해야 했겠죠. 데몬으로 도는 덕에 인프로세스 브라우저(oxibrowser)나 인프로세스 git(gix)도 서브프로세스를 스폰하지 않고 직접 제어할 수 있습니다 — README가 못박아둔 "No containers. No subprocess browser."가 가능한 것도 결국 이 상시 구동 모델 덕분입니다. 그리고 이 전부가 사용자 인프라 안에서만 돈다는 것, 데이터가 외부 클라우드로 안 나간다는 것도 기업이나 프라이버시에 민감한 개인에게는 실질적인 이유가 됩니다.

그런데 이 편의는 그대로 운영 부담으로 돌아옵니다. 클라우드 서비스(Claude Code Routines 같은)를 쓰면 "서버가 살아있는지" 자체를 신경 쓸 필요가 없는데, 자체 호스팅 데몬은 그 책임을 사용자가 떠안습니다. oxios가 스스로 이 문제에 부딪힌 적도 있습니다 — 예전에는 웹서버·게이트웨이 태스크를 fire-and-forget으로 띄워놓고 죽어도 감지를 못해서, oxios status는 "Running"이라고 뜨는데 실제로는 절반만 살아있는 상황이 있었습니다(RFC-030). 결국 데몬 안에 또 다른 감시자(TaskSupervisor)를 자체 구현해야 했죠. 리소스도 항상 켜져 있으니 계속 CPU·메모리를 점유하고, 그래서 Budget Manager·Resource Monitor 같은 자체 통제 장치가 필요해집니다 — 서버리스였다면 신경 안 써도 될 비용입니다. 업데이트할 때도 재시작이 필요하니 진행 중인 작업을 어떻게 안전하게 넘길지 스스로 설계해야 하고, 다른 기기에서 내 데몬에 접근하려면 클라우드처럼 그냥 로그인하면 되는 게 아니라 별도의 원격 접속 체계를 직접 만들어야 합니다(E2EE 페어링 기반 리모트 컴패니언 기능을 따로 구현한 이유, RFC-044). 데몬 모델은 "내 손 안에 다 있다"는 통제력을 주는 대신, 클라우드가 대신 해주던 운영 전부를 스스로 떠안는 거래입니다.

사실 oh-my-pi는 경쟁자라기보다 오리지널에 가깝습니다. oxicode가 통째로 이식해 온 서브시스템만 셋(Mnemopi, managed-skills, snapcompact)이니, "누가 더 나은가"를 묻기 전에 oxicode는 oh-my-pi의 좋은 아이디어를 Rust로 재구성하면서 태어난 프로젝트라는 걸 인정하고 시작해야 합니다. 그래도 이식 과정에서 얻은 게 있습니다 — oh-my-pi는 Rust 코어(~80K줄)에 TypeScript 패키지가 섞인 하이브리드 배포인데, oxicode는 그 개념들을 전부 순수 Rust 크레이트로 다시 짜면서 단일 정적 바이너리 하나로 밀어넣었습니다. 설치가 스크립트 한 줄로 끝나고 Node·Bun 런타임을 따로 깔 필요가 없다는 뜻이죠. "SDK가 행동을 소유한다"는 크레이트 경계 규율도 oh-my-pi에는 없던 것이고, oxicode-lsp처럼 프로토콜만 딱 떼어낸 얇은 어댑터도 재사용성 면에서 더 깔끔합니다.

반대로 냉정하게 보면 기능 커버리지는 oh-my-pi가 아직 한참 앞서 있습니다. LSP 14개 오퍼레이션에 DAP(디버거 프로토콜) 14개 오퍼레이션까지 지원하는데, oxicode-lsp는 JSON-RPC 프레이밍만 하는 552줄짜리 얇은 어댑터라 디버거 통합 자체가 없습니다. oh-my-pi는 60개가 넘는 프로바이더와 31개 내장 툴, 거기에 브라우저 제어·Python 실행·서브에이전트까지 한 프로젝트 안에 다 들어있는데, oxicode-agent는 21개 툴(그중 7개만 필수)로 상대적으로 더 미니멀합니다. 결국 oxicode는 "더 잘 조직된 후발주자"고, oh-my-pi는 "기능은 더 많지만 조직은 덜 정돈된 원조"인 셈입니다.

opencode와 나란히 놓고 보면 가장 먼저 눈에 띄는 차이는 배포 방식입니다. opencode는 Bun/Node 위에서 도는 TypeScript 모노레포라 로컬 서버 하나가 뜨고, 그 서버에 TUI·데스크톱 앱(Electron)·VSCode 확장·모바일 클라이언트가 동시에 접속하는 client/server 구조입니다. oxicode는 그냥 정적 바이너리 하나 실행하면 끝이라 배포·설치가 압도적으로 단순합니다. 게다가 oxicode-sdk를 별도 크레이트로 떼어낸 덕분에 다른 Rust 프로젝트가 CLI는 필요 없고 에이전트 런타임만 갖다 쓰고 싶을 때 크레이트 하나만 의존성으로 걸면 됩니다 — 실제로 oxios가 정확히 이렇게 합니다. opencode에는 이런 식으로 딱 떼어서 재사용할 수 있는 "SDK 크레이트" 개념 자체가 없습니다.

그런데 이 client/server 구조가 opencode한테는 진짜 장점이기도 합니다. 서버가 세션 상태를 SQLite에 들고 있으니 터미널에서 시작한 작업을 데스크톱 앱이나 VSCode에서 이어받아 볼 수 있습니다 — oxicode처럼 단일 프로세스 TUI 중심 구조에서는 애초에 상상하기 어려운 시나리오죠. opencode는 또 Plan(읽기 전용)/Build 모드를 명시적으로 나누고 undo/redo까지 붙여놨는데, 이 정도의 세밀한 UX 다듬기는 oxicode 쪽 문서에서는 아직 확인되지 않습니다. 정리하면 oxicode는 "가볍고 재사용 가능한 엔진"에 강하고, opencode는 "여러 디바이스를 넘나드는 협업형 UX"에 강합니다.

oxicode 대 Claude Code는 "오픈소스 자유 vs 수직 통합 최적화" 싸움에 가깝습니다. oxicode는 openai·anthropic·google·vertex·azure·bedrock·ollama까지 8개 프로바이더를 다 붙여놨고 로컬 SQLite 벡터 메모리(mnemopi)까지 내장하고 있어서, 어떤 모델을 쓸지·데이터를 어디에 둘지 전부 사용자가 결정할 수 있습니다. 완전히 자체 호스팅이 가능하다는 것도 강점이고요. Claude Code는 태생적으로 Anthropic 모델에 묶여 있습니다.

근데 바로 그 "묶여 있음"이 Claude Code의 무기이기도 합니다. 같은 회사가 모델과 도구를 같이 만드니 프롬프트 설계·툴 콜링 포맷·컨텍스트 관리가 모델 특성에 맞춰 세밀하게 튜닝돼 있고, 이건 멀티 프로바이더를 지향하는 oxicode가 구조적으로 따라가기 어려운 이점입니다. 거기에 IDE 확장·데스크톱 앱·hooks·MCP·서브에이전트까지 아우르는 생태계 규모, 공식 문서와 지원 조직의 크기 자체가 비교가 안 됩니다. oxicode는 소수가 끌고 가는 프로젝트라 안정성 검증이나 엔터프라이즈 지원 트랙레코드가 아직 없죠. 모델 선택의 자유와 데이터 주권이 중요하면 oxicode, 최고 수준으로 다듬어진 단일 경험이 필요하면 Claude Code로 갈리는 그림입니다.

oxios와 Claude Code의 Routines를 나란히 놓고 보면 이건 아예 다른 무게 체급의 물건입니다. Routines는 "예약된 프롬프트 실행"에 가깝습니다 — 특정 시간이나 GitHub 이벤트가 오면 정해진 프롬프트를 한 번 돌리는 것으로, 상태를 가진 에이전트 프로세스라는 개념 자체가 없습니다. 반면 oxios는 fork/exec/wait/kill로 에이전트를 진짜 프로세스처럼 다루고, REST API 150개 이상 엔드포인트로 그 전체를 프로그래밍할 수 있고, MCP와 A2A(에이전트 간 통신)를 동시에 지원합니다. 실제로 커뮤니티에서 Claude Code에 네이티브 데몬·스케줄러를 만들어달라는 요청(#28229)이 올라왔는데 Anthropic은 "not planned"로 닫아버렸습니다 — oxios가 정확히 그 빈자리를 자기 존재 이유로 삼고 있는 셈입니다. 자체 호스팅이라 데이터가 외부로 안 나간다는 것도 기업 입장에선 중요한 포인트고요.

반대로 Routines의 장점은 압도적인 편함입니다. 클릭 몇 번으로 클라우드에 바로 올라가고, 서버를 사거나 운영할 필요가 전혀 없습니다. oxios는 데몬이니 누군가는 그 프로세스가 살아있는지·리소스는 괜찮은지 신경 써야 하는데(그래서 Budget Manager·Resource Monitor 같은 걸 자체 구현했습니다), Routines는 그런 운영 부담을 Anthropic이 통째로 가져가 버립니다. 거기에 Anthropic 모델의 프롬프트 캐싱·컨텍스트 압축 같은 모델 레벨 최적화 혜택도 자동으로 따라오고, GitHub 이벤트 트리거처럼 이미 있는 SaaS 생태계와의 연결도 매끈합니다. "운영 부담 없이 가볍게 자동화만 하고 싶다"면 Routines가 압도적으로 편하고, "여러 에이전트를 프로세스처럼 부리고 싶다"면 그 그림 자체가 Routines에는 없습니다.

OpenClaw는 접근 자체가 다릅니다. 이미 쓰고 있는 WhatsApp·Telegram·Slack·Discord·iMessage 같은 메신저 안으로 비서가 들어오는 방식이라 사용자 입장에서는 배울 게 거의 없습니다 — 그냥 메시지를 보내면 됩니다. 이 진입장벽의 낮음 덕분인지 실제로 채택 규모도 꽤 큰 것으로 조사됐습니다. oxios는 이런 손쉬운 진입로가 없습니다. REST API와 대시보드를 통해 접근하는, 명백히 개발자·파워유저를 겨냥한 물건입니다.

하지만 그 대신 oxios는 훨씬 무거운 일을 할 수 있게 설계돼 있습니다. 여러 에이전트를 동시에 프로세스처럼 굴리는 멀티 에이전트 오케스트레이션, MCP+A2A로 에이전트끼리 서로 대화하게 만드는 구조, oxibrain에 위임하는 불변 원장+재생성 프로젝션 기반의 정교한 기억 시스템까지 — 이 정도 구조를 가진 개인 비서형 제품은 조사 범위 안에서 확인되지 않았습니다(OpenClaw가 MCP·A2A를 지원하는지, 벡터 기억을 갖고 있는지는 공개된 자료로는 확인이 안 됐습니다). 브라우저도 서브프로세스 없이 인프로세스로 도는 oxibrowser를 내장하고 있고요. OpenClaw는 "이미 쓰는 메신저 안에서 만나는 개인 비서"에 강하고, oxios는 "여러 에이전트를 동시에 운용하는 백엔드 인프라"에 강한, 사실상 다른 카테고리의 제품입니다.