553. 코레오그래피 사가 (Choreography Saga) - 이벤트 구독 기반의 자율적 흐름

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

본질: 코레오그래피 사가(Choreography Saga)는 중앙 지휘자(Orchestrator) 없이 각 마이크로서비스가 허공(Kafka)에 이벤트를 툭 던지고 퇴근하면, 관심 있는 다른 서비스들이 알아서 주워 먹고 다음 행동을 이어가는 **무정부 자율 핑퐁 구조(Event-Driven)**다.

가치: 중앙 서버가 없기에 단일 장애점(SPOF)이 완벽히 사라지며, 각 서비스는 옆 팀 서버의 API 주소나 생사 여부를 1도 알 필요 없이 카프카만 쳐다보면 되는 **극강의 시스템 결합 끊기(Decoupling)**를 달성하여 시스템의 민첩성을 우주 끝까지 끌어올린다.

융합: 서비스가 2~3개일 땐 최고의 속도를 자랑하지만, 4~5개를 넘어가는 순간 메시지가 핑퐁 치다 어디서 뻗었는지 전사 흐름을 볼 도면이 사라지는 **스파게티 결합의 늪(디버깅 지옥)**에 빠지게 되므로, 복잡도가 올라가면 **오케스트레이션(552장)**으로 반드시 회귀해야 하는 양날의 검이다.

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

개념: 'Choreography'는 무용수들이 정해진 룰(음악)에 맞춰 각자 지 알아서 춤을 추는 '안무'를 뜻한다. 주문, 결제, 배송 서버가 중앙의 지시를 받지 않고, "나 주문 만들었음!(Event)"을 허공에 던진다. 결제 서버는 그냥 평소에 "주문 만들어졌나?" 카프카를 쳐다보고(구독, Subscribe) 있다가 잽싸게 낚아채서 돈을 빼고 "나 돈 뺐음!"을 던지는 자율적 퍼스텝 릴레이 구조다.
필요성: MSA로 서버를 예쁘게 찢어놨는데, 552장의 오케스트레이션처럼 중앙 대빵 서버를 띄워서 "네가 해!"라고 REST API를 쏘는 짓을 하면, 결국 그 대빵 서버 코드가 비대해지는 **스파게티 몬스터(God Object)**가 된다. "아니, MSA의 핵심은 탈중앙화(Decentralization)잖아! 왜 또 중앙 통제기를 만들어? 그냥 쿨하게 이벤트 허공에 던지고 남남으로 살자!"는 궁극의 무결합(Zero-Coupling) 이상주의가 코레오그래피를 대세로 만들었다.
💡 비유: 코레오그래피는 동네 골목길의 **'쓰레기 수거 시스템'**과 똑같습니다. 시민(주문 앱)은 쓰레기를 버릴 때, 청소부(배송 앱)한테 전화(API 호출)해서 "쓰레기 가져가세요"라고 중앙 지시를 내리지 않습니다. 그냥 전봇대 밑(Kafka)에 쓰레기봉투(이벤트)를 툭 던져두고 자기 할 일 하러 갑니다. 청소부 역시 시민을 알 필요가 없습니다. 새벽에 트럭 타고 돌다가 전봇대 밑에 쓰레기가 있으면 묵묵히 주워다가 처리합니다. 둘은 평생 얼굴 한번 안 보고도 도시의 쓰레기(비즈니스 룰)를 완벽하게 순환시킵니다.
등장 배경 및 발전 과정:
1. ESB의 붕괴 (2010s 초반): 옛날엔 중앙 버스(ESB)가 모든 메시지를 쥐락펴락했다. 이 버스가 뻗으면 전사가 뻗었다(SPOF). 사람들은 중앙 통제에 학를 뗐다.
2. Kafka의 혁명 (2010s 중반): 링크드인에서 카프카(Kafka)라는 미친 속도의 이벤트 큐를 발명했다. "야, 그냥 다 카프카로 쏴. 중앙 통제기 없애!" 이른바 덤 파이프 & 스마트 엔드포인트(Dumb Pipe & Smart Endpoint) 사상의 전성기가 열렸다.
3. 복잡성의 역습 (현재): 코레오그래피가 유행하자 스타트업들이 무지성으로 도입했다. 그런데 이벤트가 10번 핑퐁을 치니, 버그가 났을 때 아무도 롤백 흐름을 파악하지 못해 회사가 파산하는 사례가 속출하며 "작을 땐 코레오그래피, 클 땐 오케스트레이터"라는 하이브리드 국룰이 세워졌다.
📢 섹션 요약 비유: 오케스트레이션이 **'지휘자의 손끝만 보는 100인 교향악단'**이라면, 코레오그래피 사가는 무대 위에서 각자 상대방의 춤(이벤트)을 보고 알아서 다음 스텝을 밟는 **'길거리 비보이 댄스 배틀'**입니다. 지휘자가 없으니 프리스타일(민첩성)은 최고지만, 한 명이 춤을 망치면(에러) 나머지 애들이 스텝이 꼬여서 무대가 개판(스파게티)이 되는 리스크를 안고 뜁니다.

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

1. 코레오그래피 동작 시퀀스 (PUB / SUB 모델)

명령(Command)은 1도 없다. 오직 "과거형 상태(Event)"만 존재한다.

[ 🛡️ 주문 ➡ 결제 ➡ 재고 (자율 릴레이 흐름) ]

이벤트 폭발: 주문 서버가 DB에 주문을 넣고, Kafka Order_Topic에 OrderCreated (주문 생성됨) 이벤트를 툭 쏜다.
자율 구독(Sub): 결제 서버가 Order_Topic을 쳐다보다가 이벤트를 낚아챈다. 고객 돈을 깎고 DB에 커밋한다. ➡ Kafka Payment_Topic에 PaymentBilled (결제 완료됨) 이벤트를 툭 쏜다.
자율 구독(Sub): 재고 서버가 Payment_Topic을 쳐다보다가 낚아챈다. 물건 1개 깐다. ➡ Kafka Inventory_Topic에 InventoryUpdated (재고 차감됨) 쏜다. ▶ 특징: 주문 서버는 결제 서버가 세상에 존재하는지조차 모른다. 결제 서버 코드가 파괴되어도 주문 서버는 0.1초도 기다리지 않고 지 할 일 한다(궁극의 Decoupling).

2. 에러 났을 때의 눈치 게임 (보상 트랜잭션 핑퐁) 💥

지휘자가 없으니 에러가 나도 스스로 눈치껏 주워 먹고 환불해야 한다.

[ 💥 재고 서버가 뻗었다면? ]

재고 서버가 이벤트를 먹고 재고를 까려는데 품절이다!
재고 서버는 로컬 롤백 치고 ➡ Kafka Inventory_Topic에 InventoryFailed (재고 차감 실패함) 이벤트를 던진다. (누가 보든 말든 상관 안 함)
결제 서버의 책임감: 결제 서버는 평소에 자기가 돈 뺐던 놈이 실패할까 봐 Inventory_Topic을 **역으로 구독(Sub)**하고 있다. 실패 이벤트를 주워 먹고, "아오 ㅆㅂ 내가 뺀 거 뻗었네!" 하면서 로직으로 환불(+1000원) 쿼리를 때린다.
환불 끝난 결제 서버는 PaymentRefunded (결제 환불됨)을 던진다.
주문 서버가 그걸 주워 먹고 주문 상태를 CANCELED(취소)로 바꾼다.

원리 (단일 책임 원칙, SRP): 각 마이크로서비스는 자기 자신의 앞가림(Forward)과 자기 자신의 똥 치우기(Compensation) 코드를 모두 뱃속에 내재화해야 한다. 지휘자가 없기 때문이다.
📢 섹션 요약 비유: 이 눈치 게임은 식당 주방의 **'주문서 꽂이(Kafka)'**와 같습니다. 카운터 직원이 주문서에 "짜장면!" 써서 꽂이에 꽂으면(이벤트 발행), 면 끓이는 직원이 뽑아가서 면을 끓이고 "면 다 끓임!" 쪽지를 다시 꽂습니다. 볶음 직원이 그걸 보고 소스를 볶죠. 그런데 볶음 직원이 "아 춘장 다 떨어짐 ㅠㅠ(에러)" 쪽지를 꽂아두면, 면 끓이던 직원이 그걸 보고 "아씨 면 버려(보상 트랜잭션)"라고 스스로 알아서 쓰레기통에 버립니다. 주방장(통제기)이 "야 버려!"라고 소리치지 않아도 완벽하게 굴러갑니다.

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

1. 사가 뇌 구조 최종 복습 (Choreography vs Orchestration)

척도	코레오그래피 (Choreography) 💃	오케스트레이션 (Orchestration) 👑
통제 주체	없음. Kafka 이벤트 PUB/SUB 눈치 게임	있음. 중앙 서버가 Command(명령) 직접 쏨
코드 결합도	앱 간 무결합(Decoupling 100%). 옆 앱 IP 알 필요 없음.	통제기가 50개 앱 IP를 다 쥐고 멱살을 잡음.
최대 장점	서비스 1개를 추가할 때 통제기 코드를 고칠 필요 없이, 걍 나 혼자 큐만 새로 구독하면 끝. (확장성 극강)	복잡한 에러(결제->포인트->쿠폰 에러) 터졌을 때 흐름과 디버깅 파악이 통제기 UI에서 1초 컷.
최대 단점	비즈니스 흐름 추적 불가 (스파게티). 핑퐁 치다 에러 나면 누가 책임질 건지 알 수가 없음.	통제기 서버가 터지면 전사 마비(SPOF). 통제기 코드가 갈수록 뚱뚱해짐(God Object).

과목 융합 관점

소프트웨어 공학 (사이클릭 의존성 안티패턴 방어): 코레오그래피의 핑퐁은 방심하면 순환 참조(Cyclic Dependency) 버그를 낳는다. A앱 ➡ B앱 ➡ C앱 ➡ 다시 A앱을 찌르는 식의 이벤트 순환 고리가 발생하면, 카프카 큐 안에서 이벤트가 토네이도처럼 뱅뱅 돌며 1초 만에 메시지 1억 개가 쌓여 서버 전체 램(RAM)이 터져버리는 대재앙이 온다. 아키텍트는 이벤트 토픽(Topic) 설계 시, 단방향 다이렉티드 아시클릭 그래프(DAG) 방향으로만 토픽이 흐르도록 엄격한 아키텍처 리뷰를 갈겨야 한다.
데이터베이스 (이벤트 소싱과의 완벽한 시너지): 555장 이벤트 소싱(Event Sourcing)을 쓸 거면 99% 확률로 코레오그래피 사가를 쓰게 된다. 이벤트 소싱은 애초에 "내 상태(DB)를 바꾸려면 나한테 이벤트를 쏴라!"는 철학이다. 오케스트레이터가 "야 돈 빼(Command)" 쏘는 건 이벤트 소싱 사상과 안 맞는다. "돈 뺄 권한을 가진 이벤트가 발생함(Event)"이라고 던지고 각 DB가 알아서 상태를 업데이트하는 찰떡궁합의 클라우드 생태계 조합이다.
📢 섹션 요약 비유: 코레오그래피의 스파게티 지옥은 **'오징어 게임의 유리 징검다리 건너기'**와 같습니다. 앞사람이 유리(이벤트)를 밟고 무사히 넘어가면 뒷사람이 눈치껏 따라 밟습니다. 3명이 밟을 땐 괜찮은데, 10명이 한 번에 밟다가 앞사람이 뻥 터져 떨어지면(에러), 뒤에 있던 애들이 당황해서 "야 어디로 돌아가야 돼?!" 소리치다 서로 엉켜서 다 같이 바닥으로 추락하는 대혼돈입니다. 통제관(Orchestrator)이 없기 때문에 에러 수습의 난이도가 수학적으로 폭증합니다.

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

실무 시나리오

시나리오 — '추적 불가(Unobservable)' 스파게티 지옥에 갇힌 배달앱: 배달의 민족 짭 앱을 만들며 코레오그래피로 짰다. [결제 ➡ 쿠폰 ➡ 배송 ➡ 리뷰 ➡ 사장님 앱 알림]. 메시지가 5단계를 친다. 사장님이 "어? 고객이 결제했다는데 내 앱엔 주문이 안 떠요!" 클레임을 걸었다. 개발자가 로직을 까보려는데, 결제 토픽, 쿠폰 토픽, 배송 토픽 3개의 큐를 뒤져야 하고 각 앱의 로그를 Elasticsearch에서 검색어 3번 쳐서 5분 동안 머릿속으로 그림을 맞춰봐야 "아, 쿠폰 서버가 카프카 메시지 뱉고 죽었네!"라는 걸 깨닫는다. 장애 복구 시간(MTTR)이 우주로 간다.
- 아키텍트의 해결책: 상관관계 ID (Correlation ID / Trace ID)의 K8s 전사 강제 주입이다. 코레오그래피를 쓰려면 무조건 이 안전장치가 있어야 한다. 아키텍트는 분산 트레이싱 툴(Jaeger, Zipkin)을 박고, 주문이 최초 생성될 때 생성된 무작위 난수 Trace-ID: X-1234를 K8s 전사 표준 헤더로 선언한다. 결제, 쿠폰 서버가 카프카에 이벤트를 핑퐁 칠 때, 이 꼬리표(Trace-ID)를 절대 잃어버리지 않고 바디에 릴레이로 박아서 넘기도록 강제한다. 사장님 클레임이 들어오면 대시보드에 X-1234만 검색창에 때려 넣으면, 5개 서버가 핑퐁 친 화살표 다이어그램이 1초 만에 3D로 그려지는 마술을 얻는다. (526장 연계).
시나리오 — 토픽(Topic) 파편화로 인한 카프카 클러스터 관리 마비: 마이크로서비스 팀들이 "우리 팀 코레오그래피 할 거임 ㅋ" 하면서 각자 맘대로 Kafka 토픽을 파댔다. order-created, order-created-v2, order-success-final... 토픽이 1,000개가 넘어가면서 Kafka 브로커 램(RAM)이 터지고, 누가 어떤 토픽을 구독하는지 아무도 모르는 유령 토픽이 500개나 방치되는 폐기물 처리장이 되었다.
- 아키텍트의 해결책: 이벤트 스키마 레지스트리(Schema Registry) 기반의 거버넌스 통치다. 코레오그래피는 '무정부'가 장점이지만, 그렇다고 스키마(규격)까지 지들 맘대로 치면 회사가 망한다. 아키텍트는 Apache Avro 나 Protobuf를 도입하고 "이벤트 쏠 거면 중앙 스키마 레지스트리에 필드 구조(Field, Type) 검사받고 도장받은 구조만 카프카에 쏴라!"라고 헌법을 세운다. A팀이 user_id를 쏘고 B팀이 userId를 주워 먹다 NPE 에러로 파드 전체가 셧다운되는 타입 캐스팅(Type-casting) 폭탄을 원천 봉쇄해야 코레오그래피가 돌아간다.

도입 체크리스트

비즈니스적: "비즈니스 프로세스(흐름)에 참여하는 마이크로서비스가 3개 이하인가?" 주문 ➡ 결제 ➡ 재고 이렇게 심플하게 3개짜리 릴레이면 코레오그래피의 핑퐁 속도가 빛을 발한다. 굳이 무거운 오케스트레이터 서버 파고 자시고 할 돈이 아깝다. 하지만 4개를 넘어가는 순간 핑퐁 경우의 수는 수학적 N(N-1) 로 폭증한다. 도메인이 너무 심플하고 확장이 자주 안 일어나는 코어 도메인이 아닌 '변두리 로그 적재, 알림 톡 발송' 정도의 쩌리 비즈니스라면 코레오그래피가 압도적 갓성비다.
기술적: At-Least-Once 보장과 멱등성 필터를 감당할 여력이 있는가? 지휘자가 없기 때문에, 결제 서버가 "돈 뺐다" 이벤트를 쐈는지 안 쐈는지 챙겨줄 놈이 아무도 없다! 카프카는 최소 1번 전달(At-Least-Once)을 보장하므로, 네트워크가 꼬이면 "돈 뺐다" 이벤트가 배송 서버에 2~3번 중복 전달될 확률이 100%다. 모든 구독자(Consumer)는 뱃속에 이 메시지를 1번만 처리하는 멱등성(Idempotency) 로직 방파제를 기본 소양으로 치고 1주일 내내 TDD 테스트해야 한다.

안티패턴

"코레오그래피 사가 하면서 DB 동기화(Sync) 락을 같이 섞어 쓰기": 이벤트(Event) 던져서 무결합 비동기를 하겠다면서, 정작 앱 코드 뱃속에는 JPA @Transactional 안에서 카프카에 kafkaTemplate.send() 때리는 미친 짓. DB 트랜잭션 락 잡고 카프카 통신 대기하다 10초 렉 걸리면 커넥션 풀 100% 다 말라서 서비스 연쇄 폭발함. (550, 551장에서 귀에 딱지가 앉도록 말한 아웃박스 패턴 부재의 파국).
📢 섹션 요약 비유: 코레오그래피로 4개 이상 서버를 핑퐁 치게 놔두는 것은, **'탁구대 하나에 10명의 선수를 올려놓고 탁구공 5개를 동시에 던지며 알아서 쳐내라고 하는 미친 게임'**과 같습니다. 1명이 공을 놓치면(에러), 대체 누가 누구한테 던진 공을 놓쳤는지 심판(통제기)이 없어 잡아낼 수가 없습니다. 공이 2개(서비스 2개)일 때까지만 이 눈치 게임이 아슬아슬하게 통합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	중앙 통제기(오케스트레이터/ESB) 기반 강결합 시절	코레오그래피(이벤트 구독) 사가 도입 후	개선 효과
정량	새 서버(포인트 적립) 붙일 때 중앙 서버 코드 수정+배포 1달 소요	신규 서버가 혼자 결제 완료 이벤트 구독만 하면 끝 (0초)	비즈니스 수평적 확장(Scale-out) 시 개발/배포 리드타임 90% 극감
정량	중앙 통제기 죽으면 전사 파드 100개 올 스톱 (SPOF)	각자 핑퐁 치다 에러 난 파드 1개만 뒤지고 나머진 정상 생존	단일 장애점 제거로 시스템 전체 생존율(Resilience) 최고치 확보
정성	"오케스트레이터 팀 코드 리뷰 통과해야 배포할 수 있음 ㅠㅠ"	"내 맘대로 큐 구독해서 기능 추가하면 되네 개꿀 ㅋ"	마이크로서비스 팀 간 조직적 사일로 파괴 및 완벽한 애자일 독립성 달성

미래 전망

Event-Driven Architecture (EDA)의 글로벌 정복: 코레오그래피는 그 자체로 EDA의 영혼이다. 단순히 사가 트랜잭션 롤백용을 넘어서, 회사 전체의 모든 데이터 흐름이 "API 호출(명령)" 중심에서 "이벤트 발행/구독(알림)" 중심으로 이동하는 거대한 아키텍처 대격변의 핵심 코어다. 마이크로서비스는 서로 명령하지 않는다. 그저 상태를 선언할 뿐이다.
오케스트레이션과의 하이브리드 대통합 (Choreo-Orchestration): 2025년 아키텍트들의 대세. "결제 ➡ 재고 ➡ 쿠폰"처럼 돈이 물린 핵심 3대장 로직은 중앙 지휘자가 멱살 잡는 오케스트레이터로 묶어 무결점 롤백을 치고, 결제가 다 끝난 뒤의 "영수증 메일 쏘기, AI 추천 서버에 로그 던지기, 통계 덤프 치기" 같은 쩌리 10개 앱들은 지휘자가 개입 안 하고 그냥 **코레오그래피(허공 이벤트 핑퐁)**로 쿨하게 찢어버리는 양동 작전(Hybrid Saga)이 대기업 클라우드의 교과서로 자리 잡았다.

참고 표준

Martin Fowler의 Saga Pattern 리뷰: 마틴 파울러 성님이 "사가 패턴엔 코레오그래피랑 오케스트레이션 2개 있는데, 코레오그래피 멋지다고 무지성 도입하다 복잡성에 대가리 다 깨지니까 처음엔 오케스트레이션으로 시작해라!"라고 뼈를 때린 클라우드 아키텍처 바이블.
Apache Kafka: 코레오그래피 생태계를 혼자서 전 세계 100% 장악한 메세지 브로커 황제. 카프카의 초당 100만 건 처리 속도가 없었다면 코레오그래피 사가는 속도 저하로 이미 멸종했을 것이다.

코레오그래피 사가 (Choreography Saga)는 소프트웨어 공학이 도달한 **'통제에 대한 혐오'와 '절대 자유주의(Decoupling)의 미학'**이다. 개발자들은 중앙에 뚱뚱한 신(God Object)을 세우고 결합당하는 낡은 2PC와 ESB의 악몽을 치떨리게 증오했다. 그들은 50개의 마이크로서비스가 오직 '과거의 사실(이벤트)'만을 허공에 선언하고, 그 파문을 읽어낸 옆 서버가 묵묵히 자기 일을 이어가는 낭만적인 연쇄 작용의 우주를 창조했다. 명령(Command)은 억압적이고 동기적(Sync)이며 상대를 옭아매지만, 이벤트(Event)는 선언적이고 비동기적(Async)이며 상대를 해방시킨다. 하지만 그 극단적 해방의 대가는 잔혹했다. 보이지 않는 거미줄처럼 핑퐁 치는 이벤트들은 추적 불가능한 스파게티 지옥(Unobservability)을 낳았고, 결국 비즈니스는 스스로 싼 똥(보상 트랜잭션 환불)을 눈치껏 각자 치워야 하는 치열한 각자도생의 정글로 변모했다. 아키텍트는 낭만에 취해선 안 된다. 서비스가 2~3개일 땐 이 빛의 속도와 자유를 마음껏 누리되, 비즈니스의 사슬이 4개를 넘어가 거대한 용으로 자라나는 순간, 과감히 코레오그래피의 환상을 도끼로 깨부수고 중앙 지휘자(Orchestrator)의 목줄을 채울 수 있는 냉혹한 밸런싱 타협안, 그것만이 마이크로서비스가 불타오르지 않게 지키는 유일한 방파제다.

📢 섹션 요약 비유: 코레오그래피는 **'가족 단톡방(Kafka)에 던지는 한 마디'**와 같습니다. "엄마 나 밥 먹었어!(이벤트)" 라고 단톡방에 던지면, 아빠는 그걸 읽고 내 그릇을 치우고, 동생은 그걸 읽고 "아 그럼 내 간식은 내가 먹어야지" 하고 각자 움직입니다. 내가 "아빠 그릇 치워! 동생 간식 먹어!"라고 멱살 잡고 명령(API 호출)하지 않아도 집안일(트랜잭션)이 착착 돌아가는 눈부신 자율성과 민첩성의 극치입니다. 단, 톡방 인원이 100명이 넘어가면 누가 무슨 톡을 보고 움직였는지 개판 1분 전이 되어버리죠.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
오케스트레이션 사가 (Orchestrator)	코레오그래피의 빛이자 그림자. 코레오그래피 스파게티 지옥에 쳐 맞은 아키텍트들이 결국 눈물을 흘리며 중앙 지휘자 대빵 서버를 파서 회귀하게 되는 1티어 뇌 구조. (이전 장 552번 연계)
사가 패턴 (Saga Pattern)	코레오그래피 사상의 거대한 뿌리. 락(Lock)을 걸지 않고 앞으로 가다 에러 나면 환불 큐를 날려 보상(Compensation)을 친다는 베이스 원칙은 코레오든 오케스트레이션이든 100% 똑같이 쓴다. (이전 장 550번 연계)
이벤트 주도 아키텍처 (EDA)	코레오그래피는 EDA의 훌륭한 실전 적용 사례. REST API로 동기식(Sync) 점대점 찌르기를 파괴하고, 허공에 이벤트(Async)를 던지는 사상 자체가 EDA 그 자체다. (이전 장 538번 연계)
스파게티 코드 결합 (Spaghetti)	코레오그래피를 10개 이상 서비스에 무지성으로 발랐을 때 닥쳐오는 최후. 누가 이벤트를 쏘고 줏어먹는지 회사 전체에 아는 사람이 단 1명도 없는 전사적 안티패턴.
분산 트레이싱 (Zipkin, Jaeger)	코레오그래피 스파게티 지옥에서 개발자 목숨을 살려주는 유일한 동아줄. 헤더에 `Trace_ID`를 안 박아두면 핑퐁 치다 에러 났을 때 디버깅 불가능해서 100% 퇴사함. (이전 장 526번 연계)

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

학교에서 급식을 먹을 때, 선생님(중앙 지휘자)이 **"1번 먹어! 2번 숟가락 놔! 3번 국 떠!"**라고 일일이 명령하는 게 '오케스트레이션'이에요. 엄청 숨 막히죠.
하지만 **'코레오그래피'**는 선생님이 없어요. 1번 친구가 밥을 푸고 숟가락을 딱 놓으면 찰칵 소리(이벤트)가 나고, 그걸 들은 2번 친구가 눈치껏 국을 뜨고, 3번 친구가 밥을 먹는 자율 릴레이 게임이에요!
옆 친구한테 "나 다 했어"라고 말할 필요도 없이 그냥 찰칵 소리만 듣고 자기 할 일만 슉슉 빠르게 해치우는 짱 자유롭고 빠른 컴퓨터들의 마법 릴레이 방법을 '코레오그래피 사가'라고 부른답니다!