나만의 블로그를 만들어보자

"에디터도 좋고 integration도 풍부하니 Notion을 CMS로 쓰는 블로그를 만들어보자." 딱 그 생각 하나로 Notion CMS 기반 블로그를 만들었다. 그 과정이 꽤 뿌듯해서 첫 글로 남길 만큼 열심히 했었다.

이제부터 블로그 글 작성 뿐이야! ...라고 생각했다 (현실은 아니지만)

그런데 LLM agent를 매일같이 쓰게 되면서, 애지중지 만들어 놓은 블로그에 대한 마음이 점점 식어갔다. 글 하나 고치고 올리는 것부터 번거로웠다. 이미 써둔 글을 다시 불러와 LLM 검색에 RAG로 붙이고 싶어도, Notion MCP에 별도 프로세스까지 얹어야 했다. 정작 Notion을 고른 이유였던 "잘 쓰고 잘 찾는" 게 안 되니, 그렇게 공들여 만들어 놓고 결국 방치해버렸다 ㅜㅜ...

결정적인 건 글쓰기 습관이 바뀐 거였다. 요즘은 회사 일이든 개인 글이든 Claude나 ChatGPT한테 한 번 검수를 받곤 하는데, 정작 처음에 Notion을 고르게 만든 그 풍부한 integration이 이제는 발목을 잡았다. 마크다운이 아니라 노션 문법이라 LLM에 그대로 넣기가 매끄럽지 않았다. 게다가 글을 한 번 고치고 나면 그걸 다시 노션 문법에 맞게 변환해서 넣어야 했으니, 매번 손이 두 번 갔다.

개발하는 입장에서도 답답하긴 마찬가지였다. Notion API와 react-notion-x에 단단히 묶인 구조 탓에 커스터마이징이 어려웠다. 렌더링을 react-notion-x가 통째로 책임지다 보니, 디자인을 조금 손보려 해도 CSS 하나 고치는 게 여간 번거로운 게 아니었다... 내가 짠 마크업이 아니라 라이브러리가 뱉어내는 DOM에 스타일을 억지로 끼워 맞춰야 했으니까. 데이터를 꺼내 빌드에 태우는 과정도 Notion API가 워낙 불친절해 손이 많이 갔고, 이미지마저 private으로 두면 URL이 만료돼서 글들을 죄다 public으로 열어둬야 했다. 그러다 보니 내 글인데도 "남의 포맷에 얹혀 사는" 기분이 들었다.

이러다 노션이 갑자기 요금제나 정책을 바꾸면 어쩌지...?

이렇게 노션에 묶여 있으니 정작 내 글을 정리하고 관리하기가 점점 더 버거워졌다. 사실 처음 고민할 때 마크다운이라는 선택지도 있었다. 그땐 integration도 부족하고 쓰기도 불편할 것 같아 접었는데, LLM이 좋아지면서 그 걱정이 거의 사라졌다. 게다가 개발이며 경제며 이런저런 주제를 공부하다 보니, 흩어진 지식베이스를 한곳에 모아 통합하고 분석하고 싶다는 욕심까지 생겼다.

그렇게 마음이 기울었고, 결국 지식베이스(Notion)와 블로그를 통째로 갈아엎기로 했다.

Bye Notion, Welcome LLM Wiki!

갈아엎기로 마음먹고 나서, 새 지식베이스가 꼭 갖춰야 할 조건부터 적어봤다.

LLM wiki가 뭐죠?

LLM wiki는 안드레이 카파시가 주창한 개념으로, 예전에 회사에서도 한 번 공유됐던 내용이었다. 솔직히 그땐 흘려들었다. 그런데 막상 "LLM agent에 최적화된, 스스로 자라는 지식베이스"가 필요해지고 보니, 다시 꺼내 볼 수밖에 없는 얘기였다.

그래서 스치듯 봤던 Karpathy의 LLM Wiki를 제대로 다시 읽어봤는데, 지금 내 고민에 신기할 만큼 딱 맞았다. 핵심은 원자료(raw)와 컴파일된 지식(wiki)을 분리하고, wiki는 반드시 raw를 근거로만 쓴다는 규칙이다. 덕분에 모든 결론에 출처가 남고, 새 자료가 들어오면 기존 글이 낡는 게 아니라 오히려 더 단단해진다.

게다가 그사이 환경도 받쳐줬다. GitHub 마크다운이 Mermaid 같은 것도 알아서 렌더해주고, LLM의 마크다운 실력도 부쩍 늘어서, 예전에 Notion으로 풀어보려 했던 에디터·integration 고민이 대부분 무색해져 있었다. 더 미룰 이유가 없었다. 블로그와 지식베이스를 한꺼번에 LLM Wiki로 옮기기로 마음먹었다.

LLM wiki로 나만의 지식베이스 만들기

카파시의 LLM wiki는 어디까지나 큰 틀이라, 내 상황과 목적에 맞게 살을 붙이는 게 관건이었다. 출발점은 같되, 구조는 내 식대로 잡았다.

먼저 큰 골격부터. 주로 개발을 공부하지만 요즘 경제 공부도 틈틈이 하고 있어서, 둘을 한 지붕 아래 담을 수 있게 경제·개발·일상 같은 대주제 밑에 sources/(원자료)와 wiki/(정리본)를 두는 식으로 나눴다. 시세처럼 시간이 지나면 바뀌는 자료는 섞이지 않게 reports/에 기준일과 함께 스냅샷으로 따로 남기기로 했다.

KNOWLEDGE_BASE/
├─ 경제/ · 개발/ · 일상/      # 대주제
│  └─ <세부주제>/            # 예: 개발/데이터베이스
│     ├─ sources/           # 원자료 (불변·출처)
│     ├─ wiki/              # 근거 기반 정리본 (kr/en/ja)
│     └─ reports/           # 시점 스냅샷 (시세 등, 해당 주제만)
├─ index.md                 # 발행 카탈로그
└─ README.md

골격을 세웠으니 그 위에 실제 지식을 채웠다. 공부하던 경제 자료를 넣고, 기존 Notion 글도 전부 마크다운으로 옮기면서 각 글이 참고한 자료를 sources/에 출처로 붙였다. 그러자 글마다 "이건 어디서 나온 얘기"인지가 알아서 이어지기 시작했다.

옵시디언 그래프뷰로 본 지식베이스 — 가운데 허브를 중심으로 source·wiki 노트가 거미줄처럼 이어진다.

순수 마크다운이라 Obsidian 같은 도구로 이렇게 그래프까지 들여다볼 수 있는 건 생각지 못한 덤이었다. 영상 요약 하나가 여러 wiki 문서로 뻗어나가는 모양이 한눈에 들어온다.

블로그도 통째로 다시 만들었다

지식베이스가 준비됐으니, 이제 블로그가 그걸 읽도록 바꿀 차례였다. 기존 r3gardless.dev는 빌드 때 Notion DB에서 메타데이터를 가져오고 본문은 react-notion-x로 렌더링하는 구조라, 데이터 소스와 렌더러가 Notion에 단단히 묶여 있었다. 이 의존을 걷어내는 게 일의 핵심이었다.

가장 먼저 Notion API 의존을 빌드 파이프라인에서 통째로 들어냈다. 대신 지식저장소인 KNOWLEDGE_BASE를 가져와 publish: true인 글과 필요한 asset만 content/posts/로 골라 복사하고, 블로그는 그 결과물만 읽게 했다. 비공개 노트나 raw source는 애초에 산출물에 끼지 못하도록 말이다.

렌더러는 react-notion-x를 버리고 remark/rehype 파이프라인으로 새로 짰다. GFM 표·체크리스트·취소선·각주는 물론, 코드블록·KaTeX·Mermaid·GitHub alert까지 지원하게 했고, Mermaid는 정적 export에서도 안전하도록 클라이언트 컴포넌트로 처리했다.

Before — Notion API에서 빌드

After — 로컬 Markdown에서 빌드

의외로 가장 신경 쓴 건 링크였다. 본문에 쓴 위키링크를, 발행된 글이면 /blog/<slug>로, 미발행 source라도 source_url이 있으면 원본 URL로 바꾸고, 둘 다 아니면 그냥 텍스트로 떨어뜨리도록 했다. 참고문헌도 같은 URL이 중복 카드로 뜨지 않게 정리했다.

마지막은 망가진 외관을 되살리는 일이었다. Notion 렌더러를 들어내자 타이포·여백·인용·코드 스타일이 우수수 깨져서, markdown.css를 새로 쓰며 Pretendard 본문과 기존 톤, 라이트·다크 모드까지 다시 맞췄다. 카테고리·태그를 누르면 검색 필터로 넘어가던 동작도 되살렸다.

여기에 예전보다 훨씬 탄탄한 CI도 새로 깔았다. 타입체크·린트·테스트부터 콘텐츠 빌드·Next 빌드, 그리고 실제 out/ HTML에 필요한 마커가 박혔는지 보는 smoke 테스트까지 한 번에 검증하고, PR마다 자동으로 돌게 했다. 큰 마이그레이션은 별도 브랜치에서 진행하고, 자잘한 후속 작업도 main 기준으로 쪼개 각자 CI를 통과시킨 뒤 합쳤다.

이렇게 지식베이스와 블로그가 한 줄기로 이어졌다. 글 한 편이 쓰이고 발행되기까지, 내가 짠 전체 흐름을 한 장으로 정리하면 이렇다.

뭐가 좋아졌나

우선 글을 쓰고 올리는 게 확실히 편해졌고, 포맷도 들쭉날쭉하지 않고 한결같이 유지된다. 무엇보다 Claude나 Codex에게 "이 주제 지식베이스에 뭐 있어?"라고 바로 물어볼 수 있게 된 게 가장 컸다. Notion에 묶여 있던 의존도 사라져, 정책이 바뀌네 마네 마음 졸일 일도 없어졌다.

게다가 Markdown 기반 구조는 다국어(i18n) 확장에서 진가를 발휘했다. 사실 이건 LLM이 있어서 가능해진 일이다.

예전 Notion 구조로 다국어를 하려 했다면 어땠을까. 언어별로 페이지를 따로 파고, 블록을 하나하나 복사·번역한 뒤, 원문이 바뀔 때마다 어디가 달라졌는지 눈으로 대조하며 세 페이지를 손으로 맞춰야 했을 것이다. 생각만 해도 아찔하다.

반면 지금은 한국어 원문 하나만 고치면, LLM agent가 코드·표·위키링크 같은 구조는 그대로 둔 채 영어·일본어 문서를 알아서 다시 생성한다. Git diff로 바뀐 부분만 집어 재번역하니 동기화도 정확하다. 지금 이 글도 그렇게 한국어 원문을 기준으로 영어·일본어 번역본을 함께 관리하고 있다.

결국 Notion과 LLM Wiki가 어떻게 갈리는지 한눈에 정리하면 이렇다.

남은 생각

고생해서 붙여둔 Notion 연동을 제 손으로 다시 떼어내는 건 솔직히 쉬운 결정이 아니었다. 그래도 LLM agent를 이렇게까지 끼고 사는 시대라면, 언젠가 한 번은 거쳐야 할 일이었다고 생각한다.

아직 자료가 많지 않아 LLM 검색의 한계를 크게 느끼진 않는다. 다만 양이 방대해지면 RAG 같은 별도 인프라가 필요해질 수 있다는 건 늘 염두에 두고 있다. 그래도 분명한 건 하나다. 이제는 자료가 쌓일수록 더 어지러워지는 게 아니라, 쌓일수록 wiki가 더 단단해지는 방향으로 움직이게 됐다는 것.

이제 진짜 블로그 개발 해치웠나...?

참고문헌

• Karpathy — LLM wiki (gist)gist.github.com
• Notion CMS 블로그 직접 만들기 — 기획부터 배포까지 4개월의 기록r3gardless.dev