재수집 때마다 1,000만~1억 건의 외부 API 요청이 필요하던 원테이크 수집을, RAW 보존·재파싱 구조의 오브젝트 스토리지 기반 파이프라인으로 재설계
기간2026 (3월~ 진행)
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어링 리드 · 파이프라인 재정립 주도
ETLELTData PipelineObject StorageSeaweedFSDB / Infra
0작업자의 메모
원테이크 수집은 처음에는 단순하지만 재수집이 필요해지는 순간 외부 API 비용과 실패 위험이 그대로 다시 옵니다. 1,000만~1억 건 요청을 반복해야 하는 구조라면 파이프라인부터 바꾸는 편이 맞았습니다.
RAW를 남기고 재파싱할 수 있게 만든 것은 저장소를 하나 더 둔다는 뜻이 아니라, 장애와 품질 개선을 나중에 더 낮은 비용으로 처리할 수 있게 만든 결정이었습니다. 업계 용어로 치면 ETL에서 ELT로의 전환입니다 — 일단 원본을 적재해 두고, 변환은 필요할 때 다시 할 수 있게 만든 구조니까요.
1배경
제품 데이터는 수집(Gathering) → 정제(Curation) → 배포(Distribution)로 이어지는 파이프라인으로 운영됩니다. 단계별로 처리 방식과 저장 위치가 제각각이라, 흐름을 한눈에 파악하기 어렵고 데이터 규모가 늘수록 확장에 부담이 있었습니다.
RAW를 보존하지 않는 원테이크 수집(API 호출 → 즉시 파싱 → DB 저장) 구조라, 재수집·추가 수집 때마다 매번 1,000만~1억 건의 외부 API 요청이 필요했고 rate limit에 걸려 수집이 장기화
파싱 버그·이상 데이터 발견 시 원본(RAW)이 이미 사라져 원인 추적·재현 불가 — 유일한 해결책이 전체 재수집
오픈소스 RAW 데이터가 늘어나면서 기존 파일시스템 기반 저장으로는 용량·확장성·관리에 한계
수집부터 배포까지의 흐름이 표준화되어 있지 않아 신규 데이터 소스 편입과 운영 인계가 어려움
2접근
파이프라인 전체를 다시 정의하면서 RAW 데이터 저장을 파일시스템에서 오브젝트 스토리지(SeaweedFS)로 옮기는 마이그레이션 전략과 로드맵을 수립했습니다. 단계별 책임과 데이터 흐름을 명확히 해 수집 플로우를 표준화하는 것이 핵심입니다.
RAW 데이터를 오브젝트 스토리지에 원본 보존하고 상태 관리 DB로 수집(Collector)과 정제(Worker)를 분리 — 재처리는 외부 요청 없이 재파싱으로 해결
Cache Hit/Miss 패턴(이미 있으면 즉시 반환)과 version_id 기반 수정 이력 추적으로 데이터 재현 가능성 확보
오픈소스 RAW 데이터 수집용 오브젝트 스토리지 설계
파일시스템 → 오브젝트 스토리지(SeaweedFS) 마이그레이션 전략·로드맵 수립
3임팩트
외부 요청 제거 — 재수집 때마다 반복되던 1,000만~1억 건의 API 호출이 재처리 시 0건으로 (RAW 재파싱)
재처리 시간 단축 — rate limit에 묶여 수일씩 걸리던 기간 재수집을 내부 재파싱으로 대체 (설계 산정 예: 2일 → 5분)
추적·재현 가능 — version_id 이력 추적과 원본 보존으로, 이상 데이터의 원인 규명·재현이 가능
수집 플로우 표준화 — 수집→정제→배포 책임 명확화, 신규 소스 편입·운영 인계 용이
4역할
데이터 엔지니어링 리드로서 파이프라인 재정의 → 스토리지 설계 → 마이그레이션 전략 수립을 단독으로 수행했습니다. 수집부터 배포까지 전체 흐름을 표준화하고 파일시스템에서 오브젝트 스토리지로 옮기는 로드맵을 세워 확장 가능한 데이터 기반을 마련하고 있습니다.