Claude Code에 FDE 메인 디스패처 붙이기 - 스킬을 부르는 스킬

[AI] Peterica의 AI공부와 비젼 정리

ㅁ 들어가며

예전에 "Claude Code를 소프트웨어처럼 설계하기 — 프롬프트 하네스 아키텍처" 라는 글에서 정리한 적이 있다.

프롬프트가 코드이고, 스킬이 함수이며, 에이전트가 마이크로서비스라는 관점이다.

그 위에서 블로그 1,000편을 스크래핑하고 위키로 변환하는 파이프라인을 운영했다.

 

시간이 지나니 스킬이 17개, 18개, 20개로 늘어났다.

한편으로는 좋았지만, 다른 한편으로는 "어떤 스킬을 언제 불러야 하는지" 를 나조차 자주 잊어버렸다.

 

"이 초안 팩트체크도 하고 폴리싱도 하고 발행준비도 해줘"라고 말하면,

Claude가 어떤 스킬을 어떤 순서로 부를지 매번 다르게 해석했다.

 

그래서 하나 더 만들었다.

이번엔 스킬을 부르는 스킬 - FDE(Forward Deployed Engineer) 역할의 메인 디스패처다.

이 글은 그 설계와 동작 방식을 짧게 정리한다.

 

ㅁ 문제 — 스킬이 늘어날수록 라우팅이 어려워진다

스킬 하나는 잘 정의된 워크플로를 가진다.

blog-factcheck, blog-polish, blog-publish-prep 각자 명확하다.

그런데 사용자는 자연어로 말한다:

"task/11_새주제에 초안 만들고 팩트체크·폴리시·발행준비까지 해줘"

 

이 한 줄에 4개의 하위 작업이 있고,

각각 다른 스킬과 매칭되며, 일부는 병렬 가능하고 일부는 의존성이 있다.

이걸 매번 사람이 분해해서 "먼저 이거 실행하고, 그다음 저거 실행하고…" 라고 지시하기는 번거롭다.

소프트웨어로 치면 라우터가 없는 마이크로서비스 군집 같은 상태다.

 

ㅁ 해결 — FDE 역할의 디스패처 스킬

Forward Deployed Engineer의 핵심 역할은

  고객의 모호한 요청을 실행 가능한 작업으로 분해하는 것이다.

그 역할을 스킬로 캡슐화했다.

 

동작은 5단계로 고정한다.

1. 분석 (Analyze)   → 자연어 지시 파싱, 의도·산출물·제약 추출
2. 계획 (Plan)      → 원자 단위로 분해 + 스킬 매칭 + 의존성 그래프
3. 제안 (Propose)   → 실행 계획 테이블 제시 (사용자 승인 대기)
4. 위임 (Dispatch)  → 승인 후 Wave 단위 병렬 실행 (≤3)
5. 통합 (Integrate) → 결과 회수 + 충돌 조정 + 최종 보고

 

핵심은 3번 제안 단계에서 반드시 멈춘다는 것이다.

소프트웨어의 Plan/Apply 패턴 (Terraform, kubectl diff)과 같다 — 계획을 먼저 보여주고, 승인받은 후에만 상태를 바꾼다.

 

 

ㅁ 스킬 매칭은 어떻게 하나 — 3-tier Lookup

사용자 지시에서 추출한 하위 작업을 스킬에 매칭할 때, 우선순위 3단으로 탐색한다.

Tier	방법	근거 파일
1	Exact keyword	skill-cross-reference.md, 4 트리거 매트릭스
2	Category match	skill_info.md, 2 카테고리 분류
3	Fallback	직접 수행 또는 manage-skills 에 신규 스킬 제안 위임

 

각 매칭에 Confidence (High / Medium / Low)를 부여한다.

  Low면 사용자에게 확인을 요청한다.

  이 구조는 CDN의 캐시 계층 과 닮았다 — L1 미스면 L2, 그래도 없으면 오리진으로 간다.

 

ㅁ 왜 승인 단계를 넣었는가

디스패처를 만들면서 가장 고민한 건 "언제 멈출 것인가" 였다.

자연어 지시에서 바로 실행으로 넘어가면 편하지만, 내가 의도하지 않은 스킬이 호출되는 순간 되돌리기 어려워진다.

그래서 실행 계획을 표로 제시하고 승인받는 단계를 강제했다. 

Terraform 이나 kubectl 의 plan / diff 가 한 번 검토를 강제하는 것과 같은 이유다. 

사람이 "예"라고 말하기 전까지는 어떤 스킬도 건드리지 않는다.

편의를 조금 포기하는 대신, 예상 가능한 실행을 얻었다.

 

ㅁ 왜 글로벌로 승격했는가

처음엔 블로그 레포 하나에서만 쓰려고 만들었다.

그런데 다른 레포로 옮겨 작업하다가 같은 사고 패턴이 또 필요해졌다.

문제는 같은데 레포마다 스킬 목록·참조 파일·경로가 다르다는 것이다.

그래서 ~/.claude/skills/ 로 올렸다. 

대신 프로젝트마다 환경이 다르니 있으면 쓰고, 없으면 다음 층을 본다는 fallback 체인으로 설계했다.

프로젝트 특화 정보가 풍부하면 정확히 매칭되고, 아무것도 없으면 세션 레지스트리 description 만으로도 동작한다.

한 줄로 요약하면 — "환경은 다르지만 사고 패턴은 같다" 를 코드로 옮긴 것이다.

ㅁ 스킬에 스킬을 붙인다는 것

스킬 1~2개일 때는 필요 없는 고민이다. 그때는 그냥 부르면 된다.

그런데 스킬이 20개쯤 되자 내가 먼저 잊기 시작했다. 

그 시점부터는 스킬을 더 만드는 것보다 스킬을 고르는 방식 을 설계하는 게 효율적이었다. 

함수가 늘면 라우터를, 마이크로서비스가 늘면 API 게이트웨이를 붙이는 것과 같은 순서다.

도구의 수가 임계점을 넘으면, 도구보다 도구를 고르는 방식이 더 중요해진다.

 

 

ㅁ 마무리

처음엔 스킬 하나로 시작했다. 몇 개 더 만들면서 편해졌다.

열 개가 넘어가자 어떤 스킬이 있는지 내가 잊기 시작했다.

스무 개쯤 되자 Claude 도 라우팅을 흔들기 시작했다.

그 시점에서 필요한 건 더 많은 스킬이 아니라 스킬을 부르는 스킬이다.

 

FDE 디스패처는 그렇게 태어났다.

"도구가 늘어나면 도구를 고르는 도구가 필요해진다."

 

 

ㅁ 함께 보면 좋은 사이트

• Claude Code를 소프트웨어처럼 설계하기 — 프롬프트 하네스 아키텍처 (이 글의 선행 맥락)
• Claude Code 공식 문서 — https://docs.claude.com/en/docs/claude-code
• Terraform Plan/Apply — https://developer.hashicorp.com/terraform/cli/commands/plan

사용 기술

• Claude Code (Opus) — 메인 오케스트레이터
• Sonnet subAgent — 병렬 실행 워커 (≤3)
• .claude/skills/ — 스킬 레지스트리
• skill_info.md — 스킬 카탈로그
• skill-cross-reference.md — 의도→스킬 매핑 테이블