클로드는 긴 지시문과 다단계 흐름 처리에 강하고, GPT 계열은 깊은 추론 기반 문제 해결에 능합니다. 제미나이 계열은 UI/UX와 프론트엔드 작업에서 장점을 보이죠. 이렇게 AI는 모델마다 잘하는 게 다릅니다.

문제는 모델 수가 늘수록 어떤 작업에 어떤 모델을 쓸지 매번 판단해야 하고, 전환할 때마다 컨텍스트를 다시 세팅해야 한다는 점입니다. 이 전환 비용이 쌓이면 모델이 많다는 게 오히려 부담이 됩니다.

기존 단일 에이전트 방식도 마찬가지입니다. 하나의 AI가 조사부터 설계, 구현, 검증까지 전부 맡게 되는데, 작업이 작을 때는 괜찮지만 규모가 커지면 방향이 중간에 바뀌거나 검증이 부실해지는 일이 반복되기도 합니다.

💡 "모델이 부족한 게 아니라, 모델을 운영하는 구조가 없는 게 문제다."

OMO는 원래 Oh-my-opencode라는 이름으로 시작했고, 현재는 Oh-my-openagent로 리네이밍되었습니다. 하나의 환경 안에서 작업 성격에 따라 AI 모델과 에이전트가 자동 배정되는 오픈소스 플러그인입니다. 플래닝·익스큐션·워커 레이어로 역할을 분리한 구조가 핵심입니다.

OMO 안에는 역할이 서로 다른 네 가지 에이전트가 있습니다.

💡 "설계 담당은 구현을 걱정하지 않고, 구현 담당은 방향을 다시 고민하지 않는다. 그게 역할 분리의 효과다."

OMO는 특정 에이전트를 직접 호출하는 방식이 아닙니다. 작업 방식 자체를 설정하는 명령어를 씁니다. Ultra Work는 AI가 처음부터 끝까지 자동으로 완료할 때, Plan은 실행 전 설계와 범위 정의가 필요할 때, /start-work는 플랜을 실행으로 전환할 때, /init-deep은 프로젝트 구조를 분석하고 계층적 컨텍스트를 생성할 때 사용합니다.

모델 설정도 유연합니다. 에이전트마다 어떤 모델을 붙일지 직접 지정할 수 있어서, 추론이 필요한 역할에는 GPT 계열을, 빠른 탐색에는 경량 모델을 배치하는 식으로 성능과 비용 균형을 조절합니다.

기존 자산 재활용도 됩니다. 클로드에서 쓰던 스킬 에이전트를 OMO 안에서 그대로 쓸 수 있고, 새 서브 에이전트를 MD 파일로 정의해 추가하면 바로 통합됩니다.

💡 "세션이 끊겨도 플랜, 홀더.json, 노트패드가 상태를 저장한다. 긴 작업에서 맥락을 잃지 않는 이유다."

모든 작업에 OMO를 쓸 필요는 없습니다. 간단한 수정이나 워크플로우가 이미 잡힌 작업에는 클로드 코드 같은 단일 에이전트가 더 빠릅니다. 스킬이 잘 세팅되어 있다면 그걸 그대로 쓰는 게 맞습니다.

반면 대규모 리팩토링이나 아키텍처 변경, 여러 단계를 거쳐야 하는 복합 작업 계획에서는 역할이 분리된 멀티 에이전트 구조가 맞습니다. OMO 외에도 OMX, OMC 같은 유사 플러그인이 있고, 기본 작동 원리는 공통됩니다.

💡 "도구를 하나만 고집하는 게 아니라, 작업 성격에 맞게 구조를 고르는 판단이 더 중요하다."