Microservices

애플리케이션이 커지면 한 기능의 변경이 전체 배포를 막고, 어떤 영역은 트래픽이 폭증하는데 다른 영역까지 함께 확장해야 하는 상황이 생깁니다. 팀이 여러 개로 갈라지면 코드 소유권도 자주 충돌합니다. 한 덩어리 안에서 모든 속도를 맞추려 하면 조직과 시스템이 서로 발목을 잡습니다. Microservices는 이 독립성 부족 문제를 서비스 경계로 풀어 보려는 접근입니다.

대규모 웹 서비스와 SaaS가 커지면서 팀과 기능이 동시에 늘어났고, 단일 배포 단위가 조직 속도를 따라가지 못하는 문제가 흔해졌습니다. 클라우드와 컨테이너, 자동화된 배포가 보편화되면서 서비스 단위 운영이 현실적인 선택지가 되었습니다. Microservices는 '더 현대적이라서'가 아니라, 조직과 운영 규모가 커질 때 독립성이 실제 병목이 되기 때문에 등장한 구조입니다.

각 서비스는 자기 도메인 책임을 중심으로 API와 데이터 저장소를 소유합니다. 외부 요청은 보통 공통 진입점을 거쳐 적절한 서비스로 라우팅되고, 서비스끼리는 동기 호출이나 이벤트로 협력합니다. 핵심은 단순히 작은 코드베이스가 아니라, 변경과 운영 책임을 분리할 수 있는 경계를 잡는 데 있습니다.

Microservices와 Layered Architecture는 모두 복잡도를 나누지만 나누는 축이 다릅니다. Layered Architecture가 한 애플리케이션 내부에서 책임을 층으로 정리한다면, Microservices는 애플리케이션 경계 자체를 여러 배포 단위로 자릅니다. 또한 Monolith와 달리 네트워크를 건너는 협력이 기본이기 때문에, 데이터 일관성과 관측 가능성 같은 운영 문제가 더 전면으로 올라옵니다.

팀별 ownership이 분명하고, 특정 도메인만 다른 속도로 배포하거나 확장해야 하며, 서비스 경계를 운영할 준비가 된 조직에서 Microservices는 강합니다. 반대로 경계 설계가 불안정하면 분산 호출과 장애 추적만 늘어날 수 있습니다. 즉 코드를 자르는 기술이 아니라, 경계와 운영 책임을 같이 설계하는 방식으로 다뤄야 합니다.

다음에 볼 개념

함께 보면 좋은 개념