실행은 도메인별로, 문맥은 한 레포에

들어가며안녕하세요, 토스 Data Warehouse 팀의 Data Analytics Engineer 김문수입니다.이 글에서는 데이터 웨어하우스(DW) 마트를 만드는 중앙 DW Airflow를 멈추지 않고, 도메인별 DW Airflow와 dbt 기반의 선언적 파이프라인으로 옮겨 온 과정을 공유하려고 합니다. 새 플랫폼은 팀 안에서 이를 ‘뉴타운’이라고 부르고 있습니다.얼마 전 코딩 에이전트에게 "이 테이블 어디서 만들어져?"라고 물었습니다. 한참 코드를 뒤지던 에이전트의 답은 이랬습니다. "적재 주체는 코드에 없어 확인할 수 없습니다." 맞는 말입니다. 정말로 코드에 없었기 때문이죠.이 글은 그 답을 코드에 적어 넣기까지의 이야기입니다. 그 과정에서 토스 광고 도메인의 DAG 코드는 2,794줄에서 100줄이 되었고, 테이블 순서를 손으로 잇던 >> 180줄은 0줄이 되었습니다. 파이프라인 시간도 4시간에서 2시간 30분으로 줄었습니다.DW Airflow 하나에 DAG 400여 개토스에는 용도와 팀에 따라 운영하는 Airflow가 여럿 있습니다. 이 글에서 다루는 건 그중 DW 마트를 만드는 DW Airflow입니다. DW 마트에는 광고, 쇼핑, 결제, 금융 등 도메인 팀이 각자 관리하는 도메인 마트와, 중앙 DW팀이 관리하는 마트가 있습니다. 중앙 DW팀은 전사 공통 마트뿐 아니라, 어느 도메인에도 딱 떨어지지 않아 주인이 애매한 마트까지 맡고 있습니다. 그런데 이 마트 파이프라인이 도메인과 상관없이 전부 DW Airflow 클러스터 하나에서 돌고 있었습니다. DAG 파일로 세면 400개가 넘습니다.한 클러스터에 모여 있다 보니 문제가 몇 가지 있었습니다. 한 도메인의 배치가 몰리면 다른 도메인의 배치까지 밀렸고, 파이프라인 하나를 고치려면 다른 도메인이 어떻게 돌고 있는지까지 알아야 했습니다. 비슷한 로직도 표준 없이 여기저기 복사돼 있었습니다.매일 겪는 불편은 조금 더 구체적이었습니다. 테이블 하나를 이해하려면 다섯 군데를 열어야 했습니다.고쳐 쓰지 않고 옆에 새로 짓기로 했습니다처음에는 기존 레포를 리팩토링하는 방법도 생각했습니다. 그런데 문제의 뿌리가 "클러스터 하나에 다 모여 있다"는 구조 자체라서, 코드를 아무리 정리해도 이 부분은 해결이 안 됩니다. 그렇다고 전사 배치를 한 번에 새 플랫폼으로 옮기는 건 너무 위험합니다. 문제가 생기면 대응하기가 꽤 까다로워요.돌이킬 수 있으면서 간편한 ...