Scribe는 이메일 서명을 더 간편하고, 더 측정 가능하게 만듭니다. 기업은 직원별 개별 설정 없이도 전사적으로 일관되고 브랜드에 맞는 서명을 배포할 수 있고, 그 서명을 측정 가능한 수익 채널로 전환할 수 있습니다. 설립 5년 차인 이 회사는 이미 강력한 제품-시장 적합성을 확보한 상태였습니다. 전체 제품을 재구축하는 과정에서 Scribe는 제품 전체와 문서를 16개 언어로 출시했습니다. 통합에는 하루도 채 걸리지 않았고, 이후에는 창업자 두 명이 채용도, 에이전시도 없이 직접 로컬라이제이션을 운영했습니다. 이들은 Lingo.dev의 MCP 서버를 통해 Claude와 반복적으로 작업하며 용어집, 브랜드 보이스, 로캘별 지침, 그리고 모든 번역에 대한 AI 평가까지 엔진 전체를 구성했습니다.

"Lingo.dev는 API, MCP, CLI로 우리 스택 안에서 바로 운영할 수 있는 로컬라이제이션 엔진을 제공했습니다. 엔지니어링 중심 팀이라면 고민할 이유가 없죠."

Clément Champau, CEO 겸 공동 창업자, Scribe

왜 5년이 지난 지금 로컬라이제이션을 시작했을까#

AI 덕분에 로컬라이제이션은 2인 팀에게도 현실적인 선택지가 됐고, 시점도 전체 제품 재구축과 정확히 맞물렸습니다. 새로운 UI, 새로운 UX, 그리고 16개 언어 지원을 알리기에 자연스러운 타이밍이었던 것입니다. Scribe는 5년이 지난 시점에 강한 제품-시장 적합성과 안정적인 UI를 확보하고 있었기 때문에, 인터페이스가 계속 바뀌어 번역을 반복해서 손봐야 하는 상황도 아니었습니다.

시장도 같은 방향으로 움직이고 있었습니다. 일부 엔터프라이즈 구매자들은 여전히 AI 도입보다 디지털화 단계에 머물러 있었고, 여러 시장에서는 현지 언어를 지원하지 않는 제품 자체가 영업 과정의 마찰로 작용했습니다. Scribe는 먼저 매출이 있는 시장부터 공략했습니다. 프랑스어권 아프리카를 포함한 프랑스어, 라틴아메리카 우선의 스페인어, 그리고 영어였습니다. 이 세 언어만으로 서구권 대부분과 라틴아메리카를 포괄할 수 있습니다. 그 다음에는 GDP가 가장 높은 시장들인 스위스, 노르웨이, 스웨덴으로 확장했습니다. Clément는 "유럽에서 GDP가 가장 높고, 세계적으로도 GDP가 높은 시장들이죠"라고 말했습니다.

엔지니어링 중심 플랫폼이 결정적이었던 이유#

Clément는 Y Combinator 디렉터리에서 Lingo.dev를 발견했습니다. 그는 새로운 YC 툴을 꾸준히 살펴보고, 남들보다 빨리 도입하는 편입니다. 최종적으로 결정에 영향을 준 것은 이 플랫폼이 스택 어디에 위치하느냐였습니다. Lingo.dev는 로컬라이제이션 엔지니어링 플랫폼입니다. 즉, 용어집, 브랜드 보이스, 로캘별 지침, 그리고 결과물을 독립적으로 채점하는 AI 평가를 갖춘 구성 가능한 로컬라이제이션 엔진이며, API, MCP 서버, CLI로 구동됩니다. 팀이 다른 인프라를 운영하듯, 개발 프로세스의 가장 첫 번째 레이어에서 작동합니다.

"우리는 개발 프로세스의 가장 첫 번째 레이어에 들어갈 수 있는 무언가를 원했습니다. API도 필요하고 MCP도 필요하죠. 그리고 그게 있으면, 그런 레고 같은 조각을 우리 에이전트 워크플로에 아주 쉽게 끼워 넣을 수 있습니다."

Scribe의 공동 창업자이자 CTO인 Gil은 API 문서를 읽고 구조가 탄탄하다고 판단한 뒤, 하루도 채 안 돼 모든 것을 통합했습니다.

"Gil에게 보내줬더니 API 문서를 읽고는 괜찮다고 하더군요. 그리고 하루도 안 돼 전부 구현했습니다."

CEO가 MCP를 통해 엔진 전체를 구성한 방법#

하루 만에 통합을 마친 뒤, Clément는 개발자가 아님에도 Lingo.dev의 MCP 서버를 통해 브랜드 보이스, 용어집, 로캘별 지침까지 엔진 전체를 직접 구성했습니다. 완성된 설정의 규모도 상당했습니다. 브랜드 보이스 16개, 지침 133개, 용어집 항목 644개였습니다.

반복 과정은 아주 구체적이었습니다. 한 언어를 실행하고, 앱을 열어 보고, 스크린샷을 찍어 MCP를 통해 다시 보냈습니다. 여기서는 클릭 유도 문구가 깨졌고, 저기서는 UI가 무너졌다는 식이었습니다. 그러면 Claude가 세 가지 레버인 용어집, 지침, 브랜드 보이스를 조정해 결과가 제대로 나올 때까지 다듬었습니다. 그렇게 한 뒤 전체 번역을 실행하고 나머지 언어까지 배포했습니다.

"한 언어를 돌려 보고, 앱을 확인하고, 스크린샷을 찍어서 MCP로 다시 보냈습니다. 여기서는 CTA가 깨졌고, 저기서는 UI가 깨졌다고요. 그러면 Claude가 용어집과 지침, 브랜드 보이스를 조정해서 제대로 맞춰줬습니다."

에이전트는 같은 워크플로 안에서 스스로 주도적으로 움직이기도 했습니다. 재구축한 홈페이지의 SEO를 최적화하던 중 Claude는 Google이 로컬라이즈된 페이지를 독립적인 로캘 타깃이 아니라 영어 페이지의 대체 페이지로 처리하고 있다는 점을 발견했습니다. 그리고 엔진에 대한 MCP 접근 권한이 있었기 때문에, 이를 바로잡기 위해 Lingo.dev 동기화를 다시 실행했습니다.

직접 읽지 못하는 언어의 번역 품질은 어떻게 검증할까?#

이 엔진은 자기 결과물을 스스로 측정합니다. Scribe의 실행 전반에서 AI 평가 평균은 100점 만점에 약 87점이었고, 점수가 매겨진 번역 가운데 약 96%가 70점 이상이었습니다. 창업자 두 명이 직접 읽지 못하는 16개 언어에 대해서도 품질 신호를 확보할 수 있었던 셈입니다.

Scribe는 대략 95% 수준이면 출시하고, 규모가 커질수록 남은 간극은 사람이 후편집하는 방식으로 메운다고 봅니다. 논리는 단순합니다. 실제 문제를 해결하는 제품이라면, 번역이 완벽하게 다듬어지지 않았다는 이유만으로 사용자가 이탈하지는 않는다는 것입니다.

"95% 수준이면 충분히 좋습니다. 진짜 문제를 해결하고 있고 사용자가 그 해결책을 원한다면, 번역이 완벽하지 않다고 해서 제품 사용을 멈추지는 않아요."

로컬라이제이션은 직접 만들어야 할까, 사야 할까?#

Clément는 로컬라이제이션을 이미 사내에서 구축해 본 경험이 있는 CTO이자 자신의 투자자 중 한 명에게 Lingo.dev를 추천했습니다. 그 반응이 빌드와 구매 사이의 질문에 답이 됐습니다.

"우리 투자자 중 한 명에게 Lingo.dev를 추천했는데, 그분도 CTO입니다. 이미 사내에서 로컬라이제이션을 구축해 본 적이 있었고, 반응은 이랬어요. '우리가 써야 했던 게 바로 이거다.' 진작 알았다면 투자했을 거라고 하더군요."

Scribe가 예상보다 크게 느낀 비용은 초기 구축 비용이 아니었습니다. 유지보수였습니다. 끝없이 생겨나는 엣지 케이스와, 시스템을 어떻게 더 개선할지에 대한 지속적인 의사결정이 진짜 비용이었습니다.

"쉬운 건 아무것도 없습니다. 엣지 케이스를 처리하기 시작하면, 그리고 그런 문제는 끝도 없이 계속 나오죠, 유지하는 데 정말 많은 시간이 듭니다. 엔지니어링 중심의 무언가를 붙여 두고, 그걸 전담해 계속 개선하는 팀이 있다는 편이 낫습니다."

AI가 실행을 맡게 되면서, 가치는 시스템을 설계하는 사람 쪽으로 이동합니다. 용어집, 브랜드 보이스, 지침, AI 평가로 구성된 로컬라이제이션 엔진은 촉박한 일정 속에서 사내 팀이 직접 구축한다고 해도 이만큼 잘 설계하기 어려운 아키텍처입니다.

과금에서 생긴 마찰, 그리고 해결#

초기에는 비용 가시성이 낮았습니다. Clément는 실행 도중 크레딧이 바닥나지 않는지 확인하려고 실행을 시작한 뒤 계속 인터페이스를 새로고침해야 했고, 실제로 크레딧이 떨어지면 실행이 멈춰 다시 시작해야 했습니다. 그는 이 문제를 제기했고, 같은 주 안에 수정 사항이 배포됐습니다. 실행 전 비용 추정과 자동 충전 사용량 표시 기능이 추가된 것입니다.

"이제는 실행을 시작하기 전에 얼마나 걸릴지, 비용이 얼마일지 볼 수 있습니다. 예전에는 크레딧이 중간에 떨어지지 않는지 확인하려고 실행을 시작한 뒤 계속 새로고침해야 했어요. 크레딧이 다 떨어지면 모든 게 멈췄고, 우리는 다시 시작해야 했거든요."

이 변화로 그는 실행이 시작되기 전에 결과를 미리 예측할 수 있게 됐습니다. 실행 시간과 비용을 사전에 알 수 있게 된 것입니다. 그가 강조한 대비는 요청을 넣고 기다리는 것과, 요청한 변경 사항이 같은 주 안에 실제로 배포되는 것을 보는 것 사이의 차이였습니다. 그는 "빠른 반복 루프, 정말 축하합니다"라고 말했습니다.

지금은 어떻게 운영되고 있나#

Scribe는 웹 앱, 데스크톱 앱 등 총 4개의 앱과 문서를 모두 영어를 기준으로, 하나의 로컬라이제이션 엔진으로 운영하고 있습니다. 지금은 autosync를 꺼 둔 상태입니다. Gil은 큰 푸시가 있은 뒤 수동으로 실행을 트리거하는데, 이는 초기 크레딧 이슈에서 생긴 습관이기도 하고 대규모 릴리스 이후 변경 사항이 많지 않았기 때문이기도 합니다. 계획은 모든 것이 완전히 안정되면 autosync를 켜서, 한 번의 푸시로 모든 앱과 문서까지 배포되게 하는 것입니다.

MCP 서버는 API, CLI와 함께 플랫폼에 들어가는 세 가지 경로 중 하나입니다. 대부분의 MCP는 읽기 전용이거나 컨텍스트 제약이 있지만, Lingo.dev의 MCP는 비개발자도 로컬라이제이션 엔진 전체를 구성할 수 있게 해줬고, 덕분에 Gil은 하루 만에 설정을 마친 뒤 곧바로 다음 일로 넘어갈 수 있었습니다.

"저는 인터페이스에서 많은 시간을 쓰지도 않았는데, 그게 아주 잘 해냈어요."

번역은 엔진이 맡았고, 구성은 Clément가 맡았습니다.

소규모 팀의 소프트웨어 로컬라이제이션에 이것이 의미하는 것#

Scribe의 론칭은 이메일 서명 관리라는 카테고리를 넘어서는 하나의 패턴을 보여줍니다. 엔지니어링 중심 팀에게 로컬라이제이션은 이제 노동의 문제가 아니라 시스템 설계의 문제가 됐습니다. 번역은 모델이 처리하고, 남는 일은 그것을 통제하는 엔진을 구성하는 일입니다. 용어집, 브랜드 보이스, 로캘별 지침, 그리고 결과물을 채점하는 AI 평가가 바로 그 핵심입니다.

이 변화는 직접 만들지, 사서 쓸지에 대한 계산 자체를 바꿉니다. 사내 로컬라이제이션에서 비용이 많이 드는 부분은 처음 버전이 아니었습니다. 시간이 갈수록 쌓이는 엣지 케이스, 모델 변화, 로캘별 규칙 같은 유지보수였습니다. 로컬라이제이션 엔지니어링 플랫폼은 그 부담을 흡수하기 때문에, 전담 로컬라이제이션 인력 없이도 2인 팀이 16개 언어를 운영할 수 있는 것입니다.

이 방식이 다른 팀에도 그대로 적용되려면 세 가지 조건이 필요합니다. 원본 콘텐츠가 버전 관리 안에 있어야 합니다. 엔진은 API, CLI, MCP 서버로 구동되어 팀이 이미 쓰고 있는 워크플로에 자연스럽게 연결될 수 있어야 합니다. 그리고 AI 평가는 팀 내 누구도 읽지 못하는 언어에서도 결과물을 측정 가능하게 만들어야 합니다. 단순히 번역을 믿는 것과, 실제로 검증하는 것의 차이입니다.

직접 들어본 이야기#

"AI가 실행을 너무 잘하게 되면서 이제 가치는 아키텍트 쪽에 있습니다. 결국 최고의 시스템 설계자가 이기는 거죠. 제가 직접 만들었다면 이렇게 좋은 시스템으로 설계하지는 못했을 겁니다."

"우리 투자자 중 한 명에게 Lingo.dev를 추천했는데, 그분도 CTO입니다. 이미 사내에서 로컬라이제이션을 구축해 본 적이 있었고, 반응은 이랬어요. '우리가 써야 했던 게 바로 이거다.' 진작 알았다면 투자했을 거라고 하더군요."

"진출하고 싶은 시장을 정하고, 먼저 한 언어만 돌려보세요. 구현하고 MCP도 테스트해 보세요. 스스로 일을 해냅니다. 진짜 아하 모먼트는 바로 MCP입니다."

Clément Champau, CEO 겸 공동 창업자, Scribe

Scribe는 수천 개 기업이 전사적으로 일관된 브랜드 이메일 서명을 직원별 설정 없이 손쉽게 배포하고, 이를 측정 가능한 매출 채널로 전환하는 데 활용하는 이메일 서명 플랫폼입니다. 두 명의 공동 창업자가 16개 언어로 제품과 문서를 운영하고 있으며, 이를 다른 인프라처럼 다루는 하나의 로컬라이제이션 엔진으로 구성했습니다. Scribe의 로컬라이제이션은 Lingo.dev로 구동됩니다.

자주 묻는 질문#

로컬라이제이션 엔진을 통합하는 데 얼마나 걸리나요?

하루도 채 걸리지 않았습니다. Scribe의 CTO는 API 문서를 읽고 충분히 탄탄하다고 판단한 뒤, 하루가 되기 전에 기존 에이전트 워크플로에 Lingo.dev API를 연결했습니다. 이후 엔진 구성(용어집, 브랜드 보이스, 로캘별 지침)은 CEO가 MCP 서버를 통해 별도로 진행했습니다.

개발자가 아닌 사람도 로컬라이제이션 엔진을 구성할 수 있나요?

네. 하루 만에 통합을 마친 뒤, Scribe의 CEO는 개발자는 아니지만 기술적 이해를 바탕으로 Lingo.dev의 MCP 서버에서 엔진 전체를 직접 구성했습니다. 한 언어씩 실행해 보고, 앱을 검토하고, 결과가 기대한 수준에 이를 때까지 Claude로 용어집, 지침, 브랜드 보이스를 조정했습니다. 최종 구성은 브랜드 보이스 16개, 지침 133개, 용어집 항목 644개에 달했습니다.

직접 읽지 못하는 언어의 번역 품질은 어떻게 검증하나요?

Scribe는 AI 품질 점수에 의존합니다. 모든 번역은 이를 생성한 모델과는 별개의 독립된 모델이 평가합니다. Scribe의 실행 전반에서 평균 점수는 100점 만점에 약 87점이었고, 전체 번역의 약 96%가 70점 이상을 기록했습니다. 덕분에 2인 팀도 직접 읽을 수 없는 16개 언어에서 측정 가능한 품질 신호를 확보할 수 있었고, 사람의 사후 편집은 마지막 간극을 메우는 데만 집중하면 됐습니다.

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

Scribe의 두 공동 창업자는 기술적 역량이 있어 사내에서 로컬라이제이션을 직접 구축할 수도 있었습니다. 하지만 이들은 초기 개발보다 유지보수까지 감안해 플랫폼을 선택했습니다. 직접 사내 구축을 경험해 본 한 투자자이자 CTO는 이렇게 말했습니다. “우리가 정말 써야 했던 게 바로 이거였어요.” 시간이 갈수록 불어나는 비용은 첫 버전이 아니라, 예외 케이스와 로캘별 규칙을 계속 관리하는 데서 발생합니다.

로컬라이제이션 엔지니어는 실제로 무슨 일을 하나요?

번역 자체보다 구성의 비중이 훨씬 큽니다. Scribe에서 핵심 업무는 번역가나 파일을 관리하는 일이 아니라 엔진(용어집, 브랜드 보이스, 로캘별 지침)을 설정하고 AI 품질 점수에 맞춰 튜닝하는 것이었습니다. 이 역할은 벤더 조율보다 플랫폼 엔지니어링에 더 가깝습니다. 즉, 번역을 만들어 내는 사람을 관리하는 대신 번역을 생성하는 시스템을 설계하고 운영하는 일입니다.

이 솔루션을 검토 중인 동료에게 어떤 말을 해주고 싶나요?

"진출하려는 시장의 언어 하나만 먼저 돌려보세요. 구현해 보고 MCP도 테스트해 보세요. 알아서 제 역할을 해냅니다. 진짜 아하 모먼트는 결국 MCP예요."