Cal.com의 미션은 오픈소스 일정 관리 인프라를 통해 2031년까지 10억 명을 연결하는 것입니다. 이를 위해서는 모든 언어의 사용자를 지원해야 했고, 그 요구는 수년간 엔지니어링 속도를 갉아먹는 요인이었습니다.
문제: 늘 뒤처지는 로컬라이제이션#
Cal.com은 흔히 쓰이는 방식은 모두 시도해 봤습니다. 번역 관리 시스템을 통한 크라우드소싱 번역, 로컬라이제이션 에이전시 활용까지. 하지만 비용과 조율 부담만 커졌을 뿐, 결과는 같았습니다. 우선순위가 가장 높은 언어조차도 늘 최신 상태를 따라가지 못했습니다.
"우리는 국제화에서 늘 뒤처져 있었습니다." 엔지니어링 총괄 Keith Williams는 이렇게 회상합니다. "에이전시에 투자하고 번역 관리 시스템을 통한 크라우드소싱도 해봤지만, 주요 언어들조차 동기화가 맞지 않았습니다. 비용은 많이 들었고, 수작업은 엔지니어들이 기능 개발에 집중하지 못하게 했죠."
이런 패턴은 흔합니다. 기존 로컬라이제이션 플랫폼은 사람 번역가의 워크플로를 관리할 뿐, 조율에 드는 오버헤드를 없애지는 못하고 그저 정리해 줄 뿐입니다. 릴리스 사이클마다 외부 팀으로 넘기고, 다시 기다리고, 또 검토하는 일이 반복됐습니다. 엔지니어링 팀은 하루 만에 기능을 출시할 수 있었지만, 로컬라이즈하는 데는 2주가 걸리기도 했습니다.
전환점: 인프라가 된 로컬라이제이션#
2025년, Cal.com은 Lingo.dev에 로컬라이제이션 엔진을 배포했습니다. 은 상태를 유지하는 번역 API로, 모든 번역 요청에 걸쳐 Cal.com의 제품 용어, 일정 관리 도메인 어휘, 로캘별 설정을 지속적으로 보존합니다. 엔진이 영어 문자열에서 "Workspace"나 "Booking"을 만나면, 모델이 토큰 하나를 생성하기도 전에 용어집이 로캘별로 올바른 용어를 확정합니다.
Cal.com의 오픈소스 코드베이스와 기여자 커뮤니티 특성상 통합 과정에서 몇 가지 초기 조정이 필요했습니다. Lingo.dev 팀은 그 부분까지 직접 해결했습니다.
"응답 속도가 정말 믿기 어려울 정도였어요." Williams는 말합니다. "조정이 필요할 때마다, 제가 본 어떤 벤더보다도 빠르게 수정 사항을 제공해줬습니다."
결과#
로컬라이제이션 엔진 구성이 끝나자, Cal.com은 이를 CI/CD 파이프라인에 연결했습니다. 이제 코드가 푸시될 때마다 엔진이 실행되고, 36개 언어 전체의 번역이 자동으로 업데이트됩니다.
- 엔지니어링 팀이 더 이상 번역 워크플로를 관리하지 않음
- 36개 언어가 모든 릴리스에서 동기화 상태를 유지함
- 에이전시 비용 대비 로컬라이제이션 비용 대폭 절감
- 인계 과정이 전혀 없음 — 코드 배포와 같은 파이프라인에서 번역이 처리됨
"가장 좋은 점이 뭔지 아세요? 이제 우리 엔지니어들은 로컬라이제이션을 아예 생각하지 않습니다." Keith는 이렇게 설명합니다. "그냥 기능을 만들면 번역이 자동으로 이뤄지죠. 전 세계 누구나 Cal.com을 쓸 수 있게 만들기 위해 우리에게 꼭 필요했던 방식입니다."
다음 단계#
Cal.com은 이제 로컬라이제이션 엔진을 이메일 템플릿까지 확장하고 있습니다. 그곳이 번역이 별도로 처리되던 마지막 영역이기 때문입니다. 이 작업이 완료되면 제품의 모든 사용자 대상 문자열이 동일한 로컬라이제이션 인프라를 통해 흐르게 됩니다.
10억 건의 연결을 향해 나아가는 팀에게는 이런 누적 효과가 중요합니다. 오늘 설정한 모든 용어집 항목이 앞으로 추가될 새 기능, 새 릴리스, 새 로캘 전반에서 일관되게 정확성을 보장하기 때문입니다.
