만들고자 하는 것과 사용하는 기술

• 웹 프로젝트를 Spring Cloud 마이크로서비스 아키텍처로 구현. (서버·게이트웨이·프런트엔드·배포·사용자 등 다섯 개의 서비스로 프로젝트가 구성되어 있습니다.)
  • 전역적으로 Spring Boot 3, Spring Cloud 2023 BOM, Validation/Web 스타터 등을 공통 의존성으로 사용하고, 서비스별로는 Eureka Server/Client, WebFlux, Thymeleaf 등을 채택해 역할에 맞는 기술 스택을 선언했습니다.
• Gradle 빌드, Docker Compose 배포, GitHub Actions 수동 트리거 페이지와 실행 스크립트가 함께 제공되어 CI/CD와 환경 자동화를 염두에 둔 구성을 갖추고 있습니다.

현재의 진척

• Eureka Server는 **@EnableEurekaServer**로 활성화된 부트스트랩 클래스와 자체 레지스트리 비활성화 설정을 갖추고 있어 서비스 디스커버리의 기반이 마련되었습니다.
• 게이트웨이·프런트엔드·배포·사용자 서비스는 모두 기본 SpringApplication.run(...) 엔트리포인트와 Eureka 클라이언트 접속 정보만 존재하며, 아직 컨트롤러나 비즈니스 로직은 구현되지 않은 초기 골격 단계입니다.
• Docker Compose 정의와 통합 실행 스크립트로 각 서비스 이미지를 빌드하고 일괄 기동할 수 있는 운영 흐름은 준비되어 있습니다.
• GitHub Actions를 수동 호출하는 정적 웹 페이지가 포함되어 있어 배포 파이프라인의 실험적 트리거 수단이 마련된 상태입니다.

어려운 점, 앞으로 어려울 것 같은 점

• 사용자·배포 등 각 도메인 서비스는 아직 부트스트랩 코드만 있으므로, 실질적인 API와 비즈니스 로직을 설계·구현하고 데이터 모델링까지 완성해야 하는 큰 과제가 남아 있습니다.
• WebFlux를 의존성으로 포함한 API Gateway에 라우팅 규칙이 비어 있어, 서비스별 라우팅·보안·Fallback 전략을 새로 정의해야 할 가능성이 큽니다.
• 프런트엔드는 Thymeleaf 기반으로 계획되었지만 현재 템플릿/컨트롤러가 없으므로 UI 제작과 백엔드 연동을 처음부터 구축해야 합니다.
• 통합 실행 스크립트가 특정 JDK 경로와 로컬 Docker 환경에 의존하므로, 팀별 개발 환경이나 CI 환경으로의 이식 시 설정 충돌과 자동화 실패가 발생할 수 있습니다.
• GitHub Actions 수동 트리거 페이지는 사용자 토큰 입력을 전제로 하므로, PAT 보관과 권한 관리 같은 보안 이슈를 해소할 방안이 필요합니다.

전체 개요

• 프로젝트는 settings.gradle로 다섯 개의 마이크로서비스(deploy, fe, gateway, server, user)를 포함하는 Gradle 멀티모듈 구조로 정의되어 있으며, 루트 **build.gradle**에서 모든 서브프로젝트에 공통 Spring Boot 3.3.5, Spring Cloud 2023.0.3 BOM, Java 17 툴체인, 웹·검증 스타터 등을 적용해 일관된 기반을 제공합니다.

서비스별 구성

• Eureka Server: server 모듈은 **@EnableEurekaServer**가 선언된 부트 애플리케이션과, 자기 자신을 레지스트리에 등록하지 않도록 한 설정으로 서비스 디스커버리를 담당합니다.