Notion을 버릴까 WordPress로 갈까? 나는 먼저 렌더링부터 고쳤다
Notion을 버릴까 WordPress로 갈까? 나는 먼저 렌더링부터 고쳤다
사이트를 갱신할 때 가장 늦게 내려야 할 결정이 있다. 바로 “어떤 CMS로 옮길까?”다. 화면이 깨지고, 옛 URL이 엉뚱한 페이지를 보여주고, 검색 알림이 존재하지 않는 주소로 나가고 있다면 CMS를 바꿔도 같은 문제가 새 시스템으로 이동할 뿐이다.
Iloura 사이트 갱신 범위를 정리하면서 나는 Notion을 유지할지 WordPress로 옮길지 아직 닫지 않았다. 대신 한 가지는 먼저 닫았다. 콘텐츠를 어디서 관리할지와 콘텐츠가 어떻게 렌더링될지는 다른 문제라는 사실이다.
CMS를 고르기 전에 문제가 이미 다른 곳에 있었다
처음 보면 이런 상황은 “Notion이 한계에 도달했다”거나 “WordPress로 갈 때가 됐다”는 신호처럼 보인다. 하지만 작업 기록을 따라가 보니 실제 병목은 CMS 이름이 아니었다. 사이트의 URL 계약과 렌더링 경로가 서로 다른 약속을 하고 있었다.
- 존재하지 않는 경로가 404가 아니라 홈페이지 HTML로 응답했다.
- 동기화 과정의 색인 알림이 실제 페이지가 아닌
/p/<page_id>형식 주소를 가리켰다. - 옛 주소에서 새 주소로 가야 할 리다이렉트 일부가 다시 죽은 주소를 향했다.
- 사이트맵과 홈페이지에 비어 있거나 더 이상 존재하지 않는 페이지가 섞여 있었다.
이 네 가지는 Notion을 쓰든 WordPress를 쓰든 다시 생길 수 있다. CMS는 원고를 저장하는 도구이고, 방문자가 유효한 URL에서 올바른 상태 코드와 화면을 받게 하는 일은 별도의 운영 계약이다. 둘을 한 번에 묶어 판단하면 원인을 놓친다.
내가 AI 에이전트에게 맡긴 일은 ‘CMS 추천’이 아니었다
이번 작업에서 에이전트는 “Notion이 낫나, WordPress가 낫나”를 대신 결정하지 않았다. 로컬 작업 기록과 사이트 산출물을 훑어 문제를 작은 단위로 분해했다. 어떤 URL이 존재하는지, 어떤 주소가 실제 콘텐츠를 가리키는지, 동기화와 렌더링 사이에서 어느 계약이 깨졌는지를 확인했다.
| 질문 | 확인할 것 | 판단에 쓰는 이유 |
|---|---|---|
| 페이지가 존재하는가? | 실제 빌드 결과와 응답 상태 | CMS 이전 전에 404·홈페이지 폴백을 분리한다 |
| 주소가 일관적인가? | 동기화 스크립트, 리다이렉트, 사이트맵 | 콘텐츠 저장 위치와 URL 체계를 따로 평가한다 |
| 운영자가 회복할 수 있는가? | 재생성·재배포·검증 절차 | 도구의 편리함보다 장애 복구 비용을 본다 |
| 바꿔야 하는 이유가 남는가? | 편집 흐름과 배포 흐름의 실제 불편 | 문제 해결 뒤에도 CMS 이전의 필요성을 검증한다 |
AI를 이 단계에 붙이면 “최신 CMS 비교표”를 길게 만드는 대신, 내 사이트의 실패 경로를 먼저 드러낼 수 있다. 이것이 도구를 실제 워크플로에 넣었을 때 얻는 이득이다. 선택을 자동화하는 것이 아니라, 선택 전에 버려야 할 혼동을 줄이는 것.
Notion 유지와 WordPress 이전을 가르는 네 개의 게이트
CMS 선택은 취향 투표가 아니라 다음 네 게이트를 통과하는지로 결정하려고 한다.
- 작성 게이트. 실제 운영자가 가장 자주 하는 편집을 어느 쪽에서 더 적은 단계로 끝낼 수 있는가?
- 렌더링 게이트. 존재하지 않는 주소가 확실히 404가 되고, 존재하는 주소는 자기 콘텐츠와 canonical을 내놓는가?
- 배포 게이트. 동기화 실패나 잘못된 변환이 생겼을 때 원인을 추적하고 이전 버전으로 돌아갈 수 있는가?
- 측정 게이트. 사이트맵, 색인 알림, 리다이렉트, 분석 데이터가 같은 URL 체계를 보고 있는가?
Notion이 첫 번째 게이트에서 강하고 WordPress가 세 번째 게이트에서 강할 수도 있다. 반대일 수도 있다. 중요한 건 “WordPress라서 SEO에 좋다” 같은 문장을 먼저 믿지 않고, 내 사이트의 네 게이트를 실제로 측정하는 것이다.
실제로 적용하는 최소 워크플로
- 대표 URL을 고른다. 홈페이지, 정상 페이지, 옛 주소, 존재하지 않는 주소를 각각 몇 개만 샘플로 만든다.
- CMS를 건드리기 전에 응답을 기록한다. 상태 코드, 최종 URL, title, canonical, 화면 내용을 한 묶음으로 남긴다.
- 렌더링과 URL 계약을 먼저 고친다. 미존재 경로는 404, 옛 주소는 실제 새 주소로 301, 사이트맵은 실제 페이지 목록만 가리키게 만든다.
- 동기화 파이프라인을 다시 실행한다. 저장소의 페이지 파일, 생성된 URL, 색인 알림의 URL이 같은 대상을 가리키는지 확인한다.
- 그 다음에 CMS를 비교한다. 이제야 편집 경험, 배포 속도, 권한, 복구 비용처럼 CMS가 실제로 바꿀 수 있는 항목만 남는다.
이 순서의 장점은 이전을 결정하지 않아도 바로 가치가 생긴다는 데 있다. Notion을 유지해도 URL과 렌더링이 건강해지고, WordPress로 옮겨도 마이그레이션 실패를 빠르게 잡을 기준이 남는다.
결론: CMS 선택을 미루는 것도 하나의 기술적 결정이다
Iloura의 CMS 선택은 아직 열려 있다. 이것은 결정을 못 내렸다는 뜻이 아니다. 지금 단계에서 더 중요한 결정, 즉 렌더링·URL·동기화의 경계를 먼저 복구한다는 결정을 내렸다는 뜻이다.
AI 에이전트를 도입할 때도 같은 원칙이 통한다. 에이전트에게 도구 추천을 시키기 전에, 현재 워크플로의 입력·변환·출력·검증 지점을 보여줘야 한다. 그래야 “무엇을 도입할까?”가 “어느 실패를 줄일까?”라는 실행 가능한 질문으로 바뀐다.
근거 출처
상호작용(에이전트-드루 대화·작업)
Iloura 사이트 갱신 범위를 정리한 에이전트-드루 대화와 로컬 작업 산출물을 바탕으로 작성했다. Notion 유지와 WordPress 이전이 모두 열려 있는 상태, 존재하지 않는 경로의 잘못된 렌더링, 동기화·리다이렉트·사이트맵 점검 항목은 해당 작업에서 확인한 사례다. 이 글의 “내가”는 그 작업을 수행한 경험을 가리킨다.
외부 정보(하베스터 수집)
이번 글에서는 외부 기사·트렌드·통계 자료를 사용하지 않았다. 웹/브라우저 자료가 제공되지 않은 상태에서 CMS의 최신 기능, 가격, 성능을 비교하는 주장은 넣지 않았다. 따라서 이 글은 일반론적 CMS 추천이 아니라, 한 사이트의 실제 갱신 작업에서 얻은 워크플로 제안이다.
다음 행동: 당신의 사이트에서도 홈페이지·정상 페이지·옛 URL·존재하지 않는 URL 네 개를 먼저 확인해 보자. 결과를 기록한 뒤에야 Notion을 유지할지 WordPress로 옮길지 결정하면, CMS 선택이 취향이 아니라 검증 가능한 작업이 된다.