마이크로서비스는 목표가 아니다

아샬

시스템이 커지면 이런 말을 자주 듣습니다.

“이제 마이크로서비스로 가야 하지 않을까요?”

그럴듯하게 들립니다.
규모가 커졌으니 구조도 더 커져야 할 것 같고,
팀이 늘었으니 시스템도 나눠야 할 것 같습니다.

그런데 질문부터 다시 해야 합니다.

마이크로서비스는 좋은 구조가 아닙니다.
복잡한 구조입니다.

네트워크가 생기고,
배포 단위가 늘어나고,
상태가 흩어지고,
장애 지점도 많아집니다.

그 자체만 놓고 보면 모놀리식보다 훨씬 어렵습니다.
그런데도 마이크로서비스를 선택하는 이유는 하나입니다.

전체 시스템의 복잡도를 낮출 수 있을 때입니다.

나눴는데 같이 바뀐다

많은 팀이 처음에는 기능 이름을 기준으로 나눕니다.

회원 마이크로서비스
게시판 마이크로서비스
주문 마이크로서비스
결제 마이크로서비스

처음에는 깔끔해 보입니다.
이름도 명확하고, 책임도 나뉜 것 같습니다.

그런데 조금만 지나면 이상한 일이 생깁니다.
회원 정책 하나를 바꾸려고 했는데 게시판도 고쳐야 합니다.
주문 규칙 하나를 바꾸려고 했는데 결제와 배송까지 같이 손봐야 합니다.

배포 단위는 나뉘었는데 변경은 함께 일어납니다.

이러면 복잡도는 줄지 않습니다.
오히려 더 커집니다.

예전에는 같은 코드베이스 안에서 함께 바꾸면 됐습니다.
이제는 네트워크 호출, 메시지 순서, 장애 처리, 배포 타이밍까지 함께 신경 써야 합니다.

겉으로는 마이크로서비스가 됐지만,
실제로는 분산 모놀리식이 된 것입니다.

비슷한 것끼리 묶는 게 아니다

좋은 분리는 비슷한 기능끼리 나누는 것이 아닙니다.
함께 변경되는 것끼리 묶는 것입니다.

주문 생성, 결제 승인, 배송 시작이 항상 같이 바뀐다면
셋을 억지로 나누는 순간 복잡도가 늘어납니다.

정책이 바뀔 때마다 세 군데를 고쳐야 하고,
세 군데의 배포 순서를 맞춰야 하고,
중간에 하나가 실패했을 때 보상 절차도 생각해야 합니다.

그럴 바에는 하나로 유지하는 편이 낫습니다.

반대로 상품 검색은 주문 규칙과 거의 같이 변하지 않을 수 있습니다.
검색 조건, 랭킹, 캐싱, 색인 방식은 주문 생성 규칙과 다른 이유로 바뀝니다.

그렇다면 상품 검색은 분리 후보가 됩니다.
나눴을 때 독립적으로 바뀔 가능성이 있기 때문입니다.

핵심은 “이름이 다르냐”가 아닙니다.
변경 이유가 다르냐입니다.

기술보다 먼저 물어야 할 것

마이크로서비스 이야기를 시작하면 금방 기술 이름이 나옵니다.

Kafka, Redis, gRPC, Service Mesh.

물론 필요할 수 있습니다.
하지만 그보다 먼저 물어야 할 질문이 있습니다.

이 변경은 항상 같이 일어나는가?

이 질문에 답하지 못한 채 기술을 붙이면
복잡도는 줄지 않습니다.

메시지 브로커를 붙여도 여전히 같이 배포해야 하고,
gRPC를 써도 여전히 같이 고쳐야 하고,
Service Mesh를 도입해도 경계 자체가 생기지는 않습니다.

기술은 경계를 만들어 주지 않습니다.
이미 발견한 경계를 운영할 수 있게 도와줄 뿐입니다.

좋은 설계는 변경을 기준으로 한다

좋은 구조는 화면을 기준으로 나누지 않습니다.
조직도를 그대로 옮겨서도 안 됩니다.
테이블 이름을 기준으로 나누는 것도 위험합니다.

좋은 구조는 변경의 경계를 기준으로 나눕니다.

어디까지는 항상 같이 바뀌는지.
어디부터는 따로 바뀌어도 되는지.
어느 규칙은 강하게 묶어야 하고,
어느 연결은 느슨해도 되는지.

이 경계를 발견하는 것이 설계입니다.

그래서 설계는 다이어그램을 예쁘게 그리는 일이 아닙니다.
변경이 일어났을 때 어디까지 영향을 받는지 확인하는 일입니다.

지금 나누려는 이유가 무엇인가

규모가 커졌다는 것만으로는 마이크로서비스를 선택할 이유가 되지 않습니다.

정말 물어야 할 질문은 따로 있습니다.

이번에 나누려는 경계는 실제 변경 경계인가요?
나눈 뒤에 독립적으로 배포할 수 있나요?
장애가 나도 다른 기능은 계속 동작하나요?
아니면 결국 매번 같이 고치고 함께 배포해야 하나요?

이 질문에 답하지 못하면,
마이크로서비스는 해결책이 아니라 새로운 짐이 됩니다.

마이크로서비스는 기술만으로 되는 게 아닙니다.
복잡도를 줄이기 위한 선택입니다.

와일드 백엔드에서는 프레임워크보다 먼저,
무엇을 함께 묶고 무엇을 나눌지 판단하는 기준을 다룹니다.