DoorDash의 엔지니어링 리더 Matt가 말하는 MSA

마이크로서비스는 기술 부채다

---

마이크로서비스를 도입하는 진짜 이유는 '팀 확장'

 

• 많은 사람들이 트래픽 확장을 위해 마이크로서비스를 도입한다고 생각하지만, 실제로는 엔지니어링 팀의 규모가 커졌기 때문인 경우가 많다.
• 수백 명의 개발자가 하나의 모놀리식 코드베이스를 수정하고 배포하려 하면 서로 충돌이 발생하고 배포 속도가 느려진다. 마이크로서비스는 팀들이 서로 독립적으로 배포할 수 있게 해 주어 이 문제를 해결한다.

 

분산된 모놀리스(Distributed Monolith)와 복잡성

 

• 마이크로서비스를 도입하면 초기에는 빠르지만, 결국 모든 서비스가 항상 정상 작동해야 하는 '분산된 모놀리스'가 되기 쉽다.
• 서비스 간의 의존성이 생기면, 하나의 기능을 변경하기 위해 여러 서비스(A, B, C)를 순차적으로 배포해야 하는 등 복잡도가 증가한다. 이는 변경 비용을 높이고 리팩토링을 어렵게 만든다.

 

사회-기술적 문제

 

• 도메인 주도 설계(DDD) 원칙을 너무 엄격하게 적용하면, 간단한 데이터 조회에도 수많은 네트워크 호출(RPC)이 발생하게 된다.
• DoorDash의 경우, 프론트엔드 요청 하나가 평균적으로 약 1,000개 이상의 RPC 호출을 유발한다고 언급하며, 이는 시스템을 매우 복잡하게 만든다.

 

기타 통찰

 

• 데이터베이스 공유: 이론적으로는 마이크로서비스 간 DB 공유가 금기시되지만, 실용적인 이유(빠른 개발)로 DB를 공유하는 것이 더 나은 선택일 때가 있다.
• 테스트: 테스트 커버리지 100% 같은 숫자에 집착하기보다 실제 유의미한 테스트를 작성하는 것이 중요하다. 때로는 과도한 테스트가 구조 변경을 어렵게 만들기도 한다.