Skip to content

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가 같은 큰 목표에 속할 때가 있다 (예를 들어 두 개의 Flow가 함께 "앱 런칭"이라는 목표를 이룰 때). OTD는 이를 위한 상위 계층을 두지 않는다. 대신 관련 Flow 이름에 [[키워드]] 접두사를 붙인다:

Area: 사이드 프로젝트
  ├─ Flow: [[앱 런칭]] MVP 개발
  └─ Flow: [[앱 런칭]] 런칭 마케팅

접두사의 세 가지 유용한 속성:

  1. 정렬에서 자동 그루핑. 가나다순/알파벳순 정렬에서 이 Flow들이 자동으로 옆에 배치된다. 도구의 추가 기능이 필요 없다.
  2. 자동 정리. 목표가 끝나서 Flow들을 삭제하면 그루핑도 함께 사라진다. 남아서 관리해야 할 태그, 라벨, 폴더가 없다.
  3. 도구 무관. 어떤 도구에서도 작동한다 (메모 앱, 스프레드시트, 전용 태스크 매니저). 가나다순/알파벳순 정렬은 보편적이기 때문이다.

목표에 Flow가 하나뿐이라면 접두사를 붙이지 않는다. 접두사는 둘 이상을 묶을 때만 의미가 있다.

[[키워드]]를 권장하지만, [키워드]나 《키워드》 등 일관된 접두사라면 무엇이든 같은 방식으로 작동한다. 핵심은 정렬에서 묶이는 안정된 접두사다.

도구가 진짜 그룹 기능을 제공한다면 그것을 쓴다. 접두사는 그렇지 못한 도구를 위한 폴백이다. 대부분의 도구가 그렇기 때문에 기본값으로 둔 것이다. 그룹을 1급 개념으로 가진 도구라면 그것을 직접 제공하고, 텍스트 환경에서 넘어온 사람을 위해 접두사도 계속 작동하게 두면 된다. 프레임워크가 요구하는 것은 관련 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"가 너무 넓어져서 명확한 순차 순서가 없어졌다

나누는 방법:

  1. Action들을 작업 흐름별로 여러 Flow로 분리한다
  2. 각 새 Flow 이름에 공통 [[키워드]] 접두사를 붙인다
전환 전: 너무 커진 하나의 Flow:
Flow: 웹사이트 런칭
  1. 카피 작성
  2. 디자인 목업
  3. 사이트 개발
  4. 분석 세팅
  5. SEO 점검
  6. SNS 공지

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

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


Someday와 Wishlist Flow ​

지금 작업하지 않을 Flow는 두 가지 보관 목적지가 있다:

  • Someday: 이 Flow로 돌아올 의도가 있다; 시점만 멈춘 것이다. 1단계가 이미 정의돼 있다.
  • Wishlist: 아이디어를 commitment가 아닌 가능성으로 보관한다. Flow가 충분히 오래 stall되어 "곧 손댈게"가 더 이상 정직하지 않을 때 자주 가는 곳.

둘 다 Today에 Action을 올리지 않는다. 둘 다 Weekly Review에서 검토된다.

이건 삭제와 다르다. 포기하는 게 아니라 실제 진실인 commitment 수준에 보관하는 것이다. 상황이 바뀌면 둘 중 어느 계층에서든 활성화한다 (활성화는 원칙 3을 발동시킨다: 자리를 만들기 위해 무엇이 닫히는지 결정한다).

전체 구분은 Today, Someday & Wishlist를 참조한다.


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이 Flow가 새로 시작되는 것처럼 Today에 다시 올라온다.

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

반복 Flow를 쓰는 경우:

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

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

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

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

Released under the open source license.