docs(content): 서비스 인프라 현대화 시리즈 확장 기획

[devy1540]

근거가 된 기존 글

• content/posts/ko/ecs-to-eks-migration.md
• content/posts/ko/gitops-argocd-n8n-deployment.md
• content/posts/ko/lgtm-stack-observability.md

왜 시리즈로 갈 만한가

서비스 인프라 현대화 시리즈는 이미 ECS→EKS와 LGTM을 포함하지만, GitOps 자동화 글은 같은 축임에도 시리즈로 묶이지 않았다. EKS, Gateway API, Karpenter, ArgoCD, kustomize, Slack 승인 배포를 하나의 운영 플랫폼 시리즈로 정리할 수 있다.

후보 목차

• ECS에서 EKS로 옮길 때 먼저 비교해야 하는 것들
• kustomize base/overlay로 환경별 차이를 관리하기
• Gateway API와 AWS Load Balancer Controller 구조
• Karpenter NodePool과 consolidation 운영 주의점
• ArgoCD Image Updater와 GitOps 배포 흐름
• dev/stage/prod 배포 전략을 다르게 가져가는 이유
• Slack 승인 배포와 rollback 기준
• readiness probe, PDB, allowedRoutes 같은 실제 삽질 정리

챌린지 산출물

• base/overlay 예제 매니페스트
• ArgoCD sync drift 분석표
• Gateway/HTTPRoute 라우팅 다이어그램
• Karpenter consolidation 장애 시나리오 분석
• 배포 실패 시 runbook 초안

성공 기준

• 기존 인프라 글들을 운영 플랫폼 관점의 연속 시리즈로 묶는다.
• 각 글은 단순 설치법보다 source of truth, 배포 경계, 장애 대응 기준을 포함한다.