공공기관 홈페이지 다국어 페이지 설계 기준을 단계별로 정리했습니다. 지원 언어 결정, 핵심 메뉴 선정, 번역 범위와 예산 산정까지 제작 전 반드시 확인할 실무 체크포인트를 안내합니다.
- 다국어 홈페이지 설계, 왜 '번역'보다 '항목 선정'이 먼저인가 — 결론 요약
- 준비 단계: 지원 언어 결정과 핵심 정보·메뉴 선정 기준
다국어 홈페이지 설계, 왜 '번역'보다 '항목 선정'이 먼저인가 — 결론 요약
다국어 홈페이지 프로젝트가 어긋나는 지점은 대부분 번역 단계가 아닙니다. "무엇을 번역할 것인가"를 정의하지 않은 채 시작하기 때문이죠. 메뉴 전체를 영어로, 일부를 중국어로, 그러다 예산이 바닥나면 어중간한 반쪽짜리 사이트가 남습니다.
왜 '항목 선정'이 먼저인가
외국인 이용자가 실제로 찾는 정보는 생각보다 좁습니다. 이용 안내, 민원 절차, 공고, 연락처 같은 핵심 화면입니다. 이 범위를 먼저 고정하면 언어를 늘려도 페이지 수가 통제되고, 예산과 운영 부담이 선형으로 늘어나는 대신 '필요한 화면만큼만' 묶입니다.
국제행사·학회 운영에서 이미 검증된 방식이 이것입니다. 실제 사례를 보면:
- 해외 학회 지원을 위해 영문 홈페이지, 다국어 등록 폼, 해외카드·PayPal 같은 국제 결제를 묶어 제공
- 학회 전용 포털은 한국어·영어 다국어 지원과 함께 세션·연사·좌장 정보를 다국어로 등록·관리
- 현장 배지조차 한국어·영어 다국어 배지로 운영
즉, '외국인이 실제로 쓰는 화면만 다국어화'하는 것이 표준이지, 사이트 전체를 통째로 번역하는 것이 아닙니다. 행사 중에는 AI 동시통역으로 발표 언어를 즉시 전환하고, 전문 용어집과 발표 초록 사전 학습으로 의학·기술 용어 오류까지 줄이는 식으로, '정적 번역'과 '실시간 통역'의 역할을 분리하는 것이죠.
준비 단계: 지원 언어 결정과 핵심 정보·메뉴 선정 기준
다국어 홈페이지 프로젝트가 흔히 처음부터 꼬이는 지점이 바로 여기예요. "우리 홈페이지 메뉴 전부 영어로 번역해 주세요"라고 시작하면, 예산은 예산대로 쓰고 정작 외국인이 찾는 정보는 놓치게 됩니다. 언어 수와 메뉴를 정하는 기준부터 잡아볼게요.
지원 언어는 어떻게 정하나
세 가지 기준을 순서대로 대입해 보세요.
- 이용 통계: 어떤 국적의 방문자가 어느 페이지를 보는지 로그를 확인합니다. 영어 페이지 체류 시간이 짧고 특정 국적 비중이 높다면 그 언어가 1순위예요.
- 법적 요구사항: 다국어 정보 제공이 의무인 항목(민원 안내, 고지·공고 등)이 있다면 해당 언어는 선택이 아니라 필수입니다.
- 예산: 언어 하나를 추가할 때마다 번역·감수·유지보수 비용이 선형으로 늘어납니다. 의무 언어 → 이용 비중 높은 언어 순으로 채우는 게 현실적이에요.
번역 범위와 예산 산정: 전체 번역 vs 핵심 정보 번역 비교
번역 범위를 정하는 일은 사실 예산을 정하는 일과 거의 같습니다. "전부 번역할까, 필요한 것만 번역할까"를 정하기 전에 두 방식이 실제 운영에서 어떻게 다른지를 먼저 보는 게 좋습니다.
| 항목 | 전체 페이지 번역 | 핵심 정보 번역 |
|---|---|---|
| 일관성 | 사이트 전체 용어·톤 통일 용이 | 번역/미번역 페이지 간 톤 엇박자 가능 |
| 초기 비용 | 페이지 수 × 언어 수만큼 증가 | 번역 대상을 줄여 통제 가능 |
| 유지보수 | 원문 수정 시 모든 언어 페이지 동기화 필요 | 갱신 부담 적음 |
| 미번역 안내 | 불필요 | "한국어 페이지로 이동" 등 안내 장치 필수 |
핵심 정보 번역을 선택했다면, 외국인 이용자가 빈 페이지를 만나지 않도록 미번역 콘텐츠에 대한 안내 문구와 이동 경로까지 설계에 넣어야 합니다. 이게 빠지면 "깨진 사이트"라는 인상을 줍니다.
- 변경 빈도가 낮은 정적 콘텐츠 (조직 소개, 이용 안내, 절차 설명): 전문 번역으로 정확도를 높이는 게 맞습니다. 한 번 번역하면 오래 쓰니 초기 비용이 아깝지 않습니다. - 빈번히 바뀌는 공지·게시글·알림: 기계번역 + 전문가 검수 혼용이 합리적입니다.
관리자·CMS 구조와 한국어-번역본 동기화 운영 프로세스
공지 하나를 수정하는 순간 문제가 시작됩니다. 한국어 페이지엔 바뀐 마감일이 반영됐는데 영어 페이지엔 예전 날짜가 그대로면, 외국인 이용자는 그걸 공식 안내로 믿고 행동합니다. 민원이 들어와야 불일치를 발견하는 구조라면 이미 늦은 거죠.
왜 번역본이 방치될까
언어별 페이지를 복사해 따로 관리하는 구조가 가장 흔한 원인입니다. 원본과 번역본을 잇는 연결고리가 없으니 수정은 한쪽에만 반영되고, 격차는 시간이 지날수록 벌어집니다.
해결의 출발점은 콘텐츠 원본과 번역본을 하나의 데이터 구조(다국어 필드 매핑)로 묶는 설계입니다. 제목·본문·첨부 같은 필드마다 언어별 값을 붙이고, 관리자 화면에서 언어별 상태를 한눈에 확인할 수 있어야 합니다.
- 번역 대기: 원본 등록 후 번역이 안 된 상태
- 번역 완료: 검토를 거쳐 게시된 상태
- 원본 수정됨: 한국어가 바뀌어 번역본이 뒤처진 상태
| 항목 | 흔한 실수 구조 | 권장 구조(매핑형) |
|---|---|---|
| 원본 수정 시 | 번역 페이지에 표시 없음 | 연결된 전 언어에 '갱신 필요' 자동 표시 |
| 게시 흐름 | 언어별 개별 등록 | 검토·번역 후 게시 승인 단계 |
| 불일치 점검 | 민원 발생 후 사후 확인 | 정기 점검으로 사전 확인 |
권장 운영
KWCAG 웹 접근성·lang 속성 적용과 최종 설계 체크리스트
스크린리더 사용자가 언어 전환 버튼을 눌러 영문 페이지에 들어왔는데, 화면의 영어 문장이 한국어 발음 규칙으로 읽힌다면 그 페이지는 이미 접근성에서 실패한 상태입니다. 실무에서 가장 흔한 케이스가 바로 URL만 언어별 경로로 바뀌고 lang 값은 ko로 남아 있는 경우입니다.
언어별 독립 URL 구조 자체는 좋은 설계입니다. AI 동시통역 자막처럼 언어별 독립 URL로 서비스를 운영하는 사례도 있지만, URL이 나뉜 것과 lang 값이 정확한 것은 별개 문제입니다. KWCAG 관점의 판단 기준은 단순합니다. 지금 이 페이지의 lang 값이 화면에 보이는 언어(ko, en, ja, zh)와 일치하는가, 본문 중간에 다른 언어 문구가 섞였다면 해당 요소에 lang을 지정했는가입니다. 언어 전환 링크도 같이 점검해야 합니다. 국기 아이콘만 단독으로 걸면 스크린리더가 무엇을 의미하는지 인식하지 못하므로, 전환 대상 언어 자체로 된 텍스트 라벨을 함께 노출하고 기계번역이 섞인 페이지라면 번역 방식을 알리는 안내 문구를 표기해야 사용자가 정보를 걸러 읽을 수 있습니다.