[회고] 0부터 서비스 배포까지, 8주간 만든 것들: 구름 PROPECT 프로펙트 클라우드 엔지니어링 과정

2025년 10월 14일(화)에 개강해 2025년 12월 12일(금)에 수료한
구름 프로펙트(PROPECT) 클라우드 엔지니어링 과정에 대해 아주 개인적인 회고를 작성해보려고 한다!
 
과정 정보나 추천 여부가 궁금하다면 글 맨 마지막만 읽어도 충분하고,
중간 내용은 그냥 ‘한 사람의 기록’ 정도로 봐주면 좋겠다 🙂
 

수료식

GRADUATION !

---

📍 프로펙트 지원 과정

그때 나는 ..  당시 상황

새싹 용산캠퍼스에서 클라우드 엔지니어 과정을 수강하고 있었다. 3.5개월 과정에서 네트워크, 리눅스, 도커, 쿠버네티스를 배우고 약 3주간 팀 프로젝트를 진행했다. 기획과 발표 준비 시간을 제외하면 실제 인프라 프로젝트는 약 2주. 짧은 시간이었지만 인프라의 기초를 다질 수 있었다.
 
하지만 내가 담당한 인프라 프로젝트 경험으로는 좋은 회사에 취업하기 어려울 것 같았다.
 
그리고 내 개인적인 감으로 .. 지금이 딱 더 공부하기 좋은 시기라는 느낌이 들었다.
 
지금 더 달리지 않으면 나중에 기회가 없을 것 같은 기분.
더 늦기 전에, 해가 바뀌기전에 깊게 공부해야 한다는 느낌.
조금만 더 공부하면 원하는 바에 도달할 수 있을 거라는 느낌.
 
나 스스로 일에 대한 자신감이 있어야 면접도 잘 보고, 취업하고 나서도 더 열심히 일할 수 있을 것 같았다.
 
프로펙트를 통해 내가 마주친 문제에 대해 팀원들이랑 얘기하고, 깊게 고민해 보는 시간을 가져보고 싶었다. 
 

결심하게 된 계기

프로펙트 광고를 보고, 지원할까 말까 고민했다.
카카오테크 부트캠프, 새싹을 포함하면 3번째 부트캠프여서 내가 너무 교육을 많이 듣는 건 아닐지, 이제 교육은 그만 듣고 취업 준비에 더 힘써야 하는 건 아닌지 방향성에 대해 고민했다. 아직 좀 더 공부해보고 싶다는 생각이 들었고, 집에서 혼자 하는 것보다는 같은 분야에 있는 사람들과 기술에 대해 이야기 나누고 같이 프로젝트를 진행하는 게 훨씬 빠르게 성장할 수 있는 환경이라고 판단했다.
 
지원할지 말지 대해 그 당시 동료들에게 고민 상담을 했는데, 취업 준비에 더 집중하는 게 좋지 않겠다는 말을 들었다. 마지막으로 내 대학 동기 절친에게 고민 상담을 했을 때, "너는 이미 답을 알고 있다"는 말을 들었다. 
그렇다 ! 나는 이미 이 과정을 통해 더 공부하고 싶은 마음이 가득했다. 20대 초의 나라면 남의 말을 듣기보단 내가 하고 싶은 대로 밀고 나갔을 텐데, 요즘 내가 원하는 대로 삶이 흘러가지 않으니까 내 선택에 의심을 했던 것 같다. 과연 내가 맞게 가고 있는 건지.
근데 친구 덕분에 정신이 들었다. 나는 이미 내가 가야할 길을 알고 있다. 
(내가 힘들때마다 도움을 주는 내 친구에게 이 글을 통해 감사 인사를 전하고 싶다 .. ❤️)
 
그리고 새싹에서 친하게 지내던 친구가 프로펙트 할 생각이 있다고 해서 더 관심이 생겼다. 정말 가깝게 지냈던 친구라 같이 하게 되면 너무 재미있을 것 같았다. 부트캠프는 심리적으로, 체력적으로 많이 힘든데 아는 사람이 한 명이라도 더 있으면 좋겠다고 생각했다. 
프로펙트 입과 후 운영진이 클라우드 과정 교육생을 랜덤으로 조를 배정했는데, 정말 신기하게도 이 친구랑 같은 조가 되었다. 운명적인 순간..ㅎㅎ
 

지원 과정

새싹 부트캠프가 끝나갈 때쯤 프로펙트 지원서를 작성했고, 면접 후 입과했다.
면접은 Zoom으로 30분 정도 진행되었는데, 나 포함 4명이서 같이 봐서 내가 답변한 시간은 10분도 안 되는 것 같다. 
 
면접 질문으로는 가장 의미 있었던 프로젝트와 그 이유, 그 프로젝트를 진행하면서 마주했던 트러블과 해결한 방식 등이었다.
나는 카카오테크 부트캠프에서 했던 프로젝트에 대해 이야기했다. 면접 때 말을 조리 있게 못 했다고 생각했는데, 다행히 합격했다. 
 
새싹 부트캠프를 10월 2일에 수료하고, 추석 연휴가 있었다. 연휴 기간 동안 프로젝트 정리하고, 기업에 지원서 쓰다 보니 시간이 금방 흘렀다. 거의 바로 새롭게 교육을 하나 더 듣게 되었다.
 
내 진짜 마지막 교육 !! 

---

1️⃣ 1차 프로젝트: 백엔드 개발 도전, 모놀리식 구조에서 서비스 분리

2025.10.14(화) ~ 2025.10.30(목) 

 
기존 부트캠프에서는 아이디어 회의만 거의 1주일씩 걸렸는데, 이번 프로젝트 과정에서는 e커머스라는 큰 주제를 먼저 정해주셔서 방향성을 잡기 좋았다. 1차, 2차, 3차 프로젝트 목표 가이드라인이 있어서 "어디까지 해야 하는가"라는 목표 지점을 정하는 데 도움이 되었다.
우리 팀은 쿠팡이츠를 타겟으로 한 "구름이츠" 배달 플랫폼 프로젝트를 진행하게 되었다. 

goormEats 마스코트 ☁️

 
1차 프로젝트는 백엔드 개발만 진행했다.
물론 그 이상으로 더 할 수도 있었겠지만, 우리 팀원들 중 백엔드 개발을 깊게 해 본 적 있는 사람이 없다는 점을 고려해 ERD 설계, API 명세서 설계, 기능 개발 위주로 진행되었다.

단일 레포지토리
├── user-service/
├── store-service/
├── order-service/
├── payment-service/
└── review-service/ (내가 담당)

 
내가 백엔드 개발을 할 수 있을까 걱정이 정말 많이 되었다. 아무리 AI가 발달했다고 해도 원래 알고 있던 사람이 AI를 활용할 때 그 진가를 발휘하는 거지 아무것도 모르는 사람이 처음부터 하기엔 무리가 있다고 생각했다. 그래서 스트레스를 정말 정말 많이 받았다.
 
개발 과정에서는 생성형 AI를 적극적으로 활용했다. 그리고 프론트엔드 개발 경험이 있는 팀원, JAVA를 조금 다뤄보신 팀원에게도 계속 물어보면서 진행했다.
 
다행히 내가 REST API에 대한 이해는 있어서 AI를 사용해 큰 구조를 먼저 잡고 세세한 오류를 잡아가는 방식으로 진행했고, 기능 개발 이후에 JWT 토큰 인증 방식 도입하는 것도 무사히 개발했다!
 
강사님과의 개인 면담에서, “어떤 어노테이션을 사용했는가”라는 질문에 제대로 답하지 못했다.
그때 AI를 활용하더라도 내가 구현한 부분에 대해서는 잘 이해하고 설명할 수 있어야 하는 게 무엇보다 중요하구나 느꼈다. 
 
9시부터 6시까지 역삼 교육장에 있는 동안은 열심히 집중하려고 노력했다.
졸려도 참고! 커피와 함께!
 
1차 프로젝트에서 내가 맡은 reviewService 개발은 무사히 완료했다.
당시 면접 일정이 겹쳐서 정신이 없었고, 기한 안에 맡은 바를 못 끝낼까 봐 걱정했는데 다행이었다. 
 

• 1차 프로젝트 주요 작업:
  • 각 서비스 별 REST API 개발
  • JWT 토큰 인증 시스템 구현
  • ERD 설계 및 API 명세서 작성
• 나의 기여:
  • reviewService 구현
    • 리뷰 작성/조회/수정/삭제 API
    • 별점 계산 로직
    • 헤더 검증 -> JWT 토큰 검증으로 전환
    • Postman 테스트

---

2️⃣ 2차 프로젝트: ECS 기반 블루-그린 배포, 멀티 레포 구조로 분리

2025.10.31(금) ~ 2025.11.21(금)

 
CICD 분야에 관심이 생겼다. 미리 이 분야에 관심을 갖고 새싹 프로젝트 진행할 때 내가 주도적으로 맡아서 했으면 좋았을 텐데, 그 이후에 관심이 생겼다. 그래서 이번 프로펙트 프로젝트에서는 꼭 내가 CI/CD를 맡아서 해야겠다는 마음이었다.
다행히 나 말고 다른 팀원들은 CICD에 관심이 없어서 .. 내가 운 좋게 주도적으로 배포 파이프라인 구성을 맡게 되었다!
 
2차 프로젝트에서는 Github Actions를 사용했다. AWS ECR에 이미지를 업데이트하고 ECS에 배포했다.
 
Github Actions라는 걸 처음 사용해 봐서, 시작할 때는 그냥 다 어렵게 느껴졌다. 
일단 Dockerfile을 통해 앱을 컨테이너화 했고, Github Acitons CICD workflow YAML 파일을 작성했다. AI와 구글 검색을 통해 개념을 잡은 뒤 실제 프로젝트 레포에 적용해 봤는데 다행히 기본적인 배포 흐름을 구성하는 건 어렵지 않았다. 

GitHub Actions (CI/CD)
    ↓
AWS ECR (이미지 저장)
    ↓
ECS Fargate (컨테이너 실행)
    ↓
ALB (블루/그린 트래픽 분배)

 
 
구체적으로 우리 팀에서 원하는 CI, 그리고 CD 코드를 구성하는 과정에서 조금 어려움이 있었다.
 
먼저 CI의 역할이 정확이 무엇인지 이해하려고 했다. 
dev 브랜치에 merge 하기 전에 코드를 검사하는 과정이 필요했기 때문에 CI 단계에서 빌드 테스트, 단위 테스트, 코드 품질 검사를 진행했다. JaCoCo 테스트 커버리지 검사를 도입해서 dev에 머지하기 전(배포하기 전)에 검증을 충분히 거치려고 노력했다. 
 
2차 프로젝트에서는 ECS + Fargate 환경을 사용하고 있었고, 블루 그린 배포 전략을 적용하기로 했다. 그래서 CD 파일에서 활성화되고 있는 ECS Service를 감지하고, 새롭게 배포하는 코드를 작성했어야 했는데 그 과정이 Job안에 step으로 구성하기에는 너무 복잡하고 길었다. 결국 구현에는 성공했으나, 내 머릿속에 계속 이렇게 복잡하고 어렵게 배포를 해야 하나..?라는 의문이 들었다. 
 

• 2차 프로젝트 주요 작업:
  • AWS ECS 인프라 구축 (Terraform)
  • CI/CD 파이프라인 구축 (GitHub Actions)
  • 블루-그린 배포 구현
• 나의 기여:
  • ALB를 활용한 블루-그린 배포 구현
    • 무중단 배포
    • 각 백엔드 서비스 별 ALB Target Group 2개 구성
    • Blue/Green 두 환경을 ALB 가중치로 제어 -> 가중치 기반 트래픽 전환
    • 헬스체크 로직
    • 배포 후 5분 모니터링 로직
  • GitHub Actions 기반 CI/CD 파이프라인
    • CI/CD workflow YAML 파일 작성

---

3️⃣ 3차 프로젝트: 선언적 배포로의 전환, EKS + GitOps 아키텍처

2025.11.24(월) ~ 2025.12.11(목)

 
2차 프로젝트를 마무리할 때쯤, 내 머릿속에 한 가지 질문이 계속 맴돌았다.
배포라는 게 원래 이렇게까지 복잡해야 하는 걸까?
 
ECS 환경에서 블루-그린 배포를 구현하기 위해 작성한 Github Actiosn CD 코드는 실행 과정을 확인하기 위한 echo 구문을 포함해 550줄이 넘어갔다.
 
활성 서비스 감지부터 배포, 헬스체크, 트래픽 전환, 모니터링까지 모든 과정을 절차적으로 나열하다 보니 코드가 길어졌다. 수정에 어려움이 있었고 구조 자체를 바꿔서 해결해야겠다는 생각이 들었다.
 

ECS에서 EKS로, 그리고 GItOps로

최종 CICD 아키텍처

 
우리는 MSA 환경에 맞게, 여러 백엔드 서비스(컨테이너)를 더 유연하게 효율적으로 관리하기 위해 EKS 전환을 선택했다.
 
또 하나의 결정은 배포 방식이었다.
기존에는 Github Actions 하나가 CI와 CD를 모두 담당하고 있었지만,
CI와 Delivery는 Github Actions이, Deployment는 ArgoCD로 역할을 분리했다. 
 
어떻게 배포할 것인가 코드로 나열하는 대신,
최종 상태가 무엇인지 선언적으로 정의하고 그 상태를 맞추는 일은 ArgoCD에게 맡기는 구조로 전환했다.
 
선언적 배포로 전환한 이후 변화는 다음과 같다.
- github CD workflow 코드: 550줄 → 157줄 (약 71% 감소)
- 전체 배포 시간: 12분 → 4분 30초
- GitHub Actions CD 실행 시간: 6분 37초 → 1분 36초 (76% 단축)
 

GitOps 아키텍처 구성

GitOps 아키텍처를 구현하기 위해, k8s-manifests 레포지토리를 새로 만들었고, Helm Chart의 values.yaml을 기준으로 배포를 관리했다. 

"Git = Single Source of Truth"

 
블루-그린 배포 구현을 위해 Argo Rollout을 도입했고, Rollout manifest를 작성했다. 
AnalysisTemplate을 통해 Prometheus 메트릭 기반 자동 롤백 로직을 구현했다. 

• 에러율 5% 초과
• 레이턴시 1초 초과
  → 자동 롤백 트리거

[개발자] 
    ↓ push
[Service Repo] 
    ↓ GitHub Actions CI
[ECR] + [GitOps Repo values.yaml 업데이트]
    ↓ ArgoCD 감지 (3분 주기, 수동이면 즉시)
[EKS Cluster]
    ↓ Argo Rollouts
[블루-그린 배포]

 
수동 배포하면 명령어를 매번 치기도 귀찮고, 배포 설정을 일관되게 유지하기도 어려웠다. 관리적인 측면에서도 비효율적이었다.
 
GitOps를 도입하고 나서는 Git repo를 기준으로 중앙에서 배포 상태를 관리하는 게 용이해졌다. 코드 개발한 걸 PR 날리고 dev에 머지하면 바로 배포로 이어져 효율적이고 빠른 배포가 가능해졌고, 일관된 흐름을 만들 수 있었다.
 

• 3차 프로젝트 주요 작업:
  • EKS 클러스터 기반 컨테이너 오케스트레이션
  • Kafka 도입
  • ArgoCD + Argo Rollouts 도입
  • GitOps 레포지토리 구성
• 나의 기여:
  • GitOps 레포지토리 기반 배포 관리
    
    • k8s-manifests 레포지토리 신규 생성
    • values.yaml 기반 배포 관리 - 이미지 태그 명시
    • Helm Chart 구조 설계
    • Git commit = 배포 이력
  • ArgoCD를 통한 선언적 배포
    
    • Argo CD: 3분 주기 Auto-sync, 수동 Sync시 즉시 반영.
    • Argo Rollouts: 블루-그린 배포, 헬스 체크 후 수동 승인 -> 트래픽 전환
    • Rollout manifest 작성
    • 선언적 배포 전략 정의
  • AnalysisTemplate 작성 (Post 검증)
    • Prometheus 메트릭 기반 자동 롤백 로직
    • 에러율 5%, 레이턴시 1초 기준 설정

 
(※ 자세한 트러블슈팅 과정은 별도 포스팅에서 다루겠습니다!)
 

회의중!

---

📍회고

기술을 대하는 태도

프로펙트 과정을 통해 가장 크게 바뀐 건 기술 스택 그 자체보다 기술을 대하는 태도였다.
예전의 나는 "일단 돌아가게 만드는 것"에 집중했다면, 지금의 나는 "왜 이 선택을 했는지, 설명할 수 있는지"를 먼저 고민하게 되었다. 
 
무엇보다 인프라는 정답이 없다는 점에서, 각자의 상황에 맞게 최선의 선택을 하고 그 이유를 설명하는 과정이 중요하다는 것을 배웠다.
 
주어진 상황을 분석하고, 고민 끝에 선택하고, 그 선택에 대해 말고 설명하는 경험을 반복했다.
내가 한 일을 말로 설명할 수 있어야 비로소 내 것이 된다. 
 

협업에서 배운 것들 

팀 프로젝트를 진행하면서 팀원들에게 피해를 주지 않기 위해 어떻게든 맡은 역할을 마무리하려고 노력했다.

Git을 활용해 코드와 변경 사항을 공유하면서 협업 흐름을 유지할 수 있었다.
 
나도 잘 모르고, 팀원도 잘 모르는 개념에 대해서 어떤 선택을 내려야 할지 선택의 기로에 섰을 때 힘들었다. 
인프라 프로젝트 특성상 정답은 없고, 그 시점의 상황과 비용, 리스크를 고려해 최선의 선택을 내려야 하는 순간들이 반복되었다.
우리끼리 논의만으로 답이 나오지 않을 때는 답이 안 나올 때는 강사님께 질문을 드렸고 피드백을 받아 해결했다.
(더 일찍, 더 많이 질문하지 못한 점이 가장 아쉽다.)
 

부트캠프를 통해 얻은 것

이 과정을 통해 다음과 같은 기술적 경험을 쌓을 수 있었다.

• Java를 사용한 백엔드 서비스 구현
• Git 기반 사용한 협업
• CI/CD 파이프라인 설계 및 구축
• GitHub Actions 활용
• ArgoCD를 통한 GitOps 패턴 구현
• Kubernetes 기반 컨테이너 오케스트레이션

그리고 배포 자동화와 운영이 어떻게 연결되는지, 왜 이 구조가 필요했는지 설명할 수 있는 경험을 얻었다.
 
강사님께 질문을 더 많이 하지 못했던 점, 모니터링 영역을 좀 더 살펴보지 못한 부분은 아쉬움으로 남는다.
시간을 돌린다면! 더 많이 질문하고, 더 많이 기록하고 공유했을 것 같다. 
 
기술적으로 도움을 준 팀원들, 질문에 항상 구체적으로 답변해 주신 강사님께 감사드리고 싶다.
 

다음 단계 적용 계획

3차 프로젝트에서 기술적으로 아쉬웠던 부분은 팀원들과 개인적으로 4차 프로젝트를 통해 고도화해보려고 한다. 

• Istio를 활용한 Service Mesh 구현
  • 마이크로서비스 간 통신 관리 개선
  • 더 정교한 트래픽 제어 가능
• 카나리 배포(Canary Deployment) 구현
  • 현재 한계: Argo Rollouts로는 Pod 수에 따른 트래픽 분배만 가능
  • 개선 방향: Istio를 적용하면 세밀한 트래픽 분배 구현 가능 (예: 95% vs 5%) - 카나리 배포의 본질적인 목적
• Istio Ingress Gateway로 변경
  • 기존 Ingress Controller 대비 더 강력한 트래픽 관리 기능 활용

---

📍 PROPECT 클라우드 엔지니어링 과정, 그래서 어땠냐면?

• 진행 방식: 오프라인 중심 프로젝트
• 교육장 위치: 구름스퀘어 강남 (테헤란로 145 13층, 14층)
• 프로젝트 구성: 1차 / 2차/ 3차 단계별 프로젝트 진행

교육장은 역삼역 4번 출구 바로 앞 건물 13, 14층에 위치해 있어 접근성이 매우 좋았다.
통학 부담이 적어 매일 교육장에 오는 데 스트레스가 거의 없었고,
층수가 높아 뷰도 좋아서 답답함이 덜했다.
강의장도 깨끗하고 쾌적해서 프로젝트에 집중하기 좋은 환경이었다. 
 
강사님이 매일 아침 알고리즘 문제를 풀도록 하셔서, 자연스럽게 코딩테스트를 준비하는 습관을 만들 수 있었다.
 
12월에는 약 1주 반 정도 팀별로 주제를 정해 돌아가며 발표하는 시간을 가졌다.
나는 이 시간에 ArgoCD를 활용한 GitOps 배포 전략을 주제로 발표를 진행했는데, 내가 공부하고 적용했던 내용을 정리해 설명해 볼 수 있어 의미 있는 시간이었다.
 
프로펙트는 기술을 차근차근 알려주는 강의형 과정이라기보다, 정답 없는 문제 앞에 계속 서게 만드는 프로젝트 중심 과정이다.
자유도가 높은 만큼 파고들지 않으면 얻어가는 게 적을 수도 있고, 질문하지 않으면 그대로 지나갈 있는 환경이기도 하다.
하지만 그만큼 스스로 고민하고 선택한 경험은 오래 남는다!
 
이 과정은 처음 개발이나 인프라를 시작하는 사람보다는
이미 한 번쯤 프로젝트를 경험해 봤고, 그 경험을 더 깊게 발전시키고 싶은 사람에게 잘 맞을 것 같다. 
 
프로젝트 단계별 가이드라인이 있어, 아이디어 기획보다는 기술적 선택과 구조에 대한 고민에 집중할 수 있었고
정답 없는 인프라 기술 선택의 문제를 두고 팀원들과 계속 논의하며 성장할 수 있는 환경이었다.
 
그래서 누군가 "PROPECT 클라우드 엔지니어링 과정 추천해?"라고 물어본다면
나는 망설임 없이 YES라고 답할 것 같다.
 

---

📍 에필로그

내가 하고 있는 일이 팀 프로젝트의 생산성을 높이고 있고, 시간과 노력 대비 효율을 개선하고 있다는 느낌이 들 때 뿌듯함을 느꼈다. 
 
백엔드 코드를 처음부터 직접 설계하고 구현하는 일은 아직 많이 어렵지만, 코드를 읽고 흐름을 이해하는 과정 자체는 꽤 재미있었다.
인프라 직무를 하더라도 결국 서비스의 중심에는 백엔드가 있다는 점에서 이 둘은 떼려야 뗄 수 없는 영역이라고 느꼈다.
 
그래서 인프라도 다루면서 코드 단까지 이해하는 DevOps 직무가 나에게 가장 잘 맞는 방향이라고 판단했고, 앞으로 이 직무를 위해 계속 노력하고 싶다.
지금까지 했던 개발 프로젝트 중에서 제일 재미있었다!
 
프로펙트는 나에게 앞으로 어떤 기술을 만나더라도 왜 이 선택을 하는지 고민하게 만드는 습관을 만들어준 부트캠프였다.
하길 정말 잘했다!
 
마지막으로, 두 달 동안 오프라인으로 출석하며 버텨낸 나에게 고생 많았다고 말해주고 싶다! 🥹
 

🎄☃️❄️