왜 최고의 스타트업들은 여전히 모놀리스를 사용할까?
당신도 이런 경험 있나요?
어떤 마이크로서비스 프로젝트는 너무 과하게 설계되어서, 다른 서비스가 살아 있는지만 알려주는 별도의 서비스가 필요했던 적.
저도요.
스타트업을 컨설팅하거나 조언한 경험이 너무 많아서 이제는 숫자도 셀 수 없을 지경입니다. 그들 대부분은 자랑스럽게 “완전히 분리된, 무한히 확장 가능한” 최신 마이크로서비스 아키텍처를 소개하곤 하죠. 그럴 때마다 저는 속으로 조용히 생각합니다.
“이거, 6개월 안에 무너질 텐데.”
아이디어가 나빠서 그런 건 아닙니다. 마이크로서비스는 분명 필요할 때가 있습니다.
하지만 그 ‘때’는 보통 “직원 셋이 위워크에 앉아서, 반쯤 망가진 MVP 하나 들고, 유료 고객은 단 한 명도 없는 상황”은 아닙니다.
아이러니하게도, 제가 실제로 성공하는 걸 본 최고의 스타트업들 —
지속적으로 제품을 출시하고, 시드 투자를 인프라가 아니라 실제 문제 해결에 쓴 팀들 —
이들이 사용한 건 모놀리스였습니다.
맞습니다.
모놀리스. 소프트웨어 아키텍처계의 공룡이라고 불리는 그것 말이죠.
모놀리스는 적이 아니다
어느 순간부터 "모놀리스"라는 단어는 일종의 비하 표현처럼 쓰이기 시작했습니다.
마치 누군가를 "레거시"라고 부르는 것처럼요. 듣기만 해도 괜히 눈살이 찌푸려집니다.
그런데 모놀리스를 비웃는 사람들 중 대부분은 CRUD 이상을 만들어본 적이 없습니다.
반면, 실제로 유저를 확보하고, 수익을 내고, 성장 궤도에 오른 스타트업들은 오히려 단일 레포지토리에 Postgres 백엔드, 그리고 커다란 services 폴더 하나로 전 사업을 운영하고 있습니다.
그리고 그게… 놀라울 정도로 잘 작동합니다.
문제는 모놀리스가 아닙니다.
문제는 섣부른 복잡성입니다.
“확장성”이라는 신화
스타트업들은 스스로에게 이렇게 말하곤 합니다.
“우린 확장 가능한 구조를 만들고 있어. 혹시라도 하룻밤 새 백만 명이 몰려오면 어쩔 건데?”
그러면서 정작 가입 폼 하나도 제대로 작동하지 않고, 로그인하는 유저도 없습니다.
현실을 직시합시다.
대부분의 스타트업은 확장성이 필요한 게 아닙니다.
존재가 먼저입니다.
정말 만들고 싶은 게 뭔지 스스로 파악할 때까지 살아남아야 합니다.
빠르게 방향을 바꿀 수 있어야 하고, 하루에도 여러 번 배포할 수 있어야 하며,
서비스 메시 꼬인 거 푸느라, 컨테이너 두 개 사이 gRPC 호출 왜 안 되는지 디버깅하느라 하루를 날려선 안 됩니다.
스타트업 초기엔, 확장성보다 유연성이 중요합니다.
우아한 설계보다 단순함이 낫습니다.
직관적이고 잘 작동하는 코드 > 분산돼서 보기만 해도 눈물 나는 코드입니다.
빠르게, 집중해서, 일단 출시하자
모놀리스로 개발하면 무슨 일이 일어날까요?
일이 끝납니다.
"인증(auth)을 별도 서비스로 빼야 하나?" 고민하느라 3일을 날리지 않습니다.
YAML 쓰느라 시간을 낭비하지도 않고,
레포지토리 5개 만들어 놓고 “이게 아키텍처지”라는 말도 안 합니다.
그냥… 기능을 만듭니다.
그래서 최고의 팀들 — 특히 경험 많은 시니어들이 있는 팀일수록 —
기본값처럼 모놀리스를 선택합니다.
이미 마이크로서비스의 춤사위를 겪어봤기 때문이죠.
비용이 얼마나 드는지, 그게 언제쯤 가치 있는 선택인지 잘 압니다.
초기 페이스북? 모놀리스.
초기 깃허브? 모놀리스.
아마존조차도 처음엔 모놀리스였고,
스스로 쪼개도 될 만큼 성장한 뒤에야 비로소 분리하기 시작했습니다.
마이크로서비스의 비용은 기술적인 것만이 아니다
사람들은 마이크로서비스의 경계, 확장성 같은 기술 얘기는 잘합니다.
하지만 팀의 사기에 대해서는 말하지 않습니다.
마이크로서비스가 40개쯤 있는 숲속 같은 구조에 새로운 엔지니어를 온보딩시켜 보세요.
그 중 절반은 문서도 없고, 네이밍도 엉망이라면…
그 엔지니어의 영혼이 조용히 빠져나가는 걸 보게 될 겁니다.
반대로, 깔끔하고 읽기 쉬운 모놀리스에 투입된 엔지니어는 어떨까요?
함수를 검색하면 실제로 찾을 수 있고,
“앱을 실행하는 일”이 쉘 스크립트 세 개랑 퇴마 의식(!)이 필요하지 않은 곳이라면요?
사람들은 아키텍처가 개발 속도에 얼마나 영향을 주는지 과소평가합니다.
그리고 마이크로서비스는?
정말 반드시 필요하지 않다면, 속도를 느리게 만듭니다.
기술적으로도, 문화적으로도, 심리적으로도요.
나중에 쪼개도 늦지 않다
모놀리스는 되돌릴 수 있습니다.
하지만 마이크로서비스는 그렇지 않습니다.
모놀리스가 너무 커졌나요?
좋습니다. 그때 가서 하나씩 떼어내면 됩니다.
진짜 아프기 시작할 때, 진짜 경계선이 보이기 시작할 때 추출하세요.
좋은 소프트웨어는 그렇게 유기적으로 진화합니다.
첫 번째 고객이 생기기도 전에 그려진 아키텍처 다이어그램대로 움직이는 게 아닙니다.
스타트업을 미래에 대비하는 방법은 예측이 아닙니다.
버티고, 빠르게 움직이고, 정신줄을 놓지 않는 것,
그게 진짜 미래 대비입니다.
마무리하며
그러니까, 모놀리스는 구시대 유물이 아닙니다.
저평가된 전략입니다.
게으르기 때문에 선택하는 기본값이 아니라, 똑똑하기 때문에 선택하는 기본값입니다.
왜냐고요?
당신은 지금 스타트업을 만드는 중이지, 분산 시스템 박사 논문을 쓰고 있는 게 아니니까요.
기술이란 건 멋져 보이는 것이 아니라, 실제로 잘 작동하는 것이니까요.
그리고 언젠가 정말 그 전설 같은 스케일에 도달했을 때 —
그때쯤이면 당신에겐 그걸 제대로 쪼갤 수 있는 돈, 팀, 그리고 맥락이 있을 겁니다.
그때까진?
빠르게 만들고, 가볍게 움직이세요.
모놀리스 만세.
🧠 이 글을 읽고 얻은 인사이트
그동안 나는 ‘모놀리스’라고 하면 자연스럽게 부정적인 이미지를 떠올렸다.
낡고, 비효율적이며, 레거시 시스템의 상징이라는 인식이 강했다.
그래서 스타트업이라면 당연히 마이크로서비스 구조를 써야 한다고 여겨왔다.
하지만 이 글을 통해 그 생각이 짧았다는 걸 절실히 느꼈다.
모놀리스는 게으름의 결과가 아니라, 지혜로운 선택일 수 있다.
특히 스타트업처럼 빠르게 움직이고, 빠르게 피드백을 받고, 매일 방향을 바꿔야 하는 조직에겐
복잡함보다 단순함이, 세련됨보다 실용성이 훨씬 더 중요하다는 걸 다시금 깨달았다.
무엇보다 중요한 건,
기술은 “멋져 보이는 것”이 아니라 “실제로 잘 작동하는 것”이어야 한다는 점.
이제는 아키텍처를 선택할 때, 트렌드보다는
팀의 현재 상황, 개발 속도, 그리고 생존 가능성을 먼저 고민하려 한다.
