발표자료를 만들다 다이어그램에서 막히는 순간이 있다. 파워포인트 도형으로 그리자니 선 맞추는 데만 30분이 가고, Mermaid로 뽑으면 개발 문서 티가 그대로 난다. AI에게 그려달라고 하면 어디서 본 듯한 둥근 박스 뭉치가 돌아온다.
diagram-design은 이 구간을 겨냥한 Claude Code 스킬이다. 자연어로 요청하면 27종 다이어그램 중 맞는 타입을 골라, 우리 회사 색과 폰트로, 슬라이드에 바로 붙일 수 있는 파일로 뽑아준다. 저장소 한 줄 소개는 이렇다 — 디자이너가 싫어하지 않을 다이어그램.
이 글은 설치 명령부터 슬라이드 추출까지 실제 사용 순서대로 정리한 가이드다.
무엇을 만들어주나
결과물은 HTML 파일 하나다. 더블클릭하면 브라우저에서 열리고, 인터넷이 끊겨도 열린다. 빌드 도구도, 자바스크립트 엔진도, 외부 이미지 링크도 없다. 다이어그램은 인라인 SVG로 파일 안에 들어 있다.
27종 전부가 세 가지 변형으로 제공된다.
- minimal light — 밝은 배경, 문서·블로그용
- minimal dark — 어두운 배경, 다크 테마 슬라이드용
- full editorial — 요약 카드와 헤더가 붙은 잡지형 레이아웃
접근성도 기본값이다. 모든 다이어그램 SVG에 role="img"와 제목·설명이 붙어서 스크린리더가 읽고, prefers-reduced-motion 설정을 켠 사용자에게는 움직임 없는 정지 화면이 나간다.
설치
Claude Code — 플러그인 마켓플레이스로 설치한다.
/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design
설치 후 자동 업데이트를 한 번 켜두는 편이 좋다. /plugin → Marketplaces → diagram-design → Enable auto-update. Claude Code는 서드파티 마켓플레이스의 자동 업데이트를 기본으로 꺼두기 때문에, 이 토글을 켜야 다음 세션부터 배경에서 갱신된다.
Codex
codex plugin marketplace add cathrynlavery/diagram-design
codex plugin add diagram-design@diagram-design
Pi
pi install https://github.com/cathrynlavery/diagram-design
열려 있는 세션에서는 /reload를 실행한다. Pi는 자동 갱신이 없으므로 업데이트는 pi update --extensions로 직접 당겨온다.
직접 고쳐 쓸 계획이라면 편집 가능 설치. 마켓플레이스 설치는 편하지만, 스타일 가이드를 손댔을 때 업데이트가 덮어쓸 수 있다. 브랜드 토큰을 계속 관리할 거라면 클론해서 심볼릭 링크를 거는 쪽이 안전하다.
git clone git@github.com:cathrynlavery/diagram-design.git ~/code/diagram-design
ln -s ~/code/diagram-design/skills/diagram-design ~/.claude/skills/diagram-design
27종, 무엇을 언제 쓰나
스킬의 핵심은 "어떤 그림을 그릴지"를 사람이 고르지 않아도 된다는 점이다. 요청 내용을 보고 타입을 먼저 고른 뒤, 그 타입의 문법 문서만 읽고 그린다.
표로 옮기면 이렇다. 왼쪽이 우리가 보여주고 싶은 것, 오른쪽이 스킬이 고르는 타입이다.
| 보여주려는 것 | 타입 |
|---|---|
| 시스템 구성요소와 연결 | Architecture |
| 낡은 IT 환경의 현재 상태 (현대화 제안서용) | IT current-state |
| 분기가 있는 의사결정 로직 | Flowchart |
| 주체 간 시간순 메시지 | Sequence |
| 상태와 전이, 조건 | State machine |
| 엔티티·필드·관계 | ER / 데이터 모델 |
| 시간축 위의 사건들 | Timeline |
| 부서 간 인수인계가 있는 프로세스 | Swimlane |
| 두 축 위의 우선순위 배치 | Quadrant |
| 3~5개 기준으로 점수화한 비교 | Radar / Spider |
| 마지막이 처음을 다시 미는 선순환 | Loop (플라이휠) |
| 포함 관계로 표현하는 계층 | Nested |
| 부모 → 자식 관계 | Tree |
| 사람·에이전트·팀의 담당과 보고선 | Org chart |
| 쌓아 올린 추상화 층 | Layer stack |
| 집합 간 겹침 | Venn |
| 순위 계층 또는 전환 이탈 | Pyramid / Funnel |
| 항목 간 수량 비교 | Bar chart |
| 시간에 따른 추세 | Line chart |
| 작업과 단계의 일정 | Gantt |
| 두 변수의 분포와 상관 | Scatter plot |
| 컨테이너 클러스터 위 전체 스택 | High-Level |
| 여러 주체가 데이터를 넘기는 순차 업무 | Process |
| 품질 등급별 데이터 저장소 | Medallion |
| 파이프라인 단계별 역할 분담 | Data flow |
| 소스 → 코어 → 소비자 연동 구조 | DP integration |
| 역할별 접근 권한 매트릭스 | DP security matrix |
전체 갤러리는 cathrynlavery.github.io/diagram-design에서 라이트·다크·에디토리얼 탭으로 넘겨볼 수 있다.
어떻게 쓰나 — 요청 한 줄의 구성
설치 후에는 그냥 말하면 된다. 다만 한 줄을 어떻게 쓰느냐에 따라 결과가 크게 갈린다.
우리 서비스 아키텍처 그려줘. 프론트엔드, 백엔드, 데이터베이스, Redis 캐시.
이 정도만 써도 그림은 나온다. 하지만 문서용 기본 크기에, 기술 용어 그대로, 강조 없이 나온다. 슬라이드에 붙이는 순간 글자가 작아 안 읽힌다.
실무에서 쓸 만한 결과를 한 번에 받으려면 네 가지를 넣는다.
앞의 요청을 네 요소로 다시 쓰면 이렇게 된다.
발표자료에 넣을 서비스 구조도 하나 만들어줘.
- 구성: 웹/모바일 앱 → API 게이트웨이 → 주문 서비스 → PostgreSQL,
주문 서비스 옆에 Redis 캐시
- 용도: 16:9 슬라이드, PNG 3배 해상도
- 청중: 임원 보고 (기술 용어는 최소화)
- 강조: 병목 지점인 주문 서비스 하나만
노드는 7개를 넘기지 말고, 그리기 전에 고른 타입과 뺄 항목을 먼저 말해줘.
실제로 오가는 대화
스킬이 제대로 물렸는지 확인하는 방법이 저장소에 명시돼 있다. 그리기 전에 에이전트가 "어떤 타입으로, 어떤 크기로, 무엇을 뺄지"를 먼저 말하고 시작해야 한다. 바로 그리기부터 시작하면 스킬이 안 붙은 것이다.
실제 진행은 대략 이렇게 흘러간다.
나: 위 요청 (구조도 + 슬라이드 + 임원 + 강조)
에이전트:
타입: Architecture / 크기: slide-16x9 / 밀도 목표 4-5 노드
뺄 것: Redis는 주문 서비스 안의 부속 표기로 합침,
프로토콜·포트 표기는 임원 청중이라 생략
강조: 주문 서비스 1개
→ 진행할까요?
나: 좋아. 진행해줘.
에이전트:
order-architecture.html 저장 완료 (다크·라이트 변형 포함)
나: PNG로 뽑아줘. 3배로.
에이전트:
order-architecture.png (3x) 저장 완료
여기서 중요한 건 중간에 끼어들 수 있다는 점이다. "Redis는 따로 빼줘", "강조를 게이트웨이로 옮겨줘", "노드 하나 더 줄여줘" 같은 수정은 다시 그리는 게 아니라 같은 대화에서 이어서 시킨다.
우리 회사 색으로 바꾸기
기본값은 흰 배경 + 주황 계열 강조색이다. 그대로 써도 나쁘지 않지만, 이 스킬의 진짜 값은 회사 홈페이지 주소 하나로 브랜드를 입히는 온보딩에 있다.
diagram-design을 https://theaxlabs.com 기준으로 온보딩해줘.
홈페이지를 읽고, 색과 폰트를 뽑아, 의미 단위 토큰에 매핑한 다음, 바꿀 내용을 먼저 보여주고 승인받아 references/style-guide.md에 쓴다.
두 가지가 특히 실무적이다.
하나, 대비 검사를 먼저 한다. 홈페이지에서는 멀쩡하던 색이 9~12px 다이어그램 라벨에서는 안 읽히는 경우가 많다. 토큰을 쓰기 전에 WCAG AA 기준으로 본문색과 배경색의 대비를 검사하고, 미달이면 조정값을 제안하면서 이유를 설명한다.
둘, 근거 영수증을 남긴다. 어떤 URL을 읽었는지, 각 색이 어떤 역할로 들어갔는지, 폰트 패밀리와 굵기, 폰트 파일 출처, 대체된 항목이 있으면 무엇인지까지 목록으로 남긴다. 공개된 웹폰트는 그대로 쓰고, 렌더링 후 실제로 적용됐는지 확인한다.
한 가지 안전장치가 더 있다. 새 프로젝트에서 첫 다이어그램을 만들 때, 스타일 가이드가 아직 기본값이면 스킬이 멈추고 묻는다 — 온보딩할지, 토큰을 직접 붙여넣을지, 기본값으로 갈지. 브랜드가 있는 프로젝트에 기본 스킨 다이어그램이 조용히 섞여 들어가는 사고를 막는 장치다.
슬라이드로 가져가기
여기가 PPT 관점에서 가장 중요한 부분이다. 결과물은 HTML이지만, 슬라이드에 붙이려면 이미지가 필요하다.
/diagram-design:export path/to/diagram.html
/diagram-design:export path/to/diagram.html --svg-only
/diagram-design:export path/to/diagram.html --png-only --scale=3
자연어로 "이 다이어그램 PNG로 저장해줘"라고 해도 된다.
- SVG —
<svg>노드만 뽑아내고 폰트를 주입해서 피그마·일러스트레이터에서 그대로 열린다. - PNG — Playwright로 기본 2배 해상도 래스터화. 처음 한 번만 설치가 필요하다.
pip install playwright && playwright install chromium
빔프로젝터로 쏠 자료라면 크기 옵션을 반드시 지정한다. slide-16x9를 주면 viewBox뿐 아니라 글자 크기 단계까지 같이 커진다. 문서용 12px 라벨이 슬라이드에서는 16px로 올라간다. 이 한 줄 차이가 뒷자리에서 읽히느냐 아니냐를 가른다.
내보내기는 다이어그램 본체만 나간다. full editorial 변형의 요약 카드와 헤더는 포함되지 않으니, 그 레이아웃째로 필요하면 브라우저의 전체 페이지 캡처나 PDF 인쇄를 쓴다.
이미 있는 draw.io · Mermaid 되살리기
새로 그리는 것보다 이 기능을 먼저 쓰게 될 팀이 많을 것이다. 기존 .drawio 파일이나 README 안의 Mermaid 블록을 가리키면 같은 내용을 이 디자인 시스템으로 다시 그린다.
/diagram-design:import platform.drawio
/diagram-design:import platform.drawio --size=slide-16x9 --detail=simplified --audience=executive
/diagram-design:import-mermaid README.md --diagram=all
핵심은 변환이 아니라 목적지에 맞추는 것이다. 다이얼이 네 개다.
특히 audience가 실무에서 잘 듣는다. 노드 개수가 아니라 표현을 바꾼다. 저장소의 예시를 그대로 옮기면, 엔지니어용 Auth Service / JWT · RS256 · :8443이 혼합 청중에게는 Auth Service / token check로, 임원 대상으로는 그냥 Sign-in으로 줄어든다. 같은 소스에서 개발팀 문서용과 경영진 보고용을 따로 뽑는 게 명령어 한 줄 차이다.
detail은 정해진 순서로 깎는다 — 장식 → 중복 → 말단 묶음 → 인프라. faithful은 24개 노드까지, balanced는 12개, simplified는 7개다.
작업이 끝나면 무엇을 합치고 무엇을 버렸는지 목록을 준다.
Detail: balanced · 12 source nodes → 8 drawn
Collapsed: "Token valid?" 판단 → Gateway → Auth 엣지 라벨로
Dropped: 1 sticky note ("legacy path, to be retired") — 원본에서 연결 없음
Kept in full: 요청 경로 (Web/Mobile → Gateway → Orders → Postgres)
넘어오지 않는 것은 원본 좌표, 원본 팔레트, 원본 폰트, draw.io의 대각선 연결선 스파게티, Mermaid의 자동 배치다. 넘어오는 것은 구성요소, 관계, 묶음, 방향이다. 압축돼서 편집기에서는 base64 덩어리로 보이는 .drawio.png, .drawio.svg 같은 형식도 읽는다. 텍스트만 파싱하며 렌더링이나 네트워크 접근은 하지 않는다.
디자인 규칙 — 왜 AI가 만든 티가 안 나나
저장소가 밝힌 규칙은 짧다. 강조색은 하나, 초점은 다이어그램당 1~2개. 폰트는 세 종류(제목용 세리프, 노드 이름용 산세리프, 기술 표기용 모노). 테두리는 1px 헤어라인, 그림자 없음, 모서리 반경 최대 10px.
그리고 하나 더 — 모든 좌표와 너비와 간격이 4로 나누어떨어져야 한다. 저장소는 이 항목을 타협 불가로 못 박으면서, 다이어그램이 AI가 만든 것처럼 보이지 않게 하는 결정적 요인이라고 설명한다. 사람 눈은 3px씩 어긋난 간격을 정확히 짚어내지는 못해도 "뭔가 조잡하다"고는 느낀다.
밀도 목표는 4/10이다. 기술적으로 충분하되, 별도 설명이 필요할 만큼 빽빽하지는 않은 수준. 노드가 9개를 넘으면 사실 두 장짜리 다이어그램이라고 본다.
철학은 한 문장으로 요약돼 있다. 가장 품질을 높이는 수정은 대개 삭제다. 뭔가를 더 넣을 게 없을 때가 아니라, 뺄 게 없을 때 완성이다.
안 쓰는 게 나은 경우
저장소가 스스로 선을 그어둔 부분이라 그대로 옮긴다.
- 트윗이나 터미널용 간단한 유니코드 도식 → 다른 도구를 쓴다
- 무언가의 목록 → 표나 불릿이 낫다
- 단순 전후 비교 → 표가 낫다
- 도형 하나짜리 "다이어그램" → 그냥 문장으로 쓴다
그리기 전 판단 기준도 한 줄이다. 잘 쓴 문단 하나보다 이 그림에서 독자가 더 얻는 게 있는가? 없으면 그리지 않는다. 발표자료를 만들 때도 그대로 적용되는 기준이다. 슬라이드를 채우려고 넣은 다이어그램은 대개 문장 한 줄보다 못하다.
복사해서 쓰는 프롬프트 13개
상황별로 그대로 붙여 쓰고 대괄호만 바꾸면 되는 프롬프트다.
처음 한 번만
1. 브랜드 온보딩 — 설치 직후 제일 먼저 할 일이다. 이걸 안 하면 모든 다이어그램이 기본 주황색으로 나온다.
diagram-design을 [https://우리회사.com] 기준으로 온보딩해줘.
추출한 색·폰트를 의미 토큰(paper/ink/accent/title)에 어떻게 매핑했는지
먼저 보여주고, 대비가 부족한 값이 있으면 조정안과 이유도 같이 알려줘.
승인하면 style-guide.md에 반영해.
2. 설치 확인 — 스킬이 실제로 붙었는지 3노드짜리로 확인한다.
diagram-design 스킬로 3노드짜리 간단한 아키텍처 하나 만들어줘.
그리기 전에 고른 타입·크기·뺄 항목을 먼저 말해줘.
발표자료 만들 때
3. 제안서용 구조도 — 가장 많이 쓰게 될 프롬프트다.
제안서에 들어갈 시스템 구조도 만들어줘.
- 구성: [A → B → C, D는 B에 붙음]
- 16:9 슬라이드용, PNG 3배
- 청중: [임원 / 실무진]
- 강조: [핵심 1개]
노드 7개 이내로 하고, 뺄 항목을 먼저 알려줘.
4. 현재 상태 진단(AS-IS) — 현대화·전환 제안서의 첫 장에 들어가는 그림이다. 전용 타입(IT current-state)이 따로 있다.
현대화 제안서에 넣을 AS-IS 환경도를 IT current-state 타입으로 만들어줘.
부서별로 묶어서: [영업팀 - 시스템 나열 / 생산팀 - 시스템 나열 / ...]
노후 시스템은 시각적으로 구분되게 하고, 교체 대상 [X]만 강조해줘.
5. 로드맵 간트 — 일정표를 엑셀로 캡처해 붙이는 것보다 훨씬 낫다.
[6개월] 도입 로드맵을 간트로 만들어줘.
단계: [1단계 진단 - 2주 / 2단계 파일럿 - 6주 / 3단계 확산 - 12주]
16:9 슬라이드용, 현재 시점 표시 넣고, [파일럿] 구간만 강조해줘.
6. 우선순위 사분면 — 임원 보고에서 "그래서 뭐부터?"에 답하는 장표다.
[2분기 과제 목록]을 임팩트 대 공수 사분면으로 배치해줘.
항목: [과제명과 각각의 임팩트·공수 추정]
바로 착수할 [2개]만 강조하고, 사분면마다 이름을 붙여줘.
7. 부서 간 프로세스 — 인수인계에서 일이 막히는 지점을 보여줄 때 쓴다.
[업무명] 프로세스를 스윔레인으로 그려줘.
레인: [영업 / 심사 / 운영 / 고객]
각 단계와 넘어가는 지점을 표시하고, 지연이 생기는 [심사 → 운영] 구간을 강조해줘.
16:9 슬라이드용.
8. 계층 구조 정리 — 아키텍처 원칙, 거버넌스 체계, 기술 스택처럼 "쌓여 있는" 것에 쓴다.
[AI 거버넌스 체계]를 레이어 스택으로 정리해줘.
층: [정책 / 프로세스 / 도구 / 인프라], 각 층에 [해당 항목들]
층마다 담당 조직을 부제로 붙이고, 지금 비어 있는 [프로세스] 층을 강조해줘.
이미 있는 자료 살릴 때
9. draw.io 파일 재작성
[platform.drawio] 파일을 슬라이드용으로 다시 그려줘.
--size=slide-16x9 --detail=simplified --audience=executive
무엇을 합치고 무엇을 버렸는지 목록으로 알려줘.
10. Mermaid 블록 재작성 — README나 기술 문서에 박혀 있는 Mermaid를 발표용으로 바꾼다.
[README.md] 안에 있는 Mermaid 다이어그램 전부를 이 디자인 시스템으로 다시 그려줘.
--diagram=all --size=doc-wide
원본에서 못 살린 게 있으면 알려줘.
나온 결과 다듬을 때
11. 너무 복잡할 때
노드가 너무 많다. simplified 수준으로 다시 그려줘.
무엇을 뺐는지 목록으로 알려주고, 뺀 것 중에 꼭 필요한 게 있으면 말해줘.
12. 강조를 옮길 때
강조색을 [X 노드] 하나에만 남기고 나머지는 중립색으로 바꿔줘.
지금은 강조가 너무 많아서 어디를 봐야 할지 모르겠다.
13. 다크 슬라이드용 변형과 내보내기
같은 다이어그램을 다크 배경 변형으로도 만들고,
둘 다 PNG 3배로 뽑아줘. 피그마에서 쓸 SVG도 같이.
프롬프트를 외울 필요는 없다. "무엇을 / 어디에 붙일 / 누구에게 / 무엇을 강조" 네 가지만 습관적으로 붙이면 나머지는 스킬이 알아서 한다.
정리하며
정리하면 이 스킬이 바꾸는 것은 세 가지다.
- 타입 선택을 사람이 안 한다. 무엇을 보여주고 싶은지만 말하면 27종 중에서 골라준다.
- 브랜드가 한 번에 끝난다. 홈페이지 주소 하나로 색과 폰트가 모든 다이어그램에 적용되고, 대비 검사까지 붙는다.
- 같은 원본이 목적지별로 나뉜다. 문서용, 슬라이드용, 임원 보고용을 명령어 한 줄로 갈아낀다.
Claude Code를 코드 작성 도구로만 쓰던 팀이라면, 이 스킬은 문서·제안서·발표자료 제작으로 범위를 넓히는 가장 낮은 진입 지점이다. 설치 두 줄이면 시작할 수 있다.
스킬 자체를 어떻게 쓰고 조직에 배포할지는 이전 글 'Claude Code를 회사로 만드는 스킬 42종'에서 다뤘다.
AX LABS는 국내 대기업을 대상으로 AX 컨설팅과 AI 에이전트 개발 실무 교육을 수행하고 있습니다. 팀의 문서·제안서 제작 파이프라인에 에이전트를 붙이고 싶다면 문의하기 →
참고
- 저장소: https://github.com/cathrynlavery/diagram-design
- 라이브 갤러리(27종 전부): https://cathrynlavery.github.io/diagram-design/
- 스킬 본문(SKILL.md): https://github.com/cathrynlavery/diagram-design/blob/main/skills/diagram-design/SKILL.md
- Claude Code 플러그인 문서: https://docs.claude.com/en/docs/claude-code/plugins
- Claude Code 스킬 문서: https://docs.claude.com/en/docs/claude-code/skills



