[Data Engineering] 대규모 데이터 레이크의 숨겨진 병목, ‘스몰 파일’ 문제와 엔터프라이즈급 해결 전략: 바이낸스(Binance) 사례 분석

현대의 데이터 플랫폼은 멈추지 않는 파이프라인 위에서 돌아갑니다. 수집(Ingest), 변환(Transform), 서빙(Serve)으로 이어지는 데이터의 흐름은 모니터링, 부정 탐지(Fraud Detection), 비즈니스 인텔리전스(BI) 등 핵심 프로덕트의 혈관과도 같습니다.

하지만 데이터 웨어하우스나 레이크의 규모가 페타바이트 급으로 커지면, 시스템의 성능을 저하시키는 아주 사소하지만 치명적인 문제가 발생합니다. 바로 ‘스몰 파일(Small File)’ 문제입니다.

오늘은 글로벌 암호화폐 거래소인 바이낸스(Binance)가 이 고질적인 스몰 파일 문제를 해결하고 데이터 건강성을 회복하기 위해 가동한 ‘바이낸스 데이터 클리닉(Binance Data Clinic)’ 이니셔티브와, 그 핵심 엔진인 **’Small File Doctor’**의 아키텍처 및 운영 철학을 심층 분석합니다. 이를 통해 대규모 데이터 플랫폼이 나아가야 할 최적화 방향성을 고찰해 보고자 합니다.

1. 스몰 파일(Small File): 왜 단순한 ‘작은 파일’이 아님을 인지해야 하는가

데이터 엔지니어링에서 ‘스몰 파일’은 단순히 용량이 작은 파일 그 자체를 의미하는 것이 아닙니다. 이는 분산 처리 시스템의 구조적 한계를 건드리는 아키텍처상의 부채입니다.

하둡 분산 파일 시스템(HDFS)이나 AWS S3와 같은 객체 스토리지, 그리고 Spark와 같은 분산 처리 엔진은 기본적으로 대용량 파일을 병렬 처리하는 데 최적화되어 있습니다. 하지만 실시간 데이터 수집이나 잦은 파티셔닝으로 인해 수 KB에서 수 MB 단위의 파일이 수천, 수만 개 생성되면 다음과 같은 심각한 문제가 발생합니다.

• 메타데이터 오버헤드(Metadata Overhead) 폭증: 네임노드(NameNode)나 스토리지의 메타데이터 서버는 파일의 위치와 정보를 저장해야 합니다. 1TB의 데이터를 1개의 파일로 저장하는 것과 100만 개의 파일로 저장하는 것은 스토리지 용량은 같지만, 메타데이터 처리 비용에서 천문학적인 차이를 보입니다.
• 리드 앰플리케이션(Read Amplification): 쿼리 엔진이 데이터를 읽을 때, 실제 데이터 읽기 시간보다 파일을 열고(Open), 메타데이터를 확인(List)하고, 커넥션을 맺는 오버헤드 시간이 더 길어집니다.
• 테일 레이턴시(Tail Latency) 악화: 전체 파이프라인의 속도는 가장 느린 태스크(Straggler)에 의해 결정됩니다. 수만 개의 작은 파일을 읽어야 하는 작업은 스케줄링 부하를 일으키고, 이는 결국 SLA(서비스 수준 협약) 위반과 간헐적인 작업 실패(OOM 등)로 이어집니다.

바이낸스 역시 이러한 문제로 인해 쿼리 성능 저하와 스토리지 비용 증가를 겪었으며, 이를 해결하기 위해 단순한 스크립트가 아닌 **’바이낸스 데이터 클리닉(Binance Data Clinic)’**이라는 시스템화된 솔루션을 도입하게 됩니다.

2. 애드혹(Ad-hoc) 스크립트에서 ‘거버넌스 시스템’으로의 전환

초기 단계의 데이터 팀은 보통 cron 작업이나 일회성 스크립트를 통해 주기적으로 파일을 병합(Merge)합니다. 하지만 테이블이 수천 개로 늘어나고, 파티션이 수만 개로 쪼개지는 규모에서는 이러한 접근법은 위험합니다.

• 어떤 테이블이 실제 성능에 악영향을 주는지 식별하기 어렵습니다.
• 병합 작업 중 데이터 유실이나 중복 쓰기(Race Condition)의 위험이 있습니다.
• 작업의 이력과 성과(비용 절감 효과)를 추적할 수 없습니다.

바이낸스는 이러한 문제의식을 바탕으로 **’바이낸스 데이터 클리닉(Binance Data Clinic)’**이라는 체계적인 접근법을 수립하고, 그 실행 도구인 **’Small File Doctor’**를 개발했습니다. 이 프레임워크는 기존의 수동 작업을 **’식별-판단-실행-검증’**이라는 4단계의 자동화된 프로덕션 과정으로 격상시켰습니다.

핵심 목표는 단순히 파일을 합치는 것이 아니라, **”프로덕션 파이프라인을 방해하지 않으면서, 측정 가능한 성능 향상이 있는 곳에만 리소스를 투입하는 것”**입니다.

3. Small File Doctor의 핵심 아키텍처: 무엇을 고칠 것인가?

바이낸스 데이터 클리닉의 핵심 진단 엔진인 이 프레임워크의 가장 큰 특징은 무조건적인 최적화를 지양하고, **ROI(투자 대비 효과)**가 확실한 대상을 선별하는 인텔리전스에 있습니다.

Step 1: 메타데이터 기반의 핫스팟 탐지

먼저 스토리지 시스템의 메타데이터를 스캔하여 테이블 및 파티션별 파일 개수와 크기 분포를 분석합니다. 파일 개수는 많지만 평균 크기가 극도로 작은 디렉토리를 1차 후보군으로 선정합니다.

Step 2: 액세스 패턴 분석 (Access Pattern Analysis)

이 부분이 핵심입니다. 모든 스몰 파일이 즉각적인 문제를 일으키지는 않습니다. 예를 들어, 데이터가 생성된 후 거의 조회되지 않거나(Cold Data), 최신 파티션만 읽히는 테이블은 우선순위가 낮습니다. 프레임워크는 Spark, Hive 등의 쿼리 로그와 ETL 잡(Job)의 실행 경로를 분석합니다. 다운스트림 작업이 수십 일 치의 파티션을 한 번에 스캔(Scan)하는 패턴이 발견되면, 해당 테이블은 ‘고위험군’으로 분류되어 바이낸스 데이터 클리닉의 최적화 1순위 대상이 됩니다. 이는 엔지니어링 리소스를 실제 레이턴시 개선에 직결되는 곳에 집중하기 위함입니다.

Step 3: 최적화 백로그(Backlog) 관리

선별된 대상은 설정 테이블(Configuration Table)에 등록되어 관리됩니다. 이 테이블은 최적화 작업의 큐(Queue) 역할을 하며, 시스템이 안전하게 처리할 수 있는 속도로 작업을 분배합니다.

4. 안전한 실행(Safe Execution): 프로덕션 환경에서의 쓰기 전략

운영 중인 데이터 레이크의 파일을 건드리는 것은 외과 수술과 같습니다. 데이터 무결성이 깨지면 안 되며, 읽기/쓰기 충돌을 방지해야 합니다. 바이낸스 데이터 클리닉 전략의 일환으로 마련된 안전장치는 다음과 같습니다.

1) 파티션 테이블 처리 (Partitioned Tables)

가장 일반적인 케이스입니다. 프레임워크는 타겟 파티션의 데이터를 Spark로 읽어 들인 후 coalesce 등을 통해 목표 파일 크기(예: 256MB)에 맞춰 파일 개수를 줄입니다. 그 후 해당 파티션에 대해 INSERT OVERWRITE 구문을 사용하여 원자성(Atomicity)을 보장하며 덮어씁니다. SQL 레벨의 시맨틱을 활용함으로써, 스토리지 레벨에서 발생할 수 있는 불완전한 파일 생성을 방지합니다.

2) 비파티션 테이블 처리 (Non-Partitioned Tables) – 스테이징 전략

파티션이 없는 통짜 테이블은 훨씬 위험합니다. 읽는 동시에 덮어쓰는 행위는 데이터 손실을 유발할 수 있습니다. 이를 해결하기 위해 ‘스테이징 테이블(Staging Table)’ 패턴을 사용합니다.

1. 원본 테이블과 동일한 스키마의 임시 테이블을 생성합니다.
2. 최적화된 데이터를 스테이징 테이블에 먼저 씁니다.
3. 데이터 검증이 끝나면, 스테이징 테이블의 데이터를 원본 테이블로 덮어씌웁니다.

이러한 Two-Step 접근은 읽기 경로와 쓰기 경로를 분리하여 운영 안정성을 극대화합니다.

3) 멱등성(Idempotency)과 동시성 제어

모든 작업은 로그에 기록되며, 이미 최적화된 파티션은 중복 실행되지 않도록 멱등성을 보장합니다. 또한, 클러스터의 리소스를 독점하지 않도록 동시 실행 작업 수를 제한하고, 트래픽이 적은 오프 피크(Off-peak) 시간에만 작동하도록 스케줄링 됩니다.

5. 비즈니스 임팩트와 로드맵

바이낸스 데이터 클리닉을 통한 체계적인 접근의 결과는 수치로 증명되었습니다. 바이낸스는 이 시스템을 통해 약 5,900만 개의 스몰 파일을 290만 개로, 약 95% 감소시키는 데 성공했습니다.

• 비용 절감: 스토리지 API 호출 비용 감소 및 컴퓨팅 리소스 효율화로 연간 약 10만 달러($90,000 ~ $100,000) 이상의 비용을 절감했습니다.
• 안정성 향상: 스몰 파일로 인한 다운스트림 작업의 OOM(Out of Memory) 오류와 타임아웃 실패가 획기적으로 줄어들었습니다.
• 성능 개선: 메타데이터 조회 시간이 단축되면서 전반적인 쿼리 응답 속도가 향상되었습니다.

현재 바이낸스 데이터 클리닉 시스템은 비동기식(Asynchronous)으로 작동하지만, 향후 데이터 파이프라인의 스케줄러에 직접 통합될 계획을 가지고 있습니다. 즉, 데이터가 생성되는 즉시(Real-time) 파일 병합과 검증을 거쳐야만 다운스트림에서 사용할 수 있게 하는 ‘Built-in Quality’ 방식으로 진화하려는 것입니다.

6. 결론: 인프라의 제약이 비즈니스의 제약이 되지 않도록

스몰 파일 문제는 데이터 플랫폼이 성장하면서 겪게 되는 필연적인 성장통입니다. 초보적인 단계에서는 이를 ‘청소(Housekeeping)’의 관점에서 바라보지만, 성숙한 엔지니어링 조직은 이를 **’인프라 최적화(Infrastructure Optimization)’**의 관점에서 접근합니다.

바이낸스의 사례는 단순히 파일을 합치는 기술이 중요한 것이 아니라, 어떤 데이터를, 언제, 어떻게 안전하게 처리할 것인가에 대한 거버넌스(Governance)가 핵심임을 보여줍니다. 데이터 레이크의 성능 저하로 고민하고 있다면, 단순히 Spark 옵션을 튜닝하는 것을 넘어, 데이터의 라이프사이클 전체를 관리하는 **’바이낸스 데이터 클리닉’**과 같은 종합적인 프레임워크 도입을 고려해야 할 시점입니다. 시스템의 규모가 커질수록, 문제는 시스템적으로 해결해야 하기 때문입니다.

작성자 주: 본 글은 대규모 데이터 처리에 대한 기술적 이해를 돕기 위해 작성되었으며, 실제 적용 시에는 각 기업의 인프라 환경(Hadoop, AWS, Azure, GCP 등)에 맞는 커스터마이징이 필요합니다.

Coinpop Official Editor

코인팝 수석 시장 분석가. 온체인 데이터와 거시경제 지표를 기반으로 비트코인 및 글로벌 암호화폐 시장의 흐름을 분석합니다. 감에 의존한 투자가 아닌, 데이터와 팩트에 기반한 객관적인 인사이트를 제공하는 것을 목표로 합니다.