TL;DR

omp는 터미널 중심의 AI 코딩 에이전트로서 LSP와 DAP를 에이전트 호출 경로에 직접 연결하고 해시라인 패치·서브에이전트·인프로세스 네이티브 툴을 결합해 코드 읽기·편집·디버깅의 수작업을 줄인다. 내부적으로 약 55k 줄의 Rust 네이티브 코드로 검색·쉘·AST·토큰 카운팅을 프로세스 내부에서 처리하고 TypeScript SDK·RPC·ACP 등 네 가지 진입점을 통해 에디터·스크립트·서비스에 임베드할 수 있다. 제공자 라우팅·fallback chains·path-scoped 모델 설정을 통해 다중 제공자 환경에서 세션-스코프 메모리와 비용 제어를 지원하며, 해시 앵커 검증과 서브에이전트의 스키마화된 결과 합산으로 대규모 리팩터링과 병렬 분석의 안전성과 예측가능성을 확보한다.

주요 기능

• 에이전트가 LSP와 동기화된 리팩터링을 수행해 파일 이동 전에 재수출·별칭·참조까지 업데이트한다. 이 기능은 workspace/willRenameFiles 경로로 호출되어 IDE 수준의 네비게이션 메타데이터를 에이전트가 동일하게 활용하게 만든다. 결과적으로 리네임·리팩터링으로 인한 누락 참조가 줄고 일관된 코드베이스 상태를 유지한다.
• 네이티브 DAP 어댑터를 통해 네이티브 바이너리·Go 런타임·Python 프로세스에 직접 연결해 스택 프레임과 지역 변수를 읽고 평가한다. 에이전트는 lldb, dlv, debugpy 같은 어댑터를 호출해 브레이크포인트와 스텝 단위를 제어하며 디버깅 정보를 기반으로 수정 제안이나 실행 도구를 호출한다. 이 방식은 단순한 print 주입 대신 런타임 상태를 읽어 정확한 원인 추적을 가능하게 만든다.
• 서브에이전트 패턴으로 작업을 병렬 분할하고 각 서브에이전트가 격리된 작업트리와 도구 표면에서 실행된 결과를 스키마 검증된 JSON으로 반환한다. 부모는 구조화된 결과들을 경로로 추출해 병합하므로 자연어 중간 파싱이 불필요하고 충돌 없는 병렬 분석이 가능하다. 서브에이전트는 cost·duration 등 메타정보를 개별적으로 보고해 작업 트래킹과 비용 모니터링이 용이하다.
• 해시라인(hashline) 방식의 편집을 사용해 모델이 변경하려는 텍스트를 콘텐츠 해시로 지목하게 하며 stale-anchor 검증으로 충돌을 사전에 차단한다. 이 접근은 모델이 전체 라인을 재생성하지 않고 앵커 중심으로 정확한 패치를 적용하게 하여 토큰 소비를 크게 줄인다. 앵커 불일치 시 패치를 거부해 저장소 무결성을 보장한다.
• 웹·레지스트리·아카이브를 포함한 25개 검색 백엔드를 내장해 web_search를 통해 arXiv PDF·GitHub·Stack Overflow 등 구조화된 마크다운을 수집한다. 검색 결과는 에이전트의 read 도구로 직접 전달되어 인용·앵커를 보존한 상태로 참조가 가능하다. 이 구조는 외부 자료를 코드 컨텍스트와 연결해 근거 기반 수정을 지원한다.

어떻게 동작하는가

omp는 TypeScript 기반 런타임과 약 55k LOC의 Rust 네이티브 모듈을 결합해 주요 도구(검색·쉘·AST·PTTY·토큰 카운팅 등)를 프로세스 내부에서 실행한다. 에이전트는 도구 콜을 카드 형식으로 렌더링하고 AST 기반 미리보기와 해시라인 패치로 변경을 제안한 뒤 사용자의 승인으로 원자적 적용을 수행한다. 모델 역할 라우팅·대체 제공자·팰백 체인 같은 라우팅 정책을 통해 다중 제공자 구성과 세션-스코프 메모리를 지원한다.

해결 문제

코드 편집·리팩터링·검색·디버깅을 서로 다른 도구와 수작업으로 연결해야 하는 워크플로가 비효율적이라는 문제를 해결한다. omp는 IDE 수준의 메타데이터(LSP)와 디버거(DAP), 해시 기반 편집, 서브에이전트 병렬화를 하나의 터미널-첫 UX에 통합해 수동 조작과 도구 간 불일치로 인한 오류를 줄인다. 또한 외부 검색 결과를 구조화해 코드 변경의 근거를 자동으로 연결한다.

지금 주목받는 이유

프로젝트는 40개 이상의 제공자와 32개의 내장 도구, 약 55k 줄의 Rust 코어로 광범위한 통합을 제공해 실무 환경에서 바로 쓸 수 있는 완성도를 갖추었다. 이 저장소는 터미널 중심 UX와 에디터 통합(ACP), 그리고 LSP·DAP·서브에이전트 같은 실무 기능을 한 제품군으로 모아 현장 운영 사례에 맞춘 점이 주목을 끌고 있다. 높은 별 수와 활발한 토픽 노출이 실사용 피드백과 연속적인 조율을 뒷받침한다.

차별점

• IDE와 동일한 LSP 동기화를 에이전트 호출 경로로 연결해 리네임·재수출·별칭 업데이트를 파일 이동 전에 처리한다. 이로 인해 수동 리팩터링으로 발생하는 누락 참조와 재수정 루프가 줄어들고 편집 성공률이 높아진다. 대안들이 대부분 단방향으로 파일을 수정하는 것과 달리 omp는 워크스페이스 메타데이터를 이용해 변경 전후를 일관되게 유지한다.
• 핫 패스에서 외부 프로세스를 포킹하지 않고 Rust 네이티브로 ripgrep·glob·실행 환경·토큰 카운팅 등을 인프로세스로 제공해 시스템 콜 오버헤드를 제거한다. 이 접근은 반복적인 파일 검색·쉘 호출 비용을 줄여 지연을 낮추고 다중 플랫폼(Windows 포함)에서 일관된 동작을 보장한다. 결과적으로 동일한 작업에서 포크-exec 기반 도구보다 응답 속도가 빠르고 시스템 리소스 사용이 절감된다.
• 해시라인 기반 패치와 stale-anchor 검증으로 모델 출력의 흔한 공백·포맷 오류를 원천적으로 회피해 실패 재시도 루프를 축소한다. 모델이 변경 지점을 해시로 지정하므로 공백·문자열 매칭 실패로 인한 토큰 낭비가 줄어든다. 앵커 불일치 시 패치 거부 메커니즘이 있어 저장소 무결성 위험을 낮춘다.
• 서브에이전트 패턴으로 작업을 격리된 워크트리에서 병렬로 수행하고 스키마화된 결과를 직접 합산해 자연어 합성 비용을 줄인다. 각 서브에이전트가 별도 도구 표면과 비용·지연 메타데이터를 보고하므로 대규모 분석을 단계적으로 검증하면서 진행할 수 있다. 이 방식은 복합 작업을 수동 분할하지 않고도 충돌 없이 병렬 처리하게 만든다.

사용 사례

• 터미널에서 바로 코드리팩터링과 리네임을 수행하고 싶을 때 LSP 연동과 해시라인 패치를 통해 파일 참조를 안전하게 이동하고 변경 전후의 네비게이션 메타데이터를 보전한다. 이 흐름은 다수의 모듈을 건드리는 대규모 리팩터링에서 수작업 오류를 줄인다. 또한 변경 미리보기를 통해 제안된 편집을 검토한 뒤 원자적으로 적용할 수 있다.
• 네이티브 바이너리나 서비스의 런타임 상태를 원격으로 조사해야 할 때 DAP 어댑터를 통해 lldb·dlv·debugpy 세션을 조작해 프레임과 지역 변수를 읽고 바로 수정 제안을 생성한다. 이 과정은 전통적인 print 기반 디버깅보다 정확한 원인 진단을 허용한다. 디버깅 정보는 후속 편집이나 테스트 실행으로 즉시 연결된다.
• 협업 세션을 링크로 공유하거나 QR을 통해 다른 사용자를 참여시키고 실시간으로 세션을 읽거나 함께 편집할 때 /collab 기능으로 읽기/쓰기 권한을 제어하면서 동일한 에이전트 세션을 재현한다. 세션 프레임은 클라이언트 측에서 봉인되어 키를 중계 측에 노출하지 않는다. 이로 인해 원격 페어 프로그래밍과 검토가 안전하게 이루어진다.
• 대규모 코드베이스 스캐닝이나 PR 리뷰를 자동화할 때 task와 서브에이전트를 사용해 병렬로 여러 분석을 실행하고 스키마화된 결과를 모아 우선순위별로 문제를 정렬한다. 각 서브에이전트의 비용과 소요 시간이 메타데이터로 보고되므로 리소스 기준으로 작업을 조정할 수 있다. 자동화된 리뷰에서 P0~P3 우선순위와 신뢰도 점수를 함께 산출한다.

시작하기

macOS와 Linux에서는 curl -fsSL https://omp.sh/install | sh로 설치하거나 Homebrew로 can1357/tap/omp를 설치할 수 있다. 추천 방식으로 Bun 사용을 권장하며 bun install -g @oh-my-pi/pi-coding-agent로 글로벌 설치가 가능하고 Windows는 PowerShell로 제공되는 설치 스크립트를 사용한다. 소스에서 개발하려면 bun setup으로 워크스페이스와 네이티브 모듈 빌드를 준비한 뒤 bun dev로 개발 서버를 실행해 첫 비상호작용 테스트를 수행할 수 있다.

요구사항

• 지원 플랫폼은 macOS·Linux·Windows이며 Bun 런타임 사용을 권장하고 bun 버전은 1.3.14 이상을 요구한다.
• 소스 빌드를 위해 Rust 툴체인과 N-API 빌드 환경이 필요하며 네이티브 크레이트 변경 시 packages/natives의 빌드 재실행이 요구된다.
• 에이전트가 외부 제공자와 통신하려면 각 제공자에 대한 인증 토큰 또는 OAuth 흐름이 필요하며 일부 도구(예: github, tts, inspect_image)는 설정 게이트로 기본 비활성화 상태이다.

벤치마크

이미지 분석