1. 모델은 여러분의 도구를 어떻게 ‘보는가’
먼저, 모델에게 tool은 ‘멋진 TypeScript 함수’가 아니라 다음과 같은 형태의 구조적 설명입니다:
- name: 기술적 이름, 예: "search_gifts";
- description: 언제, 왜 이 도구를 사용해야 하는지 설명하는 자연어 텍스트;
- inputSchema: 각 필드에 description, 타입, 제약 등이 포함될 수 있는 JSON Schema.
아주 단순화하면 모델은 대략 이렇게 동작합니다(GPT의 머릿속 의사코드):
1. 사용자 요청을 읽는다(언어 무관).
2. tools 목록을 읽는다: name + description + 인자 설명.
3. 각 tool이 현재 과업에 맞는지 판단한다.
4. tool이 필요하면 스키마에 맞는 JSON 인자를 생성한다.
5. 필요 없으면 텍스트로 답한다.
여기서 두 가지 중요한 결론이 있습니다.
첫째, 도구의 description은 개발자를 위한 주석이 아니라 모델과 여러분의 백엔드 사이의 인터페이스입니다. 도구 설명이 모호하거나 불완전하거나 사용자 언어와 일치하지 않으면, 모델이 빗나갈 확률이 높아집니다. 즉, 잘못된 tool 선택, 잘못된 인자, 도구가 필요한데도 도구 없이 답하는 상황이 늘어납니다.
둘째, JSON Schema의 필드 description은 도구 자체 설명만큼 중요합니다. 모델은 실제로 각 속성의 description을 읽고, ‘나이’를 어떤 필드에, ‘예산’을 어떤 필드에 넣을지, 어디에 id가 있어야 하는지를 결정합니다.
GiftGenius 미니 예시
우리의 도구 search_gifts를 보겠습니다. 초기 ‘EN 전용’ 버전은 다음과 같을 수 있습니다:
// server/tools/searchGifts.ts
export const searchGiftsTool = {
name: "search_gifts",
description: "Search for gift ideas based on user preferences.",
inputSchema: {
type: "object",
properties: {
recipient_age: {
type: "integer",
description: "Age of the recipient in years.",
},
budget: {
type: "number",
description: "Maximum budget in user's currency.",
},
},
required: ["budget"],
},
};
사용자가 “엄마에게 줄 선물이 필요해요. 60세고, 예산은 최대 3000루블입니다.”라고 썼다면, 모델은 다음을 해야 합니다:
- search_gifts가 적절한 도구임을 파악한다.
- “60세”는 recipient_age에, “3000루블”은 budget에 넣어야 함을 파악한다.
설명이 영어로만 되어 있어도 GPT는 대체로 해냅니다. 하지만 내부적으로 추가 ‘번역’이 필요하고, 언어가 여러 개이거나 약한 모델이라면 정확도가 떨어질 수 있습니다.
2. 다국어 App에서 ‘영어 설명’만 사용할 때의 문제
9모듈에서 UI 위젯, 카탈로그, 오류, 커머스 텍스트 등 전반적인 “현지화 지도”를 간단히 언급했습니다. 이제 초점을 좁혀, 도구 설명이 오직 영어로만 되어 있고 사용자가 러시아어나 스페인어 등으로 대화하는 경우를 보겠습니다 — 여기서 작은 혼선이 시작됩니다.
전형적인 시나리오:
- 사용자: “아이티 친구에게 줄 선물 골라줘. 예산은 50유로까지.”
- 모델은 tools 목록을 보고, 설명이 EN으로만 되어 있음을 확인합니다.
- 요청도 EN이면 — 문제 없습니다.
- 요청이 다른 언어이면 모델은 다음을 해야 합니다:
- 먼저 요청을 이해하고,
- 머릿속으로 영어 설명과 대응시키고,
- 도구를 고르고,
- 그다음 JSON으로 인자를 추출합니다.
강력한 모델에서는 그럭저럭 동작하지만, 다음 문제가 늘어납니다:
- 도구 호출 없이 답하는 비율이 증가 — 모델이 “스스로 해결 가능”하다고 판단;
- 인자 오류 확률 상승(특히 통화, 단위, 지역 제한이 중요한 경우);
- 여러 도구 간 라우팅 논리 신뢰도 저하(엉뚱한 도구 선택).
단순한 오류 예시: budget 필드가 “사용자 통화” 기준을 기대하지만, 설명에 그런 언급이 전혀 없는 경우입니다. 모델은 기본값을 USD로 생각하고, 사용자가 분명 유로를 원했는데도 백엔드로 50달러를 보냅니다.
여기서 설명의 현지화가 필요해집니다.
3. 현지화 접근: 언어별 별도 tools vs 다국어 descriptions
두 가지 기본 아키텍처 접근이 있으며, 둘 다 유효합니다.
언어별로 별도의 도구
이 방식에서는 서로 다른 이름과 설명 언어를 가진 여러 tools를 만듭니다.
GiftGenius에서는 다음과 같을 수 있습니다:
export const searchGiftsEn = {
name: "search_gifts_en",
description: "Search for gift ideas based on user preferences.",
// ...
};
export const searchGiftsRu = {
name: "search_gifts_ru",
description: "사용자 선호도에 따라 선물을 추천합니다.",
// ...
};
ChatGPT App에서는 locale에 따라 사용 가능한 tools 목록이 달라지는 것이 중요합니다. 만약 locale = "ru-RU"라면, 여러분의 MCP 서버는 search_gifts_ru만 반환해야 합니다. locale이 = "en-US"라면, — search_gifts_en만 반환합니다.
장점은 descriptions가 가장 “깨끗한” 단일 언어로 유지된다는 점입니다. App을 여러 단일 언어 버전의 묶음(각각 자체 prompts와 설명)으로 생각할 수도 있습니다. 대상 언어 수가 적고 시장이 크게 다른 경우에 편리합니다.
단점은 로직이 중복되고 분석이 복잡해진다는 점입니다. 백엔드 코드는 결국 동일한 핸들러를 사용하겠지만 MCP/매니페스트 레벨에서는 두 개의 서로 다른 도구가 됩니다. 변경 시마다 두 설명을 모두 업데이트하는 것을 잊지 않아야 합니다.
인사이트(데이터 기준: 2025-12-01)
실험적으로 사용자/locale 언어의 description이 뚜렷한 우위를 보이지는 않았습니다. 설명 언어와 무관하게 도구 선택 빈도는 거의 동일했습니다. 유사한 설명(서로 다른 언어)을 가진 도구가 2개 있으면 오히려 ChatGPT가 혼란스러워했습니다.
또한, 앱을 Store에 등록할 때 리뷰를 통과해야 합니다. 그러니 모든 tool description과 argument description을 영어로 작성할 것을 권장합니다.
다만, 미래에 ChatGPT에 수천 개의 앱이 등록되고 “도구 선택” 경쟁이 심해진다면, 사용자의 locale 언어로 된 description이 우위를 가질 가능성도 있습니다. Tool Search Optimization의 등장을 기대해봅니다.
다국어 descriptions를 가진 단일 도구
두 번째 방식은 하나의 name(예: search_gifts)만 유지하되, 그 description과 JSON Schema 필드 설명을 다국어로 구성하는 것입니다.
여러 스타일이 있습니다:
- 간단한 2개 언어 형태:
description: "Search gifts for a recipient. / 선물 수신자의 선호에 맞춰 선물을 검색합니다.", - 언어별 블록 표기:
description: "[EN] Search for gifts based on user preferences. [RU] 받는 이의 선호에 따라 선물을 추천합니다.", - 개별 필드를 문자열로 합치기(덜 편리함):
description: `EN: ${enDescription} RU: ${ruDescription}`,
장점 — 단일 tool, 단일 소스(Single Source of Truth). MCP Gateway 아키텍처를 펼치기 쉽습니다. 사용자가 어떤 언어로 대화하든 ChatGPT에는 항상 동일한 인터페이스를 노출합니다.
단점: 설명이 길어집니다. 언어를 섞는 방식이 서툴면 모델이 약간 혼란스러울 수 있습니다 — 특히 영어와 현지 텍스트가 [EN], [RU] 같은 명시적인 표기 없이 섞일 때 더욱 그렇습니다.
GiftGenius 같은 학습용 프로젝트에는 하이브리드 방식을 권합니다. 설명은 주로 영어로 두되, 현지 언어로 짧은 보조 설명을 깔끔하게 덧붙이세요. 그리고 실제 “의미적 규칙”(어떤 언어를 사용할지, 사용자에게 어떻게 말할지 등)은 인자(locale)와 system‑prompt로 전달합니다.
4. JSON Schema 현지화: 필드 설명
이제 더 깊게 들어가 도구의 인자 자체를 봅시다.
JSON Schema에서는 각 필드에 description을 지정할 수 있고(지정해야 합니다). 모델은 도구를 호출할 JSON을 생성할 때 이 문자열을 읽습니다.
GiftGenius에서는 다음처럼 작성할 수 있습니다:
export const searchGiftsTool = {
name: "search_gifts",
description:
"Search gifts based on user preferences (RU: 받는 이의 선호에 따른 선물 추천).",
inputSchema: {
type: "object",
properties: {
recipient_age: {
type: "integer",
description:
"Recipient age in years. RU: 수신자 나이(정수).",
},
budget: {
type: "number",
description:
"Maximum budget in user's currency. RU: 사용자 통화 기준 최대 예산.",
},
locale: {
type: "string",
description:
"User locale (e.g. 'en-US', 'ru-RU'). RU: 인터페이스 및 응답 언어.",
},
},
required: ["budget", "locale"],
},
};
몇 가지 실전 팁.
첫째, 필드 이름(recipient_age, budget, locale)은 보통 영어로 둡니다. 번역 대상은 description입니다. 이렇게 해야 언어에 따라 JSON 형식이 바뀌지 않고, 서로 다른 계약을 유지할 필요가 없습니다.
둘째, description에는 통화, 단위, 중요한 제약을 명시하는 것이 좋습니다. 이렇게 하면 “삐딱한” 인자 수가 확 줄어듭니다.
셋째, 이미 MCP Gateway를 사용 중이라면, locale을 도구 인자에 자동으로 주입하도록 합의할 수 있습니다. 이 경우 모델이 직접 넣지 않아도 됩니다. 그래도 locale의 설명을 남겨두는 것은 유익합니다. 모델이 해당 파라미터의 성격과 목적을 더 잘 이해하기 때문입니다.
5. 설명 언어 선택: 실제 App을 위한 전략
실무에서 가장 중요한 질문: 설명의 기본 언어를 무엇으로 할지, 그리고 언제 완전한 현지화를 할지입니다.
권장사항과 실제 경험에 따르면, GPT 모델은 여전히 영어 컨텍스트에서 가장 안정적으로 동작하며, 많은 개발자가 설명을 EN으로만 유지합니다. 하지만 다국어 App에서는 절충안일 수 있습니다.
몇 가지 전략을 살펴보겠습니다.
EN 설명만
가장 단순한 방식 — 모든 설명을 영어로 작성.
장점: 단일 코드베이스, 단일 언어 유지보수, 더 간결하고 정확한 문구 작성이 쉬움. 주변이 모두 영어일 때 모델이 행복합니다.
단점: 다른 언어로 쓰는 사용자에게는 도구 선택/인자 품질이 낮아질 수 있습니다. 특히 “성능이 낮은” 모델이나 파라미터가 많은 복잡한 도구에서 그렇습니다.
EN + 짧은 로컬 추가 설명
절충안: 기본 설명은 EN으로 두되, 끝에 현지 언어로 짧은 블록을 추가하여 모델이 사용자 단어를 인자와 쉽게 매핑하도록 돕습니다.
예시:
description:
"Search for gifts based on user preferences. RU: 받는 이의 설명, 나이, 예산에 따라 선물을 추천하는 도구입니다.",JSON Schema의 경우:
description:
"Age of the recipient in years. RU: 수신자 나이(연도 기준).",장점: 모델은 여전히 “영어 세계”에 있으면서도 사용자 언어 힌트를 갖게 됩니다.
단점: 설명이 길어지지만, 대부분 큰 문제는 아닙니다.
locale별 완전 현지화
가장 본격적인 방식: ChatGPT로부터 아는 locale에 따라 도구와 필드 설명이 바뀝니다. en-US에는 순수 영어 설명, ru-RU에는 순수 러시아어 설명, de-DE에는 독일어 설명을 제공합니다.
이는 “하나의 JSON Schema 영구 고정”이 아니라, MCP/Gateway가 런타임에 선택하는 스키마 집합입니다.
MCP 레벨에서 예시는 다음과 같습니다:
function getSearchGiftsToolDescription(locale: string) {
if (locale.startsWith("ru")) {
return {
name: "search_gifts",
description: "받는 이의 선호에 따라 선물을 추천합니다.",
// ru‑schema...
};
}
return {
name: "search_gifts",
description: "Search for gifts based on user preferences.",
// en‑schema...
};
}장점: 모델이 사용자와 동일한 언어의 인터페이스를 보게 됩니다. 최상의 편의성.
단점: 유지보수와 테스트가 복잡해집니다. 모든 현지화 버전의 설명이 의미상 동기화되도록 보장하는 프로세스가 필요합니다. 예를 들어 영어 스키마에 새 필드를 추가할 때 독일어 스키마 업데이트를 잊지 않도록 해야 합니다.
6. 우리 앱 GiftGenius에서의 구현
구체적으로 가봅시다. GiftGenius에서는 하이브리드 방식을 적용합니다: 단일 도구 search_gifts, 설명은 주로 EN이지만 러시아어 설명을 짧게 보강, 그리고 locale 인자를 둡니다.
도구는 MCP SDK 스타일로 TypeScript 기반 MCP 서버에서 정의한다고 가정합니다.
// mcp/tools/searchGifts.ts
import { z } from "zod";
export const searchGiftsInputSchema = z.object({
recipient_age: z
.number()
.int()
.describe(
"Age of the recipient in years. RU: 수신자 나이(정수)."
),
budget: z
.number()
.describe(
"Maximum budget in user's currency. RU: 사용자 통화 기준 최대 예산."
),
locale: z
.string()
.describe(
"User locale (e.g. 'en-US', 'ru-RU'). RU: 인터페이스 및 응답 언어."
),
});
export const searchGiftsTool = {
name: "search_gifts",
description:
"Search for gifts based on user preferences (RU: 받는 이의 선호에 따른 선물 추천).",
inputSchema: searchGiftsInputSchema,
// execute(...) ...
};중요한 점:
- locale은 필수입니다. 위젯이 이를 알고 있다면(우리는 _meta["openai/locale"]에서 알 수 있습니다), callTool 호출 시 자체적으로 넣거나, MCP Gateway가 자체적으로 주입할 수 있습니다.
- 설명에 이미 “나이”, “예산”, “인터페이스 언어” 같은 러시아어 키워드가 포함되어 있으므로, 모델이 사용자 요청의 단어를 어디에 매핑해야 하는지 더 쉽게 이해합니다.
Apps SDK 측에서는 예를 들어 widgetAccessible이 켜져 있다면, 위젯에서 이 도구를 직접 호출하는 함수를 두고, 위젯의 locale을 그대로 전달할 수 있습니다.
// widget/hooks/useSearchGifts.ts
export async function searchGiftsFromWidget(params: {
recipientAge: number;
budget: number;
locale: string;
}) {
const openai = (window as any).openai;
const result = await openai.callTool("search_gifts", {
recipient_age: params.recipientAge,
budget: params.budget,
locale: params.locale,
});
return result;
}이 연결고리는 아키텍처를 강화합니다. ChatGPT에서 온 locale → tool로 전달 → 도구가 올바른 카탈로그와 가격 형식을 선택 → 프런트엔드에서 보기 좋게 렌더링.
7. 동작 실험: 현지화 영향 측정 방법
이제 가장 흥미로운 부분입니다. 도구와 설명의 현지화가 정말로 모델의 행동을 개선했는지, 즉 번역에 들인 시간이 아깝지 않았는지 어떻게 확인할까요?
GiftGenius의 Dev Mode에서 바로 작은 “실험”을 할 수 있습니다.
두 가지 App 구성: base vs localized
두 가지 App 구성을 준비하세요:
- base — 도구와 JSON Schema 설명이 EN만 있는 버전;
- localized — EN+RU 설명(또는 준비되어 있다면 완전한 ru 버전).
그 외(카탈로그, UI, 프롬프트)는 동일하게 유지하여 효과가 섞이지 않도록 합니다.
간단히 하려면:
- Dev Mode(및 Store)는 localized 버전만 운영하고;
- base는 로컬의 별도 브랜치에서 미리 준비한 요청 세트를 돌려 비교합니다.
무엇을 측정할까
핵심 지표는 세 가지입니다.
첫째 — 올바른 도구 선택 비율. 러시아어(또는 다른 언어) 테스트 요청 세트에 대해, 모델이 다음을 얼마나 자주 수행하는지 봅니다:
- 필요할 때 실제로 도구를 호출하는지;
- search_gifts를 정확히 선택하는지(다른 도구가 아닌지).
둘째 — 인자 정확도. 호출 JSON이 기대와 얼마나 자주 일치하는지 확인합니다. 필드를 바꾸지 않았는지, 예산이 올바른 통화인지, 나이가 명시적으로 정수인지, locale이 누락되지 않았는지 등.
셋째 — 이상하거나 무의미한 호출 수. 예를 들어 “지금 몇 시야?” 같은 질문에 search_gifts를 호출한다든지, recipient_age에 3000을 넣는다든지 하는 경우입니다.
수동으로도, MCP/Agents 로그를 통해서도 테스트할 수 있습니다 — 어차피 로그는 앞으로도 필요하니, 지금부터 이런 분석 습관을 들이는 것이 좋습니다.
수동 테스트 세트를 구성하는 방법
현지화 전용 “golden prompt set”을 작게 만들어 둘 수 있습니다:
1. "10살 여자아이에게 줄 저렴한 선물(30유로 이하)이 필요해요. 그림 그리기를 좋아해요."
2. "동료 프로그래머에게 줄 선물을 골라줘요. 35세, 예산은 100$."
3. "할머니 칠순 선물로 5000루블 이하의 선물이 필요해요."그리고 두 버전(base와 localized)을 통해 이를 실행하면서 다음을 관찰합니다:
- 모델이 어떤 tools를 고르는지;
- 어떤 인자를 넣는지;
- 도구가 호출되지 않았을 때 답변 텍스트가 어떻게 달라지는지.
반(半)전문가 팁: ChatGPT API로 이 요청들을 반복 실행하는 간단한 스크립트 래퍼를 만들 수 있습니다. 하지만 이 강의 범위에서는 Dev Mode의 수동 모드만으로도 충분합니다. 특히 포함하면 좋은 별도 카테고리는 혼합 언어 메시지와 특이한 locale 조합입니다. 이는 별도의 블록에서 다룹니다.
만약 여러분이 진지한 상업용 애플리케이션을 개발하고 있고 수백만 달러 규모의 영향이 걸려 있다면, 이러한 포인트를 여러분의 앱에 대해 반드시 검증하십시오. 모듈 20에서는 “golden prompt set”을 활용한 전문적인 작업을 다룹니다 — 꼭 숙지하세요.
8. 혼합 언어와 특이한 locale 조합
LLM 개발자를 가장 즐겁게(?) 하는 것은 두 언어를 섞어 쓰는 사용자입니다. 예를 들어:
"선물이 필요해요 for my friend, 그는 Star Wars를 좋아해요, budget 100€"모델은 다국어를 처리하므로 대개는 문제없이 해냅니다. 하지만 혼합 언어와 “영어 중심” 설명이 함께하면 오류 확률이 더 커집니다.
전형적인 상황이 몇 가지 있습니다.
첫째 — 사용자는 RU로 쓰고 도구 설명은 EN인 경우. 모델이 이해할 수는 있지만, 전문 용어(카테고리 이름, 드문 필드 라벨 등)에서 가끔 혼동합니다.
둘째 — locale = "ru-RU"인데 사용자가 영어로 쓰는 경우. ChatGPT는 인터페이스를 러시아어로 하는 것이 좋다고 신호를 보냈지만, 실제 텍스트 언어는 EN입니다. 이때는:
- locale을 1차 신뢰로 보고 러시아어 설명을 그대로 주거나,
- 메시지 언어 감지를 추가 신호로 사용해 실제 언어에 맞춰 설명을 조정할 수 있습니다.
셋째 — locale = "en"인데 사용자가 간혹 러시아어 단어를 섞는 경우. 보통은 영어 설명만으로도 충분히 잘 작동합니다.
실무에서는 명확한 정책 하나만 정해도 충분합니다. 예를 들어:
- locale이 "ru"로 시작하면 — 설명에 러시아어 단락을 추가하고;
- 그 외에는 — 설명을 순수 영어로 둡니다.
명확한 규칙의 장점은, 각 분기별로 의도적으로 테스트할 수 있고 “왜 오늘 설명이 이 언어로 보였지?”라고 추측할 일이 줄어든다는 점입니다.
9. 문서화, 프로세스, 그리고 ‘정준’ 언어
설명 현지화는 일회성 작업이 아니라 프로세스입니다. 사용자는 새 기능을 좋아하고, 우리는 기존이 망가지지 않길 바랍니다. 그러니 미리 다음을 정해두세요:
- 모든 번역의 기준이 되는 “정준” 언어는 무엇인지;
- 현지화된 설명을 어디에 저장할지;
- 일관성을 어떻게 검증할지.
보통 영어가 정준 언어 역할을 합니다. 모든 새 도구/필드는 먼저 EN으로 작성되어 리뷰를 거친 뒤, 다른 언어로 현지화됩니다. 코드베이스에서는 다음처럼 표현할 수 있습니다:
- tools.en.json — name/description/필드의 전체 설명;
- tools.ru.json, tools.de.json — 특정 언어를 위한 파생본;
- 이 사전을 바탕으로 MCP용 최종 JSON Schema를 생성하는 작은 제너레이터.
간단한 단계에서는 코드 내 문자열로도 충분하지만, 훗날 별도 사전으로 쉽게 분리할 수 있도록 구조화해 두는 것이 좋습니다.
설명도 제품 텍스트입니다. UI 텍스트만큼 엄격하게 리뷰해야 합니다. 이해하기 쉬운지, 중의성이 없는지, 군더더기가 없는지 확인하세요. 특히 다국어 설명에서는 로컬 언어 꼬리말이 영어 부분과 모순되지 않게 해야 합니다.
10. 시각화: 언어가 스택을 가로지르는 흐름
전체를 정리하기 위해, 도구 현지화를 고려한 요청 흐름의 단순화된 다이어그램을 봅시다.
flowchart TD
U[사용자가 RU로 작성] --> C[ChatGPT UI]
C -->|"_meta.openai/locale = 'ru-RU'"| W[GiftGenius 위젯]
W -->|"locale = 'ru-RU'"| T["Tool descriptions (EN+RU)"]
T --> M[GPT 모델]
M -->|callTool search_gifts| MCP[MCP / Gateway]
MCP -->|"locale = 'ru-RU'"| B[Backend / RU 카탈로그]
B --> MCP --> M2["GPT 모델(응답)"]
M2 --> C2[ChatGPT UI + RU 위젯]
여기서 사용자 언어와 locale은 다음을 좌우합니다:
- 위젯 UI 언어;
- 모델이 보게 되는 도구 및 필드 설명 언어;
- 백엔드가 선택하는 카탈로그와 통화;
- 응답 서식(모델과 위젯 모두).
11. tools와 descriptions 현지화 시 흔한 실수
오류 №1: description 필드를 ‘기술적’이라고 보고 아예 현지화하지 않음.
영어 사용자만 상대할 때는 괜찮습니다. 다른 언어 사용자가 등장하는 순간, 모델은 도구 없이 답하거나 인자를 잘못 넣는 일이 잦아집니다. UI는 번역했지만 App은 여전히 “영어식”으로 행동합니다.
오류 №2: JSON의 필드 이름을 언어에 따라 바꿈.
가끔 age → vozrast, budjet 등으로 바꾸고 싶어집니다. 이는 백엔드에 악몽을 선사합니다: 서로 다른 스키마, 다른 포맷, 복잡한 로그 분석. name은 안정적으로 유지하고 오직 설명만 현지화하세요.
오류 №3: 설명에서 언어를 무작위로 섞음.
“사용자 선호에 따라 gifts를 검색” 같은 문장은 모델과 사람 모두에게 도움이 되지 않습니다. 다국어 설명을 작성한다면, [EN] ... [RU] ...처럼 블록을 명확히 구분하세요. 그러면 모델이 구조를 볼 수 있습니다.
오류 №4: locale을 도구에 전달하지 않음.
설명을 현지화했다고 해도 locale을 tool로 전달하지 않으면(또는 MCP Gateway가 이를 주입하지 않으면) 백엔드는 어떤 카탈로그와 포맷을 써야 하는지 모릅니다. 결국 모델은 “다국어”로 애쓰지만, 서버는 한 시장만을 위한 데이터를 반환합니다.
오류 №5: 리뷰 없이 기계 번역으로 설명을 자동 변환.
자동 번역을 돌리고 끝내고 싶을 수 있습니다. 하지만 이런 번역은 특히 용어/인자 부분에서 종종 부정확합니다. 그 결과, 모델이 도구나 필드의 의미를 오해할 수 있습니다. 차라리 잘 다듬은 EN 버전 하나와 신중하게 번역한 몇 개의 현지화본이 낫습니다.
오류 №6: 각 locale에 대한 테스트/실험 부재.
각 locale에 대해 최소한의 요청 세트로 App 행동을 점검하지 않으면, 실제 사용자가 나타나기 전까지 문제가 몇 달간 숨어 있을 수 있습니다. 작은 golden 세트와 Dev Mode의 수동 테스트만으로도 이 위험을 크게 줄일 수 있습니다.
오류 №7: 정준 설명과 현지화 설명 간의 비동기화.
영어 스키마에 새 필드 occasion(선물의 “용도”)를 추가했지만, 러시아어 설명 업데이트를 잊었다고 합시다. 그러면 RU locale에서는 모델이 이 필드를 전혀 모르고 채우지 않게 됩니다. 백엔드는 해당 필드를 기대해 필터링을 시도하지만, null을 받아 너무 일반적인 목록을 보여주게 됩니다 — EN에서는 잘 동작하지만 RU에서는 눈에 띄지 않게 “망가지는” 셈입니다. 따라서 도구 설명의 모든 변경은 간단하더라도 규칙적인 프로세스를 통해 처리해야 합니다: EN 업데이트 → 각 locale 업데이트 → 짧은 테스트 실행.
GO TO FULL VERSION