스프링 클라우드 완벽 입문 가이드

MSA 아키텍처의 필수 도구인 스프링 클라우드를 초급 개발자도 이해할 수 있도록 쉽게 설명합니다. Netflix OSS와의 차이점, 주요 컴포넌트, 버전 호환성까지 실무에 필요한 모든 내용을 담았습니다.

1. 스프링 클라우드란

어느 날 김개발 씨는 회사에서 새로운 프로젝트 킥오프 미팅에 참석했습니다. "이번 프로젝트는 MSA로 진행합니다.

스프링 클라우드를 사용할 예정이에요." 팀장님의 말에 김개발 씨는 고개를 끄덕였지만 속으로는 걱정이 앞섰습니다. 스프링은 알겠는데, 스프링 클라우드는 뭘까요?

스프링 클라우드는 MSA 아키텍처를 구축할 때 필요한 다양한 기능을 제공하는 프레임워크입니다. 마치 레고 블록을 조립하듯이 서비스 디스커버리, API 게이트웨이, 설정 관리 등의 컴포넌트를 쉽게 조합할 수 있습니다.

스프링 부트 기반으로 작동하기 때문에 친숙한 방식으로 분산 시스템을 개발할 수 있습니다.

다음 코드를 살펴봅시다.

// 스프링 클라우드를 사용한 간단한 서비스 구성
@SpringBootApplication
@EnableDiscoveryClient  // 서비스 디스커버리 활성화
public class UserServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }

    @RestController
    class UserController {
        // 다른 마이크로서비스 호출을 위한 클라이언트
        @Autowired
        private RestTemplate restTemplate;

        @GetMapping("/users/{id}/orders")
        public String getUserOrders(@PathVariable String id) {
            // 서비스 이름으로 호출 - IP 주소를 몰라도 됩니다
            return restTemplate.getForObject(
                "http://order-service/orders/user/" + id,
                String.class
            );
        }
    }
}

김개발 씨는 퇴근 후 집에 돌아와 노트북을 켰습니다. "스프링 클라우드가 뭔지 제대로 알아봐야겠어." 검색을 시작했지만 어려운 용어들이 가득했습니다.

다음 날 출근하자마자 선배 개발자 박시니어 씨를 찾아갔습니다. "선배님, 스프링 클라우드가 정확히 뭔가요?" 박시니어 씨는 커피를 한 모금 마시고는 천천히 설명을 시작했습니다.

쉽게 비유하자면 "스프링 클라우드는 마치 아파트 단지 관리 시스템과 같아요." 박시니어 씨가 말했습니다. "일반 주택은 모든 것을 스스로 관리해야 하지만, 아파트 단지에는 관리 시스템이 있죠.

경비실에서 방문객을 안내하고, 관리사무소에서 각 동의 상태를 파악하고, 공지사항을 전달합니다." 스프링 클라우드도 마찬가지입니다. 여러 개의 작은 서비스들이 모여 하나의 큰 시스템을 이룰 때, 이들을 관리하고 연결해주는 역할을 합니다.

각 서비스가 어디에 있는지 찾아주고, 서비스 간 통신을 도와주고, 설정 정보를 중앙에서 관리합니다. 모놀리식에서 MSA로 예전에는 하나의 거대한 애플리케이션을 만들었습니다.

사용자 관리, 주문 처리, 결제, 배송 추적 등 모든 기능이 하나의 프로젝트에 들어있었습니다. 이런 방식을 모놀리식 아키텍처라고 부릅니다.

김개발 씨도 학교 프로젝트에서 이런 방식으로 개발해봤습니다. 처음에는 편했습니다.

모든 코드가 한곳에 있으니까요. 하지만 프로젝트가 커지면서 문제가 생기기 시작했습니다.

한 부분을 수정하면 다른 부분에서 버그가 발생했습니다. 배포할 때마다 전체 시스템을 재시작해야 했습니다.

MSA의 등장 이런 문제를 해결하기 위해 마이크로서비스 아키텍처가 등장했습니다. 거대한 애플리케이션을 작은 서비스 단위로 쪼개는 방식입니다.

사용자 서비스, 주문 서비스, 결제 서비스처럼 각자의 역할을 가진 독립적인 서비스들로 나눕니다. 하지만 새로운 문제가 생겼습니다.

"이 많은 서비스들을 어떻게 관리하지?" 서비스가 10개, 20개로 늘어나면 각 서비스의 위치를 어떻게 알 수 있을까요? 서비스 간 통신은 어떻게 처리할까요?

설정 파일은 어떻게 관리할까요? 스프링 클라우드의 등장 바로 여기서 스프링 클라우드가 등장합니다.

스프링 클라우드는 MSA를 구축할 때 필요한 모든 도구를 제공합니다. 첫째, 서비스 디스커버리가 있습니다.

각 서비스가 시작될 때 자신의 위치를 등록하면, 다른 서비스들이 이름만으로 찾을 수 있습니다. IP 주소나 포트 번호를 외울 필요가 없습니다.

둘째, API 게이트웨이가 있습니다. 클라이언트는 하나의 진입점을 통해 모든 서비스에 접근할 수 있습니다.

마치 아파트 단지의 정문과 같습니다. 셋째, 설정 관리 서버가 있습니다.

모든 서비스의 설정을 중앙에서 관리할 수 있습니다. 설정을 변경하면 서비스를 재시작하지 않아도 반영됩니다.

코드 살펴보기 위의 코드를 봅시다. @EnableDiscoveryClient 어노테이션 하나만 추가하면 이 서비스가 자동으로 서비스 디스커버리에 등록됩니다.

그리고 RestTemplate을 사용할 때 서비스 이름(order-service)만 적으면 됩니다. IP 주소를 하드코딩할 필요가 없습니다.

만약 주문 서비스가 3대의 서버에서 실행되고 있다면, 스프링 클라우드가 자동으로 로드 밸런싱을 해줍니다. 요청을 골고루 분산시켜서 특정 서버에 부하가 몰리지 않게 합니다.

실무에서의 활용 박시니어 씨는 실제 경험을 들려줬습니다. "우리 회사 쇼핑몰은 30개 이상의 마이크로서비스로 구성되어 있어요.

스프링 클라우드가 없었다면 관리가 불가능했을 거예요." 예를 들어 블랙프라이데이 같은 행사 기간에는 주문 서비스만 서버를 늘립니다. 다른 서비스는 그대로 두고요.

스프링 클라우드가 새로 추가된 서버를 자동으로 인식하고 트래픽을 분산시킵니다. 스프링 부트와의 관계 "그런데 스프링 부트랑은 뭐가 다른 건가요?" 김개발 씨가 물었습니다.

"좋은 질문이에요. 스프링 부트는 단일 애플리케이션을 빠르게 개발하기 위한 도구입니다.

반면 스프링 클라우드는 여러 개의 스프링 부트 애플리케이션을 연결하고 관리하는 도구예요. 스프링 클라우드는 스프링 부트 위에서 동작합니다." 즉, 스프링 부트로 각각의 마이크로서비스를 만들고, 스프링 클라우드로 이들을 연결하는 것입니다.

시작하기 김개발 씨는 이제 조금 감이 잡혔습니다. "그럼 제가 당장 배워야 할 건 뭔가요?" 박시니어 씨가 웃으며 대답했습니다.

"먼저 유레카(서비스 디스커버리)와 게이트웨이부터 시작해보세요. 이 두 가지만 이해해도 MSA의 기본은 알 수 있어요." 스프링 클라우드는 어렵지 않습니다.

스프링 부트를 사용해봤다면 익숙한 방식으로 시작할 수 있습니다. 어노테이션 몇 개만 추가하면 강력한 분산 시스템을 구축할 수 있습니다.

실전 팁

💡 - 스프링 클라우드는 스프링 부트 기반이므로 스프링 부트를 먼저 학습하세요

처음에는 유레카(서비스 디스커버리)와 게이트웨이부터 시작하는 것이 좋습니다
로컬 환경에서 여러 서비스를 띄워보며 실습하면 이해가 빠릅니다

2. 스프링 클라우드 2025 버전

점심시간에 김개발 씨는 스프링 클라우드 공식 문서를 읽고 있었습니다. 그런데 버전이 너무 많았습니다.

2023.0.0, 2024.0.0... 숫자도 이상했습니다.

"왜 3.0, 4.0이 아니라 연도를 쓰는 거지?" 박시니어 씨에게 다시 물어봤습니다.

스프링 클라우드는 연도 기반 버전 체계를 사용합니다. 2025.0.0처럼 출시 연도를 버전 번호로 사용하는 방식입니다.

이는 여러 개의 서브 프로젝트로 구성되어 있기 때문이며, 각 프로젝트의 버전을 통합 관리하기 위함입니다. 2025년 기준 최신 버전은 2024.0.x 시리즈이며, 이전 2023.0.x와 2022.0.x도 여전히 지원됩니다.

다음 코드를 살펴봅시다.

// pom.xml - 스프링 클라우드 버전 설정
<properties>
    <java.version>17</java.version>
    <!-- 스프링 부트 버전 -->
    <spring-boot.version>3.2.0</spring-boot.version>
    <!-- 스프링 클라우드 버전 (연도 기반) -->
    <spring-cloud.version>2024.0.0</spring-cloud.version>
</properties>

<dependencyManagement>
    <dependencies>
        <!-- 스프링 클라우드 BOM (Bill of Materials) -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

"스프링 클라우드는 특별한 버전 체계를 사용해요." 박시니어 씨가 설명을 시작했습니다. "일반적인 라이브러리처럼 1.0, 2.0이 아니라 연도를 사용하죠." 왜 연도를 사용할까 김개발 씨는 고개를 갸우뚱했습니다.

"왜 그렇게 하는 거예요?" "스프링 클라우드는 사실 하나의 라이브러리가 아니에요. 여러 개의 서브 프로젝트로 구성되어 있습니다." 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다.

스프링 클라우드 안에는 많은 컴포넌트가 있습니다. 스프링 클라우드 게이트웨이, 스프링 클라우드 컨피그, 스프링 클라우드 로드밸런서, 스프링 클라우드 서킷 브레이커 등등.

각 컴포넌트는 독립적으로 개발되고 있고, 각자의 버전을 가지고 있습니다. 예를 들어 게이트웨이는 4.1.0이고, 컨피그는 4.0.5일 수 있습니다.

개발자가 이 모든 버전을 외우고 조합해야 한다면 얼마나 복잡할까요? 릴리즈 트레인 "그래서 스프링 팀은 릴리즈 트레인이라는 개념을 도입했어요." 박시니어 씨가 계속 설명했습니다.

"기차가 정해진 시간에 출발하듯이, 1년에 한 번 모든 컴포넌트의 호환되는 버전을 묶어서 릴리즈하는 거죠." 2024년에 릴리즈한 버전은 2024.0.0입니다. 이 버전을 선택하면 게이트웨이, 컨피그, 로드밸런서 등 모든 컴포넌트의 호환되는 버전이 자동으로 결정됩니다.

개발자는 버전 호환성을 걱정할 필요가 없습니다. 2025년 현재 버전 "그럼 지금은 어떤 버전을 써야 하나요?" 김개발 씨가 물었습니다.

"2025년 1월 기준으로 2024.0.x가 최신 안정 버전이에요. 2024년 12월에 정식 출시되었죠." 박시니어 씨가 대답했습니다.

"물론 이전 버전인 2023.0.x도 여전히 많이 사용되고 있어요. 우리 회사도 아직 2023.0.3을 쓰고 있고요." 스프링 클라우드는 보통 최신 버전과 그 이전 두 개 버전을 동시에 지원합니다.

즉, 2025년에는 2024.0.x, 2023.0.x, 2022.0.x가 모두 지원됩니다. 마이너 버전과 패치 버전 "2024.0.0 뒤에 붙는 숫자는 뭔가요?" 김개발 씨가 또 물었습니다.

"연도.마이너.패치 형식이에요." 박시니어 씨가 설명했습니다. "2024.0.0이 첫 릴리즈고, 버그 수정이나 작은 개선이 있으면 2024.0.1, 2024.0.2로 올라가요.

그리고 중요한 기능이 추가되면 2024.1.0이 됩니다." 일반적으로 패치 버전은 안전하게 업그레이드할 수 있습니다. 기존 코드를 수정할 필요가 없습니다.

하지만 마이너 버전이 올라가면 일부 API가 변경될 수 있으니 릴리즈 노트를 확인해야 합니다. BOM이란 위의 코드를 보면 spring-cloud-dependencies라는 의존성이 있습니다.

이것을 BOM(Bill of Materials)이라고 부릅니다. 마치 자재 명세서와 같습니다.

BOM을 추가하면 개별 컴포넌트의 버전을 명시하지 않아도 됩니다. 스프링 클라우드가 알아서 호환되는 버전을 선택해줍니다.

예를 들어 게이트웨이를 추가할 때 이렇게 작성합니다: xml <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId>  </dependency> 버전을 적지 않았지만 BOM이 2024.0.0 버전에 맞는 게이트웨이 버전을 자동으로 선택해줍니다. 실무 팁 박시니어 씨는 자신의 경험을 공유했습니다.

"실무에서는 무조건 최신 버전을 쓸 필요는 없어요. 안정성이 더 중요하거든요." 새 프로젝트를 시작한다면 최신 버전을 사용하는 것이 좋습니다.

하지만 기존 프로젝트를 업그레이드할 때는 신중해야 합니다. 마이너 버전 업그레이드는 충분한 테스트 후에 진행하고, 메이저 버전 변경(예: 2023.x에서 2024.x)은 더욱 신중하게 계획해야 합니다.

어떻게 선택할까 "제가 새 프로젝트를 시작한다면 어떤 버전을 써야 할까요?" 김개발 씨가 마지막 질문을 했습니다. 박시니어 씨가 웃으며 대답했습니다.

"2025년 1월 기준으로는 2024.0.0 이상을 추천해요. 다만 출시된 지 2-3개월 정도는 지난 버전이 안정적입니다.

2024.0.2 정도가 나왔다면 그걸 선택하는 게 좋아요." 또한 스프링 부트 버전과의 호환성도 확인해야 합니다. 2024.0.x는 스프링 부트 3.2 이상과 호환됩니다.

공식 문서의 호환성 표를 항상 확인하세요. 정리 김개발 씨는 이제 스프링 클라우드의 버전 체계를 이해했습니다.

연도 기반 버전을 사용하는 이유, BOM의 역할, 그리고 버전 선택 기준까지 배웠습니다.

실전 팁

💡 - BOM을 사용하면 개별 컴포넌트의 버전 관리가 자동화됩니다

실무에서는 최신 버전보다 안정성이 검증된 버전을 선택하세요
스프링 부트 버전과의 호환성을 반드시 확인하세요

3. 주요 컴포넌트 소개

회의실에서 아키텍처 세미나가 열렸습니다. 박시니어 씨가 발표를 시작했습니다.

"스프링 클라우드의 핵심 컴포넌트는 크게 다섯 가지입니다." 김개발 씨는 노트북을 열고 열심히 메모하기 시작했습니다. 각 컴포넌트가 어떤 역할을 하는지 제대로 알아야 실무에 적용할 수 있을 테니까요.

스프링 클라우드는 유레카(서비스 디스커버리), 게이트웨이(API 라우팅), 컨피그 서버(중앙 설정 관리), 서킷 브레이커(장애 격리), 로드 밸런서(부하 분산) 등 핵심 컴포넌트로 구성됩니다. 각 컴포넌트는 MSA 환경에서 특정 문제를 해결하기 위해 설계되었으며, 필요에 따라 선택적으로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// application.yml - 주요 컴포넌트 설정 예제
spring:
  application:
    name: user-service  # 서비스 이름
  cloud:
    # 컨피그 서버 연결
    config:
      uri: http://config-server:8888
      fail-fast: true
    # 서킷 브레이커 설정
    circuitbreaker:
      resilience4j:
        enabled: true
    # 로드 밸런서 설정
    loadbalancer:
      ribbon:
        enabled: false

eureka:
  client:
    service-url:
      defaultZone: http://eureka-server:8761/eureka/  # 유레카 서버 주소
  instance:
    prefer-ip-address: true

박시니어 씨는 화이트보드에 큰 그림을 그렸습니다. 중앙에 여러 개의 상자가 있고, 화살표로 연결되어 있었습니다.

"이게 우리 시스템의 전체 구조예요." 유레카 - 서비스를 찾는 안내원 "먼저 유레카(Eureka)부터 볼까요?" 박시니어 씨가 화이트보드의 중앙 상자를 가리켰습니다. 유레카는 마치 백화점의 안내 데스크와 같습니다.

"스포츠 용품은 몇 층에 있나요?"라고 물으면 "5층입니다"라고 알려주듯이, 유레카는 "주문 서비스는 어디 있나요?"라고 물으면 IP 주소와 포트를 알려줍니다. 각 마이크로서비스는 시작할 때 유레카에 자신을 등록합니다.

"저는 사용자 서비스이고, 192.168.1.10:8080에서 실행 중입니다." 이렇게 말이죠. 그리고 30초마다 "아직 살아있어요!"라고 하트비트를 보냅니다.

다른 서비스가 사용자 서비스를 호출하려면 유레카에게 물어봅니다. 유레카는 현재 실행 중인 사용자 서비스의 목록을 알려줍니다.

만약 3대의 서버에서 실행 중이라면 3개의 주소를 모두 알려줍니다. 게이트웨이 - 모든 요청의 관문 "다음은 스프링 클라우드 게이트웨이입니다." 박시니어 씨가 계속 설명했습니다.

게이트웨이는 아파트 단지의 정문과 같습니다. 외부에서 들어오는 모든 요청은 게이트웨이를 거쳐야 합니다.

게이트웨이는 요청을 보고 어느 서비스로 보낼지 결정합니다. 예를 들어 /users/로 시작하는 요청은 사용자 서비스로, /orders/로 시작하는 요청은 주문 서비스로 보냅니다.

이를 라우팅이라고 합니다. 또한 게이트웨이는 인증과 권한 검사도 수행합니다.

로그인하지 않은 사용자의 요청은 바로 거부할 수 있습니다. 각 마이크로서비스에서 중복으로 인증 로직을 작성할 필요가 없습니다.

컨피그 서버 - 설정의 중앙 창고 "세 번째는 스프링 클라우드 컨피그예요." 박시니어 씨가 말했습니다. 10개의 마이크로서비스가 있다고 상상해봅시다.

각 서비스는 application.yml 파일에 설정을 가지고 있습니다. 만약 데이터베이스 주소를 변경해야 한다면 어떻게 될까요?

10개 파일을 모두 수정하고 10개 서비스를 모두 재배포해야 합니다. 컨피그 서버는 이 문제를 해결합니다.

모든 설정을 중앙의 Git 저장소에 저장합니다. 각 서비스는 시작할 때 컨피그 서버에서 설정을 받아옵니다.

설정을 변경하면 서비스를 재시작하지 않고도 적용할 수 있습니다. 김개발 씨가 손을 들었습니다.

"그럼 컨피그 서버가 죽으면 어떻게 되나요?" "좋은 질문이에요. 그래서 보통 컨피그 서버를 이중화합니다.

그리고 각 서비스는 설정을 캐시해두기 때문에 일시적으로 컨피그 서버가 죽어도 동작할 수 있어요." 서킷 브레이커 - 장애의 전파를 막는 차단기 "네 번째는 서킷 브레이커입니다." 박시니어 씨의 목소리가 진지해졌습니다. "이건 정말 중요해요." 사용자 서비스가 주문 서비스를 호출한다고 가정해봅시다.

그런데 주문 서비스에서 버그가 발생해서 응답이 매우 느려졌습니다. 사용자 서비스는 계속 기다리고, 요청이 쌓이고, 결국 사용자 서비스까지 죽게 됩니다.

서킷 브레이커는 이런 장애의 연쇄 전파를 막습니다. 마치 집의 두꺼비집(차단기)과 같습니다.

주문 서비스의 응답이 느리거나 에러가 많이 발생하면, 서킷 브레이커가 자동으로 회로를 차단합니다. 더 이상 주문 서비스를 호출하지 않고 미리 정의된 폴백 응답을 돌려줍니다.

일정 시간이 지나면 서킷 브레이커는 다시 한 번 시도해봅니다. 주문 서비스가 복구되었다면 정상적으로 호출을 재개합니다.

로드 밸런서 - 부하를 골고루 분산 "마지막은 스프링 클라우드 로드밸런서예요." 박시니어 씨가 설명을 마무리했습니다. 주문 서비스가 3대의 서버에서 실행되고 있다고 합시다.

요청이 들어왔을 때 어느 서버로 보낼까요? 로드 밸런서가 이 결정을 합니다.

가장 간단한 방식은 라운드 로빈입니다. 첫 번째 요청은 서버 1로, 두 번째 요청은 서버 2로, 세 번째 요청은 서버 3로, 네 번째 요청은 다시 서버 1로 보냅니다.

돌아가면서 골고루 분산시키는 것이죠. 더 똑똑한 방식도 있습니다.

각 서버의 응답 시간을 측정해서 가장 빠른 서버로 요청을 보낼 수도 있습니다. 실무에서의 조합 박시니어 씨가 실제 시스템 구성도를 보여줬습니다.

"우리 회사는 이렇게 구성되어 있어요." 클라이언트의 요청은 먼저 게이트웨이를 거칩니다. 게이트웨이는 유레카에게 물어서 어느 서비스로 보낼지 결정합니다.

요청을 보낼 때 로드 밸런서가 여러 인스턴스 중 하나를 선택합니다. 만약 서비스가 응답하지 않으면 서킷 브레이커가 작동합니다.

그리고 모든 서비스는 시작할 때 컨피그 서버에서 설정을 받아옵니다. 이 다섯 가지 컴포넌트가 유기적으로 동작하면서 안정적인 MSA 시스템을 만듭니다.

선택의 자유 "이 모든 걸 다 써야 하나요?" 김개발 씨가 물었습니다. "아니요, 필요한 것만 선택해서 쓸 수 있어요." 박시니어 씨가 대답했습니다.

"작은 시스템이라면 유레카와 게이트웨이만 써도 충분합니다. 시스템이 커지면서 필요에 따라 하나씩 추가하면 됩니다." 스프링 클라우드의 강점은 바로 이 유연성입니다.

레고 블록처럼 필요한 컴포넌트를 조합해서 사용할 수 있습니다.

실전 팁

💡 - 처음에는 유레카와 게이트웨이부터 시작하세요

서킷 브레이커는 장애 격리에 필수적이므로 꼭 적용하세요
컨피그 서버는 서비스가 5개 이상일 때 도입을 고려하세요

4. Netflix OSS vs 스프링 클라우드

김개발 씨는 인터넷에서 스프링 클라우드 자료를 찾다가 이상한 걸 발견했습니다. 어떤 글에서는 "넷플릭스 유레카"라고 하고, 어떤 글에서는 "스프링 클라우드 유레카"라고 했습니다.

"이게 같은 건가? 다른 건가?" 헷갈린 김개발 씨는 다시 박시니어 씨를 찾아갔습니다.

Netflix OSS는 넷플릭스가 오픈소스로 공개한 MSA 도구 모음입니다. 초기 스프링 클라우드는 Netflix OSS를 기반으로 만들어졌지만, 현재는 많은 부분이 스프링 자체 구현으로 교체되었습니다.

유레카와 히스트릭스 같은 Netflix 컴포넌트는 유지보수가 중단되어 스프링 클라우드 로드밸런서, 서킷 브레이커(Resilience4j) 등으로 마이그레이션이 권장됩니다.

다음 코드를 살펴봅시다.

// 과거 방식 (Netflix Ribbon + Hystrix) - 더 이상 권장되지 않음
@Configuration
public class OldConfiguration {

    // Netflix Ribbon - 유지보수 중단됨
    @LoadBalanced
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }

    // Netflix Hystrix - 유지보수 중단됨
    @HystrixCommand(fallbackMethod = "fallback")
    public String callService() {
        return restTemplate.getForObject("http://order-service/orders", String.class);
    }
}

// 현재 권장 방식 (Spring Cloud LoadBalancer + Resilience4j)
@Configuration
public class ModernConfiguration {

    // Spring Cloud LoadBalancer
    @LoadBalanced
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }

    // Resilience4j Circuit Breaker
    @CircuitBreaker(name = "orderService", fallbackMethod = "fallback")
    public String callService() {
        return restTemplate.getForObject("http://order-service/orders", String.class);
    }
}

"아, 그거요?" 박시니어 씨가 웃었습니다. "스프링 클라우드의 역사를 알면 이해가 쉬워요." 넷플릭스의 선구자적 역할 2010년대 초반, 넷플릭스는 세계 최초로 대규모 MSA를 구축한 회사 중 하나였습니다.

당시에는 MSA를 위한 도구가 거의 없었습니다. 그래서 넷플릭스는 직접 만들었습니다.

유레카(서비스 디스커버리), 리본(클라이언트 로드 밸런서), 히스트릭스(서킷 브레이커), 주울(API 게이트웨이) 등을 개발했고, 이를 Netflix OSS(Open Source Software)라는 이름으로 오픈소스로 공개했습니다. 많은 기업들이 Netflix OSS를 사용했습니다.

하지만 문제가 있었습니다. 넷플릭스 도구들은 스프링과 통합이 쉽지 않았습니다.

설정이 복잡하고, 사용법도 어려웠습니다. 스프링 클라우드의 탄생 이 문제를 해결하기 위해 스프링 클라우드가 탄생했습니다.

스프링 팀은 Netflix OSS를 스프링과 쉽게 통합할 수 있도록 래퍼(wrapper)를 만들었습니다. 예를 들어 Netflix Eureka를 사용하려면 복잡한 설정이 필요했지만, 스프링 클라우드를 사용하면 @EnableEurekaClient 어노테이션 하나만 추가하면 됐습니다.

이것이 초기 스프링 클라우드였습니다. 김개발 씨가 이해했다는 듯 고개를 끄덕였습니다.

"그럼 스프링 클라우드는 Netflix OSS의 스프링 버전이네요?" "처음에는 그랬어요. 하지만 이야기는 여기서 끝나지 않아요." 넷플릭스의 결정 2018년, 넷플릭스는 충격적인 발표를 했습니다.

"더 이상 OSS 프로젝트를 적극적으로 개발하지 않겠다." 리본과 히스트릭스를 유지보수 모드로 전환한다고 선언했습니다. 새로운 기능은 추가되지 않고, 중요한 버그만 수정하겠다는 뜻이었습니다.

주울은 아예 개발이 중단되었습니다. 넷플릭스는 내부적으로 주울2를 사용하지만, 오픈소스로는 공개하지 않았습니다.

왜 이런 결정을 했을까요? 넷플릭스는 자신들의 내부 시스템에 집중하기로 했습니다.

오픈소스 커뮤니티를 지원하는 것이 부담스러웠던 것이죠. 스프링의 대응 스프링 팀은 위기를 기회로 만들었습니다.

Netflix OSS에 의존하지 않는 자체 구현을 만들기 시작했습니다. 리본 대신 스프링 클라우드 로드밸런서를 만들었습니다.

더 가볍고, 스프링과의 통합도 더 자연스러웠습니다. 히스트릭스 대신 Resilience4j를 채택했습니다.

히스트릭스보다 더 유연하고 성능도 좋았습니다. 주울 대신 스프링 클라우드 게이트웨이를 만들었습니다.

스프링 웹플럭스 기반으로 비동기 처리가 가능했고, 성능이 훨씬 뛰어났습니다. 유레카만 남다 재미있게도 유레카만은 여전히 Netflix 버전을 사용합니다.

왜냐하면 유레카는 아직도 잘 동작하고, 안정적이며, 대체할 만한 더 나은 것이 없기 때문입니다. 물론 유레카 대신 Consul이나 Zookeeper 같은 다른 서비스 디스커버리를 사용할 수도 있습니다.

하지만 대부분의 프로젝트는 여전히 유레카를 선택합니다. 코드 비교 위의 코드를 봅시다.

과거에는 @HystrixCommand를 사용했지만, 현재는 @CircuitBreaker를 사용합니다. 기능은 같지만 구현체가 다릅니다.

과거 방식의 문제는 히스트릭스가 더 이상 업데이트되지 않는다는 것입니다. 새로운 자바 버전이나 스프링 부트 버전과 호환성 문제가 생길 수 있습니다.

반면 Resilience4j는 활발히 개발되고 있습니다. 자바 17, 스프링 부트 3 등 최신 기술 스택을 모두 지원합니다.

마이그레이션은 필수인가 김개발 씨가 걱정스러운 얼굴로 물었습니다. "그럼 기존 프로젝트를 다 바꿔야 하나요?" "당장은 아니에요." 박시니어 씨가 안심시켰습니다.

"히스트릭스나 리본을 쓰는 기존 프로젝트는 당분간 잘 돌아갈 거예요. 하지만 새 프로젝트를 시작한다면 Netflix 컴포넌트는 피하는 게 좋아요." 장기적으로는 마이그레이션을 계획해야 합니다.

특히 스프링 부트 3로 업그레이드할 때는 Netflix 컴포넌트를 교체해야 할 가능성이 큽니다. 현재의 스프링 클라우드 2025년 현재, 스프링 클라우드는 Netflix OSS로부터 거의 독립했습니다.

유레카를 제외하면 모든 핵심 컴포넌트가 스프링 자체 구현이거나 서드파티(Resilience4j 같은)로 대체되었습니다. 이는 좋은 변화입니다.

외부 의존성이 줄어들었고, 스프링 생태계와의 통합이 더 자연스러워졌습니다. 성능과 유지보수성도 개선되었습니다.

정리 박시니어 씨가 마무리했습니다. "Netflix OSS는 MSA의 선구자였어요.

스프링 클라우드가 성장하는 데 큰 도움을 줬죠. 하지만 이제 스프링 클라우드는 자신만의 길을 가고 있어요." 김개발 씨는 이제 왜 같은 컴포넌트에 여러 이름이 있는지 이해했습니다.

역사적 맥락을 알면 기술을 더 깊이 이해할 수 있다는 것도 배웠습니다.

실전 팁

💡 - 새 프로젝트에서는 Netflix Ribbon, Hystrix, Zuul을 사용하지 마세요

Resilience4j와 Spring Cloud LoadBalancer가 권장 대체재입니다
Eureka는 여전히 안정적으로 사용할 수 있습니다

5. 의존성 관리

김개발 씨는 첫 스프링 클라우드 프로젝트를 만들려고 pom.xml을 열었습니다. 그런데 어떤 의존성을 추가해야 할지 막막했습니다.

"게이트웨이 쓰려면 뭘 추가하지? 버전은 어떻게 맞추지?" 스택오버플로우를 뒤지다가 각각 다른 버전을 쓰는 예제들을 발견하고 더 혼란스러워졌습니다.

스프링 클라우드의 의존성 관리는 BOM(Bill of Materials)을 기반으로 합니다. spring-cloud-dependencies BOM을 추가하면 개별 컴포넌트의 버전을 명시하지 않아도 자동으로 호환되는 버전이 선택됩니다.

각 기능별로 spring-cloud-starter-* 형태의 스타터 의존성을 추가하면 필요한 라이브러리가 자동으로 포함됩니다.

다음 코드를 살펴봅시다.

<!-- Maven pom.xml - 스프링 클라우드 의존성 관리 -->
<properties>
    <java.version>17</java.version>
    <spring-boot.version>3.2.0</spring-boot.version>
    <spring-cloud.version>2024.0.0</spring-cloud.version>
</properties>

<dependencyManagement>
    <dependencies>
        <!-- 스프링 부트 BOM -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <!-- 스프링 클라우드 BOM - 버전 통합 관리 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <!-- 유레카 클라이언트 - 버전 명시 불필요 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>

    <!-- API 게이트웨이 - 버전 명시 불필요 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>

    <!-- 서킷 브레이커 - 버전 명시 불필요 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-circuitbreaker-resilience4j</artifactId>
    </dependency>
</dependencies>

박시니어 씨가 김개발 씨의 화면을 보더니 웃었습니다. "의존성 관리, 처음엔 다들 헷갈려 해요.

하지만 원리를 알면 아주 간단해요." BOM이란 무엇인가 "먼저 BOM부터 이해해야 해요." 박시니어 씨가 설명을 시작했습니다. BOM은 Bill of Materials의 약자입니다.

제조업에서 사용하는 용어인데, "자재 명세서"라는 뜻입니다. 의자를 만들 때 필요한 나사, 목재, 페인트 등의 목록과 같습니다.

소프트웨어에서 BOM은 호환되는 라이브러리 버전들의 목록입니다. 스프링 클라우드 BOM을 추가하면 "2024.0.0 버전에서는 게이트웨이 4.1.0, 유레카 4.0.3을 사용합니다"라는 정보가 포함됩니다.

개발자는 개별 버전을 외울 필요가 없습니다. BOM이 모든 것을 관리해줍니다.

dependencyManagement vs dependencies 김개발 씨가 코드를 보다가 물었습니다. "dependencyManagement와 dependencies는 뭐가 다른가요?" "좋은 질문이에요!" 박시니어 씨가 대답했습니다.

<dependencyManagement>는 버전을 선언만 하는 곳입니다. 실제로 라이브러리를 프로젝트에 추가하지는 않습니다.

마치 "앞으로 사과를 쓸 때는 부사 품종으로 쓰겠다"고 선언하는 것과 같습니다. <dependencies>는 실제로 라이브러리를 추가하는 곳입니다.

"사과를 장바구니에 담는" 행위입니다. BOM은 dependencyManagement에 추가합니다.

그리고 실제 사용할 라이브러리는 dependencies에 추가하되, 버전은 적지 않습니다. BOM이 알아서 버전을 정해주기 때문입니다.

스타터 의존성의 마법 "그리고 spring-cloud-starter-로 시작하는 의존성을 주목하세요." 박시니어 씨가 계속 설명했습니다. 스타터 의존성은 필요한 모든 라이브러리를 묶어놓은 패키지입니다.

마치 라면을 사면 스프와 건더기가 함께 들어있는 것처럼, 스타터 하나만 추가하면 관련된 모든 라이브러리가 자동으로 포함됩니다. 예를 들어 spring-cloud-starter-gateway를 추가하면 게이트웨이뿐만 아니라 웹플럭스, 넷티, 로깅 라이브러리 등이 함께 딸려옵니다.

개발자는 이것저것 찾아서 추가할 필요가 없습니다. Gradle로 작성하면 "Maven 말고 Gradle 쓰는 프로젝트도 많잖아요?" 김개발 씨가 물었습니다.

박시니어 씨가 Gradle 예제를 보여줬습니다: groovy // build.gradle plugins { id 'org.springframework.boot' version '3.2.0' id 'io.spring.dependency-management' version '1.1.4' } ext { set('springCloudVersion', "2024.0.0") } dependencies { implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' implementation 'org.springframework.cloud:spring-cloud-starter-gateway' implementation 'org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j' } dependencyManagement { imports { mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}" } } 개념은 동일합니다. BOM을 임포트하고, 개별 의존성에는 버전을 명시하지 않습니다.

버전 충돌 해결하기 "만약 제가 직접 버전을 명시하면 어떻게 되나요?" 김개발 씨가 궁금해했습니다. "그럼 BOM의 버전을 무시하고 여러분이 명시한 버전을 사용해요." 박시니어 씨가 대답했습니다.

"하지만 이건 위험한 행동이에요." 예를 들어 BOM은 게이트웨이 4.1.0을 사용하라고 하는데, 개발자가 4.0.5를 명시하면 다른 컴포넌트와 호환성 문제가 생길 수 있습니다. 버전을 직접 명시하는 것은 특별한 이유가 있을 때만 하세요.

스프링 부트와의 관계 코드를 보면 스프링 부트 BOM과 스프링 클라우드 BOM을 모두 추가했습니다. 둘의 관계는 무엇일까요?

스프링 부트는 기본 플랫폼입니다. 웹, 데이터베이스, 시큐리티 등 일반적인 스프링 애플리케이션에 필요한 것들을 관리합니다.

스프링 클라우드는 확장 플랫폼입니다. MSA에 특화된 기능들을 추가합니다.

스프링 부트 위에 얹어지는 레이어라고 생각하면 됩니다. 중요한 것은 버전 호환성입니다.

스프링 부트 3.2를 쓴다면 스프링 클라우드 2024.0.x를 써야 합니다. 공식 문서의 호환성 표를 항상 확인하세요.

실무 팁 - 버전 프로퍼티 사용 박시니어 씨가 실무 팁을 알려줬습니다. "버전을 <properties>에 정의하는 습관을 들이세요." xml <properties> <spring-cloud.version>2024.0.0</spring-cloud.version> </properties> 이렇게 하면 버전을 업그레이드할 때 한 곳만 수정하면 됩니다.

여러 곳에 흩어져 있으면 빠뜨리기 쉽습니다. 불필요한 의존성 피하기 "모든 스타터를 다 추가하면 안 되나요?" 김개발 씨가 물었습니다.

"절대 안 돼요!" 박시니어 씨가 단호하게 말했습니다. "필요한 것만 추가하세요." 예를 들어 게이트웨이 서비스라면 spring-cloud-starter-gateway만 추가합니다.

유레카 클라이언트나 컨피그 클라이언트는 필요하지 않습니다. 불필요한 의존성은 애플리케이션을 무겁게 만들고 시작 시간을 늘립니다.

의존성 확인하기 "어떤 버전이 실제로 사용되는지 확인하려면 어떻게 하나요?" 김개발 씨의 마지막 질문이었습니다. Maven에서는 mvn dependency:tree 명령어를 사용합니다.

Gradle에서는 ./gradlew dependencies를 사용합니다. 이 명령어는 모든 의존성을 트리 구조로 보여줍니다.

여기서 버전 충돌이 있는지, 예상한 버전이 사용되는지 확인할 수 있습니다. 정리 김개발 씨는 이제 의존성 관리의 핵심을 이해했습니다.

BOM으로 버전을 통합 관리하고, 스타터로 간편하게 기능을 추가하고, 필요한 것만 선택적으로 사용하는 것. 이 세 가지만 기억하면 됩니다.

실전 팁

💡 - 항상 BOM을 사용하여 버전 충돌을 방지하세요

스타터 의존성을 활용하면 필요한 라이브러리를 한 번에 추가할 수 있습니다
mvn dependency:tree로 실제 사용되는 버전을 확인하세요

6. 버전 호환성

김개발 씨는 드디어 첫 스프링 클라우드 프로젝트를 시작했습니다. 스프링 부트 3.2와 스프링 클라우드 2024.0.0을 선택했습니다.

그런데 빌드를 하자마자 에러가 쏟아졌습니다. "자바 버전이 맞지 않습니다"라는 메시지가 떴습니다.

"아, 자바 버전도 맞춰야 하는구나..." 좌절한 김개발 씨는 또다시 박시니어 씨를 찾아갔습니다.

스프링 클라우드의 버전 호환성은 자바 버전, 스프링 부트 버전, 스프링 클라우드 버전 세 가지를 모두 고려해야 합니다. 2024.0.x는 스프링 부트 3.2+ 및 자바 17+를 요구합니다.

2023.0.x는 스프링 부트 3.0-3.1과 호환되며, 2022.0.x는 스프링 부트 2.6-2.7과 호환됩니다. 잘못된 조합은 런타임 에러나 빌드 실패를 유발합니다.

다음 코드를 살펴봅시다.

// application.properties - 올바른 버전 조합 예시

// 조합 1: 최신 스택 (2025년 권장)
// Java 17 또는 21
// Spring Boot 3.2.0+
// Spring Cloud 2024.0.0+
spring.application.name=user-service
spring.cloud.compatibility.verifySpringBootVersion=true

// 조합 2: 안정적인 스택 (레거시 프로젝트)
// Java 11 또는 17
// Spring Boot 2.7.x
// Spring Cloud 2022.0.x

// 잘못된 조합 예시 (빌드 실패!)
// Java 8 + Spring Boot 3.x (불가능)
// Spring Boot 2.x + Spring Cloud 2024.x (불가능)
// Java 11 + Spring Cloud 2024.x (불가능)

// build.gradle - 버전 호환성 검증
plugins {
    id 'org.springframework.boot' version '3.2.0'
    id 'java'
}

java {
    sourceCompatibility = '17'  // Spring Boot 3.x는 Java 17 이상 필요
}

ext {
    set('springCloudVersion', "2024.0.0")  // Spring Boot 3.2와 호환
}

박시니어 씨는 화이트보드에 큰 표를 그렸습니다. 가로축에는 스프링 부트 버전, 세로축에는 스프링 클라우드 버전이 적혀 있었습니다.

"버전 호환성은 퍼즐 맞추기와 같아요." 세 가지 버전의 조화 "스프링 클라우드를 사용하려면 세 가지 버전을 맞춰야 해요." 박시니어 씨가 설명했습니다. 첫째, 자바 버전입니다.

스프링 부트 3.x는 자바 17 이상을 요구합니다. 자바 8이나 11로는 실행할 수 없습니다.

반면 스프링 부트 2.x는 자바 8부터 지원합니다. 둘째, 스프링 부트 버전입니다.

스프링 클라우드는 스프링 부트 위에서 동작하므로 호환되는 스프링 부트 버전을 선택해야 합니다. 셋째, 스프링 클라우드 버전입니다.

각 스프링 클라우드 릴리즈는 특정 스프링 부트 버전 범위를 지원합니다. 이 세 가지가 모두 맞아떨어져야 프로젝트가 정상적으로 동작합니다.

2025년 권장 조합 "지금 새 프로젝트를 시작한다면 어떤 조합을 쓰나요?" 김개발 씨가 물었습니다. 박시니어 씨가 추천 조합을 알려줬습니다: - 자바 17 또는 자바 21 (LTS 버전) - 스프링 부트 3.2.x 이상 - 스프링 클라우드 2024.0.x 자바 21은 최신 LTS 버전이지만, 아직 검증이 덜 된 면이 있습니다.

안정성을 원한다면 자바 17을 선택하세요. 많은 기업이 자바 17을 표준으로 사용하고 있습니다.

레거시 프로젝트 조합 "회사에서 옛날 프로젝트를 유지보수하고 있다면 어떻게 하나요?" 김개발 씨의 질문이었습니다. "레거시 프로젝트는 급하게 업그레이드하지 않아도 돼요." 박시니어 씨가 대답했습니다.

레거시 조합은 이렇습니다: - 자바 11 (또는 자바 8) - 스프링 부트 2.7.x - 스프링 클라우드 2022.0.x 스프링 부트 2.7은 2024년까지 공식 지원이 계속됩니다. 따라서 당장 3.x로 마이그레이션하지 않아도 괜찮습니다.

하지만 장기적으로는 계획을 세워야 합니다. 호환성 표 보는 법 박시니어 씨가 스프링 공식 문서를 열었습니다.

"이 표를 북마크해두세요." 스프링 클라우드 공식 문서에는 버전 호환성 표가 있습니다. 예를 들면: | Spring Cloud | Spring Boot | Java | |--------------|-------------|------| | 2024.0.x | 3.2.x, 3.3.x | 17, 21 | | 2023.0.x | 3.0.x, 3.1.x | 17, 21 | | 2022.0.x | 2.6.x, 2.7.x | 8, 11, 17 | 이 표만 보면 어떤 조합이 가능한지 한눈에 알 수 있습니다.

왜 호환성이 중요한가 김개발 씨가 의문을 품었습니다. "버전이 안 맞으면 그냥 경고만 뜨는 거 아닌가요?" "아니요, 애플리케이션이 아예 시작되지 않을 수 있어요." 박시니어 씨가 진지하게 말했습니다.

예를 들어 스프링 부트 2.7에 스프링 클라우드 2024.0.x를 사용하면 ClassNotFoundException이나 NoSuchMethodError 같은 런타임 에러가 발생합니다. 스프링 클라우드 2024.0.x는 스프링 부트 3.x의 API를 사용하기 때문입니다.

또한 자바 버전이 맞지 않으면 빌드 자체가 실패합니다. 스프링 부트 3.x의 바이트코드는 자바 17 이상에서만 실행 가능합니다.

마이그레이션 전략 "그럼 레거시 프로젝트를 업그레이드하려면 어떻게 해야 하나요?" 김개발 씨가 걱정스럽게 물었습니다. 박시니어 씨가 단계적 마이그레이션 전략을 설명했습니다: 1단계: 자바 버전 업그레이드 (8 → 11 → 17) 2단계: 스프링 부트 버전 업그레이드 (2.6 → 2.7) 3단계: 스프링 클라우드 버전 업그레이드 (2021.x → 2022.0.x) 4단계: 스프링 부트 3.x로 마이그레이션 (큰 변경) 5단계: 스프링 클라우드 2024.x로 마이그레이션 한 번에 모든 것을 바꾸려고 하지 마세요.

단계적으로 천천히 업그레이드하고, 각 단계마다 충분히 테스트하세요. 자동 검증 설정 코드를 보면 spring.cloud.compatibility.verifySpringBootVersion=true라는 설정이 있습니다.

이것을 활성화하면 스프링 클라우드가 시작할 때 스프링 부트 버전을 확인합니다. 만약 호환되지 않는 버전이라면 애플리케이션이 시작되지 않고 명확한 에러 메시지를 보여줍니다.

"Spring Cloud 2024.0.0 requires Spring Boot 3.2.0 or higher. You are using 3.1.5." 이런 에러 메시지 덕분에 문제를 빨리 발견할 수 있습니다.

실무에서의 선택 박시니어 씨는 자신의 경험을 공유했습니다. "우리 회사는 3년 된 프로젝트가 있어요.

아직 스프링 부트 2.7에 스프링 클라우드 2022.0.4를 쓰고 있죠." "곧 업그레이드하지 않나요?" 김개발 씨가 물었습니다. "올해 중에 할 계획이에요.

하지만 서두르지 않아요. 현재 버전도 잘 동작하고 보안 패치도 받고 있으니까요.

업그레이드는 비즈니스 가치가 명확할 때 하는 거예요." 무조건 최신 버전을 쫓을 필요는 없습니다. 안정성과 비즈니스 요구사항을 고려해서 결정하세요.

의존성 업그레이드 팁 "버전을 바꿀 때 주의할 점이 있나요?" 김개발 씨의 마지막 질문이었습니다. 박시니어 씨가 실전 팁을 알려줬습니다: 첫째, 릴리즈 노트를 꼭 읽으세요.

Breaking changes(호환성이 깨지는 변경)가 있는지 확인하세요. 둘째, 로컬 환경에서 먼저 테스트하세요.

빌드가 성공하는지, 테스트가 통과하는지 확인하세요. 셋째, 스테이징 환경에 배포해서 통합 테스트를 수행하세요.

다른 마이크로서비스와의 호환성을 확인하세요. 넷째, 프로덕션 배포 시 롤백 계획을 준비하세요.

문제가 생기면 즉시 이전 버전으로 되돌릴 수 있어야 합니다. 정리 김개발 씨는 이제 버전 호환성의 중요성을 이해했습니다.

자바, 스프링 부트, 스프링 클라우드 세 가지 버전이 조화를 이뤄야 한다는 것. 그리고 무조건 최신 버전보다는 프로젝트 상황에 맞는 안정적인 버전을 선택해야 한다는 것을 배웠습니다.

실전 팁

💡 - 스프링 공식 문서의 버전 호환성 표를 항상 확인하세요

마이그레이션은 단계적으로 진행하고 각 단계마다 충분히 테스트하세요
spring.cloud.compatibility.verifySpringBootVersion=true 설정으로 자동 검증을 활성화하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Spring Cloud#MSA#Microservices#Service Discovery#API Gateway

스프링 클라우드 완벽 입문 가이드

# 스프링 클라우드 완벽 입문 가이드 MSA 아키텍처의 필수 도구인 스프링 클라우드를 초급 개발자도 이해할 수 있도록 쉽게 설명합니다. Netflix OSS와의 차이점, 주요 컴포넌트, 버전 호환성까지 실무에 필요한 모든 내용을 담았습니다. --- ## 목차 1. [스프링_클라우드란](#스프링-클라우드란) 2. [스프링_클라우드_2025_버전](#스프링-클라우드-2025-버전) 3. [주요_컴포넌트_소개](#주요-컴포넌트-소개) 4. [Netflix_OSS_vs_스프링_클라우드](#netflix-oss-vs-스프링-클라우드) 5. [의존성_관리](#의존성-관리) 6. [버전_호환성](#버전-호환성) --- ## 1. 스프링_클라우드란 어느 날 김개발 씨는 회사에서 새로운 프로젝트 킥오프 미팅에 참석했습니다. "이번 프로젝트는 MSA로 진행합니다. 스프링 클라우드를 사용할 예정이에요." 팀장님의 말에 김개발 씨는 고개를 끄덕였지만 속으로는 걱정이 앞섰습니다. 스프링은 알겠는데, 스프링 클라우드는 뭘까요? **스프링 클라우드**는 MSA 아키텍처를 구축할 때 필요한 다양한 기능을 제공하는 프레임워크입니다. 마치 레고 블록을 조립하듯이 서비스 디스커버리, API 게이트웨이, 설정 관리 등의 컴포넌트를 쉽게 조합할 수 있습니다. 스프링 부트 기반으로 작동하기 때문에 친숙한 방식으로 분산 시스템을 개발할 수 있습니다. 다음 코드를 살펴봅시다. ```java // 스프링 클라우드를 사용한 간단한 서비스 구성 @SpringBootApplication @EnableDiscoveryClient // 서비스 디스커버리 활성화 public class UserServiceApplication { public static void main(String[] args) { SpringApplication.run(UserServiceApplication.class, args); } @RestController class UserController { // 다른 마이크로서비스 호출을 위한 클라이언트 @Autowired private RestTemplate restTemplate; @GetMapping("/users/{id}/orders") public String getUserOrders(@PathVariable String id) { // 서비스 이름으로 호출 - IP 주소를 몰라도 됩니다 return restTemplate.getForObject( "http://order-service/orders/user/" + id, String.class ); } } } ``` 김개발 씨는 퇴근 후 집에 돌아와 노트북을 켰습니다. "스프링 클라우드가 뭔지 제대로 알아봐야겠어." 검색을 시작했지만 어려운 용어들이 가득했습니다. 다음 날 출근하자마자 선배 개발자 박시니어 씨를 찾아갔습니다. "선배님, 스프링 클라우드가 정확히 뭔가요?" 박시니어 씨는 커피를 한 모금 마시고는 천천히 설명을 시작했습니다. **쉽게 비유하자면** "스프링 클라우드는 마치 아파트 단지 관리 시스템과 같아요." 박시니어 씨가 말했습니다. "일반 주택은 모든 것을 스스로 관리해야 하지만, 아파트 단지에는 관리 시스템이 있죠. 경비실에서 방문객을 안내하고, 관리사무소에서 각 동의 상태를 파악하고, 공지사항을 전달합니다." 스프링 클라우드도 마찬가지입니다. 여러 개의 작은 서비스들이 모여 하나의 큰 시스템을 이룰 때, 이들을 관리하고 연결해주는 역할을 합니다. 각 서비스가 어디에 있는지 찾아주고, 서비스 간 통신을 도와주고, 설정 정보를 중앙에서 관리합니다. **모놀리식에서 MSA로** 예전에는 하나의 거대한 애플리케이션을 만들었습니다. 사용자 관리, 주문 처리, 결제, 배송 추적 등 모든 기능이 하나의 프로젝트에 들어있었습니다. 이런 방식을 **모놀리식 아키텍처**라고 부릅니다. 김개발 씨도 학교 프로젝트에서 이런 방식으로 개발해봤습니다. 처음에는 편했습니다. 모든 코드가 한곳에 있으니까요. 하지만 프로젝트가 커지면서 문제가 생기기 시작했습니다. 한 부분을 수정하면 다른 부분에서 버그가 발생했습니다. 배포할 때마다 전체 시스템을 재시작해야 했습니다. **MSA의 등장** 이런 문제를 해결하기 위해 **마이크로서비스 아키텍처**가 등장했습니다. 거대한 애플리케이션을 작은 서비스 단위로 쪼개는 방식입니다. 사용자 서비스, 주문 서비스, 결제 서비스처럼 각자의 역할을 가진 독립적인 서비스들로 나눕니다. 하지만 새로운 문제가 생겼습니다. "이 많은 서비스들을 어떻게 관리하지?" 서비스가 10개, 20개로 늘어나면 각 서비스의 위치를 어떻게 알 수 있을까요? 서비스 간 통신은 어떻게 처리할까요? 설정 파일은 어떻게 관리할까요? **스프링 클라우드의 등장** 바로 여기서 **스프링 클라우드**가 등장합니다. 스프링 클라우드는 MSA를 구축할 때 필요한 모든 도구를 제공합니다. 첫째, **서비스 디스커버리**가 있습니다. 각 서비스가 시작될 때 자신의 위치를 등록하면, 다른 서비스들이 이름만으로 찾을 수 있습니다. IP 주소나 포트 번호를 외울 필요가 없습니다. 둘째, **API 게이트웨이**가 있습니다. 클라이언트는 하나의 진입점을 통해 모든 서비스에 접근할 수 있습니다. 마치 아파트 단지의 정문과 같습니다. 셋째, **설정 관리 서버**가 있습니다. 모든 서비스의 설정을 중앙에서 관리할 수 있습니다. 설정을 변경하면 서비스를 재시작하지 않아도 반영됩니다. **코드 살펴보기** 위의 코드를 봅시다. `@EnableDiscoveryClient` 어노테이션 하나만 추가하면 이 서비스가 자동으로 서비스 디스커버리에 등록됩니다. 그리고 `RestTemplate`을 사용할 때 서비스 이름(`order-service`)만 적으면 됩니다. IP 주소를 하드코딩할 필요가 없습니다. 만약 주문 서비스가 3대의 서버에서 실행되고 있다면, 스프링 클라우드가 자동으로 **로드 밸런싱**을 해줍니다. 요청을 골고루 분산시켜서 특정 서버에 부하가 몰리지 않게 합니다. **실무에서의 활용** 박시니어 씨는 실제 경험을 들려줬습니다. "우리 회사 쇼핑몰은 30개 이상의 마이크로서비스로 구성되어 있어요. 스프링 클라우드가 없었다면 관리가 불가능했을 거예요." 예를 들어 블랙프라이데이 같은 행사 기간에는 주문 서비스만 서버를 늘립니다. 다른 서비스는 그대로 두고요. 스프링 클라우드가 새로 추가된 서버를 자동으로 인식하고 트래픽을 분산시킵니다. **스프링 부트와의 관계** "그런데 스프링 부트랑은 뭐가 다른 건가요?" 김개발 씨가 물었습니다. "좋은 질문이에요. **스프링 부트**는 단일 애플리케이션을 빠르게 개발하기 위한 도구입니다. 반면 **스프링 클라우드**는 여러 개의 스프링 부트 애플리케이션을 연결하고 관리하는 도구예요. 스프링 클라우드는 스프링 부트 위에서 동작합니다." 즉, 스프링 부트로 각각의 마이크로서비스를 만들고, 스프링 클라우드로 이들을 연결하는 것입니다. **시작하기** 김개발 씨는 이제 조금 감이 잡혔습니다. "그럼 제가 당장 배워야 할 건 뭔가요?" 박시니어 씨가 웃으며 대답했습니다. "먼저 **유레카**(서비스 디스커버리)와 **게이트웨이**부터 시작해보세요. 이 두 가지만 이해해도 MSA의 기본은 알 수 있어요." 스프링 클라우드는 어렵지 않습니다. 스프링 부트를 사용해봤다면 익숙한 방식으로 시작할 수 있습니다. 어노테이션 몇 개만 추가하면 강력한 분산 시스템을 구축할 수 있습니다. **실전 팁** 💡 - 스프링 클라우드는 스프링 부트 기반이므로 스프링 부트를 먼저 학습하세요 - 처음에는 유레카(서비스 디스커버리)와 게이트웨이부터 시작하는 것이 좋습니다 - 로컬 환경에서 여러 서비스를 띄워보며 실습하면 이해가 빠릅니다 --- ## 2. 스프링_클라우드_2025_버전 점심시간에 김개발 씨는 스프링 클라우드 공식 문서를 읽고 있었습니다. 그런데 버전이 너무 많았습니다. 2023.0.0, 2024.0.0... 숫자도 이상했습니다. "왜 3.0, 4.0이 아니라 연도를 쓰는 거지?" 박시니어 씨에게 다시 물어봤습니다. 스프링 클라우드는 **연도 기반 버전 체계**를 사용합니다. 2025.0.0처럼 출시 연도를 버전 번호로 사용하는 방식입니다. 이는 여러 개의 서브 프로젝트로 구성되어 있기 때문이며, 각 프로젝트의 버전을 통합 관리하기 위함입니다. 2025년 기준 최신 버전은 **2024.0.x** 시리즈이며, 이전 **2023.0.x**와 **2022.0.x**도 여전히 지원됩니다. 다음 코드를 살펴봅시다. ```java // pom.xml - 스프링 클라우드 버전 설정 17 3.2.0 2024.0.0 org.springframework.cloud spring-cloud-dependencies ${spring-cloud.version} pom import ``` "스프링 클라우드는 특별한 버전 체계를 사용해요." 박시니어 씨가 설명을 시작했습니다. "일반적인 라이브러리처럼 1.0, 2.0이 아니라 연도를 사용하죠." **왜 연도를 사용할까** 김개발 씨는 고개를 갸우뚱했습니다. "왜 그렇게 하는 거예요?" "스프링 클라우드는 사실 하나의 라이브러리가 아니에요. **여러 개의 서브 프로젝트**로 구성되어 있습니다." 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. 스프링 클라우드 안에는 많은 컴포넌트가 있습니다. 스프링 클라우드 게이트웨이, 스프링 클라우드 컨피그, 스프링 클라우드 로드밸런서, 스프링 클라우드 서킷 브레이커 등등. 각 컴포넌트는 독립적으로 개발되고 있고, 각자의 버전을 가지고 있습니다. 예를 들어 게이트웨이는 4.1.0이고, 컨피그는 4.0.5일 수 있습니다. 개발자가 이 모든 버전을 외우고 조합해야 한다면 얼마나 복잡할까요? **릴리즈 트레인** "그래서 스프링 팀은 **릴리즈 트레인**이라는 개념을 도입했어요." 박시니어 씨가 계속 설명했습니다. "기차가 정해진 시간에 출발하듯이, 1년에 한 번 모든 컴포넌트의 호환되는 버전을 묶어서 릴리즈하는 거죠." 2024년에 릴리즈한 버전은 2024.0.0입니다. 이 버전을 선택하면 게이트웨이, 컨피그, 로드밸런서 등 모든 컴포넌트의 호환되는 버전이 자동으로 결정됩니다. 개발자는 버전 호환성을 걱정할 필요가 없습니다. **2025년 현재 버전** "그럼 지금은 어떤 버전을 써야 하나요?" 김개발 씨가 물었습니다. "2025년 1월 기준으로 **2024.0.x**가 최신 안정 버전이에요. 2024년 12월에 정식 출시되었죠." 박시니어 씨가 대답했습니다. "물론 이전 버전인 **2023.0.x**도 여전히 많이 사용되고 있어요. 우리 회사도 아직 2023.0.3을 쓰고 있고요." 스프링 클라우드는 보통 최신 버전과 그 이전 두 개 버전을 동시에 지원합니다. 즉, 2025년에는 2024.0.x, 2023.0.x, 2022.0.x가 모두 지원됩니다. **마이너 버전과 패치 버전** "2024.0.0 뒤에 붙는 숫자는 뭔가요?" 김개발 씨가 또 물었습니다. "연도.마이너.패치 형식이에요." 박시니어 씨가 설명했습니다. "2024.0.0이 첫 릴리즈고, 버그 수정이나 작은 개선이 있으면 2024.0.1, 2024.0.2로 올라가요. 그리고 중요한 기능이 추가되면 2024.1.0이 됩니다." 일반적으로 패치 버전은 안전하게 업그레이드할 수 있습니다. 기존 코드를 수정할 필요가 없습니다. 하지만 마이너 버전이 올라가면 일부 API가 변경될 수 있으니 릴리즈 노트를 확인해야 합니다. **BOM이란** 위의 코드를 보면 `spring-cloud-dependencies`라는 의존성이 있습니다. 이것을 **BOM**(Bill of Materials)이라고 부릅니다. 마치 자재 명세서와 같습니다. BOM을 추가하면 개별 컴포넌트의 버전을 명시하지 않아도 됩니다. 스프링 클라우드가 알아서 호환되는 버전을 선택해줍니다. 예를 들어 게이트웨이를 추가할 때 이렇게 작성합니다: ```xml org.springframework.cloud spring-cloud-starter-gateway ``` 버전을 적지 않았지만 BOM이 2024.0.0 버전에 맞는 게이트웨이 버전을 자동으로 선택해줍니다. **실무 팁** 박시니어 씨는 자신의 경험을 공유했습니다. "실무에서는 무조건 최신 버전을 쓸 필요는 없어요. **안정성**이 더 중요하거든요." 새 프로젝트를 시작한다면 최신 버전을 사용하는 것이 좋습니다. 하지만 기존 프로젝트를 업그레이드할 때는 신중해야 합니다. 마이너 버전 업그레이드는 충분한 테스트 후에 진행하고, 메이저 버전 변경(예: 2023.x에서 2024.x)은 더욱 신중하게 계획해야 합니다. **어떻게 선택할까** "제가 새 프로젝트를 시작한다면 어떤 버전을 써야 할까요?" 김개발 씨가 마지막 질문을 했습니다. 박시니어 씨가 웃으며 대답했습니다. "2025년 1월 기준으로는 **2024.0.0** 이상을 추천해요. 다만 출시된 지 2-3개월 정도는 지난 버전이 안정적입니다. 2024.0.2 정도가 나왔다면 그걸 선택하는 게 좋아요." 또한 스프링 부트 버전과의 호환성도 확인해야 합니다. 2024.0.x는 스프링 부트 3.2 이상과 호환됩니다. 공식 문서의 호환성 표를 항상 확인하세요. **정리** 김개발 씨는 이제 스프링 클라우드의 버전 체계를 이해했습니다. 연도 기반 버전을 사용하는 이유, BOM의 역할, 그리고 버전 선택 기준까지 배웠습니다. **실전 팁** 💡 - BOM을 사용하면 개별 컴포넌트의 버전 관리가 자동화됩니다 - 실무에서는 최신 버전보다 안정성이 검증된 버전을 선택하세요 - 스프링 부트 버전과의 호환성을 반드시 확인하세요 --- ## 3. 주요_컴포넌트_소개 회의실에서 아키텍처 세미나가 열렸습니다. 박시니어 씨가 발표를 시작했습니다. "스프링 클라우드의 핵심 컴포넌트는 크게 다섯 가지입니다." 김개발 씨는 노트북을 열고 열심히 메모하기 시작했습니다. 각 컴포넌트가 어떤 역할을 하는지 제대로 알아야 실무에 적용할 수 있을 테니까요. 스프링 클라우드는 **유레카**(서비스 디스커버리), **게이트웨이**(API 라우팅), **컨피그 서버**(중앙 설정 관리), **서킷 브레이커**(장애 격리), **로드 밸런서**(부하 분산) 등 핵심 컴포넌트로 구성됩니다. 각 컴포넌트는 MSA 환경에서 특정 문제를 해결하기 위해 설계되었으며, 필요에 따라 선택적으로 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```java // application.yml - 주요 컴포넌트 설정 예제 spring: application: name: user-service # 서비스 이름 cloud: # 컨피그 서버 연결 config: uri: http://config-server:8888 fail-fast: true # 서킷 브레이커 설정 circuitbreaker: resilience4j: enabled: true # 로드 밸런서 설정 loadbalancer: ribbon: enabled: false eureka: client: service-url: defaultZone: http://eureka-server:8761/eureka/ # 유레카 서버 주소 instance: prefer-ip-address: true ``` 박시니어 씨는 화이트보드에 큰 그림을 그렸습니다. 중앙에 여러 개의 상자가 있고, 화살표로 연결되어 있었습니다. "이게 우리 시스템의 전체 구조예요." **유레카 - 서비스를 찾는 안내원** "먼저 **유레카**(Eureka)부터 볼까요?" 박시니어 씨가 화이트보드의 중앙 상자를 가리켰습니다. 유레카는 마치 백화점의 안내 데스크와 같습니다. "스포츠 용품은 몇 층에 있나요?"라고 물으면 "5층입니다"라고 알려주듯이, 유레카는 "주문 서비스는 어디 있나요?"라고 물으면 IP 주소와 포트를 알려줍니다. 각 마이크로서비스는 시작할 때 유레카에 자신을 등록합니다. "저는 사용자 서비스이고, 192.168.1.10:8080에서 실행 중입니다." 이렇게 말이죠. 그리고 30초마다 "아직 살아있어요!"라고 하트비트를 보냅니다. 다른 서비스가 사용자 서비스를 호출하려면 유레카에게 물어봅니다. 유레카는 현재 실행 중인 사용자 서비스의 목록을 알려줍니다. 만약 3대의 서버에서 실행 중이라면 3개의 주소를 모두 알려줍니다. **게이트웨이 - 모든 요청의 관문** "다음은 **스프링 클라우드 게이트웨이**입니다." 박시니어 씨가 계속 설명했습니다. 게이트웨이는 아파트 단지의 정문과 같습니다. 외부에서 들어오는 모든 요청은 게이트웨이를 거쳐야 합니다. 게이트웨이는 요청을 보고 어느 서비스로 보낼지 결정합니다. 예를 들어 `/users/`로 시작하는 요청은 사용자 서비스로, `/orders/`로 시작하는 요청은 주문 서비스로 보냅니다. 이를 **라우팅**이라고 합니다. 또한 게이트웨이는 인증과 권한 검사도 수행합니다. 로그인하지 않은 사용자의 요청은 바로 거부할 수 있습니다. 각 마이크로서비스에서 중복으로 인증 로직을 작성할 필요가 없습니다. **컨피그 서버 - 설정의 중앙 창고** "세 번째는 **스프링 클라우드 컨피그**예요." 박시니어 씨가 말했습니다. 10개의 마이크로서비스가 있다고 상상해봅시다. 각 서비스는 `application.yml` 파일에 설정을 가지고 있습니다. 만약 데이터베이스 주소를 변경해야 한다면 어떻게 될까요? 10개 파일을 모두 수정하고 10개 서비스를 모두 재배포해야 합니다. 컨피그 서버는 이 문제를 해결합니다. 모든 설정을 중앙의 Git 저장소에 저장합니다. 각 서비스는 시작할 때 컨피그 서버에서 설정을 받아옵니다. 설정을 변경하면 서비스를 재시작하지 않고도 적용할 수 있습니다. 김개발 씨가 손을 들었습니다. "그럼 컨피그 서버가 죽으면 어떻게 되나요?" "좋은 질문이에요. 그래서 보통 컨피그 서버를 이중화합니다. 그리고 각 서비스는 설정을 캐시해두기 때문에 일시적으로 컨피그 서버가 죽어도 동작할 수 있어요." **서킷 브레이커 - 장애의 전파를 막는 차단기** "네 번째는 **서킷 브레이커**입니다." 박시니어 씨의 목소리가 진지해졌습니다. "이건 정말 중요해요." 사용자 서비스가 주문 서비스를 호출한다고 가정해봅시다. 그런데 주문 서비스에서 버그가 발생해서 응답이 매우 느려졌습니다. 사용자 서비스는 계속 기다리고, 요청이 쌓이고, 결국 사용자 서비스까지 죽게 됩니다. 서킷 브레이커는 이런 **장애의 연쇄 전파**를 막습니다. 마치 집의 두꺼비집(차단기)과 같습니다. 주문 서비스의 응답이 느리거나 에러가 많이 발생하면, 서킷 브레이커가 자동으로 회로를 차단합니다. 더 이상 주문 서비스를 호출하지 않고 미리 정의된 폴백 응답을 돌려줍니다. 일정 시간이 지나면 서킷 브레이커는 다시 한 번 시도해봅니다. 주문 서비스가 복구되었다면 정상적으로 호출을 재개합니다. **로드 밸런서 - 부하를 골고루 분산** "마지막은 **스프링 클라우드 로드밸런서**예요." 박시니어 씨가 설명을 마무리했습니다. 주문 서비스가 3대의 서버에서 실행되고 있다고 합시다. 요청이 들어왔을 때 어느 서버로 보낼까요? 로드 밸런서가 이 결정을 합니다. 가장 간단한 방식은 **라운드 로빈**입니다. 첫 번째 요청은 서버 1로, 두 번째 요청은 서버 2로, 세 번째 요청은 서버 3로, 네 번째 요청은 다시 서버 1로 보냅니다. 돌아가면서 골고루 분산시키는 것이죠. 더 똑똑한 방식도 있습니다. 각 서버의 응답 시간을 측정해서 가장 빠른 서버로 요청을 보낼 수도 있습니다. **실무에서의 조합** 박시니어 씨가 실제 시스템 구성도를 보여줬습니다. "우리 회사는 이렇게 구성되어 있어요." 클라이언트의 요청은 먼저 **게이트웨이**를 거칩니다. 게이트웨이는 **유레카**에게 물어서 어느 서비스로 보낼지 결정합니다. 요청을 보낼 때 **로드 밸런서**가 여러 인스턴스 중 하나를 선택합니다. 만약 서비스가 응답하지 않으면 **서킷 브레이커**가 작동합니다. 그리고 모든 서비스는 시작할 때 **컨피그 서버**에서 설정을 받아옵니다. 이 다섯 가지 컴포넌트가 유기적으로 동작하면서 안정적인 MSA 시스템을 만듭니다. **선택의 자유** "이 모든 걸 다 써야 하나요?" 김개발 씨가 물었습니다. "아니요, 필요한 것만 선택해서 쓸 수 있어요." 박시니어 씨가 대답했습니다. "작은 시스템이라면 유레카와 게이트웨이만 써도 충분합니다. 시스템이 커지면서 필요에 따라 하나씩 추가하면 됩니다." 스프링 클라우드의 강점은 바로 이 **유연성**입니다. 레고 블록처럼 필요한 컴포넌트를 조합해서 사용할 수 있습니다. **실전 팁** 💡 - 처음에는 유레카와 게이트웨이부터 시작하세요 - 서킷 브레이커는 장애 격리에 필수적이므로 꼭 적용하세요 - 컨피그 서버는 서비스가 5개 이상일 때 도입을 고려하세요 --- ## 4. Netflix_OSS_vs_스프링_클라우드 김개발 씨는 인터넷에서 스프링 클라우드 자료를 찾다가 이상한 걸 발견했습니다. 어떤 글에서는 "넷플릭스 유레카"라고 하고, 어떤 글에서는 "스프링 클라우드 유레카"라고 했습니다. "이게 같은 건가? 다른 건가?" 헷갈린 김개발 씨는 다시 박시니어 씨를 찾아갔습니다. **Netflix OSS**는 넷플릭스가 오픈소스로 공개한 MSA 도구 모음입니다. 초기 스프링 클라우드는 Netflix OSS를 기반으로 만들어졌지만, 현재는 많은 부분이 스프링 자체 구현으로 교체되었습니다. 유레카와 히스트릭스 같은 Netflix 컴포넌트는 유지보수가 중단되어 스프링 클라우드 로드밸런서, 서킷 브레이커(Resilience4j) 등으로 마이그레이션이 권장됩니다. 다음 코드를 살펴봅시다. ```java // 과거 방식 (Netflix Ribbon + Hystrix) - 더 이상 권장되지 않음 @Configuration public class OldConfiguration { // Netflix Ribbon - 유지보수 중단됨 @LoadBalanced @Bean public RestTemplate restTemplate() { return new RestTemplate(); } // Netflix Hystrix - 유지보수 중단됨 @HystrixCommand(fallbackMethod = "fallback") public String callService() { return restTemplate.getForObject("http://order-service/orders", String.class); } } // 현재 권장 방식 (Spring Cloud LoadBalancer + Resilience4j) @Configuration public class ModernConfiguration { // Spring Cloud LoadBalancer @LoadBalanced @Bean public RestTemplate restTemplate() { return new RestTemplate(); } // Resilience4j Circuit Breaker @CircuitBreaker(name = "orderService", fallbackMethod = "fallback") public String callService() { return restTemplate.getForObject("http://order-service/orders", String.class); } } ``` "아, 그거요?" 박시니어 씨가 웃었습니다. "스프링 클라우드의 역사를 알면 이해가 쉬워요." **넷플릭스의 선구자적 역할** 2010년대 초반, 넷플릭스는 세계 최초로 대규모 MSA를 구축한 회사 중 하나였습니다. 당시에는 MSA를 위한 도구가 거의 없었습니다. 그래서 넷플릭스는 직접 만들었습니다. **유레카**(서비스 디스커버리), **리본**(클라이언트 로드 밸런서), **히스트릭스**(서킷 브레이커), **주울**(API 게이트웨이) 등을 개발했고, 이를 **Netflix OSS**(Open Source Software)라는 이름으로 오픈소스로 공개했습니다. 많은 기업들이 Netflix OSS를 사용했습니다. 하지만 문제가 있었습니다. 넷플릭스 도구들은 스프링과 통합이 쉽지 않았습니다. 설정이 복잡하고, 사용법도 어려웠습니다. **스프링 클라우드의 탄생** 이 문제를 해결하기 위해 **스프링 클라우드**가 탄생했습니다. 스프링 팀은 Netflix OSS를 스프링과 쉽게 통합할 수 있도록 래퍼(wrapper)를 만들었습니다. 예를 들어 Netflix Eureka를 사용하려면 복잡한 설정이 필요했지만, 스프링 클라우드를 사용하면 `@EnableEurekaClient` 어노테이션 하나만 추가하면 됐습니다. 이것이 초기 스프링 클라우드였습니다. 김개발 씨가 이해했다는 듯 고개를 끄덕였습니다. "그럼 스프링 클라우드는 Netflix OSS의 스프링 버전이네요?" "처음에는 그랬어요. 하지만 이야기는 여기서 끝나지 않아요." **넷플릭스의 결정** 2018년, 넷플릭스는 충격적인 발표를 했습니다. "더 이상 OSS 프로젝트를 적극적으로 개발하지 않겠다." 리본과 히스트릭스를 **유지보수 모드**로 전환한다고 선언했습니다. 새로운 기능은 추가되지 않고, 중요한 버그만 수정하겠다는 뜻이었습니다. 주울은 아예 개발이 중단되었습니다. 넷플릭스는 내부적으로 주울2를 사용하지만, 오픈소스로는 공개하지 않았습니다. 왜 이런 결정을 했을까요? 넷플릭스는 자신들의 내부 시스템에 집중하기로 했습니다. 오픈소스 커뮤니티를 지원하는 것이 부담스러웠던 것이죠. **스프링의 대응** 스프링 팀은 위기를 기회로 만들었습니다. Netflix OSS에 의존하지 않는 자체 구현을 만들기 시작했습니다. **리본** 대신 **스프링 클라우드 로드밸런서**를 만들었습니다. 더 가볍고, 스프링과의 통합도 더 자연스러웠습니다. **히스트릭스** 대신 **Resilience4j**를 채택했습니다. 히스트릭스보다 더 유연하고 성능도 좋았습니다. **주울** 대신 **스프링 클라우드 게이트웨이**를 만들었습니다. 스프링 웹플럭스 기반으로 비동기 처리가 가능했고, 성능이 훨씬 뛰어났습니다. **유레카만 남다** 재미있게도 **유레카**만은 여전히 Netflix 버전을 사용합니다. 왜냐하면 유레카는 아직도 잘 동작하고, 안정적이며, 대체할 만한 더 나은 것이 없기 때문입니다. 물론 유레카 대신 Consul이나 Zookeeper 같은 다른 서비스 디스커버리를 사용할 수도 있습니다. 하지만 대부분의 프로젝트는 여전히 유레카를 선택합니다. **코드 비교** 위의 코드를 봅시다. 과거에는 `@HystrixCommand`를 사용했지만, 현재는 `@CircuitBreaker`를 사용합니다. 기능은 같지만 구현체가 다릅니다. 과거 방식의 문제는 히스트릭스가 더 이상 업데이트되지 않는다는 것입니다. 새로운 자바 버전이나 스프링 부트 버전과 호환성 문제가 생길 수 있습니다. 반면 Resilience4j는 활발히 개발되고 있습니다. 자바 17, 스프링 부트 3 등 최신 기술 스택을 모두 지원합니다. **마이그레이션은 필수인가** 김개발 씨가 걱정스러운 얼굴로 물었습니다. "그럼 기존 프로젝트를 다 바꿔야 하나요?" "당장은 아니에요." 박시니어 씨가 안심시켰습니다. "히스트릭스나 리본을 쓰는 기존 프로젝트는 당분간 잘 돌아갈 거예요. 하지만 새 프로젝트를 시작한다면 Netflix 컴포넌트는 피하는 게 좋아요." 장기적으로는 마이그레이션을 계획해야 합니다. 특히 스프링 부트 3로 업그레이드할 때는 Netflix 컴포넌트를 교체해야 할 가능성이 큽니다. **현재의 스프링 클라우드** 2025년 현재, 스프링 클라우드는 Netflix OSS로부터 거의 독립했습니다. 유레카를 제외하면 모든 핵심 컴포넌트가 스프링 자체 구현이거나 서드파티(Resilience4j 같은)로 대체되었습니다. 이는 좋은 변화입니다. 외부 의존성이 줄어들었고, 스프링 생태계와의 통합이 더 자연스러워졌습니다. 성능과 유지보수성도 개선되었습니다. **정리** 박시니어 씨가 마무리했습니다. "Netflix OSS는 MSA의 선구자였어요. 스프링 클라우드가 성장하는 데 큰 도움을 줬죠. 하지만 이제 스프링 클라우드는 자신만의 길을 가고 있어요." 김개발 씨는 이제 왜 같은 컴포넌트에 여러 이름이 있는지 이해했습니다. 역사적 맥락을 알면 기술을 더 깊이 이해할 수 있다는 것도 배웠습니다. **실전 팁** 💡 - 새 프로젝트에서는 Netflix Ribbon, Hystrix, Zuul을 사용하지 마세요 - Resilience4j와 Spring Cloud LoadBalancer가 권장 대체재입니다 - Eureka는 여전히 안정적으로 사용할 수 있습니다 --- ## 5. 의존성_관리 김개발 씨는 첫 스프링 클라우드 프로젝트를 만들려고 `pom.xml`을 열었습니다. 그런데 어떤 의존성을 추가해야 할지 막막했습니다. "게이트웨이 쓰려면 뭘 추가하지? 버전은 어떻게 맞추지?" 스택오버플로우를 뒤지다가 각각 다른 버전을 쓰는 예제들을 발견하고 더 혼란스러워졌습니다. 스프링 클라우드의 의존성 관리는 **BOM**(Bill of Materials)을 기반으로 합니다. `spring-cloud-dependencies` BOM을 추가하면 개별 컴포넌트의 버전을 명시하지 않아도 자동으로 호환되는 버전이 선택됩니다. 각 기능별로 `spring-cloud-starter-*` 형태의 스타터 의존성을 추가하면 필요한 라이브러리가 자동으로 포함됩니다. 다음 코드를 살펴봅시다. ```java 17 3.2.0 2024.0.0 org.springframework.boot spring-boot-dependencies ${spring-boot.version} pom import org.springframework.cloud spring-cloud-dependencies ${spring-cloud.version} pom import org.springframework.cloud spring-cloud-starter-netflix-eureka-client org.springframework.cloud spring-cloud-starter-gateway org.springframework.cloud spring-cloud-starter-circuitbreaker-resilience4j ``` 박시니어 씨가 김개발 씨의 화면을 보더니 웃었습니다. "의존성 관리, 처음엔 다들 헷갈려 해요. 하지만 원리를 알면 아주 간단해요." **BOM이란 무엇인가** "먼저 **BOM**부터 이해해야 해요." 박시니어 씨가 설명을 시작했습니다. BOM은 Bill of Materials의 약자입니다. 제조업에서 사용하는 용어인데, "자재 명세서"라는 뜻입니다. 의자를 만들 때 필요한 나사, 목재, 페인트 등의 목록과 같습니다. 소프트웨어에서 BOM은 **호환되는 라이브러리 버전들의 목록**입니다. 스프링 클라우드 BOM을 추가하면 "2024.0.0 버전에서는 게이트웨이 4.1.0, 유레카 4.0.3을 사용합니다"라는 정보가 포함됩니다. 개발자는 개별 버전을 외울 필요가 없습니다. BOM이 모든 것을 관리해줍니다. **dependencyManagement vs dependencies** 김개발 씨가 코드를 보다가 물었습니다. "dependencyManagement와 dependencies는 뭐가 다른가요?" "좋은 질문이에요!" 박시니어 씨가 대답했습니다. ` `는 버전을 **선언**만 하는 곳입니다. 실제로 라이브러리를 프로젝트에 추가하지는 않습니다. 마치 "앞으로 사과를 쓸 때는 부사 품종으로 쓰겠다"고 선언하는 것과 같습니다. ` `는 실제로 라이브러리를 **추가**하는 곳입니다. "사과를 장바구니에 담는" 행위입니다. BOM은 dependencyManagement에 추가합니다. 그리고 실제 사용할 라이브러리는 dependencies에 추가하되, 버전은 적지 않습니다. BOM이 알아서 버전을 정해주기 때문입니다. **스타터 의존성의 마법** "그리고 `spring-cloud-starter-`로 시작하는 의존성을 주목하세요." 박시니어 씨가 계속 설명했습니다. 스타터 의존성은 **필요한 모든 라이브러리를 묶어놓은 패키지**입니다. 마치 라면을 사면 스프와 건더기가 함께 들어있는 것처럼, 스타터 하나만 추가하면 관련된 모든 라이브러리가 자동으로 포함됩니다. 예를 들어 `spring-cloud-starter-gateway`를 추가하면 게이트웨이뿐만 아니라 웹플럭스, 넷티, 로깅 라이브러리 등이 함께 딸려옵니다. 개발자는 이것저것 찾아서 추가할 필요가 없습니다. **Gradle로 작성하면** "Maven 말고 Gradle 쓰는 프로젝트도 많잖아요?" 김개발 씨가 물었습니다. 박시니어 씨가 Gradle 예제를 보여줬습니다: ```groovy // build.gradle plugins { id 'org.springframework.boot' version '3.2.0' id 'io.spring.dependency-management' version '1.1.4' } ext { set('springCloudVersion', "2024.0.0") } dependencies { implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' implementation 'org.springframework.cloud:spring-cloud-starter-gateway' implementation 'org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j' } dependencyManagement { imports { mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}" } } ``` 개념은 동일합니다. BOM을 임포트하고, 개별 의존성에는 버전을 명시하지 않습니다. **버전 충돌 해결하기** "만약 제가 직접 버전을 명시하면 어떻게 되나요?" 김개발 씨가 궁금해했습니다. "그럼 BOM의 버전을 무시하고 여러분이 명시한 버전을 사용해요." 박시니어 씨가 대답했습니다. "하지만 이건 위험한 행동이에요." 예를 들어 BOM은 게이트웨이 4.1.0을 사용하라고 하는데, 개발자가 4.0.5를 명시하면 다른 컴포넌트와 호환성 문제가 생길 수 있습니다. 버전을 직접 명시하는 것은 특별한 이유가 있을 때만 하세요. **스프링 부트와의 관계** 코드를 보면 스프링 부트 BOM과 스프링 클라우드 BOM을 모두 추가했습니다. 둘의 관계는 무엇일까요? 스프링 부트는 **기본 플랫폼**입니다. 웹, 데이터베이스, 시큐리티 등 일반적인 스프링 애플리케이션에 필요한 것들을 관리합니다. 스프링 클라우드는 **확장 플랫폼**입니다. MSA에 특화된 기능들을 추가합니다. 스프링 부트 위에 얹어지는 레이어라고 생각하면 됩니다. 중요한 것은 **버전 호환성**입니다. 스프링 부트 3.2를 쓴다면 스프링 클라우드 2024.0.x를 써야 합니다. 공식 문서의 호환성 표를 항상 확인하세요. **실무 팁 - 버전 프로퍼티 사용** 박시니어 씨가 실무 팁을 알려줬습니다. "버전을 ` `에 정의하는 습관을 들이세요." ```xml 2024.0.0 ``` 이렇게 하면 버전을 업그레이드할 때 한 곳만 수정하면 됩니다. 여러 곳에 흩어져 있으면 빠뜨리기 쉽습니다. **불필요한 의존성 피하기** "모든 스타터를 다 추가하면 안 되나요?" 김개발 씨가 물었습니다. "절대 안 돼요!" 박시니어 씨가 단호하게 말했습니다. "필요한 것만 추가하세요." 예를 들어 게이트웨이 서비스라면 `spring-cloud-starter-gateway`만 추가합니다. 유레카 클라이언트나 컨피그 클라이언트는 필요하지 않습니다. 불필요한 의존성은 애플리케이션을 무겁게 만들고 시작 시간을 늘립니다. **의존성 확인하기** "어떤 버전이 실제로 사용되는지 확인하려면 어떻게 하나요?" 김개발 씨의 마지막 질문이었습니다. Maven에서는 `mvn dependency:tree` 명령어를 사용합니다. Gradle에서는 `./gradlew dependencies`를 사용합니다. 이 명령어는 모든 의존성을 트리 구조로 보여줍니다. 여기서 버전 충돌이 있는지, 예상한 버전이 사용되는지 확인할 수 있습니다. **정리** 김개발 씨는 이제 의존성 관리의 핵심을 이해했습니다. BOM으로 버전을 통합 관리하고, 스타터로 간편하게 기능을 추가하고, 필요한 것만 선택적으로 사용하는 것. 이 세 가지만 기억하면 됩니다. **실전 팁** 💡 - 항상 BOM을 사용하여 버전 충돌을 방지하세요 - 스타터 의존성을 활용하면 필요한 라이브러리를 한 번에 추가할 수 있습니다 - mvn dependency:tree로 실제 사용되는 버전을 확인하세요 --- ## 6. 버전_호환성 김개발 씨는 드디어 첫 스프링 클라우드 프로젝트를 시작했습니다. 스프링 부트 3.2와 스프링 클라우드 2024.0.0을 선택했습니다. 그런데 빌드를 하자마자 에러가 쏟아졌습니다. "자바 버전이 맞지 않습니다"라는 메시지가 떴습니다. "아, 자바 버전도 맞춰야 하는구나..." 좌절한 김개발 씨는 또다시 박시니어 씨를 찾아갔습니다. 스프링 클라우드의 버전 호환성은 **자바 버전**, **스프링 부트 버전**, **스프링 클라우드 버전** 세 가지를 모두 고려해야 합니다. 2024.0.x는 스프링 부트 3.2+ 및 자바 17+를 요구합니다. 2023.0.x는 스프링 부트 3.0-3.1과 호환되며, 2022.0.x는 스프링 부트 2.6-2.7과 호환됩니다. 잘못된 조합은 런타임 에러나 빌드 실패를 유발합니다. 다음 코드를 살펴봅시다. ```java // application.properties - 올바른 버전 조합 예시 // 조합 1: 최신 스택 (2025년 권장) // Java 17 또는 21 // Spring Boot 3.2.0+ // Spring Cloud 2024.0.0+ spring.application.name=user-service spring.cloud.compatibility.verifySpringBootVersion=true // 조합 2: 안정적인 스택 (레거시 프로젝트) // Java 11 또는 17 // Spring Boot 2.7.x // Spring Cloud 2022.0.x // 잘못된 조합 예시 (빌드 실패!) // Java 8 + Spring Boot 3.x (불가능) // Spring Boot 2.x + Spring Cloud 2024.x (불가능) // Java 11 + Spring Cloud 2024.x (불가능) // build.gradle - 버전 호환성 검증 plugins { id 'org.springframework.boot' version '3.2.0' id 'java' } java { sourceCompatibility = '17' // Spring Boot 3.x는 Java 17 이상 필요 } ext { set('springCloudVersion', "2024.0.0") // Spring Boot 3.2와 호환 } ``` 박시니어 씨는 화이트보드에 큰 표를 그렸습니다. 가로축에는 스프링 부트 버전, 세로축에는 스프링 클라우드 버전이 적혀 있었습니다. "버전 호환성은 퍼즐 맞추기와 같아요." **세 가지 버전의 조화** "스프링 클라우드를 사용하려면 세 가지 버전을 맞춰야 해요." 박시니어 씨가 설명했습니다. 첫째, **자바 버전**입니다. 스프링 부트 3.x는 자바 17 이상을 요구합니다. 자바 8이나 11로는 실행할 수 없습니다. 반면 스프링 부트 2.x는 자바 8부터 지원합니다. 둘째, **스프링 부트 버전**입니다. 스프링 클라우드는 스프링 부트 위에서 동작하므로 호환되는 스프링 부트 버전을 선택해야 합니다. 셋째, **스프링 클라우드 버전**입니다. 각 스프링 클라우드 릴리즈는 특정 스프링 부트 버전 범위를 지원합니다. 이 세 가지가 모두 맞아떨어져야 프로젝트가 정상적으로 동작합니다. **2025년 권장 조합** "지금 새 프로젝트를 시작한다면 어떤 조합을 쓰나요?" 김개발 씨가 물었습니다. 박시니어 씨가 추천 조합을 알려줬습니다: - **자바 17** 또는 **자바 21** (LTS 버전) - **스프링 부트 3.2.x** 이상 - **스프링 클라우드 2024.0.x** 자바 21은 최신 LTS 버전이지만, 아직 검증이 덜 된 면이 있습니다. 안정성을 원한다면 자바 17을 선택하세요. 많은 기업이 자바 17을 표준으로 사용하고 있습니다. **레거시 프로젝트 조합** "회사에서 옛날 프로젝트를 유지보수하고 있다면 어떻게 하나요?" 김개발 씨의 질문이었습니다. "레거시 프로젝트는 급하게 업그레이드하지 않아도 돼요." 박시니어 씨가 대답했습니다. 레거시 조합은 이렇습니다: - **자바 11** (또는 자바 8) - **스프링 부트 2.7.x** - **스프링 클라우드 2022.0.x** 스프링 부트 2.7은 2024년까지 공식 지원이 계속됩니다. 따라서 당장 3.x로 마이그레이션하지 않아도 괜찮습니다. 하지만 장기적으로는 계획을 세워야 합니다. **호환성 표 보는 법** 박시니어 씨가 스프링 공식 문서를 열었습니다. "이 표를 북마크해두세요." 스프링 클라우드 공식 문서에는 버전 호환성 표가 있습니다. 예를 들면: | Spring Cloud | Spring Boot | Java | |--------------|-------------|------| | 2024.0.x | 3.2.x, 3.3.x | 17, 21 | | 2023.0.x | 3.0.x, 3.1.x | 17, 21 | | 2022.0.x | 2.6.x, 2.7.x | 8, 11, 17 | 이 표만 보면 어떤 조합이 가능한지 한눈에 알 수 있습니다. **왜 호환성이 중요한가** 김개발 씨가 의문을 품었습니다. "버전이 안 맞으면 그냥 경고만 뜨는 거 아닌가요?" "아니요, 애플리케이션이 아예 시작되지 않을 수 있어요." 박시니어 씨가 진지하게 말했습니다. 예를 들어 스프링 부트 2.7에 스프링 클라우드 2024.0.x를 사용하면 `ClassNotFoundException`이나 `NoSuchMethodError` 같은 런타임 에러가 발생합니다. 스프링 클라우드 2024.0.x는 스프링 부트 3.x의 API를 사용하기 때문입니다. 또한 자바 버전이 맞지 않으면 빌드 자체가 실패합니다. 스프링 부트 3.x의 바이트코드는 자바 17 이상에서만 실행 가능합니다. **마이그레이션 전략** "그럼 레거시 프로젝트를 업그레이드하려면 어떻게 해야 하나요?" 김개발 씨가 걱정스럽게 물었습니다. 박시니어 씨가 단계적 마이그레이션 전략을 설명했습니다: 1단계: 자바 버전 업그레이드 (8 → 11 → 17) 2단계: 스프링 부트 버전 업그레이드 (2.6 → 2.7) 3단계: 스프링 클라우드 버전 업그레이드 (2021.x → 2022.0.x) 4단계: 스프링 부트 3.x로 마이그레이션 (큰 변경) 5단계: 스프링 클라우드 2024.x로 마이그레이션 한 번에 모든 것을 바꾸려고 하지 마세요. 단계적으로 천천히 업그레이드하고, 각 단계마다 충분히 테스트하세요. **자동 검증 설정** 코드를 보면 `spring.cloud.compatibility.verifySpringBootVersion=true`라는 설정이 있습니다. 이것을 활성화하면 스프링 클라우드가 시작할 때 스프링 부트 버전을 확인합니다. 만약 호환되지 않는 버전이라면 애플리케이션이 시작되지 않고 명확한 에러 메시지를 보여줍니다. "Spring Cloud 2024.0.0 requires Spring Boot 3.2.0 or higher. You are using 3.1.5." 이런 에러 메시지 덕분에 문제를 빨리 발견할 수 있습니다. **실무에서의 선택** 박시니어 씨는 자신의 경험을 공유했습니다. "우리 회사는 3년 된 프로젝트가 있어요. 아직 스프링 부트 2.7에 스프링 클라우드 2022.0.4를 쓰고 있죠." "곧 업그레이드하지 않나요?" 김개발 씨가 물었습니다. "올해 중에 할 계획이에요. 하지만 서두르지 않아요. 현재 버전도 잘 동작하고 보안 패치도 받고 있으니까요. 업그레이드는 비즈니스 가치가 명확할 때 하는 거예요." 무조건 최신 버전을 쫓을 필요는 없습니다. 안정성과 비즈니스 요구사항을 고려해서 결정하세요. **의존성 업그레이드 팁** "버전을 바꿀 때 주의할 점이 있나요?" 김개발 씨의 마지막 질문이었습니다. 박시니어 씨가 실전 팁을 알려줬습니다: 첫째, 릴리즈 노트를 꼭 읽으세요. Breaking changes(호환성이 깨지는 변경)가 있는지 확인하세요. 둘째, 로컬 환경에서 먼저 테스트하세요. 빌드가 성공하는지, 테스트가 통과하는지 확인하세요. 셋째, 스테이징 환경에 배포해서 통합 테스트를 수행하세요. 다른 마이크로서비스와의 호환성을 확인하세요. 넷째, 프로덕션 배포 시 롤백 계획을 준비하세요. 문제가 생기면 즉시 이전 버전으로 되돌릴 수 있어야 합니다. **정리** 김개발 씨는 이제 버전 호환성의 중요성을 이해했습니다. 자바, 스프링 부트, 스프링 클라우드 세 가지 버전이 조화를 이뤄야 한다는 것. 그리고 무조건 최신 버전보다는 프로젝트 상황에 맞는 안정적인 버전을 선택해야 한다는 것을 배웠습니다. **실전 팁** 💡 - 스프링 공식 문서의 버전 호환성 표를 항상 확인하세요 - 마이그레이션은 단계적으로 진행하고 각 단계마다 충분히 테스트하세요 - spring.cloud.compatibility.verifySpringBootVersion=true 설정으로 자동 검증을 활성화하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Spring Cloud

언어: Java

태그: Spring Cloud, MSA, Microservices, Service Discovery, API Gateway

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

스프링 클라우드 완벽 입문 가이드

목차

1. 스프링 클라우드란

2. 스프링 클라우드 2025 버전

3. 주요 컴포넌트 소개

4. Netflix OSS vs 스프링 클라우드

5. 의존성 관리

6. 버전 호환성

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

Helm 마이크로서비스 패키징 완벽 가이드

관찰 가능한 마이크로서비스 완벽 가이드

Prometheus 메트릭 수집 완벽 가이드