왜 OMX인가?
Codex 답답한 순간 + OMX가 그걸 어떻게 푸는지
Codex CLI 자체는 강력해요. 그래도 한 번 써 보면 "분명 일은 하는데 어딘가 자꾸 어긋난다"는 답답함이 와요. OMX는 그 어긋남이 일어나는 지점마다 끼어들어서 Codex를 잡아 주는 역할이에요.
답답한 장면이 크게 셋이라 하나씩 풀어 볼게요.
"이거 만들어 줘"가 안 통해요
"회원가입 좀 고쳐 줘" 같은 두루뭉술한 요청이 들어가면, Codex는 자기 짐작으로 빈칸을 채워서 작업을 시작해요. 결과는 보통 어긋나요. 엉뚱한 화면이 바뀌어 있거나, 의도하지 않은 흐름이 새로 들어와 있고요.
OMX는 그 앞에서 일단 멈춰요. 모호한 요청이 감지되면 OMX 안의 인터뷰 도구($deep-interview)가 끼어들어서, 어떤 사용자 흐름을 말하는 건지, 지금 동작은 어떻게 되어 있고 어떻게 바뀌면 좋겠는지 차근차근 물어봐요. 답이 모이면 한 장의 문서로 정리되고, 내가 그걸 보고 OK 한 다음에야 Codex가 코드를 만지기 시작해요.
매번 처음부터 다시 설명해야 해요
Codex CLI는 한 번 켜고 끄면 그동안 알고 있던 게 다 사라져요. 새 창을 열면 어제 뭐 했는지, 이 프로젝트가 뭔지, 어떤 결정을 내렸는지 모두 다시 알려 줘야 해요.
OMX는 그걸 .omx/라는 폴더에 자동으로 기록해 둬요. 어디까지 진행했는지, 왜 그 방향으로 갔는지, 다음에 뭘 해야 하는지를 사람이 직접 노트에 옮겨 적는 대신 OMX가 알아서 작성하고 갱신해요. 끊겼다 다시 켜도 이어서 이어 가요.
"다 했어요"가 거짓말일 때가 있어요
Codex가 "구현 마쳤어요"라고 말한다고 실제로 동작하는 건 아니에요. 빌드는 통과해도 정작 사용자 흐름이 망가져 있을 수 있고, 테스트는 아예 쓰지도 않은 채로 끝나는 경우도 있어요.
OMX는 끝났다는 말 대신 증거를 요구해요. OMX 안의 검증 도구(verifier 에이전트와 $ultraqa)가 코드를 직접 실행해 보고, 결과 출력을 읽고, 실패하면 다시 고치는 루프를 돌려요. "정말 통과했다"는 흔적이 남기 전까진 완료로 표시하지 않아요.
정리
OMX가 끼어드는 시점은 결국 세 군데예요. 시작 전에는 요청을 명확한 문서로 정리해 주고, 진행 중에는 어디까지 왔는지 기록하고, 끝났다고 할 때는 실제로 동작하는지 확인해요. 이 셋이 합쳐져야 직접 코드를 안 써도 Codex한테 의미 있는 일을 끝까지 시킬 수 있게 돼요.