국제 SEO의 ccTLD·서브도메인·서브디렉터리 비교

핵심 요약 — 국가마다 다른 사이트 버전을 제공하려면 세 가지 URL 형태를 고를 수 있습니다. example.de 같은 국가 도메인, de.example.com 같은 서브도메인, example.com/de/ 같은 폴더입니다. Google은 세 가지 모두 사용할 수 있는 구조로 문서화합니다. 중요한 차이는 국가 도메인(.de, .fr, .co.uk)이 검색엔진과 사용자에게 대상 국가를 자동으로 강하게 알린다는 점입니다. 폴더 방식은 운영하기 가장 쉬우므로 대부분 사이트에 합리적인 기본 선택입니다.

세 가지 선택지

독일로 진출하는 미국 기업이라고 가정해 보세요. 독일어 사이트 버전을 어디에 둘까요? 선택지는 세 가지입니다.

• ccTLD — 국가 코드 최상위 도메인입니다. 예는 example.de입니다. .de는 독일의 도메인 접미사이며, 프랑스의 .fr와 영국의 .co.uk도 같은 방식입니다. 국가마다 별도의 도메인을 구매합니다.
• 서브도메인 — 주 도메인 앞에 접두사를 붙인 de.example.com입니다. 같은 주 도메인 앞에 “de.”를 덧붙입니다.
• 서브디렉터리 또는 서브폴더 — 주 도메인의 경로인 example.com/de/입니다. 같은 도메인 한곳에 모든 것이 있고 폴더로만 정리합니다.

어느 쪽이 순위가 더 높을까요?

Google은 어느 한 구조가 모든 경우에 최선이라고 문서화하지 않습니다. 지침은 각각의 장단점과 지역 신호를 제시하므로, 보장된 순위 결과를 가정하기보다 대상 사용자와 운영 방식에 맞게 결정해야 합니다.

그렇다고 서로 바꿔 써도 같다는 뜻은 아닙니다. 입문자가 꼭 이해해야 할 중요한 차이는 다음과 같습니다.

ccTLD는 대상 국가를 자동으로 알립니다. Google은 example.de를 보면 추가 설정 없이도 독일을 대상으로 한다는 것을 압니다. 사용자도 같은 신호를 받습니다. 독일 구매자는 일반적인 .com보다 .de 주소를 더 신뢰합니다.

서브도메인이나 서브디렉터리에는 이런 국가 신호가 자동으로 주어지지 않습니다. hreflang, 지역별 콘텐츠, 현지 정보, 현지 링크 같은 명시적 신호로 대상 사용자를 알려야 합니다.

무엇을 골라야 할까요?

간단한 경험칙은 다음과 같습니다.

• 확신이 없다면 서브디렉터리(example.com/de/)를 사용하세요. 도메인 하나, 호스팅 설정 하나, 모든 것을 관리하는 한곳으로 가장 저렴하고 간단하게 운영할 수 있고 사이트의 ‘힘’이 한 도메인에 남습니다.
• 국가 도메인을 이미 소유하거나, 은행·정부·대형 소매업처럼 현지 주소의 신뢰가 중요하거나, 법적 이유로 해당 국가 도메인을 써야 한다면 ccTLD(example.de)를 사용하세요.
• 별도 도메인을 구매하고 싶지는 않지만 기술적 이유로 국가마다 별도 호스트를 유지해야 한다면 주로 서브도메인(de.example.com)을 사용합니다.

대부분이 잘못 생각하는 점

순위가 더 높아질 거라 생각해서 국가마다 ccTLD를 사지 마세요. 그렇게 되지 않습니다. 대신 사이트의 권위가 여러 별도 도메인으로 나뉘고, 각각 처음부터 자체 링크와 평판을 얻어야 합니다. 공짜 이득이 아니라 실제 비용입니다. 전체 장단점, Google의 실제 설명, Search Console 지역 타기팅 도구 폐지가 바꾼 점을 보려면 고급 탭으로 전환하세요.

핵심 요약 — 국가·언어 타기팅의 선택지는 ccTLD(example.de), gTLD 서브도메인(de.example.com), gTLD 서브디렉터리(example.com/de/)입니다. Google은 세 가지 모두 서로 다른 장단점을 가진 사용 가능한 구조로 설명합니다. 진짜 차이는 지역 신호입니다. ccTLD는 자동적이고 모호하지 않은 국가 신호를 제공하지만 나머지 두 방식은 이를 공짜로 얻지 못합니다. 그 대가는 분산입니다. 별도 도메인은 링크 가치를 나누고 인프라를 늘리며 속성 간 hreflang 관리를 어렵게 합니다. 서브디렉터리는 권위를 한 도메인에 모으고 운영비가 가장 낮지만, Google이 2022년 9월 Search Console의 국제 타기팅 보고서를 없앤 뒤로는 서브폴더의 대상 국가를 명시적으로 선언할 방법이 없습니다. 눈에 보이는 현지 콘텐츠와 다른 지역 신호에 hreflang을 함께 쓰세요. 서브도메인은 중간입니다. 별도 호스트 이름이라 현지에 호스팅할 수 있지만 그 외에는 서브디렉터리와 같은 수동 신호가 필요합니다. 소유권, 등록 자격, 거버넌스, 비용도 신호만큼 중요합니다. 나중에 구조를 바꾸는 것은 빠른 수정이 아니라 리디렉션·표준 URL·hreflang·사이트맵·모니터링을 포함한 완전한 URL 마이그레이션입니다. 제 기본 선택은 서브디렉터리이며 기존 ccTLD, 신뢰·법적 요건, 실제 인프라 분리 필요가 있을 때 다른 방식을 고릅니다. 이는 국제 타기팅의 결정입니다. 일반적인 점과 슬래시의 아키텍처 문제는 별개 주제입니다(아래 참조).

세 구조의 정확한 차이

ccTLD는 .de, .fr, .co.uk, .jp 같은 국가 코드 최상위 도메인입니다. Google은 기본적으로 강한 지역 타기팅 신호로 취급해 도메인을 국가에 자동으로 연결합니다. 수동 설정으로 바꿀 수 없고 바꿀 필요도 없습니다. gTLD(.com, .org, .net 같은 일반 최상위 도메인)는 자체적으로 국가 의미가 없으므로 그 위의 서브도메인·서브디렉터리는 다른 방식으로 지역 타기팅 신호를 얻어야 합니다.

Google의 실제 설명

Google의 Managing multi-regional and multilingual sites (다지역·다국어 사이트 관리) 문서는 국가 타기팅용 URL 구조와 장단점을 다음과 같이 나열합니다.

• 국가별 도메인(ccTLD) — 장점: 명확한 지역 타기팅, 관례상 명확한 서버 위치, 쉬운 사이트 분리. 단점: 비싸고 확보 가능성이 제한될 수 있으며 더 많은 인프라가 필요합니다.
• gTLD 서브도메인 — 장점: 설정이 쉽고 서버 위치를 다르게 둘 수 있습니다. 단점: URL만으로 사용자가 지역 타기팅을 알아보지 못할 수 있습니다.
• gTLD 서브디렉터리 — 장점: 설정이 쉽고 같은 호스트라 유지 관리가 적습니다. 단점: 사용자가 URL에서 지역 타기팅을 알아보지 못할 수 있고 서버 위치가 하나입니다.
• URL 매개변수(example.com?country=de) — 국가 타기팅에 권장하지 않습니다. 구간을 나누기 어렵고 사용자가 URL에서 지역을 알아볼 수 없습니다.

목록에 없는 것을 보세요. 어느 방식의 순위가 더 높다는 주장은 없습니다. Google은 URL 구조 지침과 일반 사이트 구조 문서에서 색인이나 순위상 선호가 없으며 정리하고 관리하기 가장 쉬운 것을 고르라는 입장을 일관되게 반복합니다. 구조 선택은 운영과 신호의 문제이지 순위를 올리는 수단이 아닙니다.

핵심 차이: 자동 지역 신호와 수동 지역 신호

이것이 결정의 핵심이며 일반적인 서브도메인 대 서브디렉터리 논쟁과 구별되는 점입니다.

ccTLD는 국가 신호를 공짜로 줍니다. Google은 example.de를 보는 순간 독일 타깃으로 이해합니다. 할 일이 없습니다. 사용자도 이를 봅니다. 주소 표시줄의 .de는 어떤 .com/de/ 경로도 따라갈 수 없는 신뢰·관련성 단서입니다.

gTLD의 서브도메인·서브디렉터리는 이를 자동으로 얻지 못합니다. .com은 국가에 관해 아무것도 말하지 않습니다. 그렇다면 example.com/de/가 독일의 독일어 사용자용임을 어떻게 알릴까요?

수년간 답은 hreflang과 Search Console의 국제 타기팅 보고서라는 두 부분이었습니다. 보고서는 전체 gTLD 속성의 대상 국가를 수동으로 설정하게 해 주었고, URL 접두어 속성을 쓰면 example.com/de/ 같은 특정 서브디렉터리도 대상이었습니다. 이 수동 국가 설정이 서브폴더를 명시적으로 지역 타기팅하는 유일한 방법이었습니다.

대부분의 글이 놓치는 변화: 국제 타기팅 보고서 폐지

Google은 2022년 9월 Search Console의 국제 타기팅 보고서를 제거했습니다(Google의 폐지 안내, Search Engine Land 보도). 보고서에는 hreflang 오류 검사기와 국가 타기팅 설정이라는 두 탭이 있었습니다. Google이 밝힌 이유는 시간이 지나며 수동 국가 설정의 가치가 줄고 hreflang이 성숙했다는 것이었습니다.

실무적 결과는 구체적이고 중요합니다. 서브디렉터리나 서브도메인의 대상 국가를 Google에 명시적으로 선언할 방법이 더 이상 없습니다. 수동 지정 기능이 사라졌습니다. gTLD의 서브폴더·서브도메인에 남은 것은 다음과 같습니다.

• hreflang — 어떤 사용자에게 어떤 버전을 보여 줄지 알리는 상호 연결된 language-region 주석입니다(hreflang, x-default 참조).
• Google이 스스로 추론하는 신호 — 서버·CDN 위치, 현지 언어와 통화, 현지 주소와 전화 정보, 현지 사이트의 링크입니다.

어느 것도 예전 설정처럼 ‘이 폴더는 독일을 대상으로 한다’는 확정 선언은 아닙니다. hreflang은 국가 지정이 아니라 어떤 버전을 보여 줄지에 관한 힌트입니다. 따라서 서브디렉터리 방식은 이제 hreflang의 올바른 구현에 전적으로 기대는데, 제가 hreflang 사용 도메인 374,756개를 조사했을 때 67% 넘게 적어도 일부를 잘못 구현했습니다. 이것이 ‘운영이 가장 쉬운’ 선택의 실제 비용입니다. 지역 신호의 책임이 전부 자신에게 있고 실수의 여지가 줄어듭니다.

ccTLD는 이를 완전히 비켜갑니다. 국제 타기팅 설정이 애초에 필요 없었으므로 보고서 폐지도 아무것도 바꾸지 않았습니다. ccTLD는 수동 도구에 의존한 적이 없고 서브폴더는 의존했다는 비대칭이, 지역 신호가 정말 중요할 때 ccTLD를 택할 가장 강한 단일 논거입니다.

ccTLD의 비용: 분산

ccTLD가 가장 명확한 신호를 준다면 왜 어디서나 쓰지 않을까요? 신호에 실제 비용이 함께 붙기 때문입니다.

• 권위 분산. 각 ccTLD는 별도 도메인입니다. example.de의 백링크는 example.com이 아니라 example.de의 권위를 쌓습니다. 하나의 강한 도메인에 모으는 대신 국가별 평판을 거의 0부터 시작합니다. 한 gTLD에 힘이 집중된 사이트라면 명확한 지역 신호의 이득보다 이런 분산의 피해가 클 수 있습니다.
• 인프라 증가. 등록·갱신할 도메인, 호스팅·CDN 설정, 인증서 등 모든 것이 늘어납니다. .com.au나 역사적으로 일부 EU ccTLD처럼 등록 자체에 현지 사업체나 주소를 요구하는 경우도 있습니다. 기술뿐 아니라 법적·행정적 장애물입니다.
• 더 어려운 hreflang. 단일 도메인의 hreflang도 까다롭지만, 서로 모두를 상호 참조해야 하는 여러 별도 속성에 걸치면 대형 국제 사이트가 가장 자주 실패합니다. ccTLD를 하나 추가할 때마다 나머지 모든 노드가 정확히 가리켜야 할 노드가 늘어납니다.

서브디렉터리는 이 모든 것을 반대로 만듭니다. 도메인 하나, 속성 하나, 호스팅 설정 하나에 권위가 통합되고 hreflang도 단일 사이트 안에 머뭅니다. 지역 신호는 더 약해도 운영상 단순함은 실제이므로 대부분 글로벌 사이트의 실용적 기본 선택입니다.

서브도메인: 중간 지점

gTLD 서브도메인(de.example.com)은 실제 중간 선택지이지만 왜 중간인지 이해해야 합니다.

• 서브디렉터리처럼 gTLD 위에 있으므로 자동 국가 신호가 없습니다. 서브폴더와 같은 hreflang·추론 신호가 필요합니다.
• 서브디렉터리와 달리 별도 호스트 이름이므로 다른 서버나 국가에 쉽게 호스팅하고 다른 팀·기술 스택으로 분리할 수 있습니다. Google 문서는 서브도메인이 “allow different server locations.”(한국어 풀이: 서로 다른 서버 위치를 허용)한다고 명시합니다.
• Google이 서브도메인을 권위가 흐르는 주 사이트의 일부로 볼지 별도 사이트로 볼지는 통합 정도를 바탕으로 사이트별로 결정합니다. 일반적인 서브도메인 대 서브디렉터리 문제와 같은 사이트별 평가입니다.

따라서 서브도메인은 별도 도메인을 사지 않고 호스팅 유연성을 얻는 대신 서브디렉터리와 같은 수동 지역 신호 작업을 요구합니다. 별도 호스트가 꼭 필요하지 않다면 대부분은 서브디렉터리로 같은 일을 더 적은 관리 부담으로 할 수 있습니다.

상관관계 연구는 어떨까요?

국제 검색 결과에서 ccTLD가 우세하다는 연구를 보게 됩니다. 예를 들어 SE Ranking의 15개 시장·키워드 20,000개 분석은 상위 3위 자리를 ccTLD가 대부분 차지하고 서브디렉터리가 크게 뒤처진 2위, 서브도메인이 작은 비중이라고 했습니다. 표면 그대로 받아들이면 ccTLD가 ‘이긴다’고 결론 내리게 됩니다.

저라면 주의하겠습니다. 이 수치는 상관관계이지 인과관계가 아닙니다. 경쟁이 치열한 현지 시장의 ccTLD 사이트는 오래된 현지 브랜드, 지역 기업, 전국 소매업체 등 URL 형태와 관계없이 잘할 기반 있는 사업자인 경우가 많습니다. 순위를 일으키는 것은 .de가 아니라 강한 현지 관련성과 충분한 링크를 갖춘 사이트라는 점입니다. 그런 사이트가 관례상 ccTLD에 있을 뿐입니다. 명확한 지역 신호는 조금 도움이 되지만 아직 얻지 못한 권위를 만들어 주지는 않습니다. ‘ccTLD의 순위가 높다’를 ‘ccTLD로 옮기면 순위가 높아진다’로 읽지 마세요.

국제 타기팅과 무관한 일반 장단점은 어디에 있나

위 내용은 모두 국제 타기팅 관점입니다. 블로그·도움말 센터·문서처럼 SEO 일반에서 서브도메인과 서브디렉터리가 기능적으로 같은지, 사이트별 처리가 어떻게 작동하는지, 서브도메인→서브디렉터리 마이그레이션의 ‘성공’ 대부분에 동시 변경의 영향이 섞이는지는 별개 질문입니다. 웹사이트 구조 묶음의 일반 서브도메인 대 서브디렉터리 글에서 Pink Cake Box·IWantMyName 사례, Google의 사이트별 통합 신호, 리버스 프록시 우회 방식까지 자세히 다룹니다. ‘블로그를 어디에 둘까’가 질문이라면 그 글부터 읽으세요. ‘여러 국가에 어떻게 서비스할까’라면 이 글이 맞습니다.

소유권, 거버넌스, 비용도 판단에 포함하세요

Google 지침은 이를 순위 경쟁이 아니라 장단점의 선택으로 설명하며, 그 장단점은 지역 신호를 넘어섭니다.

• 소유권과 확보 가능성. 원하는 ccTLD를 실제로 구매하고 유지할 수 있어야 합니다. 일부 국가 등록기관은 현지 사업체, 담당자, 주소 등 등록 자격을 제한합니다. 역사적으로 일부 EU와 .com.au 계열 ccTLD가 그랬습니다. .io, .co처럼 국가 신호보다 일반적인 브랜드용 도메인에 가깝게 판매·취급되는 ccTLD도 있으므로 모든 cc 접미사가 Google에 동일하게 작동한다고 가정하지 마세요.
• 거버넌스와 배포 분리. 별도 ccTLD나 서브도메인은 다른 팀·스택에서 독립적으로 배포할 수 있습니다. 현지 시장에 자체 배포 주기가 필요하면 정말 유용합니다. 하지만 분리에는 비용도 있습니다. 보안·관찰·일관성을 유지할 속성이 늘고, 한 시장의 잘못된 hreflang이나 만료 인증서를 다른 시장 운영팀이 눈치채지 못할 여지도 커집니다.
• 비용. 등록, 갱신, 호스팅, 인증서는 속성 수에 따라 늘어납니다. 시장마다 ccTLD를 쓰면 이 모두가 배가되지만 서브디렉터리 전략은 한 도메인으로 유지합니다.

핵심 답은 달라지지 않습니다. 시장 범위, 각 속성의 소유·유지 관리 주체, 해당 업종에서 현지 신뢰가 실제로 얼마나 중요한지에 구조를 맞추세요. 하지만 곧바로 ‘어느 쪽 순위가 더 높은가’로 넘어가면 실제 결정을 좌우하는 제약을 놓칩니다.

마이그레이션 위험

ccTLD에서 서브디렉터리로, 서브도메인에서 ccTLD로, 또는 다른 방향으로 나중에 구조를 바꾸는 일은 복사·붙여넣기가 아닙니다. 다른 마이그레이션과 같은 절차와 위험을 가진 URL 마이그레이션입니다.

• 리디렉션. 모든 기존 URL을 새 대응 URL로 1:1 리디렉션해야 합니다. 홈페이지로 일괄 보내면 안 됩니다.
• 표준 URL 태그. 새 URL을 가리키도록 갱신하세요. 같은 언어의 지역별 중복이 남아 있다면 Google은 서로 경쟁하게 두기보다 선호 표준 URL과 hreflang의 조합을 권합니다.
• hreflang. 모든 지역 버전의 상호 hreflang 집합이 새 URL을 참조해야 합니다. 이동한 속성 하나가 아니라 모든 속성에 걸쳐 바꾸세요.
• 내부 링크와 사이트맵. 내부 링크를 새 URL로 바꾸고 XML 사이트맵을 갱신해 크롤러가 새 구조를 빨리 찾게 하세요.
• 호스트 확인. ccTLD나 서브도메인은 Search Console/Bing Webmaster Tools의 새 속성입니다. 문제가 생긴 뒤가 아니라 데이터가 필요해지기 전에 확인하세요.
• 모니터링. 전환 중 색인, 트래픽, 순위를 보세요. 전후 수치를 비교할 때 마이그레이션 자체가 교란 요인이라는 점을 기억하세요. 리디렉션, 콘텐츠 갱신, 링크 변경처럼 동시에 바뀐 다른 모든 것을 통제하지 않으면 변화를 새 URL 형태의 효과로 돌릴 수 없습니다.

순위 상승만 쫓아 구조를 이전하지 마세요. Google은 구조 사이의 선호를 밝히지 않으며, 구조 변경으로 해결될 가능성이 있는 문제보다 마이그레이션 자체의 위험이 더 큽니다.

제 권고

• 서브디렉터리(example.com/de/)를 기본으로 삼으세요. 운영비가 가장 낮고 권위가 통합되며, 대부분 사이트에는 약한 지역 신호를 감수하고 단순함을 얻는 선택이 합리적입니다. 2022년 이후 남은 유일한 명시적 수단이므로 hreflang을 올바르게 구현할 책임은 받아들이세요.
• 지역 신호가 정말 중요하고 분산 비용을 감당할 수 있다면 ccTLD를 고르세요. 국가 도메인을 이미 소유하거나, 금융·의료·대형 소매업·정부 관련 분야처럼 현지 주소가 신뢰를 만들거나, 시장의 법적·등록 요건이 해당 도메인을 요구하는 경우입니다. 결정 전에 원하는 도메인을 실제로 등록하고 관리할 수 있는지 확인하세요. 각 도메인이 자체 권위를 쌓는다는 것을 알고 시작하세요.
• 서브도메인은 주로 인프라상의 이유로 고르세요. 별도 도메인을 원하거나 필요로 하지는 않지만 국가마다 별도 호스트·스택이 필요한 경우입니다. 서브디렉터리와 같은 수동 지역 신호 작업은 여전히 해야 합니다.
• 무계획하게 섞지 마세요. 무엇을 고르느냐보다 한 구조를 골라 모든 시장에 일관되게 적용하는 것이 중요합니다. 일관성이 대규모 hreflang과 크롤링을 관리 가능하게 합니다.
• 계획 없이 구조를 이전하지 마세요. 이동한다면 순위 문제의 빠른 해결책이 아니라 리디렉션, 표준 URL, hreflang, 내부 링크, 사이트맵, 호스트 확인, 모니터링을 포함한 완전한 URL 마이그레이션으로 다루세요.

전체 주제에서의 위치

같은 묶음의 다른 글은 국제 SEO 감사, 구현 점검표, 시장별 키워드 조사, 번역과 현지화 선택 등 더 넓은 국제 SEO 기초를 다룹니다. 태그 수준의 작동 방식은 hreflang과 x-default에 있습니다. 구조를 선택한 뒤 성패를 가르는 요인은 거의 언제나 구조 자체가 아니라 hreflang의 정확성입니다.

AI 요약

고급 버전의 요약입니다.

• 국가 타기팅용 세 구조: ccTLD(example.de), gTLD 서브도메인(de.example.com), gTLD 서브디렉터리(example.com/de/).
• Google은 순위상 선호가 없습니다. 다지역 및 URL 구조 문서에서 밝힌 내용입니다. 선택은 순위가 아니라 신호와 운영의 문제입니다.
• 핵심 차이 — 지역 신호. ccTLD는 자동적이고 모호하지 않은 국가 신호를 수동 설정 없이 Google과 사용자에게 줍니다. gTLD의 서브도메인·서브디렉터리는 자동 국가 신호가 없으므로 hreflang과 서버 위치·언어·통화·현지 링크 같은 추론 신호에 의존해야 합니다.
• 국제 타기팅 폐지(2022년 9월). Google은 gTLD 속성과 서브디렉터리의 대상 국가를 수동 설정하던 Search Console 보고서를 제거했습니다. 서브폴더의 국가를 명시적으로 선언할 방법은 더 이상 없으며 hreflang만 남은 수단입니다.
• ccTLD의 비용 = 분산. 별도 도메인은 각각 권위를 쌓으므로 링크 가치가 나뉘고 인프라가 늘며 속성 간 hreflang이 어려워집니다.
• 서브디렉터리 = 가장 저렴하고 한 도메인에 권위가 통합되지만 지역 신호는 전적으로 hreflang에 기댑니다.
• 서브도메인 = 중간 지점: 별도 호스트 이름으로 호스팅·서버 위치가 유연하지만 서브디렉터리와 같은 수동 지역 신호가 필요합니다. 사이트별로 주 사이트의 일부 또는 별도 사이트로 처리됩니다.
• 상관관계 주의: SE Ranking의 20K 키워드 연구처럼 국제 검색 결과에서 ccTLD가 우세하다는 연구는 상관관계입니다. 기반 있는 현지 브랜드가 관례상 ccTLD를 쓰는 것이며 도메인이 순위를 만들어 내는 것은 아닙니다.
• 소유권, 거버넌스, 비용. 일부 ccTLD는 현지 사업체·주소 같은 등록 요건을 두고, 일부는 국가 신호 대신 일반 브랜드용 도메인으로 취급됩니다. 속성이 늘면 지역 신호와 무관하게 등록·호스팅·인증서 비용과 관리 부담도 늘어납니다.
• 마이그레이션 위험. 나중에 구조를 바꾸는 것은 리디렉션, 표준 URL, hreflang, 내부 링크, 사이트맵, 호스트 확인, 모니터링을 포함한 완전한 URL 마이그레이션입니다. 전후 순위 비교에는 이동 중 함께 바뀐 모든 것의 영향이 섞입니다. 순위 상승만 쫓아 이전하지 마세요.
• Patrick의 기본 선택: 기존 ccTLD, 신뢰·법적 요건, 실제 인프라 분리 필요가 없다면 서브디렉터리입니다. 선택 자체보다 시장 간 일관성이 중요합니다.

어떤 구조를 사용해야 할까요?

위에서부터 따라가세요. 해당하는 첫 ‘예’가 보통 결정을 내립니다.

1. 국가 도메인(example.de, example.fr)을 이미 소유하거나 그 위에서 사업 기반을 쌓았나요? → ccTLD를 사용하세요. 이미 분산 비용을 지불하고 현지 권위를 쌓았으므로 통합하려고 버리지 마세요. 유지하고 속성 간 hreflang을 연결하세요.

2. 시장에 현지 도메인을 요구하는 법적 요건이 있거나 현지 신뢰가 핵심인가요(금융, 의료, 정부 관련, 대형 전국 소매업)? → 그 시장에는 ccTLD를 쓰세요. 자동 지역 신호와 현지 주소의 신뢰 단서가 추가 도메인의 비용을 정당화합니다. 일부 시장에는 ccTLD, 나머지에는 서브디렉터리를 써도 되지만 각 시장 안에서는 일관성을 유지하세요.

3. 별도 도메인을 사고 싶지는 않지만 국가마다 진정으로 별도 서버·스택·팀이 필요한가요? → 서브도메인(de.example.com)을 쓰세요. 별도 도메인 없이 호스팅·위치 유연성을 얻습니다. 단, hreflang은 여전히 필요합니다. 서브도메인이 스스로 지역 타기팅을 하지는 않습니다.

4. 위에 해당하지 않고 주로 .com을 쓰는 사이트가 새 언어·국가로 확장하며 작동하는 가장 단순한 방법을 원하나요? → 서브디렉터리(example.com/de/)를 쓰세요. 도메인 하나, 호스팅 설정 하나, Search Console 속성 하나에 권위가 통합됩니다. 2022년 9월 이후 기댈 수 있는 수동 국가 타기팅 설정이 없으므로 hreflang을 정확히 구현하세요.

의사결정 트리보다 우선하는 두 규칙:

• 일관성이 ‘완벽한’ 선택보다 낫습니다. 모든 시장에 깔끔하게 적용한 하나의 구조가 시장마다 감으로 고른 혼합보다 성과가 좋습니다.
• 순위 상승만을 위해 구조를 이전하지 마세요. Google은 선호가 없습니다. 마이그레이션 위험은 일반 서브도메인 대 서브디렉터리 글을 참고하세요. 대개 hreflang으로 얻을 수 있는 신호보다 그 위험이 큽니다.

공식 문서

검색엔진이 제공하는 1차 출처 문서입니다.

Google

• Managing multi-regional and multilingual sites (다지역·다국어 사이트 관리) — 국가 타기팅용 ccTLD·서브도메인·서브디렉터리, 장단점, 쿠키·브라우저 기반 제공 대신 버전마다 다른 URL을 쓰라는 권고입니다.
• URL structure best practices (URL 구조 권장사항) — 지역 타기팅에 ccTLD 또는 서브디렉터리를 권하며 순위상 선호는 밝히지 않습니다.
• Tell Google about localized versions of your page (hreflang) (Google에 페이지의 현지화 버전 알리기, hreflang) — gTLD 서브도메인·서브디렉터리에 남은 유일한 명시적 지역 신호인 상호 hreflang 규칙입니다. Google이 스스로 읽는 서버 위치·현지 콘텐츠·현지 링크 같은 추론 신호와 함께 작동합니다.
• Crawling and indexing multilingual sites (다국어 사이트 크롤링과 색인) — Google이 적합한 지역 버전을 발견하고 제공하는 방법입니다.

Bing / Microsoft

• How To Tell Bing Your Website’s Country and Language (Bing Webmaster Blog) (Bing에 웹사이트의 국가와 언어 알리기, Bing 웹마스터 블로그) — 다국가·다국어 사이트 지침입니다. Bing은 hreflang보다 content-language 메타·헤더 신호에 더 의존한다는 점에 주의하세요.
• Bing Webmaster Guidelines (Bing 웹마스터 가이드라인) — 일반 지침이며 정당한 사이트의 ccTLD·서브도메인·서브디렉터리 중 특정 방식을 규범적으로 선호하지 않습니다.

출처의 발언과 입장

공개 발언과 문서화된 입장입니다. 페이지가 지원하면 링크는 해당 구절로 바로 이동합니다. 브리프가 주장을 전달했지만 정확한 원문 구절을 검증하지 않은 경우에는 따옴표 없이 바꿔 설명합니다.

Google — 구조 간 순위 선호 없음

• 바꿔 설명하면: Google 문서는 정리하고 관리하기 가장 쉬운 것을 고르라고 하며 색인·순위 관점에서 URL 구조 간 선호가 없다고 설명합니다. URL 구조 문서

Google — 세 국제 URL 구조와 장단점

• 다지역 문서를 바꿔 설명하면: 국가 코드 최상위 도메인은 명확한 지역 타기팅과 쉬운 사이트 분리를 제공하지만 비싸고 더 많은 인프라가 필요합니다. gTLD 서브도메인은 설정이 쉽고 서버 위치를 다르게 둘 수 있지만 사용자가 지역 타기팅을 알아보지 못할 수 있습니다. gTLD 서브디렉터리는 단일 호스트에서 설정과 유지 관리가 쉽지만 마찬가지로 사용자가 지역 타기팅을 알아보지 못할 수 있습니다. Managing multi-regional and multilingual sites (다지역·다국어 사이트 관리)

Google — 국제 타기팅 보고서 제거(2022년 9월)

• 보도된 Google Search Console 발표를 바꿔 설명하면: hreflang이 성숙함에 따라 수동 국가 타기팅 설정의 가치가 시간이 지나며 줄어 국제 타기팅 보고서가 종료됐고, 현지화 버전을 알리는 수단으로 hreflang이 남았습니다. Google 폐지 안내

흔한 실수와 대안

통념 1: ‘ccTLD의 순위가 더 높으니 국가마다 하나씩 사자.’ 잘못된 이유: Google은 구조 간 순위 선호가 없고 각 ccTLD는 거의 0부터 권위를 쌓는 별도 도메인으로 인프라·hreflang 복잡성을 더합니다. ccTLD가 상위라는 순위 연구는 상관관계입니다. 기반 있는 현지 브랜드가 관례상 ccTLD를 씁니다. 대안: 자동 지역 신호나 현지 신뢰가 분산 비용을 정말 정당화하는 곳에만 ccTLD를 쓰고, 나머지는 서브디렉터리로 통합하세요.

통념 2: ‘서브디렉터리도 똑같이 좋으니 hreflang이 필요 없다.’ 잘못된 이유: gTLD의 서브디렉터리는 자동 국가 신호가 없으며 국제 타기팅 보고서가 2022년 9월 폐지된 뒤 수동 국가 타기팅 설정도 남아 있지 않습니다. hreflang이 없으면 각 버전이 누구를 위한 것인지 Google에 아무것도 알리지 않은 셈입니다. 대안: 모든 지역 폴더에 상호 연결되고 자기 자신도 참조하는 hreflang을 구현하세요. 이제 유일한 명시적 수단입니다.

통념 3: ‘Search Console에서 /de/ 폴더의 대상 국가를 설정하자.’ 잘못된 이유: 그 설정인 국제 타기팅은 2022년 9월 제거되어 더 이상 존재하지 않습니다. 서브폴더의 국가를 명시적으로 선언할 수 없습니다. 대안: hreflang과 서버·CDN 위치, 현지 언어·통화, 현지 주소, 현지 사이트 링크 같은 추론 신호에 의존하세요.

통념 4: ‘서브도메인은 별도 호스트 이름이므로 스스로 지역 타기팅한다.’ 잘못된 이유: gTLD 서브도메인(de.example.com)의 .com에는 국가 의미가 없습니다. 서브디렉터리와 같은 hreflang·추론 신호가 필요합니다. 별도 호스트 이름은 호스팅 유연성을 줄 뿐 자동 지역 신호를 주지 않습니다. 대안: 서브도메인의 지역 타기팅도 hreflang을 우선하는 서브디렉터리와 동일하게 다루고, 서브도메인은 인프라 이점 때문에만 사용하세요.

통념 5: ‘약한 국제 검색 순위를 고치려고 ccTLD나 서브폴더로 이전하자.’ 잘못된 이유: 구조 마이그레이션에는 보장된 보상 없이 위험만 있습니다. Google은 선호가 없으며 일반적인 서브도메인 대 서브디렉터리 사례의 ‘성공’ 대부분에는 동시 변경이 교란 요인으로 섞입니다. URL을 옮겨 권위나 관련성 문제를 해결하는 경우는 드뭅니다. 대안: URL 구조를 건드리기 전에 hreflang 정확성, 현지 콘텐츠 품질, 현지 사이트 링크라는 기초 신호를 고치세요.

통념 6: ‘시장마다 그때 편한 구조를 섞어 쓰자.’ 잘못된 이유: 일관성 없는 혼합은 hreflang 묶음, 크롤링, 권위를 이해하기 어렵게 하고 대규모 운영에서 쉽게 망가뜨립니다. 대안: 주 구조를 골라 일관되게 적용하고 기존 ccTLD나 법적 요건처럼 구체적이고 정당한 이유가 있을 때만 예외를 두세요.

국제 URL 구조 선택 점검표

선택 전

• 하나의 글로벌 사이트 번역만 필요한 것이 아니라 시장별 다른 콘텐츠를 제공하는 국가·언어 타기팅이 실제로 필요한지 확인하세요.
• 대상 시장을 나열하고 현지 도메인에 법적·등록 요건이 있는 곳을 표시하세요.
• 관련 ccTLD를 이미 소유하거나 그중 어느 곳에서 이미 순위를 얻는지 확인하세요.
• 업종에서 현지 신뢰가 얼마나 중요한지 판단하세요. 금융·의료·소매업은 ccTLD 쪽에, SaaS·콘텐츠는 서브디렉터리도 괜찮은 쪽에 가까운 경우가 많습니다.

결정

• ccTLD에서 이미 기반이 있거나 법적·신뢰상 핵심인가요? → ccTLD.
• 별도 도메인은 필요 없지만 국가별 호스팅·서버 위치 분리가 필요한가요? → 서브도메인.
• 그 외에 권위를 통합하고 가장 간단하게 운영하고 싶나요? → 서브디렉터리(기본값).
• 무엇을 고르든 모든 시장에 일관되게 적용할 계획을 세우세요.

선택 후(gTLD 구조 — 서브도메인 또는 서브디렉터리)

• Search Console에 수동 국가 타기팅 설정이 더 이상 없음을 기억하세요(2022년 9월 제거).
• 모든 버전에 상호 연결되고 자기 자신을 참조하는 hreflang을 구현하세요.
• 대체·선택 페이지에 x-default를 추가하세요.
• 서버·CDN 위치, 현지 언어·통화, 현지 주소·전화, 현지 사이트 링크로 추론 신호를 강화하세요.
• 잘 작동하는 기존 구조를 순위 상승만을 위해 이전하지 마세요.

ccTLD를 고른다면

• 도메인마다 등록·갱신·호스팅·인증서 예산을 잡으세요.
• 각 ccTLD가 다른 모든 ccTLD를 상호 참조하도록 별도 속성 간 hreflang을 계획하세요.
• 도메인마다 자체 권위를 쌓는다는 점을 받아들이고 링크 가치가 한데 모일 것으로 기대하지 마세요.

구조 사이를 이전한다면

• 기존 URL 각각을 새 대응 URL로 1:1 리디렉션하세요. 홈페이지로 일괄 보내지 마세요.
• 표준 URL 태그를 새 URL로 갱신하세요. 같은 언어의 지역별 중복에는 선호 표준 URL과 hreflang을 유지하세요.
• 모든 속성의 상호 hreflang을 새 URL 참조로 다시 구성하세요.
• 내부 링크와 XML 사이트맵을 갱신하세요.
• 데이터가 필요해지기 전에 새 호스트·속성을 Search Console과 Bing Webmaster Tools에서 확인하세요.
• 전환 중 색인·트래픽·순위를 관찰하고, 전후 비교에서는 마이그레이션 자체가 교란 요인임을 기억하세요.

생각의 틀

1. 신호와 권위 — 핵심 절충. ccTLD는 자동적이고 모호하지 않은 지역 신호를 극대화하지만 별도 도메인으로 권위를 분산합니다. 서브디렉터리는 한 도메인에 모인 권위를 극대화하지만 자동 지역 신호는 최소화하고 hreflang에만 기댑니다. 서브도메인은 중간입니다. 여기서 거의 모든 결정은 이 신호와 권위 사이의 선 위에 있습니다.

2. 자동 지역 신호와 수동 지역 신호. 국가 신호를 공짜로 주는 것은 ccTLD뿐입니다. gTLD 위의 서브도메인·서브디렉터리는 모두 직접 책임지는 수동 신호가 필요합니다. 2022년 9월 이후 ‘수동’은 Search Console 설정이 아니라 hreflang을 뜻합니다. gTLD 구조를 고르는 것은 hreflang을 올바르게 운영할 책임을 맡는 일입니다.

3. 구조는 순위를 올리는 수단이 아닙니다. Google은 선호가 없습니다. 형태를 골라 순위가 높아지는 것이 아닙니다. 시장에서 관련성, 신뢰, 충분한 링크를 갖추어 순위가 높아지는 것이며 구조는 어떤 시장인지 얼마나 명확하게 알리는지만 바꿉니다. ‘어느 쪽 순위가 더 높은가’라는 잘못된 질문부터 버리세요.

4. 일관성이 최적화보다 낫습니다. 모든 시장에 깔끔하게 적용한 하나의 구조가 시장마다 감으로 고른 혼합보다 가치 있습니다. 일관성이 대규모 hreflang 묶음과 크롤링을 관리 가능하게 합니다.

5. 국제 타기팅 질문과 일반 질문을 분리하세요. ‘블로그를 어디에 둘까’라는 일반적인 서브도메인 대 서브디렉터리 질문과 ‘여러 국가에 어떻게 서비스할까’는 결정 요인이 다른 별개 결정입니다. 일반 문제는 통합과 마이그레이션 위험, 국제 문제는 지역 신호가 중심입니다. 한쪽 답을 다른 쪽에 그대로 가져오지 마세요.

실력 점검: ccTLD·서브도메인·서브디렉터리

국제 URL 구조 선택에 관한 짧은 다섯 문제입니다. 각각 답을 고른 뒤 확인하세요.

읽어 볼 만한 자료

제가 쓴 관련 글

• Hreflang: The Easy Guide for Beginners (입문자를 위한 쉬운 hreflang 가이드) — gTLD 서브도메인·서브디렉터리에서 의존하는 작동 방식과, hreflang이 얼마나 자주 잘못되는지 보여 주는 제 374,756개 도메인 연구입니다. 67% 넘게 문제가 있었습니다.
• The Beginner’s Guide to Technical SEO (기술 SEO 입문 가이드) — 국제 URL 구조 결정이 전체 그림에서 차지하는 위치입니다.
• Subdomain vs Subdirectory: Subdirectories Are Not Better Than Subdomains For SEO (서브도메인 대 서브디렉터리: SEO에서 서브디렉터리가 더 낫지는 않다) — 두 방식은 기능적으로 동등하며 마이그레이션 ‘성공’ 대부분에는 교란 요인이 있다는 제 일반적·비국제적 주장입니다. ‘블로그를 어디에 둘까’가 질문이라면 이 글을 읽으세요.

제 발표

• How Search Works (검색의 작동 방식, SlideShare) — 크롤링·렌더링·색인·순위에 관한 설명이며 URL 형태가 아니라 신호가 결과를 좌우하는 이유를 이해할 배경입니다. 늘 붙이는 단서도 적용됩니다. “This is my understanding of systems… not going to be 100% complete or accurate.”(한국어 풀이: 이것은 시스템에 대한 제 이해이며 100% 완전하거나 정확하지는 않을 것입니다.)

업계의 다른 자료

• Managing multi-regional and multilingual sites (다지역·다국어 사이트 관리, Google Search Central) — 세 구조와 문서화된 장단점의 원본 목록입니다.
• The International Targeting report is deprecated (국제 타기팅 보고서 폐지, Google Search Console 도움말) — 2022년 9월 제거와 서브폴더 국가 선언에 미치는 의미입니다.
• URL structure best practices (URL 구조 권장사항, Google Search Central) — 지역 타기팅 지침과 선호가 없다는 입장입니다.
• Subdomains vs Subdirectories Research: 20K Keywords Analysed (서브도메인 대 서브디렉터리 연구: 키워드 20K개 분석, SE Ranking) — 15개 시장의 국제 검색 결과에서 ccTLD가 우세함을 보여 주는 투명한 상관관계 연구입니다. 인과관계가 아니라 상관관계로 읽으세요.
• SEO Best Practices with Cloudflare Workers, Part 1: Subdomain vs. Subdirectory (Cloudflare Workers SEO 권장사항 1부: 서브도메인 대 서브디렉터리, Cloudflare) — 서브도메인에 묶여 있지만 서브디렉터리 URL을 원할 때의 리버스 프록시 우회 방식입니다.

변경 내역