Claude Code 운영 허브 리프레시 2026 — Routines·Opus 4.7·MCP·MarkItDown 글을 색인용으로 묶기

Posted on by

2026년 4월 18일 기준 TECHTAEK에는 Claude Code Routines, Claude Opus 4.7, MCP·subagents·skills, MarkItDown MCP 글이 이미 따로 발행돼 있다.

그래서 오늘 할 일은 새 기능을 또 설명하는 게 아니다.

흩어진 글을 운영 순서로 다시 묶는 것이다.

질문은 단순하다.

Claude Code 운영 글을 처음 보는 사람이 어디서부터 읽어야 덜 헤맬까.

Routines부터 봐야 할까.

Opus 4.7부터 봐야 할까.

MCP와 subagents, skills를 먼저 구분해야 할까.

아니면 MarkItDown 같은 문서 변환 도구부터 붙여야 할까.

이 질문이 중요한 이유는 TECHTAEK 글이 늘어날수록 좋은 글도 길을 잃기 때문이다.

좋은 글 하나는 검색에서 살아남을 수 있다.

하지만 좋은 글 여러 개가 서로 연결되지 않으면 허브가 아니라 창고가 된다.

창고는 많을수록 든든해 보인다.

근데 막상 필요한 날에는 어디 뒀는지 모른다.

그게 콘텐츠 운영에서도 그대로 일어난다.

이번 글은 Claude Code 운영 허브를 다시 묶는 색인 지도다.

기능 소개보다 읽는 순서에 초점을 둔다.

각 글이 어떤 질문에 답하는지 정리한다.

어떤 독자가 어떤 글로 들어가야 하는지도 나눈다.

그리고 새 글을 더 쓰기 전에 기존 글들이 서로 트래픽을 밀어주게 만드는 구조를 만든다.

짧게 보면 이렇다.
반복 실행과 클라우드 자동화가 궁금하면 Routines 글부터 읽는다.
모델 전환과 비용 판단이 궁금하면 Opus 4.7 비교 글로 간다.
Claude Code가 느려지는 이유를 찾고 싶으면 MCP·subagents·skills 분리 글을 본다.
문서 변환을 에이전트 도구로 열어둘지 고민되면 MarkItDown MCP 글을 읽는다.

지금 허브에서 먼저 정할 것

Claude Code 운영 허브는 기능 모음집이 아니다.

기능을 어느 층에 둘지 정하는 지도에 가깝다.

2026 허브 확장: S3 실험 글을 어디에 붙일까

s3-experiments 같은 저장소형 자료는 TECHTAEK에서 단독 새 글로 밀기보다, Claude Code/MCP 운영 허브의 “도구를 붙이기 전 검증” 섹션에 붙이는 편이 안전하다.

읽는 순서는 이렇게 잡는다.

독자 질문 허브 안에서 붙일 위치 독립 글 승격 조건
이 S3 실험이 Claude Code/MCP 운영에 무슨 도움이 되나 도구 연결 전 검증 체크리스트 실제 설정, 권한, 비용, 실패 사례가 생길 때
저장소 문서를 그대로 요약해도 되나 참고자료 링크와 한 줄 해석 직접 재현 로그나 스크린샷이 있을 때
S3 도구를 에이전트에 붙여도 되나 MCP와 script 선택 기준 다음 권한 경계와 비용 추적 표가 채워질 때
지금 바로 써야 하나 “보류해도 되는 도구” 박스 반복 작업에서 수작업 시간을 실제로 줄였을 때

이번 백로그는 허브 확장으로만 닫는다.

도구 뉴스 하나를 더 쌓는 것보다, 이미 있는 Claude Code/MCP 운영 지도를 더 잘 찾게 만드는 쪽이 이긴다.

Routines는 실행 위치와 트리거의 문제다.

Opus 4.7은 모델 선택과 비용의 문제다.

MCP는 외부 시스템 연결의 문제다.

subagents는 역할 분리의 문제다.

skills는 반복 절차 재사용의 문제다.

MarkItDown은 문서 입력 레이어의 문제다.

이 여섯 가지를 한 문장으로 섞으면 멋있어 보인다.

예를 들면 이런 문장이다.

“Claude Code에 Routines와 Opus 4.7을 쓰고 MCP로 MarkItDown을 붙인 다음 subagents와 skills로 팀 자동화를 구성한다.”

읽으면 있어 보인다.

근데 운영자가 보면 바로 피곤해진다.

무엇이 트리거인지, 무엇이 모델인지, 무엇이 도구인지, 무엇이 절차인지 섞여 있기 때문이다.

운영 허브가 해야 할 일은 이 문장을 다시 쪼개는 것이다.

그래서 이 글은 아래 순서로 읽게 만든다.

순서 먼저 던질 질문 읽을 글 운영 레이어
1 이 작업을 자동으로 깨워야 하나 Routines 트리거·클라우드 실행
2 어려운 작업에 더 센 모델을 써야 하나 Opus 4.7 비교 모델·비용·마이그레이션
3 도구가 많아서 느려졌나 MCP·subagents·skills 분리 역할·권한·컨텍스트
3-1 세션 시작 전부터 토큰이 사라지나 ghost load 감사표 CLAUDE.md·memory·skills·MCP 점검
4 문서를 에이전트가 계속 읽어야 하나 MarkItDown MCP 문서 입력·도구 노출
5 이걸 팀이 반복해도 되나 온보딩·로그·용어 글 운영 규칙·감사·재현성

이 표의 장점은 하나다.

새 기능이 나와도 같은 틀에 꽂을 수 있다.

기능 이름이 바뀌어도 질문은 잘 안 바뀐다.

자동으로 실행할 것인가.

어떤 모델로 돌릴 것인가.

무엇에 연결할 것인가.

누가 맡을 것인가.

어떤 절차를 재사용할 것인가.

무엇을 기록할 것인가.

이 순서만 잡히면 Claude Code 운영 글이 쌓여도 덜 무너진다.

1번 입구: Routines는 자동화의 실행 위치를 바꾼다

먼저 볼 글은 Routines 글이다.

Claude Code Routines는 언제 쓰고 언제 과한가 2026 — schedule·GitHub event·개인계정 권한 분기표

공식 Claude Code 문서는 Routines를 schedule, API call, GitHub events로 실행되는 저장된 Claude Code 구성이라고 설명한다.

prompt, repositories, connectors를 한 번 묶어두고 Anthropic-managed cloud infrastructure에서 실행하는 흐름이다.

이 말에서 중요한 단어는 자동화가 아니다.

cloud infrastructure다.

즉 Routines는 “반복 프롬프트 저장소”보다 “Claude Code session을 클라우드에서 깨우는 방식”에 가깝다.

그래서 이 글은 운영 허브의 1번 입구가 된다.

반복 작업을 자동으로 깨우고 싶다면 Routines를 본다.

PR이 열릴 때 리뷰 초안을 만들고 싶다면 Routines를 본다.

배포 실패 후 Sentry 로그를 읽고 draft PR 후보를 만들고 싶다면 Routines를 본다.

하지만 로컬 Obsidian 볼트처럼 no-focus direct write가 중요한 작업은 바로 올리면 안 된다.

Routines는 클라우드에서 실행된다.

내 노트북의 로컬 파일 잠금, 앱 포커스, 개인 helper script 맥락을 그대로 가져간다고 보면 곤란하다.

여기서 판단표가 필요하다.

상황 Routines 적합도 이유
주간 docs drift scan 높음 repo를 읽고 draft PR을 만들기 좋다
PR opened 리뷰 초안 높음 GitHub event trigger와 맞다
Sentry alert triage 중간 API trigger와 맞지만 secret·payload 검증이 필요하다
매일 로컬 볼트 파일 정리 낮음 cloud execution과 local no-focus 운영이 충돌할 수 있다
5분마다 빌드 상태 폴링 낮음 최소 1시간 cadence와 성격이 안 맞는다
장애 대응의 유일한 gate 금지 preview 기능과 cap 누락 리스크가 있다

이 표를 보면 Routines는 만능 스케줄러가 아니다.

Claude Code session을 자동으로 시작하는 공식 레이어다.

빌드, 테스트, 배포 gate는 GitHub Actions나 기존 CI에 두는 편이 낫다.

Routines는 그 옆에서 분석, 요약, 초안, 리뷰 보조를 맡는 게 현실적이다.

돈 되는 포인트도 여기 있다.

Routines 글은 “새 기능 소개”가 아니라 “어디까지 자동화해도 되는가”를 답한다.

이런 글은 검색 유입이 크지 않아도 오래 남는다.

팀이 자동화를 붙일 때마다 다시 읽을 이유가 생기기 때문이다.

2번 입구: Opus 4.7은 더 센 모델이 아니라 비용 판단표로 읽는다

두 번째로 볼 글은 Opus 4.7 비교 글이다.

Claude Opus 4.7 vs Opus 4.6 실무 비교 2026 — 코딩 에이전트·비용·마이그레이션 판단표

Anthropic은 2026년 4월 16일 Claude Opus 4.7을 일반 제공한다고 발표했다.

공식 발표는 Opus 4.7이 Opus 4.6보다 고급 소프트웨어 엔지니어링, 장기 작업, 지시 준수, 자체 검증에서 개선됐다고 설명한다.

가격도 Opus 4.6과 같은 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러로 제시됐다.

여기까지만 읽으면 쉬워 보인다.

같은 가격이면 4.7 쓰면 되는 거 아닌가.

근데 운영 글에서는 그렇게 끝내면 안 된다.

모델 단가가 같아도 실제 비용은 달라질 수 있다.

새 tokenizer가 토큰 수를 바꿀 수 있다.

xhigh effort가 품질은 올리지만 지연시간과 출력 토큰을 늘릴 수 있다.

기존 thinking.budget_tokens 방식이나 sampling parameter가 그대로 맞지 않을 수 있다.

그래서 Opus 4.7 글은 “더 좋은 모델 뉴스”가 아니라 “어떤 작업에 먼저 켤지”를 판단하는 글이어야 한다.

Claude Code 운영 허브 안에서는 이렇게 읽는다.

작업 먼저 쓸 모델 이유
큰 코드베이스 버그 추적 Opus 4.7 high 긴 추론과 검증이 값어치를 낼 수 있다
장기 리팩터링 계획 Opus 4.7 xhigh 테스트 단계 분해와 rollback plan 품질이 중요하다
단순 요약 Sonnet 또는 낮은 effort Opus 비용을 쓸 이유가 약하다
문서 이미지 분석 Opus 4.7 high 고해상도 비전 개선이 의미 있다
대량 반복 처리 4.6 또는 Sonnet fallback 단가보다 총량이 더 중요하다
API backend 기본 모델 신중 전환 payload와 token count 테스트가 먼저다

이 표는 모델 팬심을 줄여준다.

팬심은 즐겁다.

하지만 청구서는 팬심을 잘 모른다.

운영 허브에서는 모델을 “성능 순위”가 아니라 “실패 비용이 큰 작업에 먼저 쓰는 자원”으로 둔다.

이렇게 보면 Routines와 Opus 4.7의 관계도 선명해진다.

Routines는 언제 실행할지 정한다.

Opus 4.7은 그 실행 안에서 어떤 난이도에 어떤 모델을 쓸지 정한다.

둘을 한꺼번에 켜면 멋있다.

하지만 둘을 한꺼번에 켜면 비용도 한꺼번에 열린다.

그래서 먼저 작은 routine으로 시작한다.

그다음 Opus 4.7 high와 xhigh를 나눠 측정한다.

마지막에 fallback을 남긴다.

이게 덜 화려하지만 오래 간다.

3번 입구: MCP·subagents·skills는 한꺼번에 붙이면 느려진다

세 번째로 볼 글은 분리 기준 글이다.

Claude Code에서 MCP·subagents·skills를 한꺼번에 붙이면 왜 느려질까 2026 — 자동화 팀 구성 전 분리 기준

Claude Code MCP 문서는 MCP servers가 Claude Code를 외부 도구, 데이터베이스, API에 연결한다고 설명한다.

subagents 문서는 각 subagent가 별도 context window와 특정 목적, 특정 tool access를 가질 수 있다고 설명한다.

skills 문서는 SKILL.md로 반복 절차와 참고 자료를 묶고, 필요한 때에만 로드하게 만들 수 있다고 설명한다.

셋 다 좋다.

그래서 위험하다.

좋은 기능은 한꺼번에 붙이고 싶어진다.

MCP로 GitHub, Sentry, Notion, Slack을 붙인다.

subagents로 reviewer, researcher, deployer를 만든다.

skills로 review, deploy, summarize 절차를 만든다.

DOT Studio나 DOT CLI처럼 agent behavior를 패키지로 공유하려는 도구가 들어오면,

이 분리 기준은 한 번 더 필요해진다.

DOT Studio는 Claude Code skills·agents와 뭐가 다를까 2026에서는 skills, subagents, Tal, Dance, Performer, Act를 같은 표에 올려서 어떤 층을 새로 도입하는지 먼저 본다.

거기에 slash command까지 얹는다.

겉보기엔 자동화 팀이다.

실제로는 의사결정 비용이 늘어난 자동화 상자일 수 있다.

허브에서 이 글의 역할은 기능 욕심을 식히는 것이다.

무엇을 붙일지가 아니라 무엇을 분리할지 먼저 본다.

기능 답하는 질문 잘 맞는 상황 조심할 점
MCP 어디에 연결할까 외부 API, DB, SaaS 접근 권한과 secret 경계
subagents 누가 따로 맡을까 리뷰, 리서치, 테스트처럼 역할이 선명한 작업 context 재수집 지연
skills 어떤 절차를 재사용할까 자주 반복되는 playbook, 체크리스트 너무 큰 매뉴얼화
slash commands 어떻게 빨리 호출할까 사람이 자주 부르는 단축 실행 명령이 너무 많아지는 문제
Routines 언제 자동으로 실행할까 schedule, API, GitHub event preview, cap, 계정 attribution

이 표를 허브 중앙에 두면 새 글을 쓸 때도 편해진다.

새 기술이 나오면 먼저 이 질문에 넣어본다.

외부 연결인가.

역할 분리인가.

절차 재사용인가.

호출 단축인가.

자동 실행인가.

이 중 어디에도 안 들어가면 아직 글감으로 덜 익은 것이다.

반대로 두세 칸에 동시에 들어가면 조심해야 한다.

한 기술이 여러 레이어를 먹기 시작하면 운영이 빨리 두꺼워진다.

Claude Code 운영에서 두꺼움은 종종 지능이 아니라 피로다.

3-1번 입구: 세션 시작 전 ghost load부터 감사한다

2026년 4월 19일에 하나를 더 끼워 넣었다.

도구를 많이 붙였을 때 느려지는 문제는 사용 중에만 생기지 않는다.

세션을 시작하기 전부터 이미 context budget이 조금씩 사라질 수 있다.

Reddit ClaudeAI 커뮤니티에는 Claude Code 설정을 감사해 보니 입력하기 전부터 약 30,000 tokens, 대략 15%가 agent, skill, MCP server, memory에서 사라졌다는 사례가 올라왔다.

이 숫자는 그 사용자의 환경과 추정 방식에 따른 커뮤니티 사례다.

우리 환경에서 그대로 재현됐다는 뜻은 아니다.

하지만 문제 제기는 유효하다.

Claude Code 공식 context window 문서도 입력 전부터 CLAUDE.md, auto memory, MCP tool names, skill descriptions가 context에 들어간다고 설명한다.

그래서 허브의 3번 입구에는 이제 작은 감사표를 하나 붙여야 한다.

무엇을 더 붙일까를 묻기 전에 이미 무엇이 매번 같이 타고 들어오는가를 봐야 한다.

우리 볼트도 가볍지 않다.

2026년 4월 19일 기준 로컬 감사 결과는 이렇다.

항목 로컬 수치 운영 판단
active agent markdown 127개 에이전트 목록은 주기적 정리가 필요하다
active skill 정의 57개 안 쓰는 skill은 선택지만 늘린다
slash command 28개 명령 이름이 겹치면 호출 판단이 느려진다
active agent 파일 합계 21,759줄 전부 항상 로드된다고 말하면 과장이지만, 인벤토리는 충분히 크다
active SKILL.md 합계 8,563줄 on-demand는 좋지만 subagent에 미리 붙이면 비용이 된다
command 파일 합계 911줄 상대적으로 작지만 팔레트 정리는 필요하다
root CLAUDE.md 141줄 Claude 문서의 200줄 권장선 안쪽
.claude/CLAUDE.md 330줄 분리·import·rules 이동 후보
.claude/settings.json 17줄 작지만 plugin과 permission은 확인 대상

여기서 중요한 건 숫자를 겁주기용으로 쓰지 않는 것이다.

agent 파일 21,759줄이 전부 매 세션에 통째로 들어간다고 말하면 안 된다.

Claude Code의 현재 문서 흐름에서는 MCP tool search가 기본으로 켜져 있고, full schema는 필요할 때까지 deferred된다.

skills도 description은 보이지만 full content는 호출될 때 들어가는 구조다.

다만 subagent에 skills:로 미리 지정하면 그 skill content가 subagent 시작 시 들어갈 수 있다.

즉 ghost load 감사의 목적은 공포 조성이 아니다.

현재 setup에서 항상 들어오는 것, 이름만 들어오는 것, 호출될 때 들어오는 것, subagent 시작 때 들어오는 것을 구분하는 것이다.

ghost load 감사 순서

내가 추천하는 순서는 아래다.

  1. /context로 현재 세션 category별 사용량을 본다.
  2. /memory로 어떤 CLAUDE.md와 auto memory가 로드됐는지 본다.
  3. /mcp로 MCP server별 비용과 연결 상태를 본다.
  4. .claude/agents/에서 최근 30일 안 쓴 agent를 찾는다.
  5. .claude/skills/에서 수동 호출만 필요한 skill은 disable-model-invocation 후보로 본다.
  6. .claude/commands/에서 같은 일을 하는 명령을 합친다.
  7. 삭제가 아니라 archive부터 한다.

마지막 줄이 중요하다.

바로 지우면 다음 주에 꼭 그게 필요해진다.

도구도 양말처럼 버리면 갑자기 짝이 나타난다.

그러니 첫 액션은 삭제가 아니라 archive다.

예를 들어 blog-idea-capture-team.md는 746줄이다.

하지만 실제로는 글감 수집 때만 필요하다.

이런 파일은 지울 대상이 아니라 호출 경로를 분명히 할 대상이다.

반대로 한 번 테스트하고 잊은 agent, 이름이 겹치는 command, 더 이상 쓰지 않는 MCP server는 archive 후보가 맞다.

언제 새 글로 분리할까

이 주제는 새 글로도 뽑을 수 있다.

다만 지금은 허브 섹션으로 두는 편이 낫다.

이미 TECHTAEK에는 MCP·subagents·skills 분리 글이 있고, 방금 발행한 context budget 글도 있다.

지금 별도 글로 또 내면 검색 의도는 좋아도 허브 안에서 역할이 살짝 겹친다.

새 글로 분리하려면 조건이 필요하다.

  • 실제 /context 캡처가 있다.
  • /mcp server별 비용 표가 있다.
  • archive 전후 숫자 비교가 있다.
  • 48시간 뒤 체감 속도나 사용량 변화가 있다.

이 네 개 중 두 개 이상이 생기면 그때 Claude Code 세션 시작 전에 사라지는 토큰을 독립 글로 빼도 된다.

그 전까지는 허브의 3-1번 입구가 더 효율적이다.

4번 입구: MarkItDown MCP는 문서 변환을 도구로 열지 말지의 문제다

네 번째로 볼 글은 MarkItDown MCP 글이다.

MarkItDown MCP 서버는 언제 쓰고 언제 과한가 2026 — OCR·플러그인·선택 의존성 분기표

기존 변환 품질 글도 같이 읽을 만하다.

MarkItDown 2026 — PDF·PPTX·HTML을 LLM용 markdown으로 바꿀 때 어디까지 믿어도 될까

MarkItDown은 LLM과 텍스트 분석 파이프라인용 markdown 변환기로 보는 편이 맞다.

사람에게 다시 배포할 예쁜 markdown을 만드는 도구라기보다, LLM이 읽기 좋은 중간 텍스트를 만드는 도구다.

MarkItDown MCP package는 이 변환기를 MCP tool로 노출한다.

즉 사람이 CLI에서 한 번 실행하는 게 아니라, 에이전트가 필요할 때 도구처럼 호출할 수 있게 된다.

여기서 운영 질문이 생긴다.

문서 변환기를 계속 열어둘 것인가.

아니면 필요할 때 CLI로만 부를 것인가.

서비스 내부 파이프라인이면 Python API로 감쌀 것인가.

허브에서 MarkItDown 글은 “문서 입력 레이어”를 담당한다.

Routines가 실행을 깨우고, Opus 4.7이 어려운 판단을 맡고, MCP가 외부 도구를 열고, subagents가 역할을 나누더라도 입력이 엉망이면 전체가 흔들린다.

PDF 표가 깨진다.

PPTX 구조가 눌린다.

HTML에서 필요 없는 메뉴까지 들어온다.

OCR 비용이 예상보다 커진다.

그 상태로 에이전트에게 요약하라고 하면 멋진 헛소리가 나올 수 있다.

그래서 문서 변환은 작은 기능이 아니다.

에이전트가 무엇을 보게 할지 정하는 입구다.

문서 작업 추천 방식 이유
파일 몇 개 수동 변환 CLI 실행 경계가 선명하다
서비스 내부 전처리 Python API 로그와 예외 처리가 쉽다
에이전트가 반복 호출 MCP tool로 열어두는 가치가 있다
민감 파일이 많은 로컬 폴더 신중 또는 금지 file URI 접근 경계를 봐야 한다
OCR 필요한 스캔 문서 별도 테스트 품질과 비용이 같이 움직인다

이 표는 글 하나를 넘어서 허브 전체에 필요하다.

Claude Code 운영 글을 읽는 독자는 대부분 자동화를 더 붙이고 싶어 한다.

그런데 자동화는 입력 품질을 확대한다.

좋은 입력은 좋은 결과를 더 빨리 만든다.

나쁜 입력은 나쁜 결과를 더 그럴듯하게 만든다.

그래서 MarkItDown 글은 단순 도구 리뷰가 아니라 Claude Code 운영 허브의 문서 입력 경계선이다.

5번 입구: 팀 운영은 온보딩, 로그, 용어 글로 닫는다

최신 기능 네 개만 묶으면 허브가 반쪽이다.

운영은 마지막에 팀 규칙으로 닫아야 한다.

그래서 아래 글도 같이 붙인다.

Claude Code 팀 온보딩 2026 — AGENTS.md·SKILL.md·hooks를 어떤 순서로 깔아야 덜 망할까

AI 코딩 에이전트 로그를 너무 많이 남기면 무엇이 먼저 무너지나 2026 — 원문·요약·승인 로그 분리 기준표

Claude Code 자동화 용어 정리 2026 — Triage·Compound·LLM Wiki·Harness를 어디에 써야 안 겹칠까

온보딩 글은 순서를 잡아준다.

AGENTS.md.

SKILL.md.

hooks.

subagents.

이 순서가 뒤집히면 자동화가 규칙을 앞지른다.

로그 글은 흔적을 남기는 기준을 잡아준다.

원문 로그.

요약 로그.

승인 로그.

이 셋을 섞으면 나중에 검색성과 감사 가능성이 무너진다.

용어 글은 개념을 나눠준다.

Triage.

Compound.

LLM Wiki.

Harness.

이 단어들이 겹치면 문서는 똑똑해 보이지만 실행은 흐려진다.

운영 허브에서 이 글들은 안전장치다.

Routines, Opus 4.7, MCP, MarkItDown이 엔진이라면 온보딩과 로그와 용어는 브레이크다.

브레이크가 있어야 더 빨리 간다.

이건 자동차 명언이 아니라 블로그 운영에도 그대로 먹힌다.

Claude Code 운영 허브 읽는 순서

처음 들어온 독자는 아래 순서로 보면 된다.

1단계는 반복 실행 판단이다.

Routines 글을 읽는다.

내가 자동으로 깨우려는 작업이 schedule, API, GitHub event 중 어디에 걸리는지 본다.

2단계는 모델 비용 판단이다.

Opus 4.7 비교 글을 읽는다.

이 작업이 Opus 4.7을 쓸 만큼 어렵고 실패 비용이 큰지 본다.

3단계는 도구와 역할 분리다.

MCP·subagents·skills 글을 읽는다.

외부 연결, 별도 작업자, 반복 절차, 호출 단축을 섞지 않는다.

4단계는 입력 품질이다.

MarkItDown 글을 읽는다.

문서 변환을 CLI, API, MCP 중 어디에 둘지 정한다.

5단계는 팀 운영이다.

온보딩, 로그, 용어 글을 읽는다.

누가 무엇을 맡고, 무엇을 남기고, 어떤 단어를 어떤 층에 쓸지 정한다.

이 흐름을 표로 다시 보면 이렇다.

단계 질문 글 결과물
1 언제 실행할까 Routines trigger 정책
2 어떤 모델을 쓸까 Opus 4.7 model routing 표
3 무엇을 붙일까 MCP·subagents·skills tool/role/procedure 분리
4 무엇을 읽힐까 MarkItDown document ingestion 기준
5 어떻게 지속할까 온보딩·로그·용어 팀 runbook

이 구조가 있으면 새 글을 쓸 때도 자기잠식을 줄일 수 있다.

예를 들어 새 MCP 서버가 나왔다고 하자.

바로 “무엇인가” 글을 쓰지 않는다.

먼저 이 허브에서 어느 칸인지 본다.

외부 연결 문제라면 MCP 칸이다.

문서 입력 문제라면 MarkItDown 칸이다.

자동 실행 문제라면 Routines 칸이다.

모델 선택 문제라면 Opus 칸이다.

팀 반복 절차 문제라면 skills나 온보딩 칸이다.

이렇게 분류하면 새 글 제목도 자연스럽게 좁아진다.

좁아진 제목은 검색에서 더 오래 간다.

넓은 제목은 순간 멋있다.

좁은 제목은 나중에 돈이 된다.

수익화 관점에서는 왜 이 허브가 필요한가

TECHTAEK는 TAEK2나 배당노마드처럼 즉시 돈 되는 세금·ETF 검색어가 아니다.

TECHTAEK의 역할은 브랜드, 체류시간, 링크, 뉴스레터 전환이다.

그래서 AI 뉴스 하나를 빨리 쓰는 것보다 실사용 허브를 두껍게 만드는 편이 낫다.

Routines 글은 신기능 검색 수요를 잡는다.

Opus 4.7 글은 모델 전환 검색 수요를 잡는다.

MCP·subagents·skills 글은 운영 피로 검색 수요를 잡는다.

MarkItDown 글은 문서 처리 검색 수요를 잡는다.

이 네 개가 따로 있으면 각각 작은 글이다.

하지만 한 허브로 묶으면 독자는 다음 질문으로 이동한다.

Routines를 읽은 사람은 “그럼 모델은 뭐 쓰지”로 간다.

Opus 4.7을 읽은 사람은 “그럼 이걸 언제 자동으로 돌리지”로 간다.

MCP 글을 읽은 사람은 “문서 변환도 MCP로 열어도 되나”로 간다.

MarkItDown 글을 읽은 사람은 “이 도구를 subagent에게 맡겨도 되나”로 간다.

이 이동이 체류시간을 만든다.

체류시간이 전부는 아니다.

하지만 허브형 블로그에서는 독자의 다음 질문을 잡는 게 중요하다.

애드센스도 결국 페이지 하나의 광고 노출보다 세션 전체의 깊이가 중요해진다.

뉴스레터 전환도 마찬가지다.

한 글 보고 나가는 사람보다 세 글 읽고 나가는 사람이 더 강한 독자다.

이 허브는 그 이동 경로를 만든다.

작은 표 하나가 돈 냄새를 만드는 순간이다.

종이 냄새는 아니고 링크 냄새다.

기존 글을 더 살리는 내부링크 규칙

허브를 만들었으면 기존 글에도 같은 원칙을 넣어야 한다.

무조건 모든 글에 모든 링크를 붙이면 안 된다.

관련 없는 링크는 독자를 움직이는 게 아니라 밀어낸다.

내부링크는 아래 기준으로 붙인다.

출발 글 넣을 링크 이유
Routines 글 Opus 4.7, MCP 분리 글 자동 실행 뒤 모델·권한 질문이 따라온다
Opus 4.7 글 Routines, MCP 분리 글 모델 전환 뒤 실행·도구 구조가 따라온다
MCP 분리 글 Routines, MarkItDown MCP 연결과 자동 실행, 도구 노출을 나눠야 한다
MarkItDown MCP 글 MCP 분리 글, MarkItDown 품질 글 도구 노출과 입력 품질이 붙어 있다
온보딩 글 MCP 분리 글, 로그 글 팀 규칙과 권한·기록이 붙어 있다

이 규칙의 목표는 링크 수가 아니다.

다음 질문의 정확도다.

독자가 Routines 글을 읽고 있는데 갑자기 MarkItDown 품질 테스트로 보내면 튈 수 있다.

하지만 Routines 글에서 Opus 4.7 비용 판단으로 보내면 자연스럽다.

MCP 분리 글에서 MarkItDown MCP로 보내는 것도 자연스럽다.

문서 변환기를 MCP로 열어둘지 말지가 바로 다음 질문이기 때문이다.

이렇게 붙이면 허브가 살아난다.

검색 유입은 개별 글에서 들어오고, 체류는 허브 구조가 받아준다.

이게 이번 025의 목적이다.

새 글을 하나 더 늘리는 게 아니라, 이미 써둔 글들이 서로 일을 하게 만드는 것.

말하자면 콘텐츠에게 팀워크를 시키는 일이다.

사람도 팀워크 안 되면 힘든데 글이라고 다를 리가 없다.

오늘 기준 운영 체크리스트

Claude Code 운영 허브를 2026년 4월 18일 기준으로 정리하면 아래 체크리스트가 남는다.

  • Routines는 preview 성격과 usage limit을 감안해 보조 자동화부터 쓴다.
  • Routines API trigger token은 routine별 secret으로 관리한다.
  • GitHub event trigger는 dropped event 가능성을 고려해 reconciliation을 둔다.
  • Opus 4.7은 어려운 코딩, 장기 에이전트, 고해상도 비전에 먼저 테스트한다.
  • Opus 4.7 전환 시 tokenizer, effort, API payload, fallback을 같이 본다.
  • MCP는 외부 연결이 필요할 때만 붙인다.
  • subagents는 context 분리와 역할 책임이 선명할 때만 만든다.
  • skills는 반복 절차가 커졌을 때 CLAUDE.md에서 분리한다.
  • slash command는 사람이 자주 부르는 작업만 남긴다.
  • MarkItDown은 LLM 입력용 markdown 변환기로 기대치를 맞춘다.
  • MarkItDown MCP는 반복 agent 호출이 있을 때만 열어둔다.
  • 문서 변환 결과는 샘플 3개 이상으로 품질을 확인한다.
  • 팀 운영은 AGENTS.md, SKILL.md, hooks 순서로 깐다.
  • 로그는 원문, 요약, 승인 기록을 분리한다.
  • 내부링크는 다음 질문 기준으로 1개에서 3개만 붙인다.

이 체크리스트를 다 지켜야만 Claude Code를 쓸 수 있는 건 아니다.

혼자 쓰는 작은 프로젝트라면 절반은 과하다.

하지만 팀에서 굴리거나 블로그 운영처럼 장기 자산으로 쌓을 거라면 기준이 필요하다.

기준이 없으면 새 기능이 나올 때마다 구조가 흔들린다.

기준이 있으면 새 기능이 나와도 어디에 넣을지 보인다.

허브의 진짜 가치는 여기에 있다.

정보를 모으는 게 아니라 판단 위치를 정해준다.

FAQ

Claude Code 운영 허브는 Routines 글 하나로 충분하지 않나?

아니다.

Routines는 자동 실행 레이어다.

모델 선택, 도구 연결, 문서 입력, 팀 온보딩까지 대신해주지는 않는다.

Routines 글은 입구이고, 허브는 전체 지도다.

입구만 있고 지도 없으면 결국 다시 헤맨다.

Opus 4.7 글과 Routines 글은 서로 겹치지 않나?

겹치지 않는다.

Opus 4.7은 어떤 모델을 쓸지의 문제다.

Routines는 언제 어떻게 Claude Code session을 시작할지의 문제다.

둘은 같이 쓰일 수 있지만 같은 층위가 아니다.

같은 층위로 보면 비용과 권한 설계가 섞인다.

MCP와 MarkItDown MCP 글은 왜 둘 다 필요한가?

MCP 글은 “외부 도구를 언제 어떻게 붙일까”를 다룬다.

MarkItDown MCP 글은 그중 문서 변환 도구를 MCP로 열어둘 때의 입력 품질과 보안 경계를 다룬다.

즉 하나는 지도이고, 하나는 특정 길목의 표지판이다.

표지판이 많으면 복잡하지만, 위험한 길목에는 표지판이 필요하다.

새 Claude Code 기능이 나오면 어디에 붙이면 되나?

먼저 기능이 해결하는 질문을 본다.

트리거면 Routines 칸이다.

모델이면 Opus 칸이다.

외부 연결이면 MCP 칸이다.

역할 분리면 subagents 칸이다.

절차 재사용이면 skills 칸이다.

문서 입력이면 MarkItDown 같은 ingestion 칸이다.

아무 칸에도 안 들어가면 아직 실사용 각도가 약한 것이다.

이 허브 글 자체가 돈이 되나?

단독 애드센스 폭발형은 아니다.

하지만 TECHTAEK에서는 꽤 중요한 돈 되는 글이다.

이유는 허브가 개별 글의 체류시간과 재방문 경로를 만들어주기 때문이다.

Routines, Opus 4.7, MCP, MarkItDown 글이 따로 놀면 각자 작은 트래픽으로 끝난다.

허브로 묶이면 독자의 다음 질문을 잡는다.

그게 TECHTAEK식 수익화다.

즉 바로 현금 냄새보다 브랜드와 세션 깊이 냄새가 강하다.

참고 자료/공식 출처

관련 글

SNS 포스트 초안

Claude Code 운영 글이 쌓일수록 중요한 건 새 글 하나 더 쓰기가 아니라 읽는 순서다.

Routines는 자동 실행.

Opus 4.7은 모델·비용 판단.

MCP는 외부 연결.

subagents는 역할 분리.

skills는 절차 재사용.

MarkItDown은 문서 입력.

이걸 한꺼번에 섞으면 멋있지만 운영이 느려진다.

그래서 TECHTAEK Claude Code 운영 허브를 2026년 4월 18일 기준으로 다시 묶었다.

새 기능 뉴스가 아니라, 어떤 글부터 읽고 어디에 적용할지 보는 색인 지도다.