Week 24
기간: 2026.04.27 - 2026.05.01
커리큘럼: 최종 프로젝트 (HR 인사시스템 SaaS 플랫폼) - AWS EKS 기반 운영 배포 및 인프라 안정화
1. Facts — 무엇을 했나?
이번 주는 개발이 완료된 기능들을 실제 운영 가능한 환경으로 배포하고, 서비스 간 연결 구조를 안정화하는 작업에 집중했다.
Docker 기반 컨테이너 이미지를 구성하고 GitHub Actions를 통해 CI/CD 파이프라인을 구축했다. 이후 AWS EKS 환경에서 Gateway·도메인 서비스·AI 서비스들을 Kubernetes 기반으로 배포했으며, ECR 이미지 관리와 Service DNS 기반 내부 통신 구조를 정리했다.
또한 readiness/liveness probe, RollingUpdate, HPA 설정을 통해 무중단 배포와 기본적인 운영 안정성을 확보했고, 운영 환경에서는 Eureka를 제거하고 Kubernetes Service DNS 기반으로 서비스 탐색 구조를 변경했다.
Redis, Kafka, n8n, Elasticsearch, RDS 등의 런타임 의존성도 Kubernetes Secret 및 환경변수 기반으로 분리해 운영 환경 구성을 정리했다.
2. Feelings — 어떻게 느꼈나?
-
로컬에서 기능이 잘 동작한다고 해서 서비스가 끝난 게 아니라는 걸 크게 느꼈다. 실제 운영 환경에서는 코드보다 "어떻게 연결되고 배포되는가"가 더 중요했다.
-
특히 운영 환경에서는 localhost 개념이 사라진다는 점이 가장 크게 체감됐다. 로컬에서는 자연스럽게 되던 연결들이 Kubernetes 환경에서는 Service DNS와 네트워크 구조를 제대로 이해하지 못하면 바로 깨졌다.
-
readiness probe 하나만 잘못 설정해도 Pod가 계속 재시작되거나 트래픽을 받지 못하는 상황을 겪으면서, 운영 환경에서는 "정상 동작"의 기준 자체가 다르다는 걸 배웠다.
-
배포 자동화를 구축하면서 처음에는 단순히 "배포를 편하게 만드는 작업"이라고 생각했지만, 실제로는 누가 배포하더라도 같은 결과를 보장하는 재현성 확보 작업이라는 걸 느꼈다.
3. Findings — 무엇을 배웠나?
-
운영 환경에서는 서비스 탐색 구조 자체가 달라진다. 로컬 환경에서는 Eureka 기반 discovery가 자연스럽지만, Kubernetes에서는 Service DNS와 Pod 네트워크 구조를 이해해야 안정적인 통신이 가능하다.
-
무중단 배포는 단순히 서버를 여러 대 띄우는 문제가 아니다. readiness probe와 RollingUpdate 설정이 제대로 동작해야 트래픽이 정상적으로 분산되고 장애 전파를 줄일 수 있다.
-
CI/CD의 핵심은 자동화보다 일관성이다. Docker 이미지 빌드, ECR Push, kubectl apply 흐름을 표준화하면서 운영 환경에서의 실수 가능성을 줄일 수 있었다.
-
운영 환경에서는 설정도 코드만큼 중요하다. 환경변수, Secret, profile 분리, 내부 DNS, 외부 진입 구조까지 포함해 전체를 하나의 시스템으로 봐야 했다.
4. Future — 다음에 어떻게 활용할까?
-
현재는 기본적인 HPA와 RollingUpdate만 적용했지만, 이후에는 실제 트래픽 기준의 autoscaling 전략과 모니터링 체계를 추가해 운영 안정성을 더 강화하고 싶다.
-
배포 구조를 구성하며 배운 "서비스는 코드만으로 운영되지 않는다"는 관점을 앞으로 모든 프로젝트의 기본 전제로 가져가려고 한다.
-
이후에는 로그 수집과 모니터링, 장애 추적 구조까지 포함해 실제 운영 관점의 DevOps 흐름도 함께 학습할 예정이다.
🧩 마무리 한 줄
"서비스를 만드는 것과 운영 가능한 상태로 만드는 것은 완전히 다른 문제였다 — 배포 이후부터가 진짜 시스템 설계의 시작이었다."
