DongHyeonkaandClaude Opus 5
ef947e5bb0
외부 리뷰("현재 상태를 유지하기 위한 검증이 너무 많고, 그 검증 자체를
다시 검증하는 구조까지 생겼다")를 설계 문서로 정리하고 코드로 반영한다.
설계·판단 근거는 docs/superpowers/specs/2026-09-16-verification-surface-reduction-design.md.
삭제
- .github/ci-gate-matrix.yml(1,025줄) + verify-gate-matrix.sh(568줄):
Gradle task graph와 workflow graph에 이미 있는 정보의 3중 복제
- verify-gradle-wrapper.sh(799줄): workflow 바이트 해시 잠금.
wrapper 검증은 gradle/actions/wrapper-validation(full SHA 핀)에 위임
- DeveloperExperienceContractTest 등의 CI YAML mutation 테스트:
애플리케이션 test suite가 GitHub Actions YAML 파서를 검증하던 계층 역전
- 문서 drift 파서: verifyReadmeCommands, verifyRunbookReferences,
verifyDocumentedLeafCount, verifyTestSourceSetRegistry
- 빈 레지스트리를 지키던 커스텀 YAML 파서: verifyTrivyignore,
verifyQuarantineSunset, flaky-quarantine.yaml
- verifyConfigurationPropertiesProcessor, verifyOneTypePerFile:
각각 ca.spring-config convention과 Checkstyle OneTopLevelClass가 대체
- 정상 입력으로도 성공할 수 없던 messaging always-fail task
- ModuleRegistry의 JSON 필드 집합 정확 일치, sample-portfolio negative guard
이동
- java/quality/spring 공통 설정을 configure(subprojects) 블록에서
ca.java-conventions / ca.quality-conventions / ca.java-library /
ca.spring-library convention plugin으로
- 아키텍처 검증을 ca.architecture로, JPA·messaging qualification을
gradle/qualification/ 아래로, verifyEnvKeys를 :app-bootstrap 소유로
완화
- Git revision은 releaseCheck·아카이브 생성에서만 요구. 일반 빌드는 SNAPSHOT
- SpotBugs/FindSecBugs는 로컬 check에서 빼고 qualityCheck 레인으로
task 계층
- leaf check는 그 leaf만. architectureCheck / qualityCheck /
configContractCheck / integrationCheck / ci / releaseCheck로 이름 분리
CI
- _reusable-gradle.yml 신규. checkout + wrapper validation + JDK/캐시 공통화
- fileserver-release.yml -> fileserver-certification.yml (CD가 아니라 certification)
- GitHub Actions = CI + artifact, Argo CD = CD 경계를 docs/ci-cd/boundary.md로 고정
순증감 +3,274 / -7,483.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.8 KiB
3.8 KiB
CI/CD 경계 — GitHub Actions는 CI, Argo CD는 CD
결론
GitHub Actions는 검증하고 아티팩트를 만든다. Argo CD는 배포한다. 두 역할은 겹치지 않는다.
GitHub Actions 워크플로는 kubectl apply, helm upgrade, argocd app sync 중 어느 것도 하지
않는다. 그러므로 CI에는 클러스터 자격증명(kubeconfig, 서비스 계정 토큰)이 들어가지 않는다.
흐름
git push / tag
│
▼
GitHub Actions ─────────────── CI ───────────────┐
• 테스트 · 정적분석 · 아키텍처 검증 │
• 컨테이너 이미지 빌드 │
• 취약점 스캔 (Trivy) │
• SBOM 생성 │
• 레지스트리에 이미지 push │
│ │
│ 이미지 태그(다이제스트)를 manifest에 기록 │
▼ │
GitOps 저장소 (배포 희망 상태) ──────────────────┘
│
│ Argo CD가 watch
▼
Argo CD ──────────────────── CD ───────────────
│ auto-sync
▼
Kubernetes
용어 한 줄 풀이:
- GitOps 저장소 — 클러스터에 무엇이 떠 있어야 하는지를 적어 둔 Git 저장소. 애플리케이션 소스와 분리한다.
- manifest — Kubernetes에 넣을 YAML(Deployment, Service 등).
- auto-sync — Argo CD가 GitOps 저장소의 변경을 스스로 감지해 클러스터에 반영하는 모드. 이걸 쓰면 CI가 Argo CD API 서버에 접근할 필요가 없다.
왜 이렇게 나누나
- 자격증명 반경. CI가 배포하면 CI 러너가 프로덕션 클러스터에 대한 쓰기 권한을 갖는다. 포크된 PR, 서드파티 액션, 캐시 오염이 모두 그 권한에 닿는다. auto-sync를 쓰면 그 권한은 클러스터 안의 Argo CD에만 있고, CI는 Git에 커밋만 한다.
- 현재 상태의 소유자가 하나. 클러스터에 무엇이 떠 있는지는 GitOps 저장소가 답한다. CI가 직접 apply 하면 답이 두 개가 된다 — Git에 적힌 것과 실제로 떠 있는 것.
- 롤백이 revert. 배포를 되돌리는 것이
git revert가 된다.
이 저장소의 현재 위치
| 항목 | 상태 |
|---|---|
| 이미지 빌드/스캔/push | release.yml이 수행 |
| SBOM | release.yml이 생성 |
| 이미지 서명 · provenance attestation | 없음. 추가 대상 |
| GitOps 저장소 | 없음. 별도 저장소로 만들 예정 |
| Argo CD Application 정의 | 없음. GitOps 저장소에 둘 예정 |
| CI에서의 클러스터 접근 | 없음 — 유일했던 kubectl apply는 제거됨 |
fileserver-certification.yml은 예외처럼 보이지만 아니다. PVC 매니페스트가 여전히 ReadWriteOnce를
선언하는지 파일만 확인하고, 클러스터에는 아무것도 적용하지 않는다. 실제 클러스터에서의 인증은
운영자가 infra/fileserver/kubernetes/pvc-certification-job.yaml을 직접 실행하고
docs/fileserver/storage-certification.md에 기록한다. 이름을 fileserver-release.yml에서 바꾼 이유가
이것이다 — 이 워크플로는 릴리스하지 않는다.
규칙
- 워크플로에 클러스터 자격증명 secret을 추가하지 않는다.
- 배포 대상이 바뀌면 GitOps 저장소의 manifest를 바꾼다. 워크플로를 바꾸지 않는다.
- CI가 만드는 것은 불변 다이제스트로 지정된 이미지다.
latest태그로 배포하지 않는다.