이 lesson 을 다 읽고 나면 아래 3가지를 자신 있게 할 수 있습니다.

• ▸✅ 모놀리스 vs MSA 결정 5가지 체크리스트
• ▸✅ 시스템 다이어그램을 mermaid 로 시각화
• ▸✅ 관심사 분리 (Presentation · Domain · Data)

학습 목표를 체크리스트로 두고 다 답할 수 있게 되면 lesson 을 닫으세요.

MSA (Microservices Architecture) vs 모놀리스:

메시지 큐 — 비동기 통신:

API Gateway — MSA 단일 진입점:

• ▸라우팅 (요청 → 적절한 서비스)
• ▸인증·인가 (각 서비스 중복 X)
• ▸Rate limit·캐싱·로깅
• ▸대표: Kong·AWS API Gateway·Envoy·Traefik

> 💡 언제 MSA?: 팀 8명+ · 트래픽 영역별 차이 큼. 그 전엔 모놀리스 → 모듈화 → 추출.

Event Sourcing — 상태가 아닌 이벤트 저장

• ▸전통: users 테이블 row 업데이트
• ▸ES: events 테이블에 UserCreated·EmailChanged 추가 (불변)
• ▸현재 상태 = 모든 이벤트 재생 (replay)

장점:

• ▸완전한 audit log (누가·언제·뭘 했는지)
• ▸시간 여행 (과거 상태 재현)
• ▸새 read model 추가 쉬움

단점:

• ▸복잡성 ↑ (단순 CRUD 대비)
• ▸이벤트 스키마 변경 어려움 (이벤트는 불변)
• ▸학습 곡선 가파름

CQRS (Command Query Responsibility Segregation):

• ▸Command (쓰기) — 정규화된 DB, 트랜잭션
• ▸Query (읽기) — 비정규화·캐시·검색엔진

예: 쇼핑몰

• ▸Command: PostgreSQL (주문 처리·결제)
• ▸Query: Elasticsearch (상품 검색), Redis (캐시)
• ▸동기화: Kafka 로 변경 이벤트 전달

적합 상황:

• ▸🟢 읽기/쓰기 비율 차이 큼 (예: 10000:1)
• ▸🟢 복잡한 검색·집계
• ▸🔴 단순 CRUD → 오버킬

> 💡 ES + CQRS = 자주 함께. 이벤트 → 다양한 read model 로 변환.

현대 사용 예:

• ▸Banking: ES 가 표준 (감사·규제)
• ▸E-commerce: 주문 부분만 ES
• ▸Gaming: 액션 기록

핵심 한 줄

AI 에게 "MSA 로 만들어줘" 라고만 하면 모놀리스를 그냥 쪼개기만 합니다. 진짜 MSA 가 아닌 분산 모놀리스 (가장 나쁜 형태) 가 됩니다.

왜 AI 만으로 아키텍처 가 안 되나

LLM 은 코드 패턴 학습 했지 비즈니스 도메인 은 모릅니다. 서비스 경계 가 어디인지·어떤 정보를 누가 소유 하는지는 사람이 결정 해야 합니다.

❌ 나쁜 프롬프트:
> "이 모놀리스를 MSA 로 쪼개줘"

→ AI: User Service, Order Service, Payment Service... 단순 분리.
→ 결과: 서비스 간 순환 호출 + 트랜잭션 깨짐 — 진짜 분산 모놀리스.

✅ 좋은 프롬프트:
> "다음 비즈니스 경계로 MSA 설계:
> - Auth Service: 사용자 인증·세션. 다른 서비스는 JWT 만 받음
> - Order Service: 주문 흐름. Payment 와는 이벤트로 통신 (강결합 X)
> - Notification Service: 알림. 다른 서비스는 Kafka 토픽 에 발행
>
> ACID 트랜잭션 필요한 곳: 결제. Saga 패턴 사용."

→ AI: 명확한 경계로 진짜 MSA 구현.

판단 체크리스트 — 내 프로젝트는 모놀리스? MSA?

5 문항 점수 (각 0~2점, 총 10점):

• ▸0-3점 → 모놀리스. 다른 거 신경 X. Next.js + DB 하나 로 시작
• ▸4-6점 → 모놀리스 with 모듈 경계 명확화. 향후 분리 대비
• ▸7-10점 → MSA 검토. 단, 모놀리스로 시작 후 문제 생기는 부분만 분리 권장

"모놀리스 부터 시작" 의 진리

> "If you can't build a monolith, what makes you think microservices is the answer?" — Simon Brown

95% 의 스타트업 은 모놀리스 + 잘 분리된 모듈 로 충분. MSA 는 명백한 페인 포인트 가 있을 때만.

함정 — MSA 의 숨겨진 비용

스타트업 단계에서 MSA = 시간·돈 낭비. 토스·쿠팡 정도 트래픽 되면 그때 고려.

AI 에게 아키텍처 묻기 패턴

❌ "MSA 가 좋아요 모놀리스가 좋아요?" — 추상적

✅ "제 프로젝트는 팀 3명·일 5천 사용자·1주 1배포·Node 단일 스택이에요. 이때 MSA 가 의미 있나요? 체크리스트 기반 으로 분석해줘."

→ AI 가 내 상황에 맞는 답변.

한 번 정리

• ▸AI 는 코드 패턴 만 안다. 비즈니스 경계 는 사람이 결정
• ▸5 문항 체크리스트로 내 상황 진단
• ▸모놀리스 부터. MSA 는 진짜 필요할 때만
• ▸AI 에게 물을 때 구체적 상황 명시

이 lesson 의 개념을 알면 AI 에게 구체적으로 지시할 수 있습니다. 막연한 "고쳐줘" 가 아니라 어휘를 가진 요청 — 그게 토큰 절약의 출발점입니다.

• ▸"이 모놀리스를 MSA 로 분리하기 전에 5가지 체크리스트로 점검해줘"
• ▸"이 시스템 다이어그램을 mermaid 로 그려줘"

왜 이게 토큰을 줄이나

개념을 모를 땐 AI 답변을 받고도 "그게 뭐예요?" 를 다시 물어야 합니다. 그 "다시 물음" 이 토큰을 잡아먹습니다. 개념 한 번 익혀두면 대화가 한 번에 끝납니다.