536. 서비스 간 비동기 통신 - 메시지 큐 (RabbitMQ, Kafka), AMQP 프로토콜

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

1. 본질: 서비스 간 비동기 통신(Asynchronous Communication)은 앞차(서버)가 멈추면 뒷차도 다 같이 멈추는 동기 통신(REST/gRPC)의 동반 자살(Cascading Failure)의 사슬을 끊고, 중간에 거대한 '절대 우체국(Message Queue/Broker)'을 세워 "나는 편지 던졌으니까 내 할 일 하러 간다(Fire and Forget)!"라며 서버 간의 멱살(결합도)을 100% 놔버리는 완벽한 헐거운 결합(Loose Coupling) 아키텍처다.
2. 가치: 블랙프라이데이에 초당 100만 건의 결제 요청이 쏟아져 들어올 때, 백엔드 DB가 그걸 다 처리하느라 터지는 것을 막는다. 큐(Kafka)가 이 100만 건의 쓰나미 트래픽을 거대한 댐처럼 온몸으로 다 받아먹고(Buffering/Shock Absorbing), 뒷단 DB에는 초당 100건씩 쫄쫄쫄 부드럽게 흘려보내 주어 서버가 어떠한 미친 트래픽 폭주 앞에서도 평온하게 살아남는 극강의 가용성(Availability)을 보장한다.
3. 융합: 단순한 전통적 우체국 기능에 충실한 **RabbitMQ (AMQP)**와, 한 번 쓴 편지를 우주 끝날 때까지 지우지 않고 빅데이터 스트리밍의 심장으로 쓰는 **Apache Kafka(카프카)**의 양대 산맥으로 나뉘며, 클라우드 네이티브의 **이벤트 주도 아키텍처(EDA, Event-Driven Architecture)**와 융합되어 전 세계 MSA 생태계를 완전히 지배하고 있다.

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

• 개념: 비동기 통신은 '카카오톡'이나 '이메일'이다. 내가 친구한테 "돈 보내줘"라고 카톡(Message)을 남겼다. 나는 핸드폰을 끄고 내 할 일(다른 로직)을 하러 간다. 친구(B서버)는 자다가 3시간 뒤에 일어나서 내 카톡을 보고 돈을 보낸다. 내가 메시지를 보낸 시점과 상대방이 처리하는 시점, 그리고 대답이 오는 시점이 100% 분리(Decoupling)되어 시간의 족쇄에서 해방된 통신 마술이다.

• 필요성: 쿠팡에서 '주문 완료' 버튼을 눌렀다. 주문 서버가 ➡ 결제 서버 ➡ 재고 서버 ➡ 쿠폰 서버 ➡ 배송 서버 ➡ 이메일 알림 서버까지 연달아 통신을 쏜다. 이걸 HTTP(동기)로 쏘면? 이메일 발송 서버가 3초 렉이 걸리면 고객 스마트폰 화면도 "주문 중..." 이라며 3초 동안 하얗게 멈춰있다(사용자 경험 파멸). 더 최악은 결제는 됐는데 3초 뒤에 쿠폰 서버가 뻗어서 500 에러를 뿜으면 전체가 에러(롤백)가 나버린다. **"핵심(주문/결제)이 아닌 쩌리 기능(알림, 메일)들 때문에 회사의 돈통이 멈추는 이 미친 종속성(Tight Coupling)을 부수려면, 중간에 허공(큐)에 편지만 툭 던지고 0.1초 만에 고객에게 '주문 완료!' 화면을 띄워주는 쿨거래 시스템"**이 반드시 필요했다.

• 💡 비유: 비동기 통신(Kafka/RabbitMQ)은 식당의 **'돌림판 주문서 걸이(우체국)'**와 같습니다. 동기 통신(REST)은 홀 서빙 알바생이 주방장에게 직접 가서 "짜장면 하나요!" 외치고, 짜장면이 완성되어 그릇에 나올 때까지 주방장 옆에 우두커니 10분 동안 서 있는 멍청한 짓입니다(스레드 낭비). 비동기 통신은 알바생이 주문서를 돌림판(Queue)에 탁! 꽂고 바로 뒤돌아서 다음 손님을 받으러 달려갑니다(Fire and Forget). 주방장(Consumer)은 자기가 한가할 때 돌림판에서 주문서를 쓱 빼서 요리합니다. 요리사가 뻗든, 알바생이 바쁘든 서로의 속도 차이(트래픽 병목)가 완벽하게 상쇄되는 마법의 완충지대입니다.

• 등장 배경 및 발전 과정:

  1. EAI와 전통적 AMQP 큐 (과거): 2000년대 은행에서 RabbitMQ, ActiveMQ 등을 썼다. "편지가 도착했는지 확실하게 보장해 줄게!"라며 깐깐하고 우아하게 우체국 역할을 했다(AMQP 라우팅 규칙).
  2. 빅데이터 폭발과 Kafka의 강림 (2010s): 링크드인(LinkedIn)이 빡쳤다. "우체국이 너무 깐깐해서 초당 100만 개 편지(로그 데이터)를 처리 못 하고 터지네! 야, 택배 확인 도장 다 빼고 무식하게 일렬로 하드디스크에 줄 세워 박아버려!" 라며 극강의 무지성 초고속 스트리밍 큐 **Kafka**를 발명해 세상의 판도를 엎었다.
  3. 이벤트 주도(EDA) MSA의 천하통일 (현재): MSA로 갈가리 찢긴 50개의 서버가 서로 동기화(REST)하다가 다 같이 폭사하자, "서버들끼리 IP도 모르게 하고 오직 Kafka에 이벤트(Event)만 던지고 줏어먹어라!"는 Event-Driven 패러다임이 클라우드의 제1 헌법으로 등극했다.

• 📢 섹션 요약 비유: 동기(REST)가 **'양손에 땀을 쥐게 하는 바통 이어달리기'**라면(앞사람이 넘어지면 뒷사람도 평생 못 달림), 비동기(메시지 큐)는 **'우체통에 편지 몰아넣기'**입니다. 우체통에 편지 100통을 쑤셔 넣고 1초 만에 집에 가면 됩니다. 우체부(Consumer)가 비 오는 날 배달하든, 3일 뒤에 배달하든 나는 알 바 아닙니다. 내 역할과 시간의 사슬을 끊어내는 자유의 기술입니다.

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

1. 양대 산맥의 철학적 격돌: RabbitMQ (전통) vs Apache Kafka (현대)

둘 다 메시지 큐라고 부르지만, 아키텍처의 영혼(Soul) 자체가 완전히 다른 기계다. 면접 단골 질문 1위.

2. 비동기 통신의 궁극의 필살기: 펍/섭 (Pub/Sub) 아키텍처

Kafka가 MSA 생태계의 왕이 된 이유. '1 대 다(1:N)' 흩뿌리기 마술이다.

[ 1. Publisher (주문 서버 - 생산자) ]
   "야! 주문번호 999번 결제 완료됐다!" 라는 전단지(Event) 1장을 허공(Kafka Topic)에 휙 던진다.
   (그리고 주문 서버는 끝! 자기 할 일 하러 간다. 0.1초 컷)
        │
        ▼
[ 2. Kafka Topic (거대한 전단지 게시판) ]
        │ (구독자들에게 복사해서 뿌림)
  ┌─────┼─────────────────────────┐
  ▼     ▼                         ▼
[배송] [쿠폰]                    [빅데이터]
"오!   "오! 999번 놈           "오! 999번 구매 
999번   결제했어? 1천원          로그 통계 DB에 
택배   할인 쿠폰 발행            적재해야지~"
싸자!"  진행시킴!"              (Subscriber - 소비자)

• 원리 (Decoupling의 기적): 옛날 동기(REST) 방식이었다면, 주문 서버가 배송, 쿠폰, 빅데이터 서버 3곳의 IP 주소를 다 외우고 일일이 전화를 3번 돌려야 했다(강한 결합). 1년 뒤 '알림톡 서버'가 새로 생기면 주문 서버의 소스코드를 또 뜯어고쳐야 했다.

• Pub/Sub의 위엄: 주문 서버는 배송팀이 존재하는지, 빅데이터팀이 세상에 있는지조차 알 필요가 없다(Zero Knowledge). 그저 자기가 한 일(이벤트)을 중앙 게시판(Kafka)에 던질 뿐이다. 알림톡 서버가 10개 더 생기든 말든 주문 서버 코드는 우주가 끝날 때까지 1줄도 수정되지 않는 완벽한 물리적, 논리적 절단(Decoupling)이 완성된다.

• 📢 섹션 요약 비유: 동기 통신은 **'친구 3명한테 1명씩 전화 돌려서 "나 결혼해!"라고 말하는 것(시간 오래 걸리고 1명 안 받으면 답답함)'**입니다. Pub/Sub 비동기 통신은 **'내 인스타그램 피드에 "나 결혼해!" 글 딱 1개 올리고 폰 끄고 자는 것'**입니다. 친구 1,000명이 새벽에 그 글을 읽든, 3일 뒤에 읽든, 새로 사귄 친구가 내일 내 피드에 와서 읽든 내(주문 서버) 알 바 아닙니다. 내 노력은 게시글 1번 쓰는 걸로 끝나는 무한 확장의 마술입니다.

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

1. 동기(Synchronous/REST) vs 비동기(Asynchronous/Kafka) 최후의 심판

둘 중에 무얼 쓸지 결정하는 건 아키텍트의 몸값을 증명하는 순간이다. (535장 복습 융합)

과목 융합 관점

• 소프트웨어 공학 (Saga 패턴과 Eventual Consistency): MSA 데이터베이스 분리의 영원한 저주를 푸는 열쇠다. 주문 DB와 결제 DB가 찢어졌다(534장). 결제는 성공했는데 재고 DB 서버가 뻗었다(에러). ROLLBACK이 안 된다! 이때 아키텍트는 카프카(Kafka)에 **"재고 빼기 실패했음! 주문 취소 이벤트 발사!"**라는 보상(Compensation) 편지를 던진다. 주문 서버가 나중에 그 편지를 읽고 자기 손으로 주문 취소 업데이트를 친다. 당장 1초 뒤에는 유저 화면에 주문이 된 것처럼 거짓말(에러 상태)을 하겠지만, 1분 뒤에는 어떻게든 전 우주의 데이터가 취소 상태로 딱 맞아떨어지는 **결과적 정합성(Eventual Consistency)**이라는 MSA 최고의 철학이 바로 비동기 큐를 통해 융합 완성된다.

• 클라우드 / 데브옵스 (Dead Letter Queue, DLQ 방어막): 비동기로 편지를 10번 던졌는데, 받는 쪽 서버가 로직 에러가 나서 편지를 계속 못 읽고 뱉어낸다. 이 독극물 편지(Poison Pill) 1장 때문에 큐 전체가 꽉 막혀버리는 대참사가 난다. 데브옵스 아키텍트는 무조건 큐 옆에 **'사망한 편지들의 무덤(DLQ)'**을 하나 더 파놓아야 한다. "3번 시도해서 못 읽은 편지는 이 무덤(DLQ)으로 발로 차버려라! 그리고 슬랙(Slack) 알람 띄워서 개발자가 수동으로 까보게 해!" 메인 고속도로(Queue)의 체증을 기계적으로 뻥 뚫어주는 인프라 파이프라인의 생명선이다.

• 📢 섹션 요약 비유: 비동기 통신과 DLQ는 컨베이어 벨트 위의 **'불량 사과 골라내기 기계'**입니다. 정상 사과(정상 이벤트)는 예쁘게 박스에 담깁니다. 그런데 썩은 사과(버그 난 메시지)가 기계에 걸려 덜컹거립니다. 이걸 냅두면 뒤에 밀려오는 수만 개의 사과가 다 박살 납니다(큐 마비). 기계는 3초 덜컹거리다 안 되면 그 썩은 사과를 발로 차서 옆의 **'불량품 바구니(DLQ)'**에 던져버리고 다시 벨트를 초광속으로 돌립니다. 불량품 바구니는 나중에 사람(개발자)이 와서 버리든 닦아서 다시 벨트에 올리든(Replay) 수동으로 처리하는 완벽한 공장 최적화입니다.

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

실무 시나리오

1. 시나리오 — 데이터가 두 번씩 들어가요! At-Least-Once의 딜레마 (멱등성 붕괴): 초보 개발자가 "RabbitMQ 달았으니까 결제 안심!" 이라며 런칭했다. 어느 날, 은행 앱에서 유저 1명한테 송금이 2번씩 꽂히는 미친 버그가 터졌다. 원인은 '메시지 전달 보장 룰' 때문이었다. 큐가 결제 서버에 "1만 원 이체해" 편지를 줬다. 결제 서버가 1만 원을 넣었는데, "나 처리했어(Ack)" 도장을 큐에 찍어주기 직전 0.001초 찰나에 서버 전원이 나갔다. 큐는 "어? 도장 안 왔네? 얘 처리 못 했나 보다!" 하고 다른 결제 서버를 켜서 편지를 또! 던졌다(At-Least-Once 보장). 결제 서버는 또 1만 원을 이체했다. 돈이 복사됐다.

   • 아키텍트의 해결책: 비동기 통신의 절대 원칙, 멱등성(Idempotency) 설계 누락이다. 큐(Queue)는 네트워크 에러 때문에 무조건 편지를 2번 이상 던질 수 있다(중복 배달). 아키텍트는 큐를 탓하면 안 된다. 받는 놈(결제 서버)의 DB 로직에 무조건 "내가 이 편지 번호(Message ID tx-999)를 예전에 처리한 적 있는지 DB 유니크 키(Unique Key)나 Redis 셋으로 1번 찔러보고, 이미 처리한 편지면 0.1초 만에 걍 쌩까고 Pass 하는" 멱등성 껍데기 필터를 강제로 둘러씌워야만 돈 복사 버그라는 참사를 틀어막을 수 있다.

2. 시나리오 — 이벤트 순서(Order)가 뒤섞인 혼돈의 장바구니: Kafka를 썼다. 유저가 [장바구니 추가] ➡ [장바구니 삭제] ➡ [장바구니 추가]를 1초 만에 따다닥 눌렀다. 카프카 큐에 이벤트 3개가 1, 2, 3번 순서로 들어갔다. 그런데 받는 서버 3대가 병렬(Multi-Thread)로 미친 듯이 이 편지들을 동시에 낚아챘다. 2번 서버가 제일 빨라서 삭제를 먼저 처리해 버렸고, 그다음에 1번과 3번 서버가 추가를 처리했다. 유저의 최종 화면 장바구니에는 물건이 2개 담겨버렸다(데이터 정합성 파괴). 비동기 분산 처리에서 순서(Sequence)가 꼬인 것이다.

   • 아키텍트의 해결책: 파티션 키(Partition Key) 분할의 라우팅 실패다. 카프카는 100만 건을 처리하려고 고속도로를 10차선(Partition)으로 뚫어놓는다. 차선이 10개니 도착 순서가 뒤죽박죽이 된다. 아키텍트는 철칙을 세워야 한다. "순서가 생명인 데이터(예: 동일한 유저 A의 행동 3가지)는 무조건 카프카에 편지를 던질 때 User_A 라는 키(Key) 값을 달아서 쏴라!" 키를 달아주면 카프카는 "아, 유저 A의 편지 3장은 무조건 3차선(특정 Partition 1개)으로만 밀어 넣어야지!"라고 교통정리를 한다. 1차선으로만 가니까 1번 ➡ 2번 ➡ 3번 순서가 우주가 끝날 때까지 100% 완벽하게 보장(Ordering Guarantee)되는 통제의 예술이다.

도입 체크리스트

• 비즈니스적: "이 통신이 시스템의 병목(Bottleneck)인가, 아니면 즉시 응답(Real-time)이 필요한가?" 고객이 로그인 비밀번호를 쳤는데, 이걸 큐(Queue)에 던지고 "회원님, 5분 뒤에 로그인 결과 알려드릴게요~" 하면 앱 당장 삭제당한다. 이건 무조건 REST(동기)다. 반면, 고객이 동영상을 1GB짜리 업로드했다. 이 동영상을 MP4로 인코딩하는 데 10분이 걸린다. 이걸 REST로 짜면 유저는 10분 동안 핸드폰 화면만 보고 멈춰있어야 한다. 아키텍트는 이 무거운 작업(Heavy Job)을 즉시 **비동기 큐(RabbitMQ)**로 던져놓고, 화면엔 "업로드 완료! 변환 끝나면 푸시 알림 드릴게요!"라고 0.1초 만에 튕겨내는 UX 아키텍처로 비즈니스와 기술을 찰떡같이 융합시켜야 한다.
• 기술적: 카프카(Kafka)의 오버스펙(Over-engineering) 맹신을 주의하라. 스타트업 개발자가 "요새 카프카가 짱이래!" 라며 하루 트래픽 100건 나오는 게시판 앱에 카프카 클러스터 3대를 AWS에 올렸다. 한 달 인프라 비용만 300만 원이 나오고 주키퍼(Zookeeper) 관리하느라 서버 엔지니어가 퇴사했다. 카프카는 '초당 10만 건 이상의 로깅 스트리밍'이나 '1:N 다중 브로드캐스트'가 필요한 우주선급 빅데이터 엔진이다. 그냥 "서버 2대끼리 1:1로 비동기 편지 한 통 주고받기" 용도라면 깃털처럼 가볍고 관리하기 짱 편한 RabbitMQ나 클라우드 벤더 종속형 AWS SQS를 찰칵 달고 꿀을 빠는 것이 진짜 현명한 아키텍트의 가성비(ROI) 감각이다.

안티패턴

• "보낼 게 없는데 큐에 뚱뚱한 데이터 다 때려 박기 (Message Bloat)": 주문을 1개 취소했다고 치자. 멍청한 개발자는 주문자의 이름, 집 주소, 결제 신용카드 번호, 산 물건 리스트(JSON 1MB)를 통째로 텍스트로 묶어서 카프카 큐에 쑤셔 넣는다. 10만 명이 주문 취소하면 카프카 메모리가 100GB가 차면서 뻗어버리고 네트워크가 찢어진다. "큐(Queue)는 택배 화물차가 아니라 우체부의 가벼운 가방이다." 아키텍트는 Claim Check 패턴을 강제해야 한다. 큐에는 오직 [주문번호: 999 취소됨] 딱 10바이트짜리 딱지만 날린다. 이걸 받은 서버가 "오 999번 취소됐네?" 하고 자기가 직접 DB에 999번을 검색(SELECT)해서 무거운 데이터를 가져다 쓰는 분리주의가 큐 생태계의 절대 매너다.

• 📢 섹션 요약 비유: 큐에 데이터를 다 때려 박는 짓은, 친구한테 책 100권을 빌려줄 때 **'카카오톡으로 책 100권 글씨를 다 타이핑해서 메시지로 쏘는 미친 짓'**과 같습니다. 폰 터지고 카톡 서버 터집니다. 진정한 비동기 쿨거래(Claim Check)는, 책 100권은 도서관 보관함(DB)에 얌전히 넣어두고, 친구 카톡(Queue)으로는 "보관함 3번 비밀번호 1234(딱지)" 딱 한 줄만 보내는 겁니다. 친구는 나중에 편할 때 그 번호를 들고 가서 짐을 꺼내갑니다. 메시지 큐는 가벼울수록 위대합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 서버리스 이벤트 브로커(Serverless Event Bridge)의 대통일: 과거엔 엔지니어가 카프카(Kafka)나 RabbitMQ 서버를 띄우고 메모리 관리를 하며 피똥을 쌌다. 3년 뒤 클라우드 생태계는 AWS EventBridge나 GCP Pub/Sub 같이 아예 인프라조차 없는 '완전 관리형 서버리스 우체국'으로 모든 트래픽을 넘길 것이다. 카프카 클러스터를 직접 까는 짓은 구시대 유물이 되며, "이벤트가 1개 지나갈 때마다 0.001원 과금"하는 궁극의 사용량 기반 비동기 파이프라인이 아키텍트들의 기본 베이스캠프가 되고 있다.
• 스트림 프로세싱 (Stream Processing) - 고여있는 DB의 죽음: 기존 앱은 데이터를 DB에 예쁘게 저장해 놓고 나중에 필요할 때 검색(SELECT)했다. 카프카(Kafka Streams, Flink)가 지배하는 세상에선 데이터가 고여있지 않다. 해커가 침입한 IP, 고객이 클릭한 장바구니 버튼의 수천만 개 데이터(Event)가 허공(Stream)을 콸콸 날아다닌다. 서버는 DB에 저장하기도 전에 이 날아다니는 냇물을 공중에서 낚아채 실시간(Real-time)으로 분석하고 1초 만에 "이놈 해커다! 이 고객한테 할인 쿠폰 쏴라!" 결론을 내버리는 미친 실시간 스트리밍(In-stream) 아키텍처가 RDBMS의 낡은 왕좌를 깨부수고 있다.

참고 표준

• AMQP (Advanced Message Queuing Protocol): RabbitMQ의 심장. "메시지는 절대 잃어버리면 안 되고, A단어가 있으면 1번 방, B단어면 2번 방으로 정확히 분류해서 쏴라!"는 전 세계 은행권 큐(Queue) 통신 규격의 절대 헌법이자 클래식.
• Apache Kafka: 링크드인이 빡쳐서 AMQP의 라우팅 룰을 다 버리고, 오직 "하드디스크에 1초에 100만 건 순서대로 쾅쾅 찍어버리는 무식한 통나무(Log) 장부" 철학으로 빅데이터 스트리밍의 세계 1대장으로 군림한 오픈소스.

서비스 간 비동기 통신(Message Queue, Kafka)은 소프트웨어 공학이 **"나와 타인의 시간을 완벽하게 분리(Decoupling)해 내어, 상대방의 고통과 지연이 나의 생명을 갉아먹지 않게 만든 가장 이기적이고도 가장 안전한 생존의 철학"**이다. 우리는 모놀리식 시절 함수를 호출하며 남의 대답을 목매어 기다리는 강결합의 늪에 빠져 다 같이 수장되었다. 기술사는 이 사슬을 과감히 도끼로 찍어 끊어버려야 한다. 아무리 중요한 주문 로직이라도 메인 스레드에 묶어두지 마라. "난 편지를 던졌다. 네가 죽든 살든, 오늘 밤에 읽든 1년 뒤에 읽든 난 알 바 아니고 내 화면 렌더링이나 하러 간다." 이 피도 눈물도 없는 이기주의(Fire and Forget)야말로 마이크로서비스라는 수만 대의 함대가 파도의 폭격 속에서도 서로 부딪혀 깨지지 않고 거대한 바다를 각자의 속도로 항해할 수 있게 해주는 궁극의 자유(Autonomy)이자 신이 내린 아키텍처의 황금 밸런스다.

• 📢 섹션 요약 비유: 비동기 아키텍처(Kafka)는 1,000만 명이 몰리는 놀이공원의 **'물품 보관함(락커)'**과 같습니다. 옛날 동기식(REST)은 손님 1만 명이 입장할 때 짐을 맡기려고 직원 1명(DB) 앞에 한 줄로 섰습니다(서버 마비). 비동기 시스템은 입구에 수만 개의 무인 물품 보관함(Kafka Queue)을 쫙 깔아둡니다. 1만 명의 손님(웹 서버)은 1초 만에 각자 짐(메시지)을 빈 칸에 쾅쾅 쑤셔 넣고 바로 롤러코스터를 타러 놀러 갑니다(응답 완료). 그리고 밤 12시가 되면 청소부 알바생(컨슈머)이 여유롭게 수레를 끌고 와서 보관함의 짐을 하나하나 천천히 수거해서 창고(DB)에 분류해 놓습니다. 쏟아지는 인파의 충격을 기계통(큐)이 다 흡수하여 인간(서버)이 아무도 다치지 않는 완벽한 충격 흡수(Shock Absorbing) 댐입니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 내가 배가 너무 고파서 엄마한테 "엄마 라면 끓여줘!" 하고 부엌 앞에서 10분 동안 꼼짝 안 하고 기다렸어요(동기 통신). 너무 지루하고 화장실도 못 갔죠 ㅠㅠ
2. 그래서 다음엔 냉장고에 **"엄마 나 라면 먹고 싶어!"라고 쓴 포스트잇(메시지)**을 딱 붙여놓고 바로 방으로 뛰어가서 신나게 게임을 했어요(비동기 통신).
3. 엄마가 나중에 요리를 다 하고 방문을 열고 라면을 갖다주셨죠! 이렇게 상대방이 당장 대답을 안 해도, 튼튼한 우체통(메시지 큐)에 편지만 휙 던져놓고 내 할 일을 마음대로 할 수 있게 자유를 주는 마법을 **'비동기 통신'**이라고 부른답니다!