우리 회사 홈페이지가 ChatGPT 답변에 안 나오는 이유 — AI 검색 노출을 다루는 순서

AI검색GEOSEO홈페이지구축LLM

초록

"우리 회사를 ChatGPT에 물어보니 엉뚱한 답이 나온다"는 문의가 늘고 있습니다. 이 문제를 검색 순위 문제와 같은 것으로 취급하면 손대는 곳이 어긋납니다. AI가 특정 회사를 답변에 등장시키는 경로는 모델이 학습한 지식, AI 검색이 참조하는 색인, 답변 생성 시점의 실시간 접속 세 가지이고, 각 경로는 열고 닫는 스위치가 다르며 대응 방법도 다릅니다. 이 글은 세 경로를 먼저 분리한 뒤, 각 경로에서 우리 사이트가 어디서 걸리는지를 확인하는 방법을 정리합니다. 이어서 AI가 실제로 읽는 것이 브라우저 화면이 아니라 응답 HTML이라는 사실에서 출발해, 자바스크립트 렌더링·이미지 텍스트·로그인 벽이 만드는 공백을 짚습니다. 그 다음 인용되기 쉬운 문서의 형태, 구조화 데이터의 실효 범위, llms.txt의 현재 위상을 순서대로 다루고, 마지막으로 무엇부터 하고 무엇은 하지 않아도 되는지 우선순위를 제시합니다. 특정 도구나 대행사의 방법론은 다루지 않습니다.


1. 서론

작년까지 이 질문은 이렇게 왔습니다.

"네이버에 저희 회사 검색하면 왜 안 나와요?"

올해는 이렇게 옵니다.

"ChatGPT한테 물어보니까 저희 회사를 아예 모르거나, 5년 전 정보를 말해요."

두 질문은 표면이 비슷해서 같은 작업을 요구하는 것처럼 보입니다. 그런데 실제로는 상당히 다릅니다. 검색엔진은 주소 목록을 보여 주는 일을 하고, AI는 문장을 만들어 주는 일을 합니다. 앞의 것은 우리 페이지가 목록에 오르면 성공이지만, 뒤의 것은 우리 페이지의 내용이 문장 안에 녹아 들어가야 성공입니다. 링크가 걸리든 안 걸리든 말입니다.

이 차이 때문에 "SEO 잘해 두면 AI에도 잘 나오나요"라는 질문에는 부분적으로만 그렇다고 답해야 합니다. 겹치는 부분이 크지만, 겹치지 않는 부분이 요즘 문제가 되는 부분입니다.

그리고 이 작업에는 아직 정착된 이름이 없습니다. GEO(Generative Engine Optimization), AEO(Answer Engine Optimization), LLMO 같은 말이 돌아다니지만 어느 것도 표준이 아니고, 업계에서 검증된 방법론이라기보다 관측된 경향에 붙인 이름에 가깝습니다. 이 글에서도 용어를 앞세우지 않겠습니다. 대신 확인 가능한 것부터 다루겠습니다.


2. AI가 회사를 언급하는 세 가지 경로

이 세 가지를 분리하지 않으면 대응이 엉킵니다.

경로 A — 모델이 학습한 지식

모델을 훈련할 때 들어간 데이터에 우리 회사가 있었다면, 모델은 아무것도 검색하지 않고 답할 수 있습니다. 이 경로의 특징은 우리가 지금 무엇을 해도 즉시 반영되지 않는다는 것입니다. 학습은 특정 시점에 끝났고, 다음 모델이 나올 때까지 그 내용은 고정됩니다.

"5년 전 정보를 말한다"는 현상은 대개 이 경로입니다. 옛 정보가 학습에 들어갔고, 그 뒤 바뀐 내용은 모델이 모릅니다.

대응 가능성: 낮음, 그리고 느림. 지금 사이트를 고쳐도 다음 학습 주기에나 반영될 수 있고, 그마저 보장되지 않습니다.

경로 B — AI 검색이 참조하는 색인

ChatGPT 검색, Perplexity, Google AI 개요 같은 기능은 질문을 받으면 검색을 수행하고 그 결과를 요약합니다. 이때 참조되는 것은 웹 검색 색인입니다. 즉 이 경로는 기존 SEO와 크게 겹칩니다. 검색에 안 잡히는 페이지는 여기서도 안 잡힙니다.

다만 겹치지 않는 부분이 있습니다. 검색 결과 1페이지에 오르는 것과, 그 페이지의 특정 문장이 요약에 인용되는 것은 다른 일입니다. 5위 페이지의 잘 정리된 표가 1위 페이지의 산문보다 인용되기 쉬운 경우가 실제로 있습니다.

대응 가능성: 높음. 이 글의 대부분은 이 경로를 다룹니다.

경로 C — 답변 생성 시점의 실시간 접속

사용자가 주소를 직접 주거나, AI가 필요하다고 판단해 특정 페이지를 그 자리에서 가져오는 경우입니다. "이 회사 사이트 좀 요약해 줘"라고 주소를 붙여 물으면 이 경로가 작동합니다.

이 경로가 중요한 이유는 가장 즉각적이기 때문입니다. 오늘 고치면 오늘부터 다르게 읽힙니다. 그리고 실패 원인이 대개 단순합니다. 접속이 막혔거나, 접속은 됐는데 읽을 텍스트가 없거나.

대응 가능성: 매우 높음, 즉시.


3. 각 경로에서 우리가 막고 있는 것은 없는가

의외로 흔한 상황이 있습니다. 대응을 안 해서가 아니라 막아 놔서 안 나오는 경우입니다.

AI 관련 크롤러들은 사람이 쓰는 브라우저와 다른 이름표(User-Agent)를 달고 옵니다. 사이트의 robots.txt나 보안 설정(WAF, 봇 차단, CDN 규칙)이 이들을 차단하고 있으면, 우리가 무엇을 정리해 두었든 읽히지 않습니다.

주요 이름표를 용도별로 나누면 이렇습니다.

이름표소속주로 하는 일
GPTBotOpenAI학습용 수집 (경로 A)
OAI-SearchBotOpenAI검색 색인 (경로 B)
ChatGPT-UserOpenAI사용자 요청에 따른 실시간 접속 (경로 C)
ClaudeBotAnthropic학습용 수집
Claude-SearchBotAnthropic검색 색인
Claude-UserAnthropic사용자 요청에 따른 실시간 접속
PerplexityBotPerplexity검색 색인
Google-ExtendedGoogle생성형 AI 학습·근거 활용 여부 제어
GooglebotGoogle일반 검색 색인 (AI 개요의 바탕이 되기도 함)

여기서 실무적으로 중요한 구분이 하나 있습니다. 학습용 수집을 막는 것과 검색 색인을 막는 것은 별개라는 점입니다.

많은 회사가 "AI가 우리 콘텐츠를 학습에 쓰는 게 싫다"는 이유로 GPTBot을 막습니다. 그 판단 자체는 존중할 만합니다. 그런데 이때 규칙을 뭉뚱그려 써서 검색용·실시간용 이름표까지 함께 막아 버리면, 학습도 안 되고 노출도 안 되는 상태가 됩니다. 원하던 결과가 아닙니다.

원하는 조합을 정하는 표는 이렇습니다.

원하는 것학습 수집검색 색인실시간 접속
AI 답변에 최대한 노출허용허용허용
노출은 원하지만 학습은 거부차단허용허용
AI와 거리 두기차단차단차단

두 번째 줄이 대다수 기업이 실제로 원하는 조합입니다. 그런데 설정은 세 번째 줄로 되어 있는 경우가 종종 있습니다.

확인 방법은 간단합니다. 브라우저에서 우리도메인/robots.txt를 열어 보십시오. 그리고 CDN이나 보안 서비스를 쓰고 있다면 거기에도 봇 차단 설정이 따로 있습니다. robots.txt는 깨끗한데 방화벽에서 막고 있는 경우가 있으므로 양쪽을 다 봐야 합니다.

참고로 robots.txt는 강제력이 아니라 요청입니다. 규칙을 지키는 사업자는 지키고, 지키지 않는 수집기도 세상에는 있습니다. 완전한 차단이 목적이라면 서버 단에서 차단해야 합니다.


4. AI는 화면이 아니라 응답을 읽는다

이 지점이 가장 자주 어긋납니다.

우리가 사이트를 볼 때는 브라우저가 자바스크립트를 실행하고, 데이터를 불러오고, 폰트를 입혀서 완성된 화면을 그려 줍니다. 그런데 크롤러 상당수는 그 과정을 다 거치지 않습니다. 서버가 최초로 내려 준 HTML만 보고 지나가는 경우가 많습니다.

그래서 다음 세 가지가 자주 공백을 만듭니다.

첫째, 자바스크립트로만 그려지는 본문. 화면에는 회사 소개가 잘 나오는데, 그 글자가 최초 HTML에 없고 접속 후 API로 받아 오는 구조라면 크롤러 입장에서는 빈 페이지입니다. 요즘 프레임워크는 서버 렌더링을 기본으로 지원하므로, 새로 짓는다면 걸릴 일이 적습니다. 문제는 몇 년 전 방식으로 만들어진 사이트입니다.

둘째, 이미지 안에 들어 있는 글자. 회사 소개, 사업 영역, 제품 사양이 디자이너가 만든 긴 이미지 한 장으로 들어 있는 경우입니다. 사람 눈에는 잘 보이고 검색엔진과 AI에게는 아무것도 아닙니다. 이 문제는 상세페이지를 이미지로 만들면 검색에 안 잡힌다에서 따로 다뤘습니다. 요지는 전부 바꿀 필요는 없고, 판단에 쓰이는 정보만 텍스트로 꺼내면 된다는 것입니다.

셋째, 로그인·팝업·동의창 뒤에 있는 내용. 접속하자마자 전면 팝업이 뜨고 그 아래 본문이 있는 구조라면, 최초 HTML에 본문이 함께 있는지 확인해야 합니다.

확인하는 가장 빠른 방법

터미널에서 한 줄이면 됩니다.

curl -sL https://우리도메인/about | head -c 3000

여기에 회사 소개 문장이 보이면 통과입니다. 태그만 잔뜩 나오고 글자가 없으면 그것이 크롤러가 보는 화면입니다.

터미널이 익숙하지 않다면 브라우저에서 페이지를 열고 소스 보기(⌘+U 또는 Ctrl+U)를 누른 뒤, 본문 문장 하나를 그 안에서 검색해 보십시오. 안 찾아지면 같은 상황입니다.

이 확인은 5분이면 끝나고, 여기서 걸리면 그 아래 모든 최적화는 의미가 없습니다. 순서상 가장 먼저입니다.


5. 인용되기 쉬운 문서의 형태

접속도 되고 텍스트도 있다면, 다음 질문은 "그래서 왜 우리 문장이 안 쓰이는가"입니다.

AI가 답을 만들 때는 여러 문서를 훑어 필요한 조각을 가져다 씁니다. 이때 가져다 쓰기 좋은 조각에는 공통점이 있습니다. 대단한 기법은 아니고, 사람이 읽기에도 좋은 글의 성질과 대체로 겹칩니다.

5-1. 정의가 앞에 있어야 한다

회사 소개 페이지가 이렇게 시작하는 경우가 많습니다.

"우리는 끊임없는 도전과 혁신으로 고객과 함께 성장하는 파트너가 되겠습니다."

이 문장에서 뽑을 수 있는 정보는 없습니다. 회사가 뭘 하는지, 어디에 있는지, 누구를 상대하는지가 하나도 없습니다.

필요한 것은 이런 문장입니다.

"OO는 2018년 설립된 산업용 제어기 제조사로, 반도체 장비사에 온도 제어 모듈을 공급합니다. 본사는 경기 화성이며 직원 수는 40명입니다."

한 문장에 무엇·언제·누구에게·어디서가 들어 있으면 그대로 인용됩니다. 비전 선언은 그 아래에 두면 됩니다. 없애라는 말이 아니라 순서를 바꾸라는 말입니다.

5-2. 섹션이 혼자서도 말이 되어야 한다

문서를 통째로 읽는 대신 일부만 잘라 쓰는 경우가 많기 때문에, 각 섹션이 앞을 안 읽어도 이해되도록 쓰는 편이 유리합니다.

구체적으로는 "위에서 말씀드린 그 제품은" 같은 지시어로 섹션을 시작하지 않는 것입니다. 잘려 나가면 무엇을 가리키는지 알 수 없게 됩니다. 대신 그 자리에서 대상을 다시 명명합니다.

5-3. 숫자와 조건은 표로

가격, 사양, 처리 기간, 지원 범위처럼 항목별로 값이 다른 정보는 산문보다 표가 압도적으로 잘 인용됩니다. 표는 구조가 명시적이라 어긋날 여지가 적습니다.

산문으로 쓰면 이렇게 됩니다.

"기본형은 3주 정도 걸리고 옵션을 추가하면 4주에서 5주까지 볼 수 있으며 대량 주문의 경우 별도 협의가 필요합니다."

표로 쓰면 이렇게 됩니다.

구분소요 기간
기본형3주
옵션 추가4~5주
대량 주문별도 협의

같은 내용인데 뒤의 것이 훨씬 안전하게 옮겨집니다.

5-4. 질문 형태의 제목

사람들이 실제로 검색창이나 채팅창에 입력하는 형태를 소제목으로 쓰면 매칭이 쉬워집니다. "제품 사양"보다 "OO 제품의 최대 사용 온도는 얼마인가"가 낫습니다.

다만 억지로 모든 제목을 의문문으로 바꿀 필요는 없습니다. 실제로 자주 받는 질문에 대해서만 그렇게 하면 됩니다. 영업이나 고객센터가 이미 답을 알고 있습니다. 가장 많이 받는 질문 열 개를 받아 적는 것이 이 작업의 시작입니다.

5-5. 시점이 드러나야 한다

"최근", "현재", "올해"만 있고 실제 날짜가 없는 문서는 신뢰도가 떨어집니다. 언제 쓴 글인지, 언제 갱신했는지가 본문에 있으면 최신 정보를 찾는 상황에서 유리합니다.

특히 가격, 정책, 인원, 실적처럼 변하는 값에는 기준 시점을 붙이는 편이 좋습니다. "2026년 8월 기준"이라는 다섯 글자가 그 문단의 수명을 정합니다.

5-6. 근거가 붙어 있어야 한다

주장만 있는 문서보다 출처·수치·사례가 붙은 문서가 잘 인용됩니다. 자사 데이터라면 그 사실을 밝히면 됩니다. "당사 2026년 상반기 출고 기준"처럼요.


6. 구조화 데이터는 어디까지 실효가 있는가

schema.org 구조화 데이터(JSON-LD)를 넣으면 AI 노출이 좋아진다는 말이 자주 돕니다. 정확히 말하면 이렇습니다.

확실한 것: 구조화 데이터는 기계가 읽기 쉬운 형태로 사실을 명시합니다. 회사명, 주소, 설립일, 연락처, 제품, 저자, 발행일 같은 값이 본문에서 추출하는 것보다 훨씬 오해 없이 전달됩니다. 값이 흩어져 있어 헷갈리는 사이트일수록 효과가 큽니다.

불확실한 것: 구조화 데이터를 넣었다고 AI 답변에 더 자주 인용된다는 보장은 없습니다. AI 검색 사업자들이 어떤 가중치를 쓰는지 공개하지 않았고, 검색 리치 결과처럼 명시적 보상이 있는 것도 아닙니다.

그래서 권장 범위는 이렇습니다.

넣을 가치가 분명한 것

  • Organization — 회사명, 로고, 주소, 연락처, 공식 SNS 계정. 회사 정체성을 한 곳에 고정합니다.
  • WebSite — 사이트 이름과 대표 주소.
  • BreadcrumbList — 페이지가 사이트 구조 어디에 있는지.
  • Article / BlogPosting — 발행일, 수정일, 저자. 시점 판단에 직접 쓰입니다.
  • Product, Service — 취급 품목이 명확한 회사라면.

과하게 손댈 필요 없는 것

  • FAQPage — 검색 리치 결과 노출은 예전만 못합니다. 다만 FAQ 자체를 텍스트로 잘 써 두는 것은 여전히 효과가 큽니다. 마크업이 아니라 내용이 일합니다.
  • 실제 페이지에 없는 내용을 마크업으로만 넣는 것 — 불일치는 신뢰를 깎습니다. 마크업은 본문의 요약이어야지 본문보다 커지면 안 됩니다.

Organization 예시는 이 정도면 충분합니다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "주식회사 예시",
  "url": "https://example.co.kr",
  "logo": "https://example.co.kr/logo.png",
  "foundingDate": "2018-03-01",
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "KR",
    "addressRegion": "경기도",
    "addressLocality": "화성시",
    "streetAddress": "○○로 12"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "telephone": "+82-31-000-0000",
    "email": "sales@example.co.kr"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://blog.naver.com/example"
  ]
}

sameAs가 의외로 중요합니다. 흩어진 계정들을 같은 회사로 묶어 주는 역할을 합니다.


7. llms.txt — 무엇이고 무엇이 아닌가

작년부터 llms.txt 이야기가 많이 돕니다. 정확한 위상을 먼저 말하는 편이 좋겠습니다.

무엇인가: 사이트 루트에 두는 마크다운 파일로, "이 사이트에서 중요한 문서는 이것들이고 각각 이런 내용이다"를 정리한 안내문입니다. 형식은 마크다운이고, 제목·요약·링크 목록으로 이루어집니다.

무엇이 아닌가: 표준이 아니고, 주요 AI 검색 사업자가 공식적으로 이 파일을 읽는다고 밝힌 바도 없습니다. robots.txtsitemap.xml과 같은 지위로 취급하면 안 됩니다. 커뮤니티에서 제안된 관행이고, 일부 개발자 문서 사이트가 채택하고 있는 단계입니다.

그러면 왜 만드나. 세 가지 이유가 있습니다.

  1. 비용이 거의 안 듭니다. 잘 만든 사이트라면 30분이면 씁니다.
  2. AI에게 문서를 직접 물릴 때 유용합니다. 사내에서 챗봇을 붙이거나, 상대방이 우리 문서를 AI에 넣어 검토할 때 이 파일 하나가 좋은 목차가 됩니다.
  3. 쓰는 과정 자체가 정리입니다. "우리 사이트의 핵심 문서 열 개"를 못 고르는 회사가 많습니다. 못 고른다는 것은 사이트가 그렇게 되어 있다는 뜻이고, 그게 진짜 문제입니다.

효과를 기대하고 만들기보다, 싼 값에 얻는 부수 효과를 보고 만드는 것이 맞는 태도입니다. 대행사가 "llms.txt를 넣으면 AI 노출이 올라갑니다"라고 하면 그 근거를 물어보십시오.

형태는 이렇습니다.

# 주식회사 예시

> 반도체 장비용 온도 제어 모듈을 설계·제조하는 회사입니다.
> 2018년 설립, 경기 화성 소재, 직원 40명.

## 회사

- [회사 소개](https://example.co.kr/about): 설립 배경, 사업 영역, 주요 고객사
- [오시는 길](https://example.co.kr/contact): 본사·공장 주소와 연락처

## 제품

- [TC-200 시리즈](https://example.co.kr/products/tc200): 사양표, 사용 온도 범위, 인증 현황
- [TC-500 시리즈](https://example.co.kr/products/tc500): 사양표, 호환 장비 목록

## 자주 묻는 질문

- [납기와 최소 주문 수량](https://example.co.kr/faq/lead-time)
- [A/S 정책](https://example.co.kr/faq/support)

8. 사이트 밖에서 정해지는 것

여기까지가 사이트 안의 일입니다. 그런데 AI가 회사를 어떻게 인식하는지는 상당 부분 사이트 밖에서 정해집니다.

표기가 일관되어야 합니다. 어디서는 "(주)예시", 어디서는 "예시(주)", 어디서는 "Example Co., Ltd."로 쓰면 같은 회사로 묶이지 않을 수 있습니다. 대표 표기 하나를 정하고, 사이트·SNS·보도자료·채용공고·명함에서 그것을 씁니다. 영문 표기도 하나로 정합니다.

주소와 전화번호도 마찬가지입니다. 사무실을 옮겼는데 예전 주소가 여기저기 남아 있으면 AI는 둘 다 봅니다. 그리고 종종 틀린 쪽을 말합니다.

남이 쓴 글이 강합니다. 우리 사이트가 우리를 어떻게 소개하는지보다, 업계 매체·거래처 공지·커뮤니티 글이 우리를 어떻게 부르는지가 인식에 더 크게 작용하는 경향이 있습니다. 이건 하루아침에 만들 수 없고, 만들려고 무리하면 역효과가 납니다. 다만 이미 있는 언급이 틀렸다면 고쳐 달라고 요청하는 것은 지금 할 수 있는 일입니다.

우리가 쓸 수 있는 표준 소개문을 하나 만들어 두십시오. 서너 문장짜리로, 위 5-1에서 말한 형태로. 보도자료·전시회 자료·협력사 소개란에 그것을 그대로 씁니다. 같은 문장이 여러 곳에서 반복되면 그 문장이 회사의 정의가 됩니다.


9. 확인하는 방법

작업했으면 확인이 필요합니다. AI 노출은 순위표가 없어서 확인이 애매한데, 그래도 볼 수 있는 것들이 있습니다.

9-1. 서버 로그에서 AI 봇 방문 보기

가장 객관적인 지표입니다. 접속 로그에서 User-Agent를 훑으면 어떤 봇이 언제 무엇을 가져갔는지 보입니다.

grep -iE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot" access.log \
  | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -30

여기서 볼 것은 두 가지입니다. 오기는 하는가, 그리고 응답 코드가 200인가. 403이 찍혀 있으면 3장의 차단 문제입니다.

호스팅이 로그 접근을 막고 있다면, 대부분의 배포 플랫폼과 CDN이 자체 로그 화면을 제공합니다. 거기서 봇 트래픽 필터를 찾으면 됩니다.

9-2. 실제로 물어보기

가장 단순하고 가장 자주 건너뛰는 방법입니다. 확인할 질문 목록을 열 개 정도 정해 두고, 주요 AI 서비스에 같은 질문을 넣어 답을 기록합니다.

  • "OO 회사는 뭐 하는 곳이야?"
  • "OO 제품 최대 사용 온도가 얼마야?"
  • "국내에서 △△ 만드는 회사 추천해 줘"
  • "OO랑 □□ 중에 뭐가 나아?"

세 번째와 네 번째가 중요합니다. 회사 이름을 대지 않고 물었을 때 우리가 후보에 오르는가가 실제 영업 가치에 가깝습니다. 이름을 대고 물으면 대개는 뭐라도 답합니다.

기록은 날짜와 함께 남기십시오. 답변은 같은 질문에도 매번 조금씩 달라지므로, 한 번의 결과로 판단하지 말고 시간에 따른 변화를 보는 편이 낫습니다.

9-3. 참조된 주소 확인

AI 검색 답변에는 대개 참조한 링크가 붙습니다. 우리 사이트가 붙었다면 어느 페이지가 붙었는지 보십시오. 의도한 페이지가 아니라 엉뚱한 옛 게시물이 참조되고 있다면, 그것은 그 게시물이 더 잘 쓰였다는 뜻이거나 의도한 페이지가 안 읽히고 있다는 뜻입니다.

유입 쪽에서도 흔적이 남습니다. 분석 도구의 유입 경로에서 AI 서비스 도메인이 보이기 시작하면, 그 경로로 사람이 실제로 넘어오고 있다는 뜻입니다.


10. 우선순위 — 무엇부터, 무엇은 안 해도 되는가

전부 하려면 끝이 없으므로 순서를 정합니다. 위에서 아래로, 앞의 것이 안 되어 있으면 뒤의 것은 효과가 없습니다.

순서할 일대략 걸리는 시간안 하면 생기는 일
1robots.txt·방화벽에서 AI 봇 차단 여부 확인30분아무리 정리해도 안 읽힘
2curl로 최초 HTML에 본문 텍스트가 있는지 확인30분빈 페이지로 인식됨
3회사 정의 문장 다시 쓰기 (소개·메인 상단)반나절인용할 문장이 없음
4자주 받는 질문 10개를 텍스트 FAQ로1~2일실제 질문과 안 맞음
5이미지 안에만 있는 핵심 정보를 텍스트로사안별사양·가격이 안 읽힘
6Organization 등 기본 구조화 데이터반나절정체성이 흩어짐
7표기·주소·연락처 통일 (사이트 밖 포함)1~2일옛 정보가 계속 나옴
8llms.txt 작성30분큰일은 안 남

하지 않아도 되는 것도 적어 둡니다.

  • AI 전용 페이지를 따로 만드는 것. 사람용과 AI용을 나눠 다른 내용을 보여 주는 방식은 위험합니다. 검색엔진에서 오래전부터 금지해 온 클로킹과 구분이 안 됩니다.
  • 키워드를 반복해 채우는 것. 문장 품질이 떨어지면 인용될 확률도 떨어집니다.
  • AI가 쓴 글로 페이지 수를 늘리는 것. 내용이 없는 글이 많은 사이트는 신호가 희석됩니다. 열 개의 얇은 글보다 두 개의 두꺼운 글이 낫습니다.
  • 모든 페이지에 구조화 데이터를 넣는 것. 값이 실제로 있는 페이지에만 넣으십시오.
  • "AI 최적화 패키지"에 큰돈을 쓰는 것. 위 표의 1~7번은 대부분 기존 홈페이지 관리 범위 안에서 처리 가능한 작업입니다. 별도 상품으로 팔린다면 무엇이 추가되는지 항목으로 받아 보십시오.

11. 이 작업이 홈페이지 구축 견적에서 갖는 위치

새로 짓는 경우와 이미 있는 사이트를 손보는 경우가 다릅니다.

새로 짓는 경우, 위 항목 대부분은 별도 비용이 아니라 제대로 짓는 것의 일부입니다. 서버 렌더링, 시맨틱 마크업, 구조화 데이터, 텍스트 기반 콘텐츠는 요즘 방식으로 만들면 기본으로 따라옵니다. 견적서에 "AI 검색 최적화"가 별도 항목으로 크게 잡혀 있다면, 그 안에 무엇이 들어 있는지 확인해 보는 편이 좋습니다.

다만 하나는 진짜 추가 작업입니다. 콘텐츠를 다시 쓰는 일입니다. 이건 개발이 아니라 글쓰기이고, 회사 내부만 아는 내용이 많아서 외주로 완전히 넘기기 어렵습니다. 견적에서 이 부분의 주체가 누구인지 — 우리가 쓸 것인지, 업체가 초안을 잡고 우리가 감수할 것인지 — 를 정해 두지 않으면 프로젝트 후반에 멈춥니다. 이 문제는 기업용 홈페이지 구축을 시작할 때에서 다룬 축과 이어집니다.

이미 있는 사이트라면, 10장 표의 1·2번을 먼저 해 보십시오. 여기서 걸리면 사이트 구조 문제이고, 손보는 범위가 커집니다. 이때는 부분 수정과 전면 개편 중 무엇이 싼지를 따로 판단해야 합니다. 그 판단 절차는 홈페이지를 고칠지 새로 지을지에 정리해 두었습니다.


12. 결론

정리하면 세 문장입니다.

첫째, 막고 있지 않은지 먼저 확인하십시오. AI 노출 상담의 상당수는 최적화 문제가 아니라 차단 설정 문제이거나, 크롤러가 볼 수 있는 텍스트가 애초에 없는 문제입니다. 이 둘은 한 시간이면 확인되고, 여기서 걸리면 다른 모든 작업이 헛돕니다.

둘째, 새로운 기술이 아니라 오래된 원칙에 가깝습니다. 사실을 명확한 문장으로 쓰고, 숫자는 표로 정리하고, 시점을 밝히고, 이름 표기를 통일하는 것. AI 때문에 새로 생긴 요구가 아니라, 그동안 안 지켜도 티가 덜 났던 것들이 이제 티가 나는 것입니다.

셋째, 확실한 것과 불확실한 것을 구분하십시오. 크롤러 접근성과 텍스트 가용성은 확실합니다. 구조화 데이터는 도움이 되지만 보상이 명시되어 있지 않습니다. llms.txt는 아직 관행 단계입니다. 이 구분 없이 "AI 최적화"를 한 덩어리로 파는 제안을 받으면, 확실한 항목이 몇 개나 들어 있는지 세어 보십시오.

마지막으로 하나. AI가 회사를 어떻게 소개할지는 결국 회사가 자기를 설명할 문장을 갖고 있는가에 달려 있습니다. 그 문장이 없는 회사는 검색에서도, AI에서도, 사람에게도 잘 설명되지 않습니다. 순서상 이것이 기술 작업보다 먼저입니다.

우리 사이트가 지금 어느 단계인지 가늠이 안 된다면 사이트 진단 절차를 따라가 보시고, 개편 범위를 잡아 대략의 비용 구간을 보고 싶다면 외주 개발 비용 계산기에서 페이지 수와 필요한 기능만 골라 확인할 수 있습니다. 연락처를 남기지 않아도 결과는 그대로 보입니다.

궁금한 점이 있으신가요?

협업·의뢰는 아래로, 가벼운 소통은 인스타그램 @bluefox._.hi도 환영이에요.

비용이 궁금하면 외주 계산기로 먼저 확인해보세요.