[AI] Claude Code 동향 — 서브에이전트·스킬·MCP·훅으로 진화하는 에이전틱 CLI
Claude Code 동향 — 서브에이전트·스킬·MCP·훅으로 진화하는 에이전틱 CLI
Claude Code는 처음 나왔을 때만 해도 "터미널에서 돌아가는 코딩 챗봇" 정도로 보였다. 그런데 2026년 초 시점에서 보면 이건 더 이상 챗봇이 아니다. 파일 시스템을 읽고 쓰고, 명령을 실행하고, 여러 개의 하위 에이전트를 병렬로 굴리고, 외부 도구를 MCP로 붙이고, 훅으로 결정론적 자동화를 거는 — 하나의 에이전트 런타임에 가깝다.
이 글은 마케팅 문구가 아니라, 매일 이걸로 커밋을 찍는 개발자 관점에서 지금 Claude Code가 어디까지 왔고 어디로 가는지를 정리한 것이다. 기능 나열이 아니라 "언제 빛나고 언제 삽질하는지"까지 솔직하게 짚는다.
Claude Code가 뭔가 — 다시 정의
Claude Code는 Anthropic이 만든 에이전틱 코딩 CLI다. 핵심은 두 가지다.
- 에이전트 루프: 사용자의 목표를 받으면 스스로 파일을 검색하고 읽고, 코드를 수정하고, 테스트를 돌리고, 결과를 보고 다시 고친다. 한 번의 응답이 아니라 "될 때까지 반복하는" 루프가 기본이다.
- 로컬 우선: 당신의 실제 레포, 실제 셸, 실제 환경에서 동작한다. 클라우드 샌드박스에 코드를 복사해 넣는 방식이 아니라 당신 머신의 워킹 디렉터리를 직접 만진다.
여기에 최근 1년간 붙은 레이어들 — 서브에이전트, 스킬, MCP, 훅, 플랜 모드, 백그라운드 에이전트 — 이 진짜 이야기의 본론이다.
서브에이전트 — 컨텍스트를 나눠 병렬로 일하기
가장 체감이 큰 변화는 **서브에이전트(subagents)**다. 메인 에이전트가 모든 걸 자기 컨텍스트 창에 밀어 넣는 대신, 특정 작업을 별도 컨텍스트를 가진 하위 에이전트에게 위임한다.
왜 중요한가:
- 컨텍스트 오염 방지: "이 20개 파일을 뒤져서 인증 로직이 어디 있는지 찾아줘" 같은 탐색 작업은 토큰을 엄청 먹는다. 이걸 서브에이전트에게 시키면, 서브에이전트가 파일 더미를 다 읽더라도 메인에게는 결론만 돌려준다. 메인 컨텍스트는 깨끗하게 유지된다.
- 병렬성: 서로 의존하지 않는 작업 — 예를 들어 "프론트 리팩터링"과 "테스트 작성"을 동시에 서로 다른 서브에이전트에 던질 수 있다.
- 역할 분리: 리뷰 전용, 보안 점검 전용, 탐색 전용 에이전트를
.claude/agents/에 정의해두고 필요할 때 부른다.
프로젝트에 커스텀 에이전트를 정의하는 건 마크다운 파일 하나면 된다.
markdown--- name: security-reviewer description: PR 디프에서 인증 우회·시크릿 노출·인젝션을 찾는다 model: opus tools: [Read, Grep, Bash] --- 너는 시니어 보안 엔지니어다. 변경된 코드만 검토하고, 확신도가 높은 취약점만 보고하라. 파일 경로와 라인, 재현 시나리오를 포함하라.
실전 팁: 서브에이전트는 "읽고 요약해서 결론만 가져오는" 작업에 최적이다. 반대로 서브에이전트끼리 긴밀하게 상태를 주고받아야 하는 작업은 오버헤드만 커진다. 팬아웃(fan-out) 탐색·리뷰에 쓰고, 촘촘한 협업에는 쓰지 마라.
스킬 — 재사용 가능한 역량 패키지
Skills는 2026년 들어 Claude Code 생태계를 가장 크게 바꾼 축이다. 스킬은 한마디로 **"필요할 때만 로드되는 능력 묶음"**이다. 지침(markdown) + 스크립트 + 참조 자료를 하나의 디렉터리로 패키징한다.
핵심 메커니즘은 **점진적 공개(progressive disclosure)**다.
- 평소엔 스킬의 이름과 한 줄 설명만 모델 컨텍스트에 떠 있다.
- 사용자의 요청이 그 스킬과 맞아떨어질 때 비로소 전체 지침 본문이 로드된다.
- 무거운 참조 파일이나 실행 스크립트는 실제로 필요할 때만 읽힌다.
덕분에 스킬을 수십 개 설치해도 컨텍스트가 터지지 않는다. "PDF 만들기", "디자인 리뷰", "특정 사내 배포 절차" 같은 반복 작업을 스킬로 굳혀두면, 매번 프롬프트로 설명할 필요 없이 트리거 조건만 맞으면 알아서 발동한다.
MCP가 외부 도구·데이터 연결이라면, 스킬은 절차·노하우의 코드화다. 이 둘은 경쟁이 아니라 보완 관계다.
MCP — 도구와 데이터를 붙이는 표준
**Model Context Protocol(MCP)**은 이제 Claude Code만의 이야기가 아니라 업계 표준 프로토콜로 자리 잡았다. LLM 에이전트가 외부 시스템(DB, 이슈 트래커, 브라우저, 사내 API)과 표준화된 방식으로 도구·리소스·프롬프트를 주고받게 한다.
Claude Code에서 MCP 서버를 붙이는 건 설정 파일에 선언하는 정도다.
json{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } }, "postgres": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb" ] } } }
이렇게 붙이면 에이전트가 "이 이슈 읽어서 관련 PR 찾아줘" 나 "이 쿼리로 실제 스키마 확인해줘" 같은 걸 실제 시스템에 대고 수행한다. 상상 속 스키마가 아니라 진짜 DB를 본다는 게 핵심이다.
주의점: MCP 서버를 많이 붙일수록 도구 정의가 컨텍스트를 먹는다. 도구가 40개, 50개 떠 있으면 그 스키마만으로도 토큰이 상당하고, 모델이 어떤 도구를 쓸지 헷갈릴 수도 있다. 최근엔 이 문제를 해결하려고 도구 스키마를 지연 로딩(deferred/search 방식) 하는 패턴이 표준화되고 있다 — 이름만 띄워두고, 실제 호출 직전에 스키마를 검색해 불러오는 방식이다.
훅 — 결정론이 필요한 곳엔 LLM을 쓰지 마라
에이전트의 약점은 비결정성이다. "커밋 전에 항상 포맷터를 돌려줘" 같은 규칙을 프롬프트로만 걸면, 모델이 열 번 중 아홉 번은 지키고 한 번은 까먹는다. **훅(hooks)**은 이 지점을 해결한다.
훅은 특정 이벤트(도구 실행 전후, 세션 종료 등)에 정해진 셸 명령을 무조건 실행한다. LLM의 판단이 아니라 하네스가 직접 실행하므로 100% 결정론적이다.
json{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null; true" } ] } ] } }
이 훅은 에이전트가 파일을 수정할 때마다 자동으로 Prettier를 돌린다. 에이전트에게 "포맷 맞춰줘"라고 부탁할 필요가 없다. 린트, 타입체크, 시크릿 스캔, 테스트 트리거 등 **"항상 일어나야 하는 일"**은 전부 훅으로 내려야 한다.
원칙은 간단하다. 판단이 필요하면 에이전트, 보장이 필요하면 훅.
플랜 모드 — 실행 전에 합의부터
**플랜 모드(plan mode)**는 에이전트가 파일을 건드리기 전에 무엇을 어떻게 바꿀지 계획을 먼저 제시하고, 사용자가 승인해야 실행에 들어가는 모드다.
큰 리팩터링이나 위험한 변경에서 특히 유용하다. 에이전트가 곧장 20개 파일을 갈아엎기 시작하면 되돌리기 어렵지만, 플랜 모드에서는 "이런 순서로, 이 파일들을, 이렇게 바꾸겠다"를 읽고 방향을 틀 수 있다. 계획 단계에서 30초 투자하면 잘못된 방향으로 5분 삽질하는 걸 막는다.
백그라운드 / 비동기 에이전트
또 하나의 큰 흐름은 비동기·백그라운드 실행이다. 이제 작업을 백그라운드로 던져놓고 다른 일을 할 수 있다.
- 긴 테스트 스위트나 빌드를 백그라운드 프로세스로 돌리고, 끝나면 에이전트가 결과를 받아 이어서 처리한다.
- 여러 작업을 동시에 여러 에이전트에게 맡기고, 각각의 진행 상황을 지켜본다.
- 스케줄러에 걸어 정기적으로 도는 클라우드 에이전트로 만들 수도 있다 — 예를 들어 매일 아침 의존성 취약점을 점검하고 PR을 여는 식이다.
이건 "AI가 내 옆에서 타이핑을 돕는다"에서 "AI가 백그라운드에서 여러 트랙의 일을 돌린다"로의 전환이다. 다만 병렬 에이전트가 같은 파일을 건드리면 충돌이 나므로, 격리(worktree 등)와 작업 분할 설계가 중요해진다.
멀티 서피스 — 터미널·IDE·웹
Claude Code는 더 이상 터미널에만 있지 않다.
- 터미널: 원형이자 가장 강력한 서피스. 셸·파일·프로세스에 완전한 접근.
- IDE 통합: VS Code, JetBrains 계열 등에서 인라인 디프, 파일 컨텍스트 자동 인식, 에디터 안에서의 승인 흐름.
- 웹: 브라우저에서 접근해 백그라운드/원격 에이전트를 굴리고 모니터링. 로컬 머신을 켜두지 않아도 되는 시나리오.
같은 에이전트 코어를 여러 진입점에서 쓰는 구조라, 터미널에서 시작한 작업의 맥락을 다른 서피스에서 이어가는 그림이 점점 매끄러워지고 있다.
모델 티어 — 2026년 초 기준
Claude Code는 작업 성격에 따라 모델을 골라 쓴다. 2026년 초 기준으로 대략 이런 구도다.
| 티어 | 성격 | 잘 맞는 작업 | 트레이드오프 |
|---|---|---|---|
| Opus | 최상위 추론 | 복잡한 아키텍처 설계, 어려운 디버깅, 장기 계획 | 토큰 비용·지연이 가장 큼 |
| Sonnet | 균형형 주력 | 일상적 기능 구현, 리팩터링, 리뷰 | 대부분의 실무에 기본값 |
| Haiku | 빠르고 저렴 | 단순 편집, 분류, 대량 팬아웃 서브에이전트 | 깊은 추론엔 부적합 |
실전 전략은 메인은 Sonnet 또는 Opus로, 팬아웃 탐색 서브에이전트는 Haiku로 두는 식의 혼합이다. 탐색·요약 같은 반복 작업에 최상위 모델을 쓰면 비용만 태운다. (구체적 가격은 자주 바뀌므로 항상 공식 문서를 확인하자.)
언제 빛나고 언제 삽질하나 — 솔직한 트레이드오프
빛나는 지점:
- 명확한 목표 + 검증 수단(테스트, 타입체크)이 있는 작업. 에이전트가 스스로 돌려보고 고칠 수 있다.
- 넓은 코드베이스 탐색·이해. "이 기능이 어디서 어떻게 얽혀 있나"를 순식간에 파악한다.
- 보일러플레이트, 마이그레이션, 반복 패턴 적용.
삽질하는 지점:
- 컨텍스트 한계: 코드베이스가 거대하면 모든 걸 다 넣을 수 없다. 무엇을 컨텍스트에 넣을지 설계하는 게 사용자의 몫이 된다.
- 비용: 에이전트 루프는 토큰을 많이 쓴다. Opus로 대규모 작업을 오래 돌리면 청구서가 커진다. 모델 티어 믹스와 서브에이전트 격리가 곧 비용 관리다.
- 비결정성: 같은 요청도 매번 조금씩 다르게 처리한다. 보장이 필요한 규칙은 훅으로 내려야 한다.
- 애매한 목표: "코드 좀 좋게 만들어줘" 같은 모호한 지시엔 엉뚱한 데 힘을 쓴다. 목표·제약·검증 기준을 명확히 줄수록 결과가 좋다.
어디로 가고 있나
정리하면 방향은 분명하다. Claude Code는 단일 대화형 도구에서 → 여러 에이전트가 병렬로 도는 오케스트레이션 런타임으로 이동 중이다. 서브에이전트로 컨텍스트를 나누고, 스킬로 노하우를 굳히고, MCP로 세상과 연결하고, 훅으로 결정론을 확보하고, 백그라운드/웹으로 실행 위치를 넓힌다.
개발자에게 남는 숙제는 코딩 자체가 아니라 하네스 설계다. 어떤 작업을 어떤 모델·어떤 에이전트에 맡길지, 무엇을 컨텍스트에 넣고 뺄지, 무엇을 훅으로 강제할지 — 이 설계 감각이 2026년 에이전틱 개발의 실력을 가른다.