CLI 환경에서 AI를 활용해 작업해 본 경험이 있으신가요?
저는 지금까지 ChatGPT나 Claude와 같은 웹 환경의 AI를 주로 사용해 왔습니다. 하지만 최근에는 터미널에서 직접 프로젝트를 분석하고 수정하는 Codex CLI와 같은 도구들이 등장하면서 개발 생산성이 크게 향상되고 있습니다.
그러던 중 여러 AI를 동시에 활용해 개발할 수 있도록 도와주는 Oh My Codex(OMX) 라는 오픈소스 프로젝트를 알게 되었고, 실제로 어떤 구조로 동작하는지 분석해보게 되었습니다.
Oh My Codex란?
`Oh My Codex (OMX)`는 한국인 개발자 "허예찬"님이 주도하여 만든 OpenAI Codex 기반 작업 환경 확장 도구입니다.
Codex CLI의 기능을 대체하는 것이 아니라 Codex 위에 추가적인 기능을 제공하는 레이어 역할을 제공합니다.
기존에는 단순히 AI에게 명령을 전달하는 수준이었다면, 보다 정교한 프롬프트와 재사용 가능한 역할, 다양한 스킬을 제공하여 AI가 효율적으로 움직일 수 있게 보조합니다.
OMX 등장 배경
Codex CLI, Claude Code등 강력한 AI기반 개발 도구가 등장했지만, 프로젝트 규모가 커짐에 따라 명확한 한계를 보입니다.
1. 요구사항 분석과 계획 수립 과정의 부재
대부분의 AI 코딩 도구는 요청 입력 즉시 구현에 들어가는 경우가 많습니다. 이는 복잡한 프로젝트에서 요구사항이 명확히 정의되지 않고, 설계가 충분히 이루어지지 않은 상태에서 개발이 진행되어 수정 비용이 커질 수 있습니다.
2. 컨텍스트 관리의 어려움
대규모의 프로젝트에서는 이전에 어떤 결정을 내렸는지, 현재 어떤 작업이 진행 중인지, 앞으로 어떤 작업이 남아 있는지 지속적으로 관리해야 합니다. 하지만 일반적인 AI 도구는 세션이 바뀌거나 대화가 길어질수록 이러한 정보를 효과적으로 유지하기 어렵습니다.
3. 작업 병렬화의 한계
실제 개발에서는 기능 구현, 테스트 작성, 문서화, 코드 리뷰 등 다양한 작업이 동시에 진행됩니다. 그러나 하나의 AI에게 모든 작업을 맡기면 작업 흐름이 복잡해지고 효율이 떨어질 수 있습니다.
OMX는 단순히 코드를 생성하는 도구를 넘어, 요구사항 분석, 계획 수립, 작업 분해, 멀티 에이전트 협업, 그리고 지속적인 상태 관리를 제공하여 AI가 실제 개발 프로세스를 따르며 작업할 수 있도록 설계되었습니다.
OMX 핵심 기능
OMX는 AI가 실제 개발 프로세스를 따르도록 설계되어 있습니다.
1. Workflow
OMX의 가장 큰 특징은 구조화된 워크플로우를 제공한다는 것입니다. 일반적인 AI 코딩 도구는 사용자의 요청을 받으면 바로 구현을 시작하지만, OMX는 분석과 설계 단계를 먼저 수행합니다.
$deep-interview는 요구사항을 구체화하고 범위를 정의하는 역할을 수행하며,
$ralplan은 구현 방식과 아키텍처를 설계합니다.
이후 $ultragoal을 통해 작업을 세부 단위로 분해하여 체계적으로 개발을 진행할 수 있습니다.
이러한 워크플로우를 통해 AI가 단순히 코드를 생성하는 것이 아니라, 문제를 이해하고 계획을 수립한 뒤 구현하도록 유도합니다.
2. Multi-Agent
OMX는 여러 AI 에이전트가 협업할 수 있는 멀티 에이전트 환경을 제공합니다.
예를 들어 한 에이전트는 인증 기능을 개발하고, 다른 에이전트는 테스트 코드를 작성하며, 또 다른 에이전트는 문서를 작성하는 방식으로 역할을 분담할 수 있습니다.
이를 통해 하나의 AI에게 모든 작업을 맡기는 방식보다 병렬적인 작업 수행이 가능하며, 실제 개발팀처럼 여러 작업을 동시에 진행할 수 있습니다. OMX는 이러한 에이전트들을 조율하고 관리하는 오케스트레이터 역할을 수행합다. 각 에이전트들은 prompt engineering으로 역할이 정의되어 있습니다.
3. Git Worktree
멀티 에이전트 환경에서 가장 큰 문제는 코드 충돌입니다. OMX는 Git Worktree를 활용하여 각 에이전트가 독립적인 작업 공간에서 개발할 수 있도록 지원합니다.
각 에이전트는 별도의 브랜치와 작업 디렉터리에서 작업을 수행하므로 서로의 변경 사항에 영향을 주지 않으며, 이후 작업이 완료되면 결과를 병합하여 하나의 코드베이스로 통합할 수 있습니다.
이를 통해 여러 AI가 동시에 개발을 진행하더라도 충돌을 최소화할 수 있다.
4. Persistent Memory
OMX는 프로젝트 내부에 .omx/디렉터리를 생성하여 작업 정보를 지속적으로 저장합니다.
이 공간에는 프로젝트 계획, 작업 로그, 메모리 정보, 실행 상태 등이 저장되며, 에이전트는 이를 참고하여 이전 작업 내용을 기억하고 활용할 수 있습니다.
일반적인 대화형 AI는 세션이 종료되면 컨텍스트가 사라지지만, OMX는 프로젝트 단위로 정보를 관리하기 때문에 장기간 진행되는 프로젝트에서도 일관성을 유지할 수 있습니다.
이는 단순한 대화 기록 저장을 넘어, AI가 프로젝트의 현재 상태를 이해하고 다음 작업을 이어서 수행할 수 있도록 돕는 핵심 기능 중 하나입니다.
OMX 구조
OMX는 개발 과정을 하나의 상태 머신 형태로 관리합니다.
각 단계는 명확한 목적과 종료 조건을 가지며, 조건이 충족되면 다음 단계로 이동합니다.
team-plan
↓
team-prd
↓
team-exec
↓
team-verify
↓
complete
필요시에는 team-verify의 결과에 따라 team-fix로 이동하여 개선 과정을 수행합니다.
1. team-plan
프로젝트의 목표를 분석하고 작업 계획을 수립하는 단계입니다.
이 단계에서는 요구사항을 이해하고 작업 범위를 정의하며, 어떤 방식으로 프로젝트를 진행할지 결정합니다. 계획과 작업 분해가 완료되면 다음 단계인 team-prd로 이동합니다.
2. team-prd
PRD(Product Requirements Document)를 작성합니다.
구현에 앞서 요구사항을 구체화하고, 완료 여부를 판단할 수 있는 Acceptance Criteria(수용 기준)를 정의합니다.
“무엇이 완료된 상태인가”를 먼저 정의한 후 개발을 시작한다는 특징을 보입니다.
3. team-exec
실제 구현이 이루어지는 단계입니다.
멀티 에이전트 환경에서 각 에이전트는 자신에게 할당된 작업을 수행하며, Git Worktree를 활용하여 독립적인 작업 공간에서 개발을 진행합니다.
모든 작업이 종료 상태(Terminal State)에 도달하면 검증 단계로 이동합니다.
4. team-verify
구현 결과를 검증하는 단계입니다.
요구사항과 Acceptance Criteria를 기준으로 기능이 정상적으로 구현되었는지 확인합니다.
검증에 성공하면 프로젝트는 complete 상태로 종료되며, 문제가 발견되면 team-fix 단계로 이동합니다.
5. team-fix
검증 과정에서 발견된 문제를 수정하는 단계입니다.
이 단계에서는 오류 원인을 분석하고 수정 전략(Fix Strategy)을 수립합니다. 수정이 완료되면 다시 team-exec 또는 team-verify 단계로 돌아가 재검증을 수행합니다.
느낀점
실제로 OMX를 사용해보고 블로그로 정리하면서 가장 인상 깊었던 점은, AI 개발에서도 결국 소프트웨어 공학의 원칙이 중요하다는 사실이었다.
예전에는 요구사항 분석, 설계, 검증과 같은 과정이 다소 형식적이라고 생각했던 적도 있었다. 하지만 OMX를 살펴보면서 이러한 과정들이 단순한 문서 작업이 아니라, 프로젝트의 방향을 정하고 시행착오를 줄이기 위한 핵심 단계라는 것을 다시 한번 느낄 수 있었다.
또한 OMX는 단순히 여러 AI를 연결한 도구가 아니라, 각 에이전트에게 역할을 부여하고 명확한 워크플로우 안에서 협업하도록 설계되어 있었다. 이를 통해 Agent의 핵심은 더 뛰어난 모델을 사용하는 것이 아니라, 역할 분리와 상태 관리, 그리고 프로세스 설계에 있다는 점을 확인할 수 있었다.
OMX는 더 AI를 더 똑똑하게 만드는 프로젝트가 아니었다. AI가 더 체계적으로 일할 수 있는 환경을 만드는 프로젝트였다.
