Supabase CEO 폴 코플스톤이 공개하는 700만 개발자 플랫폼 구축의 비결. 제품-시장 적합성, 오픈소스 철학, 비동기 문화의 힘을 담았습니다.
Supabase를 만든 '자아 없는' 문화 | 폴 코플스톤 CEO 인터뷰
핵심 요약
- 우연한 성공: 처음에는 DDoS 공격으로 오인했던 데이터베이스 급증이 수백만 개발자을 지원하는 오픈소스 플랫폼으로 성장
- 제품-시장 적합성의 힘: 태그라인을 "오픈소스 Firebase 대체재"로 변경하자 해커뉴스 상단에 올라갔고, 이후 3배 성장
- 자아 없는 문화: 개인의 자존심보다 팀의 성공을 우선시하는 조직 문화가 경쟁력 있는 기업 구축의 핵심
- 비동기 근무의 혁신: 완전 분산 근무 방식으로 전 세계 천재들을 영입하고, 조직의 확장성 확보
- 개발자 경험 최우선: 가치 도달 시간(time to value)을 단축하고, 프로토콜 기반의 개방형 설계로 벤더 종속 회피
Supabase의 탄생: 운과 타이밍의 만남
Supabase의 시작은 매우 평범했습니다. 폴 코플스톤이 운영하던 회사가 한 고객으로부터 데이터베이스 출시 건수가 급증하는 현상을 경험했을 때, 처음에는 이것이 DDoS 공격이라고 생각했습니다. 하지만 이 현상은 시장이 요구하는 것이 무엇인지를 명확히 보여주는 신호였습니다.
폴은 이전에 여러 스타트업을 창업했지만, 그들은 Supabase만큼의 성공을 거두지 못했습니다. 그 이유를 되돌아보면, 성공적인 스타트업은 단순히 좋은 아이디어뿐만 아니라 시장 타이밍, 운, 그리고 충분한 야망이 모두 맞아떨어져야 한다는 것입니다. 초기 벤처들은 지역적 제약이 있었고, 마켓플레이스라는 한정된 영역에만 집중했습니다. 반면 Supabase는 처음부터 전 세계 개발자들을 대상으로 설계되었습니다.
Supabase로 가는 여정은 이전 국가 관리자의 제안에서 시작되었습니다. 그는 사무실 관리 도구를 만들자고 제안했지만, 폴은 자신이 개발자이며 개발 도구 회사를 시작하고 싶다고 명확히 했습니다. 그 관리자는 몇 년 동안 부업으로 아이디어를 구상하고 개발하는 데 전념할 것을 제안했고, 이것이 Supabase의 기초가 되었습니다.
폴은 이 기간 동안 이전의 모든 출시 경험에서 얻은 교훈을 기술 스택에 적용했습니다. 특히 두 번째 회사인 Nimbus에서는 Postgres와 Firebase를 함께 사용했는데, Firebase의 한계를 마주하면서 Postgres 위에 실시간 기능을 직접 구축하는 방법을 모색하게 되었습니다. Elixir와 Phoenix를 사용하여 구축한 이 솔루션은 오픈소스로 공개되었고, 해커뉴스에서 주목받기 시작했습니다. 이때 폴은 적절한 시기임을 깨달았고, 현재의 공동 창립자에게 연락하여 Y Combinator에 지원했습니다.
제품-시장 적합성: 메시징의 힘
초기 Supabase는 많은 불확실성 속에서 출발했습니다. 폴은 개발자들이 데이터베이스를 다루는 것이 얼마나 어려운지는 분명히 알고 있었지만, Postgres가 이렇게까지 성공하리라고는 예상하지 못했습니다. 예측할 수 없었던 것은 시장이 정확히 무엇을 원하는지였습니다.
진정한 턴어라운드는 태그라인 변경에서 비롯되었습니다. Y Combinator 초기에 해커뉴스에 어떤 사용자가 Supabase를 게시했는데, 폴이 태그라인을 "오픈소스 Firebase 대체재"로 변경한 바로 다음날이었습니다. 그 순간, 게시물은 즉시 해커뉴스 상단으로 올라갔습니다. 이는 제품-시장 적합성이 종종 제품 포지셔닝에 달려 있다는 중요한 교훈을 제공했습니다.
때로는 메시징을 바꾸는 것만으로도 큰 변화를 가져올 수 있습니다. 틈새 제품이라 할지라도 당신이 만드는 것을 원하는 사람들이 분명히 존재합니다. 중요한 것은 그들을 찾아 효과적으로 소통하는 것입니다. 해커뉴스 스레드에서 많은 사람들이 Firebase가 제공하는 인증(auth) 기능을 요청했고, Supabase는 Firebase의 대안으로 자리매김하고 있었기 때문에 인증 기능을 개발하는 것이 합리적이었습니다. 다만 다른 공급업체들과 달리, Supabase는 사용자 인증을 Postgres 데이터베이스에 직접 통합하여 더 우수한 제품을 만들 수 있었습니다.
Y Combinator 데모 데이 이전에 인증 제품을 성공적으로 출시했을 때, 차트의 기울기에서 상당한 변화가 있었습니다. 이를 통해 출시 전략이 효과적임이 분명해졌고, 데모 데이 이후 Supabase는 일주일 동안 매일 새로운 것을 출시하는 "론칭 위크"를 진행했습니다. 모든 것을 하나의 페이지로 통합하여 해커뉴스에 게시하는 방식이었습니다. 매번 출시할 때마다 성장이 꾸준히 20%씩 증가했습니다.
제품 전략: 대규모 고객 유지의 기술
Supabase가 직면했던 중요한 과제는 바로 "졸업 문제(graduation problem)"였습니다. Firebase에 대해 자주 듣는 비판은 주말 해킹이나 시작하기에는 훌륭하지만, 대규모 실제 프로덕션 워크로드에는 이상적이지 않아 결국 사람들이 마이그레이션하게 된다는 것입니다. Supabase는 처음부터 이 문제를 의식하고 있었습니다.
세대를 아우르는 데이터베이스 회사를 만들고 싶었던 Supabase는 "데이 제로(day zero)" 워크로드를 목표로 삼았습니다. 즉, 무엇을 만들지 완전히 알기도 전에 선택하게 되는 경우를 말합니다. Firebase와 MongoDB가 성공한 이유도 바로 이 점이었습니다. 따라서 Supabase는 먼저 "데이 제로" 경험에서 승리해야 했고, 이것이 "오픈소스 Firebase 대안"이라는 포지셔닝이 나오게 된 이유입니다.
처음에는 Postgres라는 점을 크게 홍보하지 않았습니다. 개발자들이 반드시 이해할지, 아니면 "Postgres는 싫고 MySQL을 원해요"라고 말할지 확신할 수 없었기 때문입니다. 시간이 지나면서 Postgres가 우세하다는 것이 분명해졌고, 태그라인을 "오픈소스 Firebase 대안"에서 "주말에 만들고 수백만 명에게 확장"으로 서서히 바꾸기 시작했습니다. 그리고 Postgres 밈을 만들고, Postgres에 대해 이야기하고, 개발자들에게 Postgres를 알리기 위해 할 수 있는 모든 것을 했습니다.
로드맵은 커뮤니티 요청과 기술적 비전이 결합된 형태였습니다. 순수한 기본 요소를 제공하는 방식으로 생각했지만, 커뮤니티가 엣지 함수(Edge Functions)를 강력하게 요구했고, 결국 출시할 수밖에 없었으며, 결과적으로 훌륭한 제품이 되었습니다.
개발자 경험: 가치 도달 시간의 단축
폴이 생각하는 개발자 경험의 핵심은 "가치 도달 시간(time to value)"입니다. 개발자가 막히지 않고 가능한 한 빨리 "아하!" 하는 순간에 도달하기를 원합니다. 나쁜 개발자 경험은 수많은 "잔고장(paper cuts)"으로 특징지어지며, 개발자들이 계속해서 막히게 됩니다.
좋은 개발자 경험이란 어떤 개발자의 목표든 그 목표에 가능한 한 빨리 도달할 수 있도록 돕는 것입니다. 이는 기술적인 역량뿐만 아니라 문서, 예제, 그리고 명확한 오류 메시지 등 모든 측면을 포함합니다. Supabase는 할 일 앱을 만드는 것과 같은 목표를 달성할 때, 서너 가지 문제에 부딪혀 포기하는 일이 없도록 설계되었습니다.
초기 Supabase는 매우 실험적이었습니다. 론칭 위크 때, 한 엔지니어는 Supabase Storage를 만들었는데, 출시 두 시간 전까지 클라이언트 라이브러리의 개발자 경험(DX)에 만족하지 못해 완전히 다시 작성했습니다. 이러한 완벽주의의 문화는 Supabase의 DNA에 깊게 박혀있습니다. 개발자들과 소통할 때는 아이디어를 주고받으며 완벽하게 통합된 스위트를 만들려고 노력했습니다.
하지만 대규모 비즈니스에서 새로운 것을 구축할 때는 확장성을 갖춰야 합니다. 청구 시스템이 필요하고, 강력한 보안 장치가 필요하며, 이 모든 것들은 무언가를 진정으로 출시하기 전에 고려해야 할 사항들입니다. 이제 Supabase는 더 구조화된 파이프라인으로 나아가고 있습니다. "랩스(labs)"에 제품을 출시하여 유기적으로 발견할 수 있는 소규모 사용자 그룹을 확보한 후, 플랫폼으로 자연스럽게 통합되기 시작합니다.
오픈소스 철학: 벤더 종속의 거부
Supabase가 개발하는 모든 것은 오픈소스입니다. 플랫폼 코드나 결제 관련 코드 등을 제외하고는 MIT, Apache 2 또는 Postgres 라이선스를 사용합니다. Supabase 스택을 원한다면 docker compose up 명령만으로 Supabase 경험을 얻을 수 있으며, 어떤 추적 기능도 없습니다. 사용하고 싶다면 무료로 사용할 수 있습니다.
폴과 공동 창립자 Ant는 오픈소스 철학에 동의합니다. 폴은 오픈소스를 사랑하고, Postgres 자체도 오픈소스이기 때문에, Supabase는 오픈소스에서 많은 것을 얻고 있으며, 생태계에 최대한 기여하고 싶습니다. 이는 전 세계의 많은 오픈소스 관리자들을 고용할 수 있다는 의미이며, 이것이 바로 좋은 일이라고 생각합니다.
벤더 종속을 적극적으로 피하고 프로토콜과 개방형 표준을 기반으로 구축 하려는 노력이 Supabase 제품 원칙에 명시되어 있습니다. 이는 문제가 발생했을 때, 예를 들어 Postgres PG 덤프 기능을 사용하여 데이터를 내보내고 다른 곳으로 옮길 수 있다는 의미입니다. 왜냐하면 그것은 고객의 데이터이기 때문입니다.
이러한 접근 방식은 Supabase가 우수한 경험을 구축하고 그 경험을 바탕으로 효과적으로 경쟁하도록 만듭니다. 때로는 이 원칙이 개발자 경험과 충돌할 수 있습니다. 때때로 Postgres 철학에 완전히 반하는 기능을 구현하고 싶을 때가 있기 때문입니다. 하지만 "Postgres 방식"을 고수하면서도 달성한다면, 거기에는 본질적인 우아함과 장인정신이 깃들어 있습니다.
온라인에서 사람들이 개방형 프로토콜과 기본 요소를 활용하면서도 놀랍도록 통합되어 마치 하나의 응집력 있는 제품처럼 느껴지는 플랫폼의 우아함을 높이 평가하는 것을 볼 수 있습니다. 이러한 결정들이 Supabase의 접근 방식을 크게 이끌어왔습니다.
스케일링의 도전: 성공의 대가
Supabase의 성장은 축복이자 저주였습니다. AI 앱 빌더 Bolt와 Lovable의 등장으로 새로운 성장 기회가 찾아왔습니다. 그들이 생성하는 모든 새로운 애플리케이션은 백엔드를 필요로 했고, 그들 중 다수가 Supabase를 선택했습니다. 현재 1000개 이상의 Y Combinator 기업들이 Supabase를 활용하고 있으며, 700만에서 800만 명의 개발자 사용자 기반을 지원하고 있습니다.
그러나 스케일링 과정은 매우 도전적했습니다. 폴은 초기에 제품-시장 적합성 없이 블리츠스케일링(급격한 확장)을 하지 않는 것의 가치를 배웠습니다. 하지만 Supabase에서는 처음 4~5년 동안 급한 문제가 생겼을 때만 채용한다는 생각을 유지했는데, 이는 과도한 작업량 문제로 이어졌습니다. 작년 중반, Supabase는 "좋아, 이건 누구도 감당할 수 없을 정도로 일이 너무 많아, 가능한 한 빨리 사람들을 채용해야 해"라고 판단했습니다.
초기 채용 철학이 충분한 업무 분담을 허용하지 않았기 때문에 회사 내 일부 직원들은 번아웃을 경험했습니다. 이는 내부적으로 "영웅 문화"로 이어졌는데, 소수의 개인만이 복잡한 문제를 해결할 수 있다고 느껴졌습니다. 폴의 개인적인 고통스러운 경험은 자신이 직접 하고 싶었던 일들을 놓아주는 것이었는데, 마치 자신의 레고를 포기하는 것과 같았습니다.
IP 주소 고갈이나 서버 용량 부족과 같은 문제들은 매우 도전적이며, 때로는 해결 불가능해 보였습니다. 고객 중심 회사로서, 특정 영역에서 훌륭한 성과를 내지 못하는 것은 폴에게 매우 고통스러운 부분입니다. 그럼에도 불구하고 현재 Supabase는 다음 1천만, 1억 명의 개발자로 확장할 수 있도록 보장하는 데 집중하고 있습니다.
자아 없는 문화: Supabase의 경쟁력
Supabase의 가장 독특한 특징 중 하나는 바로 "자아 없는(egoless)" 문화입니다. 사람들은 종종 이를 야망이 없다는 의미로 오해하지만, Supabase는 사실 매우 경쟁적입니다. 이는 오픈소스 정신, 특히 공개적으로 노력하고 코드를 무료로 공개하면서 최고 수준으로 만들고자 하는 구식 오픈소스 개발자들의 정신으로 귀결됩니다.
이는 설명하기 어렵고 찾기 어려운 특정 사고방식이지만, 오픈소스 생태계에는 분명히 존재합니다. Supabase는 이 정신을 회사 내에 담아내려고 노력했습니다. 면접 중에 과거 프로젝트, 문제 또는 갈등, 그리고 그것들을 어떻게 처리했는지 논의함으로써 이러한 특성을 종종 파악할 수 있습니다.
중요한 것은 지원자가 말하는 방식입니다. "나, 나, 나"만 이야기하는지, 아니면 팀과 팀을 우선시하는지에 대한 것입니다. 작은 단서들이 많이 있으며, 공동 창립자는 이러한 기준을 아주 잘 파악해냅니다. 폴이 이 점을 중요하게 생각하는 이유는 이 사업을 앞으로 30년 더 할 수도 있고, 그런 사고방식을 공유하는 사람들과 함께 일하고 싶기 때문입니다.
폴은 전통적으로 성공하고 야심 찬 CEO들 중 많은 이들이 매우 까다롭고 때로는 잔인하다는 것을 목격합니다. 하지만 그는 "밀물이 모든 배를 띄운다"는 철학을 믿습니다. 데이터베이스 분야는 모두에게 경이롭게 성장할 것입니다. 폴은 자신의 삶의 마지막에 돌아보면서, 중요한 회사를 만들었을 뿐만 아니라 사람들이 존경할 만한 방식으로, 자신만의 방식으로 해냈다고 생각하고 싶습니다.
Supabase의 가치 중 하나는 "부정할 수 없는(undeniable)" 것입니다. 즉, 너무 뛰어나서 누구도 부정할 수 없다는 뜻입니다. 하지만 "자아를 내세우지 않는" 부분이 가장 상위에 있으며, 어떤 사람은 "이렇게 성공적인 회사에서 자아를 내세우지 않는 것을 우선시하는 곳은 처음 본다"고 반응했습니다. 많은 사람들은 "부정할 수 없는" 문화와 "자아를 내세우지 않는" 문화가 상충된다고 믿지만, 폴은 그것이 사실이 아니라고 생각합니다.
비동기 근무: 글로벌 인재 수급의 전략
Supabase는 사무실 없이 완전히 분산된 팀으로 운영됩니다. 초기에는 코로나19 팬데믹 때문에 시작된 비동기 근무였지만, 이제는 회사의 초능력이 되었습니다. 비동기 작업에 모든 사람이 적합한 것은 아니며, Supabase는 이를 아주 일찍 깨달았습니다.
정말로 비동기 작업을 좋아하려면 특정 유형의 사람이어야 합니다. 만약 비동기 작업을 좋아하지 않는다면, Supabase도 좋아하지 않을 것입니다. 그것이 바로 상충 관계입니다. Supabase는 사람들에게 이 점을 명확히 하며, 이렇게 하면 잠재적으로 훌륭할 수 있지만 Supabase에서는 성공하지 못할 일부 인재를 놓칠 수도 있습니다.
완전 분산 근무 방식으로 전환하기로 결정했다면 어설프게 해서는 안 되며, 전적으로 몰입해야 합니다. Supabase는 완전히 비동기식 접근 방식으로 전환했으며, 이제는 이것이 팀의 초능력이라고 생각합니다. 모든 것이 Slack이나 Notion에 기록되고 캡처되기 때문에, 조직이 확장함에 따라 메트칼프의 법칙 문제를 해결합니다.
모든 것이 검색 가능하고 AI가 이 문제를 해결해 주었기 때문에, 최고재무책임자(CFO)가 "Multi-gress는 언제 출시되나요?"라고 물을 필요 없이, AI에게 타임라인을 물어볼 수 있습니다. 비기술직이라 할지라도 제품의 모든 복잡한 세부 사항을 이해하지 못할 수 있지만, AI에게 "재무적인 관점에서 설명해 줄 수 있나요?"라고 물어볼 수 있습니다. Supabase의 전체 역사와 모든 지식이 내장되어 있습니다.
채용 철학: 높은 기준의 유지
Supabase는 채용에 어려움을 겪은 적이 거의 없습니다. 브랜드는 많은 사랑을 받고 있고, 오픈소스이며, 개발자 도구이고, 완전 분산 근무를 합니다. 많은 경우, Supabase는 필요로 하는 도구를 만들고 있거나 저장소에 기여하고 있는 사람들을 발견했고, 그들이 놀라운 일을 하고 있다는 것을 알게 되면 그저 "저희와 함께 일하시겠어요?"라고 물었습니다.
또한 많은 전직 창업자들이 Supabase에서 일하고 싶다고 직접 찾아왔습니다. 5년 동안 자신의 회사를 운영하다 지쳐버린 한 전직 창업자가 기억나는데, Supabase는 그에게 자신의 사업에서 잠시 벗어나 Supabase의 넘쳐나는 일을 돕도록 초대했습니다. 그는 합류하자마자 즉시 활력을 되찾았습니다. 더 이상 제품 시장 적합성을 찾기 위해 고군분투할 필요 없이, 고객을 위한 멋진 기술적 문제 해결에만 집중할 수 있었기 때문입니다.
공동 창립자는 높은 기준을 유지하는 데 부지런하며, 최고의 인재를 선택할 때 중요한 원칙이 있습니다. Y Combinator에서 어떤 사람이 높은 주도성(agency)을 가진 사람을 고용해야 할지, 아니면 높은 성과(performance)를 가진 사람을 고용해야 할지 물었는데, 폴의 답변은 매우 명확합니다. 둘 다입니다. 이 두 가지 자질 중 어느 하나도 타협해서는 안 됩니다.
자금 조달: 건설자에서 자금 조달자로의 전환
초기 벤처에서 공동 창립자는 자금 조달에 탁월했고, 폴은 그에게서 많은 것을 배웠습니다. 중요한 교훈은 자금 조달 과정과 사업 구축 과정을 두 가지 별개의 노력으로 취급해야 한다는 것입니다.
개발자들과 이야기할 때는 보통 Supabase가 하는 일의 많은 부분을 축소해서 말합니다. 하지만 투자자들에게는 그러한 조심스러운 태도가 불리하게 작용합니다. 사실, 투자자들은 말하는 모든 것을 어차피 할인해서 들을 것입니다. 따라서 "10억 달러 규모의 회사가 될 것입니다"라고 말하면, 투자자들은 아마 "음, 겨우 5억 달러짜리 회사겠군"이라고 생각할 것입니다. "100억 달러"라고 말하면, "아, 겨우 10억 달러짜리 회사겠군"이라고 생각할 수도 있다는 거죠.
정말 중요한 것은 야심 차게 생각하면서도 그 목표에 도달할 것이라고 믿는 것입니다. 그 순서가 중요합니다. 야심 차게 생각하면서도 곧 그 목표에 도달할 것이라고 생각하는 것은 터무니없습니다. 하지만 현재 위치에서 목표까지의 단계를 신중하게 고려하고 명확하게 파악하는 것이 투자자에게 중요합니다. 투자자들은 그 야망이 실현 가능하다고 믿어야 하며, 발표자가 어떻게 달성할지에 대해 진정으로 고민했음을 확신해야 합니다.
폴은 자금 조달을 즐기지 않습니다. 사실 전혀 그렇지 않습니다. 정말 중요한 일에서 엄청난 방해가 되지만, 데이터베이스 회사에게는 매우 필수적인 부분입니다.
기업 고객: 제품-주도 성장에서 제품-주도 영업으로
Supabase는 초기부터 제품-주도 성장(PLG)에 매우 집중해 왔습니다. 하지만 최근에는 엔터프라이즈 고객도 중요해지고 있습니다. 이들이 무엇을 필요로 할지에 대해 많이 생각했으며, 특정 순서에 따라 진행되었습니다.
회사 유형을 생각해 보면, 은행과 같은 위험 회피적인 대기업부터 인디 개발자, 그리고 다양한 시작 단계의 사용 사례들이 있습니다. 은행의 시스템을 지원하는 것은 최상단에 있으며, 이는 프로덕션 워크로드를 대표합니다. Supabase는 인디 개발자와 기본적인 사용 사례로 시작하여 왼쪽 하단에서 출발했습니다.
이제 Supabase는 기업 고객이 유입되는 엔터프라이즈 모션도 가지고 있는데, 이는 영업 주도 성장(sales-led growth)에 가깝습니다. 하지만 영업팀의 그 부분에 대한 집중도는 10~20% 정도로 상당히 제한적입니다. 주된 초점은 사용자가 자발적으로 가입하고 신용카드 정보를 제공하는 순수한 제품 주도 성장(PLG) 모델에서 제품 주도 영업(product-led sales) 방식으로 전환하는 것입니다.
Supabase가 한 일은 PLG 모션에서 많은 신호를 포착하는 것입니다. 예를 들어, 누군가 데이터베이스 쪽에서 디스크를 과도하게 사용하거나 CPU 한계에 도달하고 있다면, 그들은 문제를 겪고 있을 가능성이 높습니다. 이러한 신호들을 "제품 트리거"로 식별하고, 특정 범주에 해당하면 자동화된 이메일 아웃리치를 보냅니다. 응답한 사람들의 코호트(집단)를 가져와 응답하지 않은 사람들과 사용량 증가를 비교하면, 응답하지 않은 사람들은 분기별로 약 25% 증가하지만, 성공 담당자와 소통한 사람들은 125% 증가하는 것을 알 수 있습니다.
3단계 성장: PGVector, AI 빌더, 그리고 CLI 중심의 미래
Supabase의 성장을 3단계로 나눌 수 있습니다.
1단계: 임베딩과 벡터의 시대
1단계는 모두가 데이터베이스 측면에서 임베딩, 즉 벡터와 임베딩에 관심을 갖기 시작한 시기였습니다. Supabase는 PGVector를 제공한 최초의 기업 중 하나였고, 사실상 최초였다고 생각하며, 이를 홍보하는 데 도움을 주었습니다.
2단계: AI 앱 빌더와의 시너지
2024년 말에는 Bolt와 Lovable과 같은 서비스가 출시되었는데, 그것 또한 흥미로운, 일종의 두 번째 순풍이었습니다. 사실 그때 Supabase는 DDoS 공격을 받고 있다고 생각했습니다. 왜냐하면 이 고객 또는 이 두 고객이 엄청나게 많은 데이터베이스를 출시하는 것을 보았기 때문입니다.
이 경험은 이렇습니다. 접속해서 "Supabase에 연결"을 클릭하면 데이터베이스 자격 증명이 반환되어 그 위에 구축할 수 있고, 백엔드를 통해 프롬프트를 입력하기만 하면 됩니다. 여러 번의 반복을 거쳤지만, 즉시 매우 강력한 성장을 보였습니다.
당시에는 심지어 내부적으로도 사람들이 "아, 이건 그냥 프로토타입이고, 감으로 코딩하는 거고, 허술한 부분이 많아"라고 말했습니다. 하지만 Supabase에게 명확했던 것은 초기에 가졌던 원칙이었습니다. 사람들이 시작할 때 그 자리에 함께하고, 그들이 떠나고 싶지 않게 만드는 것이죠.
3단계: AI 에이전트와 CLI 중심의 미래
3단계는 올해 1월부터 Claude Code, Codex 등 모든 것이 정말 빠르게 성장하고 있습니다. 이것들은 CLI MCP 유형의 워크로드를 더 많이 사용하는 도구이며, Supabase는 이들로부터 엄청난 채택을 보고 있습니다. 사실 YC에서 보았던 것과 같은 가속화가 일어나고 있는데, 이제는 700만~800만이라는 기반 위에서 일어나고 있습니다.
미래 비전: 자율 주행 데이터베이스
Supabase의 비전은 명확합니다. 3년이라는 시간 지평을 두고 생각할 때, 회사가 어떻게 진화할지를 중요하게 생각합니다. 좋은 예시로, Supabase가 시작했을 때는 회사가 대시보드 중심이었습니다. 개발자들이 들어와서 대시보드에서 데이터베이스를 실행하고 사용했죠.
이제 에이전트와 함께, 개발자들은 매우 CLI 중심이 되고 있습니다. Supabase가 원하는 것은 CLI를 사용하면 Supabase 폴더를 얻게 되고, 이 폴더는 플랫폼에 있는 모든 것을 순수하게 나타내야 한다는 것입니다. 즉, 코드 형태로, 본질적으로 폴더 안에 인프라스트럭처를 코드로 담는 것입니다. 여기에는 데이터베이스 스키마, 선언적 스키마가 포함되어야 합니다. 에이전트가 이해할 수 있도록 모든 것이 그 안에 있어야 합니다.
따라서 이는 가능한 모든 표면 영역에서 동등성을 확보한다는 의미입니다. 대시보드, CLI, MCP 등 모든 것이 일치해야 합니다. 그 결과로 무엇이 나올까요? 사람들은 Git에서 브랜치를 사용하고 싶어 합니다. 따라서 이미지용 버킷이든 데이터베이스든 모든 것이 브랜치 가능해야 합니다. 이러한 브랜치를 위해 매우 저렴하고 일시적인 테스트 환경을 갖춰야 합니다.
그리고 물론, 명백한 것들이 있습니다. 에이전트가 지금 구축하고 있다면, 미래에는 운영도 할 것입니다. 그래서 현재로서는 개발자들이 데이터베이스가 정상인지 아닌지 등을 확인하고 있을 수 있습니다. 하지만 물론, 개발자들은 아마도 그런 일을 하고 싶어 하지 않을 것이며, 대부분의 개발자들이 시간을 쓰고 싶어 하지 않는 부분이 바로 시스템의 상태를 확인하는 것입니다.
따라서 모든 면에서 일종의 자율 주행 데이터베이스를 갖춘 인프라를 구축하면, 성능, 안정성, 보안 등 모든 것이 본질적으로 에이전트에 의해 개선될 수 있으며, 그런 다음 개발자가 어디에 개입할지 선택할 수 있습니다.
카이젠: 점진적 개선의 철학
폴이 회사의 성공에 기여했다고 생각하는 가장 중요한 요소는 프로세스 관점에서 생각하는 것입니다. 많은 사람들이 결과물이나 고정된 지점에 초점을 맞추는 경향이 있지만, 폴은 거의 그렇게 생각하지 않습니다.
Supabase는 도요타 생산 시스템의 '카이젠(Kaizen)'이라는 개념을 적극적으로 활용합니다. 이는 모든 것을 점진적으로 개선한다는 의미입니다. 도요타에서는 이것이 CEO부터 조립 라인 작업자, 심지어 청소부에 이르기까지 적용되며, 그들은 자신의 일을 시스템적인 노력으로 보고 완벽을 추구합니다.
폴은 항상 모든 것을 변동하는 프로세스로 보는 이러한 운영 방식을 높이 평가합니다. 목표는 이러한 변동의 정도를 관리하여 비즈니스의 모든 측면에 통제 목표를 두는 것입니다. 오랫동안 폴은 카이젠 관점에서 생각해왔고, 제품 개발(작고 점진적인 개선을 자주 출시하는 것)부터 비즈니스 자체에 이르기까지 내부적으로 광범위하게 활용해왔습니다.
RFC 프로세스에 문제가 생기면 작은 변화를 줍니다. Supabase는 결코 "빅뱅" 방식의 변화를 추구하지 않습니다. 항상 점진적입니다. 비즈니스를 명확하고 독립적인 프로세스로 매핑할 수 있다면, 그것이 바로 현재 Supabase의 상태입니다. 예를 들어, 퍼널의 상단은 마케팅 또는 DevRel 팀에, 이탈(churn)은 제품 팀의 프로세스로 분리될 수 있습니다.
점점 더 Supabase는 시스템 관점에서 생각하기 시작하며, 시야를 넓히고 있습니다. 시스템은 전체 엔드투엔드 흐름을 포괄합니다. 예를 들어, 비즈니스의 작은 부분만을 자동화하는 것은 이점이 없습니다. 진정으로 중요한 것은 비즈니스의 전체 엔드투엔드 세그먼트가 완전히 자동화될 수 있도록 보장하는 것입니다.
중요한 점은 이렇습니다. 스타트업처럼 작은 생태계에서는 누구나 매우 빠르게 반복 작업을 할 수 있습니다. 하지만 성장함에 따라 가장 중요한 것은 전체 시스템 내에서 이러한 개선 주기를 갖는 것입니다.
결론: 자신의 방식으로 성공하기
폴이 없을 때 고객들과 팀원들이 Supabase와 자신에 대해 뭐라고 말해주기를 바랍니까? 폴의 대답은 매우 명확합니다. 팀에 대해서는, 자신에 대해 많은 말을 하지 않기를 바랍니다. 그들이 "우리가 해냈다"고 생각하기를 바랍니다.
Supabase가 성공한 이유는 단순하지 않습니다. 운, 타이밍, 올바른 팀, 그리고 불변의 원칙들이 모두 맞아떨어졌기 때문입니다. 하지만 가장 중요한 요소는 자아를 내세우지 않으면서도 최고의 기준을 유지하는 문화입니다. 개발자 중심의 사고, 오픈소스 철학에 대한 진정한 헌신, 그리고 계속해서 개선하려는 끊임없는 노력입니다.
폴은 자신의 삶의 마지막에 돌아보면서, 단순히 상당한 규모의 회사를 세웠을 뿐만 아니라 자신만의 방식으로, 그리고 자신이 존경하는 방식으로 해냈다고 생각하고 싶습니다. 그가 만들고 싶어 하는 것은 대규모 기업일 뿐만 아니라, 좋은 사람들이 성공하는 것을 볼 수 있는 그러한 조직입니다.
최종적으로, Supabase의 성공 비결은 기술이나 제품 자체만이 아닙니다. 그것은 사람들을 대하는 방식, 팀 문화의 구축, 그리고 자신의 가치를 타협하지 않으면서도 대규모로 성장하는 능력입니다. Supabase가 미래에도 계속해서 성공할 수 있을 것이라면, 이러한 기본 원칙들을 잃지 않기 때문일 것입니다.
Original source: The egoless culture that built Supabase | Paul Copplestone (Co-founder, CEO)
powered by osmu.app