16주차 활동내용

1. 프로젝트 주차 목표

16주차는 프로젝트의 마지막 주차로, 1~15주차에 구축한 전체 시스템을 통합 검증하고 문서화하여 마무리하는 것을 목표로 하였다. 구체적으로 세 가지를 추진하였다. 첫째, 코드 push부터 운영 클러스터 반영까지 CI/CD 전체 파이프라인이 하나의 흐름으로 자동 동작하는지 End-to-End로 실측한다. 둘째, k6를 사용해 클라우드 운영 환경의 성능과 한계를 정량 측정한다(중간보고서의 Locust 100명 부하 테스트를, 로컬이 아닌 실제 클라우드 운영 환경으로 옮긴 후속 검증이다). 셋째, 전체 시스템 아키텍처 다이어그램과 운영 매뉴얼을 작성하여 재현·운영 가능한 형태로 문서화한다.

설정과 부분 검증에 그치지 않고, 실제로 코드 한 줄의 변경이 운영 EKS까지 자동 반영되는 과정을 시간 단위로 측정하고, 운영 서버에 실제 부하를 인가하여 성능 한계를 수치로 확인하는 것을 핵심 목표로 한다.

---

2. 프로젝트 주차 진행 내용

2-1. CI/CD 전체 파이프라인 End-to-End 통합 검증

13~15주차에 단계별로 구축한 GitHub Actions(CI), ECR(컨테이너 레지스트리), ArgoCD(GitOps CD), EKS(운영 클러스터)를 하나의 흐름으로 통합하여 실제 한 바퀴를 돌리고 각 구간의 소요 시간을 실측하였다.

검증 시나리오는 "백엔드 코드 변경 → main push → GitHub Actions(lint→test→build→ECR push) → 매니페스트 이미지 태그 갱신 → ArgoCD 자동 동기화 → EKS 롤아웃"이다. 무해한 빌드 마커 한 줄을 backend 디렉토리에 추가하여 커밋(b26a0d6)을 main에 push함으로써 파이프라인을 트리거하였다. 측정 결과는 다음과 같다.

• T0(코드 push) 02:54:22
• T1(GitHub Actions 완료) 02:56:53 — lint(flake8)·test(pytest)·build-and-push 3개 Job이 모두 성공하였고 약 2분 31초가 소요되었다. ECR에는 커밋 SHA(b26a0d6)와 latest 두 태그로 이미지가 적재되었다.
• T2(매니페스트 갱신 push) 02:58:43 — eks-app 매니페스트의 backend 이미지를 :latest에서 :b26a0d6(불변 SHA 태그)로 핀하여 push하였다.
• T3(EKS 롤아웃 완료) 02:59:43 — ArgoCD가 Git 변경을 감지하여 Deployment 이미지를 새 SHA로 동기화하였고, RollingUpdate 전략으로 파드를 1개씩 무중단 교체하였다. 새 ReplicaSet(6c7b5fd547)의 파드 2개가 b26a0d6 이미지로 Running 상태가 되었다.

kubectl rollout status deploy/backend -n comfortablemove
  Waiting for deployment "backend" rollout to finish: 1 out of 2 new replicas have been updated...
  Waiting for deployment "backend" rollout to finish: 1 old replicas are pending termination...
  deployment "backend" successfully rolled out

# 롤아웃 후 파드 이미지
backend-6c7b5fd547-g8thc  ...comfortablemove-backend:b26a0d6...  Running
backend-6c7b5fd547-mgwkd  ...comfortablemove-backend:b26a0d6...  Running

총 E2E 소요 시간은 5분 21초(T0→T3)로, 계획 목표인 10분 이내를 달성하였다. 코드 변경 한 번이 자동 테스트·빌드·레지스트리 적재·운영 배포까지 사람의 개입 없이 이어지는 것을 실측으로 확인하였다.

한 가지 한계도 함께 기록한다. 현재 구성은 ArgoCD Image Updater를 도입하지 않아, CI가 ECR에 새 이미지를 올린 뒤 매니페스트의 이미지 태그를 새 SHA로 갱신하는 단계가 수동으로 남아 있다. 이는 :latest(가변 태그) 대신 불변 SHA 태그를 사용해 "현재 어떤 코드가 배포되어 있는지"를 Git에서 추적 가능하게 하는 GitOps 원칙을 따른 결과이며, 향후 ArgoCD Image Updater를 적용하면 이 단계까지 무인 자동화할 수 있다.

2-2. k6 부하 테스트 — 클라우드 운영 환경 성능 실측

중간보고서의 Locust 100명 부하 테스트가 로컬 환경을 대상으로 했던 것에 이어, 실제 AWS 운영 환경(https://comfortablemove.com, EC2 t2.micro)을 대상으로 k6 부하 테스트를 수행하였다. 서울시 외부 버스 API의 일일 호출 한도를 보호하기 위해, 부하의 85%는 외부 호출이 없는 /health/ready(DB·Redis만 확인)로, 15%는 Redis 캐시 히트 경로인 /bus/arrivals로 구성하였다. 부하 패턴은 0→50→100 VU로 3분 30초간 점진 인가하였다.

총 7,196건의 요청(초당 34.1건)을 처리하였으며 주요 지표는 다음과 같다.

• 응답시간 중앙값(median) 14.12ms — 정상 부하 구간에서 매우 빠른 응답
• Redis 캐시 히트(arrivals) 중앙값 10.69ms(최저 8.21ms) — 외부 API 직접 호출(평균 300~500ms) 대비 캐시 효과를 명확히 실증
• /health/ready 중앙값 14.3ms, p90 335ms
• 그러나 100 VU 동시 부하 구간에서 단일 t2.micro가 포화되어 p95 3.37초, p99 25.98초, 최대 47.75초로 꼬리 지연(tail latency)이 급증하였고, 실패율 1.11%(7,196건 중 80건)를 기록하여 임계값(p95 500ms·실패율 1%)을 초과하였다.

checks_succeeded...: 98.88% (7115/7195)
http_req_duration..: med=14.12ms p90=411ms p95=3.37s max=47.75s
arrivals_cached_ms.: med=10.69ms (캐시 히트)
http_req_failed....: 1.11% (80/7196)

이 결과의 해석이 중요하다. 50 VU 구간까지는 중앙값 10~14ms로 안정적이었으나, 100 VU 동시성에서 단일 t2.micro(1 vCPU 버스트, Gunicorn 2 워커)의 처리 한계가 드러났다. 이는 부정적 결과가 아니라, 단일 소형 인스턴스의 수직 한계를 정량화하여 EKS 기반 수평 확장(HPA 오토스케일링)의 필요성을 데이터로 입증한 것이다. 실제로 11주차에 EKS·HPA로 CPU 임계값 초과 시 replicas가 3→5로 자동 증가하는 것을 확인한 바 있으며, 본 부하 결과는 그 오토스케일링 구조의 정당성을 뒷받침한다. 또한 캐시 히트 경로의 중앙값이 10.69ms로 측정되어, Redis 캐시 계층이 외부 API 의존성을 흡수한다는 설계 의도가 운영 환경에서도 유효함을 확인하였다.

2-3. 전체 시스템 아키텍처 다이어그램

iOS 앱·ESP32 BLE 단말부터 AWS 운영, CI/CD GitOps, 관측, 인프라 코드화까지 전 구간을 Mermaid 다이어그램 3종으로 작성하였다(docs/week16/architecture.md). (1) 런타임 서비스 아키텍처(사용자 → Route53 → ALB → EC2/RDS, Redis 캐시, 서울 TOPIS API), (2) CI/CD GitOps 파이프라인(push → GitHub Actions → ECR → ArgoCD → EKS), (3) 관측·IaC(Prometheus/Grafana/AlertManager, Terraform/Ansible)로 구성하여, 발표 슬라이드에 그대로 활용 가능하도록 하였다.

2-4. 운영 문서화

운영 매뉴얼(docs/week16/operations.md)에 배포 절차(GitOps 자동 배포 / 단일 EC2 수동 배포), 운영 상태 점검 명령(health·통계·DB 조회·EKS 파드·ArgoCD UI), 모니터링 구성, 장애 대응(롤백·파드 재시작), 비용 관리(EKS 시간당 약 $0.21, 미사용 시 terraform destroy)를 정리하였다. 아울러 라이브 검증용으로 클라우드 DB(RDS)의 최근 탑승 기록을 한국시간으로 출력하는 check-db.sh를 작성하여, 발표 시 iOS 앱의 배려석 알림이 실제로 클라우드에 저장되는 것을 즉석에서 보일 수 있게 하였다.

---

3. 프로젝트 주차 진행 결과

• CI/CD E2E 무인 자동화 실증: 코드 push에서 운영 EKS 반영까지 5분 21초(CI 2분 31초 + 매니페스트 갱신·ArgoCD 동기화·RollingUpdate 무중단 롤아웃)에 자동 완료. 새 SHA 이미지로 파드 2개 정상 교체.
• 클라우드 성능 실측: 7,196건 요청 처리, 중앙값 14ms, 캐시 히트 10.69ms로 Redis 효과 실증. 100 VU 동시성에서 단일 t2.micro 포화(p95 3.37s, 실패율 1.11%)를 확인하여 수평 확장의 필요성을 정량화.
• 문서화 완료: 전체 아키텍처 다이어그램 3종 + 운영 매뉴얼 + 라이브 검증 도구(check-db.sh).

---

4. 기타 (문제점, 해결방법, 자기평가)

4-1. 문제점 및 해결방법

ArgoCD가 이미지 변경을 자동으로 감지하지 못하는 문제가 있었다. eks-app 매니페스트가 backend 이미지를 :latest 고정 태그로 참조하고 있어, CI가 ECR에 새 이미지를 latest로 적재해도 매니페스트 자체는 변하지 않아 ArgoCD가 동기화를 트리거하지 않았기 때문이다. ArgoCD는 Git 매니페스트의 변경만 추적하고 이미지 digest 변경은 추적하지 않으므로, 매니페스트의 backend 이미지를 커밋 SHA(불변 태그)로 핀하여 push함으로써 Git 변경을 발생시켜 자동 동기화를 트리거하여 해결하였다. 이 방식은 현재 어떤 코드가 배포되어 있는지를 Git에서 추적할 수 있게 한다는 GitOps 이점도 함께 가진다.

부하 테스트가 외부 API 일일 한도를 소진할 위험이 있었다. k6가 /bus/arrivals를 대량 호출하면 캐시 미스 시 서울 TOPIS 외부 API를 호출하게 되는데, 11주차에 동일한 probe 누수로 한도가 소진된 경험이 있었기 때문이다. 부하의 85%를 외부 호출이 없는 /health/ready로 보내고, arrivals는 setup 단계에서 캐시를 미리 채운 뒤 15%만 섞어 외부 호출을 최소화함으로써 해결하였다.

k6가 종료 코드 99로 끝나 처음에는 테스트 실패로 보였다. 이는 실행 실패가 아니라 설정한 임계값(p95 500ms·실패율 1%)을 100 VU 구간에서 초과했음을 알리는 신호였기 때문이며, 실제로는 7,196건의 요청을 모두 완주한 정상 종료였다. 이를 단일 t2.micro의 처리 한계가 드러난 유의미한 측정 결과로 해석하고, 수평 확장의 필요성을 뒷받침하는 근거로 활용하였다.

4-2. 자기평가

16주차의 통합 검증은 그동안 개별적으로 구축한 구성 요소들이 실제로 하나의 자동화된 시스템으로 동작함을 시간과 수치로 증명했다는 점에서 의미가 크다. 코드 한 줄의 변경이 5분여 만에 운영 EKS에 무인 반영되는 과정을 구간별로 측정하였고, 운영 서버가 어느 부하 구간에서 한계에 도달하는지를 실측으로 확인하였다. 특히 부하 테스트에서 단일 t2.micro의 100 VU 포화 한계를 정량화한 것은, 11주차에 구현한 EKS·HPA 오토스케일링이 왜 필요한지를 데이터로 뒷받침한다는 점에서 그동안의 작업들이 하나의 일관된 서사로 연결됨을 체감하게 하였다.

16주 전체를 돌아보면, 리눅스 서버 관리(1주차)에서 시작하여 FastAPI 백엔드·Redis 캐싱·테스트 자동화·Docker 컨테이너화·AWS 클라우드 인프라·Terraform IaC(1

8주차), Kubernetes·Helm·Prometheus 모니터링(9

12주차), GitHub Actions·Jenkins CI·AWS 프로덕션 배포·ArgoCD GitOps·Ansible(13~15주차), 그리고 통합 검증·부하 테스트·문서화(16주차)에 이르기까지 현대 클라우드 네이티브 엔지니어링의 전 과정을 완주하였다. 최종적으로 https://comfortablemove.com이 상시 가동되며, 실기기와 ESP32 BLE를 통해 임산부 배려석 알림이 실제로 전달되고 클라우드에 기록되는 서비스를 완성하였다.

아쉬운 점과 향후 과제도 남는다. ArgoCD Image Updater를 도입하면 매니페스트의 이미지 태그 갱신까지 무인화할 수 있으나 이번에는 수동 단계로 남겨두었고, GitHub Webhook을 연동하면 폴링 없이 즉시 동기화가 가능하나 hard refresh로 트리거하여 검증하였다. 또한 EKS는 시간당 과금되므로 상시 운영보다는 실습·시연 후 terraform destroy로 정리하는 운용이 필요하다. 향후에는 (1) 실제 버스 탑승 환경에서의 End-to-End 시연 영상 확보, (2) ArgoCD Image Updater·Webhook 연동을 통한 완전 무인 배포, (3) AWS WAF 적용 및 RDS 인덱스 최적화 등 보안·성능 고도화, (4) EKS 비용 최적화(노드 스케일다운·스팟·On-Demand 클러스터 운용)를 프로젝트 종료 후 애프터 과제로 추진할 예정이다.

---

GitHub: https://github.com/ParkSeongGeun/dream_semester_2026_1