잘나가던 스타트업이 MSA 도입하고 6개월 만에 망할 뻔한 사연
(medium.com)최근 해외 기술 블로그에서 화제가 된 "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" 라는 글을 읽고, 내용이 너무 뼈아프면서도 공감이 되어 요약 공유합니다.
무조건적인 최신 기술 도입이 얼마나 위험한지 보여주는 좋은 "오답 노트" 같네요.
1. 사건의 발단: "우리도 넷플릭스처럼 합시다"
- 상황: 시드 투자 $2.5M 유치, 월 매출 40% 성장, 유저 5만 명. Rails 모놀리스로 아주 잘 굴러가던 스타트업.
- 문제의 시작: 리드 아키텍트가 등장해 "확장성(Scalability)"을 외치며 MSA 전환을 제안함.
- 논리: "지금 구조는 결합도가 너무 높아. 넷플릭스나 우버를 봐. 우리도 그들처럼 되려면 마이크로서비스로 가야 해."
- 현실: 개발자 4명, 데브옵스 1명인 팀에서 넷플릭스 아키텍처를 도입하기로 결정.
2. 지옥의 6개월 (MSA 도입 타임라인)
[1개월 차: 허니문]
- 알림 서비스 분리 성공. "봐! 잘 되잖아?"라며 자축.
- 하지만 배포 시간 증가, 리포지토리 증가 등 전조 증상 시작.
[2~3개월 차: 균열의 시작]
- 결제(Billing) 서비스 분리. 이게 유저, 재고, 주문 서비스와 다 엮여 있음.
- 결과: 네트워크 레이턴시로 인해 응답 속도가 200ms → 800ms로 느려짐. 서비스 하나 죽으면 전체가 다 죽는 연쇄 장애 발생.
[4~5개월 차: 분산 트랜잭션의 악몽]
- 모놀리스에선 DB 트랜잭션 하나면 될 일을, 분산 환경이라 Saga 패턴까지 도입.
- 재고는 줄었는데 결제는 실패하고, 롤백은 꼬이고... 데이터 불일치로 CS 폭주.
- 간단한 컬럼 하나 추가하는 데 6개 서비스를 건드려야 해서 2시간 걸릴 일이 3일 걸림.
[6개월 차: 팀 붕괴]
- 개발자들은 기능 개발 대신 인프라 관리에 모든 시간을 쏟음.
- 인프라 비용 $3,000 → $12,000 (4배 폭증).
- 핵심 개발자 퇴사 ("나는 제품 만들러 왔지, 하루 종일 쿠버네티스 만지러 온 게 아니다")
3. 결단: "우리는 넷플릭스가 아니다"
아키텍트는 여전히 "서비스 메시(Service Mesh)를 도입하고 모니터링 툴을 늘리자"고 주장했지만, 글쓴이는 폭발합니다.
"우리는 넷플릭스가 아니야! 넷플릭스는 엔지니어가 500명이지만 우리는 4명이라고!"
결국 아키텍트는 퇴사했고, 팀은 모놀리스로 회귀(Rollback) 를 결정합니다.
4. 모놀리스로의 복귀, 그리고 부활
- 8주에 걸쳐 다시 모놀리스로 코드를 합침.
- 결과:
- 기능 출시 속도 회복 (월 4건 → 20건)
- 응답 속도 220ms로 안정화
- 인프라 비용 감소
- 무엇보다 개발자 행복도 상승
5. 핵심 교훈 (이 글의 결론)
- MSA는 '기술적 문제'가 아니라 '조직적 문제'를 해결하는 도구다.
- 개발자가 50명 이상이라 서로 발을 밟을 때, 배포 주기가 서로 너무 다를 때 쓰는 것이다.
- 넷플릭스/구글은 당신의 롤모델이 아니다.
- 그들도 처음엔 모놀리스였다. 규모가 커져서 바꾼 거지, 처음부터 그렇게 한 게 아니다.
- 복잡성은 세금이다.
- 서비스가 늘어날 때마다 관리 비용은 복리로 늘어난다.
- 네트워크 호출은 공짜가 아니다.
- 메모리 내 함수 호출(나노초)과 네트워크 호출(밀리초)은 차원이 다르다.
한 줄 요약:
"모놀리스는 적이 아니다. 나쁜 아키텍처가 적이다. 4명인 팀은 제발 그냥 모놀리스 써라."
저도 요즘 많이 느끼는 것이지만..
많은 블로그의 글들의 본인의 경험 + AI의 도움을 받아서
쓰고 있지 않나 추측을 해봅니다.
너무 글들이 논리 정연하고 읽기 쉽게 쓰여져 있어서요.
해커뉴스에 올라온 글입니다. 제가 올리는 대부분 글들은 해커뉴스에 올라온 내용입니다.
https://news.ycombinator.com/item?id=46469845
말씀하신 것처럼.. 해커뉴스 레퍼런스를 올려야 겠네요.
1) 글의 신빙성 의심: 마케팅/AI 생성물 냄새 난다
요지
- “이거 너무 교훈극처럼 잘 짜여 있음” → HN이 좋아할 ‘도덕극’에 최적화된 문장이라는 의심 나옴
- 본문에 유료 자료 링크가 덕지덕지 붙어 있어서 “결국 세일즈 글 아니냐” 여론 강함
- 리스트 남발/이모지 같은 문체가 “AI 슬롭(대충 찍어낸 AI 콘텐츠)” 시그널이라는 지적
팩트 폭격 인용(번역)
“전체가 링크된 유료 자료 팔려고 만든 것 같음. 리스트 잔뜩 넣은 AI 슬롭 느낌 남.”
(원문: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
한줄 평
- “내용이 맞고 틀리고 이전에, 팔 냄새 + AI 냄새가 너무 진하게 난다”가 1번 반응임.
2) 리더십/아키텍트 비판: 기술이 아니라 ‘의사결정 구조’가 문제였음
요지
- “4명 팀에 아키텍트?” 자체가 이미 삐끗했다는 반응 많음
- 특히 코드 안 짜는 아키텍트/분리된 DevOps 역할을 ‘병목 + CV 최적화’로 보는 시각 강함
- 마이크로서비스가 아니라 “아무도 책임지고 배포/운영/수습 안 하는 구조”가 회사를 말아먹었다는 톤
뼈 때리는 인용(번역)
“제품도 안 만드는 아키텍트가 규칙이니 패턴이니 정하는 거 거의 항상 최악임. 그냥 출시나 해. 코드 10줄도 안 짤 사람이 결정을 독점하면 망함.”
(원문: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
한줄 평
- “MSA가 문제가 아니라 ‘결정권은 있는데 책임은 없는 역할 설계’ 가 문제”라는 쪽이 꽤 강했음.
3) 비즈니스 관점: 스타트업 실패 원인이 진짜로 MSA였나?
요지
- “아키텍처 때문에 망했다” 프레이밍 자체를 안 믿는 댓글들 있음
- 핵심 논점: PMF/수요/고객 락인이 약하면 어떤 스택이든 망할 수밖에 없다는 주장
- 특히 “고객이 이틀 느려졌다고 바로 떠난다?” 같은 디테일로 ‘원래 제품 가치가 약했던 거 아니냐’ 꼬집음
- 그리고 글 내부 모순도 찌름: “MSA가 스타트업을 죽였다” 해놓고 결론은 “살았다?” → 서사 과장 의심
팩트 폭격 인용(번역)
“사람들이 원하지 않는 제품 만든 게 스타트업 죽인 거지. Python vs Go가 스타트업 죽였다는 말이랑 똑같이 말이 안 됨.”
(원문: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
한줄 평
- “아키텍처는 핑계고, 진짜 원인은 시장/제품/현금흐름일 수 있음” 이 관점이 분명히 존재함.
4) 기술적 통찰: 모놀리스 vs MSA 경험 기반 조언 (진짜로 도움 되는 부분)
요지
- “MSA는 고정비(운영 복잡도) 세금이 있음” → 작은 팀에겐 치명타 될 수 있다는 경험담 다수
- 핵심 키워드: Premature distribution(너무 이른 분산), 모듈러 모놀리스/모듈리쓰(modulith), “경계(boundary)는 ‘벌어서’ 얻어라”
- MSA가 필요해지는 조건도 현실적으로 제시됨: 팀 규모 커져서 충돌/배포/조직 문제가 실제로 터질 때
- 반대로 성능/확장 이슈는 보통 “MSA로 해결”이 아니라 먼저 알고리즘/병목/샤딩/파티셔닝부터 보라는 조언도 있음
뼈 때리는 인용(번역)
“스타트업을 죽인 건 마이크로서비스가 아니라 ‘너무 이른 분산’임. 경계가 진짜로 생기기 전에 쪼개서 레이턴시/조율 비용만 냈고, 모듈러 모놀리스로 시작해서 경계를 벌어야 함.”
(원문: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
한줄 평
- 커뮤니티가 실제로 공감한 교훈은 이거였음:
“모놀리스로 시작하고, 경계가 ‘자연스럽게’ 생길 때만 서비스 분리해라.”
커뮤니티 총평 한 문장
“우리는 넷플릭스가 아니다”에 대부분 동의했지만, 동시에 “이 글 자체가 넷플릭스병을 팔아먹는 서사(=마케팅/AI)일 수도 있다”는 의심도 강했음.