Notion 이용한 Blog 운영

7/8/2025

사실 이걸 해보려고 생각했던게 꽤 오래되었다. 개인적으로 노션을 이용해 여러가지 메모하는 습관이 붙은 지는 오래되었는데, 막상 다른 사람들에게 공유를 한다는 데에 용기 내기가 어려웠다.

Notion Image

(2022 년도에 이미 이걸 해보고자 마음먹긴 했었는데 뭔가 알아보다 말았다. 이때는 조금 다른 구성을 생각했었다.)

뭔가 막상 또 시작하고 이런저런 내용들을 쌓아가면 누군가에겐 도움되는 내용이 있을거라 생각되긴 했지만, 또 이걸 하기 위한 시간을 투자하는 부분도 그렇고, 막상 시작하고 설정을 알아보고 계속 조정하는데 시간이 꽤 걸릴거라 생각이 드니 막상 시작하려하기 어려웠다. 다른 공부하는데에도 시간이 모자라다 생각드는 부분이 꽤 있어서 계속 부채로 남아있었는데, 최근 AI 로 빠르게 뭐든 만들 수 있다는 얘기가 나오고, Gemini CLI 나왔다고 했을 때 갑작스럽게 이걸 얼마나 빨리 만들 수 있을까 라는 의문이 들어서 CLI 설치 후 바로 시작했던 것 같다.

작업은 Next.js 를 사용하여 Vercel 에 배포하여 공짜로 운영할 생각이고, 당연히 React 로 구성, CSS 는 Tailwind 로 적용했으며, UI 구성은 shadcn/ui 이용하여 나름 구성되는 UI 들의 통일성을 주었다. 이미 어느정도 내가 다 사용하던 스펙으로 구성하면서, 주요 데이터 관리는 Notion 의 Database 를 사용하여 관리할 예정이었다. 물론 이 구성에서 Notion Database?! 싶겠지만, 속도가 다른 진짜 DB 사용에 느리더라도, 공짜로 사용할 수 있으면서, 내가 자주 사용하는 Notion 에서 모든 컨트롤이 가능하다는 점에서 이점이 있으리라 생각했다. 그리고 무엇보다 이걸 Database 처럼 제공하는데서 얼마나 성능 이슈 없이 잘 사용할만 한지 궁금한 점 이 한 몫 했던 것 같다.

작업 진행은 내가 할 수 있는 Next.js 구성(npx create-next-app) 을 진행하 고, 내가 하고자 하는 작업에 대해 Gemini CLI 에 Notion 에 어떤 구성이 필요한지 물어보고, 연관되어 app 폴더 하위에 페이지 구성을 어떻게 할지에 대해, 그리고 Notion API 를 사용하고 이를 어떻게 화면에 구성시킬지 등에 대해 물어보고, UI 구성 등에 대해 shadcn.ui 를 사용할 수 있도록 유도하였다.

결과물

결론부터 말하자면, Gemini CLI 를 이용하여 작업 시간만 따져서, 초기 배포를 위한 내 나름의 기준에 부합하는 빌드까지 순수 작업시간만 따져 24시간 조금 안되게 들어간 것 같다.

결과물에 대해 평가하자면, 만족도 측면에서 상/중/하 로 나눴을 때 나름 ‘상’ 이라고 생각되어 진다. 물론 Notion API 자체의 성능이 그리 좋은 편은 아니기 때문에, 이 부분을 보완하고자, SSR + CSR 로 구성하여 나름의 성능을 끌어올려서 그나마 많이 나아졌지만 그래도 이 보완을 하고나니 ‘개인 블로그로 운영하기’ 목적으로 보면 그래도 나쁘지 않게 운영할 수 있으리라 판단되기 때문에 만족스럽다고 판단했다.

  • 만족도: 상
  • 성능: 하 → 보정 작업하여 중
  • Notion Image

    (나름 그래도 준수하게 나온 것 같다고 생각은 하지만, 조금 더 손은 볼 예정이다)

    그럼 기대했던 편의성/접근성은 어떤가.

  • 편의성: 중
  • 접근성: 상
  • 편의성은 왜 ‘중’으로 평가했냐면, 내가 추가 하고자 하는 페이지마다, API 조회를 위해 만들어 둔 API Key 에 대해 Connection 설정을 추가해주어야 하는 번거로움이 존재했다. 하지만 이 부분에 대해 개선 작업으로 블로그 관리 Database 에 추가 하는, 블로그 등록하는 기능을 따로 만들어 연결되는 페이지는 Connection 설정을 자동 추가하도록 할 수 있는지 확인을 좀 해볼까 한다.

    접근성은 어찌되든 나의 경우, 개인적으로는 Notion 자체를 매우매우 많이 사용하기 때문에 좋다고 생각된다. 즉, 이건 개인의 영역이라 그렇다고 볼 수 있는 상당히 개인적인 평가이다.

    페이지 구성

    이미지에 있는 페이지(Global Store - Spring Boot 연결 이슈) 내용은 나름 페이지 내에 이미지 관리가 많고 여러가지 블록(Notion 에서 다루는 단위) 타입이 있어 복잡한 화면으로 가장 적합한 내용이 되리라 판단했다.

    해당 페이지는 나름 블록이 100개(페이지의 블록 조회 limit 제한)가 넘어가는 페이지이며 이미지만 11개가 된다. 구조도 나름 복잡하고 거의 대부분의 블록 타입을 다루고 있다.

    이 페이지가 성능에서 나쁘지 않으면 그래도 꽤 괜찮게 운영할 수 있으리라고 판단했다.

    결론적으로 해당 페이지의 SSR 초기 구성에 6~7초 가량(캐싱되면 3~5초)이 걸린다. 결코 좋은 수치는 아니다. 하지만 이 부분이 느려지는건 차라리 어플리케이션 내에서 문제라면 차라리 다행이지만 Notion 조회 자체에 걸리는 시간이 대부분을 차지하여(대략 5~6초 이고, 캐싱되는 부분은 2~3초) 초기에 SSR 로만 구성했을 때는 나도 답답하다 느껴질 정도였다. 때문에 이 부분에 대한 보완으로 본문에 대한 구성은 CSR 로 구성하여, 클라이언트에 조금이라도 빠르게 화면을 제공할 수 있도록 변경하였다. 그런데도 화면이 그려지는데에 지연은 걸리기 때문에 loading.tsx 를 추가하여 로딩이 출력되도록 구성하였다.

    어찌되든 Notion 을 조회하는 부분에 대해서 개선하는 작업은 쉽지 않아, 다른 부분을 보완하여 작업했지만, 개인 블로그이기 때문에 LCP 까지 ms 영역으로 떨어뜨려야 한다는 사명감으로 구성할 필요성을 못느껴 여기서 나름 만족했다.

    Notion Database

    이 Notion Database 도 리뷰하자면 확실히 일반적인 DB 등을 생각하면, 확실히 조회 성능은 이점이 없다. 누군가는 이미 별도 개인을 위한 DB 가 구축되어있다면, 그걸 쓰는게 나을 선택일 수 있다. 하지만 앞서 말했듯 내가 이걸 적용해보면서 원했던 건 간편하게 구성되어야 하는 점, 그리고 접근성이 좋아야 하는 점이 있어야 했다. 일단 편의성/접근성을 우선으로 두었고, 성능은 어느정도인지 직접 경험해보고 싶었다.

    Notion Image

    (Blog 관리를 위한 Database 구성 내용)

    관리되는 컬럼은 다음과 같이 구성하였다.

  • Title: 목록에 노출하는 페이지 타이틀
  • Slug: URL 로 처리하기 위한 영문 kebab-case
  • Published: 목록에 노출 여부
  • Category: sidebar 에 그룹핑 하기 위한 문자열
  • Tags: 검색을 위한 Metadata 구성 키워드
  • PageURL: 실제 내가 작성한 페이지의 주소
  • Date: 페이지 작성일(이 부분이 수동이라 아쉽긴하지만 빠른 조회를 위해 일단수동 등록 중)
  • 성능적인 부분은 DB 라고 하기엔 매우 처참하지만, 편의성을 우선했기 때문에 저장하여 관리할 수 있다는 측면을 생각하면 크게 실망스럽지는 않았다.

    대신 위와 같이 구성했을 때, 장점으로 가져갈 수 있는 부분으로 개인적으로 작성하여 관리하던 문서들을 변경할 필요없이 그대로 유지하면서 관리할 수 있다는 부분이다. 또 나중에 내 notion 에서 관리하던 구조가 변경되거나 하더라도 추가 작업없이 해당 데이터베이스는 그대로 두어도 된다는 점이다.

    Gemini CLI

    지금까지 전체 프로젝트를 기반으로 할 땐 Cursor 를 사용하고, 일부 프로젝트 내에 API 기반 도입에 Gemini, 대부분은 ChatGPT 를 사용하고 있었는데, Gemini CLI 는 어떤 다른 경험이 있는건지 궁금하여 사용해보았다. 이번에 사용해 봤을 때 사용자 경험은 매우 좋은 편이었다. 또 CLI 로 동작하기 때문에 Cursor 처럼 전체 프로젝트에 대한 이해를 도울 수 있어서 그런 면에서도 도움이 많이 되었다. 물론 가끔 씩 잘못 반영되는 경우나, 내가 원하던 방향이 아닌 다른 방향으로 수정이 되면 직접 수정하는게 필요하여 확실히 아직은 아예 코드나, 프레임워크에 대한 이해가 부족하면 이런 수정을 제대로 할 수 없으리라는 생각은 들었다. (아직 개발자가 아예 빠지는 코드 반영은 무리가 아닐까 하는 의견)

    실제 진행하면서 경험했던 내용을 보면, 처음 대부분의 코드 반영에 대해 Typescript 의 any 를 사용하는 코드 기준으로 반영해주었는데, 이 any 타입이 build 시에 Eslint 컨벤션에 걸려 따로 타입 선언을 해달라고 부탁했는데, 구조적으로 잘 분리되도록 반영해주었지만, 일부 타입 뎁스가 달라지게 반영되어 직접 반영하는 과정이 필요했다. 이런 부분에 대해 확인과 재반영을 부탁해도 인식을 못하여 어쩔 수가 없이 직접 수정하는 과정이 필요했다.

    그럼에도 전체적인 사용자 경험을 평가하면 좋았다고 평가할 수 밖에 없다. 무료로 사용하면서 제공되는 컨텍스트 토큰은 다 사용할 수도 없었을 만큼 넉넉하게 제공되기 때문에 많은 코드를 주고 받아도 다 사용할 수 가 없다고 느껴졌다. 그러면서 Cursor 가 반영해주는 코드보다 개인적으로 퀄리티가 좋다고 느껴졌기 때문에 앞으로 여러 프로젝트 진행에 자주 사용하리라 생각되었다.

    후기

    지금 반영된 내용은 어찌보면 정말 기본적인 내용에, 아주 조금 최소한의 디테일을 적용한 정도라서 아마 반영하고 싶었던 부분들(TODO)이나, 운영에서 나오는 추가적인 부분들까지 반영해야 완성도가 높아지리라 생각된다. 이런 부분들은 또 추가하면서 이슈된 부분이나, 좋았던 부분들은 추가적인 글로 남겨둘 예정이다.

    Unsupported block type: link_preview