42장. 다시, 마이크로서비스는 의무가 아니다 (에필로그)
긴 여정이 끝났다.
우리는 1장에서 마이크로서비스의 개념과 장점을 보았고 2장에서 그 그림자를 보았다.
그리고 41장까지 경계 설계, 통신, 정합성, 복원력, 데이터 모델, 코드 아키텍처, 함정과 운영을 모두 살펴봤다.
이제 책을 닫기 전에 1장에서 던진 질문으로 돌아간다.
정말 지금 넘어가야 하는가?
우리가 무엇을 얻었고 무엇을 잃었는가
이 책의 모든 패턴을 적용하면 다음을 얻는다.
- 영역별 독립 확장
- 영역별 독립 배포
- 장애 격리
- 조직 자율성
그러나 다음을 잃거나 떠안는다.
- 운영 복잡도
- 네트워크 호출의 불확실성
- 데이터 정합성 책임
- 분산 추적·관측 인프라
- 분산 트랜잭션의 포기
이 균형은 회사마다 다르다. 같은 회사라도 단계마다 다르다.
모든 회사에 같은 답은 없다
작은 회사가 마이크로서비스를 도입하면 필요 없는 복잡성만 떠안는다.
큰 회사가 모놀리스를 고집하면 조직 성장에 시스템이 따라가지 못한다.
답은 항상 “지금 우리 상황“에서 나온다.
이 책이 줄 수 있는 건 다음 둘이다.
- 결정에 필요한 개념들
- 결정 후 마주칠 패턴들
결정 그 자체는 책이 대신해줄 수 없다.
다시 한 번, 핵심 질문
전환 결정의 다섯 가지 질문을 다시 본다.
- 특정 기능만 독립적으로 확장해야 하는가?
- 배포가 조직 전체의 스트레스인가?
- 한 장애가 전체로 확산되는가?
- 팀이 커지면서 코드 충돌이 증가하는가?
- 도메인 경계가 명확히 구분되는가?
여러 개에 “예“라면 전환을 고려한다. 그렇지 않다면 모놀리스 최적화가 더 현명할 수 있다.
이 질문에 정직하게 답하는 것이 첫 번째 일이다.
만약 전환을 결정했다면
2부의 원칙을 기억한다.
한 번에 옮길 수 없다.
- 점진적으로
- 한 도메인씩
- 검증하면서
- 되돌릴 수 있게
빅뱅의 유혹을 거절하는 것이 가장 큰 결정이다.
만약 이미 전환 중이라면
정기적으로 함정을 점검한다.
- 37장의 분산 모놀리스 체크리스트
- 38장의 Nanoservice 체크리스트
- 23장의 정합성 검증
이 점검 없이는 모르는 사이 함정에 빠진다.
만약 전환 후 후회가 든다면
39장에서 본 회귀 사례들이 답이다.
회귀는 실패가 아니다.
이미 분리된 서비스 중 일부를 다시 합치는 결정은 용기 있는 선택이다.
마이크로서비스도 모놀리스도 도구일 뿐이다.
상황에 맞게 바꾼다.
책 너머의 일
이 책은 마이크로서비스의 개념과 패턴에 집중했다.
그러나 실제 전환은 그 이상이다.
- 조직과 팀 구조 (Conway’s Law)
- 컨테이너와 오케스트레이션
- CI/CD 파이프라인
- 보안과 컴플라이언스
- 로컬 개발 환경
- Contract Testing
- Service Mesh
- 다국가/멀티 리전
이 주제들은 각자 책 한 권 분량이다. 필요한 시점에 별도로 학습해야 한다.
이 책은 그 시작점일 뿐이다.
마지막 메시지
이 책 전체를 한 문장으로 줄이면 이렇다.
마이크로서비스는 강력한 도구다. 그러나 모든 시스템에 필요한 도구는 아니다.
이 두 사실을 동시에 인정하는 사람이 좋은 아키텍처 결정을 내린다.
- 도구의 힘을 안다
- 그 비용도 안다
- 자기 상황을 안다
- 결정을 두려워하지 않는다
- 결정을 되돌릴 줄도 안다
이 책이 그 결정에 도움이 되었기를 바란다.
닫는 말
마이크로서비스는 끝없는 여정이다.
오늘 옳은 아키텍처가 내일은 잘못된 것이 될 수 있다.
중요한 것은 흔들리지 않는 원칙이 아니라 상황을 읽고 다시 결정하는 능력이다.
이 책의 모든 페이지가 그 능력을 키우는 데 조금이라도 도움이 되었기를 바란다.
이제 책을 닫고 당신의 시스템으로 돌아가자.
이 장의 핵심
- 마이크로서비스는 도구이지 목적이 아니다
- 모든 회사·모든 단계에 같은 답은 없다
- 전환을 결정하면 점진적으로, 함정을 점검하며 진행한다
- 회귀할 줄 아는 것도 좋은 결정이다
- 이 책은 시작점이다 — 결정과 실행은 당신의 몫이다