최근 몇 주 동안 저는 네 가지 작고 집중적인 개발자 도구를 만들었습니다. 이 모든 도구들은 하나의 아이디어를 공유합니다. 즉, 우리의 코드 중 더 많은 부분이 AI에 의해 작성되고 검토됨에 따라, 우리 스스로 LLM 호출을 필요로 하지 않는 방식으로 그 작업을 확인할 방법이 필요하다는 것입니다. API 비용도 없고, 블랙박스 판단도 없으며, 단지 정적 분석과 그래프 알고리즘이 지시받은 대로 정확히 작동하는 방식입니다.

각 도구가 어떤 역할을 하는지 설명드리겠습니다.

skillcheck
SKILL.md 파일용 ESLint 스타일 린터입니다. 이 파일들은 Claude Code, Codex, 그리고 Cursor 에이전트가 스킬을 학습하기 위해 읽는 지침 파일입니다. 프런트매터(frontmatter)의 완전성을 확인하고, 깨진 상대 링크를 포착하며, 설명이 너무 짧거나 길 경우 플래그를 지정하고, 심지어 스킬 파일이 작동을 시작하기도 전에 에이전트의 컨텍스트 창을 초과하지 않도록 토큰 예산을 강제합니다. CLI와 GitHub Action으로 배포됩니다.

github.com/DIYA73/skillcheck

mcp-schema-watch
MCP 서버는 경고 없이 도구 스키마를 변경할 수 있으며, 만약 여러분이 특정 스키마에 의존하고 있다면, 그 깨지는 변경(breaking change)은 프로덕션 환경에서 조용한 실패로 나타납니다. 이 도구는 설정된 MCP 서버들을 폴링하여 각 도구의 스키마를 마지막으로 알려진 스냅샷과 비교하고, 변경 사항이 깨지는 것인지 아니면 단순히 추가적인 것인지를 알려줍니다. Postgres 히스토리, BullMQ 스케줄링 폴링, REST API, 그리고 깨지는 변경에 대해서만 Slack 알림 기능을 제공합니다.

github.com/DIYA73/mcp-schema-watch

pr-blast-radius
'이 PR(Pull Request)이 건드려서는 안 되는 파일을 건드렸는지 여부'를 결정론적으로 확인하는 도구입니다. 리포지토리의 모든 파일에 대한 실제 AST(Abstract Syntax Tree)를 파싱하고, 임포트 그래프(import graph)를 구축한 다음, 변경된 파일들 중 실제로 서로 연결되어 있는 파일과 관련 없는 범위 확장처럼 보이는 파일들을 검사합니다. GitHub Action으로 실행되며 PR에 댓글을 달고 (새로운 댓글로 스팸하는 대신 푸시할 때마다 해당 댓글을 업데이트합니다).

github.com/DIYA73/PR-Blast-Radius-

swarm-trace-viewer

가장 최신 버전이며, 여전히 기초 레이어에 불과합니다. 오케스트레이터(orchestrator)가 수백 개의 서브 에이전트(subagents)로 분산될 때, 실제 실행에서 어디가 잘못되었는지 찾아내는 것은 어렵습니다. 이 실패가 진짜 원인인지, 아니면 단순히 다른 무언가로부터 발생한 하류 연쇄 반응(downstream cascade)에 불과한지 알기 어렵죠. 이것은 평평한 이벤트 목록(flat event list)으로부터 에이전트 트리(agent tree)를 구축하고, 모든 실패를 근본 원인(root cause) 또는 연쇄 반응으로 분류하며, 형제 에이전트들 사이의 통계적 이상치(statistical outliers)를 표시합니다 (높은 팬-인(