당근 200+개 DB 를 옮기는 ELT 플랫폼, DT Platform 을 만든 이야기

2026년 6월 4일

0. 들어가며

안녕하세요, 당근 데이터 가치화 팀의 Andy예요. 데이터 가치화 팀은 당근의 구성원 누구나 데이터를 쉽게 활용할 수 있도록 데이터 인프라와 플랫폼을 만들고 운영하고 있어요.

그중에서도 오늘 이야기하고 싶은 건 '서비스 DB의 데이터를 분석 환경으로 옮기는 일' 이에요. 별거 아닌 것처럼 들릴 수도 있는데, 당근 규모로 오면 생각보다 훨씬 까다로운 문제가 돼요.

현재 당근은 글로벌 서비스 전반에 걸쳐 200개 이상의 DB로부터 데이터를 사내 Data Warehouse인 BigQuery로 전송하고 있어요. 단순히 숫자만 많은 게 아니라, 리전도 한국 · 일본 · 캐나다로 나뉘어 있고, 각각 alpha와 prod환경으로 나뉘어 있어요. 뿐만 아니라 도메인별로 요구하는 전송 주기나 설정도 제각각이에요.

이런 환경에서 저희 팀은 작년 말까지 꽤 아픈 문제를 안고 있었어요. 그 문제를 어떻게 정의했고, 어떤 대안을 검토했고, 결국 DT (Data Transfer) Platform이라는 사내 ELT 플랫폼을 어떻게 만들었는지, 플랫폼이 런칭된 이후 실제 지표가 어떻게 바뀌었는지, 그리고 AI 시대의 ELT / ETL 파이프라인 관리를 준비할 수 있게 되었는지 공유해볼게요. 당근 서비스 DB ELT 전체 구성

1. 기존 ELT 의 문제점 --- 소스코드와 설정의 강결합

저희가 가진 문제의 근원에는 '**파이프라인의 정의(설정)와 실행 코드가 하나의 레포지토리에 강하게 결합돼 있었다'**는 구조가 있었어요.

모든 ELT 파이프라인은 단일 레포지토리의 코드로 관리되고 있었고, 새로운 테이블을 하나 추가하거나 전송 설정을 조금 바꾸려면 무조건 PR을 올려야 했어요. 그리고 그 PR은 코드베이스를 이해한 사람만 제대로 작성할 수 있었죠.

이 구조가 만들어낸 Pain Point는 2가지였어요.

데이터 가치화 팀 관점

수백 개의 ELT 파이프라인의 현재 상태를 한눈에 파악할 수 있는 방법이 없었어요. "지금 어떤 테이블이 어떤 주기로 싱크되고 있지?", "이 테이블의 파티션 키는 뭐지?", "누가 언제 이 설정을 추가했지?" 같은 질문에 답하려면 Python 코드와 Scala 코드를 직접 읽어야 했어요. 뿐만 아니라 테이블 특성에 따라 전체 덮어쓰기를 할지, 증분 적재를 할지, CDC를 세팅할지 매번 DB 환경을 직접 조회하며 고민해야 했어요. 설정은 코드에 산재돼 있고 DB 환경은 매번 수동으로 조회해야 하니 자연스럽게 리뷰 병목이 생겼고, 팀의 시간이 반복적인 설정 리뷰에 계속 쓰였어요.

서비스 팀 관점

서비스 팀 입장에서도 불편했어요. 본인 서비스에 새 테이블이 추가됐을 때 이걸 분석 환경에 연동하려면, 그 서비스와는 거의 관련이 없는 레포의 코드베이스를 학습해야 했거든요. "그냥 테이블 하나 추가하고 싶었을 뿐인데..." 라는 소리가 나올 만했어요. 결국 귀찮고 복잡하니 요청이 데이터 가치화 팀으로 넘어오고, 리뷰 병목은 더 커지는 악순환이었어요.

요약하면 데이터 가치화 팀은 리뷰어 병목에, 서비스 팀은 학습 부담에 시달리는 구조였어요. 기존 ELT 파이프라인 생성 / 변경 프로세스 PR 리뷰 병목 예시

2. 고려한 대안과 한계

이 문제를 해결하기 위해 가장 먼저 검토한 건 오픈소스 ELT 플랫폼인 Airbyte였어요.

풍부한 Source / Destination 커넥터 생태계가 있고, UI 기반으로 파이프라인을 선언할 수 있어서 서비스 팀이 직접 셀프서비스로 운영하기에 잘 맞아 보였거든요. 오픈소스라서 내부 환경에 직접 설치해서 쓸 수 있다는 점도 매력적이었어요.

하지만 실제로 당근 환경에 녹이기엔 결정적인 한계가 있었어요.

대규모 테이블의 Sync 시간이 너무 길었어요. 당근은 수십억 row 규모의 테이블이 드물지 않은데, 실험 결과 Airbyte의 기본 동작 방식으로는 한 번의 Sync에 며칠 이상의 시간이 걸리는 것으로 드러났고, 이는 실제로 프로덕션 운영을 하기엔 비현실적으로 긴 시간이었어요. 저희가 이미 운영 중인 방식처럼 파티션 키 기반으로 병렬화를 돌리거나 스트림별로 Spark 리소스를 세밀하게 조정하는 식의 튜닝을 Airbyte 위에서 동등하게 구현하기엔 제약이 많았어요.

결국 '이미 잘 쓰고 있는 Airflow + Spark 기반의 실행 레이어는 그대로 두고, 그 위에 당근에 맞는 선언적 파이프라인 정의 계층만 직접 만들자' 로 방향을 잡게 됐어요.

3. DT Platform 소개

DT Platform은 당근의 구성원이 복잡한 코드베이스를 이해하지 않아도 UI에서 데이터 파이프라인을 선언적으로 정의 · 수정 · 모니터링할 수 있도록 돕는 no-code 데이터 전송 플랫폼이에요.

현재 지원 범위는 다음과 같아요.

Source: MySQL, PostgreSQL
Destination: BigQuery
Engine: Spark (EMR on EKS)

구성원 요청이 가장 많았던 "서비스 RDB → BigQuery 덤프" 케이스를 1차 타겟으로 잡고 만들었고, 이후 MongoDB · DynamoDB · S3 · GCS 등으로 확장해 가고 있어요.

플랫폼은 사용자에게 이렇게 보여요.

사용자들은 웹 UI에 들어와서, 자기 서비스의 DB를 Source로 선택하고, 전송하고 싶은 테이블(스트림) 에 체크하고, BigQuery쪽 Destination 을 선택한 뒤 스케줄을 잡아요.
설정이 끝나면 '리뷰 요청'을 눌러요. 그러면 슬랙 채널로 알림이 가고, 데이터 가치화 팀이 리뷰 → Approve 해요.
그 이후엔 사람 손이 필요 없어요. 설정이 자동으로 Airflow에 반영되고, 스케줄에 맞춰 Spark Job이 실행돼서 BigQuery로 데이터가 흘러가요.

이 '사람이 손 쓰는 구간' 을 UI 클릭 + 리뷰 한 번으로 줄이는 게 플랫폼의 1차 목표였어요. DT Platform 스트림 생성 화면

4. 아키텍처와 구현기

DT Platform 전체 아키텍처

전체 흐름을 한 줄로 그려보면 이렇게 생겼어요.

구성원이 DT Platform에서 파이프라인을 Draft로 만들고 리뷰 요청을 보내면, 데이터 가치화 팀의 Approve 시점에 DB 모델을 JSON DSL로 변환해 저장해요.
Airflow 쪽에서는 별도의 Synchronizer DAG이 10분마다 이 DSL을 S3로 가져와요.
Scheduler는 S3의 JSON을 읽어 Dynamic DAG Generation으로 파이프라인별 DAG을 만들어요.
스케줄 시점이 오면 DAG이 EMR on EKS에 Spark Job을 제출하고, Spark 는 Source DB에서 데이터를 읽어 BigQuery에 저장해요.

이 전체 그림에서 주목할 지점은 '**파이프라인 정의(데이터포털)과 실행(Airflow + Spark)가 S3 위의 JSON DSL Object 한 장을 통해 연결된다'**는 점이에요. 이 연결 지점이 저희가 원래 가지고 있던 "코드와 설정의 강결합" 문제를 끊어낸 핵심 구조예요. 데이터포털은 UI / 워크플로 설정에만 집중하고, Airflow와 Spark는 실행에만 집중하도록 책임을 깨끗하게 분리할 수 있었어요.

이 JSON DSL은 Spark에서 수행하던 모든 액션을 표현할 수 있도록 설계되었어요.

사용자는 일부 열을 제외(dropColumn)하거나, 일부 행을 제외(filter) 하도록 파이프라인을 설정할 수 있어요.
DB의 부하를 최소화하기 위해 병렬성을 제한하거나, 파이프라인 성능을 최적화하기 위해 JDBC Partition을 세밀하게 조정할 수도 있어요.
원한다면 Spark SQL을 활용해 데이터를 변환(transform)하도록 설정하여 DT Platform을 ELT를 넘어선 ETL 플랫폼으로 활용할 수도 있어요.

물론, 이런 디테일을 전부 신경쓰고 싶지 않다면 데이터 가치화 팀이 제공하는 기본 값으로 파이프라인을 실행해도 무방해요. 중요한 것은 이 모든 설정이 no-code 로 가능하다는 것이고 이것이 바로 DT Platform의 목표이자 성과였어요. DT Platform 설정 가능 값 예시

5. 마이그레이션 자동화 이야기

플랫폼을 만들었다고 끝이 아니었어요. 오히려 진짜 까다로운 일은 그 다음이었죠. 이미 프로덕션에서 돌고 있는 수백 개의 기존 ELT 파이프라인을 새 플랫폼으로 옮겨야 했거든요.

선택지는 2가지였어요.

옵션 A --- 사람이 직접: 기존 코드베이스를 하나씩 읽고, UI 에 똑같이 입력하고, 검증하고... 수백 개를 하려면 몇 달이 걸릴 일이었어요.
옵션 B --- 단순 스크립트로 일괄 변환: 코드베이스에 케이스별 예외가 너무 많아서 순수 규칙 기반 변환으로는 한계가 명확했어요.

그래서 저희가 택한 건 Claude Code와 함께 마이그레이션 에이전트 + 스킬을 만드는 것이었어요. 아이디어는 단순해요.

기존 코드베이스의 Python / Scala 소스코드를 파싱해서 의미를 추출해요.
DT Platform API 를 호출해서 해당 파이프라인을 그대로 옮겨 생성해요.
기존 DAG에 "Migration 완료" 표시를 남겨 ELT의 중복 처리를 막아요.

위 행위를 공통으로 사용할 스킬로 묶어두고, 각 엔지니어의 로컬 에이전트에서 해당 스킬을 사용하도록 했어요.

그런데 여러 명의 엔지니어가 동시에 에이전트를 돌릴 수 있어야 했기 때문에, 여러 에이전트가 동일한 대상을 중복으로 마이그레이션하는 사고를 막을 장치가 필요했어요.

저희는 이걸 위해 Notion 데이터베이스를 일종의 "작업 단위 레지스트리" 로 사용했어요. 각 row는 "어떤 파이프라인을 누가 언제 처리 중인지" 를 나타내요. 에이전트는 작업을 시작하기 전에 Notion MCP를 통해 해당 row를 조회/생성해서 선점(in-progress 로 마킹)하고, 완료하면 상태를 업데이트해요. Notion이 Single Source of Truth 역할을 해주기 때문에, 에이전트 사이의 충돌을 자연스럽게 직렬화하면서 사람도 읽기 쉬운 Migration 기록을 팀 내 문서함에 유지할 수 있었어요. DT Platform Migration Log Notion Database

결과적으로 이 방식으로 약 2주 안에 MySQL/PostgreSQL ELT 파이프라인 203개를 프로덕션까지 마이그레이션 완료 할 수 있었어요. 현재 DT Platform 운영 현황

6. 성과

그래서 이 플랫폼이 실제로 뭘 바꿨을까요? 저희가 가장 궁금했던 건 '서비스 DB 데이터를 Data Warehouse 에 연동하는 리드타임이 진짜로 줄었는가' 였어요.

6--1. 파이프라인 변경 리드타임

신규 DB 연동, 신규 테이블 추가, 전송 설정 변경을 모두 합쳐서 하나의 "파이프라인 추가/변경 요청" 으로 놓고 리드타임을 계산했어요.

리드 타임 감소 외에도 DT Platform 출시 이후 요청 수가 크게 증가한 것을 확인할 수 있어요. 데이터 가치화 팀은 이러한 증가가 Data Warehouse 연동 과정의 허들이 크게 낮아졌다는 사실을 반영하고 있다고 보고 있어요. DT Platform 월별 파이프라인 추가/변경 요청 건수

6--2. 정성적인 변화

숫자 외에도 체감되는 변화가 있었어요.

데이터 가치화 팀은 Web UI를 통해 파이프라인 상태를 한눈에 볼 수 있게 됐어요. "지금 어떤 테이블이 어떻게 싱크되고 있지?" 라는 질문에 코드를 읽지 않고도 답할 수 있어요. 이는 구성원들에게도 마찬가지로 적용돼요. 데이터 가치화 팀에 문의할 필요 없이 파이프라인의 현재 설정을 플랫폼을 통해 바로 알 수 있어요.
서비스 팀은 이제 코드베이스를 학습하지 않고도 UI 에서 바로 설정을 만들고 바꿀 수 있어요. 리뷰 요청은 Slack 으로 자동 알림이 가요.

스트림 설정 확인 화면 파이프라인 리뷰 / 승인 Slack 알림

6--3. 플랫폼이 열어준 다음 단계들

플랫폼화의 진짜 매력은 '**한 번 해두면 그 위에 올릴 수 있는 게 생긴다'**는 점이에요. 설정이 하나의 스키마로 통일돼 있고 중앙에서 관리된다는 사실 덕분에, 저희가 다음에 해볼 수 있는 일들이 늘어났어요.

파이프라인 실행 성공 / 실패 가시화: 이전엔 파이프라인 실행 현황을 확인할 수 있는 곳은 Airflow UI뿐이었고, 서비스 팀 구성원들은 데이터 가치화 팀을 통해서만 이를 확인할 수 있었어요. 이제 플랫폼 UI 에서 파이프라인과 스트림 별 실행 성공 / 실패 여부를 직접 확인할 수 있게 되었어요.
파이프라인 비용 가시화: 각 파이프라인의 비용을 플랫폼에서 가시화할 수 있게 되었어요. 이를 통해 구성원들의 비용 인지도를 높여 보다 효율적인 운영을 위한 발판을 마련하게 되었어요.
보안 강화: PII 컬럼 자동 제외, 데이터셋 분리, Credential 관리 강화 같은 가드레일을 플랫폼 레벨에서 일괄 적용할 수 있어요.
Agentic 한 최적화: 설정이 일원화돼 있어서, 에이전트가 Spark 지표를 보고 executor_config / num_partitions 같은 튜닝을 제안하거나 자동으로 적용하는 시도가 가능해요.
Data Transfer MCP: 파이프라인 생성 / 최적화 / 관리의 과정을 전부 에이전트가 진행할 수 있도록, DT API를 기반으로 한 MCP 서버를 구성해볼 수 있어요.

파이프라인 실행 현황 / 비용 가시화 화면

7. 플랫폼의 미래, 그리고 함께할 동료를 찾아요

DT Platform은 아직 초기 단계예요. 지금은 MySQL / PostgreSQL → BigQuery에 집중돼 있지만, DSL 스키마에는 이미 MongoDB, DynamoDB, S3, GCS, Aurora S3 Export, GCP Storage Transfer Service 같은 다양한 Source / Destination / Engine 타입이 선제적으로 정의돼 있어요.

차차 모든 종류의 ELT / ETL 파이프라인을 품는 플랫폼으로 키워갈 예정이에요. 단순히 지원 범위를 넓히는 데 그치지 않고, AI-native한 파이프라인 관리 환경의 토대가 되는 걸 목표로 개발하고 있어요.

그 여정을 같이 만들 동료를 찾고 있어요. 대규모 데이터 플랫폼의 문제를 재밌게 풀어보고 싶다면, 꼭 연락 주세요.

👉 당근 데이터가치화팀 채용 공고 --- Software Engineer, Data

👉 당근 데이터가치화팀 채용 공고 --- Data Analytics Engineer

당근 200+개 DB 를 옮기는 ELT 플랫폼, DT Platform 을 만든 이야기 was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.