# [ENHC|OBJ] Object storage plan — three options compared
AI Summary
Purpose:
- Preserve the decision record for the open-source RAW data object-storage
design (last modified 2026-07-14), authored by 김현욱. This is the comparison document cited by the resume claim "방안을 여러 개 만들어 리뷰로 확정".
Key points:
- One-line decision: meta/binary data on SeaweedFS, git repositories on ZFS,
multi-repo mirror automation delegated to Forgejo.
- Data inventory framing: META DATA (KB-scale json/xml/html), BINARY FILE
(KB~GB jar/tar/aar/whl — new collection scope), GIT REPOSITORY (full source).
- Three options compared in a table, adopted one starred:
1) Full integration — JuiceFS over SeaweedFS, bare repos inside object storage (git clone performance: low; mirror automation: build yourself) — rejected. 2) Split + self-built mirror — SeaweedFS + ZFS native git (clone: high; mirror automation: build yourself) — rejected. 3) Split + Forgejo (adopted ★) — SeaweedFS for meta/binary, ZFS + Forgejo for git (clone: high; mirror automation: provided by Forgejo).
- Connects to: etl-flow-redesign (RAW preservation pipeline) and the Forgejo
server redesign doc (2026-07-15) which implements the git side.
Relevant when:
- Interview question "방안 비교 문서 예시 보여달라" — this is the primary
evidence; also any storage architecture follow-up work.
Do not read full document unless:
- You need the full comparison table cells — open the origin page.
Linked documents:
- ai/sources/confluence/2026-07-17-forgejo-server-redesign.md
- human/portfolio/items/etl-flow-redesign.html, object-storage-seaweedfs.html