Notion 기반 블로그 자동화 프로젝트 (1): 계획
2025년 6월 9일
이 시리즈는 Notion과 MCP를 활용해, 콘텐츠 작성부터 배포까지 자동화된 블로그를 만드는 과정을 기록한 글입니다
레포지토리 저장소: 링크
왜 이 프로젝트를 시작했을까?
이 프로젝트를 시작한 가장 큰 이유는 단순히 그냥 만들고 싶었습니다.
“이거 만들면 재밌겠다.”라는 마음이 들었고, 그 감정을 따라 시작하게 되었습니다.
물론 더 구체적인 이유들이 뒤따랐습니다. 실무에서는 사용하기 어려운 기술 스택들을 마음껏 실험해볼 수 있는 pre-prod 환경이 필요하다고 느꼈기 때문입니다. 예를 들어, 최신 버전의 Next.js를 사용해 보고 싶었고, 모노레포 구조로 애플리케이션을 구성해보는 것도 직접 경험해보고 싶었습니다. 또, 평소에는 손을 대기 어려운 프론트엔드 영역 바깥의 기술들—Docker 이미지를 활용해 애플리케이션을 배포하고, 실제로 운영하며 관리하는 과정—까지 직접 다뤄보고 싶었습니다. 이번에는 시간이나 자원을 고려하지 않고, 순전히 호기심에 따라 기술 스택을 구성해보고 싶었습니다.
또 하나의 큰 동기는 블로그 작성의 진입 장벽을 낮추고 싶다는 욕구였습니다. 그동안은
Notion에 글 작성 → mdx 변환 → 이미지 파일 첨부 → mdx에 추가 라는 번거로운 과정을 반복해야 했습니다. 이런 과정을 겪다 보니, 자연스럽게 포스팅을 미루게 되더라고요. 작성부터 배포까지의 흐름을 단순화한다면, 블로그를 훨씬 꾸준히 운영할 수 있을 것이라 판단했습니다.
그리고 무엇보다 성장하고 싶었습니다. 고민을 흘려보내지 않고 기록하고 정리하면서, 그 과정을 통해 나만의 지식으로 만들고 싶었어요. 실무에서는 늘 시간이 부족하기 때문에 ‘최선의 효율’을 우선하게 되죠. 그러다 보면 오히려 기초부터 차근차근 쌓아보고 싶은 것들을 깊게 탐구할 기회가 줄어듭니다. 예를 들어, 디자인 시스템을 구축할 일이 생기면, 자원이 부족한 환경에서는 컴포넌트를 처음부터 직접 개발하기보다 shadcn 같은 headless UI 라이브러리를 활용해 빠르게 완성도를 끌어올리는 게 더 좋은 선택이 될 수 있습니다. 실제로는 그게 가장 효율적이고 현명한 방식이기도 하니까요.
그렇다 보니 자연스럽게 input, calendar와 같은 기본 컴포넌트를 처음부터 직접 만들어보는 경험은 자꾸만 미뤄졌습니다. 이번 프로젝트에서는 그런 아쉬움을 해소하고자 했습니다. 가능하면 기초부터 직접 빌드업해보는 것을 목표로 삼았고, 작은 것부터 차근차근 쌓아가고자 합니다.
그리고 마지막으로, 꾸준히 가꿔나갈 수 있는 형태의 애플리케이션을 고민했을 때 블로그만큼 적합한 형태도 없다고 생각했습니다.
이번 프로젝트의 목표
이 프로젝트는 단순히 블로그를 만드는 것이 목적은 아니었습니다.
어떻게 만들 것인가, 그리고 왜 그렇게 만들 것인가를 스스로 정의하고 직접 실험해보는 과정에 더 가까웠습니다.
그래서 저는 이 프로젝트의 방향을 아래 네 가지 목표에 맞춰 설정했습니다.
1. 무사히, 끝까지 배포하기
이번 프로젝트는 생각보다 규모가 작지 않았습니다.
Notion API를 통한 콘텐츠 연동, 모노레포 기반의 설계, Docker를 이용한 배포까지. 단순한 사이드 프로젝트라고 하기엔 꽤 많은 구성이 필요했습니다.
그래서 가장 먼저 세운 목표는, '끝까지 완주해서 실제로 배포하는 것' 이었습니다.
2. MCP 직접 활용해보기
블로그를 만들던 중에 Anthropic에서 제안한 MCP(Model Context Protocol)에 대해 알게 되었습니다.
MCP는 LLM과 애플리케이션이 유연하게 소통할 수 있도록 도와주는 일종의 통신 규약입니다.
이에 흥미를 느꼈고, 실제로 프로젝트 안에 녹여내 보며 어떻게 응용할 수 있을지 실험해보는 것도 중요한 목표 중 하나였습니다.
3. 기술 스택 선정에서 ‘호기심’과 ‘실험’ 우선하기
실무에서는 언제나 효율성과 안정성이 최우선입니다.
하지만 이 프로젝트에서는 그 기준을 잠시 내려놓고, 호기심을 따라가 보기로 했습니다.
평소에 써보고 싶었던 기술을 직접 선택하고, 때로는 일부러 비효율적인 방법을 택해서 바닥부터 만들어보는 경험을 해보고 싶었습니다.
4. 사용하는 기술에 대해 ‘깊이 있는 이해’ 갖기
기술을 적용하는 데 그치지 않고, 왜 그렇게 동작하는지, 그리고 그 구조가 어떻게 이루어져 있는지를 스스로 설명할 수 있을 정도로 깊이 파고들어 보고자 했습니다.
단순히 ‘동작하는 코드’를 넘어서, 기술의 본질을 이해하는 것이 이번 프로젝트를 통해 얻고 싶은 중요한 수확 중 하나였습니다.
추가할 기능
처음부터 너무 많은 기능을 넣기보다는, 꼭 필요한 핵심 기능들만 골라서 시작하기로 했습니다.
기능을 먼저 정의한 이유는, 이 결정이 곧 어떤 기술 스택을 사용할지에도 큰 영향을 줄 거라고 생각했기 때문입니다.
제가 정한 최소한의 필수 기능은 다음과 같습니다:
- 최신 글을 한눈에 확인할 수 있는 포스트 리스트
- 각 글의 내용을 자세히 볼 수 있는 포스트 상세 페이지
- 나를 소개하는 소개 페이지
이 기본적인 구조를 바탕으로 천천히, 그리고 꾸준히 블로그를 만들어갈 계획입니다.
완성된 후에는 조금 더 재미있고 유용한 기능들도 차차 추가해보려고 합니다.
와이어프레임 제작
블로그를 어떻게 구성할지 머릿속엔 대충 그림이 그려졌는데, 막상 손으로 옮기려니 어디서부터 시작해야 할지 막막했습니다.
그래서 일단, 화이트보드 툴인 Excalidraw를 열고 아주 러프하게 레이아웃을 그려봤습니다. 원하는 흐름과 구조가 시각적으로 보이기 시작하니 한결 정리가 잘 되었습니다.
excalidraw로 그린 와이어프레임
하지만 이 상태로 바로 개발에 들어가기엔 뭔가 아쉬움이 남았습니다.
좀 더 정제된 형태의 디자인이 필요하다고 느끼던 찰나, MCP가 떠올랐고, 자연스럽게 디자인에 적용해보면 어떨까 싶었습니다.
그래서 시도했습니다.
사용한 툴은 cursor-talk-to-figma-mcp라는 GitHub 프로젝트입니다.
사용법은 간단합니다:
- WebSocket 서버랑 MCP 서버를 띄우고
- Figma 플러그인에서 채널 ID를 얻고
- 채널ID를 Cursor에 붙여넣고 “연동해줘”라고 말하면 됩니다.
먼저 Excalidraw로 만든 레이아웃, 참고하고 싶은 블로그 디자인, 원하는 색감과 톤앤매너 등을 최대한 구체적으로 입력했습니다.
그 결과, MCP가 만들어준 Figma 디자인은 생각보다 꽤 괜찮았고, 처음 봤을 땐 “이거 그냥 써도 되겠는데?” 싶을 정도로 마음에 들었습니다.
하지만 다음 날 다시 보니, 묘하게 손이 안 가더라고요. 정확히 뭐가 문제인지 모르겠지만, 뭔가 ‘내가 애정을 갖고 운영할 블로그’ 느낌은 아니라는 생각이 들었어요.
결국 이 디자인은 참고만 하고, 새로 다시 만들기로 결정했습니다.
MCP로 만든 피그마 디자인
비록 이 디자인을 그대로 사용하진 않았지만, MCP를 직접 활용해본 경험은 큰 의미가 있었습니다.
MCP를 통해 LLM과 도구 사이의 제약이 사라졌고, 그만큼 LLM이 할 수 있는 일의 범위가 훨씬 넓어졌다는 걸 직접 체감할 수 있었습니다.
이 경험 이후로, MCP를 활용할 수 있는 다른 도구들도 적극적으로 사용해보고 싶다는 생각이 들었습니다.
기술 스택 선정
pnpm workspace
모노레포 구조는 확장성이 뛰어나고, 대규모 애플리케이션에 적합하다는 점은 잘 알려져 있습니다. 물론 어떤 규모에서 모노레포가 효과적인지는 프로젝트의 성격이나 개발자의 판단에 따라 다르지만, 직접 경험해보지 않으면 장단점을 파악하기 어렵다고 생각했습니다.
자세한 사용 후기는 다음 포스팅에서 다루겠습니다.
TurboRepo
모노레포를 사용하면 패키지 간 의존성이 복잡하게 얽히면서 빌드 시간이 길어지고, 불필요한 작업이 반복되는 경우가 많습니다. 이 문제를 해결해주는 것이 TurboRepo 입니다. TurboRepo는 변경된 부분만 선택적으로 빌드해줌으로써 전체 빌드 시간을 단축시켜주며, 특히 CI/CD 환경에서의 작업 시간을 크게 줄여주었습니다.
Next.js
Next.js를 선택한 가장 큰 이유는 App Router와 함께 도입된 React Server Component(RSC)를 직접 경험해보고 싶었기 때문입니다. 개인적으로 RSC는 SSR을 넘어서는 진화된 방식이며, 앞으로 점점 더 업계의 표준으로 자리 잡아갈 것이라고 생각합니다.
기존 Pages Router는 페이지 단위로만 서버 렌더링을 할 수 있었던 반면, RSC는 컴포넌트 단위로 서버에서 렌더링이 가능해졌습니다. 이 변화는 애플리케이션의 유연성을 크게 향상시키는 방향이라고 생각합니다.
또한, App Router에서의 디렉터리 구조가 colocation을 자연스럽게 강제한다는 점도 장점으로 느껴졌습니다. 기능 단위로 파일이 구조화되다 보니, 유지보수성과 가독성이 높아졌습니다.
Tailwind CSS
Tailwind CSS는 utility-first 방식의 CSS 프레임워크로, 개인적으로 선호하는 스타일링 도구입니다. CSS-in-JS와 달리 정적인 방식으로 사전에 빌드되기 때문에, 런타임 비용 없이 사용자에게 빠르게 스타일을 전달할 수 있다는 점이 큰 장점입니다.
또한, 개발 중 빠르게 클래스를 조합해 스타일을 적용할 수 있어 생산성이 높았고, 반복적인 스타일링 패턴을 재사용하거나 추상화할 수 있는 점도 유용하게 느껴졌습니다.
Oracle Cloud
직접 인스턴스를 띄워 서버를 운영하려고 한 가장 큰 이유는, 서버 운영 과정에서 발생하는 장애 상황에 직접 대응하는 역량을 기르고 싶었기 때문입니다. 머릿속에 개념이 잡혀 있더라도, 실제 트러블슈팅을 경험하면서 개념을 체화할 수 있다고 생각했습니다.
실제로 운영 중 클라이언트 코드로 인해 발생한 메모리 누수 문제로 서버가 다운되는 경험을 한 적이 있습니다. 원인을 찾기까지 시간이 오래 걸렸지만, 그만큼 애플리케이션의 구조를 깊이 이해하는 계기가 되었습니다. 이런 경험의 중요성을 알기에, 서버를 직접 운영해보기로 마음먹었습니다.
처음에는 AWS EC2도 고려했지만, 1년 무료라는 제약이 있어 지속적으로 무료로 사용할 수 있는 Oracle Cloud를 선택하게 되었습니다. 추후 실제 트래픽이 붙었을 때 성능을 검토해보고, 필요하다면 다른 대안을 고민할 계획입니다.
Docker
현재 회사에서 Docker를 활용해 마이크로서비스로 전환하는 과정을 겪고 있기 때문에, 이번 사이드 프로젝트에서 직접 사용해보면 그 과정에서 도움이 될 것이라 판단했습니다. 예전에 Docker 강의를 수강한 적은 있었지만 실무에 적용해본 경험은 없었던 것도 한 몫 했습니다. Docker는 서버 자원을 유연하게 활용할 수 있게 해준다는 점에서 기존 가상머신 기반 구조와 비교했을 때 분명한 이점을 갖고 있다고 생각했고, 이번 기회에 개념을 정리해보고 싶었습니다.
Notion API
기존에 블로그를 운영하면서 가장 불편하게 느꼈던 점은 콘텐츠를 레포지토리 내부에서 MDX 형식으로 직접 관리해야 했다는 점이었습니다. 하지만, Notion API를 활용하면 이 과정을 자동화 할 수 있었습니다.
블로그를 꾸준히 운영하기 위해 개인의 의지도 중요하지만, 무엇보다 중요한 건 ‘얼마나 쉽게 시작할 수 있느냐’는 환경적인 요소라고 판단했습니다. 글쓰기의 진입장벽을 낮추면 블로깅을 더 꾸준히 이어갈 수 있을 것이라 생각했습니다.
제가 원했던 자동화의 형태는 단순했습니다. Notion에 글을 작성하기만 하면, 그것이 곧바로 웹에 서빙되는 구조를 만드는 것이 목표였습니다.
마무리
이번 포스팅에서는 전반적인 자동화 뼈대를 세웠습니다.
다음 글에서는 이를 실제 코드로 구현해 나가는 과정을 구체적으로 설명드릴게요.
읽어주셔서 감사합니다 :)