상세문의
×
간편문의
홍은표 · 넥스트티 대표 · SEO/GEO 컨설턴트 | 작성 2026-05-24
실험 노트 · 진행 중
이 글은 결론이 난 글이 아니라, 진행 중인 실험 기록입니다. 시작은 단순했습니다 — 한 AI에게 우리 포트폴리오 URL을 줬더니 가져오긴 했는데 메뉴가 너무 무거워 뒤의 포트폴리오 내용이 잘 안 잡혔습니다. "한 번에 가져오는데 왜 안 보이지?"에서 출발해 HTML을 실측·개선했습니다. 그 효과(AI 인용 변화)는 아직 단정하지 않고, 관측되는 대로 이 글에 단계적으로 갱신합니다. 지금 공개하는 건 누구나 소스 보기로 재현할 수 있는 HTML 구조 수치뿐입니다.
결론부터
우리 포트폴리오 페이지를 열어 보니, 메뉴(GNB)가 HTML의 76%, 본문은 4%였습니다. 사람은 메뉴를 hover로만 보지만, AI는 HTML을 한 번에 받아도 — 텍스트로 추출·요약하는 단계에서 앞·무거운 메뉴가 토큰(AI가 한 번에 읽는 분량)을 차지해 뒤의 본문을 잘라내거나 묻습니다.
SAME HTML, READ DIFFERENTLY
사람에게 GNB는 마우스를 올려야 펼쳐지는 가벼운 UI입니다. AI 크롤러는 HTML을 한 번에 받지만, 받은 코드를 텍스트로 추출·요약하는 단계가 따로 있습니다. 정교한 크롤러는 메뉴(boilerplate — 전 페이지에 반복되는 머리·꼬리 영역)를 어느 정도 걸러낼 수 있지만 완벽하지 않고, 실시간 답변용 fetch나 단순 추출 환경에서는 메뉴 텍스트가 본문과 함께 들어갈 수 있습니다. 그래서 메뉴가 본문보다 많고 앞서면, 추출·요약 처리 한도에서 본문 신호가 묻히거나 잘립니다.
THE PROBLEM
메뉴를 접어 두는 건 사람의 눈에만 통합니다. AI엔 접힘/펼침이 없어, 추출된 텍스트엔 메뉴가 본문과 함께(보통 앞에) 담깁니다. 그 결과는 세 가지입니다.
DIAGNOSIS (BEFORE)
우리 포트폴리오 페이지의 HTML(약 294KB)을 영역별로 쟀습니다. 추측이 아니라 바이트 단위 실측입니다.
신호 대 잡음 비율이 본문 4% : 메뉴 76% — 본문보다 앞에 메뉴 223KB가 놓여, 추출·요약 처리 한도에서 본문이 밀리기 쉬운 구조였습니다. 가장 강력한 트랙레코드 페이지가, 정작 AI에겐 가장 안 보이는 셈이었습니다.
WHAT WE DID
UI는 그대로 두고, AI가 읽는 순서·비중만 바꿨습니다.
1. 신호 분리
본문을 <main>으로 감싸고, 메뉴는 <nav>로 표시 — "여기는 본문, 저기는 메뉴"를 명시. (data-nosnippet은 검색 스니펫 제외용 보조 신호.)
2. 노이즈 제거
화면에 보이기 전엔 초기 HTML에서 빼고, 첫 상호작용(hover/탭)이나 브라우저 유휴 시점에 한 번 불러옵니다. 메뉴 동작은 동일.
3. 반복 제거
전 페이지에 반복되던 메뉴 CSS를 외부 캐시 파일로 분리 — 매 페이지 HTML이 가벼워집니다.
발견성은 그대로, 클로킹도 아닙니다. 상위 메뉴 링크는 HTML에 남기고, 하위 링크는 푸터·sitemap.xml·llms.txt(AI용 사이트 안내 파일)·사이트맵 페이지에 모두 있어 크롤러가 전 페이지를 발견합니다. 같은 메뉴를 모두에게 제공하되 무거운 부분만 나중에 부르는 것이라, 사용자와 크롤러에게 다른 내용을 보이는 클로킹과는 다릅니다.
FOR DEVELOPERS — 구현 예시
실제 적용 방식의 최소 골격입니다(모바일 아코디언·캐시 헤더 등 세부는 생략).
① 메가메뉴 lazy-load — 무거운 패널을 첫 hover 또는 유휴 시점에 한 번만
<!-- 초기 HTML: 무거운 패널은 비워 둔다(껍데기만) -->
<nav class="mega" data-gnb-lazy></nav>// 첫 hover(또는 유휴) 때 한 번만 메뉴 조각을 불러온다
const mega = document.querySelector('.mega');
let loaded = false;
function loadMega() {
if (loaded) return; loaded = true;
fetch('/gnb-mega.php') // 메뉴 HTML 조각
.then(r => r.text())
.then(html => { mega.innerHTML = html; });
}
mega.addEventListener('mouseover', loadMega, { once: true });
// 모바일: 첫 탭 또는 메뉴 버튼 클릭 시 loadMega() 호출
window.requestIdleCallback?.(loadMega); // 초기 HTML 이후, 브라우저 유휴 시점에 지연 로딩② 시맨틱 분리 — "여기는 메뉴, 저기가 본문"
<nav data-nosnippet>…메뉴…</nav> <!-- 검색 스니펫 제외(보조 신호) -->
<main id="content">…본문…</main> <!-- 여기가 진짜 신호 -->data-nosnippet은 메뉴를 검색 스니펫에서 빼 달라는 보조 신호일 뿐이고, 본문 비중 자체는 ①의 lazy-load와 CSS 외부화가 만듭니다. 프로덕션 적용 시 Cache-Control 헤더와 fetch 실패 시 fallback을 함께 설계하세요.
RESULT — HTML 구조 (재현 가능)
아래 수치는 모두 페이지 소스 보기(View Source)로 누구나 재현할 수 있는 공개 사실입니다.
| 항목 | 개선 전 | 개선 후 |
|---|---|---|
| 페이지 HTML 총량 | 293.7 KB | 132.7 KB (−55%) |
| 메뉴(GNB)가 차지하는 비중 | 76% | 29% |
| 본문 비중 | 4% | 10% |
| 본문보다 앞에 놓인 메뉴(잡음) | 223 KB | 39 KB |
| 초기 HTML 링크 수 | 317개 | 136개 |
시맨틱 <main> | 없음 | 있음 |
본문의 절대 분량은 그대로지만, 페이지가 절반으로 줄고 본문 비중이 올라 추출·요약 처리 한도에서 본문이 살아남을 가능성이 커집니다.
WHAT WE DON'T CLAIM
이 글은 결론이 난 글이 아니라 진행 중인 실험 기록입니다. "이 개선으로 AI 인용이 N배 늘었다"고 말하지 않습니다 — 지금 공개할 수 있는 건 HTML 구조라는 재현 가능한 사실뿐이고, 인용 변화는 관측 중으로 두고 관측되는 대로 이 글에 단계적으로 갱신합니다.
두 가지 더 정직하게 — ① lazy-load로 뒤로 뺀 하위 링크가 GNB에 있을 때와 동일하게 평가된다고 단정하지 않습니다(링크 가중치는 다를 수 있어, 실제 발견 여부는 수집 로그로 확인). ② 푸터의 반복 링크는 본문 뒤라 덜 치명적이지만 여전히 관찰 대상입니다. 모두 관측과 추정의 경계 원칙의 자기적용입니다.
CHECK YOUR OWN SITE
<main> 태그가 있는지, 메뉴가 본문보다 양이 많지 않은지 확인하세요.참고 — 거친 신호등(절대 기준 아님): 우리 사이트 진단 기준으로 본문 비중 10% 이상이면 안전권, 5% 미만이면 점검 필요로 봅니다. 사이트 유형에 따라 다를 수 있어 절대 기준은 아닙니다. 우리 페이지는 본문 4%→10%로 올렸고, 숫자 자체보다 "본문이 메뉴보다 뒤·적게 놓였는가"가 핵심입니다.
메뉴를 없애라는 게 아닙니다 — 본문이 메뉴에 묻히지 않게 순서·비중을 조정하라는 것입니다.
FAQ
메뉴 자체가 나쁜 게 아니라, 본문보다 양이 많으면 문제입니다. AI 크롤러는 HTML을 한 번에 받지만, 텍스트로 추출·요약하는 단계에서 메뉴(boilerplate)를 완벽히 걸러내지는 못합니다. 메뉴가 본문보다 많고 앞서면 본문 신호가 희석되고, 토큰(컨텍스트) 한도 안에서 본문이 뒤로 밀려 잘릴 수 있습니다.
초기 HTML에서 무거운 메가패널을 빼도 발견성은 손실되지 않습니다. 상위 내비 링크는 그대로 두고, 하위 링크는 푸터·sitemap.xml·llms.txt·사이트맵 페이지에 모두 있어 크롤러가 전 페이지를 발견합니다.
아닙니다. 사용자와 크롤러에게 다른 콘텐츠를 보여주는 게 클로킹입니다. 여기서는 같은 메뉴를 모두에게 제공하되 무거운 패널을 첫 상호작용 때 불러오는 lazy-load일 뿐, 본문 콘텐츠는 동일합니다.
단정하지 않습니다. 공개 가능한 사실은 HTML 구조 수치(본문 4%→10%, 페이지 293KB→133KB)이며 누구나 소스 보기로 재현할 수 있습니다. 인용 변화는 관측 중이며, 관측되면 추정과 분리해 보고합니다.
맺으며
솔직히 말씀드리면, 이 글도 우리 사이트도 100% 완벽하지 않습니다. 여기 적은 크롤러 메커니즘 설명조차 더 엄밀히 다듬을 여지가 있고(엔진마다 동작이 다릅니다), 사람이 하는 일이라 실수는 늘 존재합니다.
우리는 "완벽하다"고 말하려는 게 아닙니다 — 완벽을 향해 지금도 고치는 중이고, 멈추지 않고 계속 진화하기를 바랄 뿐입니다. 그래서 더 정확한 지적이 있다면 환영합니다. 그 지적 또한 이 글을 다음 단계로 여는 하나의 관측이 되니까요.
RELATED CONTENT
학습 깊이와 도입 단계에 맞춘 추천
UI는 그대로, AI가 읽는 비중만 바꿉니다
본문이 메뉴에 묻혀 AI가 못 읽고 있지 않은지 — 페이지 구조부터 진단해 드립니다.