lang=ko 는 꼭 챙겨야 할 요소인가
예전에 Hashnode에 글을 쓰면서 조금 이상하다고 느낀 적이 있다. 분명 한국어로 쓴 글인데, 페이지의 html 헤더는 영어로 고정되어 있었기 때문이다. Medium도, hackernoon도 그랬다. 영어 플랫폼 서비스는 대부분 언어 설정을 바꿀 수 없었다. 처음에는 단순한 표시 문제처럼 보였지만, 지금 다시 보면 이게 꼭 사소한 일로만 보이진 않는다.
웹에서 언어 정보는 생각보다 많은 곳에서 쓰인다. 브라우저의 번역 기능, 스크린 리더, 검색엔진, 그리고 최근에는 AI 크롤러까지도 문서의 언어를 참고한다. 그래서 본문은 한국어인데 메타데이터는 영어로 되어 있으면, 사람에게도 기계에게도 문서의 정체성이 조금 흐려진다.
언어 설정은 장식이 아니다
HTML의 lang 속성은 단순한 꾸밈이 아니라, 이 문서가 어떤 언어로 작성되었는지를 알려주는 기본 정보다. 이 값이 맞으면 스크린 리더는 더 자연스러운 발음을 적용할 수 있고, 브라우저는 번역 여부를 더 정확하게 판단할 수 있다. 검색엔진도 페이지를 분류할 때 이 정보를 함께 본다.
문제는 여기서 생기는 불일치다. 예를 들어, lang=en인데 본문이 한글인 상황을 떠올려 보자. 사람은 문서만 보기 때문에 한국어로 인식할 수 있다. 하지만 기계는 다르다. 시작점부터 혼란이 생긴다. 시작점에선 영어라 인지하고 본문으로 내려갔으나, 본문 텍스트는 영어가 아닌 한국어가 등장한다. 문서 전체 내용을 보면 한국어가 더 강한 신호이긴 하지만, 첫 인상에 해당하는 메타데이터는 영어였기 때문에, 전체 품질이 조금씩 깎인다.
왜 이게 중요하다고 느꼈나
개별 페이지 하나만 놓고 보면 큰 차이가 없어 보일 수도 있다. 하지만 이런 글이 플랫폼 전체에 반복되면 이야기가 달라진다. Medium, Hackernoon, Hashnode 같은 트래픽 많은 사이트에서는 도메인만으로도 영문 콘텐츠일 듯한 인상을 준다. 오픈그래프가 조금이라도 해소해주긴 하겠지만, 도메인이 쌓은 평판은 영어 콘텐츠다. 하물며 lang=en이다. 기본 언어가 영어로 고정돼 있으므로, 그 플랫폼을 수집하는 검색엔진이나 AI 시스템은 도메인만으로 언어 분포 기준점을 영어라 추정하고 본문을 읽는다. 분명, 한국어 글이 꽤 쌓여 있다는 걸 우리는 알고 있지만, 전체 분포로 보자면 너무 미미하다.
문제는 “이 글 하나가 안 읽히느냐”가 아니다. 오히려 “이 사이트가 어떤 언어의 문서를 담고 있는지”를 기계가 얼마나 정확하게 파악하느냐에 더 가깝다. 그 차이는 검색 결과, 자동 번역, 접근성, 요약 품질 같은 데서 천천히 드러날 수 밖에 없다. 최악의 상황에는 후순위나 의미 없는 데이터로 치부될지도 모른다.
AI 시대에 더 눈에 띄는 이유
예전에는 이런 문제를 주로 검색엔진 최적화나 접근성 관점에서만 이야기했다. 그런데 지금은 AI가 웹문서를 읽고 요약하고 재구성하는 일이 훨씬 많아졌다. 그러다 보니 lang 같은 정보가 더 이상 형식적인 선언으로만 보이지 않는다.
AI는 본문 텍스트 중심으로 이해하지만, 언어 메타데이터를 무시할 순 없다. 메타데이터와 실제 내용이 어긋나면, 언어 감지, 토큰화, 번역 판단, 인덱싱 같은 단계에서 불필요한 오차가 생길 수 있다. 완전히 틀린 답을 내는 수준은 아니더라도, 이런 작은 오차가 쌓이면 검색성과 재사용성이 달라진다.
실제 얼마나 영향을 주는진 알 수 없겠지만
그래서 이 문제는 단순히 “Hashnode가 왜 lang=en을 고정하느냐”로 끝나지 않는다. 웹문서의 언어 정보는 사람을 위한 표시이면서 동시에 기계를 위한 약속이기도 하다. 본문이 한국어라면 헤더도 한국어여야 한다. 그건 보기 좋으라고 맞추는 옵션이 아니라, 문서 정체성을 정확하게 전달하기 위한 최소한의 정리이며 규약이다. 예전에는 그냥 불편하다고만 생각했고, SEO에서만 약점을 가진다 생각했다. 지금 다시 보면 웹 접근성, 검색엔진 최적화, AI 수집과 학습까지도 영향을 줄 수 있단 생각도 든다.
깃허브 페이지도 영어다
일반 마크다운 문서에는 언어 설정값 자체가 없다. 그래서 깃허브 페이지로 만든 개인 블로그는 100중 99는 lang=en으로 돼 있다. 깃허브 자체가 영문 사이트기 때문에, 상속받은 상태라 그렇다. 차라리 깃허브 페이지가 아니라 그냥 마크다운 문서 그 자체일 때가 더 자연스럽지 않은가 싶다.
가랑비에 옷 젖을 수 있을까?
각 회사에서 언어 메타데이터를 활용하는 정도나 토크나이징하는 방법 등은 사실상 비공개 대외비라고 봐야 한다. 거기다 정말 많은 자료가 지금 이 순간에도 인덱싱되고 있으므로, 지나간 데이터를 수정하기도 쉽지 않다. 그저 연관성이 높은 벡터가 될 수 있냐 없냐의 문제일 뿐, 딱 이 하나가 전체 구조를 무너뜨리지도 않는다.
API로 정확히 규약에 맞춰서 데이터 통신을 하는 경우를 제외하고선, 사실상 다 크롤링으로 웹문서를 해소하고 있다는 사실을 꼭 알아야 한다. curl로 호출한 웹페이지도 결국 언어 메타데이터부터 읽는다. 헤드리스 브라우저라도 다르겠는가. 그냥 미미한 데이터라 보고 무시할 뿐이다. 가랑비를 무시할 것인지, 신경쓸 것인지는 각자의 선택이다.
