AEO 개념과 최적화 – AI 답변에 인용되는 글 만들기

1 – AEO 알아보기

1.1 – 작업 환경 준비

바탕화면에 aeo_practice 폴더를 만듭니다.
aeo_practice 폴더 안에 aeo_memo.txt 파일을 만듭니다.
Chrome을 열어 둡니다.
aeo_memo.txt를 메모장(Windows) 또는 텍스트 편집기(macOS)로 엽니다.
아래 내용을 첫 줄부터 그대로 입력하고 저장합니다.

[AI 답변 기록]
확인한 날짜:
사용한 AI 검색 서비스:
질문:
답변 요약:
인용된 출처(주소):

aeo_memo.txt는 AI 답변과 인용 출처를 적어 두는 기록 파일입니다. 같은 질문을 나중에 다시 던졌을 때 무엇이 달라졌는지 비교하려면, 처음 결과를 적어 두어야 합니다. 이 파일은 뒤에서 글을 고친 뒤 결과를 다시 확인할 때 이어서 씁니다.

1.2 – AI 검색에서 답변과 출처 확인하기

평소 쓰는 AI 검색 서비스 하나를 Chrome에서 엽니다. 예: ChatGPT의 검색 기능, Google의 AI 모드, Perplexity.
질문 입력란에 HTML에서 img 태그의 alt 속성은 무엇이고 왜 써야 하나요?를 입력합니다.
Enter 키를 누릅니다.
답변이 나타나면 답변 옆이나 아래에 붙은 출처 표시(링크, 번호, 사이트 이름)를 찾습니다.
aeo_memo.txt의 각 항목에 확인한 날짜, 서비스 이름, 질문, 답변 요약을 적습니다.
출처 표시를 하나씩 클릭해 열린 페이지 주소를 인용된 출처(주소): 줄 아래에 한 줄에 하나씩 붙여 넣습니다.
Ctrl+S(macOS는 ⌘+S)를 눌러 저장합니다.

AI 검색 서비스는 질문을 받으면 웹 문서를 찾아 읽고, 답변과 함께 출처 링크를 보여 주는 서비스입니다. 어느 서비스를 써도 답변 옆에 출처가 붙는다는 점은 같습니다.

방금 본 출처 링크가 AEO가 겨냥하는 자리입니다. AEO(Answer Engine Optimization, 답변 엔진 최적화)는 AI 검색 서비스가 답변을 만들 때 내 글을 근거로 읽고 출처로 인용하도록 글과 페이지를 정리하는 일입니다. 답변 엔진은 질문을 받으면 링크 목록 대신 정리된 답변을 먼저 보여 주는 검색 서비스를 말합니다.

AEO는 SEO와 떨어진 새 기술이 아닙니다. SEO(Search Engine Optimization, 검색 엔진 최적화)는 검색 결과 목록에서 내 페이지가 잘 발견되도록 페이지를 정리하는 일입니다. AI 검색 서비스도 먼저 웹 문서를 찾아 읽은 다음 답변을 쓰므로, 검색 엔진이 찾고 읽을 수 없는 페이지는 인용될 수도 없습니다. 그래서 AEO는 SEO 위에 "답변으로 옮겨 쓰기 쉬운 글"이라는 조건을 하나 더 얹는 일로 이해하면 됩니다.

도서관 사서에 빗대면 차이가 분명해집니다. SEO는 책에 분류 번호를 정확하게 붙여 서가에서 찾히게 하는 일입니다. AEO는 사서가 질문에 답하면서 "이 책 몇 쪽에 나와 있습니다"라고 짚어 줄 수 있도록, 책 안의 답을 찾기 쉬운 자리에 또렷하게 적어 두는 일입니다.

AEO는 업계에서 쓰는 이름이며, 표준 기관이 정한 공식 용어가 아닙니다. 같은 일을 GEO(Generative Engine Optimization, 생성형 엔진 최적화)라고 부르는 곳도 있습니다.

Google은 AI 개요(AI Overviews)와 AI 모드에 나오기 위한 별도 요건이나 특별한 최적화가 없으며, 기존 검색 최적화의 기본이 그대로 적용된다고 밝히고 있습니다. 이 문서의 최적화 방법은 이 원칙과 각 검색 서비스의 공식 안내를 기준으로 삼습니다(2026-09-10 확인, Google Search Central – AI features and your website).

AI 답변은 틀릴 수 있습니다. 출처가 붙어 있어도 그 출처에 실제로 같은 내용이 있는지 열어서 확인합니다. 출처에 없는 내용을 그럴듯하게 지어낸 답변을 환각이라고 합니다.

AI 검색 서비스에는 회사 기밀, 고객 정보, 본인의 개인정보를 입력하지 않습니다. 실습 질문은 누구에게나 공개된 일반 지식으로만 던집니다.

앞에서 AI 답변이 어떤 페이지를 출처로 붙이는지 확인했으니, 이제 인용된 페이지 안에서 답변과 겹치는 문장을 찾아봅니다.

1.3 – 인용된 페이지에서 답변과 겹치는 문장 찾기

aeo_memo.txt에 적은 출처 주소 가운데 첫 번째 주소를 Chrome에서 엽니다.
Ctrl+F(macOS는 ⌘+F)를 누릅니다.
검색창에 alt를 입력하고 Enter 키를 누릅니다.
노란색으로 표시된 자리를 차례로 넘겨 보며, AI 답변과 뜻이 같은 문장을 찾습니다.
찾은 문장 바로 위의 제목이 무엇인지 확인합니다.
찾은 문장이 제목 아래 첫 문장인지, 문단 중간인지 확인합니다.
찾은 문장만 따로 떼어 읽어도 뜻이 통하는지 확인합니다.
5~7에서 확인한 내용을 aeo_memo.txt 맨 아래에 [인용 문장 관찰] 줄을 만들고 그 아래에 적습니다.
두 번째 출처 주소로 1~8을 한 번 더 합니다.

많은 경우 답변과 겹치는 문장은 질문과 비슷한 제목 바로 아래에 있고, 앞뒤 문장 없이 읽어도 뜻이 통합니다. 이 관찰은 AI 검색 서비스가 문장을 고르는 규칙을 밝힌 것이 아니라, 인용된 페이지들에서 자주 보이는 모양입니다.

검색 서비스가 공식으로 밝힌 안내도 같은 방향을 가리킵니다. Microsoft Bing은 AI 답변 인용을 늘리려면 명확한 제목, 표, 자주 묻는 질문 형식으로 구조를 또렷하게 하고, 예시와 데이터와 출처로 주장을 뒷받침하며, 내용을 최신으로 유지하라고 안내합니다(2026-09-10 확인, <a href="https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview">Bing Webmaster Blog – Introducing AI Performance</a>). 다음 단계부터는 이 안내를 실습 페이지에 하나씩 적용합니다.

출처 페이지에서 답변과 겹치는 문장을 찾지 못할 수도 있습니다. AI 답변은 여러 페이지의 내용을 합쳐 새 문장으로 쓰기 때문입니다. 이때는 뜻이 가장 가까운 문단을 찾아 같은 세 가지를 확인합니다.

코칭 프롬프트

여기까지의 내용을 혼자 해 보다 막히면 아래 프롬프트를 대화형 AI(ChatGPT·Claude·Gemini)에 붙여 넣어 한 단계씩 도움을 받습니다.

실습에 쓰던 대화창이 아니라 새 대화창에 붙여 넣습니다. 앞서 AI 검색에 던진 질문과 답변이 남은 대화창에 얹으면 답이 뒤섞입니다.

아래는 AEO(답변 엔진 최적화)의 개념을 스스로 정리하기 위한 요청입니다.
정답을 통째로 주지 말고, 한 번에 질문 하나만 던져 제가 직접 설명하게 해 주세요.
제가 답하면 틀린 부분만 짚고 다음 질문으로 넘어가 주세요.

- AI 검색에 던진 질문: {던진 질문}
- 인용된 출처에서 관찰한 것: {관찰한 것}
- 헷갈리는 점: {헷갈리는 점}

SEO와 AEO의 관계, 출처가 있어도 답변이 틀릴 수 있다는 점처럼
처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

아래는 AEO(답변 엔진 최적화)의 개념을 스스로 정리하기 위한 요청입니다.
정답을 통째로 주지 말고, 한 번에 질문 하나만 던져 제가 직접 설명하게 해 주세요.
제가 답하면 틀린 부분만 짚고 다음 질문으로 넘어가 주세요.

- AI 검색에 던진 질문: HTML에서 img 태그의 alt 속성은 무엇이고 왜 써야 하나요?
- 인용된 출처에서 관찰한 것: 답변과 겹치는 문장이 "alt 속성" 제목 바로 아래 첫 문장이었습니다.
- 헷갈리는 점: AEO를 하면 SEO는 안 해도 되는지 모르겠습니다.

SEO와 AEO의 관계, 출처가 있어도 답변이 틀릴 수 있다는 점처럼
처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

{던진 질문} – AI 검색 서비스에 실제로 입력한 질문을 적습니다. 예: CSS에서 flex와 grid는 무엇이 다른가요?
{관찰한 것} – aeo_memo.txt의 [인용 문장 관찰]에 적은 내용을 옮깁니다. 예: 답변과 겹치는 문장이 표 바로 위 문단에 있었습니다.
{헷갈리는 점} – 정리하다 막힌 점을 한 문장으로 적습니다. 예: 답변 엔진과 검색 엔진이 어떻게 다른지 모르겠습니다.

AI가 설명을 길게 늘어놓으면 “설명 말고, 제가 답할 질문 하나만 주세요”라고 다시 요청합니다. 관찰한 것을 적을 때는 출처 페이지 주소와 그 문장 바로 위 제목을 함께 적어야 AI가 상황을 정확히 파악합니다.

2 – 답을 찾기 쉬운 글로 고쳐 쓰기

2.1 – 실습용 페이지 만들기

aeo_practice 폴더 안에 index.html 파일을 만듭니다.
index.html을 코드 편집기(VS Code 등)로 엽니다.
아래 코드를 그대로 붙여 넣고 저장합니다.
aeo_practice 폴더에서 index.html을 더블클릭해 Chrome으로 엽니다.

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>원두 이야기</title>
</head>
<body>
  <h1>원두 이야기</h1>
  <p>커피를 좋아하는 분들이 많습니다. 저도 매일 아침 커피를 마십니다. 원두는 여러 요인에 영향을 받는데, 공기와 빛과 열과 습기가 대표적이며 이런 것들을 잘 관리해야 맛이 오래가고, 보통 밀폐 용기에 담아 서늘한 곳에 두는 것이 좋다고 알려져 있습니다. 냉동 보관도 할 수 있지만 주의할 점이 있고 냉장 보관은 권하지 않는다는 의견이 많습니다.</p>
  <h2>기타</h2>
  <p>분쇄 원두는 통원두보다 빨리 향이 날아갑니다. 그러니 조금씩 사서 빨리 마시는 게 좋겠죠.</p>
</body>
</html>

화면에 "원두 이야기" 제목과 긴 문단 하나, "기타" 제목과 짧은 문단 하나가 나타납니다. 이 페이지는 가상의 동네 카페 블로그 글이며, 답을 찾기 어려운 글의 모양을 일부러 모아 둔 것입니다.

"원두는 어떻게 보관하나요?"라는 질문의 답은 첫 문단 안에 들어 있습니다. 하지만 답이 자기소개 뒤, 긴 문장 한가운데에 묻혀 있습니다.

"기타"라는 제목은 그 아래에 무엇이 있는지 알려 주지 않습니다. 사람도 이 글에서 답을 찾으려면 문단을 끝까지 읽어야 하고, AI 검색 서비스가 이 문단에서 답만 떼어 옮기기도 어렵습니다. 다음 단계부터 이 페이지를 조금씩 고쳐, 각 변화가 무엇을 바꾸는지 확인합니다.

2.2 – 질문을 제목으로, 답을 첫 문장으로 옮기기

index.html에서 <title>부터 첫 번째 <p>의 끝까지를 아래 코드로 바꿉니다.
저장한 뒤 Chrome에서 F5를 눌러 새로 고칩니다.

  <title>원두 보관 방법 - 밀폐 용기에 담아 서늘하고 어두운 곳에</title>
</head>
<body>
  <h1>원두 보관 방법</h1>
  <h2>원두는 어떻게 보관해야 하나요?</h2>
  <p>원두는 밀폐 용기에 담아 빛이 들지 않는 서늘한 곳에 보관합니다.</p>
  <p>원두의 향과 맛을 떨어뜨리는 요인은 공기, 빛, 열, 습기입니다. 밀폐 용기는 공기와 습기를, 서늘하고 어두운 자리는 빛과 열을 막습니다.</p>

제목이 질문 모양으로 바뀌고, 그 아래 첫 문장이 곧바로 답을 말합니다. 이렇게 답을 먼저 쓰고 이유를 뒤에 붙이는 방식을 두괄식이라고 합니다.

두괄식으로 쓰면 "원두는 어떻게 보관해야 하나요?"라는 질문과 제목이 거의 같은 말이 됩니다. 그 아래 첫 문장은 앞뒤 문장 없이 떼어 읽어도 답이 됩니다. 1.3에서 인용된 문장을 관찰할 때 확인한 모양이 바로 이것입니다.

첫 문장에 자기소개나 배경을 두지 않은 것도 같은 까닭입니다. "커피를 좋아하는 분들이 많습니다" 같은 문장은 글의 분위기를 만들지만, 질문의 답은 아닙니다. 그런 문장이 필요하면 답과 이유를 쓴 다음에 둡니다.

질문 모양 제목은 모든 제목에 쓰는 규칙이 아닙니다. 독자가 실제로 물을 만한 질문이 있는 자리에만 씁니다. 모든 제목을 질문으로 바꾸면 목차가 질문 목록처럼 읽혀 오히려 글의 흐름이 끊깁니다.

앞에서 핵심 답을 첫 문장으로 옮겼으니, 이제 비교와 순서처럼 줄글로 쓰면 찾기 어려운 내용을 표와 목록으로 바꿉니다.

2.3 – 비교는 표로, 순서는 목록으로 바꾸기

index.html에서 <h2>기타</h2>부터 그 아래 <p>의 끝까지를 지웁니다.
지운 자리에 아래 코드를 넣습니다.
저장한 뒤 Chrome에서 F5를 누릅니다.

  <h2>상온, 냉장, 냉동 보관은 무엇이 다른가요?</h2>
  <p>원두는 상온 보관이 기본이며, 오래 두어야 할 때만 냉동 보관을 고릅니다.</p>
  <table>
    <thead>
      <tr><th>보관 장소</th><th>알맞은 때</th><th>주의할 점</th></tr>
    </thead>
    <tbody>
      <tr><td>상온(서늘하고 어두운 곳)</td><td>곧 마실 원두</td><td>가스레인지 옆, 창가처럼 열과 빛이 닿는 자리를 피합니다.</td></tr>
      <tr><td>냉장</td><td>권하지 않음</td><td>문을 여닫을 때마다 온도가 바뀌고 다른 음식 냄새가 뱁니다.</td></tr>
      <tr><td>냉동</td><td>오래 두어야 할 원두</td><td>한 번에 쓸 만큼 나눠 담고, 꺼낸 원두는 다시 넣지 않습니다.</td></tr>
    </tbody>
  </table>

  <h2>냉동한 원두는 어떻게 꺼내 쓰나요?</h2>
  <p>냉동한 원두는 한 번 쓸 만큼만 꺼내 봉지를 연 채로 두지 않고 상온에 둔 다음 씁니다.</p>
  <ol>
    <li>한 번 쓸 만큼 나눠 담은 봉지 하나를 꺼냅니다.</li>
    <li>봉지를 닫은 채로 상온에 둡니다.</li>
    <li>봉지 겉면에 맺힌 물기가 마르면 봉지를 열어 원두를 분쇄합니다.</li>
  </ol>

화면에 보관 장소를 견주는 표와 번호가 붙은 순서 목록이 나타납니다. "기타"라는 제목과 그 아래 짧은 문단은 질문 모양 제목 두 개로 나뉘었습니다.

표는 여러 대상을 같은 기준으로 견주는 내용을 담는 틀입니다. 줄글로 "상온은 이렇고, 냉장은 저렇고"라고 쓰면 읽는 사람이 머릿속에서 기준을 맞춰 가며 읽어야 합니다. 표로 쓰면 같은 줄과 같은 칸이 같은 기준이 돼, 사람도 기계도 "냉장 보관의 주의할 점" 같은 한 칸을 바로 찾습니다.

번호 목록은 차례가 있는 일을 담는 틀입니다. HTML의 <ol>은 "이 항목들은 순서가 있다"는 뜻을 가진 태그라서, 화면 모양뿐 아니라 문서의 뜻까지 전합니다. 표와 목록 위에도 첫 문장에 답을 먼저 두었다는 점을 확인합니다. 표만 덩그러니 두면 그 표가 어떤 질문의 답인지 문장으로 드러나지 않습니다.

표를 그림 파일로 만들어 넣으면 기계가 칸 안의 글자를 읽기 어렵습니다. 비교 내용은 이미지가 아니라 <table> 태그로 적습니다. 이미지로 설명해야 한다면 alt 속성에 이미지가 담은 내용을 글로 적습니다.

앞에서 글의 모양을 정리했으니, 이제 이 글을 누가 언제 어떤 근거로 썼는지 밝혀 믿을 수 있는 글로 만듭니다.

2.4 – 글쓴이, 날짜, 근거 밝히기

index.html에서 <h1>원두 보관 방법</h1> 바로 아래 줄에 아래 첫 번째 코드를 넣습니다.
</body> 바로 위 줄에 아래 두 번째 코드를 넣습니다.
저장한 뒤 Chrome에서 F5를 누릅니다.

첫 번째 코드는 글쓴이와 날짜를 적는 줄입니다.

  <p>글쓴이: 달빛 로스터리 바리스타 김하늘 · 작성일 <time datetime="2026-09-01">2026년 9월 1일</time> · 수정일 <time datetime="2026-09-10">2026년 9월 10일</time></p>

두 번째 코드는 글의 근거를 밝히는 문단입니다.

  <h2>이 글은 무엇을 근거로 썼나요?</h2>
  <p>이 글의 보관 방법은 매장에서 원두를 보관하며 확인한 경험과 원두를 납품받는 로스터리의 보관 안내를 바탕으로 썼습니다.</p>

제목 아래에 글쓴이와 작성일, 수정일이 한 줄로 나타나고, 글 맨 아래에 근거를 밝히는 문단이 나타납니다. "달빛 로스터리"와 "김하늘"은 실습을 위해 지어낸 가상의 이름입니다. 실제 글에는 본인이나 운영하는 곳의 이름을 적습니다.

Google은 좋은 글인지 스스로 따져 볼 질문으로 누가(Who), 어떻게(How), 왜(Why)를 제시합니다. 글쓴이가 누구인지 방문자에게 분명히 보이는지, 자동화나 AI를 써서 만들었다면 그 사실이 드러나는지, 이 글을 무엇보다 사람을 돕기 위해 썼는지가 그 질문입니다(2026-09-10 확인, <a href="https://developers.google.com/search/docs/fundamentals/creating-helpful-content">Google Search Central – Creating helpful, reliable, people-first content</a>). 글쓴이와 날짜와 근거는 이 질문에 페이지 스스로 답하는 장치입니다.

<time> 태그는 사람이 읽는 날짜와 기계가 읽는 날짜를 함께 적는 태그입니다. datetime 속성에는 2026-09-10처럼 정해진 형식의 날짜를 적고, 태그 사이에는 사람이 읽기 편한 날짜를 적습니다. 수정일을 따로 적어 두면, 읽는 사람도 기계도 이 정보가 언제 기준인지 알 수 있습니다.

날짜만 바꾸고 내용은 그대로 두는 것은 바람직하지 않습니다. 수정일은 내용을 실제로 고친 날에만 바꿉니다. 날짜와 내용이 어긋나면 읽는 사람이 글 전체를 믿지 않게 됩니다.

근거로 다른 사람의 글을 옮길 때는 짧게 인용하고 출처를 밝힙니다. 남의 글을 통째로 붙여 넣으면 저작권을 침해할 수 있습니다.

코칭 프롬프트

여기까지의 내용을 혼자 해 보다 막히면 아래 프롬프트를 대화형 AI(ChatGPT·Claude·Gemini)에 붙여 넣어 한 단계씩 도움을 받습니다.

실습에 쓰던 대화창이 아니라 새 대화창에 붙여 넣습니다. 앞서 다른 요청을 시킨 대화창에는 그 요청의 응답이 남아 있어, 그 위에 얹으면 답이 뒤섞입니다.

아래는 제 글을 AI 검색이 답을 찾기 쉬운 구조로 고쳐 쓰는 연습을 점검받기 위한 요청입니다.
고친 글을 대신 써 주지 말고, 한 번에 고칠 자리 하나만 짚어 주세요.
제가 직접 고친 문장을 보내면 그때 다음 자리를 짚어 주세요.

- 글의 주제: {글의 주제}
- 독자가 물을 만한 질문: {독자 질문}
- 지금 쓴 제목과 첫 문장: {제목과 첫 문장}

첫 문장에 답이 아니라 배경이 먼저 나오는 문제, 비교 내용을 줄글로 쓴 문제,
글쓴이와 날짜와 근거가 빠진 문제처럼 처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

아래는 제 글을 AI 검색이 답을 찾기 쉬운 구조로 고쳐 쓰는 연습을 점검받기 위한 요청입니다.
고친 글을 대신 써 주지 말고, 한 번에 고칠 자리 하나만 짚어 주세요.
제가 직접 고친 문장을 보내면 그때 다음 자리를 짚어 주세요.

- 글의 주제: 반려 식물 물 주기
- 독자가 물을 만한 질문: 몬스테라는 며칠마다 물을 줘야 하나요?
- 지금 쓴 제목과 첫 문장: 제목 "우리 집 초록이들", 첫 문장 "식물을 키운 지 벌써 3년이 되었습니다."

첫 문장에 답이 아니라 배경이 먼저 나오는 문제, 비교 내용을 줄글로 쓴 문제,
글쓴이와 날짜와 근거가 빠진 문제처럼 처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

{글의 주제} – 고쳐 쓸 글이 다루는 주제를 적습니다. 예: 원두 보관 방법.
{독자 질문} – 독자가 이 글에서 답을 찾으려고 던질 질문을 적습니다. 예: 냉동한 원두는 어떻게 꺼내 쓰나요?
{제목과 첫 문장} – 지금 쓴 제목과 그 아래 첫 문장을 그대로 옮깁니다. 예: 제목 "기타", 첫 문장 "분쇄 원두는 통원두보다 빨리 향이 날아갑니다."

AI가 글 전체를 고쳐 쓴 결과를 내놓으면 “고친 글 말고, 지금 글에서 가장 먼저 고칠 한 자리만 알려 주세요”라고 다시 요청합니다. 회사 내부 문서나 개인정보가 담긴 글은 붙여 넣지 않고, 공개해도 되는 글로만 연습합니다.

3 – 기계가 읽는 신호 정리하기

3.1 – 구조화 데이터 넣기

index.html에서 </head> 바로 위 줄에 아래 코드를 넣습니다.
저장한 뒤 Chrome에서 F5를 누릅니다.

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "원두 보관 방법",
    "datePublished": "2026-09-01T09:00:00+09:00",
    "dateModified": "2026-09-10T09:00:00+09:00",
    "author": {
      "@type": "Person",
      "name": "김하늘"
    }
  }
  </script>

화면에는 아무 변화가 없습니다. 이 코드는 사람에게 보이지 않고, 페이지를 읽는 프로그램에게만 전달되기 때문입니다.

구조화 데이터는 페이지의 내용을 정해진 형식으로 요약해 프로그램에게 알려 주는 코드입니다. 여기서 쓴 형식은 JSON-LD이며, 표시할 이름표는 schema.org라는 공개 어휘에서 가져옵니다. "@type": "BlogPosting"은 이 페이지가 블로그 글이라는 뜻이고, headline, datePublished, dateModified, author는 각각 제목, 작성일, 수정일, 글쓴이를 뜻합니다.

값을 2.4에서 화면에 적은 내용과 똑같이 맞춘 것을 확인합니다. 구조화 데이터에는 화면에 보이는 내용만 적어야 합니다. 화면에는 없는 내용을 구조화 데이터에만 적으면, 사람이 보는 페이지와 기계가 읽는 페이지가 서로 다른 말을 하게 됩니다.

Google은 AI 개요와 AI 모드에 나오기 위해 따로 넣어야 할 schema.org 구조화 데이터나 AI용 텍스트 파일은 없다고 밝히고 있습니다. 구조화 데이터는 AI 답변에 인용되게 하는 스위치가 아니라, 페이지 내용을 프로그램이 오해 없이 읽게 돕는 보조 장치입니다(2026-09-10 확인, Google Search Central – AI features and your website, Article 구조화 데이터).

예전에 많이 권하던 FAQ 구조화 데이터(FAQPage)의 Google 검색 리치 결과는 2026년 5월 7일부터 표시되지 않습니다. FAQ 구조화 데이터를 넣어도 Google 검색 화면에 질문과 답이 펼쳐지지 않으므로, 이 효과를 기대하고 넣지 않습니다(2026-09-10 확인, Google Search Central – FAQ).

앞에서 넣은 구조화 데이터는 문법이 하나만 틀려도 프로그램이 통째로 읽지 못하므로, 이제 검사 도구로 오류가 없는지 확인합니다.

3.2 – 구조화 데이터 검사하기

Chrome 주소창에 https://validator.schema.org/를 입력하고 Enter 키를 누릅니다.
화면 위쪽의 두 탭 가운데 코드를 직접 붙여 넣는 탭(Code Snippet)을 클릭합니다.
index.html의 내용을 처음부터 끝까지 선택해 복사합니다.
입력란에 붙여 넣습니다.
입력란 아래의 검사 실행 버튼(Run test)을 클릭합니다.
오른쪽 결과 영역에 BlogPosting 항목이 나타나는지 확인합니다.
오류(Errors)와 경고(Warnings) 개수를 aeo_memo.txt 맨 아래에 [구조화 데이터 검사] 줄을 만들고 적습니다.

오른쪽 결과 영역에 BlogPosting이 나타나면, 검사 도구가 이 페이지를 블로그 글로 읽었다는 뜻입니다. 그 아래를 펼치면 headline, datePublished 같은 속성과 값이 목록으로 보입니다. 여기 보이는 값이 곧 프로그램이 이 페이지에서 읽어 가는 정보입니다.

오류가 나오면 대부분 쉼표나 따옴표 문제입니다. JSON에서는 마지막 속성 뒤에 쉼표를 붙이면 안 되고, 모든 이름과 글자 값을 곧은 큰따옴표(")로 감싸야 합니다. 오류 줄을 클릭하면 코드에서 문제가 난 자리가 표시되므로, 그 자리를 고치고 5를 다시 합니다.

Schema Markup Validator는 schema.org 문법이 맞는지만 검사합니다. Google 검색에서 특별한 모양으로 표시될 수 있는지는 Google의 리치 결과 테스트(https://search.google.com/test/rich-results)에서 따로 확인합니다. 화면의 탭과 버튼 이름은 도구가 바뀌면 달라질 수 있습니다(2026-09-10 기준).

구조화 데이터로 페이지 안의 신호를 정리했으니, 이제 페이지 밖에서 AI 크롤러가 이 사이트를 읽어도 되는지 정하는 파일을 다룹니다.

3.3 – robots.txt로 AI 크롤러 허용 여부 정하기

Chrome 주소창에 https://www.google.com/robots.txt를 입력하고 Enter 키를 누릅니다.
화면에 나타난 글에서 User-agent:로 시작하는 줄과 Disallow:, Allow:로 시작하는 줄을 찾아봅니다.
aeo_practice 폴더 안에 robots.txt 파일을 만듭니다.
아래 내용을 그대로 붙여 넣고 저장합니다.

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Allow: /

robots.txt는 사이트 맨 위 주소에 두는 글 파일로, 크롤러에게 어느 주소를 읽어도 되는지 알려 주는 규칙을 적습니다. 크롤러는 웹 페이지를 자동으로 돌아다니며 내용을 가져가는 프로그램입니다. User-agent: 줄은 규칙을 적용할 크롤러 이름이고, 그 아래 Allow: /는 모든 주소 허용, Disallow: /는 모든 주소 차단을 뜻합니다.

AI 크롤러는 하는 일에 따라 이름이 나뉩니다. 그래서 "AI 검색 답변에는 나오되, AI 모델 학습에는 쓰이지 않게" 같은 선택을 크롤러 이름별로 할 수 있습니다. 위 파일은 그 선택의 한 예이며, 어떻게 정할지는 사이트 운영 방침에 따라 다릅니다.

크롤러 이름	하는 일	차단하면
`OAI-SearchBot`	ChatGPT 검색 답변에 사이트를 보여 주기 위해 읽습니다	ChatGPT 검색 답변에 나오지 않습니다(이동용 링크로는 나올 수 있음)
`GPTBot`	OpenAI의 AI 모델 학습에 쓸 수 있는 내용을 읽습니다	학습에 쓰지 말라는 뜻이 전달됩니다
`PerplexityBot`	Perplexity 검색 결과에 사이트를 보여 주기 위해 읽습니다	Perplexity 검색 결과에 링크가 나오기 어렵습니다
`Google-Extended`	Gemini 모델 학습과 Gemini 앱의 근거 자료에 쓸지를 정하는 이름입니다	Google 검색 노출과 순위에는 영향이 없습니다

표는 각 회사의 공식 안내를 옮긴 것입니다(2026-09-10 확인, <a href="https://developers.openai.com/api/docs/bots">OpenAI crawlers</a>, <a href="https://docs.perplexity.ai/guides/bots">Perplexity crawlers</a>, <a href="https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers">Google common crawlers</a>). Google의 AI 개요와 AI 모드는 일반 Google 검색과 같은 크롤러를 쓰므로, 그 크롤러(Googlebot)를 막으면 AI 답변뿐 아니라 검색 결과 전체에서 빠집니다.

User-agent: * 아래에 Disallow: /를 적으면 모든 크롤러가 사이트 전체를 읽지 않습니다. 검색 결과와 AI 답변에서 함께 사라지므로, 이 두 줄은 사이트를 통째로 숨길 때만 씁니다.

robots.txt는 약속을 적은 파일이지 잠금장치가 아닙니다. 사용자가 AI에게 특정 페이지를 열어 달라고 요청할 때 쓰이는 ChatGPT-User, Perplexity-User는 robots.txt 규칙을 따르지 않을 수 있다고 각 회사가 밝히고 있습니다.

실습용 robots.txt는 폴더 안에만 있으므로 실제로 작동하지 않습니다. 운영하는 사이트가 있다면 사이트 주소 뒤에 /robots.txt를 붙여 열어 보고, 지금 적힌 규칙이 의도와 맞는지 먼저 확인합니다. 워드프레스 같은 사이트 관리 도구는 이 파일을 자동으로 만드는 경우가 많으므로, 고치기 전에 그 도구의 설정 화면부터 확인합니다.

코칭 프롬프트

여기까지의 내용을 혼자 해 보다 막히면 아래 프롬프트를 대화형 AI(ChatGPT·Claude·Gemini)에 붙여 넣어 한 단계씩 도움을 받습니다.

아래는 구조화 데이터(JSON-LD)와 robots.txt 실습을 스스로 마치기 위한 요청입니다.
고친 코드를 통째로 주지 말고, 한 번에 다음 한 단계만 알려 주세요.
제가 그 단계를 해 본 뒤 결과를 적으면 그때 다음 단계를 알려 주세요.

- 지금까지 한 것: {지금까지 한 것}
- 막힌 지점과 검사 도구에 나온 메시지: {막힌 지점}
- AI 크롤러를 어떻게 다룰지 정한 방침: {크롤러 방침}

먼저 막힌 까닭이 무엇인지 한 가지로 짚어 주세요.
마지막 속성 뒤 쉼표, 굽은 따옴표, 화면에 없는 내용을 구조화 데이터에만 적은 문제,
검색 크롤러와 학습 크롤러를 헷갈린 문제처럼 처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

아래는 구조화 데이터(JSON-LD)와 robots.txt 실습을 스스로 마치기 위한 요청입니다.
고친 코드를 통째로 주지 말고, 한 번에 다음 한 단계만 알려 주세요.
제가 그 단계를 해 본 뒤 결과를 적으면 그때 다음 단계를 알려 주세요.

- 지금까지 한 것: index.html의 head에 BlogPosting 구조화 데이터를 넣고 Schema Markup Validator에 붙여 넣었습니다.
- 막힌 지점과 검사 도구에 나온 메시지: BlogPosting 항목이 나오지 않고 오류가 1건 나옵니다.
- AI 크롤러를 어떻게 다룰지 정한 방침: AI 검색 답변에는 나오고 싶지만 AI 학습에는 쓰이고 싶지 않습니다.

먼저 막힌 까닭이 무엇인지 한 가지로 짚어 주세요.
마지막 속성 뒤 쉼표, 굽은 따옴표, 화면에 없는 내용을 구조화 데이터에만 적은 문제,
검색 크롤러와 학습 크롤러를 헷갈린 문제처럼 처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

{지금까지 한 것} – 어디까지 했는지 적습니다. 예: 구조화 데이터를 넣고 검사까지 했습니다.
{막힌 지점} – 검사 도구에 나온 메시지를 그대로 옮깁니다. 예: Missing '}' or object member name.
{크롤러 방침} – AI 크롤러를 어떻게 다루고 싶은지 한 문장으로 적습니다. 예: 모든 AI 크롤러를 허용하고 싶습니다.

AI가 고친 JSON-LD를 통째로 내놓으면 “코드 말고, 제 코드에서 몇 번째 줄을 고쳐야 하는지만 알려 주세요”라고 다시 요청합니다. 크롤러 이름과 역할은 회사가 바꿀 수 있으므로, AI가 알려 준 이름은 3.3 표의 공식 안내 주소에서 한 번 더 확인합니다.

4 – 결과 확인하고 다시 고치기

4.1 – 검색 도구 보고서에서 AI 노출 확인하기

운영하는 사이트가 Google Search Console에 등록돼 있으면 https://search.google.com/search-console을 엽니다.
왼쪽 메뉴에서 [실적]을 클릭합니다.
화면 위쪽의 검색 유형이 [웹]인지 확인합니다.
그래프 아래 표의 [페이지] 탭을 클릭해 고친 글의 노출수와 클릭수를 확인합니다.
운영하는 사이트가 Bing Webmaster Tools에 등록돼 있으면 https://www.bing.com/webmasters를 엽니다.
왼쪽 메뉴에서 AI 성과 보고서(AI Performance)를 클릭합니다.
고친 글 주소가 페이지별 인용 수 목록에 있는지 확인합니다.
2~7에서 확인한 숫자를 aeo_memo.txt 맨 아래에 [검색 도구 보고서] 줄을 만들고 날짜와 함께 적습니다.

Google Search Console은 AI 개요와 AI 모드에서 생긴 노출과 클릭을 따로 나누지 않고 [웹] 검색 유형의 전체 수치에 함께 셉니다(2026-09-10 확인, <a href="https://developers.google.com/search/docs/appearance/ai-features">Google Search Central – AI features and your website</a>). 그래서 Google 쪽에서는 "AI 답변에 몇 번 인용됐는지"를 숫자 하나로 볼 수 없고, 고친 글의 전체 노출과 클릭이 어떻게 달라지는지로 가늠합니다.

Bing Webmaster Tools의 AI 성과 보고서는 Copilot 같은 Microsoft의 AI 답변에 내 사이트가 출처로 인용된 횟수를 보여 줍니다. 총 인용 수, 하루 평균 인용 페이지 수, AI가 내용을 찾을 때 쓴 검색어(Grounding Queries), 페이지별 인용 수를 볼 수 있습니다(2026-09-10 확인, <a href="https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview">Bing Webmaster Blog – Introducing AI Performance</a>). AI가 쓴 검색어를 보면, 독자가 실제로 어떤 질문으로 내 글에 닿는지 알 수 있어 다음에 질문 모양 제목을 정할 때 참고가 됩니다.

Bing의 AI 성과 보고서는 2026년 2월 공개 미리 보기(Public Preview)로 시작한 기능입니다. 메뉴 이름과 위치, 보여 주는 항목은 바뀔 수 있으므로 화면이 다르면 위 공식 안내 주소에서 최신 내용을 확인합니다.

운영하는 사이트가 없으면 이 단계는 읽고 넘어가도 됩니다. 두 도구 모두 사이트 소유를 확인한 계정에서만 보고서를 볼 수 있습니다.

검색 도구 보고서는 숫자가 쌓이는 데 시간이 걸리므로, 바로 확인할 수 있는 AI 답변 쪽으로 돌아가 처음 기록과 비교합니다.

4.2 – AI 답변 다시 확인하고 기록 비교하기

1.2에서 쓴 AI 검색 서비스를 다시 엽니다.
1.2에서 던진 질문을 글자 하나 바꾸지 않고 그대로 입력합니다.
새 답변의 요약과 인용 출처 주소를 aeo_memo.txt 맨 아래에 1.2와 같은 형식으로 한 벌 더 적습니다.
처음 기록과 새 기록을 나란히 놓고 인용 출처 주소가 달라졌는지 비교합니다.
새 답변의 출처를 하나씩 열어, 답변 내용이 출처 페이지의 문장과 맞는지 확인합니다.
운영하는 사이트가 있으면 직접 고친 글에도 질문을 하나 정해 같은 방식으로 기록합니다.

같은 질문에도 AI 답변과 인용 출처는 날마다 달라질 수 있습니다. AI 검색 서비스가 읽는 웹 문서가 계속 바뀌고, 답변을 만드는 방식도 서비스마다 다르기 때문입니다. 그래서 한 번의 결과로 성패를 가르지 않고, 같은 질문을 일정한 간격으로 다시 던져 기록을 쌓아 흐름을 봅니다.

기록을 쌓으면 어떤 글이 자주 인용되는지, 인용된 문장이 어떤 모양인지가 보입니다. 자주 인용되는 글의 모양을 다른 글에 옮겨 적용하는 것이 AEO를 이어 가는 가장 확실한 방법입니다.

지금까지 한 작업이 제대로 됐는지 아래 다섯 가지로 따져 봅니다. 세 가지 이상 맞으면 이 과정을 마친 것으로 봅니다.

독자가 물을 만한 질문이 있는 자리에는 질문 모양 제목이 있고, 그 아래 첫 문장만 떼어 읽어도 답이 됩니다.
여러 대상을 견주는 내용은 표에, 차례가 있는 일은 번호 목록에 담겨 있습니다.
글쓴이, 작성일과 수정일, 근거가 화면에 보입니다.
구조화 데이터 검사에서 오류가 나오지 않고, 구조화 데이터의 값이 화면에 보이는 내용과 같습니다.
robots.txt의 AI 크롤러 규칙이 정한 방침과 맞고, AI 답변 기록이 날짜와 함께 aeo_memo.txt에 쌓여 있습니다.

코칭 프롬프트

여기까지의 내용을 혼자 해 보다 막히면 아래 프롬프트를 대화형 AI(ChatGPT·Claude·Gemini)에 붙여 넣어 한 단계씩 도움을 받습니다.

실습에 쓰던 대화창이 아니라 새 대화창에 붙여 넣습니다. 앞서 AI 검색에 던진 질문과 답변이 남은 대화창에 얹으면 답이 뒤섞입니다.

아래는 AI 답변 기록을 비교해 다음에 고칠 점을 스스로 찾기 위한 요청입니다.
결론을 대신 내리지 말고, 한 번에 질문 하나만 던져 제가 기록에서 직접 찾게 해 주세요.
제가 답하면 그 답을 바탕으로 다음 질문을 던져 주세요.

- 비교한 질문: {비교한 질문}
- 처음 기록과 새 기록의 차이: {기록 차이}
- 다음에 고치려는 글: {고칠 글}

한 번의 결과로 성패를 단정하는 문제, 출처를 열어 보지 않고 답변을 믿는 문제처럼
처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

아래는 AI 답변 기록을 비교해 다음에 고칠 점을 스스로 찾기 위한 요청입니다.
결론을 대신 내리지 말고, 한 번에 질문 하나만 던져 제가 기록에서 직접 찾게 해 주세요.
제가 답하면 그 답을 바탕으로 다음 질문을 던져 주세요.

- 비교한 질문: HTML에서 img 태그의 alt 속성은 무엇이고 왜 써야 하나요?
- 처음 기록과 새 기록의 차이: 인용 출처 세 곳 가운데 한 곳이 다른 사이트로 바뀌었습니다.
- 다음에 고치려는 글: 제 블로그의 "시맨틱 태그 정리" 글

한 번의 결과로 성패를 단정하는 문제, 출처를 열어 보지 않고 답변을 믿는 문제처럼
처음 배우는 사람이 자주 놓치는 부분이 보이면 그 자리를 짚어 주세요.

{비교한 질문} – 1.2와 4.2에서 똑같이 던진 질문을 적습니다. 예: CSS에서 flex와 grid는 무엇이 다른가요?
{기록 차이} – 두 기록을 비교해 달라진 점을 적습니다. 예: 답변은 같지만 출처 순서가 바뀌었습니다.
{고칠 글} – 다음에 고쳐 쓸 글의 제목을 적습니다. 예: 원두 보관 방법.

AI가 “이렇게 하면 반드시 인용됩니다” 같은 단정을 내놓으면 “그 근거가 되는 공식 문서 주소를 알려 주세요”라고 다시 요청합니다. 근거 주소를 대지 못하는 방법은 추측으로 보고 기록에 따로 표시합니다.

1 – AEO 알아보기

1.1 – 작업 환경 준비

1.2 – AI 검색에서 답변과 출처 확인하기

1.3 – 인용된 페이지에서 답변과 겹치는 문장 찾기

코칭 프롬프트

2 – 답을 찾기 쉬운 글로 고쳐 쓰기

2.1 – 실습용 페이지 만들기

2.2 – 질문을 제목으로, 답을 첫 문장으로 옮기기

2.3 – 비교는 표로, 순서는 목록으로 바꾸기

2.4 – 글쓴이, 날짜, 근거 밝히기

코칭 프롬프트

3 – 기계가 읽는 신호 정리하기

3.1 – 구조화 데이터 넣기

3.2 – 구조화 데이터 검사하기

3.3 – robots.txt로 AI 크롤러 허용 여부 정하기

코칭 프롬프트

4 – 결과 확인하고 다시 고치기

4.1 – 검색 도구 보고서에서 AI 노출 확인하기

4.2 – AI 답변 다시 확인하고 기록 비교하기

코칭 프롬프트

댓글 남기기 응답 취소