ML 팀을 위한 외부 API 데이터 수집 파이프라인 설계 가이드

커뮤니티 반응

작성자의 체계적인 접근 방식과 실무적인 고려 사항에 대해 긍정적인 반응이며, 특히 원본 데이터 보존의 중요성에 공감하는 분위기이다.

주요 논점

01찬성다수

설계 전 요구사항 구체화와 원본 데이터 보존 계층의 필요성을 강조한다.

합의점 vs 논쟁점

합의점

데이터 수집 시 원본(Raw) 데이터를 별도로 저장하는 것이 재처리를 위해 필수적이다.
재시도 로직과 멱등성은 프로덕션 파이프라인의 기본 요건이다.

실용적 조언

API 호출 실패에 대비해 1분, 5분, 15분 간격의 지수 백오프 재시도 설정을 적용하라.
데이터 변환 로직 수정 시 API를 다시 찌르지 말고 저장된 Raw JSON에서 백필을 수행하라.
데이터 로드 후에는 반드시 행 수와 중복 여부를 체크하는 검증 단계를 두어라.

섹션별 상세

설계 시작 전 데이터의 형식, 규모, 빈도, 사용자 수에 대한 명확한 질문이 선행되어야 한다. 데이터 규모가 5GB인지 1TB인지에 따라 Python과 PostgreSQL 조합에서 Spark나 Delta Lake 기반의 데이터 레이크로 설계 방향이 완전히 달라지기 때문이다. 실시간성 여부에 따라 Kafka와 Flink를 사용할지, Airflow DAG를 통한 배치 처리를 할지도 결정된다.

수집된 원본 데이터(Raw JSON)를 변형 없이 MinIO와 같은 저장소에 먼저 보관하는 계층화 전략이 필수적이다. API 소스에서 데이터를 추출한 후 즉시 변환하지 않고 원본을 유지하면, 변환 로직에 버그가 발생했을 때 API를 다시 호출하지 않고도 로컬에서 재처리가 가능하다. 이는 API 호출 비용을 절감하고 데이터 복구 속도를 비약적으로 높이는 결과를 낳았다.

프로덕션 환경에서는 지수 백오프를 적용한 재시도 메커니즘과 멱등성 보장이 시스템의 신뢰성을 결정한다. 동일한 날짜의 데이터를 재실행했을 때 중복이 발생하지 않도록 Upsert나 파티션 덮어쓰기 방식을 사용해야 한다. 또한 매 로드 작업 후에는 Null 값 개수나 행 수 확인과 같은 데이터 품질 체크 단계를 포함하여 데이터 무결성을 검증한다.

Kubernetes 기반의 Airflow 환경에서 태스크당 하나의 포드를 할당하는 KubernetesExecutor를 사용하여 병렬 추출을 구현했다. 실제 Binance API 데이터를 활용해 이 구조를 구현했으며, 이를 통해 확장성과 격리된 실행 환경을 확보했다. 단순한 기능 구현을 넘어 실패 경로에 대한 대응책과 백필 지원 능력이 실무 설계의 핵심 차별점이다.

용어 해설

멱등성(Idempotency): — 동일한 작업을 여러 번 수행하더라도 결과가 항상 동일하게 유지되는 성질이다. 데이터 파이프라인에서 재실행 시 중복 데이터가 생성되지 않도록 보장하여 시스템의 안정성과 복구 가능성을 높이는 핵심 원칙이다.
지수 백오프(Exponential Backoff): — 네트워크 요청 실패 시 재시도 간격을 지수적으로 늘려가며 시도하는 알고리즘이다. API 서버의 부하를 방지하고 일시적인 장애 상황에서 시스템이 스스로 회복할 수 있는 시간을 확보하는 데 사용된다.
백필(Backfill): — 과거 시점의 데이터를 소급하여 처리하거나 누락된 데이터를 보충하는 작업이다. 파이프라인 로직 수정이나 장애 복구 시 원본 데이터를 기반으로 과거 데이터를 다시 계산하여 데이터 일관성을 유지하는 데 필수적이다.
데이터 수집(Data Ingestion): — 외부 소스로부터 데이터를 가져와 저장소로 옮기는 초기 단계의 프로세스이다. 실시간 스트리밍 또는 배치 방식으로 수행되며, 이후의 데이터 분석 및 모델 학습을 위한 기초 데이터를 확보하는 역할을 한다.

언급된 도구

Airflow추천

워크플로 오케스트레이션 및 배치 작업 스케줄링

MinIO추천

원본 JSON 데이터 저장을 위한 오브젝트 스토리지

PostgreSQL추천

정제된 데이터 저장을 위한 관계형 데이터베이스

언급된 리소스

GitHubMLOps Boilerplate GitHub