Spring Cloud MSA 골격 형성
`api-gateway`, `auth`, `service-discovery`, `config`, `config-file-repository`가 거의 동시에 만들어지며 Gateway, Eureka, Config Server 중심의 MSA 초안이 잡힙니다.
- api-gateway
- service-discovery(Eureka)
- Spring Cloud Config
- central YAML repository
조직의 저장소와 infrastructure manifest 이력을 기준으로, Liberty52가 Spring Cloud MSA 초안에서 Kubernetes/GitOps 운영 구조와 백엔드 멀티모듈 구조로 이동한 흐름을 시간순으로 정리했습니다.
`api-gateway`, `auth`, `service-discovery`, `config`, `config-file-repository`가 거의 동시에 만들어지며 Gateway, Eureka, Config Server 중심의 MSA 초안이 잡힙니다.
`front-end`, `Liberty52-BE`, `admin-page`, `admin`이 추가되며 사용자 화면, 상품 도메인, 관리자 도메인이 분리됩니다. 이 시점에는 도메인별 API와 화면이 빠르게 늘어납니다.
각 서비스가 GHCR 이미지로 빌드되고, GitHub Actions가 원격 서버에 SSH 접속해 `docker pull`과 `docker run`을 수행합니다. 배포 자동화는 되었지만 운영 단위는 여전히 VM 중심입니다.
`infrastructure` 레포가 생기고, 앱 배포 단위가 Kubernetes Deployment, Service, Ingress manifest로 이동합니다. 이후 앱 repo의 CD는 manifest image tag를 갱신하고 Argo CD가 적용하는 구조가 됩니다.
infra 레포는 앱 manifest만 저장하지 않습니다. EKS 생성 스크립트, Nginx Ingress Controller, GHCR pull secret, Redis, Istio/Grafana/Jaeger/Kiali, Kubernetes Dashboard, SonarQube/Postgres, deprecated 워크로드까지 포함합니다.
config repo에서 Eureka 설정이 제거되고, gateway 라우팅은 `auth-server`, `product-server`, `config-server` 같은 Kubernetes Service 주소를 직접 사용합니다. 서비스 탐색 책임이 애플리케이션 레벨에서 클러스터 레벨로 내려갑니다.
`Liberty52-BE`가 `liberty52-main-service`, `liberty52-auth-service`, `liberty52-common`, `liberty52-authentication-library`를 포함하는 멀티모듈 구조로 정리됩니다. 배포 단위는 분리되지만, 공통 코드와 서비스 구조는 한 repo 안에서 조율됩니다.