페이지의 문자 인코딩과 언어를 선언하는 두 메타 신호. html.mdx와 head.mdx에서 부분적으로 다뤘지만 — 한국어 사이트의 가장 기본적인 무료 보험이라 전용 카드로.
SEO 관점에서 lang 속성이 검색엔진의 언어 인식 1순위 신호. 구글은 콘텐츠 자체도 분석하지만 — lang이 명시되면 추측 없이 언어 분류. 인코딩이 깨진 페이지는 검색엔진이 본문을 읽을 수 없어 인덱싱 자체 불가. 가장 기본적인 SEO 인프라.
GEO 관점에서 AI가 페이지 언어를 확정하는 신호가 lang. AI Overviews와 LLM이 사용자 언어에 맞는 페이지를 인용할 때, lang이 매칭 기준. 한국어 사용자에게 영어 페이지 인용하는 실수를 방지.
A11y 관점에서 가장 critical. NVDA·VoiceOver의 발음 엔진은 lang을 보고 어떤 언어 모드로 발화할지 결정. lang이 영어인데 한국어 콘텐츠를 만나면 — 한글이 영어 발음 규칙으로 들리지 않는 소음이 된다. 시각장애 사용자에게 가장 큰 좌절 중 하나.
자주 보는 안티패턴:
- charset이 head 중간 — charset은 반드시 head의 첫 줄에 있어야. 정확히는 첫 1024바이트 안에 인식돼야 함. 늦게 박히면 그 전까지의 바이트가 다른 인코딩으로 해석되어 한글 깨짐.
- EUC-KR — 구식 한국어 인코딩. 이모지, 외국어, 일부 한자 표현 불가. UTF-8이 글로벌 표준. 새 사이트는 반드시 UTF-8.
- html lang 누락 — 한국어 사이트인데 lang 미명시. 스크린리더 영어 발음, 검색엔진 언어 추측. 단 한 속성이 빠져 발생하는 결함.
- lang과 콘텐츠 불일치 —
<html lang="en">인데 한국어 콘텐츠. 부트스트랩 템플릿 그대로 둔 사이트에서 흔히 보는 실수.
charset 위치의 중요성 — 명세상 head의 첫 1024바이트 안에 있어야 인식. 안전한 패턴은 반드시 head의 첫 줄. <title> 등 다른 메타보다 앞에.
HTTP 응답 헤더 charset — Content-Type: text/html; charset=utf-8이 meta보다 우선. 둘이 다르면 헤더가 이김. 가능하면 둘 다 UTF-8로 일관.
본문 안 인라인 lang — 한국어 글에 영어 인용이 섞일 때 <span lang="en">...</span>. 스크린리더가 그 부분만 영어 발음으로 전환. 일본어 한자(<span lang="ja">漢字</span>), 중국어, 다른 언어 모두 같은 패턴.
lang 코드의 정확성:
- 언어만:
ko,en,ja,zh - 언어-지역:
ko-KR,en-US,en-GB,zh-CN,zh-TW - region이 의미 있을 때만 region 코드. 한국어는 보통
ko로 충분 (한국·북한 차이 거의 없음). 영어는 en-US vs en-GB 차이 있어 region 추가가 의미 있다.
Next.js에서 — app/layout.tsx의 <html lang="ko">로 한 번에 모든 페이지 적용. charset은 Next.js가 자동 박아 별도 설정 불필요. 이 두 줄이 사이트 전체의 기본 보험.
도감의 모든 카드가 한국어 — <html lang="ko">가 layout에 박혀 있어 스크린리더가 한국어 발음으로 읽는다. 영어 코드 예시(<button>, useState 등)는 자동으로 영어 발음 전환되거나, 코드는 글자별 발화 모드로 전환된다.