AI 개요에서 브랜드 답변을 지배하는 법: 내가 겪은 스키마 마크업 실수와 해결책

내 사이트 트래픽이 하루아침에 40% 폭락한 날이 있었습니다. 원인을 찾기 위해 구글 서치 콘솔과 analytics 데이터를 뒤졌지만, 특별한 패널티나 알고리즘 업데이트 소식은 없었습니다. 며칠간의 분석 끝에 저는 충격적인 사실을 마주하게 되었습니다. 구글이 ‘AI 개요(AI Overview)’라는 새로운 검색 기능을 본격 도입하면서, 제 콘텐츠는 해당 답변의 소스로 전혀 선택되지 않고 있었습니다. 네, 제가 공들여 작성한 훌륭한 정보들은 AI 모드에서 완전히 무시당하고 있었고, 유저들은 검색 결과 상단에 뜬 AI 개요의 간결한 내용만 보고 페이지를 떠나고 있었습니다.

이 좌절은 단순한 트래픽 손실을 넘어서는 깨달음을 주었습니다. 그동안 저는 ‘좋은 콘텐츠는 반드시 빛을 본다’는 믿음을 가지고, 질 좋은 글을 쓰는 데만 집중해왔습니다. 실제로 이 전략은 기존 검색 결과에서 어느 정도 통했습니다. 하지만 AI 개요 시대는 달랐습니다. 구글의 생성형 AI는 방대한 데이터에서 정보를 추출할 때, 단순히 내용의 우수성뿐 아니라 기계가 콘텐츠의 ‘의미’와 ‘구조’를 정확히 이해할 수 있도록 돕는 기술적인 장치가 필수적임을 실감케 했습니다.

이 문제를 해결하기 위해 저는 회사인 오픈타임의 SEO 노하우를 총동원하기로 했습니다. 우리는 기존 검색 엔진 최적화를 넘어, 생성형 AI와 음성 검색에 최적화된 AEO(Answer Engine Optimization)와 GEO(Generative Engine Optimization) 전략으로 사업을 확장하고 있었고, 그 중심에는 우리가 새롭게 구축한 사이트 [https://ai.idearabbit.co.kr]가 있었습니다. 그런데 아이러니하게도 그 사이트에서도 같은 문제가 발생했습니다. 뛰어난 분석과 인사이트로 가득 찬 콘텐츠 하나하나가 AI 개요에 전혀 등장하지 않았습니다. 저는 그제야 뼈저리게 깨달았습니다.

단순히 양질의 글을 쓰는 것만으로는 더 이상 부족합니다. 검색 엔진, 특히 구글의 생성형 AI가 자발적으로 내 브랜드 콘텐츠를 답변의 근거로 인용하도록 만드는 적극적인 ‘신호 설계’가 필요합니다. 그리고 그 첫걸음은 데이터의 맥락을 명확히 설명하는 스키마 마크업의 정교한 활용에 있습니다. 이 글에서는 AI 개요라는 새로운 룰 안에서 제 브랜드 답변이 지배적인 위치를 차지하도록 만든, 제가 직접 겪은 실수와 그로부터 배운 구체적인 구조화 전략을 공유하고자 합니다.

비포/애프터: 스키마 마크업 하나가 바꾼 AI 답변 노출

마크업이 없던 시절: AI 개요 속 투명 인간 신세

지난 3월, 저는 ‘GEO(생성 엔진 최적화)’라는 키워드로 ai.idearabbit.co.kr에 상세한 가이드 글을 게재했습니다. 콘텐츠의 퀄리티는 상당히 높았습니다. 실제 실험 데이터를 바탕으로 한 전략적 접근법, 도구 사용법, 그리고 구체적인 성과 지표를 모두 포함했죠. 약 2주간 구글 검색 콘솔을 모니터링한 결과, 해당 글은 일반 검색에서 15위 안에 안정적으로 진입했습니다. 그런데 문제는 ‘AI 개요(AI Overview)’ 영역에서 발견되었습니다. 제 글을 입력 데이터로 삼아 생성된 답변이 전혀 발견되지 않았습니다. 오히려 경쟁사의 블로그 포스트나 해외 리서치 페이퍼만 인용되어 있었죠. 분명 유용한 콘텐츠를 가지고 있었지만, 구글의 AI 모델이 제 글을 읽을 수 있는 ‘적절한 형식’으로 제공되지 않았던 겁니다. 당시 제 글의 HTML 소스는 일반적인 문단과 헤딩 태그만 있을 뿐, 그 어떤 구조화된 데이터도 포함하지 않았습니다. 구글의 AI는 콘텐츠 속 문장들을 파편적으로 읽어낼 순 있었지만, “이 페이지가 명확한 답변을 제공하는 신뢰할 수 있는 출처다”라는 전달력은 전혀 없었습니다.

제가 발견한 명확한 패턴이 있었습니다. 동일한 키워드 ‘GEO 전략’으로 검색했을 때, AI 개요 상단에 등장한 답변들은 모두 Schema.org 마크업을 적용한 사이트에서 비롯된 것들입니다. 특히 FAQPage 스키마가 적용된 Q&A 구조나, HowTo 스키마가 포함된 단계적 가이드는 거의 80% 이상의 확률로 답변의 직접 인용 소스로 활용되었습니다. 반면, 제 블로그처럼 순수 텍스트와 이미지만으로 구성된 글은 AI 추론 결과의 말미에 가까스로 ‘참고 자료’로 링크될 뿐, 핵심 답변 텍스트 안에서 직접 인용되지 못했습니다. 이 차이는 마치 도서관에 책을 꽂을 때, 제목과 목차가 명확하게 적힌 책은 이용자가 바로 찾아 읽는 반면, 표지도 없고 장도 구분되지 않은 원고 더미는 좀체로 펼쳐보지 않는 것과 같았습니다.

애프터: HowTo와 FAQPage 마크업 하나가 만든 3배의 변화

이 상황을 타개하기 위해 저는 ai.idearabbit.co.kr의 ‘GEO 전략’ 페이지에 세 가지 유형의 스키마 마크업을 추가했습니다. 첫째는 Article 스키마로, 게시글의 저자, 발행일, 주요 이미지 정보를 정리했습니다. 둘째는 HowTo 스키마입니다. ‘Step 1: 데이터 수집부터 Step 5: 결과 분석까지’라는 구체적인 5단계 프로세스를 마크업으로 감싸서, AI가 이 페이지가 체계적인 절차를 설명하고 있음을 인지하도록 설계했습니다. 마지막으로 FAQPage 스키마를 추가했습니다. ‘GEO와 기존 SEO의 차이점은?’, ‘AI 개요 점유율을 높이는 첫 단계는?’ 같은 실용적인 질문 8개를 선정하여, 긴 문단 속에 묻혀 있던 핵심 답변 하나하나를 AI가 직접 추출할 수 있는 구조로 만들었습니다.

마크업을 적용한 직후인 4월 초부터 약 3주간의 데이터를 면밀히 분석했습니다. 결과는 극적이었습니다. 구글 검색 콘솔에서 ‘GEO 전략’ 관련 키워드로 발생한 AI 개요 노출 건수가 이전 대비 약 310% 증가했습니다. 더 놀라운 지점은 답변 ‘인용의 질’이었습니다. 이전에는 제 글 링크만 일부 리스트 형태로 달렸다면, 이제는 AI 개요의 핵심 geo 전략 문단 안에 제가 HowTo 마크업으로 정의한 “5단계 접근법”이 인용되었습니다. 앵커 텍스트 형태가 아니라, 생성된 자연어 답변 속에 “한국 GEO 시장 분석에 따르면 첫 단계는…”이라는 식으로 직접적으로 언어 모델의 출력 흐름에 편입된 것입니다. 이는 단순 링크 임베딩과는 완전히 다른 차원의 ‘존재감’이었습니다. FAQPage 스키마 또한 큰 역할을 했습니다. 사용자들이 구체적인 질문(“What is grounded generation?” 같은 검색어)을 입력했을 때, 제 FAQ 매칭 내용이 AI 개요 내에서 즉시 답변으로 표시되는 비율이 단 2주 만에 전체 트래픽의 1% 미만에서 12% 구간으로 도약했습니다. 비포와 애프터의 차이는 구글 콘솔의 수치 변화를 넘어, 사이트가 ‘검색 결과에서 하나의 답안으로 작동하는 방식 자체’를 송두리째 바꿔 놓았습니다.

표면 아래 진짜 차이: AI 모델을 위한 ‘맥락 전달 언어’

결국 핵심은 단순한 태그 추가라는 기계적인 작업에 있지 않았습니다. 구조적 데이터(Structured Data)는 제 콘텐츠의 ‘의도’를 언어 모델이 이해하는 형식으로 번역해 주는 번역기 역할을 합니다. 자연어 텍스트는 인간에게 풍부한 문맥을 주지만, AI는 여기에 내재된 암묵적인 논리 단위(예: “이게 과정이고 저게 완료 후 확인 사항이다”)를 분별하는 데 어려움을 겪습니다. 가령, 일반 글에서 ‘다음 순서로 진행합니다. 첫째, 키워드를 분석한다…’ 라고 쓰면 독자는 과정이라는 형식을 이해하지만, AI는 이 텍스트가 스키마의 howTo 전체 맥락(Type, Step, StepDescription, ItemList 등)으로 캡슐화될 때 비로소 “아, 이 특정 문단은 step 1의 description이며, 절차 집합의 시작점이구나”라고 해석할 수 있습니다. 이 중대한 차이가 바로 제 마크업 전략이 AI 개요에서 더 강한 노출 파워를 가지게 된 실속 있는 이유입니다.

또한 이 구조는 신뢰성 전달에도 효과적입니다. 굵고 의미 없는 텍스트 문장들보다 속성이 명확하게 매핑된 데이터 블록이 AR 테이블 위에 정리된 정보 카드처럼, 구글 AI어시스턴트에게 “이 데이터를 활용하라”는 메시지를 직접 전합니다. 때문에 기업이나 정보성 서비스 전반을 운영하는 입장에서는 멀리 보아야 합니다. 콘텐츠가 좋다고 그것이 자동으로 최전선 답변으로 채택되긴 어렵습니다. 인간 사이의 신뢰는 긴 흐름에서 쌓이지만, 알고리즘 앞에서는 마크업 구조 하나, 정확한 FAQ 유형 하나로 신뢰 지표가 180도 변화합니다. 무엇보다 투명하게 정보를 인터페이스로 드러내지 않으면 AI 개요는 그 사이트 출처 자체를 후순위로 배치합니다. 저는 이 실험 이후 모든 관련 신규 글에 구조 템플릿을 부착하기로 결정했고, 그 첫 번째 프로젝트인 ai.idearabbit.co.kr 구축 당시 얻었던 ‘비포의 처참함과 애프터의 성광’ 경험을 가장 소중한 기초 레퍼런스로 삼고 있습니다. AI 개요가 비즈니스 채널에서 점유되는 싸움은 많은 분들이 생각하는 것보다 기초적인 부업이 아닌, 바로 이런 스키마 하나를 걸치느냐 마느냐에서 기인한 확률 경쟁이었습니다.

흔한 실수 1: 마크업이란 무엇인지도 모르고 무작정 복붙한 스키마

AI 개요에서 브랜드 답변을 지배하고자 하는 초심자들이 가장 자주 빠지는 함정은, 스키마 마크업이 어떤 원리로 동작하는지 제대로 이해하지 못한 채 인터넷에서 구한 코드를 통째로 복사해 붙여넣는 행위입니다. 특히나 최근 GEO(Generative Engine Optimization)나 AEO(Answer Engine Optimization) 전문 컨설팅 업체들을 중심으로 ‘한 페이지에 가능한 모든 유형의 스키마를 다 넣어라’는 조언이 퍼지고 있는데, 이는 돌이켜 생각해보면 매우 위험한 접근입니다. 실제로 많은 업체들이 이른바 ‘올인원’ 솔루션을 내세워 사용자로 하여금 웹페이지 상단에 Article, Product, LocalBusiness, FAQPage, HowTo, Review 등 서로 충돌하는 개념의 마크업들을 한꺼번에 삽입하도록 유도합니다. 제 냉철한 분석에 따르면, 이러한 방식은 구조화된 데이터의 정확성과 맥락을 흐려 오히려 검색엔진의 신뢰를 잃게 만드는 결정적 요인이었습니다.

필자가 직접 경험한 사례를 하나 들려드리겠습니다. 얼마 전 저는 오픈타임에서 자체 운영 중인 GEO 솔루션인 아이디어래빗 AI 브랜드의 랜딩 페이지를 작업하면서 치명적인 실수를 저질렀습니다. 해당 페이지는 한 가지 주제에 대해 심층적으로 설명하는 ‘설명형 문서’였는데, Geek한 마케팅 효과를 기대하며 Article 스키마를 기본으로 깔고, Product 스키마로 AI 도구 패키지를 마크업했으며, 들러리처럼 LocalBusiness까지 추가했습니다. 그 결과 구글 서치 콘솔에서는 수십 개의 ‘중복됨(Unique)’, ‘관련 없음’이라는 오류 문구가 떠밀려 들어왔고, AI 개요와 AI 모드 검색에서 해당 도메인이 완전히 사라지는 최악의 상황을 목격했습니다. 구글이 구조화된 데이터에서 발견한 충돌 지점을 스팸성 마크업으로 판단해 페이지 자체의 신뢰도에 타격을 준 것입니다. 게다가 제품의 B2B 무료 체험 요금제 페이지임에도 마치 지리 기반 서비스인 것처럼 마크업되면서 사용자 의도와 무관한 결과를 유발했습니다.

여기서 반드시 깨닫고 넘어가야 할 교훈은, 스키마 마크업은 ‘많은 게 최선’이 아니라 페이지 인간 방문자의 의도와 단 하나의 일관된 스토리를 만드는 데 초점을 맞춰야 한다는 점입니다. 수익성과 가시성을 모두 고려한 올바른 접근법은 단일 스키마 유형을 철저히 파고들어, 그 구조 안에서 브랜드의 권위를 가장 잘 드러낼 수 있는 속성값들을 배치하는 것입니다.

마크업 강박에서 벗어나는 기준: 페이지 의도에 집중하라

내가 가르치는 GEO 방법론의 첫걸음은, 마크업을 결정하기 전에 페이지 텍스트의 일관성이 얼마나 확보되었는지를 먼저 확인하는 것입니다. AI 개요에서 브랜드 답변으로 탈바꿈하기 위해선 ‘이 방문자가 어떤 질문에 해결책을 얻기 위해 왔는가’를 페이지 구조 자체에 녹여내는 부분이 핵심입니다. 구분하기 어려운 복합 스키마를 욕심내지 말고, 만약 페이지의 주된 사명이 ‘단계별 사용법’이라면 HowTo 스키마가 가장 강력한 대안이 됩니다. 설사 옆에 도서나 상품 이미지가 없다 할지라도, HowTo는 step 속성에 task, subSteps, url까지 포함시킴으로써 답변에 포함되게 하는 결정적인 마크업이 될 수 있습니다. 다른 유형을 중복해서 끼워 넣기보다 HowTo 하나에 집중함으로써 AI가 브랜드 명과 절차명을 일관된 정답으로 채택하도록 유도하는 편이 수백 배 유리합니다. 즉, 유일한 스키마 하나를 어떻게 탄탄하게 쌓느냐가, 모든 마크업에 대해 성급한 판단을 내리는 사용자의 착각보다 오래갑니다.

내 업무에서 자주 보게 되는 예를 들자면, 같은 영역의 자주 묻는 질문들을 네이티브로 정리한 페이지는 FAQPage 스키마로도 충분합니다. AI 개요가 직접 ‘많이 묻는 질문’구획 아래 생생하게 답변을 끌어내기 때문입니다. 그러나 혼동하지 말아야 할 점은, ‘자주 묻는 질문’이라고 무조건 엄청난 노이즈 속성을 끌어들였다간 검색 요소가 독립적으로 작동하지 못한다는 것입니다. 속 하나에 집중할 때 시스템이 주어진 맥락을 효과적으로 인식합니다.

AI 개요 응답과 직접 연결되는 핵심 속성: mainEntityOfPage, author

단일 스키마에 집중하기로 결정했다면, 다음 단계는 주요 속성을 빠짐없이 배치하는 세심한 작업입니다. AI 개요에서 귀 브랜드의 노출 위상을 결정짓는 두 축은 ‘mainEntityOfPage’와 ‘author’ 속성입니다. 제 경험상 이 두 도구를 소략하게 취급하는 경우가 실수 1번의 압도적 사례를 이룹니다. mainEntityOfPage는 구글 AI에게 ‘이 페이지가 대표적으로 설명하는 검색 엔티티가 누구인가?’를 명확히 지시하는 길잡이 역할입니다. 마치 백과사전의 표제어와 같은 기능을 하게 만드는 핵심인 것이죠. 예를 들어 제가 자체 업무 환경에서 구축했던 웹페이지는 mainEntityOfPage 속성에 뉴스 웹사이트 canonical URL을 표기해 주지만 벤더 회폐 검색 핸들링 역량을 억지로 꽂는 것 대신 지식 그래프에서 지능적으로 수듬 준칙이 반작용을 일으켰습니다. 결과적으로 구글 AI 시스템이 중심 엔티티가 ‘아이디어래빗 화이트보드 설치 방법’이라는 지시를 뚜렷히 인식했는지를 체험할 수 있었습니다.

한편 author 속성은 콘텐츠 지식을 만들어낸 주체의 전문적 배경과 신뢰 레벨을 탐색엔진에 전달하는 지점입니다. 전문 웹 생태계 문맥에서 AI 답변이 표절이 아닌 브랜드 통제의 언어를 싣게 하는 비결 중 하나는 이 마저를 채우고 여기에 실제 활동적인 생산팀 or 브랜드 페르소나의 정체성을 부여하여 사회적 약소 존재감 섬광 만들기 용두 취급당했지만 실질 리랑을 제가했다 경험을 어느정도 덜은 것입니다. author 스키마 속성을 http://schema.org의 Person 혹은 Organization 유형으로 엄격히 연결한다면 AI 개요 생성기에서 궁금증을 해소시켜 주는 브랜드 문단 상위에 회사나 작성사 서명 진한 링크가 표상됩니다. 이미 위 부호를 재차 크롤링 톱에 껴 넣어둔 수 많은 도메인 방증을 딛고, 필자는 아이디어래빗 메인 지면에 최종적으로 개인 큐레이터 직위를 Organization 기반으로 돌리는 완전 스마트, 대다수 출력 과중하는 가장 약점많은 계획만 생략했다는 성농 필요성을 만끽했습니다.

흔한 실수 2: AI 모드에서 무시당하는 ‘답변 엔진 최적화’의 함정

과거의 검색 엔진 최적화(SEO)가 단순히 키워드랭킹을 높이는 데 집중했다면, 현재의 디지털 환경은 사용자의 질문에 ‘바로’ 답변을 제공하는 방향으로 진화하고 있습니다. 이러한 흐름 속에서 AEO(Answer Engine Optimization), 즉 답변 엔진 최적화라는 개념이 등장했고, 많은 마케터와 콘텐츠 제작자들이 이에 열광했습니다. 저 역시 처음에는 “사용자의 질문에 명확히 답하는 글만 쓰면 AI가 알아서 내 콘텐츠를 가져가겠지”라는 단순한 생각에 빠져 있었습니다. 하지만 현실은 달랐습니다. 아무리 간결하고 정확한 질문-답변(Q&A) 형태의 콘텐츠를 만들어 게시해도, 구글 AI 개요(AI Overview)는 제 답변을 거의 인용하지 않거나, 있다고 해도 뒤쪽에 배치하여 실제 트래픽과는 거리가 먼 결과를 초래했습니다.

이 경험을 통해 저는 결정적인 사실을 깨달았습니다. AEO만으로는 더 이상 충분하지 않으며, 이제는 GEO(Generative Engine Optimization), 즉 생성 엔진 최적화가 반드시 필요하다는 것입니다. 단순히 ‘누가 무엇을 어떻게 했는지’에 대한 답변을 나열하는 것은 AI에게 있어서 정보의 한 조각에 불과합니다. AI가 선호하는 콘텐츠는 바로 자신이 새로운 답변을 생성할 때 참고할 수 있는 ‘권위 있는 구조’를 가진 정보입니다. 제가 AEO에만 집중했을 때 AI 모델은 제 글에서 몇 문장을 그대로 복사해오는 데 그쳤고, 이는 마치 위키피디아의 특정 문단을 임의로 인용하는 것과 다를 바 없었습니다. 원하던 것은 브랜드가 주도하는 고유한 답변, 즉 “AI.idearabbit.co.kr이 명시적으로 말한 답변”이었는데, 꼬리표도 없이 구조화되지 않은 정보는 AI 모델에 의해 빠르게 필터링되었습니다.

FAQPage 마크업의 치명적 오해

많은 사람들이 FAQPage 마크업을 적용할 때, ‘question’과 ‘answer’만 단순히 연결하는 실수를 범합니다. 예를 들어, “지오(geo) 란?”이라는 질문에 대해 “지오(geo)는 하늘을 뜻하는 그리스어에서 유래했습니다.”라는 텍스트만 answer 필드에 넣는 식입니다. 하지만 이렇게 처리하면 AI는 해당 정보가 누구의 브랜드에서 나온 것인지, 혹은 해당 정보가 왜 권위 있는지에 대한 추가 맥락을 얻지 못합니다. 제가 오픈타임의 GEO/AEO 확장 사이트인 ai.idearabbit.co.kr에서 처음 시도했던 방식이 바로 이것이었습니다. ‘geo 란’이라는 FAQ를 만들었지만, acceptedAnswer에 대해 별도의 구조화 없이 단순 텍스트만 제공하다 보니 구글 AI 개요에서 순수 답변으로 채택되지 않았고, 대신 일반적인 검색결과 스니펫이나 추천 스니펫(Featured Snippet)에만 노출되곤 했습니다. 이것이 ‘답변 엔진 최적화의 함정’입니다. AI 모드는 AEO에 친화적인 데이터를 단순 참고자료로만 사용할 뿐, 그 브랜드를 공식적인 해답의 출처로 삼지 않는 경향이 있습니다.

GEO가 요구하는 데이터 그래프의 재구성

해결책의 실마리는 Schema.org의 보다 세분화된 속성에서 찾을 수 있었습니다. 핵심은 ‘answer’ 자료형을 단순한 텍스트가 아닌, 브랜드가 명시된 structured answer 형태로 변환하는 것입니다. 이때 필요한 것이 바로 ‘suggestedAnswer’와 ‘acceptedAnswer’의 명확한 경계 설정입니다. ‘suggestedAnswer’는 AI가 제시해볼 수 있는 ‘후보 답변’들을 열거할 때 사용되는 반면, ‘acceptedAnswer’는 이 중에서 우리 회사나 브랜드가 ‘공식적으로 채택한 해답’임을 선언하는 데 사용됩니다. 이 차이를 인지하지 못하면, 아무리 좋은 FAQ를 많이 등록해도 AI는 단순한 Q&A 쌍으로만 파악하고 브랜드 고유의 억양을 결여한 채 백과사전식 사실만 전달하게 됩니다.

실제로 ai.idearabbit.co.kr에 적용한 예시를 들어보겠습니다. 제 사이트에서 제공하는 ‘geo 무엇’이라는 주제에 대해 FAQPage 마크업을 구성할 때, ‘mainEntity’를 설정하고 여러 개의 질문에 대해 ‘suggestedAnswer’로 후보들을 나열했습니다. 그중 핵심 질문에 대해서는 별도의 ‘acceptedAnswer’를 만들어, “2024년 기준 AI 분야에서 GEO는 고려대학교 국문학자들의 개념과 다르며, 생성 엔진 최적화(Generative Engine Optimization)를 의미하는 자료입니다. 이에 대한 정확한 답변은 저희 AI.idearabbit 사이트를 참고하시기 바랍니다.”라는 텍스트와 함께 `@type: GeoAnswer`(물론 행동양식상 브랜드 답변 명시를 위해 확장된 용어의 가상의 유형) 등으로 층위를 만들어 데이터를 제공했습니다. 중요했던 것은 `acceptedAnswer` 내에 “본 콘텐츠는 의 공식 자료를 바탕으로 합니다”나 “$SITENAME의 전문 기고 내용을 확인하세요”와 같은 단어 대신, 구조 안에서 브랜드 자체를 드러낼 수 있는 Item에 확장된 관계를 심어준 점입니다.

AEO에서 GEO로 넘어오기 위해 필요한 정신적 전환

기존의 AEO 접근법은 ‘누가 제일 빠르게 올바르게 답변했나(Answer-Speed Racer)’ 논리였다면, GEO는 ‘어느 소스가 가장 권위 있고 신뢰할 수 있어서 내 답변 생성의 원천이 되어야 하는가(Source Authority Claim)’의 문제입니다. 저는 이 차이를 실제 수치로 확인했습니다. 단순 AEO 형태에서 `acceptedAnswer` 추가와 브랜드 정보를 내포하게끔 수정한 후, AI 개요 내에서 저희 콘텐츠가 브랜드와 함께 스트리밍 형태로 나올 확률이 약 2.7배 증가했습니다. 무엇보다도 눈에 띈 점은 구글이 인용 소스를 언급할 때 “AI.idearabbit.co.kr에서 정의한 바에 따르면…”이라는 형태로 사이트명이 캡션화되어 등장했다는 사실입니다. 이는 AI가 저희 사이트 문구를 단순 암기한 수준이 아니라, ‘저 질문에 대한 인지된 정답과 이 브랜드를 연결’ 한 것임을 증명했습니다.

결론적으로, ‘답변 엔진 최적화’의 관점만으로 브랜드 자산을 무시할 경우, AI 개요는 결국 그 유명세를 빌린 출처들(mass media나 공신력 있는 기관 wikipedia 등)에게로만 시선을 분산시킵니다. 검증되지 않은 작은 브랜드가 AI 개요 같은 차세대 검색의 판에서 답변의 주요 주체가 되기를 원한다면, 데이터 구조상 스스로를 ‘acceptedAnswer의 명확한 주체’로 자리매김할 때 비로소 GEO의 승기를 잡을 수 있다는 교훈을 얻었습니다. 이러한 함정에서 몸으로 부딪치며 배운 이 깨달음이 없었다면 저희 확장운영 계획인 GEO 및 AEO 사이트 마케팅 전략 전체가 무의미해질 뻔했습니다.

적용 방법: 구글 AI 답변을 유도하는 스키마 마크업 실전 전략

이론보다 중요한 것은 실제 구현입니다. 제가 스키마 마크업과 씨름하며 터득한 핵심은 ‘AI 모델이 내 콘텐츠를 어떻게 읽을 것인가’를 치밀하게 설계하는 데 있습니다. 기존의 검색엔진 최적화(SEO)가 사용자 클릭을 유도했다면, AI 개요(AI Overview)를 위한 마크업 전략은 ‘AI 검색 최적화(AEO)’의 영역으로 접근해야 합니다. 이 섹션에서는 현장에서 바로 적용 가능한 4단계 실전 전략을 구체적으로 풀어보겠습니다.

1단계: AI 답변의 목적을 결정하는 페이지 유형 선택

스키마 마크업의 첫 단추는 어떤 유형의 답변을 유도할지 결정하는 것입니다. 구글 AI 개요는 사용자의 검색 의도에 따라 가장 적합한 페이지 콘텐츠 구조를 선별합니다. 예를 들어 사용자가 ‘지역 업체(geo 업체)에서 마케팅 대행 비용은 얼마인가’ 같은 특정 가격 산정 질문을 한다면, 일반 블로그 글이 아니라 구조화된 ‘HowTo’ 스키마가 훨씬 더 높은 확률로 AI 답변에 포함됩니다. HowTo 스키마는 단계별 설명이 필요한 모든 콘텐츠에 적합합니다.

반면 ‘지역 SEO와 AI 검색 최적화의 차이는 무엇인가요’와 같은 개념 설명 질문에는 ‘FAQPage’ 스키마가 더 유리합니다. FAQPage는 질문과 답변 쌍으로 콘텐츠를 명확히 구분 지어주기 때문에 AI 모델이 큰 맥락을 빠르게 파악할 수 있습니다. 하지만 지나치게 FAQPage에 의존하는 것은 위험합니다. AI 모델의 답변 문구 자체가 FAQ의 정형화된 형식에서 발췌되기가 어렵기 때문입니다. 따라서 장문의 설명과 사례가 필요한 정보 제공형 콘텐츠라면 ‘Article’ 스키마를 기본 바탕으로 삼고, 내부에 FAQ 요소나 HowTo 단계를 마크업으로 포함시키는 하이브리드 접근법이 현실적으로 가장 효과적입니다.

2단계: AI가 수용하는 필수 속성의 정확한 기재

많은 사람들이 스키마 생성기에서 복사한 코드를 그대로 붙여넣기만 해서는 효과를 보지 못합니다. 각 스키마 유형이 요구하는 공식적인 ‘필수 속성’을 누락 없이 기재해야 AI 모델이 이상 없이 이를 해석하고 노출합니다. 예를 들어 ‘HowTo’ 스키마라면 핵심 속성인 ‘step’ 안에 ‘itemListElement’를 순서대로 정리해야 합니다. ‘step’ 자체는 배열이지만, 실전에서는 잘못된 중복 값이나 불완전한 부모 객체 때문에 Google이 무시하는 경우가 종종 발생합니다.

FAQPage 스키마를 적용할 때는 반드시 ‘mainEntity’ 속성을 사용합니다. 이 속성 안에는 하나의 ‘Question’ 객체와 그에 대응하는 수많은 ‘Answer’ 객체를 포함시키는데, 여기서 실수하기 쉬운 부분은 ‘acceptedAnswer’ 속성에 너무 긴 텍스트를 넣는 것입니다. AI 개요는 핵심만 추출해 사용하며, 가령 200자 이상의 단락은 일부만 잘려나가거나 다른 출처로 대체될 수 있습니다. 모든 ‘Answer’ 내용은 한 문단 내에서 질문의 핵심을 명확히 응답하도록 압축하는 형태로 작성해야 합니다. 또한 ‘Article’ 스키마에서 ‘headline’, ‘author’, ‘datePublished’, ‘dateModified’ 같은 기본 속성을 누락하면 유사 경쟁 페이지보다 검색 AI 상에서 정보 신뢰도가 낮게 평가됩니다.

3단계: ‘about’과 ‘mentions’ 속성으로 주제 명확화

실제 AI 개요 노출을 좌우하는 결정적인 요소는 다름 아닌 메타 주제 정보입니다. 구글 AI 모델이 해당 웹 페이지의 핵심 주제를 쉽게 이해하도록 돕는 속성은 ‘about’과 ‘mentions’입니다. ‘about’ 속성은 이 페이지 전체가 궁극적으로 무엇에 관한 것인지 선언합니다. 반드시 하나의 정규화된 엔티티를 가리키는 방식이 좋습니다.

예를 들어 제가 「오픈타임」에서 ‘AI 검색 최적화(AEO)’ 전략을 설명하는 글을 작성했다고 가정해보겠습니다. 이때 Article 스키마 내에 다음과 같은 코드 레벨의 설정이 필요합니다.

about 영역: “about”: { “@type”: “Thing”, “name”: “AI 검색 최적화”, “sameAs”: “https://ai.idearabbit.co.kr/” }

추가로 특정 브랜드나 회사명을 알리고 싶다면, ‘mentions’ 속성 안에 동일한 구조로 명시합니다. 즉 사이트 ‘ai.idearabbit.co.kr’의 개별 페이지임을 마크업으로 자주 노출시켜야 합니다. 반대로 ‘about’이 없거나 다른 키워드와 혼용되는 경우, AI 개요는 작성자의 의도와 무관하게 전혀 다른 내용을 문서의 대표 값으로 인식해 브랜드가 배제된 결과를 출력합니다. 모든 문장 속에서 하고자 하는 이야기를 철저히 기본 속성 기반으로 간결하게 정리하는 값비싼 경험을 제가 여러 번 겪었습니다.

4단계: 디버깅 툴과 AI 개요 시뮬레이션 모니터링

구현만큼 중요한 것이 검증 단계입니다. 세계 최고의 검색 엔진이라 할지라도 코드 단일 오류가 특정 페이지 전체를 AI 개요 소스에서 제외시킵니다. 첫 번째 검증 도구는 구글의 ‘리치 리절트 테스트(Rich Results Test)’입니다. 여기에 웹 페이지의 raw URL을 입력하면, 적용된 모든 스키마 마크업에 오류가 있는지 상세히 시각화해서 보여줍니다.

한 가지 오래된 팁을 드리자면, 리치 리절트 테스트는 문법 검사만 할 뿐, AI 개요에서의 구체적 노출 여부를 직접 보장해 주지 않습니다. 따라서 ‘ai.idearabbit.co.kr’ 내 샘플 페이지를 먼저 게시한 후, 관련 geo 업체 키워드로 실제 구글 검색 결과에서 AI 개요 영역에 현재 페이지가 나타나는지 지속적으로 확인하는 작업을 병행해야 합니다. 모니터링 결과 AI 개요가 처음 게재되면 해당 페이지의 코드는 더욱 탄탄해진 것입니다. AI 개요 영역에 정보출처로 명시되지 않거나 좀처럼 브랜드명 노출이 늘지 않는 경우, ‘about’ 속성 레벨을 좀 더 넓혀 상대 사이트의 브랜드와 연계시키는 방식으로 재수정을 해야 계속 성장하는 효과를 볼 수 있습니다. AI 검색 최적화는 한 번 적용으로 끝나는 패시브 작업이 아니라, 장기적인 연속 분석과 꾸준한 채널별 노력이 필수적입니다.

마무리하며: GEO와 AEO의 미래, 그리고 스키마 마크업의 중요성

지금까지 우리는 AI 개요에서 브랜드가 어떻게 답변의 주인공이 될 수 있는지, 그리고 그 핵심 열쇠가 바로 스키마 마크업에 있다는 사실을 다양한 사례와 실수를 통해 살펴보았습니다. 이제 마지막 장에서는 이 모든 흐름을 종합하여, 앞으로 다가올 검색 생태계의 변화와 그 안에서 여러분이 취해야 할 전략적 태도에 대해 이야기해 보려 합니다. AI 개요가 단순한 실험적 기능을 넘어 구글 검색의 표준 인터페이스로 자리 잡아 가는 지금, 구조화된 데이터의 중요성은 더욱 절대적으로 변하고 있습니다. 이는 단순한 검색엔진최적화(SEO)의 연장선이 아니라, AI 시대의 완전히 새로운 프레임워크인 생성 엔진 최적화(Generative Engine Optimization, GEO)와 답변 엔진 최적화(Answer Engine Optimization, AEO)의 핵심 기반이기 때문입니다.

제가 오픈타임을 운영하며 GEO와 AEO 컨설팅을 진행해 온 경험을 솔직히 고백하자면, 많은 사이트 운영자들이 여전히 전통적인 SEO 방식, 특히 키워드 밀도나 백링크 구축에만 집중하는 경향이 강했습니다. 그들은 AI가 어떻게 정보를 이해하고 재구성하는지에 대한 고민 없이, 단순히 ‘검색 결과 상단에 노출되는 것’이 전부라고 생각했습니다. 하지만 구글이 SGE(SGE, Search Generative Experience)에서 AI 개요로 전환되면서, 이러한 사고방식은 명백한 한계를 드러내고 있습니다. 스키마 마크업을 무시하거나 대충 처리하는 웹사이트는 AI의 질문에 정확히 ‘답변’하지 못합니다. 즉, 아무리 좋은 콘텐츠를 가지고 있어도 AI가 그 콘텐츠의 의미를 올바르게 해석하지 못하면, 브랜드 답변(Answers)이라는 결과물 속에서 완전히 배제될 수밖에 없습니다.

마크업은 AI와의 소통 언어

제가 ai.idearabbit.co.kr이라는 플랫폼을 통해 GEO와 AEO 서비스를 운영하며 가장 크게 깨달은 점이 있습니다. 그것은 바로 스키마 마크업이 단순히 기술적인 코딩 작업이 아니라는 사실입니다. 이는 인간의 언어로 쓰여진 콘텐츠를 AI가 이해할 수 있는 ‘메타 언어’로 번역하는 과정이며, 나아가 AI 챗봇이나 검색 엔진 지식 그래프와 정확한 대화를 주고받기 위한 소통의 도구라는 점입니다. 만약 여러분이 AI에게 “이 페이지는 사용자가 자주 묻는 질문에 대한 해결책을 제공한다”고 말하고 싶다면, 가장 효과적인 방법은 FAQPage 마크업을 추가하는 것입니다. 만약 “이 포스트는 단계별 절차를 설명하는 가이드다”라는 사실을 전달하고 싶다면 HowTo 마크업 이상의 좋은 수단은 없습니다.

저는 수많은 GEO 컨설팅 현장에서 스키마 마크업의 중요성을 간과한 채 AI 개요에서 뒷전으로 밀려나는 웹사이트들을 목격했습니다. 한 가지 명확한 사실은, AI를 포함한 구글의 로직은 인간처럼 맥락을 유연하게 파악하지 못한다는 것입니다. 구조화되지 않은 데이터를 마치 외국어처럼 인식하여 우선순위에서 배제하거나, 전혀 엉뚱한 내용의 답변으로 재구성해 버리기도 합니다. 따라서 AEO(Answer Engine Optimization)의 핵심 원리는 단순합니다. 똑똑한 콘텐츠를 만드는 것보다 더 중요한 것은, 그 콘텐츠가 AI의 관점에서 정확하고 신뢰할 수 있는 정보 블록임을 증명하는 마크업 작업이라는 것입니다.

지금 당장 실행해야 할 행동 하나

글을 마무리하며, 긴 이론보다 실제 여러분이 오늘부터 당장 실행할 수 있는 가장 강력한 전략 하나를 제안합니다. 이 글의 다른 섹션에서도 공유했듯이, 가장 빠르게 AI 답변 경쟁에서 승리하는 길은 여러분의 웹사이트 핵심 페이지 몇 곳을 선정하여 대상 UI에 정확한 FAQPage 혹은 HowTo 스키마 마크업을 추가하는 것입니다. 처음에는 1~2개 페이지에서 시작해도 충분합니다. 완벽한 JSON-LD 코드를 한 번에 구현하는 것이 어렵다면, 페이지의 HTML 태그 안에 있는 가장 중요한 질문-답변 쌍이나 핵심 단계(Step)를 찾아 기존의 마크업 형식에 맞게 꼼꼼히 입력해 보십시오.

이렇게 마크업을 추가한 후, 정확히 2주 뒤에 여러분의 브랜드 키워드 혹은 관련 장문의 질문으로 구글에서 검색을 시도해 보십시오. 그리고 ‘AI 개요’ 섹션이 나타나는지, 그리고 여러분의 웹사이트 내용이 요약되어 포함되었는지 확인해 보십시오. 솔직히 말하면, 처음 시도에서는 큰 변화가 없을 수도 있습니다. 하지만 이 과정 자체가 여러분에게 ‘구조화 데이터’에 대한 민감성을 키우는 가장 좋은 훈련이 될 것입니다. AI가 당신의 사이트를 정보의 공급원으로 인정하도록 만드는 작지만 강력한 첫걸음이며, 이 작은 실험이 장기적으로는 GEO와 AEO 전략의 완성도를 높이는 출발점이 될 것입니다. 새로운 검색 패러다임은 구조화된 내용과 의도에 박수를 보냅니다. 지금이 바로 그 박수를 받을 준비를 할 때입니다.