mattpocock 40K skills 안 쓰고 14 OpenClaw 유지하는 이유 — 갈라파고스 위험 인정

mattpocock 40K skills 안 쓰고 14 OpenClaw 유지하는 이유 - 갈라파고스 위험 인정

결단부터 적는다

mattpocock skills가 GitHub 40,670 star를 찍었다 (gh API 2026-05-02 기준). 그런데 나는 16개를 다 안 가져갔고, 1개도 측정해본 적 없다. 내 14 OpenClaw를 유지한다.

이 글은 “왜 mattpocock이 안 좋은가”가 아니라 “왜 나는 더 좋을 수도 있는 도구를 안 쓰고 내 도구를 쓰는가”의 답이다. 핵심은 두 줄이다.

  • 14 OpenClaw가 mattpocock 16개보다 우월하다는 근거는 없다.
  • 한국어 사용자 시장만 남는다. 규모도 작다 — Threads 한국어 Claude Code 글이 일주일 100~300건, r/ClaudeAI는 일주일 5,000건+ (체감 비율 약 1:20, trend-scout 측정). 이게 갈라파고스 틈새의 다른 이름일 가능성을 인정한다.

한 번쯤 따라가볼까 망설인 적 있다면

GitHub Trending에서 mattpocock을 본 적이 있다면 “이거 다 가져다 써야 하나” 한 번쯤 망설인 적이 있을 것이다. r/ClaudeAI에서 매일 올라오는 후기 글을 읽은 적이 있다면 흡수 욕구가 더 커진 적도 있을 것이다. 영어권 표준이 한국어 환경을 다 덮을지 걱정한 적이 있다면, 이 글이 다른 결정을 내리는 사례 하나를 보여준다. 동의하지 않아도 좋다.

객관적 우위 없음 — 그럼에도 유지하는 이유

mattpocock 16개 중 grill-me, diagnose, improve-codebase-architecture, zoom-out, caveman 같은 것들은 한국어 환경에서도 작동할 가능성이 높다. 검증한 적은 없다. “한국어라 안 맞을 것”이라는 가설은 약하다. AI 에이전트의 한/영 처리 격차는 모델별로 다르고 줄어드는 추세다 (Anthropic Opus 4.7 기준 한국어 토큰이 영어 대비 약 1.3배 — 절대 격차는 아니다).

그러면 왜 안 갈아타는가. 답은 도구 우월성이 아니라 사용자 시장이다.

내 14 OpenClaw는 한국어 SEO·블로그·콘텐츠 자동화·trend-mine 같은 한국 시장 전용 워크플로우에 묶여 있다. mattpocock으로 갈아타려면 14개 중 한국 시장 전용 도구 9-10개를 그의 영어 프레임 위에 다시 올려야 한다. 비용은 크고, 영어권 표준 합류 효과는 측정한 적 없다.

따라서 “지금 갈아타지 않는다”는 결정은 합리적이지만 위험을 동반한다. 갈라파고스 위험이다.

갈라파고스 위험 — 5가지

10년 뷰에서 한국어 단일 시장에 안주하는 비용은 다음과 같다.

  1. 표준에서 멀어짐. 영어권 AI 코딩 에이전트 표준은 분기에 한 번씩 새로 등장한다 (2026년 1분기에만 GSD, BMAD, Spec-Kit, mattpocock skills 4건). 한국어 사용자는 N달 늦게 받는다.
  2. AI 에이전트 시대 무효. AI 에이전트가 주체가 되면 한국어/영어 구분 자체가 인간 시대 유물이 된다. 한국어 전용 도구는 영어로 직접 일하는 에이전트에게 무의미해진다.
  3. 셋째는 사용자 시장이다. 한국 vibe coder가 영어권 표준 쪽으로 빠지면 14 OpenClaw 사용자도 따라 빠진다 — 한 명씩 조용히.
  4. 인재 밀어냄. 영어권 표준에 합류하려는 개발자는 한국 시장 전용 도구를 외면한다. 도구 운영자는 점점 좁은 사용자층에 갇힌다.
  5. 개선 속도 느려짐. mattpocock 같은 표준 레포는 외부 PR이 빠르게 들어온다. 좁은 시장은 소수 사용자가 주는 피드백만 받는다.

위 5가지는 가설이 아니라 갈라파고스화 사례에서 반복 관찰된다 (일본 피처폰의 스마트폰 전환기 격차, 한국 액티브X 표준 격리). 인정 안 하면 확증 편향(confirmation bias)이다.

해지 임계 — 갈아탈 조건

“지금은 유지”가 영구 결정은 아니다. 다음 셋 중 하나라도 충족되면 14 OpenClaw 일부 또는 전부를 mattpocock 표준으로 교체한다.

  • 조건 1. mattpocock grill-me를 1주 측정해서 CLAUDE.md “State Assumptions” 룰보다 재작성 횟수 50%+ 줄이면 → CLAUDE.md 룰 폐기, mattpocock 흡수.
  • 조건 2. 14 OpenClaw 사용자 중 영어권 비중이 30% 넘으면 → 영어 레이어 추가 또는 mattpocock 호환 모드 검토.
  • 조건 3. AI 에이전트가 한국어 워크플로우를 영어 도구 위에서 직접 처리하는 게 안정화되면 → 한국어 전용 레이어 자체 폐지, 사용자 시장이 인간이 아니라 에이전트가 된 시점.

조건 1은 측정만 하면 답 나온다. 5월 9일까지 작업 10건에 grill-me를 적용하고 같은 기간 5건은 기존 “State Assumptions” 룰 유지, 재작성 횟수 비교 결과를 5월 12일에 발행한다. 조건 2-3은 시장·기술이 정해줄 부분이다.

Q&A

Q. 측정도 안 했으면서 “안 갈아탄다”는 결정을 하는 건 확증 편향 아닌가?
A. 그렇다. 본문에 인정한다. 다만 갈아타기의 비용(한국 시장 전용 9-10개를 영어 프레임 위로 재구축)이 크다는 비측정 추정은 합리적이다. 측정 후 폐기 옵션이 조건 1에 명시되어 있다.

Q. 14 OpenClaw가 mattpocock 16개보다 객관적으로 어디가 우월한가?
A. 우월하지 않다. 한국어 콘텐츠/마케팅 도메인에 묶여 있다는 점이 다를 뿐이다. 도메인 차별성은 우월성이 아니라 사용자 시장이다.

Q. 갈라파고스 위험을 알고도 유지한다는 게 무책임 아닌가?
A. 무책임이 맞을 수 있다. 다만 한국 시장 전용 도구(trend-scout 한국어 키워드, blogspot SEO, naver-keyword-finder)는 영어 프레임으로 옮길 때 손실이 크고, 그 손실을 “갈라파고스 비용”보다 더 직접적이라고 본다. 손실 비교가 측정으로 뒤집히면 갈아탄다.

Q. AI 에이전트 시대에 한국어 전용 도구가 무의미해진다면 지금부터 폐지해야 하지 않나?
A. 그 시점이 언제인지 측정한 적 없다. 조건 3 충족이 그 시점이다. 너무 일찍 폐지하면 현 사용자 시장이 무너지고, 너무 늦게 폐지하면 갈라파고스에 갇힌다. 1년에 1회 재검토.

결론

이 글은 mattpocock을 깎으려는 글이 아니다. 40K star는 가치 + Total TypeScript 60K 뉴스레터 + 안티-vibe coding 타이밍이 합친 결과이고, 16개 중 다수가 영어권 워크플로우에서 그대로 좋은 도구다.

다만 나는 실측 0건 위에서 “한국 시장 전용 도구를 영어 프레임 위로 재구축할 비용이 더 크다”는 비측정 추정을 따라 14 OpenClaw를 유지한다. 갈라파고스 위험을 인정하고, 해지 임계 3개를 명시한다. 측정 한 번이 결정을 뒤집을 수 있다.

다음 행동은 grill-me 1주 실측이다. 5월 9일 데이터 마감, 5월 12일 후속 글 발행. 그 글이 나오기 전까지 이 결정은 가설이다.

관련 글과 저자

관련 글

저자

cd4761 — Claude Code, AI 에이전트, 한국어 콘텐츠 자동화를 다룬다. 측정 안 한 결정은 가설로 표시하고, 측정 후 갱신한다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "측정도 안 했으면서 안 갈아탄다는 결정은 확증 편향 아닌가?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "그렇다. 본문에 인정한다. 다만 갈아타기의 비용이 크다는 비측정 추정은 합리적이고, 측정 후 폐기 옵션이 해지 임계 조건 1에 명시되어 있다."
      }
    },
    {
      "@type": "Question",
      "name": "14 OpenClaw가 mattpocock 16개보다 객관적으로 어디가 우월한가?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "우월하지 않다. 한국어 콘텐츠·마케팅 도메인에 묶여 있다는 점이 다를 뿐이다. 도메인 차별성은 우월성이 아니라 사용자 시장이다."
      }
    },
    {
      "@type": "Question",
      "name": "갈라파고스 위험을 알고도 유지한다는 게 무책임 아닌가?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "무책임이 맞을 수 있다. 다만 한국 시장 전용 도구를 영어 프레임으로 옮길 때 손실이 더 직접적이라고 본다. 손실 비교가 측정으로 뒤집히면 갈아탄다."
      }
    },
    {
      "@type": "Question",
      "name": "AI 에이전트 시대에 한국어 전용 도구가 무의미해진다면 지금부터 폐지해야 하지 않나?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "그 시점이 언제인지 측정한 적 없다. 너무 일찍 폐지하면 현 사용자 시장이 무너지고, 너무 늦게 폐지하면 갈라파고스에 갇힌다. 1년에 1회 재검토."
      }
    }
  ]
}
</script>

태그: #mattpocock #ClaudeCode #OpenClaw #갈라파고스 #AI에이전트 #Skills

댓글

댓글 쓰기

이 블로그의 인기 게시물

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

Claude Code로 블로그 발행 15분을 1줄로 — 해고 후 첫 자동화 경험

Claude Code로 블로그 자동 발행 스크립트를 만드는 방법이다. 마크다운 파일을 터미널에서 명령어 한 줄로 Blogspot에 발행한다. Google Cloud Console 설정 10분, Claude Code에 지시 20분, 테스트 5분이면 끝난다. 코드를 직접 쓰지 않고 Claude Code에게 지시만 해서 만들었다. Claude Code가 뭔가 터미널에서 “블로그 발행 자동화해줘”라고 치면 스크립트를 만들어주는 AI 코딩 도구다. Anthropic이 만들었다. IDE 플러그인이 아니라 독립 CLI 도구다. 프로젝트 폴더 전체를 읽고, 파일을 직접 생성하고 수정하고 실행까지 한다. 블로그 글 1편 올리는 데 15분이 걸렸다 Blogspot에 글을 올리려면 마크다운 → HTML 변환 → Blogger 접속 → 제목 입력 → HTML 모드 전환 → 본문 붙여넣기 → 라벨 설정 → 검색 설명 → 미리보기 → 발행. 1편에 15분. 한 달에 30편이면 7시간 이상을 “올리는 작업”에만 쓰는 셈이다. 글 쓰는 시간보다 올리는 시간이 더 길었다. 이걸 Claude Code에게 맡겼다. Claude Code에게 한 지시 터미널에서 Claude Code를 열고 이렇게 말했다: “마크다운 파일을 Blogger API v3으로 자동 발행하는 Python 스크립트를 만들어줘. frontmatter에서 제목, 라벨, 슬러그를 읽고, 마크다운을 HTML로 변환한 뒤, OAuth 2.0으로 인증해서 Blogger에 POST해줘. dry-run 옵션도 넣어줘.” Claude Code가 만든 것: publish.py 메인 스크립트 (약 200줄) requirements.txt 의존성 목록 config.json 설정 파일 OAuth(구글 로그인 인증) 흐름 (최초 1회 브라우저 인증 → 이후 자동) dry-run 모드 (발행 없이 HTML 미리보기) ...
자세한 내용 보기

맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기