한 shim이 claude·codex를 감싼다 — 스킬은 랭킹되고, 감시가 아니라 케어가 된다
에이전트 CLI를 팀에 깔면 곧바로 두 개의 문제가 따라온다. 하나는 동기화 — 누구는 스킬이 최신인데 누구는 3주 전 버전이고, 훅 하나 바뀌면 전원에게 “다시 받아라”를 외쳐야 한다. 다른 하나는 가시성 — 도대체 누가 무엇을 쓰고 있는지, 내가 만든 스킬이 실제로 도움이 되는지, 아무도 모른다.
이 둘을 CLI 바깥 에서, CLI를 건드리지 않고 푸는 방법이 있다. 명령을 가로채는 얇은 껍데기 하나 — shim. 아래 한 장이 그 구조 전체를 네 칸으로 압축한다.
“한 shim이 claude·codex를 감싼다 — 스킬은 랭킹된다.”
이 그림의 핵심은 어디에 손을 대는가 다. Claude Code도 Codex CLI도 건드리지 않는다. 그 앞에 껍데기를 하나 세운다. 그 껍데기가 지나가는 모든 호출을 보고, 필요한 일을 하고, 그러고 나서 진짜 CLI에게 자리를 넘긴다. 네 칸을 하나씩 풀어 보자.
1. shim — 명령을 가로챈다
”
~/.zeude/bin의 shim이 claude·codex를 가로채 빠르게 동기화하고 텔레메트리를 켠 뒤 진짜 CLI를 실행한다.”
shim은 오래된, 그리고 아주 견고한 유닉스 패턴이다. PATH 앞쪽에 같은 이름의 실행 파일을 심어 두면, 사용자가 claude 를 치는 순간 진짜 claude 대신 내 껍데기가 먼저 잡힌다. ~/.zeude/bin 을 PATH 최상단에 두는 이유가 이것이다.
가로챈 shim이 하는 일은 세 박자다.
가로채기 → 빠른 동기화 + 텔레메트리 ON → 진짜 CLI exec
- 가로채기 — 사용자는 평소처럼
claude나codex를 친다. 명령을 바꾸지 않는다. 학습 비용 0. - 빠른 동기화 + 텔레메트리 ON — 진짜 CLI가 뜨기 전에, shim이 최신 스킬(그리고 Claude라면 훅·MCP까지)을 끌어오고 OTEL 텔레메트리를 켠다. “빠른”이 중요하다. 이 앞단이 무거우면 매 호출마다 체감 지연이 되고, 사람들은 shim을 우회할 방법부터 찾는다.
- 진짜 CLI exec — 마지막으로 shim은 자기 자신을 진짜 바이너리로 교체(exec) 한다. 감싸는 게 아니라 자리를 내준다. 그래서 진짜 CLI의 동작·종료 코드·TTY 처리에 아무 흠집이 없다.
이 설계의 미덕은 비침투성이다. CLI를 포크하지도, 패치하지도, 래핑 프로세스로 감싸 두지도 않는다. 벤더가 내일 claude 를 새 버전으로 갈아도 shim은 그대로 산다 — 그저 앞에서 잠깐 일하고 비켜설 뿐이니까. 지난 글에서 말한 “런타임으로부터의 결합 끊기”가 여기선 가장 얇은 형태 로 구현된다. 어댑터조차 필요 없다. PATH 한 줄이면 된다.
2. claude vs codex — 둘 다, 단 범위는 다르다
“둘 다 OTEL을 같은 ClickHouse로 보냈다(같은 사용자로 묶임). 동기화는 Claude=skills+hooks+MCP, Codex=skills만.”
shim은 한 종류의 CLI만 감싸지 않는다. claude 와 codex 를 둘 다 감싼다. 그런데 두 축에서 대칭이 깨진다 — 하나는 의도적으로 같게, 하나는 어쩔 수 없이 다르게.
텔레메트리는 같은 곳으로. 두 CLI 모두 OTEL(OpenTelemetry) 신호를 같은 ClickHouse 로 흘려보낸다. 그리고 결정적으로, 같은 사용자로 묶인다. 내가 오전엔 Claude로 리팩터링하고 오후엔 Codex로 테스트를 돌려도, 리더보드 위에서 나는 한 사람이다. 도구가 갈라져도 사람은 갈라지지 않는다. 채택률·사용량을 사람 단위로 정직하게 집계하려면 이 “같은 사용자로 묶임”이 반드시 있어야 한다.
동기화 범위는 다르다. 여기선 대칭을 강제할 수 없다.
Claude = skills + hooks + MCP
Codex = skills (hooks·MCP는 Claude 전용)
- skills — 두 CLI에 공통. 그래서 스킬은 두 진영 어디서든 동기화되고, 뒤에 나올 리더보드도 스킬을 축으로 삼는다. 공통분모가 곧 측정 단위가 된다.
- hooks·MCP — Claude Code에만 있는 확장 지점이다. Codex에는 대응물이 없으니 shim도 억지로 만들어 내지 않는다. 있는 것만 동기화하고, 없는 것은 없는 대로 둔다.
이게 정직한 설계다. 두 도구를 하나인 척 추상화해 버리면, 없는 기능을 흉내 내느라 shim이 뚱뚱해지고 결국 양쪽 다 제대로 못 굴린다. 대신 공통은 공통대로, 고유는 고유대로 둔다. 측정과 순위는 공통분모(skills) 위에서만 공정하게 성립하고, 각 CLI의 고유 능력은 그대로 살아남는다.
3. 리더보드 — 누가 만든 스킬이 얼마나
“스킬별 사용량·사용자 수가 랭킹된다. 비개발자가 만든 스킬이 오르면 엔지니어 마인드가 퍼진다 = 동기3.”
ClickHouse에 쌓인 신호는 그냥 로그가 아니다. 스킬 리더보드가 된다. 스킬마다 얼마나 많이 실행됐는지, 몇 명이 쓰는지 가 순위로 드러난다.
여기서 이 시스템의 진짜 의도가 나온다. 리더보드의 목적은 “누가 CLI를 많이 쓰나”를 줄 세우는 게 아니다. 목적은 좋은 스킬이 눈에 보이게 하는 것이다. 그리고 그 가시성이 만드는 연쇄가 이 그림이 말하는 동기3이다.
스킬 랭킹 → 비개발자가 만든 스킬이 오름 → "나도 만들 수 있네" → 엔지니어 마인드 확산
디자이너가, 기획자가, 마케터가 만든 스킬이 리더보드 상단에 걸리는 순간 — 그건 단순한 순위가 아니라 증거다. “코드 몰라도, 문제를 자동화 가능한 절차로 쪼개면 남들이 쓴다”는 증거. 엔지니어링은 언어가 아니라 사고방식이라는 걸, 리더보드가 조용히 증명한다. 상위권 스킬이 비개발자에게서 나올수록 그 사고방식은 조직에 더 넓게 퍼진다. 리더보드는 랭킹 도구가 아니라 문화 전파 장치다.
4. 케어 — 못 쓰는 사람을 돕는다
“채택률·미사용자가 보이니 감시가 아니라 케어로 쓴다 = 동기2.”
같은 텔레메트리가 반대편에서 만드는 게 동기2다. 리더보드가 잘 쓰는 사람 을 비추면, 채택률 지표는 필연적으로 안 쓰는 사람 도 비춘다. 여기서 모든 관측 시스템이 마주하는 갈림길이 온다.
“안 쓰는 사람이 보인다” 는 사실은 두 방향으로 쓸 수 있다.
- 감시로 — “너 왜 안 써? 왜 성과가 낮아?” 실적 압박의 근거로.
- 케어로 — “이 사람은 왜 막혔지? 온보딩이 부족했나, 스킬이 그의 일에 안 맞나, 초반에 한 번 데였나?”
이 시스템은 명시적으로 후자를 택한다. 미사용은 잘못이 아니라 신호다 — 대개는 도구가 그 사람의 맥락에 아직 닿지 못했다는 신호. 채택률이 낮은 팀이 보이면 벌점이 아니라 핸즈온 세션이 가고, 특정 스킬만 안 쓰이면 그 스킬의 문서·발견성을 손본다.
관측 데이터의 성격은 데이터가 아니라 그걸로 무엇을 하기로 했는가 가 정한다. 같은 채택률 숫자가 감시의 무기도, 케어의 지도도 된다. 이 시스템은 지도 쪽을 골랐다.
네 칸을 잇는 한 줄
정리하면, 이 그림은 하나의 얇은 개입이 만드는 네 가지 결과다.
- shim —
PATH앞 껍데기 하나로, CLI를 건드리지 않고 동기화와 텔레메트리를 심는다. (비침투) - claude vs codex — 둘 다 감싸되, 텔레메트리는 같은 곳·같은 사람으로 모으고 동기화는 각자 있는 만큼만. (정직한 비대칭)
- 리더보드(동기3) — 좋은 스킬을 눈에 보이게 해, 비개발자발(發) 자동화가 엔지니어 마인드를 퍼뜨리게 한다. (문화 전파)
- 케어(동기2) — 같은 지표의 뒷면으로 막힌 사람을 찾아 돕는다. 감시가 아니라 케어. (사람 중심)
동기1은 그림 밖의 가장 당연한 층 이다 — 모두의 스킬·훅·MCP를 자동으로 최신·표준으로 맞추는 것. 하지만 이 설계가 흥미로운 이유는 그 당연한 동기화 파이프라인 하나에 동기2(케어)와 동기3(마인드 확산) 을 공짜로 얹었다는 데 있다. 텔레메트리는 이미 흐르고 있으니까. 데이터는 이미 한 사람으로 묶여 있으니까.
가장 얇은 개입(shim 하나)이, 가장 두꺼운 결과(도구 표준화 + 문화 전파 + 사람 케어)를 만든다. 좋은 인프라는 대개 이렇게 생겼다 — 눈에 안 띄는 곳에서 조용히, 그러나 위로 갈수록 넓게.