Let's Build a Blog of My Own

"The editor is great and the integrations are plentiful — let's build a blog with Notion as the CMS." That single thought was all it took for me to build a Notion-CMS-based blog. I was proud enough of the process to write it up as my first post — that's how much I poured into it.

All that's left now is writing blog posts! ...or so I thought (reality had other plans)

But as LLM agents became part of my daily routine, my feelings for the blog I had so lovingly built slowly cooled. Even editing and publishing a single post was a hassle. When I wanted to pull up posts I'd already written and hook them into LLM search as RAG, I had to bolt a separate process on top of the Notion MCP. The very reason I picked Notion — "write well, find well" — no longer held up, so after all that careful work, I ended up abandoning it...

The decisive blow was a change in my writing habits. These days, whether it's work documents or personal writing, I tend to run everything by Claude or ChatGPT for a review — and the rich integrations that made me choose Notion in the first place were now holding me back. Everything was in Notion's syntax rather than markdown, so feeding it straight into an LLM was always awkward. And once I'd edited a post, I had to convert it back into Notion's syntax to put it in — which was no small hassle.

From a developer's perspective it was just as frustrating. The structure was tightly coupled to the Notion API and react-notion-x, which made customization difficult. With react-notion-x owning the entire rendering, even a small design tweak meant fixing a single line of CSS was a real ordeal... I had to force styles onto the DOM the library spat out, not markup I had written myself. Pulling data out and feeding it into the build was labor-intensive too, since the Notion API is anything but friendly, and because image URLs expired on private pages, I had to leave every post public. Over time, even though the posts were mine, it felt like I was "living as a tenant in someone else's format."

What if Notion suddenly changes its pricing or policies...?

Being chained to Notion like this made organizing and managing my own writing more and more of a burden. Actually, back when I first weighed my options, markdown was on the table too. At the time it seemed to lack integrations and be inconvenient to write in, so I passed — but as LLMs got better, those worries mostly evaporated. On top of that, as I studied everything from development to economics, I started wanting to gather my scattered knowledge bases into one place to integrate and analyze them.

That's how the scales tipped, and in the end I decided to tear down the knowledge base (Notion) and the blog entirely.

Bye Notion, Welcome LLM Wiki!

Once I had committed to the rebuild, I started by writing down the conditions the new knowledge base absolutely had to meet.

So What Is an LLM Wiki..?

The LLM wiki is a concept championed by Andrej Karpathy, and it had actually been shared at my company once before. Honestly, I let it slide past me back then. But once I actually needed "a self-growing knowledge base optimized for LLM agents," it was a story I had no choice but to dig back up.

So I went back and properly reread Karpathy's LLM Wiki, which I had only skimmed before — and it fit my current problem almost uncannily well. The core is the rule of separating raw material (raw) from compiled knowledge (wiki), where the wiki must be written strictly from the raw sources. Thanks to this, every conclusion carries its provenance, and when new material comes in, existing articles don't go stale — they actually get sturdier.

On top of that, the environment had caught up in the meantime. GitHub markdown now renders things like Mermaid on its own, and LLMs' markdown skills have improved dramatically, so most of the editor and integration concerns I once tried to solve with Notion had become moot. There was no reason to put it off any longer. I made up my mind to move the blog and the knowledge base to an LLM Wiki in one go.

Building My Own Knowledge Base with an LLM Wiki

Karpathy's LLM wiki is only a broad framework, so the key was fleshing it out to fit my situation and goals. Same starting point, but I shaped the structure my own way.

First, the big skeleton. I mostly study development, but lately I've been dipping into economics too, so to house both under one roof I organized things with top-level topics like 경제 (economy), 개발 (development), and 일상 (daily life), each holding sources/ (raw material) and wiki/ (compiled notes). Material that changes over time, like market prices, gets snapshotted separately in reports/ with a reference date so it never gets mixed in.

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

With the skeleton in place, I filled it with actual knowledge. I brought in the economics material I'd been studying, and migrated every existing Notion post to markdown, attaching the material each post referenced to sources/ as provenance. And then, post by post, "where did this claim come from" started connecting itself.

The knowledge base seen through Obsidian's graph view — source and wiki notes spread out like a spiderweb around a central hub.

Since it's pure markdown, being able to peer into the graph like this with tools like Obsidian was an unexpected bonus. You can see at a glance how a single video summary branches out into multiple wiki documents.

I Rebuilt the Blog From Scratch Too

With the knowledge base ready, it was time to make the blog read from it. The old r3gardless.dev fetched metadata from a Notion DB at build time and rendered the body with react-notion-x, so both the data source and the renderer were firmly tied to Notion. Removing that dependency was the heart of the work.

The very first step was ripping the Notion API dependency out of the build pipeline entirely. Instead, the blog now pulls in the knowledge repository KNOWLEDGE_BASE, selectively copies only publish: true posts and the assets they need into content/posts/, and reads nothing but that output. Private notes and raw sources never make it into the artifacts in the first place.

For the renderer, I dropped react-notion-x and rebuilt it as a remark/rehype pipeline. It now supports GFM tables, checklists, strikethrough, and footnotes, plus code blocks, KaTeX, Mermaid, and GitHub alerts — with Mermaid handled as a client component so it stays safe even in static export.

Before — built from the Notion API

After — built from local Markdown

Surprisingly, what I fussed over most was links. Wikilinks in the body now resolve to /blog/<slug> if the target is a published post, fall back to the original URL if an unpublished source has a source_url, and simply degrade to plain text if neither applies. I also cleaned up the references so the same URL doesn't show up as duplicate cards.

The last job was reviving the wrecked appearance. Pulling out the Notion renderer shattered the typography, spacing, quote, and code styles all at once, so I wrote a fresh markdown.css and re-tuned the Pretendard body text, the existing tone, and light and dark modes. I also restored the behavior where clicking a category or tag jumps to a search filter.

On top of all this, I laid down a much sturdier CI than before. It verifies everything in one pass — typecheck, lint, tests, then the content build, the Next build, and even a smoke test that checks the actual out/ HTML for the required markers — and it runs automatically on every PR. The big migration happened on a separate branch, and the small follow-up tasks were split up against main, each passing CI before being merged.

That's how the knowledge base and the blog became a single pipeline. From a post being written to being published, here's the whole flow I built, in one picture.

What Got Better

For starters, writing and publishing posts is noticeably easier, and the formatting stays consistent instead of drifting all over the place. Above all, the biggest win is being able to just ask Claude or Codex, "what's in the knowledge base on this topic?" The Notion dependency is gone too, so there's no more holding my breath over whether some policy will change.

On top of that, the markdown-based structure really proved its worth when it came to multilingual (i18n) expansion. Honestly, this is something LLMs made possible.

What if I'd tried to go multilingual with the old Notion setup? I would have had to spin up a separate page per language, copy and translate each block one by one, and then, every time the original changed, eyeball the diffs and hand-sync all three pages. Just thinking about it makes me dizzy.

Now, by contrast, I only edit the single Korean original, and an LLM agent regenerates the English and Japanese documents on its own, leaving structure like code, tables, and wikilinks untouched. Git diffs let me pick out exactly what changed and re-translate just that, so the sync stays accurate. This very post is managed that way — the English and Japanese translations kept in step with the Korean original.

To sum up at a glance how Notion and the LLM Wiki diverge:

Remaining Thoughts

Ripping out the Notion integration I had worked so hard to wire up, with my own hands, was honestly not an easy decision. But in an era where I lean on LLM agents this much, I think it was something I would have had to go through eventually.

I don't have much material yet, so I haven't really hit the limits of LLM search. That said, I always keep in mind that once the volume grows huge, separate infrastructure like RAG may become necessary. Still, one thing is clear. Things now move in a direction where the more material piles up, the sturdier the wiki gets — not the messier.

Have I really finished the blog development this time...?

References

• Karpathy — LLM wiki (gist)gist.github.com
• Building My Own Notion CMS Blog — A 4-Month Journey from Planning to Deploymentr3gardless.dev