개인 아키텍처 시스템 시리즈
- #1 왜·어떻게 만들었나
- #2 포트 기반 baseline
- #3 인프라 concern 조립 — 지금 이 글
- #4 MSA 즉시 접목
애플리케이션 골격(2편)이 섰으면, 그걸 굴릴 인프라가 필요하다. 나는 인프라를 하나의 덩어리로 보지 않고 10개의 concern으로 쪼갠 뒤, 필요한 것만 순서대로 깔리게 만들었다.
1. 한 장으로 보는 조립
concern은 platform · persistence · messaging · identity · workflow · observability · ci · delivery · migration · secrets 로 나뉜다. 각 concern은 manifest.yaml에 의존성과 산출물을 선언한다.
# concern manifest (개념)
depends_on: [platform, secrets]
provides:
patterns: [...] # 이 concern이 제공하는 아키텍처 패턴
skills: [...] # 초기화/배포 스킬
commands: [...] # 슬래시 커맨드
env:
required: [<GCP_PROJECT_ID>, <DOMAIN>]
optional: [...]그래서 /infra-init --with persistence,delivery 처럼 필요한 concern만 지정하면, depends_on을 위상정렬해서 platform·secrets 같은 선행 concern부터 순서대로 깔아 준다. “무엇을 깔면 무엇이 따라오는가”가 코드가 아니라 문서로 고정되는 셈이다.
2. 무엇까지 자동화되나
| 영역 | 내용 |
|---|---|
| 플랫폼/배포 | Kubernetes 초기화, GitOps(ArgoCD App-of-Apps / ApplicationSet), GitHub Actions 워크플로 셋 |
| 메시징/영속성 | 브로커 프로비저닝, DB 마이그레이션 파이프라인 |
| API 스펙 | OpenAPI를 단일 진실 공급원으로 두고 다중 싱크로 내보내는 파이프라인 |
| 시크릿 | External-Secrets 연동, 프로파일은 플레이스홀더 템플릿으로만 커밋 |
모든 예시 값은 <GCP_PROJECT_ID>·<DOMAIN> 같은 플레이스홀더다. 실제 값은 로컬 프로파일(깃 추적 제외)에만 두어, 어떤 조직 고유정보도 저장소에 남지 않게 설계했다.
마지막 편에서는 이 모든 게 향하는 지점 — MSA로의 즉시 접목 — 을 본다.
답글 남기기