개인지식관리(Personal knowledge management, PKM)

제가 구성한 개인지식관리(Personal knowledge management, PKM)에 대해 소개합니다!

서론​

PKM의 기본 개념​

PKM 은 Personal knowledge management 의 이니셜 약어로써 개인지식관리 라는 뜻을 말합니다.

외부 혹은 자신이 깨달은 지식은 소화하여 내 지식으로 만들고 쌓아가는 일련의 과정을 말합니다.

PKM의 중요성​

정보 의 양이 적다면 단순하게 노트 한권에 지식 을 정리하고 관리 하더라도 큰 문제가 되지 않을 것입니다.
애초에 양이 많지 않으면 노트 에 정리하지 않아도 머리 에서 잘 정리되어서 기억 하고 있을 것입니다.

하지만, 현대 사회 에서 정보 의 양은 기하급수적으로 양이 증가하다 못해 쏟아지고 있습니다.

모든 정보를 흡수하기도 어려워서 정보 에도 우선순위 를 매기고 얻은 정보를 유기적 으로 연결하여 장기 기억력 을 도모하고 나중에 찾아보았을 때 놀라운 아이디어 를 만들어낼 수 있는 능력이 중요해질 것입니다.

즉, 정보 를 얻는 것은 쉽지만 그것을 내 것 으로 만들고 다시 찾아보았을 때 어떤 가치 를 전달할 수 있는가 가 중요해지고 있습니다.

내 PKM 여정의 시작​

늘, 기록 은 중요하다고 생각하면서 살아왔습니다. 과거 의 경험 이자 미래 에 또 같은 실수 를 하지 않도록 도와줄 수 있으면서 쌓인 데이터를 기반으로 추세 와 같은 유의미 한 결과를 도출할 수 있기 때문입니다.

개인적으로 제가 하고 있던 행위가 PKM 인 줄도 모르고 스스로 개인자원관리(Personal Resource Planning, PRP) 으로 부르며 정리하고 있었는데 알고 보니 PKM 과 일치하더군요.

그동안 저에게 맞는 PKM 을 만들기 위해서 많은 노력이 들어갔습니다.

공부, 더 나아가 학습 하고 지식 을 관리한다는 것이 사람마다 다 다르기에 그대로 따라 한다고 해서 능률이 올라가는 것이 아니라 나만의 방법을 찾아야 하는데 그 과정이 고통스럽습니다.

쉽게 고민 없이 할 수 있는 사람도 있겠지만, 고민을 한다면 다른 사람들도 여러 방법에 대해 생각하고 많은 노력을 통해서 방법을 찾았을 것이라고 생각합니다.

체계적인 정리 를 위해 들어간 제 노력과 노하우의 결과를 공유하고 싶었습니다. 이렇게 지식 을 정리하는구나라고 보실 수도 있을 거 같습니다.
그래서 해당 페이지에서는 PKM 에 대한 정의 보다는 저만의 PKM 이 어떻게 구성되어 있는지 소개하는 것이 중점입니다.

지식 을 얻고 , 가공 한다는 것이 순차적 인 과정에 따라 진행되지 않음으로 하나의 페이지 에 순차적으로 작성하여 소개하는데 어려움이 있지만 순서대로 읽어도 최대한 이해할 수 있도록 섹션 을 배치해 보았습니다.

어떻게 관리 하는지가 궁금하다면 방법론을, 데이터 구조 가 궁금하다면 아키텍처를 참고하면 됩니다.

내 시스템의 철학과 원칙​

핵심가치​

정보 에 대해 빠르게 기록 하고 볼 수 있도록 합니다.

거의 모든 정보 에 대해서 기록할 수 있도록 확장성 을, 기록한 정보를 바탕으로 미래 에 더 도움이 될 수 있는 데이터를 볼 수 있는 형태 를 중점으로 기록하도록 발전했습니다.

📜 매니페스토​

단일 진실 공급원 달성​

단일 진실 공급원(Single source of truth)을 달성해서 비슷한 내용은 하나의 Domain 으로 모으도록 한다.

여러 서비스에 동일한 데이터가 분산 되어서 삭제와 통계의 어려움을 겪거나 비슷한 내용이라 Domain을 하나로 합칠 수 있음에 분산시켜서 한눈에 볼 수 없어서 다시 합치기 작업의 반복이다.

처음에 달성하면 이런 문제의 발생을 줄어들겠지만 처음부터 합칠 수 있는 모델 설계는 힘들다. 그럼에도 여러 시나리오를 생각하고 목표에 달성할 수 있도록 노력한다.

일상과 작업 분리​

일상(데일리) 와 개인 생활(개발, 작업) 을 구분해라

• 여기서 말하는 일상 은 무엇일까? 비슷한 또래의 사람들이라면 당연하게 하는 그런 것들을 지칭한다.
  • 예를 들어 약속 , 밥 먹기 , 술 먹기 , 여행 , 행사 , etc.
• 개인 생활 은 보편적이지 않고 나만을 위한 것들을 말한다.
  • 예를 들어 개발 공부 , 내용 정리 , etc.
• 사실 일상 과 개인 생활 의 구분을 모호한 점이 많다. 그렇다면 아래의 질문으로 한번 생각을 해봐라 그렇다면 왜 구분 지어서 관리해야 하는지 느낄 수 있다.
  • 캘린더에 내가 하는 Task 에 대해서 모두 표시할 것인가?
    • Backlog 과 Task 가 캘린더 에 표시되면 어떻게 될까? 오염돼서 내가 원하는 정보를 얻을 수 있을까?
  • Notion 의 종합 캘린더에 친구 생일을 표시할 것인가?
    • 애플 생태계 에 있는데 네이티브 앱으로 연락처에 생일을 등록하면 알아서 캘린더 에도 나오고 알림 도 주는데 굳이?

항상 바뀐다 유연해라​

오늘 좋은 구조가 내일은 별로다. 이건 계속 반복될 것이다.

정리에 집착하지 말아라​

1년 전 반드시 노트로 정리해야 된다고 생각한 것이 1년 후 다시 정리하려고 보면 굳이 정리를 해야 하나? 싶은 생각이 꽤나 많이 느껴질 것이다.

물론 그때 대충이라도 적으면서 머리에 들어갔기 때문에 그런 것 일 수 있지만 정리에 너무 집작하지 않도록 한다.
시간이 지나면 자연스럽게 아무 일도 없던 것처럼 돌아간다.

한곳에 모아서 정리할 수 없다​

한곳에 모아서 정리할 수 있는 방법은 없다고 생각해라
생각의 시작은 나의 뇌에서 시작이다.

정리를 하다 보면 항상 드는 생각이 있다. 여기에 작성하면 안 될 거 같은데? 나중에 새로운 문서가 추가되면 어떻게 배치하지?

위 고민은 끝도 없이 발생한다. 나중에 어떤 문서가 추가될지 예측할 수 없다.

그리고 한곳에 모으는 방법도 불가능하다.

• 개발로 예시를 들어보자
  • react-hook-form 이라는 것을 배울 때 카테고리로 분류할 수 있는 것만 나열해도 배운 시점 , Front-end , HTML , react , TS , etc. 끝도 없이 나온다.
  • 그리고 내가 배운 것을 순차적으로 나열하고 싶어도 일하다가 배운 거 , 퇴근해서 배운 거 , 주말에 개인 시간 투자해서 배운 거 , etc. 로 끝도 없으며 데이터 보안 레벨에 맞게 (회사 것의 중요한 정보는 노출되면 안 되기 때문) 맞춰야 해서 힘들다.
• 헬스로 생각해 보자
  • 웨이트 트레이닝 루틴과 식단은 한 몸인데 내가 식단과 관련된 정보만 식단 페이지에 기입할 것인가?
  • 식단에 대해서 일자도 중요할 것인데 그것은 어떻게 할 것인가?
  • 식단과 같이 병행한 운동을 어떻게 역을 것인가?

Notion 혹은 정리 라는 행위는 내 뇌의 보조적인 기억 도구 라고 생각하자.

대부분의 Insight 혹은 생각은 1차적으로 내 뇌에서 시작된다. 그러다가 통계 혹은 이전 데이터가 궁금할 때쯤 Notion 을 실행해서 찾아보게 된다.

내가 프로그래밍 문법이 궁금해서 Notion 에 정리된 정보를 신용해서 다 읽어보고 하지는 않지 않는가? 일단 내 머릿속에 있는 것을 기반으로 수행한다.

그리고 Notion 의 데이터 구조 또한 내 뇌가 알고 있다.

설명 한곳에 모으는 방법이 있다고 해도 아주 복잡한 스키마 일 확률이 높다 왜냐면 모든 것을 정리하기 위한 스키마이기 때문이다.

시나리오는 아래와 같다.

• 뭐든지 정리할 수 있는 단위를 .txt 라고 생각해보자 마음껏 만들어서 정리하면 된다.
  • 근데 이렇게 정리하니까 데이터가 많아지만 원하는 정보를 찾기 어려워질 것이다.
    • 왜냐고? 모든 것을 정리하는 방법이니까 분류 없이 한곳에 모두 있으니까
  • 그래서 목적에 맞게 카테고리화하려고 하는 작업 (i.e. DB 디자인) 을 하고 나니까 데이터가 분산되는 느낌을 받을 것이다.
    • 왜냐고? 목적에 맞게 분리라는 작업을 진행했으니까
  • 결국 상충 되는 개념인 것이다.
    • 데이터 분산되는 것이 싫어서 DB의 스키마를 무한정으로 확장하면 이전에 .txt 처럼 될 것이다.
    • 모든 DB 의 스키마 다 동일해질 수도? 있을 것이다.

커패서티에 맞게 설정해라​

커패서티(capacity, 캐파)에 맞게 설정해라

어떤 작업을 수행하거나 공부를 하는 행위는 즐겁다.
다만, 그 행위에 대해서 적절한 capacity 를 부여하지 않으면 문제가 발생한다.

주로 공부할 때 이런 현상이 많이 발생하는데 관심 있는 주제/토픽 에 대해서 신기하고 정복하고 싶다고 capacity 에 오버해서 목표를 잡으면 무기한 공부(무기한 Epic)가 진행될 수 있다.

대부분의 일은 모두 우선순위 에 맞게 진행되어야 한다.
capacity 에 맞지 않는 목표 는 중간에 작업을 잘라내기가 어렵다.
이는 다른 우선순위 높은 작업이 들어왔을 때 복잡도 와 레거시 의 성격을 크게 가지게 된다.

하루 종일 하고 싶은 공부, 일만 하게 한다면 capacity 가 오버해도 문제가 없다.
하지만 회사에서 일도 해야 하고, 회사에서 모르는 거 있으면 추가적으로 공부도 해야 하고, 야근도 할 수 있고, 친구도 만나야 하고, 공부 이외 서류 접수 등 다른 업무를 해야 할 수도 있고 변수가 많다.

capacity 에 맞게 단위를 작게 부여 하면 이런 문제가 발생할 여지가 줄어든다.
이는 우선순위 에 맞게 작업을 중단 하고 Context Switch 를 손쉽게 도와줄 것이다.

그렇기에 어떤 작업을 수행하거나 공부를 할 때 목표 를 작게 세분화 해서 달성하도록 해라.
한 번에 달성하면 손쉽게 머리에 들어오고 처리할 수 있어서 좋지만 그 한 번의 처리의 볼륨 은 예상하기 힘들며 유연 하지 않다.

우선순위에 맞게 행동해라​

기본 중에 기본이다.

나의 몸은 하나고 모든 일을 할 수 없다.

중요한 일 먼저 처리하는 것이다.

RM(Resource Management)​

정보 , 자원 으로서 중요하게 생각하는 것을 문서화 해서 관리합니다.

이는 모든 정보 자원 을 노트 앱과 같은 한곳에 관리할 수 없기에 정보 목적에 맞게 특화된 서비스 에 저장되어 관리됩니다.

예시로 Cloud , Mail , 음악 스트리밍 서비스 , Chrome , 카카오톡 , etc 가 있습니다.

개인적으로는 Boundary 를 부여서 해서 관리하고 있는데 예시로 아래와 같습니다.

• Boundary 1
  • 메일
  • 연락처
  • 사진
• Boundary 2
  • Github
  • 네이버 지도
  • 카카오톡
• Boundary 3(보조 기억 장치)
  • HDD
  • USB

흐름​

정보 수집​

다양한 소스로부터 정보를 수집합니다.
이 소스는 책, 논문, 웹사이트, 온라인 코스, 세미나, 워크숍 등 다양할 수 있습니다.
중요한 것은 관련성 높고 질 좋은 정보를 선택하는 것입니다.

수집 경로는 너무나 다양하며 개인적으로는 아래와 같이 정보 의 수립 경로를 분류하였습니다.

• Content: 정적 인 데이터로 커리큘럼 혹은 목차 가 있어서 그대로 따라가면 됨
  • 글, 블로그
  • 책
  • 유튜브
  • 강의
  • 교육 기관
  • 이메일
• Event: 언제 발생할지 모르며 듣고 배운 것을 기록 하는 것이 중점이 됨
  • 질문/ChatGPT
  • 면담
  • 컨퍼런스
• Effort: 목적 을 위해 내가 시간 투자 가 된 것
  • 개인 공부/실험/프로젝트
  • 회사 프로젝트

분류 된 특징은 비슷한 목적을 가진 것으로 이렇게 분류 시 데이터의 형태와 기억에 잘 남는 장점이 있었습니다.

정보 정제​

수집한 정보를 분석하고 이해하기 위한 과정입니다.
여기에는 중요한 내용을 요약하고, 개인적인 생각이나 주석을 추가하는 것이 포함됩니다.
이 단계는 정보를 자신의 지식 체계에 통합하는 데 도움이 됩니다.

현재는 특히나 ChatGPT 처럼 AI 가 나온 시점에서 내가 정리하는 것이 효율적인가?에 대한 생각이 들 수 있습니다.
정리를 하는 순간 stale 데이터가 되는데 fresh 한 데이터는 공식 문서 혹은 AI 에게 실시간 으로 물어보는 게 빠른 텐데 말이죠

그럼에도 정리 라는 것은 가치가 있다고 생각합니다. 내가 겪은 고민 과 경험 이기에 머릿속에 훨씬 기억이 잘 남고 그것은 나의 경쟁력 있는 자산 이기 때문입니다.

그래서 정보 정제 시 내가 공식 문서 를 만들 것처럼 너무 완벽한 정리 는 오히려 시간적 손해임을 인지해야 하며 다시 보았을 때 이런 고민 이 있어서 어떤 가치를 얻었는가(지식, 해결 방법) 을 상기 시킬 수 있는 수준으로 하고 부족한 것은 다시 찾아보는 것이 좋습니다.

정보 조직화​

수집된 정보를 체계적으로 정리하는 단계입니다.
이는 태그, 카테고리, 폴더 등을 사용하여 정보를 쉽게 찾고 접근할 수 있도록 하는 것을 포함합니다.
정보의 효율적인 조직화는 나중에 필요할 때 빠르게 찾을 수 있게 해줍니다.

저는 데이터 목적 에 맞게 Board , DB , Page 의 Collection 으로 분류 하고 제텔카스텐(Zettelkasten)방식으로 정리하며 필요에 따라 tag 를 이용해서 여러 개의 정보를 묶습니다.

Page 데이터는 Role(역할) 과 단체(Organizations) 에 맞게 분류합니다.

계층 구조 의 데이터의 경우 상향식 접근 아닌 하향식 접근 으로 데이터를 정리합니다. 우선 막 적은 다음 구조에 맞게 정리하는 개념인데 처음에는 하향식 으로 구조를 잡고 해보려고 했지만 설계 당시 맞는다고 생각한 구조는 실제 진행 시 다르다는 것을 느끼었고 이미 만들어진 하향식 데이터를 허무는 것도 시간이 많이 들어 실행 후 정보를 찾기 쉽도록 목적에 맞게 분류하는 것이 더 좋다는 것을 느껴 이렇게 바꾸게 되었습니다.

데이터 는 항상 늘어남으로 보고, 추가하기 쉽도록 내림차순 으로 배치합니다.

지식 저장​

조직화된 정보를 저장하는 단계로 디지털 노트, 데이터베이스, 클라우드 스토리지 등 다양한 저장 수단을 활용할 수 있습니다.
중요한 것은 안전하고 접근 가능한 방식으로 정보를 보관하는 것입니다.

대부분의 데이터는 Notion 에 저장하여 이외 중요한 데이터는 클라우드 화 시켜서 안전하게 보관합니다.

지식 검색​

저장된 정보를 필요할 때 쉽게 찾아 사용할 수 있어야 합니다.
효과적인 검색 시스템은 PKM의 핵심 요소 중 하나입니다.

데이터가 많은 경우 전체 검색 으로 원하는 정보는 찾는 경우는 거의 없는 거 같습니다.

그래서 나중에 내가 찾아볼 때 기대하는 위치에 정리한 내용을 배치하는 것을 중점으로 두고 있습니다.

지식 공유​

자신의 지식을 다른 사람들과 공유하는 단계입니다.
이는 블로그 포스팅, 소셜 미디어 게시, 또는 교육 콘텐츠 제작을 통해 이루어질 수 있습니다.
지식 공유는 다른 사람들과의 교류를 통해 새로운 관점을 얻고, 자신의 지식을 확장하는 데 도움이 됩니다.

기록한 내용 중 공유 의 가치가 있는 내용은 블로그 와 같은 Public 한 곳으로 공유 합니다.

방법론​

흐름에 맞게 어떻게 행동하는지에 대해서 서술합니다.

작업 관리: Daily Sprint​

애자일 의 Sprint 에서 착안한 것으로 long term 이 아닌 짧게 하루를 되돌아볼 수 있도록 Daily Sprint 를 진행합니다.

하루에는 아래의 분류 만 있으면 생산적 이 활동도 하고 기록 도 할 수 있다고 생각합니다.

• 오늘 메모
  • 오늘 사용할 메모입니다.
  • 메모에는 할 일이 들어갈지, 기록이 들어갈지 모릅니다.
  • 그래서 PKM 을 관리하는 도구에서 한 번에 관리하도록 하였으며 OS 와 같이 기본 메모장은 종료 시 삭제될 수 있음으로 상시 클라우드에 저장되어 사용할 수 있도록 합니다.
• 오늘 할 일
  • 오늘 할 일에 대해서만 노출합니다.
  • 할 것만 딱 노출하여 집중하고 퇴근 혹은 하루가 종료될 때 놓이는 것이 없도록 합니다.
• 오늘 배운 거
  • 오늘 배운 내용을 토픽 단위로 정리합니다.
  • 기록은 해야 하는데 빠르게 기록한다가 핵심입니다.
• opt: 알림 기반 Todo App
  • 개인적으로는 Apple 에서 제공하는 미리 알림 앱을 사용합니다.
  • 오늘 할 일 에서로 합쳐서 처리할 수 있지만 오늘 할 일 주로 업무 와 관련된 할 일 이 들어가는데 이런 것을 제외하고 마트가서 장보기 , 머리 자르기 와 같은 생활적 인 내용을 알림 으로 받기 위해서 사용합니다.

하루를 마무리할 때는 종합해서 볼 수 있는 Dashboard 를 보면서 정리합니다.

실제로 Notion 을 이용해서 구현된 것을 보면 Daily Sprint 는 손쉽게 데이터에 접근할 수 있도록 아래와 같이 보기 를 만들었으며

Dashboard 는 한눈에 데이터를 볼 수 있도록 보기 를 페이지 에 연결해서 만들었습니다.

목표 지향적 계획: Board​

목표 가 있고 나의 발전 을 위한 데이터는 Board 레벨의 데이터로 관리합니다.

흔히 생각하는 Project 와 유사하며 애자일 스크럼(Agile Scrum) 을 제 개인에 맞게 바꿔 사용합니다.

하이어라키 구조이며 더 자세한 내용은 하단 아키텍처에 설명되어 있습니다.

누적 데이터: DB​

날짜 데이터가 있거나 누적 이 되는 데이터들은 한곳에서 모아서 볼 수 있도록 DB 레벨의 데이터로 관리합니다.

TIL(Today I Learned) , 일기 , 영화 감상평 을 예시로 들을 수 있습니다.

Excel 과 같은 표 형태로 관리한다고 생각하시면 됩니다.

위키: Page​

제목 에 맞게 내용 을 전달하는 것들이 들어가는데 주로 설명서 와 같은 것들이 들어갑니다.

React 기본 개념 , 알고리즘 , 아이디어 , 영어 을 예시로 들을 수 있습니다.

복잡하게 생각할 것 없이 가장 기본적인 메모 단위입니다.

아키텍처​

실질적으로 흐름과 방법론에 맞게 Application 에서 어떻게 구현했는지를 서술합니다.

Notion 기준으로 작성되었지만 구조를 이해하고 다른 App 에서도 사용할 수 있을 것으로 기대합니다.

내비게이션 바 만 보자면 아래와 같이 생겼습니다.

Board​

내가 언제, 뭘 했는가

전진 하는 곳이며 과거의 데이터에 연연하지 않습니다.

상태 가 완료 된 것은 필요한 정보가 모두 입력된 것으로 내용을 신뢰 합니다.

하이어라키 는 반드시 유지하도록 합니다.

내용 은 내가 뭘 했는지 궁금한 것으로 Page 혹은 다른 Level 에 작성하는 것이 맞는다면 그곳에 작성하고 Board 로 연결하도록 합니다.

너무 나도 세세한 시간 작성에 목 메지 않도록 합니다. 제어의 역전 입니다…

Milestone​

새해 목표 같은 것

인생의 큰 목표를 정하는 BluePrint 입니다.

Project 와 간접적으로 영향이 있겠지만 이것을 위해서 Project 가 생성되지는 않습니다.

Project​

최소 분기 단위 기간을 가짐

거대한 목표를 다루기 위한 목표를 가집니다.

하이어라키 의 최상위 입니다.

Epic​

최소 한 달 단위 기간을 가짐

부모 로 Project 를 가지며 Backlog 를 그룹핑하기 위해서 사용됩니다.

여러 개의 Backlog 를 묶어서 대외적으로 말할 수 있는 작업의 단위 입니다.

Backlog​

최소 일주일 단위의 기간을 가짐

부모 로 Epic 을 가지며 목표 혹은 주제가 있는 명확한 단위이며 강의 로 따지면 챕터 라고 할 수 있습니다.

해당 아이템이 가장 기억에 잘 남고 어떤 것을 왜? 해서 결론! 이 나왔는지 보이는 부분이며 보고서 라고 생각할 수 있습니다.

하고 싶은 일들이 쌓아져있는 곳으로 큐레이션(Curation) 을 통해 우선 순위 에 따라 수행됩니다.

Task​

일의 트랜잭션 단위로 주로 1시간 내외로 끝날 수 있는 기간을 가짐

할 일 작성하는 부분이며 내용 정리 같은 내용은 절 때 들어가서는 안됩니다.

여기에는 할 일이 나열되는 것이 있고 정리할 것이 있으면 상위 부모 에 기록하도록 합니다.

Retrospective​

특정 기간마다 진행되는 회고

Project 가 잘 진행되고 있는지, Project 성격에 맞게 되돌아보는 곳, Project 일기라고 생각할 수 있습니다.

주기적인 회고 를 통해 피드백 루프 를 태워서 너무 빠르지는 않는지, 느리지는 않은지 점검 하여 계속 발전을 도모합니다.

DB​

Board 처럼 전진하는 데이터는 아니지만 자주 발생하고 쳬계적으로 모아서 봐야하는 데이터들이 존재합니다.

상황에 맞게 더 추가해서 사용할 수 있으며 저도 더 많은 DB 가 있지만 중요하다고 생각하는 것만 나열했습니다.

Notepad​

아주 명확하게 구분되지 않는 모든 데이터의 집합(임시 저장소) 으로 사용됩니다.

부모 페이지가 어디인지 모르겠고 일단 노트 작성이 필요한 경우 Notepad 를 사용할 것입니다.

어 이전에 작성한 내용이 어딨지…? 하면 Notepad 으로 가서 찾아볼 것입니다. Notepad 에 없다면 이미 제 머릿속에 잘 추상화된 페이지에 잘 정리되어 있을 것입니다.

그래서 주기적으로 Notepad 에 들어와서 필요한 데이터는 카테고리에 맞게 부모 페이지로 이동하도록 합니다.

핵심으로 찾지 않고 히트율이 낮은 데이터는 정리 필요성이 없다는 것입니다. 모든 내용에 대해서 작성하고 백업하려고 생각하지 마세요. 의미 있는 데이터로써 남아야 의미가 있는 것입니다.

TIL​

하루에 배운 내용을 정리합시다.

빠르게 기록하기 위해서 탄생한 DB입니다. 그래서 정리 는 불가능한 목표 로 하지 않습니다.

작성하는 시간은 아깝다고 생각하지 않습니다. 왜냐면 실제 제 경험에 의거한 공부 내용을 적는 것이기 때문입니다.

하지만 요즘 ChatGPT 와 같은 AI 가 요약하고 알려주는 시대인데 내용을 맞게 찾고 정리하는 시간인 아깝게 느껴집니다.

핵심은 이해할 때까지 찾고 완벽한 정리 가 아니라 힌트 느낌으로 낙서장 처럼 작성하라는 것입니다.

저는 기억이 휘발되기 이전에 빠르게 대충 작성하고 상태를 스테이징 으로 변경 → 제목과 내용을 다듬고 tag 추가하고 완료 로 변경해서 사용합니다.

내용이 많이 쌓이기 때문에 Context (상황, 이벤트) 기반으로 분리합니다.

Archive​

목적을 달성하고 죽은 데이터들이 존재합니다.

영화 , 강의 , 여행 과 같이 기간 에 맞게 작업을 수행 후 완료 된 데이터들의 모임입니다.

Diary​

일기장으로 일기를 작성합니다.

Page​

• 날짜, 시간에 국한되지 않는 데이터가 존재합니다.
  • 이렇게 해야 하는 이유는 Page 는 Wiki 의 레벨로써 날짜 와 상황 이 딱히 궁금하지 않습니다.
  • 공식 문서 를 읽을 때 이게 언제 어떤 상황에 의해서 추가되었다고 말하지는 않잖아요?
  • Wiki 에서는 그냥 스크롤로 쭉 내용이 그룹화 되어서 볼 수 있으면 좋은데 날짜 혹은 Board Item 단위로 묶여버리면 날짜 단위로 내용을 이해해야 하는데 그렇게 해서 얻는 가치가 없습니다.
  • TS 를 예로 든다면 나는 날짜 관련 함수 의 테크닉, 변수 관련 테크닉 이렇게 묶어서 보고 싶은데 11월 하위에 여러 가지 작성되어 있고, 12월 하위에 여러 가지 작성되어 있고 이러면 원하는 정보를 찾기 위해서 날짜 를 계속 열어보면서 찾아야 하는 어려움이 있습니다.
• 기초 정보 들이 들어가며 주로 목적이 없는 데이터입니다.
  • 만약, 목적이 있게 진행이 되었더라도 기본적인 지식 은 Page 으로 들어갑니다.
  • 이러한 기초 지식은 언제 진행되었는지, 날짜 정보가 크게 중요하지 않습니다.
  • 진행된 Board Item 에 대해서 백링크 는 지정하지만 내용은 Page 에 작성합니다.
  • 이것은 TIL 와 구분을 짓는 아주 중요한 요소입니다.
• 여기서 목적이 있는 데이터란?
  • 내가 A 라는 작업을 하기 위해서 찾아보고 하였다고 한다면
  • A 라는 작업의 이유 때문에 발생한 것이므로 목적이 있습니다.
  • 이러한 데이터는 A 라는 작업과 의존 관계 를 맺는 것이 더 기억이 오래 남기 때문에 Page 가 아니라 Board 같은 곳에 명시하는 것이 더 장기 기억에 유리합니다.
• 만약, 여러 개의 tag 가 겹치는 데이터이라면 높은 확률로 TIL 일 것입니다.
  • 여러 개의 tag 가 겹칠 정도로 각 tag 에 대한 이해도가 있는 것이며 여러 개를 복잡적으로 작성하기에는 TIL 가 유리하기 때문입니다.

Page 템플릿​

대부분 아래의 TOC 를 가집니다.

• 관련
  • 제텔카스텐 에 따른 해당 페이지와 관련 있는 문서를 나타냄
  • 백링크 로도 나타낼 수 있지만 Notion 은 팝오버 라 티가 안 나서 중요한 것은 상단에 따로 또 명시하는 편
• Index
  • 해당 페이지의 하위 페이지 를 모아 놓음
  • 하위 페이지 가 모두 해당 Header에 있을 필요는 없지만 특성상 페이지에 어떤 하위 페이지가 있는지 찾기가 어려워서 놓아놓는 편
  • 예를 들어 Azure 페이지가 있으면 Index Header 에는 Azure와 관련된 SasS 들의 페이지가 있는 것이고 하위에 Azure와 관련된 설명이 작성될 것
• 개요
  • 해당 페이지의 소개, 어떤 내용인지 가이드
• 내용
  • 페이지의 주제에 맞게 기록하며 자유롭게 Header 등 생길 것
  • 주로 생기는 Header 으로 단어 , Feature 가 있음
• Insight
  • TIL 와 비슷한 것으로 페이지와 관련이 있는 서브 주제에 대한 것들
  • 주로 정적인 데이터보다는 이렇게 하니까 안되더라 이렇더라 와 같이 주제에 대해서 연관되어 파생된 실험과 같은 내용이 작성됨 (목적이 있다는 것이 특징)
• Resource
  • 페이지와 관련된 첨부 파일 들이 들어감
  • 주로 Assets 이라는 Header의 이름으로 페이지 아이콘 같은 것이 들어감
  • 뭐, 소스 코드 가 들어갈 수도 있을 것입니다.
• Reference
  • 페이지와 관련된 웹 링크 및 관련 문서를
  • 참고 자료 들입니다.

예시입니다.

백링크(Backlink)​

제텔카스텐(Zettelkasten) 방식으로 정리하기 위해서 필수적 으로 사용되는 개념입니다.

아무리 체계를 잡아도 예외적인 데이터들이 들어옵니다. 이런 경우 백링크 를 통해 각각의 페이지를 연결시켜서 데이터가 길을 잃지 않도록 합니다.

• 중요한 것은 데이터 목적에 맞는 곳에 Origin Page 생성하고 백링크 로 연결하도록 한다.
  • 왜냐면 export 시 Origin Page 만 실제 파일로 export 되고 백링크 는 a link 으로 걸리기 때문에 Notion 의 page 가 하나의 디렉터리 이므로 Origin Page 가 어디에 있느냐는 중요할 수 있습니다.
  • 블로그 글 과 같은 분류가 어려운 것은 Backlog 자체에 작성해서 넘겨도 되지만 처음 보는 내용 을 Backlog 에 작성하면 export 시 Wiki 에 해당하는 곳에는 백링크 로 연결되어 있기에 텅텅 비어있는 문제가 발생합니다.
• 예시
  • 데이터 배치는 데이터 유형에 더 가까운 곳에 배치하고 다른 개념에서도 참조할 수 있도록 링크
    • 예를 들어 주말에 인프런 2022 다시 보기를 보았다면? Board 에 강의 보았다고 기록을 남기는 방법과 인프런 2022 페이지 하위에 작성하는 2가지 방법이 존재함
    • 내가 주말에 논 것이 아니라 어떤 행위를 한 것이고 그것에 대한 명확한 목표와 데이터 (언제부터 언제까지 모았는가)라는 것이 존재하므로 해당 데이터 유형은 Board 레벨의 데이터에 적합함
    • 그리고 내가 10년이 지나서 인프런 2022 강의 내용의 정리된 것을 보고 싶다면 인프런 2022 페이지를 찾을 것임 그리서 Board 에 작성된 내용을 인프콘 관련 페이지에도 맨션 하면서 데이터가 길을 읽지 않도록 디자인해야 함
  • 더 목적에 맞는 곳에 작성하고 백링크 로 연결하기
    • Azure Storage 에 대해서 찾아봤는데 하다 보니 여러 기술들이 얽히게 되었고 알게 되는 것이 많아졌다.
    • 그래서 TIL 으로 넣어서 여러 기술의 tag 를 지정하는 것이 좋다는 생각이 들면서도 어떠한 목적에 의해서 시작되었기 때문에 board 에 적는 것이 맞는다는 생각도 들었다.
    • 이런 경우 더 목적에 맞는 board 에 작성하고 (왜냐면 이걸 왜 했는지 Context가 있으니까 나중에 그것에 맞게 찾기 쉬울 것이다) 각각의 page 에 백링크 로 연결하면 될 것이다.

Apple의 미리 알림​

이름 그대로 미리 알림이 필요한 것만 배치해서 사용합니다.

무조건 날짜 가 모두 지정되어 있어야 합니다.

주로 마트 가기 , 머리 자르기 와 같은 일상적인 것들이 지정됩니다.

시나리오​

모바일로 접속하는 경우​

모바일에서는 페이지 탐색이 불편하여 이에 대해서 접근성 개선이 필요했습니다.

회의실 에 들어가는 경우 혹은 헬스장 , 여행 중 등 스마트폰 으로 접근하는 경우도 꽤 많았습니다.

특히, 회의실 에 들어가서 불편한 점이 있었는데 회의 자료 정리도 해야 되고, 회의 내용 중 내가 적어놨던 것 보려면 다른 페이지로 이동해야 되고 이런 과정이 불편하더군요.

이를 개선하기 위해서 자주 접근되는 페이지는 즐겨찾기 로 추가해서 사용하도록 했으며 내용 작성 시에도 손쉽게 클릭해서 찾아갈 수 있도록 TOC 와 블록 색상 을 고려하도록 했습니다.

오늘 공부한 내용은 어디에 작성?​

• 목적이 있나요? → Board
• 목적이 없거나 분류가 애매한가요? → TIL
• 처음 배우고 변하지 않는 내용인가요? → Page
• 1개 이상 겹치는 내용인가요? → 내용에 맞는 카테고리에 넣고 백링크 로 연결

행사에서 강의를 들은 것은 어디에 기록?​

강의 내용은 Archive 에 작성하고 강의를 언제 들었는지는 Board 에 작성해서 연결

Task와 Backlog의 큰 차이점은?​

Task 랑 Backlog 는 성격이 다릅니다.

Task 는 꼭 해야 하는 할 일 의 성격으로 거의 필수적으로 처리되어야 하는 일들입니다. 그리고 일 자체가 가볍습니다.

그에 반해 Backlog 는 내가 공부하고 싶은 것, 깊은 시간을 투자할 수 있는 것, 내가 집중해서 할 수 있는 공부 혹은 이외의 한 단위 이기 때문에 제가 기분 좋게 오늘은 뭘 할까~ 하고 고를 수 있습니다.

Task 는 이유 불문해야 하지만 Backlog 는 제가 선택할 수 있는 것이 차이점입니다.

Epic이 굳이 필요하지 않은 Backlog는?​

Board 에서는 하이어라키 를 지커야 하는데 Epic 을 만들 정도가 아닌 하나의 Backlog 가 생기면 이걸 위해서 Epic 을 만들지… Epic 에 Backlog 내용을 작성할지… 고민됩니다.

Backlog 가 하나 일지 를 나타내므로 그에 맞는 Epic 을 만들어서 하위에 Backlog 으로 넣도록 합니다.

알고 있습니다 이것이 얼마나 귀찮은 작업인지… 원래는 Project 처럼 병풍 Epic 만들어서 해결하려고 했습니다.

이렇게 하면 문제는 Epic 은 어떤 가치를 전달했는지 보는 부분인데 병풍 으로 묶어 있으니 조회가 어렵다는 생각이 들었고(Project 는 root 하나이기 때문에 굳이 병풍으로 하더라도 별문제가 없습니다) Epic 은 Backlog 에 대해서 묶어주고 tag 역할도 하기 때문에 하나의 Backlog 가 있더라도 Epic 으로 묶어주는 것이 맞는다고 생각되었습니다.

즉, Epic 에는 시간이 없는 날짜 만, Backlog 에는 웬만하면 날짜 와 시간 이 들어갈 것이며 그래야지 Epic 와 Backlog 에 대해서 데이터를 살펴보면서 이런 가치 와 행동 을 했구나 알 수 있을 것입니다.

부분집합 구조의 내용은?​

아래에 나열된 것들은 부분집합 , 마트료시카(Matrioshka) 형태의 내용들입니다.

• JS ⊆ TS
• JetBrains IDEs ⊆ IntelliJ IDEA , WebStorm , DataGrip
• Mysql ⊆ MariaDB

이런 것들의 경우 가장 내부 에 있는 페이지에 공통 되는 내용을 작성하도록 합니다.
만약, 공통 되는 페이지가 없다면 만들도록 합니다.

IntelliJ IDEA ⊆ WebStorm , IntelliJ IDEA ⊆ DataGrip 와 같이 너무 세세하게 부분집합을 구분하지 않도록합니다.
기억하기 쉽도록 상식적이고 단순한 형태로 구분하도록 합니다.

페이지 in 페이지 방법으로 작성된다면 가장 내부 페이지에 공통 되는 내용을 작성하면 되지만 평면 으로 페이지 를 깔고 싶은 경우 가장 내부에 해당하는 페이지에 기록하게 될 것입니다.

Insight​

커리큘럼 없는 공부는 목차 만들기 어렵다​

책과 같이 커리큘럼 없이 공부하는 것은 Index 를 뽑아서 정리할 수 없다.

정해진 방향 없이 내가 알아서 찾아서 공부하는 것이기 때문에 하루 공부한, 그리고 정리할 수 있는 그 단위가 하나의 토픽이다.

정리를 하면서 얻을 수 있는 장점​

참 귀찮지만 내가 그동안 무엇을, 왜?, 어떻게 해왔으며 관련 정보를 빠르게 찾을 수 있습니다.

인프콘 다시 보기 강의도 그냥 대충 적어서 놓으면 편하겠지만 언제 보았는지 날짜를 지정하면 아 내가 이 시기에는 이런 고민이 있어서 이런 것을 찾아보고 했구나 하는 넓은 Context 를 얻을 수 있으며 이는 앞으로의 자신감 및 이력서 같은 것을 작성할 때 도움을 얻을 수 있습니다.