오픈소스 생태계의 메타·바이너리·Git 원본 30억~60억 건을 외부 의존 없이 재현 가능하게 보존하는 자체 미러 인프라 설계·구축
외부 API와 원천 저장소가 계속 살아 있을 것이라고 가정하면 수집 시스템은 편해 보입니다. 하지만 오픈소스 데이터는 사라지거나 바뀌기 때문에, 원본을 내부에서 다시 재현할 수 있어야 했습니다.
SeaweedFS와 ZFS+Forgejo를 나눠 본 것은 데이터의 수정 패턴이 달랐기 때문입니다. 메타·바이너리와 Git 원본을 같은 저장 방식으로 밀어 넣지 않은 점이 이 설계의 핵심입니다.
오픈소스 생태계의 메타정보(npm·PyPI·Maven·Go 패키지, CVE·OSV·SPDX 라이선스), 바이너리(tarball·wheel·jar 등), Git 원본(RAW 저장소)을 대규모로 수집·보존하는 자체 미러 인프라가 필요했습니다. 원본을 스키마 강제 없이 그대로 보존해 두는 층이라는 점에서, 사내 데이터 레이크의 저장 기반에 해당합니다.
모든 데이터를 한 저장소에 몰지 않고 데이터가 어떻게 수정되는가를 기준으로 저장소를 나눴습니다.
한 번 쓰고 key로 읽는(write-once, read-by-key) 패턴.
SeaweedFS(S3 호환) · 오브젝트 볼륨 파일시스템 XFS잠금·부분수정·ref 갱신·index 재작성이 잦은 패턴.
ZFS 위 bare 저장소 · 미러 자동화는 Forgejo Mirror에 위임Haystack 패킹으로 효율 저장. 객체당 파일 1개인 MinIO는 inode 폭발이 약점이라, 작은 파일 대량 보관에는 SeaweedFS가 유리.checksum/scrub으로 bit rot을 자동 감지·복구하고 LZ4 압축·스냅샷·send/recv 복제가 강점.EC(6+2)로 서버 간 복제.검토했으나 미채택: ① JuiceFS 완전 통합 안(git까지 오브젝트 스토리지 안에) — git의 다수 작은 객체 워크로드에서 clone/fetch 성능 저하, 추상화 3중첩(git→JuiceFS→SeaweedFS→디스크)의 디버깅 난이도로 제외. ② cron+스크립트 자체 미러 안 — 동시성·재시도·인증·모니터링을 모두 직접 구현해야 하고 repo가 늘수록 부담이 가속되어 제외. 오브젝트 스토리지 후보는 MinIO(객체당 파일 1개 → inode 폭발)·Ceph(2서버엔 과한 운영 복잡도)·Garage(신생)·클라우드 R2/B2(egress 비용·데이터 주권)를 비교한 뒤 SeaweedFS로 선정 — 라이선스도 Apache 2.0(MinIO는 AGPL v3)으로 유리.
데이터 엔지니어링 리드로서 저장소 분리 설계 → 기술 선택 근거 정리 → 구축 착수를 단독으로 수행했습니다. 데이터의 수정 패턴에 맞춰 오브젝트 스토리지와 파일시스템을 나누고, 작은 파일 대량 저장(SeaweedFS·Haystack)과 git 무결성·복제(ZFS·Forgejo)를 각각 최적화해 외부 의존 없는 확장 가능한 데이터 인프라 기반을 마련했습니다.
2026-05 설계 문서화, 6월 구축 착수.
📦 데이터 플랫폼 재구축 시리즈 ② — 이 인프라가 뒷받침하는 상위 수집 파이프라인 전략: ① ETL 데이터 수집 플로우 재정립 →