데이터엔지니어 주형권

[DRE] 실패 알림을 넘어 영향 범위 예측으로 — 데이터 파이프라인 Observability 구현 (with. Databricks)

주형권 — Thu, 30 Jul 2026 13:30:59 +0900

이 글의 핵심 요약 (Key Takeaways)

단순히 "작업이 실패했습니다"라고 통보하는 1차원적 모니터링을 넘어, 장애 발생 시 "어떤 후속 작업과 데이터 마트 테이블에 영향이 가는가?"를 예측하는 관측 가능성(Observability) 시스템 구축 실무 사례입니다. 본 글에서는 Databricks 파이프라인의 코드를 스캔하여 데이터 리니지(Lineage) 메타데이터를 자동화하는 방법, 다단계(A➡️B➡️C) 영향도 추적 로직, 그리고 알림 피로도(Alert Fatigue)를 방지하기 위해 MS Teams 채널을 세분화하여 공지하는 DRE(Data Reliability Engineering) 조직 문화 정착 노하우를 집중적으로 다룹니다.

안녕하세요. 주형권입니다.

어느덧 Data Reliability Engineering를 도전한 지 7개월의 시간이 흘렀습니다. 단순히 모니터링을 넘어서 이제는 Observability라는 이름으로 무언가를 만들고 싶다는 생각이 들어서 단순히 1차원적 알림에서 나아가 어떠한 데이터에 영향이 갈지도 예측하는 방향으로 모니터링 시스템을 진화시키고자 합니다.

이 글의 경우 어쩌면 기존에 작성 하였던 "[DRE] 데이터 파이프라인 장애 감지 자동화 — Airflow + Teams 연동"의 Step 2가 아닐까 싶습니다. 기존에는 단순히 이 작업이 "실패 하였으니 확인을 해봐"였다면 이제는 어떠한 "테이블과 작업이 영향이 있다"까지 보여주는 알림으로 진화시켰습니다.

[DRE] 데이터 파이프라인 장애 감지 자동화 — Airflow + Teams 연동

이 글의 핵심 요약무슨 문제인가: 기존 팀 단위의 단편적인 모니터링 방식으로는 본부 전체 사용자가 무작위로 생성하는 수많은 Databricks 워크플로우의 성공/실패/지연 상태를 체계적으로 관

burning-dba.tistory.com

1. 무엇이 변경되었는가?

기존에는 앞서 말한 것과 같이 단순히 어떠한 작업이 실패하였는지 알림을 보냈습니다. 다음과 같은 형태로 알림이 발생했습니다.

담당자를 호출하여 본인의 작업이 실패하였다는 것을 인지 시키고, 간략하게 실패 원인에 대해서 보여줍니다. 사용자는 해당 파이프라인의 중요도에 따라 즉시 처리할지 후에 처리할지를 판단 가능하며, 자세한 내용을 보려면 View Run Details를 이용해서 작업으로 하이퍼링크를 통해서 확인도 가능합니다.

하지만 여기에서 한 가지 문제가 있습니다. 사용자가 만약 그 시스템에서 모든 것을 알고 있다면, 앞서 말한 판단을 할 때 망설임이 없이 즉시 처리할지 후에 처리할지를 판단할 수 있습니다. 그런데 여기에서 그 판단을 하려면 시스템을 모두 알아야합니다. 그리고 내가 만든 작업이 대규모 마트 작업이라서, 이로 인한 파생되는 테이블이 매우 많아지면 어느 부분이 문제가 되는지 알기 어렵습니다.

그렇기 때문에 이를 판단 할 수 있도록 더욱 많은 정보가 필요합니다. 제가 여기에서 가장 필요하다고 느끼는 건 내 작업이 실패하면 어떠한 작업과 테이블에 영향이 가는가? 를 알 수 있어야 한다는 것입니다.

내 작업이 실패하면 어느 테이블 어느 작업까지 영향이 가는가?

이게 제가 생각하기에 Monitoring과 Observability의 차이라고 보입니다. 단순히 알렸다에서 무엇이 영향이 간다까지 알려주는 부분에서 기존의 작업 실패 알림을 넘어서 예측까지 하는 범위로 진화하였습니다.

2. 설계와 구현

일단 첫 번째로 제일 중요한 것은 Source 테이블과 Target 테이블을 한눈에 알 수 있어야 한다는 것입니다. 그래야지 체인으로 모두 연결하여, A->B->C 이렇게 이어지는 파이프라인 체인을 통해서 어디서 잘못되면 어디서부터 어디까지 영향이 있는지를 정확히 알 수 있습니다.

그래서 필요한 게 이러한 Source / Target 테이블의 정보와 해당 작업에서 어디서 데이터를 읽어서 어디로 적재하는지 정보를 담고 있는 정보가 필요하였습니다. 그래서 task_table_mapping이라는 테이블을 만들어서 Source와 Target 테이블의 정보 그리고 어느 작업에 영향을 받는지 모두 한눈에 조회가 가능한 테이블을 만들었습니다.

모니터링 시스템의 RDS에 저장하는 DDL을 다음과 같이 만들 수 있습니다. 어디까지나 DDL은 참고용이므로, VARCHAR 길이등은 너무 타이트하게 보지 마시고, 각자의 시스템에 맞게 조정을 부탁드립니다. (PK도 길이가 긴데, 어차피 디멘젼 느낌이라서 이렇게 잡는 게 확실하다고 판단하였습니다.)

CREATE TABLE reliability.task_table_mapping (
  job_id VARCHAR(100) NOT NULL COMMENT 'Job ID',
  job_name VARCHAR(255) NOT NULL COMMENT 'Job 이름',
  schedule VARCHAR(100) COMMENT '실행 스케줄',
  task_key VARCHAR(150) NOT NULL COMMENT 'Task 키',
  task_order INT NOT NULL COMMENT 'Task 실행 순서 (depends_on 기반)',
  notebook_path VARCHAR(500) COMMENT '노트북 경로',
  source_table VARCHAR(255) NOT NULL COMMENT '소스 테이블 (fully qualified)',
  target_table VARCHAR(255) NOT NULL COMMENT '타겟 테이블 (fully qualified)',
  write_method VARCHAR(100) COMMENT '적재 방식 (MERGE, CREATE OR REPLACE, INSERT, replaceWhere)',
  source_type VARCHAR(50) COMMENT '소스 유형 (UC_TABLE, S3, RDS)',
  
  -- 데이터가 UPDATE 될 때도 시간이 자동 변경되도록 트리거 추가
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '메타데이터 갱신 시각',
  
  -- 복합 기본키 지정 (총 길이: (100 + 150 + 200 + 200) * 4 = 2600 Bytes로 안전 범위 내 안착)
  PRIMARY KEY (job_id, task_key, source_table(200), target_table(200))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
  COMMENT='코드 스캔 기반 Job Task → Source/Target 테이블 매핑. 파이프라인 실패 시 영향 범위 파악 용도.';

처음에는 Databricks에서 제공하는 system.access.table_lineage / system.access.column_lineage을 사용하려고 하였으나 일회성으로 만든 테이블로 인해서 혼선을 줄 수 있다는 점과 완벽하게 커버가 불가능한다는 판단하에 실제로 Databricks의 작업에 있는 Task를 모두 일 1회 SCAN(추후에는 변경 부분만 SCAN으로 변경)하여, 실제로 등록된 Notebook / SQL 등을 읽어서 정규식 표현으로 Source / Target을 주기적으로 가져와서 reliability.task_table_mapping이라는 매핑 테이블에 적재하도록 하는 작업을 만들었습니다. (databricks의 Genie 코드의 도움을 받았으며, 아주 잘 가져옵니다.)

이렇게 하면 빠짐없이 가능하며, 실제로 주기적 작업에 등록된 작업의 Source / Target 정보 이외에 작업 정보와 어디로부터 오는지 여러 가지 정보를 얻을 수 있습니다.

def extract_tables_from_code(code):
    """코드에서 source/target 테이블을 정규식으로 추출한다."""
    if not code:
        return []
    
    results = []
    
    # --- Target 패턴 ---
    merge_targets = re.findall(
        r'MERGE\s+INTO\s+([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    insert_targets = re.findall(
        r'INSERT\s+(?:INTO|OVERWRITE)\s+(?:TABLE\s+)?([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    ctas_targets = re.findall(
        r'CREATE\s+(?:OR\s+REPLACE\s+)?TABLE\s+(?:IF\s+NOT\s+EXISTS\s+)?([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    save_targets = re.findall(
        r'\.saveAsTable\(\s*["\']([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)["\']',
        code, re.IGNORECASE
    )
    delete_targets = re.findall(
        r'DELETE\s+FROM\s+([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    
    # --- Source 패턴 ---
    from_sources = re.findall(
        r'FROM\s+([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    join_sources = re.findall(
        r'JOIN\s+([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)',
        code, re.IGNORECASE
    )
    spark_sources = re.findall(
        r'(?:spark\.table|spark\.read\.table)\(\s*["\']([a-zA-Z0-9_]+\.[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+)["\']',
        code, re.IGNORECASE
    )
    s3_sources = re.findall(
        r'(s3://[a-zA-Z0-9\-_]+/[^\s"\'\)]+)',
        code
    )
    
    all_sources = list(set(from_sources + join_sources + spark_sources))
    all_targets = set()
    
    # Write method 판별 및 target 수집
    for t in merge_targets:
        all_targets.add((t, "MERGE"))
    for t in insert_targets:
        all_targets.add((t, "INSERT"))
    for t in ctas_targets:
        all_targets.add((t, "CREATE OR REPLACE"))
    for t in save_targets:
        all_targets.add((t, "saveAsTable"))
    for t in delete_targets:
        all_targets.add((t, "DELETE"))
    
    # replaceWhere 감지
    if re.search(r'replaceWhere', code, re.IGNORECASE):
        updated = set()
        for t, m in all_targets:
            if m in ("saveAsTable", "CREATE OR REPLACE"):
                updated.add((t, "replaceWhere"))
            else:
                updated.add((t, m))
        all_targets = updated
    
    # Source에서 target 제거 (self-reference 방지)
    target_names = {t for t, _ in all_targets}
    all_sources = [s for s in all_sources if s not in target_names]
    
    # Source type 판별 + 매핑 생성
    for target, method in all_targets:
        for source in all_sources:
            source_type = "UC_TABLE"
            if source.startswith("monitoring_rds"):
                source_type = "RDS"
            results.append((source, target, method, source_type))
        
        # S3 소스 추가 (날짜 변수 정규화)
        for s3 in s3_sources:
            s3_normalized = re.sub(r'/\{[^}]+\}', '/', s3)
            s3_normalized = re.sub(r'/\$\{[^}]+\}', '/', s3_normalized)
            s3_normalized = re.sub(r'/f"[^"]*"', '/', s3_normalized)
            s3_normalized = s3_normalized.rstrip('/')
            # 날짜 path 부분 제거 (/{year}/{month}/{day} 패턴)
            s3_normalized = re.sub(r'(/\d{4})?(/\d{2})?(/\d{2})?/?$', '/', s3_normalized).rstrip('/')
            results.append((s3_normalized, target, method, "S3"))
    
    return results

그래서 결론적으로 다음과 같이 기존에 성공/실패에 대한 알림만 전달하는 방식으로써 사용자에게 무엇이 실패했는지만 알림을 보냈다면 위에서 추가한 reliability.task_table_mapping 테이블을 통해서 예측을 하도록 구현합니다.

단순 상태 체크

다음과 같이 reliability.task_table_mapping을 통해서 영향도를 추가하여 알림을 보내도록 만들 수 있습니다. 단순히 테이블이 하나가 추가된 것 하나로 성공/실패뿐 아니라 영향도가 어디까지 있는지 알림을 보냅니다.

매핑 테이블을 이용한 영향도 체크

3. 알림과 후속 처리

기존에 단순히 성공/실패 여부만을 알려줬었다면, 이제는 진화하여 영향도까지 알 수 있도록 알림을 구성하였습니다.

(샘플 데이터입니다.)

진화된 알림

어떠한 작업이 실패하였으며, 이 작업이 실패함으로 인해서 다음의 테이블이 영향이 가는지 알 수 있습니다. 최대한 가독성이 좋게 하기 위해서 불필요한 메시지를 최대한 자제하려고 노력하였으며, 작업 실패로 인한 1차 테이블 그 1차 테이블을 바라보는 2차 테이블까지 표기가 됩니다. 물론 체인이 길게 있다면 1차 -> 2차 -> 3차 -> N차로 이어지게 됩니다. 이로써 담당자는 결정을 내리는데 더욱 많은 정보를 알기 쉽고 빠른 판단을 내릴 수 있습니다.

하지만 여기에서 문제가 있습니다. 일단 알림을 보냈고, 작업의 담당자가 알림을 받아서 알았지만 이 테이블을 사용하는 사람들에게는 전파를 할 방법이 없습니다. 담당자가 내가 만든 테이블이 아닌 이걸 참조하는 테이블의 담당자까지 알기는 어렵습니다. 처음에는 system.query.history 또는 aduit을 이용해서 최근 30일 이내에 해당 테이블을 조회한 사용자를 역 추적해서 알림을 보내려고 하였지만 제가 늘 언급하듯이 배보다 배꼽이 큰 상황이 생길 거 같아서, 이 부분은 접었습니다.

그리고 사람들이 습관적으로 SELECT * FROM 테이블 이런 식으로 데이터를 조회해서 샘플을 보고 판단하는 경우도 빈번하기에 실제 해당 사용자가 저 테이블을 사용하고 있다고 보기에는 확실히 무리가 있었습니다.

만약에 정말 큰 테이블의 작업이 장애가 난 경우 수백 명에서 하나씩 멘션을 줄수도 없고, 이런 메시지가 너무 빈번하다면 사람들은 피로도를 느껴서 정작 중요한 메시지를 놓치기 십상입니다. 그래서 아예 Teams에서 채널을 하나 만들어서 사람들이 이 채널을 통해서 어떠한 테이블에 문제가 있는지를 알 수 있도록 하는 것이 더욱 현실적인 방법이라고 생각했습니다.

Teams 채널을 통해서 전파

데이터 영향도 알림

초반에는 사람들이 우왕좌왕할 수 있으나 이 문화가 정착되면 자연스레 사람들은 이 채널을 통해서 장애 여부를 알 수 있을 것입니다. 또한 해당 메시지에 다음과 같이 댓글을 이용해서 담당자가 언제 복구되었는지 얼마나 소요될지에 대해서도 알 수 있습니다. 물론 SLI / SLO / SLA 등을 확인하기 위해서 복구를 자동으로 감지하도록 할 수도 있지만 현재 DRE의 문화가 정착이 안된 시점에서 너무 이른 판단으로 보여, 다음과 같이 후속 처리는 수동으로 하였습니다.

자문자답 상황극...

위와 같이 소소하지만 정확하게 담당자가 처리 이후에 댓글을 달아서 해당 작업이 잘 처리되었다고 다시금 공지를 할 수 있으며, 사람들은 당연히 해당 공지를 통해서 자신의 후속 작업이나 새로운 데이터 작업을 완료할 수 있습니다.

마치며

지난 7개월간 Data Reliability Engineering(DRE) 업무를 도전하며 얻은 가장 큰 교훈은, "데이터 신뢰성은 완벽한 기술력만으로 완성되지 않는다"는 것입니다. 아무리 정교한 모니터링 시스템과 리니지(Lineage) 추적 기술을 도입하더라도, 장애 상황을 투명하게 공유하고 장애 복구에 대해 적극적으로 소통하는 '문화'가 정착되지 않는다면 그 시스템은 결국 외면받게 됩니다.

이번에 구축한 '영향도 예측 알림'과 '이상탐지 전용 공지 채널' 역시, 엔지니어와 현업 사용자가 서로의 상황을 이해하고 신뢰할 수 있도록 돕는 소통의 다리가 되기를 바라는 마음에서 시작되었습니다.

아직 우리 조직의 DRE 문화가 완전히 무르익었다고 할 수는 없지만, 이렇게 작지만 확실한 시스템적 변화들이 모여 단단한 데이터 문화를 만들어갈 것이라 확신합니다. 앞으로도 단순한 알림을 넘어, 모두가 믿고 쓸 수 있는 진정한 의미의 '관측 가능성(Observability)'을 구현하기 위해 끊임없이 고민하고 발전시켜 나가겠습니다.

긴 글 읽어 주셔서 감사합니다.

[DRE] 로그 정합성 모니터링 고도화

주형권 — Wed, 15 Jul 2026 15:08:13 +0900

이 글의 핵심 요약 (Key Takeaways)

매일 수억 건이 발생하는 대규모 데이터 파이프라인에서 단순 건수 체크를 넘어선 '다차원 로그 정합성 모니터링 시스템(Airflow + Databricks + MySQL + Teams)'을 구축한 실무 사례입니다. 본 글에서는 특정 로그 타입 및 국가별 유실을 감지하는 세분화된 집계 로직, 알림 피로도(False Positive)를 줄이기 위한 임계치 설정 노하우, 그리고 대용량 집계 시 발생하는 비용 최적화(Cost Optimization) 전략을 집중적으로 다룹니다.

안녕하세요. 주형권입니다.

최근 방대한 로그들이 여기저기에서 들어오다 보니 로그가 정상적으로 들어오는지에 대해서 고민을 많이 하게 되었습니다. 그래서 데이터 엔지니어들의 영원한 숙제인 정합성 모니터링에 대해 깊은 고민을 하게 되었습니다.

현재 저희 팀에서는 매일 수천만~수억 건의 핵심 서비스 로그 데이터를 적재하고 있습니다. 그런데 시스템 규모가 커지다 보니, 전체 볼륨은 정상인데 특정 권역, 테이블, 로그타입, 국가등 로그가 정상적으로 들어오고 있는지에 대한 검증이 필요하다고 생각이 되었습니다.

기존에는 단순하게 권역/테이블/일자 이렇게 3개로만 데이터를 체크 하였다면, 이제는 각 로그타입별 / 국가별로 로그 타입을 더욱 세분화하여 로그의 집계를 통해서 해당 로그에 이상이 있는지에 대해서 조금 더 세부적으로 보고 이를 발견할 수 있도록 해야겠다는 고민을 하게 되었습니다.

단순히 "어제 1억 건 들어왔네, 정상!" 하고 넘어갈 수 없는 상황이 된 것이죠. 그래서 이번에 Airflow, MySQL, 그리고 Teams Adaptive Card를 엮어, 오탐(False Positive) 없이 정확하게 장애 차원을 집어내는 다차원 정합성 모니터링 및 데일리 리포트 시스템을 새롭게 구축했습니다.

그 과정에서 겪었던 쿼리 튜닝, DB 설계, 그리고 알림 피로도를 줄이기 위한 엔지니어링적 고민을 공유해 보고자 합니다.

1. 기존 로그 모니터링의 한계와 다차원 집계의 필요

앞서 말했듯이 정합성 모니터링이나 로그의 누락에 대해서 모니터링을 아예 안하진 않았습니다. 기존에는 단순히 오늘 몇 건이 들어왔으며, 어제와 비교해서 얼마 정도의 증가/하락정도를 권역별 테이블별로 보여줬습니다.

이렇게 함으로써 데이터가 들어오지 않은 경우 다음날 바로 알고 조치가 가능 했습니다. (이 로그는 일 배 치입니다.) 그래서 데이터의 누락이 없이 꼼꼼하게 건수 체크를 함으로써 누락이 발생하지 않도록 최소한의 장치를 마련하였습니다. 이렇게 하면 적어도 데이터가 아예 안 들어온 경우는 잡을 수 있었습니다.

하지만 이렇게 될 경우 특정 로그나 또는 데이터가 유실되어 들어오는 경우는 알수가 없었습니다. 물론 증감/하락이 매우 뚜렷하면 알 수는 있지만 어디까지나 전날과 비교하므로, 무언가 잘못되었다고 알기는 쉽지 않았습니다. 그래서 조금 더 세부적으로 알고 싶다는 생각이 들었고, 내가 만든 건수 체크 모니터링이 정말 문제가 없나?라는 생각이 들었습니다.

그래서 단순히 전날 -> 오늘 건수를 보여주고, 비교하는 로직을 벗어나서 몇가지 로직을 더 추가하였습니다.

2. 기존보다 더욱 세분화 된 모니터링

2.1. 모니터링의 세분화

일단 첫번째로 집계의 깊이( Depth)를 더욱 세분화하였습니다. 기존에는 권역 / 테이블 / 일자 이렇게 3개의 GROUP BY로 집계를 하였다면, 이번에는 로그타입 대분류 / 로그타입 소분류 / 국가까지 총 6개의 GROUP BY로 묶었습니다. 이렇게 되면 더욱 세분화하여 특정 로그타입과 특정 국가에서 로그가 유실되거나 로그의 문제를 감지 가능 합니다.

기존에는 하나의 테이블 단위로만 로그를 감지 하였다면 이번에는 로그타입과 세부타입 그리고 국가까지 볼 수 있습니다. 이렇게 됨으로써 사용자는 자신에 맞게 필요한 로그의 정합성을 더욱 쉽게 알 수 있습니다.

2.2. 로그의 추세 모니터링

앞서 말한것과 같이 전날 -> 오늘 이렇게 두 개의 날짜만 비교하다 보니 추세를 각 개인이 봐야 했습니다. 기존에는 이렇게 추세를 볼 수 있는 모니터링 대시보드는 제가 만들어서 제공하고 있었습니다.

하지만 본인이 보는 로그가 굉장히 중요하다면 일일이 들어가서 확인 하겠지만 모두 본업이 있고, 매일 들어가서 보는 것은 생각보다 쉽지 않습니다. 개인이 하나씩 챙겨 보기는 생각보다 어렵다 보니 알림을 주는 형태로 가는 게 맞다고 판단하였습니다. 그래서 일주일치의 로그의 평균을 내고 거기에서 너무 심한 등락이 있는 경우를 추적하는 것으로 만들면 좋겠다고 생각하였습니다.

3. Airflow & Databricks 기반 로그 정합성 모니터링 아키텍처

막상 그리고보니 엄청 대단한 아키텍처는 아닌데, 간단하게 그리면 위와 같이 만들었습니다.

각 Databricks에서 api/2.0/sql/statements를 통해서 각 테이블을 조회합니다. 집계 SQL의 경우 각각의 테이블이 다르고 칼럼명이 다르기 때문에 각각 폴더를 만들어서 파라미터 형태로 불러오도록 SQL 파일로 저장하여 사용하였습니다.

각각의 형식에 맞게 저장 된 SQL을 통해서 api를 이용해서 Databricks에서 테이블을 조회하여 각각 테이블의 세부적인 적재 현황을 집계하여 RDS에 적재합니다. 적재된 내역을 이용해서 Role 기반으로 정합모니터링을 하고, 기본적인 건수 체크 로직을 합니다. 여기에서 발생된 내역을 Teams 알림을 통해서 발송합니다. 필요하면 각 담당자를 호출할 수도 있지만 대개 많은 회사에서 그렇듯이 1차 담당자 (데이터 적재 담당자)가 확인합니다.

추가적으로 세부적인 내역을 확인하기 위해서 Databricks의 Redash를 이용해서 지표화를 하였습니다. 이후에 설명 하겠지만 Teams 알림으로는 세부내역을 볼 수 없습니다. Teams의 경우는 알림의 용도가 크기 때문에 리포팅을 할 경우 payload의 글자수 제한으로 일부밖에 보낼 수 없습니다. 그렇기에 심각도에 따라서 순위를 주어서 잘라서 일부만 보내도록 하였습니다.

아래와 같이 일부의 내역만 우선 Teams 메시지에서 노출하고 혹시라도 본인이 보는 로그에 이상이 있는 경우에 Databricks의 Redash를 통해서 보도록 유도 하였습니다. (아래쪽에 하이퍼링크 링크를 걸었습니다.)

그리고 아래와 같이 더욱 세부적으로 보기를 유도하여 대시보드에서 각각의 로그의 세부 항목과 국가까지 보도록 만들었습니다. 물론 심각한 로그의 경우는 알림에서 보여지도록 만들었습니다.

4. 대용량 로그 집계 시 트러블슈팅: 비용 최적화와 알림 피로도 해결

4.1. 집계 비용

처음에 든 생각으로는 단순히 GROUP BY 집계에 칼럼 몇 개 추가라고 생각했습니다. 그런 게 놓친 게 있습니다. 로그의 적재 건수가 너무나도 많았고 (수십억 건) 이를 집계하는 것도 자원이 필요하였습니다. 그리고 모니터링을 위해서 비용을 너무 많이 쓴다면 배보다 배꼽이 더 큰 상황이었습니다.

그래서 첫번쨰 아이디어를 낸 게 Databricks에 Delta Table로 데이터를 저장하기 전에 "원천 데이터 파일을 읽어서 데이터를 검증하고 이걸 넣자"로 생각해냈습니다. 제가 만든 적재 파이프라인의 경우 (적재도 제가 만들었기에 가능한 이야기) 로그 자체를 필터 하진 않습니다. 원천 자체가 parquet라서 csv , text 같은 파일이 아니므로, 일단 깨지지 않았고, (파일이 깨지면 아예 그 파일이 문제지...) 100% 모두 넣는 것을 원칙으로 만들었기에 오히려 이게 가능했습니다.

만약에 적재 과정에서 데이터 클렌징과 필터 작업이 있다면, 당연히 적재 이후에 집계를 해야 합니다. 저 같은 경우 적재가 N -> N으로 그대로 가기 때문에 이 방법은 고안 하였습니다. 그리고 현재 저희 데이터의 특성상 일자별로 파티션이 아니고 월자별 파티션이라서 이 방법이 최선이라고 생각했습니다.

4.2. 너무 세분화된 데이터의 잘못된 알림

앞서 말한 대로 세분화하여 집계를 하다 보니 허점이 생겼습니다. 예를 들어서 A 타입의 로그가 전날 2건이 들어왔는데 오늘 0건이면 이건 과연 유실인가? 였습니다. 로그의 특성이 모두 다르고 패턴이 다른데 이렇게 로그의 발생 건수가 너무도 낮은 경우 자칫 사용자들에게 너무 많은 알림으로 인해서 알림 피로가 발생할 것 같았습니다.

그래서 과감하게 로그 건수 1,000건 이하의 로그는 집계는 하지만 알림에서 제외하였습니다. 1,000건 이하의 경우 아직 테스트 단계의 로그일수도 있고 빈도수가 매우 적어서 이것이 대시보드나 다른 AX 관점에서 활용될 가치가 적을 수 있다고 판단하여, 알림에서는 과감하게 제외 하였습니다. (어디까지나 저의 생각입니다.)

그리고 이렇게 작은 건수 이외에도 로그의 타입에 따라서 등록이 너무 심각하게 많은 경우가 있을 수 있어서 등락 조정이 조금 어려웠습니다. 저의 경우 로그에서 50% 이상 상승/하락인 경우 알림 대상으로 고정하였습니다. 이 정도면 꽤나 많은 유실이나 중복일 수 있으므로 충분히 검토가 필요하다고 판단하였습니다.

4.3. 더욱 세분화 및 맞춤의 한계

위의 내용을 모두 메타 테이블을 만들거나 yaml 파일을 만들어서 각각 체계적으로 관리를 하고 싶었지만 앞서 말한 대로 너무나도 세부적인 집계의 경우 비용의 한계가 분명히 있었습니다. 또한 현재 로그의 종류가 수천 개가 넘어가는데, 이 모든 로그의 생성자가 다르고, 역사가 있는데 모든 것을 혼자 감당하기는 어렵다고 판단하였습니다.

제가 데이터 신뢰성 엔지니어만 하는 직군이거나 아니면 담당자라면 더욱 세분화하여 할 수 있었을 것 같기도 합니다. 하지만 시간/비용적 이슈로 인해서 어느 정도까지만 세분화가 가능한 것은 분명한 한계였습니다.

5. 앞으로 개선하고자 하는 것은?

5.1. Databricks Lakebase 교체

개선점은 굉장히 명확합니다. 우선 AWS RDS의 경우 한계점이 많이 있습니다. 우선 성능상 문제입니다. 모니터링을 위해서 좋은 스펙을 쓰기도 굉장히 애매하고 집계 및 조회등에 한계가 있으므로, Databricks에서 제공하는 Lakebase로 교체를 하고자 합니다. 이렇게 되면 플랫폼 자체가 통일되기 때문에 네트워크를 이용할 필요도 없고 안정성 측면에서도 굉장히 많은 이점이 있으며, 관리 포인트도 많이 줄어든다고 생각합니다.

5.2. Meta Table 개발

Meta Table 또는 yaml 파일을 이용해서 단순히 정해진 Role이 아니고, 세부적으로 각 로그마다 특성에 맞게 데이터를 저장하여 감지하도록 할 수 있습니다. 예를 들면 A 로그의 경우 굉장히 민감한 장애 코드 로그라서 잘 발생하지 않지만 발생한다면 매우 중요하므로 알림을 받고 싶다고 하는 사람이 나타나면 이것을 Meta에 저장하고 알림을 받도록 할 수 있습니다. 또한 앞서 말한 등락이 심한 로그도 특정 요일 특정 일 특정 달 같은 부분을 Meta에 저장하고 각각의 상황에서 맞게 관리가 가능합니다.

5.3. Role & AI를 이용한 이상 탐지

현재는 단순하게 정해진 Role에만 의존한다면 AI를 이용해서 AI가 판단해서 할 수도 있습니다. 기존에 만들었던 개인정보 모니터링의 경우도 AI를 활용하여하였듯이 AI를 활용하여 각각의 로그를 판단하여 검증이 가능합니다. 위의 Meta에 해당 정보를 넣고 Role 기반으로 1차 체크 후 2차로 AI를 통한 체크도 가능 합니다.

5.4. 알림 개별화

위의 모든 부분을 충족하면 개발적 알림 메시지도 가능할 것으로 보입니다. 각각의 요구 사항을 받아서 Meta에 미리 넣어두면 각각의 알림 대상자에게 어느 상황에 알림을 발송할지 AI가 판단하고 알림의 개별화가 가능합니다. 이렇게 되면 단순히 A 로그가 들어오지 않았다. A로그가 적게 들어왔다. 이런 단순한 알림을 넘어서 A로그가 이번 달에 적게 무슨 이유로 적게 들어왔다. 등의 내용도 알 수 있습니다.

6. 추가적으로 개발해야 하는 것들

지금까지 위의 모든 내용의 경우 로그가 잘 들어왔냐의 초점을 맞춥니다. 조금 더 상세하게 말하면 그 로그가 100건인데, 100건이 그대로 우리에게 왔는가? 에 포커스를 맞췄습니다. 하지만 이것은 너무나 초기적인 모니터링입니다.

저는 앞으로 더욱 나아가서 해당 칼럼마다의 NULL의 비율이나 해당 일자로 데이터가 정확하게 들어왔는가? 추가적으로 값에는 이상이 없는지가 중요한 포커스라고 봅니다.

데이터가 들어온 건 알겠는데 정확히 들어왔어?

제가 앞으로 해보고 싶은 것은 위에 대한 질문에 대한 대답입니다. 지금까지는 단순히 건수에 집중하는 건수의 세분화된 로그 탐지였다면, 이제는 그 로그의 내용을 보는 모니터링을 만들고자 합니다. 하지만 이 역시 앞서 말한 한계점으로 비용의 문제가 가장 큰 거 같습니다. 집계된 로그를 보고 AI를 통한 검증의 경우 집계를 하였으므로 몇백 ~ 몇천 건으로 끝날 수 있습니다.

하지만 각 Row를 검증하는 것은 이야기가 다르다고 생각합니다. 모든 Row를 AI로 검증하면 너무나도 편하겠지만 이건 어디까지만 꿈의 이야기 같습니다. 저 같은 경우 추후에 앞서 말한 Meta Table을 이용해서 Role기반으로 한번 검증 이후에 나오는 데이터를 AI를 통해서 재검증하는 시스템으로 진화하고자 합니다.

지금 현재는 집계된 데이터를 검증이었다면 이후에는 집계되지 않은 데이터를 검증하여 데이터 신뢰성을 더욱더 높이고자 합니다. 이렇게 되면 AX에서 사용될 데이터를 더욱 신뢰하며 사용이 가능할 것으로 보입니다.

마치며

바야흐로 AX의 시대인 거 같습니다. AX를 안 하면 죽는 것 같이 모두들 말합니다. 하지만 저는 AX가 잘 작동하려면 데이터가 그만큼 잘 적재되고 그만큼 신뢰가 가야 한다고 봅니다. 그렇기에 데이터엔지니어가 AI를 통해서 AX를 못하면 큰일 난다가 아니고 데이터 엔지니어가 이제는 더욱 세분화되어서 업무를 하는 형태로 진화할 것으로 보입니다.

그래서 계속해서 데이터 신뢰성에 대해서 공부하고자 하며, 이러한 작업 중에 일부가 이번 글의 핵심이라고 생각됩니다. AI는 내부의 데이터를 이용해서 의사 결정을 해야 하는데, 내부의 데이터가 잘못되었거나 들어오지 않았다면, 판단은 당연히 잘못될 수밖에 없습니다.

앞으로도 더욱 많은 데이터 신뢰성 관련 글을 작성하도록 하겠습니다. 긴 글 읽어 주셔서 감사합니다.

[Databricks] 멀티 리전 Delta Table 최적화: OPTIMIZE & VACUUM 자동화 파이프라인 구축기

주형권 — Fri, 19 Jun 2026 14:01:52 +0900

이 글의 핵심 요약 (Key Takeaways)

멀티 리전 Databricks 환경에서 발생하는 고질적인 'Small File 문제'와 스토리지 낭비를 해결하기 위해, 메타데이터 기반으로 OPTIMIZE & VACUUM 작업을 완전히 자동화한 데이터 파이프라인 구축기입니다. 본 글에서는 수백 개의 분산된 델타 테이블 중 정리가 필요한 대상 테이블을 자동으로 판별하는 동적 메타데이터 관리 기법, 데이터 유실 없이 디스크 용량을 확보하는 안전한 VACUUM 자동화 아키텍처, 그리고 멀티 리전 간의 효율적인 배치 최적화 노하우를 실무 코드와 함께 다룹니다.

안녕하세요. 주형권입니다.
최근 Databricks 환경을 운영하면서 피할 수 없는 숙명과도 같은 문제를 마주했습니다. 바로 데이터 엔지니어들의 영원한 골칫거리인 Small File 문제입니다. 현재 팀에서는 여러 글로벌 워크스페이스(멀티 리전)를 운영 중인데, 데이터가 쌓이고 MERGE가 빈번해지다 보니 파일들이 끝없이 잘게 쪼개지기 시작했습니다.

수동으로 치우는 것도 한계가 있다. 시스템이 알아서 찾고, 알아서 청소하게 만들자.

평균 파일 사이즈가 5MB에서 130MB 수준으로 파편화되니 성능이 떨어지는 건 당연한 수순이었습니다.(심지어 저희는 삭제도 합니다.) 매번 수동으로 OPTIMIZE와 VACUUM을 돌리는 건 비효율의 극치이며, 수백 개의 테이블 중 당장 어떤 테이블이 문제인지 파악하기도 어렵습니다. 그래서 매주 주 주말, 스스로 대상을 찾아내서 최적화를 수행하는 자동화 파이프라인을 만들기로 결심했습니다.

⚠️ 잠깐, Small File이 대체 왜 문제일까?
본격적인 파이프라인 구축기에 앞서, 파일 크기가 작은 것이 왜 문제가 되는지, 그리고 왜 일회성 정리가 아닌 꾸준한 관리가 필요한지 짧게 짚고 넘어가겠습니다.

1. 숨 막히는 Metadata 오버헤드와 I/O 병목 Spark 클러스터가 데이터를 읽을 때, 실제 데이터를 처리하는 시간보다 수만 개의 자잘한 파일 목록(List)을 읽어오고 각 파일에 대한 네트워크 커넥션을 맺고 끊는 데(Open/Close) 더 많은 시간을 허비하게 됩니다. 극단적으로 말해 1GB짜리 파일 1개를 읽는 것보다, 1MB짜리 파일 1,000개를 읽는 것이 훨씬 느리고 클러스터의 Driver 노드에 엄청난 메모리 부하(OOM)를 유발합니다. 또한 클라우드 스토리지(S3 등)의 API 호출 횟수도 급증하여 불필요한 비용이 발생합니다.

2. Delta Lake의 숙명: "변경할 때마다 파일은 늘어난다"Databricks의 근간인 Delta Lake는 데이터의 일관성을 유지하기 위해 MVCC(Multi-Version Concurrency Control) 방식을 사용합니다. 즉, 기존 데이터를 UPDATE 하거나 DELETE 할 때 원본 파일을 직접 수정하지 않고, 새로운 데이터 파일을 만들고 기존 파일은 논리적으로 무효화(Tombstone) 시킵니다.또한, 실시간이나 마이크로 배치로 데이터가 계속(Streaming) 들어오게 되면 필연적으로 작은 파일들이 우후죽순 생성될 수밖에 없는 구조입니다.

결국, 데이터를 활발하게 변경하고 적재하는 살아있는 플랫폼일수록 Small File은 끊임없이 증식합니다. 이것이 바로 우리가 일회성 수동 정리가 아닌, "지속적이고 자동화된 관리 파이프라인"을 구축해야만 했던 이유입니다.

1. 비용과 안정성을 고려한 아키텍처 설계

처음 설계를 시작할 때 가장 중요하게 생각한 건 "안전장치"와 "비용 효율성"이었습니다. Databricks의 컴퓨팅 자원도 결국 비용입니다. 무작정 전체 테이블을 대상으로 OPTIMIZE를 수행하면 그 비용의 압박은 고스란히 엔지니어에게 돌아옵니다. (이걸 하는 이유도 비용인데...)

따라서 다음과 같은 4가지 핵심 설계 원칙을 세웠습니다.

각 워크스페이스 독립 실행
멀티 리전 간의 불필요한 의존성을 없애고, 크로스 워크스페이스 API 호출 없이 각 환경에서 로컬로 완결되도록 구성했습니다.
자동 후보 선정
무분별한 실행이 아닌, information_schema와 DESCRIBE DETAIL을 활용해 실시간으로 테이블 상태를 진단하여 꼭 필요한 대상만 추려냅니다.
우선순위 기반 처리
CRITICAL ➔ WARNING ➔ VACUUM_ONLY 순으로 상태별 심각도를 나누어 시급한 대상부터 우선 처리합니다.
실행 로그 중앙화
결과를 테이블에 저장해서 언제든 실행 이력을 추적할 수 있도록 구성했습니다.

이를 바탕으로 설계한 전체 아키텍처는 다음과 같습니다. 토요일 오전 9시가 되면 각 워크스페이스의 스케줄러가 알아서 진단, 최적화, 로깅까지 한 사이클을 돌고 종료되는 구조입니다. 사실 아래의 전체적인 아키텍처를 보면 구조가 굉장히 단순합니다. 각각 Workspace에서 독립적으로 수행하고 이를 각각의 로그 테이블에 저장하고 주기적으로 중앙에 로그를 쏘는 구조입니다.

자동 Optimize / VACCUM 아키텍처

중앙 Workspace에 하나로 로그를 모두 모은 이유는 추후에 Report 시스템이나 대시보드를 만들거나 알림을 주기 위해서 한번에 모았습니다. 중앙 Workspace에서 데이터를 모아서 한 번에 조작을 해야지 추후에 뭘 하든 편하기 때문입니다.

2. Optimize / VACCUM 대상 테이블 선정

어느 워크스페이스에 배포해도 코드 수정 없이 동작하도록 단일 노트북(5개 Cell)으로 파이프라인을 구성했습니다. 그중에서 가장 공들인 부분은 단연 후보 진단 로직입니다. 해당 로직은 노트북 상단 셀에 아래와 같이 구성했습니다. (128 ~ 512MB로 로직을 만든 이유는 위의 Small파일 부분에 설명)

먼저, 클러스터 환경에 상관없이 파라미터를 받고 리전을 판별하는 초기 설정 코드입니다.

import time
from datetime import datetime

# 1. 위젯 파라미터 설정
dbutils.widgets.text("dry_run", "true", "Dry Run Mode")
dbutils.widgets.text("max_table_size_gb", "500", "Max Table Size (GB)")
dbutils.widgets.text("min_table_size_gb", "10", "Min Table Size (GB)")
dbutils.widgets.text("optimize_timeout_min", "180", "Optimize Timeout (min)")

dry_run = dbutils.widgets.get("dry_run").strip().lower() == "true"
max_table_size_gb = int(dbutils.widgets.get("max_table_size_gb"))
min_table_size_gb = int(dbutils.widgets.get("min_table_size_gb"))
timeout_seconds = int(dbutils.widgets.get("optimize_timeout_min")) * 60

# 2. 워크스페이스 URL 기반 리전 자동 판별
workspace_url = spark.conf.get("spark.databricks.workspaceUrl", "")
if "a" in workspace_url:
    region_prefix = "a_"
elif "b" in workspace_url:
    region_prefix = "b_"
else:
    region_prefix = "c_"

start_time = time.time()

가장 공들인 부분은 단연 후보 진단 로직입니다. information_schema를 통해 대상을 수집하고 DESCRIBE DETAIL로 실제 사이즈를 진단합니다.

from pyspark.sql import Row

# Delta 테이블 목록 조회 및 Exclude 테이블 필터링 과정 생략...

candidates = []

# 3. 테이블별 상태 진단 및 후보 판별
for tbl in tables_df.collect():
    full_name = f"`{tbl.table_catalog}`.`{tbl.table_schema}`.`{tbl.table_name}`"
    detail = spark.sql(f"DESCRIBE DETAIL {full_name}").collect()[0]
    
    num_files = int(detail["numFiles"])
    size_bytes = int(detail["sizeInBytes"])
    size_gb = size_bytes / (1024**3)
    
    # 설정한 파라미터 사이즈 필터링
    if size_gb <= min_table_size_gb or size_gb >= max_table_size_gb or num_files <= 50:
        continue
        
    avg_file_mb = (size_bytes / num_files / (1024**2)) if num_files > 0 else 0
    is_candidate = False

    # 핵심 판별 로직: 사이즈 및 DML 이력 확인
    if avg_file_mb < 128:
        is_candidate = True
    elif avg_file_mb < 512:
        history = spark.sql(f"DESCRIBE HISTORY {full_name} LIMIT 50").collect()
        has_dml = any(h["operation"] in ("DELETE","UPDATE","MERGE") for h in history)
        if has_dml:
            is_candidate = True

    if is_candidate:
        candidates.append(Row(
            table_catalog=tbl.table_catalog, table_schema=tbl.table_schema, table_name=tbl.table_name, 
            avg_file_size_mb=avg_file_mb, size_gb=size_gb, num_files=num_files
        ))

# 결과를 Temp View로 저장하여 다음 작업으로 전달
spark.createDataFrame(candidates).createOrReplaceTempView("optimize_candidates")

이 로직을 보면 임계값이 1GB가 아닌 512MB로 설정되어 있습니다. 여기에는 비용과 효율을 고려한 설계 의도가 담겨 있습니다.

128MB 미만 (무조건 실행): 이미 Small File 문제가 심각한 상태이므로, 히스토리를 묻고 따질 것 없이 무조건 OPTIMIZE 대상으로 편입시킵니다.
128MB ~ 512MB 구간 (DML 이력 확인): 사실 512MB 수준만 되어도 읽기(I/O) 성능상 큰 무리가 없습니다. 단순 쿼리 성능 향상만을 위해 이 큰 파일들을 1GB로 합치는 작업은 컴퓨팅 비용 낭비입니다. 하지만 최근 트랜잭션에 DML(DELETE, UPDATE, MERGE) 이력이 있다면, 논리적으로 삭제된 가비지 파일들이 S3에 대량으로 쌓여 스토리지 비용을 갉아먹고 있을 확률이 높습니다. 따라서 이 구간은 가비지 파일을 지우는 VACUUM 효율 극대화에 초점을 맞추어 대상을 선정합니다.
512MB 이상 (대상 제외): 이상적인 파일 포맷을 유지하고 있는 상태이므로, 굳이 컴퓨팅 비용을 들여 재배치하지 않도록 원천 제외했습니다.

3. 설계 과정에서 겪은 이슈들 ‍♂️

머릿속의 설계가 한 번에 매끄럽게 돌아가는 법은 없습니다. 이번에도 예상치 못한 변수들을 마주했습니다.

이슈	원인 및 해결 과정
네트워크 차단 (VPC 방화벽)	초기에 중앙 Workspace에서 통합 제어 하려 하였으나 API 호출이 방화벽에 의해 차단된 것을 발견 ➔ 하지만 각각의 Workspace에서 중앙 Workspace로 보내는 Outbound는 열려 있음을 확인 ➔ 이를 기반으로 각자 독립 실행 후 로그를 저장하고 중앙 Workspace로 보내서 관리 하도록 설정 물론 앞서 말한것과 같이 중앙에서 관리 해야지 알림/대시보드등 만들기 편함도 있었습니다. 결국 내가 Romote 실행이냐 수행하고 보내주느냐의 차이였던거 같습니다. 나중에 각 Workspace에서 로그를 남기면 여러 Workspace에서 Job을 관리 해야하므로 귀찮긴 했지만 이것을 위해서 네트워크를 허용하는 것은 너무 리스크가 크다고 판단 하였습니다.
너무 큰 테이블	너무 큰 테이블의 경우 (1TB 이상) 각각 따로 Optimize와 VACCUM을 수행 하도록 하였습니다. 이 테이블들의 경우 모두 크기가 크고 주요 테이블인 경우가 많아서 따로 처리 하였으며, 자동화에서 제외 하도록 예외처리 테이블을 만들었습니다. (해당 테이블은 자동 Optimize / VACCUM 안함)
적재/삭제/변경 동시성 이슈	이게 제일 고민이였는데, Optimize / VACCUM을 할때 테이블에 작업을 하면 동시성 이슈로 인해서 실패 합니다. Databricks의 경우 ACID를 보장 하기 때문에 이 작업을 할때 SELECT 이외에 작업을 하면 실패하 하는 경우가 여럿 있었습니다. 그래서 최대한 주말에 적재 없는 시간을 확인하여 오전 시간에 하도록 하였습니다. 또한 주 1회만 하여 최대한 비용과 스케줄 겹침(?) 현상을 최소화 하였습니다. 추가적으로 Timeout 시간을 변수로 받아서 최대 시간을 조정 하였습니다.
비용 이슈	역시 문제는 돈 입니다. 뭘 하든 돈이 필요하고, 이 작업도 큰 테이블인 경우 또는 Small 파일이 많으면 큰 컴퓨팅이 필요하며, 오래 걸립니다. 실제로 수십 TB 테이블의 경우 1시간 이상 소요됩니다. (매주 1시간 이상) 그래서 이것도 배보다 배꼽이 큰 경우가 발생 할 수 있습니다. 그래서 아래에서 다시 언급 하겠지만 dry_run을 통해서 최대한 비용과 시간을 예측해서 작업을 진행 하였습니다.

사실 별로 신경을 안 쓰면 이슈가 아닐 수도 있는데, 이 작업은 운영 작업이다 보니 적재나 삭제등과 같이 필수 작업에 영향을 최소로 해야 했습니다. Optimize와 VACCUM 자체가 엄청나게 어려운 작업이 아니지만 (아닐 수도 있지만) 이것으로 인해서 중요한 작업이 안되면 큰 이슈가 있기에 신중을 기해서 만들었습니다.

4. 실제 수행해 보기 : Job 설정 및 dry_run 결과

모든 구성을 마치고, 파이프라인을 Databricks Job으로 등록했습니다. Job의 안정성과 유연성을 확보하기 위해, 노트북의 핵심 설정값들을 아래와 같이 위젯 파라미터로 추출하여 관리했습니다.

파라미터 (Parameter)	설정값	설계 의도
dry_run	false	안전장치. true로 설정하면 실제 OPTIMIZE/VACUUM 없이 시뮬레이션만 수행하여, 운영 환경에 적용하기 전 안전하게 결과를 예측할 수 있습니다.
max_table_size_gb	500	비용 통제. 실수로 수십 TB가 넘는 초대형 테이블에 OPTIMIZE가 실행되어 과도한 비용이 발생하는 것을 막기 위한 상한선입니다. 위에서 1TB라고 하였는데, 조금 걱정되서 우선 500GB로 설정 했습니다.
min_table_size_gb	10	효율성. 10GB 미만의 아주 작은 테이블은 최적화 대상에서 제외하여, Job이 더 중요한 테이블에 집중하도록 합니다.
optimize_timeout_min	180	예산 및 시간 관리. Job의 최대 실행 시간을 3시간으로 제한하여, 예기치 못한 이슈로 Job이 무한정 실행되는 것을 방지합니다.

이를 바탕으로 실제 최적화와 로깅을 수행하는 실행 루프 코드는 다음과 같이 구성했습니다. 타임아웃 조건을 체크하며 우선순위에 따라 직렬로 실행합니다.

def execute_optimize_vacuum(row, dry_run):
    full_table_name = f"`{row['table_catalog']}`.`{row['table_schema']}`.`{row['table_name']}`"
    
    if dry_run:
        return "SKIPPED (dry_run)"
        
    try:
        # OPTIMIZE 실행
        spark.sql(f"OPTIMIZE {full_table_name}")
        # 과거 Tombstone 파일 삭제 (7일 보존)
        spark.sql(f"VACUUM {full_table_name} RETAIN 168 HOURS")
        return "SUCCESS"
    except Exception as e:
        return f"FAILED: {str(e)[:100]}"

candidates = spark.table("optimize_candidates").collect()

# 우선순위 정렬 (CRITICAL -> WARNING -> VACUUM_ONLY)
critical = [r for r in candidates if r["avg_file_size_mb"] < 32]
warning = [r for r in candidates if 32 <= r["avg_file_size_mb"] < 128]
vacuum_only = [r for r in candidates if r["avg_file_size_mb"] >= 128]
sorted_candidates = critical + warning + vacuum_only

results = []
for idx, row in enumerate(sorted_candidates):
    if time.time() - start_time > timeout_seconds:
        print(f"Timeout reached. Stopping at {idx}/{len(sorted_candidates)}")
        break
        
    result_status = execute_optimize_vacuum(row, dry_run)
    results.append({"table_name": row["table_name"], "status": result_status})

# 결과를 로컬 모니터링 테이블에 Append
if results:
    from pyspark.sql.types import StructType, StructField, StringType
    schema = StructType([
        StructField("table_name", StringType(), True),
        StructField("status", StringType(), True)
    ])
    
    results_df = spark.createDataFrame(results, schema=schema)
    results_df.write.mode("append").saveAsTable("monitoring.governance.optimize_execution_log")

Job 운영 설정

스케줄: 매주 토요일 09:00 KST
클러스터: r5d.xlarge, Autoscale (2~10 workers) / 추후 소요시간에 따라 조정
타임아웃: 180분 (위 파라미터와 연동)

실제 적용 전, dry_run 파라미터를 true로 변경하여 AIC 환경을 먼저 스캔해 보았습니다.

[A 워크스페이스 dry_run 실행 결과]

스캔 대상 테이블: 160개 (Exclude 12개 제외)
최종 실행 후보: 19개
- CRITICAL (< 32MB): 5개
- WARNING (32~128MB): 12개 ⚠️
- VACUUM_ONLY (DML 이력 존재): 2개

결과는 예상보다 심각했습니다. 가장 상태가 좋지 않았던 테이블은 24,001개의 파일이 평균 4.89MB 단위로 파편화되어 있었습니다. 데이터 스캔 속도가 느려질 수밖에 없는 명확한 원인이었습니다.

확실히 테이블을 만드는 사람이 대다수고 이것을 관리하거나 하는 사람을 따로 두지 않으면 위와 같이 하나의 Workspace에서도 안 좋은 결과가 있을 수 있습니다. Optimize / VACCUM 작업이 어느 정도 자동으로 Databricks에서 해준다고 알고 있지만 어디까지나 한계는 존재하며 사람이 매번 할 수도 없습니다. 제가 생각했던 것보다 진짜 많은 테이블이 관리가 안 되는 것을 확인하고 조금 놀랐습니다.

5. 자동 리포팅 및 장애 알림 체계 구축

아무리 훌륭한 최적화 파이프라인을 구축했더라도, "매주 작업이 잘 돌았는지, 실패한 테이블은 없는지" 일일이 Databricks에 접속해 로그를 뒤져보는 것은 데이터 엔지니어에게 또 다른 운영 리소스 낭비입니다. 그래서 파이프라인 구축의 마지막 퍼즐로 Airflow를 활용한 이메일 자동 리포팅 체계를 얹었습니다. 매주 월요일 아침, 주말간 수행된 최적화 결과를 데이터플랫폼팀 전체가 한눈에 파악할 수 있도록 구성했습니다.

마무리 : 최적화 자동화가 가져다준 효과 ✨

파이프라인을 운영 환경에 배포하고 몇 주간 모니터링 로그를 지켜보며, 우리 팀은 기대 이상의 성과를 거둘 수 있었습니다. 단순히 눈에 보이는 수치 개선을 넘어, 데이터 엔지니어링의 본질적인 목적에 한 걸음 더 다가선 느낌입니다. 이번 최적화 자동화가 가져다준 효과는 크게 네 가지로 요약할 수 있습니다.

1. 쿼리 성능(Performance)의 극적인 향상
수만 개로 쪼개져 클러스터를 괴롭히던 Small File들이 128MB 이상의 건강한 크기로 압축(Compaction)되었습니다. 파일 스캔 시 발생하던 메타데이터 읽기 오버헤드와 I/O 병목이 해소되면서, 다운스트림 배치 Job과 분석가들의 대시보드 쿼리 속도가 체감할 수 있을 정도로 눈에 띄게 빨라졌습니다.

2. 낭비되는 스토리지 비용(Cost) 절감
Databricks에서 MERGE나 UPDATE가 발생할 때마다 보이지 않는 곳에 쌓여가던 과거의 데이터(Tombstone)들을 VACUUM을 통해 물리적으로 완벽히 걷어냈습니다. 이는 단순히 클라우드 요금 청구서를 줄이는 것을 넘어, 불필요한 데이터를 보관하지 않음으로써 시스템 전반의 효율을 높이는 건강한 체질 개선이었습니다.

3. 데이터 엔지니어의 운영 부담(Toil) 제로화
사실 가장 뿌듯한 부분입니다. 예전에는 주말마다 엔지니어가 직접 스파크 UI를 들여다보며 "어떤 테이블이 느려졌나?" 고민하고 수동으로 최적화 명령을 날려야 했습니다. 이제는 매주 토요일 아침, 스케줄러가 스스로 상태를 진단하고 가장 아픈 테이블부터 치료한 뒤 리포트(Log)만 남깁니다. 우리는 그저 월요일 출근 후 로그 테이블을 쓱 훑어보기만 하면 됩니다.

4. 멀티 리전 관리의 일관성 확보
AIC, EIC, KIC로 나뉜 3개의 거대한 워크스페이스를 하드코딩 하나 없이 단일 코드베이스로 제어할 수 있게 되었습니다. 향후 새로운 리전이나 워크스페이스가 추가되더라도 동일한 파이프라인을 그대로 배포하기만 하면 알아서 동작할 것입니다.

마치며...
이번 작업을 통해 다시 한번 느낀 것은, "데이터 플랫폼의 규모가 커질수록 백그라운드 관리 작업의 자동화는 선택이 아닌 생존의 문제"라는 점입니다. 데이터가 쌓이는 속도를 사람의 손으로 따라잡을 수는 없으니까요. 물론 이것으로 최적화의 모든 과제가 끝난 것은 아닙니다. 다음 스텝으로는 Z-Ordering을 적용해 쿼리의 Data Skipping 효율을 극대화하는 방안이나, 테이블의 특성(예: 시계열 데이터 vs 디멘전 데이터)에 따라 최적화 주기를 동적으로 조절하는 고도화 작업을 고민하고 있습니다.

당분간 Databricks의 Small File이라는 오랜 숙제에 대해서는 한시름 놓아도 될 것 같습니다. 비슷한 성능 이슈나 스토리지 비용 문제로 밤잠을 설치고 계신 데이터 엔지니어 동료분들께, 이 자동화 파이프라인 구축기가 작은 영감과 돌파구가 되기를 진심으로 바랍니다.

긴 글 읽어주셔서 감사합니다.

[DRE] Databricks 감사 로그 기반 데이터 거버넌스 자동화 시스템 구현

주형권 — Thu, 28 May 2026 09:26:46 +0900

이 글의 핵심 요약

무슨 문제인가: Databricks 글로벌/멀티 테넌트 환경을 운영하면서 비인가자의 접근, 불필요한 퍼스널 토큰 남용, 보안 취약점 노출을 수동으로 일일이 감시하기 어려웠음.
어떻게 해결했나: Databricks가 생성하는 시스템 감사 로그(Audit Log)를 자동으로 수집·적재하고, Python API와 Teams 알림을 연동하여 비인가 접근 및 보안 위협을 실시간으로 감지하는 데이터 거버넌스 자동화 시스템을 구축함.
무슨 효과를 얻었나: 보안 감사(Audit) 업무를 100% 자동화하여 리소스를 제로화하고, 개인정보(PII) 유출 및 비인가 토큰 사용 등 데이터 플랫폼의 보안 위협을 실시간으로 철통 방어함.

안녕하세요, 주형권입니다. 정말 오랜만에 블로그로 인사 드립니다.

그동안 밀려드는 현업과 하루가 다르게 쏟아지는 AI 기술들을 쫓아가느라 도무지 글을 쓸 여유가 없었습니다. 그리고 개인적으로 '2세 탄생'이라는 제 인생 최고의 축복이자 엄청난 변화까지 맞이하면서, 하루하루가 어떻게 지나가는지 모를 정도로 치열하고 정신없는 시간을 보냈습니다.

하지만 그렇게 육아와 업무, 그리고 새벽 스터디를 병행하며 보낸 시간들이 모여 꽤 의미 있는 결과물을 만들어 냈습니다. 오랜만의 복귀인 만큼, 그동안 빈 화면에 쌓아두기만 했던 저만의 실전 인사이트를 꾹꾹 눌러 담아 더욱 깊고 알찬 내용으로 돌아왔습니다.

오늘 이야기할 주제는 바로 데이터 플랫폼의 심장, Databricks 글로벌 환경에서의 철통 보안 자동화입니다.

왜 이 시스템을 직접 만들었을까?

최근 데이터 기반 의사결정이 기업의 핵심이 되면서, Databricks는 저희 데이터 플랫폼의 중심으로 굳건히 자리 잡았습니다. 하지만 글로벌 서비스를 운영하며 여러 리전(한국, 미국, 유럽 등)에 분산된 워크스페이스를 관리하다 보니 심각한 고민이 생겼습니다.

바로 "민감한 개인정보(PII)를 어떻게 안전하게 보호하고, 전 세계에서 들어오는 비인가 접근을 어떻게 중앙에서 통제할 것인가?" 였습니다.

시중에는 훌륭한 상용 보안 솔루션들이 많지만, 도입 비용이 수천만 원에 달하거나 아키텍처가 너무 무거워진다는 단점이 있었습니다. 그래서 저는 데이터 엔지니어의 관점에서 접근했습니다. "기존 인프라(Airflow)와 Databricks의 Native 기능, 그리고 AI를 활용해 월 $25 이하의 극단적으로 낮은 비용으로 강력한 데이터 거버넌스를 확보해 보자" 라는 생각으로 해당 프로젝트를 진행 했습니다. 그렇게 탄생한 저의 글로벌 3개 리전 보안 모니터링 파이프라인 구축 노하우를 지금부터 본격적으로 공유합니다.

️ 1. 아키텍처에 녹여낸 4가지 핵심 보안 철학

이 시스템은 단순히 로그를 모으는 것을 넘어, 철저한 사내 보안 원칙을 아키텍처 전체에 녹여냈습니다.

보안 원칙	상세 내용 및 구현 방안
Zero Trust Network	모든 IP는 기본적으로 비인가 상태로 간주하며, Unity Catalog 내 화이트리스트(ip_whitelist)에 명시적으로 등록된 IP만 허용합니다.
최소 권한 원칙 (Least Privilege)	PII 데이터는 업무 목적에 한해 접근 가능하며, 로컬 다운로드나 외부 스토리지 등 Databricks 외부로의 반출은 원칙적으로 금지합니다.
실시간 감사 (Continuous Auditing)	글로벌 전체 워크스페이스의 시스템 감사 로그(system.access.audit)를 Airflow로 스케줄링하여 자동 스캔합니다. ( 실무 Tip: Databricks 시스템 테이블 로그가 최대 3시간까지 지연 적재되는 현상이 있어, 1시간 주기로 돌되 6~24시간 앞부분의 로그를 넉넉하게 덮어쓰며 스캔하는 멱등성(Idempotency) 방식을 택했습니다.)
책임 추적성 (Accountability)	위반 감지 시 즉시 Teams 알림과 함께 *계정 소유자를 직접 멘션(@)*하여 소명 의무를 부여합니다. 골든타임을 놓치지 않는 것이 핵심입니다.

⚙️ 2. 듀얼 파이프라인 아키텍처: 어떻게 탐지하는가?

이 시스템은 PII 접근 모니터링과 비인가 IP 접속 모니터링이라는 두 가지 파이프라인으로 나뉩니다. 위반 종류는 다르지만, 본질적인 흐름은 [로그 수집 ➡️ 위반 판정 ➡️ Teams 알림 및 중앙 집계(KR)]라는 일관된 패턴을 갖도록 설계하여 향후 유지보수와 확장을 극도로 단순화했습니다.

실제 아키텍처

Architecture Point: 확장성을 고려한 단일화된 설계 패턴
아키텍처 다이어그램을 보면 알 수 있듯, 저는 두 가지 복잡한 보안 위협(PII 접근, 비인가 IP 접속)을 다루고 있지만 전체 시스템의 구조는 놀랍도록 단순하고 일관되게 설계했습니다. 위반 종류는 다르지만 본질적인 흐름은 [로그 수집(Databricks) ➡️ 위반 판정(AI/규칙) ➡️ Teams 알림 및 중앙 집계(Unity Catalog)]라는 하나의 단일 파이프라인 패턴을 공유합니다.덕분에 향후 새로운 형태의 보안 위협 모니터링 규칙이 추가되더라도, 이 견고한 뼈대 위에 레고 블록처럼 손쉽게 얹을 수 있는 강력한 확장성을 자랑합니다.

️ 파이프라인 1: AI 기반 PII(개인정보) 접근 모니터링

단순히 특정 테이블을 조회했는지가 아니라, 어떤 데이터에, '어떤 의도'로 쿼리를 실행했는지가 핵심입니다. 이 파이프라인을 정교하게 구축하기 위해, 저희는 로그를 수집하기 전 가장 먼저 데이터 자산 전체에 대한 철저한 분류 작업부터 시작했습니다.

사전 PII 컬럼 태깅 (Data Tagging):
단순히 이름, 이메일, 전화번호 등 범용적인 개인정보뿐만 아니라, 시스템이 쉽게 인지하기 어려운 우리 회사만의 특화된 민감 정보도 존재합니다. 단 하나의 개인정보 유출 사각지대도 남기지 않기 위해, 사내 수많은 테이블의 PII 관련 컬럼을 일일이 식별하고 명시적인 메타데이터 태그(Tag)를 부여하는 사전 작업을 완벽히 수행했습니다.
데이터 수집:
태깅된 메타데이터를 기반으로, 각 워크스페이스의 Query History API를 통해 사전에 정의된 PII 컬럼에 접근한 모든 쿼리 이력을 누락 없이 수집합니다.
AI(LLM) 의도 판정:
Databricks 내장 AI Functions(LLM)를 활용해 수집된 쿼리의 문맥을 분석합니다. 이를 통해 해당 쿼리가 내부적인 단순 분석용 조회(SAFE)인지, 아니면 외부 반출이나 파일 다운로드 등 규정 위반(VIOLATION) 시도인지 AI가 자동으로 의도를 분류합니다.
즉시 알림:
VIOLATION으로 판정될 경우, 파이프라인이 즉시 Teams Adaptive Card를 생성합니다. 위반 당사자를 직접 멘션하고, 어떤 테이블의 어떤 컬럼에 접근했는지에 대한 상세한 보안 경고를 발송합니다.

실제 개인정보 위반 Teams 메시지

파이프라인 2: KIC 중앙 집중형 비인가 IP 접속 모니터링

미국(US)과 유럽(EU) 등 글로벌 워크스페이스의 모든 접근 이력을 본사가 있는 한국(KR) 리전으로 모아 중앙에서 통제합니다.

이 파이프라인의 핵심은 '모든 접근을 의심한다'는 Zero Trust 사상을 바탕으로, 화이트리스트 테이블을 직접 구축하여 Databricks로 향하는 모든 IP 접속을 전수 감시하는 데 있습니다.

화이트리스트(Whitelist) 기반 전수 감시:
회사에서 인가된 정상 IP 및 CIDR 대역을 담은 중앙 화이트리스트 테이블(ip_whitelist)을 구축했습니다. 각 리전에서 발생하는 system.access.audit 감사 로그의 모든 IP 접속 이력을 이 화이트리스트와 1시간마다 전수 대조(Cross-check)합니다.
글로벌 탐지 및 로컬 저장:
전수 대조 결과, 화이트리스트에 명시적으로 등록되지 않은 모든 접속은 즉각 '비인가 IP'로 식별됩니다. 이렇게 탐지된 위반 내역은 우선 각 리전(한국, 미국, 유럽)의 로컬 Checkpoint 테이블에 1차로 저장됩니다.
한국(KR) 중앙 집계 (통합 증적 보존):
이후 파이프라인은 탐지된 글로벌 미수집 내역을 한국 리전의 통합 테이블(ip_access_consolidated)로 주기적으로 MERGE합니다. 이를 통해 전 세계에서 발생하는 모든 비인가 접근 이력을 본사 거버넌스 하에 단일 감사 증적으로 안전하게 보존합니다.
위험도 기반 자동 알림:
통합된 로그를 바탕으로 비인가 IP의 접속 횟수에 따라 위험도를 자동 등급화( Critical / High / Medium / Low)합니다. 위험도가 높은 의심 사례 탐지 시, Teams로 경고를 발송하고 즉시 데이터팀 주도의 소명 절차를 진행합니다.

️ 3. 기술 스택: 있는 것을 최대한 활용하라

새로운 툴을 도입하기보다, 이미 우리가 가진 무기들을 극한으로 활용하는 데 집중했습니다. 사실 이러한 시스템을 만들때 가장 중요한게 돈이라고 생각 합니다. 아무래도 새로운 솔루션 도입에는 한계가 있고 회사의 규모가 클수록 이러한 리스크를 감수하기 쉽지 않습니다.

️ 구분	사용 기술 및 도구
오케스트레이션	Apache Airflow (BashOperator, 1시간 주기 스케줄링) 어차피 audit 테이블이 데이터 동기화 주기가 3시간까지 지연되므로, 계속해서 6~10시간씩 이전의 데이터를 가져오므로, BashOperator를 사용해서 1시간마다 계속 호출 하였습니다.
데이터 소스 & 엔진	Databricks 시스템 테이블 (system.access.audit) / SQL Statements API (REST)
핵심 분석 로직	Python / Databricks 내장 LLM (PII 접근 의도 분류)
알림 채널	Microsoft Teams Incoming Webhook + Adaptive Cards (멘션 기능 포함)
데이터 거버넌스	Unity Catalog 관리형 Delta 테이블 (monitoring.governance.*)
인프라 환경	글로벌 3 Multi-Region Databricks Workspaces (한국, 미국, 유럽)

⏱️ 4. Incident 대응 프로세스 타임라인: 골든타임을 사수하는 자동화 플레이북

아무리 좋은 탐지 시스템이 있어도 사후 대응이 느리거나 담당자가 놓치면 아무 소용이 없습니다. 저희는 보안 위협이 탐지되었을 때 단 1초의 골든타임도 놓치지 않고 즉각 대응할 수 있도록, 인간의 개입을 최소화한 일관된 자동화 타임라인을 설계했습니다.

위반 사항이 감지되는 순간, 시스템은 아래 일련의 대응 프로세스를 마치 시계태엽처럼 물 흐르듯 실행합니다.

⏳ 단계	프로세스명	수행 내용
Step 1	자동 탐지	Apache Airflow가 1시간 주기로 글로벌 전체 리전의 감사 로그를 스캔하여 미소명 위반 패턴을 즉각 식별합니다.
Step 2	즉시 알림	위반 시각을 KST(한국 표준시) 기준으로 자동 변환하여 가독성을 높인 후, Teams Adaptive Card를 통해 위반 당사자와 보안 담당 채널에 실시간 경고를 발송합니다.
Step 3	소명 요청 및 트래킹	경고 발생과 동시에 위반자에게 즉각적인 소명 의무가 부여됩니다. 시스템은 위반 당사자가 정해진 기한 내에 소명 메일을 발송했는지 로그를 추적하기 시작합니다.
Step 4	중앙 집계 & 증적 보존	위반 내역과 이에 대한 조치 결과는 한국(KR) 리전의 통합 마스터 테이블에 MERGE 되어, 향후 외부 감사나 사내 보안 검토 시 제출할 수 있도록 단일 감사 증적(Single Source of Truth)으로 영구 보존됩니다. 추후에 대시보드를 만들기 위해서 하나의 리전으로 모두 데이터를 모았습니다.
Step 5	정기 리뷰 & 정책 피드백	한 달간 축적된 누적 보안 데이터를 바탕으로 자동화된 월간 보안 리포트를 발행합니다. 빈번하게 발생하는 위반 패턴을 분석하여 화이트리스트 정책을 정교하게 업데이트하고 거버넌스를 지속해서 개선합니다.

5. ROI 분석: 이것이 엔지니어링의 묘미다

가장 강조하고 싶은 부분은 바로 '압도적인 비용 효율성'입니다. 거창한 외부 솔루션 도입 없이 최적화된 아키텍처만으로 완벽한 통제 환경을 만들었습니다.

항목	상세 분석 및 비용 절감 포인트
컴퓨팅 비용 (DBU)	Databricks Serverless SQL Warehouse 사용. 상시 켜두지 않고 파이프라인이 실행되는 시간(수 초~분)에만 과금되어 비용을 극적으로 낮춤.
데이터 수집 비용	Databricks에서 무료로 제공하는 시스템 테이블(system.access.audit)과 내장 AI Functions 활용으로 별도 API/수집 인프라 비용 제로($0).
오케스트레이션	사내 구축되어 있던 기존 Airflow 인프라(AWS EKS 위에 있음)를 재활용하여 추가 도입 비용 없음.
월간 총 예상 비용	현재 매시 정각 일 24회, 월 720회 글로벌 파이프라인을 가동하고 (시간당 100~200회 쿼리 발생 기준) 발생하는 총비용은 약 $5 ~ $25 / 월 수준입니다.

Genie Code에게 물어본 결과

✨ 주요 도입 효과

컴퓨팅 비용 (DBU): 상시 켜두는 클러스터 대신 Databricks Serverless SQL Warehouse를 활용했습니다. Airflow가 파이프라인을 트리거할 때 수 초~분 단위로만 실행되고 바로 꺼지기 때문에 과금을 극적으로 낮췄습니다.
수집 인프라 비용 제로 ($0): Databricks에서 기본 제공하는 시스템 테이블을 활용하여 별도의 로그 수집기(Fluentd, Logstash 등)를 띄울 필요가 없었습니다.
최종 월간 예상 비용: 현재 매시 정각 일 24회, 월 720회 글로벌 파이프라인을 가동하고 (시간당 100~200회 쿼리 발생 기준) 발생하는 총비용은 약 $5 ~ $25 / 월 수준입니다. 수천만 원짜리 상용 솔루션을 압도하는 가성비죠!

마무리하며: 시스템을 넘어 '문화'를 만들다

이번 프로젝트는 단순히 스크립트 몇 개를 짜는 것을 넘어, 흩어져 있던 글로벌 워크스페이스를 Unity Catalog라는 하나의 거버넌스 우산 아래 엮어내고, AI와 Airflow를 결합해 능동적인 방어 체계를 갖췄다는 점에서 제 엔지니어링 커리어에 큰 이정표가 되었습니다.

이전에는 담당자가 월 1회 수동으로 취합하며 고통받던 작업이 이제는 1시간 단위로, 100% 자동으로, 그것도 AI의 판정을 거쳐 Teams로 배달됩니다. 데이터 플랫폼이 자체적으로 제공하는 기능들만 잘 조합해도 얼마나 강력한 환경을 만들 수 있는지 증명해 낸 것 같아 뿌듯합니다.

물론 1년 넘게 데이터 플랫폼을 구축하며 크고 작은 시행착오도 많았고, 다음 단계로는 분석가분들이 더 쉽게 화이트리스트를 신청하고 관리할 수 있도록 **'보안의 사용성'**을 높이는 과제가 남아있습니다. 제 치열했던 경험과 사례가 글로벌 멀티 환경에서 데이터 거버넌스를 고민하시는 많은 엔지니어 분들께 좋은 영감이 되기를 바랍니다. 긴 글 읽어주셔서 감사합니다. 궁금하신 점이 있다면 언제든 댓글로 남겨주세요!

[DRE] 데이터 파이프라인 장애 감지 자동화 — Airflow + Teams 연동

주형권 — Sun, 12 Apr 2026 21:35:44 +0900

MoEye 프로젝트

이 글의 핵심 요약

무슨 문제인가: 기존 팀 단위의 단편적인 모니터링 방식으로는 본부 전체 사용자가 무작위로 생성하는 수많은 Databricks 워크플로우의 성공/실패/지연 상태를 체계적으로 관리하고 대응하기 어려웠음.
어떻게 해결했나: Databricks Job/Task API를 주기적으로 호출하는 자동 탐지 백엔드를 개발하고, 메타데이터 저장을 위한 RDS 구축 및 비공개 Teams 채널 연동을 아우르는 전사적 워크플로우 관측 가능성(Observability) 알림 아키텍처를 수립함.
무슨 효과를 얻었나: 본부 내 누구나 워크플로우를 생성해도 별도 설정 없이 실시간 장애 알림이 자동 적용(바이브코딩 배려)되었으며, 단순 감지를 넘어 장애 원인을 신속히 진단할 수 있는 데이터 신뢰성(DRE) 기반을 마련함.

이 글은 AI를 기반으로 작성하였으며 실제 제가 만든 Monitoring의 내용을 Gemini와 함께 작성하였습니다.

안녕하세요. 데이터 엔지니어로 일하며, 최근 DRE(Data Reliability Engineer)로의 도전을 시작한 주형권입니다. 그 첫 번째 발걸음으로, 제가 소속된 본부 전체가 함께 사용할 수 있는 'Databricks Job 자동 감지 및 알림 시스템'을 구축한 이야기를 공유해보려 합니다.

왜 이 시스템을 만들었나?

사실 기존에도 팀 내부적으로 쓰던 모니터링 방식은 있었습니다. 하지만 체계화보다는 '일단 돌아가게' 만드는 데 급급했죠. 이번에는 차원이 다릅니다. 본부 전체 인원이 스케일에 상관없이 안정적으로 사용할 수 있는 시스템을 목표로 했습니다. 제가 생각하는 데이터 신뢰성(Reliability)의 로드맵은 다음과 같습니다.

Monitoring -> Observability -> Reliability

결국 신뢰성 있는 데이터 파이프라인을 구축하려면, 가장 기초 단계인 **Monitoring(모니터링)**이 체계화되어야 하고, 이를 넘어 **Observability(관측 가능성)**가 확보되어야 합니다.

그래서 이번 프로젝트에서는 Databricks에서 발생하는 모든 워크플로우의 성공/실패/지연 상황을 체계적으로 감지하고, 조건에 따라 적절한 담당자에게 즉시 알림을 보내는 시스템을 한 땀 한 땀 만들어 보았습니다.

4가지 핵심 구축 조건

시스템 개발에 앞서 본부 전체 사용자를 고려한 4가지 필수 조건을 정립했습니다.

불특정 다수 커버: 본부 누구나 Workflow를 만들어도 Teams 채널을 통해 알림을 받을 수 있어야 함.
비공개 Teams 채널 대응: 회사 Teams 채널은 비공개이므로, 알림을 받으려면 반드시 '초대' 프로세스가 선행되어야 함.
바이브코딩(비개발자) 배려: Databricks에 익숙하지 않은 사용자가 워크플로우를 만들어도 무조건 알림 대상에 포함되어야 함.
직관적인 알림: 누구나 메시지만 보고도 상황을 즉시 파악할 수 있어야 함.

이 조건들을 충족하기 위해 정책과 개발 방향을 꼼꼼히 설계했습니다.

⚙️ 개발 및 정책 핵심

복잡하지는 않지만, 안정성을 위해 여러 가지 고민을 담았습니다.

1. 알림 발송 개발 방식 (백엔드)

API 기반 주기적 탐지: Databricks의 Workflow 리스트 API와 Task API를 주기적으로 호출하여 상태 변경(특히 실패)을 지속적으로 감지합니다.
상태 저장 및 중복 방지 (RDS): 추후 Observability 확장을 고려하여 데이터를 RDS(MySQL)에 저장합니다. ON DUPLICATE KEY UPDATE 구문을 활용해 리스트와 Task 테이블을 효율적으로 업데이트합니다.
알림 히스토리 관리: job_result_state 칼럼으로 실제 발송된 메시지 종류를 표시하고, updated_at으로 최종 발송 시점을 체크하여 중복 알림을 방지합니다.

2. 운영 정책 및 자동화 (Tagging)

Teams 채널 자동 초대 (SMTP): Databricks 권한이 있는 사용자가 Workflow를 생성하는 순간을 API로 캐치합니다. 해당 사용자에게 자동으로 이메일(SMTP)을 발송하여 Teams 채널 가입을 유도합니다.
Tag 정책 기반 자동 할당: Databricks는 태그에 콤마(,)를 지원하지 않아 슬래시(/)를 구분자로 사용했습니다.
- alert_type: S(공), F(실패), L(지연) 플래그 조합. (예: S/F/L)
- alert_user: 알림을 받을 사용자 ID(여러 명 가능).
자동 Tagging: 시스템이 주기적(10분마다)으로 탐지하여 Tag가 없는 워크플로우에는 정책에 따라 자동으로 Tag를 달아줍니다.

✨ Gemini와의 티키타카, 그리고 깨달음

이번 개발 과정에서 특별했던 점은 인공지능(Gemini)을 적극적으로 활용했다는 것입니다. 단순히 코드를 짜달라고 하는 것을 넘어, "내가 설계한 이론에 논리적 모순이 없는지", "코드의 리팩토링 방향은 맞는지", "비효율적인 쿼리나 프로세스는 없는지"를 Gemini와 계속 주고받으며 검증했습니다. 그 결과, 혼자 고민했을 때보다 개발 생산성이 비약적으로 향상되었고, 더 견고한 시스템을 만들 수 있었습니다.

SUCCESS 알림

FAILED 알림

마치며

단순한 알림 발송처럼 보일 수 있지만, '본부 전체'라는 스케일과 '비개발자'라는 사용자 경험을 고려하니 많은 고민이 필요했던 프로젝트였습니다. 이 시스템이 본부 데이터 파이프라인의 신뢰성을 높이는 든든한 주춧돌이 되기를 기대합니다. 그리고 아직 데이터 환경을 갖추지 못한 여러 회사에게 도움이 되기를 기원합니다.

[DRE] 데이터 엔지니어 다음 커리어, Data Reliability Engineer(DRE) 로드맵

주형권 — Mon, 8 Dec 2025 17:26:26 +0900

해당 내용은 제가 생각한 부분과 외국 블로그, 사이트에서 있는 내용을 정리 한 개념이므로 정답은 아닙니다.

이 글의 핵심 요약

무슨 직군인가: 데이터 신뢰성 엔지니어(Data Reliability Engineer, DRE)는 소프트웨어 분야의 SRE(사이트 신뢰성 엔지니어링) 철학을 데이터 도메인에 이식하여, 대규모 데이터 파이프라인의 품질, 정합성, 안정성을 보장하고 자동화하는 차세대 직군입니다.
왜 필요한가: 데이터 플랫폼이 대형화되면서 사후 모니터링만으로는 정합성 오류와 성능 저하를 방지하기 어려우며, 데이터 신뢰도를 엔지니어링 기법으로 '설계 단계'부터 강제하고 관리해야 하기 때문입니다.
앞으로의 방향성: 국내에는 아직 매우 생소하지만 해외 및 선도 IT 기업들을 중심으로 급부상 중이며, 전통적인 데이터 엔지니어링 업무를 한 단계 고도화하는 핵심 로드맵으로 자리 잡을 것입니다.

들어가며

최근에 링크드인을 통해서 Data Reliability Engineer(이하 : DRE)에 대해서 관심을 갖고 이쪽으로 로드맵을 만들어 가겠다고 다짐하였습니다. 이후에 DRE에 대해서 정확히 알고자 검색을 통해서 여러 정보를 얻었습니다. 우선 이 개념은 국내에 T사 한 곳에만 있는 것 같습니다. 실제로 운영을 하고 있으며 잘 운영 중인 것 같습니다. 실제로 검색해도 T사 이외에 어떠한 한글 문서가 나오지 않고 외국 블로그나 업체에서 제공하는 정보만 있습니다.

우선 DRE라는 개념 자체가 전세계적으로 생긴 지 얼마 안 되는 직군인 것 같습니다. 그리고 국내에는 굉장히 생소한 개념으로 보입니다. 생각해 보면 Data Engineer(이하 : DE)라는 직군도 엄청 오래된 직군은 아닙니다. 제가 초창기에 DE 직군이 생겼을 때 시작해서 벌써 7년을 하고 있으니 제가 보기엔 10년이 안된 거 같습니다. 처음에 DE를 한다고 잘 다니는 대기업을 박차고 나갔을 때 다들 X 쳤다고 했습니다. 근데 저는 이 직군이 굉장히 뜰 거라고 생각했습니다. 왜냐면 데이터의 종류가 많아지고 다양해지면서 기존의 방식은 점차 살 곳을 잃을 거 같았습니다.

그 말은 사실이 되었고 전통적인 DataWarehouse Engineer(이하 : DW)들의 이직은 더욱 어려워졌습니다. (지금은 아닌거 같지만...) 그때 당시에는 이런저런 형태의 데이터를 가리지 않고 커스텀해서 하나의 데이터 플랫폼 또는 데이터 레이크에 적재하고 이를 분석할 수 있는 사람을 선호하였습니다. 그러면서 자연스럽게 전통적인 DW만 하는 사람들은 갈수록 구직이 어려워졌습니다.

그리고 오늘날 이제는 DE 조차도 이직이 어려워지고 있습니다. 본인의 특별한 색이 있는 DE들이나 출중한 실력을 가진 DE들만이 이직을 하고 있으며 그 조차도 이직의 허들은 굉장히 높아졌습니다. DE가 그만큼 직업적으로 성숙해졌고 이로 인해서 더욱 세부적인 기술을 요구하는 기업이 많아지고 있습니다. 또한 하나의 회사에서 데이터 플랫폼/레이크를 여러 개를 사용하는 경우도 많다 보니 DE조차도 개발에 중점이 아닌 운영에 중점을 두기 시작하는 곳이 많아지고 있습니다.

Data Reliability Engineering은 무엇인가?

정의

우리가 이미 많이 알고 있는 SRE(Site Reliability Engineering)에서 Site 대신 Data를 접목시킨 역할입니다. SRE이가 인프라의 신뢰성을 보장하는 역할을 하였다면 DRE는 데이터의 신뢰성을 보장하는데 중점을 둡니다. 기업에서는 데이터의 중요성이 지소적으로 커지고 데이터 파이프라인의 복잡성이 증가하면서 관리의 어려움을 겪고 있습니다. 그렇기에 DRE는 데이터가 정확하고 신뢰 할 수 있는 고품질의 데이터로써 제공되게 하고 데이터가 필요한 사람들에게 제공되며 이에 관련하여 보안에도 신경 쓰는 엔지니어링입니다.

(출처 : Data Reliability Engineering: A Guide to Ensuring Data Quality in the Modern Data Stack)

내 생각

외국 블로그/사이트에서 설명하는 내용을 보면 약간은 다르지만 모두 같은 말을 하고 있습니다. DER는 데이터의 신뢰성을 위한 엔지니어링 입니다. 데이터의 신뢰성을 보장하기 위해선 단순하게 생각하면 데이터의 품질이 있을 것입니다. 우리가 사용하는 데이터가 실제로 정상적으로 적재되었는지 정상적으로 전처리가 이루어졌는지 등의 데이터 품질이 있으며 데이터 파이프라인이 정상적으로 작동했는지도 보증해야 합니다. 왜냐하면 다음과 같은 A, B, C의 소스 데이터를 이용해서 Mart를 만들 때 실제로 A, B, C의 데이터 파이프라인이 모두 정상 작동 했는지 보증이 되어야지 Mart의 데이터가 정확한지 신뢰할 수 있기 때문입니다.

예를 들어서 login , purchase , user_info 테이블 3개를 종합하여 user mart 테이블을 만든다고 가정할 경우 3개의 소스 테이블에서 한 개의 테이블이라도 파이프라인이 동작을 안 하면 정상적인 데이터가 나올 수 없습니다. 또는 3개의 테이블 중에 한 개라도 정합성이나 데이터에 이상이 있으면 잘못된 값이 나올 수 있습니다.

이러한 단순한 파이프라인 구조에서도 데이터 파이프라인이 하나 잘못되면 문제가 생기는데, 엄청나게 복잡하고 규모가 큰 데이터 플랫폼에서는 작은 부분이 하나 틀어지면 얼마나 많은 부분의 데이터가 잘못될까요? 또한 여기에 소스 테이블을 추가하여 마트 테이블에 더욱 많은 정보를 넣기 위해서 영향도가 어떨지 등등 많은 부분을 신경 써야 할 것입니다. 그렇기에 DRE의 범위는 데이터에 관련된 대부분의 영역에서 신뢰성 있는 데이터를 제공하기 위해서 일하는 것을 의미한다고 생각합니다.

데이터에 관련된 대부분의 영역에서 데이터의 신뢰성을 위한 엔지니어링

Data Reliability Engineer은 무엇을 하는가?

소방관

정의

DRE의 역할에 대해서는 너무 다양하고 너무 설명하는 게 달라서 뭐라고 정의하기가 어려웠습니다. 하지만 결론적으로는 데이터 신뢰성을 높이기 위해서 데이터 관련된 대부분의 영역에서 활동하는 것으로 보입니다. 또한 어느 블로그에서는 DRE를 데이터 관한 소방수라고 표현하기도 하였습니다. 아래는 몇 가지 공통적으로 등장하는 역할에 대해서 몇 개 써봤습니다.

1) 모니터링 시스템 구축 데이터 신뢰성을 보증하기 위해서 데이터 파이프라인 데이터 정합성등에 대해서 모니터링 시스템을 만들어서 관리합니다.

2) 데이터 품질 관리 데이터를 사용하는 사람들에게 데이터 품질에 대해서 자동으로 검증하고 이를 기반으로 한 데이터 신뢰성 지표 제공 합니다.

3) 데이터 운영 데이터 운영이라고 하면 범위가 굉장히 큽니다. 데이터에 수명주기 데이터의 메타정보 등 여러 가지 데이터 관련 된 운영을 모두 맡는다고 할 수 있습니다. 이밖에 데이터 사용이 쉽게 하도록 교육을 하기도 합니다.

4) 데이터 사용자와 협업 데이터를 사용하는 데이터 엔지니어 / 데이터 과학자 / 데이터 분석가등과 협업하여 모두가 신뢰할 수 있는 데이터를 만듭니다.

출처 : How to become a Data Reliability Engineer

Data Reliability Engineer: 9 Skills to Help You Become One!

What is a Data Reliability Engineer – And Do You Need One?

내 생각

이 부분에서는 제 생각이 많이 반영되었습니다. 사실 어디 회사를 입사하냐에 따라서 같은 직무라도 조금씩 다른 역할을 맡습니다. 같은 DE를 하더라도 조금씩 본인의 색채가 다르듯이 DRE도 비슷한 것 같습니다. 저는 DE를 하면서 운영을 시키지 않았지만 스스로 하였습니다. DBA를 하던 시절에 버릇이 남아서 그런지 운영에 굉장히 민감하고 보수적으로 접근하다 보니 내가 편하자고 만들어서 쓰는 모니터링 시스템이 기본이 되었습니다.

제 생각에는 DRE는 DE에서 Administrator의 역할을 수행하는 직군이라고 생각됩니다. Management보다는 Administrator의 역할을 수행함으로써 운영에 제어를 더해서 관리를 하는 역할이라고 생각됩니다. 제가 회사를 처음 입사하면 항상 하는 게 모니터링 시스템 구축입니다. ( 데이터 엔지니어인 내가 새롭게 입사하는 회사에서 하는 것)

모니터링을 해야지 어느 부분에서 누수가 발생하는지 쉽게 알 수 있고 어느 부분에서 비용이 낭비되는지 알 수 있으며 빠르게 장애를 해결할 수 있습니다. 누군가에게는 별거 아닐 수 있지만 이러한 시스템 자체를 만드는 사람을 저는 회사를 다니면서 본 적이 없습니다. 물론 Datadog / Datahub와 같은 좋은 도구들이 있지만 저 같은 경우 제 입맛에 맞는 대시보드와 제 입맛에 맞는 또는 팀의 입맛에 맞는 대시보드와 알람을 만들기 위해서 그리고 내가 또는 다른 팀원이 원하는 모니터링을 만들기 위해서 직접 만드는 것을 선택하였습니다.

이러한 모니터링을 만들기 위해서는 네이밍룰이나 여러 가지 Tag에 관련해서 정책이 필요하며 카탈로그를 지표를 만들기 위해서는 카탈로그에 대한 정책도 필요합니다. 왜냐하면 나중에 알람을 만들거나 지표에 무언가를 표시할 때 Tag나 네이밍이 이상하면 한눈에 알아보기 어렵기 때문에 당연하게도 정책 수립은 필수적으로 따라옵니다.

이러한 일련의 모든 과정을 수행해야 하는 직무라고 생각이 들며 데이터에 관련된 Administrator이라고 하는 게 제가 생각하기에 가장 맞는 거 같습니다. 그래서 직무를 특정적으로 제한하기보다는 데이터 관련된 대부분의 역할을 수행하되 그 역할이 데이터의 신뢰성에 초점을 맞춰서 해야 하는 역할로 보입니다.

데이터 관련 된 대부분의 역할을 수행하되 그 역할이 데이터 신뢰성에 포커싱 된 역할

내가 생각하는 Data Reliability Engineer

사실 이 내용을 쓰기 위해서 앞부분의 내용을 여러 가지 해외 자료를 통해서 공부했습니다. Data Reliability Engineer가 무엇인지 무엇을 하는지 알아야지 어떻게 할지 고민할 수 있다고 생각이 들어서였습니다. 사실 DRE에 대해서 찾아보면 찾아볼수록 아직은 완성되지 직군인 것 같습니다. Job Description을 봐도 각기 모두 다르고 직무에 대한 이야기를 하는 것도 모두 다르기에 무언가를 한다고 딱 정해져 있기보다는 말 그대로 데이터 신뢰성을 위해서 일하는 직군으로 보였습니다.

그래서 제가 생각하기에 지금 당장 할 수 있는 DRE의 방향은 무엇일까 고민하다가 제가 기존에 해왔던 일을 접목시킨다면 이렇게 할 것 같다는 생각이 있어서 그것을 공유하려고 합니다.

제가 생각하기에 DRE의 역할 중에 3개의 영역으로 나누고 수행하면 좋을 거 같습니다. 물론 제가 이 분야의 전문가들과는 다르게 세부적으로 더 자세하게는 이야기하기 어렵겠지만 3개의 직무 자체를 통합하여 관리하고 적용하다 보니 조금씩 해야 하지 않을까 싶습니다.

1) Data Monitoring

Data에 관련된 모니터링 시스템을 구축하는 것은 어쩌면 DRE의 가장 기본이자 핵심적인 업무가 될 것이라고 생각합니다. 앞서 이야기하였듯이 데이터 파이프라인의 동작이 끊기는 경우 마트 데이터 또는 팩트 데이터의 잘못된 값이 입력될 수 있기에 이를 즉시 알리는 모니터링 시스템을 만드는 부분에 대해서 생각할 수 있을 거 같습니다.

데이터 파이프라인의 경우 각종 시스템에서 각기 다른 소스로부터 오기 때문에 파이프라인의 모니터링을 한눈에 볼 수 있도록 만드는 것이 핵심 일 것 같습니다. 또한 누구나 알기 쉽고 빠르게 대처가 가능하도록 하는 것이 중요할 거 같습니다.

데이터 파이프라인 알람

추가적으로 파이프라인의 성공 실패뿐 아니라 이를 실행시키는 플랫폼의 리소스나 사용량에 대해서도 모니터링이 필요할 것 같습니다. 예를 들면 S3의 사용량이나 Spark의 모니터링등을 하나의 지표에서 함께 볼 수 있다면 굉장히 도움이 될 것 같습니다.

작업별 비용 지표

여기에 더불어 각종 리소스에 관련된 비용을 볼수 있도록 한다면 비용적으로도 도움이 많이 될 것으로 보입니다. 이는 과도하게 사용되는 리소스를 찾아서 비용을 최적화할 수 있으며 성능과도 연관되게 볼 수 있습니다. 다양한 데이터 플랫폼이 과금 구조가 사용한 만큼 비용을 지불하기에 비용이 많이 소모되는 작업을 찾아서 성능을 튜닝하여 비용을 낮추고 성능을 좋게 만드는 효과도 불러올 수 있다고 생각됩니다.

2) Data Quality

데이터의 품질 또한 DRE의 주요 업무라고 생각됩니다. 소스로부터 타깃까지 데이터가 정상적으로 적재되었는지 가장 기본이 되는 ODS부터 시작해서 마트와 팩트 테이블에 이르기까지의 여러 가지 정합성 모니터링을 통해서 데이터의 품질을 올릴 수 있을 것 같습니다.

아주 간단하게는 건수 체크를 통해서 소스로부터 타깃으로 데이터가 그대로 적재되었는지를 볼 수 있을 것이며, 필요에 따라서 Primary Key를 통해서 중복 체크를 해서 데이터의 중복이 있는지 볼 수도 있습니다. Primary Key가 없는 로그성 데이터 또는 RDBMS로부터 오는 데이터가 아닌 경우 일자별로 로그의 건수의 추이를 보고 가중치를 부과해서 가중치 이상 또는 이하로 데이터가 들어오거나 또는 너무 많이 들어올 경우 알람을 보낼 수도 있습니다.

또한 NULL의 비율이나 NULL 값이 있는지 체크를 통해서 NULL로 들어오면 안 되거나 너무 많이 들어오면 이상이 있는 경우를 모니터링할 수도 있습니다. 실제로 ETL 하는 과정에서 변환하는 과정에서 데이터의 타입 변경이 자동으로 이루어지거나 인식하지 못하는 경우에 NULL로 잘못 들어오는 경우가 실제로 많이 발생합니다. 또는 실수로 인한 잘못된 패치로 인해서 아예 NULL로 들어오는 경우도 실제로 많이 있습니다.

3) Data Governance

제가 자세히 알지 못하는 영역이지만 작게나마 수행하고 있던 영역입니다. 실제로 Data Governance 영역의 경우 견고하게 설계된 회사가 많지 않고 실제로 이 부분은 엄청나게 많은 지식을 요구하기에 몇몇 필요한 부분만 적용했었습니다. (저는 그랬습니다.)

수많은 Data Governance 영역에서 저의 경우 데이터 수명주기에 대한 정책을 세우고 관리하였습니다. 왜냐하면 이 부분은 데이터의 저장소 비용과 처리 비용과 직접적으로 연관되기에 신경을 많이 쓸 수밖에 없는 부분입니다. 가장 많이 신경 썼던 부분은 S3 저장소로써 중간 저장소 역할을 하기도 하고 최종 저장소 역할을 하기도 합니다. 예를 들어 RDBMS에서 데이터를 S3에 저장하고 이를 여러 곳에서 사용한다고 하면 S3의 비용이 아무리 싸더라도 중간 산출물인 경우 또는 집계를 위해서 데이터를 S3에 저장하고 있다면 S3 수명주기를 통해서 데이터를 관리할 필요가 있습니다.

실제로 AWS S3에서는 이와 같은 기능을 제공하고 있지만 각 S3 Bucket마다 일일이 들어가서 봐야 하는 번거로움이 있습니다. 그래서 DRE의 경우 이러한 정보를 한눈에 볼 수 있는 지표나 알림을 보여주는 역할을 해야 한다고 생각합니다.

또한 보안과 관련된 일에도 여러 가지 모니터링을 통해서 알림을 받거나 관리 하는 지표를 만들수 있습니다.

이를 통해서 주기적으로 Access Key 또는 여러가지 Key 파일을 관리하고 주기적인 교체를 할 수도 있습니다. 또는 담당자에게 만료 기간이 도래 하였음을 알림으로써 각 담당자가 직접 변경을 할수 있도록 도울 수도 있습니다.

이밖에도 데이터 카탈로그 정보를 관리함으로써 데이터 스키마 변경 내역을 기록하고 이를 문서화할 수 있으며 언제든지 변경 부분에 대해서 누구나 쉽게 보도록 만들 수 있으며 현재 최신 상태의 카탈로그도 제공해야 한다고 생각합니다. 여기에 더불어 데이터에 관련된 여러 가지 Meta 정보를 수집하여 제공도 가능합니다. 예를 들면 현재 테이블의 건수와 테이블의 마지막 업데이트 시간등을 표기하여 데이터를 사용하는 사람으로 하여금 해당 데이터의 신뢰성을 더욱 높일 수 있습니다.

마치며

사실 DRE는 저에게 엄청나게 도전적이고 모험적인 직무인 거 같습니다. 아직 국내에서는 굉장히 생소한 개념이며, 해외에서도 찾아보면 각기 다르게 이야기하고 있습니다. 무엇이 맞다 틀 리다를 이야기하기보다는 어느 방향성으로 데이터의 신뢰성을 올리느냐가 중요해 보입니다. 데이터의 신뢰성을 올린다고 하는 의미가 저에겐 너무 추상적으로 다가오긴 합니다. 어떻게 하면 신뢰성을 올릴 수 있는지는 사람마다 또는 기업마다 모두 다르다고 생각하기 때문입니다.

결론적으로 DRE를 말하자면... 솔직히 말해서 데이터 운영에 관련된 모든 일 하는 사람으로 보입니다. 이게 진짜 범위 자체의 경계가 없고 모든 데이터 관련 운영 업무에 투입이 될 수 있으며 데이터베이스, 데이터웨어하우스, 데이터레이크 등 데이터가 들어가면 모두 왠지 운영적으로 봐야 할거 같습니다.

그래서 당장에는 우선 데이터 운영의 부담을 덜어주면서 데이터 품질을 올리는 부분에 집중하는 게 맞다고 생각됩니다. 이 부분도 굉장히 추상적이지만 생각해 보면 제가 데이터엔지니어를 하면서 팀에서 필요하다고 생각하거나 내가 보고 싶어서 만드는 여러 가지 업무들이 데이터 운영의 부담을 덜어주고 데이터 분석가나 데이터 과학자 나아가 데이터를 사용하는 데이터와 관련이 없는 직군이지만 데이터를 사용하는 모든 사용자들에게 데이터 신뢰도를 올렸습니다.

예를 들면 데이터 파이프라인의 종료되는 시간을 계산해서 테이블의 최신 업데이트 주기를 보는 지표를 만들어서 사용자들이 언제쯤 데이터를 보면 될지 알 수 있도록 하였으며, 데이터가 중복되지 않도록 추세 또는 PK를 통해서 이 데이터가 실제로 잘 쌓이고 있다는 지표등을 제공하여 데이터를 사용하는 사람들이 안심하고 쓰도록 하였습니다.

아마도 제가 DRE 직무를 맡게 된다면 시키는 일 + 내가 했던 일 2개를 병행 할거 같습니다. 위에서 제가 해왔던 일이면서 필요해 보이는 일을 정리하였지만 이밖에도 DRE의 잠재성(?)은 무궁무진하다고 생각됩니다. 하여 회사에서 추구하는 DRE로써의 역할은 언제나 열어놔야 한다고 생각합니다.

[Databricks] API를 이용한 Token정보 가져오기 (Python)

주형권 — Tue, 18 Nov 2025 10:29:49 +0900

안녕하세요. 오랜만에 Databricks 관련 글을 올립니다. 오랜만에 쓰는 글인데 심화적인 글은 아니고 간단한 API를 이용한 내용입니다. Databricks에서는 AWS나 GCP 같은 플랫폼에서와 같이 Key 형태의 Token을 제공합니다. Token을 이용해서 여러 가지 Databricks의 모니터링을 할 때 Token을 이용해서 코드에 삽입하여 사용합니다.

제가 만든 수많은 모니터링 시스템에서 필요한 것이 Databricks의 Token입니다. 모니터링을 하려면 AWS에서는 Access key 가 필요하고 GCP에서는 key file이 필요하듯이 여기서도 Token이라는 것이 존재 합니다.

Authenticate with Databricks personal access tokens (legacy) | Databricks on AWS

Learn how to set up Databricks authentication by using Databricks personal access tokens (PATs).

docs.databricks.com

하지만 이 Token에도 관리가 필요합니다. 특히 최근에 많은 이슈가 되고 있는 보안을 위해서 Token을 주기적으로 교체하거나 수명주기를 관리하여 Token을 관리해야 합니다.

Token 확인 방법

Databricks Token의 경우 위의 스크린숏과 같이 우측 상단의 워크스페이스명을 누르면 나오는 곳의 가장 아래에 "계정 관리"부분을 클릭하면 나오는 페이지로 접속 후 아래와 같이 확인 가능 합니다.

여기서 Token을 생성하는 방법이나 각각의 워크스페이스별로 보는 방법은 다루지 않겠습니다. (글 목적과 맞지 않으므로)

Token 정보 가져오기

Databricks의 Token 정보의 경우 다음의 API를 통해서 가져올 수 있습니다.

List all tokens | Token management API | REST API reference | Databricks on AWS

Databricks REST API reference

docs.databricks.com

Token의 정보를 가져올 수 있으며 결과값 예시는 다음과 같습니다.

{
  "token_infos": [
    {
      "comment": "This is for the ABC department automation scripts.",
      "created_by_id": 202480738464078,
      "created_by_username": "jsmith@example.com",
      "creation_time": 1580265020299,
      "expiry_time": 1580265020299,
      "last_used_day": 1710374400000,
      "owner_id": 202480738464078,
      "token_id": "5684c955822ac792a51ae2aeb80190f13457bab3e2e2934c133a08b38454816c",
      "workspace_id": 5750939285643220
    }
  ]
}

다음의 코드로 Token의 정보를 가져올수 있습니다. info_list에 보시면 list형태로 넣은 이유는 list에 여러 개의 워크스페이스를 넣어서 한 번에 정보를 전부 가져오기 위함입니다. (각 워크스페이스마다 Token을 생성하여 각 워크스페이스마다 API를 실행해야지 모든 Token정보를 획득 가능함)

import requests
from datetime import datetime,timedelta

info_list = [
             {'account':'Please enter your account.','domain':'Please enter your domain.','token':'Please enter your token.'}
             ]

for info_row in info_list:
    account = info_row.get('account')
    domain = info_row.get('domain')
    token = info_row.get('token')

    print(f'Collect the corresponding {account}')

    url = f"https://{domain}/api/2.0/token-management/tokens"
    headers = {"Authorization": f"Bearer {token}" }
    response = requests.get(url=url, headers=headers)
    result = response.json()
    token_list = result.get('token_infos')

    if token_list == []:
        pass

    else:
        for token in token_list:
            print(token)

위의 코드를 이용해서 Token 정보를 가져오고 저희 같은 경우 다음과 같이 Teams 메신저를 통해서 알림을 받고 있습니다. 이렇게 Token의 만료기간을 알려서 사용자가 갑자기 Token이 안 되는 상황을 막고 사전에 이를 방지하기 위함입니다.

[공통] 데이터엔지니어링팀의 계획 - 중기편 (3~N년)

주형권 — Thu, 13 Nov 2025 10:05:07 +0900

빌딩숲

[공통] 데이터엔지니어링팀의 계획 - 단기 편 (0~2년)

[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고

burning-dba.tistory.com

지난 단기편에 이어서 중기 편을 이어가려고 합니다. 만약 여러분이 단기 과정을 어느 정도 끝냈다면 이제부터는 중반에 접어들었을 것이라고 봅니다. 기존의 데이터가 없는 환경에서 이제 플랫폼을 이용하여 무엇을 할 수 있는 단계에 이르렀다고 생각됩니다. 이것은 엄청난 도약입니다.

데이터 없이 경험과 감으로 일하던 환경에서 이제는 사실 기반으로 데이터와 수치를 기반으로 업무를 하는 환경을 조금씩 만들어 가고 있는 과정에 서 있다고 봅니다. 제 생각에는 아마도 중반기의 과정이 가장 고달프고 가장 많은 스트레스를 받는 단계가 아닐까 싶습니다.

들어가며

앞에서 이야기 했듯이 제 생각에는 이 시기가 가장 고달프고 스트레스받는 시기인 것 같습니다. 왜냐하면 1~2년 많게는 3~5년까지 데이터 플랫폼을 구축하였다면 이제는 이것을 쓰게 해야 하는 단계이며, 사용자의 편의성을 증대시켜야 하는 시기이기 때문입니다. 제가 여러 회사에서 데이터 플랫폼을 구축하고 데이터 환경을 만들면서 느끼는 점은 잘 만들어도 쓰지 않으면 인정을 받지 못한다는 것입니다.

많은 사람들이 저에게 "잘 만든 데이터 플랫폼은 무엇인가요?"라고 묻습니다. 예전에는 저는 최신 기술을 접목하여 만든 고도화된 데이터 플랫폼 아니면 엄청나게 잘 잡혀있는 데이터 거버넌스를 기반으로 만들어진 단단하고 견고한 데이터 플랫폼등 여러가지 기술이나 정책 기반의 데이터 플랫폼을 많이 이야기하였습니다. 하지만 데이터 엔지니어로써 많은 시간을 보내다 보니 제 생각에 가장 잘 만들어진 데이터 플랫폼은 사용자가 잘 쓰는 데이터 플랫폼인 것 같습니다.

사용자가 많은 데이터 플랫폼이 가장 잘 만든 데이터 플랫폼이라고 감히 말하고 싶다.

이렇게 하기 위해선 수많은 노력이 필요하며 엔지니어로써 "내가 왜 이걸 하지?"라는 생각이 드는 여러가지 일도 많이 해야 하기 때문인 것 같습니다. 이밖에도 여러 가지 고도화를 통해서 비용을 감축시키고 데이터 플랫폼이 구축되었기에 내가 예상하지 못하였던 다양한 종류와 방대한 양의 데이터를 데이터 플랫폼에 넣어줘야 하는 여러 가지 스트레스도 받습니다.

계획	계획 내용	비고
데이터 플랫폼 홍보/교육	데이터를 사용할 수 있는 환경을 만들었다면 이제는 데이터를 잘 쓰도록 해야함
다양한 데이터 적재	이미 있는 데이터 또는 기본적인 데이터를 적재 하였다면 이제는 다양한 데이터를 적재 해야함	예시) CRM / GA4 / 타 플랫폼 데이터등
사용자 편의성 증대	데이터 플랫폼을 계속해서 사용자가 사용하기 편한 환경으로 만들어줘야함 (요구사항 수집 및 반영)	예시) 데이터 카탈로그 강화 / Text To SQL등
데이터 관련 고도화	다양한 사용자와 데이터가 계속해서 유입됨으로 인하여 정책 또한 생성하고 고도화 되어야하며, 기존의 정책도 끊임없이 업데이트 되어야함

1. 데이터 플랫폼 홍보/교육

솔직히 말해서 많이 하기 싫은 일중에 하나입니다. 이 일을 왜 해야하는지 이해하는데 많은 시간이 걸린 거 같습니다. 왜냐면... 저는 엔지니어니까요. 엔지니어가 왜 어째서? 교육하고 홍보하고를 해야 하지?라는 생각을 정말 많이 했습니다. 그런데, 어느 회사를 가든 이건 엔지니어의 숙명 같습니다. 제가 다녔던 많은 회사에서 SQL 교육이나 데이터의 기초 교육을 진행했을 때 항상 반응이 좋았고, 언제나 환영받았습니다. 그만큼 피드백도 좋았습니다.

제가 앞서 말했듯이 데이터 플랫폼을 아무리 잘 구축해도 사용자가 나 뿐이라면 인정받지 못합니다. 다양한 사용자가 잘 쓸 수 있는 환경을 만들어놨다면 이제 다양한 사용자가 쓸 수 있도록 만들어야 합니다. 요즘에는 AI나 LLM을 통해서 Text To SQL을 쓰는 곳도 굉장히 많지만 기본적으로 이런 것을 쓰기 위해서는 데이터 플랫폼 환경에 접속하는 방법부터 시작해서 정말 수많은 것들을 기본적으로 알아야 합니다.

[공통] 데이터를 적재하고 보기까지

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된

burning-dba.tistory.com

제가 예전에 써둔 데이터를 적재하고 보기까지라는 글에서 나오는 내용을 주로 교육 콘텐츠로 사용하였습니다. 사람들은 설명하지 않으면 데이터를 어떻게 볼 수 있고 데이터를 보기까지의 수많은 과정이 있다는 것을 알지 못합니다. 뭐... 당연한 이야기겠지만 우리의 사용자들은 각자의 본업이 있고 데이터를 그분들에게 어디까지나 보조 도구입니다. 그렇기 때문에 이 분야에 대해서 우리만큼 알지 못합니다. 이 부분을 받아들이고 우리의 사용자들에게 설명(교육)하는 시간이 필수적이라고 봅니다.

저 같은 경우 전단지 돌린다는 말을 자주 사용 하였는데, 실제로 전단지를 나눠주면서 홍보를 하는것과 똑같다고 봅니다. 이 일을 전담하는 부서가 있어야 하는 거 아니야?라고 할 수 있는데, 전담해줘도 어차피 우리의 사용자들의 궁금증을 시원하게 해소해주려면 본인이 나서야 합니다. 왜냐면 교육만 전담하는 부서가 전달하는 것과 실제 현업의 사람이 전달하는 건 차이가 꽤 큽니다.

2. 다양한 데이터 적재

아마 데이터 플랫폼을 구축 하겠다는 요구가 있다면 기본적으로 보고 싶은 데이터는 있다는 뜻이고 아마 그 기본적인 데이터는 적재가 되어서 데이터 플랫폼을 구축하고 사용자들에게 오픈하였다고 볼 수 있습니다. 이제 그럼 사용자가 유입되고 데이터 플랫폼이 생겼으니 다양한 데이터를 적재해달라고 요구가 올 것입니다.

즉, 담을 그릇이 생겼으니 다양한 음식을 준비 해달라는 것과 비슷하다고 봅니다. 제가 주로 받았던 요청은 CRM 데이터, GA4 데이터 그리고 서버로그등이었습니다. 그리고 추가적으로 개발팀에서 로그나 데이터를 추가적으로 만들기도 하며 또는 다른 플랫폼에서 나오는 결괏값 데이터를 적재해달라는 요구도 많이 있습니다.

다양한 데이터들

저는 주로 CRM 데이터를 마케팅 부서로부터 가장 먼저 요청 받았던 기억이 있습니다. 그 이후에 서버개발팀에서 요청이 오거나 또는 사업팀으로부터 요청이 오는 경우가 대부분이었습니다. CRM 데이터나 GA4 같은 데이터들은 사실 적재가 그렇게 어렵진 않습니다. 이미 export 기능이 잘 만들어져 있고 연동을 원한다고 하면 방법도 이미 다 있습니다. 여기서 조금 까다로운 게 다른 플랫폼이나 자체구축 플랫폼에서 데이터를 가져오는 일입니다.

자체 구축하거나 다른 플랫폼의 경우 데이터를 가져오기 위해서는 ODBC / JDBC등과 같은 커텍터로 직접 연결하거나 이것도 안 될 경우 직접 데이터를 내려받아서 가져오는 부분도 필요합니다. 우리 쪽 시스템이 아니라서 굉장히 까다로운 경우가 많습니다. 그리고 웹 크롤링 데이터나 공공기관 데이터도 주로 요청받는 데이터중 하나입니다.

3. 사용자 편의성 증대

앞서 1번에서 이미 홍보와 교육까지 했는데 또 뭘 해야 하지?라고 생각 할 수 있습니다. 이 부분은 약간 다른 내용입니다. 앞의 내용이 사용자가 진입하게 만들었다면 이제는 진입 후 잘 사용하도록 만드는 방법입니다. 약간 같으면서도 다른데요. 예를 들면 이런 것들입니다.

[Databricks] 비효율적인 작업 추적기 만들기

안녕하세요. 주형권입니다.정말 오랜만에 글을 쓰는 거 같습니다. 요즘 내/외부적으로 바쁘게 살고 있어서 글을 쓸 시간이 없습니다... 그래서 한 달에 1개 업로드하기도 어렵습니다. 들어가

burning-dba.tistory.com

[Athena] Query 사용량 및 사용자 추적 대시보드 만들기

안녕하세요. 주형권입니다. 지난번에 개발한 GS리테일의 데이터레이크 모니터링 시스템 도베르만에 추가적인 기능을 만들어서 만드는 과정에 대해서 공유하려고 글을 작성하였습니다. 기존에

burning-dba.tistory.com

이게 무슨 연관이 있을까 싶겠지만 굉장히 연관이 많습니다. 제가 현재 사용하고 있는 Databricks 환경을 예로 들어보겠습니다. 비효율적으로 판단되는 쿼리의 기준으로 잡습니다. 저 같은 경우 30분 이상 동작하는 Query를 추적하도록 했습니다. 그럼 이걸 하는 이유가 단순히 튜닝을 위한 목적이라고 생각할 수 있지만 다르게 생각하면 사용자들이 그만큼 오래 기다려야 한다는 의미입니다.

이 말인즉 사용자들이 Query를 실행하고 결과를 받기까지 오래 걸린다는 의미입니다. 내가 사용자라면 매번 Query를 할 때마다 30~60분씩 걸린다고 생각하면 얼마나 고달플까요. 물론 수억 수천억 건의 데이터를 1~N년치 이런 식으로 조회하면 사용자도 느리다 생각하겠지만 하루 또는 이틀 치만 데이터를 질의하는데 오래 걸린다? 그럼 저 같아도 쓰기 힘들 거 같습니다. 그렇기 때문에 이와 같은 Query를 추적하여, 테이블에 파티션을 재조정하거나 파티션이 없으면 만들어 준다거나 조금 더 효율적으로 조금 더 빠르게 결과를 받을 수 있도록 할 수 있습니다.

또한 사용자들이 데이터를 쉽게 볼 수 있도록 카탈로그를 고도화할 수 있으며 데이터 관련 마트/팩트를 설계하여 제공도 가능합니다. 단순히 데이터를 적재하고 끝이 아닌 사용자가 잘 사용할 수 있도록 계속해서 만들어야 합니다. 카탈로그의 경우 사용자가 플랫폼에 접속해서 속성을 찾아서 보기보다는 하나의 페이지에서 검색이 가능하도록 웹 사이트를 만들어서 제공하면 굉장히 큰 호응을 얻을 수 있습니다. (실제로 그랬습니다.)

4. 데이터 정책 고도화

데이터 플랫폼을 구축하고 어느 정도 시간이 지남에 따라서 정책은 끊임없이 업데이트되어야 합니다. 예를 들어서 데이터 플랫폼에서 권한 체계만 해도 다양한 부서와 다양한 데이터를 보는 사람들이 다양하게 생기므로 정책을 다르게 수립해야 하는 경우가 많습니다.

또한 다른 플랫폼에서 데이터가 들어오거나 굉장히 민감한 데이터가 들어오는 경우 데이터를 어떻게 어디까지 보여줘야 할지에 대해서도 고민해야 합니다. 예를 들면 민감 정보의 경우 암호화의 방법부터 시작해서 암호화를 하더라도 볼 수 있는 부서 또는 사용자가 있고 어디까지 볼 수 있는지 모두 고민해야 합니다. 물론 거버넌스 또는 보안부서에서 어느 정도 도움을 주긴 하겠지만 어디까지나 이것을 만들어서 적용은 데이터 엔지니어들이 합니다. (데이터 플랫폼이 우리 거니깐...) 그렇기에 이러한 정책을 계속해서 업데이트해야 합니다.

추가적으로 데이터 수명주기나 데이터의 관리에 관한 여러 가지 정책도 이제 중기에 접어들면 관리가 필요합니다. 데이터의 양이 매우 작으면 큰 의미가 없지만 데이터의 사이즈가 큰 경우 한 달을 보관하는 것도 그만큼 많은 비용이 들어갑니다. 그렇기 때문에 데이터의 수명주기를 설정해서 데이터가 몇 년 또는 몇 달 치 보관을 할지 정해야 합니다. 데이터의 종류가 다양하고 각기 데이터의 성질과 크기가 다르므로 이 모든 것을 관여하여 정책을 잡아야 합니다.

[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

주형권 — Tue, 14 Oct 2025 09:29:15 +0900

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고 비전에 파생되는 계획을 단/중/장기적으로 실천하는 일이 필요합니다. 비전과 계획이 별거 아닌 것 같지만 이것이 없으면 팀원들은 팀 비전에 대해서 의구심을 느낄 수 있으며 불안감이나 또는 보람을 느끼지 못할 수 있습니다.

그렇기 때문에 비전과 계획은 굉장히 중요한것 같습니다. 이번 글에서는 비전 이야기보다는 실질적인 계획에 대해서 이야기해보고자 합니다. 목표라고 할 수도 있겠네요. 사실 비전은 팀마다 정하기 나름이고 회사의 기조에 따라서 많이 달라질 것 같기에 비전에 대해서 다루지 않고 데이터엔지니어링 팀의 계획에 대해서만 다루고자 합니다.

제가 생각 하기에 비전은 조금 더 추상적인 느낌의 긍극적인 목표라면 계획은 구체적인 실행 방안이기 때문에 계획은 큰 틀에서는 비슷할 것 겉으로 보입니다. 제가 팀장을 역임했던 경험과 제로 베이스에서 시작하는 데이터 플랫폼 구축에 관련하여 계획을 세우는 부분에 대해서 실제 행했던 경험을 이야기하고자 합니다.

들어가며

계획은 단기 계획 ➡️ 중기 계획 ➡️ 장기 계획으로 조금씩 나아갑니다. 조금씩 단계를 거쳐가면서 필요한 일과 해왔던 일에 대해서 정리를 하고자 합니다. 현재 2025년 9월 기준으로 속해 있는 LG전자에서는 단기 계획을 넘어서 중/장기 계획을 수립하여 나아가는 단계에 놓여있고 중/장기 계획을 수립하는 과정에 있습니다.

이를 기반으로 현재의 실제 계획을 수행하고 있는 경험과 기존의 회사에서 경험 하였던 계획 수립과 계획 실행을 기반으로 글을 작성하려고 합니다. 생각보다 거창한 이야기는 아닐 수도 있고 엄청나게 혁신적인 이야기는 아닐 수 있지만 아마도 누구나 해야 하고 누구나 필요한 이야기 일 것입니다.

항상 이야기 하지만 저의 이야기가 전부 정답은 아니며, 각자의 상황과 여건에 맞게 받아들이면 좋겠습니다. 이글로 인해서 경험을 해보지 못하여 방황하거나 다른 회사의 사례를 듣고자 하는 분들에게 귀감이 되었으면 좋겠습니다.

단기 계획은 0~2년 정도의 계획이라고 생각 됩니다. 조금 빠르면 0~1년이라고 할 수 있습니다. 이 역시 회사의 여건과 현재 자신의 상황에 따라서 많은 부분이 다를 거라고 생각됩니다. 어느 회사의 경우 조금 여유가 있기에 3년이라고 생각할 수도 있을 것 같습니다.

처음 아무것도 없는 환경에서는 우선 데이터 플랫폼의 선정이 주요하다고 봅니다. 레이크 하우스의 구축을 하거나 데이터 웨어하우스 시스템을 구축하거나 하는 등의 여러가지 플랫폼 구축을 하고 이를 기반으로 모니터링 및 데이터 파이프라인 개발이 필요한 시기입니다. 추가적으로 로그 자체가 없는 경우도 있을 텐데 이 경우 로그를 만드는 작업부터 해야 하는 경우가 있습니다. 다행히 저의 경우 개발자분들이 로그를 미리 만들어주셨기에 로그를 심는 과정부터 진행하진 않았습니다. 만약에 로그가 없지만 빠르게 분석이 필요한 경우 관계형 데이터베이스에서 일단 데이터를 가져와서 인사이트를 얻을 수도 있습니다.

다음은 단기 계획에 대해서 표로 정리한 것 입니다. 순서대로 정리하였으며 필요에 따라서 해도 되고 안 해도 됩니다.

계획	계획 내용	비고
로그 설계/개발	로그가 없다면 설계가 필요함 (이미 있는 경우가 많음)	관계형 데이터베이스의 데이터를 임시로 사용하는 경우도 있음 또는 로그 플랫폼(?)을 사용하기도 함 (Google Analyics / Amplitude 등)
데이터 플랫폼 선정 및 구축	데이터를 담을 데이터 플랫폼 구축 필요함 (예시 : BigQuery / Snowflake / Databricks등)	레이크하우스를 구축할것인지 정보계 데이터 웨어하우스를 만들것인지 구축 범위 협의도 필요
데이터 아키텍처 설계 및 정책 수립	데이터가 어디에 어떻게 적재되고 어떠한 형태로 적재될지부터 정책등을 만들어야함 또한 데이터 관련 정책을 수립하여 데이터가 잘 쌓이고 잘 활용되도록 해야함	참고 : 데이터아키텍처란 무엇인가?
데이터 파이프라인 개발	데이터를 담을 데이터 플랫폼을 구축 하였다면 데이터 플랫폼에 담을 데이터를 가져와야 함
데이터 모니터링 개발	데이터 파이프라인 / 정합성등의 체크를 하는 모니터링 개발	필요에 따라서 파이프라인 구축과 동시에 진행 필요
데이터 플랫폼 운영	데이터 플랫폼을 운영하여 사용자가 잘 사용 하도록 함

1. 로그 설계/개발

일단 아무것도 없는 경우 로그 설계부터 시작해야 합니다. 로그를 만들어야지 그것을 담을 그릇을 만들어도 담을 내용물이 있기 때문에 이 작업은 굉장히 중요합니다. 로그를 당연하게도 기획/사업/마케팅등 데이터를 실제 사용할 사람들의 의견을 반영하여 설계를 하는 게 좋습니다. (나중에 만들었는데 실제 사용자가 못쓰면 무슨 소용이겠습니까...?)

아마 이 로그 설계와 개발은 회사의 여건에 따라서 가능 하기도 하고 불가능하기도 하고 오래 걸리기도 하고 빠르게 진행되기도 할 것 같습니다. 관련해서 조금 더 자세한 내용은 아래의 글을 참고하면 좋을 거 같습니다.

[공통] 데이터를 적재하고 보기까지

[공통] 데이터를 적재하고 보기까지

burning-dba.tistory.com

앞서 말한것과 같이 로그가 없으면 만들어야 하지만 아닐 경우 관계형 데이터베이스에서 가져와서 인사이트를 얻을 수도 있습니다. 관계형 데이터베이스에서 데이터를 가져오기 위해선 아무 준비가 없어 가능은 하지만 제가 예전에 썼던 글을 참고하면 조금 더 안전하고(?) 좋은 성능으로 관계형 데이터베이스에서 데이터를 가져올 수 있습니다.

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

안녕하세요. 데이터엔지니어 주형권입니다. 오랜만에 꽤나 길고 범용적인 주제에 관해서 글을 쓰려고 합니다. 많은 회사에서 데이터를 활용하여 많은 업무를 하고 데이터를 이용해서 많은 의사

burning-dba.tistory.com

2. 데이터 플랫폼 선정 및 구축

로그가 어느정도 준비되었거나 관계형 데이터베이스에서 가져오기로 하였다면 데이터를 담을 공간이 필요합니다. 그렇기 때문에 여러 가지 데이터 플랫폼 중에서 하나를 선택하기도 하고 필요에 따라서 여러 개를 선택하기도 합니다. 다만 저는 한 개로 통일하여 사용하시길 권장드립니다. (나중에 관리 포인트가 너무 많아지고 각 데이터플랫폼마다 특색이 달라서 공부할게 많아집니다.)

다양한 데이터플랫폼

데이터 플랫폼의 경우 제가 아는 것만 나열해도 10개가 넘을 것 같고 위의 사진에 나오지 않은 여러가지 수많은 오픈소스 플랫폼 /상용 플랫폼 등 여러 가지 플랫폼이 있습니다. 제가 알지 못하는 플랫폼도 엄청나게 많을 거라고 봅니다. 사실 데이터 플랫폼을 무엇을 선택하는지는 본인의 상황과 회사의 상황에 따라서 모두 다른 것 같습니다. 꼭 위의 사진에 데이터 플랫폼을 사용하지 않아도 되고 관계형 데이터베이스를 데이터 플랫폼으로 사용하는 곳도 많이 있습니다.

관련해서는 아래의 글을 참고하면 도움이 많이 될거 같습니다. LG전자에서 1년 동안의 Databricks 구축에 관련된 회고 글입니다. 전반적인 데이터플랫폼 구축 과정을 담고 있으면 이 글의 기술적 압축본이라고 보면 좋을 거 같습니다.

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

안녕하세요. 주형권입니다.태어나서 처음으로 회고라는 것을 해보네요. 회고라는 것이 무엇인지 몰라서 인터넷을 검색하다가 다양한 회고 기법에 대해서 보았고 잘 모르겠어서 AI에게도 질문을

burning-dba.tistory.com

3. 데이터 아키켁처 설계 및 정책 수립

데이터를 어디서 받아서 어떻게 저장하고 어떠한 단계를 거쳐서 어떻게 제공할지 등의 전체적인 그림을 보여주는 것이라고 알고 있습니다. 대표적으로 Databircks에 메달리온 아키텍처가 있으며, 이러한 데이터 아키텍처를 설계하여 데이터가 어디에 적재되어야 할지 등과 데이터를 어떻게 보여줄지 등을 보여줘야 합니다.

Databricks 메달리온 아키텍처

데이터 아키텍처를 설계하고 이를 기반으로 데이터플랫폼을 만들었다면 정책을 세워야 합니다. 데이터 정책에 여러가지 예시가 있는데, 예를 들면 데이터권한 관리 또는 데이터 배치 주기 또는 사용자들에게 제공할 데이터와 제공하지 않을 데이터등의 정책이 필요합니다.

사실 이 부분은 조금 더 큰 범위로 말하면 데이터 거버넌스라고 할 수 있습니다. 그런데 굳이 거버넌스라고 하지 않은 이유는 초기에 거버넌스 부서가 있지 않은 경우가 대부분이고 있다 하더라도 엄청 세세한 부분까지 빠르게 만들어지는 어려울 거라고 봐서 정책이라고 약간(?) 축소하여 말하였습니다. 물론 거버넌스를 처음부터 확실하게 정하고 가면 제일 좋겠지만 초반에 이런저런 인력 및 시간적 이슈로 그렇지 못한 경우가 많아서 정책이라고 표현하였습니다.

4. 데이터 파이프라인 개발

로그도 준비가 되었고 담을 그릇(데이터 플랫폼)도 준비가 되었다면 이제는 데이터를 넣어야 합니다. 데이터를 넣을 파이프라인을 만들어서 데이터 플랫폼에서 데이터를 볼 수 있도록 만들어야 합니다. 데이터의 형태는 크게 3가지로 나뉘는데 초반에는 거의 대부분이 정형/반정형 데이터를 취급합니다. (아닐 수도 있지만 저의 경험상으론 그랬습니다.) 정형의 경우 주로 관계형 데이터베이스의 데이터를 의미하고 반정형의 경우 parquet 또는 Json이나 avro 같은 데이터를 의미합니다. 이러한 데이터의 경우 형태가 어느 정도 있기에 가져오는데 무리가 크게 없습니다.

우선 정형 데이터의 경우 신경 써야 하는 게 관계형 데이터베이스에서 데이터를 가져올 때 성능을 고려해서 가져와야 합니다. 위에서 언급한 [ETL] RDB에서 데이터를 ETL을 위한 최소한의 테이블 설계를 참고하시면 많은 도움이 될 것으로 보입니다. 아무리 강조해도 관계형 데이터베이스의 성능을 절대적으로 고려해야지 추후에 문제가 없습니다. 나중에 가서 파이프라인을 고치는 행위는 정말 많은 시간과 노력이 필요하고 데이터 파이프라인을 고치지 않고 관계형 데이터베이스를 고치려고 하면 정말 나중에 수십 수백 배의 시간과 노력이 필요합니다. (못 믿겠으면 한번 해보시길 권장...^^)

반정형의 경우는 성능도 성능이고 비용을 주로 많이 고민하는 것 같습니다. 아무래도 사용하는 만큼 부과되는 ETL 도구나 AWS / GCP 같은 곳에서 제공하는 도구등을 사용하거나 아니면 Spark 같은 도구등 여러 가지 도구를 사용해서 데이터를 ETL 하실 텐데 성능적으로는 파일 시스템에 분산처리를 하시기에 성능은 아주 잘 나올 것으로 예상됩니다. (아닌 경우도 있습니다.) 그래서 아마도 성능보다는 비용적으로 처리 비용을 아껴서 하시는 것에 중점을 둘 것으로 보입니다. 주로 네트워크 비용 (데이터 전송비용)과 저장비용 그리고 컴퓨팅 비용을 많이 중점적으로 봐야 할 것입니다.

5. 데이터 모니터링 개발

모니터링의 경우 자칫 쉽게 생각하여 나중에 만들지라고 생각할 수 있는데요. 그렇지 않습니다. 생각보다 모니터링만으로도 장애율을 많이 줄일 수 있고 비용적인 부분에서도 많은 부분을 잡아낼 수 있습니다. 자세한 이야기는 제가 이전에 썼던 모니터링 관련 글을 참고하면 좋을 거 같습니다.

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

안녕하세요. Databricks 관련해서 글을 쓰다 보니 굉장히 기본적인 모니터링 관련해서 글을 쓰지 않았네요. 제가 오늘 말씀드릴 내용은 아마도 모니터링에 가장 기본적인 Job에 대한 모니터링 방법

burning-dba.tistory.com

Databricks용으로 쓰긴 했지만 사실상 다른 데이터 플랫폼에도 적용 가능하며 읽어보면 많은 도움이 될 것 같습니다. 제 경험상으로 모니터링만으로도 실시간으로 데이터파이프라인 실패를 감지하고 불필요하게 발생하는 비효율 Query 등을 잡아내서 튜닝을 해주고 많은 것들을 할 수 있습니다.

6. 데이터 플랫폼 운영

데이터 플랫폼 운영을 굳이 따로 뺀 이유는 생각보다 할 일이 많아서입니다. 단순하게 데이터 추출이나 단순히 모니터링에 그치지 않고 데이터 플랫폼의 성능 튜닝이나 모니터링 고도화 파이프라인 고도화등 여러 가지 해야할 일이 많습니다. 실제로 제가 사용하는 Databricks에서도 Optimize / VACCUM등 여러가지 주기적으로 해줘야 하는 일이 있고 관계형 데이터베이스를 기반으로 데이터 플랫폼을 구축하신 분들이라면 백업과 인덱스 리빌딩등 해야 할게 참 많을 것 같습니다.

여기에 당연하게도 데이터 추출 및 데이터 사용자 관리등도 운영에 포함될 것입니다. 데이터 추출이 엔지니어로써 굉장히 하기 싫은 일이지만 어쩔수 없이 해야할수 밖에 없는 일이고 사용자가 늘어남에 따라서 여러가지 권한 문제나 어디까지 데이터를 제공할지의 문제도 봉착하게 될 것 입니다.

여기에 조금 더 나아가 비용의 압박을 조금씩 받기 시작할 것입니다. 보통 2년 차부터 받았던 거 같고 이 부분은 중기 단계에서 조금 더 자세히 다뤄볼까 합니다.

[Databricks] Job Monitoring 방법론 : 수집 알람 보기

주형권 — Tue, 2 Sep 2025 08:04:28 +0900

안녕하세요. Databricks 관련해서 글을 쓰다 보니 굉장히 기본적인 모니터링 관련해서 글을 쓰지 않았네요. 제가 오늘 말씀드릴 내용은 아마도 모니터링에 가장 기본적인 Job에 대한 모니터링 방법에 관련된 내용입니다. Databricks를 운영하면서 수도 없이 많은 모니터링을 만들었지만 아마도 이 모니터링을 가장 처음 만들었던 거 같습니다.

Databricks 운영에 관련해서 다른 글을 보시고 싶으시면 아래의 글을 참고해주세요.

[Databricks] Databricks 운영 정리 - 1편 :: 데이터엔지니어 군고구마

[Databricks] Databricks 운영 정리 - 1편

안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제

burning-dba.tistory.com

들어가며

위에서도 언급하였지만 Databricks의 모니터링의 필수요소라고 할 수 있는 Job에 대해서 오늘 글을 쓰고자 합니다. Job의 경우 아래의 그림에서 나오는 메뉴에 대한 부분입니다.

해당 내용에 관련해서 제일 먼저 만든 게 알림이였습니다. 우선 알람이 오고 빠르게 실패 유무를 확인해야지 실시간으로 대응이 가능했기에 Job의 실패 여부에 대한 알람 발송부터 만들었던 거 같습니다. 이후부터는 Job의 비용에 관한 대시보드를 만들어서 보여주기 시작했고, 이를 기반으로 Job마다 얼마의 비용이 나오는지 확인하고 이 비용을 줄여나가는 작업을 하였습니다.

이번 글에서는 작업의 실패여부를 감지하여 Teams로 발송하여 알람을 보내고 작업당 비용을 수집하여 일 배 치로 지표화 하는 과정에 대해서 설명하고 있습니다. 아마도 이 정도만 해도 Databricks의 Job에 대부분의 모니터링이 될 것으로 보입니다.

1. 데이터 가져오기

우선 무엇을 하든지 데이터가 있어야 합니다. 데이터를 가져와야지 그다음에 지표화를 하거나 알람을 발송할 수 있습니다. 저 같은 경우 Databricks에서 제공하는 api를 사용하였고, 이를 AWS에 RDS에 저장하고 알람/지표를 생성하였습니다. 간략하게 아키텍처를 그리면 다음과 같습니다.

위와 같이 API와 system table에서 데이터터를 가져왔습니다. 그리고 이것을 AWS의 RDS(Aroura)에 저장하고 이를 Superset으로 시각화하고 Teams 메시지로 발송하여 알림을 만들었습니다. 이 모든 과정을 Airflow를 통해서 스케줄 처리하고 Python기반으로 코드를 만들었습니다.

1.1. Job 실패 유무 데이터 가져오기

우선 Job 실패 유무의 경우 system.lakeflow.job_run_timeline 테이블에서 정보를 가져올 수 있습니다. 그래서 아래에 이야기 할 Job의 비용 관련 테이블을 가져올때 함께 가져올수 있지만 저는 해당 테이블을 사용하지 않았습니다. 그 이유는 해당 테이블이 실시간 동기화가 아니고 랜덤 하게 동기화되기 때문입니다. 실시간으로 데이터가 동기화되지 않아서 자칫 제가 해당 정보를 수집할 때 데이터가 없거나 테이블에 업데이트가 되어 있지 않아 잘못된 알람이나 정보를 알려 줄 수 있기 때문에 저는 Databricks의 API를 사용하였습니다.

제가 사용한 API의 경우 jobs/runs/list입니다.

Databricks REST API reference

docs.databricks.com

해당 API의 경우 실시간으로 실행되는 정보를 그대로 가져오기 때문에 누락의 위험이 없고 실시간으로 작업의 실패 여부를 판단 가능 합니다. 또한 Databricks의 Rest API의 경우 현재로서는 큰 제약이 없어서 여러 번 호출해도 큰 이슈가 없습니다. (추후에 유료화 or 제한이 있을 수 있습니다.)

저의 경우 다음과 같이 변수화 하여 받았습니다. job/runs/list의 경우 굉장히 많은 항목을 자세하게 볼 수 있습니다.

job_id = job_run_row.get('job_id')
run_id = job_run_row.get('run_id')
run_name = job_run_row.get('run_name')
run_page_url = job_run_row.get('run_page_url')
creator_user_name = job_run_row.get('creator_user_name')
job_state = job_run_row.get('state').get('life_cycle_state')
job_result_state = job_run_row.get('state').get('result_state')
job_start_time = datetime.fromtimestamp(job_run_row.get('start_time')/1000)
job_end_time = datetime.fromtimestamp(job_run_row.get('end_time')/1000)
run_duration = job_run_row.get('run_duration')/1000

저는 위의 내용을 기반으로 Job의 내용을 가져와서 실패 여부를 체크하였습니다. 물론 더욱 자세하게 볼 수 있으며 여러 가지 항목을 더 필요로 할 경우 위의 링크를 통해서 필요한 정보를 가져와 주시면 좋을 듯합니다.

1.2. Job 비용 관련 데이터 가져오기

Job의 비용에 관련해서는 system.billing.usage를 참고하였습니다.

SELECT
    usage_date,
    workspace_id,
    sku_name,
    usage_metadata.job_id AS job_id,
    SUM(usage_quantity) AS total_dbus_consumed
FROM system.billing.usage
WHERE usage_metadata.job_id IS NOT NULL 
    AND usage_date >= '{tddate}'
GROUP BY usage_date,workspace_id,sku_name,usage_metadata.job_id

위의 SQL을 보면 job_id가 IS NOT NULL을 가져옴으로써 job을 필터 할 수 있습니다. 저 같은 일 배 치로써 하루 한 번씩 RDS에 집계하면서 가져오도록 만들었습니다.

아래의 스키마 정의서에서 씐 부분을 붉은색으로 표기하였으며, 자세한 내용의 위의 테이블 링크를 참고해주세요. (이곳에 모든 칼럼이 있진 않습니다. 너무 컬럼이 많아서 잘렸습니다.)

1.3. Job 리스트 가져오기

Job의 실행 관련 데이터 이외에 가져와야 하는 게 Job의 리스트입니다. 여기에는 실행자 / 생성자가 있으므로 담당자를 알아야지 해당 담당자에게 알람을 발송할 수 있으므로 꼭 필요합니다. 또한 추가적으로 몇 가지 좋은 정보들이 있어서 저는 Job의 성공/실패를 알려주는 API와 별개로 해당 API도 호출하여 계속해서 Job 리스트를 가져옵니다.

제가 사용하는 Job리스트를 가져오는 API는 api/2.2/jobs/list이며, 아래에서 자세하게 볼 수 있습니다.

List jobs | Jobs API | REST API reference | Databricks on AWS

Databricks REST API reference

docs.databricks.com

아래와 같이 몇몇의 값을 가져와서 RDB에 저장하고 있습니다.

creator_user_email = result_job.get('creator_user_name')
run_as_user_email = result_job.get('run_as_user_name')
run_as_owner = result_job.get('run_as_owner')
job_name = result_job.get('settings').get('name')
schedule_time = json.dumps(result_job.get('settings').get('schedule'))
task = json.dumps(result_job.get('settings').get('tasks'))
create_time = datetime.fromtimestamp(result_job.get('created_time')/1000)
tags = json.dumps(result_job.get('settings').get('tags'))

1.4. 가격표 가져오기

가격표 가져오기(?)라고 하여 이게 뭐지? 싶은 분들이 많으실 겁니다. Databricks의 경우 모든 가격의 표기를 USD가 아닌 DBU (Databricks Unit)으로 하기 때문에 이것을 우리가 볼 수 있도록 하려면 USD로 바꿔줘야 합니다. 그런데 가격이라는 게 환율처럼 항상 변경이 됩니다. 그래서 Databricks 내에서 제공하는 테이블을 통해서 가격표를 매일 가져와야 합니다.

가장 최신의 데이터를 가져오기 위해서 PARTITION BY를 사용하였습니다. PARTITION BY를 이용해서 가장 마지막에 업데이트된 가격에 대해서 모두 가져옵니다.

SELECT 
   price_start_time
  ,sku_name
  ,pricing
FROM 
(
  SELECT ROW_NUMBER() OVER (PARTITION BY sku_name ORDER BY price_start_time DESC) AS rank
          ,price_start_time,sku_name,pricing.default as pricing
  FROM system.billing.list_prices
)AS T
WHERE rank = 1

가격이 업데이트될 때마다 APPEND 형태로 추가되는 것으로 보이며, 그렇기 때문에 최신 데이터만 필터 해서 가져오면 다음과 같이 가져올 수 있습니다.

위의 내용을 가지고 sku_name과 조인하여 보여주면 DBU를 USD로 보여줄 수 있습니다.

2. 알람 보내기

알람은 Teams 기준으로 만들었습니다. 왜냐면 저희 회사에서는 공식적으로 Teams를 사용하고 있어서 Teams를 활용하였습니다. Teams를 통해서 보내는 참고할 자료는 아래의 링크를 확인해 주세요.

[Teams] Python에서 Power Automate Workflow을 이용한 Teams 메시지 전송 :: 데이터엔지니어 군고구마

[Teams] Python에서 Power Automate Workflow을 이용한 Teams 메시지 전송

안녕하세요. 주형권입니다. 최근에 Python을 통해서 특정 상황에서 Teams 채널에 메시지를 전송 할때 다음과 같이 알림이 발생하여 다른 방법으로 보내는 방법을 찾는 과정을 정리하였습니다. 이

burning-dba.tistory.com

[Python/Teams] Teams Webhook 메시지 보내기 — 데브옵스 놀이터

[Python/Teams] Teams Webhook 메시지 보내기

[Python/Teams] Teams Webhook 메시지 보내기 팀즈 채널의 커넥터에서 Incoming Webhook을 구성하면, Webhook URL을 얻을 수 있다. 파이썬의 requests와 json 라이브러리를 통해 webhook 메시지를 json형태로 전달할 수

heywantodo.tistory.com

작년부터 Teams에서 webhook을 없앤다고 하였는데 잘 서비스되고 있고 Power Automate Workflow는 아직 안정화가 안된 거 같아서 저는 webhook을 조금 더 추천드립니다. 물론 다양한 기능은 Power Automate Workflow가 조금 더 좋지만 안정성은 제 개인적 생각으로 webhook이 좋은 거 같습니다.

일단 위에서 저장한 2개의 테이블 1.1.Job 실패유무 테이블 / 1.3.Job 리스트 테이블 2개를 이용해서 아래와 같이 데이터를 만들어서 for문을 돌리면서 더 아래에 JSON을 이용해서 Teams 메시지를 발송하였습니다.

SELECT CONVERT_TZ(job_start_time, 'UTC', 'Asia/Seoul') AS job_start_time
            ,CONVERT_TZ(job_end_time, 'UTC', 'Asia/Seoul') AS job_end_time
            ,a.job_id
            ,a.job_name
            ,a.job_state
            ,job_result_state
            ,creator_user_email
            ,a.workspace_name
            ,a.run_page_url
FROM monitoring.databricks_job_task AS a -- 1.1. 테이블
LEFT JOIN monitoring.databricks_job_list AS b -- 1.3. 테이블
ON a.job_id = b.job_id 
WHERE a.job_end_time >= DATE_ADD(DATE_FORMAT(NOW(),'%Y-%m-%d %H:00'), INTERVAL -1 HOUR)
AND a.job_result_state NOT IN ( 'SUCCESS','CANCELED') 
AND a.job_name NOT LIKE 'TEST_%' -- TEST라고 앞부분에 넣으면 알람 안받음(테스트용은 X)

아래는 webhook 기준으로 보내는 JSON입니다. 참고해서 사용해주시면 좋을 거 같습니다. 그리고 여기에 JSON에 보시면 몇 가지 이모티콘이 있는데요. 아래에 사이트를 들어가서 키워드에 맞춰서 검색하면 알맞은 이모티콘이 나옵니다.

Storage Emojis | ️ ️ | Copy & Paste

We've searched our database for all the emojis that are somehow related to Storage. Here they are! There are more than 20 of them, but the most relevant ones appear first.

emojidb.org

{
    "type": "message",
    "attachments": [
        {
        "contentType": "application/vnd.microsoft.card.adaptive",
        "content": {
            "type": "AdaptiveCard",
            "size": "Large",
            "body": [
                {
                    "type": "TextBlock",
                    "size": "Large",
                    "weight": "Bolder",
                    "text": "**  Databricks 작업 실패 알람**"
                },
                {
                    "type": "TextBlock",
                    "text": "<at>user_mention</at>",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  Workspace : {workspace_name}",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 이름 : {job_name} / ({job_id})",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 수행 시간 : {start_date} ~ {end_date}",
                    "wrap": "true"
                },
                {
                    "type": "TextBlock",
                    "text": f"  작업 상태 : {job_state}[{job_state_result}]",
                    "wrap": "true"
                },
                {
                "type": "ActionSet",
                "actions": 
                    [
                        {
                        "type": "Action.OpenUrl",
                        "title": "  작업 바로가기",
                        "url": f'{run_page_url}'
                        }
                    ]
                }
            ],
            "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
            "version": "1.0",
            "msteams": {
                "width": "Full",
                "entities": [
                    {
                        "type": "mention",
                        "text": "<at>user_mention</at>",
                        "mentioned": {
                            "id": f"{job_creator}",
                            "name": f"{job_creator}"
                        }
                    }
                ]
            }
        }
    }]
}

위의 내용에 대해서 결과물은 다음과 같이 나옵니다. 아주 심플하게 만들었고 링크를 통해서 담당자가 바로 해당 Job으로 접근이 가능합니다.

3. 대시보드

대시보드의 경우 엄청 많지는 않고, 몇몇의 필요한 대시보드만 만들어서 봤습니다. Superset을 이용해서 만들었으며 요청하시면 해당 대시보드를 만든 SQL이나 여러 가지 기법은 개별적으로 메일로 보내드리겠습니다.

3.1.Job 실행 내역 대시보드

특정 Job이 갑자기 오래 걸리거나 평소에 얼마나 걸리는지 확인을 위해서 만들었습니다. 위의 내용은 모든 Job을 클릭해서 그렇지만 특정 Job을 검색하면 아래와 같이 상세하게 분석이 가능합니다. 물론 더 아래쪽에 표 형태로 존재합니다. (지울 게 너무 많아서 귀찮아서 안 붙였습니다...)

실행 내역의 경우 특정 작업이 오래 걸리거나 하는 것을 볼 수도 있고 갑자기 전체적으로 시간이 늘어난 것도 볼 수 있습니다. 이럴 경우 작업을 조정하거나 컴퓨팅 성능을 늘리거나 하는 여러 가지 조치를 취할 수 있습니다. 관련해서 작업 시간이 오래 걸리는 SQL을 추적하는 방법은 아래의 링크를 통해서 볼 수 있습니다.

[Databricks] 비효율적인 작업 추적기 만들기 :: 데이터엔지니어 군고구마

[Databricks] 비효율적인 작업 추적기 만들기

burning-dba.tistory.com

3.2. Job 실행 리스트 대시보드

어딜 가나 전체적인 현황을 보여주는 대시보드는 있어야 합니다. Databricks 자체에서 제공하긴 하지만 region을 여러 개 사용하는 사람들의 경우 하나씩 들어가서 봐야 하는 번거로움이 있습니다. 그렇기 때문에 이를 합쳐서 볼 수 있도록 1.3.Job리스트 테이블을 이용하여 다음과 같이 한 번에 볼 수 있는 대시보드를 만들었습니다.

그리고 추가적으로 실행시간을 보여줌으로써 사용자가 언제 내가 요청한 데이터가 동기화되는지 알 수 있습니다. 그렇기에 조금이나마 문의사항을 덜어줄 수 있습니다.

3.3. Job 비용 대시보드

아마도 이 대시보드가 반응이 제일 좋았던 거 같습니다. 비용에 관련해서 민감하기 때문에 대시보드를 통해서 어떠한 Job이 비용이 많이 들어가는지 한눈에 본다면 그만큼 대처가 빠르고 정확해집니다. 이 대시보드를 통해서 몇몇의 불필요하거나 비용이 많이 들어가는 Job에 대해서 튜닝을 통해서 비용을 절감하였습니다.

해당 대시보드의 경우 1.2.Job 비용 관련 테이블을 이용해서 만들어졌으며, Superset에 Pivot Table을 이용해서 만들었습니다. 아마 1.2.Job비용 관련 테이블을 잘 적재하셨다면 지표를 만드는 데는 큰 문제는 없을 것 같습니다.

관련해서 비용이 많이 나오는 경우 알람을 보내는 기능도 추가할 수 있습니다. 이건 취향(?)에 따라서 운영자가 하면 좋을 것 같습니다.

마치며

운영은 정말 끝이 없는 거 같습니다. 이렇게 길고 여러 개의 글을 썼는데 아직도 써야 하는 글이 산더미인 것을 보면 정말 끝이 없습니다. 운영은 계속해서 나오고 계속해서 진화하는 거 같습니다. 최근 AI로 인해서 많은 사람들이 직업에 위기를 느끼지만 저는 딱히 느끼지 못합니다. 왜냐면 그 AI 조차도 운영을 해야 하거든요...

그렇기 때문에 저는 오히려 운영을 고도화하고 운영에 대해서 경험이 많은 엔지니어로써 계속해서 성장하고 싶습니다. 그에 대한 몇 가지 팁 중에 오늘은 Databricks Job에 모니터링에 대해서 알아봤습니다. 어찌 보면 가장 먼저 다뤘어야 하지 않았나 싶었지만 하다 보니 Databricks Job의 모니터링을 빼먹고 있는 걸 얼마 전에 알았습니다. 그래서 부랴부랴 글을 작성하였습니다.

이글이 많은 데이터 엔지니어 나아가 데이터를 다루는 모든 분들에게 영감이 되었으면 좋습니다. 감사합니다.

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

주형권 — Thu, 24 Jul 2025 13:54:57 +0900

두오모 성당

이 글의 핵심 요약

무슨 도전이었나: Databricks 경험이 전무한 상태에서 이미 가동 중인 대규모 데이터 환경을 인수받아, 플랫폼의 현황을 파악하고 안정적인 운영 체계를 확보해야 하는 극한의 과제에 직면함.
어떻게 해결했나:
1. 모아이(MOAI) 모니터링 시스템을 선제 구축하여 비용 및 실패 지표를 시각화하고,
2. VACUUM 최적화를 통해 S3 스토리지의 불필요한 데이터 수백 TB를 청소했으며,
3. 파티션 재설계 및 쿼리 최적화로 성능을 극대화하는 동시에 업무 프로세스를 도식화하여 팀원들과 함께 시너지를 내는 구조를 확립함.
무슨 가치를 얻었나: 인프라 비용 대폭 절감 및 쿼리 성능 향상이라는 하드웨어적 성과를 넘어, "누구나 데이터를 쉽게 사용할 수 있는 데이터 민주화(Democratization)"의 기반을 다지고 팀 전체의 엔지니어링 눈높이를 상향 평준화함.

안녕하세요. 주형권입니다.

태어나서 처음으로 회고라는 것을 해보네요. 회고라는 것이 무엇인지 몰라서 인터넷을 검색하다가 다양한 회고 기법에 대해서 보았고 잘 모르겠어서 AI에게도 질문을 하였습니다. 그래서 제가 내린 결론은 결국 형식과 틀은 없다입니다. 딱히 무언가 정해진 틀은 없는 거 같고 다양한 기법이 존재하는 거 같습니다.

저는 이러한 기법을 사용하지 않고 제가 느꼈던 점과 어려웠던 점을 이야기 해보고 다른 사람들에게 영감을 주었으면 좋겠습니다. 항상 이야기하듯이 저의 경험과 기술은 정답이 아니며 참고를 하고 앞서 말했듯이 영감을 받기를 바랍니다. 딱 참고 정도 하면 좋겠습니다.

이 회고는 제가 현재의 회사에 입사하고 처음으로 Databricks라는 데이터 플랫폼을 접하고 이를 기반으로 데이터 환경을 구축한 경험을 기반으로 작성하였습니다. 현재 입사 후 어느덧 1년이 지났고 지금까지 경험하였던 어려움과 새로운 경험 그리고 새로운 배움 그리고 이를 통해서 느끼는 생각과 앞으로 남은 과제까지 여러 가지 부분에 대해서 작성하였습니다.

시작 : 입사 후 1~3개월의 상황 파악과 급한 불 끄기

이 회사에 입사는 2024년 06월에 하였습니다. 슬슬 더워지기 시작 할때즈음에 입사를 하였고 입사 첫날 인사팀에 입사 관련하여 서류 작성과 회사 내부 복지나 여러 가지 제도등을 간략하게 들었습니다. 그리고 끝나자마자 일을 시작했습니다. 당장 다음 주에 오픈해야 하는 서비스가 있는데, 이걸 오픈해야 했거든요... 입사하고 아직 계정도 못 받았지만 일단 시작해야 하니 일단 상황 파악을 하고 이것을 잘 오픈하는 것이 급선무였습니다.

어찌어찌 급한불은 끄고 상황을 하나씩 파악했습니다. 우선 현재 데이터 플랫폼이 Databricks라는 점을 듣고 Databricks에 대해서 공부를 시작하였습니다. 저는 태어나서 한 번도 Databricks를 해본 적이 없거든요....

인생 처음 접하는 Databricks

제가 공부만 하고 있을 순 없었습니다. 왜냐면 그럴 시간이 없었습니다. 이미 Databricks를 이용한 데이터 환경이 오픈을 하고 실제로 사용하는 사람도 있었습니다. 사용자는 많지 않지만 그래도 있으니 어떻게든 운영을 해야 했습니다. 우선 데이터는 잘 들어오는지 이 데이터들은 문제가 없는지 수명주기나 파티션등 여러 가지 등을 봐야 했습니다.

0. 데이터 아키텍처 설계 : 어떤 곳이든 어떤 일이든 설계는 중요하다.✍

어떤 분야를 떠나서 무슨 일을 하기 전에 계획을 수립 하는 것은 매우 중요합니다. 처음에 입사했을 때 데이터를 적재하고 는 있지만 ODS / MART / FACT와 같이 잘 나뉘진 아키텍처가 아니었고 데이터를 어떠한 네이밍에 맡게 적재하고 어떻게 어디에 얼마나 적재를 해야 하는지에 대해서도 정책이 없었습니다.

설계는 언제나 중요하며, 기반을 잘 다져야지 건물도 튼튼하다.

그래서 우선 만들어야 했던게 데이터 아키텍처였습니다. 우선이라고 했지만 사실상 1번의 모니터링 시스템과 거의 동시에 만들었습니다. 저의 모든 지식과 경험과 각종 글을 참고해서 꾸역꾸역 데이터 아키텍처를 설계하였습니다. 내부적인 아키텍처이기에 공개는 못하겠으나 Databricks의 Medallion 아키텍처와 같은 형식으로 데이터 아키텍처를 설계 하였습니다. 기존에 데이터를 어디에 어떻게 적재할지 몰랐으나 이런 식으로 데이터의 형태와 가공정도에 따라서 데이터를 분류하고 이를 기반으로 Naming Rules을 만들어서 적재적소에 데이터를 나누어서 적재하였습니다.

대략적으로 위와 같이 설계하였고 운영을 하였습니다. 아마도 데이터를 하신 분들이라면 위의 아키텍처가 엄청나게 특별하거나 부족하거나 하기 보다는 그냥 보편적인 느낌일 수 있습니다. ODS -> Mart -> Fact로 이어지는 데이터와 개인이 쓸 수 있는 Personal 데이터를 만들어서 개인이 조작할 수 있도록 하고 인사이트를 도출하도록 하는 여러 가지는 아마 많은 회사에서 도입해서 사용하는 방식일 것입니다.

1. 일단 보고 이야기하자 : 모니터링 시스템 구축

일단 뭐가 어떻게 되어 있는지 현황을 파악하고 당장 모니터링을 통해서 현재의 현황을 보여주는 모니터링 시스템을 구축하여 대시보드를 구축하고 데이터 파이프라인이나 시스템 등이 문제가 있을 때 이를 실시간으로 알려주는 여러 가지 시스템이 필요했습니다.

보고 이야기 하는 게 생각보다 중요하다.

뭐가 어떻게 돌아가는지 알아야지 어디서 문제가 있는지 알 수 있으니까요... 그러면서 자연스럽게 Databricks의 여러 가지 봐야 하는 부분에 대해서 공부를 하였습니다. Databricks에 어떠한 게 필요하고 무엇을 중점적으로 봐야 하고 성능을 끌어올리기 위해서는 무엇이 필요하고 무엇은 필요하지 않고 이것을 판단하려면 현황 파악을 해야 했습니다.

만들었던 것 중에 크게 몇 가지만 나열하면 다음과 같은 것들을 만들었습니다. 이것은 Databricks뿐 아니라 AWS와 데이터 관련 모니터링도 포함 합니다. 저는 이것은 Superset을 이용해서 구축 하였으며 현재 이 모니터링 시스템은 모아이로 불리고 있습니다. 몇가지 중점적인 모니터링 관련해서 적어보면 다음과 같으며, 회사의 내부적인 부분도 있기에 전부 공개하지는 않았습니다.

️ Databricks
- Databricks 비용 관련 DBU 지표
- Workflow 작업 실패 실시간 감지 알림 (메신저 연동)
- 오래 걸리는 작업 감지 알림 ( SQL / Notebook )
☁️ AWS
- S3 Bucket 사이즈 지표
- AWS 전체적인 비용 지표
Airflow
- Airflow Dag 실패 실시간 감지 알림
️ 데이터
- 주요 테이블 건수 체크

여러 가지 모니터링을 만들어서 상황 파악을 어느 정도 하였고 급한 부분을 수습하기에 이르렀습니다. 그중에 몇 가지 사례를 소개하려고 합니다.

2. vacuum : 청소기요? ️

AWS S3의 사이즈를 보고 이상한 생각이 들었습니다. Databricks의 기본 저장소가 S3를 사용해서 Delta가 전부 S3에 있는데 Databricks에서 표기하는 테이블 사이즈와 S3의 사이즈가 너무 많이 차이가 났습니다. 수십~수백 TB가 차이가 나니 이건 왜 이럴까?라는 생각이 들었습니다. 그러다 알아낸 게 Databricks는 vacuum이라는 명령어가 있고 이를 수행 하는것이 굉장히 중요한 것이라는 것이였습니다.

VACCUM 굉장히 중요하더라

일단 이놈이 뭔지부터 공부해서 왜 이게 필요한지를 알아봤습니다. 일단 말 그대로 청소하는 명령어였습니다. 여기서 줄줄이 이야기하면 이야기가 길어지니 관련된 내용은 제가 기존에 써둔 글을 참고하면 좋을 것 같습니다.

[Databricks] Optimize / VACUUM

안녕하세요. 데이터엔지니어 주형권입니다.어느덧 Databricks를 맡고 운영한 지 5개월 정도가 흘렀습니다. 초반에 데이터 아키텍처와 정책을 잡고 서서히 물리적인 데이터를 운영 함에 있어서 꼭

burning-dba.tistory.com

결론적으로 총 합쳐서 수백 TB의 불필요한 AWS S3의 용량을 줄였습니다. 엄청나게 감소하였고 이로 인해서 저장 비용과 처리 비용이 굉장히 많이 감소하였습니다.

3. 왜 느리지? : 파티션을 다시 구축하였다.

파티션은 어느 빅데이터 또는 RDB 모든 데이터 관련 시스템에서 가장 중요하다고 볼 수 있습니다. 파티션이 없으면 엄청나게 느리게 데이터를 처리하고 불필요한 데이터까지 모두 읽어서 처리해야 하기 때문에 당연히 느릴 수밖에 없습니다. 그래서 가장 주요하게 사용되는 핵심 테이블부터 파티션을 재구성하기 시작하였습니다.

현재 다니고 있는 회사가 약간 특이하게도 대규모 삭제를 하고 있다는 것입니다. 그래서 기존에 흔한(?) 데이터 플램폼과 같이 APPEND만 하는 방식과 달리 APPEND와 DELETE가 일어나야 합니다. 그래서 일자별로 파티션을 생성하면 전체 테이블을 모두 조회해서 지워야 하기에 파티션이 너무 많이 파편화됩니다. 그렇다고 다른 것으로 파티션을 걸자니 파티션의 단위가 너무 커져서 처리할 때 이점을 얻지 못합니다.

결론적으로 가장 많이 그리고 가장 자주 사용 하는 패턴을 기반으로 만들었다.

뭐 당연하겠지만 WHERE에 가장 많이 사용하는 칼럼 그리고 가장 자주 사용하는 SELECT 패턴을 기반으로 하나씩 파티션을 재구축하기 시작하였습니다. 여기서 문제는 기존의 테이블이 너무나도 대규모라서 (크게는 1개에 50TB가 넘는) 일반적인 방법으로는 처리가 굉장히 어려웠습니다. 단순히 새로 만들고 부어 넣고 하려고 해도 계속해서 터져 버리는 Databricks를 보면서 현타가 왔습니다.

그때 공부해서 했던 게 바로 Shuffle partition이었습니다. Databricks는 Spark를 기반으로 만들어졌고 (혹시 아니면 말해주세요.) Spark 옵션에 대해서 공부를 하기 시작했습니다. 왜 터질까? 참고로 저는 Spark도 해본 적이 없습니다. 그래서 Databrick와 Spark를 동시에 공부하면서 많은 것을 배웠습니다.

이후에 처리에 많은 시간이 소요되는 작업이 소요시간이 많이 감소되었습니다. 이로 인해서 자연스럽게 Databricks의 비용이 감소하는 효과까지 얻었습니다. 처리하는 양이 줄어들면 그만큼 자원의 소모가 적기에 효율적으로 작업을 할 수 있게 되었습니다.

중간 : 숨을 고르면서 업무를 분배하였다. ️

어느덧 6개월 정도의 시간이 흐르니 시스템이 많이 안정화되었습니다. 급한 불을 끄고 정책을 세우고 아키텍처를 만들고 어느 정도 데이터 플랫폼이 궤도에 올랐습니다. 혼자서는 이제 무언가를 하기엔 힘이 붙이기도 하였고 시니어 엔지니어로써 팀원들을 챙겨야 했고 팀원들에게 업무를 분배해서 각자의 확실한 색을 입혀주고 싶었습니다.

그래서 이것을 정리하기 시작하였고 다음과 같이 업무를 정리하고 업무를 나누었습니다. 각자의 특색에 맞게 업무를 나눔과 동시에 팀원들의 커리어도 잘 챙겨야 했기에 많은 생각을 하면서 업무 분장과 프로젝트를 정리 나아갔습니다.

1. 나부터 정리를! : 업무를 표로 정리하고 자세하게 기입하였다.

일단 저도 업무가 정리가 안되고 미친 듯이 달려왔기에 뭘 했고 뭘 해야 하고 무엇이 미흡한지 몰랐습니다. 그래서 우선 나부터 살고 보자는 생각으로 업무를 정리하였습니다. 그게 아마 입사 후 4~5개월 즈음이었던 거 같습니다. 제 머릿속에서도 정리가 안되는데 어떻게 남에게 주겠습니까?

일단 내 업무를 정리부터 하자.

작년에 제가 해야 했지만 못했던 일과 하려고 했던 일 했던 일을 크게 나누어서 정리를 하였습니다. 분류를 정하고 이에 관련해서 내가 찾아본 아니면 읽으려고 했던 글이 있으면 링크를 걸어두고 제목과 내용 그리고 어디까지 하였는지 진척도까지 표로 정리하였습니다. 대략 이렇게 정리하였습니다.

이렇게 정리하고 내가 지금 할 수 있는 것과 없는 것을 정확히 분류해서 가장 급한 것부터 우선순위로 쳐내야겠다 싶었습니다. 그렇게 정리를 하고 나니 이제 무엇을 해야 할지 보이기 시작하였습니다.

2. 같이 하자 : 업무를 분배해서 함께 시너지를!

이제 업무를 정리하였고 급한 업무도 어느 정도 하였으니 분배를 해야 했습니다. 그래서 모든 팀원을 불러서 여기서 본인이 하고 싶거나 할 수 있다고 생각하는 업무를 고를 수 있도록 하였고 그렇게 프로젝트를 나누어서 수행하였습니다. 큰 프로젝트와 작은 상시 업무를 나눠서 고루 분배하고 본인들의 강점을 최대한 살릴 수 있도록 하였습니다.

혼자서는 한계가 있고 나는 1명이다. 나누고 함께 가야지 오래간다.

이렇게 업무를 나누고 저는 실무적인 측면과 함께 프로젝트를 리딩하는 역할을 많이 맡아서 하였습니다. 고문 격으로 프로젝트에 참가하여 프로젝트를 봐주고 조언을 해주고 방향을 잡아주는 일이 많아졌습니다. 초반에는 많은 부분을 봐줘야 했지만 나중에 가면 갈수록 모든 팀원들의 눈높이가 향상되면서 제가 관여하지 않아도 잘 끝나는 프로젝트가 점차 늘어났습니다.

그렇게 함으로써 저는 더욱 멀리 보게 되면서 팀의 더욱 많고 큰 프로젝트에 대해서 이야기를 할 수 있게 되었습니다. 여러 가지 프로젝트를 동시에 진행도 가능해지고 저뿐 아니라 팀원들도 현재의 팀에서 무엇을 하는지 명확히 이해하고 같은 방향과 목표를 가지고 일을 할 수 있도록 되었습니다.

후반 : 데이터 플랫폼의 비용절감 그리고 사용성 증가를 위한 노력 ‍

후반부로 가면서 데이터 플랫폼이 거의 안정화되었습니다. 그러면서 이제는 안정화를 넘어서서 비용을 절감하고 사용성을 증가시키기 위한 노력이 필요했습니다. 아무래도 데이터 플랫폼이 많은 돈을 쓰다 보니 어느 회사나 비용의 압박은 언제나 받는 거 같습니다. 그래서 데이터 엔지니어는 해를 거듭할수록 어떻게든 돈을 아끼기 위해서 노력하는 거 같습니다. 예전에는 고민하지 않았던 부분까지도 보고 또 보고 하면서 비용을 아끼기 시작하는 거 같습니다.

그리고 나아가 데이터 플랫폼을 만들고 아무도 사용하지 않으면 안 되기에 사용성을 증가시키기 위해서 노력해야 하는 거 같습니다. 처음 엔지니어를 시작할 때 이런 고민을 해본 적이 없었는데 이제는 데이터가 누구나 사용이 가능하도록 하는 것이 많은 회사의 목표이다 보니 이런 고민에 부딪히는 거 같습니다.

1. 돈의 압박 : 정말 쥐어 짜내서 해야 한다.

제가 데이터 플랫폼을 운영하면 정말 짜기로 유명한 엔지니어입니다. 진짜 회사 돈을 내 돈처럼 아껴서 쓰려고 합니다. 돈에 굉장히 민감합니다. 왜냐면 결국 비용이 많이 들면 그 압박은 고스란히 데이터 플랫폼을 운영하는 팀이 받습니다. 사용자는 최대한 이러한 압박을 받지 않도록 해야 하기에 여기저기서 눈치를 봐야 합니다.

더러워서 내가 가끔 내주고 싶다.

라는 말을 가끔 속으로 하지만 절대 그럴 순 없기 때문에 한 푼 두 푼 아끼고 아껴서 해야 합니다. 처음부터 잘 만들어야지 돈도 그만큼 아낄 수 있습니다. 두 번 세 번 작업하면 그게 다 돈입니다. 내 돈은 아니지만 어차피 제가 할 일이니 최대한 돈 아껴서 하는 게 좋겠지요. (그냥 귀찮아서 크긴 하다...)

그래서 저는 최대한 오픈 소스를 많이 활용하고 모니터링도 타이트하게 하려고 노력합니다.

위와 같이 수많은 (이것도 일부입니다.) 모니터링을 통해서 실시간 또는 주기적으로 알람을 받고 이를 끊임없이 검증하고 돈을 더 아낄 수 없을지 고민합니다. 그래야지 누수가 덜하거든요. 그리고 이런 거 준비를 해두면 나중에 위 (팀장님보다 더 위)에서 뭐라고(?) 할 때도 변명(?) 거리가 생깁니다. 우리는 진짜 타이트하게 하는데 많이 쓰는 걸 어떻게 합니까?라고 할 수 있습니다.

말은 변명이지만 이건 사실입니다. 데이터가 많고 많은 사람이 쓰는데 어떻게 합니까? 못하게 할 수도 없고 아니면 느리다고 쓰지도 않을 테고 정말 답이 안 나옵니다. 그래서 그만큼 정당한(?) 사유를 만들어두고 하는 것은 꽤나 유용합니다.

2. 혹시 우리 거 써볼래..? : 잘해줄게요 한번 해보세요.

아마도 제가 가장 크게 힘들어하고 가장 크게 고민하고 가장 크게 하고 있는 부분이라고 생각합니다. 내가 아무리 좋은 플랫폼을 만들었다고 하여도 누구도 사용하지 않는다면 어쩔 수 없이 그 플랫폼이 얼마나 잘 만들었다고 한들 그것은 외면받지 마련입니다. 그렇기에 이것을 잘 사용할 수 있도록 하는 것도 이제는 데이터 엔지니어의 숙명과도 같은 일이 돼 가는 것 같습니다. 하지만 정말 하기 싫습니다. 엔지니어가 하는 일이 얼마나 많은데 이것까지 해야 한다니요...? 근데 어쩌겠습니까? 세상이 변해가는 거 같습니다. 물론 저도 적응이 안 됩니다. 그리고 정말 하기 싫습니다.

잘 만들었으나 아무도 쓰지 않는다면 무슨 소용이겠는가?

그래서 어쩔 수 없이(?) 교육을 준비하고 교육 자료를 만들고 발표를 합니다.

이러한 교육을 진행하고 사람들이 우리가 만든 데이터 플랫폼을 잘 쓰도록 유도했습니다. 요즘은 그래서 "내가 데이터 엔지니어인지 인터넷 강의 강사인지 모르겠다." 싶을 때도 있습니다. 이밖에도 사람들이 잘 따라 할 수 있도록 따라 하기 글을 계속해서 연재하고 업데이트하고 하다 보면 현타가 많이 오긴 합니다.

그래도 한편으로 뿌듯한 것은 다양한 부서에서 사용하고 어떻게 쓰는지 문의가 하고 여러 가지 다양한 시그널이 있을 때는 보람을 느끼기도 합니다. 우리가 있다는 것을 어쩌면 알아주는 것이니까요. 하지만 현타와 뿌듯 사이의 충돌을 생각보다 자주 일어납니다. 아직도 충돌 중이고 아마 앞으로도 몇 년은 계속 충돌하지 않을까 싶습니다.

마무리 : 이제 뭐 하지? 그리고 뭘 더 해야 하지?⁉️

사실 저도 잘 모르겠습니다. 1년 동안 정말 많이 달려왔습니다. 이제는 무엇을 해야 할지 더 이상 찾기도 버겁습니다. 정말 쉴 새 없이 달리다 보니 이제는 달릴 기운도 없습니다. 그래서 숨 고르기 하면서 천천히 주변을 살피고 무엇이 미흡하고 무엇이 있으면 더 좋을지를 고민하고 있는 시기 같습니다.

전부 했다고 할 수 없기에 이것보다 더 나은 것은 없는지 이것보다 더 쉽게는 안되는지를 고민하는 단계인 거 같습니다. 제가 예전에 면접을 가면 "네가 모든 데이터 환경을 구축하고 그다음 스태프로 무엇을 할 것이냐?"라는 질문에 저는 늘 똑같은 대답을 했습니다.

플랫폼 다 구축하면 비용 절감하고 안정화시켜야죠

이제는 이 대답에서 한발 더 나아가야 하지 않을까? 싶습니다. 아마도 그건 사용성 증가겠죠... (진짜 싫지만...) 저는 항상 이걸 전단지 돌린다고 비유합니다. 내가 어떠한 제품을 생산하다가 다 만들었으니 이제 전단지 돌린다고 말이죠. 이게 진짜 싫긴 한데, 중요하지 않다고 하기엔 또 아니라고 생각합니다.

왜냐면 누군가는 써줘야 하거든요. 예전에는 데이터 플랫폼 소위 말해 정보계나 분석계의 사용자가 굉장히 한정적이라고 생각 합니다. 예를 들면 데이터 분석가 / 데이터 과학자 이외에 SQL이나 Python을 조금 하시는 분들이 대상자였다면 이제는 그 대상자의 한계가 없는 거 같습니다. 아니 정확히는 없애라고 많은 회사에서 요구를 하고 있습니다.

나는 데이터 엔지니어니깐 당연히 데이터 플랫폼 운영을 하고 데이터를 적재하고 데이터의 정합성을 검증하고 이런 전통적인 데이터 엔지니어에서 나아가서 이제는 어찌 보면 사용성을 증가시키는 데이터 엔지니어를 많이 필요로 하는 거 같습니다. 그냥 SQL 배우세요. Python 배우세요. 에서 끝나지 않고 어떻게 무엇을 얼마나 이용할지를 알려주고 누구나 쓸 수 있게 보편적으로 만들고 설명하는 부분도 하나의 과제로 주어진 거 같습니다.

끝으로 어느덧 1년의 기간을 이 회사에서 보내면서 너무나도 많은 일이 있었고 앞으로도 있을 것 같습니다. 무사히 잘 지나갔으면 좋겠고 저의 글을 보고 많은 분들이 Databricks 나아가 데이터 플랫폼을 구축하고 운영하는 부분에 있어서 영감을 얻으시고 공감을 얻으시길 바랍니다.

감사합니다.

[Databricks] 비효율적인 작업 추적기 만들기

주형권 — Fri, 11 Jul 2025 09:17:13 +0900

databricks

안녕하세요. 주형권입니다.

정말 오랜만에 글을 쓰는 거 같습니다. 요즘 내/외부적으로 바쁘게 살고 있어서 글을 쓸 시간이 없습니다... 그래서 한 달에 1개 업로드하기도 어렵습니다.

들어가며

Databricks를 이용해서 데이터환경을 구축하고 이를 기반으로 수많은 유저들에게 오픈하여 사용하다보면 어쩔 수 없이 비용이 많이 나오게 됩니다. Databricks도 결국 사용하는 만큼 비용을 지불하기 때문에 그만큼 오래 수행이 된다면 비용을 많이 지불하게 됩니다. (AWS EC2 비용은 별도다. )

어쩔 수 없이 기간을 오래 잡아서 데이터를 집계하거나 어쩔 수 없이 큰 데이터를 조회하는 경우는 어쩔 수 없지만 비전공자나 데이터를 잘 사용해 본 적이 없는 사용자의 경우 파티션이나 리퀴드 클러스터링 등 사용을 하지 않고 그냥 전체적으로 SELECT 하고 집계하는 경우도 많습니다. 이럴 경우 비용도 비용이지만 공용으로 사용하는 클러스터에 무리를 주거나 한 개의 대용량 작업이 점유하고 있어서 다른 작업이 모두 밀리거나 느려지는 경우가 생길 수 있습니다.

그것을 방지하기 위해서 작업을 추적하여 이러한 비효율적인 작업을 추적하도록 하였습니다. 여기에서 나오는 범위는 SQL편집기를 이용한 작업이나 워크스페이스에서 Notebook을 사용한 작업을 추적합니다.

1. SQL편집기 데이터 수집

Query를 추적하는 가장 간단한 방법은 system.query.history 테이블을 사용하는 방법 입니다. 이 테이블에는 수행을 완료한 Query의 전반적인 정보가 나옵니다. 하지만 저는 이 테이블을 사용하지 않고 API를 사용하였습니다. 이 테이블은 수행이 완료된 작업만 나오므로 실제로 점유하고 계속 돌고 있을 경우는 데이터가 나오지 않습니다. 그래서 API를 통해서 SQL 편집기에서 수행하는 Query를 수집하였습니다.

Databricks에서 제공하는 API중에 쿼리 기록(Query History)을 가져오는 API가 있습니다. 이를 가져오는 API를 주기적으로 실행해서 데이터를 수집하였습니다.

https://{domain}/api/2.0/sql/history/queries

API는 sql/history/queries이며, 다음의 링크에서 자세한 내용을 확인 할 수 있습니다.

Databricks REST API reference

docs.databricks.com

API는 엄청나게 자세하게 정보를 JSON 형식으로 제공하는데, 여기서 필요한 정보만 python으로 가져와서 RDB에 저장하도록 하였습니다. RDB에 따로 저장하는 이유는 주후에 Query 관련해서 사용량이나 사용자를 조사하기 위해서 RDB에 저장하고 지표화 하기 위하여 RDB에 저장하였습니다.

이 API의 경우 RUNNING 상태의 현재 실행중인 Query도 모두 나오기 때문에 오랫동안 점유하고 있는 작업도 추적이 가능합니다. 그래서 Databricks에서 제공하는 테이블을 사용하지 않고 API를 사용해서 작업을 추적하였습니다.

2. 워크스페이스 (Notebook) 데이터 수집

워크스페이스의 경우 SQL편집기와 같이 기록을 저장하는 곳이 없는것으로 보였습니다. API를 찾아보려고 하였으나 역시 찾지 못하였습니다. (혹시 있다면 말씀해 주세요.)

그래서 선택한 방법이 system.access.audit 테이블을 사용하는 방법입니다.

Audit log reference | Databricks Documentation

Learn which services and events are recorded in the audit logs.

docs.databricks.com

이 테이블은 원래의 목적은 감사로그이지만 이곳에도 Notebook의 실행에 관련한 내용이 나옵니다. 다음과 같이 Query를 작성하여 테이블을 SELECT 하면 Notebook에서 실행한 내역이 나옵니다.

SELECT *
FROM system.access.audit 
WHERE action_name = 'runCommand'
AND service_name = 'notebook'

이 테이블에서도 마찬가지로 엄청나게 자세한 정보가 나오는데요. request_params에는 notebookid 및 어떠한 클러스터 컴퓨팅을 사용하였는지 현재 상태값과 실행 시간 및 어떠한 작업을 수행하였는지까지 모두 나옵니다. 이를 기반으로 바로가기 링크를 만들어서 Notebook으로 바로가기 버튼을 만들 수도 있습니다.

이 Query의 경우 Databricks에서 제공하는 API를 사용하여 python으로 지속적으로 데이터를 가져오도록 만들고 Airflow를 통해서 지속적으로 수행하도록 하였습니다. API의 경우 다음의 API를 사용하였습니다.

https://{domain}/api/2.0/sql/statements

Statement Execution API: Run SQL on warehouses | Databricks Documentation

Learn how to use the SQL Statement Execution API in Databricks SQL with this hands-on tutorial.

docs.databricks.com

해당 API를 통해서 지속적으로 Notebook에서 수행한 작업에 대해서 수집하여 이 역시 RDB에 저장하였습니다.

3. 메시지 알람 만들기

현재 저희의 경우 메신저를 Teams를 사용하고 있기에 Teams를 통해서 메시지를 받도록 만들었습니다. 제가 아까 RDB에 계속해서 저장한다고 하였는데요. RDB에서 Query를 통해서 우리가 정한 기준에 따라서 데이터를 가져와서 이를 Teams 메시지로 보냈습니다.

Teams Webhook을 통해서 다음과 같이 채널에 메시지를 보낼 수 있습니다.

Teams 알람 예시

Email로 당사자에게 발송도 가능합니다. 하지만 실제로 비효율적으로 사용하였는지 아니면 데이터가 너무 많아서 그런 것인지 알 수 없기에 팀에서 한번 보고 판단하도록 일부러 Teams 메시지로 우선 받도록 개발하였습니다.

4. 대시보드 만들기

아까 제가 모든 작업 내역을 RDB에 저장한다고 하였습니다. 이 데이터를 저장하여 집계를 통해서 다음과 같이 실제 대시보드를 만들어서 작업의 여러 가지 사용량과 횟수등 많은 것을 한눈에 볼 수 있습니다.

이렇게 하면 누가 얼마나 어떻게 사용하였는지 볼 수 있고, 관련 부서와 협의 및 컴퓨팅을 따로 만들어주거나 여러 가지로 볼 수 있는 것이 많습니다. 그렇기 때문에 RDB에 저장해서 보는것은 굉장히 편리하고 이점이 많습니다. 저 같은 경우 대시보드는 superset을 이용하여 만들었는데, 오픈소스이기에 큰 부담 없이 만들 수 있습니다.

이밖에 Query 내역을 볼수 있는 History 대시보드를 만들어서 누가 언제 어떻게 작업을 하였는지 등도 볼 수 있습니다. 그렇기 때문에 RDB에 모든 데이터를 저장하는 것은 생각보다 굉장히 이점이 많습니다.

마치며

Databricks를 운영한 지 2025년 07월 기준으로 어느덧 1년이 되었습니다. 구축과 운영을 동시에 하다 보니 많은 삽질(?)을 하였고, 비효율적으로 작업도 많이 하였습니다. Spark를 알지 못하여 Databricks를 접하기에 엄청나게 많은 어려움이 있었고 Databricks 또한 처음이기에 우여곡절이 많았습니다.

하지만 1년 정도 운영을 해봤더니 많은 이점이 있었고 위와 같은 비효율 작업을 추적하는 모니터링 이외에 다른 여러 가지 모니터링을 만들기도 하였습니다. 앞으로도 더 많은 필요한 모니터링을 더 많이 공유하겠습니다.

감사합니다.

[Databricks] Databricks 운영 정리 - 1편

주형권 — Wed, 21 May 2025 14:50:55 +0900

안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제일 많이 집중하고 있습니다. 제가 어느덧 Databricks를 접한 지 10개월이 넘어가는 시점에서 회사에 와서 처음 시작해 보는 Databricks 플랫폼 환경에서 무엇을 하였는지에 대해서 회고 겸 정리 겸 글을 작성하였습니다.

이 글은 타 회사와 환경과 비용적 측면에서 다를 수 있으므로 참고 차원에서 보시길 권해 드립니다. 제가 작성한 글이 무조건 정답은 아니며, 회사의 상황에 맞게 적용이 필요합니다. 그렇기에 꼭 본인의 회사에 적용을 하실때 환경과 상황에 맞게 각자의 판단에 맞게 적용을 부탁드립니다. 저의 글이 틀릴 수 있음을 감안해 주시기 바랍니다.

들어가며

앞서 말씀 드렷듯이 이 내용은 제가 적용하고 괜찮다(?) 싶은 생각이 드는 내용을 대략적으로만 정리하였습니다. 자세한 내용은 회사의 중요한 내용이 포함되어 있기도 하고 아직 정리가 끝나지 않아서 자세한 내용은 정리하지 못한 점 양해를 부탁드립니다. 그리고 비용이 생각보다 이것저것 많이 나와서 무엇이 맞다고 말씀을 못 드리겠습니다.

저도 Databricks 초보이고 하나씩 배워가면서 하기 때문에 틀린 내용이 있다면 언제든지 말씀 부탁 드립니다. 또한 이 내용을 꼭 인터넷에 검색하여 충분히 검증하고 적용을 부탁 드립니다. (글 내용을 회사에 적용 후 문제에 대하여 책임지지 않습니다.)

우선 1편이라고 시작은 하였지만 2편이 나오지 않을 수 있습니다. 생각나는 것을 적다보니 순서도 중요도가 아니고 그냥 번호만 붙여두었기에 순서는 중요하지 않습니다. 그러니 해당 내용에서 필요한 부분만 정리하여 보시길 권해 드립니다.

1. 비용 모니터링

비용

엔지니어는 언제나 비용에 관련해서 고민을 안할수 없습니다. 제가 여타 다른 글에서도 항상 강조하지만 돈은 엔지니어에게 떼려야 뗄 수 없는 존재입니다. 항상 모두 가능하다고 하지만 돈 앞에선 장사가 없습니다. 그렇기에 처음에 저는 비용을 모니터링하는 부분에 대해서 만들었습니다.

Databricks에서는 비용에 관해서 보여주는 테이블이 존재 합니다. ( system.billing.usage )

Billable usage system table reference | Databricks Documentation

Learn how the billable usage system table works so you can query and monitor usage in your Databricks account.

docs.databricks.com

위의 테이블에 비용에 관련해서 저장하는 테이블이 존재하며, 여러가지 정보를 담고 있습니다. 해당 테이블에서는 굉장히 자세하게 어떠한 작업이나 사용자가 얼마의 비용을 사용하였는지 보여줍니다. 하지만 이 테이블은 DBU(DataBricks Unit)라는 단위로 row가 저장되어 있어서 실제로 이를 계산하기 위해서는 디멘젼 테이블이 필요합니다.

Databricks에서 사용하는 비용 관련 디멘젼 테이블은 다음과 같이 존재합니다. ( system.billing.list_prices )

Pricing system table reference | Databricks Documentation

Learn how the billable usage system table works so you can query and monitor usage in your Databricks account.

docs.databricks.com

2. 테이블 옵션

Databricks의 옵션이라고 하기 보다는 저희가 지금 사용하는 Delta의 테이블 옵션이라고 하는 게 더 맞을지도 모르겠지만 Databricks 테이블에 적용할 수 있는 옵션은 엄청나게 다양합니다. 아래의 링크를 보면 옵션이 굉장히 다양한 것을 볼 수 있습니다.

Delta 테이블 속성 참조 - Azure Databricks

Azure Databricks의 Delta Lake 테이블 속성에 대한 참조 목록입니다.

learn.microsoft.com

이 옵션 역시 상황에 맞게 적절하게 옵션을 걸어주는게 맞을 거 같습니다. 몇 가지 중요하게 걸었던 옵션을 보면 제가 최근에 작성하였던 targetFileSize 옵션이 있습니다.

[Databricks] targetFileSize 테이블 옵션

안녕하세요. 테이블 옵션에 관해서 처음 글을 쓰는 거 같네요. Databricks에는 여러 가지 자동으로 최적화해주는 옵션이 있지만 해당 옵션을 추가하여 Small 파일을 방지하고 성능을 향상할 수 있을

burning-dba.tistory.com

추가적으로 제가 주요하게 확인하고 걸어본 옵션을 몇가지 공유하면 다음과 같습니다. (옵션 설명은 위의 링크 참고)

delta.autoOptimize.optimizeWrite
delta.autoOptimize.autoCompact
delta.targetFileSize
delta.dataSkippingStatsColumns
delta.enableDeletionVectors

옵션이라는게 테이블마다 특성이 다르기 때문에 모두 다르게 적용해야 하는 경우도 있으니 꼭 테이블의 특성에 맞게 옵션을 적용해야 합니다. 예를 들면 DELETE가 많거나 INSERT가 많거나 SELECT만 주로 일어나거나 여러 가지 상황이 있기 때문에 옵션은 테이블의 사용성에 맞게 다를 것으로 보입니다.

3. OPTIMIZE / VACCUM

어쩌면 정리작업?

이 2개는 진짜 아무리 강조해도 부족할거 같습니다. Delta 테이블의 경우 ACID가 보장되므로 INSERT / UPDATE / DELETE의 작업을 하면서 계속해서 새로운 파일을 만들어 냅니다. 그리고 기존의 파일에 내용을 삭제하면 (DELETE) deletion vectors가 있어서 OPTIMIZE를 통해서 주기적으로 정리가 필요합니다.

What are deletion vectors? | Databricks Documentation

Learn how Databricks leverages deletion vectors to accelerate deletes and updates to data stored in Delta tables.

docs.databricks.com

OPTIMIZE와 VACCUM을 하지 않으면 변경 후의 오래된 파일이 계속해서 남아 있어서 저장소의 낭비를 불러옵니다. 그렇기 때문에 주기적으로 작업을 수행해야지 저장소 공간의 낭비와 성능을 향상할 수 있습니다. 관련하여 제가 예전에 작성 한 글을 참고하면 도움이 될 것 같습니다.

[Databricks] Optimize / VACUUM

burning-dba.tistory.com

추가적으로 OPTIMIZE를 하면서 Z-ORDER를 하는 경우도 있는데, 이 부분에 대해서는 현재 수행하고 있지 않습니다. 저희가 사용하는 데이터 패턴상 큰 이점이 없어서 (실제로 성능 향상 효과 크지 않음) Z-ORDER를 작업하는 공수가 더 큰 것으로 판단되어서 해당 작업을 하지 않고 있습니다.

4. Partition / liquid clustering

이 부분도 3번만큼 중요한 작업으로 알고 있습니다. Partition과 luquid clustering 을 통해서 실제 물리적인 읽는 비용을 감소시키고 성능을 올려서 그만큼 작업의 효율을 증대시키고 작업 시간을 효율화시키고 비용을 감소시키는 효과를 볼 수 있습니다.

Partitions | Databricks Documentation

Learn about table partitions in Databricks SQL and Databricks Runtime.

docs.databricks.com

Use liquid clustering for Delta tables | Databricks Documentation

Learn how Delta Lake liquid clustering works to simplify data layout decisions and accelerate data access.

docs.databricks.com

2가지를 섞어서 사용은 불가능 하지만 (둘중 하나만 선택 가능) 각자의 상황에 맞게 적용하여 사용이 필요합니다. (제가 알고 있기에 2개는 함께 적용이 불가능합니다.) 지금 제가 주로 사용하는 테이블의 경우 Partition을 적용하여 사용하고 있으며 둘 중에 무엇이 낫다고 말하기보다는 데이터를 쌓는 방식과 주로 사용되는 사용성을 확인해서 걸어야 할 것 같습니다. 또한 데이터의 성격 (카디날리티와 같은...)에 따라서 역시 무엇을 주력으로 사용할지 결정이 필요할 것 같습니다.

관련해서는 곧 성능을 비교하는 내용을 작성 해보고자 합니다.

마치며

어느덧 10개월정도 Databricks를 사용하다 보니 무엇을 해야 하는지 감을 잡아가는 것 같습니다. 아직 많이 부족하지만 어느 정도 구색(?)을 갖춘 데이터 환경을 구축하였고 많은 사용자가 해당 환경을 사용함에 있어서 뿌듯함을 느낍니다. 계속해서 사용자를 늘리면서 겪는 문제와 데이터의 크기와 다양성이 증가하면서 겪는 문제에 대해서 글을 추가적으로 작성하도록 하겠습니다.

감사합니다.

[Databricks] targetFileSize 테이블 옵션

주형권 — Wed, 30 Apr 2025 11:10:08 +0900

안녕하세요.

테이블 옵션에 관해서 처음 글을 쓰는 거 같네요. Databricks에는 여러 가지 자동으로 최적화해주는 옵션이 있지만 해당 옵션을 추가하여 Small 파일을 방지하고 성능을 향상할 수 있을 것 같습니다. 실제로 파일의 개수가 1/2 가량 줄어드는 것을 보았고, KB의 파일들이 모여서 MB로 변경되는 것을 눈으로 직접 확인하였습니다.

제가 알고 있기로 Databricks에는(아니면 delta 옵션 일수도?) 다음과 같이 파일에 관련하여 옵션을 제공 합니다. 제가 아는 건 2개 정도였는데요. 이미 테이블에 옵션을 적용해 놨습니다.

delta.autoOptimize.autoCompact
delta.autoOptimize.optimizeWrite

데이터 파일 크기를 제어하도록 Delta Lake 구성 - Azure Databricks

대상 파일 크기를 수동으로 제어하거나 Delta Lake로 파일 크기 자동 튜닝을 구성합니다.

learn.microsoft.com

실제로 위의 2개의 옵션으로 인해서 최적의 파일 크기를 조정해서 저장소에 저장 하는것으로 보입니다. 해당 옵션을 보고 크기가 매우 크고 중요한 테이블이 옵션을 적용하였는데, 생각보다 KB의 파일이 있어서 어쩔 수 없이 (파일을 나누다 보니 남는 데이터들?) 파일을 저렇게 저장하는구나 싶었습니다.

그래서 찾던 와중에 delta.targetFileSize 이라는 옵션을 찾았고, 해당 옵션을 적용하였는데 실제로 큰 효과를 봤습니다. 이 내용을 들어가기 앞서 왜 Small 파일이 성능에 안 좋은 영향을 미치는지 간단하게 그림으로 그려봤습니다.

Small 파일이 좋지 않은 이유?

예를 들어서 우리가 아이스크림을 퍼서 먹는다고 가정 하겠습니다. 아이스크림은 아주 작은 용기에 담겨 있습니다. 이 용기에서 아이스크림을 퍼야 합니다. 그런데 우리에게는 국자 크기의 수저밖에 없습니다.

파일이 작을때

위의 그림을 보면 작은 단위로 나눠져 있기 때문에 옮길 수 있는 크기는 크지만 8번을 옮겨야 합니다. 파일의 크기(아이스크림)가 작기 때문에 한 번에 읽을 수 있는 크기를 여러 번 옮겨야 합니다.

파일이 클때

하지만 파일의 크기(아이스크림의 크기)가 크면 한번에 옮기는 양도 많아지므로 국자 크기에 딱 맞게 옮길 수 있습니다. 그렇기 때문에 작업의 횟수가 줄어듭니다. 이게 파일을 읽는 횟수를 크게 줄여서 그만큼 더 이점이라고 볼 수 있습니다. 여러 가지 더 좋은 부분이 있겠지만 제가 알기로 가장 큰 이점이 이것으로 알고 있습니다.

실제 적용 후 비교

적용 테이블의 크기는 약 4.5TB였으며, 파일의 앞서 말씀드린 옵션이 2가지가 모두 적용 되었습니다. 해당 테이블의 경우 월별로 파티션이 걸려 있습니다. 이외의 몇 가지 옵션이 더 걸려 있지만 다른 옵션은 파일의 크기에 큰 상관이 없는 것으로 알고 있으므로 공유하지 않겠습니다.

일단 가장 중요한 파일의 개수는 다음의 구문으로 확인 하였습니다.

describe detail 테이블명

다음과 같이 검색하면 numFiles라는 칼럼이 나오는데, 해당 칼럼으로 파일의 개수를 확인 가능 합니다. 해당 옵션을 적용하는 구문은 다음과 같습니다.

ALTER TABLE 테이블명
SET TBLPROPERTIES (delta.targetFileSize = '1048576000')

위의 수치는 byte이며, 1GB가 parquet 파일의 최적의 파일 크기로 공식 문서에 언급되어 있어서 1GB로 설정하고자 하였습니다.

targerFileSize 설명

옵션을 적용하고 꼭 OPTIMIZE를 해줘야 합니다. OPTIMIZE를 해주면 파일을 다시 최적으로 쓰기 시작합니다. OPTIMIZE는 시간이 조금 걸리니 꼭 다른 작업을 피해서 수행해주셔야 합니다.

테이블의 파일은 실행 전에 약 13,000개에서 약 7,000개로 거의 1/2 수준으로 줄어들었습니다. 실제로 파일의 크기가 KB 단위가 없어졌습니다. 적용한 시간이 그리 오래되지 않아서, 성능에 대한 체감과 정확한 비교를 하지는 못하였으나 이후에 성능에 대해서 굉장히 기대됩니다.

주의 사항

1. LOCK이 걸립니다.

해당 옵션은 LOCK에 걸립니다. DELETE 나 UPDATE와 OPTIMIZE와 같은 작업을 하는 도중에 해당 옵션을 설정하면 LOCK으로 작업이 실패할 수 있습니다. 아래의 문구와 같이 나오면서 해당 작업이 실패 할 수 있으니 다른 작업이 있을 때는 해당 옵션을 걸지 않는 게 좋습니다. 작업이 끝난 후에 걸도록 해야 합니다.

[DELTA_METADATA_CHANGED] MetadataChangedException: The metadata of the Delta table has been changed by a concurrent update. Please try the operation again.

2. 설정한 파일 크기만큼 필수적으로 파일을 만들지 않습니다.

파일의 크기를 1GB로 설정하였으나 다른 옵션들로 인해서 최적의 파일 크기로 Databricks가 설정하는 것으로 보입니다. 그래서 파일의 크기를 실제로 저장소에서 확인하면 1GB가 아닌 경우가 있습니다.

구글링 해보니 비슷한 질무을 한 사람들이 좀 있는데 당황하지 마시고, 최적화 상에서 이렇게 판단하여한 것으로 보입니다. (댓글 상으로는...) 그러니 내가 설정한 크기로 안된다고 너무 당황하지 않으시길 바랍니다.

감사합니다.

[Databricks] S3에 있는 파일을 테이블 처럼 읽기

주형권 — Fri, 25 Apr 2025 08:15:50 +0900

안녕하세요.

Databricks로 데이터 파이프라인을 만들고 있는데, 좋은 기능이 있어서 글을 씁니다. Databricks에서 주로 파일을 읽을 때 워크스페이스(노트북) 환경에서 데이터프레임을 만들어서 이것을 APPEND 또는 OVERWRITE 하는 방식으로 작업하시는 분들이 많은데요. 이럴 경우 데이터프레임이 용량의 제한이 있어서 OOM이 생길 수 있습니다.

그래서 혹시 바로 읽을 수 있는 방법이 없을까 하였는데, 찾아보면 대부분이 External tables를 추천 합니다. 그런데 External Table을 만들려면 스키마 형태를 알아야 하기 때문에 굉장히 곤욕입니다. 스키마가 너무 많거나 하나씩 열거하기 어려우면 이 방법 또한 굉장히 번거롭습니다.

그래서 찾아보다가 S3에 있는 파일을 그대로 읽어서 보여주는 문법을 찾았습니다. 문법은 SQL이며, Databricks 환경에서 잘 작동합니다.

SELECT * 
FROM parquet.`S3파일 위치`

구문이 굉장히 심플 합니다. 제가 지금 가지고 있는 파일은 parquet라서 parquet로 설정하였고, 찾아보니 CSV도 가능한 것으로 보입니다. 이 구문으로 읽어서 다음과 같이 테이블을 생성할 수도 있습니다.

CREATE TABLE a
SELECT * 
FROM parquet.`S3파일 위치`

추가적으로 여러 파일을 한번에 읽기도 가능하여, * 도 가능 합니다. 예를 들면 2025/04/25/ 아래의 모든 파일을 읽고자 한다면 다음과 같이 할 수 있습니다.

SELECT * 
FROM parquet.`S3명/2025/04/25/*`

정상적으로 잘 작동하며, 읽는데 그리 오래 걸리지도 않습니다. 아래의 스펙으로 테스트를 하였을 때 다음과 같은 결과가 나왔습니다.

Driver / Worker 스팩 같음
- Worker 최대 10개
파일 크기 : 24GB
파일 개수 : 2,311개

위의 테스트 데이터를 읽어서 새로운 테이블을 만드는 시간을 총 22분 46초가 걸렸습니다. 아마도 파일 개수가 더 적고 파일의 크기가 컸다면 더욱 빠른 성능을 기대할 수 있었을 것입니다. 대규모 파이프라인에서는 이 방법이 좋지 않을 수 있겠으나, 소규모의 파이프라인의 경우 이 방법이 굉장히 유용할 것으로 보입니다.

감사합니다.

데이터엔지니어 주형권

[DRE] 실패 알림을 넘어 영향 범위 예측으로 — 데이터 파이프라인 Observability 구현 (with. Databricks)

이 글의 핵심 요약 (Key Takeaways)

1. 무엇이 변경되었는가?

2. 설계와 구현

3. 알림과 후속 처리

마치며

[DRE] 로그 정합성 모니터링 고도화

이 글의 핵심 요약 (Key Takeaways)

1. 기존 로그 모니터링의 한계와 다차원 집계의 필요

2. 기존보다 더욱 세분화 된 모니터링

2.1. 모니터링의 세분화

2.2. 로그의 추세 모니터링

3. Airflow & Databricks 기반 로그 정합성 모니터링 아키텍처

4. 대용량 로그 집계 시 트러블슈팅: 비용 최적화와 알림 피로도 해결

4.1. 집계 비용

4.2. 너무 세분화된 데이터의 잘못된 알림

4.3. 더욱 세분화 및 맞춤의 한계

5. 앞으로 개선하고자 하는 것은?

5.1. Databricks Lakebase 교체

5.2. Meta Table 개발

5.3. Role & AI를 이용한 이상 탐지

5.4. 알림 개별화

6. 추가적으로 개발해야 하는 것들

마치며

[Databricks] 멀티 리전 Delta Table 최적화: OPTIMIZE & VACUUM 자동화 파이프라인 구축기

이 글의 핵심 요약 (Key Takeaways)

1. 비용과 안정성을 고려한 아키텍처 설계

2. Optimize / VACCUM 대상 테이블 선정

3. 설계 과정에서 겪은 이슈들 ‍♂️

4. 실제 수행해 보기 : Job 설정 및 dry_run 결과

5. 자동 리포팅 및 장애 알림 체계 구축

마무리 : 최적화 자동화가 가져다준 효과 ✨

함께 보면 좋은 글

[DRE] Databricks 감사 로그 기반 데이터 거버넌스 자동화 시스템 구현

이 글의 핵심 요약

왜 이 시스템을 직접 만들었을까?

️ 1. 아키텍처에 녹여낸 4가지 핵심 보안 철학

⚙️ 2. 듀얼 파이프라인 아키텍처: 어떻게 탐지하는가?

️ 파이프라인 1: AI 기반 PII(개인정보) 접근 모니터링

파이프라인 2: KIC 중앙 집중형 비인가 IP 접속 모니터링

️ 3. 기술 스택: 있는 것을 최대한 활용하라

⏱️ 4. Incident 대응 프로세스 타임라인: 골든타임을 사수하는 자동화 플레이북

5. ROI 분석: 이것이 엔지니어링의 묘미다

마무리하며: 시스템을 넘어 '문화'를 만들다

[DRE] 데이터 파이프라인 장애 감지 자동화 — Airflow + Teams 연동

이 글의 핵심 요약

왜 이 시스템을 만들었나?

4가지 핵심 구축 조건

⚙️ 개발 및 정책 핵심

1. 알림 발송 개발 방식 (백엔드)

2. 운영 정책 및 자동화 (Tagging)

✨ Gemini와의 티키타카, 그리고 깨달음

마치며

[DRE] 데이터 엔지니어 다음 커리어, Data Reliability Engineer(DRE) 로드맵

이 글의 핵심 요약

들어가며

Data Reliability Engineering은 무엇인가?

정의

내 생각

Data Reliability Engineer은 무엇을 하는가?

정의

내 생각

내가 생각하는 Data Reliability Engineer

1) Data Monitoring

2) Data Quality

3) Data Governance

마치며

[Databricks] API를 이용한 Token정보 가져오기 (Python)

Token 확인 방법

Token 정보 가져오기

[공통] 데이터엔지니어링팀의 계획 - 중기편 (3~N년)

들어가며

1. 데이터 플랫폼 홍보/교육

2. 다양한 데이터 적재

3. 사용자 편의성 증대

4. 데이터 정책 고도화

[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

들어가며

1. 로그 설계/개발