tm-hub-library internal

2. 글 vs 그림

published 섹션: 기초 Updated: 2026-04-22

"다이어그램으로 만들어주세요." 이 말을 듣자마자 그리기 시작하면 안 됩니다. 먼저 생각해야 할 게 있어요.

이거 진짜 그림이 필요한 건가?

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. 시각화의 갈래

Local Graph