Microservice Architecture

왜 마이크로서비스를 선택하는가

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 서비스로 나누는 방식이다. 각 서비스는 독립적으로 배포되고, 자신의 데이터와 책임을 가진다. Lewis와 Fowler의 정의는 다음과 같다.

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

글 James Lewis, Martin Fowler, Microservices 이 출처의 인용 모아 보기

애플리케이션을 각자 프로세스로 도는 작은 서비스의 묶음으로 만들고, HTTP API 같은 가벼운 방식으로 통신한다는 뜻이다.

이 구조를 쓰는 이유는 보통 다음과 같다.

• 팀 단위로 소유권을 나누기 쉽다.
• 특정 기능만 독립적으로 배포할 수 있다.
• 트래픽 특성에 맞춰 서비스별로 확장할 수 있다.
• 장애 범위를 한 서비스 안으로 제한하기 쉽다.

반대로 시스템이 단순한 초기 단계라면 운영 복잡도만 늘어날 수 있다.

---

핵심 구성 요소

마이크로서비스를 설계할 때 자주 등장하는 구성 요소는 다음과 같다.

• API Gateway: 외부 요청의 진입점
• Service Discovery: 서비스 위치 관리
• Message Broker: 비동기 이벤트 전달
• Observability: 로그, 메트릭, 트레이싱
• Per-service Database: 서비스별 데이터 소유권

핵심은 기능을 나누는 것보다 경계와 소유권을 명확히 나누는 것이다.

---

데이터베이스를 어떻게 나눌 것인가

마이크로서비스에서 가장 자주 부딪히는 문제는 데이터 분리다.

• 서비스마다 DB를 따로 가지면 결합도는 낮아진다.
• 하지만 조인, 트랜잭션, 일관성 처리가 어려워진다. 여러 DB에 걸친 쓰기에는 Saga 같은 설계가 필요하다.
• 반대로 공유 DB를 쓰면 서비스 경계가 무너지기 쉽다.

실무에서는 다음 질문이 중요하다.

• 이 데이터의 진짜 소유 서비스는 어디인가
• 다른 서비스는 조회만 필요한가, 직접 수정도 필요한가
• 동기 호출이 필요한가, 이벤트 전파로 충분한가

마이크로서비스의 어려움은 대부분 여기서 시작된다.

---

장점보다 먼저 봐야 할 비용

마이크로서비스는 기술적으로 세련돼 보이지만 운영 비용이 크다.

• 배포 파이프라인이 여러 개로 늘어난다.
• 로컬 개발과 테스트가 어려워진다.
• 장애 원인 추적이 네트워크 구간까지 넓어진다.
• 데이터 정합성을 코드와 이벤트 설계로 보완해야 한다.

그래서 서비스 분해는 “코드를 나누고 싶다”가 아니라 “팀 구조와 변경 빈도, 확장 패턴이 정말 다르다”일 때 설득력이 있다.

---

언제 적합한가

다음 조건이 많을수록 마이크로서비스가 맞을 가능성이 높다.

• 기능별 팀이 이미 분리돼 있다.
• 서비스별 트래픽 패턴이 많이 다르다.
• 배포 주기와 장애 허용 범위가 서로 다르다.
• 특정 기능만 독립적으로 빠르게 진화해야 한다.

반대로 작은 팀, 단일 제품, 강한 데이터 결합 구조라면 모놀리식이 더 좋은 선택일 수 있다. 중간 단계로 모듈러 모놀리스도 있다.

---

정리

마이크로서비스 아키텍처에서 어려운 부분은 “작게 나누기”가 아니라, 경계를 잘 나누고 그 경계를 운영 가능한 수준으로 유지하는 일이다. 서비스 분해 자체보다 데이터 소유권, 호출 방식, 장애 격리, 운영 도구가 더 중요하다.

참고한 자료외부 출처 1

외부 출처

• Microservicesmartinfowler.comJames Lewis, Martin Fowler: (2014-03-25)