refactor: 구조 변경

docs/architecture/argocd.md

@@ -4,16 +4,16 @@
 
 Controller 설치 후 다음 두 bootstrap object를 순서대로 수동 seed합니다.
 
-1. `bootstrap/argocd/control-plane-project.yaml`
-2. `bootstrap/argocd/root-application.yaml`
+1. `bootstrap/gitops/argocd/control-plane-project.yaml`
+2. `bootstrap/gitops/argocd/root-application.yaml`
 
 `gitops-control-plane` AppProject는 canonical Gitea repository와 in-cluster
 `argocd` namespace, AppProject/ApplicationSet kind만 허용합니다. 단일 root
-Application은 이 Project를 사용하고 다음 control-plane 구성을 source로
-사용합니다.
+Application은 이 Project를 사용하고 `gitops/clusters/dev-k3s`를 source로
+사용합니다. Cluster root는 다음 control-plane 구성을 참조합니다.
 
 ```text
-platform/control-plane/argocd
+gitops/platform/control-plane/argocd
 ├── projects
 │   ├── platform-addons.yaml
 │   ├── platform-services.yaml
@@ -26,7 +26,7 @@ platform/control-plane/argocd
     └── workloads.yaml
 ```
 
-Root는 AppProject와 ApplicationSet까지만 직접 소유합니다. 각
+Cluster root는 AppProject와 ApplicationSet까지만 직접 소유합니다. 각
 ApplicationSet의 list inventory가 실제 child Application을 생성합니다.
 Routine 변경에 category별 root나 직접 `kubectl apply`를 추가하지 않습니다.
 
@@ -134,8 +134,8 @@ generator가 가장 쉽게 검토됩니다. 존재하지 않는 production이나
 cluster를 위해 Matrix abstraction을 미리 만들지 않습니다.
 
 두 번째 실제 cluster가 생겨 `cluster`, `server`와 cluster별 gate를 여러
-component에서 반복하게 될 때 `clusters/<cluster>/config.yaml`을 Git files
-generator로 읽고 component inventory와 Matrix generator로 결합합니다.
+component에서 반복하게 될 때 `gitops/clusters/<cluster>/config.yaml`을 Git
+files generator로 읽고 component inventory와 Matrix generator로 결합합니다.
 그때도 AppProject는 ApplicationSet template에 고정하고, cluster별
 `autoSync`는 quoted string과 승인 gate로 유지합니다.
 

docs/architecture/deployment.md

@@ -25,14 +25,16 @@ registry이며 desired state source가 아닙니다.
 
 | Layer | 역할 |
 |---|---|
-| `platform/control-plane/argocd` | AppProject와 ApplicationSet control plane |
-| `platform/shared-services/*/base` | 환경 중립을 목표로 하는 공유 cluster service base |
-| `systems/*/base` | 환경 중립을 목표로 하는 bounded-context backing system base |
-| `workloads/*/base` | first-party 애플리케이션 base |
-| `clusters/dev-k3s/overlays/*` | dev namespace, host, digest, Vault role/path, NetworkPolicy를 합친 최종 구성 |
+| `gitops/clusters/dev-k3s` | bootstrap root가 읽는 유일한 cluster entrypoint |
+| `gitops/platform/control-plane/argocd` | AppProject와 ApplicationSet control plane |
+| `gitops/platform/shared-services/*/base` | 환경 중립을 목표로 하는 공유 cluster service base |
+| `gitops/apps/systems/*/base` | 환경 중립을 목표로 하는 bounded-context backing system base |
+| `gitops/apps/workloads/*/base` | first-party 애플리케이션 base |
+| `gitops/clusters/dev-k3s/overlays/*` | dev namespace, host, digest, Vault role/path, NetworkPolicy를 합친 최종 구성 |
 
 현재 concrete ownership은 Vault가 platform shared service,
-PostgreSQL/Keycloak이 `systems/auth-system`, 두 서버가 workload입니다.
+PostgreSQL/Keycloak이 `gitops/apps/systems/auth-system`, 두 서버가
+`gitops/apps/workloads`의 workload입니다.
 Argo CD Application은 base가 아니라 최종 cluster overlay만 source로
 사용합니다.
 

docs/architecture/repository-structure.md

@@ -0,0 +1,150 @@
+# Repository Structure
+
+## 설계 목표
+
+이 구조는 특정 제품의 파일 배치보다 변경 주기와 소유권을 우선합니다.
+
+- 한 리소스에는 한 명확한 소유자가 있다.
+- 재사용 구현과 실제 배포 진입점을 분리한다.
+- 소규모 구성은 선택 영역을 생략할 수 있다.
+- 규모가 커져도 기존 경계를 바꾸지 않고 같은 종류의 leaf를 추가한다.
+- 사람이 실행하는 명령과 CI 검증이 같은 진입점을 사용한다.
+
+## 소유권 매트릭스
+
+| 대상 | 소유 경로 | 직접 실행 여부 | 변경 주기 |
+|---|---|---:|---|
+| state backend, 초기 identity | `bootstrap/foundation` | 예 | 매우 낮음 |
+| 네트워크, IAM, DNS, 클러스터 | `infrastructure/live` | 예 | 낮음 |
+| 재사용 IaC 단위 | `infrastructure/components` | 아니요 | 중간 |
+| 재사용 IaC 조합 | `infrastructure/stacks` | 아니요 | 중간 |
+| GitOps 컨트롤러와 root 연결 | `bootstrap/gitops` | 예 | 낮음 |
+| 클러스터 desired state | `gitops/clusters` | reconcile 진입점 | 지속적 |
+| cluster-wide addon | `gitops/platform` | 아니요 | 중간 |
+| 애플리케이션 배포 정의 | `gitops/apps` | 아니요 | 높음 |
+| 정책과 tenant 정의 | `gitops/policies`, `gitops/tenants` | 아니요 | 중간 |
+
+Catalog 영역(`components`, `stacks`, `platform`, `policies`, `tenants`, `apps`)은
+직접 배포하지 않습니다. 실제 진입점이 필요한 항목만 조합해서 참조합니다.
+
+## 의존 방향
+
+```text
+bootstrap/foundation
+        │ output
+        ▼
+infrastructure/components ◀── infrastructure/stacks
+        ▲                              ▲
+        └──────── infrastructure/live ─┘
+                         │ cluster endpoint/identity
+                         ▼
+                 bootstrap/gitops
+                         │ root reference
+                         ▼
+  platform ─┐
+  policies ─┼────────▶ gitops/clusters
+  tenants  ─┤
+  apps     ─┘
+```
+
+역방향 의존은 만들지 않습니다. 예를 들어 reusable component가 특정
+`live/prod` 값을 읽거나, app base가 특정 cluster overlay를 참조하면 안 됩니다.
+
+## Infrastructure 경계
+
+### `components`
+
+네트워크, identity, registry, Kubernetes cluster처럼 작고 응집된 재사용
+단위입니다. Terraform/OpenTofu를 선택했다면 일반적으로 backend가 없는 child
+module에 해당합니다.
+
+### `stacks`
+
+여러 component를 반복해서 같은 방식으로 조합할 때만 사용합니다. 작은 프로젝트는
+이 계층 없이 `live`가 component를 직접 호출할 수 있습니다. stack이 다른 stack을
+깊게 중첩하기보다는 live root에서 평평하게 조합하는 방식을 권장합니다.
+
+### `live`
+
+실제로 plan/apply하는 root입니다. leaf 하나는 다음을 만족해야 합니다.
+
+- 독립된 state와 locking
+- 명시적인 provider와 backend 설정
+- 고정된 component/module/chart 버전
+- 비밀이 아닌 환경 입력만 저장소에 커밋
+- 출력값과 downstream contract 문서화
+
+작은 구성은 `live/dev/cluster`로 충분합니다. 계정과 리전이 늘어나면
+`live/<provider>/<account>/<region>/<environment>/<stack>`처럼 경로를 확장합니다.
+자동화는 경로의 고정 깊이에 의존하지 말고 실행 가능한 root 파일을 기준으로
+대상을 찾도록 작성합니다.
+
+서로 다른 환경의 root가 상대 경로로 다른 환경 구현을 import하면 안 됩니다.
+공유가 필요하면 versioned component나 명시적인 remote output/data contract를
+사용합니다.
+
+## GitOps 경계
+
+### `clusters`
+
+클러스터가 reconcile하는 유일한 진입점입니다. 공통 리소스를 복사하지 않고
+platform, policy, tenant, app catalog에서 필요한 항목만 참조합니다.
+
+작은 구성은 `clusters/dev/main`, 다중 리전 구성은
+`clusters/<environment>/<region>/<cluster>` 형태를 사용할 수 있습니다. 여기에도
+고정된 경로 깊이를 강제하지 않습니다.
+
+### `platform`
+
+cluster-wide controller와 addon을 둡니다. 예시는 다음과 같습니다.
+
+- ingress/gateway, external DNS, certificate
+- storage class/CSI, autoscaling
+- metrics, logs, traces, alerting
+- secret operator와 delivery controller
+
+각 component는 `base`와 필요한 `overlays`를 같은 디렉터리 안에 응집시킵니다.
+환경 차이는 전체 파일 복사 대신 Kustomize patch 또는 별도 values로 표현합니다.
+
+### `policies`, `tenants`, `apps`
+
+- `policies`: cluster-wide admission 규칙, 거버넌스와 예외
+- `tenants`: 구체적인 namespace, RBAC, quota, limit range, NetworkPolicy
+- `apps`: application source code가 아닌 배포 정의
+
+애플리케이션 팀이 별도 저장소를 소유하면 `apps`에는 그 저장소/OCI artifact를
+참조하는 GitOps 리소스만 둘 수 있습니다.
+
+Cloud DNS zone/delegation과 cloud IAM role은 `infrastructure`가 소유합니다.
+External DNS controller, 동적 record 요청과 Kubernetes ServiceAccount binding은
+`gitops/platform`이 소유합니다. 두 계층 사이에는 zone ID, role ARN 같은
+명시적인 output contract만 전달합니다.
+
+## Bootstrap 경계
+
+Bootstrap은 선언형 관리가 스스로 시작될 수 없는 최소 범위만 담당합니다.
+
+- `foundation`: state backend, 최초 CI identity와 같은 선행 조건
+- `gitops`: Flux 또는 Argo CD 중 선택한 컨트롤러 설치와 root reference
+
+ingress, cert-manager, observability 같은 addon은 bootstrap이 아니라 GitOps가
+소유합니다. bootstrap 이후의 변경을 계속 수동 명령으로 누적하지 않습니다.
+
+## 규모 확장 기준
+
+| 단계 | 추가하는 것 | 그대로 유지하는 것 |
+|---|---|---|
+| 소형 | 단일 live root, 단일 cluster root, 최소 platform | lifecycle/ownership 경계 |
+| 중형 | reusable stack, staging/prod, 정책, 관측성 | component와 entrypoint 분리 |
+| 대형 | 계정·리전별 state, 다중 cluster, tenants, CODEOWNERS | 한 리소스 한 소유자 |
+| 조직 분리 | lifecycle/team별 repository 분리 가능 | 각 repository 내부의 동일한 계약 |
+
+repository를 분리하는 시점은 폴더 수가 아니라 권한, 배포 주기와 소유 팀이
+실제로 달라졌을 때입니다.
+
+## 설계 참고 자료
+
+- [Kubernetes: Kustomize를 이용한 선언형 객체 관리](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [Flux: GitOps repository 구조](https://fluxcd.io/flux/guides/repository-structure/)
+- [OpenTofu: reusable module](https://opentofu.org/docs/language/modules/)
+- [OpenTofu: 평평한 module composition](https://opentofu.org/docs/language/modules/develop/composition/)

docs/architecture/repository-taxonomy.md

@@ -8,11 +8,11 @@
 
 | 분류 | 판단 질문 | 현재 예 |
 |---|---|---|
-| `platform` | GitOps control plane이거나, 둘 이상의 system이 독립 lifecycle로 소비할 cluster capability인가? | Argo inventory, Vault shared service |
-| `systems` | 하나의 bounded context가 함께 소유하는 backing system인가? | Project Auth의 PostgreSQL, Keycloak, realm/client sync |
-| `workloads` | 별도 source repository에서 빌드하는 first-party 실행 단위인가? | `auth-server`, `api-server` |
-| `clusters` | 특정 클러스터의 최종 composition 값인가? | namespace, host, digest, Vault role, NetworkPolicy |
-| `iac` | Kubernetes가 아닌 외부 API 객체를 선언하는가? | Vault mounts, policies, auth roles, database roles |
+| `gitops/platform` | GitOps control plane이거나, 둘 이상의 system이 독립 lifecycle로 소비할 cluster capability인가? | Argo inventory, Vault shared service |
+| `gitops/apps/systems` | 하나의 bounded context가 함께 소유하는 backing system인가? | Project Auth의 PostgreSQL, Keycloak, realm/client sync |
+| `gitops/apps/workloads` | 별도 source repository에서 빌드하는 first-party 실행 단위인가? | `auth-server`, `api-server` |
+| `gitops/clusters` | 특정 클러스터의 최종 composition 값인가? | namespace, host, digest, Vault role, NetworkPolicy |
+| `infrastructure` | Kubernetes가 아닌 외부 API 객체를 선언하는가? | Vault mounts, policies, auth roles, database roles |
 | `bootstrap` | GitOps controller가 존재하기 전에 필요한 최소 seed인가? | Argo CD 설치 버전, 제한된 control-plane AppProject와 root Application |
 
 다음 세 질문을 순서대로 사용합니다.
@@ -23,9 +23,10 @@
 
 제품 이름만으로 분류하지 않습니다. 예를 들어 Keycloak이 여러 system의
 공용 identity service가 되고 별도 owner와 release cadence를 갖게 되면
-실행 서비스는 `platform/`으로 이동할 수 있습니다. 그래도 Project Auth
-realm/client 구성은 `systems/auth-system/`에 남습니다. 현재 Keycloak과
-PostgreSQL은 Project Auth 전용이므로 모두 system 소유입니다.
+실행 서비스는 `gitops/platform/`으로 이동할 수 있습니다. 그래도 Project
+Auth realm/client 구성은 `gitops/apps/systems/auth-system/`에 남습니다.
+현재 Keycloak과 PostgreSQL은 Project Auth 전용이므로 모두 system
+소유입니다.
 
 ## Path contract
 
@@ -33,16 +34,16 @@ PostgreSQL은 Project Auth 전용이므로 모두 system 소유입니다.
 contract입니다.
 
 ```text
-platform/shared-services/<name>/base
-systems/<system>/base
-workloads/<workload>/base
+gitops/platform/shared-services/<name>/base
+gitops/apps/systems/<system>/base
+gitops/apps/workloads/<workload>/base
 
-clusters/<cluster>/overlays/platform/<name>
-clusters/<cluster>/overlays/systems/<system>
-clusters/<cluster>/overlays/workloads/<workload>
+gitops/clusters/<cluster>/overlays/platform/<name>
+gitops/clusters/<cluster>/overlays/systems/<system>
+gitops/clusters/<cluster>/overlays/workloads/<workload>
 
-platform/control-plane/argocd/projects
-platform/control-plane/argocd/application-sets
+gitops/platform/control-plane/argocd/projects
+gitops/platform/control-plane/argocd/application-sets
 ```
 
 Base에는 재사용 가능한 workload 구조, Service, ServiceAccount와 기본
@@ -68,8 +69,9 @@ Base 내부의 PostgreSQL·Keycloak 참조는 namespace를 포함하지 않은
 Service DNS를 사용하므로 overlay namespace에 재사용할 수 있습니다. 다만
 아직 다음 dev/single-node 가정은 남아 있습니다.
 
-- `systems/auth-system/base`의 Keycloak 실행 command가 `start-dev`입니다.
-- `platform/shared-services/vault/base/files/vault/vault.hcl`이
+- `gitops/apps/systems/auth-system/base`의 Keycloak 실행 command가
+  `start-dev`입니다.
+- `gitops/platform/shared-services/vault/base/files/vault/vault.hcl`이
   `tls_disable = 1`과 고정된 single-node `node_id`를 사용합니다.
 
 이는 숨겨진 환경 중립성이 아니라 명시적인 리팩터링 부채입니다. 두 번째
@@ -88,14 +90,14 @@ base -> dev-k3s overlay -> ApplicationSet inventory -> generated Application
 - Cluster addon: Kubernetes API를 확장하거나 admission/control-plane
   기능을 제공하는 외부 chart. 현재 Sealed Secrets와 Vault Agent Injector가
   해당합니다. Inventory는
-  `platform/control-plane/argocd/application-sets/platform-addons.yaml`에
+  `gitops/platform/control-plane/argocd/application-sets/platform-addons.yaml`에
   둡니다.
 - Shared service: 일반 workload처럼 namespace에서 실행되지만 여러 system이
   사용할 수 있는 capability. 현재 Vault가 해당합니다.
 
 외부 Helm chart를 복사해 base처럼 유지하지 않습니다. chart version과
 values는 Argo inventory에서 pin합니다. 저장소가 직접 소유하는 shared
-service manifest만 `platform/shared-services/`에 둡니다.
+service manifest만 `gitops/platform/shared-services/`에 둡니다.
 
 `foundation`은 소유권 분류가 아닙니다. Bootstrap 때 먼저 필요하다는 뜻은
 분리된 ApplicationSet category, `autoSync` gate와 runbook 순서로
@@ -104,16 +106,16 @@ service manifest만 `platform/shared-services/`에 둡니다.
 
 ## System와 workload의 경계
 
-`systems/auth-system`은 인증 bounded context가 함께 책임지는 데이터와
-identity backing services입니다.
+`gitops/apps/systems/auth-system`은 인증 bounded context가 함께 책임지는
+데이터와 identity backing services입니다.
 
 - PostgreSQL StatefulSet와 초기 database contract
 - Keycloak server와 Project Auth realm
 - Keycloak client synchronization
 
-`workloads/auth-server`와 `workloads/api-server`는 각각 별도 source
-repository와 release digest가 있는 애플리케이션입니다. Workload가
-auth-system을 사용하더라도 두 lifecycle을 합치지 않습니다.
+`gitops/apps/workloads/auth-server`와 `gitops/apps/workloads/api-server`는
+각각 별도 source repository와 release digest가 있는 애플리케이션입니다.
+Workload가 auth-system을 사용하더라도 두 lifecycle을 합치지 않습니다.
 
 Dev namespace도 소유권을 드러냅니다.
 
@@ -145,12 +147,12 @@ state가 아닙니다.
 
 | 변경 | 위치 |
 |---|---|
-| 또 다른 공용 admission controller | `platform/control-plane/argocd/application-sets/platform-addons.yaml` |
-| 공용 object storage service base | `platform/shared-services/object-storage/base` |
-| Project Auth 전용 Redis | `systems/auth-system/base` |
-| 새 first-party worker | `workloads/<worker>/base` |
-| dev worker digest/secret annotation | `clusters/dev-k3s/overlays/workloads/<worker>` |
-| Vault workload policy/role | `vault-workloads` Terraform state와 `policies/vault/` |
+| 또 다른 공용 admission controller | `gitops/platform/control-plane/argocd/application-sets/platform-addons.yaml` |
+| 공용 object storage service base | `gitops/platform/shared-services/object-storage/base` |
+| Project Auth 전용 Redis | `gitops/apps/systems/auth-system/base` |
+| 새 first-party worker | `gitops/apps/workloads/<worker>/base` |
+| dev worker digest/secret annotation | `gitops/clusters/dev-k3s/overlays/workloads/<worker>` |
+| Vault workload policy/role | `infrastructure/live/dev-k3s/vault-workloads`와 그 아래 `policies/` |
 | Vault auth backend | `vault-foundation` Terraform state |
 
 분류가 애매하면 설치 순서가 아니라 owner와 소비자 경계를 ADR에 먼저

docs/architecture/terraform.md

@@ -77,10 +77,10 @@ destroy/backup 책임이 정해졌을 때만 다음처럼 별도 machine root를
 추가합니다.
 
 ```text
-iac/terraform/live/<cluster>/machine
-iac/terraform/live/<cluster>/vault-foundation
-iac/terraform/live/<cluster>/vault-workloads
-iac/terraform/live/<cluster>/vault-database
+infrastructure/live/<cluster>/machine
+infrastructure/live/<cluster>/vault-foundation
+infrastructure/live/<cluster>/vault-workloads
+infrastructure/live/<cluster>/vault-database
 ```
 
 Machine root output을 읽기 위해 Vault state 전체를 공유하지 않습니다.