바이브 코딩으로 만든 기업 블로그, 테크니컬 SEO 16개 항목은 누가 해주나요?

최근 커피챗에서 한 창업자분이 물었어요.

"프레이머에 있는 네이티브 CMS로 블로그 하려고 하는데, 분석적인 측면에서 차이가 많나요?"

같은 주에 다른 분은 이렇게 물었어요.

"요즘 클로드 코드로 블로그 30분이면 만들던데, 인블로그 같은 거 왜 돈 주고 쓰세요?"

두 질문은 표현이 다르지만 뿌리가 같습니다.

블로그 만드는 데 전문 도구가 꼭 필요한가?

3년 넘게 인블로그로 블로그를 운영하면서, 이 질문에 대한 답이 점점 명확해졌습니다.

클로드 코드로 만든 블로그, 처음 20개까지는 괜찮다

클로드 코드로 블로그 만들 수 있냐고 물으면? 당연히 가능합니다. Vercel에 Next.js 올리고, 마크다운 렌더링하고, 디자인 입히면 블로그처럼 보여요. 프레이머의 네이티브 CMS를 쓰는 것도 마찬가지예요. 글 올라가고, 예쁘고, 구글에 인덱싱도 됩니다.

처음 10개 글까지는 차이를 못 느껴요. 솔직히 20개까지도 괜찮을 수 있어요. "이거면 충분한데?"라는 생각이 드는 게 정상이에요. 그 시점에서는 진짜 충분하니까요.

서브디렉토리 vs 서브도메인: 16개 항목보다 먼저 결정해야 할 것

테크니컬 SEO 16개 항목을 나열하기 전에, 먼저 결정해야 할 게 하나 있어요.

블로그가 홈페이지의 서브디렉토리에 붙느냐, 별도 도메인이나 서브도메인으로 분리되느냐.

aientry.io/blog처럼 메인 도메인의 하위 경로에 블로그가 위치하면, 블로그 콘텐츠가 쌓을수록 도메인 권위(Domain Authority)가 메인 홈페이지에 함께 쌓입니다. 백링크가 걸리든, 검색 트래픽이 들어오든, 그 SEO 자산이 전부 하나의 도메인에 귀속돼요.

딸깍으로 블로그를 만들면 보통 blog.company.com(서브도메인)이나 아예 별도 도메인에 배포하게 됩니다. 서브도메인은 구글이 별도 사이트로 취급할 수 있어요. 블로그에 아무리 좋은 글을 쌓아도, 그 SEO 자산이 메인 홈페이지로 흘러가지 않는 거예요.

이건 나중에 "고치면 되는" 문제가 아니라, 처음부터 아키텍처를 잘못 잡으면 쌓인 자산이 엉뚱한 곳에 가 있는 문제입니다.

인블로그는 서브디렉토리(company.com/blog) 연결을 기본으로 지원해요. 이 세팅 하나가, 아래 이야기할 16개 항목 전체의 효과를 몇 배로 키워주는 전제 조건입니다.

블로그에 필요한 테크니컬 SEO 16개 항목

블로그를 "만드는 것"과 블로그가 "검색에서 작동하는 것"은 다른 레이어의 문제예요. 검색에서 작동하게 만드는 요소들을 테크니컬 SEO라고 부르는데, 이게 생각보다 많아요.

• 사이트맵 자동 생성: 구글 크롤러가 블로그의 전체 구조를 파악하려면 사이트맵이 있어야 해요. 글을 발행할 때마다 사이트맵이 자동으로 업데이트돼야 합니다.

• 캐노니컬(canonical) URL: 같은 콘텐츠가 여러 URL로 접근 가능할 때, "이게 원본이다"라고 검색엔진에 알려주는 태그예요. 이게 없으면 중복 콘텐츠로 인식돼서 크롤링 예산이 낭비됩니다.

• 308 리다이렉트 자동 처리: 슬러그를 바꿨을 때, 기존 URL로 들어온 사람이 새 URL로 자동 이동되게 해야 해요. 이게 없으면 슬러그 하나 바꿀 때마다 기존 백링크가 전부 404가 됩니다.

• JSON-LD 구조화 데이터: 검색엔진이 "이 페이지가 블로그 글인지, 제품 페이지인지, FAQ인지"를 이해할 수 있게 해주는 스키마 마크업이에요.

• OG(Open Graph) 태그: 링크드인이나 슬랙에 블로그 URL을 붙여넣었을 때 썸네일과 제목이 예쁘게 나오게 하는 태그예요. 없으면 링크를 공유했는데 회색 박스만 뜹니다.

• 이미지 자동 압축, 포맷 변환, Lazy Loading: 글에 이미지를 올릴 때마다 최적 사이즈로 압축하고, WebP 같은 차세대 포맷으로 변환하고, 화면에 보일 때만 로딩하는 Lazy Loading까지 적용해야 Lighthouse 성능 점수와 Core Web Vitals의 LCP(Largest Contentful Paint)가 유지돼요. 이미지가 많은 블로그에서는 이 세 가지가 한 세트입니다.

• 시맨틱 헤딩(H1~H6) 구조: H1은 페이지당 하나, H2~H6은 논리적 순서대로. 크롤러가 콘텐츠의 위계를 파악하는 기본 구조예요.

• robots.txt 설정: 크롤러에게 "여기는 수집해도 되고, 여기는 하지 마"라고 알려주는 파일이에요.

• RSS 자동 생성: 구독자가 새 글을 자동으로 받아볼 수 있게 해주고, 일부 검색엔진과 뉴스 수집기도 RSS를 활용합니다.

• 글로벌 CDN: 어디서 접속하든 빠르게 로딩되도록 콘텐츠를 전 세계 서버에 분산 배포하는 인프라예요.

• 이미지 alt 태그: 이미지를 텍스트로 설명해주는 속성이에요. 크롤러가 이미지 내용을 이해하는 데 쓰이고, 접근성(accessibility)에도 필수입니다.

• AI 기반 SEO 슬러그 자동 추천: URL에 한글이나 의미 없는 ID 대신, 검색엔진이 읽을 수 있는 키워드 기반 슬러그가 필요해요. 인블로그는 포스트 내용을 AI가 분석해 SEO 친화적인 URL을 자동으로 추천해줍니다. 슬러그를 뭘로 지을지 고민하는 시간 자체가 사라지는 거예요.

• 404 페이지 핸들링: 존재하지 않는 URL로 들어왔을 때 사용자를 적절히 안내하는 페이지예요. 없으면 이탈률이 올라갑니다.

• HTTPS 기본 적용: 보안 연결은 구글 랭킹 요소이기도 하고, HTTP 사이트는 브라우저에서 "안전하지 않음" 경고가 뜹니다.

• 15. 폰트 최적화: 웹폰트 로딩이 느리면 콘텐츠가 깜빡이거나 레이아웃이 밀려요(CLS). 프리로드, 서브셋팅, 적절한 폴백 설정이 필요합니다.

• 반응형 레이아웃: 모바일, 태블릿, 데스크탑 어디서든 콘텐츠가 깨지지 않고 읽히는 구조. 구글은 모바일 우선 인덱싱(mobile-first indexing)을 기본으로 합니다.

이 16개 항목을 알아두면 콘텐츠를 더 잘 쓸 수 있어요. H2 구조를 의식하면서 글을 쓰면 글의 논리 자체가 단단해지고, 슬러그가 뭔지 알면 URL을 의미 있게 설계할 수 있어요. 더 깊이 알고 싶다면 인블로그 팀이 정리한 SEO 최적화 완벽 가이드도 참고해 보시면 좋습니다.

근데 이걸 직접 구현하고 유지보수하는 건 완전히 다른 문제입니다. "H2가 중요하다"는 걸 아는 것과, "내 블로그 템플릿에서 H2가 실제로 시맨틱 태그로 렌더링되고 있는지 확인하고, 그게 깨지면 고치는 것"은 다른 일이에요.

Framer, Webflow CMS면 충분하지 않나요?

"프레이머나 웹플로우에도 CMS가 있잖아요. 사이트맵도 자동 생성되고, robots.txt도 있고, OG 태그도 되고, 반응형도 되는데 이거면 충분하지 않나요?"

이 플랫폼들도 위 16개 중 절반 이상을 체크박스 수준에서는 제공합니다. 하지만 "기능이 존재하는 것"과 "블로그 운영에 최적화된 것"은 다릅니다. 프레이머는 본질적으로 홈페이지 빌더이고, CMS는 부가 기능이에요. 블로그 전문 도구는 블로그가 코어 프로덕트입니다. 그 차이는 구체적인 지점에서 드러나요.

프레이머에서 커스텀 캐노니컬 URL을 설정하려면 가장 비싼 엔터프라이즈 플랜이 필요해요. 블로그 운영에서 캐노니컬 관리는 기본 중의 기본인데, 요금 장벽 뒤에 숨어 있습니다. JSON-LD 구조화 데이터를 넣으려면 직접 코드를 작성해야 하고, 카테고리나 태그 같은 블로그 기본 기능도 제한적이에요. 하위 요금제에서는 CMS 아이템 수에 상한이 있어서, 콘텐츠 100개를 목표로 한다면 요금제부터 올려야 합니다.

결정적으로 서치 콘솔 연동 대시보드, AI 기반 슬러그 추천, 에디터 내 내부 링크 검색 연결, CTA와 리드 수집 폼, 에디터별 성과 분석 같은 "블로그 운영 레이어"의 기능들은 이 플랫폼들에 아예 존재하지 않아요. 글을 발행한 다음, 그 글이 검색에서 어떻게 작동하고 있는지 확인하고, 다음 글을 결정하는 피드백 루프 — 이건 블로그가 코어인 제품만이 제공할 수 있는 특화된 영역입니다.

노션에도 테이블이 있고 에어테이블에도 데이터베이스가 있지만, 세일즈 파이프라인을 본격적으로 돌리려면 결국 세일즈포스 같은 CRM을 써야만 합니다. "테이블이 있다"는 것과 "파이프라인을 운영할 수 있다"는 건 다른 차원의 문제니까요.

블로그도 마찬가지예요. "CMS가 있다"는 것과 "콘텐츠 마케팅을 운영할 수 있다"는 건 다른 게임입니다.

블로그 콘텐츠 50개 넘으면 터지는 구조적 부채

커피챗에서 만난 그 창업자분이 본인의 바이브코딩(일명 '딸깍') 경험을 얘기하면서 한 말이 있어요.

"처음에는 다 될 것 같다가, 많이 하다 보면 안 되는 부분이 있고, 그걸 어디서 어떻게 선택할 거냐가 제일 중요한 것 같더라고요."

기업 블로그 툴도 마찬가지입니다. 콘텐츠가 10개일 때는 뭘 해도 돌아갑니다. 슬러그를 잘못 지어도 수동으로 고치면 되고, 이미지 용량이 커도 10개밖에 없으니까 로딩 속도가 큰 문제가 안 돼요. 사이트맵을 수동으로 만들어도 10줄이면 끝나요. 50개부터 달라져요. 슬러그 하나 바꿨는데, 그 글을 링크한 다른 글 3개에서 404가 터집니다. 이미지가 최적화 안 돼 있으니까 Core Web Vitals 점수가 슬금슬금 내려가요. 카테고리가 늘어나면서 canonical이 꼬이기 시작하고, 어떤 글이 인덱싱이 안 되고 있는지 추적이 안 됩니다.

내부 링크도 문제예요. 글이 10개일 때는 어떤 글이 어떤 글을 참조하는지 머릿속에 다 들어 있는데, 50개가 넘어가면 관련 글끼리의 연결을 수동으로 관리하는 게 사실상 불가능해져요. 내부 링크는 구글이 사이트 구조를 파악하는 핵심 시그널인데, 이게 빠지면 크롤러가 콘텐츠 간 관계를 이해 못 합니다. 인블로그는 에디터에서 글을 쓰는 중에도 블로그 내 관련 글을 바로 검색해서 연결할 수 있게 해줘요. 이 기능 하나가, 글이 쌓일수록 연결 구조를 자연스럽게 만들어줍니다.

세일즈에서도 비슷한 일이 생겨요. 엑셀로 세일즈 파이프라인을 관리하면, 딜이 10개일 때는 괜찮습니다. 30개 넘어가면 빠지기 시작해요. 그래서 저는 1인 임에도 불구하고 세일즈포스 같은 CRM을 사용하고 있습니다.

블로그 인프라도 마찬가지예요. 특히 콘텐츠 마케팅을 아웃바운드 채널로 쓰려면 볼륨이 나와야 하고, 볼륨이 나오려면 인프라가 그 스케일을 버텨야 합니다. 100개 넘으면 이 문제들이 복리로 쌓여요. 그때 가서 "테크니컬 SEO 세팅 다시 하자"고 하면, 이미 쌓인 구조적 부채를 청산하는 비용이 처음부터 제대로 세팅하는 비용보다 훨씬 커요. 그리고 하나 더 — 이전(migration) 비용도 생각해야 합니다.

"나중에 옮기면 되지"가 가장 비싼 선택인 이유

"일단 딸깍으로 시작하고 나중에 전문 도구로 옮기면 되지"라고 생각할 수 있는데, 콘텐츠가 50개, 100개 쌓인 상태에서 플랫폼을 옮기는 건 그 자체로 프로젝트예요. 슬러그 매핑, 리다이렉트 설정, 이미지 재최적화, 메타데이터 재구성 — 엑셀에서 세일즈포스로 CRM 마이그레이션 해본 사람은 이 고통을 알 겁니다. "나중에 옮기면 된다"는 말은 "나중에 비용을 더 크게 치르겠다"는 말이에요.

그 창업자분이 쓴 "시행착오 비용"이라는 표현이 딱 맞습니다. 전문 도구는 이 시행착오 비용을 구조적으로 제거해줘요. 슬러그를 바꾸면 308 리다이렉트가 자동으로 걸리고, 이미지를 올리면 압축과 포맷 변환이 알아서 되고, 사이트맵은 글 발행할 때마다 자동 업데이트되니까요.

GEO부터 Lighthouse까지, 테크니컬 SEO 판단 비용을 위임한다는 것

얼마 전에 GEO에 대해 리서치를 꽤 깊게 했어요. GEO — Generative Engine Optimization. AI 검색에서 브랜드가 인용되게 만들자는 새로운 최적화 개념이에요. llms.txt라는 새 파일 포맷도 등장했고, 구조화 데이터의 중요성이 더 커졌다는 얘기도 나오고요.

GEO의 80%는 기존 SEO이고, 나머지 20%도 결국 "웹에 좋은 콘텐츠를 만드는 것"으로 돌아옵니다.

그런데 중요한 건 이런 세상의 변화에 대해서 우리가 모두 대응하는데 시간을 쓸 수 없다는 겁니다. 우리가 돈 내고 쓰는 툴이 이런 일을 대신해주는거죠.

인블로그가 2025년 7월에 llms.txt 자동 생성 기능을 추가했어요. 저는 그걸 나중에 알았어요. "아, 넣었구나" 하고 넘어갔습니다. 사이트맵 포맷이 업데이트됐을 때도 마찬가지였고, 이미지 최적화 로직이 개선됐을 때도 제가 한 건 없어요. 구글 Lighthouse 기준으로 90점 이상을 유지하는 것도 인블로그 팀이 알아서 맞춰주는 거예요.

Lighthouse 점수가 뭔지 아는 사람은 알겠지만, 이걸 90 이상으로 "유지"하는 건 한 번 맞추는 것과 전혀 다른 일입니다. 구글이 측정 기준을 바꿀 때마다, 서드파티 라이브러리가 업데이트될 때마다 점수가 흔들려요. 딸깍 블로그에서는 그때마다 직접 디버깅해야 합니다.

인블로그 팀이 필요하다고 판단해서 넣었겠지, 혹은 비용이 낮으니까 일단 넣어둔 거겠지. 어느 쪽이든 저는 그 의사결정에 시간을 쓸 이유가 없었어요.

딸깍으로 만든 블로그는 이게 안 됩니다. llms.txt 기사가 뜨면 "나도 넣어야 하나?"를 고민해야 해요. 구조화 데이터 스펙이 바뀌면 직접 찾아서 업데이트해야 하고요. Google AI Overview가 확대되면 "뭔가 달라져야 하나?"를 본인이 판단해야 합니다.

전문 도구에 위임한다는 건, "무엇이 중요한지 판단하는 비용"까지 위임하는 겁니다. 테크니컬 SEO 트렌드를 모니터링하고, 우선순위를 매기고, 구현하고, 유지보수하는 — 이 전체 사이클을 도구 팀이 대신 돌려주는 거예요.

덕분에 저는 글만 쓰면 됩니다. SEO에서 뭐가 바뀌든, 새 용어가 나오든, 제 할 일은 변하지 않아요. 좋은 글을 쓰는 것.

다음에 뭘 쓸지 알려주는 피드백 루프

인블로그는 서치 콘솔을 연동해서 어떤 키워드로 유입이 들어오는지, 어떤 글이 인덱싱이 돼 있는지를 대시보드에서 바로 보여줘요. 이 데이터를 보면서 "다음에 뭘 쓸 것인가"를 결정하는 피드백 루프가 생깁니다.

딸깍 블로그에는 이 루프가 없어요. 글을 쓰고 나서 "이게 검색에서 작동하고 있는지"를 확인할 방법 자체가 없으면, 콘텐츠 전략은 감에 의존하게 됩니다.

바이브코딩 블로그 vs 전문 블로그 도구, 어디에 쓸 것인가

저도 딸깍을 씁니다. Claude로 세일즈포스 MCP 서버를 만들었고, 인블로그 MCP 서버도 만들었어요. 내부 도구나 자동화 파이프라인에서는 딸깍이 위력적이에요. 프로토타이핑할 때, MVP를 빠르게 검증할 때, 사내 도구를 만들 때 — 이런 영역에서 딸깍의 속도는 대체 불가능합니다.

하지만 SEO는 다른 종류의 문제예요. 시간이 지날수록 구조가 쌓이고, 그 구조 위에 콘텐츠가 올라가요. 콘텐츠가 쌓일수록 구조의 빈틈이 비용으로 돌아오는 영역이에요. 이런 영역에서는 "빠르게 만드는 능력"보다 "오래 운영할 수 있는 구조"가 중요합니다. 그리고 그 구조를 전문적으로 관리해주는 제품이 존재하면, 위임하는 게 맞아요. 이전에 SaaS 도입 vs 직접 개발에 대해 쓴 글에서도 같은 원리를 다뤘는데, 블로그 인프라에도 그대로 적용됩니다.

홈페이지 만드는 도구와 블로그 만드는 도구가 다른 영역인 것처럼, 만드는 도구와 운영하는 도구도 다른 영역이에요.

"글만 쓸 수 있게 해주니까요"

"인블로그 같은 기업 블로그 툴 왜 쓰세요?"

처음엔 "SEO가 잘 돼 있으니까요"라고 답했어요. 지금은 좀 다르게 말합니다.

"글 쓰는데만 집중할 수 있게 해주니까요."

테크니컬 SEO를 알면서도 거기에 시간을 쓰지 않아도 되는 환경. 그걸 만들어주니까요. 저는 지금 40번째 글을 향해 달려가고 있는데, 테크니컬 SEO에 쓴 시간은 0입니다.

그 시간은 전부 글 쓰는 데 들어갔어요. 이게 전문 도구의 ROI예요. 월 구독료가 아니라, 되찾은 시간으로 측정되는 거죠. 지금 블로그를 직접 만들까 고민하고 있다면, 하나만 물어보세요.

"이 블로그에 글이 100개 쌓였을 때,

나는 글을 쓰는 데 시간을 쓰고 있을까?

인프라 고치는 데 시간을 쓰고 있을까?"