SEO를 처음부터 생각했어야 했다 — 뒤늦은 최적화 분투기

-

 


사이트를 공개한 지 2주가 지났는데 구글 검색 유입이 0이었다. 알고 보니 구글 봇 눈에는 내 사이트가 텅 빈 HTML 파일이었다. React SPA의 근본적 한계를 그때서야 깨달았다.

검색 유입 제로의 충격

프로젝트를 GitHub Pages에 올리고 나서, 매일 구글 서치 콘솔을 확인했다. 노출 0, 클릭 0. 일주일이 지나도 변함없었다. "아직 인덱싱이 안 됐나 보다"라고 자위했지만, 2주째에 현실을 직시했다.

URL 검사 도구로 확인해보니, 구글이 크롤링한 페이지의 렌더링 결과가 거의 비어 있었다. 타이틀과 간단한 로딩 스피너만 보이고, 실제 콘텐츠는 없었다. 이유는 단순했다. React SPA는 JavaScript가 실행되어야 콘텐츠가 렌더링되는데, 구글 봇이 항상 JavaScript를 완벽하게 실행하는 건 아니기 때문이다.

SPA의 근본적 SEO 문제

전통적인 웹사이트는 서버에서 HTML을 완성해서 보내준다. 구글 봇이 페이지를 요청하면 콘텐츠가 담긴 HTML을 받는다. 하지만 React SPA는 다르다. 서버가 보내는 HTML은 빈 껍데기이고, 브라우저에서 JavaScript가 실행되면서 비로소 콘텐츠가 채워진다.

구글은 JavaScript를 렌더링할 수 있다고 공식적으로 밝히고 있지만, 실제로는 두 단계 인덱싱 과정을 거친다. 첫 번째 단계에서 HTML만 보고, 두 번째 단계에서 JavaScript를 렌더링한다. 두 번째 단계까지 가는 데 시간이 걸리고, 모든 페이지가 완벽하게 렌더링되는 것도 아니다.

Next.js나 Remix 같은 프레임워크를 썼다면 서버 사이드 렌더링(SSR)으로 이 문제를 자연스럽게 해결할 수 있었다. 하지만 이 프로젝트는 Vite로 시작했고, 지금 와서 프레임워크를 바꾸는 건 사실상 처음부터 다시 만드는 것과 같았다.

프리렌더링이라는 절충안

SSR을 도입할 수 없다면, 대안은 프리렌더링이다. 빌드 시점에 각 페이지의 HTML을 미리 생성해두는 방식이다. 구글 봇이 페이지를 요청하면 콘텐츠가 포함된 정적 HTML을 받게 된다.

원리는 이렇다. 빌드가 완료된 후, 헤드리스 브라우저가 각 페이지를 방문해서 JavaScript를 실행하고, 렌더링된 결과 HTML을 파일로 저장한다. 이 HTML 파일을 배포하면, 구글 봇은 JavaScript 실행 없이도 콘텐츠를 읽을 수 있다.

문제는 페이지가 많아질수록 빌드 시간이 길어진다는 것이다. 가이드 페이지, 칼럼, 백과사전 등 콘텐츠를 추가하면서 프리렌더링 대상 페이지가 수십 개로 늘어났고, 빌드 시간도 함께 늘어났다. 그래도 SSR 서버를 운영하는 것보다는 훨씬 단순하다.

react-helmet-async로 동적 메타 태그

프리렌더링으로 HTML 본문 문제는 해결했지만, 메타 태그 문제가 남아 있었다. 모든 페이지의 타이틀과 description이 동일했다. 구글 검색 결과에 표시되는 제목과 설명이 모든 페이지에서 같다면, 사용자는 어떤 페이지를 클릭해야 할지 판단할 수 없다.

react-helmet-async를 도입해서 각 페이지별로 고유한 타이틀, description, og:image 등을 설정했다. 카드 상세 페이지라면 "타로 마스터 | 바보(The Fool) 카드 해석"처럼, 페이지의 내용을 정확히 반영하는 메타 태그를 넣었다.

Open Graph 태그와 Twitter 카드 태그도 추가했다. 소셜 미디어에서 링크를 공유할 때 미리보기가 제대로 표시되도록 하는 것이다. 직접적인 SEO 요소는 아니지만, 소셜 공유로 인한 유입도 무시할 수 없다.

사이트맵 자동 생성

구글이 내 사이트의 모든 페이지를 발견하려면 사이트맵이 필요하다. 수동으로 관리하는 건 페이지가 추가될 때마다 잊어버리기 쉬우니, 빌드 과정에서 자동으로 생성하는 스크립트를 만들었다.

라우트 설정 파일에서 모든 경로를 추출하고, 동적 경로(카드 상세 페이지 등)의 파라미터를 채워서, 전체 URL 목록이 담긴 sitemap.xml을 생성한다. 빌드할 때마다 최신 상태의 사이트맵이 자동으로 만들어진다.

robots.txt에 사이트맵 위치를 명시하고, 구글 서치 콘솔에도 사이트맵을 제출했다. 사이트맵 제출 후 며칠 만에 인덱싱이 눈에 띄게 빨라졌다.

검색 엔진 등록: 구글 그리고 네이버

한국어 콘텐츠라면 구글만으로는 부족하다. 네이버 검색에서의 노출도 중요하다. 네이버 서치어드바이저에 사이트를 등록하고 소유권을 인증했다.

네이버의 인덱싱은 구글과 다른 특성이 있다. 네이버 블로그나 카페 콘텐츠에 비해 외부 웹사이트의 노출 순위가 낮은 편이고, 인덱싱 속도도 느리다. 그래도 등록하지 않으면 아예 노출되지 않으니, 기본은 해두는 것이 맞다.

구글 서치 콘솔에서는 URL 검사 도구가 유용했다. 특정 페이지가 제대로 인덱싱되었는지, 모바일 사용성에 문제가 없는지 바로 확인할 수 있다. 프리렌더링 적용 후 다시 URL 검사를 해보니, 이번에는 콘텐츠가 온전하게 표시되었다.

구조화된 데이터: JSON-LD 스키마 마크업

검색 결과에서 더 눈에 띄려면 구조화된 데이터가 필요하다. JSON-LD 형식의 스키마 마크업을 추가하면, 구글이 페이지의 내용을 더 정확하게 이해하고, 검색 결과에 리치 스니펫을 표시해줄 수 있다.

메인 페이지에는 WebApplication 스키마를, 가이드 페이지에는 Article 스키마를, FAQ가 포함된 페이지에는 FAQPage 스키마를 적용했다. 카드 백과사전 페이지에는 ItemList 스키마를 사용해서 78장의 카드 목록을 구조화했다.

구조화된 데이터가 검색 순위에 직접적으로 영향을 미치는지는 논쟁의 여지가 있지만, 리치 스니펫으로 표시되면 클릭률이 확실히 올라간다. 같은 검색 결과 페이지에서 별점이나 FAQ가 표시된 결과와 그렇지 않은 결과 중 어느 쪽을 클릭하겠는가.

"처음부터 SEO"가 맞다

돌이켜보면, 프로젝트 시작 시점에 SEO를 고려했어야 했다. 프리렌더링을 나중에 추가하면서 빌드 파이프라인을 크게 수정해야 했고, 메타 태그를 모든 페이지에 추가하는 것도 한꺼번에 하려니 꽤 많은 작업이었다.

처음부터 Next.js를 선택했다면 SSR이 자연스럽게 해결됐을 것이다. 하지만 그때는 Vite의 빠른 개발 경험이 더 중요했고, SEO는 나중에 생각하자고 미뤘다. 사이드 프로젝트에서 흔히 하는 실수다.

교훈은 분명하다. 검색 유입이 필요한 프로젝트라면 SEO는 "나중에"가 아니라 "처음부터"다. 프레임워크 선택, 라우팅 구조, 메타 태그 설계를 초기에 결정해야 한다. 나중에 고치는 비용이 처음에 제대로 하는 비용보다 항상 크다.

다음 편 예고

SEO의 기술적 기반을 닦았지만, 검색 유입을 실제로 만들려면 "검색할 만한 콘텐츠"가 있어야 한다. Part 14에서는 기능 앱에서 콘텐츠 허브로의 전략 전환, 그리고 AI를 활용한 대량 콘텐츠 생산 워크플로우를 다룬다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

사랑을 직접 올리지 않는 설계

-
  이전 편에서 3계층 감정 모델을 설계했다. 그 중 가장 중요한 원칙이 하나 있다.  사랑이라는 변수는 시스템에 존재하지 않는다. love += 1은 없다. 대신 사랑은 다른 변수들의 조합에서 "발생"한다. 이게 이 시스템의 핵심이고, 기존 호감도 시스템과의 가장 큰 차이다. 왜 사랑을 직접 변수로 두면 안 되는가 AI와 이 주제로 대화했을 때, AI가 흥미로운 관점을 제시했다. "사랑은 다른 감정과 같은 급이 아니다." 슬픔, 분노, 질투, 두려움. 이것들은 단발적 감정이다. 특정 사건에 반응해서 올라가거나 내려간다. 하지만 사랑은 다르다. 사랑은 보통 단발 감정보다  누적된 관계 해석의 결과 에 가깝다. 신뢰가 높다. 의존이 있다. 친밀감이 쌓였다. 질투도 약간 있다. 상실 공포가 있다. 상대를 반복적으로 우선 선택한다. 이 조합을 플레이어가 "사랑"으로 읽는 거다. 시스템적으로 이걸 표현하면 이렇다. love_state = ( trust >= 70 and intimacy >= 60 and fear_of_loss >= 30 and chosen_priority >= 5 ) love를 직접 올리는 게 아니라, 사랑이 발생하는 조건을 설계하는 것이다. 이 차이가 크다. 왜 이 방식이 더 자연스러운가 현실을 생각해보자. 누군가를 사랑하게 되는 순간을 정확히 짚을 수 있는 사람이 있는가? 대부분은 없다. 어느 날 문득 "아, 내가 이 사람을 좋아하는구나"를 깨닫는 거다. 사랑은 시작 버튼을 누르는 게 아니라, 이미 쌓여 있던 것을 인식하는 거다. love += 1 시스템에서는 이 경험을 재현할 수 없다. 선택할 때마다 사랑이 올라가니까, 플레이어는 "지금 사랑이 몇 점쯤 되겠지"를 계산하게 된다. 감정이 아니라 점수 관리가 된다. 조건 조합형에서는 다르다. 플레이어는 사랑 수치를 모른다. 사랑이라는 변...
자세한 내용 보기

감정을 변수로 옮기다 — 3계층 감정 모델

-
  이제 본격적으로 감정을 설계할 차례다. 호감도+1의 한계를 파악했으니, 그걸 대체할 시스템을 만들어야 한다. AI에게 말했다. "호감도 하나가 아니라, 사람의 감정을 좀 더 현실적으로 표현할 수 있는 변수 시스템을 만들고 싶어." 그리고 여기서부터 AI가 본격적으로 힘을 발휘하기 시작했다. 감정을 구조화하는 작업, 즉 추상적인 것을 변수와 계층으로 분해하는 작업은 AI가 잘하는 영역이다. 감정은 몇 개가 필요한가 첫 번째 질문이 이거였다. "감정 변수를 몇 개 두면 될까?" AI의 답은 의외로 신중했다. "많으면 많을수록 좋은 게 아니다. 변수가 많아지면 오버엔지니어링이 된다." 그리고 핵심적인 구분을 제안했다. 표현해야 하는 감정의 종류는 많아도 된다. 하지만 시스템이 직접 추적하는 상태값은 구조적으로 정리되어야 한다. 무슨 뜻인가. 사랑, 슬픔, 분노, 자만, 시기, 질투, 믿음, 신뢰, 긴장, 갈등, 두려움, 공포, 선망. 이런 감정을 전부 독립 변수로 나열할 수는 있다. 하지만 그러면 상호작용 규칙이 폭증한다. 어떤 이벤트가 뭘 얼마나 바꾸는가, 사랑과 신뢰가 동시에 오를 수 있는가, 시기와 선망의 차이는 어떤 조건에서 갈라지는가. 정의 없이 변수만 많으면 게임이 더 가짜가 된다. 그래서 AI가 제안한 건 감정을 레이어로 나누는 것이었다. 3계층 모델 AI와 반복적으로 대화하면서 정리된 구조가 이거다. A층: 근본 성향 / 욕구  — 캐릭터의 고유값. 쉽게 안 바뀐다. 게임 시작 시 설정되고, 플레이 중에는 거의 변하지 않는다. 애정 욕구 (need_for_affection) 거절 공포 (fear_of_rejection) 자존심 (pride) 불안정감 (insecurity) 이건 캐릭터의 "성격"이다. 왜 이 사람이 이런 행동을 하는지의 근본 이유. B층: 현재 감정 상태  — 장면이나 사건에 반응해서 흔들린다. 순간적이고 유동적이다. 애정 (affection) 분노 (anger...
자세한 내용 보기

시작의 충동 — "타로 웹앱을 만들어볼까?"

-
사이드 프로젝트는 대부분 기획서 작성 단계에서 죽는다. 당신도 경험이 있을 것이다. 번뜩이는 아이디어가 떠올라 노션을 열었다가, 기획을 정리하다 에너지를 다 써버리고, 결국 "나중에 해야지" 폴더에 묻히는 그 패턴 말이다. 이 글은 그 패턴을 깬 이야기다. AI에게 한 문장을 던지고, 10분 만에 프로젝트가 구체화된 경험에 대한 이야기다. 한 문장에서 시작된 프로젝트 "타로카드를 보는 웹페이지를 만드려고 해." 프로젝트의 시작은 이 한 문장이었다. 거창한 기획서도, PRD도, 경쟁사 분석도 없었다. 평소 타로에 관심이 있었고, 웹으로 만들면 재밌겠다는 생각이 전부였다. 구체적인 기능 목록도 없었고, 어떤 기술 스택을 쓸지도 정하지 않았다. 보통이라면 여기서 두 가지 중 하나가 벌어진다. 구글링을 시작해서 "타로 웹앱 만들기"를 검색하거나, 노션에 기획 문서를 만들고 목차부터 쓰기 시작하는 것이다. 두 방법 모두 나쁘지 않지만, 공통적인 위험이 있다. 실행에 들어가기 전에 에너지가 소진된다는 것이다. 이번에는 다르게 접근했다. Claude에게 바로 물었다. 이 선택 하나가 프로젝트 전체의 성격을 결정지었다. 왜 기획 단계에서 프로젝트가 죽는가 잠깐 이야기를 돌려서, 사이드 프로젝트가 왜 기획 단계에서 사라지는지 생각해보자. 내 경험상 이유는 세 가지다. 첫째, 완벽주의의 함정이다. "제대로 시작하려면 제대로 기획해야지"라는 생각이 들면, 기획서의 목차를 쓰고, 벤치마킹할 서비스를 찾고, 기능 목록을 정리하기 시작한다. 그러다 보면 만들어야 할 것이 점점 커지고, "이건 주말에 할 수 있는 규모가 아닌데"라는 결론에 도달한다. 둘째, 도메인 지식의 벽이다. 타로 웹앱을 만들려면 타로에 대해 알아야 한다. 카드가 몇 장인지, 어떤 종류가 있는지, 리딩은 어떻게 하는지. 이걸 알아보려고 검색을 시작하면 탭이 열 개, 스무 개 쌓인다. 정보는 많은데 "내 프로젝트에 필요한...
자세한 내용 보기