✒ 설명

(0) 들어가며...

평소 노션을 활용하여 계획표를 작성하는데, 노션이 관계형 DB를 지원하는 이점을 살려, 다음과 같은 연관 관계로 계획표 기획하여 관리하였습니다.

위의 계획법은 티아고 포르테의 The PARA Method에 착안하여, 작성한 노션 ERD 입니다. PARA 방식을 모르는 분들을 위해 설명하면, 모든 계획을 4가지 원칙에 따라 관리하는 것입니다.

첫째, 관심사 영역 분리 - 저희들의 삶에는 기간이 정해지지 않고 평생에 걸쳐 책임을 져야 하는 영역이 존재하고, 책임은 지지 않고, 지식이나 취미를 탐구해도 되는 영역이 존재합니다. 이것을 각각 책임의 영역, 관심의 영역 으로 분류 합니다. AREA의 영역
둘째, 위와 같이 분리된 각 영역에 도움이 되는 아이디어, 래퍼런스, 주변인의 조언이 저희 삶에는 하나의 바다 처럼 존재합니다. 좋은 아이디어는 항상 샤워할 때, 산책을 할 때 떠오름으로, 이를 관리할 공간이 또 따로 필요합니다. RESOURCE의 영역
셋째, AREA의 책임 혹은 관심 영역에서 성과를 이루려면, 기한이 정해진 프로젝트가 매 순간 필요 합니다. 이것을 관리하는 영역을 따로 둡니다. PROJECT의 영역
넷째, 위에서 나온 3가지 중 완료하거나 성공하지 못한 일들은 따로 모아둬야 합니다. 자만할 때는 메멘토 모리를 좌절할 때는 성취감을 불러 일으키는 역할을 합니다. ARCHIVE의 영역

이에 착안하여 위의 ERD를 짜고, 다음과 같이 노션을 만들었습니다.

저는 두 달간 해당 계획을 써보며, 몇 가지 문제점을 느꼈습니다. (게을러서 못 지킨 것도 있지만)

BOTTOM-UP 계획표 작성이 어렵다
관심사 자원 분리 부터 하나의 TO-DO-LIST를 작성할 수 있어서, 모든 계획을 명확히하고, 우선순위를 분리해서 할 수 있다는 장점이 있었지만 긴박한 할 일 이 생기거나, 계획의 변경 이 생긴 경우, 이것을 대응하기가 어려웠습니다. 백수 시절에는 이 단점을 크게 못 느꼈으나, 부트 캠프를 다시 시작하며 사이드 프로젝트를 하면서, 긴박하게 해야할 새로운 일들이 하루에도 수십개씩 생겼습니다. 그런 상황에서 고상하게 앉아 계획을 짤 여유가 없었습니다.
TO-DO를 위해서는 노션의 DB가 너무 과하다.
노션의 DB는 특이하게도 하나의 레코드마다 페이지를 주어줍니다. 저는 그저 VAR CHAR (300) 짜리 줄글만 기록하면 되는데, 하나의 사소한 TO-DO를 작성할 떄도 하나의 페이지가 생기고, 그것이 클릭되어 필요없는 페이지로 들어가는 일이 잦았습니다. 이는 메모리 낭비이자 (물론 노션 서버가 낭비하는 거겠지만...), 가볍고 사소한 TO-DO 작성을 스스로도 망설이게 하는 계기가 되었습니다.

그래서 다음과 같이 ERD를 수정하고, 계획표를 간소화 하고자 합니다.

뭐가 바뀐 거야? 라고 의문이 드실 수 있겠지만, TO-DO-LIST DB 부분을 깃 이슈로 대체하였습니다. 이는 위의 두 가지 문제점을 해결할 수 있습니다.

1. 긴박한 일이 추가될 떄는 우선 깃 이슈부터 파서 할 일을 처리하고, 나중에 다시 TOP-DOWN으로 PROJECT와 연결한다.
  개발을 중심으로 하는 제 특성상, 깃 이슈를 많이 쓰게 되어 이 점에서 편하다고 느꼈습니다. Dev-log라는 페이지에 개발 이외의 Log 작성과 관련 할 일들 또한 기록하고 모을 수 있기 떄문에, 선택하였습니다.
1. TO-DO 용 DB 를 관리하지 않아도 됨.
  깃 이슈 자체가 하나의 TO-DO과 되어 연관된 PR을 한데 묶을 수 있었습니다. 이를 통해 DEV 작성과 프로젝트 구현, 알고리즘 문제 풀이도 한 곳에 묶어 관리가 가능하였습니다. 이 떄문에 이 방법을 선택하였습니다.