RAW 보존·재파싱 구조로 바꾼 ETL 수집 플로우
외부 데이터를 먼저 보존해 파서 수정 후에도 API를 다시 호출하지 않고 재처리하도록 바꿨습니다.
작업 요약
적용 소스 재처리 시 외부 API 호출 0건
RAW 재파싱을 택한 이유
이 파이프라인은 재수집이 필요해질 때마다 1,000만~1억 건의 외부 API 요청과 실패 위험이 그대로 다시 왔습니다. 파싱 오류를 고칠 때도 같은 요청을 반복해야 해 수집과 파싱을 분리했습니다.
RAW를 먼저 보존하자 파싱 버그를 고친 뒤 외부 API를 다시 호출하지 않고 변환만 재실행할 수 있었습니다. 저장 공간은 더 쓰지만 재수집 비용과 rate limit 위험을 줄이는 쪽을 택했습니다.
배경
제품 데이터는 수집(Gathering) → 정제(Curation) → 배포(Distribution)로 이어지는 파이프라인으로 운영됩니다. 단계별로 처리 방식과 저장 위치가 제각각이라, 흐름을 한눈에 파악하기 어렵고 데이터 규모가 늘수록 확장에 부담이 있었습니다.
- RAW를 보존하지 않는 일괄 수집·처리(API 호출 → 즉시 파싱 → DB 저장) 구조라, 재수집·추가 수집 때마다 매번 1,000만~1억 건의 외부 API 요청이 필요했고 rate limit에 걸려 수집이 장기화
- 파싱 버그·이상 데이터 발견 시 원본(RAW)이 이미 사라져 원인 추적·재현이 불가능했고, 유일한 해결책이 전체 재수집
- 오픈소스 RAW 데이터가 늘어나면서 기존 파일시스템 기반 저장은 용량이 차고 파일 수가 늘수록 백업·조회가 무거워지는 한계
- 수집부터 배포까지의 흐름이 표준화되어 있지 않아 신규 데이터 소스 편입과 운영 인계가 어려움
접근
파이프라인 전체를 다시 정의하면서 RAW 데이터 저장을 파일시스템에서 오브젝트 스토리지(SeaweedFS)로 옮기는 이전 방식과 순서를 정했습니다. 단계별 책임과 데이터 흐름을 정의해 수집 플로우를 표준화했습니다.
- RAW 데이터를 오브젝트 스토리지에 원본 보존하고 상태 관리 DB로 수집(Collector)과 정제(Worker)를 분리해, 재처리는 외부 요청 없이 재파싱으로 해결
- Cache Hit/Miss 패턴(이미 있으면 즉시 반환)과 version_id 기반 수정 이력 추적으로 데이터 재현 가능성 확보
- 오픈소스 RAW 데이터 수집용 오브젝트 스토리지 설계
- 파일시스템 → 오브젝트 스토리지(SeaweedFS) 마이그레이션 전략·로드맵 수립
결과
역할
데이터 엔지니어로서 파이프라인 재정의 → 스토리지 설계 → 마이그레이션 전략 수립을 주도했습니다. 오브젝트 스토리지 방안은 세 가지 안을 비교 문서로 만들어 팀장·CTO 리뷰로 확정했고, 수집부터 배포까지 전체 흐름을 표준화하고 파일시스템에서 오브젝트 스토리지로 옮기는 로드맵을 세워 저장 구조를 단계적으로 옮기고 있습니다.
현재도 저장소 이전을 진행하고 있습니다.
📦 데이터 플랫폼 재구축 시리즈 ① — 이 전략의 핵심 구현은 별도 항목으로 정리했습니다: ② 오픈소스 RAW 데이터 오브젝트 스토리지 구축 →