1. MSA와 DDD 기반 서비스 설계 핵심 정리
1️⃣ MSA(Microservices Architecture) 개념
1) MSA란?
- 하나의 큰 시스템을 작은 서비스 단위로 분리하여 개발/운영하는 아키텍처
- 각 서비스는 독립적으로 배포, 확장, 개발 가능
2) 왜 사용하는가?
- 특정 기능에 트래픽이 몰릴 때 해당 서비스만 확장 가능
- 장애 발생 시 전체 시스템이 아니라 일부 서비스만 영향
- 팀 단위로 나누어 개발 속도 향상
2️⃣ 모놀리식 vs MSA 핵심 차이
1) 모놀리식 구조
- 특징
- 하나의 애플리케이션에 모든 기능 포함
- 장점
- 단순함
- 초기 개발 빠름
- 단점
- 일부 기능 때문에 전체 서버 다운
- 특정 기능만 확장 불가능
- 코드가 커질수록 유지보수 어려움
2) MSA 구조
- 특징
- 기능별로 서비스 분리
- 장점
- 필요한 서비스만 확장 가능 (ex. 수강신청)
- 장애 격리 가능
- 팀 단위 개발 가능
- 단점
- 분산 시스템 → 복잡도 증가
- 트랜잭션 처리 어려움
3️⃣ MSA가 필요한 실제 사례 (수강신청 시스템)
1) 문제 상황
- 수강신청 기간 → 트래픽 폭증
- 기존 구조
- 수강신청 + 급여 + 인사 + 재무 → 모두 같은 서버
➡️ 수강신청 기간에 전체 시스템 다운
2) 해결 방법 (MSA 적용)
- 수강신청 서비스만 분리
- 해당 서비스만 서버 증설, 컨테이너 확장
3) 핵심 기술
- 클라우드: Amazon Web Services (AWS)
- 컨테이너 기반 배포 (Docker 등)
- 오토스케일링 (트래픽 폭증 기간 예상 불가할 경우)
- 트래픽 증가 → 자동 서버 증가
- 트래픽 감소 → 서버 축소
4️⃣ DDD(Domain-Driven Design) 핵심 개념
1) DDD란?
- 개념
- 비즈니스(도메인)를 중심으로 설계하는 방법론
- 핵심
- "기능이 아니라 업무 영역 기준으로 시스템을 나눈다"
5️⃣ Bounded Context (바운디드 컨텍스트)
1) 개념
- 하나의 도메인을 명확한 경계로 나눈 영역
- 각 영역은 독립적인 모델과 책임을 가짐
2) 잘못된 구조 예시
- 각 부서마다 “환경팀” 존재
- 국방부 환경팀
- 교통부 환경팀
- 해양수산부 환경팀
- 문제
- 동일 업무가 여러 곳에 존재 (중복)
- 상위 조직 영향 → 독립성 없음
- 전문성 저하, 효율성 감소
3) 올바른 구조 (DDD 관점)
- “환경”이라는 도메인을 하나로 묶음 → 환경부 중심
- 각 부서에 전문 인력 파견
- 효과
- 명확한 책임
- 높은 전문성
- 중복 제거
6️⃣ DDD + MSA 연결 관계 (핵심 중요🔥)
1) 관계 구조
- DDD → 서비스를 어떻게 나눌지 결정 (설계 기준)
- MSA → 나눈 서비스를 어떻게 운영할지 결정 (실행 구조)
2) 잘못된 설계 vs 올바른 설계
❌ 잘못된 경우
- 기술 기준으로 나눔 (Controller, Service 등)
- 결과 → 강한 결합
✅ 올바른 경우
- 도메인 기준으로 나눔 (주문, 결제, 회원 등)
- 결과 → 독립적인 서비스
7️⃣ 애자일(Agile)과의 관계
1) 애자일이란?
- 빠르게 개발하고 → 피드백 받고 → 개선 반복
2) MSA + 애자일 시너지
- 서비스 단위로 배포 가능 → 빠른 개선
- 작은 단위 개발 → 리스크 감소
- 흐름
- 목표 설정
- 작은 기능 개발
- 배포
- 피드백 반영 반복
8️⃣ 핵심 요약 (시험/면접용)
1) 한 줄 정리
- DDD로 도메인을 나누고 → MSA로 서비스 분리 및 운영한다
2) 키워드 정리
- MSA: 서비스 분리, 독립 배포, 확장성
- DDD: 도메인 중심 설계
- Bounded Context: 책임 경계
- 오토스케일링: 트래픽 대응
- 애자일: 반복적 개선
9️⃣ 실무 관점 핵심 포인트
- 서비스 분리는 "기능"이 아니라 "도메인" 기준
- 트래픽 집중 서비스는 반드시 분리 (ex. 결제, 수강신청)
- 클라우드 + 컨테이너 + 오토스케일링은 MSA 필수 요소
- DDD 없이 MSA 하면 → 서비스 경계 망가짐 (가장 흔한 실패 원인)
Share article