흔한 번역 실수 10가지(그리고 피하는 방법)
Chrome에 추가 
TABLE OF CONTENTS
잘못 번역된 슬로건 하나로 HSBC는 1,000만 달러를 잃었습니다. 날짜 형식 버그 하나로 5만 달러어치 공장 장비가 망가졌습니다. Facebook 자동 번역 때문에 한 남성이 체포된 일도 있었습니다. 번역 실수는 그저 어색한 문제가 아닙니다. 실제로 일을 망칩니다. 여기 꼭 주의해야 할 10가지 구체적인 실수와, 몇 초면 적용할 수 있는 수정 방법을 정리했습니다.
1. 관용구를 단어 그대로 번역하기
관용구는 직역으로 거의 살아남지 못합니다. 문맥 안에서는 한 뜻을 가지던 말이, 개별 단어로 떼어 놓으면 전혀 다른 뜻이 되기 때문입니다. 그런데도 이건 거의 모든 언어 쌍에서 가장 흔한 번역 실수입니다.
❌ “It’s raining cats and dogs” → 「下猫下狗」(중국어 직역: “고양이와 개가 떨어진다”)
✅ 「倾盆大雨」(중국어: “억수같이 쏟아지는 비”) / “Il pleut des cordes” (프랑스어: “밧줄이 쏟아진다”) / “Es regnet in Strömen” (독일어: “줄기처럼 비가 온다”)
❌ “Break a leg” → 「رجل اكسر」(아랍어로 문자 그대로는 “다리를 부러뜨려라”)
✅ 「بالتوفيق」(아랍어: “행운을 빈다”) / «Ни пуха ни пера!» (러시아어: “Break a leg”에 해당하는 표현)
❌ Coors 맥주의 “Turn it loose” → 스페인어에서는 “설사에 걸리다” 같은 뜻으로 받아들여짐
✅ 타깃 시장의 원어민으로 검증한 현지화 슬로건
❌ “To have other cats to whip” (프랑스어: «avoir d’autres chats à fouetter») → 영어로 직역하면 말이 안 됨
✅ “To have other fish to fry” — 영어에서 자연스러운 대응 관용구
어떻게 피할까: 관용구를 보면 먼저 이렇게 물어보세요. “이 표현이 목표 언어에도 같은 의미로 그대로 존재하나?” 답이 아니면, 그리고 대개는 아닙니다, 단어를 옮기지 말고 현지에서 자연스러운 대응 표현을 찾아야 합니다.
2. 높임말과 말투를 무시하기
영어는 누구에게나 “you”를 씁니다. 하지만 대부분의 다른 언어는 그렇지 않습니다. 호칭이나 말투를 잘못 고르면 조금 어색한 수준을 넘어, 노골적으로 무례해질 수 있습니다. 특히 비즈니스, 법률, 고객 응대에서는 더 그렇습니다.
❌ 일본어: 고객 응대에서 あなた (anata)를 사용. 문자 그대로는 “당신”이지만, 서비스 맥락에서는 차갑고 무례하게 들립니다.
✅ お客様 (okyakusama, “존귀한 고객”) 또는 고객 이름 + 様 (-sama)
❌ 프랑스어: 비즈니스 이메일에서 “Vous” 대신 “Tu” 사용. 친하지 않은 사람에게 반말형을 쓰면 주제넘어 보입니다.
✅ 아직 비공식 관계가 아닌 사람에게는 “Vous”를 사용. 기본은 존칭으로 둔다
❌ 이탈리아어: 고객에게 “Lei” 대신 “Tu” 사용. 이탈리아어에서는 공식적인 호칭으로 여성 3인칭 “Lei”를 사용합니다.
✅ 비즈니스와 공식 상황에서는 “Lei” + 3인칭 동사 활용 사용
❌ 한국어: 비즈니스 이메일에서 존댓말(jondaenmal)이 아니라 반말(banmal)을 사용.
✅ 관계가 분명히 편한 사이가 아닌 한 가장 높은 공손 수준(합니다 / 합니까체)을 기본값으로 사용
어떻게 피할까: 어떤 언어로 번역하든 두 가지는 꼭 알아야 합니다. 공식/비공식 호칭 구분이 어떻게 되는지, 그리고 독자가 어떤 말투를 기대하는지입니다. 애매하면 존댓말 쪽으로 가세요. 조금 지나치게 공손한 편이 실수로 무례한 것보다 훨씬 안전합니다. 일본어, 한국어, 태국어는 높임 체계가 특히 복잡해서 기계 번역만으로는 잘 맞지 않습니다.
3. 날짜와 숫자 형식 뒤섞기
MM/DD/YYYY를 쓰는 곳은 미국과 몇몇 지역뿐입니다. 세계 대부분은 DD/MM/YYYY 또는 YYYY-MM-DD를 씁니다. 여기서 틀리면 단지 어색해 보이는 게 아니라 데이터가 실제로 망가집니다.
❌ 유럽 독자를 대상으로 한 계약서에 03/06/2026 표기. 작성자는 3월 6일(DD/MM)을 뜻했지만, 독자는 6월 3일(MM/DD)로 읽는다.
✅ “6 March 2026” 또는 “March 6, 2026” — 지역이 달라도 모호하지 않음
❌ 독일어 문서에 1,500.75 사용. 독일어는 천 단위 구분과 소수점이 반대라 1.500,75가 됩니다. 브라질식 포르투갈어도 1.500,75를 씁니다. 스위스 프랑스어와 이탈리아어는 1’500.75를 사용합니다.
✅ 1.500,75(독일어/포르투갈어), 1 500,75(프랑스어), 또는 로케일 대응 형식 사용
❌ 모든 독자가 그레고리력을 쓴다고 가정. 사우디아라비아는 공식 문서에 히즈리력을 사용합니다. 태국은 불기(연도 +543)를 쓰고, 일본은 연호를 씁니다(레이와 8년 = 2026년).
✅ 독자가 날짜에 어떤 달력 체계를 쓰는지 확인하기
어떻게 피할까: 내부 저장은 ISO 8601(YYYY-MM-DD)로 통일하세요. 보여줄 때만 독자가 기대하는 형식으로 바꾸면 됩니다. 번역 문서라면 “이 문서의 날짜는 DD/MM/YYYY 형식을 사용합니다.”라고 명시하는 것도 좋습니다. 5초 걸리는 문장 하나가 며칠치 혼란을 막아줍니다.
4. False Friends: 단어가 당신을 속일 때
false friend는 두 언어에서 모양이 같거나 아주 비슷하지만, 뜻은 완전히 다른 단어를 말합니다. 특히 위험한 이유는 “맞아 보이는 착시”를 만들기 때문입니다. 번역가는 익숙한 단어를 보면 확인을 멈추기 쉽습니다.
| 영어 단어 | False Friend | 언어 | 실제 의미 |
|---|---|---|---|
| embarrassed | embarazada | 스페인어 | 임신한 |
| actually | attualmente | 이탈리아어 | 현재 |
| gift | Gift | 독일어 | 독 |
| sensible | sensibile | 이탈리아어 | 민감한 |
| eventually | eventualmente | 포르투갈어 | 어쩌면 / 가능하면 |
| library | librairie | 프랑스어 | 서점 |
| demand | talep etmek | 터키어 | ”요구하다”가 아니라 “요청하다” |
| pain | pain | 프랑스어 | 빵 |
| magazine | магазин (magazin) | 러시아어 | 가게 / 상점 |
| brave | braaf | 네덜란드어 | 얌전한 |
| location | location | 프랑스어 | 임대 |
| pretender | pretender | 포르투갈어 | 의도하다 |
Parker Pens는 이걸 호되게 배웠습니다. 영어 슬로건은 “주머니에서 새지 않아 당신을 난처하게 하지 않는다”였는데, 스페인어 번역에서 embarazar 를 “embarrass”로 착각해 “주머니에서 새서 당신을 임신시키지 않는다”가 되어 버렸습니다. false friend는 언어가 사람을 놀라게 하는 수많은 방식 중 하나일 뿐입니다. 놀라운 언어 사실 모음에서는 번역가를 헷갈리게 만드는 다른 언어적 함정도 소개합니다.
어떻게 피할까: 작업하는 언어 쌍마다 알려진 false friend 용어집을 유지하세요. “Do Not Translate” 경고를 붙여 두면 더 좋습니다. 목표 언어에서 눈에 익은 단어가 보이면 잠깐 멈추고 확인하세요. 닮아 있다는 점 자체가 위험 신호입니다.
5. 기계 번역을 맹신하기
기계 번역은 크게 좋아졌지만, 사람이라면 하지 않을 범주 오류를 여전히 냅니다. 2025년 7월, Meta의 자동 번역은 한 인도 주 총리가 다른 사람을 애도하는 글을 쓴 것을 바탕으로, 살아 있는 그 총리가 “사망했다”고 잘못 알렸습니다. 그의 사무실은 이 도구를 “위험하다”고 부르며 칸나다어에서 중단을 요구했습니다.
다른 실제 사례:
❌ 아랍어 → 히브리어 (Facebook, 2017): 팔레스타인 남성이 올린 “Good morning”이 자동 번역으로 “그들을 공격하라”가 되었다. 이스라엘 경찰은 오류가 밝혀지기 전에 그를 체포했다.
✅ 사람 번역가는 صباح الخير가 “good morning” 외의 뜻이 아님을 이해한다.
❌ 힌디어 → 영어 (Uber, 2025): “Mother Dairy ke samne hun” (유명 인도 브랜드 Mother Dairy 앞에 있다)이 “I am facing the threat of murder.”로 바뀌었다.
✅ 번역기는 “Mother Dairy”를 번역 대상 단어가 아니라 브랜드명으로 인식했어야 했다.
❌ 영어 → 프랑스어 (몬트리올 교통국, 2025): “Bishop Street”가 버스 노선도에서 AI에 의해 “Beeshop”으로 번역되었다.
✅ 고유명사는 번역하지 않는다. 사람 번역가는 시도조차 하지 않는다.
어떻게 피할까: 기계 번역은 초안이지 최종본이 아닙니다. 고객 대상, 법률, 의료, 안전 관련 내용이라면 언제나 사람이 결과를 검토해야 합니다. 도구마다 약한 지점도 다릅니다. OpenL vs Google Translate 비교를 보면 어떤 도구가 어디서 자주 넘어지는지 알 수 있습니다. 규칙은 단순합니다. 실수의 결과가 “민망함”이라면 감수할 수 있습니다. 법적 책임이나 물리적 피해라면 감수하면 안 됩니다.
6. 텍스트 확장과 레이아웃 붕괴
언어마다 차지하는 공간은 다릅니다. 영어를 독일어로 옮기면 텍스트가 대략 2540% 늘어납니다. 이탈리아어와 포르투갈어는 1530%, 프랑스어와 스페인어는 15~25% 정도입니다. 글자가 비교적 압축적인 언어도 예외가 아닙니다. 러시아어 키릴 단어는 평균적으로 영어보다 길고, 네덜란드어 합성어는 독일어만큼 길어지기도 합니다. 짧은 UI 문자열은 훨씬 더 극적으로 늘어납니다. 영어에서 10자 미만인 버튼 라벨이 독일어에서는 세 배가 될 수도 있습니다.
❌ 폭 80px짜리 “Submit” 버튼. 독일어 “Absenden”은 넘친다. 이탈리아어 “Invia”는 들어갈 수 있어도 러시아어 “Отправить”는 안 들어간다. 터키어 “Gönder”도 레이아웃을 깨뜨린다.
✅ 버튼은 30% 이상 늘어나는 것을 감안해 설계하거나, 내용에 따라 커지는 유연한 레이아웃을 사용
❌ 텍스트 박스가 빡빡한 PDF. 영어 “Job Application”(15자) 자리에 네덜란드어 “Sollicitatieformulier”(17자)가 들어가고, 독일어 “Bewerbungsformular”(19자)는 페이지 밖으로 넘친다.
✅ 최종 확정 전에 모든 대상 언어에서 레이아웃을 점검한다. 원본 디자인에 여백을 남겨 둔다
어떻게 피할까: UI 설계에서는 독일어를 스트레스 테스트 언어로 삼으세요. 독일어에 맞으면 대체로 다른 언어에도 맞습니다. 문서는 번역 후 반드시 레이아웃 점검을 해야 합니다. PDF 번역은 특히 레이아웃 깨짐이 흔합니다. 서식을 잃지 않고 PDF를 번역하는 가이드에서 여러 언어에 걸쳐 디자인을 보존하는 도구와 워크플로를 설명합니다. W3C도 영어에서 유럽 언어로 번역할 때 최소 30~40%의 확장을 고려하라고 권장합니다.
7. 용어 불일치
같은 용어를 한 문서 안에서 세 가지 다른 방식으로 번역하면 신뢰가 떨어지고 혼란이 생깁니다. 특히 법률, 기술, 의료 문서에서 치명적입니다.
❌ 영어 법률 계약서에서 1페이지는 “Service Agreement”, 5페이지는 “Services Contract”, 8페이지는 “Terms of Engagement”라고 쓴다. 모두 같은 문서를 가리키는데 독자는 “이게 서로 다른 건가?”라고 생각하게 된다.
✅ 개념마다 용어를 하나로 정하고, 문서 전체와 번역 전체에서 일관되게 유지한다
❌ 일본어 의료 번역(NIH, 2025)에서 「患者」가 한 문단에서는 “patient”, 다음 문단에서는 “case”로 번역되어, 같은 사람을 말하는지 모호해졌다
✅ 분야별 용어집을 만들고 프로젝트 전체에 강제 적용한다
어떻게 피할까: 번역 프로젝트를 시작하기 전에 가장 중요한 용어 10~20개와 승인된 번역을 담은 작은 용어집을 만드세요. 문서 작업자 모두와 공유해야 합니다. OpenL 같은 전문 번역 플랫폼에 들어 있는 번역 메모리 도구는 이걸 자동화합니다. 한 번 번역한 용어를 기억해 문서 전체에 일관되게 다시 적용해 줍니다.
8. 번역하면 안 되는 이름을 번역하기
사람 이름, 브랜드, 장소, 제품명 같은 고유명사는 거의 번역하지 않습니다. 하지만 기계 번역은 그걸 모르고, 사람 번역가도 가끔 지나치게 “교정”하려 듭니다.
❌ 스페인어 → 영어 (멕시코 관광 사이트): “Tulum”이 “Jumpsuit”, “Acolman”이 “I Blame”, “Progreso”가 “Progress”가 되었다.
✅ 지명은 번역하지 않는다. 원래 형태 그대로 둔다.
❌ 영어 → 중국어: “Palo Alto” → 「高木头」(“키 큰 나무토막”). 도시 이름이지 목재 창고가 아니다.
✅ “Palo Alto（加州一城市）” — 이름은 유지하고, 필요하면 괄호 설명만 덧붙인다
❌ 러시아어 → 영어: “Василий” → “Cornflower” (василёк가 수레국화를 뜻하기 때문). 하지만 이건 사람 이름, Vasily다.
✅ “Vasily” — 번역하지 말고 음역한다
어떻게 피할까: 번역 체크리스트에 한 줄을 추가하세요. “고유명사, 브랜드명, 제품명, 지명은 번역하지 않는다.” 기계 번역이 이름을 건드리면 즉시 플래그를 세우세요. 이건 기계가 꾸준히 실패하고 사람은 거의 실패하지 않는 영역입니다.
9. 문화적 맹점
번역은 언어 사이에서만 일어나는 게 아니라 문화 사이에서 일어납니다. 완벽하게 정확한 번역도 독자의 문화적 맥락을 무시하면 실패할 수 있습니다.
❌ 중국이나 인도 독자를 겨냥한 웨딩 색상으로 흰색 사용. 많은 동아시아 문화에서 흰색 = 장례, 빨간색 = 결혼식이다. 서아프리카 일부에서는 빨간색 = 애도다.
✅ 시각 요소와 텍스트 조합을 확정하기 전에 대상 문화의 색 상징을 조사한다
❌ 중동 플레이어 대상 라마단 캠페인에 음식과 맥주를 든 캐릭터를 넣은 게임 회사. 라마단은 금식의 시기다.
✅ 문화적 또는 종교적 행사를 언급한다면 그 문화권 사람에게 확인한다
❌ 중동과 서아프리카 대상 메시지에 👍 이모지를 사용. 그 지역에서는 가운데 손가락을 드는 것과 비슷한 모욕으로 받아들여질 수 있다.
✅ 문화권을 넘나들 때는 이모지보다 텍스트가 안전하다. 이모지를 쓸 거라면 먼저 현지 의미를 확인한다.
어떻게 피할까: 새로운 시장에 들어가는 캠페인이나 문서라면 질문은 하나면 됩니다. “검토 과정에 현지 사람이 있는가?” 답이 아니면 넣으세요. 원어민의 15분 검토 비용은 실패한 캠페인을 회수하고 다시 만드는 비용에 비하면 사실상 0에 가깝습니다.
10. 문자 인코딩: “Krüger”가 “Kr?ger”가 될 때
이 목록에서 가장 화려하지 않은 실수지만, 가장 흔한 실수 중 하나입니다. 악센트 문자(é, ü, ñ, ç, ø), CJK 문자, 키릴 문자를 잘못된 인코딩으로 저장하거나 전송하면 깨진 문자열이 됩니다. 기술적으로는 mojibake라고 부릅니다.
❌ 독일어: “Krüger” → “Kr?ger” (또는 “Kr�ger” — 대체 문자)
✅ “Krüger” — 저장과 전송은 항상 UTF-8 사용
❌ 일본어: 「翻訳」(“translation”) → 이메일 제목에서 ”�|��“로 깨짐
✅ 「翻訳」 — 이메일 클라이언트와 CMS의 인코딩 설정 확인
❌ 러시아어: “Россия” → “Ðîññèÿ”. Windows-1251을 ISO-8859-1로 읽었을 때 생김
✅ 항상 UTF-8을 사용. 라틴, 키릴, CJK, 아랍어, 태국어까지 한 인코딩으로 처리할 수 있다.
어떻게 피할까: 항상 UTF-8을 사용하세요. 현대 표준이고, 오늘날 쓰이는 모든 문자 체계를 처리합니다. 번역문을 보내거나 업로드하기 전에 눈으로 한 번 확인하세요. 특수 문자가 제대로 보이나요? Excel에서 내보낼 때는 “다른 이름으로 저장”에서 “CSV UTF-8”을 명시적으로 선택하세요. 확신이 없으면 일반 텍스트 편집기로 열어 보세요. 거기서 깨져 있으면 어디서나 깨져 있습니다.
빠른 참고: 보내기 전 10초 체크리스트
보내기, 게시, 인쇄 전에 이 네 가지를 확인하세요.
- 관용구: 단어 그대로 번역된 표현이 있는가? → 현지의 자연스러운 대응 표현으로 바꾼다.
- 말투: 독자와 상황에 맞는가? → 애매하면 존댓말로 둔다.
- 날짜: 독자가 기대하는 형식인가? → 형식을 명시한다.
- 이름: 고유명사가 “번역”되었는가? → 원래 형태로 되돌린다.
10초. 네 가지 질문. 모든 걸 잡아내진 못해도, 헤드라인을 만드는 실수는 꽤 잘 걸러냅니다.
FAQ
ChatGPT / Claude가 이런 실수를 자동으로 고쳐 주나요?
그렇게 믿을 수는 없습니다. LLM은 예전 기계 번역보다 관용구 처리나 말투 선택은 낫지만, false friend 오류도 여전히 내고, 이름도 여전히 잘못 옮기며, 문화적 판단도 부족합니다. “Mother Dairy”가 브랜드명이라는 걸 알지 못하고, 단어 두 개로 보고 번역합니다. LLM 출력도 다른 기계 번역과 마찬가지로, 사람 검토가 필요한 강한 초안으로 다뤄야 합니다.
이런 실수를 피하는 데 무료 도구와 유료 전문 번역가는 어떤 차이가 있나요?
무료 도구는 원시 번역 결과를 냅니다. 전문 번역가와 OpenL 같은 전문급 플랫폼은 용어 관리로 불일치를 막고, 서식을 보존해 레이아웃 붕괴를 막고, 문맥을 이해해 관용구와 false friend를 잡아냅니다. 격차가 가장 큰 곳은 #1~#5(관용구, 말투, false friend, 문화적 뉘앙스)입니다. #10(인코딩)은 격차가 좁고, 좋은 도구라면 양쪽 모두 UTF-8을 잘 처리합니다.
가장 돈이 많이 드는 실수는 무엇인가요?
가장 비싼 실패를 꾸준히 만드는 건 #5, 즉 기계 출력에 대한 맹신입니다. HSBC의 1,000만 달러 리브랜딩, 5만 달러 공장 장비 손실, Meta의 정치인 사망 오보는 모두 사람 검토 없이 기계 번역을 공개한 데서 비롯됐습니다. 해결책은 간단합니다. 공개 전에 사람이 읽는 것. 몇 분이 들고, 수백만 달러를 아낍니다.
Sources
- PMC/NIH: Errors in Japanese–English AI-assisted translation (2025) — taxonomy of AI translation failure types in medical texts
- STAR Translation: When Translation Goes Wrong — real-world mistranslation case studies including medical, branding, and signage
- POEditor: 6 Famous Mistranslations in Localization — HSBC, Pepsi, KFC, and other brand case studies
- Meta apologizes after auto-translation mistakenly announces Indian state chief minister’s death (CNN, July 2025) — Meta auto-translation falsely declaring a living politician dead
- Uber auto-translation: “Mother Dairy” becomes “threat of murder” (Livemint, 2025) — Hindi-to-English auto-translation blunder
- Montreal Transit: AI labels Bishop Street bus stop as “Beeshop” (CTV News, 2025) — AI signage translation failure
- Goethe-Institut: Oh Heavenly Berry — false friend stories from German learners — collection of false friend errors including “Himbeere” (raspberry) → “Himmelbeere” (heaven berry)
- W3C: Text Size in Translation — authoritative reference on text expansion rates across languages
- SandVox: Text Expansion in Localization — expansion rates by language with short-string amplification data
- Lingoda: False Friends in Languages — comprehensive false friend tables across major language pairs
- Ulatus: Lessons from Marketing Localization Failures — brand localization case studies and cultural blind spots
- Forbes: Why Global Brands Fail When They Communicate Locally (Feb 2026) — strategic perspective on localization failures
