# 잘나가던 스타트업이 MSA 도입하고 6개월 만에 망할 뻔한 사연

> Clean Markdown view of GeekNews topic #25571. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25571](https://news.hada.io/topic?id=25571)
- GeekNews Markdown: [https://news.hada.io/topic/25571.md](https://news.hada.io/topic/25571.md)
- Type: news
- Author: [baeba](https://news.hada.io/@baeba)
- Published: 2026-01-05T10:08:24+09:00
- Updated: 2026-01-05T10:08:24+09:00
- Original source: [medium.com](https://medium.com/lets-code-future/microservices-killed-our-startup-monoliths-wouldve-saved-us-4ebadf584a6d)
- Points: 27
- Comments: 14

## Summary

**무리한 MSA 도입은 작은 팀에겐 독이 될 수 있습니다.** 4명의 개발자가 넷플릭스식 마이크로서비스를 따라 하다 인프라 비용이 4배로 늘고, 기능 개발이 멈춰버린 사례가 공개되었습니다. 글쓴이는 **MSA는 기술이 아니라 ‘조직 규모’의 문제를 푸는 도구**라며, 초기 스타트업은 모놀리스로 충분하다고 강조합니다. 복잡성은 성장의 상징이 아니라 관리 비용이라는 점을 다시 일깨워 줍니다.

## Topic Body

최근 해외 기술 블로그에서 화제가 된 *"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. 핵심 교훈 (이 글의 결론)  
  
1. **MSA는 '기술적 문제'가 아니라 '조직적 문제'를 해결하는 도구다.**  
* 개발자가 50명 이상이라 서로 발을 밟을 때, 배포 주기가 서로 너무 다를 때 쓰는 것이다.  
  
  
2. **넷플릭스/구글은 당신의 롤모델이 아니다.**  
* 그들도 처음엔 모놀리스였다. 규모가 커져서 바꾼 거지, 처음부터 그렇게 한 게 아니다.  
  
  
3. **복잡성은 세금이다.**  
* 서비스가 늘어날 때마다 관리 비용은 복리로 늘어난다.  
  
  
4. **네트워크 호출은 공짜가 아니다.**  
* 메모리 내 함수 호출(나노초)과 네트워크 호출(밀리초)은 차원이 다르다.  
  
  
  
---  
  
**한 줄 요약:**  
"모놀리스는 적이 아니다. 나쁜 아키텍처가 적이다. 4명인 팀은 제발 그냥 모놀리스 써라."

## Comments



### Comment 48689

- Author: ahwjdekf
- Created: 2026-01-05T11:49:43+09:00
- Points: 4

자. 이제 MSA 광신자들 몰려옵니다

### Comment 48721

- Author: aer0700
- Created: 2026-01-06T05:09:34+09:00
- Points: 2

네트워크 호출은 공짜가 아니다, 는 맞는 말이네요. 함수 호출하고 api call은 분명 다르죠.

### Comment 48695

- Author: bungker
- Created: 2026-01-05T14:43:42+09:00
- Points: 2

나는 제품 만들러 왔지, 하루 종일 쿠버네티스 만지러 온 게 아니다 —> 제가 들은 가장 병신같은 소리네요

### Comment 48724

- Author: hohemian
- Created: 2026-01-06T08:56:08+09:00
- Points: 5
- Parent comment: 48695
- Depth: 1

왜요? k8s가 목적인 k8s를 하고 있는 상황에선 맞는 말인듯 싶은데?

### Comment 49803

- Author: roxie
- Created: 2026-01-23T22:53:36+09:00
- Points: 1
- Parent comment: 48695
- Depth: 1

bungker 님 댓글들이 좋아서 하나씩 눌러보는게 이거 하나는 공감이 안가네요 흠 부연설명이 가능하실까요

### Comment 48693

- Author: passerby
- Created: 2026-01-05T12:41:24+09:00
- Points: 2

알맹이 없는 AI 포스트네요 이래서 요즘 미디엄은 거의 안봅니다

### Comment 49077

- Author: mhj5730
- Created: 2026-01-12T16:13:45+09:00
- Points: 1

4명이 만든 서비스면 MSA로 쪼갤 이유가 없긴 할것 같네요

### Comment 48705

- Author: moderato
- Created: 2026-01-05T16:38:25+09:00
- Points: 1

MSA를 하려면 조직도 MSA에 맞춰야하죠...

### Comment 48699

- Author: ifmkl
- Created: 2026-01-05T15:41:18+09:00
- Points: 1

아래 요약에 4번이 말하고자 하는 요지가 아닐까 하네요. 그리고 전체적으로 내용 자체는 공감이 가네요.

### Comment 48674

- Author: bsh998
- Created: 2026-01-05T10:12:51+09:00
- Points: 1

음... 뭔가 이상한 것 같아요  
이 글 AI로 써진 것 같네요.

### Comment 48676

- Author: baeba
- Created: 2026-01-05T10:21:06+09:00
- Points: 1
- Parent comment: 48674
- Depth: 1

저도 요즘 많이 느끼는 것이지만..  
많은 블로그의 글들의 본인의 경험 + AI의 도움을 받아서   
쓰고 있지 않나 추측을 해봅니다.  
너무 글들이 논리 정연하고 읽기 쉽게 쓰여져 있어서요.

### Comment 48682

- Author: bsh998
- Created: 2026-01-05T10:59:07+09:00
- Points: 1
- Parent comment: 48676
- Depth: 2

제가 남기고 싶었던 말은 굉장히 AI틱하고 레퍼런스도 없어서 이런 글을 공유하지 않으셨으면 좋겠다는 의견입니다.

### Comment 48684

- Author: baeba
- Created: 2026-01-05T11:05:56+09:00
- Points: 3
- Parent comment: 48682
- Depth: 3

해커뉴스에 올라온 글입니다. 제가 올리는 대부분 글들은 해커뉴스에 올라온 내용입니다.  
  
https://news.ycombinator.com/item?id=46469845  
  
말씀하신 것처럼.. 해커뉴스 레퍼런스를 올려야 겠네요.

### Comment 48673

- Author: baeba
- Created: 2026-01-05T10:12:34+09:00
- Points: 1

#### 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)일 수도 있다”는 의심도 강했음.**