[충격] "마이크로서비스(MSA)는 틀렸다?" 아마존이 다시 모놀리식으로 돌아간 진짜 이유 🧩💥

안녕하세요! 개발자라면 누구나 한 번쯤 들어봤을 '진리'가 있습니다.

"모놀리식(Monolithic)은 낡고 구린 것, 마이크로서비스(MSA)는 세련되고 완벽한 것."

 

그런데 이 믿음을 산산조각 낸 사건이 발생했습니다. 바로 클라우드의 창시자이자 MSA의 선구자인 아마존(Amazon Prime Video) 팀이 스스로 MSA를 버리고 모놀리식으로 회귀한 사건입니다. 그 결과는 충격적이었습니다. 비용을 무려 90%나 절감했거든요.

 

도대체 무슨 일이 있었던 걸까요? 아마존 프라임 비디오 팀의 사례를 통해 "MSA 무용론"의 실체를 아주 상세하게 파헤쳐 보겠습니다. 🕵️‍♂️📉

---

1. MSA의 환상: "잘게 쪼개면 무조건 좋다?" 🔪

아마존 프라임 비디오에는 '영상 품질 모니터링 서비스(VQA)'라는 게 있습니다. 고객이 보는 영상에 끊김이나 깨짐 현상이 없는지 실시간으로 감시하는 도구죠.

초기에는 이 시스템을 '교과서적인 MSA' 형태로 설계했습니다.

• AWS Step Functions를 오케스트레이터로 사용
• AWS Lambda (서버리스)를 이용해 기능을 잘게 쪼갬
• 각 기능이 데이터를 S3에 저장하고 읽어오는 구조

이론상으로는 완벽했습니다. 확장성도 좋고, 관리도 편해 보였죠. 하지만 현실은 지옥이었습니다. 🔥

2. 문제의 발생: "배보다 배꼽이 더 크다" 💸

서비스를 운영하다 보니 심각한 두 가지 문제가 터졌습니다.

• 오버헤드의 지옥: 각 기능을 마이크로서비스(Lambda)로 쪼개 놓으니, 이들이 서로 통신하는 데 드는 비용이 엄청났습니다. 데이터를 처리하는 시간보다 데이터를 '주고받는 시간'이 더 걸리는 상황이 발생한 거죠.
• 비용 폭탄 (Step Functions): 수천 개의 비디오 스트림을 초 단위로 감시하다 보니, 마이크로서비스들의 상태를 관리하는 'Step Functions'의 요금이 기하급수적으로 늘어났습니다.

쉽게 말해, "라면 하나 끓이는데(영상 처리), 물 끓이는 사람, 면 넣는 사람, 스프 넣는 사람이 다 따로 있고 서로 전화로 통신하느라 요금 폭탄을 맞은 꼴"이었습니다. 📞💸

3. 결단: "다시 하나로 합치자!" (Monolithic Transformation) 🔄

아마존 팀은 과감한 결단을 내립니다. "분산된 마이크로서비스를 하나의 프로세스(Monolith)로 합치자!"

• Lambda & Step Functions 제거: 잘게 쪼개진 람다 함수들을 하나의 거대한 애플리케이션 코드로 통합했습니다.
• 메모리 통신: 데이터를 S3나 네트워크로 주고받는 대신, 같은 메모리 안에서 변수로 주고받게 바꿨습니다. (속도가 비교할 수 없이 빨라짐 🚀)
• EC2/ECS로 이사: 서버리스를 버리고, 든든한 EC2 인스턴스(컨테이너) 위에서 하나의 큰 덩어리로 실행시켰습니다.

4. 결과: 비용 90% 절감의 기적 📉💰

결과는 놀라웠습니다.

1. 비용 90% 감소: 인프라 비용이 10분의 1로 줄어들었습니다.
2. 시스템 복잡도 해소: 수백 개의 람다와 파이프라인을 관리하던 고통에서 해방되었습니다.
3. 성능 향상: 네트워크를 타지 않고 메모리에서 바로 처리하니 처리 속도도 훨씬 빨라졌습니다.

아마존 엔지니어링 블로그는 이렇게 결론을 내립니다.

"높은 처리량이 필요한 시스템에서 마이크로서비스 아키텍처는 오히려 독이 될 수 있다."

5. 왜 MSA는 실패했나? (교훈) 🎓

이 사건이 주는 교훈은 "MSA는 쓰레기다"가 아닙니다. "MSA는 만능열쇠가 아니다"라는 점입니다.

• 잘못된 분리: 서로 너무 긴밀하게 연관된(Tightly Coupled) 기능들을 억지로 찢어놓으면, 통신 비용(네트워크, 직렬화) 때문에 효율이 박살 납니다.
• 분산 시스템의 함정: "네트워크 호출은 공짜가 아니다"라는 제1원칙을 잊으면 안 됩니다.
• 적정 기술(Right Sizing): 스타트업이나 특정 워크로드(대량의 데이터 고속 처리)에는 복잡한 MSA보다 단순한 모놀리식이 훨씬 강력하고 저렴할 수 있습니다.

---

📝 결론: 유행을 쫓지 말고 '본질'을 보자

개발자들 사이에서 "모놀리식으로 짠다"고 하면 비웃던 시절이 있었습니다. 하지만 아마존의 이 사례는 우리에게 '겸손'을 가르쳐 줍니다.

구글이나 넷플릭스가 MSA를 한다고 해서 우리 회사도 MSA를 해야 하는 건 아닙니다. 때로는 투박해 보이는 '하나의 큰 덩어리(Monolith)'가 가장 빠르고, 가장 싸고, 가장 현명한 정답일 수 있습니다.

여러분의 프로젝트는 지금 '필요에 의한 MSA'인가요, 아니면 '유행을 쫓는 MSA'인가요? 한 번쯤 점검해 볼 시간입니다. 🤔⏱️

---