노션을 홈페이지 블로그 도구로 활용하는 2가지 방법

제하 건축사 사무소 사례

얼마 전에 건축사 사무소 홈페이지를 프레이머로 만들었어요. 프레이머는 코딩 없이 홈페이지를 만드는 해외 툴이에요. 디자인 자유도와 퍼블리싱 속도에선 이만한 게 없어서, 제작 툴 자체는 고민이 별로 없었어요.

마음에 걸렸던 건 프레이머의 CMS였어요. CMS는 홈페이지에 글과 이미지를 올리고 관리하는 뒷단 페이지예요. 그런데 프레이머 CMS는 인터페이스가 전부 영어거든요. 로그인부터 편집까지 모든 화면이 영어라서, 블로그 글 하나 올리려면 필드 이름부터 하나씩 해석해야 해요. 고객사 팀장님이 이걸 직접 쓰실 수 있을까 고민이 됐어요.

이 상태 그대로 넘기면 결국 수정 요청 카톡이 계속 올 게 보였어요. 저도 피곤하고, 팀장님도 본업이 따로 있으신 분이라 피곤할 거고요.

그러다 기획 미팅 중에 팀장님이 지나가는 말이 생각났어요. 노션을 써봤다는 한마디가 생각났고 설계 방향이 그 자리에서 바꿨습니다.

사례1. 노코드 도구에서 글쓰기 도구로 활용하기

결정까지 가는 고민은 세 가지였어요.

첫째, 팀장님한테 새 도구를 가르치지 않기로 했어요. 블로그 글 하나 올리려고 새 도구를 배우는 건 직원 입장에서 너무 귀찮은 일이니까요.

둘째, 팀장님은 이미 노션을 쓰고 계셨어요. 0에서 노션을 배울 필요가 없었죠.

셋째, 프레이머의 API를 확인해봤어요. API는 서비스끼리 데이터를 주고받을 수 있게 열어둔 통로라고 생각하시면 돼요. 프레이머가 이 통로를 열어둔 덕분에, 노션 내용을 프레이머 쪽으로 옮겨 보낼 수 있겠다는 계산이 섰어요.

세 개가 맞물리면서, 처음부터 노션을 원본 CMS로 두는 구조로 설계했어요. 프레이머 CMS는 화면을 그리는 역할만 하고, 콘텐츠의 본진은 노션에 두는 방향이에요.

고객의 도구로 작업하는 게 아니라, 고객이 이미 쓰는 도구 위에 시스템을 얹는 거예요.

노션을 원본으로, 프레이머는 외부용으로!

구조는 이렇게 잡았어요.

노션에 프레이머 CMS와 똑같은 필드 구조의 데이터베이스를 만들었어요. 블로그 제목, 본문, 썸네일, 태그, 발행 여부까지 항목을 하나하나 일치시켰습니다. 그리고 프레이머 API로 노션 내용을 프레이머 CMS에 동기화하는 스크립트를 붙였어요.

팀장님 입장에선 프레이머에 로그인할 일이 한 번도 없어요. 노션에서 글을 쓰시고, 발행 토글만 켜두시면 끝이에요.

프레이머가 API를 막아뒀다면 이 방식은 처음부터 성립하지 않았을 거예요. 노션과 프레이머가 서로 말이 통한다는 게 이 구조의 전제였어요.

제하건축사사무소 | 부산 & 경남 상업·주거·공장 건축/설계

홈페이지 종료 후에 "이거 올려주세요"라는 카톡이 올 일이 없어요. "글 올렸어요" 알림만 들어오면 저는 동기화가 잘 되었는지 확인하면 되니까요. 쓰던 걸 그대로 쓰게 한 게 이 구조의 전부였어요.

사례 2. 노션을 아예 데이터베이스로 활용하기

두 번째 사례는 얼마 전에 시작한 체크프로라는 프로젝트예요.

AI한테 자연어로 설명해서 코드를 뽑아내는 방식, 요즘 말하는 바이브 코딩으로 만든 홈페이지인데, 여기는 처음부터 노션을 데이터베이스로 설계했어요. 지역별 하위 키워드가 중요해서 프로그래매틱 SEO 방식을 적용하려고 했어요.

체크프로 - 주차타워 도장·청소 전문 | 부산, 경남, 울산, 대구

첫 번째 사례가 노션에서 프레이머로 옮겨주는 방식이었다면, 이건 노션을 그대로 불러다 쓰는 방식이에요.

화면 부분은 제가 코드로 만들고, 콘텐츠 데이터는 전부 노션에 있어요. 사용자가 페이지를 열 때마다 노션 API가 데이터를 가져와서 화면을 그려요. 중간에 옮겨주는 단계가 없으니 구조가 훨씬 단순해요.

이 구조는 데이터베이스 서버를 따로 두지 않아도 되고, 관리자 페이지를 만들 필요도 없고, 권한 관리는 노션이 이미 해주니까 건너뛸 수 있었거든요.

굳이 안 만들어도 되는 건 안 만드는 것, 이게 1인 사업자한테 중요한 관점이예요.

시작하기 전에 꼭 정해두는 세 가지

두 방식 다 설계 단계에서 미리 확정해야 하는 게 있어요. 이걸 안 해두면 나중에 고생을 두세 번 하니까요.

첫째는 필드 구조예요. 데이터 항목의 이름과 속성을 먼저 정해놔야 해요. 이걸 나중에 바꾸면 동기화가 바로 깨지거나 코드를 같이 손대야 하거든요.

둘째는 이미지 처리 방식이에요. 노션에 직접 올린 이미지는 주소가 주기적으로 만료되는 이슈가 있어요. 그래서 이미지를 따로 외부 이미지 저장소에 올려둡니다. 이걸 건너뛰면 몇 달 뒤에 썸네일이 전부 죽어있는 걸 발견하게 돼요.

셋째는 발행 상태 필드예요. 노션에서 토글 하나로 공개, 비공개를 제어할 수 있어야 팀장님이 마음 편히 쓸 수 있어요.

이 세 개를 설계 단계에서 정하지 않고 시작했다면, 첫 배포 후에 고칠 게 훨씬 많았을 거예요.

이 방식이 안 맞는 경우도 있어요

물론 모든 홈페이지에 노션을 붙일 수는 없어요.

실시간 반응이 중요한 서비스엔 맞지 않아요. 노션 API가 전용 데이터베이스보다 느리거든요. 트래픽이 많은 사이트도 비슷해요. 노션이 한 번에 처리할 수 있는 요청 수에 한도가 있어서, 중간에 결과를 임시로 저장해두는 장치 없이는 금방 한도에 걸려요.

블로그 콘텐츠 발행이 중요한 조직이어야 해요. 노션을 홈페이지 데이터로 활용 추천을 드리는 경우는 콘텐츠 업데이트가 최소 주 2-3회이고, 팀원이 직접 관리해야 하는 홈페이지예요. 노션 만큼 편집과 발행이 쉬운 도구는 없기에 다른 걸 포기해도 접근성과 사용성이 중요하다면 추천해요.

노션은 만능이 아니에요. 맞는 상황에 쓸 때 가장 강하게 작동해요.

홈페이지는 제작 후가 시작!

홈페이지는 한 번 만들고 끝나는 게 아니에요. 만든 다음 운영하는 게 진짜 일이고, 그 운영은 대부분 개발자가 아니라 콘텐츠를 만드는 담당자가 해요.

고객사 팀장님이든, 저 같은 1인 사업자든, 내가 쓸 수 있는 도구로 운영되는 홈페이지가 결국 오래 갑니다.

"개발을 못해서 홈페이지 운영이 겁난다"는 말은 이제 조금 낡은 이야기가 되어가요. 고객이 이미 쓰는 도구를 그대로 쓰게 해보세요. 생각보다 먼 길을 갈 수 있어요.

노션이 편한 조직이라면, 노션 기반으로 SEO, AEO를 잡을 수 있는 홈페이지가 궁금하다면

네버슬립 | 전환되는 홈페이지, 검색되는 콘텐츠