Microservices

제품이 커지면 결제 팀이 준비한 기능 하나를 배포하려 해도, 추천 팀과 사용자 팀의 코드가 모두 준비될 때까지 기다려야 하는 상황이 생깁니다. 특정 도메인에만 트래픽이 몰려도 관계없는 다른 기능까지 함께 확장해야 하고, 긴급 패치가 필요해도 전체 릴리스 사이클을 거쳐야 합니다. 팀 수가 늘수록 이 대기 비용은 선형이 아니라 기하급수적으로 커집니다. 어느 팀의 변경 하나가 전체 배포를 막는 상황이 반복되면, 독립 배포 단위를 나눠야 한다는 압력이 실질적으로 만들어집니다.

2000년대 초반까지 대부분의 웹 서비스는 하나의 코드베이스에서 빌드하고 배포했습니다. 팀이 작고 기능이 단순할 때는 이 방식이 충분히 효율적이었습니다. 문제는 팀이 수십 명을 넘어서고 도메인이 복잡해지면서 시작됐습니다. 한 팀의 변경이 다른 팀의 배포를 블로킹하고, 전체 배포 사이클이 느려지면서 조직 속도가 꺾였습니다. 같은 시기 클라우드와 컨테이너가 보편화되면서 서비스 단위 독립 운영이 기술적으로 현실화됐습니다. Microservices는 이 두 흐름, 즉 조직 병목을 해소하고 싶다는 압력과 인프라 성숙이 맞물리면서 등장했습니다. '더 현대적이라서'가 아니라, 특정 규모에서 단일 배포 단위가 실제 병목이 됐기 때문에 생긴 구조입니다.

각 서비스는 자기 도메인에 해당하는 API와 데이터 저장소를 따로 소유합니다. 주문 서비스는 주문 DB만 보고, 사용자 서비스는 사용자 DB만 봅니다. 다른 서비스의 데이터가 필요할 때는 DB를 직접 조회하지 않고 API나 이벤트로 요청합니다. 그 결과 한 서비스의 내부 구조를 바꿔도, 인터페이스가 유지되는 한 다른 서비스는 영향받지 않습니다. 외부 클라이언트 요청은 서비스 앞단의 단일 진입점을 통해 적절한 서비스로 전달되고, 배포는 서비스 단위로 각자 이루어집니다. 이 구조에서는 경계를 어떻게 잡느냐가 가장 중요한 설계 결정입니다. 경계가 어긋나면 서비스 간 호출만 늘고 이점은 줄어듭니다.

Monolith와 Microservices는 모두 하나의 제품을 구현하지만 배포 단위가 다릅니다. Monolith는 하나의 코드베이스와 하나의 배포 단위로 전체를 묶어 운영하고, Microservices는 도메인 경계마다 별도 서비스를 두어 각자 배포합니다. 팀이 작고 도메인이 단순하면 Monolith가 더 빠르고 일관성을 유지하기 쉽습니다. Microservices는 독립 배포와 독립 확장이 실제 병목이 됐을 때, 운영 복잡성을 감수하고 전환하는 방식입니다. Layered Architecture와는 나누는 축이 다릅니다. Layered는 하나의 애플리케이션 내부에서 프레젠테이션·비즈니스·인프라 같은 책임을 수직으로 분리하고, Microservices는 그 애플리케이션 경계 자체를 도메인 단위로 수평으로 자릅니다. 둘은 상호 배타적이지 않아서 각 마이크로서비스 내부를 Layered 구조로 설계하는 경우도 흔합니다. Microservices가 맞지 않는 경우는 팀 규모가 작거나 도메인 경계가 아직 불분명할 때입니다. 경계가 확정되지 않은 상태에서 서비스를 나누면 나중에 경계를 바꿀 때 큰 비용이 생깁니다.

보통 여러 팀이 각자 다른 속도로 기능을 출시하고, 도메인마다 트래픽 패턴이 달라 확장 전략이 달라야 하는 시점에 Microservices를 도입합니다. '이 기능 배포하려면 다른 팀 배포 끝날 때까지 기다려야 한다'는 상황이 반복된다면, 배포 경계를 분리할 시점이라는 신호입니다. 각 서비스 팀은 자기 도메인 DB와 배포 파이프라인을 소유하고, 다른 팀에게는 안정된 인터페이스만 노출합니다. 단, 서비스 간 호출이 늘수록 장애 전파 경로와 추적이 복잡해지므로 관측 가능성과 분산 추적 도구를 함께 갖춰야 합니다. 팀이 작거나 도메인 경계가 불분명한 상태에서는 서비스를 먼저 나누기보다 경계 설계를 다듬는 것이 낫습니다.