본 글은
2024.07.27에 발표한
"옵시디언과 Notion - 데이터 호딩 전략" 자료를 재구성 및 정리한 글입니다.

​서론

데이터 호딩

Digital hoarding - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

데이터를 수집하는 일종의 강박증과도 같은 개념입니다. 보통은 부정적인 맥락에서 사용되는데 저는 그냥 데이터를 모아보자 라는 맥락에서 사용한 단어로, 데이터를 수집하고 분류하고 정리하는데에 관심이 있으신 분들은 reddit의

• r/DataHoarder : 데이터의 저장, 백업 등에 대해 다룸.
• r/dataisbeautiful : 데이터 시각화, 통계 관련.

등지로 가시면 관련 정보를 다수 얻으실 수 있습니다.

왜 나는 데이터를 모으고 있는가

중학생 때 스마트폰 파손으로 그 이전까지의 사진 몇천장을 날려먹은 이후로, 어떻게 하면 데이터를 안전하게 잘 보관할 수 있을까 라는 생각을 항상 가져왔습니다.

2019년부터 파일을 백업하기 시작하여서 현재 대부분의 해당 시기 자료를 보유하고 있으며, 이를 발표자료 하단의 대학입시 보고서 자료로 활용하여 입시를 편하게 진행한 바 있습니다.

자료를 잘 정리를 해두면 추후 보고서작성이라던지 서류처리, 혹은 추억회상이라던지 다양한 목적으로 잘 활용할 수 있다는것을 몸소 체감해 보았기에, 데이터를 어떻게 하면 잘 정리할 수 있을까 에 대한 관심이 매우 높은 편입니다.

노션과 옵시디언의 공통점

노션과 옵시디언 둘 모두 markdown 이라는 방법을 통해서 데이터를 저장합니다.

마크다운 - 위키백과, 우리 모두의 백과사전

Wikimedia Foundation, Inc.위키미디어 프로젝트 기여자

지금 이 블로그 글의 발행도 markdown 규격으로 작성하고 관리되고 있는 만큼, 개발자들에게는 참으로 익숙한 규격이 아닐 수 없는데, 마크다운의 장점은 텍스트 형태의 자료를 정리하는데 좋다는 점에 있습니다.

그런데 노션이던 옵시디언이던 마크다운을 통해서 "많은" 양의 서류를 작성하고 관리하다 보면, 폴더의 깊이가 한도끝도 없이 깊어진다는 단점이 존재합니다.

내가 원하는 문서를 찾아 들어가기 위해서 폴더를 5개씩 들어가야 하는 경험은 결코 유쾌하지 않습니다.

이걸 해결하기 위해서는 보통 바로가기나 즐겨찾기 기능을 많이들 활용 하시고, 실제로 노션에서는 즐겨찾기를 제공하고 있기 때문에 자주 접근하는 문서를 쉽게 찾아 들어갈 수 있도록 하고 있습니다.

이런 폴더 기반으로 문서를 관리하다 보면 폴더 구조를 뜯어고치는 시도를 반드시 하게 되는데, 이 경우 대단한 시간을 투자해야 해서 별로 효율적이지 못합니다. 이 정리를 어떻게 효율적으로 할 수 있을지에 대해서 공유해보는 시간을 가지려고 합니다.

본론 : 비교분석하기

둘을 비교하는 근본적인 이유는 둘 모두 markdown으로 관리되어서 어디 옮기거나 하기 매우 편하다는 점에 있습니다.

아까의 폴더 구조를 뜯어 고치고, 노션에서 옵시디언으로 건너가는 것처럼, 살면서 데이터를 옮기는 것이 대단히 중요해지게 됩니다. 하나의 서비스는 영원하지 않고, 저의 서비스에 대한 선호도도 영원하지 않습니다.

하지만 markdown이라서 생기는 단점도 분명히 존재합니다. 마크다운은

텍스트를 꾸미는 확장 문법

을 위해서 만들어진 규격이기 때문에, 사진이나 음악 영상 등의 형태의 자료는 사용하지 못합니다. 이런 문서를 보관하기 위해서는 노션이나 옵시디언을 고려하는게 아니라, 클라우드 서비스나 개인 NAS등에 대한 고민을 해보셔야 합니다.

음악 관리 서버를 찾기 위한 여정과 gonic

음악을 자주 듣는 편이라서, 이것저것 긁어모은 음원파일들이 꽤나 많아졌습니다. 이 음원들을 서버에다 다 때려박아놓고 관리하고 있는데, 최종적으로는 gonic 이라는 프로그램에 정착해서 음악을 이걸로 관리하고 있습니다. plex / jellyfin 처음에는 단순하게 영상과 음원 둘다 하나에서 관리하면 더 편하지 않을까? 를 이유로 plex, jellyfin을 둘 다 사용해 보았습니다. plex는 유료 구독이라는게 맘에 안들어서

Koder / 박성훈박성훈

저는 실제로 음악과 영상을 관리할 때는 jellyfin / gonic 등을 통해 관리하고 있습니다.

제한적으로나마 markdown에서 이러한 형태의 데이터를 다루고자 시도하는 경우들이 존재합니다. 노션이 이 경우에 속하는데, markdown에 기능을 추가해서 사진이나 표 등의 복잡한 자료를 커버하는 경우를 flavored Markdown이라고 부릅니다.

GitHub Flavored Markdown Spec

Github사에서도 자체적인 규격인 gfm을 만들어서 사용하고 있으며, 노션 역시도 마크다운으로 입력이 "가능한" 확장 규격을 자체적으로 만들었으며, 실제 저장은 json규격으로 저장하여 사용하고 있습니다.

당연히 규격이 달라진 만큼 다른 프로그램이나 서비스로 옮겨갈 때에 장벽이 될 수 있다는 것이 단점입니다.

차이점

온 / 오프라인

둘의 가장 큰 차이점은 노션은 온라인 지원을 핵심 기능으로 내세우며, 옵시디언은 로컬에 저장된다는것을 핵심으로 내세우고 있다는 점에 있습니다.

privacy나 performance에 중점을 두는 경우, 내가 만든 데이터에 대한 주권을 내가 가져가고 싶으신 분은 옵시디언을 선택하는것이 유리하고

편의성이나 connectivity에 중점을 두는 경우 별 고민 안해도 알아서 해주는 노션을 사용하는 경우가 훨씬 편리할 것입니다.

정리 규모의 차이

옵시디언은 로컬 파일으로 저장되는 만큼 파일이 많고 정리하고 싶은 내용물이 많을수록 압도적으로 유리해집니다.

옵시디언의 강점은 파일이 많은 경우에 편리하게 작동할 수 있도록 설계되어 있다는 것인데, graph view도 이경우에 속합니다.

• 폴더 경로
• 태그
• 문서에 붙은 추가 속성
• 문서 안에 들어간 특정 단어

등을 인식해서 다양한 색깔을 매겨줄 수 있고, 서로 연결시킨 글들이 가깝게 배치되는 것을 통해서 2차원적인 폴더 뷰를 만들 수 있습니다.

그래프에는 정점과 간선이라는 두가지 개념이 존재합니다. 옵시디언의 graph view에서는 각각의 문서들이 정점으로, 문서와 문서가 서로 연관이 있는 경우 간선을 통해 연결되는 형태로 표현되게 됩니다.

• 정점의 수가 많을수록
• 하나의 정점에 많은 간선이 붙을수록
• 간선이 없는 정점의 갯수가 적을수록

옵시디언으로 관리하기가 적합합니다. 이 특징으로 인해 일반적으로는 단점인 경우를 커버할 수 있기도 합니다.

옵시디언은 확장문법을 거의 사용하지 않은 markdown을 사용합니다. 따라서 그냥 작성하고 복사해 붙여넣기만 해도 블로그에 글을 쓸 수 있다던지 하는 편의성을 줍니다.

하지만 이러한 특징 때문에 노션에서 자주 사용되는 2-col 에 대한 지원이 거의 없다시피 합니다. 확장 플러그인으로 이 문제를 해결하려고 시도해 보았습니다만 오른쪽과 같이 복잡한 방법을 통해 명시해주어야 하고

매우 중요한 포인트로 그냥 못생기게 나옵니다

그렇기 때문에 옵시디언에서는 단일 파일에 많은 내용을 저장하기 보다는 여러개의 작은 파일을 서로 연결짓는게 핵심이 되고, 이 개념을 극적으로 활용하는 경우가 소위 말하는 제텔카스텐입니다.

정리

• 서로 연결이 필요없는 일기 / Todo리스트 등은 노션이 적합합니다
• 남에게 공유하는 자료는 노션이 적합합니다
• 내용이 많은 개인 공부나 지식/생각 정리는 옵시디언이 적합합니다
• 블로그 초안은 markdown이라 옮겨넣기가 쉬운 옵시디언이 적합합니다

핵심은 둘 중 하나만 쓸 이유가 없다는 데에 있습니다.

상황에 맞는 프로그램을 사용해보는건 어떠실까요

데이터 호딩 전략

여기부터는 데이터를 어떤 형태로 저장하는게 좋을지,
모아둔 데이터를 어떻게 사용할 수 있을지에 대한 개인적인 제안 사항입니다.

노션 - RestAPI 활용하기

노션은 외부 공개 기능을 매우 적극적으로 가져가고 있는데, 그 중에서도 아직 널리 퍼지지 않은듯 하여서 다뤄봅니다.

노션 API 호출 및 데이터베이스 조회

방학기간을 활용해서 자기소개 홈페이지를 react로 재작성 중인데, 잡다한 수상 내역 같은 것들을 노션에다가 저장해두고 하드코딩해서 따로 자기소개 페이지에 옮기는 방법으로 관리했었다. 리액트의 컴포넌트를 좀 써먹을 겸 해서, 노션 API로 수상 내역을 호출한 다음 출력해보는 부분까지 진행할 예정이다. 기존 DB는 이렇게 유지되고 있다. 이 데이터베이스에서 값들을 가져와서 다뤄보도록 하겠다. API 발급받기

Koder / 박성훈박성훈

Notion API와 함께 정적 페이지로의 여정 – 화해 블로그 | 기술 블로그

Notion API와 함께 정적 페이지로의 여정 정적 페이지를 notion으로 관리하는 방법으로 접근하기까지의 과정을 약 3주 간 리서치한 과정을 글로 옮겼습니다. 과제 완성 후 최종 결과물을 공유하는 것도 좋지만 과정을 기록하고 소개하는 것 또한 의미 있는 일이라 생각합니다.

화해 블로그 | 기술 블로그

노션의 데이터베이스는 그냥 단순히 내 데이터를 적재해두는 것 뿐만 아니라, 그 데이터를 써먹을수도 있게 해줍니다.

평균 초당 3번의 request를 처리해주는 notion api를 사용하면, 노션의 데이터베이스에 있는 값을 뽑아서 원하는 대로 사용할 수 있게 해줍니다.

상단에 첨부한 예시를 포함하여,

• 개인정보 제공동의서와 같은 문서 관리
• 데이터베이스 값을 뽑아 처리하기
• 노션에 수기로 적던 값을 자동으로 넣어주기

등의 다양한 사용방법을 가지고 있습니다.

저의 경우에는 윗 블로그에서와 같이 자기소개 페이지를 제작할때 가끔씩 갱신해주어야 하는 학력, 대외활동 등의 값들을 노션 데이터베이스에 적재 후 홈페이지 개발에 활용하고 있습니다.

데이터가 많아지면 많아질수록 귀찮아 지는 부분이

어떤 데이터를 원본으로 관리할 것인가

인데, 숫자나 문자 같은 text값들을 관리할 때 노션을 원본으로 함으로써 이 문제를 해결할 수 있었습니다.

노션 - template 활용하기

노션의 데이터베이스는 템플릿 기능을 활용할 수 있는데, 이 기능을 사용할 경우 문서를 특정 조건에 따라 생성하는게 가능합니다.

• 매일 매일 쓰는 일기
• 매주 쓰는 스크럼 회고
• 습관 트래킹

같은 매일 반복되는 task의 경우 템플릿 기능을 활용하면 편하게 관리할 수 있습니다. 서로 연관성이 없는 이러한 유형의 문서의 경우 옵시디언의 graph view 상에서 가장 모서리쪽으로 밀려나기 때문에, 옵시디언에서 이러한 문서를 작성하는것은 그리 바람직하지 않습니다.

단 이 경우 문서가 빠르게 쌓이므로 1년정도 운용한 지금은 전체 리스트 확인 시 꽤나 렉이 걸리는 편입니다.

옵시디언 - graph 활용하기

graph view를 적극적으로 활용하시는 분들은 보통 제텔카스텐을 많이들 시도하는데, 저의 경우에는 문서를 작게작게 매번 쪼개고 연결하는 과정이 너무 귀찮아서 단일 파일에 내용을 좀 몰아서 넣고 있습니다.

제 정리 방법의 경우에는 기본적으로 project와 task를 기준으로 관리합니다

project

앞으로 진행할 프로젝트입니다. 보다 장기적인 시점에서 진행하는 task라고도 할 수 있습니다

• 블로그 만들기
• 개인 서버 구축하기
• 특정 캠프 / 활동
  • 2024 동아리활동
  • 소프트웨어 마에스트로 15기 목차 문서

등이 이 분류에 속합니다.

task

보다 작은 분류의 할일들 입니다

• 국민대학교/중앙대학교 연합 대회 문서
• 개인서버에 올리는 프로그램들 구축 방법을 정리한 문서
• 블로그에 posting할 글감들

등이 이 분류에 속합니다.

정리하기

기본적으로 이러한 task들 간의 선후 관계를 -> 그래프로 표현합니다

서버 구축 (이 되어야) -> 블로그(를 올리고) -> 글을 씁니다

이렇게 선후관계를 만들어서 관리를 해주고 있는데, 이 그래프가 DAG의 형태가 되게끔 구상해주면 알고리즘 하더놈의 시점에서 그냥 위상정렬해서 어떤거 먼저 할지 고민을 안할 수 있게 만들어줍니다.

최근에는 일이 많아 별로 도움을 받았던 적이 없습니다만, 일정이 간간히 빌때 비어있는 곳을 채우는 느낌으로 문서를 확인하고 있습니다.

옵시디언 - plugins

플러그인에 대해서는 너무 잘 정리해주시는 분들이 많아 크게 설명하지는 않겠습니다. 추후 필요하다고 판단한다면 분량이 꽤 되는 만큼 아마 별도의 글로 분리하지 싶습니다.

저는 커스텀하는것도 귀찮다 싶어서

• remotely sync (개인서버와 동기화)

플러그인 한개만 사용하고 있습니다.

결론

텍스트 데이터 뿐만 아니라, 수많은 데이터를 체계적으로 정리하시면 생각보다 활용할 수 있는 사용처가 대폭 늘어나게 됩니다.

이 블로그도 그러한 맥락에서 유효합니다. 저 자신이 자주 접하는 문제를 해결하고자 처음에 블로그를 시작했던 기억이 있습니다. 지금도 제가 정리해놓은

visual studio code 알고리즘 문제풀이 환경 구축

기존에는 dev c++ ide를 사용하고 있었는데, 이걸 굉장히 오래전부터 사용하기도 했고 이제 지원도 끊겨서 너무 오래된 프로그램이기 때문에, 계속 ide를 갈아타고자 하고 있었다. ICPC 준비 과정에서, vscode를 ide로 사용하고 있는 팀원이 있었기 때문에 vscode로 갈아타기로 결정했고, 설치 과정이 dev c++ 에 비해서 상대적으로 복잡하기 때문에 여기에 정리해두도록 하겠다. C++17

Koder / 박성훈박성훈

시놀로지 DSM6 비밀번호 보안수준 설정

NAS를 사서 비밀번호를 설정할때 영어 대문자를 입력해야하는게 별로 맘에 안들었다. 나야 비밀번호가 복잡한 다른 비밀번호지만 사용자 이름이 포함되서는 안되고 숫자를 반드시 포함해야하는등 몇가지의 까다로운 조건들이 있다고 한다. 이걸 고쳐보도록 하겠다. 이런 빨간색 필드와 함께 변경할수 없다..... 이를 수정하기 위해서는 제어판 -> 사용자로 들어간다. 상단에 있는 ”고급”을 선택하면 이렇게 패스워드의

Koder / 박성훈박성훈

같은 문서들을 참고하고는 합니다.

혹시 제 방법이 비효율적이라고 생각하시거나 더 효율적인 방법을 알고 계시다면 언제나 추천해주시면 좋을것 같습니다. 저 역시도 현재에는 본 글에서 소개한 방법으로 정리하고 있습니다만 추후 개선의 의향이 있습니다.

감사합니다.