"한국어만 지원하면 되는 거 아닌가요?"
처음에는 저도 그렇게 생각했습니다. 한국 시장을 타겟으로 만든 채용 SaaS인데, 굳이 영어와 일본어까지 지원할 이유가 있나? 그런데 채용 시장의 특성을 생각하면 답이 달라집니다.
한국의 시니어 테크 인재 중 상당수는 글로벌 기업 출신이거나, 영어로 업무하는 환경에 있습니다. 일본은 한국 다음으로 큰 2차 시장이고, IT 인재 부족이 심각한 곳입니다. 처음부터 다국어를 고려하지 않으면, 나중에 붙이는 건 10배는 더 어렵습니다.
그래서 첫 번째 리디자인 스프린트 때 i18n을 전면 적용하기로 했습니다. 혼자서. AI와 함께.
• • •
왜 3개국어인가
Convince-X가 지원하는 언어는 세 개입니다. 한국어(KO), 영어(EN), 일본어(JA). 각각을 선택한 이유가 있습니다.
한국어 — 홈 마켓. 창업자가 12년간 일한 시장이고, 초기 유저 대부분이 한국 리크루터입니다. 제품의 핵심 로직과 TA 방법론이 한국 채용 시장의 맥락에서 나왔기 때문에, 한국어가 기본 언어입니다.
영어 — 글로벌 확장. 글로벌 런칭을 앞두고 있고, 영어를 지원하지 않으면 글로벌 유저 접근이 불가능합니다. 또한 한국에서도 외국인 채용을 하는 기업이 많기 때문에, 영어 지원은 선택이 아니라 필수입니다.
일본어 — 2차 시장. 일본 IT 채용 시장은 $30B+ 규모이고, 엔지니어 부족이 심각합니다. 한국 헤드헌터가 일본 시장에 진출하는 케이스가 늘고 있고, Convince-X의 포지셔닝과 맞습니다.
| 항목 |
한국어 |
영어 |
일본어 |
| 번역 키 |
550+ |
550+ |
550+ |
| 데모 프로필 |
13직군 200명 |
200명 (미국) |
200명 (일본) |
| 난이도 |
기본 |
중간 |
높음 |
• • •
i18n 시스템 설계
프레임워크를 쓸까 잠깐 고민했습니다. react-i18next, vue-i18n 같은 라이브러리들이 있지만, Convince-X는 바닐라 JS + Express 기반이라 무거운 프레임워크를 붙이는 게 오버킬이었습니다.
결국 자체 i18n 시스템을 만들었습니다. 핵심은 단순합니다.
i18n 아키텍처
// HTML: data-i18n 속성으로 마킹
<button data-i18n="search.button">검색</button>
// JSON: 언어별 파일
ko.json: { "search.button": "검색" }
en.json: { "search.button": "Search" }
ja.json: { "search.button": "検索" }
// JS: DOM 순회하며 텍스트 교체
document.querySelectorAll('[data-i18n]')
.forEach(el => el.textContent = lang[el.dataset.i18n])
이 방식의 장점은 프레임워크 의존성이 제로라는 것입니다. HTML 파일에 data-i18n 속성만 붙이면 되고, 언어 전환은 JSON 파일만 로드하면 끝입니다. 빌드 과정도 필요 없습니다.
물론 단점도 있습니다. 복수형 처리, 날짜/숫자 포맷, 컨텍스트 기반 번역 같은 고급 기능은 직접 구현해야 합니다. 하지만 채용 SaaS에서 그런 기능이 필요한 경우는 드뭅니다. 실용적인 선택이었습니다.
• • •
550개 키의 관리법
i18n을 시작하면 가장 먼저 부딪히는 문제가 키 관리입니다. 550개가 넘는 번역 키를 3개 언어로 관리하면 총 1,650개의 번역 엔트리가 됩니다.
규칙을 정했습니다.
네이밍 컨벤션: 페이지.컴포넌트.요소 형식. 예를 들어 search.filter.location, pipeline.stage.interview. 이렇게 하면 키만 봐도 어디에 쓰이는지 알 수 있습니다.
누락 감지: 한 언어에서 키를 추가하면, 다른 두 언어에서 해당 키가 없을 때 콘솔에 경고가 뜨도록 했습니다. 개발 중에 번역 누락을 바로 잡을 수 있습니다.
Fallback 전략: 번역이 없으면 한국어 기본값을 보여줍니다. 빈 문자열이 노출되는 것보다 훨씬 낫습니다.
리디자인 스프린트 때 전체 HTML 12개 파일을 한꺼번에 i18n 적용했습니다. data-i18n 속성을 수백 군데 붙이는 작업은 단순하지만 시간이 걸립니다. AI가 패턴을 인식하고 반복 작업을 처리해주면서, 이틀 만에 전체 적용을 끝냈습니다.
550개의 키를 관리하는 비결은 키를 잘 이름 짓는 것이 전부입니다. 나중에 봐도 어디에 쓰이는지 알 수 있으면 됩니다.
• • •
AI 번역의 함정
550개 키를 3개 언어로 번역하는 건 혼자서는 불가능합니다. AI의 도움이 필수적이었습니다. 그런데 AI 번역을 그대로 쓰면 안 됩니다.
가장 흔한 문제는 과도한 직역입니다. "Upload your resume"을 "당신의 이력서를 업로드하세요"로 번역하면 한국어로서는 어색합니다. 한국어 UI에서는 "이력서 업로드"가 자연스럽습니다. AI는 문법적으로 정확한 번역을 하지만, UI 맥락에서의 자연스러움은 놓칩니다.
또 하나는 일관성 문제입니다. 같은 "candidate"를 어떤 곳에서는 "후보자"로, 다른 곳에서는 "지원자"로 번역하는 경우가 생깁니다. AI에게 한 번에 전체를 번역시키면 이런 불일치가 발생합니다.
| 원문 (EN) |
AI 직역 |
수정 후 |
| No results found |
결과가 발견되지 않았습니다 |
검색 결과 없음 |
| Are you sure? |
확실합니까? |
정말 삭제하시겠습니까? |
| Get started |
시작하세요 |
무료로 시작하기 |
해결책은 용어 사전을 먼저 만드는 것이었습니다. "candidate = 후보자", "position = 포지션", "pipeline = 파이프라인" 같은 핵심 용어를 정의한 후, AI에게 이 사전을 참조해서 번역하도록 지시했습니다. 그리고 번역 결과를 사람이 한 번 더 검토합니다. 완벽하진 않지만, 일관성이 크게 올라갔습니다.
• • •
일본어라는 난관
한국어와 영어는 그래도 관리가 됩니다. 문제는 일본어입니다.
일본어에는 경어(敬語, keigo)라는 체계가 있습니다. 같은 "확인하다"가 맥락에 따라 "確認する", "ご確認ください", "確認いたします"로 달라집니다. UI에서 어떤 레벨의 경어를 쓸지 결정하는 것 자체가 설계 문제입니다.
경어 레벨 결정: B2B SaaS이므로 "です/ます" 체(정중체)를 기본으로 잡았습니다. 너무 격식 있으면 딱딱하고, 너무 캐주얼하면 전문성이 떨어져 보입니다. 버튼 텍스트는 명사형("検索", "保存"), 설명 문구는 정중체("〜してください")로 통일했습니다.
또 하나의 문제는 UI 길이입니다. 같은 의미의 텍스트가 일본어로 쓰면 한국어보다 길어지는 경우가 많습니다. "검색 결과"는 4글자인데, "検索結果"도 4글자이니 괜찮지만, "이 후보자를 파이프라인에 추가하시겠습니까?"는 일본어로 쓰면 버튼이나 모달이 터집니다.
해결 방법은 일본어 전용 축약 규칙을 만든 것입니다. 버튼은 최대 6자, 모달 제목은 최대 15자 같은 가이드라인을 정하고, 일본어 번역 시 이 제한을 지키도록 했습니다.
• • •
한자 깨짐 사건
v1.5.3 배포 때 터진 사건입니다. 중국어 간체(簡體)가 전 영역에서 깨졌습니다.
정확히 말하면, 일본어 한자와 중국어 간체가 같은 유니코드 코드 포인트를 공유하는 경우가 있는데, 폰트가 제대로 로드되지 않으면 한쪽이 깨져 보입니다. PDF 리포트에서 특히 심했습니다.
장애 리포트 — 한자 렌더링
증상: PDF/HTML 전 영역에서 중국어 간체 글자가 깨짐
원인: 다국어 폰트 미로드 상태에서 렌더링 시도
해결: HTML 12개 + CSS + PDF 3종에 다국어 폰트 적용, 서버사이드 렌더링 최적화로 폰트 완전 로드 보장
교훈: 다국어 지원은 텍스트 번역만이 아니라 렌더링까지 포함한다
PDF 생성 시 서버사이드 렌더링을 최적화해서 폰트가 완전히 로드된 후에 렌더링하도록 바꿨습니다. 이 한 줄의 변경이 전체 한자 깨짐 문제를 해결했습니다.
이 사건에서 배운 건, i18n은 텍스트 번역만이 아니라는 것입니다. 폰트, 렌더링, PDF 생성, 이메일 인코딩까지 모두 다국어의 영역입니다.
• • •
혼자서도 가능합니다
솔직히, 3개국어 지원은 1인 창업자가 할 일이 아니라고 생각할 수 있습니다. 대기업도 로컬라이제이션 팀을 따로 두는데, 혼자서 이걸 한다고?
가능합니다. 단, 조건이 있습니다.
1
처음부터 설계에 넣을 것
나중에 붙이면 모든 하드코딩된 문자열을 찾아야 합니다. 처음부터 data-i18n을 쓰면 이 비용이 0입니다.
2
AI를 보조로만 쓸 것
AI 번역을 그대로 출시하면 안 됩니다. 용어 사전 + 사람 검토가 필수입니다.
3
키 네이밍에 투자할 것
550개 키가 체계 없이 늘어나면 관리 불가능합니다. 네이밍 컨벤션이 생명입니다.
4
폰트와 렌더링을 테스트할 것
번역만 하고 끝이 아닙니다. 실제 화면에서, PDF에서, 이메일에서 글자가 제대로 보이는지 확인해야 합니다.
언어 토글 UX도 중요합니다. Convince-X에서는 헤더 우측에 KO/EN 버튼을 두고, 선택한 언어를 localStorage에 저장해서 다음 방문 시에도 유지되도록 했습니다. 사소해 보이지만, 매번 언어를 다시 선택해야 한다면 유저는 떠납니다.
데모 프로필도 지역별로 로컬라이즈했습니다. 한국어 데모에는 한국 기업과 한국 이름의 프로필이, 영어 데모에는 미국 기업과 영문 이름이, 일본어 데모에는 일본 기업과 일본 이름이 나옵니다. 200명씩, 13개 직군. 이것도 AI와 함께 만들었지만, 실존 기업명과 지역에 맞는 현실적인 프로필이 되도록 사람이 검수했습니다.
다국어 지원의 핵심은 번역이 아닙니다. 각 시장의 유저가 "이건 내 언어로 만들어진 제품이구나"라고 느끼게 하는 것입니다.
3개국어 SaaS를 혼자 만드는 건 쉽지 않지만, 불가능하지도 않습니다. AI가 반복 작업을 처리하고, 사람이 품질을 잡으면 됩니다. 완벽하지 않아도, 시작하는 게 중요합니다. 완벽은 유저 피드백을 받으면서 만들어가는 겁니다.
"Why not just support Korean?"
That was my first thought too. I built a recruitment SaaS targeting the Korean market -- why bother with English and Japanese? But when you consider the nature of the hiring industry, the answer changes completely.
Many senior tech professionals in Korea come from global companies or work in English-speaking environments. Japan is our second-largest target market, facing a severe IT talent shortage. If you don't plan for multilingual support from the start, retrofitting it later is 10x harder.
So during the first redesign sprint, I decided to implement i18n across the entire product. Solo. With AI.
• • •
Why Three Languages
Convince-X supports three languages: Korean (KO), English (EN), and Japanese (JA). Each was chosen for a specific reason.
Korean -- Home market. The founder spent 12 years in this market, and most early users are Korean recruiters. The product's core logic and TA methodology emerged from the Korean hiring context, making Korean the default language.
English -- Global expansion. With a global launch ahead, not supporting English means zero access to international users. Even within Korea, many companies hire foreign talent, making English support a necessity rather than an option.
Japanese -- Secondary market. Japan's IT recruitment market exceeds $30B, and the engineer shortage is severe. More Korean headhunters are entering the Japanese market, and it aligns perfectly with Convince-X's positioning.
| Item |
Korean |
English |
Japanese |
| Translation Keys |
550+ |
550+ |
550+ |
| Demo Profiles |
200 (13 roles) |
200 (US) |
200 (Japan) |
| Difficulty |
Basic |
Medium |
Hard |
• • •
Designing the i18n System
I briefly considered using a framework. Libraries like react-i18next and vue-i18n exist, but Convince-X runs on vanilla JS + Express, making a heavy framework overkill.
So I built a custom i18n system. The core concept is simple.
i18n Architecture
// HTML: Mark with data-i18n attribute
<button data-i18n="search.button">Search</button>
// JSON: Language-specific files
ko.json: { "search.button": "검색" }
en.json: { "search.button": "Search" }
ja.json: { "search.button": "検索" }
// JS: Traverse DOM and swap text
document.querySelectorAll('[data-i18n]')
.forEach(el => el.textContent = lang[el.dataset.i18n])
The advantage of this approach is zero framework dependency. Just add data-i18n attributes to HTML elements, load the JSON file for each language, and you're done. No build process needed.
Of course, there are downsides. Advanced features like plural handling, date/number formatting, and context-based translations need to be implemented manually. But for a recruitment SaaS, those rarely come up. It was a pragmatic choice.
• • •
Managing 550 Keys
The first challenge you hit with i18n is key management. Over 550 translation keys across 3 languages means 1,650+ translation entries.
I established rules.
Naming Convention: page.component.element format. For example, search.filter.location, pipeline.stage.interview. This way, you can tell where a key is used just by reading it.
Missing Key Detection: When a key is added in one language, a console warning appears if the corresponding key is missing in the other two languages. This catches translation gaps during development.
Fallback Strategy: If a translation is missing, the Korean default is displayed. Much better than showing an empty string.
During the redesign sprint, I applied i18n to all 12 HTML files at once. Adding data-i18n attributes to hundreds of elements is simple but time-consuming. AI recognized the patterns and handled the repetitive work, letting me finish the entire rollout in two days.
The secret to managing 550 keys is naming them well. If you can tell where a key is used months later, you've won.
• • •
The Pitfalls of AI Translation
Translating 550 keys into 3 languages is impossible solo. AI assistance was essential. But you can't ship AI translations as-is.
The most common issue is over-literal translation. Translating "Upload your resume" literally into Korean produces an awkward result. In Korean UI, "Resume Upload" (noun form) is more natural. AI produces grammatically correct translations but misses the naturalness required in UI context.
Another problem is consistency. The same word "candidate" might be translated differently across locations -- sometimes as one Korean term, sometimes as another. When AI translates everything at once, these inconsistencies creep in.
| Original (EN) |
AI Literal (KO) |
After Review (KO) |
| No results found |
Results were not found |
No results |
| Are you sure? |
Are you certain? |
Confirm deletion? |
| Get started |
Please start |
Get started free |
The solution was building a glossary first. I defined core terms -- "candidate," "position," "pipeline" -- then instructed AI to reference this glossary during translation. A human reviews the output. Not perfect, but consistency improved dramatically.
• • •
The Japanese Challenge
Korean and English are manageable. The real challenge is Japanese.
Japanese has an honorific system called keigo. The same verb "to confirm" changes form depending on context -- casual, polite, or humble. Deciding which level of formality to use in a UI is itself a design decision.
Honorific Level Decision: Since it's a B2B SaaS, I chose the "desu/masu" form (polite) as the default. Too formal feels rigid; too casual undermines professionalism. Button text uses noun forms, while descriptive text uses the polite form consistently.
Another issue is text length variation. The same content in Japanese is often 30-50% longer than Korean. Buttons, error messages, and tooltips in confined spaces can overflow when rendered in Japanese.
The solution was creating Japanese-specific abbreviation rules. Guidelines like "buttons max 6 characters, modal titles max 15 characters" kept the translations within safe bounds.
• • •
The CJK Rendering Incident
This incident hit during the v1.5.3 deployment. Simplified Chinese characters broke across the entire product.
To be precise, certain Japanese kanji and Simplified Chinese characters share the same Unicode code points. When fonts fail to load properly, one set renders incorrectly. It was especially severe in PDF reports.
Incident Report -- CJK Rendering
Symptom: Simplified Chinese characters broken across all PDF/HTML surfaces
Root Cause: Rendering attempted before multilingual fonts fully loaded
Fix: Applied multilingual fonts to 12 HTML files + CSS + 3 PDF templates; optimized server-side rendering to ensure full font loading
Lesson: Multilingual support isn't just text translation -- it includes rendering
I optimized the server-side PDF generation to wait for fonts to fully load before rendering. This single change resolved all CJK character rendering issues.
The lesson from this incident: i18n isn't just about text translation. Fonts, rendering, PDF generation, email encoding -- all fall under the multilingual umbrella.
• • •
Yes, You Can Do It Solo
You might think trilingual support isn't feasible for a solo founder. Even large companies have dedicated localization teams. How can one person do this?
It's possible. With conditions.
1
Build it in from Day 1
Retrofitting means hunting down every hardcoded string. Starting with data-i18n from the beginning reduces this cost to zero.
2
Use AI as an assistant, not the author
Never ship raw AI translations. A glossary + human review is non-negotiable.
3
Invest in key naming
550 keys growing without structure becomes unmanageable. Naming conventions are your lifeline.
4
Test fonts and rendering
Translation alone isn't enough. Verify that characters render correctly on screen, in PDFs, and in emails.
Language toggle UX matters too. In Convince-X, we placed KO/EN buttons in the header and store the selection in localStorage so it persists across visits. It seems minor, but if users have to re-select their language every time, they'll leave.
Demo profiles are also localized by region. Korean demos show Korean companies and names; English demos feature US companies and English names; Japanese demos present Japanese companies and names. 200 profiles each, across 13 job categories. AI helped create them, but humans verified that each profile references real companies and realistic career trajectories.
The essence of multilingual support isn't translation. It's making users in each market feel: "This product was built for my language."
Building a trilingual SaaS solo isn't easy, but it's not impossible. Let AI handle the repetitive work while you maintain quality. It doesn't have to be perfect -- just start. Perfection comes from user feedback.
