아키텍처 패턴은 타협안

---

이 글의 결론

아키텍처 패턴은 “더 좋은 구조”가 아니라, 조직·배포·관측·데이터·장애 제약 하에서 감당 가능한 실패 비용을 선택하는 문제다.

---

왜 패턴을 ‘타협안’으로 봐야 하는가

패턴은 문제를 해결하지만, 동시에 새로운 문제를 강제로 만든다.

왜

패턴 논쟁이 실패하는 이유는 “이게 더 낫다”는 비교 때문이다. 실제 설계에서는

• 팀이 몇 명인지
• 배포를 얼마나 자주 하는지
• 장애를 어디까지 허용하는지
  가 결정 변수다. 패턴은 이 제약을 만족시키기 위한 구조적 타협이다.

무엇

여기서 비교할 패턴 3종:

• 멀티티어(Multi-tier)
• 마이크로서비스(Microservices)
• 이벤트 기반(Event-driven)

어떻게

동일한 쇼핑몰을 세 패턴으로 재구성해, 무엇을 얻고 무엇을 버리는지 본다.

---

패턴 3종 한 장 비교표

구조보다 중요한 건 운영 곡선이다.

항목	멀티티어	마이크로서비스	이벤트 기반
팀 규모	소~중	중~대	중~대
배포 빈도	낮음~중	높음	높음
데이터 일관성	강함	약~중	약
장애 범위	넓음	제한 가능	전파 지연
관측 난이도	낮음	높음	매우 높음
운영 난이도	낮음	높음	매우 높음

---

기준 사례: 쇼핑몰 도메인

• 기능: 상품 조회 / 주문 / 결제 / 배송
• 트래픽: 이벤트 시 8~10배
• 요구: 결제는 강한 일관성, 조회는 빠르게
• 팀: 초기 6명 → 성장 시 20명+

---

1) 멀티티어 아키텍처

멀티티어는 ‘단순함을 통한 통제’다.

어떤 문제에서 나왔나

• UI / 비즈니스 / 데이터 책임 분리
• 단일 배포 단위로 안정성 확보

쇼핑몰 구성

• Web → App → DB
• 주문/결제 트랜잭션 단일 DB

언제 쓰는가

• 팀 규모 작음
• 배포 빈도 낮음
• 강한 트랜잭션 요구

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

• 기능별 배포 독립성이 필요할 때
• 트래픽 특성이 계층별로 크게 다를 때
• 일부 장애가 전체 장애로 전파되는 구조를 감당 못 할 때

실패 신호

• “조회 트래픽 때문에 결제가 느려진다”
• “작은 변경도 전체 배포가 필요하다”

---

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

마이크로서비스는 ‘배포 독립성’을 얻기 위해 모든 것을 포기하는 구조다.

어떤 문제에서 나왔나

• 대규모 조직에서의 병렬 개발
• 기능 단위 배포 필요

쇼핑몰 구성

• 상품/주문/결제/배송 서비스 분리
• 서비스별 DB

언제 쓰는가

• 팀이 기능 단위로 나뉘어 있음
• 배포 자동화 성숙
• 장애 격리가 최우선

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

1. 관측성: 분산 트레이싱 필수
2. 자동화: CI/CD 없으면 즉시 붕괴
3. 플랫폼: 공통 인프라 팀 존재
4. 조직 구조: 팀-서비스 1:1
5. 데이터 분리: DB 공유 금지
6. 장애 대응 문화: 실패 허용 전제

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

• 팀이 1~2개뿐일 때
• 배포 자동화가 없는 상태
• 데이터 일관성이 핵심 경쟁력일 때
• “나중에 쪼개자”라는 막연한 기대만 있을 때

실패 신호

• API 호출 지옥
• 데이터 정합성 문제를 코드로 땜질
• 장애 원인 추적 불가

---

3) 이벤트 기반 아키텍처

이벤트 기반은 ‘결합도 감소’ 대신 ‘이해도 비용’을 지불한다.

어떤 문제에서 나왔나

• 동기 호출 병목
• 확장성 한계

쇼핑몰 구성

• 주문 생성 → 이벤트 발행
• 결제/배송/알림 비동기 구독

언제 쓰는가

• 처리량 스파이크가 큼
• 결과 즉시성보다 처리 보장 중요

이벤트 기반의 함정 (핵심)

1. 중복 처리: 멱등성 필수
2. 순서 문제: 이벤트 순서 보장 어려움
3. 재처리: 실패 이벤트 재실행 비용
4. 사가: 분산 트랜잭션 대체 복잡성
5. 보상 트랜잭션: 설계·테스트 난이도 높음

언제 쓰지 말아야 하는가

• 흐름을 한 눈에 이해해야 하는 도메인
• 디버깅 인력이 부족할 때
• “나중에 맞추자” 식의 정합성 요구

실패 신호

• “왜 이 상태가 됐는지 아무도 모른다”
• 운영자만 시스템을 이해

---

단계적 진화 전략

대부분의 시스템은 이 경로를 벗어나지 않는다.

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. 지금 당장 필요한가

---

한 줄 요약

아키텍처 패턴 선택은 구조 문제가 아니라, 감당할 수 있는 실패 비용의 선택이다.

---

• 참고: 소프트웨어 아키텍처 및 대규모 시스템 설계