번역만 하면 다국어 사이트일까?
많은 분들이 웹사이트에 영어 버전을 추가하는 것을 단순히 텍스트를 번역하는 작업이라고 생각합니다. 하지만 실제로 다국어 사이트를 구축해보면 예상치 못한 기술적 과제가 산더미처럼 쏟아집니다. 번역은 시작일 뿐이고, 진짜 작업은 그 이후부터입니다. URL 구조를 어떻게 설계할지, 텍스트 길이가 달라질 때 레이아웃이 깨지지 않을지, 검색엔진은 각 언어 페이지를 제대로 인식할지 — 이 모든 것을 미리 설계해야 합니다.
URL 설계: 서브디렉토리 vs 서브도메인
다국어 사이트의 첫 번째 결정은 URL 구조입니다. 크게 세 가지 방식이 있습니다. 서브디렉토리 방식(example.com/en/, example.com/ko/)은 하나의 도메인 권한을 공유하므로 SEO에 유리하고 관리가 편합니다. 서브도메인 방식(en.example.com)은 언어별로 서버를 분리할 수 있지만 검색엔진이 별도 사이트로 인식할 수 있습니다. 별도 도메인(example.kr, example.com)은 브랜딩에는 강하지만 비용과 관리 부담이 큽니다. 대부분의 중소기업에는 서브디렉토리 방식을 추천합니다. 설정이 간단하고 SEO 효과를 가장 효율적으로 누릴 수 있기 때문입니다.
hreflang 태그 — 검색엔진에 언어를 알려주는 법
구글이 한국어 페이지와 영어 페이지의 관계를 이해하려면 hreflang 태그가 필수입니다. 이 태그는 각 페이지의 언어와 지역 버전을 검색엔진에 명시적으로 알려줍니다. 예를 들어 한국어 페이지에는 hreflang="ko", 영어 페이지에는 hreflang="en"을 설정하고, 각 페이지가 서로를 참조하도록 양방향으로 선언해야 합니다. 이 설정을 빠뜨리면 검색 결과에서 엉뚱한 언어 버전이 노출되거나, 중복 콘텐츠로 불이익을 받을 수 있습니다.
레이아웃이 깨지는 진짜 이유
같은 문장이라도 언어에 따라 길이가 크게 달라집니다. 한국어로 "문의하기"는 세 글자지만, 독일어로는 "Kontaktieren Sie uns"처럼 훨씬 길어집니다. 반대로 영어 "Settings"가 중국어로는 "设置" 두 글자가 됩니다. 이런 차이를 고려하지 않으면 버튼이 넘치거나, 내비게이션이 두 줄로 밀리거나, 카드 레이아웃의 높이가 들쑥날쑥해집니다. CSS에서 고정 너비 대신 유연한 단위를 사용하고, 텍스트가 150% 이상 길어져도 레이아웃이 유지되는지 반드시 테스트해야 합니다. 아랍어나 히브리어처럼 오른쪽에서 왼쪽으로 읽는(RTL) 언어를 지원한다면 CSS의 논리적 속성(margin-inline-start 등)을 활용하는 것도 중요합니다.
번역 관리는 시스템으로 해결한다
페이지가 10개만 넘어도 수동으로 번역 파일을 관리하는 것은 사실상 불가능합니다. 실무에서는 언어 파일을 JSON이나 YAML로 분리하고, 키-값 구조로 텍스트를 관리합니다. Laravel이라면 내장 다국어 기능(lang 디렉토리)을, React 기반이라면 i18next 같은 라이브러리를 사용합니다. 핵심은 코드에서 직접 텍스트를 하드코딩하지 않는 것입니다. 모든 텍스트를 언어 파일로 분리해두면 번역가에게 파일만 전달하면 되고, 새로운 언어를 추가할 때도 파일 하나만 추가하면 됩니다.
실무에서 놓치기 쉬운 디테일들
다국어 사이트를 운영하다 보면 예상치 못한 곳에서 문제가 터집니다. 날짜와 숫자 형식은 나라마다 다릅니다. 미국식 04/09/2026은 유럽에서 9월 4일로 읽힙니다. 통화 표기, 전화번호 형식도 마찬가지입니다. 이미지 속 텍스트도 번역 대상입니다. 배너나 인포그래픽에 한국어가 박혀 있으면 다른 언어 사용자에게는 의미 없는 그림이 됩니다. 가능하면 이미지 위에 HTML 텍스트를 올리는 방식으로 제작하는 것이 좋습니다. 또한 언어 전환 UI를 국기 아이콘으로 만드는 것은 피해야 합니다. 하나의 국기가 하나의 언어를 대표하지 않기 때문입니다. 영어를 미국 국기로 표시하면 영국, 호주 사용자는 어색함을 느낍니다.
CYAN이 다국어 프로젝트를 접근하는 방식
CYAN에서는 다국어 프로젝트를 진행할 때 설계 단계에서부터 언어 확장을 고려합니다. URL 구조와 hreflang 설정을 초기에 잡아두고, 레이아웃은 텍스트 길이 변화에 유연하게 대응하도록 설계합니다. 번역은 시스템으로 관리하되, 기계 번역에만 의존하지 않고 현지화(localization) 관점에서 맥락에 맞는 표현을 사용하는 것을 중요하게 생각합니다. 글로벌 시장을 고려하고 계신다면, 처음부터 다국어를 염두에 둔 설계가 나중에 드는 비용을 크게 줄여줍니다.