검색이 바뀌면 제품도 바뀐다 — 개발 외주 전에 알아야 할 SEO·GEO 변화

한줄 요약

AI 검색 시대, 개발 방식 자체가 제품의 발견 가능성을 결정한다.

본문

검색엔진 최적화(SEO)는 이제 렌더링 구조와 배포 파이프라인까지 건드리는 기술 문제다. 불과 몇 년 전까지만 해도 SEO는 마케팅팀이 키워드를 고르고 메타 태그를 다듬는 일이었다. 하지만 AI가 검색 결과 화면의 구조를 뜯어고치면서, 제품이 어떻게 발견되는지를 결정하는 요인이 완전히 달라졌다.

외주 개발을 의뢰하거나 자체 개발팀을 꾸려 제품을 만들 때, 이 변화를 모르고 시작하면 나중에 훨씬 큰 비용을 치른다.

AI 검색은 왜 개발자·PM의 문제인가

AI는 사용자에게 링크 목록을 보여주는 대신 직접 답을 내놓는다. 이 과정에서 AI 모델이 웹페이지를 어떻게 읽고, 어떤 정보를 우선적으로 가져오는지가 제품의 노출을 좌우한다.

여기서 핵심은, AI가 정보를 파싱하는 방식이 기존 검색 크롤러와 다르다는 점이다. 자바스크립트로 동적 렌더링된 콘텐츠는 AI 모델이 제대로 읽지 못하는 경우가 많다. 서버사이드 렌더링(SSR)을 쓰는지, 클라이언트사이드 렌더링(CSR)을 쓰는지에 따라 AI에 인식되는 정보량 자체가 달라진다.

외주 개발사에 단순히 "빠르게 만들어 달라"고 요청하면, 이런 부분은 대부분 기본값대로 처리된다. 나중에 검색 유입이 기대보다 낮은 이유를 찾다가 렌더링 구조를 뒤늦게 뜯어고치는 상황이 생기는 이유다.

개발 단계에서 챙겨야 할 것들

GEO(생성형 엔진 최적화)는 콘텐츠를 잘 쓰는 문제를 넘어, 정보를 어떻게 구조화하느냐의 문제로 바뀌고 있다. AI가 참조하기 좋은 정보는 맥락이 명확하고, 위계가 잘 잡혀 있으며, 구조화된 데이터 마크업이 붙어 있다.

외주 개발을 맡길 때 기술 명세서에 포함해야 할 항목들이 있다.

• 렌더링 방식 명시: SSR, SSG, CSR 중 어떤 방식을 쓸 것인지, 그리고 그 선택이 검색 노출에 미치는 영향을 개발사와 함께 검토해야 한다.
• 구조화 데이터 적용 범위: Schema.org 마크업을 어느 페이지에 어떤 유형으로 붙일 것인지를 기획 단계에서 정의해야 한다. 개발이 완료된 뒤에 붙이려 하면 구조를 다시 손봐야 하는 경우가 생긴다.
• 크롤 접근성 확보: robots.txt, sitemap, canonical 설정은 배포 파이프라인 안에 포함시켜야 한다. 런칭 이후 개별 수정 요청으로 처리하면 누락이 발생한다.

이걸 요구사항으로 명문화하지 않으면, 개발사 입장에서는 기능 구현에 집중하는 게 자연스러운 선택이다.

정보 구조가 곧 제품 경쟁력이 되는 시대

AI 검색이 인용하는 콘텐츠는 특정 조건을 갖추고 있다. 명확한 주장이 있고, 그 근거가 문서 안에서 체계적으로 연결되어 있으며, 다른 문서와의 관계가 논리적으로 이어진다. 온톨로지(개념 간 관계 설계)라는 개념이 SEO 맥락에서 다뤄지기 시작한 것도 이 이유에서다.

제품 관점에서 바꿔 말하면, 정보 아키텍처(IA)를 잘 설계한 제품이 AI 검색에서도 잘 인용된다는 뜻이다. 콘텐츠를 얼마나 많이 만드느냐보다, 콘텐츠 간의 관계를 얼마나 잘 설계하느냐가 중요해지고 있다.

외주 개발을 의뢰할 때 IA 설계 단계에서 SEO·GEO 요건을 같이 논의해야 하는 이유가 여기에 있다. 개발이 끝난 뒤에 정보 구조를 바꾸는 건, 건물을 다 지은 뒤에 배관을 다시 까는 것과 비슷하다.