공개 웹의 대부분은 몇몇 언어로 쓰여 있고, 한 나라에서 실행되는 크롤러는 그보다 더 좁은 범위만 봅니다. 현지 방문자에게는 현지 텍스트를 보여줄 사이트의 영어 버전이나 기본 버전이죠. 여러 시장을 위한 모델을 학습하거나 미세 조정한다면, 진짜 다국어·지역별 데이터를 모으는 일 자체가 별개의 과제이고, AI·ML 데이터 수집이 어려워지는 지점도 바로 여기입니다.
이 가이드에서는 언어별 범위를 계획하는 방법, 현지 소스를 찾는 곳, 현지 독자가 보는 버전을 가져오는 방법, 그리고 수집한 텍스트를 식별하고 필터링하고 균형을 맞추는 방법을 다룹니다. 크롤에서 코퍼스까지의 전체 흐름은 공개 웹에서 대규모 학습 데이터셋을 구축하는 방법 가이드를 참고하세요.
언어와 지역별로 범위 계획하기
크롤러가 아니라 표로 시작하세요. 대상 언어마다 다음을 적습니다.
- 중요한 지역. 스페인, 멕시코, 아르헨티나의 스페인어는 어휘, 철자, 주제가 다릅니다. 브라질과 포르투갈의 포르투갈어는 더 많이 다릅니다. 어떤 변종이 필요한지 정합니다.
- 목표 분량. 언어와 변종별로 토큰 수나 문서 수로 정합니다.
- 다뤄야 할 분야. 뉴스, 포럼, 공공기관, 상거래, 참고 자료, 기술 문서 등입니다.
- 문자 체계. 세르비아어의 키릴 문자와 라틴 문자처럼 여러 문자로 쓰는 언어가 있습니다. 둘 다 남길지 정합니다.
이 표가 곧 테스트가 됩니다. 수집이 끝날 때마다 얻은 결과를 언어별로 이 표와 비교하세요.
현지 소스 찾기
일반 크롤은 작은 언어를 충분히 담지 못하므로 언어별 시드 목록을 만드세요.
- 국가 도메인.
.pl,.vn,.co.ke같은 도메인은 지역 콘텐츠를 찾는 좋은 출발점입니다. - 글로벌 사이트의 언어별 버전. 페이지 헤더와 사이트맵의
hreflang태그에는 그 페이지의 모든 언어 버전이 나열되어 있습니다. hreflang으로 페이지의 모든 언어 버전을 찾는 방법 가이드에서 추출 방법을 설명합니다. - 현지 디렉터리, 뉴스 애그리게이터, 정부 포털. 같은 언어의 많은 사이트로 연결됩니다.
- 현지 언어 검색 결과. 그 지역에서 가져오면 글로벌 크롤이 거의 닿지 않는 사이트가 나옵니다.
시드마다 출처와 수집 거부 여부를 기록하세요. 가져올 때 robots.txt와 AI 수집 거부 설정을 지키고, 그 기록을 데이터와 함께 보관합니다.
현지 독자가 보는 버전 가져오기
많은 사이트가 방문자 위치에 따라 무엇을 보여줄지 정합니다. 언어, 통화, 지역 뉴스, 지역판, 동의 화면 같은 것들입니다. 데이터센터에 있는 크롤러는 모든 나라에 대해 기본 버전, 흔히 영어 버전을 받고 그것을 현지 콘텐츠인 것처럼 저장합니다.
현지 버전을 모으려면 모든 요청이 현지 독자의 요청처럼 보여야 합니다.
- 대상 국가의 IP. 가정용 회선이 가장 좋습니다. 레지덴셜 프록시를 통한 요청은 선택한 국가나 도시의 레지덴셜 IP에서 오므로, 사이트가 실제 방문자처럼 라우팅하고 현지화합니다.
- 그에 맞는
Accept-Language헤더. 예를 들어 폴란드의 폴란드어 독자라면pl-PL,pl;q=0.9입니다. - 일관된 신호. 헤드리스 브라우저의 시간대와 로캘은 IP와 맞아야 합니다. 불일치는 사이트가 기본 버전으로 돌아가는 원인 중 하나이며, 프록시 위치, 시간대, 로캘을 맞추는 방법 글에서 점검 항목을 다룹니다.
수집 초반에 지역마다 샘플을 직접 확인하세요. “베트남어” 묶음이 영어 페이지로 가득하다면 수집 단계가 잘못된 것이고, 나중의 어떤 필터로도 고칠 수 없습니다.
모든 문서의 언어 식별하기
lang 속성이나 도메인만 믿어서는 안 됩니다. 추출한 텍스트에 언어 식별 모델을 돌리세요.
- fastText의 lid.176 모델은 176개 언어를 지원하고, 모든 문서에 돌릴 만큼 빠릅니다.
- GlotLID 같은 더 넓은 모델은 훨씬 많은 언어를 다루며, 자원이 적은 언어에 더 강합니다.
문서 단위뿐 아니라 문단 단위로도 식별하세요. 많은 페이지가 여러 언어를 섞어 씁니다. 영어 메뉴가 달린 현지 기사나, 사용자가 언어를 바꿔 쓰는 포럼 스레드 같은 경우입니다. 원하는 언어의 문단만 남기고, 나중에 기준을 높일 수 있도록 신뢰도 점수도 기록합니다. 식별이 가장 자주 틀리는 것은 짧은 텍스트이므로, 라벨을 믿기 전에 최소 길이를 정해 두세요.
전체가 아니라 언어별로 필터링하기
영어에 맞춰 조정한 품질 필터는 다른 언어를 망가뜨립니다. 불용어 수, 평균 단어 길이, 문장부호 비율 같은 휴리스틱은 단어 사이에 띄어쓰기가 없는 태국어나 단어가 매우 긴 핀란드어에서 다르게 동작합니다. 원어민이 검토한 샘플을 바탕으로 언어별 기준을 정하세요.
다국어 데이터에서는 두 가지 문제가 커집니다.
- 기계 번역된 콘텐츠. 많은 사이트가 영어 페이지를 자동 번역해 게시합니다. 분량은 늘지만 모델이 번역 오류를 배우게 됩니다. 알려진 영어 페이지를 거의 그대로 번역한 페이지를 표시하고, 모든 것을 자동 번역하는 사이트는 통째로 조심스럽게 다루세요.
- 인코딩 오류. 잘못 디코딩된 텍스트는 깨진 문자를 만들어 실제로 있는 이상한 언어처럼 보입니다. 유니코드로 정규화하고, 깨진 인코딩은 고치거나 버리고, 같은 단어가 두 가지 방식으로 저장되지 않도록 유니코드 정규화 형식도 맞추세요.
중복 제거는 각 언어 안에서, 그리고 언어 사이에서 모두 하세요. 같은 상투 문구, 법적 고지, 템플릿이 사이트의 모든 버전에 나오기 때문입니다.
구성 비율 맞추기
원시 웹 데이터는 소수의 언어가 대부분을 차지합니다. 원래 비율로 학습하면 작은 언어는 거의 배우지 못합니다. 같은 비율로 학습하면 작은 언어가 여러 번 반복되어 모델이 외워 버립니다.
흔히 쓰는 중간 방법이 온도 샘플링입니다. 각 언어를 그 크기에 1보다 작은 지수를 거듭제곱한 값에 비례해 샘플링합니다. mT5와 XLM-R 논문은 지수 0.3을 사용했습니다. 무엇을 고르든 샘플링 전후의 언어별 토큰 수와 함께 기록해, 구성을 재현하고 설명할 수 있게 하세요. 무엇을 기록해야 하는지는 AI 학습 파이프라인의 데이터 출처 가이드에서 다룹니다.
결론
다국어 데이터는 영어 데이터에 번역 단계를 더한 것이 아닙니다. 언어와 변종별로 범위를 계획하고, 현지 소스를 찾고, 각 지역을 현지 독자가 보는 그대로 가져오고, 문단 단위로 언어를 식별하고, 언어별 기준으로 필터링하고, 의도적으로 비율을 맞추세요. “폴란드어” 데이터가 정말 폴란드어인지는 수집 단계에서 결정되므로, 가져오는 과정부터 바로잡아야 합니다.