토스 데이터 웨어하우스 팀이 중앙 DW Airflow를 도메인별 실행 환경으로 옮기는 과정을 10월 16일 공개했다. 400개가 넘는 DAG가 한 클러스터에 모이면서 배치가 서로 밀리고, 테이블의 생성 경로를 파악하려면 여러 시스템을 찾아야 했다는 설명이다. 새 환경은 도메인별 클러스터로 실행을 분리하되 코드는 한 저장소에서 관리한다. 팀이 밝힌 9월 말 상태는 클러스터 5개와 dbt 모델 983개다. 다만 기존 파이프라인을 큰 규모로 옮긴 곳은 광고 도메인이며, 전사 이관을 마쳤다는 의미는 아니다.
교체보다 병행 검증을 먼저 했다
팀은 기존 배치를 유지하면서 새 파이프라인으로 같은 데이터를 다시 만들고 결과를 비교했다. 한 마트는 약 3주간 검증했고, 기존 시스템의 의존 관계 정리가 덜 끝났을 때는 전환을 되돌린 뒤 다시 적용했다. Spark와 Jenkins 작업을 모두 새 방식으로 바꾸려 하지는 않았다. 비즈니스 SQL은 dbt 모델로 정리하고, 다른 작업이 만드는 테이블은 별도 선언과 래퍼로 연결했다. 이 기록은 기술을 일괄 교체하는 일정표보다, 계속 운영할 경로와 전환할 경로를 함께 설계한 사례에 가깝다.
문맥을 코드와 함께 수정하는 구조
설명·품질 규칙과 적재 주체를 모델 옆 설정 파일에 모은 점도 중요하다. 토스는 광고 도메인의 DAG 코드가 2,794줄에서 100줄로, 파이프라인 시간이 4시간에서 2시간 30분으로 줄었다고 밝혔다. 이는 해당 이관의 결과이며 다른 조직의 예상 절감률은 아니다. 팀이 문서 구성에 참고한 디아택시스는 학습용 튜토리얼, 작업 절차, 기술 참조, 배경 설명을 서로 다른 요구로 나눈다. 같은 저장소에 넣는 것에 더해 독자가 어떤 질문을 해결하려는지에 따라 정보의 역할을 구분하는 방식이다.
참조 관계와 실행 검증은 다른 층이다
dbt 공식 문서에서 ref 함수는 다른 모델의 데이터베이스 객체를 가리키는 동시에 모델 사이의 의존 관계를 만든다. 배포 환경에 맞는 이름으로 치환되고 실행 순서를 정할 그래프에 반영된다. 테이블 이름을 문자열로 적는 방식과 차이가 나는 지점이다. 따라서 모델의 입력을 바꾸는 수정은 SQL 표현만 바꾸는 일이 아니라 의존 구조를 바꾸는 일이기도 하다. 이름이 비슷한 모델이 여러 프로젝트에 있다면 어느 프로젝트의 모델인지 명시하는 참조도 지원한다.
컴파일 명령은 모델과 검사 등의 SQL을 실행할 수 있는 형태로 만드는 단계다. 이것만으로 데이터가 기대한 의미와 수량을 가졌는지 확인되지는 않는다. 팀이 적용할 때는 참조가 해석되는지, 실제 데이터베이스의 컬럼과 맞는지, 산출물이 업무 기준을 충족하는지를 별개의 검사로 두는 편이 좋다. 자동으로 만든 의존 관계가 정확해지려면 입력을 올바르게 선언해야 하며, 선언되지 않은 외부 작업의 완료 여부를 알아서 추론한다고 기대해서도 안 된다. 이 구분이 코드에 문맥을 모으는 구조를 실제 운영의 신뢰로 연결한다.
코드 감소와 실행 시간 감소의 분모를 나누면
토스가 공개한 전후 수치로 감소율을 다시 계산했다. DAG 코드 2,794줄에서 100줄은 2,694줄 감소이므로 기존 줄 수 대비 약 96.4%다. 파이프라인 4시간에서 2시간 30분은 240분에서 150분, 90분 감소이므로 약 37.5%다. 두 비율은 같은 분모를 쓰지 않는다. 코드가 96.4% 줄었다고 실행이 그만큼 빨라졌다는 뜻도 아니며, 이 숫자만으로 어떤 변경이 시간 감소를 일으켰는지 분리할 수도 없다.
줄 수는 이 사례에서 수동으로 관리하던 DAG 정의가 얼마나 바뀌었는지를 보여주고, 시간은 해당 배치의 소요를 보여준다. 생성되는 task나 외부 시스템까지 사라졌다고 해석하면 안 된다. 아래 표는 발표 수치에 산식을 적용한 결과이며 토스 인프라를 직접 실행하거나 동일한 작업량으로 벤치마크한 결과가 아니다. 다른 도메인의 예상 효과를 산정할 때는 작업 수·데이터량·의존 대상이 같은 조건인지부터 봐야 한다.
실행 시간 외에 전환의 안전성을 판단할 기록도 있다. 같은 데이터로 구·신 경로를 약 3주간 병행 비교했고, 외부 의존 sensor 준비 때문에 전환을 되돌린 과정이 남아 있다. 컴파일이 통과하는지, 컬럼이 맞는지, 업무 산출물이 일치하는지, 후속 작업이 올바른 완료 신호를 받는지는 각각 다른 확인이다. 새 정의가 짧다는 사실보다 그 정의가 연결한 실제 운영 경로를 추적할 수 있는지가 이관의 완료 기준에 가깝다.
| 항목 | 이전 → 이후 | 직접 계산 | 해석 범위 |
|---|---|---|---|
| DAG 코드 줄 수 | 2,794 → 100줄 | (2,794 − 100) / 2,794 ≈ 96.4% | 관리하는 DAG 코드 규모 |
| 파이프라인 소요 | 240 → 150분 | (240 − 150) / 240 = 37.5% | 발표 사례의 경과 시간 |
DW 파이프라인은 실행을 도메인별로 나누면서 정의와 의존 관계를 코드 가까이에 모았다. 병행 이관의 기록과 참조·컴파일·문서화가 각각 맡은 역할을 구분해 운영 구조를 읽을 수 있다.
ARCH.B 의견
저장 위치가 하나라도 같은 지표를 여러 곳에서 다르게 설명하면 문맥은 여전히 어긋난다. 이 사례를 참고하는 팀이라면 테이블을 누가 만들고 어떤 입력에 의존하는지, 지표의 계산식과 예외를 누가 승인하는지까지 코드 변경과 연결할 필요가 있다. 디아택시스의 구분을 적용하면 운영 중 필요한 재실행 절차와 설계 배경 설명을 섞지 않을 수 있다. 에이전트가 읽기 좋다는 이유로 문서량부터 늘리기보다 실제 질문에서 누락되는 정보와 정의의 책임자를 찾아 보완하는 접근이 타당하다. 문서가 계산 실행과 검토를 대체하는 것도 아니다.
토스는 팀 해커톤의 데이터 챗봇 평가도 공개했지만 질문 수가 적고 실행마다 결과가 흔들릴 수 있다고 명시했다. 문맥을 보완한 실험과 시맨틱 레이어로 계산을 실행한 실험은 문항 구성이 달라 직접 비교할 수 없다는 설명도 붙였다. 이 제한을 남겨야 모델 개선과 기반 데이터 정리의 효과를 혼동하지 않는다. 도입을 검토한다면 같은 질문과 같은 데이터 시점으로 검색 정확도, 계산 결과, 실패 시 추적 가능성을 각각 비교하는 편이 좋다. 배치 시간만 줄었는지와 운영자가 결과의 생성 이유를 설명할 수 있는지는 서로 다른 품질 항목이다.
