수탁 개발이나 SES 현장에 있다 보면, 어쨌든 「그림」을 만드는 상황이 매우 많습니다.

업무 플로우도, 시스템 구성도, ER도, 시퀀스 다이어그램, 화면 천이도, 체제도, CI/CD 파이프라인……. 설계서 페이지를 넘길 때마다 그림, 그림, 그림. 게다가 이것은 고객에게 제출하는 자료이기도 하므로 대충 만들 수 없습니다.

"그럼 AI에게 그리게 하면 되잖아"라고 생각하시겠죠. 저도 그렇게 생각했습니다.

하지만 실제로 ChatGPT나 Claude에게 "이 사양으로부터 업무 플로우도를 그려줘"라고 던지면, 나오는 것은——

✅ 그럴싸함
❌ 하지만, 쓸 수 없음

이라는 미묘한 물건입니다. 색상은 제각각, 범례는 없고, 화살표 방향은 이상하며, 스코프(Scope)도 적혀 있지 않습니다. 결국 리뷰에서 매번 똑같은 지적을 받고, 직접 다시 그리는 상황에 처하게 됩니다. 이것이 AI 주도 개발에서 가장 "맡길 수 있을 것 같으면서도 맡길 수 없는" 영역이 바로 "그림"이었습니다.

그래서, 「그림의 규칙(お作法)」을 통째로 스킬로 담아낸 draw.io 생성 스킬 모음을 만들었습니다. 이 기사에서는 그 내용과 사용법, 그리고 "이것이 누구의 고통을 해결하는가"를 정중하게 쓰겠습니다.

📦 리포지토리는 여기로 →

먼저 결론. 이 스킬이 효과적인 대상은 다음과 같은 사람들입니다.

핵심적인 고통을 한마디로 말하면,

"AI에게 그림을 그리게 해도 '그럴싸하지만 쓸 수 없는 그림'밖에 나오지 않는다. 결국 리뷰와 다시 그리기 작업으로 시간이 녹아내린다"

이것을 해결하는 것이 목표입니다.

원인을 분석해 보면, 대략 이 5가지로 집약되었습니다.

특히 효과적인 점은 "규칙이 개인의 역량에 의존한다"는 점입니다. 시니어 엔지니어의 머릿속에는 "이 색은 App 계층", "파선은 복귀", "한 장에 너무 많이 담으면 분할"과 같은 암묵적인 규칙이 대량으로 존재합니다. 이것을 AI에게 매번 프롬프트로 전달하는 것은 현실적이지 않습니다.

→ 그렇다면, 그 규칙을 "스킬"로서 한 번 제대로 글로 써두고, AI가 상시 참조하게 하면 되지 않을까? 라는 것이 이번의 발상입니다.

Claude Code의 스킬(SKILL.md)은 특정 태스크의 절차·규칙을 Markdown으로 적어두면, 관련 요청이 왔을 때 AI가 자동으로 읽어 들여 따르는 메커니즘입니다.

여기에, 그림 종류별 레시피를 전부 기록했습니다.

• 추출 대상… 무엇을 노드(Node)/에지(Edge)로 할 것인가 (예: 업무 플로우라면 액터→레인, 스텝→박스)
• 레이아웃… 어떻게 배치할 것인가 (예: 구성도는 Client→App→Data→External의 계층 구조)
• 색상 규칙… 어떤 색이 무엇을 의미하는가 (계층·역할별로 고정)
• 점선의 의미… 그림 종류별로 일의적으로 정의 (복귀／배포／겸무 등)
• ID 체계… 노드에 붙이는 접두사 (C-XXX = 컴포넌트 등)
• 스케일 제한… 한 장당 노드 40·에지 60을 상한으로 하며, 초과하면 분할을 제안
• 오해 방지… 타이틀·범례·주석(Scope/전제/대상 외)을 필수화

그리고 출력은 **.drawio (편집 가능한 draw.io 파일)**입니다. 이미지나 Mermaid가 아니라, 고객이 draw.io로 열어서 바로 수정할 수 있는 형식으로 만들었습니다.

주제를 「태스크 관리 앱」으로 통일하여, 각 스킬 내장 템플릿의 완성 예시를 보여드립니다. 이것은 전부 AI가 생성하여 그대로 .drawio 파일로 출력한 것입니다 (수작업으로 다듬지 않았습니다).

Client → App → Data → External의 계층 구조, Cloud/External의 경계, OAuth·Push의 인과 규칙(전송 = 점선).

레인(Lane)으로 책임을 나누고, DB는 조작명(UPSERT 등)으로 표기하며, 검증 실패 시의 리턴 루프는 점선으로 표현. OAuth의 인과 체인(Front → External → Back → DB → Front)도 형식에 맞게 구성.

동기 = 실선 / 비동기 = 점선 / 리턴 = 점선. 활성 구간은 생략하고, 메시지는 「동사 + 목적어」로 통일.

PK/FK를 명시하고, N:N은 중간 테이블(Intermediate Table)로 해소하며, 관계선에 카디널리티(Cardinality, 1..N)를 표시.

dev/stg/prod 환경 대역, 툴 이름(GitHub Actions / ArgoCD)을 명기하고, 수동 승인 게이트(◇)와 모니터링(점선)도 표현.

포인트는, 어떤 도표에도 제목·범례·주석(Scope/전제/대상 외)이 반드시 포함되어 있다는 점입니다. 이것이 「쓸 수 있는 도표」와 「그럴싸해 보이는 도표」의 결정적인 차이입니다.

「마법처럼 아무것도 없이 나오는」 것은 아닙니다. 좋은 인풋(Input)이 좋은 도표를 만듭니다. 그렇다고 너무 어렵게 생각할 필요는 없습니다. 가지고 있는 사양서·회의록·요건을 그대로 붙여넣기만 하면 됩니다.

스킬이 처음에 확인하는(즉, 전달하면 정밀도가 올라가는) 항목은 다음과 같습니다.

요령은 Scope(대상/대상 외)를 처음에 확실히 정하는 것입니다. 이것만으로도 「전체도처럼 보이는 부분도」 같은 사고를 방지할 수 있습니다.

리포지토리(Repository)를 clone 하여, 각 스킬을 Claude Code의 스킬 디렉토리에 두기만 하면 됩니다.

git clone https://github.com/enomoso-pm/drawio-diagram-skills.git
# 각 스킬을 글로벌하게 배치 (프로젝트 단위라면 .claude/skills/ 도 OK)
cp -r drawio-diagram-skills/skills/* ~/.claude/skills/

그 후에는 평소처럼 말을 걸기만 하면 됩니다. 사양이나 회의록을 붙여넣고, 도표 종류와 Scope를 덧붙입니다.

이 로그인 사양으로 업무 플로우도를 draw.io로 만들어줘.
Scope는 「Google OAuth 로그인만」, 추상도는 L1으로 부탁해.
(여기에 사양서 또는 회의록 텍스트를 붙여넣기)

도표 종류에 따라 적절한 스킬이 자동으로 기동하여, 규칙에 따른 .drawio 파일을 생성해 줍니다.

출력된 .drawio 파일을 draw.io (데스크톱 / Web / VSCode 확장)에서 열면,

• 박스 이동·색상 변경·문구 수정이 그대로 가능
• PNG / SVG / PDF로 내보내어 자료에 첨부 가능
• 고객에게도 파일째로 전달 가능 (편집 가능)

「AI로 토대를 한 번에 생성 → draw.io로 미세 조정」이라는 흐름이 도표 작성의 체감 난이도를 가장 낮춰주었습니다.

이 스킬 모음의 본질적인 가치는 외형보다 「그려서는 안 될 도표」를 그리지 않게 하는 것에 있습니다. 몇 가지 예를 들어보겠습니다.

• 인과관계의 제약: 시스템 구성도에서 「외부 서비스로 향하는 화살표는 반드시 App 계층에서」 시작해야 함. Cache / Queue / Storage (Data 계층)에서 외부로 직접 화살표를 내보내는 것은 금지. → AI가 저지르기 쉬운 오류를 차단
• Push 알림 표현 고정: Worker → APNs/FCM은 실선(HTTPS), APNs/FCM → 클라이언트...

는 점선(배포). → 방향과 종류를 한눈에 파악 가능

• 점선의 의미를 도표 종류별로 일의적(Unique)으로 정의: 업무 흐름도(Business Flow)에서는 "되돌아옴(Return)", 구성도(Configuration Diagram)에서는 "배포(Distribution)", 조직도(Organization Chart)에서는 "겸임(Concurrent)". 혼용 금지 및 범례(Legend)에 반드시 명시
• 스케일 제한으로 "과도한 정보 밀집 사고" 방지: 한 장에 노드(Node) 40개, 에지(Edge) 60개를 초과할 것 같으면, 임의로 다 그려버리지 말고 분할안을 제시한 후 그릴 것
• 버전 관리(Versioning) 필수: 파일명에 _v1.0을 부여하고, 덮어쓰지 말고 새 버전으로 저장

요컨대, 리뷰 때마다 매번 지적했던 내용을 처음부터 규칙으로組み込んだ(組み込んだ, 포함시킨) 것입니다. 그래서 출력이 한 번에 리뷰를 통과하기 쉽습니다.

• AI에게 "그림을 그려줘"라고 부탁해도 "그럴싸하지만 쓸 수 없는 그림"밖에 나오지 않는 이유는,
  에티켓(암묵지, Tacit Knowledge)을 AI가 모르기 때문입니다. - 그 에티켓(추출 대상·색상·점선의 의미·인과 규칙·스케일 제한·범례 필수)을
  스킬로 명문화하면, 출력이 단번에 "쓸 수 있는 그림"이 됩니다. - 출력물은
  편집 가능한 .drawio 형식입니다. AI로 토대를 생성하고 → draw.io로 마무리하는 흐름이 가장 편합니다.

• "설계서의 도표가 너무 많다", "리뷰가 소모전이다", "도표만은 AI에게 맡길 수 없었다"라고 느끼는 분들에게 특히 효과적입니다.

도표를 그리는 데 쓰던 시간을 본래 하고 싶었던 설계나 검토에 돌리세요. 꼭 한번 시도해 보세요!

📦

리포지토리(Repository): https://github.com/enomoso-pm/drawio-diagram-skills

7종의 샘플, 템플릿, 각 스킬의 SKILL.md를 동봉하고 있습니다.

도표 종류별 "첫 마디" 템플릿입니다. (여기에 사양/회의록을 붙여넣으세요) 부분에 가지고 계신 정보를 넣어주세요.

# 업무 흐름도 (Business Flow)
이 업무의 흐름을 draw.io의 업무 흐름도로 그려줘.
Scope="(대상 범위)", 추상도=L1. 레인(Lane) 분할과 되돌아오는 루프(Return Loop)도 포함해줘.
...