tm-hub-library internal

도구 가이드 구조 설계 과정

draft

도구 가이드 — 구조 설계 노트

1. 시각화에서 도구 전체로 확장

시각화 가이드를 만들고 나니 질문이 나왔다: "시각화 말고 사업이나 교육할 때 쓸 도구는?"

처음엔 도구 종류별로 나열하려 했다:

tool/
├── visualization/
├── note-taking/
├── project-management/
└── ...

→ 이러면 "도구 목록"이지 가이드가 아님.

2. Pain point 기반으로 전환

"뭐가 안 되는가"에서 출발하자.

혼자 사업하는 사람이 반복적으로 겪는 문제를 정리했다:

# pain point 한 줄
1 정리가 안 됨 머릿속에만 있고 구조화가 안 됨
2 뭘 먼저 할지 모름 할 건 20개, 손은 두 개
3 전달이 안 됨 말로 3분 설명해도 이해 안 됨
4 뭐가 되는지 모름 실험은 했는데 결과를 모름
5 가르치기 어려움 나는 아는데 콘텐츠로 못 만듦
6 매번 처음부터 재사용 구조가 없음

3. 교육 도구의 위치

"교육 도구는 어디에?"라는 질문에서 — 교육이 커리큘럼 설계만이 아니라는 걸 정리:

교육할 때 pain point
├── 커리큘럼 설계 — "Day 1~7을 어떻게 쪼개지?"
├── 전달/설명 — "이걸 어떻게 이해시키지?"
├── 평가/피드백 — "이 사람이 이해한 거 맞아?"
└── 동기부여 — "어떻게 끝까지 하게 하지?"

education/으로 묶는 게 맞다. 커리큘럼만 따로 빼는 것보다 교육 전체를 하나의 심화 시리즈로.

4. 본편 + 심화 2단 구조

tool/
├── guides/          ← 본편 (입구). pain point → 도구 방향 안내
├── visualization/   ← 심화. "전달이 안 될 때"의 깊은 버전
├── education/       ← 심화. "가르치기 어려울 때"의 깊은 버전
└── ...

본편 guides/가 입구 역할. "나 이게 막혀" → 해당 챕터 → 심화가 필요하면 하위 시리즈로.

5. pain point만이 답은 아니다

스킬화를 논의하면서 정리한 것: 주제 성격에 따라 접근법이 달라야 한다.

주제 성격 접근법 예시
도구/방법론 pain point → 도구 추천 시각화, AI 도구
실전 스킬 막히는 단계 → 해결법 글쓰기, 브랜딩
프로세스 순서대로 따라가기 지원사업, 사업자등록
학습 개념 → 연습 → 적용 프레임워크 공부

→ 스킬이 주제를 받으면 성격을 먼저 판단하고, 맞는 접근법으로 목차를 생성하는 구조.

6. 설계 원칙 (공통)

모든 가이드에 적용되는 원칙:

  1. pain point (또는 상황)에서 출발 — 도구 나열이 아니라 문제부터
  2. 기존 연구부터 공부 — 감이 아니라 근거
  3. 직접 테스트 — 같은 작업을 여러 도구로 해보고 채점
  4. 상황별 추천 — "최고"가 아니라 "이 상황에서 가장 나은"
  5. 쉬운 톤 — 지원사업 가이드 벤치마크. 입문자도 읽힘
  6. 3~5분 분량 — 한 문서에 몰지 않고 쪼개기
  7. 체크리스트 — 각 편 끝에 실전 점검

Local Graph

도구 가이드 구조 설계 과정
시각화 리서치 설계 과정