brunch

매거진 3시 27분

You can make anything
by writing

C.S.Lewis

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를 롤업하는 방식이 떠올랐다. (하위 항목으로 생성하지 않는 이유는 롤업과 하위 항목의 성격이 다르기 때문. 하위 항목은 꼭지가 정해져 있을 때 사용하면 좋고, 롤업의 경우 하위 항목보다는 더 유연하게 사용할 수 있다.)

방금 만든 예시

앞서 말한 4Ls와 KPT DB를 분리하고 4Ls를 KPT에 롤업하는 방식의 DB를 간단하게 만들어본 것이다. 그래서 디테일한 DB 속성들이 빠져있다. 예를 들어 작성일자 등.


예상되는 장점은 월간 회고를 작성할 때 어떤 과거의 레슨런이 근거가 되어 KPT가 나왔는지 논리를 가질 수 있을 듯하고, 월간 회고 DB를 문서 앞단에 대시보드처럼 고정해 둔 후 회고록을 작성하면 회고록 작성이 훨씬 수월할 것 같다는 것.


이는 OKR에서 주로 사용되는 체크인을 모티브로 한 건데, 분기 회고 시에는 해당 분기에 작성된 KPT를 보고 얼마나 실천했는지 실천 점수를 매기고  리뷰를 하면 좋을 듯하여 해당 속성을 추가했다.


*OKR의 체크인: 주기적으로 목표를 점검하는 방법. 레몬베이스에서 체크인을 다룬 아티클을 읽으면 이해가 쉽다.




그래서?

쓰다 보니 노션을 다루는 내용이 더 많은 것 같다. 따로 노션 세션을 만들어야지..


1분기의 회고 작성 프로젝트는 실패한 것이 맞다. 일단 회고 작성을 건너뛴 날이 반틈이나 되니까. 하지만 좋은 경험을 '많이' 했다는 것은 변하지 않는다. 레슨런을 잊지 않고 작성하고 온전히 내 것으로 만드는데 신경을 써야겠다.


5월에는 내용들을   더 고찰하고, 미세 조정을 가질 생각이다. 내가 회고 등 아카이빙과 관련된 목표 달성에 집중할 수 있도록 말이다.


그러면 다들 행복한 가정의 달이 되길~~!


ⓒ 327roy

매거진의 이전글 늦은 회고록-1
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari