데이터 파이프라인을 만드는 일보다 머지 충돌을 해결하는 시간이 더 길어지는 순간이 온다. 배민을 만드는 우아한형제들 데이터 엔지니어링 팀이 정확히 그 지점에서 플랫폼 전체를 뜯어고치기로 했다.
EMR에서 EKS로 — 왜 갈아탔나
우아한형제들은 원래 Amazon EMR on EC2 기반의 데이터 플랫폼을 운영했다. Spark 잡을 돌리고 Airflow로 파이프라인을 오케스트레이션하는, 한국 테크 기업이라면 익숙한 구성. 문제는 규모가 커지면서 나타났다.
EMR on EC2의 스케일링은 느리고, YARN 기반 리소스 관리는 워크로드 간 격리가 허술하다. 데이터 엔지니어 A의 무거운 Spark 잡이 엔지니어 B의 가벼운 ETL까지 느려지게 만드는 상황이 반복된다. 거기에 Airflow를 단일 인스턴스로 공유하니, DAG 파일 하나 수정하려고 PR 올릴 때마다 충돌이 터진다. 패키지 의존성 충돌은 덤이다.
이걸 해결하려고 선택한 게 Amazon EKS 위에 데이터 스택 전체를 올리는 방식, 이른바 "Data on EKS"다. Spark는 EMR on EKS로 전환해 YARN 대신 쿠버네티스 네이티브 스케줄러(Apache Yunikorn)를 쓰고, Airflow·Trino·Ranger 같은 주변 도구도 전부 EKS 클러스터 안으로 들어갔다.
클라우드 네이티브 진영에서는 "당연한 수순"이라고 할 수 있지만, 한국 대형 서비스 중 데이터 플랫폼까지 통째로 EKS에 올린 사례는 아직 많지 않다. 대부분 서비스 백엔드는 K8s에 올려도 데이터 파이프라인만큼은 EMR이나 Dataproc을 그대로 쓴다. 배민은 그 관성을 깼다.
"내 브랜치에 내 Airflow"
가장 눈에 띄는 변화는 개발자별 Airflow 환경이다. 각 엔지니어의 개발 브랜치에 연동된 독립 Airflow 인스턴스가 뜬다. 머지 충돌? 사라졌다. 패키지 충돌? 각자 컨테이너에서 해결한다.
얼핏 리소스 낭비 같지만 EKS 환경에서는 파드가 필요할 때만 올라가고, 안 쓰면 내려간다. Karpenter 같은 노드 오토스케일러와 결합하면 비용 효율도 나쁘지 않다는 계산이다.
메달리온 아키텍처, 배달 데이터에 맞는가
우아한형제들은 이 플랫폼 위에 메달리온 아키텍처(Bronze → Silver → Gold)를 적용했다. Databricks가 제안한 이 패턴은 원래 레이크하우스 환경에서 데이터 품질을 단계적으로 올리는 구조다.
Bronze 레이어에는 주문, 결제, 배달 추적 같은 원시 이벤트가 쌓인다. 배민 규모면 하루 수천만 건이다. Silver에서 중복 제거, 스키마 정규화, 늦게 도착하는 이벤트(late-arriving events) 처리를 거친다. Gold는 사업부별 집계 테이블 — 지역별 배달 소요 시간, 카테고리별 주문 패턴 같은 것들이 여기서 나온다.
여기서 흥미로운 건 배달 도메인 특유의 문제다. 음식 배달은 상태 전이가 빠르다. 주문 접수 → 조리 시작 → 픽업 → 배달 중 → 완료. 각 이벤트가 순서대로 도착한다는 보장이 없고, 라이더 앱의 네트워크 상태에 따라 뒤집히기도 한다. Bronze에서 Silver로 넘어갈 때 이런 비순차 이벤트를 어떻게 정합하느냐가 일반적인 커머스 데이터보다 까다롭다.
메달리온 패턴이 이런 실시간성 높은 도메인에 최적인지에 대해서는 의견이 갈릴 수 있다. 순수한 스트리밍 아키텍처(Kafka + Flink)가 더 적합한 구간도 분명 있다. 배민이 메달리온을 택한 건 분석 워크로드에 대한 일관된 인터페이스를 먼저 확보하겠다는 판단으로 읽힌다. 실시간 처리는 별도 스트리밍 파이프가 담당하고, 메달리온은 배치 기반 진실의 원천(source of truth) 역할에 집중하는 식이다.
IDC의 GPU, 클라우드의 유연성 — 하이브리드라는 현실
한 가지 더. 우아한형제들은 EKS Anywhere를 활용해 자체 IDC의 GPU 서버에도 동일한 쿠버네티스 워크로드를 배포한다. 자율주행 배달 로봇 '딜리'의 ML 모델 학습이나 추천 모델 파인튜닝처럼 GPU 집약적인 작업은 IDC에서 돌리고, 나머지는 클라우드에서 처리하는 하이브리드 구조다.
클라우드 올인을 외치는 시대에 IDC를 남겨두는 게 구식처럼 보일 수도 있다. 하지만 GPU 인스턴스 비용을 감안하면 이미 보유한 하드웨어를 활용하는 쪽이 현실적이다. 특히 한국처럼 데이터센터가 물리적으로 가까운 환경에서는 레이턴시 페널티도 크지 않다.
데이터 민주화라는 말은 안 쓰겠지만
결국 이 전환의 핵심은 데이터 엔지니어의 생산성이다. 파이프라인 하나 만들겠다고 인프라 팀에 티켓 걸고, 머지 큐 기다리고, 패키지 버전 맞추느라 하루가 가던 구조가 "내 Airflow에서 내 코드 돌리고, 검증되면 메인에 머지"로 바뀌었다.
데이터 팀의 자율성을 높이면서 거버넌스는 Ranger로, 비용은 Karpenter와 스팟 인스턴스로 통제한다. 말은 쉽지만 운영 복잡도는 올라간다. 쿠버네티스 위에 데이터 플랫폼까지 얹으면 장애 표면(failure surface)이 넓어지기 때문이다. 그럼에도 배민이 이 방향을 택한 건, 50명 넘는 데이터 조직이 하나의 Airflow에서 삽질하는 비용이 쿠버네티스 운영 비용을 넘어섰기 때문일 것이다.
한국 테크 기업의 데이터 플랫폼이 "매니지드 서비스 조합"에서 "쿠버네티스 네이티브 통합"으로 옮겨가는 흐름, 배민이 그 앞줄에 서 있다.