ChatGPT나 퍼플렉시티에 질문을 던지면, 그 자리에서 웹을 통째로 뒤지는 게 아닙니다. 검색으로 후보 문서를 몇 개 건져 온 다음, 그 안에서 다시 몇 문장만 골라 답을 만듭니다. 이 두 번째 단계, 문서 안에서 문장을 고르는 과정이 실제로 어떻게 돌아가는지를 아는 사람은 많지 않습니다.
이 글은 그 과정을 설명합니다. AEO 팁 목록이 아니라, 왜 그 팁들이 효과가 있는지에 대한 이유입니다. 청킹, 임베딩, 코사인 유사도. 용어가 낯설어도 끝까지 읽으시면 지금까지 들으셨던 AEO 조언들이 왜 그런 형태였는지 한 번에 이해되실 겁니다.
30초 요약
- •AI는 문서 전체를 읽지 않습니다. 문서를 잘게 쪼갠 조각(청크) 단위로 다룹니다.
- •질문과 조각을 각각 숫자 벡터로 바꿔 거리를 잽니다. 이게 임베딩과 코사인 유사도입니다.
- •쪼개는 경계를 잘못 잡으면 좋은 문장도 통째로 버려집니다. 문단 구조가 곧 청크 경계입니다.
- •한 문단에 주제를 하나만 담아야 벡터가 흐려지지 않습니다.
- •결론을 먼저 쓰는 이유는 습관이 아니라 검색 특성 때문입니다.
AI는 사이트를 읽는 게 아니라 조각을 검색합니다
먼저 짚어야 할 오해가 있습니다. AI 검색 엔진이 질문을 받으면 관련 사이트에 접속해서 페이지를 처음부터 끝까지 읽는다고 생각하기 쉽습니다. 그렇지 않습니다.
실제로는 이런 순서로 돌아갑니다.
- 1.수집 크롤러가 웹의 문서를 미리 가져와 저장해 둡니다
- 2.분할 각 문서를 작은 조각으로 쪼갭니다. 보통 몇백 자에서 천 자 안팎입니다. 이걸 청크(chunk)라고 부릅니다
- 3.변환 조각마다 의미를 숫자 목록(벡터)으로 바꿔 저장해 둡니다. 이걸 임베딩(embedding)이라고 부릅니다
- 4.질문 시점 사용자의 질문도 같은 방식으로 벡터로 바꿉니다
- 5.검색 질문 벡터와 가장 가까운 조각 벡터들을 찾습니다. 이 거리가 코사인 유사도입니다
- 6.생성 찾아온 조각 몇 개를 근거로 언어모델이 답을 씁니다
당신 사이트가 인용되느냐 마느냐는, 5번 검색 단계에서 당신 문서의 어느 한 조각이 질문 벡터와 가까운 자리에 있었느냐로 갈립니다.
이 구조를 검색 증강 생성, 흔히 RAG라고 부릅니다. AI 검색 서비스 대부분이 이 방식을 씁니다. 여기서 중요한 건 4번과 5번입니다. AI는 당신의 홈페이지를 보고 판단하지 않습니다. 미리 쪼개져 벡터로 저장된 한 조각을 보고 판단합니다.
청크, 문서가 잘리는 자리
청크가 어디서 어디까지 잘리는지가 생각보다 중요합니다. 잘리는 위치에 따라 같은 문장도 살아남거나 버려집니다.
예를 들어 이런 문단이 있다고 하겠습니다.
저희는 프레이머로 웹사이트를 제작합니다. 프레이머는 노코드 툴이지만 실제 개발 지식이 필요한 작업이 많습니다. 그래서 초기 상담에서 예산과 일정을 먼저 확인합니다.
이 문단이 통째로 하나의 청크에 들어가면 괜찮습니다. 그런데 분할 지점이 중간에 걸리면, 앞부분과 뒷부분이 서로 다른 청크로 흩어집니다. 그러면 '초기 상담에서 예산과 일정을 먼저 확인합니다'라는 문장만 남고, 이게 무슨 서비스에 대한 이야기인지 맥락이 사라집니다.
맥락을 잃은 조각은 질문 벡터와 멀어집니다. 누가 무엇을 물어봐도 걸리지 않는 죽은 조각이 됩니다.
실무에서 이걸 어떻게 막는가
- •한 문단에 한 주제만 담습니다. 여러 주제가 섞인 긴 문단은 어디서 잘려도 절반은 맥락을 잃습니다
- •문단을 짧게 끊습니다. 3~5문장 단위가 안전합니다. 청크 크기가 보통 이 정도이기 때문입니다
- •소제목(h2, h3)을 자주 씁니다. 많은 분할 방식이 제목을 경계로 삼습니다. 소제목이 곧 청크 경계 후보입니다
- •핵심 문장은 문단 앞에 둡니다. 분할이 문단 중간에 걸려도 핵심은 앞쪽 청크에 남습니다
결론을 먼저 쓰라는 조언을 여러 번 들어보셨을 겁니다. 이게 그냥 좋은 글쓰기 습관이 아니라, 분할 구조 자체가 그렇게 요구하기 때문입니다.
벡터 거리, 비슷한 말이 아니라 같은 방향
임베딩을 쉽게 설명하면 이렇습니다. 모든 문장과 질문을 다차원 공간의 한 점으로 바꿉니다. 의미가 비슷한 문장끼리는 가까운 자리에, 의미가 다른 문장은 먼 자리에 놓입니다.
여기서 오해하기 쉬운 지점이 있습니다. 같은 단어를 많이 쓴다고 가까워지는 게 아닙니다. 오래된 검색 엔진의 키워드 매칭과는 다른 방식입니다. 임베딩은 단어가 아니라 의미의 방향을 봅니다.
그래서 이런 일이 생깁니다. "프레이머 유지보수 비용"이라는 질문과 "매달 정기적으로 사이트를 점검하고 관리하는 데 드는 금액"이라는 문장은 겹치는 단어가 하나도 없어도 벡터 공간에서는 가깝게 잡힙니다. 반대로 같은 단어 '유지보수'가 들어가도 완전히 다른 문맥(코드 유지보수, 인간관계 유지보수)이면 멀어집니다.
이게 실무에 주는 의미
같은 개념을 여러 표현으로 반복해서 담을 필요가 없습니다. 예전 SEO식으로 키워드를 억지로 욱여넣는 방식은 임베딩 기준에서는 별 효과가 없습니다. 대신 그 질문을 실제로 던질 법한 사람의 말투로 답을 적어두는 편이 유리합니다.
저희가 상담에서 실제로 받는 질문 문장을 그대로 제목이나 소제목에 쓰는 이유가 여기 있습니다. 질문과 가장 가까운 벡터는, 그 질문에 가장 가까운 언어로 쓰인 문장입니다.
검색되는 것과 인용되는 것은 다릅니다
여기까지는 5번 단계, 검색까지의 이야기입니다. 조각이 검색되었다고 반드시 인용되는 건 아닙니다. 6번 생성 단계에서 언어모델이 한 번 더 고릅니다.
이 단계에서 유리한 조각의 특징이 있습니다.
- •그 자체로 완결된 문장 앞뒤 맥락 없이 읽어도 뜻이 통해야 합니다. 언어모델은 조각 몇 개만 보고 쓰기 때문에, 완결되지 않은 문장은 이어붙이기 어렵습니다
- •명확한 사실이나 숫자 모호한 형용사보다 구체적인 수치나 절차가 답변에 그대로 옮겨지기 쉽습니다
- •질문과 형태가 비슷한 문장 질문이 "얼마나 걸리나요"라면, "제작 기간은 3주입니다"처럼 대칭되는 문장이 답으로 옮겨지기 좋습니다
- •출처가 분명한 문장 회사명이나 서비스명이 근처에 명시되어 있으면 언어모델이 그 출처를 답변에 붙이기 쉽습니다
검색은 후보를 넓게 뽑고, 생성은 그중에서 가장 인용하기 편한 조각을 씁니다. 두 관문을 모두 통과해야 인용됩니다.
이 조건을 실제로 어떻게 문장으로 옮기는지는 인용 조건 5가지 글에서 사례로 정리해두었습니다. 이 글은 그 조언들이 왜 통하는지의 배경입니다.
구조화 데이터가 하는 실제 역할
FAQ 스키마나 구조화 데이터를 넣으라는 조언도 자주 들으셨을 겁니다. 이것도 같은 원리로 설명됩니다.
구조화 데이터는 청크를 사람이 미리 나눠주는 것과 같습니다. 질문과 답이 명시적으로 쌍을 이루고 있으면, 분할 시스템이 애매하게 자르지 않고 그 쌍을 하나의 조각으로 다룰 가능성이 높아집니다. 맥락이 잘릴 위험이 애초에 줄어듭니다.
구조화 데이터를 넣어야 하는 이유를 자세히 다룬 글은 이쪽에 있습니다. 이 글에서 이어 보시면, 그 조언이 청킹 구조와 정확히 맞물린다는 걸 확인하실 수 있습니다.
자주 묻는 질문
모든 AI 검색이 이 방식을 쓰나요?
세부 구현은 서비스마다 다릅니다. 다만 큰 틀에서 검색으로 후보를 좁히고 언어모델이 답을 생성하는 구조는 ChatGPT의 웹 검색, 퍼플렉시티, 구글 AI 개요 모두 공통적으로 이 방식에 가깝습니다.
문단을 짧게 쓰면 SEO에는 불리하지 않나요?
불리하지 않습니다. 전통 검색 엔진도 명확한 구조를 선호하는 방향으로 오래전부터 움직여왔습니다. 짧고 완결된 문단은 SEO와 AEO 양쪽에서 손해 보지 않습니다.
같은 내용을 여러 번 반복하면 인용 확률이 오르나요?
오히려 역효과가 날 수 있습니다. 중복된 조각이 여러 개 검색되면 언어모델이 그중 하나만 씁니다. 반복보다는 같은 개념을 다른 질문 각도에서 한 번씩 다루는 편이 낫습니다.
이미지나 표에 담긴 정보도 인용되나요?
현재 대부분의 시스템은 텍스트 중심으로 조각을 나눕니다. 표나 이미지 안의 핵심 정보는 근처에 텍스트로도 풀어써 두시는 게 안전합니다.
llms.txt 를 올리면 이 과정이 달라지나요?
llms.txt 는 이 검색 파이프라인을 대체하지 않습니다. 대신 어떤 페이지가 중요한지 요약해서 알려주는 보조 신호입니다. 프레이머에서 올리는 방법은 이쪽 글에 정리해두었습니다.
정리하면
AI가 당신의 문장을 인용하는 과정은 두 단계입니다. 먼저 검색으로 후보 조각을 찾고, 그다음 생성 단계에서 그중 가장 쓰기 좋은 조각을 고릅니다.
이 두 단계를 통과하려면 문단은 짧고 완결되게, 핵심은 앞에, 소제목은 자주, 그리고 질문자의 언어로 써야 합니다. 이건 요령이 아니라 이 파이프라인의 구조 자체가 요구하는 조건입니다.
웹사이트를 정보의 창고가 아니라 답변의 재료로 설계해야 한다는 이야기를 이전에 드린 적이 있습니다. 그 글과 이 글을 함께 보시면, 왜 그래야 하는지의 이유가 메커니즘 수준까지 채워집니다.
함께 읽으면 좋은 글
- •ChatGPT, Perplexity가 당신 사이트를 인용하게 만드는 5가지 조건
- •웹사이트를 '정보 창고'로 만들지 마세요
- •AEO 시대, FAQ에 구조화 데이터를 입혀야 하는 이유
- •AEO와 GEO, 무엇이 다른가요?
우리 사이트의 문장이 실제로 어느 위치에서 잘리고 있는지, AFS 점수로 확인해 드립니다. AEO 무료 진단을 신청해 주시면 청크 단위로 잘라 직접 확인한 결과를 보내드립니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, AI 검색 시스템의 구현 세부사항은 서비스마다 다르고 계속 바뀌고 있어 일반적인 원리로 이해해 주시길 권합니다. 우리 사이트에 맞는 방향이 궁금하시다면 편하게 상담 신청해주세요.
