전산학 마이크로서비스 아키텍처 기초: 하나의 큰 서비스 대신 여러 작은 서비스를 나누는 이유

전산학 마이크로서비스는 “유행어”가 아니라 운영 방식의 선택이다

서비스가 커지면 기능이 늘어나고, 동시에 사용자도 늘어난다. 초기에 빠르게 만들기 위해 하나의 애플리케이션으로 시작했더라도, 시간이 지나면 배포가 느려지고 장애 영향 범위가 커지며, 팀 간 충돌이 잦아진다. 이때 자주 등장하는 해법이 마이크로서비스 아키텍처(Microservices Architecture)다.
마이크로서비스는 하나의 큰 서비스(모놀리식, Monolith)를 여러 개의 작은 서비스로 나누어 개발·배포·확장을 분리하는 접근이다. 다만 무조건 나누면 좋은 것이 아니라, 어떤 문제를 해결하려고 나누는지와 어떤 비용이 늘어나는지를 함께 이해해야 한다.
이 글은 마이크로서비스 아키텍처의 핵심을 마이크로서비스, 모놀리식, 서비스 경계(Service Boundary), API 통신, 독립 배포(Independent Deployment)라는 키워드로 설명한다. 또한 실제 운영에서 “왜 나누는지”, “언제 나누면 손해인지”, “문제가 생겼을 때 어디를 먼저 점검해야 하는지”까지 연결해 정리한다.

 

전산학 개념 정의, 기본 원리, 관련 용어 정리

1) 모놀리식(Monolith): 하나의 코드와 하나의 배포 단위로 운영하는 구조다

모놀리식 구조는 기능이 많아도 결국 하나의 애플리케이션으로 묶여 있다. 로그인, 상품 목록, 결제, 관리자 기능이 모두 같은 코드베이스와 같은 배포 단위로 관리되는 형태다.
초기에는 장점이 크다. 개발 환경이 단순하고, 로컬에서 실행·디버깅하기 쉬우며, 서비스 간 통신 지연이 없다. 데이터도 하나의 데이터베이스에 모여 있어 트랜잭션 처리도 비교적 단순하다.

문제는 서비스가 커질수록 나타난다.

• 작은 수정도 전체를 다시 빌드·배포해야 한다.
• 특정 기능의 트래픽이 폭증해도 전체를 함께 확장해야 한다.
• 장애가 발생하면 영향 범위가 넓어지고 복구가 어렵다.
• 팀이 커지면 같은 코드베이스에서 충돌이 증가한다.

2) 마이크로서비스(Microservices): 기능을 작은 서비스로 나누고, 각 서비스를 독립적으로 운영한다

마이크로서비스 아키텍처는 기능을 서비스 단위로 분리한다. 예를 들어 쇼핑 서비스라면 “회원(인증) 서비스”, “상품 서비스”, “주문 서비스”, “결제 서비스”, “배송 서비스”처럼 나눌 수 있다. 각 서비스는 자기 역할을 수행하고, API를 통해 서로 통신한다.
핵심은 “작게 나누는 것” 자체가 아니라 “독립 배포와 독립 확장”이 가능해지는 운영 모델이라는 점이다.

• 결제 서비스만 수정해도 결제 서비스만 배포할 수 있다.
• 주문이 폭증하면 주문 서비스만 확장(스케일 아웃)할 수 있다.
• 한 서비스 장애가 전체 장애로 번지지 않도록 격리할 수 있다.

3) 서비스 경계(Service Boundary): 어디까지를 한 서비스로 볼 것인가

마이크로서비스에서 가장 중요한 설계는 경계 설정이다. 경계를 잘못 잡으면 서비스가 너무 잘게 쪼개져 통신 비용만 늘거나, 반대로 경계가 커서 모놀리식과 다를 바가 없어질 수 있다.
현실적으로 좋은 경계는 “업무 기능의 책임 단위”를 기준으로 잡는다. 예를 들어 “주문”은 주문 생성, 주문 상태 변경, 주문 이력 조회라는 한 덩어리의 책임을 가진다. 이 책임을 주문 서비스가 소유하고, 다른 서비스는 주문 서비스의 API를 통해서만 주문을 다루게 만드는 방식이 경계를 선명하게 한다.

4) 데이터 소유권(Data Ownership): 각 서비스는 자기 데이터에 대한 최종 책임을 가진다

마이크로서비스는 단순히 코드만 나누는 것이 아니라 “데이터의 책임”도 나누는 방향으로 발전한다. 주문 데이터는 주문 서비스가, 결제 데이터는 결제 서비스가 소유한다.
이 원칙의 목적은 명확하다. 서비스가 독립적으로 변화하려면, 데이터 구조 변경도 독립적으로 할 수 있어야 한다. 모든 서비스가 하나의 데이터베이스 테이블을 직접 만지기 시작하면, 결국 강하게 결합되어 독립 배포가 어렵다.

 

모놀리식 vs 마이크로서비스 구조 비교(서비스 경계와 데이터 소유권)

5) API 통신과 동기/비동기: 네트워크 호출이 기본 비용이 된다

서비스가 나뉘면 서비스 간 통신이 필요하다. 이때 가장 흔한 방식이 HTTP 기반의 API 호출이다. 또한 메시지 큐나 이벤트 스트리밍을 이용한 비동기 통신도 자주 사용한다.

• 동기 통신(예: HTTP API): 요청 후 즉시 응답을 기다린다. 구현이 직관적이지만, 상대 서비스 지연이 곧 내 서비스 지연으로 이어질 수 있다.
• 비동기 통신(예: 메시지 큐, 이벤트): 요청을 메시지로 남기고 처리 결과를 나중에 반영한다. 확장성과 회복력이 좋지만, 설계와 운영이 복잡해질 수 있다.

초보자가 이해해야 할 핵심은 간단하다. 마이크로서비스는 네트워크를 타는 순간부터 “느려질 가능성”과 “부분 장애”가 기본 전제가 된다. 따라서 장애 전파를 막는 설계가 중요해진다.

 

전산학 왜 나누는가, 어떤 문제를 해결하는가, 그리고 주의할 점

1) 이유 1: 독립 배포로 배포 속도와 위험을 낮춘다

모놀리식에서는 작은 수정도 전체 배포가 필요하다. 배포 횟수가 줄고, 배포 규모가 커지며, 결과적으로 배포가 두려운 일이 된다.
마이크로서비스는 변경이 필요한 서비스만 배포할 수 있다. 배포 단위가 작아지면 테스트 범위가 줄고, 롤백도 쉬워진다. 이는 운영에서 매우 큰 차이를 만든다.

실제 상황으로 보면 “상품 상세 화면에 필드 하나 추가” 같은 변경이 있을 때, 상품 서비스만 배포하면 된다. 주문이나 결제는 건드리지 않는다. 배포 위험이 작아지고 배포 주기를 짧게 가져갈 수 있다.

2) 이유 2: 독립 확장으로 비용과 성능을 동시에 관리한다

트래픽은 기능별로 다르게 증가한다. 검색과 상품 조회는 요청이 많고, 결제는 요청 수는 적어도 안정성이 매우 중요하다.
모놀리식에서는 특정 기능만 폭증해도 전체를 같이 확장해야 하는 경우가 많다. 마이크로서비스에서는 병목이 생긴 서비스만 확장할 수 있어 비용 효율이 좋아질 수 있다.

예를 들어 평소에는 주문이 적지만, 행사 시간에 주문이 폭증한다면 주문 서비스만 서버를 늘리고, 행사 종료 후 다시 줄이는 방식이 가능하다. 이것이 독립 확장의 가치다.

3) 이유 3: 장애 격리로 전체 장애를 줄인다

마이크로서비스가 항상 장애를 줄여주는 것은 아니지만, “잘 설계된 경우”에는 장애 전파를 줄일 수 있다.
예를 들어 추천 서비스가 일시적으로 장애가 나도, 상품 조회나 주문 기능은 정상 동작하도록 설계할 수 있다. 추천 영역은 빈 상태로 보여주되 페이지 전체는 뜨게 만드는 방식이다. 이런 설계는 사용자 경험을 지키고, 장애 복구 시간을 벌어준다.

여기서 중요한 기법이 타임아웃, 재시도 정책, 회로 차단기(Circuit Breaker) 같은 안정성 패턴이다. 서비스 간 동기 호출이 많을수록 이러한 안전장치가 필수가 된다.

 

마이크로서비스 요청 흐름과 장애 전파 방지(타임아웃·회로 차단기)

4) 현실적인 단점: 분산 시스템의 복잡도가 운영 비용으로 돌아온다

마이크로서비스는 장점만큼 단점도 분명하다. 특히 다음 비용은 대부분의 팀이 겪는다.

• 관측 가능성(Observability) 필요: 로그가 여러 서비스에 흩어지므로, 요청 ID로 추적하고 분산 트레이싱을 갖춰야 원인 파악이 가능하다.
• 데이터 일관성 문제: 서비스별 데이터가 분리되면, 한 번에 묶어 처리하던 트랜잭션이 어려워진다. 결국 일관성은 “즉시 일관성”에서 “최종 일관성”으로 설계를 바꾸는 경우가 많다.
• 배포와 운영 자동화 필요: 서비스 수가 늘면 수동 운영은 금방 한계에 부딪힌다. CI/CD, 모니터링, 알림 체계가 사실상 필수다.
• 통신 지연과 장애 가능성 증가: 네트워크 호출은 로컬 함수 호출보다 느리고, 실패 가능성도 높다.

따라서 마이크로서비스는 “개발이 쉬워지는 구조”라기보다 “운영을 체계화할 수 있는 팀이 선택하는 구조”에 가깝다.

5) 언제 마이크로서비스가 적합한가: 해결하려는 문제가 명확해야 한다

마이크로서비스가 적합한 상황은 대체로 다음 조건 중 일부를 만족한다.

• 배포가 너무 느리고, 잦은 변경이 부담이 되는 상태다.
• 특정 기능만 트래픽이 폭증해 확장 단위를 나눌 필요가 있다.
• 팀이 커져 한 코드베이스에서의 충돌이 심각하다.
• 장애 격리와 복구 속도가 중요한 서비스다.

반대로 다음 상황에서는 마이크로서비스가 손해일 수 있다.

• 서비스 규모가 작고, 팀이 작으며, 배포도 부담이 크지 않다.
• 기능이 자주 바뀌는데 경계가 아직 안정되지 않았다.
• 운영 자동화와 모니터링 체계를 갖출 여력이 부족하다.

현실적인 시작은 모놀리식으로 빠르게 만들고, 병목이 확실해질 때 단계적으로 분리하는 방식이 많다. 이를 모놀리식에서 마이크로서비스로의 점진적 분해라고 볼 수 있다.

6) 초보자가 흔히 하는 오해: “작게 쪼갤수록 좋다”는 생각

마이크로서비스의 목표는 “서비스 개수 늘리기”가 아니다. 목표는 독립 배포와 독립 확장으로 운영 문제를 해결하는 것이다.
서비스를 너무 잘게 쪼개면 다음 문제가 발생한다.

• API 호출이 늘어 지연이 증가한다.
• 개발자가 전체 흐름을 파악하기 어렵다.
• 배포 파이프라인과 모니터링이 감당하기 어려워진다.

따라서 초보 단계에서는 “작게”보다 “경계가 명확하게”가 더 중요하다. 나눴을 때 책임이 분명하고, 변경과 배포가 실제로 분리되는지가 기준이 된다.

 

전산학 마이크로서비스는 독립 배포·독립 확장·장애 격리를 위해 선택하는 구조다

마이크로서비스 아키텍처는 하나의 큰 서비스를 여러 작은 서비스로 분리해, 서비스 경계와 데이터 소유권을 명확히 하고 API 통신으로 협력하는 운영 모델이다. 이를 통해 독립 배포로 배포 위험을 줄이고, 독립 확장으로 비용과 성능을 관리하며, 장애 격리로 핵심 기능을 보호할 수 있다. 다만 분산 시스템의 복잡도, 데이터 일관성, 관측 가능성, 운영 자동화 같은 추가 비용이 반드시 발생한다. 따라서 마이크로서비스는 유행이 아니라, 해결하려는 문제가 명확할 때 선택해야 하는 아키텍처다.

다음으로 이어서 보면 좋은 주제는 두 가지다. 첫째, API 게이트웨이와 서비스 디스커버리가 마이크로서비스에서 왜 필요한지에 대한 설명이다. 둘째, 분산 트레이싱과 로그 상관관계 ID로 장애 원인을 빠르게 찾는 방법에 대한 정리다.