[260405] [우아한 기술블로그] 5년 동안 못 푼 배민 다국어 숙제, AI와 함께 한 달 만에 끝내기

메뉴를 주문하려면 가게 이름과 메뉴명을 읽을 수 있어야 한다.

한국어만 제공되는 배민앱에서 외국인이 경험하는 장벽이다.

5년동안 해결되지 않았던 배민 다국어 과제가 어떤 배경과 제약 속에서 반복적으로 중단되었는지,

그리고 AI를 활용해 어떻게 한달만에 구현까지 이어질 수 있었는지를 'AI 기반 구축 TF' 의 TPM과 푸드 담당 서버 개발자 관점에서 다룬다.

 

'AI 기반 구축 TF'는 기술을 통해 실행의 속도를 가속화하고, 제약으로 인해 시도하지 못했던 일들이 지속적으로 실현될 수 있는 환경을 구축하기 위해 신설된 조직이다. (규제 기관이 아닌 'Service Provider'로서, 개발자가 보안, 비용 걱정 없이 AI를 즉시 업무에 활용할 수 있는 기반을 만드는 것을 목표로 한다.

 

[번역이 아니라 시스템 개편의 문제]

다국어 대응을 단순한 번역 작업으로 보면 쉬워 보인다.

하지만 실제로는 전사 수준의 시스템 개편이 뒤따라야 했다.

디자인 시스템 정의부터 DB 아키텍처 개편, 전용 운영 어드민 구축까지를 단순 계산으로도 1년이 넘는 작업량이었다.

 

1. 정의의 벽

단어를 옮기는 것과, 맥락을 담아 옮기는 것은 다른 문제. 배민만의 음식 용어와 브랜드 톤을 담은 번역 기준을 만드는 것 자체가 거대한 과제였다.

 

2. 구축의 벽

다국어 데이터를 처리할 파이프라인, DB 개편, 어드민 시스템, 어느 것 하나 가볍지 않다.

 

3. 운영의 벽

매일 생성되고 수정되는 콘텐츠를 지속적으로 번역하고 유지 보수할 방법이 없었다.

 

2026년, 2가지가 달라졌다.

 

1. FDH(Food Data Hub) 시스템

2024 12월, 푸드 서비스의 대용량 데이터를 처리하는 시스템이 오픈됐다. 전국 가게와 메뉴 데이터를 안정적으로 처리할 수 있는 기반이 마련되었다.

 

2. LLM 품질 도약

번역 품질이 기대 이상으로 올라왔고, API 하나로 연동이 가능할 만큼 구현 난이도도 낮아졌다.

수백 명의 번역기와 수년의 시간이 필요했던 작업이, 이제는 기술로 대체될 수 있는 가능성이 생겼다.

 

[LLM 기반 다국어 아키텍처]

핵심 목표: 앱 업데이트 없이 서버 배포만으로

 

구현에서 가장 중요하게 고려한 요소는 '속도' 였다.

 

지난 5년간의 실패를 살펴보면, 일정이 가장 큰 걸림돌이었다.

다국어 과제에 많은 리소스를 투입하기에는 현실적으로 어려웠다.

서버 배포를 신속하게 진행해 핵심 동선에 다국어를 빠르게 적용하고, 이후 점진적으로 품질을 개선해 나가는 전략을 수립했다.

 

이러한 전략을 중심으로 아키텍처를 설계한다.

 

(2개의 파이프라인)

1. 번역 파이프라인(FDH Translation Pipeline)

2. 응답 처리(Backend BFF Handling)

 

 

번역 파이프라인(FDH Translation Pipeline):

가게/메뉴 데이터가 변경되면 이벤트가 발행된다.

FDH Worker가 이 이벤트를 받아 LLM에 번역을 요청하고, 결과를 언어별 메타데이터로 적재한다.

사용자 요청과 무관하게 비동기로 진행된다.

 

응답처리(Backend BFF Handling):

앱에서 요청이 들어오면 Accept-Language 헤더를 분석해 적재된 다국어 데이터를 매핑해서 응답한다.

[Backend 다국어 정적파일]
(ko) global.all.freedelivery=배달팁 무료
(en) global.all.freedelivery=Free delivery
(ja) global.all.freedelivery=送料無料
(zh) global.all.freedelivery=免配送费

[FDH 다국어 데이터]
{
  "menuName": "두바이 쫀득 쿠키",
  "menuNameSource": {
    "en": "Dubai Chewy Cookies",
    "ja": "ドバイのもちもちクッキー",
    "zh": "迪拜软糯曲奇"
  }
}

 

가게/메뉴처럼 동적으로 변하는 콘텐츠는 LLM 번역 파이프라인으로, 장바구니 담기처럼 서버에 하드코딩된 UI 문구는 i18n(internationalization, 다국어 처리) 정적 파일로 따로 관리했다.

 

(LLM과의 협상)

LLM을 프로덕션 수준으로 연동하는 과정은 많은 조율 필요

-사례 소개

1. 개행문자 문제: 번역 결과에 \n이 그대로 도출되는 문제가 있었다. 프롬프트에 한줄을 추가해서 해결

"문자열 내에 개행문자는 \n으로 escape 해주세요."

 

2. 단건->다건 처리: 한 건씩 요청하면 비용과 속도 면에서 비효율적이다. 배열로 요청하고, 배열로 받는 구조로 바꿨다.

// 요청
{ "message": "[\"두바이 쫀득 쿠키\", \"아메리카노\", \"장바구니에 담기\"]" }

// 응답
{
  "translations": [
    { "en": "Dubai Chewy Cookie", "ja": "ドバイのもちもちクッキー", "zh": "迪拜软糯曲奇" },
    { "en": "Americano", "ja": "アメリカーノ", "zh": "美式咖啡" },
    { "en": "Add to Cart", "ja": "カートに入れる", "zh": "加入购物车" }
  ]
}

 

3. 응답 필드명 불안정: 가게 주소 텍스트를 번역하면 LLM이 응답 필드명을 address로 바꾸는 일이 생겼다.

-LLM 이 입력 내용을 보고 필드명을 자의적으로 결정. 

-명시적으로 고정함.

"응답 배열의 이름은 translations로 고정해 주세요."

LLM 연동은 원하는 동작을 명확하게 지시하고, 예상치 못한 응답에 대응하며 점진적으로 안정화해나가는 과정이 필요함.

 

4. 정적 파일 표준화

서버에 하드코딩된 UI 문구는 i18n 방식으로 별도 관리했다. 주문 메인 플로우만 해도 1600개가 넘었다.

힘든 것은 배포주기! -파일을 정리해두면 다음 배포에 항목이 추가되거나 삭제됐다.

(ex. 1600개를 다 번역했는데 한 줄이 틀려 있으면 처음부터 다시 확인해야 했다.)

 

구조는 두 레이어로 나눴다.

• [global]: 전사 공통 용어, 중앙 관리
  • global.stod=알뜰배달->영어 파일에서 global.stod=Saver Delivery
• [local]: 지면/서버별 독립 문구, 개별 관리
  • local.detail.stod.info=알뜰배달은...

 

[무엇이 성공 포인트?]

#기술만으로는 부족했다.

LLM이 없었다면 불가능, 그렇다고 LLM이 있다고 해서 저절로 되는 것도 아님.

5년동안 완성하지 못한 이유는, 기술을 빠르게 실험하고 실행하는 구조가 없었기 때문

 

이번에 달랐던 것은 2가지가 동시에 갖춰졌음

 

1. 조직이 일하는 방식의 변화

PoC 결과 하나로 전사 목표가 바뀜.

역번역 데이터를 공유하자, 20분 안에 의사결정이 내려짐.

문서 없이 시작했고, 문서 없이 끝냈다. 

요구사항이 명확했기 때문이다.

 

2. 기술의 도약

FDH 시스템이 이 모든 것의 물리적 토대였다.

대용량 파이프라인 없이는 시도 자체가 불가능했다.

 

여기에 LLM이 더해졌다. 

단건 번역은 물론, 다건 배치 처리로 수백만 개 데이터를 빠르게 처리했다.

Java/Spring 서버 개발자가 익숙한 환경에서 LLM을 직접 연동해 대용량 번역 파이프라인을 만든 것, 그 자체가 새로운 가능성을 열었다.

 

(결론)

빠른 실행만 있고 기술이 없었다면, 100GB가 넘는 번역 데이터의 물리적 한계를 뛰어넘지 못했을 것이다.

기술은 있지만 빠른 실행 구조가 없었다면, LLM은 다른 검토 항목으로만 남았을 것이다.

조직이 일하는 방식(빠른 실험/실행/의사결정)과 기술(FDH+LLM)이 맞물렸을 때, 해결될 수 있었다.

 

1. 공감은 설득이 아니라 실행 결과로 만든다.

2. 핵심을 뽑아서 가볍게 가라.

3. LLM은 단순한 챗봇이 아니다.-인간의 시간으로 불가능한 영역을 기술로 해결하는 생산성 도구다. (그리고 그 가능성은 아직 충분히 탐색되지 않았다.)