로컬라이제이션 API

2010년 이전에는 온라인에서 결제를 받으려면 은행에 판매자 계정을 신청해야 했습니다. 몇 주씩 걸리는 서류 작업, 신용 조회, 최소 거래 요건이 따라붙었죠. 그다음에는 운영 환경과는 거의 딴판인 테스트 환경을 가진 XML API로 결제 게이트웨이를 연동해야 했습니다. PCI 규정 준수도 직접 책임져야 했습니다. 카드 번호를 저장하고, 암호화 키를 관리하고, 보안 감사를 통과해야 했죠.

오늘날 개발자는 체크아웃 페이지에 코드 몇 줄만 넣으면 됩니다. 규정 준수, 사기 탐지, 통화 변환, 정산은 모두 API 뒤에서 처리됩니다. 개발자는 그 복잡성을 직접 마주하지 않습니다. 복잡성이 사라진 건 아닙니다. 그저 캡슐화됐을 뿐입니다.

이런 일은 계속 반복됩니다. 예전에는 전문가, 벤더, 그리고 몇 달에 걸친 조율이 필요했던 전문 업무 한 분야가 API 호출 하나로 압축됩니다. 호출은 단순하지만, 그 뒤에서 돌아가는 일은 단순하지 않습니다.

API 이전의 전문 로컬라이제이션#

제품을 여러 언어로 로컬라이즈하려면 번역 벤더를 써야 했습니다. 벤더는 번역가를 배정했지만, 이들은 제품이나 도메인, 기존 용어에 익숙하지 않은 경우가 많았습니다. 용어 가이드를 보내면 번역가는 대체로 읽긴 했습니다. 번역은 영업일 기준 5~10일 뒤 돌아왔습니다. 그런데 용어 세 개가 틀려 있었습니다. 수정 요청을 보내면 다시 3일이 걸렸습니다.

그 사이 누군가는 용어집을 관리하고, 지난 배치 이후 어떤 문자열이 바뀌었는지 추적하고, 독일어 번역에 올바른 따옴표가 쓰였는지 확인하고, 포르투갈어 결과물이 브라질식이 아니라 유럽식 철자를 따르는지 검증해야 했습니다. 이런 조율은 스프레드시트, 이메일, Slack 스레드 곳곳에서 이뤄졌습니다.

LLM으로 자동화를 시도한 팀도 있었습니다. 번역 자체는 빨랐지만 품질 보증은 그렇지 않았습니다. 모든 요청이 매번 처음부터 다시 시작됐습니다. 승인된 용어에 대한 기억도 없고, 브랜드 보이스에 대한 이해도 없고, 결과물이 해당 도메인의 용어 관례와 맞는지 검증하는 과정도 없었습니다.

그러다 LLM이 프로덕션 번역에 쓸 수 있는 품질 임계점을 넘어섰습니다. 언어를 더 잘하게 됐기 때문이 아닙니다. 추론 시점에 도메인 컨텍스트를 주입해 일관되고 용어 정확도가 높은 결과를 낼 수 있게 됐기 때문입니다. 빠져 있던 마지막 퍼즐은 모델을 둘러싼 컨텍스트 파이프라인이었습니다.

API 뒤에서 작동하는 전문 로컬라이제이션#

POST 한 번이면 됩니다. 각 언어가 완료되는 즉시 결과가 webhook으로 도착합니다.

curl -X POST https://api.lingo.dev/jobs/localization \
  -H "X-API-Key: $LINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sourceLocale": "en",
    "targetLocales": ["de", "fr", "ja", "ko", "pt-BR",
      "es", "it", "zh-Hans", "nl", "sv", "pl", "tr", "ar", "th"],
    "data": {
      "title": "Introduction to Machine Learning",
      "steps": [
        { "heading": "What is ML?", "body": "Machine learning is a subset of artificial intelligence." },
        { "heading": "Supervised Learning", "body": "Training a model with labeled data." }
      ]
    },
    "callbackUrl": "https://your-app.com/webhooks/translations"
  }'

수 밀리초 안에 202가 반환됩니다. 호출자는 다음 작업을 계속 진행하면 됩니다. 각 언어는 로컬라이제이션 엔진을 통해 독립적으로 처리됩니다. 독일어는 4초, 일본어는 6초, 아랍어는 8초 만에 도착합니다. 각 결과는 준비되는 순간 바로 webhook으로 전달됩니다. UI에서 실시간 진행 상황을 보여주고 싶다면 작업 그룹에 WebSocket을 연결하세요. 그러면 "16개 언어 중 3개 준비 완료" 같은 상태가 실시간으로 갱신됩니다.

개발자는 그 복잡성을 직접 관리하지 않습니다. 복잡성이 사라진 건 아닙니다. 결제와 마찬가지로 캡슐화됐을 뿐입니다.

API 뒤에서 실제로 실행되는 것들#

로컬라이제이션 작업이 시작되면 플랫폼은 엔진 구성에 따라 다단계 파이프라인을 실행합니다. 총 여섯 단계이며, 각 단계는 생략했을 때 드러나는 특정 실패 유형을 해결합니다.

각 단계는 엔진별로 설정할 수 있습니다. 소스 개선, 사람 후편집, AI 후편집, 역번역은 각각 독립적으로 켜거나 끌 수 있습니다. 컨텍스트 보강과 LLM 번역은 항상 활성화됩니다. 이것이 엔진의 핵심이기 때문입니다.

마케팅 카피를 로컬라이즈하는 팀이라면 여섯 단계를 모두 켤 수 있습니다. 사내 문서를 로컬라이즈하는 팀이라면 컨텍스트 보강과 LLM 번역만 실행할 수도 있습니다. 어느 쪽이든 API 호출은 같습니다. 파이프라인이 목적에 맞게 조정됩니다.

전달#

결과는 설정해 둔 채널로 도착합니다. 폴링은 필요 없습니다.

Webhooks - 각 언어는 완료되는 즉시 전달됩니다. 4초 만에 끝난 독일어 번역은 6초가 걸리는 일본어를 기다리지 않고 바로 도착합니다. 모든 webhook에는 Standard Webhooks 사양을 따르는 암호학적 서명이 포함됩니다. 전달이 실패하면 최대 5회까지 지수 백오프로 재시도합니다.

WebSocket - 작업 그룹에 연결하면 실시간 진행 상황을 확인할 수 있습니다. 모든 이벤트에는 총 작업 수, 완료된 작업 수, 실패한 작업 수, 언어별 상태를 포함한 전체 상태 스냅샷이 들어 있습니다. 프런트엔드가 로컬 상태를 유지할 필요는 없습니다. 서버가 매 이벤트마다 현재 상태를 그대로 푸시합니다.

장애 격리 - 일본어가 실패하고 독일어가 성공하더라도 독일어 번역은 정상적으로 전달됩니다. 실패한 작업은 오류 메시지와 함께 표시됩니다. 그룹 상태는 partial(으)로 바뀝니다. 실패한 로캘만 포함해 새 요청을 제출하면 재시도할 수 있습니다.

이게 의미하는 것#

규정 준수, 용어 거버넌스, 도메인 적응, 검토, 품질 점수화까지 모두 API 뒤에서 처리됩니다. 개발자는 콘텐츠와 대상 로캘을 보냅니다. 로컬라이제이션 관리자는 엔진을 구성합니다. 플랫폼이 워크플로를 실행합니다.

예전에는 프로젝트 매니저, 벤더와의 관계, 공동 스프레드시트가 있어야 가능했던 조율이 이제는 webhook 전달, 장애 격리, 실시간 진행 스트리밍을 갖춘 내구성 있는 백그라운드 워크플로 안에서 이뤄집니다.

여러 릴리스에 걸친 일관성이 중요하지 않은 일회성 문서 번역만 필요하다면, 이 API는 당신의 요구에 비해 과할 수 있습니다. 엔진의 가치는 시간이 갈수록 누적됩니다. 용어집은 쌓이고, 브랜드 보이스는 더 선명해지며, 품질 점수는 꾸준히 올라갑니다. Lingo.dev는 제품을 지속적으로 출시하는 팀, 즉 매 스프린트마다 같은 콘텐츠가 바뀌고 로캘 전반의 일관성을 타협할 수 없는 제품을 위해 설계되었습니다.

전체 API 레퍼런스 읽기 또는 데모 예약으로 파이프라인이 실제로 어떻게 작동하는지 확인해 보세요.

다음 단계#