AI 프롬프트, 한국어로 쓰면 손해일까 — 같은 문제 120회 한·영 지시문 실측 (2026)

한국어 지시문 35/60, 영어 지시문 39/60. 눈으로 보면 영어가 4건 앞섰습니다. 그런데 같은 사례를 짝지어 보니 두 언어가 갈린 건 60쌍 중 불일치 6쌍뿐이었고, 그 6쌍으로 계산한 값은 p=0.2188이었습니다. 이 표본에서는 우연과 구별되지 않는다는 뜻입니다.

같은 한국어 업무 60사례에 한국어 지시문과 영어 지시문을 한 번씩 적용해 비교했습니다. "프롬프트는 영어로 써야 한다"는 말은 커뮤니티에서 정설처럼 돌지만, 정작 같은 문제로 같은 횟수를 재본 한국어 자료를 찾기 어려웠습니다. 그래서 직접 측정했습니다. 60사례에 언어 2종, 총 120회입니다. 2026년 7월 31일 로컬 gemma3:4b에서 돌렸습니다.

영어 우위도 동률도 입증되지 않았습니다. 판단 재료는 서로 다르게 성공한 6쌍뿐이고, 정확 McNemar 검정은 p=0.2188이었습니다.

58.3% 대 65.0%보다 먼저 봐야 할 6쌍

각 언어의 성공률 58.3%와 65.0%만 나란히 놓으면 6.7%포인트 차이가 먼저 보입니다. 하지만 두 팔은 같은 60사례를 풀었습니다. 서로 다른 표본이 아니라 같은 시험지를 두 번 본 겁니다. 이럴 때 각 팔의 신뢰구간을 그려놓고 "겹치니까 차이 없다" 혹은 "안 겹치니까 차이 있다"고 읽으면 둘 다 오독입니다.

짝지은 비교에서 정보를 가진 건 두 언어가 서로 다른 답을 낸 사례뿐입니다. 둘 다 맞힌 34쌍과 둘 다 틀린 20쌍은 어느 쪽 손도 들어주지 않습니다. 60쌍을 다 굴려놓고 우열을 따질 재료는 남은 6쌍이 전부입니다.

짝지은 60쌍	건수
한국어·영어 모두 성공	34
한국어만 성공	1
영어만 성공	5
둘 다 실패	20

1 대 5. 동전을 6번 던져 한쪽이 5번 나오는 일은 흔합니다. 정확 McNemar 검정으로 계산하면 p=0.2188이고, 관례적 기준인 0.05에 한참 못 미칩니다. 그래서 이 글은 "영어 프롬프트가 더 정확했다"는 문장을 쓰지 않습니다. 쓰면 데이터가 뒷받침하지 않는 말이 됩니다.

같은 한국어 데이터에서 지시문 언어만 바꿨습니다

같은 60사례를 한국어 지시문과 영어 지시문에 각각 배정했습니다. 바뀐 건 지시문의 언어 하나입니다.

• 입력 데이터(고객 문의·발주 문장·상품 설명)는 양쪽 모두 한국어 원문 그대로 뒀습니다.
• 정답도 양쪽이 완전히 같습니다. 한국어 정답을 영어팔에서 따로 번역하지 않았습니다.
• 출력 형식은 JSON 하나로 고정했습니다. 형식 변수는 지난 출력형식 실측에서 이미 분리해 재봤기 때문에, 이번엔 언어만 남겼습니다.
• 같은 사례의 두 언어를 붙여서 연달아 보내지 않고 순서를 교대해, 앞 응답이 뒤에 영향을 주는 경로를 줄였습니다.

시험지는 자동화에서 자주 만나는 세 작업입니다. 고객 문의 20건 분류, 발주 문장 20건에서 항목 추출, 상품 설명 20건 정규화. 요청은 한 번에 하나씩, 매 요청 뒤 모델을 내리는 keep_alive: 0 조건이었습니다.

중요한 건 영어팔도 한국어 데이터를 다뤘다는 점입니다. 측정 대상은 한국어 문서를 영어 프롬프트로 처리하는 실무 상황이므로, 데이터까지 영어로 바꾸면 비교 질문이 달라집니다.

JSON 파싱은 120/120, 값에서는 6쌍이 갈렸습니다

지시문 언어	엄격 파싱	스키마	값까지 맞은 최종 성공	95% Wilson 구간
한국어	60/60	60/60	35/60 (58.3%)	45.7~69.9%
영어	60/60	60/60	39/60 (65.0%)	52.4~75.8%

출력 형식만 보면 두 언어 모두 오류가 없었습니다. 파싱과 스키마는 양쪽 다 60/60이었습니다. 지시문을 어느 언어로 쓰든 JSON 구조 자체는 흔들리지 않았다는 뜻입니다. 실패는 전부 값 오류였습니다. 한국어 25건, 영어 21건.

위 구간은 각 팔을 따로 본 범위입니다. 두 팔이 같은 사례를 풀었으므로 이 구간이 겹치는지로 결론을 내면 안 됩니다. 120회를 굴려놓고도 판정의 근거는 앞 절의 짝지은 6쌍뿐입니다.

작업별로 쪼개면 방향이 일정하지도 않았습니다.

• 고객 문의 분류: 한국어 16/20 · 영어 18/20
• 발주 정보 추출: 한국어 17/20 · 영어 16/20
• 상품 속성 정규화: 한국어 2/20 · 영어 5/20

발주 추출은 한국어가 한 건 높았고, 분류와 정규화는 영어가 높았습니다. 방향이 뒤집히는 작업이 섞여 있다는 점이, 6쌍이라는 작은 불일치 수와 함께 "언어가 지배 변수는 아니었다"는 쪽을 가리킵니다.

상품 정규화는 한국어 2/20·영어 5/20에 그쳤습니다

세 작업 중 상품 속성 정규화만 자릿수가 다르게 무너졌습니다. 한국어 2/20, 영어 5/20. 양쪽 다 실패한 20쌍 중 대부분이 여기에 몰려 있습니다. 지시문 언어와 무관하게 이 작업의 성공률만 크게 낮았습니다.

일을 말아먹는 방식은 언어와 무관하게 비슷했습니다. 두 지시문 모두 제품명에 색상을 붙이거나, 모델 코드를 누락하거나, 재고 여부를 계약과 다른 값으로 반환했습니다. 지시문을 영어로 바꿔도 이 실수는 그대로 남았습니다.

개선 우선순위는 여기서 갈립니다. 프롬프트 언어를 바꾸는 데 들이는 노력 대비, 어려운 작업의 계약을 촘촘히 적는 쪽이 회수가 큽니다. 허용값 목록, 코드 유지 규칙, 정규화 기준 같은 것들 말입니다. 같은 프롬프트에서 조건 하나가 빠졌을 때 얼마나 크게 무너지는지는 AI 프롬프트 4칸 공식 실측에서 따로 재봤습니다.

한국어 지시문은 입력 토큰이 더 길었고 영문 값 누출도 더 많았습니다

정확도 우위는 판정하지 못했지만, 실행 과정에서 방향이 달랐던 지표는 두 가지였습니다.

첫째, 입력 토큰이 늘어납니다. 같은 내용의 지시문인데 프롬프트 토큰 중앙값이 한국어 372, 영어 314였습니다. 약 18% 차이입니다. 로컬 모델에서는 지갑에 영향이 없지만, 토큰 단가로 과금되는 상용 API에서 같은 작업을 대량으로 돌린다면 여기서 비용이 벌어집니다. 다만 이 수치는 이 모델의 토크나이저 기준이라 다른 모델에 그대로 옮겨 적을 수 없습니다.

둘째, 답변 언어가 새어나갑니다. 정답이 한국어인 필드에 한글이 하나도 없이 영문만 돌아온 경우가 한국어팔 5건, 영어팔 2건이었습니다. 전부 상품 정규화 작업이었고, 제품명이나 규격 필드에서 발생했습니다.

여기서 눈여겨볼 건 방향입니다. 지시문을 한국어로 썼는데도 답이 영문으로 튄 쪽이 오히려 더 많았습니다. "한국어로 물으면 한국어로 답한다"가 자동으로 보장되지 않는다는 뜻이고, 출력 언어를 강제해야 한다면 지시문 언어에 기대지 말고 계약으로 못 박는 편이 안전합니다.

응답 길이와 속도는 사실상 차이가 없었습니다. 응답 토큰 중앙값은 한국어 77.5·영어 76.0, 소요 시간 중앙값은 4.09초·4.07초였습니다. 콜드 로딩이 섞인 값이라 절대 수치로 읽을 것은 아니지만, 언어가 속도를 가르진 않았습니다.

정확도 우위를 판정하지 못한 뒤 남은 선택 기준

정확도·비용·출력 계약을 기준으로 선택지를 정리하면 이렇습니다.

언어를 바꿀 가치가 있는지는 같은 사례로 먼저 확인하세요.

1. 먼저, 자주 쓰는 업무 사례 10개와 기대값을 고르고 한국어 지시문을 입력하세요.
2. 그다음, 입력 데이터와 출력 스키마는 그대로 둔 채 지시문만 영어로 바꾸세요.
3. 마지막으로, 사례별 두 결과를 쌍으로 비교해 어느 언어에서만 실패했는지 확인하세요. 성공률 두 개만 나란히 놓지 말고, 서로 다르게 끝난 쌍이 반복되는지도 함께 보세요.

한국어 데이터를 다루면서 한국어 프롬프트가 편하다면, 이번 결과는 언어를 바꿀 근거가 되지 못합니다. 6쌍의 불일치로는 아무것도 증명되지 않았고, 대신 익숙한 언어로 계약을 정확히 쓰는 편이 실수가 적습니다.

대량 API 호출로 비용이 실제로 아픈 구간이라면 토큰 수는 따져볼 만합니다. 18% 차이가 호출 수에 곱해지면 무시하기 어려워집니다. 단, 언어를 바꿔서 정확도가 오른다는 보장은 이 측정에 없으므로, 비용 때문에 바꾼다면 정확도는 따로 재보고 결정하는 게 맞습니다.

출력 언어가 중요하면 지시문 언어에 맡기지 말고 명시하세요. 한국어로 물어도 영문 값이 5건 나왔습니다. "값은 한국어로, 원문 표기 유지" 같은 조건을 계약에 넣고, 코드로 검사하는 편이 확실합니다.

어려운 작업이면 언어보다 계약을 손보세요. 아무리 굴려도 정규화 작업은 어느 언어로도 2/20과 5/20이었습니다. 여기서 30%포인트를 되찾을 여지가, 언어를 바꿔 얻을 수 있는 폭보다 훨씬 큽니다.

이 결론은 gemma3:4b·한국어 업무문장 60건 안에서만 유효합니다

같은 모델도 실행 환경이 달라지면 같은 수치가 나오지 않습니다. 아래 경계 안에서만 읽어주세요.

• 한 모델 gemma3:4b만 측정했습니다. ChatGPT·Claude·Gemini 같은 대형 상용 모델은 한국어 처리 능력이 다르므로 이 결과를 옮겨 읽을 수 없습니다. 오히려 모델이 커질수록 언어 격차가 줄어든다는 쪽이 흔한 관찰이지만, 그건 이번 측정으로 확인한 사실이 아닙니다.
• 불일치 6쌍은 판정을 내리기에 너무 적습니다. "차이가 없다"고 증명한 것이 아니라 "이 표본으로는 말할 수 없다"입니다. 사례 수를 늘리면 결과가 갈릴 수 있습니다.
• 한국어 합성 업무문장 60건과 단층 JSON만 썼습니다. 장문 문서, 창작 글쓰기, 코드 생성, 추론이 긴 작업은 다른 그림일 수 있습니다.
• 각 사례에 언어별 요청을 한 번씩 보냈습니다. 같은 요청을 여러 번 반복해 모델의 무작위성까지 잡아낸 실험은 아닙니다.
• 토큰 수 비교는 이 모델의 토크나이저 기준입니다. 모델이 바뀌면 한국어의 토큰 효율도 달라집니다.
• 측정 시점은 2026년 7월 31일입니다. 모델이나 런타임이 바뀌면 결과도 달라집니다.

한 줄로 남기면, 이번 120회에서 프롬프트 언어는 이 모델의 성패를 가르는 변수가 아니었습니다. 성패를 가른 건 작업의 난이도와 계약의 촘촘함이었습니다. 답이 그럴듯해 보여도 원문과 맞대야 하는 이유는 AI 환각을 거르고 검증하는 방법에 정리해뒀습니다.

시네의 선택은 이렇습니다. 프롬프트는 내가 정확하게 쓸 수 있는 언어로 쓰고, 아낀 시간은 값 검증기에 넣는다. 언어를 바꿔 6.7%포인트를 노리는 것보다, 정규화 계약을 다시 쓰는 쪽이 회수가 컸습니다.

참고자료

• Ollama gemma3 모델 정보
• 테스트 방법론: cinevyze 고정 테스트셋 LANG 축(FMT-01~03 재사용), 실행기 run_lang_bench.py, 채점기 lang_score.py
• 통계: 짝지은 이분 결과에 정확 McNemar 검정, 각 팔 비율에 95% Wilson 구간
• 원자료: 120개 원응답·프롬프트·API 메타와 aggregate.json을 실행 아티팩트에 보존

이 글은 cinevyze 운영자가 해당 모델을 테스트하고, 120개 원응답을 결정론적 채점기로 채점한 뒤 결과를 비교·검수해 정리·편집했습니다. 무엇을 어떻게 테스트할지·판단·사실확인은 모두 사람이 했고, 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다.