오픈코드 리뷰: 솔직한 결과, 청구 리스크, 그리고 투자할 가치가 있는 경우

Ultrawork 를 실행할 때 실제로 어떤 일이 일어나는지 알아봅니다.

Page content

Oh My Opencode 는 “가상의 AI 개발 팀"을 약속합니다. Sisyphus 가 전문가들을 지휘하고, 작업이 병렬로 실행되며, 마법 같은 ultrawork 키워드가 모든 것을 활성화합니다.

이 약속은 적절한 워크로드에서는 성립합니다. 하지만 잘못된 워크로드에서는 결과를 개선하지 않으면서 비용과 복잡성만 추가합니다. 이 글에서는 실제 수기 테스트에서 발생한 일과, 실제 사용 몇 달 후 커뮤니티가 발견한 내용을 다룹니다.

lazy agents working in parallel

스택에 처음 접하셨다면 다음 순서를 따르세요.

이 글은 이미 시스템에 익숙하고 실제로 성능이 발휘되는지 알고 싶어 하는 독자를 전제로 합니다. OMO 가 AI 코딩 툴체인에서 어떻게 위치하는지에 대한 더 넓은 그림은 AI 개발자 도구 개요 를 참조하세요.

Oh My Opencode 성능: 수기 테스트 결과

저는 순수 OpenCode 를 테스트할 때 사용하는 동일한 테스트를 실행했습니다. 이는 OpenCode 와 로컬 Ollama, llama.cpp 모델을 비교한 LLM 벤치마크 작업 과 동일합니다. 이번에는 Big Pickle 모델 (OpenCode Zen 을 통한 GLM 4.6 — 무료 티어) 에서 실행했습니다.

요약하자면: 결과는 엇갈렸고, 실패 모드는 많은 교훈을 제공했습니다.

명시적인 Ultrawork 프롬프트가 없을 때 Sisyphus 가 위임을 생략하는 이유

제가 처음 겪은 문제는 Sisyphus 가 명시적인 프롬프팅 없이는 오케스트레이터처럼 행동하지 않았다는 점입니다. ulw 접두사조차 있더라도, 그는 모든 작업을 직접 수행하기 시작했습니다. 파일을 직접 읽거나 코드를 작성하고, 연구 및 계획 단계를 완전히 생략했습니다. Oracle 로의 위임도, 병렬 Explore 실행도, Prometheus 인터뷰도 없었습니다.

실제로 오케스트레이션을 트리거하려면 프롬프트가 명확해야 했습니다:

ulw 먼저 코드베이스를 연구하고,
상세한 계획을 수립하며,
구현 작업을 위임하고,
위임이 비합리적일 때만 직접 작업 수행

이렇게 한 후 시스템은 광고대로 작동했습니다. 하지만 그 프레임을 제거한 기본 동작은 더 무거운 컨텍스트 윈도우를 가진 바닐라 OpenCode 와无异했습니다. ultrawork 키워드만으로는 위임을 보장하지 않습니다. 그것은 위임을 위한 전제 조건일 뿐입니다.

테스트 1: IndexNow CLI 도구 — Oh My Opencode 오케스트레이션이 빛을 발하는 곳

작업은 검색 엔진 색인을 위해 IndexNow API 에 URL 을 제출하는 명령줄 도구를 구축하는 것이었습니다. 이는 API 스펙 읽기, CLI 설계, 구현, 테스트 등 합리적인 범위의 다단계 작업입니다.

Oh My Opencode 과 명시적인 오케스트레이션 프롬프팅을 사용하면, 결과는 순수 OpenCode 보다 현저히 좋아졌습니다. 최종 도구는 sitemap.xml 에서 URL 을 올바르게 추출하고 일괄 전송했으며, 표준 CLI 옵션도 지원했습니다. Librarian 에이전트가 IndexNow 문서를 가져오며, 순수 모델 실행에서 놓쳤던 컨텍스트를 제공했습니다.

oh my opencode indexnow session log

이것이 OMO 가 구축된 목적의 작업입니다: 연구 + 구현 + 일부 설계 결정. 여기서 오버헤드는 그 대가를 치렀습니다.

테스트 2: 페이지 마이그레이션 매핑 — 동일한 결과, 3 배의 토큰

두 번째 테스트는 문서 분석 작업이었습니다: 슬러그와 마이그레이션 정책 문서를 기반으로 웹사이트 페이지가 어디로 마이그레이션되어야 하는지 정리하는 작업입니다.

결과는 순수 OpenCode 실행과 완전히 동일했습니다. 정확도, 구조, 결정 모두 같았습니다. 하지만 OMO 실행은 약 3 배의 토큰을 소비했습니다.

이는 단일 컨텍스트 윈도우 추론 작업입니다. 활용 가능한 병렬성도 없고, 서브에이전트에서 가져올 전문 지식도 없습니다. 오케스트레이션 레이어는 가치를 더하지 않고 오버헤드만 추가했습니다. 이 유형의 작업에서는 바닐라 OpenCode 가 더 나은 선택입니다.

모델 선택: 왜 약한 모델이 오케스트레이션 오버헤드에 더 취약한가

Big Pickle(무료 티어 모델) 에서 실행해 보니, 커뮤니티도 주목한 것이 드러났습니다: 약한 모델은 강력한 모델보다 하네스 품질에 더 민감합니다. Claude Opus 는 무거운 오케스트레이션 레이어가 있어도 좋은 출력을 생성할 만큼 탄력적입니다. Big Pickle 과 같은 작은 모델은 복잡한 다에이전트 설정에서 컨텍스트에 노이즈를 추가하는 것보다 깨끗하고 집중된 프롬프트에서 더 큰 이점을 얻습니다.

예산 모델을 OMO 로 실행한다면 더 단순하게 시작하세요. Librarian 과 Explore 가 실제로 정보를 추가하는 연구 중심 작업에 오케스트레이션을 사용하세요. 모델이 명확한 입력과 사고 공간을 필요로 하는 순수 추론 작업에서는 오케스트레이션을 피하세요.

Oh My Opencode 커뮤니티 발견: 벤치마크, 청구 및 현실적 주의사항

모든 것을 믿고 투자하기 전에, 실제 사용을 통해 커뮤니티가 발견한 것, 즉 성공 사례와 실패 모드를 알고 있어야 합니다.

Oh My Opencode 벤치마크: 69% 대 73% 통과율, 바닐라 OpenCode 보다 3 배 많은 요청

커뮤니티 멤버 중 한 명이 120 개 이상의 에이전트/모델 조합에 대해 체계적인 벤치마크를 수행하고 결과를 발표했습니다. OMO Ultrawork 가 활성화된 상태에서 코딩 평가의 통과율은 **69.2%**였으며, OMO 가 없는 순수 OpenCode 는 **73.1%**였습니다. OMO 실행은 10 분 더 오래 걸렸고 (55 분 대 45 분), 요청 수는 27 회가 아닌 96 회였습니다.

그들의 결론은 이렇습니다: “이는 단순히 단계가 더 많은 Opus 일 뿐이다.” Opus 는 하네스 차이에 특히 탄력적이며, 주변 환경과 상관없이 강력한 결과를 제공합니다. 약한 모델은 하네스에 더 민감했으나, 그것이 반드시 OMO 에 유리한 것은 아니었습니다.

이는 OMO 가 쓸모 없다는 것을 의미하지는 않습니다. 대형 다파일 작업, 병렬 배경 에이전트, 복잡한 엔지니어링 워크플로우의 경우 오버헤드는 그 대가를 치릅니다. 하지만 단일 컨텍스트 윈도우에 맞는 코딩 작업에서는 좋은 모델이 달린 바닐라 OpenCode 가 종종 전체 오케스트레이션 스택과 맞거나 더 나은 결과를 냅니다.

시작 토큰 오버헤드: 실제 작업 시작 전 15,000~25,000 토큰

커뮤니티의 반복되는 불만은 OMO 가 시작 시 많은 도구와 MCP 를 주입한다는 점입니다. 단순한 “Hello world” 메시지만으로도 실제 작업이 시작되기 전 컨텍스트 윈도우 설정만으로 15,000~25,000 토큰이 소비될 수 있습니다. 유지보수자는 이를 인지하고 지연 도구 로딩을 작업 중이지만, 2026 년 초 기준 가격 추정치에 반영해야 할 실질적인 비용입니다.

350 달러의 Gemini 무한 루프 — 그리고 대응 방안

2026 년 3 월, 확인된 버그 (이슈 #2571, will-fix 라벨) 로 인해 한 사용자가 오후 한 시간 동안 약 438 달러의 청구금을 받았습니다. 세 가지 문제가 복합적으로 작용했습니다:

  1. 회로 차단기 부재: OMO 는 서브에이전트당 최대 단계 제한이 없었습니다. Gemini 모델이 git diff / read 검증 루프에 걸려 3.5 시간 동안 809 회 연속 턴을 멈추지 않고 실행했습니다.

  2. 침묵의 모델 라우팅: 사용자의 부모 세션은 GPT-5.4 에 있었습니다. 하지만 위임된 Compose UI 작업은 범주 라우팅 (visual-engineering) 을 통해 Gemini 3.1 Pro 로 라우팅되었습니다. 이는 사용자가 의도적으로 선택하지 않았고, 사후 SQLite 데이터베이스를 파헤치기 전까지는 전혀 알 수 없었던 모델이었습니다.

  3. 잘못된 비용 표시: OpenCode 의 gemini-3.1-pro-preview 가격 스냅샷에는 >200K 컨텍스트 가격 티어가 누락되었습니다. Google 은 20 만 토큰 이상의 컨텍스트에 대해 2 배 요금을 부과하지만, OpenCode 는 기본 요금으로 모든 것을 계산했습니다. 표시된 비용은 실제 Google 청구금의 절반도 못 미쳤습니다.

한 커뮤니티 멤버의 댓글이 이를 요약했습니다: “Gemini 는 저에게 끊임없이 루프에 걸리므로, 비읽기 전용 모델로는 거의 사용하지 않습니다.”

수정 (PR #2590) 이 진행 중입니다 — 구성 가능한 최대 단계 제한 및 루프 감지 기능이 추가됩니다. 출시될 때까지 자신을 보호하세요:

  • 범주 설정을 감사하세요. 어떤 범주가 Gemini 로 매핑되어 있다면 (기본적으로 visual-engineering 포함), 해당 범주의 모든 배경 작업은 Gemini 를 사용하며 — 사용자가 다른 모델을 사용하는 전경 세션에서도 — 침묵으로 이루어집니다.
  • background_task 에서 Gemini 에 대해 명시적인 providerConcurrency 한도를 설정하세요. 이를 1 로 유지하면 폭발 반경을 제한할 수 있습니다.
  • OpenCode 가 표시한 비용뿐만 아니라 실제 제공자 청구 대시보드를 확인하세요. 특히 Gemini 에 대해서는 더욱 중요합니다.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // 회로 차단기가 출시될 때까지의 하드 캡
    }
  }
}

Ultrawork 위임은 키워드가 필요하며 자동적이지 않습니다

초기 사용자는 ultrawork 없이 실행하면 메인 에이전트가 전문 서브에이전트로 위임하는 대신 read 와 grep 을 직접 호출하기 시작한다는 것을 발견했습니다. 유지보수자는 이를 일찍 인정했습니다: “명시적인 프롬프트 없이 시스템 프롬프트 지침만으로 적절한 에이전트를 호출하는 것은 어렵게 보입니다.”

ultrawork 키워드는 오케스트레이션을 신뢰성 있게 트리거하는 요소입니다. 없으면 더 무거운 컨텍스트 윈도우를 가진 바닐라 OpenCode 를 실행하는 것과 같습니다. 이는 저의 테스트 결과와 일치합니다.

OMO 의 가벼운 대안: OMO Slim 및 Oh-My-Pi

배경 실행 후크와 OMO 의 핵심 개선을 원하지만 전체 에이전트 오케스트레이션 오버헤드 없이 사용하고 싶다면, 기능 세트를 줄인 커뮤니티 포크인 oh-my-opencode-slim 을 사용하세요. 일부 사용자는 oh-my-pi 로 이전했는데, 이는 배경 작업 실행과 후크에 집중하면서도 프롬프트 표면을 최소화합니다.

한 사용자는 이렇게 잘 표현했습니다: “저는 후크와 배경 작업 실행 때문에 OMO 를 좋아합니다. OMO slim 이 잘못된 것을 최적화하려고 한다고 생각합니다. 기본 OpenCode 프롬프트에 배경 워커와 에이전트가 스스로 멈출 때 모델을 계속하도록 자동 프롬프팅하는 후크만 있으면 충분할 것입니다.”

올바른 선택은 작업 프로파일에 따라 다릅니다. 대규모, 다단계 엔지니어링 작업은 전체 OMO 를 정당화합니다. 매일의 짧은 작업의 경우, 더 가벼운 하네스가 종종 비용이 적고 더 나은 결과를 제공합니다.

Oh My Opencode 가 실제로 뛰어날 때: 실제 사용자 결과

주의사항을 균형을 맞추기 위해, 사용자가 OMO 의 가장 명확한 성과로 보고한 내용은 다음과 같습니다:

  • 하루 만에 8,000 개의 ESLint 경고 제거 — 병렬 Explore 에이전트가 코드베이스를 스캔하는 동안 워커 에이전트가 동시에 수정을 실행
  • 45k 줄 Tauri 앱이 하룻밤 사이에 SaaS 웹 앱으로 변환 — Prometheus 인터뷰 모드가 상세한 계획을 수립하고, Ralph Loop 가 처음부터 끝까지 실행
  • 사용자가 초기 프롬프트 외에는 키보드에 손을 대지 않고 전단식 기능이 끝까지 구현
  • 상속된 코드베이스에 대한 아키텍처 검토 — Oracle 의 읽기 전용 자문 역할이 변경을 우연히 만들지 않고 문제를 드러냄

공통된 실마리: 병렬성이 도움이 되며 Prometheus 가 검증할 수 있는 명확한 수용 기준을 가진 작업입니다. 단일 집중된 모델이 잘 처리할 수 있는 작업은 오케스트레이션 오버헤드로부터 거의 이점을 얻지 못합니다.

Oh My Opencode vs 바닐라 OpenCode: 각각을 언제 사용할 것인가

Oh My Opencode 은 보편적으로 바닐라 OpenCode 보다 낫지 않습니다. 그것은 특정 유형의 작업에 대한 승수이자, 그 외 모든 것에 대한 오버헤드입니다.

다음과 같은 경우 전체 OMO 스택 (ultrawork 포함) 을 사용하세요:

  • 작업이 여러 파일과 레이어에 걸칠 때
  • 연구, 계획, 구현, 검증이 별도의 단계로 필요할 때
  • 배경 에이전트 (Explore, Librarian) 가 컨텍스트를 수집하는 동안 워커가 실행되는 병렬성에서 이점을 얻을 때
  • 범위가 충분히 커서 에이전트를 여러 순차적 프롬프트를 통해 돌봐야 할 때

다음과 같은 경우 바닐라 OpenCode (또는 더 가벼운 하네스) 를 사용하세요:

  • 작업이 단일 컨텍스트 윈도우에 맞을 때
  • 외부 연구가 없는 순수 추론 문제일 때
  • 예산 모델을 실행 중일 때 — 이들은 오케스트레이션 복잡성보다 깨끗하고 집중된 프롬프트에서 더 큰 이점을 얻습니다
  • 범주 라우팅의 예상치 못한 사고 없이 예측 가능한 청구를 원할 때

청구 위험은 실질적이며 보고되지 않았습니다. 회로 차단기가 도입될 때까지 Gemini 와 함께 OMO 를 사용할 때는 능동적인 모니터링이 필요하며 “발사하고 잊어버리는” 시스템으로 취급하지 마세요. 그 외 모든 것에서, 이 시스템은 올바른 문제를 겨냥할 때 정말 인상적입니다.

출처

이 글에서 참조된 커뮤니티 논의 및 이슈: