Claude Code 라우팅 매트릭스 빈 행 3개를 새 전문 에이전트로 메운 회고

매트릭스를 박은 직후, fallback 행이 마음에 걸렸습니다

지난 글 라우팅 매트릭스를 글로벌 CLAUDE.md 와 review-loop SKILL.md 에 박은 회고 의 마지막 단락에서, 1~2주 후 다시 측정해볼 항목 네 가지를 적어두었습니다. 그 중 마지막이 "fallback 으로 흘러간 general-purpose 호출 prompt 에 영역만 명시해두면 다음 진단의 매트릭스 갭 보강 자료가 되어 준다" 였습니다. 그 자체로 합리적인 룰이라고 생각해서 적어두었는데, 박스를 박고 자리에서 일어나려는 순간 그 한 줄이 손쉽게 1~2주 미루기 좋은 변명이 될 수 있겠다는 생각이 들었습니다.

매트릭스 24행을 그대로 다시 들여다보니, 제 환경에서 specialized 로 매칭이 안 되어 fallback 으로 흘러갈 수밖에 없었던 도메인이 의외로 어렵지 않게 떠올랐습니다. 7일치 transcript 자가 진단 에서 잰 general-purpose 비중 40%·69% 의 상당 부분이 사실 정해져 있는 도메인으로 흘러가고 있었던 셈입니다. 이번 글은 그 빈 행 세 개를 그날 자리에서 새 전문 에이전트로 메운 짧은 후속편입니다.

devops-engineer — 컨텍스트가 매번 흩어지던 영역

가장 먼저 눈에 들어온 건 인프라 운영 영역이었습니다. 제 모노레포는 Coolify 로 8개 서비스를 배포하고 있고, 별도 자동화 레포에는 LaunchAgent 기반 cron 자동화가 다섯 개 이상 떠 있습니다. multi-stage Dockerfile 의 api / worker target 분기, Coolify 의 build args 주입, KeepAlive 의 {Crashed: true} 정책, autossh 의 ServerAliveInterval 30 옵션 — 패턴이 적지 않은데, 정작 등록된 sub-agent 중에는 인프라 운영을 도메인으로 잡은 친구가 없었습니다.

매번 호출할 때마다 같은 컨텍스트를 시스템 프롬프트에 다시 주입하고 있었던 셈입니다. ~/.claude/agents/devops-engineer.md 한 파일에 그 컨텍스트와 안티패턴 — 포트 충돌 시 무관 PID 를 죽이지 않기, docker compose down -v 의도 명확화, 시크릿은 build args 로만 주입 — 까지 박아두었더니, 매트릭스에 새로 한 행이 깔끔하게 들어왔습니다. 이전이라면 general-purpose 로 갔을 인프라 작업이, 이제는 그 자리에서 자기 페르소나로 시작합니다.

dba — 정의를 한 번 좁게 잡았다가 즉시 되돌렸습니다

두 번째로 떠올린 영역은 데이터베이스였습니다. 그런데 처음에는 DBA 를 "운영 부하 분석" 으로 좁게 잡고, ROI 가 낮으니 우선순위에서 빼자고 결론을 냈습니다. MongoDB Atlas 와 HeatWave MySQL 이 매니지드 서비스라 slow query 분석이나 replica lag 모니터링 같은 운영 작업이 콘솔 쪽으로 위임되어 있다는 점이 이유였습니다.

다행히 그 자리에서 피드백을 받았습니다. "새 기능 만들 때마다 일어나는 인덱스 추가, 컬럼 변경, 쿼리 설계가 가장 빈번한데 그건 어디 소관이냐" 라는 지적이었습니다. 곰곰이 생각해보니 정확했습니다. 운영 분석 빈도는 낮지만, 개발 중 스키마 진화 빈도는 새 기능 PR 마다 발생합니다. 처음 잡은 정의가 좁았던 탓에 ROI 가 낮게 보였을 뿐, 사실 가장 빈번한 모드가 정의 안에 빠져 있었던 것입니다.

정의를 다시 잡아 세 가지 모드를 한 agent 의 본문에 같이 박았습니다. 모드 A 개발 변경 (가장 빈번 — 새 컬럼·인덱스·쿼리 설계), 모드 B 운영 분석 (낮은 빈도 — slow query·lock·replica lag), 모드 C 캠페인 마이그 (ORM 전환·dual-write·cutover 같은 단계적 데이터 이동). 같은 도메인이라 컨텍스트가 공유되고, 호출 시점의 입력 신호로 모드를 분기합니다. 정의를 어디까지 넓힐지가 위임 판단을 절반은 결정한다 는 사실을 데이터를 기다리지 않고도 빠르게 확인한 케이스였습니다.

test-data-verifier — e2e 가 영상까지만 보던 자리

세 번째 빈 행은 조금 의외의 자리에서 나왔습니다. 이미 등록되어 있는 e2e-test-dev 의 description 을 다시 들여다보니 "Playwright 로 사용자 시나리오를 테스트하고, 영상 녹화/스크린샷으로 결과를 검증한다" 까지였습니다. 그 다음 단계 — 시나리오가 끝난 직후 DB 행이 시나리오 기대값과 정말 일치하는가, Bull 큐에 알림이 enqueue 되었는가, ISR revalidation 이 트리거되었는가 — 는 description 어디에도 적혀 있지 않았습니다.

특히 페르소나 dogfood 가 마음에 걸렸습니다. 도메인별 dogfood 슬래시들이 페르소나 sub-agent 를 여럿 띄워 admin 페이지를 실제로 클릭하게 만드는데, 그 액션이 DB 에 의도대로 반영됐는지는 페르소나 본인이 검증하지 않습니다. 외부 광고 플랫폼 통합 시나리오라면 API 호출 → 인사이트 행 적재 → dedup → 환율 적용까지 매 단계 검증할 자리가 비어 있었던 셈입니다.

이 영역을 새 agent 로 분리하면서 한 가지 룰을 description 에 같이 박았습니다. 운영 DB 검증 절대 금지 — URI 가 mongodb+srv:// 로 시작하면 즉시 중단합니다. 테스트 데이터 검증을 도와주는 도구가 무심코 운영 데이터에 가닿는 것보다 위험한 silent fail 은 없겠다는 생각이 들었습니다. 데이터를 보는 도구일수록, 보지 말아야 할 데이터를 명시적으로 박아두는 일이 본업의 절반쯤은 되는 것 같습니다.

분량 점검도 transcript-diagnose 에 합쳤습니다

새 agent 세 개를 만들고 나니 자연스럽게 다음 질문이 따라왔습니다. 등록된 스킬·에이전트가 늘어날수록 description 이 매 메시지마다 시스템 프롬프트에 누적되는 비용은 어떻게 관리하지. 이 질문은 transcript-diagnose 의 자연스러운 확장이라는 생각이 들었습니다. 호출 시점이 곧 정리·재배치 모드라, 정적 파일 분량 점검을 같은 슬래시 안에 묶어두는 편이 결정의 속도가 빨라집니다. 측정과 정리를 같은 자리에서 본다 는 룰의 일관 적용이라고 보아도 좋을 것 같습니다.

임계 세 가지로 추렸습니다. SKILL.md 본문 500줄 초과 (Anthropic 공식 권장), description + when_to_use 합산 800자 초과 (1,536자 hard cap 의 절반), agent 본문 700줄 초과. 위반 0건이면 한 줄로 끝나고, 있을 때만 표가 나오도록 했습니다. 첫 호출에서 SKILL.md 500줄 초과 4건 (가장 긴 진입점이 776줄, 그 다음이 557·535·531) 과 description 800자 초과 5건이 잡혔습니다. dormant 와 분량을 같은 자리에서 보면 "안 쓰는데 무거운 진입점" 같은 정리 1순위 후보가 즉시 보입니다.

호출 지점마다 박는 것보다 정의를 어디까지 넓힐지가 먼저였습니다

지난 글에서는 호출 지점마다 룰을 박아야 한다 가 핵심 메시지였습니다. 메모리·글로벌 한 곳만으로는 스킬 분기 안까지 도달하지 않는다는 점을 codex 룰에서 한 번 확인하고, 라우팅 매트릭스에서 다시 박았습니다.

이번에 한 단계 더 추가된 것은 정의를 어디까지 넓힐지 입니다. DBA 케이스에서 가장 또렷하게 드러났는데, 같은 도메인이라도 정의를 좁게 잡으면 빈도가 낮아 보여 dormant 후보가 되고, 정의를 넓히면 가장 빈번한 모드를 흡수해 일급 agent 가 됩니다. description 의 트리거 키워드, 책임 범위, backend-dev 와의 경계 표 — 이 세 가지가 결국 정의 작업이라는 생각이 들었습니다. 호출 지점에 박는 작업의 절반은 그 자리에서 무엇을 박을지 정의하는 일이 차지하고 있었습니다.

다음 측정 — 매트릭스가 좀 더 골고루 나오는가

1~2주 후 transcript-diagnose 를 같은 자리에서 다시 돌릴 때 보고 싶은 수치가 다섯으로 늘었습니다. 지난 글의 네 가지 — general-purpose 비중이 40%/69% 에서 내려오는가, specialized 호출이 매트릭스 행에 골고루 분산되는가, fallback prompt 에 영역이 명시되는가 — 는 그대로 두고, 이번에는 새로 박은 세 행 (devops-engineer, dba, test-data-verifier) 에 호출이 실제로 잡히는가 가 추가되었습니다.

호출이 잘 잡힌다면 빈 행을 메운 처방이 효과를 냈다는 결론이 데이터로 받쳐집니다. 잘 안 잡힌다면 description 의 트리거 워딩이 평소 말투와 맞지 않거나, 책임 범위 정의가 여전히 좁다는 뜻입니다. 어느 쪽이든 다음 회고의 자료가 됩니다. 측정은 자동, 판단은 사람 — 이 경계가 매트릭스 갱신 쪽에서도 그대로 작동하는지 보고 싶습니다.

돌이켜 생각해보면, 측정으로 처방을 정하고, 처방을 박고, 박는 자리에서 다시 갱신할 자리를 찾는 — 이 사이클이 한 번에 끝나지 않는다는 것이 이 시리즈의 결론에 가깝다는 생각이 들었습니다. 인프라를 만드는 시간만큼, 그것이 어디까지 자기 일을 해주고 있는지 묻는 시간이 같이 있어야 한다는 점이 며칠치 작업에서 더 분명해졌습니다.