Laurel은 전문 서비스 업계를 위한 업무 인텔리전스 플랫폼입니다. 기업은 Laurel을 통해 시간 기록을 자동화하고, 수익성을 좌우하는 요인을 파악하며, AI 투자 ROI를 입증합니다. 얼마 전까지만 해도 제품은 영어만 지원했습니다. 지금은 북유럽 언어, 프랑스어, 네덜란드어, 포르투갈어, 스페인어, 한국어를 포함해 12개가 넘는 언어를 제공하고 있으며, 중국어(만다린), 태국어, 아랍어, 일본어, 베트남어도 추가를 앞두고 있습니다.

Laurel의 통합은 비교적 간단했습니다. 기존 문자열을 추출하고 정리해 코드베이스를 준비하는 작업 등, 대부분의 노력은 Laurel 측에서 이뤄졌습니다. 직접 구축하는 대안은 엔지니어링 시간 4~6개월로 추산됐고, 이후 유지보수도 끝없이 따라붙는 구조였습니다. 여기에 지연으로 놓칠 수 있는 딜까지 감안하면, 구매하지 않았을 때의 총비용은 구매 비용의 약 10배에 달한다는 결론이 나왔습니다. 이제는 새 언어 추가에 하루면 충분하고, 제품 관리자 한 명이 혼자서도 해낼 수 있습니다. 18개월 전만 해도 상상하기 어려운 일이었습니다.

"Lingo.dev는 우리의 문제를 이해하고 해결책을 제시해줬다는 점이 정말 좋았습니다. 우리는 로컬라이제이션 인프라를 직접 구축할 필요가 없었고, 그들이 완벽하게 해결해줬습니다. 엔터프라이즈 가격도 합리적이었고, 그들의 엔지니어들과는 공유 Slack 채널에서 함께 일하고 있습니다. 엣지 케이스 대응은 몇 시간 안에 이뤄집니다."

– Nick Bazley, Laurel Staff Product Manager

SaaS 기업은 언제 로컬라이제이션에 투자해야 할까요?#

Nick Bazley는 Laurel의 Staff Product Manager로, 지난 6년간 회사가 제품을 글로벌하게 확장하는 과정에서 제품 팀을 이끌어왔습니다. 그는 실제로 로컬라이제이션에 착수하기 약 1년 전부터 이 문제를 고민하고 있었습니다.

"언젠가는 해야 한다는 건 알고 있었어요." Nick은 이렇게 말합니다. "문제는 언제냐는 거였죠. 이 얘기를 꺼낼 때마다 결론은 늘 같았어요. 엄청나게 큰 프로젝트가 될 거고, 끝도 없이 오래 걸릴 거고, 결과물의 품질도 완전히 확신할 수 없다는 거였죠."

Laurel은 성장하고 있었고, 중견 시장 고객을 넘어 글로벌 엔터프라이즈 고객으로 확장하고 있었습니다. 그러다 한 가지 패턴이 보이기 시작했습니다. 한 지역에서 고객을 확보해 가치를 입증하면, 그 고객은 곧 다른 지역으로도 확장하길 원했습니다.

유럽 전역에서 영업 인력을 채용하고, 고객 성공 팀이 확장 요청을 받기 시작하면서 Nick은 이 문제가 곧 현실이 될 것임을 직감했습니다.

"이 작업이 필요해졌을 당시 우리는 약 50명 규모였어요. 로컬라이제이션 인프라를 직접 구축하는 건 너무 큰 부담이었죠. 팀 절반이 몇 달씩 묶일 수 있는 일이었고, 고객을 위해 만들어야 할 다른 것들도 많았으니까요."

왜 로컬라이제이션 인프라는 직접 만들기보다 구매해야 할까요?#

Laurel 앞에는 구매와 구축, 두 가지 선택지가 있었습니다. 직접 구축은 여러 분기에 걸친 작업이 될 가능성이 높았고, 내부 추산으로도 XXL급 프로젝트, 즉 엔지니어링 시간 4~6개월이 드는 일이었습니다. "자체 로컬라이제이션 인프라를 구축하는 데 드는 비용과 시간, 노력을 떠안는 건 현명한 선택이 아니에요. 당시 우리의 성장 단계에서는 시장에서 가장 좋은 솔루션을 도입하고, 대신 핵심 플랫폼 개발에 집중하는 게 비즈니스적으로 더 합리적이었습니다."

이 논의에서 의사결정을 기울게 한 핵심 요인은 네 가지였습니다. 시장 출시 속도, 출시 후 확장성, 맞춤화, 그리고 품질이었죠.

"우리는 로컬라이제이션 인프라 전문가가 아닙니다. 품질이 어느 정도 나올지도 알 수 없죠. 이미 로컬라이제이션 엔지니어링을 중심으로 비즈니스를 만든 회사가 있는데, 왜 그런 위험을 감수해야 할까요?"

로컬라이제이션 플랫폼과 레거시 TMS는 어떻게 평가해야 할까요?#

Nick은 Perplexity Pro로 빠르게 시장을 훑었고, 상위 검색 결과를 살펴보다가 한 레거시 TMS를 발견했습니다. 별도로 Google 검색도 해 몇 가지 옵션을 더 찾았고, Laurel의 Head of Engineering도 독립적으로 Lingo.dev를 발견했습니다.

그는 두 제품을 병행해 평가했습니다.

"겉으로 보기엔 그 레거시 TMS가 정말 세련되고 탄탄한 회사처럼 보였어요." Nick은 이렇게 말합니다. "하지만 그들이 실제로 제공하는 것과 우리가 필요로 하는 걸 하나씩 뜯어보니, 우리가 추구하던 속도와 품질 측면에서 선택지는 하나뿐이었습니다."

"제가 높이 평가한 건 Lingo.dev의 방식이었어요. 우리의 문제와 우리가 하려는 일을 이해하고, 거기에 맞는 해결책을 제시해줬죠. 엔터프라이즈 가격도 합리적이었습니다. 그리고 속도와 품질에 대한 약속이 핵심 동인이었어요. 특히 인상적이었던 건 접근성이었습니다. 우리는 실제로 플랫폼을 만드는 엔지니어들과 공유 Slack 채널에서 함께 일하고 있어요. 엣지 케이스에 부딪혀도 몇 시간 안에 대응이 이뤄집니다. 거의 우리 조직의 일부처럼 느껴질 정도예요."

법률·회계 용어에서 AI 로컬라이제이션은 얼마나 정확할까요?#

Laurel의 사용자는 법률 및 회계 전문가입니다. 독일어 UI에서 "billing rate"나 "matter" 같은 용어가 잘못 번역되면, 단지 어색해 보이는 수준이 아니라 제품 전체에 대한 신뢰를 흔들 수 있습니다. 법률·회계 용어는 정확해야 합니다.

Nick은 실제 고객과 함께 품질을 테스트했습니다. 첫 번째 결과물은 북유럽 고객들과 한 프랑스 고객에게 전달됐습니다. 북유럽 팀에서는 피드백이 전혀 없었습니다. 원어민인 프랑스 고객은 부정확한 표현 두 가지만 찾아냈고, 팀은 즉시 이를 용어집에 추가했습니다. 그 이후로는 네덜란드어, 포르투갈어, 스페인어 등에서도 문제가 없었습니다.

우리는 6개월 동안 12개 언어에 걸쳐 원어민 고객과 함께 품질을 테스트했습니다. 보고된 용어 문제는 총 2건이었고, 둘 다 같은 날 용어집 추가로 해결됐습니다. 설정된 용어집이 적용된 로컬라이제이션 엔진은 번역 로직을 처음부터 직접 구축하는 것보다 법률 용어를 더 일관되게 유지해줬습니다. 엔진이 모든 언어 쌍에 걸쳐 용어를 동시에 일관되게 적용하기 때문입니다. 이는 수작업 프로세스로는 보장하기 어려운 부분입니다.

"한동안은 용어집에 다시 들어가 손볼 일이 없었습니다."라고 Nick은 말합니다.

SaaS 제품에 새 언어를 추가하는 데 얼마나 걸릴까요?#

고객 성공 매니저가 고객이 UI에서 포르투갈어를 필요로 한다고 알리면, 예전에는 그 요청이 로드맵에 들어가고, 우선순위를 받고, 스프린트를 기다린 뒤, 몇 주씩 걸리곤 했습니다.

이제 Nick은 티켓을 만들고, 과거 언어 추가 티켓을 템플릿처럼 참고해 AI Tooling에 넘긴 뒤 기다립니다. 그러면 툴링이 config에 언어를 추가하고, 언어 전환기를 업데이트하고, PR을 엽니다. 엔지니어가 PR을 검토하고 배포하면, 이후의 지속적인 로컬라이제이션은 Lingo.dev가 자동으로 처리합니다.

"하루라는 건 처음부터 끝까지를 말해요. 티켓 작성부터 PR 완료까지요. 그렇다고 제가 하루 종일 그 일만 붙잡고 있다는 뜻은 아닙니다. 그 시간 대부분은 다른 일을 하고 있어요."

AI 코딩 도구와 Lingo.dev 로컬라이제이션 인프라 덕분에 Nick은 엔지니어링 리소스 없이도 새 언어를 추가할 수 있습니다.

"이제는 Lingo.dev 덕분에 회사의 누구나 새 언어를 추가할 수 있고, 우리 로컬라이제이션 엔진도 조정할 수 있습니다. 정말 놀라운 일이죠."

로컬라이제이션 속도는 엔터프라이즈 딜 속도에 어떤 영향을 줄까요?#

비즈니스 케이스의 핵심은 엔지니어링 시간을 절약하는 데만 있지 않습니다. 물론 그것도 가능합니다. 핵심은 변화하는 확장 기회에 얼마나 빠르게 대응할 수 있느냐입니다.

"엔터프라이즈 고객과 일하다 보면 확장 기회는 정말 빠르게 생겨나요." Nick은 이렇게 말합니다. "고객은 새로운 오피스에서 어느 정도 성과가 나기 시작하면, 우리가 그들의 언어로 제품을 빠르게 제공할 수 있을 때 그 지역으로도 확장하길 원합니다. 성장을 이어가려면 우리는 그 속도에 무리 없이 대응할 수 있어야 해요."

Laurel은 첫 유럽 확장을 지원하기 위해 북유럽 5개 언어와 프랑스어부터 시작했습니다. 그 이후에는 영업팀과 고객 성공 팀을 통해 포르투갈어, 스페인어, 네덜란드어 요청이 이어졌고, 이제 글로벌 오피스로 확장하면서 더 많은 언어 도입도 논의 중입니다.

집계 결과, 통합 후 6개월 동안 Laurel은 고객 확장 요청에 대응해 7개 언어를 추가했습니다. 각각 하루도 채 걸리지 않았습니다. 이를 직접 구축하는 모델이었다면, 그 7개 언어를 위해 약 28회의 엔지니어링 스프린트가 필요했을 것이고, 그만큼의 역량을 핵심 제품 기능 개발에 쓰지 못했을 것입니다.

로컬라이제이션 인프라는 직접 구축해야 할까요, 아니면 구매해야 할까요?#

비슷한 회사, 즉 엔터프라이즈 B2B에 전문 사용자를 대상으로 하고 글로벌 확장 중이며 엔지니어링 팀이 실제 제품 개발에 집중해야 하는 회사의 VP Product에게 어떤 조언을 하겠느냐는 질문에 Nick은 망설이지 않았습니다.

"저라면 100% 벤더를 선택하겠습니다."

자체 구축에서 가장 과소평가하기 쉬운 부분은 이것입니다. "복잡성과 품질이죠. 어떤 품질이 나올지 알 수 없어요. 왜 그런 위험을 감수하겠습니까?"

벤더를 고를 때 가장 흔히 하는 실수는, 자기 문제를 충분히 명확하게 이해하지 못한 채 적합한 벤더를 선택하는 것입니다. "우리가 해결하려는 문제가 정확히 무엇인지 제대로 이해하고, 그 특정 문제에 맞는 벤더를 선택하는 것, 그게 핵심입니다."

가장 먼저 테스트해야 할 것은 이것입니다. "속도와 시장 출시까지 걸리는 시간입니다. 그리고 초기 설정을 마치고 나면, 그다음은 속도와 확장성이죠."

기다림의 실제 비용#

초기 설정은 대부분 Laurel 측에서 기술 스택을 준비하는 작업이었습니다. 그 이후에는 언어당 하루, 엔지니어링 스프린트도 필요 없고 로드맵 우선순위 조정도 필요 없습니다.

대안은 구축에 엔지니어링 시간 3~4개월이 들고, 유지보수는 계속 이어지며, 팀 내 누구도 구사하지 못하는 언어의 품질은 보장할 수 없는 방식이었습니다.

Nick은 이를 간단히 정리합니다. "로컬라이제이션 인프라는 한 번 끝내고 넘어가는 프로젝트가 아닙니다. 계속 이어지는 일이에요. 규모를 키울 때마다, 새로운 시장에 진입할 때마다, 새 기능을 추가할 때마다 필요하죠. 쉬워야 합니다. 필요한 걸 제공하기 위해 또 다른 스프린트를 요청하러 엔지니어링 팀을 계속 찾아가고 싶지는 않아요."

이 사례가 새로운 시장으로 확장하는 제품 팀에 주는 의미#

Laurel의 경험은 글로벌 엔터프라이즈 수요를 상대하는 B2B SaaS 기업 전반에서 반복되는 패턴을 보여줍니다. 로컬라이제이션은 더 이상 단순한 기능 요청이 아니라 성장의 병목이 됩니다. 이제 질문은 "로컬라이제이션을 해야 할까?"가 아니라 "다음 시장에 얼마나 빨리 '할 수 있다'고 답할 수 있을까?"입니다.

Laurel의 접근 방식을 결정한 요인은 세 가지였습니다. 팀은 핵심 제품이 아닌 인프라에 엔지니어링 리소스를 따로 투입할 여력이 없었습니다. 법률 및 회계 용어의 품질 역시 막연히 믿을 것이 아니라, 분명하게 검증할 수 있어야 했습니다.

로컬라이제이션 엔지니어링은 언어 지원을 엔지니어링 프로젝트가 아니라 설정 레이어로 바라보는 접근 방식입니다. 제품 관리자는 스프린트 없이, 엔지니어링 리소스 소모 없이, 번역 벤더와의 조율 없이도 새 언어를 추가할 수 있습니다. 시장 확장 속도가 곧 매출 성장을 좌우하는 팀에게 이 운영 방식의 변화는 기회를 선점하느냐, 그대로 놓치느냐를 가르는 차이입니다.

Laurel은 법률 및 회계 전문가를 위한 AI를 만듭니다. 현재 12개가 넘는 언어로 제품을 제공하고 있으며, 새로운 언어도 하루 만에 추가할 수 있습니다. 이들의 로컬라이제이션 인프라는 Lingo.dev 기반으로 운영됩니다.

자주 묻는 질문#

SaaS 제품에 새로운 언어를 추가하는 데 얼마나 걸리나요?

Laurel은 새로운 언어를 처음부터 끝까지 약 하루 만에 추가합니다. 제품 관리자가 이전 언어 추가 사례를 참고한 티켓을 만들고, AI 코딩 에이전트가 이를 처리한 뒤 엔지니어가 PR을 검토합니다. 별도 스프린트도, 벤더 조율도 필요 없습니다. 기존 대안이었던 사내 로컬라이제이션 인프라 구축은 어떤 언어든 실제로 출시하기까지 4~6개월이 걸릴 것으로 예상됐습니다.

스타트업은 로컬라이제이션 인프라를 직접 구축해야 할까요, 아니면 구매해야 할까요?

Laurel의 Staff PM Nick Bazley는 직접 구축과 구매를 비교 검토했습니다. 그의 결론은 명확했습니다. "우리는 로컬라이제이션 인프라 전문가가 아닙니다. 품질이 어느 수준일지도 알 수 없죠. 이미 누군가가 로컬라이제이션 엔지니어링을 중심으로 완전한 비즈니스를 만들어 놓았는데, 왜 그 리스크를 감수해야 할까요?" 내부 구축안은 엔지니어링 팀 절반이 몇 달간 매달려야 하는 XXL 프로젝트로 추산됐습니다.

전문 용어에 대한 AI 로컬라이제이션의 정확도는 어느 정도인가요?

Laurel은 6개월에 걸쳐 법률 및 회계 분야의 현지 언어 사용자 고객들과 함께 12개 언어를 테스트했습니다. 전체 용어 이슈는 단 2건뿐이었고, 두 건 모두 당일 용어집을 추가해 해결했습니다. 로컬라이제이션 엔진은 모든 언어 쌍에서 용어집 일관성을 동시에 적용합니다. 수작업으로 구축한 방식으로는 규모가 커질수록 보장하기 어려운 부분입니다.

로컬라이제이션 속도는 엔터프라이즈 세일즈 사이클에 어떤 영향을 주나요?

Laurel의 경험상, 새로운 언어 지원을 요청하는 엔터프라이즈 고객은 몇 달이 아니라 며칠 안에 답을 기대합니다. Nick Bazley는 이를 이렇게 설명합니다. "기회는 오래 기다려주지 않습니다. 우리가 일주일 안에 대응하지 못하면 그 창은 닫힐 수 있습니다." 로컬라이제이션 인프라로 전환한 뒤 Laurel은 6개월 동안 7개 언어를 추가했고, 각각 하루도 채 걸리지 않았습니다.

로컬라이제이션에서 구축과 구매의 비용 차이는 어떻게 되나요?

Laurel의 비교는 명확합니다. 짧은 통합 기간과 지속적인 사용량 기반 비용을 감수하는 것과, 직접 구축에 4~6개월의 엔지니어링 시간을 투입하고 이후 유지보수까지 무기한 떠안는 데다 품질도 보장할 수 없는 상황을 감수하는 것의 차이입니다. 6개월 동안 추가한 7개 언어는 구축 모델이었다면 약 28번의 엔지니어링 스프린트를 소모했을 것이고, 그 리소스는 대신 핵심 제품 기능 개발에 투입됐습니다.