SEO 진단툴이 시킨 대로 고치기 전에 — 「텍스트 비율 0.7%」의 진짜 원인은 글이 아니었습니다

안녕하세요. Jay입니다!

사이트 주소만 넣으면 점수와 "지금 가장 중요한 3가지"를 뽑아 주는 SEO 진단 도구, 한 번쯤 돌려 보셨을 겁니다. 저도 직접 운영하는 도구 사이트를 넣어 봤는데, 이런 결과가 나왔습니다.

진단 항목	감점	도구의 처방
검색 결과 설명 길이 부적정	-10점	70~120자로 줄여라
AI 안내 파일(llms.txt) 없음	-20점	루트에 올려라
본문 대 코드 비율 0.7%	-15점	글을 늘리고 스크립트를 줄여라

항목마다 "대신 고쳐 드릴게요 · 9,900원~" 버튼이 붙어 있었습니다. 고치기 전에 세 가지를 하나씩 직접 재 봤고, 결론은 이랬습니다. 하나는 무시, 하나는 해도 그만, 하나는 진짜 문제 — 그런데 진짜 문제의 원인은 도구가 말한 것과 달랐습니다.

📏 ① 설명문 길이 — 따르지 않았습니다

홈 설명문은 153자였습니다. 도구는 70~120자로 줄이라고 했죠.

그런데 흔히 도는 권장 길이는 대부분 영문 기준이고, 한글은 검색 결과에서 8090자 근처에서 잘립니다. 저는 지난번 Bing 경고 50건을 실측해서 기준을 한글 130170자, 핵심은 앞 80자 안에로 잡아 두었습니다. 120자로 줄이면 "도구 60개·6개 카테고리·로그인 없이" 같은 정보가 빠질 뿐입니다.

✅ 실측 근거가 있는 기준과 도구의 일반론이 부딪히면, 근거 쪽을 따릅니다.

🤖 ② llms.txt — 30분짜리, 기대는 낮게

llms.txt는 사이트 소개와 주요 페이지 목록을 마크다운으로 적어 루트(/llms.txt)에 두자는 제안 단계의 관례입니다. 2024년 9월 Answer.AI의 제레미 하워드가 제안했습니다.

없는 건 사실이었지만, 주요 AI 검색이 이 파일을 실제로 읽어 간다고 공식적으로 밝힌 곳은 아직 찾기 어렵습니다. "-20점"은 과장이라고 봤습니다. 다만 만드는 비용이 거의 없어서 추가했습니다.

• 손으로 쓰지 않고 메뉴 데이터·카테고리 설명·블로그 목록에서 빌드할 때 자동 생성하게 했습니다
• 손으로 쓴 목록은 도구가 늘 때마다 어긋나기 때문입니다

🔍 ③ 텍스트 비율 0.7% — 진짜 원인은 「글이 적어서」가 아니었다

도구의 처방은 "글을 늘려라"였습니다. 하지만 홈은 원래 도구 목록이 본문인 페이지라 글을 늘릴 이유가 없습니다. 그래서 HTML을 받아 뭐가 그렇게 큰지부터 분해했습니다.

구성	크기
HTML 전체	409KB
**인라인 <style>	244KB (60%)**
프레임워크 데이터(Next.js)	89KB
실제 텍스트	6KB

인라인 스타일 244KB를 열어 보니 UI 라이브러리(Ant Design) CSS 122KB가 똑같은 내용으로 두 벌 들어 있었습니다. 모든 페이지가 그랬습니다.

원인은 Next.js의 스트리밍 렌더링이었습니다. HTML을 여러 번 나눠 보내는데, 그때마다 스타일을 꺼내는 함수가 다시 불리고, 라이브러리가 이미 보낸 스타일까지 매번 전부 내보내고 있었습니다. 라이브러리에 "이미 꺼낸 건 건너뛰기"(once) 옵션이 있어서 그걸 켜자 중복이 사라졌습니다.

⚠️ 여기서 함정이 하나 더 있었습니다. 이 옵션만 켜면 스타일 끝에 붙는 "이미 넣은 스타일 목록" 표시가 빈 값으로 덮어써져서, 브라우저가 스타일을 자바스크립트로 전부 다시 넣었습니다(홈에서 약 120KB). HTML에서 줄인 만큼이 브라우저 작업으로 옮겨간 셈이죠. 코드 리뷰에서 잡아서 목록을 누적하도록 고쳤고, 고장 난 버전을 일부러 다시 돌려 실제로 재주입이 사라졌는지 확인했습니다.

📦 남은 CSS는 파일로 — 그런데 「전부」는 아니었다

중복을 없애도 페이지마다 CSS 120~200KB가 남았습니다. 이걸 별도 파일로 빼면 두 번째 페이지부터는 캐시를 쓸 수 있습니다. 그런데 재 보니 그렇게 간단하지 않았습니다.

방식	첫 방문 CSS (압축 후)	두 번째 페이지부터
지금처럼 페이지마다 인라인	약 16KB	매번 다시 받음
쓰는 컴포넌트 전부 파일로	약 42KB	0
공통 컴포넌트 11종만 파일로	약 12KB	0

전부 빼면 첫 방문에 화면을 막는 CSS가 세 배가 됩니다. 검색으로 들어와 한 페이지만 보고 나가는 방문자에게는 오히려 손해죠. 그래서 거의 모든 페이지가 쓰는 11종(버튼·카드·레이아웃 등)만 파일로 뺐습니다. 홈 HTML은 409KB → 192KB가 됐습니다.

이때도 화면이 한 군데 달라졌습니다. 파일로 옮기자 CSS 적용 순서가 바뀌어, 칼로리 계산기의 태그가 커졌습니다. 우선순위가 같은 규칙끼리는 뒤에 오는 쪽이 이기는데, 그 앞뒤가 뒤집힌 겁니다. 예전 인라인 스타일이 있던 바로 그 자리에 파일 링크를 넣는 방식으로 바꾸고, 84개 페이지를 모바일·데스크톱으로 찍어 라이브와 픽셀 단위로 비교해서 차이가 없는 걸 확인한 뒤에 배포했습니다.

🚨 그리고 사이트가 40분 넘게 깨졌습니다

고친 걸 배포한 뒤, 작업 기록 문서만 바꾼 커밋을 하나 더 올렸습니다. "코드는 안 바뀌었으니 괜찮겠지" 했는데, 이게 문제였습니다.

• 배포할 때마다 JS·CSS 파일 이름(해시)이 바뀌고, 옛 파일은 새 서버에 없습니다
• CDN(Cloudflare)에는 옛 HTML이 남아 있었고, 그 HTML이 지워진 파일을 가리켰습니다
• 결과: 스타일 일부가 빠지고, 버튼을 눌러도 계산 결과가 안 나오는 상태가 약 40~50분

화면 비교를 하다가 "라이브 쪽이 이상하다"는 걸 보고서야 알았습니다. CDN 캐시를 전부 비워 복구했고, 근본 대책으로 배포가 끝나면 자동으로 캐시를 비우는 장치를 다시 만들었습니다.

• GitHub Actions가 배포 완료 신호(호스팅이 커밋에 남기는 success 상태)를 받으면 시작
• 서버가 정말 그 커밋으로 바뀌었는지 헬스체크로 확인한 뒤 전체 캐시 삭제
• 삭제 뒤 페이지가 참조하는 파일이 전부 200인지 검사, 아니면 한 번 더

첫 실행은 배포 완료부터 검증까지 34초였습니다.

💡 Jay의 정리 — 진단툴은 「어디를 볼지」까지만

이번 일로 정리된 생각은 이렇습니다.

• ✅ 진단 도구는 어디를 봐야 할지 알려 주는 데까지는 쓸모가 있습니다. 텍스트 비율 경고가 없었다면 CSS 두 벌을 몰랐을 겁니다
• ❌ 처방은 그대로 믿지 않습니다. "글을 늘려라"를 따랐다면 진짜 원인은 그대로 둔 채 홈에 필요 없는 문단만 생겼을 겁니다
• 📏 고치기 전에 재고, 고친 뒤에도 잽니다. 재주입 함정도, 적용 순서 회귀도, 캐시 장애도 전부 "다시 재 보다가" 찾았습니다
• 🧯 배포는 "문서만 바꿨으니 괜찮다"가 없습니다. CDN 앞에 Next.js를 둔 사이트라면, 배포 후 캐시 비우기를 사람 기억에 맡기지 마세요

결론

SEO 진단 점수는 출발점일 뿐입니다. 세 항목 중 실제로 고칠 가치가 있었던 건 하나였고, 그마저 원인은 도구의 설명과 달랐습니다. 감점 숫자보다 "이 경고가 가리키는 곳을 직접 열어 보면 무엇이 있는가" 를 보시길 권합니다. 9,900원을 내기 전에, 개발자 도구에서 HTML 크기부터 한 번 확인해 보세요.

다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!

📚 참고 / 출처

• llms.txt 제안 문서 (llmstxt.org)
• Bing이 "설명이 너무 짧다"고 해서 고쳤더니, 본문 오류가 줄줄이 나왔습니다 — 한글 설명문 길이 기준 실측