OMX·OMC를 Meta-Harness 제품으로 읽지 않는 법

이 글은 「AI 공부 지도 20부작」의 18편(M8) 입니다.
앞 편: M7 — Meta-Harness는 실무적으로 뭐냐
다음 편: M9 — RAG는 죽었냐

0. 시리즈 안내 (18/20)

M1에서 M7까지 공부 지도를 따라오셨으면 지금쯤 머릿속에 이런 구분선이 생겼을 거예요. Retrieval Layer, RAG, autoresearch, Meta-Harness. 각각이 무엇이고, 어디가 연구 방향이고 어디가 제품이고 어디가 단순 키워드인지 나눠보는 연습을 같이 해왔어요.

이번 M8은 약간 다른 각도입니다. 실제 돌아가는 도구 두 개를 그 프레임 위에 놓아보는 거예요. OMX (Oh My Codex) 와 OMC (Oh My Claude Code). 요즘 한국·일본 개발자 트위터에서 자주 보이는 이름이죠. 각종 소개 글에서 “자기개선 AI 에이전트“, “autoresearch 를 구현한 제품”, “Meta-Harness 를 탑재” 같은 문구가 붙어 나와요.

그 문장들을 그대로 믿고 도입 결정을 내리면 기대가 어긋날 가능성이 큽니다. 이번 글에서 하려는 건 하나예요. 이 도구들을 공부 지도의 어느 좌표에 놓아야 정확한가 를 같이 재는 겁니다. 찬양도 아니고 까내리기도 아닙니다. 치수를 제대로 재는 연습이에요.

1. “OMX 가 autoresearch 를 구현했다” 는 기사를 제대로 읽으려면

최근에 OMX 를 소개하는 글들에서 자주 보이는 한 줄이 있어요.

“OMX 는 autoresearch 명령을 내장한, 자기 스스로 공부하는 에이전트다.”

이 문장 앞에서 실무자가 잠깐 멈춰야 합니다. 왜냐면 여기에 두 가지가 은근슬쩍 섞여 있기 때문이에요.

하나는 이름 입니다. OMX 의 CLI 명령어 목록 안에 autoresearch 라는 이름이 실제로 걸려 있어요. 이건 사실이에요.

다른 하나는 개념 입니다. M6 에서 얘기했던 autoresearch — 에이전트가 스스로 리서치 자료를 찾고, 새 지식을 소화해서, 자기 행동 전략을 갱신한다는 연구 방향. 이건 산업계에서 아직 “완전히 닫힌 문제” 가 아닙니다. 데모는 여럿 나왔지만 실무 수준의 검증은 희박해요.

위 한 줄짜리 소개 문장은 이 두 가지를 같은 것처럼 쓰고 있어요. “OMX 에 autoresearch 라는 이름의 명령이 있다” 와 “OMX 가 autoresearch 라는 연구 방향을 실무에서 닫았다” 는 완전히 다른 주장 이에요. 앞엣것은 표면의 이름, 뒤엣것은 실질의 달성입니다.

이 차이를 감각적으로 느끼려면 이런 비유가 도움이 돼요. 카페에 가서 메뉴판에 “정통 이탈리아식 에스프레소” 라고 쓰여 있다고 해봅시다. 그 카페에 진짜 이탈리아인 바리스타 가 있을 수도 있고, 그냥 메뉴 이름만 그렇게 붙어 있을 수도 있어요. 메뉴 이름과 실제 품질은 다른 층이에요. 두 층을 분리해서 보는 습관이 도구 평가의 기본입니다.

그리고 한 가지 더. 도구를 만든 쪽이 이름을 그렇게 짓는 건 전혀 나쁜 일이 아닙니다. autoresearch 라는 키워드는 산업 흐름의 방향을 가리키는 말이고, 제품이 그 방향을 겨냥한다는 선언으로는 타당해요. 문제는 그 선언을 읽는 쪽 이 선언과 달성을 헷갈릴 때 생깁니다. 이 글은 그 헷갈림을 예방하려는 글이에요.

이 프레임을 깔아두고, 이제 도구 자체를 뜯어볼게요.

2. OMX 짧게 뜯기 — 무엇을 더하는가

OMX 는 OpenAI Codex 위에 얹는 툴킷이에요. Codex 가 실행 엔진이라면, OMX 는 그 엔진 위에 작업 환경을 두껍게 깔아주는 층입니다.

공식 위키 문서 기준으로 정리하면 OMX 가 추가하는 건 다섯 면이에요.

• setup 면 — omx setup 하나로 프로젝트에 .codex/prompts, .codex/skills, .codex/agents, .codex/config.toml, .codex/hooks.json, 루트 AGENTS.md, .gitignore 까지 한 번에 깔립니다. Codex 가 프로젝트에서 어떤 규칙으로 돌지 를 파일로 고정하는 설치자 역할이에요.
• state 면 — .omx/ 아래에 세션 상태, 모드, 잠금, 원자적 쓰기 로그를 남깁니다. 세션이 끊겨도 “이 프로젝트가 지금 어느 단계인지” 가 디스크에 남아요.
• hooks 면 — SessionStart, PreToolUse, PostToolUse, UserPromptSubmit, Stop 같은 Codex native hook 에 명령을 꽂아둡니다. 사람이 일일이 기억하지 않아도 훅이 규칙을 강제합니다.
• HUD / doctor / operator surface 면 — omx hud --watch, omx doctor, omx status, omx state list-active. 지금 이 프로젝트에 뭐가 걸려 있는지 운영자가 직접 읽을 수 있는 계기판을 붙여요.
• team runtime 면 — omx team 기반 tmux / worktree coordination. 여러 작업을 병렬로 돌리는 분업 구조가 설계되어 있어요.

그리고 논의의 핵심이 될 한 표면이 하나 더 있어요.

• autoresearch 표면 — omx autoresearch 라는 CLI 명령이 실제로 존재합니다. 이름만 보면 M6 의 “자기공부 에이전트” 를 바로 떠올리게 되는 그 표면이에요.

여기서 중요한 질문이 생기죠. 이 이름표 안에 실제로 뭐가 돌고 있는가? 다음 섹션이 그 얘기예요.

3. OMX 의 실제 위치 — runtime overlay 그 이상은 아직

위키가 OMX 에 대해 뭐라고 판단했는지 간추려 볼게요. 이 부분은 감상이 아니라 1차 검증 결과 에 기반한 얘기라서, 가능하면 원문의 표현에 가깝게 옮겨 둡니다.

위키의 oh-my-codex 엔티티와 oh-my-codex-runtime-architecture 시노프시스를 같이 읽으면 이런 판단이 나옵니다.

first-party 로 확인된 것:

• repo clone / dependency install / build 가 현재 기준으로 성공한다.
• setup, hooks, HUD, state server, mode-aware runtime, team decomposition 관련 targeted test 33개 가 통과했다.
• clean sandbox 에서 omx setup --scope project --force 가 실제로 .codex/, .omx/, AGENTS.md, hooks, MCP config 를 생성했다.
• 같은 sandbox 에서 omx doctor 가 11 passed, 1 warning, 0 failed 로 닫혔고, status / state list-active / hud / reasoning 표면도 실제로 응답했다.

여기까지는 단단해요. “OMX 는 Codex 위에 setup/state/hook 오버레이를 까는 installer + runtime layer 다” 는 문장은 README 감상이 아니라 코드 경로와 테스트를 근거로 방어 가능한 주장입니다.

반대로 아직 검증되지 않은 것 도 위키가 명시해 뒀어요.

• live omx team tmux / worktree runtime 의 실전 안정성.
• long-running task 에서의 state carry-over 이득이 plain Codex 대비 반복적으로 확인됐는가.
• 현재 shell / auth 환경에서 omx exec 가 끝까지 닫히는가. (이번 검증에서는 401 Unauthorized 로 막혔어요.)
• same-task side-by-side 에서 OMX lane 이 manual lane 보다 회복 비용을 반복적으로 더 낮추는가.

마지막 항목이 특히 중요해요. same-task 비교에서 결정적으로 작동한 restart aid 는 OMX 고유 surface 가 아니라 TASK.md + HANDOFF.md 같은 explicit local intent capture 였어요. 이건 OMX 를 까내리는 얘기가 아니고, “작은 bounded task 에서는 manual lane 과 OMX lane 의 차이가 생각보다 작다” 는 관찰입니다. 위키는 이런 증거를 근거로 현재 OMX 에 adopt-partial 이라는 판정을 내렸어요. 메인 wiki 에 전면 도입이 아니라, 신규 장기 프로젝트나 별도 greenfield repo 에서 제한적으로 다시 검증하는 쪽이 맞다는 거예요.

그래서 “OMX 가 autoresearch 를 구현했다” 에 돌아와 보면 이렇게 정리가 됩니다. autoresearch 라는 이름의 표면 은 있어요. 그 표면이 M6 에서 말한 자기공부 에이전트를 실제로 닫았다 는 건 현재 위키 근거로는 말하기 어렵습니다. 위키가 확인한 OMX 의 본체는 runtime overlay + project-scoped state visibility 쪽이에요. 이 둘은 다른 층입니다.

한 문장으로 좌표를 찍으면 이래요. OMX 는 Codex 세션을 상태와 운영 규칙이 남는 작업 시스템으로 바꾸는 오버레이다. 이 문장이 맞는 크기의 문장이에요. 그보다 한 단계 위로 올라간 “자기개선 AI” 라는 문장은 현재 증거 앞에서 한 칸 더 가는 셈입니다.

4. OMC 짧게 뜯기 — 무엇을 더하는가

같은 작성자가 Claude Code 쪽에 만든 대응 레이어가 OMC 예요. Claude Code 를 기본 작업면으로 놓고, 그 위에 운영 규칙과 분업 방식을 덧씌우는 구조입니다.

공식 위키 기준으로 정리하면 OMC 가 추가하는 면은 이렇게 나눠져요.

• 설치와 식별 면 — plugin marketplace install 경로 + npm / runtime 경로 를 같이 가집니다. 그런데 주의할 점이 하나 있어요. repo / brand 이름은 oh-my-claudecode 지만, 실제 npm package identity 는 oh-my-claude-sisyphus 예요. 설치 문서에서 이 차이를 안 쓰면 운영 혼선이 생깁니다.
• 세션 명령 면 — /autopilot, /team, /pipeline, /ralph 같은 in-session orchestration skill 이 있어요. Claude Code 한 세션 안에서 작업 방식을 고정하는 쪽이에요.
• 외부 팀 런타임 면 — src/cli/team.ts 가 별도의 job record, worker identity guard, pane artifact, team state root 를 가집니다. 중요한 건 /team 과 omc team 이 같은 이름의 한 기능이 아니라는 것 이에요. 하나는 세션 안, 하나는 tmux 중심 외부 런타임.
• 아티팩트 / 기억 면 — .omc/prompts/ 아래에 prompt, response, metadata 가 쌓입니다. 작업 흔적을 다시 읽게 만드는 시스템 쪽에 가까운 구조예요.
• 운영 가시성 면 — HUD, wait, session search, teleport, config 같은 표면. 모델 성능을 올리는 기능이 아니라 사람이 runtime 을 다루기 쉽게 만드는 기능들이에요.

위키 검증에서 확인된 사실도 붙여둘게요.

• repo clone / dependency install / build 성공.
• team runtime boundary, team CLI, prompt persistence, artifact convergence 관련 targeted test 26개 통과.
• isolated CLAUDE_CONFIG_DIR 에 실제로 install 가능했고, 결과로 hooks/, skills/, agents/, hud/omc-hud.mjs, settings.json, CLAUDE.md 가 config space 에 생성됐다.
• settings.json 에 UserPromptSubmit, SessionStart, PreToolUse, PostToolUse, PostToolUseFailure, Stop hook 과 statusLine 이 실제로 들어갔다.
• 생성된 CLAUDE.md 는 단순 README 가 아니라 상위 operating contract 역할이었다.

여기까지 보면 OMC 역시 “Claude home / config 표면을 재구성하는 설치 오버레이” 라는 주장은 방어가 됩니다. 문제는 그 다음 층이에요.

5. OMC 의 실제 위치 — orchestration / runtime 이 강점, self-improvement 는 약함

OMC 공식 표면에는 이런 문구가 걸려 있어요. 3-5x faster, 30-50% token savings. 처음 보면 솔깃하죠. 그런데 위키는 이 수치를 독립 검증이 필요한 claim 으로 분류했어요. 벤치마크 출처가 빠져 있거나, 테스트 조건이 명시되지 않아서 그렇습니다. 이 숫자를 그대로 인용해서 “OMC 를 쓰면 3배 빨라진다” 고 옮기면 1차 증거 없이 마케팅 문구를 퍼 나르는 셈이 됩니다.

또 하나의 오독 축은 “OMC 는 Meta-Harness 제품이다” 라는 문장이에요. M7 에서 얘기했던 Meta-Harness 의 핵심은 하네스 자체를 자동으로 탐색 / 갱신 / 최적화 하는 시스템이었어요. 여러 하네스 후보를 돌려보고, 성공률을 재고, 더 잘 동작한 하네스로 갈아끼우는 루프. 이건 연구 쪽에서도 아직 까다로운 문제입니다.

OMC 가 하는 일은 그것과 관련이 있지만 같은 층이 아닙니다. OMC 는 “좋은 하네스 한 세트 (plugin install + in-session skill + team runtime + prompt persistence + hook set) 를 프로젝트에 고정해서 깔아주는” 쪽입니다. 하네스를 운영 하는 쪽에 가까워요. 하네스를 탐색 하는 쪽은 아직입니다.

둘이 왜 구분돼야 하는지 조금 더 풀어볼게요. 비유하자면 이래요. Meta-Harness 는 “메뉴판 자체를 매일 실험해서 손님 만족도가 가장 높은 조합을 찾아가는 셰프” 예요. OMC 는 “이미 검증된 메뉴 세트를 가게마다 똑같은 품질로 깔아주는 프랜차이즈 본사” 에 가까워요. 둘 다 외식업의 중요한 역할이지만 하는 일이 달라요. 전자는 실험이고 후자는 표준화입니다.

OMC 의 실제 강점을 정직하게 표현하면 이래요.

• orchestration layer 로서 강함. 역할 분담, 단계 파이프라인, 팀 런타임이 코드와 테스트 수준으로 존재한다.
• prompt persistence 로 기억 표면이 있음. 세션 간 아티팩트 조회가 가능한 구조.
• config space 를 재구성하는 installer 로서 두껍다. CLAUDE.md 가 단순 설명서가 아니라 상위 contract 로 동작하게 깔린다.

약한 쪽도 정직하게 적으면 이래요.

• live tmux team runtime 의 실제 운영 마찰은 미검증.
• plugin-first 설치가 환경별로 얼마나 매끄러운지 미검증.
• base Claude Code 대비 반복적 생산성 우위 미확인.
• self-improving loop 의 증거 없음. 하네스 자동 탐색은 현재 표면에 없음.

한 줄로 좌표를 찍으면, OMC 는 Claude Code 세션·외부 팀 런타임·아티팩트 저장소를 한 운영 계층으로 묶는 구조 예요. 이 이상으로 당겨서 “자기개선 Claude 플러그인” 이라고 부르면 현재 위키 근거 기준으로는 과장입니다.

6. 철학 vs 실무 대응물의 거리 — 한 장 표

공부 지도를 따라온 분들은 M6 과 M7 에서 연구 방향 과 실제 제품 을 구분하는 연습을 했어요. 그 결과를 한 장 표로 눌러볼게요.

이 표에서 제일 중요한 건 autoresearch 행 과 Meta-Harness 행 이에요. 두 행 모두 “대응 깊이” 가 “이름 수준” 또는 “관련 있지만 다른 층” 이라고 적혀 있죠. 이 칸의 단어가 정확히 이 정도 크기에서 잡혀야 실무 판단이 흔들리지 않습니다.

7. 왜 이 거리 측정이 실무자에게 중요한가

거리 측정이 왜 꼭 필요한지 이유를 조금 풀어볼게요. 세 가지 장면에서 직접적으로 차이가 납니다.

첫째, 제품 평가 장면. 팀에 도입을 검토할 때 “자기개선 AI 에이전트” 를 기대하고 OMX/OMC 를 깔면, 이 도구가 알아서 사람 도움 없이 지식을 갱신하고 하네스를 개선 해 줄 거라고 기대하게 돼요. 실제로는 그렇지 않습니다. 도입 후 몇 주가 지나도 에이전트가 “더 똑똑해지는” 감각이 안 오면 도입 자체에 실망하게 되죠. 실망은 포기로 이어지고, 포기 과정에서 이미 설치된 .codex/, .omx/, CLAUDE.md, hooks 를 어떻게 정리할지 같은 운영 부채가 남습니다. 처음부터 “이 도구는 runtime overlay 다” 로 기대를 세팅 하면 이런 실망 · 포기 · 운영 부채 사이클이 안 생겨요.

둘째, 뉴스 해석 장면. 앞으로 “OMX 가 autoresearch 벤치마크에서 X 점을 냈다”, “OMC 가 Meta-Harness 를 구현한 최초의 Claude Code wrapper 다” 같은 문구가 계속 나올 수 있어요. 이 문구를 그대로 믿고 기사화 / 리트윗 / 사내 공유 를 하면, 증거 없는 마케팅 문구가 실무 지식처럼 퍼지는 일이 생깁니다. 위키가 확인한 경계 안에 머무르는 습관이 있으면, 같은 문구를 봐도 “그 벤치마크가 어떤 태스크 세트에서 나왔는가”, “하네스 자동 탐색 루프가 정말 돌고 있는가” 같은 질문을 바로 던질 수 있어요. 이게 실무자의 방어선입니다.

셋째, 도입 후 실패 해석 장면. OMX/OMC 를 깔았는데 기대한 만큼 효과가 안 나왔을 때, 원인을 어디에 돌릴지가 갈립니다. “자기개선 AI” 로 읽고 도입했다면 “이 도구는 사기다” 로 귀결되기 쉬워요. 반면 “runtime overlay” 로 읽고 도입했다면 “우리 팀이 하네스 자체를 충분히 안 갈고 있었구나”, “workflow overlay 가 가장 효과적인 장기 작업 맥락에 우리 작업이 맞지 않았구나” 같은 정확한 회고 가 가능해집니다. 결과가 안 좋아도 배울 게 남아요.

요약하면 거리 측정은 기대를 관리하고, 뉴스를 거르고, 실패를 해석하는 세 장면에서 직접 돈을 아껴주는 실무 스킬입니다.

8. “그럼 OMX / OMC 는 쓸모없나?” — 아니다, 강점은 분명하다

지금까지 “autoresearch 도 아니고 Meta-Harness 도 아니다” 를 계속 반복했으니까 이런 인상이 남을 수 있어요. “그러면 이 도구들은 그냥 과장된 마케팅이고 쓸 필요 없다는 거냐?” 아닙니다. 실제로 다르게 읽으면 OMX 와 OMC 의 가치는 분명하고 구체적입니다. 관점만 바꾸면 돼요. “자기개선” 대신 “운영 가능한 작업면 두께” 로 보는 관점 이에요.

조금 풀어볼게요.

Codex 나 Claude Code 를 한 달쯤 써본 분들이 자주 부딪히는 벽이 있어요.

• 세션이 끊기면 어디까지 했는지 다시 떠오르는 데 한참 걸린다.
• 프로젝트마다 규칙이 다른데, 같은 지시를 매번 다시 적는다.
• 팀원 둘이 같은 repo 에서 돌리면 hook 이나 config 가 서로 덮어쓴다.
• agent 가 실수한 뒤 복구 비용이 너무 커서 결국 사람이 처음부터 다시 짠다.

이 네 가지는 “AI 가 더 똑똑해지면 풀리는 문제” 가 아니에요. “작업 환경이 더 두꺼워져야 풀리는 문제” 입니다. 그리고 이게 정확히 OMX / OMC 가 겨냥하는 자리예요.

구체적으로:

• project-scoped state visibility. OMX 의 .omx/ 는 세션이 끊겨도 “지금 어느 단계인가” 가 디스크에 남는 구조예요. HUD 로 상태가 바로 읽혀요. 재개 비용이 줄어듭니다. 같은 맥락에서 OMC 의 .omc/prompts/ 는 과거 세션이 어디서 멈췄는지, 어떤 프롬프트가 먹혔는지 흔적으로 남아요.
• workflow overlay. OMX 의 canonical session path (deep-interview → ralplan → ralph / team) 나 OMC 의 autopilot / pipeline / ralph / team 같은 skill 은 “매번 처음부터 생각하는 프롬프트” 를 줄여줘요. 작업 방식 자체가 파일로 고정되어 있으니까요.
• team coordination. 혼자 쓰는 툴이 아니라 팀에서 같은 규칙 세트로 일하게 만드는 장치가 있어요. AGENTS.md, CLAUDE.md, hook 이 repo 안에 박히면 새 팀원도 같은 계약을 자동으로 가져갑니다.
• operator visibility. omx doctor, omx hud --watch, OMC 의 status line — 지금 내 환경에 뭐가 걸려 있고 뭐가 고장 났는지를 사람이 바로 읽게 해줘요. 이게 없으면 디버깅이 고스란히 사람 머릿속으로 내려옵니다.

“자기개선” 이 아니라 이 네 가지로 OMX / OMC 의 가치를 표현하면, 기대와 실측이 맞아떨어지는 도입이 됩니다. 이 관점이 핵심이에요.

9. 실무 도입 판단 — 당신 팀이 이걸 써야 하는가

“관점은 알겠는데 우리 팀이 쓸 만한가” 라는 구체 질문으로 내려가 볼게요. 추상적인 찬반 대신 다섯 가지 질문 으로 재보는 게 제일 빨라요.

질문 1. 지금 하는 일이 “bounded task 로 쪼개서 manual handoff 로 돌릴 수 있는” 크기인가?

작은 bounded task 에서는 TASK.md + HANDOFF.md 같은 명시적 로컬 의도 캡처만으로 대부분 해결됩니다. 위키의 same-task side-by-side case 도 이걸 보여줬어요. OMX / OMC 의 두꺼운 설치 표면이 이런 규모에선 과할 수 있어요. 답이 “예, bounded 하고 짧다” 면 당분간 도입 보류 가 합리적입니다.

질문 2. 동일 프로젝트에서 “한 주 이상 이어지는 multi-session 작업” 이 있는가?

세션이 끊겼다 이어지는 작업이 많을수록 state 표면의 가치가 커집니다. 어제 어디까지 했는지 재구성하는 데 매번 15분이 든다면 일 년으로 환산하면 꽤 큰 비용이에요. 이 비용이 느껴진다면 OMX / OMC 를 써볼 가치가 생겨요.

질문 3. 팀 협업이 필요하고, 사람 둘 이상이 같은 repo 에서 agent 를 돌리는가?

혼자 쓰는 환경에서는 설치 표면이 얇을수록 좋고, 팀 환경에서는 공유되는 계약이 파일로 박혀 있어야 협업이 버텨요. OMX 의 AGENTS.md + hooks 나 OMC 의 CLAUDE.md + settings.json 은 이 계약을 repo 에 고정시켜줍니다. 답이 “예, 팀으로 돈다” 면 가치가 커져요.

질문 4. plugin / npm / tmux 같은 런타임 환경을 팀이 실제로 감당할 수 있는가?

두꺼운 오버레이를 깔아 놓으면 그걸 운영하는 것도 새로운 책임이 됩니다. package identity 혼선 (oh-my-claudecode 와 oh-my-claude-sisyphus), plugin path 와 npm path 의 분리, tmux 환경 준비 — 이런 걸 팀이 감당할 수 있어야 해요. 이걸 감당할 여력이 없는 팀이 무리해서 도입하면 “도구가 또 다른 유지비용” 이 돼요.

질문 5. 우리 팀이 “자기개선 AI” 를 기대하고 있나, 아니면 “운영 가능한 작업면 두께” 를 기대하고 있나?

이게 가장 결정적이에요. 앞의 네 질문이 다 “예” 여도 팀이 기대하는 게 전자라면 도입 후 실망이 빠릅니다. 기대를 세팅하는 게 먼저예요. 이 한 문장을 도입 전 회의록에 그대로 박아 두시길 권합니다. “우리가 사는 건 자기개선 AI 가 아니라 세션·팀·상태가 남는 작업면이다.”

다섯 질문을 다 통과한다면, OMX / OMC 중 팀의 base CLI 에 맞는 쪽 을 골라 sandbox 에서 한 차례 돌려보시면 됩니다. Codex 가 base 라면 OMX, Claude Code 가 base 라면 OMC. 둘 다 쓰는 팀은 거의 없을 거예요. 두 base CLI 를 동시에 운영하면 하네스 축이 둘 돼서 관리 비용이 확 오릅니다.

10. 기대가 과장되기 쉬운 3 가지 지점

마지막으로, 현장에서 가장 자주 어긋나는 기대 포인트 세 가지를 모아 둡니다. 이 세 가지만 미리 알고 가셔도 도입 판단에서 실수가 줄어요.

(a) “autoresearch 표면이 있다” = “autoresearch 가 구현됐다” 로 읽는 실수.

앞서 1장에서 깐 그 실수예요. CLI 명령 이름에 autoresearch 가 있다고 해서 에이전트가 혼자 지식·전략을 갱신하는 루프가 닫혔다는 뜻이 아닙니다. 이름은 선언, 실질은 증거 라는 감각을 계속 유지해야 해요. 지금 돌아가는 실증은 state 와 workflow 의 표면까지.

(b) “runtime overlay 를 깔았다” = “생산성 향상이 자동 보장된다” 로 읽는 실수.

오버레이는 “일할 면” 을 깔아주는 거지, “일을 대신해 주는” 게 아닙니다. 설치 후 생산성이 오르려면 팀이 그 작업면 위에서 실제로 습관을 바꿔야 해요. hook 이 깔렸지만 아무도 기대를 갱신하지 않으면 hook 은 돌기만 하고 사람 머리는 예전 그대로 굴러요. 생산성 향상은 오버레이 + 사람의 habit change 의 곱입니다. 한쪽이 0 이면 전체가 0 이에요.

(c) “orchestration layer 를 제공한다” = “Meta-Harness 다” 로 읽는 실수.

M7 에서 얘기한 Meta-Harness 의 본질은 하네스를 자동으로 탐색하고 갱신하는 루프 예요. OMX / OMC 가 제공하는 orchestration layer 는 잘 고른 하네스 한 세트를 고정해서 배포 해주는 쪽입니다. 같은 “하네스” 라는 단어가 붙지만 동사가 달라요. 전자는 evolve, 후자는 standardize / deploy 입니다. 같은 명사로 두 층을 퉁치면 제품 평가가 엉킵니다.

이 세 실수만 피해도 도입 판단의 정확도는 꽤 올라와요.

11. 이런 도구들을 평가할 때 붙여야 할 체크리스트

OMX / OMC 만이 아니라, 앞으로도 “Codex 위의 뭔가”, “Claude Code 위의 뭔가”, “새로운 self-improving agent” 같은 이름으로 계속 도구가 나올 거예요. 매번 같은 실수를 반복하지 않으려면 체크리스트가 필요해요. 위키의 평가 축을 그대로 가져오면 이런 항목들이에요.

• same-task recovery cost. 같은 작업을 manual lane 과 이 도구 lane 으로 두 번 돌렸을 때, 세션이 끊긴 뒤 재개 비용이 실제로 더 낮은가?
• handoff quality. 사람 → 사람, 사람 → 도구, 도구 → 사람 으로 넘어갈 때 컨텍스트 손실이 줄어드는가? 로그만 많아지는 건 handoff quality 가 아니다.
• explicit local intent capture. 이 도구 없이 TASK.md + HANDOFF.md 만 잘 써도 되는 부분은 어디까지인가? 이 도구가 거기서 추가로 해주는 건 무엇인가?
• operator visibility. 지금 이 프로젝트에 뭐가 걸려 있는지, 뭐가 고장 났는지 사람이 한 화면 에서 읽을 수 있는가?
• package identity. repo 이름 / brand 이름 / npm package 이름이 어디서 어떻게 갈라지는가? 이 차이를 설치 문서가 정확히 다루는가?
• claim 의 출처. 3x faster, 50% token savings 같은 숫자가 어떤 태스크, 어떤 모델, 어떤 조건에서 측정된 값인가? 출처가 없으면 수치는 0 으로 취급한다.
• first-party 검증 가능성. 내가 이 repo 를 clone 해서 install / build / targeted test 를 돌려 재현할 수 있는가?
• adopt 판정. 위키 관점에서 이 도구가 adopt, adopt-partial, trial, hold, avoid 중 어디에 있는가? adopt-partial 이면 어떤 조건에서 adopt 로 올라가는가?

체크리스트가 많아 보이지만 실제로는 도구를 세 번쯤 평가해 보면 체화됩니다. 그 뒤부턴 새 도구를 봤을 때 자동으로 이 질문들이 머릿속에서 돌아요. 이 감각이 실무자 한 명의 가장 싼 AI 방어선 입니다.

12. M9 / M10 예고 — 이제 직접 답해볼 준비가 끝났다

여기까지 따라오신 상태에서 M9 과 M10 으로 넘어갈 준비가 거의 끝났어요.

M9 는 “RAG 는 죽었냐” 라는 질문입니다. Long-context 모델이 커지면서 “RAG 필요 없다” 는 트윗이 계속 반복되는 중인데, 실무에선 어디까지 맞는 말이고 어디서부터 틀린 말인지를 정리합니다. 여기까지 오신 분들은 Retrieval Layer / RAG / autoresearch 를 이미 구분하셨고, 지금 배운 OMX / OMC 라는 실제 도구 기준의 runtime overlay 감각 까지 있기 때문에, “long-context 만으로 정말 끝인가” 라는 질문을 자기 말로 답해볼 수 있는 상태예요.

M10 은 “Meta-Harness 는 실무적으로 뭐냐” 입니다. M7 에서 개념을 잡고, 이번 M8 에서 “OMC 는 Meta-Harness 가 아니다” 는 좌표를 찍었으니, 다음은 실무자의 손에 잡히는 Meta-Harness 가 어떤 모양으로 등장할 가능성이 있는지, 그리고 오늘 실무자가 미리 준비할 수 있는 habit 은 무엇인지 를 얘기합니다.

두 글 모두 이번 M8 의 감각 — 연구 방향과 실무 표면을 같은 단어로 퉁치지 않는 습관 — 위에서 돌아갑니다. 여기까지 오신 시간이 다음 두 글에서 바로 효과를 낼 거예요.

한 문장 닫음: OMX 와 OMC 는 자기개선 AI 가 아니라, base CLI 위에 상태·운영 규칙·팀 분업을 깔아주는 runtime overlay 다. autoresearch 라는 이름과 orchestration layer 라는 표현을 각각 M6 의 autoresearch, M7 의 Meta-Harness 와 같은 것으로 읽으면 현재 증거 기준에서 한 칸씩 당겨진다. 이 거리만 맞게 재도 실무 판단이 안 흔들린다.

다음 읽기

• M9 — RAG 는 죽었냐 [준비 중]
• M10 — Meta-Harness 는 실무적으로 뭐냐 [준비 중]

시리즈 앞으로 돌아가기: M1 — Retrieval Layer 가 왜 필요한가 · M6 — autoresearch 란 무엇인가 · M7 — Meta-Harness 는 실무적으로 뭐냐

자주 묻는 질문 (FAQ)

Q1. OMX / OMC 는 지금 당장 도입해도 되나요?

조건부로 “예” 입니다. 다섯 가지 질문 — bounded task 가 주가 아닌가, multi-session 작업이 있나, 팀 협업이 필요한가, 런타임 감당이 되는가, 기대를 “runtime overlay” 로 세팅했는가 — 에 모두 “예” 면 sandbox 검증 후 도입을 시작해볼 만해요. 한두 개만 “예” 라면 TASK.md + HANDOFF.md 같은 경량 local intent capture 로 먼저 해결되는지부터 보세요. 위키 판정은 현재 adopt-partial 이고, 이 판정은 “모두에게 무조건 쓰라” 는 뜻이 아니라 “특정 조건에서 제한적으로 써볼 가치가 있다” 는 뜻이에요.

Q2. “autoresearch” 명령이 이름만 있다면 앞으로는 달라질 수 있나요?

충분히 가능합니다. repo 가 계속 업데이트되고 있고, 이름이 붙은 표면 아래에 점점 실질을 채울 수도 있어요. 위키도 thesis_last_checked, recheck_trigger 같은 필드로 재검증 시점 을 명시하고 있어요. 다만 “지금 이 시점의 증거” 로는 이름 수준에 가깝다는 게 정확한 표현입니다. 6 개월 뒤에 같은 질문을 다시 던져야 해요. 저도 이 시리즈가 마무리될 때쯤 다시 체크해서 변동이 있으면 메모를 덧붙일 생각이에요.

Q3. OMX 와 OMC 중 하나만 고른다면 무엇을 기준으로 하나요?

팀이 base 로 쓰는 CLI 가 결정권입니다. Codex 가 주라면 OMX, Claude Code 가 주라면 OMC. 두 CLI 를 반반씩 쓰는 팀은 생각보다 드물어요. 그리고 “둘 다 깔아서 비교해 보자” 는 접근은 비용이 크니까 권장하지 않아요. 각각이 깔리면서 config space 가 두 번 겹치고, 팀원마다 어떤 쪽을 기본으로 쓰는지 기억해야 하거든요. 결정을 한 쪽으로 내리고, 반대쪽은 공부용으로 문서만 읽어두는 편이 실무 비용이 싸요.

뉴스레터 구독 안내

매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. OMX / OMC 같은 도구들이 업데이트될 때 “이번 변화가 공부 지도의 어느 좌표를 흔드는가” 를 같이 재는 내용도 자주 다뤄요. 이런 정리를 차분히 쌓아가고 싶으시면 구독해 주세요.

뉴스레터 구독하기

시리즈 안내 — AI 공부 지도 20부작
– M1: Retrieval Layer 가 왜 필요한가
– M2: RAG 의 실무 골격
– M3: Agent 가 왜 이렇게 다양해 보이는가
– M4: Work Surface 라는 개념
– M5: Harness 는 무엇인가
– M6: autoresearch 란 무엇인가
– M7: Meta-Harness 는 실무적으로 뭐냐 (연구 방향편)
– M8: OMX · OMC 의 실제 위치 (현재 글)
– M9: RAG 는 죽었냐
– M10: Meta-Harness 는 실무적으로 뭐냐 (실무편)
– (이하 20편까지)

소스 리스트

• 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
• AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 공식 docs
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.

바이브코딩 태일러

AI의 작동 원리와 비즈니스 적용을 일본어·한국어로 기록합니다. 매주 월요일 뉴스레터 발행 중.

뉴스레터 구독하기 →

이 시리즈의 다음 편

”RAG는 죽었냐”에 내가 자기 말로 답한다면

"RAG는 죽었냐"라는 질문에 태일러가 자기 말로 답한다. 죽은 건 1층(단순 embedding + 일회성 retrieval)뿐이고 2~4층(GraphRAG·Agentic·Memory Adaptation)은 오히려 확장 중. long context가 대체할…

”Meta-Harness는 실무적으로 뭐냐”에 내가 답한다면

Meta-Harness는 실무적으로 뭐냐 — 태일러가 자기 말로 답한다. 학계 미래형 용어가 아니다. 당신이 매일 CLAUDE.md·Cursor rules를 고치고 있다면 이미 수작업 Meta-Harness다. 도입…

Haiku·Sonnet·Opus의 기술적 차이와 4.7 업그레이드 메커니즘

📍 AI 공부 지도 — 24/29편이 글은 AI의 기초부터 Meta-Harness·응용 비교까지 순서대로 읽는 29편 시리즈의 24편입니다.📚 전체 지도 보기← 이전 편: M10.…

★ 태일러의 다른 추천

LLM이 뭐냐고 물으면 말이 막히는 분께 — 자동완성이 끝까지 간 이야기

ChatGPT·Claude 2~3년째 쓰는데도 "LLM이 뭐예요?"에 막히는 분을 위한 해설. 다음 토큰 예측, 토큰, 파라미터, 학습/추론, 환각까지 비유 하나로 이어 읽는다. AI 공부…

Transformer가 뭔지 진짜 이해하고 싶은 분께

ChatGPT·Claude 안에는 다 Transformer가 들어 있다. 근데 Transformer가 정확히 뭐냐고 물으면 다들 얼버무린다. RNN 한계부터 attention, multi-head, stacking까지 비유 하나로 따라가게 정리.…