26A01a

먼저 전체 개념 구조를 한 눈에 보여드리고, 상세 디렉토리를 이어서 설명합니다.개념을 파악하셨으면 상세 디렉토리 구조를 보여드립니다.탭별로 각 레이어를 확인하실 수 있습니다. 핵심 결정사항을 정리합니다.

핵심 설계 결정 3가지

values 3-layer 패턴 (base → site → env): 모든 중복을 제거하는 핵심입니다. 예를 들어 이미지 태그 버전을 올릴 때 base.yaml 한 곳만 수정하면 전 사이트/환경에 반영됩니다. ic 사이트의 StorageClass를 바꿀 때는 ic/site.yaml만, ic-prod의 리소스 크기는 ic/prod.yaml만 건드립니다. 어느 파일을 수정해야 할지 항상 명확합니다.

ArgoCD multi-source로 chart와 values 분리: Harbor(air-gap Helm 레포)에서 차트를, Bitbucket에서 values를 각각 참조합니다. ref: values로 $values 변수를 선언하면 valueFiles에서 $values/helm/values/... 경로로 두 소스를 연결합니다. 차트 버전(targetRevision)과 values 변경을 독립적인 PR로 관리할 수 있어 변경 추적이 깔끔합니다.

Kustomize 전환 전략: kustomize/ 디렉토리를 지금 만들어두되 ArgoCD Application은 아직 Helm을 바라보게 합니다. 전환 시 apps/ic/prod/directpv.yaml의 sources 블록을 source.path: kustomize/directpv/overlays/ic-prod로 교체하는 것이 전부입니다. 앱 하나씩 순차 전환이 가능해 리스크가 없습니다.

App-of-Apps 결론: 지금 사이트 수(ic, wx)에서는 App-of-Apps가 맞습니다. apps/_root/ic-prod.yaml 하나만 ArgoCD에 수동 등록하면 그 아래 directpv/operator/objectstore가 wave 순서(0→1→2)대로 자동 배포됩니다. 사이트가 5개 이상으로 늘어나는 시점에 ApplicationSet matrix로 전환을 검토합니다.