첫 SaaS를 위한 기술 스택 선택: 창업자를 위한 솔직한 가이드

첫 SaaS에 어떤 기술 스택을 써야 하느냐고 엔지니어 열 명에게 물으면 열다섯 가지 답이 돌아오고, 그중 셋은 신앙과도 같은 확신으로 전해질 것입니다. 그 답 대부분은 옳습니다 — 그것을 말하는 사람에게는요. 어느 것도 당신, 당신의 자금 여력, 아직 확보하지 못한 고객에 관한 것이 아닙니다. 창업자로서 이 결정을 마주하고 속이 조금 메스꺼워진다면, 아무도 소리 내어 말하지 않는 사실이 있습니다. 스택은 당신이 믿게 된 것보다 훨씬 덜 중요하며, 그것이 정말로 중요해지는 몇 안 되는 경우는 사람들이 온라인에서 다투는 지점이 아닙니다.

저는 꽤 많은 초보 창업자가 발표 자료에서 실제 사람들이 돈을 내는 제품으로 나아가도록 도왔습니다. 그들 거의 모두가 비기술 출신이었습니다. 그리고 거의 전부가 무서울 만큼 많은 스택 관련 통념을 이미 흡수한 채 찾아왔습니다 — 마이크로서비스가 필요하다, 어떤 프레임워크는 "죽었다", 잘못 고르면 망한다는 식으로요. 그리고 거의 매번 스택은 그해 그들이 내린 결정 가운데 가장 영향이 작은 축에 속했습니다. 프로젝트를 죽인 것은 범위, 불명확한 책임 소재, 그리고 엉뚱한 것을 아름답게 만든 일이었습니다. 결코 프레임워크가 아니었습니다.

그래서 이것은 코드 한 줄을 쓰기 전에 제가 그 창업자들에게 건네는 가이드입니다. 특정 스택을 쓰라고 말하지는 않습니다. 당신의 사업을 모르면서 그것을 약속하는 사람은 무언가를 팔고 있는 것이기 때문입니다. 대신 사고하는 방법을 드립니다 — 그래서 당신이 무엇을 고르든, 팀이 무엇을 제안하든, 불안하게 고개만 끄덕이는 대신 어른답게 점검할 수 있도록 말입니다.

왜 이 결정은 실제보다 어렵게 느껴지는가

스택 문제가 거대하게 느껴지는 까닭은, 그것이 당신이 내리는 첫 번째 '되돌릴 수 없을 것 같은' 선택이고, 당신이 구사하지 못하는 언어로 포장되어 있기 때문입니다. Postgres, React, Kubernetes, 서버리스 같은 말들이, 그것들 사이의 선택이 마치 건물의 기초를 고르는 일 — 잘못 고르면 전체가 무너지는 — 인 양 오갑니다.

하지만 소프트웨어는 건물이 아닙니다. 요리를 하면서도 개조할 수 있는 주방에 훨씬 가깝습니다. 성공한 회사들은 끊임없이 스택의 일부를 다시 씁니다. 첫 백 명의 고객을 찾아주는 제품 버전이 첫 십만 명을 떠받치는 버전인 경우는 거의 없습니다. 당신의 첫 스택의 목표는 영원히 버티는 것이 아닙니다. 누군가 이것을 원하기는 하는지를 배울 만큼 빠르게 만들고, 바꾸고, 출시하게 해주는 것입니다. 그것은 "다음 십 년 동안 완벽한"과는 전혀 다른 — 그리고 훨씬 낮은 — 기준입니다.

그것을 받아들이는 순간 압박은 절반으로 줄어듭니다. 더 이상 미래를 예측하려는 것이 아닙니다. 작동하는 제품과 유료 사용자에게 데려다줄, 합리적이고 되돌릴 수 있는 베팅을 하려는 것입니다. 그리고 합리적인 베팅은 비기술 창업자도 얼마든지 평가할 수 있는 것입니다.

"스택"이란 실제로 무엇인가, 쉬운 말로

무엇을 결정하기 전에 이 단어의 신비를 걷어내는 것이 도움이 됩니다. 기술 스택은 그저 소프트웨어를 만들고 운영하는 데 쓰이는 도구들의 모음입니다. 네 개의 층으로 생각할 수 있고, 어느 층도 깊이 이해할 필요는 없습니다 — 그것들이 존재한다는 것만 알면 됩니다.

• 프런트엔드 — 사용자가 브라우저나 앱에서 보고 클릭하는 부분. 모두가 당신을 판단하는 부분입니다.
• 백엔드 — 서버에서 돌아가는 로직과 규칙. 누가 무엇을 할 수 있는지, 그것을 할 때 무슨 일이 일어나는지, 돈이 어떻게 움직이는지.
• 데이터베이스 — 당신의 정보가 실제로 사는 곳. 사용자, 주문, 구독 등 잃으면 망연자실할 모든 것.
• 인프라 — 위의 모든 것을 온라인으로, 백업된 채로, 새벽 세 시에도 닿을 수 있게 유지하는 서버와 서비스.

누군가 "우리는 모던 자바스크립트 스택을 쓴다"거나 "Postgres 위의 Rails"라고 말한다면, 그는 이 네 층에 걸친 선택을 묘사하는 것입니다. 그게 전부입니다. 두 사람의 사이드 프로젝트부터 상장 기업까지, 모든 SaaS는 이 네 가지를 쌓아 올린 어떤 버전입니다. 거창하게 들리는 아키텍처 다이어그램도 그저 이것을 상자를 더 그려 표현한 것일 뿐입니다.

정말로 중요한 것들 (그리고 그렇지 않은 것들)

여기서 대부분의 스택 조언이 길을 잃습니다. 첫 2년에 영향을 주지 않는 것을 최적화하고, 영향을 주는 것은 무시합니다. 두 목록 모두에 대해 솔직히 말씀드리겠습니다.

진짜로 중요한 것

누가 만들고 유지보수할 수 있는가. 단 하나의 가장 큰 요인은 기술이 아니라 사람입니다. 당신에게 최고의 스택은 당신의 팀(혹은 고용하는 파트너)이 오늘 당장 실제로 능숙하게 다룰 수 있는 것입니다. 희귀한 전문가 한 명만 이해하는 "완벽한" 스택은, 유능한 개발자라면 누구나 이어받을 수 있는 지루한 스택보다 나쁜 선택입니다. 채용과 연속성은 언제나 이론적 우아함을 이깁니다.

얼마나 빨리 바꿀 수 있는가. 초기에 당신은 제품에 대해 끊임없이 틀립니다. 스택의 진짜 임무는 마음을 바꾸는 일을 값싸게 만드는 것입니다. 성숙하고 잘 문서화되었으며 큰 커뮤니티를 가진 도구는, 문제에 대한 답이 이미 존재하기에 빠르게 움직이게 해줍니다. 최첨단 도구는 당신을 버그를 발견하는 사람으로 만듭니다.

그것으로 채용할 수 있는가. 비주류를 고르면 당신의 미래를 그것을 만든 사람에게 묶게 됩니다. 흔하고 지루한 것을 고르면 다음 개발자, 다음 에이전시, 이어받을 다음 사람을 언제든 찾을 수 있습니다. 사업이 그것에 달려 있을 때 지루함은 장점입니다.

사람들이 말하는 것보다 훨씬 덜 중요한 것

순수 성능과 "확장성". 당신에게는 확장 문제가 없습니다. 정반대의 문제, 즉 아직 아무도 안 쓴다는 문제가 있습니다. 수백만 사용자를 위해 설계된 아키텍처는 사용자가 열한 명일 때 당신을 느리게 만듭니다. 당신이 따라 하는 유명 기업들은 먼저 단순한 버전을 만들고 나중에 — 성공으로 자금을 대어 — 다시 만들었습니다. 당신도 그래야 합니다.

올해 어떤 프레임워크가 "이기고" 있는가. 프레임워크는 유행의 주기를 따라 뜨고 지지만, 그것이 당신의 청구 SaaS를 잘 만들지와는 거의 관계가 없습니다. 주류이고 널리 쓰이는 선택지라면 어느 것이든 일을 해냅니다. 트렌드는 소음입니다. 지루하고 인기 있는 가운데에서 골라 앞으로 나아가십시오.

왜 "지루한" 기술이 대개 이기는가

경험 많은 제작자들 사이에는 신참이 실망하는 조용한 지혜가 있습니다. 새 사업에 가장 좋은 기술은 대개 지루하고 검증되었으며 약간 유행에 뒤진 종류라는 것입니다. 새 도구가 나빠서가 아니라, 당신이 내리는 모든 선택이 새로움의 한정된 예산 — 당신의 작은 팀이 한 번에 감당할 수 있는, 낯설고 지원되지 않으며 놀라운 것들의 수 — 을 소모하기 때문입니다.

그 예산은 당신의 사업을 특별하게 만드는 것 — 실제 제품, 당신만이 가진 통찰 — 에 쓰십시오. 그저 모던하게 느끼려고 아무도 들어보지 못한 데이터베이스에 쓰지 마십시오. 지루하고 성숙한 스택은 문제가 이미 풀려 있고, 문서가 존재하며, 채용이 쉽고, 유일한 유지보수자가 흥미를 잃어도 내년에 사라지지 않는다는 뜻입니다. 지루함은 모든 열정을 보상받는 곳 — 고객 — 에 쏟게 해줍니다.

여기서 AI가 그림을 조금 바꾸기도 합니다 — 다만 과대 광고가 암시하는 방식은 아닙니다. AI 코딩 보조 도구는 지루하고 인기 있는 기술에 훨씬 더 능합니다. 그것들에 관한 십 년 치 공개 답변으로 학습되었기 때문입니다. 주류 스택을 고르면 당신의 팀(그리고 도구)은 더 빠른 도움을 공짜로 얻습니다. 이색적인 것을 고르면, 가장 여력이 없는 바로 그때 홀로 남게 됩니다.

실제로 쓸 수 있는 결정 방법

원칙은 충분합니다. 직접 고르든, 프리랜서에게 의뢰하든, 에이전시의 제안을 평가하든, 결론에 이르는 구체적인 방법을 알려드립니다. 어느 것도 코드를 쓸 것을 요구하지 않습니다 — 올바른 것을 묻고 답을 저울질하기만 하면 됩니다.

1. 1
   기술이 아니라 팀에서 출발하라

   물으십시오. 앞으로 2년간 이것을 만들고 유지보수할 사람은 누구인가? 그들이 이미 잘 아는 것이 당신의 강력한 기본값입니다. 트렌드를 좇아 스택을 바꾸는 것이 능숙함을 이기는 경우는 드뭅니다.
2. 2
   기본값은 주류이고 검증된 것으로

   각 층의 인기 있고 잘 문서화된 가운데에서 고르십시오. 어떤 도구에 대한 튜토리얼, 채용 공고, 큰 커뮤니티를 빠르게 찾지 못한다면, 그것을 장점이 아니라 경고로 받아들이십시오.
3. 3
   확장이 아니라 변경에 최적화하라

   제품 수정을 값싸고 빠르게 만드는 선택을 선호하십시오. 당신은 제품에 대해 거듭 틀릴 것입니다 — 스택의 임무는 틀리는 일을 견뎌낼 수 있게 만드는 것입니다.
4. 4
   아키텍처를 가능한 한 단순하게 유지하라

   데이터베이스 하나. 백엔드 하나. 프런트엔드 하나. 실제로 측정된 문제가 손을 강요하기 전까지는 마이크로서비스도, 영리한 분산형의 그 무엇도 없이. 단순함은 타협이 아니라 목표입니다.
5. 5
   왜 그것을 골랐는지 적어두라

   한 단락이면 됩니다. 누가 만드는지, 무엇을 골랐는지, 다시 검토하려면 무엇이 바뀌어야 하는지. 이 메모는 누군가 과격한 견해를 읽을 때마다 결정을 다시 따지는 일에서 당신을 구해줍니다.

다른 어떤 것도 따르지 않더라도, 1단계와 4단계는 따르십시오. 가진 사람들로, 작동하는 가장 단순한 아키텍처 위에 만드십시오. 그 조합은 대부분의 첫 SaaS 제품을 침몰시키는 두 가지 실패 양식 — 유지보수할 사람이 없음, 그리고 규모에 비해 너무 복잡한 시스템 — 을 조용히 피합니다.

스택을 제안하는 사람에게 던질 질문

대부분의 창업자는 스택을 혼자 고르지 않습니다 — 개발자, 에이전시, 혹은 CTO인 친구가 제안합니다. 기술을 직접 검증할 필요는 없습니다. 몇 가지 질문을 하고 그들이 어떻게 답하는지 들으면 됩니다. 쉬운 말로 된 자신 있는 답은 좋은 신호입니다. 방어적인 전문 용어는 그렇지 않습니다.

• "왜 이것이고, 지루한 인기 선택지는 아닙니까?" — 좋은 답은 유행이 아니라 당신의 구체적인 필요에 관한 것입니다.
• "당신이 버스에 치인다면, 다른 사람이 이것을 얼마나 쉽게 이어받을 수 있습니까?" — 그 답은 선택이 얼마나 희귀하고 위험한지를 드러냅니다.
• "이 아키텍처에서 여전히 작동하는 가장 단순한 버전은 무엇입니까?" — 그들이 단순함으로 향하는지 복잡함으로 향하는지 보십시오.
• "이것을 위해 다음 개발자를 채용하기가 얼마나 쉽습니까?" — 흔한 기술은 건강한 시장을, 이색적인 기술은 의존을 뜻합니다.
• "석 달 뒤 핵심 기능을 바꿔야 할 때 무슨 일이 일어납니까?" — 변경이 값싸다는 말을 듣고 싶은 것이지, 두렵다는 말을 듣고 싶은 것이 아닙니다.

좋은 아이디어처럼 보이는 흔한 함정

몇 가지 패턴은 너무 자주 나타나서 이름 붙일 가치가 있습니다. 각각이 그 순간에는 책임감 있게 느껴지지만 나중에 큰 대가를 치르게 하기 때문입니다.

가지지 않은 규모를 위해 만들기. "제대로 하자"는 충동은 창업자가 열 명도 되기 전에 수백만 사용자를 위해 설계하게 만듭니다. 그 미래 대비의 한 조각 한 조각이, 결코 오지 않을지도 모르는 문제를 풀기 위해 지금 시간과 돈으로 치르는 복잡성입니다. 다음 백 명의 사용자를 위해 만드십시오. 성장이 그것을 필요로 할 때 다시 설계하고, 그것을 행복한 문제로 삼으십시오.

가장 새로운 것을 좇기. 지난달 출시된 반짝이는 프레임워크는 실적이 없고, 문서가 빈약하며, 커뮤니티가 아주 작습니다. 제품을 만드는 대신 도구를 디버깅하며 밤을 보내게 될 것입니다. 얼리 어답터는 다른 사람들에게 맡기십시오. 당신에게는 출시해야 할 사업이 있습니다.

가장 싼 사람에게, 그들이 선호하는 무엇으로든 외주 주기. 가장 낮은 입찰가는 흔히 그 한 팀만 아는 비주류 스택을 동반합니다. 갈라서는 날, 당신의 제품은 다른 누구도 닿을 수 없는 섬이 됩니다. 앞에서는 싸지만 나중에는 파멸적입니다. 외주를 줄 때조차 — 아니 외주를 줄 때야말로 — 주류이고 채용 가능한 기술을 고집하십시오.

정말로 스택을 재검토해야 할 때

이 가운데 어느 것도 "절대 바꾸지 말라"는 뜻이 아닙니다. 상상이 아니라 측정된, 진짜 이유로 바꾸라는 뜻입니다. 스택을 진화시킬 때가 정말로 되었음은 구체적인 신호가 나타날 때 알 수 있습니다 — 블로그 글이 당신을 불안하게 만들 때가 아니라요.

패턴을 알아채십시오. 진짜 이유는 당신의 실제 사업에서 측정된 고통에 관한 것입니다. 가짜 이유는 유행, 비교, 안절부절못함에 관한 것입니다. 진짜 신호가 정말로 나타나면, 한 번에 한 조각씩 바꾸십시오 — 모든 것을 여섯 달간 멈추는 영웅적인 재작성으로 스택 전체를 바꾸는 것이 아니라요. 혁명이 아니라 진화입니다.

자주 묻는 질문