oh-my-openagent 딥다이브
독립 실행형 OmO와 senpi 확장 구조

기존 OpenCode 플러그인 중심 설명을 5.1.52 소스로 다시 검토했다. 현재 주 진입점은 omo-ai가 제공하는 omo 명령이며, Pi에서 갈라진 senpi 엔진에 OMO 확장을 함께 싣는다. 기존 카탈로그 이름과 링크는 유지한다.

1프로젝트 한줄 요약

OmO는 모델 접속, 코드·문서 작업 도구, 역할별 위임과 메모리를 한 실행 환경에 묶는 코딩 에이전트 하니스다. 현재 README는 독립 실행형을 기본으로 안내한다. OpenCode 어댑터와 Codex용 구성도 소스에 남아 있지만, 예전 문서의 Ultimate·Light 두 에디션만으로 현재 제품을 설명하기는 어렵다.

2왜 주목받는가

2026-10-31 Daily에서 재등장했는지와 별개로 전체 카탈로그 기준 검토 대상으로 확인했다. 주목할 기술적 변화는 호스트 플러그인에서 자체 실행 명령으로 중심이 이동했다는 점이다. 작업별 모델 라우팅, 병렬 도구 호출, 세션 재개, 마크다운 메모리와 보조 관찰자 Kibitzer를 하나의 경험으로 묶는다. README의 성능·규모 표현은 제작자 설명이며 여기서 독립 벤치마크로 검증한 값은 없다.

3기술 스택 전체 지도

루트 npm 이름은 여전히 oh-my-opencode이고 다수의 명령 별칭을 가진다. 독립 명령을 설치하는 패키지 omo-ai와 구분해야 한다. 소스 빌드 워크스페이스와 사용자가 받는 배포 패키지를 같은 것으로 취급하지 않는 연습에 적합하다.

4아키텍처 심화 분석

진입점은 먼저 Bun 실행 가능성을 검사한다. 적절한 Bun으로 재실행하지 않았다면 인증·동기화·계정·설정 명령을 분기하고 나머지를 runLauncher()에 전달한다. 이 구조는 엔진 부팅 없이 처리할 명령과 실제 대화 실행을 구분한다.

// packages/omo-native/bin/omo.js의 분기 구조를 줄인 예시
if (command === "setup") await runSetup(args)
else await runLauncher()

확장 패키지 manifest는 pi.extensions로 ./extensions/omo.js를 등록한다. imports에는 task·computer-use·memory·session-history 등 실행 모듈이 나뉘어 있다. 단일 입구를 여러 기능 모듈에 연결하는 어댑터 설계를 읽을 수 있다.

5디렉토리 구조 해부

진입점 → manifest → 공통 모듈 순서로 읽는다. 예전 문서처럼 모든 핵심 기능을 omo-opencode/src에만 있는 것으로 추정하면 현재 native 경로를 놓친다. 이 조사에서는 내려받은 빌드·설치 스크립트를 실행하지 않았다.

6학습 포인트

• 명령과 엔진 분리: omo.js에서 CLI 하위 명령, 런타임 전환, 엔진 부팅의 경계를 표시해 본다.
• 여러 호스트 지원: 공통 core 패키지와 native·OpenCode·Codex 어댑터가 의존하는 지점을 비교한다.
• 설정 이전의 계약: 가져올 수 있는 API 키와 복사할 수 없는 OAuth 로그인을 구분하고, 미지원 값을 보고하는 방법을 읽는다.
• 고정 엔진 배포: omo-ai가 senpi 버전을 고정하는 이유와 사용자 설치·소스 빌드의 차이를 추적한다.

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

npm 패키지 경로는 Node 24 이상을 명시한다. README는 운영체제·CPU에 맞는 native 바이너리 설치도 안내하므로 Node 하한을 모든 배포 방식에 일괄 적용하면 안 된다. 별도 GPU 최소 사양은 이 조사에서 확인하지 못했다. 선택한 모델 제공자의 계정·접속 조건이 필요하며, 병렬 위임의 비용과 동시성은 각 설정에서 확인해야 한다.

기존 OpenCode 사용자는 이전 가이드의 설치기 경로를 확인한다. 옛 패키지가 omo 명령을 점유할 수 있어 단순 전역 패키지 설치만으로 새 명령이 선택된다고 가정할 수 없다. omo setup --dry-run으로 계획을 먼저 볼 수 있다. setup은 설정을 읽고 동의 후 OmO 경로에 쓰며, OAuth 로그인은 별도로 다시 필요하다.

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

1. 입문: 공식 설치 절차 후 omo --version과 omo doctor로 native 명령·엔진·모델 범주를 확인한다. 이 글의 조사는 설치 실행 검증을 포함하지 않는다.
2. 중급: 기존 OpenCode 환경이 있다면 omo setup --dry-run 결과에서 가져올 값·누락 값·재로그인 필요 항목을 표로 만든다. 인증 원문은 실습 보고에 넣지 않는다.
3. 중급: 작은 저장소에서 ulw 요청을 실행하고 도구 호출·완료 근거·실제 변경을 대조한다. 작업 규모와 호출 비용을 함께 기록한다.
4. 심화: omo.js 분기와 확장 manifest만으로 모듈 의존도 그림을 만든 뒤 실제 파일 위치와 대조한다.

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

10핵심 키워드 사전

11참고 링크

• 검토한 고정 SHA df6524a
• README · omo-ai manifest
• 실제 명령 진입점 · 확장 manifest
• OpenCode 이전 가이드 · 공식 문서