Flow

Flow는 순서가 있는 구체적인 작업 흐름이다. 내부는 순차, Flow 간에는 병렬.

Flow란 무엇인가

OTD에서 실제 작업이 일어나는 곳이 Flow다. 특정 결과를 향한, 이름이 있는 순차 Action들의 흐름이다. 미완료 Action이 하나 이상 있으면 활성 Flow이고 — 첫 번째 미완료 Action이 Today에 올라온다.

Flow: 지원서 작성
  1. [Do]       자격요건 확인     ← Today에 올라옴
  2. [Do]       아웃라인 작성
  3. [Delegate] 멘토에게 초안 피드백 요청
  4. [Await]    멘토 응답 대기
  5. [Review]   멘토 피드백 검토
  6. [Do]       최종 수정
  7. [Do]       제출

1번이 Today에 있다. 완료하면 2번이 올라온다. 그렇게 계속된다. Flow가 자기 영역 안에서 "다음에 뭘 해야 하지?" 질문을 처리한다.

내부 순차, Flow 간 병렬

이게 Flow의 핵심 설계다.

내부 순차: Flow 안의 Action들에는 자연스러운 순서가 있다. 현재 Action이 완료되어야 다음 Action이 올라온다. 매일 아침 순서를 결정할 필요가 없다 — Flow가 이미 결정해놓았다.
Flow 간 병렬: 여러 Flow가 첫 번째 Action을 Today에 동시에 올린다. 세 개의 활성 Flow가 있으면 세 가지 작업 흐름에서 동시에 Action이 Today에 올라올 수 있다. 각자 독립적으로 전진한다.

이게 GTD와의 핵심 차이다. GTD의 Project는 하나의 순차 사슬이었다. OTD의 Flow는 동시에 진행되는 여러 독립 사슬이고, 각자 전면 Action을 올린다.

순서를 깨는 경우

순차 순서는 기본값이지, 제약이 아니다. 당신이 지휘자다 — 오버라이드할 수 있다.

같은 Flow의 Action 두 개를 동시에 진행하고 싶다면, 두 번째 Action을 수동으로 Today에 끌어오면 된다. 시스템이 순서를 제공하고, 적절하다고 판단하면 그 순서를 깬다.

순서를 깨는 게 맞는 경우:

두 번째 Action이 더 이상 첫 번째에 의존하지 않는 경우 (1번을 완료하지 않아도 필요한 정보가 있을 때)
대기 시간을 활용해 병렬로 무언가를 시작하고 싶을 때
외부 상황이 바뀌어 원래 순서가 더 이상 유효하지 않을 때

깨지 않는 게 맞는 경우:

그냥 조급한 경우
두 번째 Action이 실제로 첫 번째 없이 완료될 수 없는 경우
첫 번째 Action을 회피하려고 앞으로 건너뛰는 경우

시스템은 순서를 가정한다. 반사적으로가 아니라, 의식적으로 오버라이드하라.

Flow의 위치

Flow는 Area 바로 아래에 있다.

Area: 커리어
  └─ Flow: 이직 준비

Flow를 담는 더 상위의 컨테이너는 없다. 여러 Flow가 같은 큰 목표에 속할 때는 [[키워드]] 접두사로 묶는다 — 아래를 참조.

Flow를 잘 설계하기

Flow의 품질은 Action을 어떻게 정의했느냐에 달려 있다. 잘 설계된 Flow는 매일 아침 명확하고 모호하지 않은 "다음에 할 것"을 준다.

좋은 Flow:

Flow: 비자 신청 준비
  1. [Do]       필요 서류 목록 작성
  2. [Do]       개인 서류 준비 (신분증, 여권 사본)
  3. [Delegate] 인사팀에 재직증명서 요청
  4. [Await]    재직증명서 수령 대기
  5. [Review]   서류 내용 확인
  6. [Do]       신청서 작성
  7. [Do]       영사관 예약
  8. [Do]       신청서 제출

각 Action이 구체적이고, 하루에 완료 가능하고, 모호하지 않다. 올라왔을 때 뭘 해야 할지 정확히 안다.

부실한 Flow:

Flow: 비자 신청 준비
  1. [Do] 비자 관련 작업
  2. [Do] 비자 작업 계속
  3. [Do] 신청 마무리

이건 Action이 아니다 — 모호한 의도다. Today에 올라오면 실제로 뭘 해야 하는지 알 수가 없다.

너무 커진 Flow 나누기

하나의 Flow로 시작했는데, 작업이 진행되면서 병렬로 처리하는 게 나은 독립적인 흐름들이 생겨났다. 이때는 Flow를 쪼개고 공통 [[키워드]] 접두사로 묶는다.

나눌 신호:

Action들이 너무 많아져서 실제로는 두세 개의 독립 흐름이 됐다
한 부분을 위임하면서 다른 부분을 계속 진행하고 싶다
"Flow"가 너무 넓어져서 명확한 순차 순서가 없어졌다

나누는 방법:

Action들을 작업 흐름별로 여러 Flow로 분리한다
각 새 Flow 이름에 공통 [[키워드]] 접두사를 붙인다

전환 전 — 너무 커진 하나의 Flow:
Flow: 웹사이트 런칭
  1. 카피 작성
  2. 디자인 목업
  3. 사이트 개발
  4. 분석 세팅
  5. SEO 점검
  6. SNS 공지

전환 후 — 세 개의 병렬 Flow로 분리:
Flow: [[웹사이트 런칭]] 콘텐츠 & 디자인   (카피 → 목업 → 최종 검토)
Flow: [[웹사이트 런칭]] 개발              (개발 → 분석 → SEO)
Flow: [[웹사이트 런칭]] 런칭              (소프트 런칭 → 공지 → 모니터링)

가나다·알파벳 정렬에서 세 Flow가 자동으로 옆에 배치된다. 런칭이 끝나면 세 Flow를 삭제하기만 하면 된다 — 별도로 관리해야 할 컨테이너가 없다.

Someday Flow

지금 작업하지 않을 Flow는 Someday로 옮긴다. Today에 Action을 올리지 않는다. Weekly Review의 Someday 목록에서 검토된다.

이건 삭제와 다르다. 포기하는 게 아니라 보관하는 것이다. 상황이 바뀌면 (시간이 생기고, 기회가 돌아오고, 목표가 다시 관련성을 가지면) 활성화하면 다시 Action을 올리기 시작한다.

Flow와 완료 신호

모든 활성 Flow는 계속해서 다음 Action을 올린다. 시스템이 스스로 전진하고 — 올라온 Action을 완료하기만 하면 된다.

이 말은 Flow를 "끝내는" 유일한 방법은 모든 Action을 완료하는 것이라는 뜻이다. 마지막 Action이 체크되면 Flow가 완료된다. 그 완료는 Area의 건강으로 이어진다.

이 사슬 — Action → Flow → Area — 이 OTD를 고립된 태스크의 모음이 아닌 일관된 시스템으로 만드는 것이다.

반복 Flow

반복 Flow는 모든 Action이 완료된 후 리셋되고, 다음 예정 주기에 시스템에 재진입한다.

Flow: 주간 보고서  (반복: 매주 금요일)
  1. [Do]       이번 주 진행사항 정리    ← 다음 금요일에 여기서 다시 시작
  2. [Do]       초안 작성
  3. [Delegate] 팀장에게 검토 요청
  4. [Await]    피드백 대기
  5. [Review]   피드백 처리 및 완성

마지막 Action이 완료되면 Flow가 1번 Action으로 리셋된다. 다음 예정 날짜에 1번 Action이 Today에 다시 올라온다 — Flow가 새로 시작되는 것처럼.

사용자 관점: 같은 Flow가 매 주기마다 새로 시작된다.
도구 관점: 내부적으로 새 인스턴스가 생성되어 히스토리가 보존된다. 사용자에게는 초기화된 상태로 보인다.

반복 Flow를 쓰는 경우:

작업이 정기적으로 반복되고 두 단계 이상인 경우
매 주기마다 순서가 강제되어야 하는 경우
예: 주간 보고서, 월간 리뷰, 스프린트 회고, 온보딩 체크리스트

반복 Action(Flow 아님)을 쓰는 경우:

반복 작업이 단일 단계인 경우
예: 경비 제출, 정기 체크인 메시지, 주기적 백업

반복과 Mode: 반복 Flow는 Delegate와 Await Action을 포함할 수 있다. 새 주기마다 새로운 위임 지시를 보내고 새로운 Await 사이클이 시작된다. Mode 구조는 반복 Flow와 일회성 Flow에서 동일하게 작동한다.

Flow ​

Flow란 무엇인가 ​

내부 순차, Flow 간 병렬 ​

순서를 깨는 경우 ​

Flow의 위치 ​

관련 Flow 묶기 ​

Flow를 잘 설계하기 ​

너무 커진 Flow 나누기 ​

Someday Flow ​

Flow와 완료 신호 ​

반복 Flow ​