Claude Code 대안 멀티 에이전트, Oh My OpenAgent 솔직 후기 (2026)

1. Oh My OpenAgent는 결국 뭘 하는 도구인가?

Claude Code Pro $20에 시작했다가 Max $100~$200으로 갈아탄 뒤, 2026-01-09 갑자기 “이 토큰으로는 Claude Code CLI 외부에서 못 쓴다”는 메시지를 받은 개발자라면 이 글이 당신을 위한 것이다. Oh My OpenAgent(이하 OmO, 한국어로는 오마이오픈에이전트)는 그 직후 한 달 만에 다운로드 20만을 찍은 한국산 멀티 에이전트 하네스다 (출처: 요즘IT 위시켓).

OpenCode 위에 얹는 “오케스트레이션 레이어”다

OmO는 “AI 모델”이 아니다. 단독으로는 추론도, 코드 생성도 하지 않는다. OmO는 오픈소스 코딩 CLI인 OpenCode 위에 얹는 플러그인으로, 12종 이상의 사전 정의된 에이전트(Sisyphus, Prometheus, Oracle, Atlas, Hephaestus 등)와 모델 라우팅, 작업 흐름 명령을 묶어 한 번에 제공한다. 즉, “어떤 모델을 어떤 역할에 끼울지, 어떤 명령에 어떤 컨텍스트를 줄지”를 미리 설계해 둔 하네스다. 하네스 개념 자체에 익숙하지 않다면 AI 앱은 프롬프트가 아니라 하네스로 완성된다를 먼저 읽어 두는 편이 이해가 빠르다.

GitHub 저장소는 2026-04-30 기준 v3.17.x이며 별 55,200개·포크 4,500개를 기록 중이다 (출처: oh-my-openagent GitHub). 누적 다운로드는 약 1.6M+로, 한국 단독 개발자 프로젝트로는 이례적인 규모다.

메인테이너 김연규가 직접 굴린 도구

메인테이너는 인덴트코퍼레이션의 AI 에이전트 엔지니어 김연규(YeonGyu Kim)다. 본인 Threads 게시글에서 “방구석에서 진행하던 실험이 플러그인이 되었고, 한 제품에서 큰 팬층을 형성하는 컴포넌트가 되었습니다”라고 회고했다 (출처: @yeon.gyu.kim, 33.1K 조회). README.ko.md에는 “개인 토큰값 약 $24,000(약 3천만 원)을 부었다”는 자기 자백이 박혀 있어 “취미 프로젝트가 아닌 실 사용 검증”을 강조한다.

패키지명 변경에 대한 정정

오래된 한국어 자료(특히 2026-01 이전 PyTorchKR 글)에는 oh-my-opencode로 표기돼 있다. 2026-02 전후로 메인테이너가 oh-my-openagent라는 이름을 플러그인 엔트리로 우선시했고, 패키지명 oh-my-opencode는 하위 호환을 위해 유지 중이다. config 파일은 둘 다 인식한다. 본문에서는 OmO로 줄여 부른다.

2. Claude Code 대신 갈아타도 괜찮을까?

OmO 사용자가 가장 자주 묻는 질문이고, 답은 “조건부 예”다. 2026-01-09 사건으로 게임 룰이 바뀌었지만, 그렇다고 모든 사용자가 즉시 옮겨야 하는 건 아니다.

2026-01-09 Anthropic OAuth 차단 사건

2026-01-09 Anthropic은 서버 측에서 구독 OAuth 토큰을 공식 Claude Code CLI 외부에서 차단했다. OpenCode·Roo Code·Cline 사용자가 그날 동시에 작업 화면을 잃었다 (출처: nxcode opencode-alternative-2026). 김연규는 README에서 “Anthropic blocked OpenCode because of us… They want you locked in”이라고 마케팅 카피로 썼다. 이 문구는 메인테이너 측 입장이며 Anthropic의 공식 사유 발표는 별도로 확인된 바 없다.

요점은 두 가지다. 첫째, Claude Code 외부 클라이언트에서 구독을 굴리던 사용 패턴이 사실상 막혔다. 둘째, 우회 자체가 ToS 위반 소지가 있어 한국 사용자는 계정 정지 리스크를 떠안는다. Apiyi의 한국어 가이드도 “공식 Claude Code Max는 국내 사용자의 경우 계정 정지 위험이 있다”고 경고한다 (출처: Apiyi). Claude Code 자체의 가격·기능을 점검하려면 클로드 코드 완전 정복: 설치, 가격, 활용법 총정리 (2026)를 참조하자.

비용 구조 비교

OmO의 권장 묶음은 ChatGPT $20 + Kimi Code $19 + GLM Coding $10(또는 OpenCode Go $10) 조합이다. Claude Max $200 대비 명시적인 비용 절감 동기가 있다. Apiyi가 8개월 100억 토큰 워크로드를 가정해 산출한 시나리오에서는 API $15,000을 Max $800로 93% 절감한 사례가 인용되지만, 이는 Anthropic 차단 이전·헤비유저 가정이다.

다만 비용만 보고 갈아타기 전에 H2-3과 H2-6을 먼저 읽어야 한다. 단순 작업에서는 OmO가 오히려 토큰을 3배까지 더 쓴다는 객관 측정이 있다.

”갈아타도 되는 사람” vs “기다려야 하는 사람”

먼저 갈아타도 좋은 쪽: 사이드 프로젝트, 멀티모델 실험형 연구자, OpenCode를 이미 일상적으로 쓰는 사람. 반대로 기다려야 하는 쪽: 한국 프로덕션 백엔드·금융 도메인, Claude Max를 이미 잘 쓰고 있는 헤비유저, 비용 민감하면서 짧은 작업이 대부분인 사용자다. 결정 매트릭스 전체는 H2-9에 정리한다.

3. ultrawork 한 줄로 정말 8천 ESLint 경고가 사라질까?

ultrawork는 OmO의 시그니처 명령이다. ulw <목표> 한 줄로 계획·분담·실행·검증까지 자동화한다는 카피로 유명하지만, 실측 데이터를 보면 양면성이 분명하다.

압도적인 성공 사례 3건

OmO 공식 사이트에는 사용자 후기 3건이 박혀 있다 (출처: ohmyopenagent.com).

• Jacob Ferrari: “Oh My Opencode로 하루 만에 ESLint 경고 8,000개를 해결했다.”
• James Hargis: “45,000줄 Tauri 앱을 하룻밤 만에 SaaS 웹앱으로 변환했다.”
• Quant Researcher B: “Claude Code 7일 작업이 Sisyphus 1시간이었다.”

세 사례의 공통점은 “분기·반복이 많지만 변형 패턴이 일정한” 작업이다. ESLint 룰 일괄 정리, 동일 컴포넌트 패턴 마이그레이션, 자료구조 일괄 리팩터링처럼 LLM이 한 번 패턴을 잡으면 수천 곳에 동형 적용할 수 있는 작업에서 OmO의 병렬 분담 구조가 돋보인다.

4th Path 리뷰의 반박: “스타터 비용이 비싸다”

같은 명령을 짧은 작업에 그대로 쓰면 결과가 달라진다. 4th Path 리뷰는 이렇게 지적한다 (출처: 4th Path).

“ultrawork activation alone consumes 15,000–25,000 tokens on context setup.”

“Using ultrawork for everything is as inefficient as using a sledgehammer to hang a picture frame.”

즉, 명령 호출 자체가 1.5만~2.5만 토큰을 소모하기 때문에 “함수 한 개 고치기” 같은 짧은 작업에는 오히려 손해다. ulw는 무거운 명령이고, 가벼운 명령은 일반 OpenCode subagent 흐름을 그대로 쓰는 편이 효율적이다.

Glukhov 비교 측정: 단일 문서 마이그레이션에선 OmO가 졌다

Glukhov의 비교 리뷰는 단일 문서 마이그레이션 한 건을 OmO와 순정 OpenCode로 동시에 돌렸다 (출처: Glukhov OmO Experience).

Glukhov 본인도 결론에서 “OmO가 모든 작업에서 나쁘다는 뜻은 아니지만, 단순한 단건 작업에는 오버킬이다”라고 명시했다. 이 부분은 한국 커뮤니티에서 자주 누락되는 정보다.

4. Sisyphus·Prometheus·Oracle… 이 에이전트들은 어떻게 분업하나?

OmO의 핵심 가치는 “어느 작업에 어느 모델을 끼우는지”의 사전 설계다. 12종 이상의 에이전트가 4개 그룹으로 묶여 있고 각 그룹마다 권장 모델이 다르다.

4그룹 분류와 권장 모델

(출처: agent-model-matching.md)

Sisyphus가 작업을 끄는 이유

Sisyphus는 OmO의 메인 컨트롤러다. 사용자가 ulw "이 코드베이스에서 ESLint 경고를 전부 정리해줘"를 입력하면 Sisyphus가 먼저 코드베이스를 훑고, 작업을 분할하고, Prometheus에게 분기 시나리오를 받고, Hephaestus에게 정밀 변환을 위임한다. 이 분업이 Claude Code 단일 에이전트 흐름과 가장 다른 점이다. velog의 한 사용자는 이를 두고 “각 에이전트가 병렬적으로 작업을 백그라운드에서 실행한다는 점이 매력적”이라고 평가했다 (출처: @takealittletime velog).

Hephaestus와 Atlas: 정밀 분석 라인

Hephaestus는 코드 변환 전문가, Atlas는 분기 전략가에 가깝다. 둘 다 GPT-5.4 high 또는 Claude Opus 계열을 권장하는데, 한국 사용자는 OAuth 차단 이후 Opus 직접 사용이 까다롭다. Kimi K2.6의 가성비를 곁들이는 조합이 현실적인데, 이 부분은 Kimi K2.6 완전분석 — Claude Opus 4.7을 88% 싸게 대체하는 법에서 상세 비교를 다룬 바 있다.

Utility 그룹: 무료 폴백 가능

Librarian, Explore, Sisyphus-Junior 같은 보조 에이전트는 Haiku/Sonnet/Mini급 또는 무료 오픈 모델로도 굴러간다. OmO가 무료 폴백 묶음(Kimi K2.5-free, MiniMax M2.7-free, big-pkl GLM 4.6 무료)을 굳이 명시한 이유다. 다만 Utility 그룹만 무료로 돌리고 Communicator·Dual-Prompt는 유료를 쓰는 식의 혼합이 안정적이다.

5. Hash-Anchored Edit이 stale-line 오류를 0%로 만든다고?

OmO에서 가장 마케팅 카피가 강한 기능이 Hash-Anchored Edit이다. 이건 “에이전트가 보지 않은 사이 파일이 바뀌어도 잘못된 위치에 패치를 박는 사고를 막는” 메커니즘이다.

동작 방식: LINE#ID 태그

OmO는 파일을 에이전트에 전달할 때 모든 라인에 [N|hash] 형태의 LINE#ID 태그를 붙인다. 다음과 같은 형태다.

11#VK: function hello() {
22#XJ:   return "world";
33#MB: }

에이전트가 편집을 요청하면, OmO는 마지막으로 읽힌 시점의 hash와 현재 파일의 hash를 비교한다. mismatch가 발견되면 편집을 reject하고 에이전트에게 “파일이 바뀌었으니 다시 읽어라”를 강제한다. 이 패턴 자체는 Can Bölük의 “The Harness Problem” 글에서 영감을 얻었다고 메인테이너가 밝힌 바 있다. 하네스 설계 일반론은 AI 앱은 프롬프트가 아니라 하네스로 완성된다에서 다룬 적이 있다.

공식 벤치: Grok Code Fast 1만 측정됐다

OmO 공식 벤치는 Grok Code Fast 1 모델로 측정했는데, Hash-Anchored Edit 활성화 전 6.7%였던 성공률이 활성화 후 68.3%로 올랐다. 61.6포인트 상승이다. 인상적인 수치이지만 한 가지 제한이 있다. DeepWiki는 원문에서 다음과 같이 명시한다.

“The documentation does not provide success rate data for other models (GPT, Claude, Gemini).”

(출처: DeepWiki oh-my-openagent)

즉, GPT-5.4·Claude Opus·Gemini 3.1 Pro에서의 성공률은 공식 측정이 없다. “stale-line 0%“라는 표현은 자체 측정·마케팅 카피이며 외부 검증이 아직 없다는 점을 분명히 짚는다.

그럼에도 가치가 있는 이유

이 한계를 고려해도 Hash-Anchored Edit은 멀티 에이전트 환경에서 의미가 크다. 멀티 에이전트가 동시에 같은 파일을 만지는 상황에서 stale-line 오류는 일상이다. 한 에이전트가 라인 50을 수정하는 사이 다른 에이전트가 라인 30을 지웠다면, 첫 에이전트의 패치가 잘못된 위치에 박힐 수 있다. Hash-Anchored Edit은 이 케이스를 mismatch로 만들어 reject한다. Grok 벤치 외에 정량 수치는 없지만, “동시 편집이 많을수록 효과가 크다”는 정성적 근거는 충분하다.

6. 한 달 써보니 한계는 뭐였나?

여기서부터가 실사용 리뷰의 본론이다. OmO를 한 달 굴리며 마주한 한계를 6개로 정리했다.

한계 1: $438 무한루프 빌링 사고 (issue #2571)

가장 큰 사고는 2026-03-14 보고된 issue #2571이다 (출처: GitHub issue #2571).

PR #2590/#2575로 Closed 처리됐지만, 멀티 에이전트 자동화에서 max-step 가드를 어떻게 설계해야 하는지를 보여주는 교과서적 사고다. OmO를 운영에 쓰려면 자체 alert/limit 가드를 외부에서 한 겹 더 걸 것을 권장한다.

한계 2: OpenCode 1.4.0 호환성 (issue #3220)

2026-04-08 보고된 issue #3220은 OpenCode 1.4.0 업그레이드 시 모든 OmO 에이전트가 사라지는 증상이었다. Closed로 마감됐지만, OpenCode 본가의 마이너 버전이 OmO를 끌고 가는 의존 구조를 그대로 보여준다. OmO를 쓰려면 OpenCode 버전 핀닝이 사실상 필수다.

한계 3: TUI 프리즈 (issue #3143, Open 미해결)

2026-04-05 보고된 issue #3143은 v3.15.2 TUI 프리즈 및 blank screen 이슈로 2026-04-30 시점에도 Open 상태다. 워크어라운드는 v3.14.0 다운그레이드뿐이다. 안정성 측면에서 한국 프로덕션 도입을 늦춰야 하는 가장 직접적 근거가 된다.

한계 4: Glukhov 측정 — 토큰 3배, pass rate 더 낮음

H2-3에서 다룬 Glukhov 비교를 다시 짚는다. 단일 문서 마이그레이션에서 OmO는 순정 OpenCode 대비 요청 3.5배·토큰 3배·pass rate 3.9pp 낮음을 기록했다. 이건 “어떤 작업이든 OmO가 좋다”는 가정에 대한 명확한 반증이다.

한계 5: OpenCode TUI 자체의 메모리 압박

OmO만의 문제는 아니지만, OpenCode TUI는 1GB+ RAM을 자주 점유한다. Hacker News 사용자 보고에 따르면 7$/year급 VPS에서는 OOM이 자주 발생한다. 개발자 PC에서는 문제가 적지만 셀프호스팅·CI 환경에서는 무거운 편이다.

한계 6: 에이전트 간 status 신호 부재

issue #1980은 Hephaestus와 Atlas 간 작업 상태 신호 부재를 지적한다. 두 에이전트가 동시에 같은 파일을 만질 때 서로의 진행 상황을 알지 못해 충돌이 잦다. Hash-Anchored Edit이 일부를 막아주지만 워크플로 단위 락이나 상태 broker는 아직 빈자리다.

7. 라이선스·텔레메트리·비용은 어떻게 봐야 하나?

OmO를 회사에서 쓰려면 라이선스와 텔레메트리를 반드시 확인해야 한다. 한국어 2차 자료에 잘못된 정보가 적지 않으니 정정한다.

라이선스 정정: MIT가 아니라 SUL-1.0이다

PyTorchKR·일부 한국어 블로그가 OmO를 “MIT 라이선스”로 표기하지만 이는 oh-my-opencode 시기의 오래된 정보다. 2026-04-30 기준 GitHub 라이선스는 SUL-1.0(Sustainable Use License)이다 (출처: LICENSE.md).

SUL-1.0 핵심 조항을 풀어 쓰면 이렇다.

• 사용 범위: 내부 비즈니스/비상업/개인 용도만 허용
• 재배포: 비상업·무료 형태로만 가능
• 라이선스 고지: 변경·삭제 금지
• 위반 시 자동 종료: 30일 시정 기간 후 라이선스 자동 종료

회사에서 “OmO를 SaaS 제품에 통합해서 유료로 판매”하는 형태는 명백히 제한된다. 사내 개발 도구로 쓰는 것은 일반적으로 허용 범위에 들어가지만, 법무 검토는 필수다.

텔레메트리: 기본 ON, 옵트아웃 가능

OmO는 PostHog 기반 텔레메트리를 기본 활성화한다. hashed installation identifier 기준으로 익명 집계되며, 수집 대상은 다음과 같다 (출처: privacy-policy.md).

• 수집: run_started/completed/failed, install_*, plugin_loaded, omo_daily_active, 패키지 버전·런타임 메타
• 비수집: 프롬프트 본문, 소스 파일, 리포 콘텐츠, 액세스 토큰, API 키, raw hostname

옵트아웃은 환경 변수 한 줄이면 된다.

export OMO_SEND_ANONYMOUS_TELEMETRY=0
# 또는 PostHog 자체를 비활성
export OMO_DISABLE_POSTHOG=1

회사 정책상 텔레메트리 자체를 차단해야 한다면 .bashrc/.zshrc에 위 라인을 추가하거나 CI 환경 변수에 넣어 둔다. 토큰 사용량을 모니터링하고 싶다면 Claude Code 토큰 71배 줄이는 법 — Graphify 실전 구축 2026에서 다룬 토큰 측정 패턴을 함께 도입하면 도움이 된다.

비용: “묶음 가격”의 실제 운영 비용

권장 묶음 $49~$59는 구독료 합계일 뿐이다. 실제 토큰 비용은 별도다. 정정일(jeongil.dev) 비평이 이 부분을 직격한다.

“API 전환 시 30분 만에 $15~20을 태운다. 한 달 $3,650 이상 나온 사례도 있다.”

(출처: 정정일 jeongil.dev)

즉, 구독료보다 토큰 비용이 압도적으로 크다. 운영에 도입하려면 일·주 단위 토큰 한도와 max-step 가드를 반드시 외부에서 걸어둘 것을 권장한다. issue #2571 사고는 max-step 가드 하나만 있었어도 막을 수 있었다.

8. 한국 커뮤니티는 어떻게 평가하나?

OmO는 한국 메인테이너 프로젝트답게 한국 커뮤니티 반응이 빠르고 다양하다. 호평·비판이 모두 있어 균형 있게 인용한다.

호평 포인트: “병렬 실행과 한국어 친화”

@takealittletime velog 글이 대표적이다. “각 에이전트가 병렬적으로 작업을 백그라운드에서 실행한다는 점이 매력적”이라는 평가는 OmO의 차별점을 잘 짚는다 (출처: @takealittletime velog). 한국어 README, 한국어 Threads 게시글, PyTorchKR 한국어 토론(2026-01-05) 같은 한국어 자원이 풍부한 것도 입문자 친화적이다 (출처: PyTorchKR).

비판 포인트 1: 컨텍스트·세션 관리

@ziczin7176 velog 글(2026-01-09)은 페인포인트를 명료하게 지적한다. “구현 중간에 자꾸 삼천포로 샌다”, “본인의 널널한 기준으로 테스트한다”, “새로운 세션에서 컨텍스트를 까먹는다.” 멀티 에이전트 환경에서 세션 간 컨텍스트 전이가 약한 부분은 OmO의 구조적 한계다.

비판 포인트 2: 업데이트 편차와 협업 환경

@nomadjun195 Threads 글(2026-01-29)은 세 가지 비판을 제시했다 (출처: @nomadjun195 Threads).

1. 업데이트 때마다 인증 이슈가 반복된다.
2. OpenCode는 결국 어느 LLM을 쓰더라도 우회 성격을 띤다. 큰 기업 협업에서 무료 모델 사용은 ToS·보안상 어렵다.
3. 업데이트마다 성능 편차가 크다.

비판 포인트 3: 정정일의 균형 비평

정정일(jeongil.dev) 글은 한국어 분석 중 가장 구조적이다. “한 달 $3,650 이상 나온 사례”, “API 전환 시 30분 만에 $15~20 태운다”는 비용 경고와, “지금 당장은 Agent Teams로 시작하는 걸 추천. 공식 기능이라 밴 리스크가 없다”는 결론은 한국 프로덕션 사용자에게 가장 현실적인 가이드라인이다 (출처: jeongil.dev).

9. 지금 도입할 만한가, 좀 더 기다려야 하나?

여기까지의 데이터를 페르소나별 결정 매트릭스로 정리한다.

페르소나별 결정 매트릭스

이런 분에게 추천한다

• 사이드 프로젝트로 대규모 리팩터링이 잡혀 있는 개발자: ulw 사례가 정확히 이 작업에 맞춰져 있다.
• 멀티모델·하네스 학습형 시니어: 12+ 에이전트 4그룹 구조 자체가 좋은 학습 자료다.
• OpenCode를 이미 쓰는 사용자: 진입 장벽이 거의 없고, 한 달 시도 후 ulw만 골라 써도 가치가 있다.

반대로 다음에 해당하면 한 분기 더 지켜본다.

• 한국 프로덕션 백엔드/금융: SUL-1.0, TUI 프리즈, max-step 가드 부재 모두 운영 리스크다.
• Claude Max로 작업이 안정적인 헤비유저: 비용 절감 동기가 약하고, ToS 리스크만 새로 짊어진다.
• GPT-5.5의 코딩 모드를 이미 잘 쓰는 사용자: 단일 모델 흐름이 더 단순하다. 비교 자료는 GPT-5.5 총정리: 성능·벤치마크·가격·반응 (2026)에서 다뤘다.

결론