기술 포트폴리오 · 슬라이드
ETL 데이터 수집
플로우 재정립
재수집 때마다 1,000만~1억 건의 외부 API 요청이 필요하던 원테이크 수집을, RAW 보존·재파싱 구조의 오브젝트 스토리지 기반 파이프라인으로 재설계
래브라도랩스(LabradorLabs) · 데이터파트 · 2026-03~ 진행 · 데이터파트 파트리더
01 · 배경
왜 재정립했나
- RAW를 보존하지 않는 원테이크 수집(API 호출 → 즉시 파싱 → DB 저장) — 재수집·추가 수집 때마다 매번 1,000만~1억 건 외부 요청, rate limit으로 수집 장기화
- 파싱 버그·이상 데이터 발견 시 원본이 없어 원인 추적·재현 불가 — 유일한 해결책이 전체 재수집
- 데이터는 수집(Gathering) → 마스터(Master) → 배포(Distribution) 파이프라인으로 운영 — 단계별 처리·저장 방식이 제각각, 오픈소스 RAW 증가로 파일시스템 저장의 확장성 한계 도달
02 · 접근
파이프라인 표준화 + 스토리지 전환
수집 (Gathering)오픈소스 RAW 데이터 수집
마스터 (Master)정제·통합 기준 데이터
배포 (Distribution)서비스로 전달
RAW 데이터를 오브젝트 스토리지에 원본 보존하고 상태 관리 DB로 수집(Collector)과 정제(Worker)를 분리 — 재처리는 외부 요청 없이 재파싱으로 해결. Cache Hit/Miss 패턴과 version_id 이력 추적으로 재현 가능성 확보. 저장은 파일시스템 → 오브젝트 스토리지(SeaweedFS) 마이그레이션 로드맵으로 전환.
03 · 임팩트
결과
외부 요청 0건재수집 때마다 반복되던 1,000만~1억 건 API 호출을 RAW 재파싱으로 제거
재처리 시간 단축rate limit에 묶인 기간 재수집을 내부 재파싱으로 대체 (설계 산정 예: 2일 → 5분)
추적·재현 가능version_id 이력 추적 + 원본 보존으로 이상 데이터 원인 규명
플로우 표준화수집→마스터→배포 책임 명확화, 신규 소스 편입·인계 용이
04 · 역할 & 배움
내 역할
- 데이터파트 파트리더로서 파이프라인 재정의 → 스토리지 설계 → 마이그레이션 전략 수립 주도
- 수집부터 배포까지 전체 흐름을 표준화하고 확장 가능한 데이터 기반 마련
- 배움: 파이프라인은 흐름의 표준화와 저장 기반의 확장성이 함께 가야 지속 가능
현재 진행 중 · 로드맵에 따라 단계적으로 마이그레이션 적용.
📦 데이터 플랫폼 재구축 시리즈 ① — ① ETL 재정립 · ② 오브젝트 스토리지