3 hours ago
1
들어가며
한국을 찾는 외국인이 연간 약 2천만 명을 넘어선 지금, 배민 앱은 이들을 위해 준비되어 있었을까?
메뉴를 주문하려면 우선 가게 이름과 메뉴명을 읽을 수 있어야 합니다. 하지만 한국어만 제공되는 배민 앱에서 외국인이 경험하는 첫 번째 장벽이 바로 여기 있었습니다. 배민은 이 문제를 알고 있었고, 5년 전부터 해결하려 해왔습니다. 그리고 매년 멈췄습니다.
2026년 1월, 우리는 다시 시작했고 이번엔 달랐습니다.
이 글에서는 5년 동안 해결되지 않았던 배민 다국어 과제가 어떤 배경과 제약 속에서 반복적으로 중단되었는지, 그리고 AI를 활용해 어떻게 한 달 만에 구현까지 이어질 수 있었는지를 ‘AI 기반 구축TF’의 TPM과 푸드 담당 서버 개발자 관점에서 다룹니다.
- ‘AI 기반 구축 TF’는 기술을 통해 실행의 속도를 가속화하고, 제약으로 인해 시도하지 못했던 일들이 지속적으로 실현될 수 있는 환경을 구축하기 위해 신설된 조직이다. 규제 기관이 아닌 ‘Service Provider’로서, 개발자가 보안, 비용 걱정 없이 AI를 즉시 업무에 활용할 수 있는 기반을 만드는 것을 목표로 합니다.
시간 흐름에 따른 실제 상황을 생생하게 전하고자 이후 본문에서는 저자 어조를 그대로 살렸습니다.
5년의 역사: 시도와 포기 사이
매년 올라왔다가 사라진 과제
배민 다국어 프로젝트의 첫 기록은 2021년이다. 이후 매년 시도가 있었다.
2021년엔 다국어 앱 스펙을 정의했다.
2022년엔 시스템 연동을 시도했다.
2023년엔 전시 영역 작업 범위를 전수 검토했고, 2024년엔 다국어 사전 어드민 구축 프로젝트로 이어졌다.
2025년에도 타당성 분석이 진행됐다.
5년간 멈추지 않고 시도했다. 그리고 5년간 완성하지 못했다.
의지의 문제가 아니었다. 구조의 문제였다.
번역이 아니라 시스템 개편의 문제였다
다국어 대응을 단순한 번역 작업으로 보면 쉬워 보인다.
하지만 실제로는 전사 수준의 시스템 개편이 뒤따라야 했다.
디자인 시스템 정의부터 DB 아키텍처 개편, 전용 운영 어드민 구축까지.
단순 계산으로도 1년이 넘는 작업량이었다.
여기에 운영 문제가 더해졌다. 배민에는 전국에 걸쳐 가게가 수십만 개가, 그 안의 메뉴만 대략 수천만 개가 넘는다. 이걸 세 개 언어로 번역해도, 다음 날 메뉴가 바뀌면 다시 번역해야 한다. 인력 기반 운영으로는 구조적으로 따라잡을 수 없었다.
결국 세 가지 벽에 막혀 있었다.
첫째는 정의의 벽이다.
‘두바이 쫀득 쿠키’를 어떻게 번역할 것인가. 단어를 옮기는 것과, 맥락을 담아 옮기는 것은 다른 문제다. 배민만의 음식 용어와 브랜드 톤을 담은 번역 기준을 만드는 것 자체가 거대한 과제였다.
둘째는 구축의 벽이다.
다국어 데이터를 처리할 파이프라인, DB 개편, 어드민 시스템. 어느 것 하나 가볍지 않았다.
셋째는 운영의 벽이다.
매일 생성되고 수정되는 콘텐츠를 지속적으로 번역하고 유지 보수할 방법이 없었다.
그리고 2026년, 두 가지가 달라졌다
2026년 초, 이전과 달라진 조건이 두 가지 생겼다.
하나는 FDH(Food Data Hub) 시스템이다.
2024년 12월, 푸드 서비스의 대용량 데이터를 처리하는 이 시스템이 오픈됐다. 전국 가게와 메뉴 데이터를 안정적으로 처리할 수 있는 기반이 처음으로 갖춰진 것이다. FDH가 없었다면 이번 시도 자체가 불가능했다.
다른 하나는 LLM의 품질 도약이다.
번역 품질이 기대 이상으로 올라왔고, API 하나로 연동이 가능할 만큼 구현 난이도도 낮아졌다. 수백 명의 번역가와 수년의 시간이 필요했던 작업이, 이제는 기술로 대체될 수 있는 가능성이 생겼다.
조건은 갖춰졌다. 이제 남은 건 실행뿐이었다.
D-day: 1월 15일, 하루에 벌어진 일
1월 14일 (D-1) — 또 시작된 ‘그 채널’
1월 14일, 슬랙에 ‘다국어 대응 프로젝트’ 채널이 열렸다. 공지 문구에는 "5년 된 백로그인데, 이번엔 꼭 오픈하고 싶어요"라고 적혀 있었다.
솔직히, 이번이 다를 거라고 크게 기대하지 않았다. 매년 같은 채널이 만들어지고, 매년 같은 결론이 났으니, 우리도 그렇게 생각했다. 연례행사처럼 느껴졌고, 크게 동요하지 않았다.
1월 15일 (D-day) 16:56 — 세상에서 가장 무서운 DM
다음 날 오후 4시 56분, DM이 왔다.
"진호 님 잠깐 허들 되세요~?"
회사 생활을 해본 사람이라면 안다. ‘잠깐’은 절대 잠깐이 아니다.
9분간의 통화가 이어졌다.
내용은 세 단어였다. “다국어 / LLM / 빠르게”
AI 기반 구축 TF에서 미리 만들어둔 Spring AI Bedrock 연동 템플릿이 있으니, 이걸로 바로 구현해 보자는 것이었다.
1월 15일 (D-day) 17:22 — 17분 만에 API 키 도착
통화 종료 17분 후, AWS Bedrock 인증 키가 도착했다. 한집배달보다는 살짝 느렸지만 충분히 빠른 속도였다.
1월 15일 (D-day) 17:31 — 로컬 첫 접속
LLM에 처음 접속하는 데 성공했다.
curl -X POST http://localhost:8080/api/chat \ -H "Content-Type: application/json" \ -d '{"message": "안녕하세요"}' {"response":"안녕하세요! 무엇을 도와드릴까요?"}1월 15일 (D-day) (D+1) 17:44 — 두바이 쫀득 쿠키
당시 한창 유행이었던 ‘두바이 쫀득 쿠키’로 첫 번역을 돌렸다.
{ "systemPrompt": "당신은 음식 배달 앱에서 가게, 메뉴 정보 번역을 담당하는 영어, 일본어, 중국어 번역가입니다. 응답 포맷은 json 형태로 en, ja, zh 필드로 구성되며, 각각 하나의 문자열로 작성해 주세요. ", "message": "두바이 쫀득 쿠키" }응답이 돌아왔다.
{ "en": "Dubai Chewy Cookies", "ja": "ドバイのもちもちクッキー", "zh": "迪拜软糯曲奇" }번역 품질이 기대 이상이었다. 처음으로 어쩌면 가능하겠다는 생각이 들었다.
1월 15일 (D-day)) 22:00 — 베타 환경 PoC 완료
저녁을 먹고 지하철에서 구조를 구상했다. 아이디어는 단순했다. 가게/메뉴 변경 이벤트가 오면 LLM으로 변환해서 원본을 바꿔치기하는 방식. 집에 돌아와 코드를 작성했고, 밤 10시가 넘어 베타 환경에서 PoC(Proof of Concept, 개념 증명)를 완료했다.
다음 날 채널에 공유했다. 반응이 왔다.
"프로젝트 시작한 게 이틀 전인데… 속도가…"
그리고 예상치 못한 말도 들렸다. "왜 이렇게 빨리 됐는데, 왜 이제야 한 거야?"
PoC 결과 하나가 조직을 움직였다. 그렇다면 실제 구현은 어떤 구조였을까?
기술 들여다보기: LLM 기반 다국어 아키텍처
핵심 목표: 앱 업데이트 없이 서버 배포만으로
이번 구현에서 가장 중요하게 고려한 요소는 ‘속도’였다.
지난 5년간의 실패를 되돌아보면, 일정이 가장 큰 걸림돌로 작용했다. 다국어 과제에 많은 리소스를 투입하기는 현실적으로 어려웠다. 서버 배포를 신속하게 진행해 주문 핵심 동선에 다국어를 빠르게 적용하고, 이후 점진적으로 품질을 개선해 나가는 전략을 수립했다.
이 전략을 중심으로 아키텍처를 설계했다.
두 개의 파이프라인
전체 구조는 크게 ‘번역 파이프라인(FDH Translation Pipeline)’과 ‘응답 처리(Backend BFF Handling)’, 두 흐름으로 나뉜다.
다국어 처리 플로우(출처: NotebookLM으로 생성)번역 파이프라인(FDH Translation Pipeline)
가게/메뉴 데이터가 변경되면 이벤트가 발행된다. FDH Worker가 이 이벤트를 받아 LLM에 번역을 요청하고, 결과를 언어별 메타데이터로 적재한다. 이 과정은 사용자 요청과 무관하게 비동기로 진행된다.
응답 처리(Backend BFF Handling)
앱에서 요청이 들어오면 Accept-Language 헤더를 분석해 적재된 다국어 데이터를 매핑해서 응답한다.
가게/메뉴처럼 동적으로 변하는 콘텐츠는 LLM 번역 파이프라인으로, ‘장바구니에 담기’처럼 서버에 하드코딩된 UI 문구는 i18n(internationalization, 다국어 처리) 정적 파일로 따로 관리했다.
LLM과의 협상
LLM을 프로덕션 수준으로 연동하는 과정은 예상보다 많은 조율이 필요했다. 몇 가지 대표적인 사례를 소개한다.
개행문자 문제
번역 결과에 \n이 그대로 노출되는 문제가 있었다. 프롬프트에 한 줄을 추가해서 해결했다.
"문자열 내에 개행문자는 \n으로 escape 해주세요."
단건 → 다건 처리
한 건씩 요청하면 비용과 속도 면에서 비효율적이다. 배열로 요청하고 배열로 받는 구조로 바꿨다.
응답 필드명 불안정
가게 주소 텍스트를 번역하면 LLM이 응답 필드명을 address로 바꾸는 일이 생겼다. LLM이 입력 내용을 보고 필드명을 자의적으로 결정한 것이다. 명시적으로 고정했다.
"응답 배열의 이름은 translations로 고정해 주세요."
LLM 연동은 API 하나 호출하는 것으로 끝나지 않는다. 원하는 동작을 명확하게 지시하고, 예상치 못한 응답에 대응하며 점진적으로 안정화해나가는 과정이 필요하다.
정적 파일 표준화: 1,600개의 싸움
서버에 하드코딩된 UI 문구는 i18n 방식으로 별도 관리했다. 주문 메인 플로우만 해도 1,600개가 넘었다.
더 힘든 건 배포 주기였다. 파일을 정리해두면 다음 배포에 항목이 추가되거나 삭제됐다. 1,600개를 다 번역했는데 한 줄이 틀려 있으면 처음부터 다시 확인해야 했다. 오탈자 하나가 전체 검수를 되돌리는 작업이었다.
구조는 두 레이어로 나눴다.
-
[global]: 전사 공통 용어, 중앙 관리
global.stod=알뜰배달 → 영어 파일에서 global.stod=Saver Delivery -
[local]: 지면/서버별 독립 문구, 개별 관리
local.detail.stod.info=알뜰배달은…
계획대로 흘러가지 않았다
PoC까지는 빨랐다. 그 이후부터가 진짜였다. 목표일은 2월 3일, 설 연휴 직전이었다.
D+6 (1월 21일) — 범위를 정하다
1월 21일, 채널에 1차 작업 범위를 공유했다. 선택의 기준은 하나였다.
"이게 없으면 오픈 자체가 불가능한 것"을 먼저 하자.
가게/메뉴 콘텐츠 번역이 0순위였다. 메인 화면이 번역 안 돼도 아이콘을 보고 들어갈 수 있다. 하지만 들어간 가게의 메뉴를 읽을 수 없으면 주문이 불가능하다. 범위를 서버 배포 중심으로 좁히고, 기능 플래그를 활용해 임직원 대상 사내 오픈을 먼저 목표로 잡았다.
왜 굳이 설 연휴 전을 목표로 했냐고 묻는다면, 이유는 단순하다.
2월을 넘기면 다른 과제들이 밀려온다. 그 순간 다국어는 또다시 백로그로 돌아간다.
D+12 (1월 27일) — 청천벽력
전체 오픈이 불가능하다는 분석이 나왔을 때, 2월 3일까지 7일이 남아 있었다. 기술적인 이유였다. 앱 언어 설정은 OS를 따라가기 때문에 임직원 전용으로 제어하는 것이 구조적으로 불가능했다.
결론은 하나였다. 다국어 버전 전체 오픈.
기능 플래그를 쓸 수 없으니, 수십만 개 가게의 마이그레이션을 오픈 전에 전부 완료해야 했다.
계획을 바꿀 수는 없었다. 남은 시간 안에 해야 했다.
D+12 (1월 27일) 밤 11시 — 20분 만의 결정
같은 날, 중국어/일본어 추가 적용 여부 논의가 시작됐다. 영어는 사내에서 검수가 가능했지만, 중국어/일본어는 아니었다. 외부 업체를 섭외하거나, LLM 역번역으로 품질을 검증해야 했다.
당장 해볼 수 있는 역번역 테스트를 진행했다. 번역된 중국어를 다시 한국어로 돌렸을 때 의미가 대부분 보존됐다.
그 결과를 공유하자, 20분 만에 승인이 났다.
배민 입사 이래 처음 겪어본 속도의 의사결정이었다.
그 시각, 밤 11시였다.
D+15 (1월 30일) — 모델 변경과 지옥의 시작
오픈 4일 전, 마이그레이션 비용을 계산해 보니, 당초 사용하던 Claude Haiku 모델로는 감당하기 어려웠다. 기능과 가격을 함께 검토한 끝에, 이번 용도에 더 합리적인 Amazon Nova 2 Lite로 교체하기로 했다. 하지만 모델을 바꾸니 처음부터 다시 시작하는 느낌이었다.
프롬프트 재조정, 배치 처리 인프라 구성, 대용량 안정화. LLM은 예측이 불가능하다.
빠르게 시도하고 빠르게 확인하는 것 외에 방법이 없다는 걸, 이때 몸으로 배웠다.
D+19 (2월 3일) 새벽 — 뒤가 없었다
사실 데드라인이 하나 더 있었다. 오픈 다음 날 언론 기사가 예정되어 있었다. 일정이 공개된 이상 물러설 수 없었다.
2월 2일 밤, 채널에 메시지를 남겼다.
"아침 9시까지 가능합니다."
새벽까지 배치를 돌렸다. 아침 일찍 출근한 청소하시는 분과 하이파이브를 하고 퇴근했다.
1월 14일 킥오프부터 2월 3일 대고객 오픈까지, 19일이 걸렸다.
이제 외국인도 영어/일본어/중국어 세 언어로, 배민 앱으로 두바이 쫀득 쿠키를 주문할 수 있게 됐다.
오픈 후, 팀원들의 소감이 채널에 올라왔다.
"다국어는 두 번은 못할 것 같다(입대를 두 번 할 순 없음)", "기도를 제일 많이 했던 프로젝트"라는 말들이 이어졌다.
프로젝트가 얼마나 빠르고 치열하게 돌아갔는지를 가장 잘 보여주는 표현들이었다.
그리고 한 가지 공통된 반응도 있었다.
이런 방식으로 일해본 게 처음이었다는 것.
배민앱 다국어 적용 버전무엇이 이것을 가능하게 했는가
기술만으로는 부족했다
LLM이 없었다면 이번 도전은 불가능했다. 하지만 LLM이 있다고 해서 저절로 되는 것도 아니었다.
이전에도 기술은 있었다. 매년 새로운 접근이 시도됐다. 그런데도 5년 동안 완성하지 못한 이유는, 기술을 빠르게 실험하고 실행하는 구조가 없었기 때문이다.
이번이 달랐던 건 두 가지가 동시에 갖춰졌기 때문이다.
1. 조직이 일하는 방식의 변화
이번 프로젝트에서 목격한 장면들이 있다.
PoC 결과 하나로 전사 목표가 바뀌었다.
밤 11시에 역번역 데이터를 공유하자 20분 안에 의사결정이 내려졌다. 문서 없이 시작했고, 문서 없이 끝냈다. 요구사항이 명확했기 때문이다.
2. 기술의 도약
FDH 시스템이 이 모든 것의 물리적 토대였다. 수십만 개 가게, 수천만 개 메뉴를 처리할 수 있는 대용량 파이프라인 없이는 시도 자체가 불가능했다.
여기에 LLM이 더해졌다. 단건 번역은 물론, 다건 배치 처리로 수백만 개 데이터를 빠르게 처리했다. Java/Spring 서버 개발자가 익숙한 환경에서 LLM을 직접 연동해 대용량 번역 파이프라인을 만든 것, 그 자체가 새로운 가능성을 열었다.
두 가지가 만났을 때
빠른 실행만 있고 기술이 없었다면, 100GB가 넘는 번역 데이터의 물리적 한계를 넘지 못했을 것이다. 기술은 있지만 빠른 실행 구조가 없었다면, LLM은 또 다른 검토 항목으로만 남았을 것이다.
조직이 일하는 방식(빠른 실험/실행/의사결정)과 기술(FDH + LLM)이 맞물렸을 때, 5년 된 백로그가 한 달 만에 풀렸다.
이번 프로젝트에서 얻은 것을 정리하자면 세 가지다.
첫째, 공감은 설득이 아니라 실행 결과로 만든다.
"왜 이렇게 빨리 됐는데 왜 안 했냐"라는 반응은 기획서가 아니라 돌아가는 PoC를 봤을 때 나왔다.
둘째, 핵심만 뽑아서 가볍게 가라.
1년이 넘는 과제를 한 달 만에 끝낼 수 있었던 건, 전부 다 하지 않았기 때문이다. "이게 없으면 오픈 자체가 안 된다."는 것만 먼저 했다.
셋째, LLM은 단순한 챗봇이 아니다.
인간의 시간으로 불가능한 영역을 기술로 해결하는 생산성 도구다. 그리고 그 가능성은 아직 충분히 탐색되지 않았다.
마치며: 기술 혁신의 진짜 트리거
5년간 합리적으로 포기해왔던 과제가 달라진 건, 의지가 더 강해져서가 아니었다.
기술이 바뀌었고, 그 기술을 즉시 실험하고 실행하는 구조가 함께 갖춰졌기 때문이다.
우아한형제들은 이 시기에 일하는 방식 자체를 바꾸고 있었다. AI 기반 구축 TF를 신설해 개발자가 LLM을 즉시 실험할 수 있는 환경을 만들었고, 실험 결과가 나오면 밤 11시에도 20분 안에 의사결정이 내려졌다. 완벽한 기획서 없이 PoC 결과로 방향을 잡았고, 실행하면서 다음 플랜을 세웠다.
이것이 이번 프로젝트의 진짜 트리거였다.
기술(LLM)과 조직력(빠른 실험과 의사결정 문화)이 동시에 준비되어 있었기 때문에 가능했다. 어느 한쪽만으로는 5년 전과 결과가 달라지지 않았을 것이다.
기술은 준비됐다.
이제 남은 건 그 기술을 실험하고 실행하는 구조를 만드는 일이다. 우리는 이미 한 번, 그 답을 알고 있다.
우아한형제들 TPM 우아한형제들 서버 개발자
AI 기반 구축 TF에서 TPM으로 일하고 있습니다. 오래 풀리지 않던 문제에서 새로운 가능성을 찾는 일을 좋아합니다.
배달의민족 푸드 서비스를 개발하고 있습니다. 이번 프로젝트를 통해 LLM이 단순한 챗봇이 아니라는 걸 몸으로 배웠습니다.
English (US) · 