01 자동 배포 환경: 체크리스트를 넘어 운영 흐름으로 읽기 소스 변경에서 빌드, 이미지, 배포, 공개, 확장, 관측, 승인까지 이어지는 하나의 운영 흐름으로 미니프로젝트 6차를 읽는다. KT AIVLE School
Mini Project 6
EKS, CI/CD, RDS, HPA, CloudWatch까지 완성한 6차 미니프로젝트 배포 사례 산문
- 원고
- 9
- 8월 25일-9월 24일
- 0편
01 자동 배포 환경: 체크리스트를 넘어 운영 흐름으로 읽기 소스 변경에서 빌드, 이미지, 배포, 공개, 확장, 관측, 승인까지 이어지는 하나의 운영 흐름으로 미니프로젝트 6차를 읽는다. 
02 dev와 main 배포 레일로 구축하는 안전장치 dev 브랜치와 main 브랜치가 각각 dev/prod 파이프라인과 namespace로 이어지며 검증과 운영 배포를 분리하는 안전장치가 된다는 점을 이해한다. 
03 소스 코드에서 EKS 배포 단위까지: 빌드팩, 도커파일, ECR의 여정 backend Gradle build와 frontend Vite build가 Docker image build, ECR push를 거쳐 EKS가 가져갈 배포 단위로 바뀌는 흐름을 이해한다. 
04 단일 EKS 클러스터, dev/prod 네임스페이스 분리: 의미와 한계 하나의 EKS cluster와 node group 위에서 dev/prod namespace를 나누고, 배포 리소스와 서비스 범위를 환경별로 분리하는 의미를 이해한다. 
05 프론트엔드와 백엔드의 경계: 현명한 서비스 노출 전략 사용자는 frontend LoadBalancer와 Cloudflare 도메인을 통해 들어오고, frontend nginx가 `/api`를 내부 backend ClusterIP로 프록시하는 노출 경계를 이해한다. 
06 자동 배포의 역설: 운영 책임 게이트로서의 수동 승인 자동화가 모든 판단을 없애는 것이 아니라, prod로 넘어가는 순간에 운영 책임과 승인 지점을 명확히 세우는 도구라는 점을 이해한다. 
07 HPA와 RDS 연결 한계: 시스템 스케일링의 진짜 운영 규칙 스케일링은 단일 지표 성공이 아니라 downstream 병목까지 포함한 운영 규칙이며, HPA 숫자는 데이터베이스 연결 한계와 함께 정해야 한다는 점을 이해한다. 
08 CloudWatch Container Insights로 배포 상태를 관측 가능하게 만든 과정 배포 성공을 눈으로 본 상태에서 끝내지 않고, 로그와 지표가 쌓여 운영자가 상태를 확인할 수 있는 관측 가능성으로 확장하는 의미를 이해한다. 
09 완성된 배포 시스템, 운영 경험으로 재해석하기 교안 요구사항과 실제 해결 이슈를 한 장의 운영 사례로 묶어, 다음 프로젝트에 가져갈 배포/운영 판단을 정리한다.