빌딩 블록 도입 기준

---

왜 ‘필요해질 때만’ 추가해야 하는가

왜

초기 설계에서 흔한 실수는 “언젠가 필요할 것 같아서”를 이유로 블록을 미리 쌓는 것이다. 이 접근은 트래픽이 아니라 조직의 이해도 부족을 기술로 덮는 행위다.

무엇

여기서 다룰 빌딩 블록 4종은 다음 문제를 해결한다.

• 트래픽 분산/경로 제어 (DNS/LB/GSLB)
• 처리량 완충/비동기화 (Message Broker)
• 경계 통제/정책 일관화 (API Gateway)
• 전송 비용/지연 최소화 (CDN)

어떻게

각 블록을 문제 → 신호 → 도입 → 운영 비용 → 부작용 흐름으로 판단한다.

---

통일 사례: 쇼핑몰

• 일일 활성 사용자: 100만
• 이벤트 시 트래픽 10배 스파이크
• 읽기:쓰기 = 15:1
• 결제/재고는 강한 일관성 필요

---

DNS vs LB vs GSLB (도식적 설명)

이 셋은 계층과 책임이 다르다.

사용자
↓
DNS (어디로 보낼지 - 지역/도메인 수준)
↓
GSLB (어느 리전으로 - 글로벌 분산)
↓
LB (어느 인스턴스로 - 로컬 분산)
↓
애플리케이션

• DNS: 느리지만 단순, 캐시 영향 큼
• GSLB: 리전 선택, 비용/운영 난이도 큼
• LB: 실시간 분산, 장애 반응 빠름

---

1) DNS / LB / GSLB

해결하는 문제 3개

1. 단일 서버 병목
2. 특정 노드 장애 시 전체 다운
3. 지역별 지연 시간 편차

도입 신호/증상 5개

• 트래픽 증가 시 특정 서버 CPU 100%
• 장애 시 수동 IP 변경
• 지역별 응답 시간 차이 2배 이상
• 배포 시 트래픽 드롭
• 헬스체크 없는 라우팅

구성 비교

• 최소: DNS + 단일 LB
• 흔한: DNS + L4/L7 LB
• 과한: DNS + GSLB + 다중 LB (초기엔 과도)

장애 시나리오

1. LB 헬스체크 오탐 → 전체 트래픽 차단
   → 대응: passive/active 체크 분리
2. DNS 캐시로 장애 리전 고착
   → 대응: TTL 단축 + GSLB 헬스 연동

대체/미도입 전략

• 초기: 애플리케이션 레벨 라운드로빈
• 단일 리전 고정 후 지표 확보

너무 빨리 넣으면 생기는 비용

• 네트워크 디버깅 난이도 급증
• 장애 원인 추적 지연

---

2) Message Broker

해결하는 문제 3개

1. 트래픽 스파이크 완충
2. 동기 의존성 제거
3. 재처리/내구성 확보

도입 신호/증상 5개

• 이벤트성 트래픽에 DB 폭주
• 외부 연동 장애가 전체 요청 실패로 전파
• 재시도 로직이 코드에 난립
• 처리량 변동 폭이 큼
• 배치/비동기 요구 증가

구성 비교

• 최소: 단일 토픽/큐
• 흔한: 토픽 분리 + 컨슈머 그룹
• 과한: 이벤트 소싱 전면 도입

장애 시나리오

1. 컨슈머 지연으로 큐 적체
   → 대응: 백프레셔/알람 기준
2. 중복 처리
   → 대응: 멱등성 키/처리 상태 저장

대체/미도입 전략

• DB 기반 작업 테이블
• 제한적 비동기(메일/로그만)

비동기 전환의 부작용

• 일관성 약화: 결과가 즉시 보이지 않음
• 디버깅 난이도: 호출 스택 단절
• 재처리 비용: 순서/중복 관리 필요

너무 빨리 넣으면 생기는 비용

• “왜 늦는지” 설명 불가
• 운영자 의존 급증

---

3) API Gateway

해결하는 문제 3개

1. 인증/인가 일관화
2. 트래픽 제어/쿼터
3. 외부 경계 단일화

도입 신호/증상 5개

• 서비스마다 인증 로직 중복
• 외부 파트너 증가
• DDoS/오남용 위험
• API 정책 변경 잦음
• 관측 지점 분산

구성 비교

• 최소: 인증/라우팅
• 흔한: 인증 + rate limit + 로깅
• 과한: 비즈니스 로직 포함

장애 시나리오

1. 게이트웨이 장애로 전체 API 다운
   → 대응: 단순화 + 우회 경로
2. 정책 오류로 정상 트래픽 차단
   → 대응: 단계적 롤아웃

대체/미도입 전략

• 서비스 메시에 인증 위임
• BFF(Backend for Frontend)

팀을 망치는 케이스

• 게이트웨이에 로직 집중 → 단일 병목 팀 방지 규칙
• 게이트웨이는 “통과/차단”만 담당
• 도메인 로직 금지

너무 빨리 넣으면 생기는 비용

• 배포 속도 저하
• 모든 변경이 중앙 승인 필요

---

4) CDN

해결하는 문제 3개

1. 정적 자산 지연
2. 원본 서버 부하
3. 글로벌 사용자 체감 성능

도입 신호/증상 5개

• 이미지/JS가 응답 시간 대부분 차지
• 지역별 로딩 편차
• 트래픽 비용 급증
• 이벤트 페이지 트래픽 폭증
• 캐시 가능한 자산 명확

구성 비교

• 최소: 정적 자산 캐시
• 흔한: API 일부 캐시
• 과한: 동적 API 전면 캐시

장애 시나리오

1. 캐시 무효화 실패 → 오래된 데이터 노출
   → 대응: 버저닝/immutable URL
2. 캐시 불일치로 사용자 혼란
   → 대응: 사용자별 캐시 분리 금지

대체/미도입 전략

• 서버 사이드 캐시
• 이미지 리사이징 최소화

캐시 정합성 이슈

• “바뀌면 바로 보여야 한다” 요구는 CDN과 충돌
• 해결책: URL 버저닝 + TTL 전략

너무 빨리 넣으면 생기는 비용

• 캐시 규칙 이해 부족으로 버그 양산
• 무효화 비용 폭증

---

도입 의사결정 한 장 요약

블록	도입 신호	핵심 이득	핵심 비용
DNS/LB	서버 병목	가용성	네트워크 복잡도
Broker	스파이크	완충	디버깅 난이도
Gateway	외부 API	통제	중앙 병목
CDN	정적 트래픽	비용/지연 절감	캐시 정합성

---

재학습 체크리스트 (12)

• 지금 문제가 실제로 존재하는가
• 신호가 지표로 관측되는가
• 최소 구성으로 해결 가능한가
• 장애 반경이 커지는가
• 운영 인력이 감당 가능한가
• 되돌릴 수 있는가
• 대체안은 검토했는가
• 팀 이해도가 있는가
• 비용 증가를 설명할 수 있는가
• 디버깅 경로가 명확한가
• 장애 시 우회 경로가 있는가
• “지금 당장” 필요한가

---

한 줄 요약

빌딩 블록은 스케일을 키우기 전에, 문제를 정확히 정의했을 때만 추가해야 한다. —

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