by
May 04. 2023
늦은 회고록-2(完)
이미 늦어버린 1분기 회고와 4월 회고에 대한 기록
1부에서는 올해 1분기와 4월 동안 진행했던 큼지막한 이벤트들의 경험과 레슨런을 이야기했다. 2부에서는 기존 회고 프로세스에 대한 고찰과 개선에 대해 다룰 예정.
1부가 궁금하다면?
☞ https://brunch.co.kr/@327roy/26
1. 기존 회고 방식
기존에는 회고를 노션 페이지를 하나 만들어서 하고자 했다. 아래가 그 노션인데 거창해 보이지만 별거 없다.
멈춰버린 노션 페이지1.1. 주간 회고(ft. 4Ls)
- 주간회고를 4Ls(Liked, Learned, Lacked, Longed for) 기준에 맞춰 작성한다.
- 상단 사진 속 회고 페이지 속 4Ls와 KPT를 선택할 수 있는 속성을 가진 하나 일상회고_기록 DB를 주간 회고 문서에 표 보기로 불러와 4Ls를 작성한다.
- 4Ls 데이터를 입력할 때는 되도록 한 문장으로 입력하며, 하나의 문장은 하나의 주제를 다루도록 한다.
- 어떤 4Ls가 있었는지 나중에 해당 DB에서 한눈에 모아볼 수 있다.
1.2. 월간 회고(ft. KPT)
동일한 노션 DB를 사용한다.- 월간 회고는 앞서 작성된 4Ls의 로우 데이터를 기반으로 KPT(Keep, Problem, Try)를 작성한다.
- 한 달 동안 작성된 4Ls를 확인하고, 이를 기준으로 비슷한 성격의 로우데이터를 카테고라이징 한다.
- 카테고라이징한 것들을 '앞으로 계속할 것(Keep)', '하지 말아야 할 것(Problem)', '도전해 볼 것(Try)'로 분류하고 짤막하게 아이디어를 담는다.
1.3. 분기 회고(ft. 4Ls, KPT, Brunch)
- 분기 회고는 작성된 4Ls, KPT를 보고 회고록으로 정리한 후 아키이빙한다.
- 사실 2월에 분기 회고에 대한 내용을 정리하려 했지만 그러지 못했다. 그래서 이렇게 브런치로 바로 대체함 ^^
1.4. 왜 이렇게 복잡한가?
위의 사진처럼, 주간/월간 회고는 하나의 DB에서 데이터를 관리하고 있다. 이렇게 설계한 이유는 로우데이터를 CSV로 내보낸 후, 훗날 ChatGPT와 Python을 사용해 문장을 단어 단위로 파싱하여 토큰화하고 이를 토대로 내가 어떤 것에서 많이 배웠고 어떤 것에서 많이 부족했는지 등 분석할 수 있도록 확장성을 고려했기 때문이었다. 결국 내가 꾸준히 입력 안 해서 애매해지긴 했지만. 그래도 여러 장단점이 존재했다.
1.5. 장점
1. 4Ls, KPT를 통해 내용을 정리하기 때문에 애자일하게 할 수 있다. 일상회고의 성격을 겸할 것이라고 기준을 정해놓았던 만큼 4Ls 카테고리를 고르고 후딱 내용을 채워 넣을 수 있다.
2. 나중에 한눈에 보기 편하다. 하나의 DB에서 속성별로 필터를 걸어서 볼 수도 있고, CSV 등 로우 데이터로 내려받을 수 있기 때문에 활용도가 높다.
3. 로우데이터로 내려받을 수 있어 분석 등에 활용할 수 있다.
1.6. 실패 이유
1. 하나의 DB를 활용하려 하다 보니 매번 번거로움이 발생했다. 예를 들어 회고 문서의 표 보기 필터를 바꿔주어야 하는 번거로움 등이 있었다. 막상 주간회고 작성하는 데는 시간이 얼마 안 걸리지만 문서를 복사하고 표 보기 필터 변경하고, 속성 설정하는 과정이 주간회고 작성하는 것과 시간이 비슷하게 들었으니까.
2. 의지가 부족했던 것 같다. 의지가 부족했다는 것은 그만큼 내가 회고를 작성하는데 덜 절실했던 것이고, 이로 인해 동기부여가 되지 않았기 때문이라고 생각한다. 이거는 회고 템플릿 자체의 문제라기보다는 개인의 문제인 만큼, 스스로 동기부여를 할 수 있도록 명분을 만들어야 한다고 생각했다.
2. 개선할 것들
2.1. DB를 개선한다.
- 하나의 DB를 사용하는 것은 좋지만 문서를 빠르게 만들 수 있을 정도로 프로세스 개선이 필요하다.
- 현재는 문서를 생성할 때마다 문서에서 손봐야 하는 내용이 존재한다. 예를 들어 표 보기 필터 등.
- 주간회고, 월간회고를 1개의 DB로 쓰려다 보니 발생하는 문제인 듯하여 이 부분은 지금 구성해 놓은 DB를 분리하는 작업(일종의 비정규화)으로 해결할 수 있을 것 같다.
현재는 하나의 DB로 주간/월간 회고를 관리하려다 보니 속성값이 복잡해진다. 따라서 주간/월간 회고 DB를 분리하자.2.2. 마음을 다시 먹자, 동기부여 필수!
- 나는 회고를 왜 작성하다 멈췄을까. 시간이 그리 오래 소요되는 것도 아니고 말이다.
- 첫 번째 이유로 생각하는 것은 노션에 들어와서 작성해야 하는 것이 상당히 귀찮고, 느린 것이다. 모바일에서 노션 앱을 쓰려고 해도 앱 동작이 느린 것 + 문서별 세세한 설정들을 해야 하는 것에서 망설여진다. 이는 차라리 구글 스프레드시트와 구글 앱시트를 활용해 간단한 앱으로 만들어서 휴대폰으로 처리를 해 버릴까 생각 중이다. 한 달에 한 번 구글 스프레드시트에 쌓인 내용을 노션 DB에 업데이트하는 형태로 말이다.
- 두 번째 이유로 생각하는 것은 개인적으로 우선순위가 높은 일들이 끼어들었기 때문이다. 우선순위가 높은 일을 가끔 주말도 할애하여 처리하게 되면 보상심리가 발생한다. '아, 오늘은 이것 때문에 바빴으니 하루는 건너뛰어도 돼'와 같은 합리화를 하게 된다. 내가 가장 경계해야 한다고 생각하는 것이다. '1시간 공부했으니 30분 누워서 휴대폰해도 돼'는 조심해야겠다.
3. 아이디어
주간과 월간회고 DB를 분리해도 주간 회고를 월간 회고가 포함하고 있는 방식이 될 것이어서 이 DB를 롤업하는 방식이 떠올랐다. (하위 항목으로 생성하지 않는 이유는 롤업과 하위 항목의 성격이 다르기 때문. 하위 항목은 꼭지가 정해져 있을 때 사용하면 좋고, 롤업의 경우 하위 항목보다는 더 유연하게 사용할 수 있다.)
방금 만든 예시