SI 구축 사이트에 개발 없이 SEO·AI 대응 추가

EC 사이트를 SI에 맡겨 구축한 팀은 템플릿이나 head 한 줄을 고치는 데도 개수 견적과 개발 사이클을 거칩니다. SEO와 AI 검색 대응을 시작하려 해도 반년 뒤가 되는 구조라, 개발 공수를 새로 들이지 않고 대응할 방법이 있는지가 질문이 됩니다.

대기업·중견기업 마케팅 부서에서 가장 자주 받는 상담입니다. 답은 방식에 따라 갈립니다. 원본 코드를 고치는 방식은 개발 사이클을 거칩니다. 렌더링은 브라우저가 화면을 조립하는 과정입니다. 원본은 그대로 두고 검색 엔진과 AI 크롤러에게만 별도 렌더링 층을 보여 주는 방식도 있습니다. 렌더링 층은 봇에게 건네는 정리된 HTML입니다. 이쪽이라면 SI의 개발 사이클과 상관없이 진행할 수 있습니다.

이 글에서는 SI 구축 사이트에서 SEO 변경이 멈추는 이유부터 다룹니다. 두 방식의 비교, 적용 범위와 한계, 판단 기준, 실제 사례까지 정리했습니다.

결론: 원본을 고치는 방식은 개발 사이클이 필요하다. 별도 렌더링 층 방식이라면 독립적으로 진행할 수 있다

많은 SI 구축 사이트에서 현실적인 선택은 C입니다. A가 본래 맞는 형태이기는 합니다. 하지만 개수 사이클에 묶여 있는 한 SEO와 AI 검색 대응은 늘 반년씩 늦어집니다. B는 손쉬워 보입니다. 그런데 크롤러 대부분은 JavaScript로 넣은 내용을 안정적으로 읽지 않습니다. 기대한 효과가 나오지 않는 이유입니다.

중요한 관점: SEO와 AI 검색 대응은 사람이 보는 화면을 바꾸는 일이 아닙니다. 봇이 읽는 층을 정비하는 일입니다. 매장으로 치면 손님이 보는 진열대는 그대로 두고, 검색 엔진이 보는 상품 목록만 따로 정리하는 셈입니다. 봇이 읽는 층을 원본에서 떼어 낼 수 있으면 개발 사이클과 따로 움직일 수 있습니다.

SI 구축 사이트에서 SEO 변경이 멈추는 이유

멈추는 이유는 기술이 아니라 체제입니다. 네 가지가 겹칩니다.

1. 변경 권한이 SI에 있다. 템플릿이나 head 한 줄을 바꾸는 데도 의뢰·견적·승인을 거칩니다.

2. 유지보수 계약의 범위가 "결함 수정"에 한정되어 있다. SEO 개선은 기능 추가로 취급되어 별도 계약이 됩니다.

3. 릴리스 사이클이 고정되어 있다. 분기에 1회 같은 주기입니다. SEO는 작은 수정을 계속 쌓는 일이라 이 주기와 맞지 않습니다.

4. 렌더링이 JavaScript에 의존한다. SI가 고른 프레임워크가 클라이언트 측 렌더링이면 크롤러가 상품 정보를 읽지 못합니다. 이를 고치려면 개수 규모가 커집니다.

네 번째가 특히 무겁습니다. 원본을 고치는 방식이라면 "프레임워크 교체"에 가까운 개수가 됩니다. 자사 사이트가 넷 중 어디에 걸리는지부터 표시합니다.

별도 렌더링 층으로 할 수 있는 것과 없는 것

정리하면 봇이 읽는 층에 속한 항목은 모두 대상입니다. 사람이 조작하는 기능은 대상 밖입니다. 상품 설명을 봇이 읽게 하는 작업은 되지만, 장바구니 버튼을 바꾸는 작업은 되지 않습니다. SEO와 AI 검색 대응에 필요한 작업은 대부분 앞쪽에 들어갑니다. 하고 싶은 작업이 왼쪽 열에 있는지 확인합니다.

적용 여부를 가르는 판단 기준

아래 조건 중 2개 이상 해당하면 별도 렌더링 층 방식이 맞습니다.

• 템플릿 변경 의뢰부터 반영까지 1개월 이상 걸린다

• 유지보수 계약에서 SEO 개선이 범위 밖으로 되어 있다

• 사이트가 클라이언트 측 렌더링이고, Search Console의 URL 검사에서 상품 정보가 수집된 HTML에 포함되지 않는다

• 상품·카테고리·콘텐츠 페이지가 수천 개 이상이라 개별 대응이 현실적이지 않다

• CDN·WAF·봇 대책 도구의 설정 변경 권한이 자사 또는 인프라 회사에 있다

마지막 조건은 미리 확인해 둡니다. DNS나 리버스 프록시 설정을 바꿀 수 없으면 별도 층을 끼워 넣을 수 없습니다. 이 부분은 SI가 아니라 인프라 담당과 조율하는 경우가 많습니다. DNS 설정 권한이 누구에게 있는지부터 확인합니다.

사례: 추가 개발·마케터 인력 없이

연매출 400억 원(약 40억 엔) 규모의 한국 EC 브랜드 사례입니다. SI에 개수를 의뢰하지 않았습니다. 별도 렌더링 층으로 Technical SEO의 기반을 3주 만에 정비했습니다. 기반은 렌더링, canonical, 메타데이터, 구조화 데이터, 색인 가능성을 말합니다. 이미지에만 있던 상품 설명은 OCR로 HTML 텍스트로 바꿨습니다. 판매 중인 상품에 남아 있던 숨은 품절 텍스트도 지웠습니다. 그 뒤 봇 로그를 보면서 상품·카테고리·브랜드 콘텐츠를 우선 손봤습니다. 결과는 3개월 만에 Organic 구매 매출이 약 9,206만 원에서 약 1억 6,600만 원으로 늘었습니다. 추가 개발 인력도 마케터 인력도 들이지 않았습니다.

개발 사이클과 따로 굴러가는 운영으로

SI 구축 사이트에서 가장 큰 걸림돌은 기술이 아닙니다. "바꿀 때마다 개발 사이클을 기다리는" 체제입니다. 봇이 읽는 층을 원본에서 떼어 내면 마케팅 부서가 주도할 수 있습니다. 주 단위로 수정하고 검증하는 운영이 됩니다.

Search OS는 이 별도 렌더링 층을 SEO/GEO 자동화 솔루션으로 제공합니다. 기존 서비스 운영을 크게 흔들지 않습니다. 검색 엔진과 AI가 읽기 쉬운 렌더링 구조와 메타데이터를 별도로 제공합니다. 시맨틱 태그, sitemap.xml, robots.txt도 함께 다룹니다. canonical, hreflang, 구조화 데이터, 봇 로그 관측까지 하나로 운영합니다. SI의 개발 사이클은 사람용 기능에 집중하고, 봇이 읽는 층은 Search OS가 맡는 분담입니다.

자주 묻는 질문

SI에 알리지 않고 도입할 수 있나요?

기술적으로는 원본을 바꾸지 않으므로 가능합니다. 다만 DNS나 프록시 설정 변경은 인프라 담당과 조율이 필요합니다. SI에도 방식을 공유해 두는 편이 좋습니다. 원본 개수 계획과 역할을 나눠 두면 운영이 안정됩니다.

원본 개수와 병용할 수 있나요?

병용할 수 있습니다. 별도 렌더링 층으로 먼저 효과를 냅니다. 원본 개수는 다음 릴리스 사이클에서 진행해도 됩니다. 개수 뒤에도 가시 텍스트와 구조화 데이터가 맞는지 검증하는 층으로 남습니다.

효과는 어디서 확인하나요?

Search Console의 클릭·노출 수·색인 상황을 기준선으로 삼습니다. 봇 로그에서는 Googlebot·GPTBot 등이 무엇을 가져갔는지 확인합니다. AI 검색에서의 인용은 Bing Webmaster Tools의 AI Performance로 추적합니다. 각종 AI 가시성 도구를 써도 됩니다.

함께 읽기

• SEO/GEO 성공 사례: 연매출 400억 EC 브랜드가 3개월 만에 Organic 구매 매출을 80% 늘린 방법

• SEO와 GEO의 개념 정리: 대규모 플랫폼을 위한 AI 검색 최적화

• 상품 수만 개 규모의 몰에서 크롤 예산과 색인 누락을 관리하는 방법

참고 자료

• Google Search Central: JavaScript SEO basics

• Google Search Central: Dynamic rendering as a workaround

• Google Search Central: AI features and your website