아키텍처 패턴 해부: 멀티티어 · 마이크로서비스 · 이벤트 기반

결론 요약

아키텍처 패턴은 기술 취향이 아니라 조직·배포·관측·데이터·장애 제약에 대한 선택이다.
멀티티어는 단순성과 예측 가능성을 얻는 대신 확장 유연성을 포기한다.
마이크로서비스는 독립성을 얻는 대신 운영 책임을 조직 전체에 분산시킨다.
이벤트 기반은 결합도를 낮추는 대신 일관성과 추적성을 스스로 감당해야 한다.
대부분의 실패는 “이 패턴을 써야 할 이유”보다 “쓰지 말아야 할 조건”을 무시해서 발생한다.
성숙한 설계자는 항상 “왜 이걸 안 썼는가”를 설명할 수 있다.

---

패턴 3종 비교표 (핵심 제약 관점)

항목	멀티티어 (Monolithic / N-Tier)	마이크로서비스	이벤트 기반
팀 규모	소~중	중~대	중~대
배포 빈도	낮음~중간	높음	높음
데이터 일관성	강한 일관성(ACID)	서비스별 일관성	최종적 일관성
장애 범위	전체 장애 가능	서비스 단위	이벤트 흐름 단위
관측 요구	낮음	매우 높음	매우 높음
운영 난이도	낮음	높음	매우 높음
핵심 비용	변경 영향 반경	운영 복잡도	디버깅·정합성

---

패턴별 배경(문제)과 도입 비용

1) 멀티티어 아키텍처

문제 배경

• 단일 데이터베이스 기반의 강한 일관성 필요
• 팀 규모가 작고, 배포 빈도가 낮음
• 장애 원인을 빠르게 파악해야 함

얻는 것

• 단순한 배포
• 트랜잭션 관리 용이
• 디버깅 직관적

잃는 것

• 부분 확장 불가
• 코드베이스 커질수록 변경 비용 급증

언제 쓰지 말아야 하는가 (중요)

• 배포를 하루에도 여러 번 해야 할 때
• 팀이 기능별로 분리되어 병렬 개발이 필요할 때
• 특정 기능만 독립 확장해야 할 때

👉 멀티티어의 한계는 기술이 아니라 “변경 속도”다.

---

2) 마이크로서비스 아키텍처

문제 배경

• 팀이 커지고, 기능별로 독립 배포 필요
• 서비스별 확장 요구 상이
• 장애 격리가 중요

얻는 것

• 배포 독립성
• 장애 격리
• 기술 선택 유연성

잃는 것

• 네트워크 비용
• 관측·운영 부담
• 데이터 분산 관리 책임

마이크로서비스의 진짜 전제 6개

1. 관측성: 메트릭·트레이스·로그가 기본
2. 배포 자동화: 수동 배포는 즉시 파탄
3. 플랫폼 팀: 공통 인프라 제공 주체
4. 명확한 서비스 경계: 애매하면 실패
5. 조직 분리: 팀=서비스 책임
6. 운영 문화: “돌아가면 끝”이 아님

언제 쓰지 말아야 하는가 (더 중요)

• 관측 도구가 아직 정착되지 않았을 때
• 배포 자동화가 불완전할 때
• 데이터 일관성이 핵심 경쟁력일 때
• 팀이 “서비스 운영”을 책임질 준비가 없을 때

👉 마이크로서비스는 조직 구조를 드러내는 거울이다.

---

3) 이벤트 기반 아키텍처

문제 배경

• 서비스 간 결합도를 최소화해야 함
• 비동기 처리로 확장성 확보 필요
• 이벤트 흐름이 비즈니스 핵심

얻는 것

• 느슨한 결합
• 비동기 확장성
• 새로운 소비자 추가 용이

잃는 것

• 흐름 가시성
• 일관성 제어
• 디버깅 난이도

이벤트 기반의 함정 (현실)

• 중복 처리: at-least-once는 기본
• 순서 보장: 파티션 전략 필수
• 재처리: idempotency 설계 필요
• 사가(Saga): 분산 트랜잭션의 고통
• 보상 트랜잭션: 실패 설계가 더 복잡

언제 쓰지 말아야 하는가 (가장 중요)

• 이벤트 흐름을 설명할 사람이 없을 때
• 장애 시 “무슨 일이 벌어졌는지” 재구성할 수 없을 때
• 강한 실시간 일관성이 필요할 때

👉 이벤트 기반은 자유 대신 책임을 산다.

---

동일 사례 비교: 쇼핑몰

멀티티어

• 주문/결제/재고 단일 DB 트랜잭션
• 장애 시 전체 중단
• 구현 단순, 확장 어려움

마이크로서비스

• 주문/결제/재고 서비스 분리
• 서비스 간 동기 호출
• 관측·네트워크 비용 증가

이벤트 기반

• 주문 이벤트 발행
• 결제/재고 비동기 처리
• 일관성은 사가로 해결

👉 같은 도메인, 다른 고통 지점

---

단계 전략: 단일 → 모듈러 → 마이크로서비스

1. 단일 모놀리스
   • 빠른 개발
   • 도메인 이해 축적
2. 모듈러 모놀리스
   • 내부 경계 강화
   • 분리 연습
3. 마이크로서비스
   • 검증된 경계만 분리
   • 나머지는 유지

👉 바로 쪼개는 것은 가장 비싼 선택이다.

---

면접에서 돋보이는 포인트

“이 패턴을 안 쓴 이유” 템플릿 8개

1. 관측 비용 대비 이득이 작아서
2. 데이터 일관성이 더 중요해서
3. 조직 규모가 아직 준비되지 않아서
4. 배포 빈도가 낮아서
5. 장애 범위를 감당할 수 있어서
6. 운영 인력이 제한적이라서
7. 도메인 경계가 불명확해서
8. 변경 속도가 병목이 아니어서

---

재학습 체크리스트 (12개)

• 변경 속도가 진짜 문제인가?
• 장애 범위를 어디까지 감당 가능한가?
• 데이터 일관성이 핵심 경쟁력인가?
• 관측 도구 없이 운영 가능한가?
• 팀이 운영 책임을 질 준비가 되었는가?
• 배포 자동화 수준은 충분한가?
• 이벤트 흐름을 설명할 수 있는가?
• 재처리 시나리오가 있는가?
• 보상 트랜잭션을 설계했는가?
• 서비스 경계가 명확한가?
• 조직 구조와 일치하는가?
• “안 쓸 이유”를 설명할 수 있는가?

---

패턴 선택 질문 리스트 (15개)

1. 지금 가장 비싼 비용은 무엇인가?
2. 변경이 잦은가, 안정이 중요한가?
3. 장애를 어디까지 허용하는가?
4. 배포 실패 시 영향 범위는?
5. 데이터 정합성 요구 수준은?
6. 관측 도구 성숙도는?
7. 팀 간 의존성은?
8. 운영 인력 규모는?
9. 자동화 수준은?
10. 이벤트 재처리가 가능한가?
11. 비동기 흐름을 추적 가능한가?
12. 서비스 경계 합의가 있는가?
13. 롤백 전략은 명확한가?
14. 조직이 감당할 수 있는 복잡도는?
15. 이 패턴을 안 쓸 논리는 무엇인가?

---

• 참고: Kubernetes Istio : 완벽 실습 과정