[LG CNS AM 6기] 42일차 TIL : MSA 기초 - Monolith와 Microservice Architecture 이해하기

Об этом предложении

TIL - 2026.10.01 📌 오늘 학습한 주제 Software Architecture Cloud Native Monolithic Architecture Microservice Architecture Monolith와 MSA 비교 MSA의 장단점 Bounded Context Service Decomposition Service Ownership SOA와 MSA의 차이 Spring Cloud 💡 오늘 배운 것 — 나만의 언어로 오늘은 지금까지처럼 하나의 기능을 구현하는 수업이 아니라 서비스 전체 구조를 어떻게 설계할 것인지 에 대한 MSA를 배웠다. 지금까지 만든 Spring Boot 프로젝트를 생각해보면 회원, 게시글, 댓글 같은 기능이 하나의 Backend 안에 같이 들어 있었다. 이런 식으로 여러 기능을 하나의 Application으로 묶어서 개발하는 방식이 Monolithic Architecture이다. Monolith는 처음 만들 때는 구조가 단순하고 코드를 찾거나 Debugging하기도 편하다. 하지만 서비스가 점점 커지면 작은 기능 하나를 수정해도 전체 Application을 다시 Build하고 배포해야 할 수 있고, 특정 기능만 따로 확장하기도 어렵다. MSA는 이런 큰 Application을 업무에 맞는 작은 Service로 나누는 방식 이다. 중요한 것은 단순히 프로젝트를 여러 개 만드는 것이 아니라, 각각의 Service가 자신의 역할을 가지고 독립적으로 개발하고 실행하고 배포할 수 있도록 만드는 것 이라고 이해했다. 오늘 수업을 들으면서 MSA는 단순한 코드 분리 방법이라기보다 서비스 규모가 커졌을 때 변경과 장애를 더 잘 관리하기 위한 Architecture라는 생각이 들었다. 💻 오늘 배운 것 1 — Monolith와 MSA Monolithic Architecture Monolith는 여러 업무 기능이 하나의 Application 안에 들어 있는 구조이다. 예를 들어 하나의 쇼핑몰에 회원 상품 주문 결제 기능이 모두 들어 있고 하나의 Spring Boot Application으로 실행된다면 Monolith 구조로 볼 수 있다. 장점은 구조가 비교적 단순하다는 것이다. 처음 개발할 때 전체 코드를 한 프로젝트에서 볼 수 있고, 기능 간 호출도 같은 Application 안에서 처리할 수 있어서 이해하기 쉽다. 하지만 서비스가 커지면 단점도 생긴다. 예를 들어 주문 기능만 조금 수정했어도 전체 Application을 다시 Build하고 배포해야 할 수 있다. 또한 주문 요청만 갑자기 많아졌다고 해서 주문 기능만 따로 확장하기도 어렵다. Microservice Architecture MSA에서는 하나의 큰 Application을 여러 개의 작은 Service로 나눈다. 예를 들어 쇼핑몰이라면 회원, 상품, 주문, 결제 같은 업무를 기준으로 각각 Service를 나눌 수 있다. 여기서 중요한 것은 각 Service가 최대한 독립적으로 움직이는 것이다. 회원 Service를 수정했다고 해서 주문 Service까지 같이 배포해야 하는 구조보다는, 회원 Service만 수정하고 배포할 수 있는 방향을 목표로 한다. ✨ 이해한 점 처음에는 MSA를 그냥 “Spring Boot 프로젝트를 여러 개 만드는 것”이라고 생각하기 쉬웠다. 그런데 오늘 배운 내용을 보면 프로젝트 개수보다 더 중요한 것은 Service의 독립성 이었다. 각 Service가 독립적으로 개발되고 배포되고 필요한 부분만 확장될 수 있어야 MSA를 사용하는 의미가 생긴다. 💻 오늘 배운 것 2 — MSA가 무조건 좋은 것은 아니다 MSA를 배우기 전에는 서비스를 작게 나누면 무조건 더 좋은 구조일 것 같았다. 하지만 오늘 자료에서는 Monolith와 MSA가 각각 장단점이 있다고 설명했다. 구분 Monolith MSA 구조 하나의 Application 여러 개의 Service 개발 초기 비교적 단순 구조 설계가 더 필요 배포 전체 배포가 쉬움 Service별 독립 배포 가능 확장 전체를 기준으로 확장 필요한 Service를 따로 확장 가능 통신 같은 Application 내부 호출 Network 통신이 생김 장애 영향 범위가 커질 수 있음 Service 단위로 격리 가능 데이터 관리 비교적 단순 서비스 간 데이터 관리가 어려워질 수 있음 MSA의 장점은 Service끼리 결합도를 낮출 수 있고, 필요한 Service만 확장하거나 변경하기 쉽다는 점이다. 반대로 Service가 서로 Network를 통해 통신하기 때문에 통신 지연이나 장애를 생각해야 하고, 여러 Service에 나뉜 데이터를 어떻게 맞출 것인지도 고민해야 한다. ✨ 이해한 점 Monolith가 나쁜 구조이고 MSA가 좋은 구조라는 식으로 보면 안 될 것 같다. 작은 서비스에서는 오히려 Monolith가 더 단순하고 관리하기 편할 수 있다. MSA는 독립적인 배포나 확장이 필요한 규모가 됐을 때 장점이 생기는 구조라고 이해했다. 💻 오늘 배운 것 3 — Service를 어디까지 나눌까? MSA에서 제일 어려워 보였던 부분은 “어디까지를 하나의 Service로 볼 것인가?” 였다. Microservice라는 이름 때문에 기능을 최대한 잘게 쪼개야 할 것 같지만, 무조건 작게 만드는 것이 목적은 아니었다. 오늘은 Domain Driven Design의 Bounded Context 라는 개념도 같이 배웠다. 쉽게 이해하면 하나의 Service가 담당할 업무 범위를 정하는 경계 라고 생각했다. 예를 들어 CRM Application 안에 고객 관리, 계약 관리, VOC 관리가 있다면 이것을 하나로 묶을 수도 있지만 업무 성격에 따라 고객 Service 계약 Service VOC Service 처럼 나눌 수 있다. 그리고 하나의 Service 안에는 서로 관련 있는 기능들이 모여 있어야 한다. 고객 Service라면 고객과 관련된 기능을 모으고, 주문 Service라면 주문과 관련된 기능을 모으는 식이다. Service Decomposition Service를 나눌 때는 단순히 Class 이름이나 기술 기준으로 나누는 것이 아니라 업무를 먼저 이해하고 어떤 부분이 독립적으로 배포되고 확장되어야 하는지 판단하는 과정 이 필요하다. 그래서 오늘 자료에서는 Business Domain을 이해하고 Bounded Context를 찾은 뒤 Service 경계를 정하는 흐름을 설명했다. ✨ 이해한 점 MSA에서는 Controller Service , Repository Service 처럼 Layer 기준으로 나누는 것이 아니라, 회원 , 상품 , 주문 , 결제 처럼 업무 기준으로 Service를 나누는 것이 중요하다. 그래서 MSA는 개발 코드만 보는 게 아니라 실제 업무가 어떻게 나뉘어 있는지도 알아야 설계할 수 있다는 생각이 들었다. 📌 Service Ownership MSA에서는 Service를 나누는 것뿐 아니라 누가 그 Service를 책임지는지 도 중요했다. 한 팀이 특정 Service를 담당하면 그 팀이 기획, 개발, 테스트, 배포, 운영까지 Service의 전체 과정을 책임질 수 있다. 예를 들어 주문 Service를 맡은 팀이 주문 기능을 직접 개발하고 테스트한 뒤 배포까지 할 수 있다면 다른 팀의 작업을 계속 기다리지 않고 더 독립적으로 움직일 수 있다. 오늘 자료에서 나온 Two Pizza Team도 이런 작은 팀 단위의 Service 운영과 연결되는 내용이었다. ✨ 이해한 점 MSA는 서버를 여러 개 만드는 기술적인 문제만 있는 것이 아니라 팀을 어떻게 나누고 누가 어떤 Service를 책임질 것인지까지 연결되는 Architecture 라는 점이 기억에 남았다. 📌 Cloud Native와 지금까지 배운 내용 연결하기 오늘 MSA를 배우면서 전에 배운 Docker, CI/CD, DevOps가 다시 나왔다. Cloud Native Application을 설명할 때 Microservices Containerization Continuous Delivery DevOps 가 같이 나왔다. 전에는 각각 따로 배운 기술처럼 느껴졌는데 오늘은 왜 같이 사용되는지 조금 연결됐다. MSA에서는 Service가 여러 개로 나뉠 수 있다. 그러면 각각의 Service를 실행할 환경이 필요하고, Service마다 배포하는 과정도 많아진다. 그래서 Docker로 실행 환경을 묶고, GitHub Actions나 Jenkins 같은 CI/CD를 이용해 Build와 배포를 자동화하는 것이 중요해진다. ✨ 이해한 점 전에는 Docker나 GitHub Actions를 그냥 “배포를 편하게 하는 도구” 정도로 생각했다. 오늘 MSA를 배우고 나니 Service를 독립적으로 자주 배포하고 운영하기 위해 이런 기술들이 같이 필요한 것 이라는 점이 더 잘 이해됐다. 📌 SOA와 MSA 차이 SOA와 MSA는 둘 다 Service라는 단위로 시스템을 구성한다는 점에서 비슷하다. 하지만 수업에서는 방향의 차이를 설명했다. SOA는 공통 Service를 공유하고 재사용하는 것에 더 초점을 맞춘다. 반면 MSA는 작은 Service가 서로 낮은 결합도를 유지하면서 독립적으로 실행되는 것에 더 초점을 둔다. 쉽게 정리하면 SOA는 Service 재사용 , MSA는 Service 독립성 을 더 중요하게 보는 차이가 있다고 이해했다. 💻 오늘 배운 것 4 — Spring Cloud는 왜 필요한가? Service를 여러 개로 나누면 새로운 문제도 생긴다. 예를 들어 회원 Service, 주문 Service, 결제 Service가 각각 따로 실행되고 있다면 어떤 Service가 어디에서 실행되고 있는지 알아야 하고, 여러 Instance가 있다면 어느 곳으로 요청을 보내야 하는지도 정해야 한다. 설정도 Service마다 관리해야 하고, 하나의 Service에서 장애가 났을 때 어떻게 대응할지도 필요하다. 이런 분산 시스템에서 반복해서 필요한 기능들을 도와주는 것이 Spring Cloud 이다. 오늘은 Spring Cloud 기능을 직접 구현한 것은 아니고 전체적인 역할을 먼저 봤다. 대표적으로 Config Server: 여러 Service의 설정 관리 Service Discovery: Service 위치 찾기 Load Balancing: 요청 분산 API Gateway: 외부 요청의 입구 역할 OpenFeign: Service 간 REST 통신 Monitoring / Tracing: 요청 흐름 확인 Fault Tolerance: 장애 대응 같은 기능들이 있다는 것을 확인했다. ✨ 이해한 점 Monolith에서는 Application 하나만 잘 관리하면 됐지만 MSA에서는 Service가 많아지기 때문에 Service들을 연결하고 관리하는 기능이 추가로 필요하다. Spring Cloud는 MSA 그 자체라기보다는 이런 분산 시스템을 만들 때 필요한 기능을 제공해주는 도구라고 이해했다. ❓ 어려웠던 점 & 정리 문제 1 — 프로젝트를 여러 개 만들면 MSA인가? 처음에는 Backend 프로젝트를 회원, 주문, 결제로 여러 개 만들면 바로 MSA라고 생각하기 쉬웠다. 정리 프로젝트 수보다 중요한 것은 각각의 Service가 업무적으로 명확한 역할을 가지고 독립적으로 개발·배포될 수 있는지이다. 문제 2 — Service는 작게 만들수록 좋은가? Microservice라는 이름 때문에 기능마다 Service 하나씩 만드는 것이 좋은 줄 알았다. 정리 무조건 작게 쪼개는 것이 목적은 아니다. 업무 경계와 변경 주기, 확장 필요성 등을 보고 Service의 적절한 범위를 정해야 한다. 문제 3 — MSA가 더 복잡한데 왜 사용하는가? Service를 나누면 Network 통신도 생기고 데이터 관리도 어려워져 오히려 복잡해 보였다. 정리 독립적인 배포, 확장, 장애 격리가 필요할 정도로 서비스가 커졌을 때 MSA의 장점이 생긴다. 그래서 상황에 맞게 Architecture를 선택하는 것이 중요하다. 🧩 오늘 배운 개념 정리 개념 오늘 이해한 내용 Software Architecture 시스템의 구성 요소와 관계를 설계하는 것 Monolith 여러 기능이 하나의 Application에 들어 있는 구조 MSA 업무 단위 Service를 독립적으로 구성하는 구조 Cloud Native Cloud 환경에서 확장과 배포를 고려한 구조 Bounded Context 하나의 Service가 담당할 업무 범위 Service Decomposition 큰 Application을 Service 단위로 나누는 과정 Ownership 한 팀이 Service의 개발부터 운영까지 책임지는 구조 Fault Isolation 한 Service 장애가 다른 Service까지 퍼지는 것을 줄이는 것 Spring Cloud 분산 시스템에서 필요한 여러 기능을 제공하는 Spring 프로젝트 Service Discovery Service가 어디에서 실행되고 있는지 찾는 기능 API Gateway 외부 요청을 받아 알맞은 Service로 전달하는 입구 📌 오늘 이해한 전체 흐름 큰 Application ↓ 업무 Domain 분석 ↓ Service 경계 정하기 ↓ 각 Service 독립적으로 구성 ↓ Microservice Architecture ↓ Docker로 실행 환경 관리 ↓ CI/CD로 Build / Deploy 자동화 ↓ Spring Cloud로 Service Discovery, Gateway, 설정 등을 관리 오늘 수업을 통해 MSA는 단순히 Backend를 여러 프로젝트로 나누는 것이 아니라 업무를 기준으로 Service의 경계를 정하고, 각각을 독립적으로 운영할 수 있도록 전체 구조를 설계하는 방식 이라는 점을 이해했다. 📅 다음에 할 일 & 아직 모르는 것 실제 프로젝트에서 Bounded Context를 기준으로 Service를 나눠보기 Service Discovery가 실제 코드에서 어떻게 동작하는지 확인하기 API Gateway를 직접 구성해보기 Service별 데이터가 분리될 때 데이터 정합성을 어떻게 맞추는지 알아보기 Monolith와 MSA 중 어떤 상황에서 어떤 구조를 선택할지 다시 정리하기 ✅ 오늘 한 줄 정리 오늘은 Monolith와 MSA의 차이를 배우면서 MSA가 단순히 프로젝트를 여러 개 만드는 방식이 아니라, 업무 기준으로 Service를 나누고 각각 독립적으로 개발·배포·확장할 수 있도록 설계하는 Architecture라는 것을 배웠다. 또한 Docker, CI/CD, DevOps 같은 기술이 Cloud Native와 MSA 운영에 왜 필요한지 연결해서 이해했고, 앞으로 Spring Cloud를 이용해 여러 Microservice를 관리하는 방법을 배우게 될 것 같다. 핵심 학습 주제 MSA, Monolith, Microservice, Cloud Native, Bounded Context, Service Decomposition, Spring Cloud 태그 Java SpringBoot MSA Microservice Monolith CloudNative SpringCloud BoundedContext ServiceDecomposition Docker CICD DevOps TIL