시각화 리서치 — 설계 노트

1. 시작점

다이어그램 도구(Mermaid, draw.io, Excalidraw)를 테스트해보고 싶었다. "어떤 게 좋아?"가 아니라 **"좋다는 걸 어떻게 판단하지?"**가 진짜 질문이었다.

2. 평가체계부터 만들자

처음에 두 축으로 나눴다:

• A축: 생산성 (만드는 사람) — 초기 생성 속도, 수정 비용, 확장 한계, 공유 마찰, 유지보수
• B축: 결과물 품질 (보는 사람) — 즉시 이해도, 구조 전달력, 목적 적합성, 시각 설계, 정보 완결성

→ 여기서 "보는 사람이 실제로 뭘 하는가?"라는 질문이 나왔다.

3. 유저 행동 관점 도입

보는 사람은 다이어그램 앞에서 3단계를 거친다:

1. 스캔 (1~5초): 시작점 찾기 → 흐름 방향 → 전체 크기
2. 탐색 (5초~): 자기가 관심 있는 부분을 먼저 찾음. 전체를 순서대로 안 읽음.
3. 신뢰 (30초~): 자기가 아는 것과 대조. 빠진 게 보이면 전체 신뢰가 떨어짐.

→ 이게 B축을 대체해야 한다는 결론.

4. 기존 평가 프레임워크 5개 발견

→ 처음엔 프레임워크별로 각각 문서를 만들었다.

5. "너무 어렵다" 피드백

프레임워크별 문서가 학술 논문 요약 톤이었다. 입문자 입장에서 안 읽힌다.

→ 지원사업 가이드(biz/guides/)의 톤을 벤치마크. 쉬운 말, 질문 중심, 체크리스트, "왜 이게 중요한지"부터 시작.

6. 목차 구조 설계

첫 번째 시도 — 프레임워크 나열

01. Bertin  02. Tufte  03. Green  04. Nielsen  05. Moody

→ 학술 중심. 읽는 사람은 "그래서 뭐?"가 됨.

두 번째 시도 — 평가 → 테스트 → 결론

00. 다이어그램은 왜 필요한가
01. 사람은 그림을 어떻게 읽는가
02. 좋은 다이어그램의 조건
03~06. 종류별 가이드
99. 결론

→ 낫지만 "다이어그램"에 한정됨.

세 번째 시도 — 시각화 전체로 확장

00. 시각화란 (다이어그램, 차트, 지도 포함)
01. 사람은 그림을 어떻게 읽는가
02. 좋은 시각화의 조건
03~06. 다이어그램 시리즈 (종류별 + 도구별)
(예정) 차트 시리즈
(예정) 지도 시리즈
99. 결론

→ 확장 가능한 구조. 다이어그램 시리즈를 먼저 채우고, 차트/지도는 나중에.

최종 — 도구별 상세 문서 분리

03-1. 플로우차트 — 언제 쓰는가
03-2. 플로우차트 — 잘 그리는 법
03-3. 플로우차트 — Mermaid      ← 도구별 개별 문서
03-4. 플로우차트 — draw.io
03-5. 플로우차트 — Excalidraw
03-6. 플로우차트 — 비교 결과

→ 한 문서에 몰아넣지 않고 3~5분 분량으로 쪼개서 부담 줄임.

7. 프레임워크 원문의 위치

frameworks/ 폴더에 레퍼런스로 남김. 본편 가이드에서는 프레임워크 이름 대신 실전 언어로 풀어씀.

• Bertin → "시각 변수 — 색·크기·모양의 올바른 사용법"
• Tufte → "정보 밀도 — 빼면 더 잘 보인다"
• Moody → "기호 설계 — 보면 바로 이해되는 기호"
• Green → 도구 비교 시 평가 기준으로 녹임
• Nielsen → 도구 비교 시 UI 평가로 녹임

8. 결과

• tool/visualization/guides/ — 본편 30개 문서
• tool/visualization/frameworks/ — 레퍼런스 5개
• 지원사업 가이드와 동일한 톤, 체크리스트 포함, 순차 진행