현지화는 과거에 머물러 있었습니다. 우리는 이를 발전시키기 위해 Glossia를 만들었습니다.

소프트웨어를 두 개 이상의 언어로 출시해 본 적이 있다면 이 과정을 잘 아실 것입니다. 현지화 플랫폼을 선택하고 저장소에 연결한 다음, 나머지 시간은 동기화를 관리하는 데 사용합니다. 콘텐츠를 내보내고 번역을 다시 받아오는 사이, 어딘가에서 문제가 발생합니다.

콘텐츠를 저장소에서 내보냈다가 다시 가져오는 끊임없는 왕복 과정에서 발생하는 운영 부담은 오늘날의 현지화 도구를 사용하는 모든 팀이 치러야 하는 비용입니다. 사소하게 들릴 수 있지만, 금요일 오후 6시에 번역 풀 리퀘스트 때문에 사이트 빌드가 실패한 이유를 직접 디버깅해야 한다면 이야기가 달라집니다.

인터넷 이전 시대에서 물려받은 설계

대부분의 현지화 플랫폼은 현대적인 개발 워크플로보다 앞서 등장한 개념을 기반으로 설계되었습니다. 번역 메모리, 퍼지 매칭, 데이터베이스에서 유사한 문자열을 제안하는 도구의 지원을 받아 독점 편집기에서 작업하는 인간 번역가가 그 예입니다.

번역이 수동 오프라인 프로세스였을 때는 이러한 개념이 합리적이었습니다. 그러나 기업들은 번역 메모리를 종속을 유도하는 수단으로 바꾸었습니다. 비용을 지불해 축적한 과거 번역과 조직의 지식은 해당 플랫폼 안에만 존재합니다. 다른 제공업체로 이전하려면 처음부터 다시 시작하거나, 제대로 작동하지 않는 내보내기 기능에 비용을 지불해야 합니다.

그 결과, 현지화 업계는 인위적인 마찰을 기반으로 운영되고 있습니다. 콘텐츠는 저장소를 떠나 내부를 알 수 없는 시스템으로 들어간 뒤, 다른 업체가 정한 일정에 따라 돌아옵니다.

문제는 구조적입니다. 외부 현지화 도구는 귀사의 지속적 통합 파이프라인을 실행할 수 없습니다. 린터, 빌드 단계, 링크 검사기 또는 프런트매터 스키마를 알지 못합니다. 번역된 콘텐츠를 저장소로 다시 푸시한 뒤 문제가 없기를 바랄 뿐입니다. 문제가 발생하면, 실제로 자주 발생합니다. 팀원 중 누군가는 하던 일을 멈추고 번역 도구가 만든 서식 오류, 잘못된 구문 또는 유효하지 않은 마크업을 수정해야 합니다.

대규모 언어 모델과 에이전트 기반 경험은 이러한 워크플로를 완전히 재구상할 새로운 기회를 제시합니다. 에이전트가 번역을 생성하고, 검사를 실행하고, 오류를 확인한 뒤, 결과가 유효해질 때까지 다시 시도할 수 있습니다. 이처럼 긴밀한 피드백 루프는 모든 것을 바꿉니다.

하지만 이는 콘텐츠가 원래 위치인 저장소에 그대로 있을 때만 작동합니다. 콘텐츠를 외부 플랫폼으로 보내는 순간, 번역은 다른 업체의 일정에 따라 돌아오고 통합은 단절됩니다. 즉시 제공될 수 있었던 피드백이 이제는 몇 시간 또는 며칠이 걸립니다. 유용한 피드백을 가능하게 했던 맥락은 이미 사라집니다. 피드백 루프를 잃고, 그와 함께 에이전트 기반 워크플로가 제공해야 했던 모든 이점도 잃게 됩니다.

Glossia를 구체화한 관찰

이러한 불편만으로 Glossia가 탄생한 것은 아닙니다. 이 프로젝트는 개발과 현지화 양쪽에서 쌓은 깊은 경험을 바탕으로 성장했으며, 한쪽 관점만으로는 파악하기 어려운 문제를 명확하게 드러냈습니다. 언어적 워크플로, 번역 팀의 인간적 역학 관계, 기존 도구가 현재와 같은 형태로 자리 잡은 이유를 이해하는 것이 핵심이었습니다.

우리는 계속해서 같은 결론에 도달했습니다. 현지화 도구는 대규모 언어 모델도, 코딩 에이전트도, 지속적 통합 파이프라인도 없는 시대를 전제로 설계되었습니다. 전체 모델은 번역이 개발 워크플로 외부에서 이루어진 후 다시 개발 과정으로 푸시된다고 가정했습니다. 10년 전에는 합리적이었습니다. 이제는 그렇지 않습니다.

우리는 질문하기 시작했습니다. 현지화 에이전트가 코딩 에이전트와 같은 방식으로 작업할 수 있다면 어떨까요?

우리는 Anthropic이 Claude를 통해 에이전트 기반 워크플로를 구상하는 방식을 면밀히 살펴보고 있습니다. 에이전트가 도구에 접근하고, 작업을 추론하며, 자체 결과물을 검증하고, 문제가 있을 때 반복적으로 개선하도록 하는 패턴은 현지화에도 매우 적합합니다. 번역 에이전트가 소스 파일을 읽고, 프로젝트 맥락을 이해하고, 번역을 생성하고, 린터를 실행하고, 풀 리퀘스트를 열기 전에 문제를 해결할 수 있습니다. 이는 비현실적인 구상이 아닙니다. 바로 우리가 구축하고 있는 워크플로입니다.

Glossia는 소프트웨어 업계에 드리는 우리의 선물입니다

저희가 Glossia를 만든 이유는 더 많은 소프트웨어가 현지화되기를 바라기 때문입니다.

복잡한 절차와 비용이 많이 드는 플랫폼은 소규모 팀, 인디 개발자, 사이드 프로젝트가 현지화에 접근하기 어렵게 만듭니다. 번역 워크플로에 구매 승인 절차, 단어당 가격 협상, 인계 조율을 담당할 프로젝트 관리자가 필요하다면, 대부분의 팀은 결국 영어로만 출시하고 작업을 마칠 것입니다.

Glossia는 이미 접근 권한이 있는 모델을 사용합니다. 또한 Glossia의 도구가 아닌 사용자의 도구로 결과물을 검증합니다.

저희는 현지화가 테스트 스위트를 실행하는 것만큼 자연스러워야 한다고 생각합니다.

에이전트 우선, 인터페이스는 그다음

Glossia의 핵심은 에이전트입니다. 가장 어려운 문제를 가장 먼저 해결할 수 있는 곳이 터미널이기 때문에, 저희는 터미널을 기본 인터페이스로 시작합니다. 에이전트는 소스 파일을 읽고, 번역을 생성하고, 검사를 실행하며, 결과물이 유효해질 때까지 반복합니다. 이는 OpenAI가 Codex를 통해, Anthropic이 Claude Code를 통해 따랐던 것과 같은 방식입니다. 에이전트를 구축하고 터미널을 제공한 다음, 작업을 맡기는 방식입니다.

그러나 터미널은 첫 번째 인터페이스일 뿐, 유일한 인터페이스는 아닙니다. 현지화 품질에 기여하는 모든 사람이 개발자는 아니라는 점을 잘 알고 있습니다. 저희는 이 문제를 내부에서 자주 논의합니다. 번역 정확성, 어조, 문화적 뉘앙스를 가장 중요하게 생각하는 사람들은 브랜치, 컴파일, JSON의 관점으로 사고하지 않는 언어 전문가와 콘텐츠 전문가인 경우가 많습니다.

이것이 바로 저희가 동일한 에이전트를 기반으로 새로운 인터페이스를 구축하려는 이유입니다. 언어 전문가가 콘텐츠, 맥락, 번역을 나란히 확인할 수 있는 인터페이스입니다. 이들은 어떤 모델도 대체할 수 없는 인간의 판단을 더합니다. 다듬어야 할 부분을 다듬습니다. 그리고 에이전트는 커밋, 검증, 풀 리퀘스트 생성 등 나머지 모든 작업을 처리합니다.

아직 모든 해답을 갖고 있지는 않으며, 이는 의도된 것입니다. 핵심을 놓치는 사용자 인터페이스를 서둘러 만드는 것보다 신중하게 구축하고자 합니다. 그러나 방향은 분명합니다. Glossia는 소프트웨어가 모든 언어로 소통하도록 만드는 데 관심이 있는 모든 사람을 포용해야 합니다.

계속 지켜봐 주세요

Glossia는 아직 초기 단계이며, 저희는 개발 과정을 공개하고 있습니다. 이 내용이 현지화에 대한 귀하의 생각과 맞닿아 있다면 프로젝트를 지켜봐 주세요. 진행하면서 더 많은 내용을 공유하겠습니다.