본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.

2026년 05월 20일. 오늘을 기점으로 6개월간의 구름 부트캠프를 수료하게 되었다.

깃허브 주소 : https://github.com/Goorm4I/pposiraegi-ecommerce
회의록 노션 주소 : https://www.notion.so/goormkdx/Four-I-2fec0ff4ce3180838568e13dbd3f8bac

뽀시래기 프로젝트란?

뽀시래기는 반려동물 용품을 타임딜(시간 한정 특가) 방식으로 판매하는 이커머스 플랫폼이다.
타임딜 특성상 특정 시간대에 트래픽이 폭발적으로 몰리고, 재고가 초과 판매되지 않도록 정확하게 제어해야 한다.
이런 요구사항 때문에 단순한 웹 서비스가 아니라, 클라우드 네이티브 인프라 위에서 운영되는 서비스로 설계했다.

팀명은 포아이팀이고, 이나형(팀장/인프라), 박지훈(인프라/프론트엔드), 서주원(Git관리/백엔드) 3명으로 구성되었다.
프로젝트는 총 3개 Phase로 나뉘어 진행되었으며, 이 글은 최종 단계인 Phase 3 (EKS v3.5) 를 중심으로 한 회고이다.

뽀시래기의 역사 — ECS에서 EKS까지

Phase 1 · 2 — ECS Fargate 기반 MSA

처음에는 AWS ECS Fargate 위에 MSA(마이크로서비스 아키텍처) 구조로 서비스를 구축했다.
api-gateway, user-service, order-service, product-service 4개의 서비스를 각각 컨테이너로 분리하고,
RDS PostgreSQL과 ElastiCache Redis를 데이터 레이어로 사용했다.

ECS는 관리 오버헤드가 적고 빠르게 구축할 수 있다는 장점이 있었지만,
운영을 하면서 다음과 같은 한계에 부딪혔다.

• 트래픽 제어의 한계 — 타임딜처럼 특정 서비스에 트래픽이 몰릴 때 서비스 간 세밀한 라우팅이나 서킷브레이킹이 ECS로는 어려웠다.
• 수동 작업 잔존 — 인프라 변경 시 콘솔에서 직접 수정해야 하는 부분이 남아있었다.
• 모니터링 한계 — CloudWatch 수준으로는 Pod·Node 단위의 세밀한 지표 수집이 불가능했다.

Phase 3 — EKS로의 전환

이러한 한계를 극복하기 위해 Phase 3에서는 Amazon EKS(Elastic Kubernetes Service) 로 전환을 결정했다.
ECS보다 복잡도는 높지만, IAM·네트워크·스토리지·배포·관측성의 경계를 명확히 컨트롤할 수 있다는 점이 핵심이었다.

단순히 EKS를 띄우는 것이 목표가 아니었다.
각 도구가 맡는 책임 경계를 명확히 정리하고, 재현 가능한 운영 흐름을 만드는 것이 이번 Phase 3의 진짜 목표였다.

Phase 3 기술 스택 — 무엇을, 왜 썼나

Terraform — 인프라 전체를 코드로

VPC, EKS 클러스터, RDS, ElastiCache, ALB, IAM, IRSA까지 모든 AWS 인프라를 Terraform으로 코드화했다.
코드로 관리하면 팀원 누구든 동일한 순서로 실행하면 동일한 인프라를 재현할 수 있고,
변경 이력도 Git에 남아 언제 무엇이 바뀌었는지 추적할 수 있다.

Bootstrap Script — 플랫폼 컴포넌트 1회 설치 자동화

Terraform이 AWS 리소스를 만들고 나면, EKS 위에 올라가는 플랫폼 컴포넌트들을 설치해야 한다.
이를 위해 bootstrap-platform.sh 쉘 스크립트를 직접 작성했다.
metrics-server → ArgoCD → Karpenter → AWS LBC → Istio → Prometheus+Grafana → ESO 순서로
한 번의 실행으로 전체 플랫폼을 구성할 수 있도록 자동화했다.
--only monitoring, --from eso 같은 옵션으로 특정 단계만 재실행하는 것도 가능하다.

GitHub Actions + ArgoCD — GitOps CI/CD

GitHub Actions는 CI를 담당한다. main 브랜치에 코드가 push되면 자동으로 Docker 이미지를 빌드하고 ECR에 push한다.
이때 이미지 태그는 latest 대신 Git commit SHA를 사용한다. 어떤 코드가 배포됐는지 정확히 추적하고, 문제가 생기면 이전 SHA 태그로 즉시 롤백할 수 있기 때문이다.

ArgoCD는 CD를 담당한다. infrastructure/kubernetes/ 폴더를 지속적으로 감시하다가
변경이 감지되면 자동으로 EKS 클러스터에 sync한다. 이것이 GitOps 방식이다.
Git이 단일 진실의 원천(Single Source of Truth)이 되어, 배포 상태가 항상 코드와 일치한다.

Karpenter — 워크로드 특성별 노드 프로비저닝

Karpenter를 단순히 "비용 절감 도구"로 보면 안 된다.
워크로드 특성에 맞는 노드 프로비저닝 정책을 실행하는 운영 정책 실행기가 더 정확한 표현이다.

• 모니터링 스택(Prometheus, Grafana, Loki) → On-Demand 고정. 안정성이 중요해서 Spot이 적합하지 않다.
• 앱 워크로드(api-gateway, order-service 등) → Karpenter 탄력 확장. 타임딜 트래픽 폭증 시 Spot + On-Demand 자동 혼합으로 대응한다.

Istio Ambient — 서비스 메시

서비스 간 통신에 mTLS 암호화를 적용하고, Waypoint + AuthorizationPolicy로 접근 제어를 구현했다.
/actuator/prometheus 같은 내부 엔드포인트를 외부에서 직접 접근하지 못하도록 경계를 만들었다.

Prometheus + Grafana + Loki + Tempo — 완전한 Observability

모니터링은 "설치했다"가 아니라 실제 병목을 찾기 위해 사용했다.

• Prometheus — Pod/Node 단위 메트릭 수집. Spring Boot actuator /actuator/prometheus 엔드포인트 스크래핑
• Grafana — JVM, Kubernetes 클러스터, Karpenter 대시보드 통합 시각화
• Loki — 서비스 로그 수집 및 검색 (S3에 IRSA로 저장)
• Tempo + OTEL Collector — 분산 트레이싱. 서비스 간 지연 구간 추적
• Alertmanager → Discord — 이상 징후 발생 시 Discord 웹훅으로 즉시 알림

실제로 k6 부하 테스트(300 VU, 30초)를 통해 order-service의 HikariCP 커넥션 풀이 병목임을 발견했고,
maximum-pool-size를 10 → 30으로 조정해서 평균 응답시간을 4.15초 → 1.69초로 59% 개선했다.

해당 내용은 링크에서 확인해볼 수 있다.

ESO + AWS SSM — Secret 자동 관리

External Secrets Operator(ESO) 를 통해 AWS SSM Parameter Store에 저장된 DB 비밀번호, JWT Secret 등을
Kubernetes Secret으로 자동 주입한다. 민감한 정보를 Git에 올리지 않고도 안전하게 관리할 수 있다.

이런식으로 깃허브 settings에서 관리하고 있다.

IRSA — Pod 단위 최소 권한 보안

기존에는 노드 전체에 IAM 권한을 부여했지만, IRSA(IAM Roles for Service Accounts) 를 도입해
Pod 단위로 필요한 권한만 부여하도록 바꿨다. Loki가 S3에 접근하거나 ESO가 SSM에 접근할 때도
각각의 Service Account에 딱 필요한 권한만 가진 IAM Role을 연결했다.

뽀시래기 프로젝트 소개

뽀시래기 메인페이지, 제품 페이지

뽀시래기는 다음과 같이 반려동물을 파는 이커머스 플랫폼이다.
원래 금액과 할인된 금액을 찾아볼 수 있고, 남는시간과 남은 재고를 한눈에 살펴볼 수 있다.

그런다음, 상품을 누르면 상세페이지로 들어갈 수 있는데 밑으로 스크롤을 내리면 인기 있는 다른 제품을 구매할 수 있게 된다.

회원가입 & 로그인 화면

이렇게 회원가입을 할 수 있게 되고, 로그인을 통해 서비스를 이용할 수 있다.
그러나 물품을 구매하기 위해서는 배송지를 등록을 먼저 해야한다.

다음과 같이 마이페이지를 클릭하게 되면 배송지관리, 전화번호 관리 등 기본적인 설정을 할 수 있게되고 구매한 물품들의 목록을 확인할 수도 있다.

찜 기능

다음과 같이 찜을 하게 되면 상단에 하트를 눌러 어느 제품들을 찜했는지도 살펴볼 수 있다.

관리자 페이지 구현

관리자로 로그인하게 되면 상단과 하단에서 관리자 버튼과 모니터링 버튼이 생긴다.

관리자같은 경우에는 현재 진행중인 딜을 수정하거나 새로운 딜을 만들 수 있다.

또한 모니터링 버튼을 눌러 현재 서비스별 리소스가 어떻게 동작하는지 확인할 수 있다.

후기

6개월동안, 거의 7개월이 되는 기간동안 구름과 kt에 지원을 받아서 인프런 무료수강을 하면서 팀원들과 스터디를 매일매일 하면서 kubernetes, docker에 대한 트러블슈팅하던 것이 며칠 전 같은데 벌써 하나의 프로젝트를 완성하면서 우수상까지 받으며 수료할 수 있어서 감회가 깊게 느껴졌다.

짧지 않은 기간이었지만 6개월동안 몰입할 수 있는 환경덕에 1년 이상의 성장을 이룰 수 있었다고 생각이 들며 퇴사를 하면서 이 부트캠프를 선택했던 내 선택에 후회하지 않는다고 자신할 수 있다.
주변에 인프라나 클라우드에 관심이 있는 후배가 있다면 당당하게 이 구름의 클라우드 네이티브 부트캠프를 추천하고 싶다.