← 실험실 패키지 분석 · 공개 베타 · OMO Native

OMO Native가 한 줄 설치로 왔습니다

npm i -g omo-ai@beta. 예전처럼 Senpi와 OMO 어댑터를 따로 빌드하지 않아도 됩니다. 메모리, 모델 폴백, 멀티 프로바이더, Ultrawork와 하위 에이전트까지 한 패키지로 묶였습니다. 기능이 강한 만큼 npm 원본을 열어 무엇이 설치되고, 무엇을 읽고, 무엇을 밖으로 보내는지 확인했습니다.

나무 작업실에서 OMO Native 캐릭터 둘이 협력해 노트북을 꺼내는 장면
OMO Native 공개 베타 · 이미지 제공: 시모어
분석 버전: omo-ai 5.0.0-0.beta.12 엔진: @code-yeongyu/senpi 2026.8.19 확인일: 2026-08-20

1. 결론부터

7.5 / 10 · 강력한 공개 베타

이건 Senpi 이름만 OMO로 바꾼 실행기가 아닙니다. 정확히 고정된 Senpi 엔진 위에 OMO 확장 전체를 싣고, 상태 디렉터리와 업데이트 채널까지 omo로 통합한 제품 패키지입니다. 예전에 로컬 빌드가 필요했던 OMO Native 기능을 설치 명령 하나로 가져온다는 점이 가장 큽니다.

추천개인 프로젝트, 새 저장소, 읽기 전용 리뷰, 제한된 자동화
조건부 추천회사 저장소, 장시간 무인 실행, 많은 API 키를 쓰는 환경
아직 보류감시 없는 full-access, 안정판을 기대한 전면 교체

좋은 이유는 기능이 많아서가 아닙니다. 모델이 무너질 때 복구하고, 다른 모델로 넘어가고, 작업과 사람을 기억하는 장치를 런타임 한곳에서 관리하기 시작했기 때문입니다.

2. 한 줄 뒤에 무엇이 들어오나

기존 설치는 건드리지 않고 npm 레지스트리의 tarball을 격리 폴더에 풀어 확인했습니다. 패키지 자체는 507개 파일, 압축 해제 기준 약 7.6MB였지만 고정된 Senpi와 SDK 의존성이 붙으면서 임시 prefix의 실제 설치 크기는 약 523MB가 됐습니다.

표면확인한 내용
실행 명령omo 하나. 런처가 Senpi CLI에 OMO 확장을 자동으로 붙입니다.
Node 요구사항node >= 24. 낮은 버전에서는 설치·실행 단계부터 맞지 않습니다.
상태 저장~/.omo/agent 아래 인증, 모델, 세션, 캐시와 메모리 상태를 통합합니다.
업데이트latest가 아니라 beta dist-tag를 봅니다. omo update도 npm 명령을 안내합니다.
기본 기능read·bash·edit·write, 세션 이어하기, permission preset, model cycling, app-server.
OMO 확장Ultrawork, task engine, memory, fallback architect, LSP, ast-grep, nested agent, 24개 스킬.

omo doctor에서는 패키지 manifest, 확장, LSP daemon, agent toolkit, Senpi CLI와 엔진 버전이 모두 통과했습니다. 반대로 모델 인증이 없는 격리 환경에서 실제 추론은 멈췄습니다. 이 글은 응답 품질 체험기가 아니라 패키지·런타임·안전 표면을 열어본 분석입니다.

3. 왜 이렇게 좋게 봤나

기억이 세션 바깥으로 나갑니다

기존 코딩 에이전트는 세션 안에서는 똑똑해도 다음 날 다시 만나면 프로젝트의 실패와 사람의 선호를 잊습니다. OMO Native는 사실 추출, 사람 카드, reflection, dream consolidation을 한 메모리 계층으로 묶었습니다. 작업이 길어질수록 매번 설명하는 비용이 줄어드는 방향입니다.

모델 하나에 운명을 걸지 않습니다

모델 반복 호출, 같은 문장 반복, provider 장애를 한 모델의 실패로 끝내지 않고 fallback과 다른 역할의 에이전트로 넘기는 구조가 들어 있습니다. 모델 선택이 UI 설정이 아니라 실행 안정성의 일부가 됐다는 점이 좋았습니다.

권한을 실행 단위로 줄일 수 있습니다

read-only, workspace, full-access, ask 프리셋과 도구 allowlist·denylist가 있습니다. 강력한 에이전트를 약하게 시작할 수 있다는 뜻입니다. 처음부터 모든 권한을 열 필요가 없습니다.

설정 이전이 덜 무모합니다

omo setup은 OpenCode, Gajae Code, oh-my-pi의 인증 저장소를 검사하지만 OAuth 토큰은 자동 복사하지 않습니다. API 키를 가져오기 전 계획을 보여주고, 기존 provider를 덮어쓰지 않으며, 백업과 0600 권한을 사용합니다.

4. 메모리는 핵심이자 베타 위험입니다

이 제품의 가장 큰 차이는 메모리입니다. 동시에 가장 보수적으로 봐야 할 곳도 메모리입니다. 공식 beta.8 릴리스 노트에는 실패한 추출 작업의 무한 재시도가 디스크 388GB를 사용한 사고가 공개돼 있습니다.

현재 beta.12는 그 이후 버전입니다. 재시도 backoff, 실패 횟수 제한, 오래된 실행 정리, 128KiB payload 제한, /facts status/facts retry가 들어갔습니다. 사고를 숨기지 않고 원인과 경계를 제품에 넣은 점은 긍정적입니다. 다만 장시간 무인 실행에서 메모리가 완전히 검증됐다는 뜻은 아닙니다.

당분간 같이 볼 명령
omo --version
omo doctor
du -sh ~/.omo

5. 공급망과 인증정보 처리

npm 원본에는 preinstall이나 postinstall처럼 설치 순간 실행되는 lifecycle script가 없었습니다. beta.12에는 npm 서명과 SLSA provenance가 있고, 출처는 code-yeongyu/oh-my-openagentdev 브랜치, 커밋 ec3d5afa, GitHub Actions publish.yml로 연결됐습니다.

공급망 출처가 확인된 것과 에이전트 실행이 안전하다는 것은 다른 문제입니다. OMO는 프로젝트 파일을 읽고 쉘을 실행하며 API 키를 사용할 수 있습니다. 특히 omo setup --yes는 확인 질문을 건너뛰고 가져올 수 있는 API 키를 새 저장소에 복사하므로, 먼저 omo setup --dry-run으로 목록을 보는 편이 안전합니다.

6. 텔레메트리에서 나가는 것

텔레메트리는 기본 활성화된 opt-out 방식이며 PostHog로 전송됩니다. 공식 schema는 프롬프트와 응답 원문, 파일 경로, 작업 디렉터리, 저장소 이름, 환경변수 값을 보내지 않는다고 명시합니다. 대신 아래의 운영 지표는 나갑니다.

  • OS, 버전, CPU 수, 메모리 구간과 아키텍처
  • 기본 provider·model, provider와 model 개수
  • 입출력·추론·캐시 토큰과 비용
  • 스킬 사용, 하위 에이전트, 병렬 실행과 기능 사용 통계
  • 원문 대신 prompt 길이 구간과 Ultrawork 키워드 여부

machine id는 hostname을 로컬에서 해시하고, session id도 기계별 salt와 함께 해시합니다. 다만 전송 IP를 통해 PostHog가 위치를 파생할 수 있습니다. 원치 않으면 처음부터 끄면 됩니다.

텔레메트리 끄기
export DO_NOT_TRACK=1

또는 omo.json{"telemetry":{"enabled":false}}를 둘 수 있습니다.

7. 크기·취약점·라이선스

항목확인 결과해석
설치 크기약 523MBCLI 하나치고 무겁습니다. Anthropic SDK와 Senpi 계열이 대부분입니다.
운영 의존성약 260개직접 의존성은 2개지만 고정 엔진 아래 트리가 큽니다.
npm audithigh 7 · moderate 1brace-expansion, fast-uri, hono, ip-address, undici 등 하위 의존성입니다.
라이선스루트 package에 license 필드 없음plugin의 MIT 문구도 LSP adapter 일부로 범위가 한정돼 있습니다. 재배포·상용 번들은 별도 검토가 필요합니다.

audit의 high가 기본 로컬 실행에서 곧바로 원격 공격으로 이어진다는 뜻은 아닙니다. 하지만 네트워크와 쉘, 파일을 함께 다루는 도구이므로 “CLI니까 상관없다”라고 지우기도 어렵습니다. beta 업데이트가 빠른 만큼 버전이 올라갈 때 의존성 audit도 같이 보는 편이 맞습니다.

8. 제가 권하는 시작 방법

이미 설치했다면 다시 설치할 필요는 없습니다. 버전과 패키지 상태를 확인하고, 첫 프로젝트는 약한 권한으로 시작합니다.

첫 실행 기준
omo --version
omo doctor
omo setup --dry-run

DO_NOT_TRACK=1 omo \
  --permission-preset read-only \
  --no-session

읽기 전용 리뷰가 안정적이면 workspace로 올리고, 메모리와 fallback이 며칠 동안 어떻게 움직이는지 본 다음 full-access를 여는 순서가 좋습니다. 회사 저장소에서는 도구 allowlist까지 같이 거는 편이 안전합니다.

최종 판단. 이제야 “OMO Native를 써본다”는 말이 설치 명령 하나와 같은 뜻이 됐습니다. 아직 베타지만, 단순히 모델을 감싼 또 하나의 CLI가 아니라 긴 작업을 버티는 런타임으로 가는 방향은 분명합니다.

확인한 원문

이 글은 CMORE가 npm 원본, 설치 파일, 공식 문서와 공개 릴리스 기록을 독립적으로 확인해 작성했습니다. 장기 추론 품질과 메모리 체감은 별도 사용 기록이 더 필요하며, 프로젝트 공식 홍보나 보증이 아닙니다.