"ChatGPT에 인용되려면 어떻게 해야 하나요?"라는 질문에는 보통 좋은 콘텐츠를 쓰고, 스키마를 추가하고, llms.txt를 만들라는 목록형 글이 답으로 나옵니다. 그 조언은 틀렸다기보다 잘못된 계층을 겨냥하고 있습니다. 페이지가 어떤 모습이어야 하는지만 설명하고, 실제로 결과를 결정하는 두 질문은 건너뜁니다. 검색 시스템이 애초에 페이지에 접근할 수 있는가, 그리고 문맥에서 떼어 내도 의미가 유지되는 구절이 있는가?
이 글은 실제 작동 순서대로 그 메커니즘을 설명합니다. 우리도 자체 사이트에서 이 점검들을 실행하며, 그중 몇 가지 덕분에 콘텐츠를 아무리 손봐도 해결되지 않았을 문제를 발견했습니다.
인용은 순위 문제가 아니라 검색 문제입니다
ChatGPT가 링크와 함께 답한다고 해서 모든 질문마다 웹을 실시간으로 읽는 것은 아닙니다. 검색 단계에서 색인으로부터 후보 구절을 가져오고, 모델은 반환된 내용으로 답을 구성한 뒤 의존한 부분의 출처를 표시합니다. 여기서 두 가지 결과가 나오며 기존 SEO에 익숙하다면 둘 다 직관적이지 않습니다.
- 단위는 페이지가 아니라 구절입니다. 페이지의 순위가 높아도 전혀 기여하지 못할 수 있습니다. 인용할 가치가 있는 사실이 이미지, 텍스트 대안 없는 차트, JavaScript가 실행된 뒤에만 존재하는 문단에 들어 있기 때문입니다.
- 검색 가능성과 인용 가능성은 기준이 다릅니다. 색인에 포함되는 것은 사전 조건입니다. 질문에 대해 이용 가능한 가장 명확한 문장을 제공해야 출처로 표시됩니다. 대부분의 GEO 체크리스트는 첫 번째만 다루고 트래픽이 왜 늘지 않는지 의아해합니다.
실제로 순위와 인용은 분리됩니다. 키워드 순위가 3위여도 전혀 인용되지 않을 수 있습니다. 위의 두 페이지는 그 자체로 완결된 한 문장으로 답을 제시하는데, 자신의 답은 "우리의 철학"이라는 섹션의 네 번째 문단에 묻혀 있기 때문입니다.
봇 세 개, 서로 다른 역할 세 가지
가장 큰 대가를 치르는 실수가 여기서 발생합니다. 사람들이 "OpenAI 크롤러"를 하나인 것처럼 생각하기 때문입니다. OpenAI 문서에는 세 가지 별도 에이전트가 있으며, 이들은 서로 다른 역할을 합니다:
- GPTBot — 모델 학습을 위한 대규모 크롤링입니다. 이를 차단하면 향후 모델이 사이트에서 학습할 내용이 달라집니다. ChatGPT의 실시간 인용에서 사이트를 제거하지는 않습니다.
- OAI-SearchBot — 검색 단계에서 읽는 검색 색인을 구축합니다. 애초에 인용될 수 있는지를 결정하는 것은 이 봇입니다.
- ChatGPT-User — 사용자의 질문이 실시간 탐색을 유발하면 특정 URL을 가져옵니다. 차단하면 누군가 내 사이트에 관해 묻는 바로 그 순간 가져오기에 실패합니다.
흔한 실패는 이렇습니다. 팀이 자기 콘텐츠를 모델 학습에 쓰고 싶지 않아 GPTBot을 차단하고 신중한 결정을 내렸다고 생각합니다. 맞습니다. 다만 학습에 관한 결정입니다. 검색에 대해서는 아무것도 결정하지 않았습니다. 더 나쁜 경우도 있습니다. 누군가 와일드카드 규칙 하나로 모든 OpenAI 에이전트를 차단하여 회사를 AI 답변에서 조용히 없애 버린 뒤, 한 분기 내내 왜 경쟁사가 인용되는지 의아해합니다.
이 선택들은 분리할 수 있으므로 각각 결정하세요. 우리의 robots.txt는 세 봇을 모두 허용하고 /api/와 공유 링크는 차단합니다. 공유 링크는 색인에 포함될 이유가 없는 사용자 콘텐츠이기 때문입니다. 여러분의 설정은 달라도 됩니다. 학습과 검색은 실제로 서로 다른 거래입니다. 공급업체별이 아니라 봇별로 결정하고, 정책은 바뀌므로 가끔 공급업체 문서를 다시 읽으세요.
실제로 접근을 막는 것은 robots.txt가 아닙니다
Robots는 요청이며 누구나 확인하는 계층입니다. 실제로 문제가 되는 계층은 CDN 또는 WAF입니다. 엣지 플랫폼은 많은 기본 설정에서 낯선 사용자 에이전트에 확인 절차를 요구하거나 차단하며, 결과는 조용히 나타납니다. robots.txt는 Allow라고 하지만 엣지는 403을 반환합니다. 저장소의 모든 파일이 접근을 허용한다고 말하는데도 크롤링이 불가능해집니다.
점검에는 10초가 걸리지만 실행하는 사람은 거의 없습니다.
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/200 이면 접근할 수 있다는 뜻입니다. 403이나 503또는 확인 페이지가 나오면 콘텐츠를 아무리 손봐도 해결할 수 없는 노출 문제가 있다는 뜻입니다. 자체 네트워크 밖에서 운영 중인 모든 도메인을 대상으로 실행하세요. 도메인마다 보통 별도의 엣지 설정이 있고 서로 달라지기 때문입니다.
이 글에서 딱 한 가지를 한다면 이것을 하세요. 투입한 시간 대비 효과가 가장 큰 점검이며, 어떤 콘텐츠 감사에서도 드러나지 않습니다.
JavaScript가 필요한 사실은 존재하지 않는 것과 같습니다
검색용 크롤러는 보통 JavaScript를 실행하지 않고 원시 HTML을 파싱합니다. 따라서 어떤 주장을 인용할 수 있는지 판단하는 기준은 브라우저에 보이는 것이 아니라 다음입니다.
curl -s https://your-site/page/ | grep -i "the claim you want quoted"출력에 아무것도 없으면 인용할 것도 없습니다. 이는 실제 설계에 영향을 줍니다. 정의, 핵심 사실, FAQ 답변, 가격 및 보안 주장처럼 인용에 중요한 텍스트는 서버가 제공하는 HTML에 있어야 합니다. 하이드레이션 후 텍스트를 바꾸는 런타임 사전은 보완 수단으로는 괜찮지만, 사실이 존재하는 유일한 장소여서는 안 됩니다.
이 문제는 다국어 사이트에서 가장 크게 드러나며, 우리가 명시적으로 피하도록 설계한 함정입니다. 중국어 문구가 JavaScript i18n 사전에만 있다면 원시 HTML 크롤러에게 중국어 콘텐츠는 아예 존재하지 않습니다. 우리는 모든 언어를 실제 마크업으로 인라인 배치하고 CSS로 사람이 볼 언어를 결정하도록 해결했습니다. 크롤러는 네 언어를 모두 받고 독자는 하나를 봅니다. 페이지 용량은 늘지만 그럴 가치가 있습니다.
문맥에서 떼어 내도 의미가 유지되는 구절을 쓰세요
이 부분은 기반 작업이 아니라 실제 글쓰기이며, 기반이 작동하고 나면 가장 큰 효과를 낼 수 있는 곳입니다.
검색된 조각은 주변 페이지 없이 모델에 도착합니다. 제목 계층도, 앞 문단도, 탐색 메뉴도 없습니다. 이를 고려해 쓰세요.
- 답부터 제시하세요. 제목 아래 첫 문장은 준비 문구가 아니라 답이어야 합니다. "X는 Y다"가 "오늘날 빠르게 변화하는 환경에서…"보다 낫습니다. 후자는 아무것도 답하지 않아 인용되지 않습니다.
- 주어를 명확히 하세요. "이것은 OAuth를 지원합니다"는 떼어 내면 사용할 수 없지만 "Orkas는 OAuth를 지원합니다"는 의미가 유지됩니다. 텍스트를 조각으로 나누면 대명사는 힘을 잃습니다.
- 각 주장을 그 자체로 완결되게 만드세요. 대상, 조건, 경계를 한 문장에 넣으세요. "자체 제공업체를 사용하면 모델 트래픽은 해당 제공업체로 직접 전송되며 Orkas를 경유하지 않습니다." 이 문장은 단독으로 인용해도 거짓이 되지 않으며, 바로 그래서 인용할 만합니다.
- 인상적인 표현보다 검증 가능한 표현을 우선하세요. 모호한 최상급 표현은 누구의 질문에도 답하지 못하므로 인용되지 않습니다.
질문이 검색의 열쇠입니다
사용자는 질문하고 검색은 질문 형태의 텍스트를 찾습니다. "Orkas가 모델 트래픽을 프록시로 중계하나요?"처럼 질문 자체인 제목이 "모델 아키텍처" 같은 명사구보다 잘 매칭됩니다. FAQ 블록이 AI 노출에서 분량에 비해 큰 효과를 내는 이유는 스키마의 마법이 아니라 여기에 있습니다. 말 그대로 질문과 답의 쌍이며, 검색 대상의 형태와 같기 때문입니다.
구조화된 데이터는 파싱을 돕지만 우선 선택을 보장하지 않습니다
JSON-LD는 인용을 사 주지 않습니다. 대신 이 페이지가 무엇인지, 누가 게시했는지, 어떤 텍스트가 질문이고 어떤 것이 답인지 모호하지 않게 분류해 줍니다. 다른 무엇보다 중요한 규칙은 두 가지입니다.
- FAQ 스키마는 보이는 텍스트와 일대일로 일치해야 합니다. 페이지에 없는 내용을 주장하는 스키마는 신뢰 문제입니다. 검색 엔진은 이런 불일치를 서식 실수가 아니라 스팸 신호로 취급합니다.
- 평점, 수상 내역, 수치를 절대 꾸며 내지 마세요. 조작된 종합 평점 하나를 발견한 엔진에는 다른 모든 주장도 덜 신뢰할 이유가 생깁니다.
1:1 규칙은 조용히 무너지기 쉽습니다. 누군가 화면에 보이는 FAQ를 수정하고 스키마를 잊으면 6개월 뒤 둘이 달라집니다. 우리는 사이트맵의 모든 페이지를 순회하고 JSON-LD에서 FAQ를 추출한 뒤 각 질문과 답 문자열이 해당 페이지의 보이는 텍스트에 그대로 있는지 검사하는 테스트로 이를 강제합니다. 어긋나면 빌드가 실패합니다. 구조화된 데이터는 자기 페이지에 대한 주장이므로 그에 맞게 검증해야 합니다.
llms.txt: 저렴하고 유용하지만 과장되어 있습니다
이 파일의 정체를 솔직하게 보세요. llms.txt는 제안된 규약입니다. 이를 읽겠다고 약속한 주요 엔진은 없으며, 이를 수집 경로라고 말하는 사람은 추측하는 것입니다.
실제로 잘하는 일은 더 좁지만 그래도 한 시간을 들일 가치가 있습니다. 제품이 무엇인지, 모델과 데이터 처리 방식, 가격, 중요한 URL 등 기준이 되는 사실을 명확히 적어 두는 하나의 안정된 장소입니다. 크롤러나 조사자가 그곳에 도달하면 마케팅 페이지에서 내용을 재구성하는 대신 포장 없는 정보를 얻습니다. 또한 사실을 분명히 정리하도록 유도하는 유용한 장치입니다. 수식어 없이 40줄로 제품의 사실을 설명할 수 없다면 페이지도 마찬가지이며, 어차피 마주쳤을 콘텐츠 문제입니다.
이 파일은 보증도 아니고, 페이지 자체에 해당 사실을 담는 일을 대신하지도 않습니다.
모순이 있으면 제외됩니다
답변 엔진은 교차 확인합니다. 요금제 페이지, 문서, 홈페이지 FAQ가 각각 다른 말을 하면 엔진은 판정하지 않습니다. 답을 흐리거나 일관된 다른 출처를 인용합니다.
따라서 여러 접점의 사실을 일관되게 유지하는 것이 실제 작업의 대부분이며, 화려한 일은 하나도 없습니다. 모델, 가격, 보안 관련 사실이 바뀌면 한 번의 변경에서 모든 곳을 함께 바꿔야 합니다. 페이지, 문서, 홈페이지 FAQ, llms.txt 모두입니다. 그렇지 않으면 편집이 끝난 뒤에도 남는 모순을 직접 만든 셈입니다. 습관은 마감에 밀리므로 우리는 이를 습관이 아니라 엄격한 규칙으로 취급합니다.
외부의 뒷받침이 자기 주장보다 강합니다
가장 받아들이기 어려운 부분은 이것입니다. 자신에 관한 자료 중 자신의 사이트는 가장 약한 출처입니다. 엔진은 뒷받침되는 정보에 가중치를 두며, 타당한 방식입니다. 자기 도메인에만 있는 주장은 마케팅 주장입니다. 같은 주장이 GitHub, 타사 비교 글, 포럼 토론, 다른 사람이 쓴 문서에도 있으면 사실이 됩니다.
그래서 사이트 내부의 기본 조건을 제대로 갖추고 나면 랜딩 페이지를 하나 더 만드는 것보다 저장소, 디렉터리, 목록형 글, 진솔한 토론 같은 외부 작업의 성과가 더 큽니다. 거칠게 말하면 사이트 내부 작업은 인용될 수 있게하고, 외부 작업은 실제로 인용되게합니다. 팀은 자신이 통제할 수 있는 부분이기 때문에 전자에 과도하게 투자하는 경향이 뚜렷합니다.
스스로를 속이지 않고 측정하는 방법
GEO 글이 보통 흐릿해지는 부분이므로 분명히 말하겠습니다. ChatGPT 인용은 명확하게 측정할 수 없습니다. 대시보드는 없습니다. 이용할 수 있는 것은 세 가지 불완전한 신호입니다.
- 서버 로그. Grep으로
OAI-SearchBot과ChatGPT-User를 찾으세요. 크롤링 빈도와 가져오는 URL을 보면 색인에 포함되어 있는지, 무엇을 실시간으로 가져오는지 알 수 있습니다. 직접 보유한 신호 중 가장 솔직한 신호입니다. - 어시스턴트의 추천 유입 트래픽. 실제 신호이지만 일부만 보여 줍니다. 많은 인용은 읽기만 하고 클릭하지 않습니다. 그것이 답변 엔진의 존재 이유이기도 합니다.
- 수동 표본 점검. 자신이 답변의 주인이 되고 싶은 질문 열 개를 하고 누가 인용되는지 기록하세요. 번거롭고 방향성만 보여 주지만 답변 화면 자체를 관찰할 수 있는 유일한 방법입니다.
세 가지 모두 방향성을 나타내는 신호로 보세요. 정확한 "GEO 점수"를 판다는 사람은 자신이 만든 숫자를 파는 것입니다.
실제로 가장 먼저 할 일
발표 자료에서 멋져 보이는 순서가 아니라 효과 순서입니다.
- 1.
curl -A로 실제 운영 환경에서 검색 봇의 접근을 확인하세요. 엣지가 봇을 차단한다면 이 목록의 다른 항목은 아무 의미가 없습니다. - 2.
curl | grep으로 핵심 주장을 확인하세요. JavaScript에만 있는 내용은 서버가 제공하는 HTML로 옮기세요. - 3. 각 제목 아래 첫 문장을 명확한 주어가 있는 답으로 다시 쓰세요.
- 4. FAQ 텍스트와 FAQ 스키마를 똑같이 맞추고, 보이는 텍스트로 뒷받침할 수 없는 스키마는 삭제하세요.
- 5. 페이지, 문서,
llms.txt에서 서로 모순되는 사실을 맞추세요. - 6. 그다음에만 사이트 외부에서 뒷받침할 근거를 확보하세요.
인용이 빠지는 원인은 대개 1단계와 2단계에 숨어 있습니다. 콘텐츠 마케팅이 아니라는 이유로 아무도 글을 쓰지 않는 두 단계이기도 합니다.
마무리
ChatGPT에 인용되는 것은 이를 둘러싼 약어가 암시하는 것만큼 신비롭지 않습니다. 검색 봇이 접근할 수 있어야 합니다. JavaScript 없이 읽을 수 있어야 합니다. 그 자체로 완결된 한 문장으로 인용할 수 있어야 합니다. 자신의 여러 접점에서 일관되어야 합니다. 마케팅 사이트 밖에서도 뒷받침되어야 합니다. 도구는 계속 바뀌어도 이 다섯 가지는 유지됩니다.
우리는 자체 사이트에서 이 점검들을 실행하며, 이를 Orkas 워크플로로 만들어 사이트의 검색 및 AI 답변 노출을 감사하고 우선순위가 있는 수정 목록을 반환하도록 했습니다. 그 아래 계층, 즉 주도 에이전트가 작업을 계획하고 전문가에게 배정해 실행하는 방식을 알고 싶다면 멀티 에이전트 오케스트레이션의 실제 활용을 읽어 보세요.