3 5 최소 구조 비용 및 현재 한계 - 100-hours-a-week/KTB4-13th-wiki GitHub Wiki
3-5. 최소 구조·비용 및 현재 한계
1. 검토 결론
현재 CD 구조는 북적북적 V1을 빠르게 배포하기 위한 최소 안전 구조입니다.
App EC2와 AI EC2는 이미 서비스 실행에 필요한 서버이므로 CD를 위해 새 Server를 추가하지 않습니다. GitHub Actions, ECR, SSM, Parameter Store를 연결하여 수동 명령을 자동화하고, 승인·검증·롤백에 필요한 최소 기능만 추가합니다.
EC2 1대에 모든 Container를 합치는 절대 최소 비용 구조보다는 비용이 들지만, MySQL·Backend와 AI Server·Qdrant의 Resource 경합 및 장애 범위를 줄일 수 있습니다. 특히 Qdrant Indexing과 AI 작업이 App API와 MySQL의 응답 시간을 방해하지 않도록 두 EC2의 역할 분리를 유지하는 것이 적절합니다.
2. 유지하는 최소 구성
| 구성 | 결정 | 이유 |
|---|---|---|
| App EC2 1대 | 유지 | Nginx·Backend·MySQL 실행에 이미 필요합니다. |
| AI EC2 1대 | 유지 | AI Server·Qdrant의 Memory와 CPU 사용을 App 영역과 분리합니다. |
| EC2별 Docker Compose | 유지 | 팀이 익숙한 방식으로 두 Server를 독립 배포할 수 있습니다. |
| S3 + CloudFront | 유지 | Frontend Server를 별도로 운영하지 않고 정적 자산을 저렴하게 제공합니다. |
| ECR | 유지 | Image Digest 고정과 이전 Image Rollback에 필요합니다. |
| GitHub OIDC + SSM | 추가 | 별도 배포 Server 없이 장기 AWS Key와 SSH 의존성을 제거합니다. |
| Parameter Store Standard | 추가 | Application Secret을 별도 유료 관리 Server 없이 암호화해 저장합니다. |
| Health·Smoke Test | 추가 | Container가 실행 중인 것과 실제 서비스가 정상인 것을 구분합니다. |
| 이전 Release 1개 이상 | 유지 | 실패 시 10분 이내 복구하기 위한 최소 Rollback 자산입니다. |
두 EC2는 고가용성용 복제본이 아니라 역할이 다른 단일 Server입니다. App EC2가 실패하면 전체 API가 중단되고 AI EC2가 실패하면 추천 기능이 중단됩니다.
3. 초기 구성에서 제외하는 항목
| 제외 항목 | 제외 이유 | 도입 시점 |
|---|---|---|
| 상시 Staging EC2 | 운영과 같은 환경을 만들려면 App·AI EC2가 추가로 필요해 Compute 비용이 거의 두 배가 됩니다. | 배포가 주 1회 이상이거나 운영 장애 비용이 Staging 비용보다 커질 때 |
| Blue-Green 추가 Server | 현재 Traffic에서는 무중단 이점보다 EC2·Data 동기화 비용과 운영 복잡도가 큽니다. | 배포 중단을 허용할 수 없거나 유료 Traffic이 증가할 때 |
| ALB | 단일 App EC2에 분산할 대상이 없고 Nginx가 TLS와 Reverse Proxy를 처리합니다. | App Instance를 2대 이상 운영할 때 |
| RDS Multi-AZ | 3주 POC에서 Self-hosted MySQL보다 비용 증가가 큽니다. | 복구 자동화와 DB 가용성이 매출·SLA에 직접 영향을 줄 때 |
| NAT Gateway | 시간당 비용과 처리 Data 비용이 초기 Traffic에 비해 큽니다. | Private Subnet 전환과 중앙 Outbound 통제가 필요할 때 |
| ECS·Kubernetes | Container 수와 배포 빈도가 적어 Orchestration 운영 비용이 더 큽니다. | Service와 Instance가 늘어 Compose 관리가 반복 장애 원인이 될 때 |
| Canary | 약 0.18 RPS에서는 짧은 관찰 시간 안에 통계적으로 의미 있는 오류율을 얻기 어렵습니다. | Traffic이 충분하고 자동 지표 판정 기준을 만들 수 있을 때 |
| Secrets Manager 기본 사용 | V1은 자동 Rotation이 없어 Parameter Store Standard로 요구를 충족할 수 있습니다. | 자동 Rotation이나 Secret Lifecycle 규제가 필요할 때 |
| Container Insights·고해상도 Metric | 초기 규모에서는 관측 비용 대비 효과가 낮습니다. | 기본 Metric으로 병목을 설명하지 못할 때 |
제외는 해당 기능이 불필요하다는 뜻이 아니라, 현재 규모에서 비용과 복잡도를 먼저 부담하지 않는다는 뜻입니다.
4. CD 증분 비용 검토
기존 App·AI EC2, EBS, S3·CloudFront 등 서비스 자체의 월 비용은 1-3. 운영 기준 및 예상 비용을 기준 문서로 사용합니다. 이 페이지에서는 CD 자동화 때문에 추가되는 비용만 계산합니다.
아래 금액은 2026년 9월 확인한 공개 가격과 소규모 사용량을 바탕으로 한 Planning Estimate입니다. Region, 세금, 환율, Image 크기, Log 양, GitHub Plan에 따라 달라질 수 있습니다.
| 항목 | 가정 | 월 증분 비용 예상 |
|---|---|---|
| GitHub OIDC·AWS STS | 배포 때 단기 Credential 발급 | 별도 비용 없음 |
| SSM Run Command·Session Manager | AWS EC2 2대에 소수 배포·점검 실행 | 별도 SSM 이용료 없음 |
| Parameter Store Standard | 4KB 이하 소수 SecureString, Standard Throughput |
별도 Parameter 저장·API 비용 없음. KMS 요청 비용은 발생할 수 있습니다. |
| ECR | Backend·AI Image 각 500MB, 최근 5개 Release 보존: 최대 약 5GB | 약 $0.50/월 |
| Frontend Release 보존 | S3에 최근 3~5개 정적 Artifact 유지 | 초기 용량에서는 수 센트 수준으로 예상합니다. |
| CloudFront Invalidation | Root index.html 중심으로 배포 시 실행 |
초기 배포 횟수에서는 Free Allowance 안을 목표로 합니다. |
| CloudWatch | 필수 Log 7~14일, 기본 EC2 Metric과 소수 Alarm | Free Tier·소량 사용 시 $0에 가깝게 운영 가능하나 Log 양에 따라 증가합니다. |
| GitHub Actions | 월 2회 Release, PR CI, Linux Runner | Public Repository는 Standard Runner가 무료이며, Private Repository는 Plan 포함량 안을 목표로 합니다. |
ECR은 공식 예시의 Private Image Storage 단가인 GB당 월 $0.10을 적용했습니다. 위 가정대로라면 CD 증분 비용은 대략 월 $0.5~2.5 범위를 목표로 합니다. 이는 기존 인프라, Domain, EBS Snapshot 증가분, 외부 LLM API, 초과 Data Transfer, 세금과 GitHub 유료 Plan 비용을 제외한 값입니다.
가격 근거는 AWS Systems Manager 요금, AWS Systems Manager Parameter Store 문서, Amazon ECR 요금, AWS Secrets Manager 요금, GitHub Actions 요금 문서를 기준으로 합니다.
5. 비용 통제 정책
ECR와 GitHub Actions
- ECR에는 운영 중인 Release, 직전 Rollback Release, 최근 검증 Release를 포함해 3~5개만 보존합니다.
- Untagged Image는 1일 후 제거하는 Lifecycle Policy를 설정합니다.
- 운영 배포에서 Image를 다시 Build하지 않아 Runner 시간과 버전 불일치를 줄입니다.
- 같은 Branch의 오래된 CI는
concurrency로 취소하고 Dependency Cache를 사용합니다. - GitHub Artifact는 증거 보관에 필요한 기간만 유지하고 Docker Image 자체는 ECR에만 저장합니다.
S3·CloudFront
- Frontend Release는 최근 3~5개만 즉시 복원 가능하게 보존하고 이전 버전은 Lifecycle로 정리합니다.
- 파일명이 Hash인 정적 Asset은 Invalidation하지 않고, Root
index.html만 무효화합니다. - S3 Versioning의 Noncurrent Version도 보존 기간을 지정합니다.
CloudWatch·Data Backup
- Application과 배포 Log 보존 기간은 V1에서 7~14일로 제한합니다.
- Alarm은 EC2 Status, Disk, CPU·Memory, HTTP 5xx, Backup 실패 등 장애 판단에 필요한 항목부터 시작합니다.
- Debug Log와 요청 Body는 기본적으로 수집하지 않으며 개인정보와 Token을 Masking합니다.
- Qdrant의 이전 Collection은 Rollback 기간까지만 유지하고 Backup과 승인 후 삭제합니다.
- EBS Snapshot은 RPO 정책에 필요한 수량만 보존하고 오래된 Snapshot을 Lifecycle로 정리합니다.
6. 현재 CD 구조가 가진 한계
6.1 가용성과 배포 중단
- App EC2와 AI EC2는 각 역할에서 단일 장애 지점입니다.
- Controlled Recreate 중 Backend Container를 교체하므로 약 1~2분의 API 중단이 발생할 수 있습니다.
- Nginx 점검 응답으로 불완전한 요청은 막을 수 있지만 서비스 자체를 무중단으로 만들지는 못합니다.
- EC2 Host 장애 시 Compose Rollback만으로 복구할 수 없고 Instance나 Volume 복구가 필요합니다.
6.2 Data 복구
- MySQL과 Qdrant를 직접 운영하므로 Managed Service 수준의 자동 Failover가 없습니다.
- MySQL Schema를 파괴적으로 변경하면 Application Image만 되돌려서는 복구되지 않습니다.
- Qdrant 신규 Collection을 위한 전체 Re-indexing은 배포 시간보다 오래 걸릴 수 있으므로 사전에 완료해야 합니다.
- EBS와 Snapshot이 같은 AWS Region에만 있으면 Region 장애까지 보호하지 못합니다.
6.3 두 EC2 간 호환성
- AI Server를 먼저 배포하고 Backend를 나중에 배포하는 동안 두 Version이 함께 동작할 수 있어야 합니다.
- Backend·AI API Contract와 Qdrant Collection Version이 맞지 않으면 추천 기능이 실패할 수 있습니다.
- Private Network 지연이나 AI EC2 장애가 Backend의 추천 요청을 지연시키므로 Timeout·Circuit Breaker·Fallback이 필요합니다.
6.4 검증 정확도
- 상시 Staging 환경이 없어 운영과 완전히 동일한 조건의 사전 검증은 어렵습니다.
- 약 0.18 RPS에서는 Canary나 배포 직후 실사용 오류율만으로 회귀를 빠르게 판단하기 어렵습니다.
- 외부 LLM 결과는 비결정적이므로 추천 순위를 정확히 고정한 Test에는 한계가 있습니다.
- Smoke Test는 핵심 흐름을 확인하지만 모든 사용 경로와 추천 품질을 보장하지는 않습니다.
6.5 운영 확장성
- Docker Compose는 여러 Host의 Scheduling, Auto Scaling, 자동 Service Discovery를 제공하지 않습니다.
- Server가 늘면 Compose 파일·배포 순서·Rollback 상태를 각 Host에서 맞추기 어려워집니다.
- SSM 기반 Script 품질과 각 EC2의 Local 상태에 의존하므로 Script를 Version 관리하고 반복 실행이 안전하도록 유지해야 합니다.
7. 다음 구조로 전환하는 기준
다음 중 하나가 충족되면 초기 최소 구조를 다시 검토합니다.
- 정기 배포의 1~2분 중단을 허용할 수 없습니다.
- 배포 빈도가 주 1회 이상으로 늘어 상시 Staging의 편익이 커집니다.
- App 또는 AI EC2의 CPU·Memory가 반복해서 70~80% 이상입니다.
- Host 장애 복구가 목표 RTO를 반복해서 초과합니다.
- 유료 회원·주문·제휴 Traffic 증가로 단일 EC2 장애 비용이 복제 비용보다 커집니다.
- Service나 EC2 수가 늘어 Compose 배포 오류가 반복됩니다.
우선순위는 운영과 같은 Staging 환경, App EC2 복제와 ALB, RDS 또는 Managed Database, AI Worker 분리 순서입니다. Instance와 Service 수가 충분히 늘어난 뒤 ECS를 검토하며, Kubernetes는 더 큰 조직적 요구가 있을 때 선택합니다.