Skip to main content
이 문서는 데이터 엔지니어링 섹션의 일부입니다.

왜 파일 감지 모드를 이해해야 하는가?

Auto Loader가 클라우드 스토리지에서 새 파일을 발견하는 방식에는 Directory ListingFile Notification 두 가지가 있습니다. 이 선택에 따라 지연 시간, 비용, 확장성 이 크게 달라지므로, 프로덕션 환경에서는 워크로드 특성에 맞는 모드를 선택하는 것이 매우 중요합니다.
💡 비유: Directory Listing은 “5분마다 우편함을 직접 열어보는 것”이고, File Notification은 “우편이 도착하면 알림이 오는 스마트 우편함”입니다.

Directory Listing 모드 (기본값)

동작 원리

Directory Listing 모드는 Auto Loader가 지정된 경로의 파일 목록을 주기적으로 스캔 하여 새 파일을 감지합니다. 이전 스캔 결과와 비교하여 새로 추가된 파일만 처리합니다.

장점과 단점

Incremental Listing (증분 리스팅)

대규모 디렉토리에서 Directory Listing의 성능을 크게 개선하는 기능입니다. 매번 전체 디렉토리를 스캔하는 대신, 이전 스캔 이후 변경된 부분만 확인합니다.
⚠️ Incremental Listing의 전제 조건: 파일이 시간순으로 정렬된 디렉토리 구조(예: /year=2025/month=03/day=15/)에 저장되어야 효과적입니다. 파일 이름이나 경로에 시간 정보가 없으면 효과가 제한적입니다.

File Notification 모드

동작 원리

File Notification 모드는 클라우드 스토리지의 이벤트 알림 서비스 를 통해 새 파일 도착을 감지합니다. 파일이 업로드되면 이벤트가 발생하고, Auto Loader가 이를 수신하여 즉시 처리합니다.
1

새 파일이 클라우드 스토리지에 업로드

데이터가 S3 / ADLS / GCS 의 모니터링 경로에 도착합니다.
2

이벤트 알림 발행

클라우드 이벤트 서비스 (S3 Event Notifications / Azure Event Grid / GCP Pub/Sub) 가 파일 도착 이벤트를 발행합니다.
3

큐에 이벤트 적재

큐 서비스 (AWS SQS / Azure Queue Storage / Pub/Sub Subscription) 가 이벤트를 보관합니다.
4

Auto Loader가 큐 폴링

스트리밍 마이크로배치마다 큐를 폴링하여 새 파일 메타데이터를 수신합니다. 전체 디렉토리 스캔이 불필요합니다.
5

파일 읽어 DataFrame 으로 변환

수신한 파일 경로만 읽어 스트리밍 DataFrame 으로 처리합니다. 처리 완료 후 메시지를 큐에서 ACK 합니다.
참고: Databricks: File notification mode

클라우드별 이벤트 알림 서비스

AWS에서의 설정 예제

자동 프로비저닝 시 Auto Loader가 생성하는 AWS 리소스는 다음과 같습니다.

기존 SQS 큐 사용 (수동 설정)

이미 구성된 이벤트 인프라가 있다면 직접 지정할 수 있습니다.

필요한 IAM 권한

자동 프로비저닝을 사용하려면 다음 IAM 권한이 필요합니다.

모드 비교 총정리


선택 기준 가이드


리소스 정리 (File Notification 모드)

File Notification 모드에서 자동 프로비저닝된 리소스는 스트림 종료 시 자동으로 정리되지 않습니다. 더 이상 사용하지 않는 경우 수동으로 정리해야 합니다.
⚠️ 정리하지 않으면 불필요한 클라우드 비용이 계속 발생할 수 있습니다. 특히 SQS 큐에 메시지가 쌓이면서 비용이 누적됩니다.

현업 사례: 10만 개 파일이 쌓인 디렉토리에서 Directory Listing이 30분 걸린 경험

🔥 이것은 실제로 매우 흔한 문제입니다.
많은 팀이 Auto Loader를 처음 도입할 때 기본값인 Directory Listing으로 시작합니다. 처음에는 잘 되다가, 6개월~1년이 지나면 갑자기 파이프라인이 느려지기 시작합니다. 그 원인은 디렉토리에 파일이 누적되었기 때문 입니다.

실제 성능 저하 타임라인

왜 이런 일이 벌어지나요?

S3/ADLS의 LIST API는 한 번에 최대 1,000개의 오브젝트 만 반환합니다. 파일이 50만 개이면 최소 500번의 API 호출 이 필요합니다. 각 호출에 100200ms가 걸리면, LIST만으로 50100초가 소요됩니다. 여기에 Auto Loader가 이전 체크포인트와 비교하는 시간까지 더해지면 분 단위로 늘어납니다.
💡 현업 팁: 파일이 하루에 1,000개 이상 쌓이는 경로라면, 처음부터 File Notification 으로 시작하세요. Directory Listing에서 나중에 전환하는 것은 체크포인트 호환 문제로 생각보다 까다롭습니다.

File Notification 설정 시 IAM 권한 함정

현업에서 File Notification으로 전환하려다 IAM 권한 때문에 며칠을 허비하는 경우가 매우 흔합니다. 특히 보안이 엄격한 기업에서 자주 발생합니다.

함정 1: “Resource”: ”*” 를 보안팀이 절대 허용 안 함

위에서 소개한 자동 프로비저닝 IAM 정책에는 "Resource": "*"가 포함되어 있습니다. 대부분의 기업 보안 정책은 이를 허용하지 않습니다.
💡 현업 팁: 보안팀과 협의할 때 “Auto Loader 자동 프로비저닝이 만드는 리소스 이름은 databricks-auto-loader-로 시작합니다”라고 미리 알려주면, 리소스 범위를 좁혀서 허용받을 수 있습니다.

함정 2: S3 버킷당 이벤트 알림 제한

⚠️ 많은 팀이 이 실수를 합니다. 하나의 S3 버킷에는 기본적으로 하나의 이벤트 알림 구성(Event Notification Configuration) 만 설정할 수 있습니다. 이미 다른 서비스(Lambda, 다른 Auto Loader 스트림 등)가 이벤트 알림을 사용 중이면 충돌이 발생합니다.

함정 3: SQS 메시지 보존 기간과 파이프라인 중단

SQS 큐의 기본 메시지 보존 기간은 4일 입니다. 파이프라인이 4일 이상 중단되면, 그 사이에 도착한 파일의 이벤트가 SQS에서 사라져 파일을 놓칠 수 있습니다.
💡 현업 팁: File Notification 모드를 사용할 때는 반드시 SQS 보존 기간을 14일(최대) 로 늘리고, Dead Letter Queue(DLQ) 를 설정하세요. 그리고 파이프라인 실패 시 즉시 알림이 오도록 모니터링을 구성해야 합니다.

실전 선택 기준: 의사결정 플로우

실무에서 모드를 선택할 때는 다음 순서로 판단하시면 됩니다.

Directory Listing에서 File Notification으로 전환 시 주의사항

💡 현업에서 가장 중요한 포인트: 모드 선택보다 중요한 것은 모니터링 입니다. 어떤 모드를 쓰든 “새 파일이 들어왔는데 처리가 안 된다”를 감지하는 알림이 있어야 합니다. 처리 지연(lag) 메트릭을 Lakeview 대시보드에 구성하세요.

정리


참고 링크