2. 글 vs 그림
"다이어그램으로 만들어주세요." 이 말을 듣자마자 그리기 시작하면 안 됩니다. 먼저 생각해야 할 게 있어요.
이거 진짜 그림이 필요한 건가?
1. 글이 나은 경우
이유를 설명할 때
"왜 이 기술을 선택했는가" — 이건 그림으로 표현하기 어렵습니다. 맥락, 판단 근거, 감정은 글이 낫습니다.
순서가 단순할 때
"가입 → 결제 → 완료" — 이 정도는 글 한 줄이면 됩니다. 노드 3개짜리 플로우차트를 그리면 오히려 과합니다.
읽는 사람이 이미 구조를 아는 경우
팀원끼리 "어제 말한 그 플로우에서 B 단계만 바뀜" — 이건 글로 충분합니다. 전체 다이어그램을 다시 그릴 필요 없어요.
2. 그림이 나은 경우
분기가 있을 때
"A면 B로, 아니면 C로. C에서 다시 A로 돌아올 수 있음." — 글로 쓰면 3번 읽어야 합니다. 그림이면 한눈에 보입니다.
동시에 여러 경로가 존재할 때
"유저 A는 이 경로, 유저 B는 저 경로" — 병렬 경로를 글로 쓰면 뒤죽박죽됩니다.
전체 구조를 처음 공유할 때
처음 보는 사람에게 "이 시스템은 이렇게 생겼어"를 전달할 때. 글로 3문단 쓸 걸 그림 하나면 됩니다.
요소 간 관계를 보여줄 때
"A가 B에 의존하고, B는 C와 D 둘 다에 연결되어 있음" — 관계가 3개 이상이면 글로는 한계입니다.
3. 판단 기준표
| 질문 | Yes → | No → |
|---|---|---|
| 분기가 2개 이상인가? | 그림 | 글 |
| 요소가 5개 이상인가? | 그림 | 글 |
| 요소 간 관계가 복잡한가? | 그림 | 글 |
| 처음 보는 사람에게 공유하는가? | 그림 | 글 |
| "왜"를 설명하는 건가? | 글 | — |
| 감정이나 맥락이 중요한가? | 글 | — |
하나라도 "그림"에 해당하면 시각화를 고려하세요.
4. 흔한 실수
실수 1: 뭐든 다이어그램으로
단순한 목록을 플로우차트로 그리면 시간 낭비입니다. 글머리 기호(bullet)면 충분한 걸 굳이 노드로 만들지 마세요.
실수 2: 복잡한 걸 글로만
"이 API는 먼저 인증 서버에 요청하고, 토큰을 받으면 리소스 서버에 전달하고, 리소스 서버는 DB에 조회해서…" — 이건 글로 쓰면 아무도 안 읽습니다. 시퀀스 다이어그램 하나면 끝입니다.
실수 3: 그림만 있고 설명이 없음
그림은 "무엇"을 보여주지만 "왜"는 못 보여줍니다. 그림 + 한 줄 설명이 가장 강력합니다.
5. 체크리스트
- 이걸 그림으로 만들어야 하는 이유가 있다
- 글 한 문장으로 안 끝나는 구조다
- 분기, 관계, 또는 병렬 경로가 있다
- 그림에 "왜"를 설명하는 글도 같이 쓸 계획이다
다음: 00-3. 시각화의 갈래