Claude Code化라는 동사 — 일본 Qiita 5월의 풍경과 ‘agentic IDE’의 표준화

2026년 5월의 일본 개발자 커뮤니티는 왜 지금 Claude Code 운용 노하우에 매달리고 있는가. 그리고 “Claude Code化”라는 새 동사는 단순한 모방인가, 아니면 agentic IDE 라는 카테고리가 표준 패턴을 굳히고 있다는 신호인가.

도입 — 동사가 된 제품명

5월 둘째 주의 Qiita 트렌드 페이지를 위에서부터 읽어 내려가 보면, 묘한 공통점이 눈에 들어온다. 인기 상위 글의 절반 가까이가 Claude Code를 다루고 있다. 그 자체는 놀랍지 않다. 작년 가을 이후 Anthropic의 코딩 에이전트는 사실상 일본 엔지니어들이 가장 많이 손대는 도구가 되었다. 놀라운 것은 글의 결이다. “어떻게 시작하는가”나 “X와 비교하면”이 아니라, “어떻게 120% 짜내는가”, “어떻게 다른 도구를 Claude Code화하는가”, “어떻게 비용을 줄이면서 같은 효과를 내는가” 같은 운용 측면의 노하우가 줄지어 있다.

manchan이 5월 초에 올린 “Claude Code를 120% 사용 마스터하는 설정 3선[ECC・Memory.md・Obsidian 연계]“은 79 LGTM 을 받으며 한 주 동안 Qiita 코딩 카테고리 상위에 머물렀다. katohiro_fi의 “Copilot Studio를 Claude Code化 했더니, Copilot Studio 자신이 Power Platform을 구축할 수 있었다”는 글은 64 LGTM, faunsu의 “ChatGPT Pro 는 비싸니까 Codex + GitHub Copilot 으로 용돈을 지키고 싶다”는 51 LGTM 을 모았다. 같은 주에 올라온 세 편이 다루는 내용은 전부 다른데, 한 가지 단어가 공통적으로 등장한다. Claude Code化.

여기서 “化”는 “Claude Code 처럼 만든다”는 뜻이지만, 좀 더 정확히 읽으면 “agentic 코딩 에이전트의 표준 사용 방식 을 다른 도구에 이식한다”는 뜻에 가깝다. Copilot Studio 를 “Claude Code化” 했다는 표현은, Claude Code 가 무엇을 표준 패턴으로 굳혀 놓았는지를 역으로 보여 준다. 로컬 파일 읽기와 쓰기, 셸 명령 실행, 글로브 검색, grep, 그리고 그 모든 것을 자연어 지시로 묶는 워크플로. 이 묶음이 이제 한 회사의 제품이 아니라, 카테고리 자체의 정의가 되어 가고 있다.

이 글은 5월 일본 Qiita 의 인기 글 세 편을 토대로, 일본 엔지니어들이 지금 Claude Code 와 어떻게 살고 있는가를 정리한다. 그 다음에 왜 일본 커뮤니티가 이 분야에서 노하우를 빠르게 쌓고 있는가를 따져 보고, 마지막으로 “Claude Code化”라는 동사화가 IT 산업 전체에 무엇을 의미하는지 묻는다.

본문 1 — 일본 Qiita 5월의 세 편: ECC, Memory.md, Codex+Copilot 의 실용주의

먼저 manchan 의 글부터 보자. “Claude Code 를 120% 사용 마스터하는 설정 3선” 이라는 제목 그대로, 그가 자신의 환경에서 굳히고 있는 세 가지 설정을 정리한 글이다. 이름이 낯설지만 내용은 단순하다.

첫째, Everything Claude Code(ECC). GreatScotty44 라는 깃허브 사용자가 공개한 설정 모음으로, git clone 한 다음 ./install.sh --profile full 만 실행하면 에이전트 48개, 커맨드 79개, 스킬 149개가 한꺼번에 깔린다. 핵심은 code-reviewer, security-reviewer, planner 같은 전문가 에이전트를 자동으로 호출해 주는 라우팅 레이어다. manchan 은 자신의 자동화 도구에서 X(트위터) API 키와 YouTube OAuth 토큰을 잘못된 위치에 두었던 실수를 security-reviewer 가 잡아 줬다고 적었다. “X APIキー・YouTube OAuthトークンの扱いを自動チェック。.env への移動漏れを指摘(X API 키와 YouTube OAuth 토큰의 취급을 자동 검사. .env 로 이동하지 않은 부분을 지적했다)“는 한 줄은, 이 류의 도구가 작동했을 때 무엇을 해 주는지를 가장 짧게 보여 준다. 한국 커뮤니티에서는 ECC 라는 이름조차 거의 회자되지 않지만, 일본에서는 5월 들어 이 묶음을 자기 환경에 통째로 깔아 두는 흐름이 굳어지고 있다.

둘째, CLAUDE.md + Memory.md 이중 구조. CLAUDE.md 에는 작업 규칙과 역할을 정의해 두고, Memory.md 에는 프로젝트의 현재 상황·기술 스택·완료한 자동화·환경 변수 위치·미완료 작업 목록을 적어 둔다. CLAUDE.md 는 정책이 바뀔 때만 손대고, Memory.md 는 세션마다 갱신한다. 핵심은 CLAUDE.md 첫 줄에 “セッション開始時に必ずMemory.mdを読み込む(세션 개시 시 반드시 Memory.md 를 읽어들일 것)“이라고 못박아 두는 것이다. 이렇게 해 두면 새 세션에서 “전회 세션을 재개해 줘” 한 마디만으로 Claude 가 자동으로 Memory.md 를 먼저 로드한다. 이 패턴은 사실상 사용자가 손으로 만드는 미니 RAG 다. Anthropic 이 공식 메모리 기능을 베타로 풀고 있지만, 일본 사용자들은 그것을 기다리지 않고 마크다운 파일 두 개로 같은 효과를 내고 있다.

셋째, Obsidian 연계. manchan 은 docs/AI-DataBase/ 아래에 news/, raw-sources/, wiki/ 세 폴더를 만들고, 매일 아침 8 시에 collect_news.py 가 launchd 로 돌아가면서 Zenn 과 Qiita 의 Claude Code 태그 글을 자동 수집해 Markdown 으로 떨어뜨린다. 그러면 Claude 가 이 폴더를 읽어 Wikilinks 와 Callouts 가 정확하게 들어간 정리 노트를 wiki/ 에 적어 둔다. Obsidian 의 노트 그래프와 Claude 의 자연어 요약이 결합하는 구조다. kepano 의 obsidian-skills 를 ~/.claude/skills/ 에 그대로 복사해 쓰는 점도 인상적이다. 한국에서는 Notion 이나 Roam 이 대중화되긴 했지만, “Claude 가 직접 Obsidian 마크다운으로 적게” 만드는 패턴은 일본 쪽이 훨씬 빠르게 표준화되고 있다.

다음은 katohiro_fi 의 “Copilot Studio 의 Claude Code化”. Microsoft 의 Taiki Yoshida 가 공개한 copilot-studio-code 라는 MCP(Model Context Protocol) 서버가 등장점이다. 이 MCP 서버는 Copilot Studio 에 read_file, write_file, run_shell, glob, grep 같은 도구를 붙여 준다. 즉 Copilot Studio 의 대화창에서 직접 로컬 파일을 읽고 Python 스크립트를 돌릴 수 있게 된다. 클라우드 쪽 Copilot Studio 가 로컬 MCP 서버에 닿기 위해서는 Microsoft 의 Dev Tunnel 로 HTTPS 경로를 열어 둔다.

저자는 여기에 Hiromichi Fujiwara 의 CodeAppsDevelopmentStandard 리포지토리를 결합했다. 그러고 나서 한 줄을 입력했다. “종업원 온보딩 도구를 Power Platform 으로 만들고 싶다.” 그 한 줄로 Copilot Studio 는 Dataverse 테이블을 자동 설계해 만들고, 대량의 .tsx 파일을 작성하고, TypeScript 빌드 에러를 자기가 고치고, Power Apps 앱을 배포하고, 마지막에는 자동 생성한 아이콘까지 붙여 Copilot Studio 에이전트를 구축했다. 저자가 이 글에 단 부제는 한 줄로 모든 걸 요약한다. “Copilot Studio が Copilot Studio を作る(Copilot Studio 가 Copilot Studio 를 만든다).” 5월 Qiita 의 인기 글 가운데 가장 강렬한 한 줄이다.

물론 한계도 또렷하다. 저자는 같은 글에서 “直近 10 ターンの会話履歴を参照する(직전 10 턴의 대화 이력만 참조한다)“는 제약을 분명히 적었다. Copilot Studio 는 AI 코딩용으로 설계된 게 아니어서 토큰 한계가 낮고, 10 턴이 지나면 앞에서 합의한 설계 내용이 사라져 다시 입력해야 한다. 재현성도 낮아 PoC 수준이라고 본인이 인정한다. 하지만 그렇다고 해서 이 시도의 의미가 줄어들지는 않는다. “Copilot Studio 정도의 닫힌 환경도 Claude Code 의 도구 호출 패턴을 입혀 주면 작동한다”는 사실 자체가, agentic IDE 의 표준 인터페이스가 굳어지고 있다는 신호이기 때문이다.

세 번째 글, faunsu 의 “ChatGPT Pro 는 비싸니까 Codex + GitHub Copilot 으로 용돈을 지키고 싶다”는 분위기가 다르다. 이 글은 Claude Code 를 직접 다루지는 않지만, 일본 개발자들이 같은 시기에 어떻게 비용 최적화 노하우를 굳히고 있는지를 보여 준다는 점에서 묶어 볼 가치가 있다. 저자는 Codex 를 “실행자”가 아니라 “지시자 겸 리뷰어”로 쓰고, 실제 구현은 GitHub Copilot CLI 에 맡기는 분업 구조를 제시한다. ChatGPT 와 GitHub MCP 로 사전 조사와 이슈 정리를 마친 후 Codex 에 진입하므로, Codex 가 처음부터 코드베이스를 탐색하면서 토큰을 낭비하는 일을 막는다는 것이다.

월간 비용은 ChatGPT Plus ¥3,000 + GitHub Copilot Pro 약 ¥1,500, 합계 약 ¥4,500 으로 끝난다. ChatGPT Pro 단독 구독보다 훨씬 싸다. 저자가 적은 한 줄, “Codex のトークンを「全部の作業」に使うのではなく、「判断が必要な所」に寄せられます(Codex 의 토큰을 ‘모든 작업’에 쓰는 게 아니라 ‘판단이 필요한 곳’에 몰아 쓸 수 있습니다)“는 이 류의 글이 공유하는 미학을 드러낸다. 비싼 추론 토큰을 어디에 어떻게 배치할 것인가가 새로운 엔지니어링 능력이 되었다는 것이다. 그리고 같은 저자가 던지는 질문, “トークンの消費を気にして Plan モードを経由せずにそのまま開始していませんか？(토큰 소비가 신경 쓰여서 Plan 모드를 거치지 않고 바로 시작하지는 않았습니까?)”는 일본 커뮤니티에서 5월에 부상한 또 하나의 합의를 드러낸다. Plan 모드를 건너뛰지 마라. 시간을 아끼는 것처럼 보여도 결국 토큰을 더 쓰게 된다는 경험치다.

본문 2 — 왜 일본 커뮤니티에서 이 노하우가 먼저 굳어지는가

세 글에 공통으로 흐르는 정서가 있다. 새 도구가 나오면 일단 자기 환경에 맞춰 끝까지 짜낸다는 태도, 그것을 Qiita 에 글로 정리해 LGTM 으로 합의를 굳힌다는 패턴이다. 한국과 비교하면 이 사이클의 속도와 밀도가 다르다. 한국에서 Claude Code 를 다루는 글은 대체로 “써 봤더니” 또는 “X 와 비교하면” 류에 머물러 있다. 일본 쪽은 어느새 “내 워크플로의 어디에 어떻게 박아 넣었는가”로 한 단계 들어가 있다. 왜 그럴까.

첫 번째 이유는 노트 도구 문화의 차이다. 일본 엔지니어 커뮤니티에는 Obsidian, Logseq, Scrapbox 같은 로컬 마크다운 노트 도구를 일상적으로 쓰는 비중이 한국보다 훨씬 높다. 회사 위키가 Confluence 로 굳어 있어도 개인 지식은 로컬 마크다운으로 쌓아 두는 사람이 많다. 이 토양 위에서는 “Claude 가 직접 Obsidian 노트로 적게” 같은 패턴이 자연스럽게 떠오른다. 반대로 노트 자체가 클라우드 SaaS 안에 잠겨 있는 환경에서는, AI 가 노트를 직접 다루는 워크플로를 상상하기 어렵다. manchan 의 docs/AI-DataBase/ 폴더 구조는 그 자체로는 평범하지만, 그 평범함이 일본 엔지니어들의 평균적 환경에 깔려 있다는 점이 결정적이다.

두 번째 이유는 노트 자동화 전통이다. 일본에는 launchd, cron, AppleScript, Hammerspoon 같은 도구로 자기 환경을 잘게 자동화하는 문화가 오래 이어져 왔다. 매일 아침 8 시에 뉴스 수집 스크립트가 도는 것은 이 문화에서 보면 새 일이 아니다. Claude Code 같은 에이전트가 추가되어도 그 자리에 자연스럽게 들어간다. 일본 IT 매체에서 “정시 자동화”라는 표현이 자주 쓰이는 것도 같은 맥락이다. 한국 쪽은 “자동화”라고 하면 GitHub Actions 나 Slack 봇 같은 클라우드 기반 자동화를 먼저 떠올리는 경향이 강하다. 로컬에서 launchd 가 매일 돌고 있는 풍경이 흔하지 않다.

세 번째 이유는 “120% 사용”의 미학이다. manchan 의 제목 “120% 使い倒す(120% 짜낸다)“는 일본 엔지니어 커뮤니티에서 자주 쓰이는 표현이다. 도구를 100% 가 아니라 120% 까지 짜내겠다는 태도, 곧 도구가 공식적으로 의도한 사용법을 넘어서까지 활용 범위를 밀어붙인다는 미학이다. 이것은 단순히 “잘 쓴다”가 아니라 “내 환경에 맞춰 재구성한다”는 차원의 작업이다. ECC 같은 비공식 설정 모음을 자기 환경에 통째로 깔아 시험하는 것도, Copilot Studio 라는 닫힌 도구에 MCP 서버를 강제로 끼워 Claude Code 처럼 만드는 것도, 같은 미학에서 나온다.

네 번째 이유는 Qiita 라는 플랫폼의 효과다. Qiita 는 LGTM 이라는 단순한 합의 메커니즘을 통해 “이 노하우는 우리 커뮤니티가 인정한다”는 신호를 빠르게 만든다. 한국의 velog 나 tistory 는 좋은 글들이 많지만, 같은 도구를 다루는 사람들이 한 자리에 모여 LGTM 을 통해 공유 합의를 만드는 구조는 약하다. Qiita 의 태그 시스템과 LGTM 은 “Claude Code 라는 도구의 운용에서 이 정도가 표준이다”라는 공통 감각을 빠르게 빚어낸다. 한 사람이 글을 올리면 다음 주에 또 다른 사람이 그 글을 인용하면서 자기 변형을 더한다. 이 사이클이 한 달이면 두세 바퀴 돈다.

다섯 번째 이유는 모델 개발사가 일본어 커뮤니티에 직접 다가오고 있다는 점이다. Anthropic 도 OpenAI 도 5월 들어 일본 도쿄에서 개발자 행사를 잇따라 열고 있다. Microsoft 의 Taiki Yoshida 가 copilot-studio-code 같은 사이드 프로젝트를 공개하는 것도 같은 맥락이다. 일본은 더 이상 영어권에서 유행한 노하우가 한 박자 늦게 들어오는 시장이 아니라, 자체적으로 노하우를 만들어 영어권으로 다시 흘려 보내는 시장이 되어 가고 있다. ECC 의 GitHub 리포지토리 스타 분포를 보면 일본 사용자 비중이 눈에 띄게 높다. obsidian-skills 의 일본어 fork 는 본가보다 더 활발하게 갱신되고 있다.

다만 이 일본 우위가 영원할 거라고 보기는 어렵다. 한국 커뮤니티도 5월 들어 비슷한 글들이 늘기 시작했다. 다만 한국은 “최신 모델로 무엇을 할 수 있는가”에 집중하는 흐름이 여전히 강하고, “내 환경에서 어떻게 짜낼 것인가”의 노하우가 굳어지는 속도가 한 박자 느릴 뿐이다. 이 속도 차이는 결국 도구를 운영하는 사람들이 공유하는 합의의 두께 차이로 귀결된다. 그 두께는 한 번 벌어지면 좁히기 어렵다. 일본 쪽이 이미 “Memory.md 는 매 세션 갱신한다”는 합의를 굳혀 놓은 사이에, 한국에서 그 합의가 비슷한 두께에 도달하려면 두세 분기는 더 필요할 것이다.

본문 3 — “Claude Code化”라는 동사: agentic IDE 카테고리가 표준 패턴을 굳히고 있다

여기서 다시 katohiro_fi 의 글로 돌아가자. “Copilot Studio が Copilot Studio を作る”라는 한 줄에는 두 겹의 의미가 있다. 표면 의미는 Copilot Studio 자체가 Power Platform 위에서 또 다른 Copilot Studio 에이전트를 만든다는 자기 참조 구조다. 한 겹 더 들어가면, Copilot Studio 라는 Microsoft 의 닫힌 SaaS 가 Anthropic 의 Claude Code 가 정의한 사용 패턴을 입어야 비로소 그렇게 행동할 수 있었다는 뜻이다. 즉 Microsoft 가 자기 도구의 표준 사용법을 Microsoft 가 아니라 Anthropic 에게 빌려 온 셈이다.

이 사실을 가볍게 보면 안 된다. 작년까지만 해도 “AI 코딩 도구”의 카테고리 정의는 GitHub Copilot 이 쥐고 있었다. 인라인 자동완성이 그 정의의 핵심이었다. Cursor 가 그 정의를 한 단계 옮겼다. 채팅 패널과 멀티 파일 편집이 추가됐다. 그리고 Claude Code 가 또 한 단계 옮겼다. 터미널을 일급 인터페이스로 두고, 셸 명령과 파일 읽기·쓰기·검색을 자연어 지시로 묶는다는 패턴이 표준이 되었다. 5월의 Copilot Studio “Claude Code化” 사례는 Microsoft 가 이 새 표준을 인정하고 자기 도구도 거기에 맞춰 가고 있다는 가시적 신호다.

이런 카테고리 표준화는 IT 산업의 다른 사례와 닮아 있다. PaaS 가 Heroku 의 사용 패턴을 표준으로 삼다가 Cloud Foundry, OpenShift, Vercel 로 분화한 흐름과 비슷하다. 컨테이너 오케스트레이션이 Kubernetes 의 manifest 와 controller 패턴을 표준으로 삼은 것과 같다. agentic IDE 카테고리에서는 Claude Code 의 “터미널 + MCP + 파일 도구 + Plan 모드”가 비슷한 위치에 있다. Cursor 는 이미 같은 방향으로 움직였고, Aider, Cline, Roo Code 같은 오픈 소스 도구도 같은 패턴으로 수렴하고 있다. 그리고 5월에는 Microsoft 의 Copilot Studio 까지 그 흐름에 들어왔다.

표준이 굳어진다는 것은 동시에 두 가지를 의미한다. 하나는 사용자에게는 좋은 일이다. 한 도구에서 익힌 패턴이 다른 도구에서도 통한다. CLAUDE.md 와 Memory.md 의 이중 구조는 Cursor 의 .cursorrules, Aider 의 .aider.conf.yml 과 사고방식이 동일하다. MCP 라는 외부 인터페이스 표준은 Anthropic 이 만들었지만, 이미 OpenAI 의 ChatGPT, Google 의 Gemini, Microsoft 의 Copilot Studio 가 모두 채택했거나 채택 중이다. 사용자는 한 번 익힌 노하우를 여러 도구로 옮길 수 있다. 일본 Qiita 글들에 정리된 노하우의 가치는 그래서 Claude Code 한정이 아니다. 곧 “agentic IDE 일반의 운용 노하우”가 된다.

다른 하나는 도구 공급자 입장에서 차별화 지점이 모델 자체에서 운영 ergonomics 로 옮겨 간다는 의미다. 모델 성능은 분기마다 한 단계씩 올라가지만, 이제 그 차이가 사용자 만족의 결정적 변수가 아니다. 결정적 변수는 메모리 관리의 자연스러움, MCP 도구 생태계의 두께, Plan 모드의 속도, 비용 가시화의 정밀함, 셸 명령 권한 모델의 안전함 같은 운영 측면이다. 5월의 일본 Qiita 글들이 모두 이런 운영 디테일을 다루고 있다는 사실은, 사용자들이 이미 모델 성능 비교에는 관심을 잃었다는 신호이기도 하다. 누가 먼저 운영 ergonomics 를 잘 풀어내느냐가 다음 분기의 승부가 된다.

여기에는 위험도 있다. 표준이 빠르게 굳어지면, 그 표준을 정의한 회사가 사실상 카테고리 게이트키퍼가 된다. Anthropic 은 모델 회사로 시작했지만, Claude Code 의 도구 호출 사양과 MCP 라는 인터페이스를 통해 사실상 카테고리 표준을 쥐어 가고 있다. 다른 모델을 쓰더라도 이 사양을 따라야 호환되는 구조가 굳어지면, 모델 시장의 경쟁이 카테고리 정의의 잠금에 묶일 위험이 있다. Microsoft 가 Copilot Studio 에 자체 표준을 강제하지 않고 MCP 를 그대로 받아들인 것은, 이 게이트가 이미 닫힌 뒤에 따라간 결정에 가깝다. Google 의 Gemini Code Assist 가 5월 들어 MCP 호환을 발표한 것도 같은 맥락이다.

결론 — 모델이 아니라 운영 노하우의 시대

처음의 두 질문으로 돌아가자. 일본 개발자 커뮤니티는 왜 지금 Claude Code 운용 노하우에 매달리는가. 그리고 “Claude Code化”라는 새 동사는 단순한 모방인가.

첫 번째 질문에 대한 답은 환경적이다. 로컬 마크다운 노트 문화, launchd 같은 작은 자동화의 전통, “120% 짜낸다”는 미학, Qiita 의 LGTM 합의 사이클, 그리고 모델 회사들이 일본 시장에 직접 다가오고 있는 흐름이 겹쳐 있다. 그 위에서 manchan, katohiro_fi, faunsu 같은 사람들이 자기 환경에서 만들어 낸 운영 노하우를 빠르게 글로 굳히고, 그 글이 다음 주의 노하우의 출발점이 된다. 한국 커뮤니티도 비슷한 사이클을 만들 수 있지만, 두세 분기는 늦은 자리에 서 있다.

두 번째 질문에 대한 답은 단순한 모방이 아니라는 것이다. Copilot Studio 의 “Claude Code化”는 Microsoft 가 새 카테고리의 표준을 인정한 사건이고, agentic IDE 라는 카테고리가 이제 한 회사의 제품이 아니라 산업 표준의 단계로 들어섰다는 신호다. 이 단계가 굳으면 도구 공급자의 차별화는 모델 성능이 아니라 운영 ergonomics 에서 결정된다. 메모리 관리, MCP 생태계, Plan 모드의 속도, 비용 가시화의 정밀함, 권한 모델의 안전함이 모델 벤치마크 점수보다 중요한 변수가 된다.

이 변화는 엔지니어 개인에게도 메시지를 남긴다. 다음 분기에 어떤 모델을 써야 할지 고민할 시간보다, 지금 손에 쥔 도구의 운영 패턴을 자기 환경에 맞춰 굳히는 시간이 더 가치 있다. Memory.md 한 장을 매 세션 갱신하기, Plan 모드를 거르지 않기, MCP 도구를 한두 개씩 자기 워크플로에 끼워 보기 같은 작은 습관이 다음 한 해의 생산성을 가른다. “Claude Code化”라는 동사는 우리에게 한 가지 사실을 다시 가르친다. 도구의 이름이 동사가 되는 순간, 그 도구는 더 이상 한 회사의 제품이 아니라 우리 모두의 작업 방식이 된다. 그리고 그 작업 방식을 누가 먼저, 누가 더 깊이 자기 환경에 박아 넣느냐가 다음 라운드의 차이를 만든다.