Excalidraw 프롬프트: 생각을 손그림 다이어그램으로 바꾸는 시각화 하네스

Excalidraw 프롬프트를 처음 만들 때 가장 흔한 실수는 “손그림 느낌으로 예쁘게 그려줘”에서 멈추는 것이다. 물론 Excalidraw의 매력은 그 거친 선과 여백에 있다. 하지만 그 스타일만 흉내 내면 결과물은 금방 어수선해진다. 박스는 많고, 화살표는 여기저기 날아다니고, 읽는 사람은 어디서부터 봐야 할지 모른다.

내가 블로그와 노트 시스템에서 Excalidraw를 다시 보게 된 이유는 스타일 때문이 아니었다. Excalidraw는 생각의 위치를 정하기 좋은 도구다. 무엇을 가운데 둘지, 무엇을 주변으로 밀어낼지, 어떤 개념을 묶고 어떤 개념은 떼어놓을지, 어떤 관계를 화살표로 보이게 할지 결정하게 만든다.

그래서 좋은 Excalidraw 프롬프트는 그림을 부탁하는 문장이 아니다. 그것은 시각화 계약이다. 모델에게 “이 개념들을 이런 위계와 이런 공간 문법으로 배치하고, 이 관계만 화살표로 연결하고, 이 기준을 통과하지 못하면 다시 고쳐라”라고 요구하는 작은 하네스다.

이 글은 SDLC 2.0 치트시트를 만들며 얻은 감각과, 최근 정리한 HTML 출력 프롬프트, 스토리보드 생성 하네스의 흐름을 이어받아 쓴다. 핵심은 하나다. 다이어그램은 장식이 아니라 사고의 검증 장치다.

Excalidraw는 Mermaid와 다르게 써야 한다

Mermaid는 관계가 명확할 때 강하다. 순서도, 상태 전이, 의존성 그래프, 시퀀스 다이어그램처럼 문법으로 고정할 수 있는 구조에 잘 맞는다. 코드를 쓰듯이 관계를 선언하면 일정한 형식의 그림이 나온다.

Excalidraw는 조금 다르다. Excalidraw는 엄격한 문법보다 배치의 감각이 중요하다. 중심과 주변, 가까움과 멂, 묶음과 분리, 큰 박스와 작은 메모, 굵은 화살표와 점선 화살표가 의미를 만든다.

그래서 두 도구의 프롬프트도 달라야 한다.

도구	잘 맞는 질문	프롬프트의 핵심
Mermaid	이 관계를 정확한 그래프로 표현할 수 있는가	노드, 엣지, 방향, 상태, 순서
Excalidraw	이 생각을 한눈에 이해되는 판으로 배치할 수 있는가	중심, 영역, 거리, 강조, 주석

Mermaid 프롬프트는 문법을 먼저 잡는다. Excalidraw 프롬프트는 독자의 시선을 먼저 잡는다. 이 차이를 놓치면 Excalidraw는 단순히 예쁜 Mermaid 대체물이 되고 만다.

좋은 다이어그램은 예쁜 선이 아니라 구조의 충실도다

Excalidraw로 만든 그림이 좋아 보이는 순간이 있다. 손그림 느낌이 있고, 색이 있고, 아이콘도 있다. 그런데 그 그림을 설명하려고 하면 말문이 막힌다. 왜 이 박스가 여기 있는지, 왜 이 화살표가 저쪽으로 가는지, 무엇이 핵심이고 무엇이 보조인지 설명이 되지 않는다.

그런 그림은 예쁜 낙서에 가깝다.

좋은 다이어그램은 반대로 조금 투박해도 설명이 된다. 가운데에 놓인 개념이 전체 질문을 붙잡고, 주변 그룹이 그 질문을 나누어 받으며, 화살표가 읽는 순서를 만든다. 작은 주석은 독자가 오해하기 쉬운 지점을 미리 잡아준다.

나는 Excalidraw 프롬프트를 만들 때 다음 여섯 층을 먼저 정한다.

층	질문	프롬프트에 적을 내용
중심 질문	이 그림이 무엇을 이해시키는가	한 문장 제목과 중심 노드
개념 위계	무엇이 1차, 2차, 3차 개념인가	큰 그룹, 하위 박스, 보조 메모
공간 문법	어디에 무엇을 둘 것인가	중앙, 좌우, 상하, 가까움과 멂
화살표 의미론	어떤 관계만 선으로 연결할 것인가	인과, 순서, 피드백, 대비, 의존성
주석 층	어떤 오해를 짧게 풀어줄 것인가	캡션, 콜아웃, 작은 예시
검증 루프	좋은 그림인지 어떻게 확인할 것인가	모바일 가독성, 화살표 추적, 중심성

이 여섯 층이 없으면 모델은 대체로 많은 것을 그린다. 하지만 많이 그리는 것과 잘 보이게 만드는 것은 다르다. Excalidraw 프롬프트의 목표는 화면을 채우는 것이 아니라 설명의 길을 만드는 것이다.

Excalidraw 프롬프트의 기본 템플릿

내가 반복해서 쓰기 좋은 기본형은 아래와 같다. 그대로 붙여 넣어도 되고, 글의 성격에 맞게 줄여도 된다.

당신은 Excalidraw 다이어그램 설계자다.

목표:
- [이 다이어그램이 독자에게 이해시킬 핵심 질문]

입력 자료:
- [요약, 글, 회의록, 개념 목록, 코드 구조]

시각화 계약:
- 중심 노드 1개를 정한다.
- 1차 그룹은 3~5개로 제한한다.
- 각 그룹은 서로 다른 영역에 배치한다.
- 화살표는 인과, 순서, 피드백, 대비, 의존성을 구분한다.
- 텍스트는 한 박스당 20자 안팎으로 줄인다.
- 장식보다 관계를 우선한다.

Excalidraw 스타일:
- 손그림 느낌, 넉넉한 여백, 낮은 채도.
- 색은 그룹 구분에만 사용한다.
- 아이콘은 개념 이해를 돕는 경우만 사용한다.

검증:
- 제목만 보고도 전체 질문이 보이는가?
- 화살표를 따라가면 설명 순서가 생기는가?
- 중앙 개념과 주변 개념의 위계가 분명한가?
- 모바일 캡처에서도 핵심 문장이 읽히는가?

출력:
- 다이어그램 구성안
- 노드 목록
- 연결 목록
- Excalidraw 제작 지시
- 검증 체크리스트

여기서 중요한 부분은 “그려줘”보다 “설계해줘”에 가깝다는 점이다. 실제 .excalidraw 파일을 만들 수도 있고, 사람이 Excalidraw에서 직접 그릴 수 있도록 설계안을 받을 수도 있다. 처음부터 완성 파일을 요구하기보다 구성안, 노드, 연결, 제작 지시를 분리하면 수정하기가 훨씬 쉽다.

LLM Wiki에서는 그림도 노드가 된다

LLM Wiki 관점에서 보면 Excalidraw 다이어그램은 글의 부속 이미지가 아니다. 그것도 하나의 노드다. 글은 문장으로 설명하고, 다이어그램은 관계로 설명한다. 두 노드는 같은 주제를 다른 방식으로 압축한다.

예를 들어 “프롬프트 하네스”라는 글을 쓴다면, 본문은 개념과 사례를 풀어준다. Excalidraw는 그 글의 작동 구조를 보여준다.

LLM Wiki 노드	Excalidraw에서의 형태
핵심 개념	중심 박스
관련 개념	주변 그룹
작동 순서	굵은 화살표
되먹임	되돌아오는 화살표
위험 또는 실패	경고 콜아웃
다음 글감	열린 질문 박스

이렇게 만들면 그림은 단순한 요약이 아니라 다음 글을 부르는 색인이 된다. 독자는 그림을 보고 전체 구조를 잡고, 필자는 그림을 보고 다음에 무엇을 써야 할지 본다.

실패 패턴을 먼저 적어두면 결과가 좋아진다

Excalidraw 프롬프트에는 원하는 결과만 적지 말고 피해야 할 결과도 적어야 한다. 특히 아래의 실패 패턴은 자주 나온다.

실패 패턴	증상	막는 방법
예쁜 혼란	색과 아이콘은 많은데 중심 질문이 없다	중심 노드 1개를 먼저 고정한다
텍스트 과밀	박스마다 문장이 길다	박스당 20자 안팎으로 제한한다
화살표 남발	모든 박스가 서로 연결된다	화살표 의미를 인과, 순서, 피드백 등으로 제한한다
위계 없음	큰 개념과 작은 예시가 같은 크기다	1차, 2차, 3차 노드를 나눈다
썸네일 실패	공유 이미지에서 글자가 안 읽힌다	모바일 캡처 기준으로 재검토한다
마크다운 노출	##, **, 리스트 기호가 그림 안에 들어간다	라벨은 순수 텍스트로 변환하라고 지시한다

이 표를 프롬프트 마지막에 넣으면 모델의 결과가 꽤 달라진다. 모델은 좋은 예시보다 금지 조건을 의외로 잘 따른다. 특히 “마크다운 문법을 라벨에 넣지 말라”는 지시는 꼭 필요하다. 블로그에서 콜아웃 문법이 그대로 노출되는 문제와 비슷한 계열의 실수다.

블로그 글을 Excalidraw로 바꾸는 워크플로

내가 쓰고 싶은 흐름은 단순하다.

1. 먼저 글을 쓴다.
2. 글에서 중심 질문과 1차 개념을 뽑는다.
3. Excalidraw 프롬프트로 시각화 계약을 만든다.
4. 그림 초안을 만든다.
5. 모바일 캡처와 블로그 본문에서 읽히는지 확인한다.
6. .excalidraw 원본과 SVG 또는 PNG 결과물을 함께 보관한다.

이 루프가 중요한 이유는 그림이 글을 다시 고치게 만들기 때문이다. 다이어그램을 그리다가 “이 개념은 중심이 아니었네”, “이 화살표는 근거가 약하네”, “이 그룹은 사실 두 개로 나뉘네” 같은 문제가 드러난다. 좋은 그림은 글을 예쁘게 꾸미지 않는다. 글의 구조를 압박한다.

그래서 Excalidraw는 글쓰기의 마지막 장식이 아니라 중간 검증 도구로 쓰는 편이 낫다. 초안이 어느 정도 생겼을 때 다이어그램을 만들고, 그 다이어그램이 어색하면 글의 구조를 다시 고친다.

내가 앞으로 쓰려는 방식

앞으로 이 블로그의 프롬프트 글, 책 노트, 영상 노트, 뉴스 해설에는 가능한 한 하나의 시각화 노드를 붙이고 싶다. 모든 글에 거대한 인포그래픽이 필요하다는 뜻은 아니다. 어떤 글은 작은 개념 지도 하나면 충분하다. 어떤 글은 흐름도, 어떤 글은 비교표, 어떤 글은 스토리보드가 맞다.

중요한 것은 그림을 넣는 것이 아니라 그림이 글의 사고 구조를 드러내게 만드는 것이다.

Excalidraw 프롬프트는 그 일을 돕는 좋은 중간 언어다. 너무 엄격한 다이어그램 문법으로 생각을 얼려버리지 않으면서도, 너무 자유로운 이미지 생성으로 의미를 흩어버리지 않는다. 손그림처럼 느슨하지만, 제대로 쓰면 꽤 엄격한 사고 도구가 된다.

결국 좋은 Excalidraw 프롬프트는 이렇게 말한다.

이 생각을 보기 좋게 그리지 말고, 이해 가능한 위치에 놓아라.

그 차이가 작아 보이지만, 실제 작업에서는 크다. 위치가 생기면 관계가 보이고, 관계가 보이면 빠진 것이 보인다. 빠진 것이 보이면 다음 질문이 생긴다. 그때부터 다이어그램은 이미지가 아니라 지식 관리의 하네스가 된다.