모놀리식 · MSA · 서버리스 — 큰 그림 3종
한 덩어리(모놀리식) vs 여러 서비스(MSA) vs 함수 단위(서버리스) — 언제 뭘 고를까.
"우리도 MSA로?" 2010년대 유행에 휩쓸리지 말 것. 회사 규모·팀 수·트래픽에 따라 답이 다르다. 바이브코더 대부분은 모놀리식 + 선택적 서버리스가 정답.
아키텍처 선택은 기술 결정이 아니라 조직 결정이다. 콘웨이의 법칙: "조직 구조를 닮은 시스템이 만들어진다". 5명 스타트업이 MSA로 가면 DevOps에 다 녹는다.
| 스타일 | 뜻 | 장점 | 단점 | 어울리는 규모 |
|---|---|---|---|---|
| 모놀리식 | 한 코드베이스·한 배포 단위 | 단순·빠른 개발·트랜잭션 쉬움 | 기능 커지면 충돌 | ~50명 팀 |
| 모듈러 모놀리식 | 한 배포지만 내부 모듈 분리 | 분리·통합 장점 함께 | 규율 필요 | 중간 |
| MSA | 여러 서비스·독립 배포 | 팀 자율·스케일·기술 선택 | 분산 복잡도 폭발 | 대규모·여러 팀 |
| 서버리스 | 함수 단위, 요청당 과금 | 운영 거의 제로·자동 스케일 | 콜드 스타트·제약 많음 | 스파이키 트래픽 |
"Start monolith" 원칙. Martin Fowler·Basecamp DHH 모두 동의. 처음엔 모놀리식으로 빠르게, 경계가 명확해지면 선택적으로 MSA 또는 서버리스로 분리. 반대로 MSA 먼저 → 모놀리식 복귀(DHH, Prime Video) 사례도 다수.
MSA의 숨은 비용. 네트워크 호출(장애+지연), 분산 트랜잭션(Saga 패턴 필수), 로그 추적(Distributed Tracing), 배포 조정, 데이터 일관성. "작은 서비스 10개" = 운영 복잡도 10배가 아니라 100배에 가까움.
// ━━━ 모놀리식 (Next.js 풀스택) ━━━
// 한 저장소, 한 배포, 모든 기능
// app/
// (auth)/login/page.tsx
// api/users/route.ts
// api/payments/route.ts
// lib/
// db.ts, auth.ts, email.ts
// ━━━ 서버리스 예시 (Vercel Functions) ━━━
// app/api/resize-image/route.ts → 자동으로 서버리스 함수로 배포
export async function POST(req: Request) {
const file = await req.formData();
const buf = await sharp(file.get("image")).resize(800).toBuffer();
return new Response(buf);
}
// Vercel·AWS Lambda가 요청당 뜨고 꺼짐
// ━━━ MSA 예시 (서비스 간 HTTP) ━━━
// user-service (port 3001) ← → payment-service (port 3002)
const user = await fetch("http://user-service/api/users/42").then(r => r.json());
const payment = await fetch("http://payment-service/api/charge", {
method: "POST", body: JSON.stringify({ userId: user.id, amount: 10000 })
});
// → 여기서 네트워크 장애·타임아웃·분산 트랜잭션 문제 발생Next.js는 모놀리식 + 자동 서버리스 하이브리드. 라우트별로 Vercel이 서버리스 함수로 배포. 바이브코더에겐 이 조합이 2026년 현실의 디폴트.
BFF (Backend for Frontend) 패턴. MSA 시대 프론트에 맞춘 얇은 게이트웨이. 모바일·웹마다 다른 BFF를 두고, 뒤의 여러 MSA를 조립해 응답. Next.js의 API 라우트가 BFF 역할을 하는 경우 많음.
5명 스타트업 팀에겐 MSA가 모놀리식보다 항상 더 유리하다.
MSA에서 여러 서비스에 걸친 트랜잭션을 순차·보상 단계로 처리하는 패턴의 이름은?