저는 슬로베니아 개발자이며 Claude Code와 슬로베니아어로 대화합니다. 제 모국어를 사용하는 사람은 약 250만 명입니다. 모든 프롬프트 엔지니어링 (Prompt Engineering) 가이드는 영어로 작성되어 있으며, 일반적인 조언은 다음과 같습니다: 영어로 프롬프트를 작성하세요, 모델들이 영어에 훨씬 더 능숙하기 때문입니다. 저는 이것이 실제 일상적인 코딩 작업에서도 사실인지 알고 싶었고, 이를 측정해 보았습니다. 제가 발견한 내용은 다음과 같습니다.

테스트 방법

세 가지 부분으로 나누었습니다:

1. 실제 사용 사례. 두 가지 환경(개인 프로젝트용 WSL, 업무용 Windows PowerShell)에서 생성된 모든 Claude Code 세션 트랜스크립트 (Transcript)를 파싱했습니다. 1차 집계 시 2,319개의 프롬프트였으나, 붙여넣은 로그, 도구 출력(Tool output), 기계 생성 턴(Machine-generated turns)을 제외하는 가장 엄격한 필터링 과정을 거친 후 1,899개가 남았습니다.
2. 발표된 연구. 다국어 벤치마크 (Multilingual benchmarks), 해석 가능성 연구 (Interpretability studies), 토크나이저 (Tokenizer) 논문, 공식 벤더 문서.
3. 직접 수행한 토큰 측정. 제가 실제로 사용한 프롬프트를 영어로 번역한 뒤, 서로 다른 토크나이저로 토큰 수를 계산했습니다.

그리고 한 가지 더: 제 결과와는 별개로 OpenAI Codex (GPT-5.6)에게 정확히 동일한 연구 과제를 부여하고, 두 시스템이 내린 결론을 비교했습니다. 자세한 내용은 아래에서 다룹니다.

실제 사용 양상

따라서 저는 슬로베니아어로 "대체로" 프롬프트를 작성하는 것이 아닙니다. 저는 그냥 슬로베니아어로 프롬프트를 작성합니다. 빠르고, 오타도 있으며, 종종 발음 구별 기호(š, č, ž) 없이 작성하고, 자연스러운 곳에는 영어 기술 용어를 섞어서 사용합니다. 문제는 이것이 성능에 해를 끼치느냐 하는 점입니다.

품질에 관한 연구 결과

요약하자면: 모델의 크기가 충분히 크다면, 생각보다 큰 타격은 없습니다.

모델은 내부적으로 어쨌든 영어에 의존합니다. EPFL의 해석 가능성(Interpretability) 연구(Do Llamas Work in English?)와 Anthropic 자체의 회로 추적(circuit-tracing) 연구(On the Biology of a Large Language Model)는 동일한 방향을 가리킵니다. 즉, 거대 모델은 영어와 가장 밀접하게 맞닿아 있는 공유된 개념 공간(shared concept space) 내에서 의미를 처리한다는 것입니다. 영어가 아닌 입력값은 가장자리(edges)에 얇은 번역 계층을 추가할 뿐입니다. 중간 단계의 사고 과정은 대부분 언어 중립적(language-neutral)입니다. 이는 또한 "영어로 생각하고 슬로베니아어로 응답하라"와 같은 지침이 현대적인 모델들에게는 대부분 낭비되는 단어라는 것을 의미합니다.

격차는 실재했으나, 최첨단(frontier) 모델에서는 대부분 해소되었습니다. 2022년, PaLM은 영어 수학 문장제 문제의 62%를 해결했지만, 소수 언어 평균은 47%에 불과했습니다(MGSM). 오늘날 Anthropic의 벤치마크 언어 공식 수치에 따르면, 스페인어는 영어 성능의 98.2%, 독일어는 97.0%를 보여줍니다(multilingual support docs). 어떤 벤더도 슬로베니아어를 벤치마크하지는 않지만, 슬로베니아 화용론 벤치마크(SloPragEval)에서 GPT-5는 영어 0.83 대비 슬로베니아어 0.81을 기록했습니다. 0.02의 차이입니다. 무시할 수준은 아니지만, 일상적인 업무를 위해 언어를 바꿀 이유는 되지 않습니다.

소형 모델은 이야기가 다릅니다. 동일한 Anthropic 표를 보면 Claude Opus 4.1은 요루바어(Yoruba)에서 영어 성능의 80%를 유지하는 반면, 훨씬 더 작은 Haiku 4.5는 53%만을 유지합니다. 만약 저렴한 소형 모델이 귀하의 비영어권 업무를 처리해야 한다면, 신뢰하기 전에 해당 언어로 직접 테스트해 보십시오.

언어를 혼용하는 것은 괜찮습니다. 제 경우에는 오히려 도움이 됩니다. 2025년 연구 (Lost in the Mix)에 따르면 비대칭성이 발견되었습니다. 영어 텍스트에 삽입된 외국어는 이해도를 떨어뜨리지만, 비영어 텍스트에 삽입된 영어 단어는 일부 모델에서 이해도를 최대 13포인트까지 향상시키는 경우가 많습니다. 영어 기술 용어를 그대로 유지한 슬로베니아어 문장은 긍정적인 방식의 언어 혼용으로 나타났습니다.

슬로베니아어가 토큰 비용에 미치는 영향

기존 문헌에 따르면 비영어 텍스트는 비용이 많이 듭니다. GPT-4의 이전 cl100k 토크나이저(tokenizer) 기준으로 슬로베니아어는 영어보다 약 1.88배의 토큰을 사용합니다 (Petrov et al., NeurIPS 2023). 이 수치는 저를 걱정하게 만들었습니다. 그래서 저는 제가 직접 작성한 프롬프트 30개를 각각 영어로 충실히 번역하여 직접 측정해 보았습니다.

왜 논문의 수치보다 훨씬 낮을까요? 실제 개발자 프롬프트는 깔끔한 산문이 아니기 때문입니다. 프롬프트에는 파일 경로, SQL, 에러 메시지, 그리고 두 언어 모두에서 동일하게 토큰화되는 영어 기술 용어들이 가득합니다.

예상치 못했던 두 가지 결과가 있었습니다:

• 특수 기호(Diacritics)는 비용이 들지 않습니다. š/č/ž가 포함된 텍스트와 포함되지 않은 동일한 텍스트의 토큰 차이는 0.6%에 불과했습니다. 저의 게으른 타이핑 습관은 비용이 전혀 들지 않았습니다.
• 중요한 비용은 출력(Output) 측면에서 발생합니다. 출력 토큰은 입력 토큰보다 가격이 약 5배 비싸며 지연 시간(latency)을 지배합니다. 짧은 슬로베니아어 질문은 무시해도 될 수준의 비용이 듭니다. 하지만 모델이 생성하는 긴 슬로베니아어 문서는 동일한 영어 문서보다 시간과 비용이 16~34% 더 많이 소요됩니다.

한 가지 솔직한 주의사항을 덧붙이자면, Claude의 토크나이저는 공개되어 있지 않으므로 이 수치는 OpenAI의 토크나이저 수치(및 이에 동의한 Gemini의 count API)를 기준으로 한 것입니다. 공개된 벤더 간 비교 연구에 따르면 Claude의 비영어 프리미엄은 이보다 다소 높을 수 있음을 시사합니다.

반전: Codex에게 전체 연구를 반복하게 시켰습니다

제 작업물을 검증하기 위해, 저는 OpenAI Codex (GPT-5.6)에 동일한 연구 브리프 (research brief)를 제공했습니다. 동일한 작업 문구, 동일한 환경 정보, 격리된 작업 디렉토리(working directory), 그리고 제 보고서에 대한 접근 권한을 모두 배제했습니다. 심지어 연구를 명령한 세션의 트랜스크립트 (transcript)조차 제외하여, Codex가 제 결론을 엿볼 수 없도록 했습니다.

Codex는 동일한 핵심 답변을 내놓았습니다: 슬로베니아어로 계속 프롬프팅할 것, 기술적 식별자 (technical identifiers)는 그대로 유지할 것, 원어민 트리거 문구 (trigger phrases)를 포함하여 재사용 가능한 지침을 영어로 작성할 것, 도메인 지식 (domain knowledge)을 번역하지 말 것. 두 시스템이 독립적으로 동일한 결론에 도달했다는 점은 개별 보고서 하나보다 더 큰 가치를 지닙니다.

그리고 Codex는 제가 놓친 한 가지를 찾아냈습니다. Codex는 제 프롬프트 중 50개를 수동으로 검토했으며, 모든 오타에도 불구하고 90%를 명확히 이해할 수 있다고 평가했습니다. 성능이 낮았던 프롬프트들은 슬로베니아어라서 약했던 것이 아니었습니다. 그것들은 모호했기 때문에 약했습니다: "이것을 수정해줘", "이제 제대로 해줘"와 같이 성공 기준이나 제약 조건 (constraints)이 없었습니다. 제가 채택하기로 한 Codex의 결론은 다음과 같습니다: 가장 큰 개선점은 언어가 아니라 명시성 (explicitness)이다.

내가 변경한 것과 유지한 것

유지한 것:

• 상호작용 작업에는 슬로베니아어 사용. 저는 모국어로 생각할 때 더 빠르고 의도를 더 정확하게 표현할 수 있습니다.
• 슬로베니아어 문장 내에 영어 기술 용어 사용. 연구에 따르면 이러한 혼합 방식은 해롭지 않으며 오히려 도움이 됩니다.
• 모든 기술적 요소는 원문 그대로 유지. 패키지 이름, SQL, 경로 (paths), 에러 메시지, 설정 키 (config keys). 절대 번역하거나 의역하지 않습니다.
• 하이브리드 기술 (Hybrid skills). 재사용 가능한 에이전트 지침은 영어로, 설명란의 트리거 문구는 슬로베니아어로 (실제로 제가 입력하는 단어들), 비즈니스 도메인 지식은 용어가 슬로베니아어로 존재하므로 슬로베니아어로 작성합니다.

변경한 것:

1. 글로벌 설정 (global config)에 명시적인 언어 규칙을 추가했습니다. Claude Code는 컨텍스트 압축 (context compaction) 이후 다시 영어로 돌아가는 경향이 있기 때문입니다:

명시적으로 요청하지 않는 한 항상 슬로베니아어로 응답하세요.
코드, 식별자, 명령어, 경로 및 에러 메시지는
원래 형태를 유지하세요.

1. 더 큰 작업을 위한 5개 필드 템플릿: 목표 (goal), 맥락 (context), 제약 사항 (constraints), 검증 (verification), 출력 형식 (output format). 이는 언어를 전환하는 것보다 더 확실한 해결책을 제공합니다.

2. 선택적 영어 사용: 길고 구조화된 사양 (specs) 및 에이전트 브리프 (agent briefs), 또는 어려운 추론 (reasoning) 작업에서 불안정한 답변이 나올 때 수행하는 A/B 재시도 (retry).

마무리하며

프런티어 모델 (frontier models)의 경우, 어떤 언어로 프롬프트를 작성하느냐보다 프롬프트가 얼마나 명시적인지가 훨씬 더 중요합니다. 자신이 가장 빠르게 생각할 수 있는 언어로 프롬프트를 작성하고, 모든 기술적인 내용은 있는 그대로 유지하며, 재사용 가능한 지침은 영어로 작성하되 트리거 문구 (trigger phrases)는 자신의 언어로 작성하세요. 그리고 번역에 들일 노력을 번역 대신 명확한 목표와 제약 사항을 설정하는 데 쏟으십시오.