블로그 다국어 자동화 (hreflang, AI번역, 국제화라우팅)
솔직히 저는 한국어 블로그에 영어권 유입이 이렇게 있을 줄 몰랐습니다. 구글 애널리틱스를 우연히 들여다보다가 개발 관련 글 몇 편이 해외에서도 꽤 읽힌다는 걸 발견했고, 그날 바로 다국어 자동화 시스템을 만들기로 결심했습니다. 직접 구축해보니 일반적으로 알려진 것보다 훨씬 손이 많이 가는 작업이었고, 특히 hreflang 설정에서 예상치 못한 함정을 만났습니다.
hreflang 자동 삽입, 설정 하나 잘못됐을 때 생기는 일
시스템 구성 자체는 단순한 편이었습니다. 글이 발행되면 AI 번역 API를 호출해 영어(/en/)와 일본어(/ja/) 정적 페이지를 각각 생성하고, 각 페이지의 head에 hreflang 태그를 자동으로 넣는 스크립트를 짰습니다. 여기서 hreflang(에이치레프랭)이란 동일한 콘텐츠가 언어 또는 지역별로 다른 URL에 존재할 때, 검색엔진에 "이 페이지는 어떤 언어·지역 사용자를 위한 것입니다"라고 명시하는 HTML link 속성입니다. 제대로 설정하면 구글이 각 나라 사용자에게 맞는 언어 버전을 검색 결과에 보여줍니다.
문제는 처음에 en-US와 en을 아무 생각 없이 혼용했다는 겁니다. 일반적으로 언어 코드만 쓰면 된다고 알려져 있지만, 제 경험상 이 두 가지를 페이지마다 다르게 쓰면 구글 서치 콘솔에서 국제 타겟팅(International Targeting) 오류가 연속으로 발생합니다. 국제 타겟팅이란 어떤 국가나 언어권 사용자를 검색 노출 대상으로 삼을지 검색엔진에 알리는 설정 개념입니다. 이 오류의 원인을 파악하는 데만 일주일 가까이 걸렸고, 결국 모든 페이지에서 언어 코드를 en 단일 표기로 통일하고 나서야 오류가 사라졌습니다.
이후에는 자동화 스크립트 안에 유효성 검증 로직을 반드시 포함시켰습니다. hreflang 값이 ISO 639-1 언어 코드 규격에 맞는지, x-default 속성(어떤 언어에도 해당하지 않는 사용자에게 보여줄 기본 페이지를 지정하는 값)이 빠지지 않았는지를 배포 전에 자동으로 체크하도록 바꿨습니다. 출처: Google Search Central - hreflang 가이드를 실제로 처음부터 끝까지 읽은 건 오류가 터진 뒤였는데, 처음부터 정독했더라면 일주일을 날리지 않았을 거라는 생각이 지금도 듭니다.
- hreflang 언어 코드는 페이지 전체에서 일관성 있게 통일할 것 (en-US와 en 혼용 금지)
- x-default 속성 누락 시 기본 페이지 미지정 오류 발생 가능
- 스크립트 배포 전 ISO 639-1 코드 규격 자동 검증 로직 필수
- 구글 서치 콘솔 국제 타겟팅 리포트로 오류 여부 주기적 확인
AI번역 품질의 한계와 국제화 라우팅 구조 선택
번역 자동화는 DeepL API와 GPT 계열 API를 모두 써봤습니다. AI 번역 API란 신경망 기반 기계 번역 엔진을 외부 서비스로 제공하는 인터페이스로, 문맥을 어느 정도 파악해 자연스러운 문장을 생성하는 것이 특징입니다. 일반 문장 번역만 놓고 보면 두 API 모두 품질이 상당히 좋았습니다. 그런데 기술 블로그 특성상 코드 주석이나 CLI 명령어 설명이 많다 보니, 이런 부분에서 문맥 없이 직역해버리는 경우가 반복됐습니다.
제가 직접 겪어보니 가장 효과적인 보완책은 용어집(glossary)을 프롬프트에 미리 주입하는 방식이었습니다. 예를 들어 "middleware는 미들웨어로 번역하지 말고 그대로 유지"라든가, "build라는 단어가 동사로 쓰일 때는 빌드하다로 처리"처럼 번역 규칙을 명시적으로 지정해주면 일관성이 눈에 띄게 개선됐습니다. 출처: DeepL API 공식 문서에도 용어집(glossary) 기능이 API 레벨에서 공식 지원되는데, 이걸 진작 활용했더라면 프롬프트 엔지니어링에 쏟은 시간을 아꼈을 것 같습니다.
국제화(i18n) 라우팅 구조 선택도 생각보다 중요한 결정이었습니다. 국제화 라우팅이란 동일 콘텐츠를 언어별로 다른 URL 경로에 제공하는 방식을 말하며, 크게 서브패스(/en/, /ja/)와 서브도메인(en.example.com) 방식으로 나뉩니다. 저는 서브패스 방식을 선택했는데, 서브도메인은 도메인 권위(Domain Authority)가 언어별로 분산될 수 있다는 점이 마음에 걸렸기 때문입니다. 단일 도메인 안에서 언어 경로를 나누는 서브패스 방식이 SEO 관점에서 관리하기 수월하다는 건 직접 운영해보면서 더 확신하게 됐습니다.
번역 품질과 관련해 솔직히 이건 예상 밖이었습니다. 의견성 글이나 유머가 섞인 글은 AI 번역 결과물이 어색해서 발행을 보류한 경우도 여러 번 있었습니다. 반면 코드 예제가 풍부한 튜토리얼 성격의 글은 번역 품질에 대한 부담이 상대적으로 적어서, 이런 글부터 다국어 버전을 먼저 내보내는 전략으로 방향을 바꿨습니다. AI 번역만으로 충분하다는 의견도 있지만, 브랜드 신뢰도를 생각한다면 최소한 뉘앙스가 중요한 글에는 해당 언어에 능숙한 사람의 검수 단계를 두는 것이 바람직하다고 봅니다.
자주 묻는 질문
Q. hreflang 태그를 안 넣으면 어떻게 되나요?
A. 구글이 언어별 페이지를 중복 콘텐츠로 인식해 검색 결과에 엉뚱한 언어 버전을 노출하거나, 페이지 자체가 누락될 수 있습니다. 일반적으로 크게 문제없다고 알려져 있지만, 제 경험상 다국어 콘텐츠를 운영할 때 hreflang이 없으면 구글 서치 콘솔에서 국제 타겟팅 데이터가 아예 잡히지 않았습니다.
Q. DeepL API와 GPT 번역 중 뭐가 더 낫나요?
A. 단순 문장 번역 품질은 둘 다 비슷한 수준입니다. 다만 GPT 계열은 프롬프트로 번역 규칙과 용어집을 주입하기가 더 유연하고, DeepL API는 공식 glossary 기능이 있어 용어 일관성 관리에 편리합니다. 기술 블로그처럼 고유 용어가 많은 경우라면 두 방식을 병행하거나 DeepL의 glossary 기능을 먼저 테스트해보는 것이 좋습니다.
Q. 서브패스(/en/)와 서브도메인(en.example.com) 중 SEO에 유리한 건 어느 쪽인가요?
A. 일반적으로 두 방식 모두 구글에서 공식 지원하며 SEO 효과는 유사하다고 알려져 있습니다. 하지만 도메인 권위가 아직 높지 않은 개인 블로그라면 서브도메인보다 서브패스 방식이 단일 도메인의 신뢰도를 집중시킬 수 있어 관리에 유리합니다. 저도 서브패스를 선택했고 지금까지 별다른 문제가 없었습니다.
Q. AI 번역본을 사람 검수 없이 그냥 발행해도 되나요?
A. 코드 위주의 튜토리얼이라면 AI 번역만으로도 충분히 읽히는 경우가 많습니다. 그러나 의견이나 감정, 유머가 담긴 글은 기계 번역 특유의 어색함이 그대로 드러나 오히려 신뢰를 잃을 수 있습니다. 번역 품질을 전적으로 AI에 맡기면 검색엔진에서도 낮은 품질 신호로 읽힐 가능성이 있으므로, 글의 성격에 따라 검수 여부를 판단하는 것이 바람직합니다.
결론
AI 번역 API와 hreflang 자동화를 결합하면 소규모 블로그도 글로벌 트래픽을 노릴 수 있다는 건 사실입니다. 저도 영어권 검색 유입이 시스템 적용 이후 눈에 띄게 늘었고, 특히 코드 예제 중심의 글에서 효과가 두드러졌습니다. 그러나 자동화가 편리하다고 해서 번역의 양을 늘리는 데만 집중하다 보면, 품질 낮은 콘텐츠가 쌓여 오히려 검색엔진 신뢰도를 갉아먹는 역효과가 날 수 있습니다.
정리하면, hreflang 설정은 반드시 유효성 검증 로직과 함께 자동화하고, AI 번역은 용어집 주입으로 품질을 끌어올린 뒤 글의 성격에 따라 검수 단계를 선별적으로 두는 방식이 현실적입니다. 당장 모든 글을 다국어로 내보내려 하기보다는 코드 비중이 높고 검색 유입 가능성이 있는 글부터 시작해서 감을 잡아가는 것을 권합니다.
참고: Google Search Central - hreflang 가이드 | DeepL API 공식 문서 | Next.js Internationalized Routing 문서