다국어 서비스 개발, 번역만 붙이면 될까 — 해외 출시 전에 정해야 할 6가지

다국어 서비스 개발은 대부분 이런 순간에 시작됩니다. 국내에서 잘 돌아가던 앱에 일본 바이어나 동남아 파트너의 문의가 들어옵니다. 대표가 기존 개발사에 전화를 겁니다. “영어랑 일본어만 추가하면 되죠?” 며칠 뒤 돌아온 견적은 처음 앱을 만들 때와 크게 다르지 않은 금액입니다. 화면이 늘어난 것도 아닌데 왜 이런 숫자가 나오는지 납득이 되지 않습니다.

납득이 되지 않는 이유는 질문이 틀렸기 때문입니다. 다국어 서비스 개발에서 번역은 가장 마지막에, 가장 싸게 끝나는 일입니다. 비용과 일정을 실제로 결정하는 것은 언어가 아니라 그 언어를 쓰는 나라의 결제 수단, 개인정보 규정, 서버 위치, 시차, 그리고 그 모든 것을 누가 정의하느냐입니다.

디비컨설팅은 100건이 넘는 웹·앱·플랫폼 프로젝트를 진행했고, 50곳 이상의 글로벌 파트너사와 함께 일합니다. 와디즈의 글로벌 플랫폼, 삼성물산 홈닉, GS건설 엘리시안 리조트 웹·앱, 하나투어 하나오픈챗을 구축했습니다. 고객 만족도는 98%이고, 전담 개발팀은 평균 2~4주 안에 구성됩니다. 아래 내용은 그 과정에서 반복해서 확인한 것들입니다.

왜 다국어 견적은 ‘번역비’로 끝나지 않는가

번역은 마지막 작업이지만, 다국어는 첫 설계입니다

국내 전용으로 만든 서비스는 화면에 보이는 문구가 코드 안에 그대로 박혀 있는 경우가 많습니다. 빠르게 만들기에는 이 방식이 편하기 때문입니다. 문제는 언어를 하나 추가하려는 순간 드러납니다. 문구를 바꾸려면 그 문구가 들어 있는 화면을 전부 다시 열어야 합니다.

처음부터 국제화 구조를 깔아두면 언어 추가는 언어 파일 하나를 넣는 작업입니다. 나중에 깔면 이미 완성된 화면 전체를 다시 만지는 작업이 됩니다. 견적이 두 배가 되는 지점이 정확히 여기입니다. 개발사가 비싸게 부르는 것이 아니라, 하지 않아도 됐을 일을 지금 하게 되는 것입니다.

길이 문제도 함께 옵니다. 한국어 기준으로 잡은 버튼에 독일어 문장을 넣으면 넘칩니다. 일본어는 줄바꿈 규칙이 다르고, 아랍어는 화면이 오른쪽에서 왼쪽으로 흐릅니다. 이것은 번역가가 해결할 수 있는 문제가 아니라 웹 개발 외주 단계에서 화면 설계로 풀어야 하는 문제입니다.

화면 수는 그대로인데 검수량은 몇 배가 됩니다

국내 전용 앱은 한국어 화면 하나만 확인하면 됩니다. 3개 언어를 지원하는 앱은 언어마다 레이아웃이 깨지는 지점이 다르고, iOS와 Android가 글꼴을 다르게 처리하며, 국가마다 결제 흐름이 갈라집니다. 확인해야 하는 경우의 수가 곱셈으로 늘어납니다.

견적서에 이 검수 비용이 보이지 않는다면, 그 견적은 저렴한 것이 아니라 항목이 빠진 것입니다. 출시 직전에 “언어별로 다시 봐야 한다”는 이야기가 나오고, 그때부터 일정이 밀립니다. 무엇을 완료로 볼 것인지 미리 정하는 문제는 개발 검수 기준에서 따로 다뤘습니다.

결제·법규·인프라는 언어와 함께 따라옵니다

언어를 추가한다는 것은 사실상 나라를 추가한다는 뜻입니다. 나라가 추가되면 결제 수단이 달라지고, 통화와 세금 표기가 달라지고, 개인정보를 어디에 어떻게 보관해야 하는지가 달라집니다. 서버를 어느 지역에 둘 것인지도 결정해야 합니다.

여기서 많은 프로젝트가 멈춥니다. 이 항목들은 개발 이슈이기 이전에 사업 결정이기 때문입니다. 어느 나라에 먼저 들어갈지, 현지 법인을 세울지, 결제를 국내에서 받을지 현지에서 받을지는 개발사가 대신 정해줄 수 없습니다. 그런데 이 결정이 없으면 개발도 시작할 수 없습니다.

시차는 비용이 아니라 속도의 문제입니다

해외 개발팀과 직접 일해 본 회사들이 공통적으로 이야기하는 어려움은 단가가 아니라 왕복 시간입니다. 오전에 보낸 질문의 답이 다음 날 아침에 옵니다. 답이 질문의 의도와 다르면 하루가 더 갑니다. 사흘이면 끝날 논의가 일주일이 됩니다. 이 지연은 견적서 어디에도 적혀 있지 않지만 일정에는 그대로 반영됩니다.

해외 출시 전에 정해야 할 6가지

견적을 받기 전에 아래 여섯 가지가 정해져 있으면 프로젝트의 성격이 달라집니다. 정해져 있지 않으면 개발사는 가장 넓은 범위를 가정해서 견적을 내고, 그 결과가 “왜 이렇게 비싸냐”는 반응으로 돌아옵니다.

1. 대상 국가 — 언어가 아니라 국가를 먼저 정합니다. “영어 버전”은 범위가 아니고, “미국 출시”는 범위입니다. 결제·법규·서버 위치가 전부 여기서 갈립니다.
2. 국제화 구조를 지금 깔 것인가 — 당장은 언어 하나만 추가하더라도, 2차·3차 국가 계획이 있다면 지금 구조를 깔아두는 편이 총비용이 낮습니다. 계획이 없다면 굳이 지금 깔 이유도 없습니다. 이건 예산이 아니라 로드맵으로 판단할 문제입니다.
3. 결제를 어디서 받을 것인가 — 국내 결제사로 해외 카드를 받을 것인지, 현지 결제 수단을 붙일 것인지에 따라 연동 난이도와 정산 구조가 완전히 달라집니다. 개발 항목이기 이전에 자금 흐름의 문제입니다.
4. 개인정보를 어디에 보관할 것인가 — 국가에 따라 데이터를 자국 내에 두도록 요구하는 경우가 있습니다. 이 결정이 뒤집히면 서버 구성과 배포 파이프라인을 다시 만들어야 합니다. 가장 늦게 발견되고 가장 비싸게 고치는 항목입니다.
5. 언어별 QA를 어디까지 볼 것인가 — 모든 언어를 동일한 깊이로 검수할지, 1차 국가만 전수 검수하고 나머지는 핵심 화면만 볼지 미리 정합니다. 정하지 않으면 출시 직전에 정하게 되고, 그때는 일정을 미루는 것 외에 선택지가 없습니다.
6. 출시 후 문구는 누가 갱신할 것인가 — 언어가 늘어나면 운영 부담도 같이 늘어납니다. 프로모션 문구 하나를 바꿔도 언어 수만큼 바꿔야 합니다. 사내에서 직접 관리할지, 개발사가 맡을지, 관리자 화면에서 처리할 수 있게 만들지를 개발 전에 정해야 합니다.

여섯 가지 모두 개발사가 대신 정해줄 수 없는 항목입니다. 그런데 여섯 가지 모두 정해지지 않으면 개발을 시작할 수 없습니다. 다국어 프로젝트가 어려운 진짜 이유가 여기에 있습니다. 기술 난이도가 아니라 결정의 밀도가 높습니다.

실제 선택지는 세 가지입니다

다국어 서비스를 만들기로 했다면 발주 방식은 결국 세 가지 중 하나입니다. 언어를 몇 개 지원할지보다 이 선택이 결과를 더 크게 좌우합니다.

항목	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
다국어 구조 설계 경험	회사마다 편차	있음	있음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
시차 대응 부담	없음	발주사가 감당	PM이 흡수
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 직접 발주가 매력적으로 보이는 이유는 단가 한 줄 때문입니다. 그런데 다국어 프로젝트에서 발주사가 실제로 감당하게 되는 것은 단가가 아니라 정의와 조율입니다. 어떤 화면이 어떤 언어에서 어떻게 보여야 하는지, 결제 실패는 어떻게 처리할지, 이번 스프린트에서 무엇을 완료로 볼지를 영어로, 시차를 넘어, 매일 결정해야 합니다.

사내에 이 역할을 할 사람이 있다면 해외 직접 발주는 합리적인 선택입니다. 없다면 그 일은 대표나 기획자에게 넘어가고, 결국 본업이 멈춥니다. 세 번째 열은 단가를 낮추는 구조가 아니라 정의 책임을 한국어로 처리하는 구조입니다. 이 차이는 IT 외주가 분쟁으로 끝나는 이유에서 더 자세히 다뤘습니다.

디비컨설팅이 이 구조를 통제하는 방식

1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 다국어 프로젝트에서는 이 단계에서 대상 국가, 지원 언어, 결제 수단, 개인정보 처리 방식을 확정합니다. 뒤에서 생기는 재작업 대부분이 여기서 제거됩니다. 어디까지 적어야 하는지는 요구사항 정의서 글을 참고하시면 됩니다.
2. 개발팀 구성 — 확정된 범위에 맞춰 전담팀을 평균 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사가 하루를 개발팀 조율에 쓰지 않습니다.
4. 테스트 및 배포 — 언어별·국가별 QA를 거친 뒤 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다. 언어를 추가로 붙일 때 다시 처음부터 시작하지 않도록 구조와 절차를 남깁니다.

1차 출시 범위를 어디까지 자를지 고민 중이라면 MVP 개발 범위를, 앱과 웹 중 무엇을 먼저 만들지 정하지 못했다면 앱 개발과 웹 개발 비교를 먼저 읽어보시길 권합니다.

실제로 만든 것들

• 와디즈 — 글로벌 플랫폼
• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 직방 — 호갱노노, 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 국내 서비스가 이미 검증되었고, 이제 해외로 확장하려는 기업
• 사내에 개발 인력이 없거나 소수여서 해외 팀을 직접 관리하기 어려운 기업
• 처음부터 다국어를 전제로 서비스를 설계하려는 기업
• 두 개 이상의 국가에 동시에 대응해야 하는 기업

반대로, 이런 경우에는 권하지 않습니다

• 이미 국제화 구조가 깔려 있고 언어 하나만 추가하면 되는 경우. 구조를 만든 기존 개발사에 맡기는 편이 빠르고 저렴합니다.
• 진출 국가가 아직 정해지지 않은 경우. 국가가 정해져야 결제·법규·인프라가 정해지고, 그래야 견적이 의미를 가집니다. 사업 판단을 먼저 마치는 것이 순서입니다.
• 정말 번역만 필요한 경우. 화면 구조를 손대지 않아도 된다면 번역 업체가 맞는 파트너입니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 영어로 개발팀과 직접 이야기하실 필요가 없습니다. 이 구조에 대한 자세한 설명은 IT 아웃소싱 페이지에 정리되어 있습니다.

다국어 개발 비용은 어떻게 산정되나요?

등급별 단가와 투입 기간을 기준으로 산정하고, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해서 제시합니다. 다국어 프로젝트에서는 언어별 QA와 국가별 결제 연동이 별도 항목으로 들어갑니다. 견적이 회사마다 달라지는 구조는 모바일 앱 개발 견적과 서비스 개발 비용에서 설명했습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 다국어 프로젝트라면 여기에 대상 국가만 추가로 알려주시면 됩니다.

진출 국가가 늘어나면 팀 규모도 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중에도 조정할 수 있습니다. 1차 국가로 출시한 뒤 2차 국가를 붙이는 방식이 실제로 가장 자주 쓰이는 형태입니다.

이미 만든 서비스에 다국어를 붙이는 것과, 처음부터 다국어로 만드는 것은 얼마나 차이가 나나요?

금액보다 작업의 성격이 다릅니다. 처음부터 다국어를 전제로 만들면 국제화 구조를 설계에 포함하는 일이고, 나중에 붙이면 이미 완성된 화면을 하나씩 다시 여는 일입니다. 후자는 화면 수에 비례해서 늘어나기 때문에, 서비스가 클수록 차이도 커집니다. 다만 이미 만든 서비스라도 화면 구조가 정리되어 있으면 예상보다 수월한 경우가 있어, 실제 견적은 코드를 확인한 뒤에 드리는 것이 정확합니다.

소스코드와 번역 리소스의 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 소스코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계해 드립니다. 언어 파일도 마찬가지입니다. 나중에 개발사를 바꾸더라도 번역 자산을 다시 만들 필요가 없습니다.

정리

다국어 서비스 개발의 비용을 결정하는 것은 언어의 개수가 아니라 구조를 언제 깔았는지, 그리고 국가별 결정을 누가 정의하는지입니다. 번역은 이 두 가지가 끝난 뒤에 붙는 가장 쉬운 단계입니다. 해외로 나가기로 했다면 첫 번째 질문은 “몇 개 언어를 지원할까”가 아니라 “어느 나라에, 무엇을 기준으로, 누가 정의해서 들어갈까”여야 합니다. 사내에 그 정의를 맡을 사람이 없다면, 한국어로 정의를 받아 글로벌 팀에 전달하는 구조가 가장 현실적인 답입니다. 앱 개발 외주를 검토 중이시라면 이 기준부터 확인해 보시기 바랍니다.