532. 마이크로서비스 (Microservices) 분해 패턴

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

1. 본질: 마이크로서비스 분해 패턴(Decomposition Pattern)은 수백만 줄의 코드가 한 덩어리로 엉겨 붙은 거대 모놀리식(Monolithic) 괴물을, 무작정 난도질하는 것이 아니라 결합도(Coupling)는 찢어발기되 응집도(Cohesion)는 뭉치게 하여, 독립적으로 배포 가능하고 지들끼리 멱살 잡고 싸우지 않는 50개의 작고 우아한 자율 부대(Service)로 정밀 해부하는 외과 수술 기법이다.
2. 가치: "결제팀 코드를 고치다 게시판이 뻗어버리는" 끔찍한 나비효과를 원천 박살 낸다. 팀(Team)과 서버(Service)의 크기를 1:1로 일치시켜, 각 5명짜리 소규모 팀들이 다른 팀 눈치를 1도 보지 않고 하루 100번씩 미친 속도로 독립 배포(Agility)를 갈길 수 있는 속도전과 거버넌스의 절대적 독립성을 선사한다.
3. 융합: 이 칼질은 단순히 코드 폴더만 나누는 헛짓거리가 아니다. **'비즈니스 능력(Business Capability)'**에 따른 도메인 분해, DDD(도메인 주도 설계)의 Bounded Context(제한된 문맥) 사상과 완벽하게 융합되어, DB 50개까지 물리적으로 철저히 찢어버리는 극한의 Database-per-service(서비스당 1 DB) 인프라 아키텍처로 피어난다.

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

• 개념: 모놀리스는 짬짜면이다. 짜장면과 짬뽕 국물이 섞이지 않게 철판(메소드)으로 막아놨지만 한 그릇에 붙어있다. 마이크로서비스(MSA)는 짜장면과 짬뽕을 아예 '각자 다른 주방장의 다른 그릇(독립된 프로세스, API)'으로 100% 물리적으로 찢어내는 것이다. 분해 패턴(Decomposition)은 그 짬짜면을 자를 때 "어디를 기준으로 칼집을 넣어야 국물이 넘치거나 면이 섞여 양쪽 다 망하는(장애 전파) 대참사를 막을 수 있을까?"를 연구하는 수학적 칼질 룰이다.

• 필요성: 쿠팡 같은 앱이 1개의 소스코드 덩어리(모놀리식)로 되어있다고 치자. 검색팀이 로직 1줄 고치고 컴파일(빌드)하는 데 1시간이 걸린다. 배포할 때 결제팀, 배송팀 수십 명이 모여서 덜덜 떨며 에러가 날까 봐 기도한다(Agility 사망). 심지어 블랙프라이데이에 결제 트래픽만 폭주했는데, 쓸데없는 리뷰 서버와 검색 서버까지 100대 통째로 복제해야 해서 서버비 수억 원이 날아간다(Scalability 낭비). 괴물을 쪼개지 않으면 속도에 치여 죽고 돈에 치여 파산한다. 살기 위해선 시스템을 가장 독립적인 미니 심장(Microservice) 50개로 완벽히 쪼개서 각자 스스로 박동하게 해야 하는 필연성이 MSA라는 시대를 강제 소환했다.

• 💡 비유: 마이크로서비스 분해는 **'거대한 원룸 아파트를 50세대의 독립 오피스텔로 쪼개는 공사'**와 똑같습니다. 옛날 원룸(모놀리식)은 화장실과 주방을 다 같이 썼습니다. 한 명이 화장실 변기를 막히게(메모리 릭 에러) 하면 50명 전원이 똥을 못 싸서 죽습니다(전체 시스템 셧다운). 훌륭한 건축가(아키텍트)는 칼을 듭니다. 각 세대(Microservice)마다 벽을 두껍게 치고, 독립적인 미니 화장실과 주방(Database per service)을 개별적으로 달아줍니다. 이제 301호 변기가 터져도, 302호와 303호는 아주 평화롭게 장사를 계속할 수 있는(장애 격리) 극한의 생존술입니다.

• 등장 배경 및 발전 과정:

  1. 모놀리식의 영광 (2000년대): 코드가 수만 줄일 땐 한 통에 넣고 짜는 게 최고로 빠르고 디버깅하기도 좋았다.
  2. 아마존/넷플릭스의 딜레마 (2010s): 코드가 수백만 줄을 돌파했다. 개발자 1,000명이 똑같은 Git 코드 저장소에 Push 하다가 서로 충돌(Merge Conflict)이 나며 회사가 멈췄다. 제발 우리 각자 찢어져서 살자며 분할을 부르짖었다.
  3. 도커(Docker)와 분해 패턴의 완성 (현재): 찢어놓은 50개의 앱을 배포하는 게 지옥이었다. 하지만 도커(Container)가 등장하며 찢어진 앱들을 1초 만에 허공에 띄울 수 있게 되면서, DDD(Domain-Driven Design) 철학과 결합한 '완벽한 칼질(분해)의 룰'들이 글로벌 대세로 정착했다.

• 📢 섹션 요약 비유: 모놀리식은 **'몸이 하나인 머리 3개 달린 샴쌍둥이 괴물'**입니다. 뇌(팀)는 3개인데 몸(서버/DB)이 하나라 서로 가고 싶은 방향이 달라도 다리가 꼬여서 걷지도 못합니다. MSA 분해는 이 괴물의 몸뚱어리를 완벽하게 외과 수술로 썰어내어, **'3명의 각자 독립된 빠른 육상 선수'**로 탈바꿈시키고 각자의 전용 트랙(API)에서 자유롭게 뛰게 만드는 생존의 수술입니다.

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

1. MSA 분해의 두 가지 핵심 칼날 (어떻게 썰 것인가?)

고기(코드)를 썰 때, 결대로 썰지 않고 막 썰면 코드가 너덜너덜해진다. 아키텍트의 양대 산맥 분해법.

1. 비즈니스 능력에 따른 분해 (Decompose by Business Capability) 💥

   • 회사가 돈을 버는 "조직도"와 "기능"을 기준으로 수직으로 썰어버린다.
   • 예시: 쇼핑몰을 [주문 관리], [고객 관리], [재고 관리], [배송 관리] 라는 현실 세계의 부서(팀) 단위로 4등분 쫙 찢는다.
   • 장점: 가장 직관적이고 경영진이 이해하기 쉽다. (콘웨이의 법칙 적용)
   • (다음 장 533번에서 깊게 해부)

2. 하위 도메인에 따른 분해 (Decompose by Subdomain / DDD) 👑 궁극의 정답

   • 위 방식의 한계("야, '상품'이라는 데이터는 주문팀도 쓰고 재고팀도 쓰는데 이건 누가 가져가냐?")를 박살 내기 위해 에릭 에반스가 주창한 철학.
   • 비즈니스를 파고들어 **'제한된 문맥(Bounded Context)'**이라는 절대 방어막을 그린다.
   • "주문팀이 부르는 '상품(Order Item)'과 재고팀이 부르는 '상품(Stock Item)'은 이름만 같을 뿐 아예 핏줄이 다른 데이터다! 공용으로 쓰지 말고 각자 도메인 문맥에 맞춰서 DB를 아예 2개로 쪼개서 각자 들고 가라!"며 데이터의 중복을 허용하면서라도 완벽한 단절(Decoupling)을 쟁취하는 고도의 뇌지컬 분해법이다.

2. 칼질의 대원칙: 결합도는 낮추고, 응집도는 높여라 (Low Coupling, High Cohesion)

칼을 잘못 썰었을 때(분해 실패) 나타나는 지옥의 패턴들이다.

• 잘못된 분해 (Chatty Microservices 💥): 함수 1개를 짤 때 서버 A가 B를 부르고 B가 C를 부르게 너무 잘게 찢어놨다(Over-fragmentation). 네트워크를 10번이나 타느라(HTTP 지연) 성능이 모놀리식보다 100배 느려지고, 하나만 뻗어도 다 죽는다. (이른바 분산된 모놀리스 똥 덩어리)

• 올바른 분해 (High Cohesion 🛡️): 같이 자주 변하거나 묶여서 돌아가는 놈들(예: 결제 + 환불)은 찢지 말고 하나의 덩어리(Microservice)로 크게 뭉쳐둔다(응집도). 그리고 남(예: 리뷰 게시판)과는 오직 API(메시지)로만 느슨하게(Low Coupling) 대화하여, 결제를 뜯어고쳐도 리뷰 서버는 1도 영향을 안 받게 썰어내는 것이 외과 수술의 성패를 가른다.

• 📢 섹션 요약 비유: 코드를 써는 건 **'회사 부서 파티션 나누기'**와 같습니다. 마케팅팀과 영업팀(연관성 높음)을 다른 건물로 찢어놓으면(잘못된 쪼개기), 둘이 결재판 들고 택시 타고 왔다 갔다 하느라(네트워크 딜레이) 하루가 다 갑니다(Chatty). 진짜 천재 사장님(아키텍트)은 일 같이하는 놈들끼리(응집도) 한 방에 몰아넣어 문을 닫아주고, 다른 부서(결합도 낮춤)와는 오직 사내 메일(API)로만 소통하게 찢어놓는 공간 배치의 마법사입니다.

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

1. 분해의 가장 피 터지는 전장: Database 분리 (DB-per-Service)

코드 100개 찢는 건 1시간이면 하지만, DB를 찢는 건 영혼을 갉아 먹는 1년 치 전쟁이다.

과목 융합 관점

• 데이터베이스 (분산 트랜잭션, Saga 패턴의 융합): DB를 찢어놓는 순간 가장 위대한 객체지향 룰(ACID)이 박살 난다. 결제 DB에 돈을 뺐는데(성공), 재고 DB에서 물건을 빼려다(실패) 뻗었다. 옛날(통짜 DB)엔 Rollback 한 줄이면 1초 만에 돈이 원상 복구됐다. 찢어진 MSA 환경(네트워크 통신)에선 롤백이 안 된다! 아키텍트는 이를 구원하기 위해 **"야, 결제 서버! 방금 성공한 결제 다시 취소(환불)하는 로직 쏴!" 라는 보상 트랜잭션(Compensation)을 카프카(Kafka) 이벤트로 날리는 '사가 패턴(Saga Pattern)'**을 무조건 뼈대에 강제 융합시켜, 데이터의 정합성(Eventual Consistency)을 멱살 캐리해야만 시스템 붕괴를 막을 수 있다.

• 조직 공학 (콘웨이의 법칙, Conway's Law): "시스템의 아키텍처(설계도)는 그 회사의 조직도(조직 구조)를 그대로 복사하게 된다"는 전설의 법칙. 아키텍트가 코드를 기가 막히게 50개 MSA로 찢어놨어도, 회사 개발팀이 100명짜리 통짜(원팀) 부서라면 그 50개 코드는 결국 다시 하나로 떡져서(스파게티) 모놀리식이 되어버린다. 진정한 MSA 분해는 코드를 찢는 것에서 출발해, **"결제 코드를 짠 5명은 오늘부터 '결제 셀(Cell)' 스쿼드로 독립하고 사장님 보고 없이 맘대로 배포해라"라는 회사 조직도 자체의 분할(Cross-functional Team)**로 융합되어야만 100% 진정한 애자일 속도가 폭발한다.

• 📢 섹션 요약 비유: DB를 공유하는 가짜 MSA는, **'이혼 서류에 도장 찍고 남남이 됐는데(코드 분리), 돈이 아까워서 한집에서 냉장고(DB)를 같이 쓰는 부부'**와 같습니다. 매일 밤 냉장고 김치 냄새(스키마 변경) 때문에 피 터지게 싸웁니다. 진정한 MSA 분해는 이혼 후 각자 아파트를 전세 얻어 살고, 상대방 소식이 궁금하면 남의 집 냉장고를 열어보는(JOIN) 게 아니라 **'전화(API)'**를 걸어서 정중하게 물어보는 완벽한 물리적, 정신적 절단(DB-per-Service)입니다.

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

실무 시나리오

1. 시나리오 — 마이크로서비스 나노화(Nano-services) 뽕에 취한 대학살: MSA 책을 처음 읽은 주니어 개발자가 미쳐 날뛰며 1,000줄짜리 단순한 게시판 앱을 글쓰기 서버, 글읽기 서버, 댓글 서버, 좋아요 서버 등 10개로 갈기갈기 찢어놨다. 유저가 화면 1개를 띄우려는데, 프론트엔드가 이 10개 서버를 핑퐁으로 찌르느라 로딩에 3초가 걸렸다. 배포하려고 하니 도커 이미지 10개를 띄우느라 AWS 메모리가 펑 터져 서버 요금이 10배 폭증했다. 회사가 마비되었다.

   • 아키텍트의 해결책: 응집도(Cohesion)를 무시한 과도한 파편화(Over-decomposition)의 끔찍한 말로다. MSA는 작을수록 좋은 게 아니다. 아키텍트는 찢겨진 살점을 봉합해야 한다. "게시판과 댓글, 좋아요는 항상 1초 안에 묶여서 한 화면에 보여야 하는 완벽한 **도메인 응집 덩어리(Aggregate Root)**다!" 아키텍트는 10개 서버를 당장 1개의 게시판 서비스 깡통으로 뭉쳐(Merge) 네트워크 통신 비용(HTTP HTTP 오버헤드)을 내부 함수 호출(In-memory Call)로 바꿔버려 성능과 유지보수 지옥을 동시에 0초 컷으로 구원해 내야 한다. "찢는 것보다, 찢지 말아야 할 것을 하나로 묶는 게 진짜 아키텍트의 실력이다."

2. 시나리오 — '스트랭글러 피그(Strangler Fig)' 패턴, 레거시 괴물 사냥의 예술: 은행의 핵심 코어 뱅킹이 20년 된 1,000만 줄짜리 C/C++ 모놀리식이다. 툭하면 뻗어서 이걸 MSA로 갈아엎으려 한다. 신임 본부장이 "오늘부터 2년 동안 신기능 개발 멈추고 1,000만 줄을 싹 다 50개 MSA 서버로 재개발(Big Bang Rewrite) 하자!"고 선언했다. 2년 뒤 프로젝트는 버그 지옥에 빠져 실패하고 수백억을 날리며 본부장은 해고됐다.

   • 아키텍트의 해결책: 무지성 빅뱅 리라이트(Big-Bang Rewrite)의 전형적 자살행위다. 20년 된 레거시를 한 방에 끄고 켜는 건 러시안룰렛이다. 아키텍트는 무조건 **'스트랭글러 피그(교살자 무화과나무) 패턴'**을 꺼내야 한다. 기존 낡은 괴물(모놀리식)은 그대로 살려둔다. 그 앞에 API Gateway를 딱 1개 세운다. 그리고 가장 덜 중요한 꼬리(예: 이메일 발송 기능)만 딱 1개 뜯어내서 새로운 MSA 서버로 예쁘게 짠다. 게이트웨이에 룰을 건다. "이메일 요청이 오면 낡은 놈 말고 새 MSA 서버로 길을 틀어줘!" 낡은 괴물의 살을 한 점 한 점 베어내 새 서버로 옮기면서(Strangling), 2년 뒤 낡은 괴물은 껍데기만 남아 스르륵 숨을 거두게 만드는 가장 안전하고 점진적인 무중단(Zero Downtime) 해부 마술이다.

도입 체크리스트

• 비즈니스적: "팀이 10명 이하인가?" 그렇다면 절대 MSA를 찢지 마라! 구글이나 배민이 쓴다고 5명짜리 스타트업이 MSA 흉내를 내면 망한다. 분산 트랜잭션 잡고, 젠킨스 세팅하고, K8s 공부하느라 비즈니스 로직(돈 버는 코드)은 1줄도 못 짠 채 인프라 세팅하다 투자금 다 마르고 회사가 문 닫는다. 아키텍트는 스타트업 초기(MVP)엔 무조건 1통짜리 빠른 **'모놀리식(Monolithic)'**으로 제품을 런칭하여 시장을 뚫고 돈을 버는 데 100% 몰빵해야 한다. 팀원이 50명이 넘어가고, 코드 깃허브(Git) 충돌 때문에 멱살잡이가 일어나는 그 폭발의 임계점이 바로 MSA의 칼을 빼들 유일한 골든 타임이다. (Monolith First 원칙)
• 기술적: API 게이트웨이(API Gateway)와 BFF(Backend for Frontend)가 세팅되었는가? 백엔드를 50개로 찢어놓으면 모바일 앱(프론트엔드) 개발자가 죽어난다. 화면 1개 띄울 때 결제 서버, 이미지 서버, 유저 서버 50개로 통신을 날리면 핸드폰 배터리가 광탈하고 코드가 지옥이 된다. 아키텍트는 무조건 백엔드 50명 앞에 1명의 든든한 **API Gateway(문지기)**를 띄워줘야 한다. 모바일 앱은 이 문지기한테 "나 메인 화면 띄울래 데이터 줘" 딱 1번만 요청한다. 그러면 문지기가 뒤로 돌아서 50개 서버를 미친 듯이 찔러 데이터 조각을 모아 예쁜 1개의 JSON 상자로 묶어 모바일로 던져주는(Aggregation) 프론트엔드 맞춤형 방패(BFF)를 깔아두어야 분해의 파편화 부작용이 봉합된다.

안티패턴

• "데이터베이스는 하나로 묶고 코드만 찢을게요" (공유 데이터베이스의 저주): 앞서 설명한 MSA 최악의 자살폭탄(Distributed Monolith). 코드만 이쁘게 10개로 찢어놓고, DB 서버 살 돈 아깝다며 Oracle 1대에 테이블 100개를 다 때려 박은 뒤, 10개 서버가 다 같이 그 DB 하나에 빨대를 꽂아 쭉쭉 빨아먹게 둔다. 결과? 결제팀이 테이블 컬럼명 하나 바꿨더니, 게시판 서버, 유저 서버 10대가 "칼럼 못 찾음!" 에러를 뿜으며 연쇄 폭발하여 동시 셧다운 된다. "분해(Decomposition)의 1원칙: DB 스키마가 분리되어 네트워크 API로만 소통하지 않는 모든 분산 아키텍처는 그냥 속도만 100배 느려진 쓰레기 모놀리식 덩어리에 불과하다."

• 📢 섹션 요약 비유: 공유 DB를 쓰는 가짜 MSA는 **'프랜차이즈 식당의 본사 폭파'**와 같습니다. 전국 50개 지점(마이크로서비스)이 예쁘게 간판을 나눠 달았습니다. 그런데 요리(DB)는 각자 주방에서 안 하고, 서울 본사 1곳의 가마솥에서 끓여서 파이프로 쏴주게 묶어놨습니다. 본사 가마솥에 쥐약(스키마 변경/장애)이 1방울 떨어지면? 50개 전국 식당 손님들이 동시에 0.1초 만에 식중독에 걸려 즉사하는 최악의 단일 장애점(SPOF) 지옥입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Event-Driven Architecture (EDA)의 전면적 왕권 장악: 50개로 찢은 서버들이 서로 동기식(HTTP REST API)으로 찌르고 기다리면 결국 한 놈이 죽었을 때 연쇄적으로 기다리다 다 같이 죽는다(Time-out 붕괴). 미래의 분해 패턴 종착역은 100% **비동기 이벤트 주도(Event-Driven)**로 융합된다. 서버 A가 돈을 빼면 "나 돈 뺐다!"라고 허공(Kafka 큐)에 던지고 쿨하게 자기 갈 길(응답) 간다. B서버가 1시간 뒤에 일어나서 큐에서 줏어먹고 수습한다. 서버 50개가 서로 얼굴(IP)도 모르고 생사도 관심 없지만, 큐(Queue)라는 절대 우체국을 통해 궁극의 완벽한 헐거운 결합(Loose Coupling)으로 춤을 추는 불사조 생태계가 클라우드를 완전히 지배하고 있다.
• 분해의 귀환: 모듈식 모놀리스 (Modular Monolith)의 부활 선언: 미친 듯이 잘게 찢은 마이크로서비스(Nano-service)가 부른 인프라 유지보수 헬(Hell)에 전 세계 개발자들이 지쳤다. 아마존 프라임 비디오 팀조차 "MSA 찢었더니 인프라 요금만 90% 늘어서, 다시 1통짜리 서버로 합쳤더니 요금이 10배 줄었다!"라고 고백했다. 클라우드 고인물(아키텍트)들은 맹목적인 찢기(MSA)를 멈추고, 물리적 서버는 1개(모놀리스)로 띄워 요금을 아끼되, 내부 자바 코드는 완벽한 도메인(DDD) 경계로 찢어놔서 나중에 원하면 언제든 1초 만에 툭 떼서 MSA로 독립시킬 수 있는 영악한 타협안, **'모듈식 모놀리스(Modular Monolith)'**라는 하이브리드 황금비율로 거대하게 회귀(Return)하는 트렌드 시프트를 겪고 있다.

참고 표준

• Domain-Driven Design (DDD, 에릭 에반스): "마이크로서비스 도대체 어떻게 칼질해서 찢어야 해?"라는 피눈물 나는 질문에, "니들 DB 테이블 쳐다보지 말고, 기획자(현업)가 말하는 단어(Ubiquitous Language)와 문맥(Bounded Context)의 껍데기를 기준으로 찢어버려라!"라고 숟가락으로 입에 떠먹여 준 21세기 소프트웨어 아키텍처의 가장 위대하고 절대적인 성경책.
• Strangler Fig Pattern (교살자 무화과나무 패턴): 마틴 파울러 형님이 지은 이름. 낡은 레거시 나무(모놀리식)를 단번에 베어버리지 않고, 새싹(MSA)을 나무 기둥 겉에 빙빙 둘러 심어서 수년 동안 천천히 영양분(트래픽)을 빨아먹게 두면, 낡은 나무는 자연스럽게 말라 죽고 새 껍데기만 웅장하게 남는 완벽한 무중단 포팅(Migration)의 최고봉 전술.

마이크로서비스(Microservices) 분해 패턴은 소프트웨어 공학이 '거대하고 무거운 통제의 제국(모놀리식)'을 산산조각 내어, 수백 개의 눈부신 작은 별들(자율 조직)이 각자 스스로 빛을 내며 은하계(클라우드)를 이루게 만든 위대한 빅뱅(Big Bang)의 설계도다. 우리는 한때 코드를 100만 줄로 단단하게 뭉쳐놓는 것이 강함(Robustness)인 줄 알았다. 하지만 그 강함은 10억 명이 몰려드는 현대 인터넷의 미친 속도전(Agility) 앞에서 스스로의 무게에 짓눌려 붕괴하는 코끼리가 되었다. 기술사는 과감히 도끼를 들어야 한다. 살점(코드)과 뼈(DB)가 찢겨나가는 분산 환경의 고통(Transaction, Tracing 지옥)을 짊어지면서도, 기어이 비즈니스의 핏줄을 도메인(DDD) 단위로 무자비하게 썰어내어 "어떤 폭풍이 와도 내 심장(Core Service) 1개만큼은 절대 남과 엮여 죽지 않는" 극한의 독립 전선(Isolation)을 그어야 한다. 코드를 찢는 자가 조직을 찢고, 조직을 찢은 자가 마침내 세상을 덮어버리는 미친 속도의 패권(Deployment)을 움켜쥔다.

• 📢 섹션 요약 비유: 마이크로서비스 분해는 **'항공모함 1척을 구축함 50척의 함대(Fleet)로 쪼개는 작전'**과 같습니다. 항공모함(모놀리식)은 튼튼하고 공격력 1만 배지만, 배 밑바닥에 어뢰(장애) 1방 맞으면 조종사 5천 명이 탄 채로 통째로 가라앉아 전쟁에 집니다. 이를 구축함 50척(MSA)으로 쪼개 놓으면? 관리하기 빡세고 50척이 서로 무전(네트워크 API) 치느라 정신없습니다(인프라 복잡도). 하지만 어뢰가 날아와 구축함 3척이 가라앉아도(부분 장애), 나머지 47척의 배는 1초의 멈춤도 없이 적진을 향해 미친 속도로 진격(가용성/민첩성)하며 완벽하게 전쟁(비즈니스)을 승리로 이끄는 압도적 생존의 전술입니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 내가 레고로 엄청나게 큰 **'통짜 울트라 로봇 1개(모놀리식)'**를 만들었어요. 너무 멋진데, 발목 하나가 고장 나니까 수리하느라 로봇 100%가 움직이지 못하고 하루 종일 멈춰있어야 했어요 ㅠㅠ
2. 그래서 나는 이 로봇을 50마리의 **'작은 미니 로봇 특공대(마이크로서비스)'**로 분리해서 개조했어요!
3. 이제 발목 로봇 1마리가 고장 나도, 나머지 49마리의 로봇들은 신나게 날아다니면서 자기 임무(기능)를 완벽하게 수행해요! 고장 난 1마리만 1초 만에 새걸로 갈아 끼우면 되죠. 이렇게 거대하고 무거운 프로그램을 작고 빠른 여러 개의 조각으로 찢어서 절대 멈추지 않게 만드는 마법을 **'마이크로서비스 분해'**라고 부른답니다!