마이크로서비스 vs. 모놀리스: 어떤 아키텍처를, 언제 선택해야 할까?

모놀리스는 하나의 단위로 배포되는 단일 애플리케이션이고, 마이크로서비스는 이를 API로 통신하며 독립적으로 배포되는 작은 서비스들로 분할한 구조입니다. 이 논쟁은 아키텍처 문제처럼 들리지만 대부분 조직의 문제입니다. 진짜 질문은 팀 구조, 도메인 지식, 운영 성숙도가 분할의 비용을 감당할 수 있는가입니다. 분할은 언제나 비용을 청구하기 때문입니다.

핵심 요약

코드 한 조각으로 보는 차이

모놀리스 안에서 다른 모듈을 호출하는 것은 함수 호출입니다. 빠르고, 원자적이며, 일부만 실패하는 일이 없습니다:

// 모놀리스: 프로세스 내 호출 – 트랜잭션 하나, 장애 도메인 하나
const receipt = await billing.chargeOrder(order.id);

// 마이크로서비스: 같은 호출이 네트워크를 건넙니다 – 이제 타임아웃,
// 재시도, 부분 실패, 최종 일관성이 모두 여러분의 몫입니다
const res = await fetch('https://billing.internal/charge', {
  method: 'POST',
  body: JSON.stringify({ orderId: order.id }),
  signal: AbortSignal.timeout(3000),   // billing이 느리면?
});
if (!res.ok) await compensateOrder(order.id); // 절반만 성공했다면?

마이크로서비스의 모든 고통은 마지막 세 줄에 있습니다. 관리형 중간 길은 커스텀 로직을 독립적으로 배포할 수 있게 하면서도 장애 처리를 떠넘기지 않습니다. 함수는 서비스처럼 호출되지만 플랫폼이 관리하는 인프라에서 실행됩니다:

// JavaScript / Node.js — Back4app JS SDK
// One deployable unit of business logic, no service mesh required
const receipt = await Parse.Cloud.run('chargeOrder', { orderId: 'ord_481' });
console.log(`Charged: ${receipt.status}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('chargeOrder');
final response =
    await function.execute(parameters: {'orderId': 'ord_481'});
if (response.success) {
  print('Charged: ${response.result['status']}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("chargeOrder",
                        parameters: ["orderId": "ord_481"]) { result in
  if case .success(let receipt) = result {
    print("Charged: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("orderId" to "ord_481")
ParseCloud.callFunctionInBackground<Map<String, Any>>("chargeOrder", params) { receipt, e ->
  if (e == null) Log.d("Billing", "Charged: ${receipt["status"]}")
}

둘이 아니라 세 가지 형태

고전적인 마이크로서비스 글은 목적지를 설명하고, MonolithFirst는 그 길을 설명합니다. 성공한 마이크로서비스 시스템은 거의 모두 너무 커진 모놀리스에서 출발했으며, 모듈형 모놀리스는 그 선택지를 열어 두는 방법입니다. 경계가 먼저이고 네트워크는 나중에, 그것도 필요가 입증된 곳에만 둡니다.

마이크로서비스 vs. 모놀리스: 실무적 차이

이 표에서 가장 핵심적인 행은 복잡성이 사는 곳입니다. 시스템을 분할한다고 복잡성이 사라지지는 않습니다. 코드베이스에서 네트워크, 배포 파이프라인, 새벽 3시의 대시보드로 자리를 옮길 뿐입니다.

양방향의 마이그레이션 사례

유명한 방향은 이렇습니다. 한 대형 비디오 스트리밍 플랫폼은 수년에 걸쳐 모놀리스를 천 개가 넘는 서비스로 분할해, 실제로 안고 있던 확장 문제를 해결했습니다. 반대 방향은 더 최근의 일이지만 똑같이 교훈적입니다. 같은 업계에서 한 모니터링 서비스는 서버리스 마이크로서비스를 단일 프로세스로 다시 합쳐 인프라 비용을 약 90% 줄였습니다. 조각들 사이로 데이터를 옮기는 것이 지배적인 비용이었기 때문입니다. 또 어떤 엔지니어링 팀들은 감당할 수 없게 된 테스트 스위트와 의존성 관리를 이유로 백 개가 넘는 서비스를 하나로 통합했습니다. 두 방향 모두 합리적이었습니다. 변하지 않는 것은, 아키텍처가 유행이 아니라 측정된 문제를 따랐다는 점입니다.

일반적인 사용 사례

• 모놀리스: 신규 제품, 소규모 팀, 불분명한 도메인. 학습 속도가 확장 이론보다 중요한 모든 곳입니다.
• 모듈형 모놀리스: 현재의 오버헤드 없이 미래의 선택지를 원하는 성장 중인 제품. 지켜 낼 가치가 있는 기본값입니다.
• 마이크로서비스: 독립적으로 출시하는 여러 팀, 확장 요구가 갈리는 컴포넌트(피드 vs. 결제), 신속한 프로비저닝과 모니터링, 온콜을 이미 운영하는 조직입니다.
• 관리형 백엔드와의 하이브리드: 표준 기능(인증, 데이터, 스토리지)은 서비스로 소비하고, 커스텀 로직은 독립 배포되는 함수로 운영합니다. 모놀리스급 운영 비용으로 서비스급 자율성을 얻습니다.

분할해야 할까? 결정 매트릭스

왼쪽 열이 현재 상황을 설명하는데 오른쪽 열에 끌린다면, 모듈형 모놀리스가 솔직한 타협안입니다. 그리고 분할했는데 변경마다 서비스 세 개를 건드리게 된다면, 분산 모놀리스를 만든 것이므로 부끄러워하지 말고 다시 합쳐야 합니다.

한계와 트레이드오프

• 모놀리스: 팀이 늘어날수록 릴리스 트레인이 느려지고, 메모리 누수 하나가 모두의 장애가 되며, 모듈 규율이 느슨해지면 오래 묵은 얽힘이 추출을 가로막습니다.
• 마이크로서비스: “마이크로서비스 프리미엄”입니다. 분산 트랜잭션, 네트워크 장애 처리, 같은 회사 팀 사이의 버전 관리된 API, 그리고 그 자체로 예산 항목이 되는 관측 가능성 스택이 따라옵니다.
• 양쪽 모두: 어느 쪽도 잘못 모델링된 도메인을 고쳐 주지 않습니다. 나쁜 모델 위에 그은 서비스 경계는 같은 혼란의 분산 버전을, 지연 시간까지 더해서 만들어 냅니다.
• 조직의 제약은 실재합니다: 콘웨이의 법칙대로, 출시되는 것은 조직의 의사소통 구조입니다. 팀을 재편하지 않고 아키텍처만 재편하면 어김없이 안티패턴이 나옵니다.

Back4app에서의 마이크로서비스와 모놀리스

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이는 논쟁의 전제를 바꿉니다. 백엔드의 표준적인 80%는 애초에 직접 설계할 대상이 아니고, 커스텀 20%는 Cloud Code 함수로 실행됩니다. 각 함수는 마이크로서비스처럼 독립적으로 배포되지만, 서비스 메시도, 서비스별 데이터베이스도, 온콜 로테이션도 필요 없습니다. 그것마저 넘어서는 팀에게도 출구는 남아 있습니다. 스택이 오픈소스이므로, 나중에 진짜 서비스를 추출하는 작업은 재작성이 아니라 이미 작동하는 경계에서 시작합니다.