547. 트래픽 라우팅, 카나리 배포 제어 (Service Mesh의 역할)

핵심 인사이트 (3줄 요약)

1. 본질: 트래픽 라우팅과 카나리 배포(Canary Release)는 "새벽 2시에 전 서버 끄고 새 코드 올리자"는 낡은 빅뱅(Big Bang) 배포의 공포를 찢어버리고, 서비스 메시(Istio/Envoy)의 인프라 권력을 이용해 실제 라이브 트래픽을 정밀한 수도꼭지처럼 1%, 5%, 10%씩 살금살금 새 서버(V2)로 흘려보는 무중단 무결점 테스트 비행술이다.
2. 가치: 배포(Deployment)와 런칭(Release)의 개념을 물리적으로 완벽히 분리해 낸다. 코드가 서버에 올라가는 순간(배포)은 0명의 유저에게 영향을 미친다. 이후 아키텍트가 대시보드에서 스위치를 돌려 트래픽을 서서히 흘릴 때(런칭) 비로소 고객에게 노출되므로, 대형 버그가 터져도 단 1%의 고객(Blast Radius)만 피를 흘리게 하고 1초 만에 스위치를 꺼버려 매출 손실 수백억을 0.01초 단위로 방어해 낸다.
3. 융합: 소스코드 1바이트의 수정 없이, 오직 쿠버네티스의 VirtualService(가상 라우터) 텍스트 파일(IaC) 1장과 545장에서 배운 **Service Mesh(컨트롤 플레인)**의 지휘가 융합되어, A/B 테스트부터 다크 런칭(Shadowing)까지 비즈니스와 인프라의 극강의 결합 예술(DevOps)을 완성한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념:

  • 트래픽 라우팅(Traffic Routing): 도로에 진입하는 자동차(HTTP 패킷) 100대를 앞단(프록시)에서 낚아채어 "90대는 A 구도로(V1 서버)로 가고, 10대는 B 신도로(V2 서버)로 가라!"고 멱살 잡고 길을 틀어주는 행위다.
  • 카나리 배포 (Canary Release): 옛날 광부들이 일산화탄소를 탐지하려 '카나리아 새'를 먼저 동굴에 들여보냈던 것처럼, 새 버전(V2)을 전체 서버 100대에 확 깔지 않고 딱 1대에만 깐 뒤 1% 트래픽만 먹여보며 에러(독가스)가 터지는지 간을 보는 배포 기법이다.

• 필요성: 쿠팡에 접속자가 1,000만 명이다. 결제 버튼 로직을 새로 짰다(V2). QA 서버에서 1달 동안 테스트해서 100점 맞았다. 라이브 서버 100대에 V2를 동시에 다 덮어씌웠다(빅뱅 배포). 1초 뒤 서버가 펑펑 터지며 올 셧다운 됐다! 원인은 QA 샌드박스에서는 절대 나올 수 없는 '동시 접속 1,000만 명의 데드락 꼬임 현상' 때문이었다. **"QA 테스트는 100% 완벽할 수 없다. 오직 진짜 라이브 트래픽(Real World)만이 진실을 안다. 근데 1,000만 명을 담보로 도박을 할 순 없잖아? 10만 명(1%)한테만 몰래 먹여보고 뻗으면 0.1초 만에 다시 V1으로 롤백(Rollback)하는 생명선"**이 필수 불가결한 클라우드 생존법이 되었다.

• 💡 비유: 카나리 배포는 대형 정수장(서버)의 **'독극물 기미 상궁 수도꼭지'**와 똑같습니다. 낡은 정수기 필터(V1)를 최신 필터(V2)로 갈아 끼워야 합니다. 옛날(빅뱅 배포)엔 정수기를 10분 끄고 새 필터를 낀 뒤, 도시 전체(100% 트래픽)로 물을 쾅 쐈습니다. 만약 필터 불량이면 온 도시민이 물먹고 죽습니다(대장애). 카나리 배포는 메인 수도관은 냅두고, 옆에 가느다란 **'1%짜리 미니 파이프(라우팅)'**를 하나 팝니다. 거기만 새 필터(V2)를 끼우고 동네 사람 딱 10명한테만 줘봅니다. 먹고 아무도 안 아프면(에러율 0%), 수도꼭지 밸브를 10%, 50%, 100%로 스르륵 부드럽게 열어버리며 도시 전체를 안전하게 물갈이하는 100점짜리 무중단 배관술입니다.

• 등장 배경 및 발전 과정:

  1. 블루/그린(Blue/Green)의 시대: 2010년대 "무중단 배포"가 유행하며, V1 서버 10대 옆에 똑같이 V2 서버 10대를 돈 주고 띄워놓고 라우터 스위치를 100 ➡ 0 으로 확 꺾는 짓을 했다. 롤백은 편했지만 인프라 돈이 2배로 들었고, 100% 꺾어버리니 터지면 충격파도 100%였다.
  2. 넷플릭스와 카나리 롤아웃 (2010s 중반): 넷플릭스가 "야 돈 아까워! V2 서버 딱 1대만 띄우고 1%만 흘려!" 라며 클라이언트 라우팅(Ribbon) 룰로 트래픽을 쪼개는 가성비 카나리 시대를 열었다.
  3. Istio 서비스 메시의 무혈 통치 (현재): K8s 시대가 열렸다. 개발자가 코드로 1% 분기(if (random < 1) go V2) 치는 뻘짓을 완전히 멸망시켰다. 인프라 바닥에 깔린 Envoy 사이드카 프록시가 VirtualService 도면 딱 1장만 읽고 0.001초 단위로 네트워크 단에서 트래픽을 99:1로 기계적으로 쪼개버리는 궁극의 통제권을 획득했다.

• 📢 섹션 요약 비유: 옛날 배포(블루그린)는 **'기찻길 선로(스위치)를 100% 오른쪽으로 확 꺾어버리는 짓'**입니다. 기차가 오른쪽 선로가 끊겨있으면 그대로 낭떠러지로 다 같이 추락합니다. 카나리 배포(서비스 메시)는 **'기차 승객 중 1%만 뽑아서 쪼매난 선발대 정찰 짚차에 태워 보내는 짓'**입니다. 짚차가 낭떠러지로 떨어져도(1% 희생), 본대 기차(99%)는 1도 타격받지 않고 기존 선로(V1)로 평화롭게 여행을 계속하는 눈물겨운 꼬리 자르기 희생 정신입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 트래픽 라우팅의 흑마법: Istio VirtualService 뼈대

어떻게 코드 1줄도 안 고치고 트래픽을 90대 10으로 찢는가? 면접의 꽃이다.

[ 🛡️ 카나리 배포를 지배하는 매직 주문 (VirtualService.yaml) ]

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-route
spec:
  hosts:
  - payment-service # 앱들이 호출하는 껍데기 주소
  http:
  - route:
    - destination:
        host: payment-service
        subset: v1      # 기존 낡은 서버 (안전함)
      weight: 90        # 💥 트래픽의 90%를 일로 쏴라!
    - destination:
        host: payment-service
        subset: v2      # 방금 배포한 신상 서버 (위험함, 카나리아)
      weight: 10        # 💥 트래픽의 10%만 일로 쏴라!

• 원리 (Envoy Proxy 가로채기): K8s에 저 텍스트 파일 1장 던지면 끝이다. Istio 지휘관(Control Plane)이 1만 대의 사이드카(Envoy) 뇌 속에 1초 만에 저 룰을 다운로드시킨다. 주문 서버가 http://payment 로 100번 찌른다. 찌르자마자 밖으로 나가기도 전에 뱃속에 있는 사이드카(Envoy)가 낚아챈다. 90번은 V1 IP로, 10번은 V2 IP로 자기가 알아서 주사위를 굴려서(Weight 라우팅) 완벽하게 찢어 날려버린다. 개발자는 자기가 10번 중 1번꼴로 V2에 찌르고 있다는 사실조차 100% 모르는 완벽한 은닉(Transparency)이다.

2. 카나리 배포의 진화: 다크 런칭 (Traffic Shadowing / Mirroring)

카나리(1%) 조차 희생시키기 무섭다? 유저 피해 0(Zero)의 궁극기다.

• 문제: 결제 코어 엔진 V2를 짰다. 1% 카나리를 돌렸다. 만약 에러 나면 그 1% 고객의 결제 돈은 허공으로 증발해 소송(CS 폭주) 걸린다. 1%의 출혈조차 감당할 수 없는 초핵심 도메인의 한계다.

• 방어 (Traffic Shadowing): Istio에 mirror: subset: v2 라고 1줄 친다.

  • 유저 트래픽 100%는 전부 기존 안전한 V1 서버로 들어간다(결제 100% 정상).
  • 그런데 Envoy 프록시가 이 트래픽을 100% 똑같이 거울(Mirror)처럼 복사해서, 몰래 구석에 떠 있는 V2 서버에 유령처럼 쏜다.
  • V2 서버는 100% 리얼 트래픽을 처맞으며 미친 듯이 연산하지만, "그 연산 결과를 유저에게 응답(Response)하지 않고 걍 허공에 버린다(Fire and Forget)."
  • 아키텍트는 유저 피해 0%인 상태로, 백그라운드에서 V2 서버가 에러를 토하는지 500 로그만 여유롭게 팝콘 먹으며 감시(Monitoring)할 수 있는 무결점의 시뮬레이션 환경을 구축한다.

• 📢 섹션 요약 비유: 카나리가 **'신상 라면을 10명의 손님한테 직접 먹여보고 배탈 나나 보는 짓(10명은 배 아픔 희생)'**이라면, 섀도잉(다크 런칭)은 **'손님이 시킨 옛날 라면 주문서(트래픽)를 몰래 복사해서 주방에 한 장 더 주고, 신상 라면 100개를 만들어 보게 한 뒤, 손님한텐 안 주고 요리사가 쓰레기통에 버리며 맛(로그/에러)만 살짝 찍어 먹어보는 짓(손님 피해 0%)'**입니다. 궁극의 안전입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 배포 3형제 최후의 비교표 (Blue-Green vs Canary vs A/B Test)

초보 주니어들이 밤낮으로 헷갈리는 삼국지 개념.

과목 융합 관점

• 소프트웨어 공학 (점진적 릴리즈와 데이터베이스 딜레마): 532장에서 본 DB 분리가 왜 헬인가? 카나리로 V1과 V2 앱을 9:1로 띄워놨다 쳐보자. 두 앱이 1개의 DB 테이블을 같이 바라보고 있다. V2 앱 코드를 짜면서 DB 컬럼 name을 first_name으로 ALTER TABLE 쳐버렸다. 10%의 V2 고객은 쌩쌩 돌아가는데, 90%의 V1 고객 서버가 Column not found로 와장창 뻗어버렸다. "카나리 배포를 하려면 절대로 DB 스키마를 하위 호환성 없이(Backwards-incompatible) 깨부수면 안 된다!" 무조건 컬럼을 '추가'만 하고 6개월 뒤 낡은 V1이 우주에서 100% 멸종했을 때 옛날 컬럼을 지우는 Expand-Contract(확장-수축) 데이터베이스 융합 기법이 강제된다.

• 클라우드 데브옵스 (Flagger / Argo Rollouts 융합): 사람이 1% 넣고 5분 지켜보고, 10% 올리는 건 구석기 짓이다. 현대 K8s 생태계는 Argo Rollouts 같은 자동화 로봇을 단다. "야 로봇! 1%로 올린 뒤 프로메테우스(모니터링) 쳐다봐. 500 에러율 1% 넘거나 지연시간 2초 넘으면? 나한테 카톡 치지도 말고 즉각 1초 만에 스위치 V1으로 원상 복구(Auto-Rollback) 시켜! 에러 없으면 10분마다 10%씩 올려서 100% 풀방 채워!" 인간의 쫄보 심장(두려움)을 기계의 차가운 메트릭(Metric-based Automation)으로 덮어버린 진정한 자율 주행 데브섹옵스다.

• 📢 섹션 요약 비유: 카나리와 A/B 테스트의 차이는 이렇습니다. 카나리는 신약 백신을 만들었을 때, "이 약 먹고 심장마비(버그/500 에러) 걸려 안 걸려?"를 부작용 확인 목적으로 환자 1명한테 놔보는 **'안전 검증(엔지니어링)'**입니다. A/B 테스트는 딸기맛 백신과 초코맛 백신 두 개를 놔보고 "환자들이 무슨 맛을 더 많이 사 먹을까(매출/클릭률)?"를 보는 **'비즈니스 취향 검증(마케팅)'**입니다. 둘 다 라우팅 스위치를 꺾어버리는 인프라(Service Mesh) 뼈대는 100% 똑같은데, 써먹는 목적(뇌 구조)만 완전히 다른 쌍둥이입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 헤더 라우팅(Header-based Routing)으로 완성하는 1% VIP 컷오프: 신규 결제 UI를 배포했다. 무작위 1% 쪼개기(Weight 라우팅)를 썼더니 어제는 구버전(V1) 보던 손님이, 오늘 새로고침 하니까 갑자기 신버전(V2)이 떠서 당황하고 클레임을 걸었다(UX 붕괴, 멱등성 상실).

   • 아키텍트의 해결책: 세션 고정성(Sticky)이 부재한 무지성 비율 쪼개기의 한계다. 아키텍트는 멍청한 가중치(Weight) 라우팅을 버리고 **헤더 기반 정밀 라우팅(Header Routing / A/B Test)**으로 스위칭해야 한다. Istio VirtualService에 match: headers: "User-Tier": exact: "VIP" 룰을 딱 박는다. 프론트엔드 앱은 유저가 VIP면 헤더에 도장을 찍어 쏜다. Envoy 프록시는 이 헤더 글씨를 귀신같이 낚아채서, "VIP 손님은 무조건 죽을 때까지 V2 신상 서버로만 꽂아줘!"라며 경로를 틀어버린다. 고객은 어제나 오늘이나 100% 일관된 UI를 보장받으며 극강의 사용자 경험(UX) 방어선을 구축해 낸다.

2. 시나리오 — 서킷 브레이커(Circuit Breaker)의 오발동과 나비효과: 주문 서버가 결제 서버 V2로 10% 카나리를 틀었다. V2 코드가 꼬여서 3초씩 렉을 유발했다. 이스티오 사이드카가 "어? 결제 V2 서버가 3초나 안 받네?" ➡ 서킷 브레이커(차단기)를 툭 끊어버렸다. 좋은 현상이다. 그런데 멍청한 사이드카가 V2만 끊은 게 아니라, "아 결제 서버 군단 전체가 터졌나 보다!"라며 쌩쌩 잘 도는 결제 V1 서버(90%) 통신 선마저 도미노로 다 끊어버렸다(Fail-fast 오발동). 주문 서버 전체가 하얗게 뻗어버려 매출 0원이 찍혔다.

   • 아키텍트의 해결책: 서브셋(Subset)과 데스티네이션 룰(DestinationRule) 단위의 정밀한 인프라 절단 실패다. 이스티오 라우팅은 섬세해야 한다. 아키텍트는 서킷 브레이커 룰을 payment-service 라는 통짜 호스트에 거는 게 아니라, 무조건 라벨(Label)로 찢어놓은 subset: v2 에만 핀셋으로 타임아웃 퓨즈를 달아둬야 한다. 그래야 V2가 렉이 걸려 퓨즈가 터져도, V1 90% 트래픽은 남의 집 불구경하듯 초록불을 띄우며 돈을 평화롭게 벌어오는 진정한 격벽(Bulkhead) 방어술이 성립된다.

도입 체크리스트

• 조직적: 모니터링 알람(Metrics)과 라우팅 스위치가 한 몸(Closed-loop)으로 돌아가는가? 카나리 1% 틀어놓고 개발자가 화장실 갔다. 500 에러가 1분 동안 1만 개 쏟아졌다. 알람은 보안팀장 슬랙으로 갔고, 스위치를 끌 권한을 가진 인프라팀 이 대리는 담배 피우고 있었다(의사결정 사일로). 최악이다. 카나리는 "에러 감지(Prometheus) ➡ 스위치 원상복구(Argo Rollouts/Istio) ➡ 알림 발송" 이 3박자가 1초 안에 인간의 컨펌(Approve) 없이 기계적으로 기어 맞물려 돌아가도록 파이프라인(DevOps)이 자동 연동되어 있어야만 목숨을 구한다. 인간이 마우스로 스위치를 끄는 순간 이미 1,000만 원은 날아간 뒤다.
• 기술적: 상태 저장 서버(Stateful Server)에 억지 카나리를 쑤셔 넣지 마라! 카나리 배포는 서버 뱃속이 텅 비어있는(무상태, Stateless) 웹 API 서버에서나 1초 만에 켰다 껐다 롤백하는 신의 룰이다. 만약 Redis 캐시 서버나 오라클(Oracle) DB 엔진을 V2로 1% 카나리 배포한다? 데이터 구조가 V1이랑 꼬여서 1% 유저의 잔고 데이터가 완전히 개박살 난 채로 영구 저장된다. "명심해라. 상태를 쥐고 있는 놈(DB, Cache)은 절대로 프록시 쪼개기로 장난치면 안 되며, 오직 로직만 뱉고 죽는 무상태 깡통(App Server)에서만 라우팅 스위치를 갖고 놀아라."

안티패턴

• "프론트엔드 코드에 if문으로 트래픽 쪼개기 떡칠 (Fat Client Antipattern)": 서비스 메시를 깔기 돈 아깝다며, 안드로이드 앱 개발자한테 "야, 랜덤 난수 돌려서 10 이하면 http://v2-payment.com 치고, 아니면 http://v1... 쳐라!"라고 비즈니스 로직(앱 뱃속)에 인프라 라우팅 책임을 더럽게 박아넣는 짓. 1주일 뒤 에러 나서 V1으로 롤백하려면? 안드로이드 앱 코드 수정해서 다시 빌드하고 구글 앱스토어 심사 3일 기다려서 고객이 다운로드받게 기다려야 한다. 회사가 파산하고 묘비가 세워지는 속도다. "라우팅(길 찾기)은 100% 클라이언트의 눈을 가리고, 오직 뒷단의 투명한 프록시(인프라) 레이어에서만 0.001초 만에 모가지를 꺾어 분리해야 한다."

• 📢 섹션 요약 비유: 코드에 if문을 박아 트래픽을 쪼개는 짓은, 도로 표지판을 세울 돈이 아까워서 **'운전자(클라이언트) 1만 명의 뇌에 일일이 체면을 걸어 우회전하라고 세뇌(하드코딩) 시키는 미친 짓'**과 같습니다. 갑자기 공사(에러)가 나서 좌회전으로 길을 틀어야 할 때, 1만 명의 뇌를 다시 뜯어고칠(앱 강제 업데이트) 수가 없어 다 같이 절벽으로 돌진합니다. 서비스 메시는 아예 도로 입구에 **'리모컨으로 스르륵 움직이는 물리적 차단벽(프록시 라우터)'**을 깔아버리는 겁니다. 운전자들은 자기들 뇌를 1도 안 고치고 그냥 직진만 밟았는데, 바닥의 길이 꺾여(라우팅) 안전한 신도로(V2)로 완벽하게 미끄러져 들어갑니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• AI 주도 초정밀 카나리 롤아웃 (Autonomous Rollout): 인간이 대시보드를 보고 "에러율 0.5%네? 음 10%로 트래픽 올리자(딸깍)" 하는 매뉴얼 시대는 끝났다. 미래의 카나리는 젠킨스(CI)에 결합된 AI 옵스(AIOps)가 지배한다. AI가 1% 트래픽을 쏜 뒤, 서버의 100개 지표(CPU 곡선, GC 빈도, 유저 튕김 횟수)를 1초에 1만 번씩 머신러닝으로 씹어 먹는다. 인간의 눈에 안 보이는 '미세한 0.05초의 API 지연' 패턴을 AI가 낚아채고 "이거 놔두면 1시간 뒤에 스레드 풀 터짐 100% 확정!" 이라며 10초 만에 롤백 스위치를 턱 꺾어버리고 개발자 슬랙에 "내가 살림 ㅋ" 메시지 한 통을 남기는 '자율 주행 무인 배포 생태계'가 천하를 호령할 것이다.
• API 게이트웨이와 메시(Mesh)의 거대한 대통합 (Gateway API): 밖에서 오는 손님(North-South)은 API 게이트웨이(Nginx)가 라우팅하고, 안에서 노는 놈들(East-West)은 이스티오(Istio)가 라우팅하느라 룰(YAML)을 2개 언어로 각각 쳐야 하는 지옥(542장, 545장 딜레마)이 이어졌다. 이걸 참다못한 K8s 천재들이 **Kubernetes Gateway API**라는 전 우주 대통일 헌법을 반포했다. 이 텍스트 1줄만 치면, 밖의 게이트웨이든 안의 사이드카 프록시든 기계들이 알아서 찰떡같이 똑같은 트래픽 쪼개기(Weight Routing) 룰을 동시에 먹고 돌아가는 극강의 일원화된 뼈대 사상(Unified Control Plane)이 차세대 인프라를 갈아엎고 있다.

참고 표준

• Istio VirtualService & DestinationRule: 쿠버네티스의 멍청한 로드밸런싱(Service)을 쓰레기통에 박아버리고, "트래픽 1%는 V2로, 안드로이드 폰에서 온 놈은 가라!"라며 0.1초 단위의 마이크로 조향(Steering)을 가능하게 해 준 전 세계 서비스 메시 라우팅의 절대 교과서.
• Argo Rollouts: 깃옵스(GitOps) 생태계의 깡패. K8s 기본 기능(Deployment)으론 카나리(1% 올리기)가 수학적으로 안 돼서 피똥 쌀 때 혜성처럼 등장하여, Prometheus와 한 몸으로 붙어서 "에러 안 나면 10분마다 20%씩 올려주는" 전능한 배포 로봇 매니저.

트래픽 라우팅과 카나리 배포 제어(Service Mesh)는 소프트웨어 공학이 도달한 **'배포(Deployment)와 출시(Release)라는 단어의 거룩하고도 냉혹한 물리적 절단 수술(Decoupling)'**이다. 과거엔 소스코드를 서버에 덮어쓰는 그 순간이 곧 고객에게 선보이는 런칭이었다. 덮어쓰다 죽으면 다 같이 죽었다(공포). 기술사는 이 무식한 빅 뱅(Big Bang)의 끈을 과감히 도끼로 내리쳐 끊어내야 한다. 서버 백구석 어딘가에 새 코드(V2)를 몰래 띄워두는 것(Deploy)은 이제 아무런 위협이 아니다. 진짜 권력은 그 무기력하게 떠 있는 V2 서버를 향해, 수문장(Envoy Proxy)의 밸브를 1mm씩 비틀어 1,000만 트래픽 중 단 10방울만을 뚝뚝 떨어뜨리며 간을 보는(Release) '절대적 통제 스위치'에 있다. 코드는 개발자가 짜지만, 비즈니스의 생사를 가르는 그 트래픽 폭포수의 조향타(Steering Wheel)는 오직 인프라 아키텍트의 무자비하고 투명한 0.01초 컷오프(Cut-off) 그물망 위에서만 가장 안전하고 유려하게 춤출 수 있다.

• 📢 섹션 요약 비유: 이 라우팅 아키텍처는 극장에서 **'새로운 연극 대본(V2 코드)을 올리는 마술'**과 똑같습니다. 옛날(빅뱅)엔 커튼을 닫고 세트장을 망치로 다 부순 뒤(서버 다운), 새 세트를 짓고 커튼을 열어 1,000명의 관객(트래픽 100%)을 한 번에 맞았습니다. 배우가 연기를 틀리면 1,000명이 야유하고 환불 사태가 벌어집니다(장애 롤백의 지옥). 카나리(메시)는 극장 1층 구석의 조그만 밀실(V2 샌드박스)을 하나 파둡니다. 메인 무대(V1)는 그대로 1,000명이 즐기게 둡니다(무중단). 그리고 입장하는 관객 중 딱 10명(1%)만 몰래 샛길(라우팅 룰)로 빼돌려 밀실의 새 연극(V2)을 보여줍니다. 관객이 박수를 치면(Error 0%), 서서히 벽을 트며 10명, 50명, 1,000명을 새 무대로 부드럽게 흡수시켜 버리는 가장 완벽하고 두려움 없는 예술적 무대 전환입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 내가 세상에서 제일 맛있는 '새로운 초코맛 우유(V2 프로그램)'를 만들어서 동네 1,000명의 친구한테 한 번에 쐈어요! (옛날 배포)
2. 그런데 1,000명이 먹고 전부 다 배탈(버그/에러)이 나서 학교가 발칵 뒤집히고 선생님한테 엄청 혼났죠 ㅠㅠ (대형 장애)
3. 그래서 다음부턴 똑똑하게, 투명한 파이프(라우터) 밸브를 아주 조금만 열어서 딱 10명의 친구(1% 트래픽)한테만 먼저 몰래 먹여봤어요(카나리). 배가 안 아픈 게 100% 확실해지면 그때 밸브를 활짝 여는 마법의 밸브 조절법을 **'트래픽 라우팅과 카나리 배포'**라고 부른답니다!