다국어 AI 도구 디렉터리를 구축한 방법

디렉터리는 모든 언어에서 일관된 정체성을 유지해야 합니다

AI 도구 디렉터리에는 서로 연결된 두 가지 역할이 있습니다. 사람들이 유용한 소프트웨어를 발견하도록 돕는 것과 각 등록 항목에 일관된 식별 기준을 부여하는 것입니다. 언어를 추가하면 두 역할의 범위가 모두 넓어집니다. 번역된 인터페이스는 완성된 것처럼 보여도, 그 안의 페이지들은 어떤 URL이 항목을 대표하는지, 번역이 존재하는지, 검색엔진이 어떤 버전을 고려해야 하는지에 대해 서로 다른 정보를 내보낼 수 있습니다.

Toolso는 여러 언어로 AI 도구를 발견하고 출시할 수 있는 플랫폼입니다. 이 글은 2026년 10월 26일에 진행한 소스 검토와 소수의 실제 페이지 점검을 바탕으로 Toolso의 언어별 라우트, canonical URL, 대체 언어 표기, sitemap 항목이 어떻게 연결되는지 설명합니다. 검색 순위 개선을 측정한 글이 아니며, 모든 등록 항목이 설정된 모든 언어로 콘텐츠를 갖추고 있다고 가정하지도 않습니다.

출발점으로 삼기 좋은 질문은 간단합니다. 같은 도구가 여러 언어로 표시될 때 애플리케이션의 모든 부분이 각 언어 버전을 일관되게 설명할 수 있을까요? 이 질문은 콘텐츠 운영과 기술 SEO를 연결합니다. 번역은 메뉴에 선택지를 하나 더 넣는 데서 끝나지 않습니다. 콘텐츠와 라우트, 메타데이터가 서로 맞아야 합니다.

그림 1. 영문 홈페이지. 스크린샷 제공일: 2026년 10월 26일.

1. 언어별 라우트와 언어 식별자를 구분합니다

현재 설정에는 영어, 중국어 간체, 중국어 번체, 한국어, 일본어, 프랑스어, 독일어, 러시아어, 스페인어, 포르투갈어 등 열 개의 로케일이 정의되어 있습니다. 기본 언어는 영어입니다. 라우팅 설정은 필요한 경우에만 언어 접두사를 사용하므로 기본 언어에는 /en 접두사가 필요하지 않고, 다른 로케일에는 접두사가 붙습니다.

실제 사례로 Raphael AI 등록 페이지는 영어에서 /tool/raphael, 중국어 간체에서 /zh/tool/raphael을 사용합니다. 2026년 10월 26일에 두 페이지를 모두 점검했습니다. 렌더링된 canonical URL은 각각 해당 언어 버전을 가리켰습니다.

내부 라우팅 키는 검색엔진에 제공하는 언어 식별자와 구분됩니다. 현재 설정에서 zh는 zh-CN으로, tw는 zh-TW로, es는 es-ES로, pt는 pt-BR로 매핑됩니다. 짧은 내부 키는 라우팅에 편리하지만, 의미가 다른 언어 표기로 아무런 검토 없이 사용되어서는 안 됩니다.

라우터에서는 자동 로케일 감지도 비활성화되어 있습니다. 덕분에 요청 경로에 담긴 언어가 명확해집니다. 그렇다고 현지화가 완료되었다는 뜻은 아닙니다. 내비게이션 번역, 등록 콘텐츠 번역, 올바른 메타데이터는 여전히 각각 점검해야 합니다.

그림 2. Toolso의 Raphael AI 상세 페이지. 2026년 10월 26일에 제공된 스크린샷으로, 제품 화면을 보여 줄 뿐 언어 주석의 검증 결과를 의미하지는 않습니다.

2. URL 식별 규칙은 한곳에서 만듭니다

페이지 메타데이터와 sitemap 생성 과정이 각각 주소를 만들면 작은 URL 차이가 여러 곳으로 퍼질 수 있습니다. 한 구성요소는 기본 로케일을 숨기지만 다른 구성요소는 이를 붙일 수 있습니다. 어떤 구성요소는 도메인 루트의 슬래시를 유지하고 다른 구성요소는 제거할 수도 있습니다. 따로 보면 각 구성요소가 합리적으로 보여도 결과를 합치면 일관성이 깨질 수 있습니다.

Toolso의 canonical, hreflang, sitemap 헬퍼는 절대 URL 생성기를 공유합니다. 이 생성기는 동일한 라우팅 로직에 언어별 경로 생성을 맡기고 루트 경로 정규화 규칙도 하나로 통일합니다. 이 구현에서는 기본 홈페이지 URL이 마지막 슬래시 없이 정규화됩니다. 이는 일관성을 위한 우리의 규칙이며, 모든 웹사이트가 반드시 이 표기 방식을 택해야 한다는 주장은 아닙니다.

메타데이터 헬퍼는 페이지가 나뉜 URL에 사용할 쿼리 값도 지원합니다. 이 옵션을 전달하면 canonical과 대체 언어 URL에 같은 쿼리가 추가됩니다. 이를 통해 호출부는 2페이지를 다른 언어의 2페이지와 연결하고, 실수로 1페이지에 연결하는 일을 피할 수 있습니다. 그래도 각 호출부는 따로 살펴봐야 합니다. 헬퍼가 어떤 기능을 지원한다고 해서 모든 라우트가 그 기능을 올바르게 사용한다는 뜻은 아닙니다.

canonical 표기는 선호하는 URL을 전달합니다. Google이 실제로 선택하는 URL을 보장하지는 않습니다. 이 차이는 Google의 canonical 처리 안내에 설명되어 있습니다.

3. 실제 번역을 기준으로 언어 클러스터를 구성합니다

애플리케이션에서 열 개의 로케일을 지원한다고 해서 모든 도구의 설명이 열 개 언어로 완성되었다는 뜻은 아닙니다. 두 사실을 같게 취급하면 실제 콘텐츠가 제공하는 범위를 넘어서는 언어 표기를 만들게 됩니다.

언어 링크 헬퍼는 사용 가능한 로케일 집합을 받습니다. 호출부가 이 집합을 전달하면 헬퍼는 그 안에 포함된 로케일의 대체 URL만 생성합니다. 기본 언어 버전이 사용 가능한 집합에 속할 때만 해당 버전을 가리키는 x-default 대체 URL을 포함합니다. 집합을 생략하면 설정된 모든 로케일을 선언하므로, 콘텐츠 제공 여부를 정확하게 전달하는 것은 호출부의 중요한 책임입니다.

라우팅 설정에서는 next-intl의 자동 대체 언어 HTTP Link 출력을 비활성화합니다. 대신 페이지 메타데이터와 sitemap 헬퍼를 통해 매핑된 언어 표기를 생성합니다. 이렇게 하면 명시적인 언어 매핑과 별개로 원시 라우팅 키를 기반으로 자동 생성되는 표기 집합을 하나 더 관리할 필요가 없습니다.

배포 후에는 결과를 점검해야 합니다. Raphael 표본에서는 영어와 중국어 간체 페이지 모두 동일한 열 개의 대체 언어 URL과 x-default를 선언했고, 서로를 가리키는 링크도 포함했습니다. 이 점검은 해당 표본에서 렌더링된 표기를 검증한 것이며, 번역 품질이나 검색 색인을 검증한 것은 아닙니다. Google의 다국어 페이지 문서는 언어 코드, 상호 연결 링크, x-default의 기본 대체 버전 역할을 설명합니다.

4. sitemap은 콘텐츠를 바탕으로 만든 목록으로 다룹니다

sitemap 생성기로 가능한 모든 언어 URL을 만들어 내기는 쉽습니다. 더 유용한 목록은 실제로 포함할 조건을 충족한 콘텐츠를 반영합니다.

Toolso의 sitemap 생성기에 있는 도구 데이터 쿼리는 게시된 도구를 선택합니다. 이와 별도로 사용할 수 있는 이름과 유효한 설명 콘텐츠를 갖춘 레코드를 바탕으로 제공 가능한 번역 집합을 만듭니다. 번역 레코드는 커서 기반 배치로 읽으며, 생성기는 모든 설명을 메모리에 쌓아 두는 대신 URL 조합에 필요한 로케일 정보만 유지합니다.

그런 다음 도구 상세 항목은 제공 가능한 로케일에 대해서만 생성됩니다. 블로그 상세 항목도 마찬가지로 각 게시물의 로케일 집합에 따라 필터링됩니다. 두 경우 모두 sitemap 위치와 대체 언어 URL에 공유 URL 헬퍼를 사용합니다. 따라서 데이터베이스에 특정 언어용 자리가 있다는 사실만으로는 상세 페이지 항목이 생성되지 않습니다.

수정 날짜 역시 주의해서 다뤄야 합니다. 도구 상세 항목에는 콘텐츠 중심의 seoUpdatedAt 필드를 사용하고, 블로그 항목에는 해당 콘텐츠의 수정일 또는 게시일을 사용합니다. 조회 수가 바뀔 때마다 새로운 편집 수정이 있었던 것처럼 보이게 하는 대신 의미 있는 콘텐츠 변경을 나타내려는 의도입니다.

그렇다고 생성된 모든 항목이 현재 운영 환경에서 정상이라는 사실이 확인된 것은 아닙니다. sitemap 제출 자체는 참고 신호일 뿐입니다. Google의 sitemap 안내는 크롤링이나 색인 생성을 보장하지 않습니다.

5. 대체 콘텐츠를 명시적인 상태로 다룹니다

번역이 없을 때의 정책이 필요합니다. 그렇지 않으면 동일한 원문 설명이 여러 언어 URL에 나타나는데도 사이트는 이를 완성된 번역처럼 제시할 수 있습니다.

도구 상세 메타데이터에는 번역 대체 콘텐츠를 위한 명시적인 분기가 있습니다. 대체 콘텐츠를 제공할 때는 페이지에 noindex를 지정하고, canonical을 영어 도구 버전으로 연결하며, 해당 응답에서는 대체 언어 클러스터를 비활성화합니다. 일시적으로 사용할 수 없거나 누락된 번역 데이터에는 별도 처리가 적용됩니다. 이를 성공적으로 번역된 페이지로 설명해서는 안 됩니다.

블로그 상세 구현도 관련된 정책을 따릅니다. 대체 콘텐츠는 게시물의 원래 언어를 가리키고, 대체 언어 URL을 비활성화하며, noindex를 사용합니다. 보관 처리된 블로그 콘텐츠에도 noindex가 지정됩니다. 이는 이 프로젝트의 편집 및 기술적 결정이며, 모든 다국어 웹사이트에 똑같은 규칙을 적용하라는 권고는 아닙니다.

실무에서 구분해야 할 것은 번역된 인터페이스와 번역된 콘텐츠입니다. 방문자에게 대체 콘텐츠에 접근할 수 있는 경로가 여전히 필요할 수 있지만, 검색 메타데이터가 이를 독립적으로 완성된 언어판처럼 제시해서는 안 됩니다. sitemap의 콘텐츠 제공 여부 필터는 상세 페이지의 동작과 계속 일치해야 합니다.

6. 구현과 별개로 출력을 검증합니다

헬퍼를 읽어 보는 일은 유용하지만, 방문자와 크롤러가 받는 것은 최종 응답입니다. 미들웨어, 캐시, 데이터 제공 여부, 배포된 버전에 따라 결과가 달라질 수 있습니다. 따라서 코드 검토가 응답 점검을 대신할 수는 없습니다.

저장소에는 응답 상태, robots 지시문, canonical URL, 선택적으로 언어 간 관계를 점검할 수 있는 sitemap 감사 스크립트가 있습니다. 우리는 이 스크립트를 검토하고 Raphael 두 페이지의 렌더링된 메타데이터와 해당 sitemap 항목을 살펴봤습니다. 해당 항목들은 표본 페이지와 동일한 canonical URL 및 대체 언어 URL을 사용했습니다. 운영 환경 전체에 대한 감사는 실행하지 않았고 Search Console도 확인하지 않았습니다.

세 장의 스크린샷은 홈페이지, Raphael AI 등록 페이지, 등록 절차의 시작 화면을 보여 줍니다. 캡처 시점의 인터페이스를 기록한 자료입니다. 기술 점검을 반복하려면 먼저 제공 가능한 두 언어에서 한 등록 페이지의 렌더링된 canonical과 언어 링크를 비교한 다음, 그 URL을 sitemap과 대조하면 됩니다. URL과 날짜도 기록하세요. 번역이 없는 경우의 동작은 따로 테스트해야 합니다. 완성된 번역과 대체 콘텐츠에는 서로 다른 검증 조건이 필요합니다.

Search Console 관찰 결과는 별도 기록으로 남겨야 합니다. Google이 무엇을 크롤링했는지, 어떤 canonical을 선택했는지, 무엇이 색인에 포함되었는지를 기록하는 곳입니다. 분석 지표와 전환 수치도 다른 기록에 남겨야 합니다. 이렇게 기록을 나누면 로컬 구현 점검이 나중에 검색 성과나 매출 성과로 잘못 전달되는 일을 막을 수 있습니다.

다른 디렉터리 제작자가 활용할 수 있는 것

가장 재사용하기 좋은 아이디어는 콘텐츠 제공 여부를 기준으로 URL 선언을 만드는 것입니다. 라우팅 키와 언어 코드를 구분하고, 메타데이터와 sitemap 생성에서 URL 구성 로직을 공유하며, 번역이 없는 경우를 명시적인 상태로 다루세요. 그런 다음 검색 성과를 주장하기 전에 의도한 동작과 실제 응답을 비교해야 합니다.

소규모 팀에서는 이것이 운영 원칙이기도 합니다. 새 언어를 편집 작업 흐름에 넣을 때는 콘텐츠 상태를 파악하고 검증 단계를 마련해야 합니다. 소수의 표본으로도 불일치를 찾을 수 있지만, 디렉터리 전체의 적용 범위를 입증할 수는 없습니다. 라우팅 규칙이나 번역 제공 여부가 바뀌면 URL 클러스터를 다시 점검하세요.

그림 3. 도구 URL을 가져온 후 미디어가 채워진 등록 화면. 2026년 10월 26일에 제공되었으며 최종 등록 완료를 보여 주는 것은 아닙니다. 이미지의 가격과 카운터는 촬영 당시의 인터페이스 정보입니다.

다국어 디렉터리를 만들고 있다면 다음 질문을 염두에 두고 Toolso를 둘러보세요. 각 언어 페이지에 유용한 콘텐츠가 있는가, 그리고 URL 신호가 그 콘텐츠를 정확하게 설명하는가?