4편. 다국어 웹사이트 모바일 설계: 텍스트 팽창·RTL·폰트 선택까지
기술 설정을 마쳤다. 이제 독자가 실제로 보는 화면을 설계할 차례다. 다국어 사이트에서 반응형 디자인과 템플릿 설계는 단일 언어 사이트와 다르다. 언어마다 텍스트 길이가 달라지고 읽기 방향도 바뀐다. 폰트도 달리 써야 한다. 이 편에서는 온라인 신문사 창업자가 직접 적용할 수 있는 설계 원칙을 정리한다.
다국어 웹사이트 구조와 기술 설계
2편. 언어 선택 UI는 설계방법
3편. CMS와 번역 도구 선택 기준
4편. 모바일과 글로벌 템플릿 설계 팁 ← 현재글
5편. 다국어 사이트 기술 체크리스트 (예정)
6편. 운영 효율을 높이는 구조 설계 원칙 (예정)
7편. 구축 전 반드시 확인할 테스트 항목 (예정)
왜 글로벌 템플릿이 필요한가?
다국어 사이트를 운영할 때 언어별로 디자인을 따로 만드는 실수를 한다. 한국어판은 한국어판대로 영어판은 영어판대로 레이아웃을 따로 짠다.
이렇게 하면 한쪽 언어판을 수정하면 나머지도 일일이 수정해야 한다. 브랜드 일관성이 무너진다. 운영 부담이 배로 늘어난다.
해결책은 하나의 글로벌 템플릿이다. 레이아웃, 색상, 폰트 구조를 하나로 통일하고 언어별 콘텐츠만 교체하는 방식이다. 세계 주요 다국어 미디어 대부분이 이 방식을 쓴다. 변경 사항을 한 번만 반영하면 모든 언어판에 자동으로 적용된다.
가장 먼저 알아야 할 것: 텍스트 팽창
다국어 설계에서 가장 자주 놓치는 함정이 텍스트 팽창(Text Expansion)이다. 영어를 다른 언어로 번역하면 텍스트 길이가 달라진다.
대표적인 수치를 보자. 독일어는 영어보다 30~70% 더 길다. 프랑스어·스페인어는 20~35% 더 길다. 반대로 한국어·일본어·중국어는 영어보다 오히려 짧아지거나 밀도가 높아진다. 글자 수는 줄지만 글자 하나가 차지하는 공간이 크다.
실제 사례를 보면 피부에 와닿는다. 영어로 'Save'는 4글자다. 독일어로 'Speichern'은 되면 9글자다. TED 앱은 독일어 론칭 후 버튼 라벨이 잘리는 문제로 긴급 UI 수정을 해야 했다.
온라인 신문사 입장에서 특히 주의해야 할 곳이 있다. 헤드라인, 내비게이션 메뉴, 카테고리 버튼이다. 이 요소들은 공간이 제한적이면서 텍스트가 들어가는 곳이다.
텍스트 팽창 대응 설계 원칙
고정 너비를 쓰지 말자. 버튼, 메뉴, 헤드라인 컨테이너는 모두 유동적(flexible) 크기로 설계한다. 픽셀로 고정하면 독일어 번역이 들어올 때 잘린다.
유럽 언어 대상이라면 30~50% 여백을 미리 확보한다. 디자인 초기부터 텍스트 공간에 버퍼를 두는 것이다. 나중에 수정하는 것보다 훨씬 빠르다.
CSS clamp()를 활용한다. 폰트 크기를 화면 크기에 따라 자동으로 조정하는 CSS 함수다. 텍스트가 길어져도 레이아웃이 깨지지 않게 해 준다.
/* 예: 반응형 헤드라인 폰트 */
h1 {
font-size: clamp(1.2rem, 3vw, 2.5rem);
}
RTL 언어: 방향이 바뀌면 레이아웃도 바뀐다
아랍어, 히브리어, 페르시아어, 우르두어는 오른쪽에서 왼쪽(RTL)으로 읽는다. 전 세계 약 6억 명 이상이 RTL 언어를 사용한다.
RTL은 단순히 텍스트 방향만 바뀌는 게 아니다. 레이아웃 전체가 거울처럼 뒤집힌다. 내비게이션 메뉴가 오른쪽으로, 사이드바가 왼쪽으로, 스크롤바 방향도 바뀐다. 방향을 가리키는 아이콘(화살표, 진행 표시기)도 반전해야 한다.
처음 RTL 언어를 지원할 계획이 없더라도 글로벌 템플릿을 설계할 때 RTL을 염두에 두고 CSS를 짜는 것이 좋다. 나중에 추가할 때 리팩터링 비용이 크게 줄어든다.
RTL 설계 핵심 두 가지
첫째, dir="rtl" 속성을 HTML에 추가한다. RTL 언어 페이지의 <html> 태그에 dir="rtl"을 추가하면 브라우저가 기본 방향을 자동으로 전환한다.
<!-- 아랍어 페이지 -->
<html lang="ar" dir="rtl">
둘째, CSS 논리 속성(Logical Properties)을 사용한다. margin-left 대신 margin-inline-start를, padding-right 대신 padding-inline-end를 쓰면 LTR·RTL 언어에서 각각 올바른 방향으로 자동 적용된다. 별도 RTL 전용 CSS 파일을 만들지 않아도 된다.
/* 기존 방식 (LTR 고정) */
.nav-item {
margin-left: 16px;
}
/* 논리 속성 방식 (LTR/RTL 자동 대응) */
.nav-item {
margin-inline-start: 16px;
}
폰트 선택: 언어마다 다르게 가야 한다
다국어 사이트에서 폰트 선택은 디자인성의 문제가 아니다. 가독성과 문화적 신뢰도에 직결되기 때문이다.
라틴 문자 언어 (영어·유럽어)
대부분의 웹 폰트가 라틴 문자를 지원한다. Google Fonts의 Roboto, Inter, Open Sans가 무난하다. 특수 문자(ü, ñ, é 등)가 포함된 폰트인지 확인해야 한다.
CJK 언어 (한국어·일본어·중국어)
CJK 언어는 수만 개의 글리프(문자 형태)를 담아야 해서 폰트 파일 크기가 크다. 잘못 선택하면 페이지 로딩이 느려진다.
무료로 쓸 수 있는 최선의 선택은 Google의 Noto 폰트 패밀리다. Noto Sans KR(한국어), Noto Sans JP(일본어), Noto Sans SC(중국어 간체)를 각 언어에 맞게 적용한다. 어도비와 구글이 공동 개발한 Source Han Sans도 CJK 전체를 통합 지원하는 고품질 무료 폰트다.
주의할 점이 있다. CJK 전체를 지원하는 통합 폰트는 파일 크기가 15MB를 넘는다. 방문자 위치에 맞는 언어의 폰트만 로드하도록 서브셋(Subset)을 설정해야 한다.
<!-- 한국어 페이지에만 KR 폰트 로드 -->
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR&display=swap" rel="stylesheet">
아랍어·히브리어
라틴 폰트로는 아랍 문자를 제대로 렌더링 할 수 없다. Google의 Noto Sans Arabic, 또는 Cairo, Amiri 폰트를 사용한다. 아랍어는 글자가 연결되는 필기체 구조라 폰트 선택이 가독성에 미치는 영향이 크다.
모바일 퍼스트 설계: 글로벌 독자의 대다수는 모바일이다
구글은 모바일 퍼스트 인덱싱을 적용한다. 모바일 점수가 SEO에 반영된다는 뜻이다. 다국어 사이트라면 더욱 중요하다. 신흥 시장(동남아, 중동, 아프리카)의 독자들은 PC보다 모바일로 뉴스를 소비한다.
다국어 모바일 설계에서 꼭 확인할 항목
헤더 내비게이션이 긴 번역 텍스트에서 터지지 않는가?
모바일 헤더는 공간이 좁다. 독일어처럼 긴 언어로 메뉴가 바뀌면 버튼이 잘리거나 줄이 바뀐다. 햄버거 메뉴 내부에 언어 전환 옵션을 넣는 것도 방법이다.
터치 타깃 크기가 모든 언어에서 충분한가?
버튼·링크의 터치 영역은 최소 44 × 44px을 권장한다. CJK 언어처럼 문자 밀도가 높으면 링크가 작아질 수 있다.
이미지 속 텍스트를 사용하지 않는가?
이미지 안에 텍스트가 있으면 번역이 불가능하다. 검색 엔진도 읽지 못한다. 텍스트는 반드시 HTML로 처리해야 한다.
폰트 로딩이 모바일 속도에 영향을 주는가?
CJK 폰트를 한꺼번에 로드하면 LCP(최대 콘텐츠풀 페인트)가 나빠진다. font-display: swap으로 폰트 로딩 중에도 텍스트가 먼저 보이게 설정한다.
글로벌 템플릿에서 문화적 차이도 반영하라
디자인 자체도 문화별로 의미가 다를 수 있다. 색상이 대표적이다. 붉은색은 한국·중국에서 긍정(행운, 경사)의 의미가 강하지만, 서구권에서는 경고나 위험을 연상시키는 경우가 많다. 흰색은 서구권에서 순수함을 뜻하지만 동아시아 일부에서는 죽음을 연상시키기도 한다.
온라인 신문사 입장에서 이 문제가 실질적으로 영향을 미치는 곳이 있다. 속보 배너 색상, 카테고리 태그 색상, 광고 배너 배경색이다. 글로벌 템플릿을 설계할 때 색상이 언어별로 쉽게 교체될 수 있도록 CSS 변수(custom property)로 관리하는 것이 좋다.
/* 언어별로 CSS 변수를 덮었어 색상 변경 */
:root {
--accent-color: #e74c3c; /* 기본값 */
}
html[lang="ko"] {
--accent-color: #c0392b; /* 한국어판 조정 */
}
날짜·숫자·통화 포맷도 언어별로 다르다
글로벌 템플릿에서 자주 놓치는 세부 항목들이다.
날짜 형식. 미국에서 01/02/2025는 1월 2일이다. 유럽에서는 2월 1일이다. 한국은 2025년 1월 2일 형식을 쓴다. 날짜는 코드로 형식화하고 언어에 따라 자동으로 표시 방식이 바뀌어야 한다.
숫자 구분자. 미국·영국: 1,234.56 / 독일·프랑스: 1.234,56 / 한국·일본: 1,234.56 (미국식과 같음). 단순해 보이지만 이커머스나 구독 가격 표시에서 오해를 만들 수 있다.
통화. 독자의 위치에 따라 가격이 달리 표시되어야 한다면 서버 사이드 렌더링을 활용한다.
실전 체크리스트
글로벌 템플릿 설계 후 다음을 점검하자.
레이아웃
□ 버튼·메뉴가 고정 너비 없이 유동적으로 늘어나는가?
□ 독일어처럼 긴 언어에서도 레이아웃이 깨지지 않는가?
□ CJK 언어에서 빈 공간이 어색하게 남지 않는가?
RTL
□ RTL 언어 지원 예정이라면 dir="rtl" 구조가 준비되어 있는가?
□ CSS 논리 속성으로 작성되어 있는가?
폰트
□ 각 언어에 맞는 폰트가 지정되어 있는가?
□ CJK 폰트는 서브셋으로 로드해 속도를 최적화했는가?
□ font-display: swap이 적용되어 있는가?
모바일
□ 모든 언어에서 터치 타깃이 충분한가?
□ 이미지 안에 번역 불가능한 텍스트가 없는가?
□ 모바일 PageSpeed Insights 점수를 언어별로 확인했는가?
문화·포맷
□ 날짜 형식이 언어별로 올바르게 표시되는가?
□ 색상이 CSS 변수로 관리되어 언어별 조정이 가능한가?
정리
글로벌 템플릿은 한 번 잘 만들면 언어가 늘어도 추가 설계 비용이 거의 없다. 처음 설계할 때 텍스트 팽창, RTL 방향성, 폰트 선택, 모바일 최적화까지 고려하는 것이 핵심이다. 개별 언어판을 따로 만드는 것보다 훨씬 효율적이다.
소규모 신문사라면 지금 당장 RTL을 지원하지 않아도 된다. 그러나 CSS를 논리 속성 기반으로 작성해 두면 나중에 추가할 때 수고가 훨씬 줄어든다.
다음 편에서는 운영 효율을 높이는 구조 설계 원칙을 다룬다. 팀이 작아도 다국어 사이트를 지속적으로 운영할 수 있는 구조를 어떻게 잡는지 살펴볼 예정이다.
다국어 웹사이트 운영 팁 시리즈 5편: 다국어 사이트에서 꼭 필요한 기술 체크리스트 → 다음 글 보기
댓글
댓글 쓰기