531. 클라우드 네이티브 아키텍처 (Cloud Native Architecture) 철학

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

1. 본질: 클라우드 네이티브 아키텍처(Cloud Native Architecture)는 단순하게 "우리 서버 AWS 샀어!"라고 자랑하는 렌탈(Hosting) 개념이 아니다. "서버는 언제든 죽을 수 있는 소모품(가축)이다"라는 철학 아래, 앱을 잘게 찢고(MSA), 컨테이너(Docker)로 감싸 1초 만에 복제하며, 모든 인프라를 코드(IaC)로 쥐고 흔드는 '구름(Cloud) 환경에 태생적으로 최적화된 새로운 진화 생명체'를 창조하는 사상이다.
2. 가치: 1,000만 명이 몰리는 블랙프라이데이에도 서버가 뻗지 않고(Auto-scaling), 하루에 100번씩 신기능을 배포해도 에러가 나지 않는(CI/CD) **궁극의 비즈니스 민첩성(Agility)과 회복 탄력성(Resilience)**을 기업에 부여하여, 거대 IT 공룡들을 누르고 스타트업이 세상을 지배할 수 있는 속도전의 코어 무기를 제공한다.
3. 융합: 이 위대한 헌법은 **마이크로서비스(MSA), 데브옵스(DevOps), 컨테이너(K8s), 불변 인프라(Immutable Infrastructure)**라는 4개의 바퀴가 하나의 엔진으로 완벽하게 융합될 때만 굴러가며, 이 중 하나라도 빠진 클라우드는 껍데기만 빌려 쓰는 낡은 모놀리식(Monolithic) 고철 덩어리에 불과하다.

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

• 개념: 클라우드 네이티브(Cloud Native)는 '구름(클라우드)'에서 '태어난(Native)'이라는 뜻이다. 옛날에는 프로그램(앱)을 짤 때 "우리 회사 지하실에 있는 안 꺼지는 엄청 튼튼한 슈퍼컴퓨터"를 기준으로 짰다(온프레미스). 네이티브는 아예 뇌 구조가 다르다. **"내 앱을 돌리는 서버는 누군가의 마우스 클릭이나 장애로 5분 뒤에 갑자기 흔적도 없이 터져 죽을 수 있다"**를 전제로 코드를 짠다. 언제든 죽고, 언제든 1만 개로 복제되어 살아나는 분산 환경의 DNA를 이식하는 것이다.

• 필요성: 기존 방식(모놀리식)으로 짠 은행 앱을 그대로 AWS(클라우드)에 올렸다고 치자(Lift and Shift). 갑자기 트래픽이 10만 명 몰려서 AWS 서버가 10대로 자동 복제(Scale-out)되었다. 그런데 옛날 앱은 로그인한 사람의 세션(상태)을 자기 혼자 메모리에 꽉 쥐고 있는 구조(Stateful)라, 2번 서버로 접속된 사람은 로그인이 풀려버리는 미친 에러가 났다. "단순히 서버를 남의 집(클라우드)으로 이사 가는 게 능사가 아니다. 그 남의 집(분산 확장 환경)에서 미친 듯이 춤출 수 있게 앱의 뼈대와 체질(Architecture) 자체를 완벽하게 무상태성(Stateless)과 조립식으로 뜯어고치지 않으면 회사는 파산한다." 이 뼈저린 교훈이 클라우드 네이티브라는 학문을 탄생시켰다.

• 💡 비유: 기존 온프레미스 개발은 **'거대한 분재(나무) 화분 키우기'**입니다. 화분이 조금이라도 깨지거나 물을 덜 주면 거대한 나무 1그루가 통째로 죽어버립니다(단일 장애점). 화분을 들고 이사 가기도 너무 무겁습니다. 클라우드 네이티브는 **'1만 마리의 개미떼 군단'**입니다. 개미 몇 마리(서버)를 발로 밟아 죽여도, 여왕개미(K8s 컨트롤러)가 1초 만에 알을 낳아 즉시 1만 마리로 복구시킵니다. 이사 갈 때는 개미들이 각자 알아서 구멍을 타고 새로운 집(다른 클라우드 벤더)으로 1분 만에 쪼르륵 이동해 그곳에서 다시 1만 마리의 형태를 완벽하게 조립해 냅니다. 군단의 생명력은 개체 1마리에 의존하지 않습니다.

• 등장 배경 및 발전 과정:

  1. 가상머신(VM)과 클라우드의 탄생 (2000년대 후반): AWS가 하드웨어를 가상으로 쪼개 팔기 시작했다. 이때는 그냥 낡은 코드를 서버만 빌려서 올렸다(IaaS). 비효율의 극치였다.
  2. 12-Factor App 헌법 제정 (2011): Heroku 엔지니어들이 "클라우드에서 앱이 예쁘게 돌려면 이 12개 룰(설정 분리, 무상태 등)을 무조건 지키며 코딩해라!"라고 선포하며 클라우드 최적화 코딩의 바이블을 세웠다.
  3. CNCF(Cloud Native Computing Foundation) 결성 (2015): 구글이 도커(Docker)를 지휘하는 쿠버네티스(K8s)를 오픈소스로 풀면서, 전 세계 기업들이 "모든 시스템을 쪼개고(MSA) 컨테이너로 감싸서 배포(CI/CD)하는 생태계"로 천하를 통일했다.

• 📢 섹션 요약 비유: 클라우드 네이티브는 **'레고 블록(Lego)으로 성벽 쌓기'**입니다. 옛날 성(모놀리식)은 시멘트를 부어서 통째로 굳혔기 때문에, 대포를 맞아 벽 한쪽이 깨지면 성을 다 부수고 처음부터 다시 지어야 했습니다. 클라우드 네이티브 성은 작은 레고 조각(마이크로서비스) 수만 개로 끼워져 있어서, 대포를 맞아 조각 100개가 날아가도, 로봇(K8s)이 똑같은 레고 조각 100개를 가져와 1초 만에 그 자리에 끼워 넣어(Auto-healing) 언제나 완벽한 성의 모습을 유지하는 미친 회복력의 마술입니다.

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

1. 클라우드 네이티브의 4대 핵심 기둥 (CNCF 4대 뼈대)

아키텍트가 무인도에 가더라도 이 4개는 챙겨서 설계도를 짜야 한다.

1. 마이크로서비스 (Microservices Architecture, MSA)
   • 100만 줄짜리 뚱뚱한 코드 덩어리를 '결제', '주문', '검색' 등 50개의 작은 조각으로 갈기갈기 찢는다. 결제팀은 파이썬으로, 검색팀은 자바로 각자 맘대로 짜고 서로 간섭하지 않는다.
2. 컨테이너 (Containers)
   • 찢어놓은 50개의 작은 앱을 각자 '도커(Docker)'라는 독립된 깡통에 담아 밀봉한다. 이 깡통은 내 노트북에서 돌리든, AWS에서 돌리든, 구글 클라우드에서 돌리든 100% 똑같은 환경으로 1초 만에 실행된다(이식성 끝판왕).
3. 데브옵스 및 CI/CD 파이프라인 (DevOps & Continuous Delivery)
   • 50개의 깡통을 사람이 마우스로 서버에 올리면 밤샌다. 개발자가 git push 버튼을 누르는 순간, 기계(Jenkins/ArgoCD)가 알아서 검사하고 깡통으로 빚어내어 라이브 서버로 던져버리는 "인간 없는 자동화 컨베이어 벨트"다.
4. 선언형 인프라 (IaC, Infrastructure as Code)
   • "서버 10대, DB 1대 띄워주세요"를 마우스 클릭으로 하지 않는다. 테라폼(Terraform) 코드로 resource "aws_instance" { count = 10 } 이라고 텍스트로 치고 실행한다. 내일 회사가 통째로 폭파돼도 이 텍스트 파일 1개만 있으면 5분 만에 인프라 전체가 100% 완벽히 똑같이 부활한다.

2. 클라우드 네이티브를 완성하는 궁극의 헌법: '12-Factor App'

12개 중 아키텍트가 밤마다 외워야 할 치명적 코어 3개.

• III. Config (설정을 코드에서 분리하라): DB_PASS=1234를 자바 코드에 박으면 클라우드 네이티브 탈락이다. 테스트 환경, 운영 환경 넘어갈 때마다 소스를 뜯어고칠 텐가? 코드는 가만히 두고, 환경 변수(.env)만 밖에서 주입받아라.

• VI. Processes (앱을 무상태/Stateless 프로세스로 실행하라) 💥 가장 중요: 유저가 장바구니에 담은 데이터를 내 서버 메모리(RAM) 변수에 쥐고 있지 마라. 서버는 5분 뒤 오토스케일링으로 죽을 놈이다. 모든 상태(데이터)는 내 뱃속이 아니라 바깥에 있는 **Redis나 DB(Stateful Backing Service)**에 저장하고 내 뇌를 하얗게 비워둬야 서버가 1만 대로 늘어나도 병목이 안 생긴다.

• IX. Disposability (폐기 가능성: 빨리 켜지고 우아하게 죽어라): 서버가 부팅되는 데 10분 걸리면 트래픽 몰릴 때 다 죽는다. 1초 만에 켜져야 한다. 그리고 K8s가 "너 죽어!"라고 SIGTERM 신호를 보내면, 진행 중이던 결제만 딱 깔끔하게 10초 내로 끝내고 우아하게 짐 싸서 죽어줘야(Graceful Shutdown) 데이터가 안 찢어진다.

• 📢 섹션 요약 비유: 클라우드 네이티브 4대 기둥은 **'현대식 프랜차이즈 햄버거 공장'**입니다. 고기, 빵, 야채를 따로 굽는 'MSA' ➡ 구운 걸 상자에 깔끔하게 담는 '컨테이너' ➡ 버튼 누르면 벨트 타고 손님한테 바로 나가는 'CI/CD' ➡ 공장이 불타도 레시피 종이 한 장으로 내일 당장 똑같은 식당을 차릴 수 있는 **'IaC'**입니다. 이 시스템 덕분에 맥도날드(클라우드 앱)는 전 세계 어디서나 똑같은 맛과 미친 스피드를 유지할 수 있습니다.

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

1. 낡은 모놀리식(Monolithic) vs 클라우드 네이티브 (Cloud Native)

사장님이 "돈 들여서 왜 네이티브로 갈아엎어?"라고 물을 때 꺼내는 철퇴.

과목 융합 관점

• 소프트웨어 공학 (사이버 레질리언스와 서킷 브레이커): 클라우드는 물리적으로 장애가 밥 먹듯이 난다. 네이티브 아키텍트는 519장에서 배운 **레질리언스(회복 탄력성)**를 뼈대에 녹인다. A 서비스가 B 서비스에 통신을 10번 날렸는데 대답이 없으면 11번째는 안 날리고 회로를 끊어버리는 '서킷 브레이커(Circuit Breaker)' 패턴이 필수다. 이 끊어진 찰나 동안 뻗은 B를 죽여버리고 쿠버네티스가 새 B를 살려낸다. 죽음과 부활을 물 흐르듯 유연하게 넘기는 융합 기술이다.

• 데이터베이스 (사가 패턴, Saga Pattern의 피눈물): 클라우드 네이티브(MSA)의 유일하고도 가장 끔찍한 단점이다. 옛날엔 오라클 DB 하나 썼으니 결제하다 에러 나면 Rollback 1줄 치면 돈이 원상 복구됐다(ACID). MSA는 결제팀 DB와 재고팀 DB가 물리적으로 찢어져 있다. 결제는 됐는데 재고가 없어서 에러가 났다? 찢어진 DB는 롤백이 안 된다! 아키텍트는 이를 구원하기 위해 "야 결제 취소해라!"라는 보상 트랜잭션(Compensation) 이벤트를 카프카(Kafka) 큐에 던져 뒷수습을 하는 사가(Saga) 패턴이라는 지독한 데이터 정합성 융합 아키텍처를 도입해야만 시스템이 찢어지지 않고 유지된다.

• 📢 섹션 요약 비유: 모놀리식은 100명이 같이 타는 **'100인용 초거대 자전거'**입니다. 바퀴 하나 빠지거나 한 명 화장실 가면 100명이 싹 다 멈춰서 기다려야 합니다(유연성 제로). 클라우드 네이티브는 100명이 각자 타는 **'1인용 킥보드 100대 군단'**입니다. 한 명이 넘어져서 킥보드가 부서져도(장애), 남은 99명은 무시하고 목적지로 쌩쌩 달려가며, 부서진 1명은 트럭(K8s)이 1초 만에 새 킥보드를 리필해 주어 바로 합류하는 완벽한 독립성의 마술입니다.

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

실무 시나리오

1. 시나리오 — 무늬만 클라우드(Cloud Washing), 스케일 아웃이 불가능한 좀비 서버: 임원진이 "우리도 클라우드 도입했다!"고 자랑했다. IDC(사내 서버)에 있던 수백 기가짜리 자바(Java) 웹 서버 앱을 그대로 압축만 해서 AWS EC2에 통째로 올렸다(Lift and Shift). 블랙프라이데이 날 트래픽이 폭주했다. AWS의 오토스케일링이 작동해 서버 10대가 똑같이 켜졌다. 그런데 사용자들이 로그인하면 자꾸 풀리고 장바구니가 날아갔다. 앱이 메모리에 세션(Session)과 파일 캐시를 들고 있는 구식(Stateful) 상태였기 때문에, 로드밸런서가 유저를 2번 서버로 토스하는 순간 그 유저는 처음 온 생판 남(세션 불일치) 취급을 받은 것이다.

   • 아키텍트의 해결책: 무상태성(Stateless) 철학 붕괴에 따른 클라우드 파탄이다. 클라우드에 띄웠다고 네이티브가 아니다. 아키텍트는 12-Factor App의 6원칙(무상태)을 멱살 잡고 강제해야 한다. 서버 메모리에 쌓이던 '유저 로그인 세션'과 '임시 이미지 파일'을 싹 다 뜯어내어, 서버 외부의 절대 공간인 **Redis(인메모리 세션 군집)**와 **AWS S3(오브젝트 스토리지)**로 100% 분리(Externalize)시켜 버려야 한다. 그래야 서버가 1만 대로 늘어나든 1초 만에 찢어져 죽든, 유저 정보는 밖(Redis)에 안전하게 모셔져 있어 아무런 문제 없이 스케일 아웃의 광속을 뿜어낼 수 있다.

2. 시나리오 — 마이크로서비스(MSA)의 역습, 분산 지옥과 원인 불명 에러: 모놀리식을 부수고 MSA 서버 50개로 예쁘게 찢어놨다(아키텍트의 로망). 고객이 "결제 버튼 눌렀는데 하얀 화면만 뜨고 멈췄어요"라고 클레임을 걸었다. 개발자가 로그를 까보려는데, 결제(A)가 주문(B)을 찌르고 재고(C)를 찌르고 쿠폰(D) 서버를 찔렀다. 50대의 서버 로그가 각자 100만 줄씩 터져 나와서 도대체 C 서버에서 죽은 건지 D 서버가 뻗은 건지 디버깅이 불가능했다. 원인 찾는 데 3일이 걸려 회사가 망할 뻔했다.

   • 아키텍트의 해결책: 분산 가시성(Observability) 및 추적(Tracing) 인프라 부재의 비극이다. MSA를 찢는 건 쉽지만, 찢어진 걸 꿰뚫어 보는 눈(Eye)이 없으면 지옥이다. 아키텍트는 MSA를 찢기 전에 무조건 **'분산 트레이싱(Distributed Tracing, 예: Jaeger, OpenTelemetry)'**을 스프링 필터 뼈대에 박아 넣어야 한다. 유저가 결제를 누르는 정문 입구에서 Trace-ID: 999 라는 야광 꼬리표 1개를 콱 찍고, 이 꼬리표가 A➡B➡C➡D 50대 서버 패킷을 돌아다닐 때 무조건 같이 묻어서 릴레이 되게 만들어야 한다. 나중에 키바나(Kibana) 검색창에 999만 치면 50대 서버에 흩뿌려진 로그가 1초 만에 1개의 타임라인 족보로 쫙! 합쳐져 나와 "아 C 서버 34번 줄이 터졌네"라고 1분 만에 핀셋 적발하는 우주적 가시성을 확보해야 살아남는다.

도입 체크리스트

• 비즈니스적: "우리의 비즈니스 변경 속도가 과연 MSA를 감당할 만큼 빠른가?" 주니어 개발자들이 "우아한 형제들도 MSA 쓴대요! 우리도 갈라치죠!"라고 떼를 쓴다. MSA는 공짜가 아니다. 분산 트랜잭션, CI/CD 구축, K8s 운영 인건비로 서버 요금과 엔지니어 몸값이 3배로 뛴다. 만약 우리 회사의 앱이 1달에 1번 기능이 추가되는 느긋한 시스템(예: 사내 인사시스템)이라면, 절대 클라우드 네이티브(MSA)로 찢지 말고 하나의 뚱뚱한 **'모듈식 모놀리스(Modular Monolith)'**로 예쁘게 뭉쳐두는 것이 비즈니스 ROI를 살리는 천재적 용단이다. MSA는 하루에 100번 배포해야 살아남는 미친 생존 경쟁(B2C 커머스 등)에서만 빼드는 마검이다.
• 기술적: 인프라 자체가 불변성(Immutability)을 띠고 있는가? 라이브 서버에 버그가 터졌다. 시니어 개발자가 SSH로 리눅스 운영 서버에 다이렉트로 접속해, 터미널에서 vi 편집기를 열고 코드를 슥 고친 뒤 재시작해서 고쳤다(영웅 놀이). 클라우드 네이티브에서 이 짓거리는 해고 사유다. 라이브 환경을 손으로 직접 건드리면(Snowflake Server), 서버 100대의 상태가 짝짝이가 되어 환경이 썩어 들어간다(Configuration Drift). 아키텍트는 운영 서버 접속 포트 자체를 닫아버리고, 버그가 났으면 로컬에서 코드를 고치고 git push를 때려서 젠킨스가 **"기존 오염된 서버를 사살(Kill)하고 아예 100% 멸균된 새 도커 컨테이너를 복제해 던져 넣는 불변 인프라(Immutable) 교체"**만을 100% 강제 수단으로 락(Lock)을 걸어야 한다.

안티패턴

• "분산된 모놀리스 (Distributed Monolith)의 끔찍한 잡종": 가장 슬프고 가장 흔한 클라우드 네이티브 실패작. 사장님이 MSA로 찢으라고 해서 코드만 껍데기로 서버 10개로 찢어놨다. 그런데 **"데이터베이스(DB)는 돈 드니까 1개 통짜(Oracle)로 놔두고 서버 10대가 다 같이 그 DB 하나에 붙어 쓰자!"**라고 합의해 버렸다. 결과는? B팀이 DB 테이블 컬럼명 하나 바꿨더니 서버 10대가 동시에 다 뻗어버렸다. "진정한 마이크로서비스는 코드만 찢는 게 아니라, 피를 토하더라도 각 서비스마다 완전히 독립된 10개의 쪼꼬만 DB(Database per Service)를 따로 파서 영원히 단절(Decoupling)시켜야만 물리적 독립이 완성된다."

• 📢 섹션 요약 비유: 분산 모놀리스(DB 공유)는 **'다리에 쇠사슬을 묶은 채 각자 도망가는 10명의 죄수들'**과 같습니다. 방은 10개로 나눠 썼지만 밥(DB)을 한 그릇에 비벼 먹다 보니, 한 놈이 설사(DB 락이나 스키마 변경)를 하면 10명 전원이 다 같이 배탈이 나서 쓰러집니다. 진정한 클라우드 네이티브는 각자 독립된 방에서 자기 전용 도시락(독립 DB)만 까먹고, 소통은 오직 창문 너머로 쪽지(API/Event)를 던지면서 100% 완벽하게 분리된 1인 가구 시스템을 만드는 독한 개인주의입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 서버리스(Serverless)의 완전한 영토 침공: 지금은 쿠버네티스(K8s)와 컨테이너가 짱이다. 하지만 K8s는 인프라 셋업이 지옥처럼 어렵다. 5년 뒤엔 아예 K8s라는 껍데기 인프라마저 잊혀질 것이다. 개발자가 그저 자바 함수 1개(함수 10줄)를 클라우드에 툭 던져두면, 1초 만에 트래픽이 0건이면 서버가 아예 0대로 사라져(요금 0원) 증발하고, 10만 명이 몰리면 0.01초 만에 허공에서 10만 개의 함수가 튀어나와 쏘고 다시 증발해 버리는 서버리스(AWS Lambda, FaaS) 아키텍처가 "인프라를 1도 몰라도 되는 궁극의 클라우드 네이티브"로 생태계를 먹어 치울 것이다.
• 분산 클라우드의 통일과 서비스 메시(Service Mesh) 블랙홀: 50개로 찢어놓은 서버들의 통신망(암호화, 로깅, 재시도, 인증) 코드를 짜다 개발자들이 죽어 나갔다. 미래의 앱(App) 내부 소스코드에는 보안/통신 로직이 1바이트도 존재하지 않게 된다. 오직 비즈니스(돈 버는 로직)만 남는다. 그 앱의 바깥 허공(사이드카/eBPF 커널)에서 이스티오(Istio) 같은 '서비스 메시' 인프라 망이 투명하게 감싸고돌며, 개발자가 모르는 사이에 지들끼리 암호화(mTLS)하고, 차단하고, 로깅하는 극강의 인프라 레벨 은닉형(Transparent) 아키텍처가 전 세계 클라우드를 지배 중이다.

참고 표준

• 12-Factor App (열두 가지 팩터 앱): "클라우드에서 예쁘게 춤추고 싶으면 이 12개 규칙을 네 영혼에 박아라!" Heroku 엔지니어들이 쓴, 모든 클라우드 아키텍트 지망생이 성경처럼 매일 밤 읽고 회개해야 하는 절대 율법. (상태 분리, 설정 분리, 포트 바인딩 등)
• CNCF (Cloud Native Computing Foundation): 쿠버네티스를 필두로, 전 세계 클라우드 생태계(프로메테우스 모니터링, 엔보이 프록시 등)의 표준 오픈소스를 인큐베이팅하고 인증 마크를 박아주는 21세기 IT 생태계의 절대 권력 기구.

클라우드 네이티브 아키텍처(Cloud Native Architecture) 철학은 소프트웨어 공학이 **'불로장생(영원히 죽지 않는 완벽한 서버)이라는 낭만적 미신을 포기하고, 끊임없이 죽고 폭발하며 초당 수만 번 파괴와 부활을 반복하는 윤회의 매트릭스 속으로 자발적으로 투항한 가장 위대한 진화'**다. 과거 아키텍트의 임무가 서버 1대를 1년 동안 안 죽게 어루만지는 '애완동물(Pet) 사육사'였다면, 지금의 아키텍트는 1만 대의 서버가 1초 만에 벼락을 맞아 소멸되더라도 비즈니스는 단 1초도 멈추지 않고 허공에서 똑같은 1만 대의 클론(Cattle)을 스르륵 연성해 내는 무자비한 생태계의 '조물주'가 되어야 한다. 우리는 시스템을 가장 잘게 찢고(MSA), 가장 가볍게 가두고(컨테이너), 가장 빠르게 파괴하고 재생시킴(CI/CD)으로써 오히려 우주 최고의 불멸성(Resilience)을 획득했다. 죽음을 껴안아 불멸을 창조하는 마술, 무(無)의 상태(Stateless)를 지향하여 무한의 속도(Scale)를 뽑아내는 철학. 그것이 구름(Cloud) 너머에 100억의 달러를 쌓아 올리는 글로벌 엔터프라이즈의 찬란한 심장 박동이다.

• 📢 섹션 요약 비유: 클라우드 네이티브는 전장의 **'무적 아메바 부대'**와 같습니다. 옛날 모놀리식은 거대한 '코끼리 1마리'였습니다. 힘은 세지만 대포 한 대 맞고 다리가 부러지면 코끼리는 쓰러져서 죽습니다(서버 셧다운). 클라우드 네이티브는 '작은 아메바 1만 마리 뭉치(MSA)'입니다. 적군이 대포를 쏴서 아메바 1,000마리가 죽어도(10% 서버 장애), 나머지 9,000마리는 0.1초 만에 세포 분열(오토 스케일링)을 미친 듯이 일으켜 다시 1만 마리의 완벽한 몸집으로 복원해 내어 적진을 뚫고 들어갑니다. 파괴를 양분으로 삼아 증식하는, 물리적으로 죽일 수 없는 불멸의 군단 설계입니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 옛날엔 엄청 크고 무거운 '통짜 로봇 장난감' 1개를 썼어요. 팔 하나만 고장 나도 장난감 전체를 버리고 며칠 동안 수리 센터에 맡겨야 해서 너무 슬펐죠. (모놀리식 서버)
2. 그래서 똑똑한 박사님이 장난감을 **'100개의 쪼꼬만 레고 조각 로봇들'**로 찢어서 합체시켰어요! (클라우드 네이티브 / MSA)
3. 이제 팔 조각 로봇 하나가 부서져도 끄떡없어요. 옆에 있는 마법 복사기가 부서진 조각을 버리고 1초 만에 100% 똑같은 새 팔 조각을 쾅 찍어내서 촥! 붙여주니까, 로봇은 1년 365일 안 멈추고 춤을 출 수 있게 된 기적의 발명품이랍니다!