마이크로서비스 아키텍처 완벽 가이드

모놀리식에서 마이크로서비스로의 전환은 현대 소프트웨어 개발의 핵심 화두입니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 관점에서 마이크로서비스의 개념, 장단점, 설계 원칙을 스토리텔링으로 풀어냅니다.

1. 모놀리식 아키텍처란

신입 개발자 김개발 씨가 회사에 입사하고 처음 마주한 프로젝트는 거대한 쇼핑몰 시스템이었습니다. 회원 관리부터 주문, 결제, 배송까지 모든 기능이 하나의 프로젝트에 담겨 있었습니다.

"이게 바로 모놀리식 아키텍처입니다." 선배 박시니어 씨가 설명을 시작했습니다.

모놀리식 아키텍처는 애플리케이션의 모든 기능이 하나의 큰 덩어리로 구성된 전통적인 소프트웨어 구조입니다. 마치 모든 방이 연결된 하나의 큰 건물과 같습니다.

배포할 때도 전체를 한꺼번에 배포하고, 실행할 때도 하나의 프로세스로 동작합니다.

다음 코드를 살펴봅시다.

// 전형적인 모놀리식 Spring Boot 애플리케이션 구조
@SpringBootApplication
public class ShoppingMallApplication {
    public static void main(String[] args) {
        // 회원, 주문, 결제, 배송 모든 기능이 하나의 애플리케이션으로 실행
        SpringApplication.run(ShoppingMallApplication.class, args);
    }
}

// 모든 비즈니스 로직이 한 프로젝트에 존재
@RestController
public class AllInOneController {
    @Autowired UserService userService;        // 회원 관리
    @Autowired OrderService orderService;      // 주문 관리
    @Autowired PaymentService paymentService;  // 결제 관리
    @Autowired DeliveryService deliveryService; // 배송 관리
}

김개발 씨는 프로젝트 구조를 살펴보며 궁금증이 생겼습니다. 회원 관리 코드, 주문 처리 코드, 결제 시스템, 배송 추적까지 모든 것이 하나의 거대한 프로젝트 안에 들어 있었습니다.

파일만 수천 개가 넘었고, 빌드하는 데만 10분이 걸렸습니다. "왜 이렇게 다 같이 묶여 있나요?" 김개발 씨가 물었습니다.

박시니어 씨는 웃으며 대답했습니다. "이게 바로 모놀리식 아키텍처예요.

오래전부터 사용해온 가장 전통적인 방식이죠." 모놀리식 아키텍처란 무엇일까요? 쉽게 비유하자면, 모놀리식은 마치 백화점과 같습니다.

의류 매장, 식품 매장, 가전제품 매장이 모두 하나의 건물 안에 있습니다. 손님은 한 건물에서 모든 쇼핑을 해결할 수 있습니다.

하지만 건물 한쪽에서 화재가 나면 전체 백화점이 영업을 중단해야 합니다. 소프트웨어도 마찬가지입니다.

모놀리식 아키텍처에서는 사용자 인증, 상품 관리, 주문 처리, 결제, 배송 추적 등 모든 기능이 하나의 코드베이스에 존재합니다. 하나의 데이터베이스를 공유하고, 하나의 서버 프로세스로 실행됩니다.

이런 구조는 초기 개발 단계에서 매우 유리했습니다. 김개발 씨가 입사하기 10년 전, 이 쇼핑몰을 처음 개발할 때는 팀원이 단 3명이었습니다.

그때는 모든 기능을 한곳에 모아두는 것이 효율적이었습니다. 코드를 수정하고 테스트하고 배포하는 과정이 단순했습니다.

하나의 프로젝트만 관리하면 되었으니까요. 프로젝트 구조도 직관적이었습니다.

controller 패키지에 모든 컨트롤러가, service 패키지에 모든 서비스가, repository 패키지에 모든 데이터 접근 코드가 정리되어 있었습니다. 신입 개발자가 와도 금방 파악할 수 있는 구조였습니다.

배포도 간단했습니다. 하나의 WAR 파일이나 JAR 파일을 만들어서 서버에 올리면 끝이었습니다.

별도의 서비스 간 통신을 고민할 필요도 없었습니다. 모든 코드가 같은 메모리 공간에서 실행되니까요.

하지만 시간이 흐르면서 문제가 생기기 시작했습니다. 회사가 성장하고 개발팀이 20명으로 늘어났습니다.

여러 팀이 같은 코드베이스를 수정하다 보니 충돌이 잦았습니다. 누군가 결제 모듈을 수정하면, 전혀 관련 없는 배송 모듈에 영향을 미치는 일이 발생했습니다.

더 큰 문제는 배포였습니다. 회원 관리 기능에 작은 버그 하나를 고치려 해도, 전체 애플리케이션을 다시 빌드하고 배포해야 했습니다.

빌드에 10분, 배포에 5분, 서버 재시작에 3분이 걸렸습니다. 그사이 모든 서비스가 중단되었습니다.

김개발 씨는 고개를 끄덕였습니다. "그래서 요즘 마이크로서비스로 전환하려는 거군요." 박시니어 씨가 미소 지었습니다.

"정확해요. 하지만 모놀리식이 나쁜 것만은 아닙니다.

작은 프로젝트나 초기 스타트업에서는 여전히 좋은 선택이죠." 실제로 모놀리식 아키텍처는 여러 장점이 있습니다. 개발 초기에 빠르게 기능을 추가할 수 있고, 디버깅도 쉽습니다.

모든 코드가 한곳에 있으니 IDE에서 쉽게 추적할 수 있습니다. 트랜잭션 관리도 간단합니다.

하나의 데이터베이스 트랜잭션으로 여러 테이블을 한번에 처리할 수 있으니까요. 하지만 서비스가 커지고 팀이 커지면, 모놀리식의 한계가 명확해집니다.

그때가 바로 새로운 아키텍처를 고민할 시점입니다.

실전 팁

💡 - 소규모 프로젝트나 스타트업 초기에는 모놀리식이 여전히 효율적인 선택입니다

팀 규모가 10명 이하이고 배포 빈도가 낮다면 굳이 복잡한 아키텍처로 갈 필요가 없습니다

2. 마이크로서비스 아키텍처란

점심시간, 김개발 씨는 박시니어 씨와 카페테리아에서 마주 앉았습니다. "그렇다면 마이크로서비스는 정확히 뭔가요?" 김개발 씨가 물었습니다.

박시니어 씨는 냅킨에 그림을 그리기 시작했습니다.

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누는 설계 방식입니다. 각 서비스는 독자적으로 개발, 배포, 확장할 수 있으며, 자체 데이터베이스를 가질 수 있습니다.

서비스 간 통신은 주로 HTTP REST API나 메시지 큐를 통해 이루어집니다.

다음 코드를 살펴봅시다.

// 회원 서비스 - 독립적인 Spring Boot 애플리케이션
@SpringBootApplication
@RestController
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }

    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        // 회원 정보만 처리하는 독립적인 서비스
        return userRepository.findById(id);
    }
}

// 주문 서비스 - 별도의 독립적인 애플리케이션
@SpringBootApplication
@RestController
public class OrderServiceApplication {
    @Autowired RestTemplate restTemplate;

    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderRequest request) {
        // 회원 서비스를 HTTP로 호출
        User user = restTemplate.getForObject(
            "http://user-service/users/" + request.getUserId(),
            User.class
        );
        return orderRepository.save(new Order(user, request));
    }
}

박시니어 씨가 냅킨에 그린 그림에는 여러 개의 작은 상자들이 있었습니다. 각 상자에는 '회원 서비스', '주문 서비스', '결제 서비스', '배송 서비스'라고 적혀 있었습니다.

"모놀리식에서는 이 모든 기능이 하나의 큰 상자 안에 있었어요. 하지만 마이크로서비스에서는 각 기능이 독립된 서비스로 분리됩니다." 마이크로서비스를 이해하는 가장 좋은 비유는 전문 음식점 거리입니다.

백화점 푸드코트(모놀리식)가 아니라, 이탈리아 레스토랑, 일식당, 중국집, 카페가 각각 독립된 건물로 운영되는 것과 같습니다. 각 음식점은 자체 주방, 자체 직원, 자체 재료 창고를 가지고 있습니다.

손님이 줄어들면 한 음식점만 문을 닫으면 됩니다. 다른 음식점들은 계속 영업합니다.

마이크로서비스도 마찬가지입니다. 회원 서비스는 오직 회원 가입, 로그인, 프로필 관리만 담당합니다.

주문 서비스는 주문 생성과 조회만 처리합니다. 결제 서비스는 결제 처리만 전담합니다.

각 서비스는 자체 데이터베이스를 가지고, 독립적으로 배포되며, 필요하면 다른 서비스를 HTTP API로 호출합니다. 이런 구조가 왜 등장했을까요?

몇 년 전, 쇼핑몰 서비스에 큰 문제가 생겼습니다. 블랙프라이데이 세일 때 주문이 폭주하면서 서버가 다운되었습니다.

문제는 주문 처리 부분이었지만, 전체 시스템이 멈췄습니다. 회원 로그인도 안 되고, 상품 조회도 안 되고, 고객센터 조회도 마비되었습니다.

"하나가 죽으니까 전부 죽는 거죠." 박시니어 씨가 한숨을 쉬었습니다. 마이크로서비스로 전환한 후에는 달라졌습니다.

주문 서비스가 과부하로 느려져도, 회원 서비스와 상품 서비스는 정상적으로 작동했습니다. 주문만 잠시 지연될 뿐, 사용자는 여전히 로그인하고 상품을 둘러볼 수 있었습니다.

각 서비스는 완전히 독립적입니다. 회원 서비스는 Java Spring Boot로 개발되어 있고, 주문 서비스는 Node.js로, 결제 서비스는 Python으로 개발할 수도 있습니다.

각 팀이 가장 적합한 기술 스택을 선택할 수 있습니다. 실제로 많은 기업들이 이렇게 운영합니다.

배포도 독립적입니다. 회원 서비스에 버그를 고쳤다면, 회원 서비스만 재배포하면 됩니다.

다른 서비스들은 영향을 받지 않습니다. 전체 시스템을 내릴 필요가 없습니다.

확장도 유연합니다. 블랙프라이데이처럼 주문이 폭주할 때는 주문 서비스의 서버만 10대로 늘립니다.

회원 서비스는 2대면 충분하니 그대로 둡니다. 자원을 효율적으로 사용할 수 있습니다.

코드를 다시 살펴보겠습니다. 회원 서비스와 주문 서비스는 각각 별도의 Spring Boot 애플리케이션입니다.

독립적으로 실행되고, 독립적으로 배포됩니다. 주문 서비스가 회원 정보가 필요하면, RestTemplate을 사용해서 회원 서비스의 API를 HTTP로 호출합니다.

이것이 바로 서비스 간 통신입니다. 같은 메모리 공간의 메서드 호출이 아니라, 네트워크를 통한 API 호출입니다.

"하지만 네트워크 호출은 느리지 않나요?" 김개발 씨가 물었습니다. "맞아요.

그래서 트레이드오프가 있죠. 속도를 조금 포기하고, 대신 유연성과 안정성을 얻는 겁니다." 실제 기업들의 사례를 보면 이해가 쉽습니다.

Netflix는 수백 개의 마이크로서비스로 운영됩니다. 추천 서비스, 비디오 스트리밍 서비스, 결제 서비스 등이 모두 독립적입니다.

Amazon도 마찬가지입니다. 이커머스 거대 기업들이 마이크로서비스를 선택한 이유가 있습니다.

김개발 씨는 이제 이해가 되었습니다. 마이크로서비스는 복잡하지만, 큰 시스템을 안정적으로 운영하기 위한 현실적인 선택이었습니다.

실전 팁

💡 - 각 마이크로서비스는 단일 책임 원칙을 따라야 합니다. 한 가지 업무 영역만 담당하세요

서비스 간 통신은 API Gateway를 통해 중앙에서 관리하면 더 효율적입니다

3. 마이크로서비스의 장점

다음 날 아침, 팀 회의에서 CTO가 발표했습니다. "우리도 마이크로서비스로 전환합니다." 회의실이 술렁였습니다.

김개발 씨는 손을 들었습니다. "정확히 어떤 점이 좋아지나요?" CTO는 화이트보드에 다가갔습니다.

마이크로서비스의 핵심 장점은 독립적인 배포와 확장, 기술 스택의 자유, 장애 격리, 팀 자율성 증가입니다. 각 서비스가 독립적으로 운영되므로 시스템 전체의 유연성과 안정성이 크게 향상됩니다.

대규모 조직에서 여러 팀이 동시에 개발할 때 특히 효과적입니다.

다음 코드를 살펴봅시다.

// 주문 서비스만 독립적으로 스케일 아웃
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 10  # 블랙프라이데이 대비 주문 서비스만 10개로 확장
  template:
    spec:
      containers:
      - name: order-service
        image: order-service:v2.1

// 회원 서비스는 2개 인스턴스만 유지
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 2  # 회원 서비스는 트래픽이 적어 2개만 유지
  template:
    spec:
      containers:
      - name: user-service
        image: user-service:v1.5

CTO는 화이트보드에 네 가지 항목을 적었습니다. 독립 배포, 선택적 확장, 장애 격리, 기술 자유.

김개발 씨는 메모를 시작했습니다. 첫 번째, 독립적인 배포입니다.

모놀리식 시절을 떠올려보겠습니다. 회원 관리 팀이 작은 버그를 고쳤습니다.

하지만 배포하려면 전체 시스템을 내려야 했습니다. 주문팀, 결제팀, 배송팀 모두와 일정을 조율해야 했습니다.

"다음 주 화요일 새벽 2시에 배포합시다." 모든 팀이 대기해야 했습니다. 마이크로서비스에서는 다릅니다.

회원 서비스 팀이 버그를 고치면, 회원 서비스만 재배포합니다. 다른 팀에게 알릴 필요도 없습니다.

오후 3시에 조용히 배포하고 끝입니다. 다른 서비스들은 계속 정상 작동합니다.

이것이 지속적 배포를 가능하게 합니다. Netflix는 하루에 수천 번 배포합니다.

각 팀이 독립적으로 빠르게 기능을 출시할 수 있기 때문입니다. 두 번째, 선택적 확장입니다.

블랙프라이데이를 준비한다고 가정해봅시다. 주문이 평소의 100배로 폭증할 것입니다.

모놀리식이라면? 전체 애플리케이션 서버를 100대로 늘려야 합니다.

회원 관리, 상품 조회, 고객센터 기능까지 모두 100배로 늘어납니다. 낭비입니다.

마이크로서비스에서는 주문 서비스만 100대로 늘립니다. 결제 서비스는 50대, 회원 서비스는 5대면 충분합니다.

위의 쿠버네티스 설정 예제를 보면, 각 서비스의 replicas를 독립적으로 설정합니다. 비용을 크게 절감할 수 있습니다.

실제로 쿠팡은 새벽 배송 주문이 몰리는 시간대에 주문 서비스만 자동으로 확장합니다. 오전에는 다시 축소됩니다.

클라우드 비용을 최적화하는 핵심 전략입니다. 세 번째, 장애 격리입니다.

어느 날 밤, 결제 시스템에 장애가 발생했습니다. 외부 PG사의 API가 다운되었습니다.

모놀리식이었다면? 결제 모듈에서 발생한 예외가 전체 애플리케이션을 멈출 수 있습니다.

회원 로그인도 안 되고, 상품 조회도 안 됩니다. 전면 장애입니다.

마이크로서비스에서는 결제 서비스만 영향을 받습니다. 회원 서비스, 상품 서비스, 주문 조회 서비스는 정상 작동합니다.

사용자는 여전히 쇼핑을 하고 장바구니에 담을 수 있습니다. 결제만 잠시 "일시적 오류"가 뜹니다.

이를 부분 장애라고 합니다. 전체가 죽지 않고 일부만 영향받는 것입니다.

서비스 가용성이 크게 향상됩니다. 네 번째, 기술 스택의 자유입니다.

회원 서비스 팀은 안정적인 Java Spring Boot를 선호합니다. 주문 서비스 팀은 빠른 개발을 위해 Node.js를 선택했습니다.

추천 서비스 팀은 머신러닝을 위해 Python Flask를 사용합니다. 실시간 알림 서비스는 Go로 개발했습니다.

모놀리식에서는 불가능한 일입니다. 모두가 같은 언어, 같은 프레임워크를 써야 합니다.

하지만 마이크로서비스에서는 각 팀이 최적의 도구를 선택할 수 있습니다. 물론 무분별한 기술 선택은 위험합니다.

하지만 적재적소에 맞는 기술을 쓸 수 있다는 것은 큰 장점입니다. 다섯 번째, 팀 자율성입니다.

회원 서비스를 담당하는 팀 A는 완전히 독립적으로 일합니다. 코드 저장소도 따로, 배포 파이프라인도 따로, 데이터베이스도 따로입니다.

다른 팀의 승인을 받을 필요가 없습니다. 빠른 의사결정이 가능합니다.

이것이 Conway의 법칙과도 연결됩니다. "시스템 구조는 조직 구조를 따른다." 마이크로서비스는 자율적인 소규모 팀 구조에 최적화되어 있습니다.

Amazon의 "Two Pizza Team" 원칙을 아시나요? 피자 두 판으로 배불리 먹을 수 있는 크기의 작은 팀이 하나의 서비스를 소유합니다.

각 팀은 독립적으로 혁신하고 빠르게 움직입니다. CTO는 설명을 마치며 말했습니다.

"물론 단점도 있습니다. 하지만 우리 조직 규모와 서비스 특성을 고려하면, 장점이 더 큽니다." 김개발 씨는 고개를 끄덕였습니다.

확실히 큰 조직에서 여러 팀이 협업할 때 마이크로서비스의 장점이 빛을 발하는 것 같았습니다.

실전 팁

💡 - 마이크로서비스의 장점은 조직이 클수록, 트래픽이 많을수록 명확해집니다

작은 스타트업이라면 오히려 모놀리식이 더 효율적일 수 있습니다

4. 마이크로서비스의 단점과 과제

회의가 끝난 후, 김개발 씨는 박시니어 씨에게 조심스럽게 물었습니다. "그런데 단점은 없나요?

너무 좋은 것만 이야기하는 것 같아서요." 박시니어 씨는 쓴웃음을 지었습니다. "단점이요?

엄청 많죠. 한번 앉아보세요."

마이크로서비스는 복잡성 증가, 네트워크 통신 오버헤드, 분산 트랜잭션 관리의 어려움, 운영 부담 증가라는 명확한 단점이 있습니다. 서비스가 늘어날수록 모니터링, 디버깅, 배포 관리가 기하급수적으로 어려워집니다.

제대로 된 인프라와 조직 역량 없이 도입하면 오히려 독이 될 수 있습니다.

다음 코드를 살펴봅시다.

// 분산 트랜잭션의 어려움 예시
@RestController
public class OrderController {
    @Autowired RestTemplate restTemplate;

    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderRequest req) {
        // 1. 재고 차감 (상품 서비스)
        restTemplate.postForObject("http://product-service/reduce", req.getProductId());

        // 2. 결제 처리 (결제 서비스)
        Payment payment = restTemplate.postForObject("http://payment-service/pay", req);

        // 만약 여기서 예외 발생하면?
        // 재고는 이미 차감되었고, 결제도 완료되었는데 주문은 저장 안 됨!
        if (payment.isFailed()) {
            // 어떻게 롤백? 각 서비스에 취소 요청을 보내야 함 (Saga 패턴)
            restTemplate.postForObject("http://product-service/restore", req.getProductId());
            throw new PaymentFailedException();
        }

        return orderRepository.save(new Order(req));
    }
}

박시니어 씨는 자신의 노트북을 열었습니다. 화면에는 수십 개의 서비스 목록이 떠 있었습니다.

회원, 주문, 결제, 배송, 알림, 추천, 검색, 리뷰, 쿠폰, 포인트, 통계, 로그... 끝이 없었습니다.

"이게 우리 시스템입니다. 40개가 넘는 마이크로서비스가 돌아가고 있어요." 첫 번째 문제, 시스템 복잡도 폭증입니다.

모놀리식 시절에는 하나의 프로젝트만 관리하면 되었습니다. 이제는 40개의 독립된 프로젝트를 관리합니다.

각각 다른 저장소, 다른 배포 파이프라인, 다른 모니터링 대시보드를 가지고 있습니다. 버그를 추적하는 것만 해도 악몽입니다.

사용자가 "주문이 안 돼요"라고 신고하면, 어느 서비스의 문제인지부터 찾아야 합니다. 회원 서비스?

상품 서비스? 주문 서비스?

결제 서비스? 로그를 40개 서비스에서 다 뒤져야 합니다.

"분산 추적 시스템을 도입해야 해요. Zipkin이나 Jaeger 같은 도구로요.

안 그러면 디버깅이 불가능합니다." 박시니어 씨가 한숨을 쉬었습니다. 두 번째 문제, 네트워크 통신 오버헤드입니다.

모놀리식에서는 OrderService가 UserService를 호출할 때 그냥 메서드 호출이었습니다. 메모리 내에서 즉시 처리됩니다.

마이크로초(microsecond) 단위입니다. 마이크로서비스에서는 네트워크를 타야 합니다.

HTTP 요청을 만들고, 네트워크를 통해 전송하고, 다른 서버가 받아서 처리하고, 응답을 돌려보냅니다. 밀리초(millisecond) 단위입니다.

1000배 느립니다. 하나의 주문을 처리하는 데 10개 서비스를 거친다면?

네트워크 호출이 10번입니다. 각각 50ms씩만 걸려도 500ms입니다.

반 초가 걸립니다. 사용자 경험이 나빠집니다.

"그래서 캐싱 전략이 아주 중요해요. Redis 같은 걸 적극 활용해야 합니다." 세 번째 문제, 분산 트랜잭션의 어려움입니다.

위의 코드 예제를 다시 보겠습니다. 주문을 생성하는 과정에서 세 가지 작업이 일어납니다.

재고 차감, 결제 처리, 주문 저장. 각각 다른 서비스입니다.

만약 결제는 성공했는데 주문 저장에서 에러가 나면? 결제는 완료되었지만 주문 기록은 없습니다.

고객은 돈만 빠져나간 겁니다. 심각한 문제입니다.

모놀리식에서는 간단했습니다. @Transactional 어노테이션 하나면 끝입니다.

하나라도 실패하면 전부 롤백됩니다. 마이크로서비스에서는?

각 서비스가 독립된 데이터베이스를 씁니다. 분산 트랜잭션을 구현해야 합니다.

Saga 패턴, Two-Phase Commit 같은 복잡한 패턴이 필요합니다. "Saga 패턴은 각 단계마다 보상 트랜잭션(compensating transaction)을 준비하는 거예요.

결제가 실패하면 재고 복구 API를 호출하는 식이죠. 코드가 훨씬 복잡해집니다." 네 번째 문제, 운영 부담 증가입니다.

40개의 서비스를 운영한다는 것은 40개의 서버를 관리한다는 뜻입니다. 물론 쿠버네티스 같은 오케스트레이션 도구를 씁니다.

하지만 그것도 배워야 하고, 설정해야 하고, 모니터링해야 합니다. 각 서비스의 상태를 체크하는 헬스체크, 로그 수집, 메트릭 모니터링, 알람 설정, 배포 자동화...

인프라 엔지니어가 최소 2-3명은 필요합니다. "우리 회사는 DevOps 팀이 따로 있어요.

그들이 쿠버네티스와 프로메테우스, 그라파나를 관리하죠. 작은 회사라면 감당하기 어렵습니다." 다섯 번째 문제, 데이터 일관성입니다.

각 서비스가 독립된 데이터베이스를 가지므로, 전체 시스템의 데이터 일관성을 유지하기 어렵습니다. 회원 서비스의 사용자 이름이 바뀌었다면, 주문 서비스의 주문 기록도 업데이트해야 할까요?

이런 문제를 해결하려면 이벤트 기반 아키텍처를 도입해야 합니다. Kafka 같은 메시지 큐를 써서 데이터 변경을 다른 서비스에 전파합니다.

또 다른 복잡도가 추가됩니다. 김개발 씨는 머리가 지끈거렸습니다.

"그럼 왜 마이크로서비스를 하는 건가요?" 박시니어 씨가 미소 지었습니다. "트레이드오프예요.

복잡도는 증가하지만, 대규모 시스템을 안정적으로 운영하고, 빠르게 기능을 출시하려면 감수해야 하는 비용이죠. 작은 회사라면 절대 추천 안 합니다.

하지만 우리 정도 규모라면 필수입니다." 실제로 많은 스타트업이 너무 일찍 마이크로서비스를 도입했다가 실패합니다. 인프라 구축에 6개월을 쓰고, 정작 비즈니스 기능은 개발 못 합니다.

조직이 준비되지 않았는데 아키텍처만 먼저 바꾸면 재앙입니다. "일단 모놀리식으로 시작하세요.

충분히 커지면 그때 전환하는 게 정석입니다." 박시니어 씨의 조언이었습니다.

실전 팁

💡 - 마이크로서비스는 조직이 작고 트래픽이 적을 때는 오히려 독이 됩니다

분산 추적, 로그 수집, 서비스 메시 같은 인프라 도구 없이는 운영이 불가능합니다

5. 언제 마이크로서비스를 선택할까

주말이 지나고 월요일 아침, 김개발 씨는 커피를 마시며 고민에 빠졌습니다. "우리 팀이 새 프로젝트를 시작하는데, 마이크로서비스로 해야 할까요?" 박시니어 씨가 웃으며 물었습니다.

"팀이 몇 명인데요?"

마이크로서비스 도입 판단 기준은 팀 규모, 트래픽 규모, 도메인 복잡도, 배포 빈도, 조직의 기술 역량입니다. 일반적으로 팀이 10명 이하이고 트래픽이 적다면 모놀리식으로 시작하는 것이 현명합니다.

명확한 비즈니스 이유 없이 유행만 따라 도입하면 실패합니다.

다음 코드를 살펴봅시다.

// 마이크로서비스 도입 판단 체크리스트 (주석으로 정리)
// 1. 팀 규모: 15명 이상의 개발팀?
boolean largeTeam = developerCount >= 15;

// 2. 트래픽: 일일 활성 사용자 10만 이상?
boolean highTraffic = dailyActiveUsers >= 100000;

// 3. 배포 빈도: 주 5회 이상 배포?
boolean frequentDeployment = deploymentsPerWeek >= 5;

// 4. 도메인 복잡도: 3개 이상의 명확히 분리된 도메인?
boolean complexDomain = distinctDomains >= 3;

// 5. 인프라 역량: Kubernetes, Docker 운영 가능?
boolean hasInfraTeam = devOpsEngineers >= 2;

// 모든 조건이 true면 마이크로서비스 고려
if (largeTeam && highTraffic && frequentDeployment
    && complexDomain && hasInfraTeam) {
    architecture = "Microservices";
} else {
    architecture = "Monolith"; // 아니면 모놀리식으로 시작
}

박시니어 씨는 화이트보드에 의사결정 트리를 그리기 시작했습니다. "마이크로서비스 선택은 기술이 아니라 비즈니스 결정이에요." 첫 번째 질문, 팀이 얼마나 큰가요? 김개발 씨의 새 프로젝트 팀은 3명입니다.

박시니어 씨가 고개를 저었습니다. "3명이면 절대 마이크로서비스 하지 마세요.

인프라 구축하다가 3개월 날립니다." Amazon의 Two Pizza Team 원칙을 기억하시나요? 하나의 마이크로서비스를 5-7명의 작은 팀이 소유합니다.

만약 3개의 마이크로서비스를 만든다면 최소 15명은 필요합니다. 그보다 적으면 한 사람이 여러 서비스를 관리해야 하고, 복잡도만 증가합니다.

"10명 이하 팀이라면 모놀리식으로 시작하세요. 충분히 성장한 후에 전환해도 늦지 않습니다." 두 번째 질문, 트래픽이 얼마나 되나요? 새 프로젝트는 베타 테스트 단계입니다.

사용자가 100명도 안 됩니다. "그럼 더더욱 모놀리식이에요." 박시니어 씨가 단호하게 말했습니다.

마이크로서비스의 핵심 장점 중 하나는 선택적 확장입니다. 하지만 트래픽이 적으면 확장할 필요가 없습니다.

서버 한 대로 충분합니다. 굳이 복잡하게 나눌 이유가 없습니다.

"일일 활성 사용자가 10만 명을 넘어가고, 특정 기능에 트래픽이 몰릴 때 비로소 마이크로서비스의 가치가 드러납니다." 세 번째 질문, 얼마나 자주 배포하나요? 모놀리식에서 배포는 큰 이벤트입니다. 모든 팀이 일정을 맞추고, 주말 새벽에 배포합니다.

한 달에 한두 번 정도입니다. 만약 배포 빈도가 낮다면, 마이크로서비스의 독립 배포 장점이 크게 와닿지 않습니다.

하지만 하루에도 여러 번 배포해야 하는 빠른 조직이라면, 독립 배포는 필수입니다. "Netflix는 하루 수천 번 배포한다고 했죠?

그런 조직은 마이크로서비스 없이는 불가능합니다." 네 번째 질문, 도메인이 명확히 분리되나요? 쇼핑몰을 예로 들겠습니다. 회원 관리, 상품 관리, 주문 처리, 결제, 배송 추적.

각각 명확하게 분리된 바운디드 컨텍스트(Bounded Context)입니다. 서로 독립적으로 발전할 수 있습니다.

하지만 단순한 블로그 서비스라면? 글 작성, 댓글, 좋아요가 서로 밀접하게 연결되어 있습니다.

억지로 나누면 오히려 복잡해집니다. "도메인 주도 설계(DDD)를 공부해보세요.

바운디드 컨텍스트가 명확히 보이면 그때 나누는 겁니다." 다섯 번째 질문, 인프라 역량이 있나요? 마이크로서비스를 운영하려면 Docker, Kubernetes, Service Mesh, 분산 추적, 로그 수집, 메트릭 모니터링 등등... 엄청난 인프라 기술이 필요합니다.

DevOps 엔지니어가 없다면? 개발자가 직접 다 해야 합니다.

기능 개발은 뒷전이고 인프라 공부만 하게 됩니다. "최소한 쿠버네티스를 능숙하게 다룰 수 있는 엔지니어가 1-2명은 있어야 합니다.

아니면 AWS ECS, Google Cloud Run 같은 관리형 서비스를 쓰거나요." 실제 사례를 들어보겠습니다. 스타트업 A는 팀이 5명인데 마이크로서비스로 시작했습니다.

6개월 동안 인프라 구축만 했습니다. 경쟁사는 모놀리식으로 빠르게 기능을 출시하고 시장을 선점했습니다.

스타트업 A는 결국 실패했습니다. 스타트업 B는 모놀리식으로 시작했습니다.

빠르게 성장해서 팀이 50명이 되었습니다. 배포할 때마다 충돌이 생기고, 장애가 잦았습니다.

그때 마이크로서비스로 전환했습니다. 성공적이었습니다.

"타이밍이 중요해요. 너무 이르면 실패하고, 너무 늦으면 레거시에 발목 잡힙니다." 박시니어 씨의 조언은 명확했습니다.

"일단 모놀리식으로 빠르게 시작하세요. 시장을 검증하고, 사용자를 확보하세요.

팀이 15명을 넘고, 트래픽이 감당 안 될 때, 그때 전환하세요." 김개발 씨는 고개를 끄덕였습니다. 새 프로젝트는 모놀리식으로 결정했습니다.

언젠가 충분히 성장하면, 그때 다시 고민하기로 했습니다.

실전 팁

💡 - "마이크로서비스로 시작"보다 "모놀리식으로 시작 후 전환"이 성공률이 훨씬 높습니다

유행을 따르지 말고, 현재 조직의 규모와 역량에 맞는 아키텍처를 선택하세요

6. 마이크로서비스 설계 원칙

몇 달 후, 회사의 쇼핑몰 서비스가 급성장했습니다. 팀은 25명으로 늘어났고, 일일 사용자는 20만 명을 넘었습니다.

CTO가 발표했습니다. "이제 마이크로서비스로 전환합니다." 김개발 씨는 설계 회의에 참석했습니다.

"어떤 원칙으로 설계해야 하나요?"

마이크로서비스 설계의 핵심 원칙은 단일 책임, 독립적 배포 가능성, 느슨한 결합, 데이터 소유권, 장애 격리입니다. 각 서비스는 명확한 비즈니스 기능 하나를 담당하고, 독립적으로 운영되며, 다른 서비스와 최소한으로 결합되어야 합니다.

이런 원칙을 지켜야 마이크로서비스의 장점을 제대로 얻을 수 있습니다.

다음 코드를 살펴봅시다.

// 잘못된 설계: 서비스 간 강한 결합
@RestController
public class OrderService {
    @Autowired UserRepository userRepository; // 다른 서비스의 DB 직접 접근 - 나쁨!

    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderRequest req) {
        User user = userRepository.findById(req.getUserId()); // 강한 결합
        return new Order(user);
    }
}

// 올바른 설계: API를 통한 느슨한 결합
@RestController
public class OrderService {
    @Autowired RestTemplate restTemplate;

    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderRequest req) {
        // 회원 서비스의 API를 호출 - 느슨한 결합
        User user = restTemplate.getForObject(
            "http://user-service/api/users/" + req.getUserId(),
            User.class
        );
        return new Order(user);
    }
}

설계 회의실에 아키텍트 최설계 씨가 들어왔습니다. 화이트보드에 현재 모놀리식 구조를 그리고, 어떻게 나눌지 설명하기 시작했습니다.

첫 번째 원칙, **단일 책임 원칙(Single Responsibility Principle)**입니다. "각 서비스는 딱 하나의 비즈니스 기능만 담당해야 합니다." 최설계 씨가 강조했습니다.

회원 서비스는 오직 회원 가입, 로그인, 프로필 수정만 처리합니다. 주문 관련 로직은 절대 들어가면 안 됩니다.

주문 서비스는 주문 생성, 조회, 취소만 담당합니다. 결제 로직은 결제 서비스로 분리합니다.

"너무 작게 나누면 어떻게 되나요?" 누군가 물었습니다. "좋은 질문이에요.

너무 작게 나누면 서비스 개수가 폭발하고, 관리가 어려워집니다. 적절한 크기가 중요합니다." 적절한 크기란?

한 팀이 소유하고 관리할 수 있는 정도입니다. 보통 하나의 바운디드 컨텍스트가 하나의 마이크로서비스가 됩니다.

도메인 주도 설계(DDD)를 공부하면 이 감각을 익힐 수 있습니다. 두 번째 원칙, 독립적 배포 가능성입니다.

"각 서비스는 다른 서비스에 영향을 주지 않고 독립적으로 배포되어야 합니다." 이를 위해서는 API 버전 관리가 필수입니다. 회원 서비스가 API를 변경할 때, 기존 API도 당분간 유지해야 합니다.

그래야 주문 서비스가 아직 새 API로 전환하지 않아도 동작합니다. 예를 들어, /api/v1/users와 /api/v2/users를 동시에 제공합니다.

주문 서비스는 준비가 되면 천천히 v2로 마이그레이션합니다. 강제로 동시 배포하지 않습니다.

"하위 호환성(Backward Compatibility)을 최대한 유지하세요. API에 필드를 추가하는 건 괜찮지만, 삭제하거나 타입을 바꾸면 다른 서비스가 깨집니다." 세 번째 원칙, **느슨한 결합(Loose Coupling)**입니다.

위의 코드 예제를 보겠습니다. 잘못된 설계에서는 OrderService가 UserRepository를 직접 주입받습니다.

회원 서비스의 데이터베이스를 직접 읽습니다. 이것은 강한 결합입니다.

문제가 뭘까요? 회원 서비스가 데이터베이스 스키마를 변경하면 주문 서비스가 깨집니다.

회원 서비스 팀이 독립적으로 배포할 수 없습니다. 마이크로서비스의 의미가 없어집니다.

올바른 설계는 API를 통해 통신합니다. 주문 서비스는 회원 서비스의 REST API를 호출합니다.

내부 구현은 알 필요가 없습니다. 회원 서비스가 MySQL을 쓰든 PostgreSQL을 쓰든, 주문 서비스는 신경 쓰지 않습니다.

"데이터베이스는 절대 공유하지 마세요. 각 서비스는 자기 데이터베이스를 소유합니다." 네 번째 원칙, 데이터 소유권입니다.

각 마이크로서비스는 자신의 데이터에 대한 완전한 소유권을 가집니다. 회원 데이터는 회원 서비스만 읽고 씁니다.

다른 서비스가 회원 데이터가 필요하면, 반드시 회원 서비스의 API를 호출해야 합니다. "만약 주문 서비스가 회원 이름을 보여줘야 한다면요?" 김개발 씨가 물었습니다.

"두 가지 방법이 있어요. 첫째, 주문할 때 회원 서비스에서 이름을 가져와서 주문 테이블에 복사해둡니다.

둘째, 주문 조회할 때마다 회원 서비스 API를 실시간으로 호출합니다." 첫 번째 방법은 데이터 중복을 허용합니다. 대신 빠릅니다.

두 번째 방법은 항상 최신 데이터를 보장하지만, 네트워크 호출이 필요합니다. 트레이드오프를 고려해서 선택합니다.

다섯 번째 원칙, **장애 격리(Fault Isolation)**입니다. 한 서비스의 장애가 다른 서비스로 전파되지 않도록 설계해야 합니다.

이를 위해 Circuit Breaker 패턴을 사용합니다. 주문 서비스가 회원 서비스를 호출하는데, 회원 서비스가 다운되었다면?

무한정 기다리면 주문 서비스도 멈춥니다. Circuit Breaker는 일정 시간 실패가 계속되면 "회로를 차단"합니다.

더 이상 호출하지 않고 즉시 에러를 반환합니다. "Spring Cloud에서는 Resilience4j를 씁니다.

Netflix Hystrix의 후속이죠." 여섯 번째 원칙, API Gateway 패턴입니다. 클라이언트(모바일 앱, 웹)가 40개의 마이크로서비스를 직접 호출하면 복잡합니다.

대신 하나의 API Gateway를 둡니다. 클라이언트는 게이트웨이만 호출하고, 게이트웨이가 적절한 마이크로서비스로 라우팅합니다.

게이트웨이는 인증, 로깅, 속도 제한(Rate Limiting) 같은 공통 기능도 처리합니다. Spring Cloud Gateway나 Kong 같은 도구를 씁니다.

최설계 씨는 설명을 마치며 경고했습니다. "이런 원칙들을 무시하고 마이크로서비스를 만들면, 분산 모놀리스(Distributed Monolith)가 됩니다.

마이크로서비스의 단점만 가지고 장점은 못 얻는 최악의 상황이죠." 회의가 끝나고, 김개발 씨는 많은 것을 배웠습니다. 마이크로서비스는 단순히 코드를 나누는 게 아니었습니다.

조직, 프로세스, 인프라 전체를 바꾸는 거대한 변화였습니다. 하지만 제대로 설계하고 구축한다면, 큰 조직에서 빠르고 안정적으로 서비스를 운영할 수 있는 강력한 도구가 됩니다.

실전 팁

💡 - 데이터베이스를 절대 공유하지 마세요. 서비스 간 결합도가 높아집니다

Circuit Breaker와 Timeout 설정은 필수입니다. 장애 전파를 막아야 합니다
API 버전 관리를 처음부터 계획하세요. 나중에 추가하기 매우 어렵습니다

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

#Spring#Microservices#Architecture#MSA#DistributedSystems

마이크로서비스 아키텍처 완벽 가이드

# 마이크로서비스 아키텍처 완벽 가이드 모놀리식에서 마이크로서비스로의 전환은 현대 소프트웨어 개발의 핵심 화두입니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 관점에서 마이크로서비스의 개념, 장단점, 설계 원칙을 스토리텔링으로 풀어냅니다. --- ## 목차 1. [모놀리식_아키텍처란](#모놀리식-아키텍처란) 2. [마이크로서비스_아키텍처란](#마이크로서비스-아키텍처란) 3. [마이크로서비스의_장점](#마이크로서비스의-장점) 4. [마이크로서비스의_단점과_과제](#마이크로서비스의-단점과-과제) 5. [언제_마이크로서비스를_선택할까](#언제-마이크로서비스를-선택할까) 6. [마이크로서비스_설계_원칙](#마이크로서비스-설계-원칙) --- ## 1. 모놀리식_아키텍처란 신입 개발자 김개발 씨가 회사에 입사하고 처음 마주한 프로젝트는 거대한 쇼핑몰 시스템이었습니다. 회원 관리부터 주문, 결제, 배송까지 모든 기능이 하나의 프로젝트에 담겨 있었습니다. "이게 바로 모놀리식 아키텍처입니다." 선배 박시니어 씨가 설명을 시작했습니다. **모놀리식 아키텍처**는 애플리케이션의 모든 기능이 하나의 큰 덩어리로 구성된 전통적인 소프트웨어 구조입니다. 마치 모든 방이 연결된 하나의 큰 건물과 같습니다. 배포할 때도 전체를 한꺼번에 배포하고, 실행할 때도 하나의 프로세스로 동작합니다. 다음 코드를 살펴봅시다. ```java // 전형적인 모놀리식 Spring Boot 애플리케이션 구조 @SpringBootApplication public class ShoppingMallApplication { public static void main(String[] args) { // 회원, 주문, 결제, 배송 모든 기능이 하나의 애플리케이션으로 실행 SpringApplication.run(ShoppingMallApplication.class, args); } } // 모든 비즈니스 로직이 한 프로젝트에 존재 @RestController public class AllInOneController { @Autowired UserService userService; // 회원 관리 @Autowired OrderService orderService; // 주문 관리 @Autowired PaymentService paymentService; // 결제 관리 @Autowired DeliveryService deliveryService; // 배송 관리 } ``` 김개발 씨는 프로젝트 구조를 살펴보며 궁금증이 생겼습니다. 회원 관리 코드, 주문 처리 코드, 결제 시스템, 배송 추적까지 모든 것이 하나의 거대한 프로젝트 안에 들어 있었습니다. 파일만 수천 개가 넘었고, 빌드하는 데만 10분이 걸렸습니다. "왜 이렇게 다 같이 묶여 있나요?" 김개발 씨가 물었습니다. 박시니어 씨는 웃으며 대답했습니다. "이게 바로 모놀리식 아키텍처예요. 오래전부터 사용해온 가장 전통적인 방식이죠." **모놀리식 아키텍처**란 무엇일까요? 쉽게 비유하자면, 모놀리식은 마치 백화점과 같습니다. 의류 매장, 식품 매장, 가전제품 매장이 모두 하나의 건물 안에 있습니다. 손님은 한 건물에서 모든 쇼핑을 해결할 수 있습니다. 하지만 건물 한쪽에서 화재가 나면 전체 백화점이 영업을 중단해야 합니다. 소프트웨어도 마찬가지입니다. 모놀리식 아키텍처에서는 사용자 인증, 상품 관리, 주문 처리, 결제, 배송 추적 등 모든 기능이 하나의 코드베이스에 존재합니다. 하나의 데이터베이스를 공유하고, 하나의 서버 프로세스로 실행됩니다. 이런 구조는 초기 개발 단계에서 매우 유리했습니다. 김개발 씨가 입사하기 10년 전, 이 쇼핑몰을 처음 개발할 때는 팀원이 단 3명이었습니다. 그때는 모든 기능을 한곳에 모아두는 것이 효율적이었습니다. 코드를 수정하고 테스트하고 배포하는 과정이 단순했습니다. 하나의 프로젝트만 관리하면 되었으니까요. 프로젝트 구조도 직관적이었습니다. controller 패키지에 모든 컨트롤러가, service 패키지에 모든 서비스가, repository 패키지에 모든 데이터 접근 코드가 정리되어 있었습니다. 신입 개발자가 와도 금방 파악할 수 있는 구조였습니다. 배포도 간단했습니다. 하나의 WAR 파일이나 JAR 파일을 만들어서 서버에 올리면 끝이었습니다. 별도의 서비스 간 통신을 고민할 필요도 없었습니다. 모든 코드가 같은 메모리 공간에서 실행되니까요. 하지만 시간이 흐르면서 문제가 생기기 시작했습니다. 회사가 성장하고 개발팀이 20명으로 늘어났습니다. 여러 팀이 같은 코드베이스를 수정하다 보니 충돌이 잦았습니다. 누군가 결제 모듈을 수정하면, 전혀 관련 없는 배송 모듈에 영향을 미치는 일이 발생했습니다. 더 큰 문제는 배포였습니다. 회원 관리 기능에 작은 버그 하나를 고치려 해도, 전체 애플리케이션을 다시 빌드하고 배포해야 했습니다. 빌드에 10분, 배포에 5분, 서버 재시작에 3분이 걸렸습니다. 그사이 모든 서비스가 중단되었습니다. 김개발 씨는 고개를 끄덕였습니다. "그래서 요즘 마이크로서비스로 전환하려는 거군요." 박시니어 씨가 미소 지었습니다. "정확해요. 하지만 모놀리식이 나쁜 것만은 아닙니다. 작은 프로젝트나 초기 스타트업에서는 여전히 좋은 선택이죠." 실제로 모놀리식 아키텍처는 여러 장점이 있습니다. 개발 초기에 빠르게 기능을 추가할 수 있고, 디버깅도 쉽습니다. 모든 코드가 한곳에 있으니 IDE에서 쉽게 추적할 수 있습니다. 트랜잭션 관리도 간단합니다. 하나의 데이터베이스 트랜잭션으로 여러 테이블을 한번에 처리할 수 있으니까요. 하지만 서비스가 커지고 팀이 커지면, 모놀리식의 한계가 명확해집니다. 그때가 바로 새로운 아키텍처를 고민할 시점입니다. **실전 팁** 💡 - 소규모 프로젝트나 스타트업 초기에는 모놀리식이 여전히 효율적인 선택입니다 - 팀 규모가 10명 이하이고 배포 빈도가 낮다면 굳이 복잡한 아키텍처로 갈 필요가 없습니다 --- ## 2. 마이크로서비스_아키텍처란 점심시간, 김개발 씨는 박시니어 씨와 카페테리아에서 마주 앉았습니다. "그렇다면 마이크로서비스는 정확히 뭔가요?" 김개발 씨가 물었습니다. 박시니어 씨는 냅킨에 그림을 그리기 시작했습니다. **마이크로서비스 아키텍처**는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누는 설계 방식입니다. 각 서비스는 독자적으로 개발, 배포, 확장할 수 있으며, 자체 데이터베이스를 가질 수 있습니다. 서비스 간 통신은 주로 HTTP REST API나 메시지 큐를 통해 이루어집니다. 다음 코드를 살펴봅시다. ```java // 회원 서비스 - 독립적인 Spring Boot 애플리케이션 @SpringBootApplication @RestController public class UserServiceApplication { public static void main(String[] args) { SpringApplication.run(UserServiceApplication.class, args); } @GetMapping("/users/{id}") public User getUser(@PathVariable Long id) { // 회원 정보만 처리하는 독립적인 서비스 return userRepository.findById(id); } } // 주문 서비스 - 별도의 독립적인 애플리케이션 @SpringBootApplication @RestController public class OrderServiceApplication { @Autowired RestTemplate restTemplate; @PostMapping("/orders") public Order createOrder(@RequestBody OrderRequest request) { // 회원 서비스를 HTTP로 호출 User user = restTemplate.getForObject( "http://user-service/users/" + request.getUserId(), User.class ); return orderRepository.save(new Order(user, request)); } } ``` 박시니어 씨가 냅킨에 그린 그림에는 여러 개의 작은 상자들이 있었습니다. 각 상자에는 '회원 서비스', '주문 서비스', '결제 서비스', '배송 서비스'라고 적혀 있었습니다. "모놀리식에서는 이 모든 기능이 하나의 큰 상자 안에 있었어요. 하지만 마이크로서비스에서는 각 기능이 독립된 서비스로 분리됩니다." **마이크로서비스**를 이해하는 가장 좋은 비유는 전문 음식점 거리입니다. 백화점 푸드코트(모놀리식)가 아니라, 이탈리아 레스토랑, 일식당, 중국집, 카페가 각각 독립된 건물로 운영되는 것과 같습니다. 각 음식점은 자체 주방, 자체 직원, 자체 재료 창고를 가지고 있습니다. 손님이 줄어들면 한 음식점만 문을 닫으면 됩니다. 다른 음식점들은 계속 영업합니다. 마이크로서비스도 마찬가지입니다. 회원 서비스는 오직 회원 가입, 로그인, 프로필 관리만 담당합니다. 주문 서비스는 주문 생성과 조회만 처리합니다. 결제 서비스는 결제 처리만 전담합니다. 각 서비스는 자체 데이터베이스를 가지고, 독립적으로 배포되며, 필요하면 다른 서비스를 HTTP API로 호출합니다. 이런 구조가 왜 등장했을까요? 몇 년 전, 쇼핑몰 서비스에 큰 문제가 생겼습니다. 블랙프라이데이 세일 때 주문이 폭주하면서 서버가 다운되었습니다. 문제는 주문 처리 부분이었지만, 전체 시스템이 멈췄습니다. 회원 로그인도 안 되고, 상품 조회도 안 되고, 고객센터 조회도 마비되었습니다. "하나가 죽으니까 전부 죽는 거죠." 박시니어 씨가 한숨을 쉬었습니다. 마이크로서비스로 전환한 후에는 달라졌습니다. 주문 서비스가 과부하로 느려져도, 회원 서비스와 상품 서비스는 정상적으로 작동했습니다. 주문만 잠시 지연될 뿐, 사용자는 여전히 로그인하고 상품을 둘러볼 수 있었습니다. 각 서비스는 완전히 독립적입니다. 회원 서비스는 Java Spring Boot로 개발되어 있고, 주문 서비스는 Node.js로, 결제 서비스는 Python으로 개발할 수도 있습니다. 각 팀이 가장 적합한 기술 스택을 선택할 수 있습니다. 실제로 많은 기업들이 이렇게 운영합니다. 배포도 독립적입니다. 회원 서비스에 버그를 고쳤다면, 회원 서비스만 재배포하면 됩니다. 다른 서비스들은 영향을 받지 않습니다. 전체 시스템을 내릴 필요가 없습니다. 확장도 유연합니다. 블랙프라이데이처럼 주문이 폭주할 때는 주문 서비스의 서버만 10대로 늘립니다. 회원 서비스는 2대면 충분하니 그대로 둡니다. 자원을 효율적으로 사용할 수 있습니다. 코드를 다시 살펴보겠습니다. 회원 서비스와 주문 서비스는 각각 별도의 Spring Boot 애플리케이션입니다. 독립적으로 실행되고, 독립적으로 배포됩니다. 주문 서비스가 회원 정보가 필요하면, RestTemplate을 사용해서 회원 서비스의 API를 HTTP로 호출합니다. 이것이 바로 **서비스 간 통신**입니다. 같은 메모리 공간의 메서드 호출이 아니라, 네트워크를 통한 API 호출입니다. "하지만 네트워크 호출은 느리지 않나요?" 김개발 씨가 물었습니다. "맞아요. 그래서 트레이드오프가 있죠. 속도를 조금 포기하고, 대신 유연성과 안정성을 얻는 겁니다." 실제 기업들의 사례를 보면 이해가 쉽습니다. Netflix는 수백 개의 마이크로서비스로 운영됩니다. 추천 서비스, 비디오 스트리밍 서비스, 결제 서비스 등이 모두 독립적입니다. Amazon도 마찬가지입니다. 이커머스 거대 기업들이 마이크로서비스를 선택한 이유가 있습니다. 김개발 씨는 이제 이해가 되었습니다. 마이크로서비스는 복잡하지만, 큰 시스템을 안정적으로 운영하기 위한 현실적인 선택이었습니다. **실전 팁** 💡 - 각 마이크로서비스는 단일 책임 원칙을 따라야 합니다. 한 가지 업무 영역만 담당하세요 - 서비스 간 통신은 API Gateway를 통해 중앙에서 관리하면 더 효율적입니다 --- ## 3. 마이크로서비스의_장점 다음 날 아침, 팀 회의에서 CTO가 발표했습니다. "우리도 마이크로서비스로 전환합니다." 회의실이 술렁였습니다. 김개발 씨는 손을 들었습니다. "정확히 어떤 점이 좋아지나요?" CTO는 화이트보드에 다가갔습니다. 마이크로서비스의 핵심 장점은 **독립적인 배포와 확장**, **기술 스택의 자유**, **장애 격리**, **팀 자율성** 증가입니다. 각 서비스가 독립적으로 운영되므로 시스템 전체의 유연성과 안정성이 크게 향상됩니다. 대규모 조직에서 여러 팀이 동시에 개발할 때 특히 효과적입니다. 다음 코드를 살펴봅시다. ```java // 주문 서비스만 독립적으로 스케일 아웃 apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: replicas: 10 # 블랙프라이데이 대비 주문 서비스만 10개로 확장 template: spec: containers: - name: order-service image: order-service:v2.1 // 회원 서비스는 2개 인스턴스만 유지 apiVersion: apps/v1 kind: Deployment metadata: name: user-service spec: replicas: 2 # 회원 서비스는 트래픽이 적어 2개만 유지 template: spec: containers: - name: user-service image: user-service:v1.5 ``` CTO는 화이트보드에 네 가지 항목을 적었습니다. 독립 배포, 선택적 확장, 장애 격리, 기술 자유. 김개발 씨는 메모를 시작했습니다. 첫 번째, **독립적인 배포**입니다. 모놀리식 시절을 떠올려보겠습니다. 회원 관리 팀이 작은 버그를 고쳤습니다. 하지만 배포하려면 전체 시스템을 내려야 했습니다. 주문팀, 결제팀, 배송팀 모두와 일정을 조율해야 했습니다. "다음 주 화요일 새벽 2시에 배포합시다." 모든 팀이 대기해야 했습니다. 마이크로서비스에서는 다릅니다. 회원 서비스 팀이 버그를 고치면, 회원 서비스만 재배포합니다. 다른 팀에게 알릴 필요도 없습니다. 오후 3시에 조용히 배포하고 끝입니다. 다른 서비스들은 계속 정상 작동합니다. 이것이 **지속적 배포**를 가능하게 합니다. Netflix는 하루에 수천 번 배포합니다. 각 팀이 독립적으로 빠르게 기능을 출시할 수 있기 때문입니다. 두 번째, **선택적 확장**입니다. 블랙프라이데이를 준비한다고 가정해봅시다. 주문이 평소의 100배로 폭증할 것입니다. 모놀리식이라면? 전체 애플리케이션 서버를 100대로 늘려야 합니다. 회원 관리, 상품 조회, 고객센터 기능까지 모두 100배로 늘어납니다. 낭비입니다. 마이크로서비스에서는 주문 서비스만 100대로 늘립니다. 결제 서비스는 50대, 회원 서비스는 5대면 충분합니다. 위의 쿠버네티스 설정 예제를 보면, 각 서비스의 replicas를 독립적으로 설정합니다. 비용을 크게 절감할 수 있습니다. 실제로 쿠팡은 새벽 배송 주문이 몰리는 시간대에 주문 서비스만 자동으로 확장합니다. 오전에는 다시 축소됩니다. 클라우드 비용을 최적화하는 핵심 전략입니다. 세 번째, **장애 격리**입니다. 어느 날 밤, 결제 시스템에 장애가 발생했습니다. 외부 PG사의 API가 다운되었습니다. 모놀리식이었다면? 결제 모듈에서 발생한 예외가 전체 애플리케이션을 멈출 수 있습니다. 회원 로그인도 안 되고, 상품 조회도 안 됩니다. 전면 장애입니다. 마이크로서비스에서는 결제 서비스만 영향을 받습니다. 회원 서비스, 상품 서비스, 주문 조회 서비스는 정상 작동합니다. 사용자는 여전히 쇼핑을 하고 장바구니에 담을 수 있습니다. 결제만 잠시 "일시적 오류"가 뜹니다. 이를 **부분 장애**라고 합니다. 전체가 죽지 않고 일부만 영향받는 것입니다. 서비스 가용성이 크게 향상됩니다. 네 번째, **기술 스택의 자유**입니다. 회원 서비스 팀은 안정적인 Java Spring Boot를 선호합니다. 주문 서비스 팀은 빠른 개발을 위해 Node.js를 선택했습니다. 추천 서비스 팀은 머신러닝을 위해 Python Flask를 사용합니다. 실시간 알림 서비스는 Go로 개발했습니다. 모놀리식에서는 불가능한 일입니다. 모두가 같은 언어, 같은 프레임워크를 써야 합니다. 하지만 마이크로서비스에서는 각 팀이 최적의 도구를 선택할 수 있습니다. 물론 무분별한 기술 선택은 위험합니다. 하지만 적재적소에 맞는 기술을 쓸 수 있다는 것은 큰 장점입니다. 다섯 번째, **팀 자율성**입니다. 회원 서비스를 담당하는 팀 A는 완전히 독립적으로 일합니다. 코드 저장소도 따로, 배포 파이프라인도 따로, 데이터베이스도 따로입니다. 다른 팀의 승인을 받을 필요가 없습니다. 빠른 의사결정이 가능합니다. 이것이 **Conway의 법칙**과도 연결됩니다. "시스템 구조는 조직 구조를 따른다." 마이크로서비스는 자율적인 소규모 팀 구조에 최적화되어 있습니다. Amazon의 "Two Pizza Team" 원칙을 아시나요? 피자 두 판으로 배불리 먹을 수 있는 크기의 작은 팀이 하나의 서비스를 소유합니다. 각 팀은 독립적으로 혁신하고 빠르게 움직입니다. CTO는 설명을 마치며 말했습니다. "물론 단점도 있습니다. 하지만 우리 조직 규모와 서비스 특성을 고려하면, 장점이 더 큽니다." 김개발 씨는 고개를 끄덕였습니다. 확실히 큰 조직에서 여러 팀이 협업할 때 마이크로서비스의 장점이 빛을 발하는 것 같았습니다. **실전 팁** 💡 - 마이크로서비스의 장점은 조직이 클수록, 트래픽이 많을수록 명확해집니다 - 작은 스타트업이라면 오히려 모놀리식이 더 효율적일 수 있습니다 --- ## 4. 마이크로서비스의_단점과_과제 회의가 끝난 후, 김개발 씨는 박시니어 씨에게 조심스럽게 물었습니다. "그런데 단점은 없나요? 너무 좋은 것만 이야기하는 것 같아서요." 박시니어 씨는 쓴웃음을 지었습니다. "단점이요? 엄청 많죠. 한번 앉아보세요." 마이크로서비스는 **복잡성 증가**, **네트워크 통신 오버헤드**, **분산 트랜잭션 관리의 어려움**, **운영 부담 증가**라는 명확한 단점이 있습니다. 서비스가 늘어날수록 모니터링, 디버깅, 배포 관리가 기하급수적으로 어려워집니다. 제대로 된 인프라와 조직 역량 없이 도입하면 오히려 독이 될 수 있습니다. 다음 코드를 살펴봅시다. ```java // 분산 트랜잭션의 어려움 예시 @RestController public class OrderController { @Autowired RestTemplate restTemplate; @PostMapping("/orders") public Order createOrder(@RequestBody OrderRequest req) { // 1. 재고 차감 (상품 서비스) restTemplate.postForObject("http://product-service/reduce", req.getProductId()); // 2. 결제 처리 (결제 서비스) Payment payment = restTemplate.postForObject("http://payment-service/pay", req); // 만약 여기서 예외 발생하면? // 재고는 이미 차감되었고, 결제도 완료되었는데 주문은 저장 안 됨! if (payment.isFailed()) { // 어떻게 롤백? 각 서비스에 취소 요청을 보내야 함 (Saga 패턴) restTemplate.postForObject("http://product-service/restore", req.getProductId()); throw new PaymentFailedException(); } return orderRepository.save(new Order(req)); } } ``` 박시니어 씨는 자신의 노트북을 열었습니다. 화면에는 수십 개의 서비스 목록이 떠 있었습니다. 회원, 주문, 결제, 배송, 알림, 추천, 검색, 리뷰, 쿠폰, 포인트, 통계, 로그... 끝이 없었습니다. "이게 우리 시스템입니다. 40개가 넘는 마이크로서비스가 돌아가고 있어요." 첫 번째 문제, **시스템 복잡도 폭증**입니다. 모놀리식 시절에는 하나의 프로젝트만 관리하면 되었습니다. 이제는 40개의 독립된 프로젝트를 관리합니다. 각각 다른 저장소, 다른 배포 파이프라인, 다른 모니터링 대시보드를 가지고 있습니다. 버그를 추적하는 것만 해도 악몽입니다. 사용자가 "주문이 안 돼요"라고 신고하면, 어느 서비스의 문제인지부터 찾아야 합니다. 회원 서비스? 상품 서비스? 주문 서비스? 결제 서비스? 로그를 40개 서비스에서 다 뒤져야 합니다. "분산 추적 시스템을 도입해야 해요. Zipkin이나 Jaeger 같은 도구로요. 안 그러면 디버깅이 불가능합니다." 박시니어 씨가 한숨을 쉬었습니다. 두 번째 문제, **네트워크 통신 오버헤드**입니다. 모놀리식에서는 OrderService가 UserService를 호출할 때 그냥 메서드 호출이었습니다. 메모리 내에서 즉시 처리됩니다. 마이크로초(microsecond) 단위입니다. 마이크로서비스에서는 네트워크를 타야 합니다. HTTP 요청을 만들고, 네트워크를 통해 전송하고, 다른 서버가 받아서 처리하고, 응답을 돌려보냅니다. 밀리초(millisecond) 단위입니다. 1000배 느립니다. 하나의 주문을 처리하는 데 10개 서비스를 거친다면? 네트워크 호출이 10번입니다. 각각 50ms씩만 걸려도 500ms입니다. 반 초가 걸립니다. 사용자 경험이 나빠집니다. "그래서 캐싱 전략이 아주 중요해요. Redis 같은 걸 적극 활용해야 합니다." 세 번째 문제, **분산 트랜잭션의 어려움**입니다. 위의 코드 예제를 다시 보겠습니다. 주문을 생성하는 과정에서 세 가지 작업이 일어납니다. 재고 차감, 결제 처리, 주문 저장. 각각 다른 서비스입니다. 만약 결제는 성공했는데 주문 저장에서 에러가 나면? 결제는 완료되었지만 주문 기록은 없습니다. 고객은 돈만 빠져나간 겁니다. 심각한 문제입니다. 모놀리식에서는 간단했습니다. @Transactional 어노테이션 하나면 끝입니다. 하나라도 실패하면 전부 롤백됩니다. 마이크로서비스에서는? 각 서비스가 독립된 데이터베이스를 씁니다. 분산 트랜잭션을 구현해야 합니다. **Saga 패턴**, **Two-Phase Commit** 같은 복잡한 패턴이 필요합니다. "Saga 패턴은 각 단계마다 보상 트랜잭션(compensating transaction)을 준비하는 거예요. 결제가 실패하면 재고 복구 API를 호출하는 식이죠. 코드가 훨씬 복잡해집니다." 네 번째 문제, **운영 부담 증가**입니다. 40개의 서비스를 운영한다는 것은 40개의 서버를 관리한다는 뜻입니다. 물론 쿠버네티스 같은 오케스트레이션 도구를 씁니다. 하지만 그것도 배워야 하고, 설정해야 하고, 모니터링해야 합니다. 각 서비스의 상태를 체크하는 헬스체크, 로그 수집, 메트릭 모니터링, 알람 설정, 배포 자동화... 인프라 엔지니어가 최소 2-3명은 필요합니다. "우리 회사는 DevOps 팀이 따로 있어요. 그들이 쿠버네티스와 프로메테우스, 그라파나를 관리하죠. 작은 회사라면 감당하기 어렵습니다." 다섯 번째 문제, **데이터 일관성**입니다. 각 서비스가 독립된 데이터베이스를 가지므로, 전체 시스템의 데이터 일관성을 유지하기 어렵습니다. 회원 서비스의 사용자 이름이 바뀌었다면, 주문 서비스의 주문 기록도 업데이트해야 할까요? 이런 문제를 해결하려면 **이벤트 기반 아키텍처**를 도입해야 합니다. Kafka 같은 메시지 큐를 써서 데이터 변경을 다른 서비스에 전파합니다. 또 다른 복잡도가 추가됩니다. 김개발 씨는 머리가 지끈거렸습니다. "그럼 왜 마이크로서비스를 하는 건가요?" 박시니어 씨가 미소 지었습니다. "트레이드오프예요. 복잡도는 증가하지만, 대규모 시스템을 안정적으로 운영하고, 빠르게 기능을 출시하려면 감수해야 하는 비용이죠. 작은 회사라면 절대 추천 안 합니다. 하지만 우리 정도 규모라면 필수입니다." 실제로 많은 스타트업이 너무 일찍 마이크로서비스를 도입했다가 실패합니다. 인프라 구축에 6개월을 쓰고, 정작 비즈니스 기능은 개발 못 합니다. 조직이 준비되지 않았는데 아키텍처만 먼저 바꾸면 재앙입니다. "일단 모놀리식으로 시작하세요. 충분히 커지면 그때 전환하는 게 정석입니다." 박시니어 씨의 조언이었습니다. **실전 팁** 💡 - 마이크로서비스는 조직이 작고 트래픽이 적을 때는 오히려 독이 됩니다 - 분산 추적, 로그 수집, 서비스 메시 같은 인프라 도구 없이는 운영이 불가능합니다 --- ## 5. 언제_마이크로서비스를_선택할까 주말이 지나고 월요일 아침, 김개발 씨는 커피를 마시며 고민에 빠졌습니다. "우리 팀이 새 프로젝트를 시작하는데, 마이크로서비스로 해야 할까요?" 박시니어 씨가 웃으며 물었습니다. "팀이 몇 명인데요?" 마이크로서비스 도입 판단 기준은 **팀 규모**, **트래픽 규모**, **도메인 복잡도**, **배포 빈도**, **조직의 기술 역량**입니다. 일반적으로 팀이 10명 이하이고 트래픽이 적다면 모놀리식으로 시작하는 것이 현명합니다. 명확한 비즈니스 이유 없이 유행만 따라 도입하면 실패합니다. 다음 코드를 살펴봅시다. ```java // 마이크로서비스 도입 판단 체크리스트 (주석으로 정리) // 1. 팀 규모: 15명 이상의 개발팀? boolean largeTeam = developerCount >= 15; // 2. 트래픽: 일일 활성 사용자 10만 이상? boolean highTraffic = dailyActiveUsers >= 100000; // 3. 배포 빈도: 주 5회 이상 배포? boolean frequentDeployment = deploymentsPerWeek >= 5; // 4. 도메인 복잡도: 3개 이상의 명확히 분리된 도메인? boolean complexDomain = distinctDomains >= 3; // 5. 인프라 역량: Kubernetes, Docker 운영 가능? boolean hasInfraTeam = devOpsEngineers >= 2; // 모든 조건이 true면 마이크로서비스 고려 if (largeTeam && highTraffic && frequentDeployment && complexDomain && hasInfraTeam) { architecture = "Microservices"; } else { architecture = "Monolith"; // 아니면 모놀리식으로 시작 } ``` 박시니어 씨는 화이트보드에 의사결정 트리를 그리기 시작했습니다. "마이크로서비스 선택은 기술이 아니라 비즈니스 결정이에요." 첫 번째 질문, **팀이 얼마나 큰가요?** 김개발 씨의 새 프로젝트 팀은 3명입니다. 박시니어 씨가 고개를 저었습니다. "3명이면 절대 마이크로서비스 하지 마세요. 인프라 구축하다가 3개월 날립니다." Amazon의 Two Pizza Team 원칙을 기억하시나요? 하나의 마이크로서비스를 5-7명의 작은 팀이 소유합니다. 만약 3개의 마이크로서비스를 만든다면 최소 15명은 필요합니다. 그보다 적으면 한 사람이 여러 서비스를 관리해야 하고, 복잡도만 증가합니다. "10명 이하 팀이라면 모놀리식으로 시작하세요. 충분히 성장한 후에 전환해도 늦지 않습니다." 두 번째 질문, **트래픽이 얼마나 되나요?** 새 프로젝트는 베타 테스트 단계입니다. 사용자가 100명도 안 됩니다. "그럼 더더욱 모놀리식이에요." 박시니어 씨가 단호하게 말했습니다. 마이크로서비스의 핵심 장점 중 하나는 선택적 확장입니다. 하지만 트래픽이 적으면 확장할 필요가 없습니다. 서버 한 대로 충분합니다. 굳이 복잡하게 나눌 이유가 없습니다. "일일 활성 사용자가 10만 명을 넘어가고, 특정 기능에 트래픽이 몰릴 때 비로소 마이크로서비스의 가치가 드러납니다." 세 번째 질문, **얼마나 자주 배포하나요?** 모놀리식에서 배포는 큰 이벤트입니다. 모든 팀이 일정을 맞추고, 주말 새벽에 배포합니다. 한 달에 한두 번 정도입니다. 만약 배포 빈도가 낮다면, 마이크로서비스의 독립 배포 장점이 크게 와닿지 않습니다. 하지만 하루에도 여러 번 배포해야 하는 빠른 조직이라면, 독립 배포는 필수입니다. "Netflix는 하루 수천 번 배포한다고 했죠? 그런 조직은 마이크로서비스 없이는 불가능합니다." 네 번째 질문, **도메인이 명확히 분리되나요?** 쇼핑몰을 예로 들겠습니다. 회원 관리, 상품 관리, 주문 처리, 결제, 배송 추적. 각각 명확하게 분리된 **바운디드 컨텍스트**(Bounded Context)입니다. 서로 독립적으로 발전할 수 있습니다. 하지만 단순한 블로그 서비스라면? 글 작성, 댓글, 좋아요가 서로 밀접하게 연결되어 있습니다. 억지로 나누면 오히려 복잡해집니다. "도메인 주도 설계(DDD)를 공부해보세요. 바운디드 컨텍스트가 명확히 보이면 그때 나누는 겁니다." 다섯 번째 질문, **인프라 역량이 있나요?** 마이크로서비스를 운영하려면 Docker, Kubernetes, Service Mesh, 분산 추적, 로그 수집, 메트릭 모니터링 등등... 엄청난 인프라 기술이 필요합니다. DevOps 엔지니어가 없다면? 개발자가 직접 다 해야 합니다. 기능 개발은 뒷전이고 인프라 공부만 하게 됩니다. "최소한 쿠버네티스를 능숙하게 다룰 수 있는 엔지니어가 1-2명은 있어야 합니다. 아니면 AWS ECS, Google Cloud Run 같은 관리형 서비스를 쓰거나요." 실제 사례를 들어보겠습니다. 스타트업 A는 팀이 5명인데 마이크로서비스로 시작했습니다. 6개월 동안 인프라 구축만 했습니다. 경쟁사는 모놀리식으로 빠르게 기능을 출시하고 시장을 선점했습니다. 스타트업 A는 결국 실패했습니다. 스타트업 B는 모놀리식으로 시작했습니다. 빠르게 성장해서 팀이 50명이 되었습니다. 배포할 때마다 충돌이 생기고, 장애가 잦았습니다. 그때 마이크로서비스로 전환했습니다. 성공적이었습니다. "타이밍이 중요해요. 너무 이르면 실패하고, 너무 늦으면 레거시에 발목 잡힙니다." 박시니어 씨의 조언은 명확했습니다. "일단 모놀리식으로 빠르게 시작하세요. 시장을 검증하고, 사용자를 확보하세요. 팀이 15명을 넘고, 트래픽이 감당 안 될 때, 그때 전환하세요." 김개발 씨는 고개를 끄덕였습니다. 새 프로젝트는 모놀리식으로 결정했습니다. 언젠가 충분히 성장하면, 그때 다시 고민하기로 했습니다. **실전 팁** 💡 - "마이크로서비스로 시작"보다 "모놀리식으로 시작 후 전환"이 성공률이 훨씬 높습니다 - 유행을 따르지 말고, 현재 조직의 규모와 역량에 맞는 아키텍처를 선택하세요 --- ## 6. 마이크로서비스_설계_원칙 몇 달 후, 회사의 쇼핑몰 서비스가 급성장했습니다. 팀은 25명으로 늘어났고, 일일 사용자는 20만 명을 넘었습니다. CTO가 발표했습니다. "이제 마이크로서비스로 전환합니다." 김개발 씨는 설계 회의에 참석했습니다. "어떤 원칙으로 설계해야 하나요?" 마이크로서비스 설계의 핵심 원칙은 **단일 책임**, **독립적 배포 가능성**, **느슨한 결합**, **데이터 소유권**, **장애 격리**입니다. 각 서비스는 명확한 비즈니스 기능 하나를 담당하고, 독립적으로 운영되며, 다른 서비스와 최소한으로 결합되어야 합니다. 이런 원칙을 지켜야 마이크로서비스의 장점을 제대로 얻을 수 있습니다. 다음 코드를 살펴봅시다. ```java // 잘못된 설계: 서비스 간 강한 결합 @RestController public class OrderService { @Autowired UserRepository userRepository; // 다른 서비스의 DB 직접 접근 - 나쁨! @PostMapping("/orders") public Order createOrder(@RequestBody OrderRequest req) { User user = userRepository.findById(req.getUserId()); // 강한 결합 return new Order(user); } } // 올바른 설계: API를 통한 느슨한 결합 @RestController public class OrderService { @Autowired RestTemplate restTemplate; @PostMapping("/orders") public Order createOrder(@RequestBody OrderRequest req) { // 회원 서비스의 API를 호출 - 느슨한 결합 User user = restTemplate.getForObject( "http://user-service/api/users/" + req.getUserId(), User.class ); return new Order(user); } } ``` 설계 회의실에 아키텍트 최설계 씨가 들어왔습니다. 화이트보드에 현재 모놀리식 구조를 그리고, 어떻게 나눌지 설명하기 시작했습니다. 첫 번째 원칙, **단일 책임 원칙(Single Responsibility Principle)**입니다. "각 서비스는 딱 하나의 비즈니스 기능만 담당해야 합니다." 최설계 씨가 강조했습니다. 회원 서비스는 오직 회원 가입, 로그인, 프로필 수정만 처리합니다. 주문 관련 로직은 절대 들어가면 안 됩니다. 주문 서비스는 주문 생성, 조회, 취소만 담당합니다. 결제 로직은 결제 서비스로 분리합니다. "너무 작게 나누면 어떻게 되나요?" 누군가 물었습니다. "좋은 질문이에요. 너무 작게 나누면 서비스 개수가 폭발하고, 관리가 어려워집니다. 적절한 크기가 중요합니다." 적절한 크기란? 한 팀이 소유하고 관리할 수 있는 정도입니다. 보통 하나의 **바운디드 컨텍스트**가 하나의 마이크로서비스가 됩니다. 도메인 주도 설계(DDD)를 공부하면 이 감각을 익힐 수 있습니다. 두 번째 원칙, **독립적 배포 가능성**입니다. "각 서비스는 다른 서비스에 영향을 주지 않고 독립적으로 배포되어야 합니다." 이를 위해서는 **API 버전 관리**가 필수입니다. 회원 서비스가 API를 변경할 때, 기존 API도 당분간 유지해야 합니다. 그래야 주문 서비스가 아직 새 API로 전환하지 않아도 동작합니다. 예를 들어, `/api/v1/users`와 `/api/v2/users`를 동시에 제공합니다. 주문 서비스는 준비가 되면 천천히 v2로 마이그레이션합니다. 강제로 동시 배포하지 않습니다. "하위 호환성(Backward Compatibility)을 최대한 유지하세요. API에 필드를 추가하는 건 괜찮지만, 삭제하거나 타입을 바꾸면 다른 서비스가 깨집니다." 세 번째 원칙, **느슨한 결합(Loose Coupling)**입니다. 위의 코드 예제를 보겠습니다. 잘못된 설계에서는 OrderService가 UserRepository를 직접 주입받습니다. 회원 서비스의 데이터베이스를 직접 읽습니다. 이것은 **강한 결합**입니다. 문제가 뭘까요? 회원 서비스가 데이터베이스 스키마를 변경하면 주문 서비스가 깨집니다. 회원 서비스 팀이 독립적으로 배포할 수 없습니다. 마이크로서비스의 의미가 없어집니다. 올바른 설계는 API를 통해 통신합니다. 주문 서비스는 회원 서비스의 REST API를 호출합니다. 내부 구현은 알 필요가 없습니다. 회원 서비스가 MySQL을 쓰든 PostgreSQL을 쓰든, 주문 서비스는 신경 쓰지 않습니다. "데이터베이스는 절대 공유하지 마세요. 각 서비스는 자기 데이터베이스를 소유합니다." 네 번째 원칙, **데이터 소유권**입니다. 각 마이크로서비스는 자신의 데이터에 대한 완전한 소유권을 가집니다. 회원 데이터는 회원 서비스만 읽고 씁니다. 다른 서비스가 회원 데이터가 필요하면, 반드시 회원 서비스의 API를 호출해야 합니다. "만약 주문 서비스가 회원 이름을 보여줘야 한다면요?" 김개발 씨가 물었습니다. "두 가지 방법이 있어요. 첫째, 주문할 때 회원 서비스에서 이름을 가져와서 주문 테이블에 복사해둡니다. 둘째, 주문 조회할 때마다 회원 서비스 API를 실시간으로 호출합니다." 첫 번째 방법은 **데이터 중복**을 허용합니다. 대신 빠릅니다. 두 번째 방법은 항상 최신 데이터를 보장하지만, 네트워크 호출이 필요합니다. 트레이드오프를 고려해서 선택합니다. 다섯 번째 원칙, **장애 격리(Fault Isolation)**입니다. 한 서비스의 장애가 다른 서비스로 전파되지 않도록 설계해야 합니다. 이를 위해 **Circuit Breaker** 패턴을 사용합니다. 주문 서비스가 회원 서비스를 호출하는데, 회원 서비스가 다운되었다면? 무한정 기다리면 주문 서비스도 멈춥니다. Circuit Breaker는 일정 시간 실패가 계속되면 "회로를 차단"합니다. 더 이상 호출하지 않고 즉시 에러를 반환합니다. "Spring Cloud에서는 Resilience4j를 씁니다. Netflix Hystrix의 후속이죠." 여섯 번째 원칙, **API Gateway 패턴**입니다. 클라이언트(모바일 앱, 웹)가 40개의 마이크로서비스를 직접 호출하면 복잡합니다. 대신 하나의 **API Gateway**를 둡니다. 클라이언트는 게이트웨이만 호출하고, 게이트웨이가 적절한 마이크로서비스로 라우팅합니다. 게이트웨이는 인증, 로깅, 속도 제한(Rate Limiting) 같은 공통 기능도 처리합니다. Spring Cloud Gateway나 Kong 같은 도구를 씁니다. 최설계 씨는 설명을 마치며 경고했습니다. "이런 원칙들을 무시하고 마이크로서비스를 만들면, 분산 모놀리스(Distributed Monolith)가 됩니다. 마이크로서비스의 단점만 가지고 장점은 못 얻는 최악의 상황이죠." 회의가 끝나고, 김개발 씨는 많은 것을 배웠습니다. 마이크로서비스는 단순히 코드를 나누는 게 아니었습니다. 조직, 프로세스, 인프라 전체를 바꾸는 거대한 변화였습니다. 하지만 제대로 설계하고 구축한다면, 큰 조직에서 빠르고 안정적으로 서비스를 운영할 수 있는 강력한 도구가 됩니다. **실전 팁** 💡 - 데이터베이스를 절대 공유하지 마세요. 서비스 간 결합도가 높아집니다 - Circuit Breaker와 Timeout 설정은 필수입니다. 장애 전파를 막아야 합니다 - API 버전 관리를 처음부터 계획하세요. 나중에 추가하기 매우 어렵습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Spring

언어: Java

태그: Spring, Microservices, Architecture, MSA, DistributedSystems

작성자: AI Generated

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

CodeDeck

마이크로서비스 아키텍처 완벽 가이드

목차

1. 모놀리식 아키텍처란

2. 마이크로서비스 아키텍처란

3. 마이크로서비스의 장점

4. 마이크로서비스의 단점과 과제

5. 언제 마이크로서비스를 선택할까

6. 마이크로서비스 설계 원칙

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

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

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

Prometheus 메트릭 수집 완벽 가이드