
"React로 할까요, Vue로 할까요?"
개발자를 채용하거나 외주 개발사와 미팅할 때 자주 듣는 질문입니다.
"React가 요즘 대세라고 하던데요?"
"Vue가 더 배우기 쉽다고 들었어요"
"Angular는 어떤가요?"
그러면 개발자는 30분 동안 기술적인 장단점을 설명하고, 대표님은 고개를 끄덕이지만 사실 하나도 이해가 안 됩니다. 그리고 결국 이렇게 묻죠.
"그래서... 뭐가 좋은 건가요?"
7년 전 저도 똑같았습니다. 공동창업자들과 기술 스택을 논의하면서 React와 Vue를 비교하는 문서를 며칠 동안 읽었습니다. 그런데 지금 돌아보니 깨닫습니다. 그건 정말 중요하지 않았습니다.
충격적인 진실: 기술 스택은 생각보다 중요하지 않다
제가 7년간 배운 가장 중요한 교훈입니다.
초기 스타트업에서 React를 선택하든 Vue를 선택하든, 회사가 망하거나 성공하는 데 거의 영향을 미치지 않습니다. 정말입니다.
회사가 망하는 이유는 기술 스택 때문이 아닙니다. 고객이 원하지 않는 제품을 만들거나, 시장 타이밍을 놓치거나, 돈이 떨어지거나, 팀이 분열되기 때문입니다. React로 만들든 Vue로 만들든, 제품이 고객 문제를 해결하지 못하면 똑같이 망합니다.
반대로 성공하는 회사는 다양한 기술 스택을 씁니다. Facebook은 PHP로 시작했고, Twitter는 Ruby on Rails였고, Airbnb는 React입니다. 기술 스택이 달라도 모두 성공했습니다. 왜? 고객이 원하는 가치를 빠르게 제공했기 때문입니다.
그럼 대체 뭐가 중요한가?
기술 스택 선택에서 정말 중요한 것들은 따로 있습니다.
1. 개발자가 잘 아는 기술
가장 중요합니다. 정말로요.
React 전문가에게 Vue로 개발하라고 하면? 학습 기간만 한 달입니다. 초기 스타트업에게 한 달은 생사를 가르는 시간입니다. 고객 피드백을 받고 빠르게 개선해야 하는데, 개발자가 새로운 기술을 배우느라 시간을 쓴다면?
저희도 초기에 "최신 기술을 쓰자"며 팀원들이 잘 모르는 기술을 선택한 적이 있습니다. 결과는? 간단한 기능 하나 만드는데 예상보다 3배 오래 걸렸고, 버그는 2배 많았습니다. 6개월 후 결국 다 갈아엎고 팀원들이 잘 아는 기술로 다시 만들었습니다.
대표가 물어봐야 할 질문: "이 기술로 실제 프로젝트를 완성해본 적이 있나요?" "막혔을 때 스스로 해결할 수 있나요?"
기술의 인기도나 트렌드가 아니라, 우리 개발자가 얼마나 잘 다룰 수 있는지가 중요합니다.
2. 채용 가능한 인력 풀
두 번째로 중요한 건 나중에 사람을 뽑을 수 있느냐입니다.
극단적인 예를 들어볼까요? 첫 개발자가 Rust라는 언어로 모든 걸 만들었습니다. 문제없이 잘 돌아갑니다. 그런데 그 개발자가 퇴사하면? Rust 개발자를 구하기가 정말 어렵습니다. 연봉도 비싸고, 찾기도 어렵습니다.
반면 React나 Vue 같은 주류 기술은? 개발자 구하기가 상대적으로 쉽습니다. 연봉도 시장가가 형성되어 있고, 면접 볼 사람도 많습니다.
저희가 초기에 Python Django로 백엔드를 만든 이유도 이겁니다. 더 좋은 기술이 있을 수 있지만, Django 개발자는 한국에서 구하기 쉽고, 신입도 빠르게 온보딩할 수 있습니다. 실제로 3년 동안 10명 넘는 백엔드 개발자를 무리 없이 채용했습니다.
대표가 확인해야 할 것:
- 주요 채용 사이트에서 이 기술 스택 개발자 공고가 얼마나 많은가?
- 주변 스타트업들이 비슷한 기술을 쓰고 있는가?
3. 비즈니스 요구사항과의 적합성
이건 좀 더 기술적인 이야기지만, 중요합니다.
실시간 채팅이 핵심인 서비스인데, 실시간 처리가 약한 기술을 선택하면? 나중에 갈아엎어야 합니다. 대용량 데이터 처리가 필요한데, 그에 맞지 않는 데이터베이스를 선택하면? 성장 한계에 부딪힙니다.
하지만 솔직히, 초기 스타트업은 이걸 미리 걱정할 필요가 거의 없습니다. 월 사용자 1만 명도 안 되는데 확장성을 고민하는 건 사치입니다. 나중에 문제가 생기면 그때 해결해도 됩니다. 그 정도로 성장했다면 돈도 있고 개발자도 늘었을 테니까요.
예외 케이스:
- 실시간 동영상 스트리밍 같은 특수한 요구사항
- 금융이나 헬스케어처럼 규제가 많은 산업
- 아예 기술이 제품의 핵심인 경우 (예: AI 모델 서빙 플랫폼)
이런 경우가 아니라면, 비즈니스 요구사항은 나중에 생각해도 됩니다.
React vs Vue, 정말 알고 싶다면
그래도 궁금하실 거예요. "그럼 둘의 차이가 뭔데요?"
비개발자 대표님이 이해하기 쉽게 설명해드리겠습니다.
자동차로 비유하면:
- React = 현대 아반떼
- Vue = 기아 K3
둘 다 좋은 차입니다. 둘 다 출근할 수 있고, 가족 여행 갈 수 있습니다. 누가 뭘 타든 목적지에 도착합니다. 차이는? 운전석 버튼 배치가 약간 다르고, 브랜드 선호도가 다르고, 딜러망이 다릅니다.
실전 차이:
- React: 페이스북이 만듦, 더 많은 회사가 사용, 개발자 구하기 약간 더 쉬움
- Vue: 커뮤니티가 만듦, 아시아에서 인기, 배우기 약간 더 쉬움
둘 다 같은 일을 할 수 있습니다. 웹사이트 만들고, 앱 같은 경험 제공하고, 사용자와 상호작용합니다. 성능 차이? 일반 사용자는 못 느낍니다. 개발 속도 차이? 개발자 실력이 더 중요합니다.
정말 위험한 기술 스택 결정들
기술 스택 자체는 중요하지 않다고 했지만, 잘못된 의사결정 방식은 위험합니다.
1. "대표가 아는 기술"로 결정하기
제일 위험합니다.
"저 학부 때 Java 배웠는데, Java로 하면 안 되나요?"
"Python이 핫하다고 하던데 Python으로 하죠"
대표가 10년 전에 배운 지식이나 뉴스에서 본 트렌드로 기술을 정하면 안 됩니다. 실제로 개발할 사람이 제일 잘 알고, 제일 빠르게 만들 수 있는 기술을 써야 합니다.
저도 초기에 이 실수를 했습니다. 제가 석사 때 배운 기술로 프로젝트를 시작하자고 우겼습니다. 팀원들은 경험이 없었지만 "CTO가 알면 되지"라고 생각했죠. 결과는? 제가 모든 코드를 작성하고 리뷰하느라 병목이 되었고, 팀원들은 성장이 느렸습니다.
2. "제일 최신 기술"로 결정하기
"블록체인으로 만들면 어때요?"
"요즘 AI가 핫하니까 AI 넣어요"
"메타버스 어때요?"
유행하는 기술을 제품에 억지로 끼워 넣는 건 재앙입니다. 기술은 도구입니다. 문제를 해결하기 위한 수단이지, 목적이 아닙니다. 블록체인이 정말 필요한 게 아니라면, 일반 데이터베이스가 100배 쉽고 빠릅니다.
투자자나 고객에게 멋져 보이려고 최신 기술을 선택하는 건 자살 행위입니다. 개발은 느려지고, 버그는 많아지고, 유지보수는 악몽이 됩니다.
3. "외주 개발사 추천"으로 결정하기
조심해야 합니다.
외주 개발사는 자기들이 잘 아는 기술을 추천합니다. 당연합니다. 그게 빠르고 안전하니까요. 문제는? 그 기술이 나중에 인하우스로 전환할 때 우리 상황에 맞지 않을 수 있습니다.
외주로 개발했는데 특이한 기술 스택을 썼다면? 인하우스 개발자를 구하기 어렵고, 이어서 개발하기도 어렵습니다. 결국 처음부터 다시 만들어야 할 수도 있습니다.
외주사와 일할 때 물어볼 질문: "이 기술로 만들면 나중에 개발자 채용이 쉬운가요?" "다른 개발자가 인수인계 받기 쉬운 구조인가요?"
대표가 정말 신경 써야 할 것들
기술 스택보다 훨씬 중요한 것들입니다.
1. 빠르게 만들 수 있는가?
초기 스타트업의 생명은 속도입니다.
완벽한 기술 스택으로 6개월 걸리는 것보다, 익숙한 기술 스택으로 2개월에 만드는 게 100배 낫습니다. 2개월이면 시장 반응을 보고, 피벗하고, 다시 만들 수 있습니다. 6개월이면? 돈 떨어지고 게임 끝입니다.
대표가 물어야 할 질문: "MVP를 얼마나 빨리 만들 수 있나요?" "이 기술로 개발 속도가 빨라지나요, 느려지나요?"
2. 유지보수가 가능한가?
코드는 한 번 작성하면 끝이 아닙니다. 계속 수정하고, 버그를 고치고, 기능을 추가합니다.
복잡하고 특이한 기술 스택은 나중에 유지보수가 어렵습니다. 첫 개발자가 퇴사하면? 아무도 코드를 못 건드립니다. 신규 기능 추
가하려면? 몇 주씩 걸립니다.
저희도 초기에 "멋진 아키텍처"를 만들겠다고 복잡하게 설계한 적이 있습니다. 처음 6개월은 좋았습니다. 그런데 1년 후? 간단한 수정 하나에 3명이 달라붙어야 했고, 신입 개발자 온보딩에 한 달이 걸렸습니다. 결국 2년 차에 전체를 단순하게 다시 만들었습니다.
좋은 기술 선택:
- 다른 개발자가 봐도 이해하기 쉬운 구조
- 문제가 생겼을 때 인터넷에 해결책이 많음
- 새로운 팀원이 빠르게 배울 수 있음
3. 비용은 적절한가?
일부 기술은 돈이 많이 듭니다.
클라우드 서비스를 쓴다면, 어떤 기술은 서버 비용이 10배 차이 날 수 있습니다. 특정 데이터베이스는 라이선스 비용이 수천만 원입니다. 초기 스타트업한테는 큰 돈입니다.
그런데 이것도 나중 문제입니다. 월 사용자 1,000명일 때 서버비가 10만 원이든 100만 원이든 큰 차이 없습니다. 사용자가 10만 명, 100만 명 될 때 걱정하면 됩니다. 그때쯤이면 매출도 있고, 최적화할 개발자도 있을 겁니다.
실전 조언: 기술 스택 논의에서 대표의 역할
개발자가 "React로 하겠습니다"라고 하면, 대표는 뭘 해야 할까요?
물어봐야 할 질문들
기술 자체가 아니라 비즈니스 관점으로 물어보세요.
"이 기술로 MVP를 언제까지 만들 수 있나요?"
"나중에 개발자를 더 뽑을 때 구하기 쉬운가요?"
"다른 선택지와 비교했을 때 장단점은 뭔가요?"
"혹시 본인이 이 기술을 써보고 싶어서 선택한 건 아닌가요?"
마지막 질문이 제일 중요합니다. 개발자들도 사람입니다. 이력서에 넣고 싶은 최신 기술을 쓰고 싶어 할 수 있습니다. 회사 이익보다 개인 커리어를 우선시할 수도 있습니다. 솔직하게 물어보고, 솔직한 대답을 들으세요.
하지 말아야 할 행동들
"아니 그럼 React 말고 Vue는 안 되나요? Vue가 더 좋다고 들었는데"
이러지 마세요. 대표가 기술 선택에 개입하면 책임이 애매해집니다. 나중에 문제가 생기면 "대표님이 선택하라고 해서요"라는 말을 듣게 됩니다.
개발자를 믿고 맡기세요. 대신 결과에 대한 책임을 명확히 하세요. "이 기술로 3개월 안에 MVP를 만들 수 있다고 했으니, 3개월 후에 확인하겠습니다." 이렇게요.
의견이 갈릴 때
개발자 두 명이 다른 기술을 주장하면 어떡하죠?
- 각자의 이유를 충분히 듣기
- 객관적인 기준 세우기 (개발 속도, 채용 용이성, 유지보수)
- 빠른 결정하기 (일주일 이상 논쟁하지 말기)
- 책임자 정하기 (누가 이 결정에 책임을 질 것인가)
완벽한 답은 없습니다. 70% 확신이면 결정하고 진행하세요. 100% 확신을 찾느라 한 달 쓰는 것보다, 70% 확신으로 바로 시작하는 게 낫습니다.
언제 기술 스택을 바꿔야 하나?
초기 선택이 완벽하지 않아도 됩니다. 문제는 언제 바꿀지 판단하는 겁니다.
바꿔야 할 때
개발 속도가 극단적으로 느릴 때: 간단한 기능 하나 추가하는 데 한 달 걸린다면, 뭔가 잘못된 겁니다.
개발자를 도저히 못 구할 때: 6개월 동안 채용 공고를 냈는데 지원자가 한 명도 없다면, 기술 스택이 너무 특이한 겁니다.
서비스가 자주 다운될 때: 사용자가 늘어나는데 시스템이 감당을 못 한다면, 근본적인 재설계가 필요합니다.
참고 견뎌야 할 때
다른 회사가 더 좋은 기술을 쓴다고 느낄 때: 남들이 뭘 쓰든 상관없습니다. 우리가 빠르게 만들고 고객을 만족시키면 됩니다.
개발자가 새로운 기술을 배우고 싶어 할 때: 이건 개인 학습이지 회사 업무가 아닙니다. 사이드 프로젝트로 하라고 하세요.
투자자나 고객이 특정 기술을 물어볼 때: "왜 AI 안 써요?" 같은 질문은 무시해도 됩니다. 결과로 보여주면 됩니다.
정리하며
7년간 스타트업을 운영하며 배운 교훈입니다.
기술 스택은 생각보다 중요하지 않습니다. React든 Vue든, Python이든 Node.js든, 회사의 성패를 가르지 않습니다. 정말 중요한 건 그 기술로 얼마나 빠르게 고객 가치를 만들어낼 수 있느냐입니다.
비개발 대표님이 신경 쓸 것:
- 개발자가 익숙한 기술인가?
- 빠르게 만들 수 있는가?
- 나중에 사람 뽑기 쉬운가?
- 유지보수가 가능한가?
비개발 대표님이 신경 쓰지 않아도 될 것:
- React vs Vue 같은 기술 비교
- 최신 트렌드 기술
- 대기업이나 다른 스타트업의 기술 스택
- 기술적으로 완벽한 선택
개발자를 믿고, 비즈니스 결과로 평가하세요. 기술이 아니라 제품으로 말하게 하세요. 그게 초기 스타트업이 살아남는 방법입니다.
이 글은 '모두의 CTO' 시리즈의 여섯 번째 글입니다. 스타트업 기술 조직과 리더십에 대한 솔직한 이야기를 이어가겠습니다.
'모두의 CTO' 카테고리의 다른 글
| 5명 개발팀 vs 1명 풀스택, 뭐가 나을까? - 규모별 팀 구성 전략 (0) | 2025.10.31 |
|---|---|
| 외주 개발의 함정과 인하우스 전환 타이밍 - 언제까지 외주로 버틸 수 있을까? (0) | 2025.10.30 |
| 비개발 대표의 첫 개발자 채용 가이드 - 이력서에서 뭘 봐야 하나요? (0) | 2025.10.28 |
| 개발자가 하는 말, 번역해드립니다 - "기술 부채", "리팩토링", "레거시"의 진짜 의미 (0) | 2025.10.27 |
| CTO 지분은 얼마나 줘야 할까? - 기술 공동창업자 vs 합류 CTO (0) | 2025.10.26 |