Project
Project는 여러 Flow를 포함할 만큼 큰 목표다. 명확한 끝이 있다. Area 안에 속한다.
예: "앱 런칭", "이직 준비", "컨퍼런스 발표", "이사".
Project란 무엇인가
OTD의 Project는 GTD의 "Project"와 다르다. GTD에서 Project는 둘 이상의 Action이 필요한 모든 것이다. OTD에서 Project는 하나의 목표를 공유하는 여러 관련 Flow를 묶는 것이다.
이 구분이 중요하다. OTD에서 하나의 순차적 작업 흐름은 Flow이지, Project가 아니다. Project는 여러 Flow가 하나의 더 큰 결과에 기여할 때만 등장한다.
Project: 앱 런칭
├─ Flow: MVP 개발
├─ Flow: 런칭 마케팅 준비
└─ Flow: 인프라 세팅각 Flow는 별개의 작업 흐름이다. 병렬이다: 제품을 만들면서 마케팅도 준비할 수 있다. 하지만 같은 목표 — 앱 출시 — 를 공유하므로, 같은 Project 아래에 속한다.
Project를 쓰는 경우
결정 기준:
"같은 목표를 향해 동시에 독립적으로 진행할 수 있는 여러 작업 흐름이 있는가?"
예 → Project (그 흐름들을 Flow로 만들어 Project 아래에 묶는다) 아니오 → Flow (하나의 순차 흐름, Project 불필요)
Project를 쓰는 경우:
- 여러 Flow가 병렬로 진행될 수 있을 때. 개발하면서 마케팅도 할 수 있다. 이력서를 업데이트하면서 기업 리서치도 할 수 있다.
- 전체 진행 상황을 한 곳에서 추적할 만큼 목표가 클 때.
Project를 쓰지 않는 경우:
- 하나의 순차 흐름뿐일 때. "개인 웹사이트 리디자인"이 단계별로 하나씩 진행된다면, Flow 하나면 충분하다.
- 목표가 모호할 때. "건강 개선"은 Project가 아니다 — Area다. "하프마라톤 완주"는 Project일 수도, 하나의 Flow일 수도 있다 — 병렬 흐름이 몇 개인지에 따라 다르다.
Project를 Flow로 되돌리기
반대 방향도 있다. 병렬 흐름을 계획했는데, 실제로는 순차적으로 하고 있다. 병렬 구조가 도움이 되지 않고 오히려 오버헤드만 된다.
되돌릴 신호:
- Project 안의 Flow들이 실제로 동시에 진행된 적이 없다
- 항상 하나의 Flow를 끝내고 다음 Flow를 시작한다
- Project가 추가 구조에 비해 아무 이점도 없다
되돌리는 방법:
- Project의 모든 Flow를 순서에 맞게 하나의 Flow로 합친다
- Project 컨테이너를 삭제한다
- 단일 Flow를 Area 바로 아래로 이동한다
전환 전 — 실제로는 병렬이 아닌 Project:
Project: 이직 준비
├─ Flow: 이력서 준비 (항상 먼저 끝냄)
└─ Flow: 지원 (이력서 완료 후에만 시작)
전환 후 — 하나의 Flow로 합침:
Flow: 이직 준비
1. 이력서 업데이트
2. 포트폴리오 정리
3. 기업 리스트 작성
4. 지원서 제출
5. 인터뷰 준비구조는 실제로 일이 어떻게 이루어지는지를 반영해야 한다. 처음에 바라던 방식이 아니라.
Project가 중요한 이유: 예시
앱 런칭을 예로 들면, 보통 세 가지 별개의 작업 흐름이 필요하다:
- 제품 개발 — 범위 정의, 개발, QA, 버그 수정
- 런칭 준비 — 랜딩 페이지, 공개 문구, 홍보
- 인프라 세팅 — 호스팅, 분석, 결제, 모니터링
이 세 흐름은 진짜로 병렬이다. 개발하면서 랜딩 페이지 카피를 위임할 수 있다. 개발이 끝나기 전에 인프라 세팅을 시작할 수 있다. 각자 고유한 순서와 리듬이 있다.
Project 없이 묶으면, 세 Flow가 Area에 연결 없이 흩어진다. 목표 — 앱 출시 — 가 시스템 수준에서 보이지 않게 된다.
Project를 쓰면:
- 전체 목표가 궤도에 있는지 한눈에 보이는 단일 지점이 생긴다
- Weekly Review에서 명확한 단위가 된다: "이 Project 진행 중인가?"
- 자연스러운 Someday 대상이 된다: 런칭을 미루면 Project 전체가 Someday로 이동한다
Someday Project
비활성화된 Project를 Someday라고 부른다. 지금은 작업하지 않지만, 나중에 할 수 있다.
Project를 Someday로 이동하면:
- 그 안의 Flow들이 Today에 Action을 올리지 않는다
- Weekly Review의 Someday 목록에 나타난다
- 준비가 되면 다시 활성화할 수 있다
이것이 Project 수준에서 GTD의 "Someday/Maybe" 개념을 처리하는 방식이다. 좋은 아이디어는 버리지 않는다. 때가 될 때까지 보관한다.
Project vs. Area vs. Flow
경계가 중요하다. 구분 방법:
| 끝이 있나? | 포함하는 것 | 예 | |
|---|---|---|---|
| Area | 없음 | Project, Flow, Action | 커리어 |
| Project | 있음 | 여러 Flow | 이직 준비 |
| Flow | 있음 | 순차적 Action들 | 포트폴리오 준비 |
끝이 없으면 Area다. 끝이 있고 여러 작업 흐름을 포함하면 Project다. 끝이 있고 하나의 작업 흐름이면 Flow다.
Weekly Review에서 Project
Weekly Review 때 모든 활성 Project를 보며 묻는다: 전체 목표가 궤도에 있는가?
이건 개별 Flow 검토와는 다른 질문이다. Project를 하나의 단위로 바라본다: 모든 Flow가 전진하고 있는가? 막혀 있는 Flow가 있는가? 끝이 여전히 현실적인가?
뚜렷한 진전 없이 오랫동안 멈춰 있는 Project가 있다면 Someday로 옮긴다. 비활성 Project를 활성 목록에 방치하지 마라 — 아무것도 전진시키지 않으면서 인지 부하만 늘린다.