다국어 홈페이지는 같은 업무 정보를 여러 언어로 제공하면서 각 페이지의 대응 관계를 유지하는 웹 운영 체계입니다. 번역된 글만 올리면 해외 방문자가 자연스럽게 올바른 문서로 이동할 것 같지만, 실제로는 메뉴가 다른 언어로 돌아가거나 문의 폼이 원문으로만 남는 문제가 생깁니다. 이 글은 새 언어 사이트를 준비하는 담당자가 주소, 번역 범위와 검수 책임을 함께 정하기 위한 실무 제안입니다.
번역하기 전에 무엇을 목록으로 만들어야 합니까?
출발점은 번역할 문장의 양이 아니라 해외 고객이 완료하려는 일입니다. 회사 소개를 읽는 사람, 제품 사용 조건을 확인하는 사람, 서비스 제공 지역을 묻는 사람은 필요한 페이지가 다릅니다. 기존 메뉴를 그대로 복사하지 말고 방문 목적과 필수 정보를 연결한 목록을 만듭니다. 해외에서 판매하지 않는 제품이나 제공하지 않는 서비스도 따로 표시해 번역 대상과 구분합니다.
목록에는 원문 주소, 문서 주제, 해외 독자, 대상 언어, 정보 소유자와 검토 상태를 적습니다. 파일 다운로드, 문의 완료 화면, 오류 안내처럼 주 메뉴에 보이지 않는 화면도 포함합니다. 담당자가 전체 화면을 직접 이동하면서 목록을 대조하면 버튼 뒤에 숨어 있는 원문 문구를 발견할 수 있습니다. 번역을 맡기는 시점에 누락 화면까지 알려줘야 추가 작업의 범위를 협의하기 쉽습니다.
공개 범위는 팀이 유지할 수 있는 정보부터 정합니다. 모든 게시물을 번역한 뒤 갱신을 멈추는 것보다 핵심 서비스의 조건과 연락 방법을 정확히 유지하는 편이 실무적으로 낫습니다. 제공 가능한 범위는 웹사이트 구축 범위와 대조하되, 별도 언어가 포함되는지 계약에서 확인해야 합니다. 이 글의 절차는 작업 방법이지 특정 상품에 추가 언어가 포함된다는 약속이 아닙니다.
언어별 주소 대응표는 어떻게 작성합니까?
대응표의 한 행에는 동일한 주제를 설명하는 원문과 번역문의 주소를 넣습니다. 서비스 안내와 회사 소개처럼 목적이 다른 문서를 단지 언어가 같다는 이유로 연결하지 않습니다. 번역이 없는 문서는 공란으로 남기고 미번역 상태를 별도 열로 표시합니다. 임시로 모든 행에 외국어 홈 주소를 넣으면 작업자는 연결이 끝났다고 착각하고 방문자는 원래 찾던 내용을 잃게 됩니다.
주소와 별도로 안정적인 문서 식별자를 두는 방법도 유용합니다. 제목을 고치거나 폴더를 옮겨도 식별자가 같으면 같은 주제의 번역 관계임을 확인할 수 있습니다. 사람이 관리하는 문서에서는 식별자와 변경 사유를 기록하고, 시스템에서 관리한다면 번역 관계가 어느 필드에 저장되는지 정합니다. 주소 문자열만 비교해서 연결 관계를 추정하지 않는 것이 핵심입니다.
대응표는 개발자만 보는 문서가 아닙니다. 번역가는 문서의 목적을, 영업 담당자는 현지 제공 조건을, 운영자는 문의 이후 처리를 확인할 수 있어야 합니다. 새 언어의 페이지 수와 원문 페이지 수가 다를 수 있으므로 숫자를 맞추는 작업보다 고객의 중요한 경로가 완결되는지 살펴봅니다. 언어 선택에서 요청 완료까지 이어지는 경로를 대표 시나리오로 남겨 인수인계 자료에 포함합니다.
hreflang은 어떤 관계를 알려 줍니까?
hreflang은 같은 콘텐츠의 언어 또는 지역별 변형을 검색엔진에 알리는 표시입니다. Google 공식 문서는 각 버전에 자기 자신과 대응 버전을 포함하고, 상대 페이지에서도 되돌아오는 관계를 제공하도록 설명합니다. 절대 주소를 쓰고 실제 존재하는 언어 버전과 연결해야 합니다. 구현 방법은 HTML, HTTP 헤더, 사이트맵 중 관리하기 적절한 방식을 선택할 수 있습니다. Google 언어별 버전 안내를 구현 기준으로 확인합니다.
실무 검수에서는 태그의 개수보다 대응표와 출력 결과가 일치하는지 봅니다. 원문 서비스에서 번역 서비스로 연결한 값이 실제 배포된 페이지에도 있는지 확인하고, 번역 서비스를 열어 원문으로 돌아오는 값도 확인합니다. 한쪽만 수정하는 일을 막기 위해 같은 데이터에서 관계를 생성하고, 변경 시 연결된 페이지들을 한 묶음으로 검사하는 운영 방식을 권합니다.
이 표시가 번역 품질이나 해외 검색 성과를 대신하지는 않습니다. 외국어 메뉴 아래 원문 본문이 그대로 있으면 방문자가 읽을 수 없는 문제는 남습니다. 기술 담당자에게는 출력 관계 검수를, 언어 담당자에게는 내용과 의미 검수를 맡겨 결과를 따로 기록합니다. 서로 다른 완료 조건을 합쳐서 단순히 다국어 설정 완료라고 보고하지 않습니다.
방문자가 직접 언어를 바꿀 수 있습니까?
언어 선택 메뉴는 방문자가 현재 어디로 이동할지 예상할 수 있게 만듭니다. 현재 읽는 제품의 다른 언어 문서가 있다면 그 문서로 연결하는 것이 자연스럽습니다. 번역이 없으면 없는 이유나 지원하는 대안 경로를 안내하고, 전혀 다른 문서로 이동시키면서 같은 내용인 것처럼 표시하지 않습니다. 선택 이후에도 현재 언어가 메뉴와 본문에서 식별되는지 확인합니다.
접속 위치나 브라우저 언어를 참고하더라도 사용자의 선택권은 남겨 두는 편이 좋습니다. 해외 출장 중인 기존 고객이나 외국어 자료를 대신 확인하는 국내 담당자를 생각하면 위치가 곧 읽을 언어는 아닙니다. 추천 언어를 안내하는 기능과 다른 문서를 볼 수 없게 강제하는 기능을 구분하고, 고객이 선택한 언어를 바꿀 수 있는 경로를 시험합니다.
모바일에서는 좁은 메뉴 안에서 언어 버튼이 사라지거나 메뉴를 닫을 수 없는 문제가 없는지 봅니다. 키보드로 메뉴를 열고 항목을 고른 뒤 초점이 자연스럽게 이동하는지도 확인합니다. 언어 이름은 담당자가 구분하기 쉬운 약어만 쓰기보다 해당 언어 독자가 알아볼 수 있게 표시합니다. 작은 탐색 요소지만 구매 조건을 읽기 전 이탈하는 문제와 연결되므로 실제 사용 경로에서 검수해야 합니다.
원문과 현지화 문구가 달라도 됩니까?
현지화는 단어를 바꾸는 작업을 넘어 독자가 이해할 조건을 풀어 주는 편집입니다. 국내에서 익숙한 약어는 해외 독자에게 설명이 필요할 수 있고, 문의 가능 시간은 상대 지역에서 해석할 수 있는 기준이 필요합니다. 반면 계약 조건이나 성능 수치처럼 임의로 달라져서는 안 되는 사실은 원문 책임자가 확인해야 합니다. 문체 수정과 사업 조건 변경을 같은 승인으로 처리하지 않습니다.
검토표에는 원문 유지 항목과 현지 조정 항목을 나눕니다. 법인명, 제품 식별 정보와 검증 자료는 공통 사실로 묶고, 문의 안내나 사례 설명 방식은 현지 독자에 맞게 검토할 수 있습니다. 원문에 없는 인증이나 제공 지역을 번역 과정에서 추가하지 않습니다. 설명이 부족하다면 사실 소유자에게 질문을 남겨 답변을 받은 뒤 반영합니다.
공개 가능한 정보와 아직 협의 중인 정보도 구분합니다. 한 지역에서 제공하는 조건을 모든 국가에 적용되는 약속처럼 쓰면 문의 이후 불일치가 생깁니다. 페이지가 대상으로 하는 고객과 제공 범위를 첫 부분에서 알려 주고, 예외 조건은 핵심 설명에서 멀리 숨기지 않습니다. 번역 완료라는 표시보다 내용 승인자의 확인일이 더 중요한 이유입니다.
이미지와 다운로드 자료도 번역 대상입니까?
본문이 외국어여도 그림 안의 설명이나 내려받은 안내서가 원문뿐이면 독자의 이해가 끊깁니다. 이미지 안에 포함된 문자, 표 제목, 버튼 이미지와 첨부 문서를 목록에 넣습니다. 다시 편집할 수 없는 이미지 원본만 있다면 텍스트를 분리해 설명하는 방식도 검토합니다. 자료를 여는 순간부터 어떤 언어인지 알 수 있도록 다운로드 링크 주변의 설명을 정리합니다.
그림을 다른 언어로 제작할 때는 의미가 달라지지 않았는지 원문과 나란히 대조합니다. 공정 순서, 서비스 제공 단계와 비교 조건을 눈으로 검수하고, 단순히 이미지 파일이 교체됐는지만 확인하지 않습니다. 사진을 설명하는 대체 텍스트 역시 해당 페이지의 언어와 맥락에 맞아야 합니다. 생성형 이미지는 개념 설명용인지 실제 제품이나 현장 증빙인지 명확히 구분합니다.
자료마다 수정 책임과 최신판 위치를 기록하면 외국어 첨부 파일이 낡은 상태로 남는 일을 줄일 수 있습니다. 콘텐츠 발행 운영에서 원고, 이미지와 첨부 자료를 함께 관리하는 이유도 여기에 있습니다. 본문만 승인하고 다운로드 파일은 별도로 두면 서로 다른 조건이 동시에 공개될 수 있으므로 발행 단위에 포함해 확인합니다.
문의 이후에도 선택한 언어가 이어집니까?
다국어 페이지의 마지막 검수 지점은 문의 버튼이 아니라 문의 이후의 처리입니다. 필수 입력 오류, 개인정보 안내, 접수 완료 화면과 자동 응답 문구가 독자에게 이해되는지 봅니다. 어떤 언어로 회신할 수 있는지 아직 확정되지 않았다면 가능한 대응 범위를 먼저 안내합니다. 화면만 외국어로 바꿔 실제로 제공하지 못하는 지원 수준을 암시하지 않습니다.
폼에서 언어와 방문 페이지를 담당자가 구분할 수 있도록 전달하면 내부 배정에 도움이 됩니다. 다만 연락처나 요청 본문 같은 개인정보를 분석 이벤트나 공개 주소에 그대로 붙이지 않습니다. 테스트는 운영자가 승인한 연락처와 명확한 시험 문구로 수행하고, 수신자가 이를 실제 고객 요청으로 오해하지 않게 합니다. 화면 접수와 내부 수신을 각각 확인한 뒤 결과를 남깁니다.
진단이 필요한 경우에는 무상 사전 진단 신청 전에 현재 홈페이지 주소와 검토할 언어 경로를 준비하면 좋습니다. 번역문 자체의 품질 문제와 페이지 연결 문제를 분리해서 설명할 수 있기 때문입니다. 새 언어가 필요한 업무 목적을 함께 적으면 기술 설정을 늘리는 작업과 실제 고객 경로를 완성하는 작업을 구분해 계획할 수 있습니다.
원문이 바뀌면 번역문은 어떻게 갱신합니까?
원문 수정은 번역본을 다시 살펴볼 계기이지 번역본을 자동 승인하는 근거가 아닙니다. 바뀐 문장과 영향받는 문서 식별자를 남기고 대응하는 언어 담당자에게 전달합니다. 오탈자, 일반 설명과 계약 조건 변경의 중요도가 다르므로 수정 유형을 함께 적으면 검토 우선순위를 정하기 쉽습니다. 번역본을 언제까지 유지하거나 수정해야 할지는 업무 책임자가 판단합니다.
변경 이력에는 원문 버전, 번역에 사용한 버전, 검수자와 공개일을 각각 보관합니다. 문서가 오래됐다는 이유만으로 날짜만 새로 표시하지 않습니다. 검수하지 못한 번역은 내부에서 대기 상태로 관리하고 공개 정보에 중대한 불일치가 있으면 노출 범위를 조정하는 결정을 남깁니다. 누가 언제 무엇을 확인했는지가 빠지면 담당자가 바뀐 뒤 같은 문서를 다시 조사하게 됩니다.
갱신 주기는 회사의 정보 변동에 맞춰 정할 수 있지만, 변경 사실을 발견하는 경로는 명확해야 합니다. 신제품 추가, 서비스 종료와 연락처 변경 같은 사건을 웹 운영자에게 알리는 담당자를 둡니다. 번역 담당자가 우연히 원문을 읽고 변화를 찾도록 맡기는 구조는 피합니다. 내부 알림과 발행 승인 절차를 연결하면 추가 언어가 늘어도 책임이 분산되지 않습니다.
공개 전후 검수 결과는 어떻게 남깁니까?
언어별 용어집에는 원어와 번역어만 적지 말고 사용한 제품이나 서비스의 문맥을 덧붙입니다. 같은 원어라도 부서와 문서에 따라 뜻이 달라질 수 있기 때문입니다. 번역가가 용어 변경을 제안하면 관련 원고들을 함께 찾고 기존 표현과 새 표현이 섞이지 않는지 확인합니다. 고유 명칭의 표기 기준과 일반 설명을 구분해 두면 새 글을 추가할 때도 브랜드 이름을 임의로 번역하거나 다른 상품처럼 표시하는 실수를 줄일 수 있습니다.
검수 기록은 주소 연결, 언어 이해, 거래 조건과 문의 처리로 나누어 작성합니다. 발견한 문제에는 재현 주소와 이동 경로를 붙이고, 수정 후에는 같은 경로로 다시 확인합니다. 스크린샷만 있으면 어떤 버전인지 알기 어려우므로 확인 시점과 배포 식별 정보도 함께 적습니다. 승인 여부와 미해결 항목을 따로 남겨 조건부 공개 판단을 추적할 수 있게 합니다.
공개 후에는 현지 고객이 실제로 어떤 문서에 도착했는지 관찰하면서 대응표를 보완합니다. 잘못된 언어로 연결된 문의, 이해하기 어려운 용어와 빠진 첨부 자료를 분류해 다음 수정에 반영합니다. 검색 노출의 변동을 번역 오류로 단정하거나 번역만으로 성과가 보장된다고 설명하지 않습니다. 기술과 내용의 관찰 결과를 합쳐 운영상의 원인을 찾는 것이 목적입니다.
최종 인수인계에는 원문과 번역본의 연결 자료, 용어 기준, 정보 책임자, 공개 경로와 예외 처리를 넣습니다. 후임자는 문서의 언어를 읽지 못하더라도 누구에게 무엇을 확인해야 하는지 알 수 있어야 합니다. 다국어 홈페이지의 완성도는 번역된 화면 수보다 동일한 고객 질문에 일관된 사실로 답하고, 변경된 사실을 모든 관련 언어에 전달할 수 있는 운영 구조에서 드러납니다.