1장. 마이크로서비스의 기본 개념과 장점, 그리고 전환의 판단
시스템은 성장한다.
그리고 성장한 시스템은 언젠가 구조에 대해 다시 질문하게 만든다.
“지금 구조가 최선인가?”
“이대로 계속 가도 되는가?”
“나누는 것이 맞는가, 유지하는 것이 맞는가?”
마이크로서비스는 하나의 해답이 될 수 있다.
그러나 그 전에 반드시 스스로에게 물어야 할 것이 있다.
정말 지금 넘어가야 하는가?
마이크로서비스란 무엇인가
마이크로서비스는 단순히 서비스를 작게 나누는 방식이 아니다.
독립적으로 배포 가능하고
독립적으로 확장 가능하며
독립적으로 진화할 수 있는
비즈니스 단위 서비스들의 집합
핵심은 ‘작음’이 아니라 독립성이다.
각 서비스는
- 자체 코드베이스
- 자체 데이터 저장소
- 독립 배포
- 독립 확장
- 명확한 도메인 책임
을 가진다.
기능 계층이 아니라
비즈니스 책임 단위로 분리되는 구조다.
마이크로서비스의 장점
1. 독립 확장
트래픽이 특정 영역에 집중될 경우
그 서비스만 확장할 수 있다.
자원 사용 효율이 높아지고
불필요한 비용 증가를 막을 수 있다.
2. 독립 배포
한 기능의 수정이 전체 재배포를 의미하지 않는다.
배포 리스크가 낮아지고
변경 속도가 빨라진다.
3. 장애 격리
한 서비스 장애가 전체 시스템을 중단시키지 않도록
설계할 수 있다.
복구 범위가 작아진다.
4. 조직 단위 자율성
서비스 단위로 팀이 움직일 수 있다.
조직 성장과 함께 구조도 확장할 수 있다.
그러나, 모놀리스는 정말 나쁜가?
여기서 반드시 멈춰야 한다.
모놀리스는 잘못된 구조가 아니다.
많은 경우 여전히 가장 합리적인 선택이다.
모놀리스는
- 구조가 단순하다
- 운영이 쉽다
- 트랜잭션 관리가 명확하다
- 네트워크 장애 고민이 없다
- 디버깅이 직관적이다
특히 다음과 같은 상황이라면
모놀리스를 유지하는 것이 더 나을 수 있다.
- 팀 규모가 작다
- 트래픽 패턴이 단순하다
- 도메인이 복잡하게 분리되어 있지 않다
- 배포 빈도가 높지 않다
- 시스템 변경 속도가 안정적이다
마이크로서비스는 복잡성을 제거하지 않는다.
복잡성을 외부로 이동시킨다.
코드 내부의 의존성이
네트워크 의존성으로 바뀌고,
트랜잭션 문제는
데이터 일관성 문제로 바뀐다.
디버깅은
분산 추적 문제로 바뀐다.
우리가 스스로에게 던져야 할 질문
전환을 고민할 때는 다음 질문에 답해보아야 한다.
- 특정 기능만 독립적으로 확장해야 하는 상황이 반복되는가?
- 배포가 조직 전체의 스트레스가 되었는가?
- 하나의 장애가 전체 시스템으로 확산되는가?
- 팀이 커지면서 코드 충돌과 의존성이 증가했는가?
- 도메인 경계가 명확하게 구분되는가?
이 질문에 여러 개가 “예”라면
전환을 진지하게 고려할 시점일 수 있다.
하지만 그렇지 않다면
모놀리스 최적화가 더 합리적인 선택일 수도 있다.
전환은 선택이지 의무가 아니다
마이크로서비스는 성장 전략이다.
기술 트렌드가 아니다.
넘어가는 이유가 분명해야 한다.
- 확장성 문제 해결
- 조직 구조와의 정렬
- 배포 독립성 확보
- 장애 격리 필요
이 중 어느 것도 절실하지 않다면
지금은 준비 단계일 수 있다.
이 장의 결론
마이크로서비스는 강력한 구조다.
그러나 모든 시스템에 필요한 구조는 아니다.
중요한 것은 “쪼갤 수 있느냐”가 아니라
“쪼개야 하는 이유가 있는가” 다.