DIALØGUE를 shipping하며 배운 다국어 AI 제품의 진짜 난점

지금 AI가 우리에게 허락하는 가장 유혹적인 일 중 하나는 언어를 아주 빠르게 늘릴 수 있다는 점입니다. 저도 그걸 잘 압니다. 제가 계속 그렇게 하고 있으니까요. 저는 48시간 만에 DIALØGUE에 5개 언어를 추가했고, 그다음에는 블로그 아카이브 전체를 4일 만에 10개 언어로 번역했습니다.

그 두 편은 속도에 관한 글이었습니다. 이번 글은 속도가 덮어주지 못하는 것들에 관한 글입니다.

번역은 데모하기 가장 쉽고, 동시에 가장 위험하게 과대평가되기 쉬운 부분입니다.

기계는 이제 한 언어의 텍스트를 다른 언어로 놀라울 정도로 빠르게 옮길 수 있습니다. 그렇다고 제품이 바로 native하게 느껴지는 것은 아닙니다. 제 경험상 진짜 다국어 작업은 네 군데에서 드러납니다. 시간, 목소리, UI 시스템, 그리고 fallback behavior입니다. 제품이 thoughtful하게 느껴질지, 아니면 어딘가 가짜처럼 느껴질지는 바로 그 지점에서 갈립니다.

실제로는 이런 차이였습니다.

	Translation Work	Product Work
무엇을 다루는가	Strings, copy, labels	날짜, layout, 목소리, fallbacks
틀렸을 때 누가 알아차리는가	이중언어 리뷰어	그 locale의 모든 사용자
AI가 도와주는 방식	번역을 빠르게 생성한다	제품 수준의 적합도는 판단하지 못한다
고치는 데 드는 노력	string을 다시 번역한다	컴포넌트를 다시 설계한다
언제 발견되는가	코드 리뷰 중	누군가 실제로 써본 뒤

---

첫 번째 버그는 번역이 아니었습니다. 시간이었습니다.

이걸 가장 분명하게 느끼게 해준 fix 중 하나는 copy와 전혀 관련이 없었습니다.

반복되는 show에 대해 DIALØGUE(다이얼로그)는 에피소드 제목을 자동으로 생성합니다. 가장 직관적인 버전은 간단합니다. 쇼 이름에 오늘 날짜를 붙이는 방식이죠.

겉보기엔 harmless 합니다. 하지만 오디언스는 도쿄에 있고 서버는 아직도 캘리포니아 시간으로 생각하고 있다면 이야기가 달라집니다.

일본의 청취자가 daily show를 열었을 때 도쿄는 이미 3월 14일인데, 서버가 그렇게 생각하지 못해서 에피소드 제목에는 아직 3월 13일이라고 적혀 있다면, 제품은 바로 어딘가 어긋나 보입니다. 고장 난 건 아닙니다. 그냥 성의 없어 보입니다.

그래서 저는 결국 에피소드 제목이 서버 기본값이 아니라, 오디언스의 locale과 timezone 기준 현지 날짜를 사용하도록 바꿨습니다.

작은 구현 디테일입니다. 그리고 바로 그게 핵심입니다.

다국어 제품은 단지 단어의 문제가 아닙니다. 맥락의 문제입니다.

로컬 맥락이 없는 언어는 대개 조금 더 공손한 형태의 오답일 뿐입니다.

---

Lesson 1: 목소리는 제품의 일부입니다

이건 DIALØGUE를 더 깊이 만들수록 훨씬 더 분명해졌습니다.

이 제품은 dialogue, pacing, personality, audio를 중심에 두고 만들어졌습니다. 그래서 일반적인 SaaS 인터페이스보다 품질 기준이 훨씬 높습니다.

새 템플릿을 추가하면서 저는 다국어 지원이 단순히 이런 일이 아니라는 걸 금방 배웠습니다.

• 템플릿 이름을 번역한다
• 랜딩 페이지 copy를 번역한다
• 그리고 shipping 한다

어떤 템플릿은 이런 것들까지 모두 생각해야 했습니다.

• host profiles
• audience profiles
• dialogue guides
• TTS용 voice instructions
• 언어별 localized naming conventions

이 작업은 영어 버전에 이미 존재했지만, 일본어와 베트남어 버전도 필요했습니다. 호스트 사이의 chemistry가 제품 그 자체의 일부이지, 위에 덧씌우는 cosmetic layer가 아니기 때문입니다.

당신의 제품이 콘텐츠를 생성한다면, voice는 장식이 아닙니다. voice는 인프라입니다.

문법적으로는 맞지만 여전히 생기가 없게 느껴지는 결과물이 있습니다.

저는 이걸 중국어 계열 변형들과 spoken content 전반에서 특히 강하게 느꼈습니다. 표준 중국어는 기술적으로는 정확할 수 있지만, 어떤 맥락에서는 여전히 너무 딱딱하게 들릴 수 있습니다. 영어에서는 자연스러운 대화 리듬이 다른 언어로 넘어가며 너무 직역된 제품 언어가 되면 갑자기 관료적으로 들릴 수 있습니다. 한 시장에서는 통하던 농담이 다른 시장에서는 밋밋한 설명문으로 바뀔 수도 있습니다.

그래서 저는 요즘 tone guides와 host profiles를 정말 중요하게 봅니다. 모든 output을 "브랜드스럽게" 들리게 만들고 싶어서가 아닙니다. voice drift는 다국어 AI 제품을 가장 빠르게 generic하게 느끼게 만드는 방법 중 하나이기 때문입니다.

그리고 generic함은 비쌉니다.

---

Lesson 2: UI 길이는 번역 문제가 아니라 제품 문제입니다

이건 실제 앱을 shipping 하기 전까지는 작아 보입니다.

하지만 막상 내보내면 갑자기 everywhere가 됩니다.

DIALØGUE iOS 앱을 현지화할 때, 그건 몇 개 화면을 번역하는 수준의 일이 아니었습니다. 7개 언어에 걸친 253개 strings가 됐습니다.

그렇게 해도 작업은 끝나지 않았습니다.

앱의 language picker가 실제로 UI 언어를 일관되게 제어하도록 input components의 wiring을 다시 해야 했습니다. placeholders, buttons, pricing labels, status text, 전부요. 그렇지 않으면 전형적인 half-translated app 문제가 생깁니다.

• 어떤 화면은 선택한 언어를 따른다
• 다른 화면은 여전히 영어 placeholder를 보여준다
• status labels는 원래 언어에 머문다
• 앱은 technically 여러 언어를 지원하지만, 경험은 그렇지 않다

영어에서는 깔끔한 button이 독일어에서는 갑자기 awkward해질 수 있습니다. 짧게 맞아떨어지던 pricing line이 프랑스어에서는 줄이 바뀔 수 있습니다. 짧고 punchy한 settings label이 일본어에서는 다르게 동작할 수 있습니다.

만약 localization workflow가 text generation에서 끝난다면, 이런 문제는 꽤 늦게, 그리고 제법 민망한 방식으로 드러납니다.

그래서 저는 다국어 작업을 완전한 product system으로 다뤄야 한다고 점점 더 믿게 됐습니다.

• copy
• layout
• spacing
• truncation rules
• component behavior
• screenshot QA

단어는 기계가 생성할 수 있습니다. Simulator를 여는 건 여전히 사람입니다.

---

Lesson 3: fallback behavior가 제품의 성숙도를 드러냅니다

이건 텍스트 제품보다 오디오 제품에서 더 중요합니다.

최근 DIALØGUE에서 했던 가장 유용한 fixes 중 하나는 겉에서 보면 꽤 지루해 보였습니다. TTS thresholding과 per-segment consistency였습니다.

초기의 whole-script TTS gate는 너무 낙관적이었습니다. 긴 팟캐스트가 실제 input limit를 넘고, 여러 번 실패한 retries를 낭비한 뒤에야 fallback했습니다. 어떤 runs에서는 시스템이 스스로 바로잡기 전까지 약 12초의 피할 수 있었던 latency가 생겼습니다.

영어에서도 이건 충분히 짜증 납니다.

다국어 flows에서는 더 나쁩니다. voice consistency 자체가 원래 더 어렵기 때문입니다.

해결책은 "더 좋은 model을 쓰자"가 아니었습니다. product work였습니다.

• whole-script synthesis의 threshold를 낮춘다
• 긴 에피소드를 더 빨리 per-segment mode로 넘긴다
• 각 segment의 에너지를 위한 opening / middle / closing guidance를 추가한다
• 다음 segment가 다른 show처럼 들리지 않게 이전 dialogue 몇 줄을 continuity context로 전달한다

이게 fallback behavior입니다. 이게 성숙도입니다.

어떤 언어 전용 TTS voice가 이상하게 들리면 어떻게 되는가? 생성된 답변이 언어를 섞기 시작하면 어떻게 되는가? localized flow 한가운데 untranslated error message가 나오면 어떻게 되는가? 긴 script가 model limit를 넘으면 어떻게 되는가?

바로 그런 순간들이 다국어 지원이 단순한 feature인지, 진짜 foundation인지를 보여줍니다.

시스템이 분명히 도와주려 하고 있다는 게 느껴질 때는 사용자가 꽤 관대합니다. 하지만 제품이 careless하게 느껴지면 그 관대함은 훨씬 빨리 사라집니다.

---

Lesson 4: coverage가 값어치를 못 하는 순간을 알아야 합니다

비즈니스 질문은 "언어를 하나 더 지원할 수 있을까?"가 아닙니다.

진짜 질문은 이겁니다.

• 이 언어가 실제 usage나 실제 distribution을 열어줄 것인가?
• UI와 output 양쪽에서 믿을 만한 quality bar를 유지할 수 있는가?
• support debt를 만들지 않고 failure cases를 감당할 수 있는가?

대답이 아니라면, 당신이 내놓는 건 multilingual capability가 아닙니다. multilingual surface area입니다. 그리고 품질 없는 surface area는 조용히 trust를 약화시킵니다.

---

Lesson 5: 다국어 제품에는 자체적인 eval layer가 필요합니다

이건 DIALØGUE와 제 블로그 아카이브 모두에서 얻은 가장 큰 takeaway일지도 모릅니다.

다국어 품질은 특히 규모가 커지면 직감만으로는 판단할 수 없습니다.

explicit checks가 필요합니다.

• locale-specific 날짜와 timezone behavior
• terminology consistency
• UI overflow
• fallback language rules
• segment 간 TTS consistency
• host / personality drift
• real user flows에서의 output quality

다시 말해, 다국어 제품에도 evals가 필요합니다.

그리고 저는 바로 여기서 AI builders가 함정에 빠지기 쉽다고 생각합니다. model이 얼마나 많은 것을 produce할 수 있는지에 매료된 나머지, "좋다"를 durable하게 정의하는 데 쓰는 시간이 줄어드는 거죠.

작은 규모에서는 아직 manage할 수 있습니다.

더 큰 규모에서는 위험해집니다.

---

그래서 저는 지금 어떻게 생각하느냐

저는 다국어 AI 제품에 대해 그 어느 때보다 optimistic합니다.

AI는 정말 economics를 바꿉니다. 한 사람이나 작은 팀이 shipping할 수 있는 범위를 실제로 넓혀줍니다. 얼마 전까지만 해도 unrealistic해 보이던 product ambitions를 실제로 가능하게 만듭니다.

하지만 동시에 product judgment의 기준도 끌어올립니다.

언어 확장이 쉬워지는 순간, quality가 차별점이 되기 때문입니다. 그리고 다국어 제품의 quality는 번역만으로 오지 않습니다. context, voice, interface fit, fallbacks, review loops, 그리고 "native enough"가 실제로 무엇을 뜻하는지에 대한 아주 솔직한 정의에서 옵니다.

그게 DIALØGUE가 저에게 가르쳐준 것이었습니다. 지원하는 언어가 많아질수록, 이름을 뭐라고 붙이든 실제로는 더 많은 product management를 하고 있게 됩니다.

당신의 제품이 진짜 multilingual이라면, strings가 번역됐다고 해서 일이 끝나지 않습니다. 거기서부터 진짜 일이 시작됩니다.

이 사고방식의 결과를 보고 싶다면, DIALØGUE는 지금 7개 언어로 live입니다. 그리고 더 많은 사람이 쓸수록, 이 multilingual layer는 계속해서 새로운 걸 가르쳐줄 것 같습니다. 대체로 좀 humble해지는 종류의 것들이요.

당신도 multilingual products를 만들고 있다면 정말 듣고 싶습니다. 가장 어려운 bug가 번역과는 아무 상관이 없다는 걸 깨달은 순간이 언제였나요?

Cheers, Chandler

---

자주 묻는 질문

다국어 AI 제품을 만들 때 가장 어려운 부분은 무엇인가요?

번역 자체가 아닙니다. AI는 이제 그 부분을 꽤 잘 처리합니다. 가장 어려운 건 번역 주변의 모든 것입니다. timezone-aware formatting, TTS segments 사이의 voice consistency, 문자열 길이가 달라지며 깨지는 UI components, 그리고 특정 locale에서 무언가 잘못됐을 때의 fallback behavior 같은 것들입니다. 이런 건 언어 문제가 아니라 제품 문제입니다.

제 AI 제품에 더 많은 언어를 추가해야 할까요?

품질을 유지할 수 있을 때만요. 언어를 하나 추가할 때마다 지속적인 product work가 생깁니다. layout QA, voice tuning, locale-specific 날짜와 숫자 formatting, 그리고 fallback paths가 따라옵니다. 당신의 제품이 podcasts, long-form writing, conversational AI처럼 nuance와 generated content에 의존한다면, 단순한 transactional interface보다 훨씬 더 높은 기준이 필요합니다.

다국어 AI 기능은 어떻게 테스트하나요?

명시적인 eval layer를 구축해야 합니다. DIALØGUE의 경우 locale-specific 날짜, TTS segment consistency, 7개 언어 전체의 UI overflow, 그리고 생성된 host dialogue에서 personality drift가 있는지를 체크하는 뜻입니다. 두세 개 언어를 넘어서기 시작하면 직감만으로는 부족합니다. surface area가 너무 커서 수동 spot-check만으로는 감당이 안 됩니다.

AI는 localization을 더 쉽게 만드나요, 더 어렵게 만드나요?

둘 다입니다. AI는 초기 번역을 훨씬 더 빠르고 저렴하게 만들어 줍니다. 하지만 동시에 "이제 끝났다"는 false sense of completion도 줍니다. 단어가 맞아 보이면 제품이 ready하다고 착각하게 되죠. 실제 일, 그러니까 context, voice, UI fit, fallbacks는 여전히 human judgment를 필요로 합니다. AI는 multilingual coverage의 floor를 올렸지만, ceiling은 여전히 product craft입니다.