Oh My OpenCode 3주간의 진화: v3.0에서 v3.5까지 완전 정리
안녕하세요, Tom입니다.
저는 1월 25일부터 Oh My OpenCode(OMO)의 릴리스를 계속 추적해왔어요. v3.0.0부터 v3.5.0까지, 약 3주 동안 6번의 릴리스를 지켜봤습니다. 개별 릴리스 노트는 이미 올렸지만, 오늘은 한 발 물러서서 "3주 동안 OMO가 어떤 방향으로 진화했는가"를 분석해보려고 해요.
결론부터 말하면, OMO는 3주 만에 "멀티 에이전트 프레임워크"에서 "자기 검증하는 AI 오케스트레이션 플랫폼"으로 탈바꿈했어요.
한눈에 보는 릴리스 타임라인
| 날짜 | 버전 | 핵심 테마 | 규모 |
|---|---|---|---|
| 1/25 | v3.0.0 | 오케스트레이션 혁명 | 🔴 Major |
| 1/28 | v3.1.4 | 안정성 개선 | 🟢 Patch |
| 1/29 | v3.1.7 | OAuth 2.1 + LSP 마이그레이션 | 🟡 Minor |
| 2/03 | v3.2.2 | GPT-5.2 프롬프트 최적화 | 🟡 Minor |
| 2/05 | v3.2.3 | 웹서치 멀티 프로바이더 | 🟢 Patch |
| 2/12 | v3.5.0 | Atlas Trusts No One + 645파일 리팩토링 | 🔴 Major |
💡 3주 동안 6번 릴리스. 평균 3.5일에 한 번꼴이에요. 이 속도 자체가 프로젝트의 활발함을 보여줍니다.
테마 1: 오케스트레이션 혁명 — "에이전트의 에이전트"
v3.0.0은 OMO의 정체성을 완전히 바꾼 릴리스예요.
이전까지 OMO는 "Frontend UI/UX Engineer", "Git Master" 같은 하드코딩된 에이전트를 사용했어요. v3.0에서 이걸 완전히 뒤엎었습니다.
Categories + Skills = 동적 에이전트 조합
Categories (모델 추상화) Skills (전문 지식)
├── quick ├── frontend-ui-ux
├── visual-engineering ├── git-master
├── ultrabrain ├── playwright
└── deep └── dev-browser
visual-engineering + frontend-ui-ux = 프론트엔드 전문가
quick + git-master = 빠른 Git 작업 에이전트
🎯 왜 이게 혁신적인가: 고정된 에이전트 목록 대신, Sisyphus(메인 에이전트)가 작업에 맞는 최적의 조합을 동적으로 결정해요. N개의 카테고리 × M개의 스킬 = N×M개의 가능한 에이전트 조합이 생기는 거죠.
Prometheus + Atlas: 계획하고 실행하는 시스템
v3.0은 두 가지 핵심 에이전트도 추가했어요:
| 에이전트 | 역할 | 비유 |
|---|---|---|
| Prometheus | 사용자와 인터뷰 → 요구사항 파악 → 작업 계획 작성 | 전략 참모 |
| Atlas | 계획을 받아서 최적의 에이전트 배치 → 작업 분배 → 결과 검증 | 현장 사령관 |
🤔 제 해석: 이건 "AI 에이전트가 AI 에이전트를 관리하는" 구조예요. 개발자가 에이전트를 일일이 선택하지 않아도, Prometheus가 요구사항을 파악하고 Atlas가 최적의 팀을 꾸려서 작업을 완수합니다.
테마 2: 보안과 표준화 — "제대로 하자"
v3.1.7에서 MCP 서버를 위한 OAuth 2.1 인증이 완전 구현됐어요.
RFC 표준 4종 지원
| RFC | 설명 |
|---|---|
| RFC 7591 | Dynamic Client Registration |
| RFC 9728 | Protected Resource Metadata |
| RFC 8414 | Authorization Server Discovery |
| RFC 8707 | Resource Indicators |
# OAuth 로그인이 이렇게 간단해졌어요
opencode mcp oauth login --server my-mcp-server
opencode mcp oauth status💡 이전에는 MCP 서버 인증 설정이 복잡했는데, 이제 CLI 한 줄이면 끝이에요. 특히 팀에서 여러 MCP 서버를 쓸 때 설정 부담이 크게 줄었습니다.
같은 릴리스에서 LSP 클라이언트도 vscode-jsonrpc로 마이그레이션됐어요. Microsoft의 검증된 라이브러리로 바꾸면서 커스텀 코드를 줄이고 안정성을 높인 거죠.
테마 3: 지능과 최적화 — "더 똑똑하게, 더 효율적으로"
v3.2.2에서 GPT-5.2에 최적화된 프롬프트가 도입됐어요.
모델 기반 프롬프트 라우팅
단순히 "GPT-5.2를 쓴다"가 아니라, 작업 유형에 따라 모델과 프롬프트 스타일을 자동으로 매칭하는 시스템이에요.
| 에이전트 | 모델 | 프롬프트 스타일 |
|---|---|---|
| Atlas | GPT-5.2 | 오케스트레이션 중심 (XML 구조) |
| Sisyphus-Junior | GPT-5.2 | 작업 실행 중심 |
| Oracle | GPT-5.2 | 분석/조언 중심 |
💰 비용 최적화 포인트: GPT-5.2는 성능이 좋지만 비용도 높아요. OMO는 복잡한 작업에만 GPT-5.2를 쓰고, 단순 작업은 더 저렴한 모델로 라우팅합니다. 결과적으로 복잡한 작업의 품질은 올라가면서 전체 비용은 최적화되는 구조예요.
테마 4: 개발자 경험 — "쓰기 편하게"
여러 릴리스에 걸쳐 DX(Developer Experience)가 꾸준히 개선됐어요.
v3.1.4: 문제를 빨리 알려주기
- Provider Cache 누락 시 토스트 알림 표시 (이전엔 조용히 실패)
- npm 글로벌 설치 환경에서 버전 감지 버그 수정
v3.2.3: 선택의 자유
- 웹서치 프로바이더 선택 — Exa와 Tavily 중 택1
- Exa: 기술 문서, 코드 예제에 강함
- Tavily: 최신 뉴스, 실시간 정보에 강함
- 중첩 스킬 디렉토리 — 50개 스킬 파일을 폴더로 정리 가능
- 스킬 비활성화 — 안 쓰는 스킬을 꺼서 토큰 절약
{
"websearchProvider": "tavily",
"disabledSkills": ["playwright", "dev-browser"]
}🎯 제가 체감한 차이: 웹서치 프로바이더를 고를 수 있게 된 게 생각보다 큰 변화예요. 뉴스 수집할 때는 Tavily, 코드 문서 찾을 때는 Exa를 쓰면 검색 품질이 확 달라집니다.
LSP 진단 정확도 향상
v3.2.3에서 didChange 이벤트를 먼저 보낸 후 진단을 받아오도록 수정됐어요. 이전에는 파일 수정 후 바로 진단 요청하면 오래된 결과가 나왔는데, 이제는 항상 최신 상태를 확인할 수 있습니다.
테마 5: 신뢰와 검증 — "Atlas Trusts No One"
v3.5.0의 코드네임이 "Atlas Trusts No One"인데, 이름부터 강렬하죠.
문제: "다 했어요" 거짓말
이전까지 Atlas는 서브에이전트가 "done"이라고 하면 그냥 넘어갔어요. 테스트 실패, 코드 반만 완성, 요구사항 누락 — 다 무시. "Done"이면 된 거였죠.
해결: 강제 검증
이제는 달라요:
- 서브에이전트가 수정한 모든 파일을 직접 Read해야 함
- 주장과 현실을 크로스체크
- import, 로직, 엣지케이스 검증 — 안 하면 진행 불가
- "러버스탬핑 금지"
⚠️ 이게 왜 중요한가: AI 에이전트가 "완료"라고 했는데 실제로는 절반만 된 경험, 다들 있으시죠? OMO는 이 문제를 오케스트레이터 레벨에서 강제로 해결한 거예요. "Trust but verify"를 시스템에 내장한 겁니다.
Boulder Continuation 수정
"유령 continuation" 문제도 해결됐어요. 이전에는 boulder의 일부가 아닌 세션에도 continuation 프롬프트가 주입되는 버그가 있었는데, session_ids 목록을 먼저 확인하고 2번 실패하면 중단하도록 수정됐습니다.
테마 6: 코드 품질 — "645파일 대리팩토링"
v3.5.0에서 가장 인상적인 부분이에요. 25개 이상의 god-file을 분해하고 200줄 하드 리밋을 적용했습니다.
| 모듈 | Before | After |
|---|---|---|
src/index.ts | 1,004줄 | 88줄 + 4개 파일 |
delegate-task/executor.ts | 998줄 | 16줄 + 15개 모듈 |
background-agent/manager.ts | 1,646줄 | 코어 + 20개 모듈 |
hooks/atlas/index.ts | 700줄 | 25줄 + 15개 모듈 |
tools/lsp/client.ts | 854줄 | 129줄 + 12개 모듈 |
config/schema.ts | 483줄 | 21개 스키마 컴포넌트 |
핵심 통계
- 645개 파일 변경
- +34,507줄 추가 / -21,492줄 삭제
- 브레이킹 체인지: 0개
💡 공개 API는 하나도 안 바뀌었어요. 645개 파일을 고치면서 외부 인터페이스를 유지한 건 대단한 리팩토링이에요. utils.ts 같은 모호한 이름도 result-formatter.ts, session-formatter.ts, tmux-path-resolver.ts 같은 명확한 이름으로 바뀌었습니다.
3주간의 진화가 말해주는 것
이 6번의 릴리스를 쭉 보면, OMO 팀이 추구하는 방향이 명확해요:
1. "더 많은 에이전트"가 아니라 "더 똑똑한 오케스트레이션"
v3.0의 Categories+Skills는 에이전트 수를 늘리는 게 아니라, 조합의 자유도를 높이는 접근이에요. 에이전트 10개를 만드는 대신, 4개 카테고리 × 4개 스킬 = 16가지 조합을 만들어내는 거죠.
2. "빠른 실행"보다 "정확한 실행"
Atlas Trusts No One은 철학적 전환이에요. 빠르게 결과를 내는 것보다 정확하게 검증된 결과를 내는 걸 우선시하겠다는 거죠. 속도는 좀 느려질 수 있지만, 신뢰도는 올라갑니다.
3. 표준을 따르되, 실용적으로
OAuth 2.1 RFC 4종 지원, vscode-jsonrpc 마이그레이션 — 바퀴를 다시 발명하지 않고 검증된 표준과 라이브러리를 채택하는 실용적 접근이에요.
누가 주목해야 하나?
🎯 AI 에이전트 개발에 관심 있는 개발자 — OMO의 Categories+Skills 패턴은 멀티 에이전트 시스템 설계의 좋은 참고 사례예요
🎯 Claude Code / OpenCode 사용자 — OMO는 OpenCode 위에서 동작하는 오케스트레이션 레이어예요. AI 코딩 도구를 더 강력하게 쓰고 싶다면 주목
🎯 오픈소스 프로젝트 리더 — 645파일 리팩토링을 브레이킹 체인지 없이 해낸 과정은 대규모 리팩토링의 교과서적 사례
총평
Oh My OpenCode는 3주 만에 "멀티 에이전트 도구"에서 "자기 검증하는 오케스트레이션 플랫폼"으로 진화했어요. v3.0의 동적 에이전트 조합이 "무엇을"을 바꿨다면, v3.5.0의 Atlas Trusts No One은 "어떻게"를 바꿨습니다.
개인적으로 가장 인상 깊은 건 645파일 리팩토링을 브레이킹 체인지 없이 해낸 것과 서브에이전트 검증을 시스템에 강제한 것이에요. 전자는 엔지니어링 역량을, 후자는 설계 철학을 보여줍니다.
앞으로 OMO가 어떤 방향으로 갈지 궁금해지네요. 계속 추적하면서 업데이트해드릴게요!
관련 포스트: