0) 큰 지도: 아키텍처 스펙트럼
- 단일 ⇒ 모듈러 ⇒ 분산으로 갈수록 복잡도·운영비용이 증가하고, 독립성·확장성·배포 유연성이 커집니다.
- 보통 모놀리식 → 모듈러 모놀리식 → 마이크로서비스로 점진적 진화가 현실적입니다(스트랭글러 패턴).
1) 레이어드 모놀리식(2/3/N-Tier Monolith)
개념: 하나의 배포 단위(WAR/JAR) 안에 Presentation/Business/Persistence 레이어로 계층화.
장점: 단순 배포·트랜잭션 일관성·개발 속도 빠름.
단점: 코드베이스 비대화, 부분적 확장/배포 어려움.
권장: 초기 제품, 작은 팀, 기능 복잡도 낮음.
예시 스택: Spring MVC/Boot, JPA/Hibernate, Tomcat/TomEE, MySQL/PostgreSQL.
2) 모듈러 모놀리식(Modular Monolith)
개념: 하나의 배포물 안에 “강한 모듈 경계(도메인별 패키지/모듈)”를 두어 내부 의존을 엄격히 관리.
장점: 단일 배포의 단순함 + 내부 변경독립성/테스트 편의.
단점: 물리적 독립 배포는 아님(스케일/장애격리가 제한).
권장: MS로 쪼개기 전 단계, 도메인 경계(Bounded Context) 확립기.
키 포인트: 아키텍처 테스트(ArchUnit), 내부 이벤트, 모듈 간 인터페이스 고정.
3) 마이크로서비스(Microservices, MSA)
개념: 비즈니스 기능 단위로 서비스 분리, 각 서비스 독립 배포·DB 분리가 원칙.
장점: 팀/배포 독립성, 선택적 기술 스택, 부분 확장, 장애격리.
단점: 분산 복잡성(트랜잭션/Saga, 네트워크, 관측성, DevOps 비용).
권장: 도메인 많고 변경 잦은 대규모 조직, 높은 배포 빈도.
필수 요소: API Gateway/BFF, 서비스 디스커버리, 중앙 구성, 트레이싱/로그/메트릭, Circuit Breaker, 사가(오케스트레이션/코레오그래피), 데이터-각 서비스 소유.
예시 스택: Spring Boot, Spring Cloud, Kafka/RabbitMQ, Kubernetes, Istio/ServiceMesh, Prometheus/Grafana, OpenTelemetry/Zipkin/Jaeger.
4) SOA(서비스 지향 아키텍처)
개념: ESB/서비스 버스 중심의 기업 통합 스타일. (기관 간 연계/레거시 통합에 강점)
장점: 이기종 통합, 중앙 정책/라우팅/변환.
단점: 버스(ESB) 중심 중앙집중 복잡도/병목.
권장: 레거시 시스템 다수, 엔터프라이즈 통합(EAI/ESB) 맥락.
예시: ESB, SOAP/WS-* 또는 REST+ESB, 스키마/변환 맵핑.
5) 이벤트 주도 아키텍처(EDA)
개념: 서비스 간 **이벤트(비동기 메시지)**로 통신. 발행/구독, 스트림 처리.
장점: 느슨한 결합, 고확장, 내결함성, 비동기 처리량↑.
단점: 일관성 모델이 궁극적(최종적), 디버깅/추적 난이도↑.
권장: 대량 트래픽, 실시간 처리/알림/비동기 워크플로.
스택: Kafka, RabbitMQ, Pulsar, Debezium(Change Data Capture), Stream Processor(ksqlDB/Flink).
6) 헥사고널/포트&어댑터(= Onion/Clean)
개념: 도메인 코어를 I/O로부터 분리. 외부는 어댑터로 접속(웹, DB, 메시지 등).
장점: 테스트 용이, 교체 용이(DB/프레임워크 독립).
단점: 초기 설계/추상화 비용.
권장: 도메인 규칙이 핵심, 변화 많은 인프라 의존.
메모: 모놀리식/모듈러/MSA 어디서나 내부 설계로 적용 가능.
7) CQRS + 이벤트 소싱
CQRS: 읽기/쓰기 모델 분리(쓰기=도메인 모델, 읽기=조회 최적화 Projection).
이벤트 소싱: 상태를 이벤트 로그로 저장; 재생해 현재 상태 구성.
장점: 읽기 성능/확장 최적, 변경 이력 보존, 감사/복구.
단점: 설계/운영 복잡, 데이터 일관성 고민 필요.
권장: 복잡한 도메인 규칙, 감사/추적 필수, 읽기 트래픽 크고 패턴 다양.
8) 서버리스(Serverless/FaaS, BaaS)
개념: 함수 단위 배포, 인프라 추상화·자동 스케일.
장점: 무부하 비용↓, 빠른 실험, 운영 단순.
단점: 콜드스타트, 장기 실행/고빈도엔 비용↑, 벤더 종속.
권장: 간헐적 트래픽, 이벤트 처리, 배치/자동화 작업.
스택: AWS Lambda, GCP Cloud Functions, Azure Functions, API Gateway, SQS/Kafka Trigger.
9) BFF(Backend-for-Frontend) / API Gateway
개념: 클라이언트별 맞춤 백엔드(BFF)와 공통 관문(API GW)로 라우팅·보안·집계.
장점: 프론트 요구에 최적화된 API, 경계 명확.
단점: 레이어 증가, 관리/버전 관리 부담.
권장: 채널 다수(Web/App/파트너), 어그리게이션 필요.
스택: Spring Cloud Gateway, Kong, NGINX, GraphQL(BFF에 유용).
10) 마이크로 프론트엔드(Micro-FE)
개념: 프론트엔드를 기능/팀 단위로 분할, 런타임 조합.
장점: 독립 배포/팀 자율성, 대규모 프론트 확장.
단점: 공통 UI 일관성/번들 중복/성능 관리 이슈.
권장: 대규모 프론트 조직, 서로 다른 프레임워크 공존 필요.
11) 파이프라인/배치 아키텍처
개념: 정해진 단계(추출→변환→적재/검증)를 파이프처럼 연결해 대량 처리.
장점: 대량·정기 처리, 재시도·체크포인트 용이.
단점: 실시간성 낮음, 모니터링/스케줄 관리 필요.
권장: 일배치/대량 파일/정산/로그 ETL.
스택: Spring Batch, Airflow, Oozie, Cron, S3/HDFS, Spark.
보너스: 선택 기준(체크리스트)
- 팀/조직 규모 & 배포 빈도
- 작고 단일팀: 모놀리식/모듈러 모놀리식
- 다수 스쿼드·상시배포: MSA + EDA
- 도메인 복잡도/경계 명확성
- 불명확: 모듈러로 경계 정립부터
- 명확: 서비스 분해/데이터 분리
- 비기능 요구
- 초고가용·고확장: EDA, 읽기 트래픽 크면 CQRS
- 규제/감사: 이벤트 소싱/감사 로그
- 운영 역량(DevOps/Observability)
- 낮음: 단순 구조(모놀리식/모듈러)
- 높음: 분산(서비스 메시, 카나리, 카오스엔지니어링)
점진적 전환 로드맵(현실적)
- 레이어드 모놀리식 개선 → 아키텍처 테스트로 모듈 경계 강화
- 내부 도메인 이벤트 도입(동기 의존 줄이기)
- API GW/BFF 도입으로 외부 계약 분리
- 트래픽/도메인 기준으로 핵심부터 마이크로서비스화(Strangler)
- 트랜잭션 분해: 사가 패턴, Outbox/CDC로 일관성 확보
- 관측성(로그·메트릭·트레이스) 표준화 → 운영 자동화
아키텍처 비교 표
| 아키텍처 | 핵심 | 리스크 | 권장 상황 |
| 레이어드 모놀리식 | 단순, 빠른 개발 | 비대화/부분배포 불가 | 작은 팀·초기 제품 |
| 모듈러 모놀리식 | 내부 독립성↑ | 물리적 격리X | MS 전 단계, 경계 정립 |
| MSA | 독립 배포/스케일 | 분산 복잡성↑ | 큰 조직·높은 변경/배포 |
| SOA | 이기종 통합 | ESB 병목/중앙집중 | 레거시·기관 연계 |
| EDA | 느슨한 결합·확장 | 디버깅 난이도 | 대량 이벤트/실시간 |
| 헥사고널/클린 | 테스트·교체 용이 | 초기 설계비용 | 도메인 규칙 중심 |
| CQRS/ES | 읽기 성능·감사 | 설계/운영 복잡 | 감사 필수·조회 대규모 |
| 서버리스 | 운영 간소화 | 콜드스타트/비용 | 간헐 이벤트·자동화 |