조직화
3단계: 처리된 각 Action을 구조에 배치한다.
조직화란 무엇인가
항목이 행동 가능하고 누가 처리할지 결정한 후에, 배치한다. 그게 조직화다.
조직화는 처리와 다르다. 처리는 무엇인지를 결정한다. 조직화는 어디에 속하는지를 결정한다.
"이게 어디로 가지?"에 대한 답은 짧은 의사결정 경로를 따른다.
의사결정 플로우
기존 Area에 속하는가?
├─ 아니오 → Area 먼저 만들기, 이후 계속
└─ 예
│
├─ 순서 없는 일회성 Action인가?
│ └─ 예 → Area 바로 아래에 추가
│
└─ 아니오 — 순차 흐름의 일부다
│
├─ 기존 Flow에 속하는가?
│ └─ 예 → 해당 Flow에 추가
│
└─ 아니오 — 새 Flow가 필요하다
│
├─ 이 목표에 여러 병렬 흐름이 생길 것인가?
│ ├─ 예 → 새 Project 만들기 + 첫 번째 Flow 만들기
│ └─ 아니오 → Area 안에 새 독립 Flow 만들기대부분의 경우, 경로는 짧다. Action이 있다. 커리어라는 걸 안다. 이직 준비 Flow의 일부라는 걸 안다. 올바른 Flow에 추가한다. 끝.
더 긴 경로는 작업이 진정으로 새로울 때 나타난다: 새로운 목표, 새로운 책임, 삶의 새로운 영역.
Area에 배치하기
맞는 Area가 없다면 새로 만들어야 할 수 있다. 하지만 먼저, 잠깐 멈추고 확인하라: 진정으로 새로운 책임 영역인가, 아니면 이미 있는 Area 안의 Project인가?
"스페인어 배우기"는 새로운 Area가 아니다. "자기계발"이나 "개인 개발" Area 안의 Project일 가능성이 높다.
"프리랜서 작업"은 프리랜서 클라이언트를 받기 시작한다면 새로운 Area일 수 있다 — 지속되는 책임 영역이다. 아니면 일회성 계약이라면 "커리어" 안의 Project일 수 있다.
테스트: 이 책임 영역이 무기한 지속되는가, 아니면 끝이 있는가? 지속된다면 Area일 수 있다. 끝이 있다면 Project다.
Project에 배치하기
여러 Flow가 같은 목표를 공유할 때 Project를 사용한다. Project는 그룹핑이지, 작업 자체가 아니다.
Action을 배치할 때:
- 이 목표에 대한 Project가 이미 있는가?
- 있다면, 해당 Action이 그 Project 안의 기존 Flow에 속하는가?
- Flow가 아직 없다면, 만든다.
때로 단일 Action을 추가하다가 실제로는 새 Flow의 시작임을 깨달을 수 있다. 괜찮다 — 사전에 계획된 뼈대가 아니라, 실제 작업에서 구조가 드러나게 하라.
Flow에 배치하기
대부분의 Action이 도착하는 곳이다. Flow에는 순서가 있다. 거기에 추가하는 것이다.
끝에 추가: 대부분의 새 Action이 가는 자연스러운 위치. 단계별로 순서를 만들어가고 있다면, 새 Action은 다음 단계로 끝에 간다.
중간에 추가: 두 기존 Action 사이에 빠진 단계를 깨달을 때가 있다. 삽입한다. Flow가 자동으로 재정렬한다.
기존 Action 나누기: Action이 하루에 끝내기 너무 크게 자랐다면, 현재 위치에서 나눈다. 두세 개의 작은 순차 Action으로 교체한다.
새 구조 만들기
처리된 항목이 어디에도 맞지 않을 때가 있다. 정상이다 — 특히 처음 설정할 때나 삶이 바뀌는 시점에.
새 Flow 만들기: 활동이 아닌 결과를 묘사하는 이름을 붙인다. "신규 클라이언트 수주"가 "클라이언트 작업"보다 명확하다. "v2 기능 출시"가 "개발"보다 명확하다.
새 Project 만들기: 공통 목표 아래 여러 Flow가 있거나 예상될 때만. "혹시 몰라서" 예방적으로 Project를 만들지 마라. 두 번째 Flow가 등장할 때 드러나게 하라.
새 Area 만들기: 진정으로 새로운 지속적 책임 영역이 있을 때만. 겉으로 "새 Area"처럼 보이는 것 대부분은 실제로는 기존 Area 안의 Project다.
최소 구조 원칙
작업이 필요로 하는 만큼만 구조를 쓴다. 그 이상은 안 된다.
Area 바로 아래에 있는 독립 Action이 Project → Flow → Area 사슬 안의 Action보다 덜 정리된 게 아니다. 그것이 무엇인지에 맞게 올바르게 배치된 것이다.
과잉 구조화는 실제 실패 패턴이다: 단일 Flow에 Project 만들기, 단일 Action에 Flow 만들기, 필요보다 한 단계 더 깊이 중첩하기. 이건 명확성을 더하지 않으면서 조직화 오버헤드만 늘린다 — 그리고 시스템이 필요 이상으로 무겁게 느껴지게 만든다.
의심스러우면 더 단순하게 가라. 여러 관련 것들을 묶어야 할 때 구조를 추가한다. 그 전에는 아니다.
조직화는 가장 조용한 단계
수집(빼내야 하는 긴박감)이나 실행(완료의 만족감)과 달리, 조직화는 화려하지 않다. 정리다. 배치다. 유지보수다.
하지만 시스템을 일관되게 유지하는 것이다. 조직화되지 않은 시스템은 집 없는 항목들을 쌓고, 이게 Inbox 적체로 쌓이고, 이게 불안으로 쌓인다.
목표는: 처리된 모든 항목에 집이 있다. 집이 있으면 적시에 올라온다. 적시에 올라오면 Today를 신뢰할 수 있다. Today를 신뢰할 수 있으면 전체 시스템이 작동한다.