ETL 개념과 ETL 개발 시 고려해야 하는 원칙들

엔씨소프트 데이터 조직이 ETL 개발에서 지켜야 할 원칙을 정리한 글이다. ETL은 정답이 정해져 있지 않아 이 설계가 맞는지, 더 효율적인 구조는 없는지 하는 고민이 반복된다. 글은 ETL의 개념과 역할을 먼저 정리한 뒤 멱등성부터 모니터링까지 아홉 가지 원칙, 추가 고려사항 네 가지, 자동화 가능한 워크플로우 패턴 세 가지 순으로 이어진다. Airflow 운영을 전제로 한 예시가 많다.

핵심 포인트

ETL은 추출·변환·적재 세 단계로 이뤄진 연속 프로세스이고, 여러 팀의 정형·비정형 데이터를 비즈니스에 쓸 수 있는 형태로 바꾸는 일이다
모든 ETL 실행 결과는 멱등해야 한다. 재실행, 중단 후 재개, 과거 날짜 재적재, 예약 작업의 수동 실행이 모두 같은 결과를 내야 한다
멱등성 확보 수단은 비즈니스 로직 고유 키 기준 OVERWRITE와 MERGE INTO 두 가지이며, 데이터가 많으면 전자가 성능상 유리하다
전체 팩트 테이블을 스캔하는 대신 이전 날짜 파티션만 읽는 점진적 적재로 바꾼다
시간에 따라 소급 적용되는 비즈니스 로직은 하드코딩하지 말고 유효 날짜를 매개변수 테이블에 저장한다
운영과 테스트 환경 분리가 가장 먼저 고려돼야 한다. 테스트가 운영 테이블을 덮어쓰는 사고가 제일 치명적이다

상세 정리

멱등성 정의: 다른 날짜·시간·조건에서 같은 매개변수로 실행해도 결과가 동일하게 유지되는 성질이다
멱등성이 푸는 문제: ETL 실패 후 재실행, 비즈니스 로직 변경에 따른 과거분 재적재, 라이브를 미러링한 개발 환경 구축 세 가지다
멱등성 실패 사례: 중단 시점부터 이어서 적재하면 데이터가 중복되고 원래 의도한 결과를 얻지 못한다
점진적 적재 예시: 전체 기간을 COUNT 하던 쿼리를 어제 요약 테이블 파티션과 오늘 팩트 테이블 파티션의 UNION으로 바꿔 쓴다
과거 데이터 적재: 실행 날짜와 무관하게 시작 매개변수만 과거로 지정하면 그 시점 데이터를 다시 적재할 수 있어야 한다
데이터 분할: 대개 날짜 스탬프로 파티션을 나누고, UPDATE·APPEND·DELETE 대신 특정 파티션을 덮어써 데이터베이스 이상현상을 막는다
중간 데이터: 임시 로컬 파일은 다른 Task가 접근하지 못하는 경우가 생기므로 모든 Task가 접근 가능한 영역에 둔다. 필자 팀은 중간 데이터 전용 DB를 따로 운영한다
작업 단위: 작업 하나가 단일 파티션으로 출력돼야 논리 테이블과 작업, 파티션과 작업 인스턴스의 매핑이 단순해지고 전체가 아닌 셀 하나만 골라 재실행할 수 있다
데이터 검사: 스키마 타입 일치, 제약조건, 도메인 적용, 예상 레코드 수 일치를 본다. 레코드가 과하게 많으면 JOIN 오류를, 적으면 로직 오작동을 의심한다
모니터링: Airflow의 DAGs 탭으로 전체 상태를, Graph View로 실패한 Task를, Gantt Chart로 Task별 소요 시간을, Task Tries로 재시도가 잦은 Task를 확인한다
리소스: DAG 수가 늘면 실행 속도가 느려지고 대기 시간이 길어지는데, 배치 주기가 짧은 DAG일수록 목표 시각을 놓칠 위험이 크다
작명 규칙: 같은 데이터인데 테이블마다 컬럼명이 다르면 매번 열어 확인하는 단계가 붙고, DAG 이름 규칙이 없으면 로그만 보고 어떤 작업이 깨졌는지 알기 어렵다
의존성: 실행 도구와 DAG 코드, 컨테이너와 라이브러리, Airflow 버전과 파이썬 버전까지 초기에 분리해두지 않으면 DAG가 늘수록 얽힌다
자동화 패턴: 증분 계산은 어제 요약 파티션과 오늘 팩트 파티션만으로 누적값을 집계하고, 과거 데이터 적재는 미니 백필로 쪼개 병렬화하며, 비정규화는 팩트 테이블을 조인해 대시보드용 테이블을 만든다