AI 검색은 순위가 아니라 인용할 이유를 본다

대상: 검색·콘텐츠를 운영하는 마케터  ·  형식: 1인칭 운영 회고  ·  2026-07-07

이미지: 무기는 서랍 안에 다 있었다. 밖으로 나간 건 0. 이 글은 그 갭을 GEO의 두 개념으로 채점한 기록이다.

코드 한 줄 못 만지고, 스프레드시트로 검색을 운영했다

나는 통신·렌탈 비교 서비스의 검색을 맡았다. SEO(검색엔진 최적화), 그리고 요즘 말로 GEO(생성엔진 최적화)와 AEO(답변엔진 최적화)까지. 직함은 마케터고, 무기는 스프레드시트 한 장이었다.

사이트 코드는 개발팀 소관이라 내가 직접 못 만진다. 나는 타이틀, 메타 설명, URL 구조, 구조화 데이터, 시드 키워드를 시트에서 설계해 넘긴다. 시트가 원본(SoT)이고, 사이트는 그걸 반영하는 대상이었다.

그럼 왜 에이치레프스 같은 SaaS 도구를 두고 직접 만들었나. 이 시장은 네이버가 검색의 70퍼센트다. 글로벌 SEO 도구는 네이버 실측을 거의 못 준다. 그래서 검색광고 API의 실측 클릭·전환을 1차 소스로 삼고, 파이썬으로 직접 긁어 시트에 적재하는 파이프라인을 짰다.

그렇게 6개월을 굴렸다. 시드 키워드 900여 개를 실측으로 추리고, 53개 페이지에 타이틀·메타를 붙이고, 노출 영역까지 크롤했지. 스스로는 "검색 기본기는 웬만큼 갖췄다"고 여겼다.

그런데 AI 검색이 판을 바꾸기 시작하면서, 내가 쌓은 것이 그 판에서도 유효한지 다시 묻게 됐다. 채점표가 필요했다.

시트가 원본, 사이트가 반영 대상. 이 구조가 뒤에서 문제가 된다. 시트에 썼다고 사이트에 뜬 게 아니었으니까.

GEO는 검색을 두 층으로 가른다: 델타 지식과 알파 지식

먼저 GEO를 풀어두자. 겁먹을 말이 아니다. 예전 검색엔진은 문서들을 순위로 나열했다. 링크 열 개를 주고 고르라는 방식이지. 반면 생성엔진(챗지피티·퍼플렉시티 같은 AI 검색)은 답을 하나로 합성하고, 그 근거로 쓸 출처 몇 개만 골라 인용한다.

차이가 크다. 순위 목록에선 10등이라도 페이지에 이름은 오른다. 그런데 AI의 합성 답변에선, 인용되지 못하면 존재하지 않는 것과 같다. 그래서 질문이 바뀐다. "어떻게 상위 노출되나"가 아니라, "AI가 왜 하필 나를 인용하나"로.

이 물음을 두 층으로 갈라 보면 내 운영이 선명하게 채점됐다. GEO 담론에서 빌려 온, 그리고 내 일에 대보려고 내가 붙인 렌즈다.

델타 지식은 이미 세상에 공개된 지식 위에 얹는 증분이다. 남들도 아는 사실을, 더 나은 타이틀·메타·구조화 데이터·최신 정보로 더 깔끔하게 정리한 것. 남이 쓴 교과서를 내가 더 잘 요약한 노트에 가깝다.

알파 지식은 세상에 아직 없는 독점·원본 정보다. 자사만 가진 실측 데이터, 직접 겪은 1차 경험. 남의 교과서가 아니라, 내가 직접 실험해서 얻은 원본 측정값이지. AI가 인용하려면 결국 어딘가의 원천이 있어야 하는데, 알파는 그 원천 자리를 노린다.

이게 근거 없는 구분은 아니다. GEO를 처음 정식화한 연구(Aggarwal 외, "GEO: Generative Engine Optimization")는 콘텐츠에 통계·인용·출처 같은 신호를 붙였을 때 생성엔진 노출이 최대 40퍼센트까지 올랐다고 보고한다. 다만 효과는 도메인마다 다르다고 못박았으니, 만능은 아니다. 핵심은 이거다. AI는 검증 가능한 원본을 좋아한다.

델타는 공개 지식을 더 잘 정리한 것, 알파는 세상에 없는 원본. AI는 인용할 원본, 즉 알파를 찾는다.

델타는 거의 다 채웠다, 시트 안에서는

델타부터 채점했다. 결과는 나쁘지 않았다. 오히려 꽤 촘촘했지.

53개 페이지 전체에 SEO 타이틀과 메타 설명을 붙였다. 그냥 붙인 게 아니라, 검색어를 형태소로 쪼개서 "KT 인터넷 가입", "KT 인터넷 티비", "KT 인터넷 사은품" 같은 여러 변형이 한 타이틀에 매칭되게 짰다. 메타 설명은 페이지마다 후킹 문구를 다르게 줘서, 완전 중복이 0이 되게 했고.

구조화 데이터도 준비했다. 개체(Entity)·스키마 타입·빵부스러기(Breadcrumb, 페이지 위치를 보여주는 이동 경로)를 53개 중 52개 페이지에 설계했다. 링크 미리보기용 OG 카피도 따로 썼지.

표로 보면 이렇다. 코드처럼 보여도 겁먹을 것 없다. 그냥 "설계는 시트에 다 있는데, 사이트에 실제로 뜬 건 절반뿐"이라는 얘기다.

여기서 발이 걸렸다. 시트 설계 레벨은 거의 완성인데, "시트에서 사이트로" 넘어가는 한 칸이 비어 있었다.

라이브 페이지의 HTML을 직접 확인해 보니 구조화 데이터가 한 개도 없었다. 생성 스크립트는 다 짜놨는데 사이트엔 배포가 안 된 거다. OG도 마찬가지였다. 내가 시트에 따로 쓴 OG 타이틀 대신, 사이트는 SEO 타이틀을 그대로 복사해 내보내고 있었다.

함정: 시트에 썼다고 사이트에 뜬 게 아니다. 설계(원본)와 배포(라이브)는 다른 공정이고, 그 사이엔 개발팀 반영이라는 별도 단계가 있다. 델타를 "다 했다"고 말하려면 시트가 아니라 라이브 HTML을 열어 봐야 한다.

추적기라고 믿었는데, 스냅샷 한 장이었다

델타의 라이브 갭을 확인하다가, 더 뜨끔한 걸 발견했다. 내가 "SERP 추적기"라 부르던 도구 말이다.

SERP는 검색 결과 화면이다. 내 키워드가 네이버에서 어느 영역에 몇 위로 뜨는지 크롤해서 시트에 기록하는 스크립트를 굴리고 있었다. 나는 이걸 매주 도는 "추적기"라고 생각했지.

그런데 코드를 열어 보니 추적기가 아니었다. 크롤한 HTML을 저장하는 파일명에 날짜가 없었다. 키워드마다 파일 한 개를 계속 덮어쓰는 구조였던 거다. 게다가 크롤 날짜가 코드에 "2026-05-28"로 하드코딩돼 있었고, 캐시를 우선 읽게 돼 있어서 다시 돌려도 5월 28일 것을 재사용했다. 자동 스케줄러엔 아예 등록도 안 돼 있었지.

정리하면 이렇다. 그건 추적기가 아니라, 5월 28일에 찍은 스냅샷 한 장을 매번 다시 보여주는 도구였다. 시계열이 없는데 추적이라 부른 셈이다.

추적기라면 세 가지가 있어야 한다. 코드로 보면 이런 차이다.

# 스냅샷(내가 갖고 있던 것): 덮어쓰기, 날짜 없음
save(f"data/raw/serp/{keyword}_mobile.html")   # 매번 같은 파일 덮어씀
CRAWL_DATE = "2026-05-28"                        # 날짜 하드코딩
fetch(keyword, use_cache=True)                   # 재실행해도 옛날 것 재사용

# 추적기(고친 뒤): 날짜 파티션 + 이력 append + 스케줄
save(f"data/raw/serp/{today}/{keyword}.html")   # 1) 날짜별 폴더에 보존
history.append(today, keyword, area, rank)       # 2) 이력을 계속 쌓음
# run_weekly.bat 를 작업 스케줄러에 등록          # 3) 주기 자동 실행

세 줄을 바꾸는 일이 아니라, 도구의 정체가 바뀌는 일이었다. 날짜 파티션·이력 append·자동 스케줄. 이 3종이 없으면 그건 추적기가 아니라 스냅샷이다.

고쳐서 시계열로 돌리자 바로 실측이 하나 나왔다. 자사 사이트의 검색 노출이 브랜드성 키워드 3개에서 6개로 늘어 있었던 거다. "인터넷 가입 현금지원", "인터넷 설치 현금" 같은 전환성 키워드에 2위로 새로 진입해 있었지. 스냅샷만 봤으면 영영 몰랐을 변화다.

날짜 파티션·이력·스케줄 3종이 없으면 추적기가 아니다. 시계열로 바꾸자 자사 웹영역 노출 3개에서 6개 진입이 실측으로 잡혔다.

무기는 다 있는데, 밖으로 나간 건 하나도 없었다

이제 알파를 채점할 차례였다. 그리고 여기서 진짜로 멈춰 섰다.

원천 데이터로만 보면, 나는 부자였다. 검색광고 API에서 뽑은 실측 클릭·전환이 86만 행. 6개월치 일별 검색량 시계열. 어떤 키워드가 어느 영역에 뜨는지 실측한 노출 데이터와 진입 난이도 분류. 키워드마다 날짜·영역·순위를 기록한 SERP 추적 이력까지.

이건 경쟁 비교 사이트가 쉽게 못 가지는 것들이다. 남의 교과서가 아니라 내가 직접 측정한 원본, 정확히 알파 지식의 정의에 들어맞았다.

그런데 이 무기들이 어디에 쓰였나. 전부 내부 타겟팅에만 쓰였다. 어떤 키워드를 살지, 어느 페이지에 무슨 타이틀을 붙일지 정하는 의사결정 재료. 딱 거기까지였다.

공개 콘텐츠로 나간 건 0이었다. 실측 검색량으로 만들 수 있는 3사 비교표의 실수치, 자주 묻는 질문(FAQ)의 실제 본문, 지역별 후기, 이런 알파 레버는 전부 미가동이거나 콘텐츠 담당자 핸드오프 대기 상태였지. SERP 이력 자체도 "올해 이 키워드 검색이 이렇게 움직였다" 같은 콘텐츠가 될 수 있는데, 표로만 남아 있었다.

이게 GEO 관점의 최대 갭이었다. 검색엔진 시대엔 이 알파를 내부 무기로만 써도 순위 경쟁에서 이겼다. 그런데 생성엔진은 인용할 원본을 밖에서 찾는다. 서랍 속 데이터는 AI에게 존재하지 않는 것과 같다.

여기서 정직해야 할 게 하나 있다. 사실 지금은 "알파가 없어서 AI가 우리를 인용 안 한다"를 증명할 수도 없다. 이 사이트는 출시 전이라 통째로 색인 차단(noindex) 상태거든. 검색 로봇뿐 아니라 GPTBot·PerplexityBot·ClaudeBot 같은 AI 크롤러도 다 막혀 있다.

그러니 이 채점은 "그래서 인용이 안 됐다"는 결과 보고가 아니다. 게이트가 열리는 순간 즉시 인용될 준비가 됐는지를 보는 거다. 델타든 알파든, 크롤 자격이 없으면 지금은 0점으로 수렴한다. 준비의 완성도를 재는 채점이지, 성과의 채점이 아니다.

알파 원천은 100퍼센트 확보(86만 행·6개월 시계열·SERP 이력), 공개 콘텐츠 반영은 0. 게다가 출시 전 게이트라 크롤 자격 자체가 아직 없다.

검색엔진은 기본기에 순위를 주고, AI는 인용할 이유를 원한다

여기까지 채점하고 나니 교훈이 한 문장으로 남았다. 검색엔진은 델타, 즉 잘 갖춘 기본기만으로도 순위를 준다. 그런데 생성엔진은 "왜 이 출처를 인용해야 하나"에 답을 요구하고, 그 답이 알파다.

가장 뼈아픈 깨달음은 이거였다. 실측 데이터를 쌓는 것과, 그것을 인용 가능한 콘텐츠로 공개하는 것은 완전히 다른 작업이다. 하나는 안으로 캐는 분석이고, 하나는 밖으로 내보내는 퍼블리싱이다. 나는 앞의 일을 6개월 했고, 뒤의 일은 시작도 안 했던 거지.

이건 흔한 착각의 사촌이다. 데이터가 있으니 콘텐츠도 있다고 여기는 것. 서술이 있다고 측정이 있는 게 아니듯, 측정이 있다고 공개 콘텐츠가 있는 게 아니다. 둘 사이엔 "누가 이걸 밖에 내놓느냐"는 별도의 노동이 통째로 빠져 있다.

그래서 알파를 콘텐츠로 내보내는 일이 GEO의 진짜 레버가 된다. 자사 실측 검색량으로 만든 비교표, 실제 데이터에 근거한 FAQ 답변, 원본 이력을 정리한 분석. 이건 남이 복제할 수 없어서, AI가 인용하려면 나를 거칠 수밖에 없는 원천이다.

같은 데이터라도 안으로 캐는 분석과 밖으로 내보내는 퍼블리싱은 다른 작업이다. 나는 6개월간 앞의 것만 했다.

오늘 내 검색 운영을 알파·델타로 채점해 보자

회고는 여기까지다. 이제 당신 일에 대보자. 아래를 순서대로 물으면, 검색 운영이 AI 검색에서 어디에 서 있는지 5분이면 채점된다.

그래도 하나만 챙긴다면, 이것이다.

검색엔진은 잘 쓴 문서에 순위를 준다. AI는 자기가 인용할 원본에만 이름을 남긴다.

근거·출처

• GEO 정의·생성엔진 가시성 최대 40퍼센트 향상 근거: Aggarwal 외, GEO: Generative Engine Optimization (arXiv:2311.09735)
• 생성엔진 최적화 개념 보조 정의: Generative engine optimization (Wikipedia)
• 86만 행·6개월 시계열·53/53·52/53·3에서 6 진입: 자사 검색 운영 6개월 실측 경험값(비공개 원본 데이터)

회사·서비스·경쟁사 실명은 "통신·렌탈 비교 서비스", "경쟁 비교 사이트"로 일반화했다. 수치는 자사 검색 운영에서 실제로 센 실측값이다. "델타 지식·알파 지식"은 GEO 담론을 내 운영에 적용하려고 붙인 렌즈이지, 업계에 확립된 공식 용어는 아니다.