이제 AI 기능은 대부분의 제품에 들어 있습니다. 고객센터 페이지의 채팅 어시스턴트, 스토어 안의 AI 검색, 자동 생성 상품 설명, 추천 패널 등입니다. 이들은 모두 사용자의 위치에 따라 다르게 답할 수 있고, 팀이 사무실에서 테스트할 때는 그 차이가 거의 드러나지 않습니다. 여러 시장에 제품을 제공한다면 국가별 AI 출력 점검은 한 시장에서 불만이 들어온 뒤가 아니라 AI와 머신러닝 작업, 그리고 릴리스 테스트와 함께 이루어져야 합니다.
이 가이드에서는 AI 출력이 국가마다 달라지는 이유, 점검할 항목, 테스트 요청을 현지 사용자처럼 보이게 하는 방법, 그리고 한 글자도 같지 않은 답변을 비교하는 방법을 다룹니다.
AI 출력이 국가마다 달라지는 이유
차이 대부분은 모델 자체가 아니라 모델을 둘러싼 제품에서 생깁니다.
- 맥락으로서의 위치. 많은 어시스턴트는 IP로 읽은 사용자의 국가나 도시를 프롬프트에 추가합니다. 조회가 틀리면 엉뚱한 시장에 대한 답을 자신 있게 내놓습니다.
- 지역별 라우팅. 요청이 지역마다 다른 모델, 버전, 엔드포인트로 갈 수 있으며, 데이터 저장 위치 요건 때문인 경우가 많습니다. 같은 날 두 시장에서 서로 다른 모델 버전이 돌아갈 수 있습니다.
- 기능 플래그. AI 기능은 국가별로 순차 출시되는 경우가 많습니다. 한 시장에서 작동하는 버튼이 다른 시장에서는 없거나 고장 나 있을 수 있습니다.
- 정책과 규제 준수 규칙. 건강, 금융, 선거, 연령에 관한 현지 규칙 때문에 일부 국가에서만 거부 응답이나 면책 문구가 나올 수 있습니다.
- 검색 단계. 어시스턴트가 웹, 고객센터, 상품 카탈로그를 검색할 때는 보통 사용자 지역을 기준으로 검색하므로 인용하는 정보와 상품이 달라집니다.
이 중 첫 번째와 마지막은 요청이 출발하는 IP에 좌우됩니다. 그래서 한 곳에서 하는 테스트로는 이를 놓칩니다.
시장별로 점검할 항목
제품을 제공하는 모든 시장에서 같은 속성들을 점검하세요.
| 점검 항목 | 생길 수 있는 문제 |
|---|---|
| 언어 | 일본 사용자에게 영어로 답하거나, 한 답변에 여러 언어가 섞임 |
| 통화와 단위 | 독일 사용자에게 달러로 가격 표시, 킬로미터 대신 마일 사용 |
| 현지 정보 | 그 국가의 배송 기간, 공휴일, 세금 규정, 매장 위치가 틀림 |
| 기능 제공 여부 | AI 기능이 숨겨지거나, 오류가 나거나, “해당 지역에서 이용할 수 없음” 메시지가 표시됨 |
| 정책 동작 | 한 국가에만 적용되어야 할 거부 응답이나 면책 문구가 모든 곳에 나오거나, 그 반대 |
| 상품과 출처 | 그 시장에서 판매하지 않거나 관련 없는 상품을 추천하거나 인용함 |
| 형식 | 날짜, 숫자, 주소가 현지 형식과 다름 |
이 중 몇 가지는 기존 페이지 점검과 겹칩니다. 대규모 현지화 QA 가이드는 문구, hreflang, 레이아웃을 다루고, 이 체크리스트는 그 위에 AI 계층이 더하는 부분을 다룹니다.
현지 사용자로 테스트하기
위치는 보통 IP에서 오므로 테스트 요청은 해당 시장에서 출발해야 합니다. 그 국가를 타기팅한 레지덴셜 프록시로 요청을 보내면 제품이 그곳의 실제 사용자에게 적용하는 지역 감지, 플래그, 정책을 그대로 적용합니다. 데이터센터 대역은 IP 데이터베이스에서 엉뚱한 국가로 매핑되거나 봇 검사에 걸리는 경우가 많아, 그 시장의 누구도 보지 않을 테스트 결과를 얻게 됩니다.
요청의 나머지 부분도 시장에 맞추세요. Accept-Language 헤더, 시간대, 브라우저의 로캘 설정입니다. 영어 브라우저를 쓰는 일본 IP는 일본어 브라우저를 쓰는 일본 IP와 다른 사용자이며, 둘 다 테스트할 가치가 있습니다. 프록시 지역, 시간대, 로캘 맞추기 글에서 이 신호들을 일관되게 유지하는 방법을 설명합니다.
여러 턴이 이어지는 채팅에서는 스티키 세션으로 대화 내내 같은 IP를 유지해, 제품이 사용자가 턴 사이에 위치를 옮기는 것으로 보지 않게 하세요.
customer-USERNAME-country-jp-sid-chat-ja-01-ttl-600:PASSWORD작은 테스트 하네스
아래 하네스는 여러 시장에서 같은 프롬프트를 AI 엔드포인트로 보내고, 정확한 텍스트 대신 속성을 점검합니다. 엔드포인트와 점검 항목은 본인의 것으로 바꾸세요.
import requests
GATEWAY = "p.shifter.io:443"
USER, PASS = "USERNAME", "PASSWORD"
ENDPOINT = "https://app.example.com/api/assistant"
MARKETS = {
"de": {"lang": "de-DE", "currency": "€"},
"jp": {"lang": "ja-JP", "currency": "¥"},
"br": {"lang": "pt-BR", "currency": "R$"},
"us": {"lang": "en-US", "currency": "$"},
}
PROMPTS = ["How much is shipping for a 2 kg parcel?", "Recommend a laptop under my budget."]
RUNS = 3
def ask(country, lang, prompt, run):
proxy = f"http://customer-{USER}-country-{country}-sid-ai-{country}-{run}-ttl-600:{PASS}@{GATEWAY}"
r = requests.post(ENDPOINT, json={"message": prompt},
headers={"Accept-Language": lang},
proxies={"http": proxy, "https": proxy}, timeout=60)
return r.status_code, r.json().get("answer", "") if r.ok else ""
for country, m in MARKETS.items():
for prompt in PROMPTS:
hits = 0
for run in range(RUNS):
status, answer = ask(country, m["lang"], prompt, run)
if status == 200 and m["currency"] in answer:
hits += 1
print(country, prompt[:30], f"currency ok in {hits}/{RUNS} runs")위 표의 행마다 점검을 하나씩 추가하세요. 답변 언어 감지기, 시장별 판매 상품 목록, 지역별 “이용할 수 없음” 메시지 패턴 등입니다. 모델 출력은 실행마다 달라지므로 각 프롬프트를 여러 번 실행하세요. 세 번 중 두 번만 통과하는 점검은 잡음이 아니라 발견된 문제입니다.
릴리스 테스트에 포함하기
- 모델, 프롬프트, 플래그를 바꿀 때마다 하네스를 실행하세요. 기본 지역만이 아니라 모든 시장에서 실행합니다.
- 시장별로 고정된 프롬프트 세트를 유지하세요. 원어민이 작성하고, 그곳 고객이 실제로 묻는 질문을 포함합니다.
- 답변을 국가, 모델 버전, 시각과 함께 저장하세요. 그래야 모델 변경과 라우팅 변경을 구분할 수 있습니다.
- 매주 국가별 거부 응답을 검토하세요. 한 시장에서 거부율이 갑자기 오르면 보통 정책 규칙이나 지역 엔드포인트가 원인입니다.
AI 기능이 검색에도 나타난다면, 같은 시장별 방식을 AI 검색 노출 모니터링에도 적용할 수 있습니다. 이때 질문은 다른 어시스턴트들이 각 국가에서 우리에 대해 무엇이라고 말하는가입니다.
결론
AI 출력은 지역마다 다릅니다. 모델을 둘러싼 제품이 사용자 위치를 읽고 그에 따라 동작하기 때문입니다. 각 시장을 그 시장의 레지덴셜 IP로, 언어와 로캘까지 맞춰 테스트하고, 여러 턴의 채팅은 하나의 스티키 IP로 유지하고, 여러 번의 실행에 걸쳐 언어, 통화, 현지 정보, 제공 여부, 거부 응답 같은 속성을 점검하세요. 릴리스마다 이렇게 하면 지역별 AI 버그를 고객보다 먼저 발견하게 됩니다.