다국어 FAQ를 같은 기준으로 관리하는 방법

답변마다 원천과 담당자를 정합니다

FAQ가 늘어나는 속도는 번역 속도보다 원천 확인 속도에 맞춰야 합니다. 가격은 상품 설정, 지원 언어는 운영팀, 제품 규격은 승인된 사양처럼 답변별 원천을 연결합니다. 번역 담당자가 모르는 운영 조건을 추정해 채우지 않게 합니다.

원천이 사람 기억이면 한 달 뒤에 답이 바뀝니다. 가능한 한 URL, 내부 문서 이름, 확인 날짜를 같이 둡니다. 문서에 접근 권한이 없는 작성자에게 그 칸을 맡기지 않습니다.

의료 설명이 필요하면 웹 담당자가 아니라 해당 의료진의 검토를 받습니다. 병원 사이트의 언어 페이지 설계는 외국인 환자 안내와 같은 경계를 유지합니다. 이 글은 FAQ 운영 구조만 다룹니다.

원천이 정해지기 전에 질문 문장만 다듬는 작업은 나중으로 미룹니다. 예쁜 오답이 언어 수만큼 복제됩니다.

공통 사실과 시장별 차이를 나눕니다

모든 칸을 언어별로 따로 관리하면 유지 비용이 커집니다. 모든 칸을 강제로 같게 하면 틀린 시장 조건이 생깁니다. 두 열로 나눕니다.

항목	공통 관리할 내용	별도 확인할 내용
제품·서비스 이름	공식 명칭·표기	현지에서 쓰는 설명·검색 표현
지원 범위	실제 제공 기능·진료 범위	해당 시장에서 제공되는 조건
가격·결제	승인된 원천	통화·세금·결제 수단·공개 범위
문의	공식 채널	지원 언어·시간·응대 가능 여부
정책	실제 승인 문서	국가·상품별 다른 적용 조건

이 표는 법률 해석이 아니라 콘텐츠 관리 목록입니다. 정책 적용 판단은 해당 책임자가 검토합니다. 편집자가 세금 규칙을 요약해 쓰지 않습니다.

차이가 있으면 FAQ 질문에 그 시장을 명시합니다. “영어권 고객의 상담 시간”과 “한국어 상담 시간”을 한 답에 섞지 않습니다. 섞으면 번역이 맞아도 운영이 틀립니다.

질문을 같은 식별자로 연결합니다

권장 관리 열은 이렇습니다. faq_id, 질문 의도, 기준 원문, 언어, 해당 시장 조건, 원천, 검수자, 검수일, 발행 상태.

예시 식별자 contact-language는 시스템 키일 뿐입니다. 공개 질문을 그 키 문장으로 고정하지 않습니다. 언어별 고객이 실제로 묻는 표현으로 질문을 다듬되, 답의 사실관계는 원천과 일치시킵니다.

식별자가 없으면 영어 FAQ와 일본어 FAQ가 같은 의도인지 나중에 찾기 어렵습니다. 스프레드시트라도 식별자 열이 있으면 원문 수정 때 영향 언어를 고를 수 있습니다.

의도 열은 “예약 가능 여부”처럼 짧게 둡니다. 의도 문장이 길어지면 또 다른 본문이 됩니다. 본문은 언어별 답 칸에만 둡니다.

원문이 바뀌면 영향받는 언어를 확인합니다

운영 시간 변경처럼 공통 사실이 바뀌면 관련 언어를 “재검토 필요”로 표시합니다. 기존 번역을 즉시 삭제하거나, 새 내용을 검수 없이 자동 게시하지 않습니다.

중요 오류가 이미 공개돼 있으면 완벽한 번역보다 임시 안내와 문의 경로가 먼저입니다. 틀린 예약 시간을 자연스러운 문장으로 남겨 두는 편이 더 위험합니다.

수정 이력에는 무엇을 바꿨는지만 짧게 남깁니다. 날짜만 바꿔 최신처럼 보이게 하지 않습니다. 검수일과 발행 상태를 구분합니다. 검수는 끝났는데 발행이 남은 칸이 있으면, 그 언어 사이트에는 이전 답이 남아 있는 것입니다.

브리프 단계에서 원천과 담당을 적어 두면 이 재검토가 빨라집니다. 양식은 콘텐츠 브리프와 맞춰 둡니다.

FAQ를 모든 페이지에 반복하지 않습니다

진료 페이지에는 해당 진료의 질문, 가격 페이지에는 상품 조건을 둡니다. 홈에 모든 FAQ를 붙여 넣으면 원천이 분리돼 서로 다른 답이 생깁니다. 공통 데이터를 참조하고, 페이지에는 그 맥락에 필요한 질문만 올립니다.

스키마를 붙이는 일과 답을 맞게 유지하는 일은 다릅니다. 마크업이 있어도 본문이 틀리면 틀린 답이 구조화됩니다. FAQ를 넣는 것만으로 검색 순위나 AI 인용이 따라온다고 설명하지 않습니다.

같은 식별자의 답이 페이지마다 다르면 그게 사고입니다. 배포 전에 식별자 기준으로 한 번 비교합니다. 도구가 없으면 표에서 언어 열을 나란히 놓고 숫자와 채널만 대조해도 됩니다.

언어가 늘어날 때 무너지지 않게 운영하는 법

언어를 추가하는 결정은 마케팅 일정과 운영 가능 여부가 같이 있어야 합니다. 상담 채널이 없는 언어로 FAQ만 열면, 환자는 그 언어로 질문하고 팀은 다른 언어로 답하거나 침묵합니다. 페이지를 열기 전에 응대 가능 요일을 원천에 적습니다.

신규 언어의 첫 주에는 질문 수를 늘리지 않습니다. 공통 사실 칸과 그 시장의 차이 칸만 채웁니다. 질문 수가 많으면 검수가 형식적으로 변하고, 형식적 검수는 시간 오류를 놓칩니다. 시간 오류는 문장 오류보다 상담 비용을 더 만듭니다.

식별자 목록은 위키가 아니라 표로 둡니다. 위키 문장은 검색은 되지만 열 비교가 안 됩니다. 표에 발행 상태를 두면 “검수는 끝났는데 사이트에는 이전 답”인 칸이 보입니다. 그 칸이 보이면 배포를 미룹니다.

외부 번역 업체에 넘길 때는 추정하지 말 칸을 빨간색으로 표시합니다. 가격, 시간, 주소, 지원 여부. 업체가 문장을 매끈하게 만들수록 그 칸의 오류는 잘 안 보입니다. 매끈함 점수를 검수 완료로 쓰지 않습니다.

직원이 바뀌면 원천 권한도 같이 넘깁니다. 전 담당자 메일함에만 있는 조건표는 원천이 아닙니다. 원천이 사라지면 해당 식별자는 재검토입니다. 재검토 중에는 그 답을 다른 언어로 복제하지 않습니다.

다국어 FAQ의 성공은 언어 수가 아닙니다. 각 언어에서 현재 운영과 맞는 답이 유지되는 기간입니다. 그 기간을 점수화하지 않습니다. 틀린 답을 발견한 날짜와 고친 날짜만 남깁니다.

계절 영업시간이 바뀌는 업종이면 공통 사실 칸에 시즌 시작일을 둡니다. 시작일 없이 “겨울은 단축”만 번역하면 언어마다 시작 주가 달라집니다. 날짜가 있는 짧은 답이, 형용사가 있는 긴 답보다 운영에 안전합니다.

고객이 쓰는 메신저 채널이 언어마다 다르면 문의 칸에 채널 이름을 그대로 적습니다. 없는 채널을 있는 것처럼 번역하지 않습니다. 채널이 아직 없으면 그 언어 FAQ의 문의 답을 열지 않거나, 가능한 채널만 적고 없음을 명시합니다. 없음을 명시하는 일이 창피해 보여도, 없는 채널로 기다린 고객보다 낫습니다.

식별자 수를 분기 목표로 두지 않습니다. 목표는 틀린 식별자를 줄이는 쪽에 가깝습니다. 틀린 식별자가 줄었는지는 재검토 표시가 해제된 날짜로 봅니다. 해제 없이 식별자만 늘면 운영 부채입니다. 부채를 언어 확장 성과로 보고하지 않습니다. 확장 보고에는 응대 가능한 언어와 재검토 중인 식별자 수를 같이 적습니다. 응대 불가능한 언어를 열린 언어 수에 넣지 않습니다. 넣은 보고는 상담 팀이 받을 수 없는 기대를 만듭니다. 그 기대가 페이지에 남아 있으면 FAQ가 아니라 오안내입니다. 오안내는 언어를 늘린 성과로 세지 않습니다. 성과로 세면 다음 분기에 같은 오안내가 복제됩니다. 복제를 성과 그래프에 넣지 않습니다.