같은 주문, 두 번 시켰다

검수 질문은 하나다. 이 스킬을 깔면 산출이 실제로 달라지는가. 동일한 주문(웹서비스 아키텍처: 사용자, 로드밸런서, 웹서버 2대, API 서버, PostgreSQL, Redis)을 같은 모델로 스킬 없이 한 번, 장착하고 한 번, 격리 폴더에서 실행해 대조했다.

• 스킬 없음: 유효한 XML을 손으로 직접 썼다. 7노드 7엣지, 끊긴 연결 0. 배치도 왼쪽에서 오른쪽으로 깔끔했다
• 스킬 장착: XML을 쓰지 않았다. 다이어그램 IR(중간 표현)을 JSON으로 선언하고, 동봉 diagramctl.py가 도면을 생성·검증했다. UML 액터 도형, 엣지 라벨(SQL·cache)이 붙었다
• 정직하게 적으면, 완성 그림만 보면 차이가 작다. 소형 그림의 배치는 오히려 스킬 없는 쪽이 나았다(장착본은 그리드 배치라 대각선 교차가 생겼다, 자동 배치는 15노드 이상용으로 설계돼 있다)

둘 다 repo 동봉 검증기(validate.py)에서 0 에러. 즉 "그리기" 승부가 아니다. 차이는 산출물의 성질이다. 손으로 쓴 XML은 일회용이고, IR에서 나온 도면은 코드가 바뀌면 배치를 잃지 않고 갱신(sync)하고, 경영진용·배포용·보안용 뷰를 파생하고, CI에서 아키텍처 규칙을 검사할 수 있는 입구가 된다.

한 가지 실무 함정도 재현됐다. 첫 실험에서 Skill 도구 발동이 막힌 환경에선 장착해도 스킬 없는 산출과 똑같이 나왔다. 스킬은 깔려 있는 것과 발동되는 것이 다르다.

이 스킬의 실체는 소프트웨어다

SKILL.md는 141줄인데, 본문 대부분이 요청 유형 24갈래를 20편의 참조 문서와 44개 파이썬 스크립트로 보내는 라우팅 테이블이다. 자연어 작도, 15노드 이상 자동 배치, 코드·Terraform·K8s·compose·SQL·OpenAPI·Protobuf 임포트, 실행 중인 클러스터 실태 반영, 시맨틱 질의·리뷰, PR 시각 diff 봇, CI 게이트, PPTX·HTML 변환, 지하철 노선도 스타일까지 갈래가 나뉜다.

스크립트가 문서의 장식이 아니다. 파이썬 44개 15,419줄, 테스트 파일 18개(최대 1,937줄), 예제 .drawio 27개. 문서가 곧 제품인 스킬 repo가 많은데, 이건 스킬 규격을 입은 소프트웨어에 가깝다.

본진은 그리기가 아니라 관리다

핵심 주장인 "코드를 편집 가능한 도면으로"를 따로 실측했다. 서비스 4개짜리 docker-compose.yml을 diagramctl.py build에 넣자 AI 호출 0회로 4노드(이미지 라벨 포함)·의존 엣지 3개짜리 .drawio가 나왔다. 결정적이라 같은 입력이면 같은 도면이고, 소스가 바뀌면 sync로 따라간다. Terraform·K8s·SQL·OpenAPI도 같은 경로다.

내보내기 걱정은 접어도 된다. 코어(IR·XML·sync·질의·검증)는 파이썬 3만으로 돌았고, 우리 검수도 draw.io 데스크톱 없이 진행했다. 네이티브 PNG 내보내기와 Mermaid 변환에만 draw.io 30 이상이 필요하다.

실측

스타 9,247 · 포크 654, 생성 6개월(2026-03)의 곡선이다. 실체는 커밋 271 · 최근 90일 119 · 기여자 17명 · 태그 44 · 열린 이슈 1. 스킬 repo 치고 드물게 다인 기여와 릴리스 운영이 붙어 있다. 분석 기준 커밋 e0236d1.

가져올 것과 주의

• draw.io로 아키텍처 문서를 유지하는 팀이라면 도입 후보다. 특히 "코드가 진실, 도면은 파생"을 만들고 싶다면 이 IR 구조가 정답에 가깝다
• 스킬 작성법 자체가 배울 거리다. 지식을 본문에 욱여넣지 않고, 얇은 라우팅 테이블 + 참조 문서 + 결정적 도구로 쪼갠 구조는 스킬이 커질 때의 모범 답안이다
• 주의: 한 장 그리고 끝날 그림엔 체감 차이가 작다, 소형 도면 배치는 손 XML이 더 나을 수 있다. 그리고 발동이 안 되면 없는 것과 같다, 설치 후 draw.io를 명시해 요청하는 게 확실하다