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

최근 해외 기술 블로그에서 화제가 된 "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명인 팀은 제발 그냥 모놀리스 써라."