"SEO는 런칭하고 나서 마케팅팀이 하면 되는 거 아닌가요?"

런칭 후에 SEO를 하려고 하면, 구조를 바꿔야 하는 경우가 많습니다. 메타 태그 추가 정도는 괜찮지만, 렌더링 방식이나 URL 구조를 바꾸는 것은 재개발에 가깝습니다. SEO의 상당 부분은 마케팅이 아니라 개발의 영역입니다.

런칭 후에 SEO를 하면 생기는 문제

렌더링 방식 변경

SPA(Single Page Application)로 만든 웹사이트는 JavaScript가 실행되어야 콘텐츠가 보입니다. 구글 검색 엔진이 JavaScript를 실행하지만, 완벽하지 않습니다. 중요한 콘텐츠가 검색에 안 잡히는 경우가 생깁니다.

이걸 해결하려면 SSR(Server-Side Rendering)이나 SSG(Static Site Generation)로 전환해야 합니다. 이건 코드 구조를 근본적으로 바꾸는 작업입니다. 런칭 후에 하면 비용이 큽니다. 처음부터 설계하면 추가 비용이 거의 없습니다.

URL 구조 변경

/product?id=123 같은 URL을 /product/wireless-earbuds-pro로 바꾸는 것. 기술적으로 어렵지 않지만, 이미 검색 엔진에 인덱싱된 URL을 바꾸면 기존 검색 순위를 잃을 수 있습니다. 리다이렉트 설정도 필요합니다. 처음부터 깔끔한 URL 구조로 만들면 이런 문제가 없습니다.

실제로 본 두 가지 사례 — 쇼핑몰인데 검색을 버린 기술 선택

추상적인 얘기가 아닙니다. 저희가 직접 겪은 두 사례를 소개합니다.

첫 번째, 매트리스 전문 쇼핑몰. 한 개발사가 React로 만들겠다고 했습니다. 어떤 이유로 그 기술을 골랐는지 물었습니다. 순수 React로만 만들면(클라이언트 사이드 렌더링) 검색 노출에 크게 불리하기 때문에, 그 점을 어떻게 풀 생각인지가 궁금해서 물은 것이었습니다. 돌아온 답은 "제가 그 기술을 선택했으니까요"였습니다. SEO를 고려한 판단이 아니라, 그냥 본인이 익숙하고 선호하는 기술이라는 것 외에 아무 근거가 없었습니다. 쇼핑몰은 검색 유입이 매출의 핵심인데, 그 결정에 검색에 대한 고민이 들어있지 않았습니다.

두 번째, 이미 1억 5천만 원을 들여 외주로 완성한 쇼핑몰. 개발사가 공들여 만들었다며 기술에 대한 자부심을 보였습니다. 그런데 미팅 중에 열어보니 순수 Vue로 만든 SPA였습니다. 쇼핑몰을 검색에 거의 잡히지 않는 구조로 만들어 놓고도, 그게 문제라는 인식 자체가 없었습니다. 자부심은 대단했지만 그 무지의 비용은 고스란히 클라이언트가 치르고 있었습니다 — 1억 5천만 원짜리 쇼핑몰이 검색으로는 사실상 발견되지 않는 상태였으니까요.

두 사례의 공통점은 기술 자체가 나쁜 게 아니라는 점입니다. React도 Vue도 훌륭한 도구이고, Next.js·Nuxt 같은 프레임워크로 SSR을 적용하면 검색 문제는 해결됩니다. 진짜 문제는 "왜 이 기술을, 이 구조로 골랐는가"에 답하지 못하는 것, 그리고 그 선택이 쇼핑몰의 검색 유입에 어떤 영향을 주는지 처음부터 고려하지 않은 것입니다. 클라이언트는 그 차이를 미리 알기 어렵기 때문에, 피해는 보통 검색 유입이 안 나오는 런칭 이후에야 드러납니다.

개발 중에 해야 할 SEO

SSR 또는 SSG 적용

Next.js, Nuxt.js 같은 프레임워크를 사용하면 서버에서 HTML을 미리 생성할 수 있습니다. 검색 엔진이 콘텐츠를 확실하게 읽을 수 있습니다. 프레임워크를 선택하는 단계에서 결정해야 하는 사항입니다.

메타 태그 설계

각 페이지마다 적절한 title, description, og:image를 설정해야 합니다. 동적으로 생성되는 페이지(상품 상세, 게시글 등)에서는 서버에서 메타 태그를 생성하는 로직이 필요합니다.

시맨틱 HTML

<div>로만 이루어진 페이지와 <header>, <main>, <article>, <nav> 등 의미 있는 태그를 사용한 페이지는 검색 엔진이 이해하는 정도가 다릅니다. 코드를 작성하는 시점에서 적용해야 하는 것입니다.

사이트맵과 robots.txt

검색 엔진에 "이 사이트에는 이런 페이지들이 있습니다"를 알려주는 사이트맵. 크롤링 규칙을 정하는 robots.txt. 배포 전에 설정해두면 런칭과 동시에 검색 엔진이 사이트를 올바르게 인덱싱합니다.

페이지 속도 최적화

구글은 페이지 로딩 속도를 검색 순위에 반영합니다. 이미지 최적화, 코드 스플리팅, 캐싱 전략 — 이런 것들은 개발 과정에서 적용하는 것이 자연스럽습니다. 런칭 후에 속도를 개선하려면 코드를 다시 손봐야 합니다.

2026년, SEO를 넘어 GEO

이제는 Google 검색만 신경 쓸 때가 아닙니다. GEO(Generative Engine Optimization) — AI 생성 엔진 최적화가 새로운 흐름입니다. ChatGPT, Claude, Perplexity 같은 AI에게 "~~ 추천해줘"라고 물었을 때, 우리 서비스가 AI의 답변에 포함되는 것.

AI는 웹 페이지의 구조화된 콘텐츠를 읽어서 답변에 활용합니다. 잘 정리된 FAQ, 명확한 제목 구조, 구체적인 수치와 사례가 있는 콘텐츠일수록 AI가 신뢰하는 소스로 판단합니다. sitemap.xml이 있어야 AI 크롤러도 페이지를 발견할 수 있고, Schema.org 같은 구조화 데이터가 있으면 콘텐츠의 의미를 더 정확히 전달할 수 있습니다.

Google 검색 1페이지에 나오는 것만큼, AI의 답변에 포함되는 것이 중요해지고 있습니다. SEO와 GEO는 별개가 아니라, 둘 다 개발 단계에서 설계해야 하는 것입니다.

SEO는 개발의 영역이기도 하다

키워드 분석, 콘텐츠 전략 — 이건 마케팅입니다. 하지만 그 전략이 실행될 수 있는 기술적 기반을 만드는 것은 개발입니다.

개발사에 프로젝트를 의뢰할 때, "SEO를 고려한 개발이 가능한가요?"를 물어보세요. SSR을 적용할 수 있는지, 메타 태그를 동적으로 관리할 수 있는지, 사이트맵 자동 생성이 가능한지. 이 질문에 명확하게 답할 수 있는 개발사를 선택해야 합니다.

우리가 SEO를 어떻게 운영하는가

프로덕트 메이커는 이 블로그를 포함한 productmaker.io 자체를 직접 운영하면서 SEO·GEO를 매주 다듬고 있습니다. Next.js 위에서 SSR·SSG를 혼용하고, sitemap.xml 자동 생성·페이지별 메타 태그 동적 관리·Schema.org 구조화 데이터·OG 이미지까지 빌드 파이프라인 안에 모두 포함시켜 둔 구조입니다. "검색 엔진에 우리 페이지가 어떻게 보이는가"를 매번 수동으로 챙기지 않아도 새 글이 올라오면 자동으로 인덱싱 가능한 형태로 배포되도록 했습니다.

이런 구조는 두코 디지털 카탈로그·케이엠파크(km-park.com)·기타 클라이언트 프로젝트에도 거의 동일하게 적용해 왔습니다. 특히 케이엠파크처럼 "주차장 + 지역명" 같은 long-tail 검색 유입이 매출과 직결되는 서비스에서는 URL 구조와 페이지별 메타 태그가 그 자체로 매출 채널입니다. 처음 설계 시 잡지 못하면 나중에 도메인·인덱스를 통째로 흔드는 큰 비용이 발생합니다.

저희 입장에서 SEO가 "마케팅"이라는 단어로 처리되는 게 가장 답답합니다. 검색 엔진이 페이지를 어떻게 읽고 인덱싱하는지는 렌더링 방식·URL 구조·HTML 시맨틱·페이지 속도 같은 기술 결정에서 거의 결정되기 때문입니다. 마케팅팀의 키워드 전략은 그 위에서 비로소 효과를 냅니다. 순서가 바뀌면 콘텐츠는 좋은데 노출은 안 되는 상태가 됩니다.

키워드 분석·콘텐츠 전략은 마케팅의 영역입니다. 하지만 그 전략이 실행될 수 있는 기술적 기반을 만드는 것은 개발의 영역입니다. 개발사에 프로젝트를 의뢰할 때, "SSR·메타 태그 동적 관리·sitemap 자동 생성·Schema.org 마크업이 빌드 파이프라인에 들어있는가"를 물어보세요. 답이 명확한 개발사를 선택해야 합니다.

SEO를 넘어 GEO·AEO까지 다룬 별도 글에서 AI 답변 엔진 시대에 사이트를 어떻게 설계해야 하는지를 더 자세히 정리했으니 함께 보면 좋습니다.

*SEO·GEO를 고려한 웹 서비스 개발이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*