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

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

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

막상 만들고 나니 글이 생각만큼 쌓이지 않았다. 공부 자체보다 정리가 늘 문제였다. 배운 걸 제대로 남기려면 다이어그램도 그려야 하는데, 꼭 여기서 지쳐 포기하는 게 다반사였다...

글 작성엔 주로 AI agent를 쓰고 있었는데, Notion과는 이 흐름이 영 매끄럽지 않았다. Claude나 ChatGPT한테 검수를 받아 마크다운으로 다듬는데, 올릴 땐 그걸 다시 Notion 문법에 맞게 변환해서 넣어야 했다. 써둔 글을 다시 불러와 질의하고 싶어도 Notion MCP 설정 같은 별도 프로세스를 얹어야 돌아갔다(외우고 있을 리 없는 Notion API Key와 Database ID를 매번 찾아보는 건 덤...).

개발하는 입장에서도 답답하긴 마찬가지였다. Notion API(@notionhq/client)와 react-notion-x에 단단히 묶인 구조 탓에 커스터마이징이 어려웠다. 초기 개발 이후 Notion API가 바뀌는 바람에 @notionhq/client 패키지를 업그레이드하느라 로직을 전반적으로 뜯어고친 적도 있었고, 렌더링을 react-notion-x가 통째로 책임지다 보니 디자인을 조금 손보려 해도 CSS 하나 고치는 게 쉽지 않았다... 내가 짠 마크업이 아니라 라이브러리가 뱉어내는 DOM에 스타일을 억지로 끼워 맞춰야 했으니까. 데이터를 꺼내 빌드에서 사용하는 과정도 Notion API가 워낙 불친절해 손이 많이 갔고, 이미지마저 private으로 두면 URL이 만료돼서 글들을 죄다 public으로 열어둬야 했다.

이렇게 Notion을 쓰다 보니 오히려, 처음 생각과 다르게 작성도 어렵고 개발도 어려운 상황이 되어버렸다.

심지어 이만큼 Notion에 종속된 구조에서는, Notion이 요금 정책이라도 바꾸는 날엔 그대로 치명타였다.

사실 처음 블로그를 만들 때 마크다운이라는 선택지도 있었다. 그땐 integration도 부족하고 쓰기도 불편할 것 같아 접었는데, 최근에 다시 보니 그 걱정이 거의 사라졌다. 게다가 개발이며 경제며 이런저런 주제를 공부하다 보니, 흩어진 지식베이스를 한곳에 모아 통합하고 분석하고 싶다는 욕심까지 생겼다. 이참에 늘 지치던 정리 과정은 AI agent에 맡기고 싶었다. AI로 쓰면 동일한 서식과 톤앤매너가 보장될 테니, 나는 내용이 맞는지만 검수하면 된다.

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

Bye Notion, Welcome LLM Wiki!

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

LLM wiki가 뭐죠?

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

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

이렇게 글 작성·수정, 심지어 가장 골치 아팠던 유지보수(오래된 정보 갱신)까지 사람 개입을 최소화한 채 LLM agent에 맡길 수 있다는 건 무시할 수 없을 만큼 매력적이었다.

다만 LLM agent가 읽기 좋은 글이면 뭐하나, 결국 사람이 읽기 쉬워야 했다. 마크다운에서도 다이어그램이나 수식은 Mermaid·KaTeX로 충분히 표현하고 렌더링할 수 있었다. Notion만큼 integration이 많진 않아도, 내가 다루는 글 특성상 이 정도만 지원되면 크게 문제되지 않았다.

더 미룰 이유가 없었다. 블로그와 지식베이스를 한꺼번에 LLM Wiki로 옮기기로 했다.

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

카파시가 제안한 LLM wiki의 큰 틀은 따르되, 내 상황과 목적에 맞게 살을 붙여 구조는 내 식대로 잡았다.

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

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

골격을 세웠으니 그 위에 실제 지식을 채웠다. 기존 Notion에 작성해둔 글은 Notion MCP를 사용해 이관했고, 각 글이 참고한 자료는 sources/에 출처로 붙였다. 그러자 글마다 "이건 어디서 나온 얘기"인지 출처가 저절로 따라붙기 시작했다.

옵시디언 그래프뷰로 본 지식베이스. 회색 점은 source·wiki 노트, 초록 점은 태그, 노란 점은 이미지 같은 첨부파일이다. 같은 주제의 노트끼리 클러스터로 뭉치고, 위키링크와 태그가 클러스터 사이를 잇는다.

"Obsidian은 IDE, LLM은 프로그래머, wiki는 코드베이스"라는 말처럼, 진짜로 Obsidian을 열어보니 글들이 어떻게 엮여 있는지 그래프 뷰로 한눈에 들어와 괜히 뿌듯했다.

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

지식베이스가 준비됐으니, 이제 블로그가 그걸 읽도록 바꿀 차례였다. 기존 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에서도 안전하도록 클라이언트 컴포넌트로 처리했다. 본문의 위키링크는 발행된 글이면 /blog/<slug>로, 미발행 source면 source_url로 이어지게 했다.

Before — Notion API에서 빌드

After — 로컬 Markdown에서 빌드

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

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

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

뭐가 좋아졌나

우선 글을 쓰고 올리는 게 확실히 편해졌다. 서식과 톤앤매너를 SKILL로 등록해둔 덕에 포맷이 들쭉날쭉하지 않고 한결같이 유지된다(사람보다 낫지 않을까 싶다). 무엇보다 Claude나 Codex로 환경에 구애받지 않고 지식베이스에 지식을 등록하고 질의할 수 있게 된 점이 가장 컸다. 새 정보를 넣을 때 SKILL과 lint 룰을 기반으로 서식을 자동 검증하고, 모순된 정보가 없는지까지 검토해주는 것도 너무 좋았다. 마지막으로 Notion에 묶여 있던 의존도 사라져, 정책이 바뀌네 마네 마음 졸일 일도 없어졌다.

지금 등록해두고 쓰는 skill들은 대략 이렇다.

게다가 Markdown 기반 구조라 다국어(i18n) 확장도 할 만해졌다. 사실 이건 LLM이 있어서 가능해진 일이다.

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

여러 분야를 한 저장소에 몰아넣은 것도 은근히 좋았다. RaBitQ 같은 벡터 양자화 논문을 읽다 보면 Johnson-Lindenstrauss 변환 같은 수학 개념이 튀어나오는데, 예전엔 그때그때 찾아보고 잊어버리는 식이었다. 지금은 수학이든 물리든 일단 노트로 남겨두고 위키링크로 이어두면 된다. 분야가 달라도 지식이 서로 엮인다.

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

남은 생각

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

아직 손대지 못한 것도 있다.

• RAG 인프라: 지금은 자료가 많지 않아 LLM 검색으로 충분하지만, 양이 방대해지면 별도 인프라가 필요해질 수 있다.
• 자료 축적: 이제 막 골격을 세운 단계라, 지식베이스가 진짜 힘을 내려면 꾸준히 채워 나가야 한다.

그래도 이제는 자료가 쌓일수록 wiki가 견고해지는 방향으로 움직이게 됐다.

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

참고문헌

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