Building Turbopuffer - Gergely Orosz × Simon Eskildsen
📺 원본 영상: Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-08-05
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 대담은 Turbopuffer 창업자이자 CEO인 Simon Eskildsen이 어떻게 Shopify의 대규모 인프라 경험을 바탕으로 S3 기반 벡터 검색 시스템을 만들게 되었는지를 추적한다. 표면적으로는 AI 인프라 회사의 창업기이지만, 실제 핵심은 “컴퓨터가 실제로 얼마나 빠를 수 있는가”를 숫자로 계산하고, 그 계산과 현실의 차이를 끝까지 파고드는 엔지니어링 태도에 있다.
Gergely Orosz는 대화를 통해 Simon의 성장 과정, Shopify에서의 장애 대응과 데이터베이스 확장 경험, Napkin Math 프로젝트, Cursor가 첫 고객이 된 과정, 그리고 Turbopuffer가 원격 조직과 벤처캐피털을 바라보는 방식을 차례로 끌어낸다. 이 리포트는 강연자의 설명을 바탕으로 기술적 구조와 창업 판단의 맥락을 서술형으로 재구성한 것이다.
PowerPoint에서 시작된 컴퓨터 감각
Simon Eskildsen의 컴퓨터 경험은 의외로 PowerPoint에서 시작된다. 그는 PowerPoint의 슬라이드 링크 기능을 이용해 복잡한 게임처럼 동작하는 구조를 만들 수 있었다고 회상한다. 특정 오브젝트를 클릭하면 다른 슬라이드로 이동하는 기능은 단순한 발표 도구를 넘어, 조건과 상태를 흉내 내는 작은 인터랙티브 시스템이 될 수 있었다. Simon은 이를 농담처럼 Turing-complete에 가까워진다고 표현했지만, 이 경험은 훗날 그가 시스템을 “안쪽에서 어떻게 움직이는가”라는 관점으로 바라보게 된 출발점이었다.
그다음 단계는 Microsoft FrontPage였다. FrontPage는 웹페이지를 시각적으로 만들 수 있게 해주는 도구였지만, Internet Explorer에서는 그럭저럭 보이던 페이지가 Firefox에서 깨지는 경험은 Simon에게 웹의 실제 구조가 시각 편집기 아래에 숨어 있다는 사실을 각인시켰다. 그는 우연히 HTML 화면을 열어보게 되었고, 이해할 수 없는 태그와 속성들을 보며 온라인에서 작은 코드 조각을 찾아 붙이기 시작했다. 커서 모양을 바꾸는 간단한 스니펫에서 출발한 호기심은 Dreamweaver, PHP, 동적 페이지 구현으로 이어졌고, 결국 더 깊은 프로그래밍 세계로 들어가는 문이 되었다.
흥미로운 점은 Simon이 영어권 개발 자료에 접근하기 위해 우회적으로 영어를 익혔다는 대목이다. 그는 덴마크어로 된 프로그래밍 자료를 거의 다 소비한 뒤 한계에 부딪혔고, 이후 World of Warcraft에 빠져 지내며 영어 실력을 키웠다고 말한다. 오늘날이라면 LLM이 덴마크어로 설명해 주었을 것이기 때문에 그런 벽을 덜 느꼈을 수 있다고도 덧붙인다. 이 발언은 단순한 회고가 아니라, 언어 장벽이 개발자 성장 경로를 어떻게 바꾸는지, 그리고 현재의 AI 도구가 학습 접근성을 얼마나 바꿔놓았는지를 보여준다.
대학 대신 Shopify로 간 고등학생
Simon은 고등학교 시절 International Olympiad in Informatics(IOI)를 접하면서 웹 개발과는 전혀 다른 유형의 문제를 풀기 시작했다. 그가 설명한 예시는 여러 트럭과 여러 패키지가 있을 때 어떤 패키지를 어느 트럭에 넣을지 최적화하는 문제다. 이는 현실적으로 NP-complete 성격을 띨 수 있는 문제이며, 정답을 완전하게 계산하기보다는 제한된 시간 안에 얼마나 좋은 해법을 찾느냐가 핵심이 된다. 이런 알고리즘 문제들은 HTML과 PHP로 웹페이지를 만들던 경험과는 달리, 추상화와 계산 복잡도에 대한 감각을 키워주었다.
Shopify와의 연결은 전형적인 채용 경로와 달랐다. Simon은 iPhone을 떨어뜨려 화면이 망가진 뒤 오래된 Nokia 휴대폰으로 돌아간 경험을 글로 썼고, 스마트폰이 일상에 미치는 영향에 대한 이 글이 Hacker News와 New York Times를 거치며 주목을 받았다. Shopify의 리크루터는 그 글을 보고 Simon에게 연락했고, 그는 아직 고등학생인 상태에서 캐나다 Ottawa에 있는 Shopify 사무실로 면접을 보러 가게 되었다. 그는 처음에는 1년짜리 갭이어처럼 생각했지만, 결국 2013년부터 2021년까지 8년 동안 Shopify에서 일하게 된다.
그가 대학에 가지 않은 결정은 단순한 반항이나 우연이 아니라, 이미 자신이 배우고 싶은 현장에 도착했다는 감각에서 비롯되었다. Simon은 컴퓨터공학을 정식으로 공부하지 않았다는 불안감을 갖고 있었고, 그 불안감은 오히려 학습 엔진이 되었다. Shopify에서 누군가 TCP, TLS, Wireshark 같은 용어를 언급하면 그는 종이에 적어두었다가 퇴근 후 직접 조사했다. 그 결과, 표면적인 개념 이해에서 멈추지 않고 프로토콜의 내부 구조와 시스템 계층까지 파고드는 습관이 형성되었다.
이 대목에서 Simon이 강조하는 엔지니어의 특성은 “층을 벗겨내고 싶어 하는 충동”이다. 그는 현재 Turbopuffer에서 엔지니어를 인터뷰할 때도 이런 태도를 본다고 말한다. 단순히 문제를 해결하는 능력보다, 왜 reverse proxy가 reverse인지, 왜 inverted index가 inverted인지 궁금해하며 용어와 구조의 배후로 들어가는 성향을 중요하게 여긴다는 것이다. 이런 성향은 이후 Shopify 인프라 팀에서의 경험과 Turbopuffer의 제품 철학으로 이어진다.
Shopify 인프라에서 배운 확장과 장애의 현실
Shopify는 2010년대에 빠르게 성장한 SaaS 기업 중 하나였고, Simon은 그 성장의 인프라 최전선에 있었다. 당시 Docker가 등장하면서 Shopify는 서비스를 컨테이너화하고 있었고, 매년 Black Friday와 Cyber Monday(BFCM)를 준비해야 했다. 그는 당시 성장률이 전년 대비 120~140% 수준이었다고 설명하며, 매년 이전보다 훨씬 큰 트래픽을 견디기 위한 하드웨어 주문과 소프트웨어 확장을 병행해야 했다고 말한다. 오늘날 클라우드가 무한해 보일 수 있지만, 물리 서버를 사전에 주문하던 시절에는 수요 예측과 용량 계획이 훨씬 더 직접적인 문제였다.
애플리케이션 계층의 확장 문제는 결국 데이터베이스 계층으로 돌아왔다. Shopify는 단일 shard로는 감당할 수 없는 지점에 도달했고, Black Friday를 불과 일주일 앞두고 sharding cutover를 수행했다. Simon은 이를 “믿기 어려운 일”이라고 표현하지만, 결과적으로는 성공했다. 이 경험은 대규모 시스템에서 데이터베이스가 단순한 저장소가 아니라 전체 서비스의 확장성과 장애 모드를 결정하는 중심축이라는 사실을 보여준다.
또 하나의 중요한 사례는 거대한 Redis 서버였다. 당시 128GB RAM을 가진 Redis 서버는 매우 큰 규모였고, 사람들은 그 안에 무엇이 들어 있는지 명확히 알지 못한 채 key-value store처럼 사용하고 있었다. 어느 날 이 Redis 서버가 장애를 일으키자, 조직은 특정 상태 저장 컴포넌트가 내려갔을 때 전체 서비스가 함께 무너지는 기본 실패 모드를 마주하게 되었다. Simon과 팀은 “이 서비스가 이 컴포넌트 장애 시 어떻게 동작해야 하는가”를 매트릭스로 정리했고, 세션 저장소가 내려가더라도 전체 Shopify storefront가 멈추지 않도록 장애 대응 방식을 설계했다.
이 과정에서 Simon은 단순한 mock 테스트로는 충분하지 않다고 판단했다. 그는 GDB를 통해 프로세스 내부로 들어가 데이터베이스 연결 file descriptor를 닫아버리는 방식으로 실제 연결 장애를 시뮬레이션하려 했다. 이 방식은 CI에 올리기에는 과격했지만, Rails와 MySQL 드라이버의 연결 계층 장애 처리 문제를 다수 드러냈다. 중요한 점은 이 실험이 “실패를 가짜로 흉내 내는 것”이 아니라, 애플리케이션이 의존하는 실제 하위 계층을 깨뜨려서 전체 스택이 어떻게 반응하는지 확인하려 했다는 데 있다.
Toxiproxy와 실패를 테스트 가능한 것으로 만드는 방법
GDB를 이용한 실험은 이후 Toxiproxy라는 도구로 발전했다. Toxiproxy는 애플리케이션과 데이터베이스 사이에 위치하는 프록시로, MySQL 같은 데이터베이스 프로토콜 자체를 깊게 이해하지 않더라도 네트워크 레벨에서 장애를 주입할 수 있게 해준다. 예를 들어 테스트 중 API 호출을 통해 데이터베이스를 느리게 만들거나, 연결을 끊거나, 특정 실패 조건을 재현할 수 있다. Simon이 강조한 핵심은 low-level driver를 mock하는 대신, 실제 드라이버와 프레임워크의 실패 처리 경로까지 함께 검증한다는 점이다.
12:59 - Toxiproxy를 통해 MySQL 장애나 지연을 주입하고 CI에서 실패 조건을 테스트하는 구조
이 접근은 대규모 시스템에서 특히 중요하다. 운영 환경에서 MySQL이 내려가면 엔지니어의 관심은 우선 복구에 쏠리기 때문에, 애플리케이션이 더 우아하게 실패할 수 있었는지를 실시간으로 분석하기 어렵다. 그러나 Toxiproxy를 CI에 넣으면, 장애가 발생하기 전부터 특정 컴포넌트가 내려갔을 때 checkout, session, page rendering 같은 경로가 어떻게 반응하는지 반복적으로 확인할 수 있다. Simon에 따르면 이 방식은 Shopify 생태계에서 수십 개의 문제를 찾아냈고, 여전히 Shopify의 CI에서 쓰이고 있을 가능성이 높다.
이 사례는 Turbopuffer의 기술적 성격을 이해하는 데 중요한 배경이 된다. Simon은 상태(state)가 있는 시스템의 어려움이 대부분 데이터베이스와 연결된다고 본다. Stateless service는 노드 장애나 부분 장애가 생겨도 상대적으로 고립될 수 있지만, 데이터베이스는 상태를 갖기 때문에 실패가 전체 서비스의 의미와 직접 연결된다. 따라서 좋은 인프라 엔지니어링은 빠른 정상 동작만 보는 것이 아니라, 상태 저장 계층이 깨졌을 때 어떤 일이 일어나는지를 먼저 모델링하고 테스트 가능한 형태로 만드는 일이다.
Napkin Math - 벤치마크보다 먼저 해야 할 계산
Shopify를 떠난 뒤 Simon이 계속 붙잡고 있던 프로젝트 중 하나는 Napkin Math였다. 그는 GitHub에 DRAM bandwidth, S3 round trip 비용과 지연시간, NVMe SSD bandwidth, EBS volume 비용과 성능, 메모리와 디스크의 GB당 비용 같은 숫자들을 표로 정리해두었다고 설명한다. 단순한 참고표가 아니라, 각 셀에 대해 flashcard를 만들어 외울 정도로 이 숫자들을 몸에 익혔다. 그 이유는 실제 인프라 의사결정에서 “벤치마크가 이렇게 나왔으니 database B를 쓰자”는 식의 판단이 너무 자주 등장했기 때문이다.
16:34 - Napkin Math 프로젝트에서 DRAM, S3, NVMe, EBS 비용과 성능 숫자를 표로 관리했다는 설명
Simon이 보기에 벤치마크는 필요하지만, 벤치마크만으로는 만족스러운 설명이 되지 않는다. 어떤 검색 쿼리가 세 개의 term을 검색하고, 각 term에 해당하는 document list를 읽고, 이를 intersect하는 작업이라면, 필요한 메모리 대역폭과 CPU 처리량을 기준으로 대략 몇 ms가 걸려야 하는지 먼저 계산할 수 있다. 이 계산이 10ms를 가리키는데 실제 벤치마크가 10초를 가리킨다면, 둘 중 하나가 틀렸거나 중요한 설명 변수가 빠진 것이다. 이때 해야 할 일은 데이터베이스를 즉시 바꾸는 것이 아니라, query plan, disk latency, distributed query fan-out, P99 latency 같은 요소를 추적해 계산과 현실의 차이를 좁히는 것이다.
17:54 - 검색 쿼리 성능을 DRAM bandwidth와 document list intersection 계산으로 추정하는 구간
그가 든 MySQL write throughput 사례도 같은 사고방식을 보여준다. 단순히 생각하면 write마다 fsync가 필요하고, fsync가 1ms 걸린다면 초당 1,000 writes가 상한처럼 보인다. 그러나 실제 작은 머신에서 MySQL은 초당 10,000 writes를 처리할 수 있었고, Simon은 그 이유를 파고들었다. 답은 batching이었다. fsync 하나가 단일 write만 persist하는 것이 아니라 더 큰 단위의 데이터를 함께 flush하기 때문에, 직관적인 계산보다 훨씬 높은 처리량이 가능했던 것이다. 그는 eBPF trace와 소스 코드 분석을 통해 이 차이를 확인했고, 이 경험은 “성능은 숫자와 구현의 대화”라는 그의 관점을 강화했다.
Napkin Math는 Turbopuffer의 핵심 철학과도 직접 연결된다. 시스템이 이론적으로 얼마만큼 빨라야 하는지, 어느 저장 계층이 어떤 비용 구조를 갖는지, 어떤 latency percentile을 기준으로 설계해야 하는지를 모르면 인프라 제품을 만들 수 없다. Simon은 완벽한 논문식 모델을 먼저 세우기보다, 실제 기계가 제공하는 비용과 성능의 경계선을 손으로 계산하고, 그 경계선에 최대한 가까이 가는 구현을 선호한다. Turbopuffer는 바로 이 계산 습관에서 출발한 제품이라고 볼 수 있다.
검색 시스템에 대한 불만이 벡터 데이터베이스로 이어지다
Simon이 Shopify에서 마지막으로 맡았던 프로젝트는 search였고, 그는 그 경험이 좋지 않았다고 말한다. 특정 전통적 검색 데이터베이스를 사용했지만, Napkin Math로 계산한 성능 기대치와 실제 시스템의 성능이 자주 맞지 않았다. 그는 query planner가 왜 그런 선택을 하는지, 왜 어떤 때는 성능이 설명되고 어떤 때는 전혀 설명되지 않는지 이해하기 위해 소스 코드까지 읽었지만, 끝내 충분히 납득할 수 없었다고 한다. 이 경험은 그가 검색 시스템이라는 문제 영역을 다시 생각하게 만든 첫 번째 계기였다.
두 번째 계기는 앞서 언급한 Napkin Math 프로젝트였고, 세 번째 계기는 Shopify를 떠난 뒤 여러 친구 회사에 “angel engineering” 방식으로 참여하며 반복적으로 마주한 문제였다. 그는 단순히 돈만 투자하는 대신, 지분을 받고 직접 엔지니어링 문제를 해결하는 방식으로 여러 스타트업을 도왔다. 2022년 ChatGPT가 등장한 뒤 많은 회사가 문서를 AI에 연결하려 했고, 당시 context window가 4K 또는 8K 토큰 수준으로 매우 작았기 때문에 검색은 빠르게 필수 구성요소가 되었다. LLM에 모든 문서를 넣을 수 없으니, 관련 문서를 찾아 넣는 retrieval 계층이 필요했던 것이다.
Readwise 사례는 Turbopuffer 탄생의 직접적인 동기였다. Simon은 Readwise의 사용자 저장 글을 기반으로 추천 엔진을 만들었고, 추천 품질은 놀랄 만큼 좋았다고 설명한다. 그러나 이를 모든 사용자에게 제공하기 위한 비용을 계산해보니 월 3만 달러 수준이었고, 당시 Readwise가 전체 인프라에 쓰던 비용이 월 5천 달러 정도였기 때문에 경제성이 맞지 않았다. 좋은 기능이라도 gross margin을 망가뜨리면 제품으로 출시하기 어렵다. 그는 결국 해당 기능 대신 PostgreSQL autovacuum 튜닝 같은 다른 작업을 하게 되었지만, “왜 이 벡터들을 저장하는 것이 이렇게 비싼가”라는 질문을 떨칠 수 없었다.
그 질문의 끝에서 S3가 등장했다. Simon은 벡터를 S3에 저장하고 clustering을 통해 파일을 구성하면 훨씬 낮은 비용으로 검색할 수 있지 않을까를 계산했다. S3는 내구성과 비용 면에서 강력하지만 latency가 문제였고, 특히 256KB 또는 512KB object에 대한 P99 latency가 약 200ms 수준이라고 설명한다. 벡터 검색은 여러 object를 읽어야 하므로 평균 latency보다 P99, 경우에 따라 P999까지 고려해야 한다. 그는 2023년 여름 내내 이 문제를 붙잡고 여러 접근을 시도했고, 2023년 7월 end-to-end로 작동하는 버전을 만들었으며, 2023년 10월 첫 버전을 공개했다.
24:47 - S3 object의 P99 latency가 약 200ms 수준이라는 점을 바탕으로 시스템 설계 제약을 설명하는 구간
S3 위에 세운 가장 단순한 벡터 검색 구조
Turbopuffer의 첫 버전은 정교한 LSM-tree 구현이나 방대한 논문 구현체가 아니었다. Simon은 LSM 관련 문헌을 일부 읽었지만, 완전한 구현에 매몰되기보다 가장 단순한 형태의 시스템을 먼저 만들었다고 말한다. 기본 아이디어는 벡터에 clustering algorithm을 적용해 cluster를 만들고, 각 cluster를 파일로 저장한 뒤, 별도의 centroid 파일을 유지하는 방식이었다. 검색 시에는 먼저 centroid 파일을 다운로드해 query vector와 가까운 cluster를 찾고, 그다음 가장 가까운 cluster 파일들을 내려받아 실제 검색을 수행한다.
27:15 - cluster 파일과 centroid 파일을 이용한 Turbopuffer 초기 벡터 검색 구조
이 구조의 장점은 object storage의 경제성을 활용하면서도 검색 범위를 줄일 수 있다는 데 있다. 모든 벡터를 매번 읽는 대신 centroid를 통해 필요한 cluster만 선택하면, S3에 있는 대량의 cold data를 저렴하게 보관하면서 hot query에 필요한 데이터만 가져올 수 있다. 다만 S3 latency는 여전히 크기 때문에, round trip 수를 줄이고 인접 cluster를 같은 파일에 병합하는 식의 비용 및 성능 최적화가 필요했다. Simon은 이 첫 버전이 “가장 단순하게 가능한 형태”였다고 반복해서 강조한다.
초기 성능 개선도 매우 실용적이었다. 그는 자체 caching layer를 구현하지 않고, nginx reverse proxy를 S3 앞에 두어 object를 캐시했다. 삭제 처리는 xargs로 캐시 파일을 지우고 nginx의 디렉터리 구조를 reverse engineering하는 방식에 가까웠다. 지금 기준으로 보면 거칠고 임시적인 접근이지만, Simon에게 중요한 것은 해당 구조가 실제 사용자 문제를 해결할 수 있는지 빠르게 확인하는 것이었다. 첫 버전은 GCP의 8-core node 하나 위 tmux session에서 돌아가는 수준이었고, 그는 누군가 실제로 관심을 보이면 그때 더 제대로 만들겠다는 태도로 출시했다.
이 선택은 데이터베이스 제품에 대한 일반적인 기대와 다르다. 많은 데이터베이스 엔지니어라면 내부 완성도에 대한 자부심 때문에 이런 초기 제품을 공개하지 않았을 수 있다. 그러나 Simon은 데이터베이스도 SaaS처럼 출시하고 학습할 수 있다고 보았다. 핵심 invariant, 즉 VM이 모두 내려가도 데이터가 사라지지 않고 write가 object에 직접 commit된다는 안정성은 지키되, 내부 구현은 가장 단순한 형태로 시작한 것이다. 이 균형이 Turbopuffer를 단순한 장난감이 아니라 실제 고객을 받을 수 있는 MVP로 만들었다.
💡 [영상 참조] 강연자는 이 구간에서 S3 기반 벡터 검색 구조, cluster 파일, centroid 파일, 캐싱 방식을 구두로 설명합니다. 화면에 표시된 구조도나 세부 구현은 STT에 포함되어 있지 않으므로, 상세 시각 자료는 원본 영상을 확인하세요.
Cursor가 첫 고객이 된 이유
Turbopuffer의 첫 고객은 Cursor였다. Simon은 Twitter에 “백만 개 벡터를 1달러에 처리할 수 있다”는 식으로 제품을 공개했고, 당시 실제로 동작하는 대안 중 가장 저렴한 수준이 백만 벡터당 100달러 정도였다고 설명한다. 이 가격 차이는 단순한 할인 전략이 아니라, DRAM 중심 벡터 저장 구조와 object storage 중심 구조 사이의 unit economics 차이를 반영한다. Cursor는 당시 빠르게 성장하고 있었고, 코드베이스 검색과 AI 기능을 위해 벡터를 대량으로 다뤄야 했기 때문에 이 문제를 누구보다 절실하게 느끼고 있었다.
Simon은 Cursor 창업자들이 아마도 “자주 쓰는 codebase는 메모리에 두고, 나머지는 S3 같은 object storage에 두면 되지 않을까”라는 생각을 이미 하고 있었을 것이라고 추정한다. 그는 이것이 실제로 있었던 저녁 대화인지, 특정 창업자의 머릿속에 있던 생각인지는 모른다고 전제하면서도, Turbopuffer가 그들이 찾던 패턴에 정확히 들어맞았다고 설명한다. Cursor는 당시 약 8명 규모의 작은 회사였지만, 이미 제품 사용량은 빠르게 늘고 있었고 기존 인프라 비용은 감당하기 어려워지고 있었다.
결정적인 장면은 Simon이 San Francisco의 Cursor 사무실에 직접 찾아간 순간이다. 그는 B2B sales를 잘 몰랐지만, 단순히 그들을 돕고 싶다는 마음으로 방문했다. 마침 Cursor는 PostgreSQL 또는 AWS Aurora 관련 문제를 논의하고 있었고, Simon은 pgAnalyze를 설정하고 autovacuum이 충분히 돌지 않아 heap scan이 발생하는 문제 등을 함께 살폈다. 그는 이를 두고 자신의 “database genes”가 작동했다고 표현한다. 제품을 팔기 전에 고객의 실제 데이터베이스 문제를 도와준 이 행동이 신뢰를 만들었고, Cursor는 Turbopuffer로 마이그레이션하기로 결정했다.
Simon은 Cursor의 비용을 95% 낮추겠다고 약속했고, 실제로 이전 vendor의 마지막 청구서와 Turbopuffer의 첫 청구서를 비교했을 때 95% 절감이 이루어졌다고 말한다. 이는 단순한 가격 인하가 아니라 아키텍처 선택의 결과였다. 모든 벡터를 비싼 메모리 계층에 상주시킬 필요가 없고, object storage와 cache를 조합해 workload의 hot/cold 특성을 활용하면 비용 구조 자체가 달라진다. Cursor 입장에서는 작은 스타트업의 핵심 인프라에 또 다른 작은 스타트업을 쓰는 비합리적 위험을 감수한 셈이지만, Simon과 Justine이 보여준 기술적 신뢰가 그 위험을 받아들일 수 있게 만든 것이다.
GPU 시대에 다시 중요해진 CPU
Turbopuffer는 AI 인프라 회사이지만, Simon은 대담에서 GPU보다 CPU를 더 많이 이야기한다. 그는 NVIDIA 행사에서 Jensen Huang 앞에서 Turbopuffer를 소개한 일화를 들려준다. 회사 이름에 대해 “모든 것이 잘못되면 vape 사업으로 pivot할 수 있다”고 농담하자, Jensen이 슬라이드를 보고 “그럴지도 모르겠다”는 취지로 받아쳤고, Simon은 당황한 끝에 Jensen에게 vape를 하느냐고 되물었다. 이 일화는 가벼운 농담처럼 보이지만, 이어지는 대화에서는 Turbopuffer가 CPU, SIMD, AVX-512 같은 범용 연산 자원을 중요하게 본다는 점이 드러난다.
36:52 - NVIDIA 행사에서 Jensen Huang이 Simon의 슬라이드에 반응한 일화
AI 붐에서 병목으로 주로 언급되는 것은 GPU이지만, Simon은 CPU도 더 이상 쉽게 구할 수 있는 자원이 아니라고 말한다. Reinforcement Learning(RL) workload가 커지면서 모델이 검색, grep, bash 실행, 실제 환경 조작 등을 배우기 위해 많은 CPU가 필요해지고 있기 때문이다. 또한 agentic workflow는 GPU에서 모델 inference만 수행하는 것이 아니라, 다양한 일반 목적 작업을 CPU 위에서 실행한다. AI가 더 많은 실제 업무 영역에 적용될수록, 각 도메인에 맞는 RL 환경을 더 많이 띄워야 하고, 이는 다시 CPU 수요를 밀어 올린다.
Turbopuffer 역시 이 경쟁의 한가운데에 있다. 회사는 많은 CPU와 NVMe SSD, S3를 필요로 하며, 동시에 Turbopuffer의 고객들도 같은 cloud provider에서 CPU allocation을 놓고 경쟁한다. Simon은 cloud가 작은 규모에서는 무한해 보일 수 있지만, 일정 규모를 넘어서면 지역별 전력, 신규 CPU 배치, instance type별 allocation 같은 현실적 제약이 드러난다고 설명한다. Shopify 시절 BFCM을 앞두고 몇 달 전에 cloud provider와 사용량 commit을 논의했던 경험은, 현재 AI 인프라 시장에서도 반복되고 있다.
Turbopuffer가 가진 장점은 특정 instance type 하나에 강하게 묶이지 않는다는 점이다. Simon은 GCP의 C4, Z3, ARM C4A 같은 machine type을 언급하며, 회사가 다양한 SKU에서 잘 동작하도록 최적화하고 있다고 말한다. 이는 단순한 비용 최적화가 아니라 공급망 리스크를 줄이는 아키텍처 전략이다. 특정 CPU나 region에만 의존하면 고객 수요가 늘어날 때 확장성이 막히지만, 여러 instance family와 cloud region을 활용할 수 있으면 부족한 자원을 더 유연하게 흡수할 수 있다.
벤처캐피털을 바라보는 비실리콘밸리식 관점
Simon의 자본 조달 관점은 Silicon Valley의 전형적인 성장 서사와 거리가 있다. Turbopuffer의 초기 가격은 Cursor의 비용을 월 4천 달러 수준으로 낮출 수 있다는 napkin math에서 출발했다. 문제는 그 당시 소프트웨어가 아직 충분히 효율적이지 않았다는 점이다. 신뢰성은 있었지만 구현은 단순했고, Simon과 공동창업자 Justine은 월급을 받지 않으면서 GCP 비용까지 직접 부담하고 있었다. 그럼에도 그는 “Cursor가 내는 돈보다 GCP 청구서가 낮아야 한다”는 아주 기본적인 사업 감각으로 회사를 운영하려 했다.
그는 자신이 Aarhus, Ottawa, Canada, San Francisco라는 여러 단계의 외부자였다고 표현한다. 이는 자본 조달을 바라보는 방식에도 영향을 주었다. Simon은 벤처캐피털을 받는다는 것은 웃으며 악수하는 것 이상으로, pension fund를 포함한 자본의 전체 stack이 특정 timeline 안에 큰 return을 기대한다는 의미라고 본다. 초기에는 Turbopuffer가 billion-dollar company가 될 수 있는지 확신하지 못했기 때문에, 섣불리 큰돈을 받는 것이 맞는지 판단할 수 없었다.
그가 처음 자금을 조달하려 한 이유는 명확했다. IOI 시절부터 알고 지내던 뛰어난 엔지니어 Boyan과 함께 일하고 싶었지만, 그를 고용할 현금이 부족했다. Simon은 Silicon Valley에서 알고 있던 투자자 Lachy에게 연락해 약 70만 달러를 조달할 수 있는지 물었다. 목적은 창업자들이 여전히 급여를 받지 않더라도 1년 동안 두 명의 엔지니어를 고용하고, 연말까지 product-market fit과 시장 규모에 대한 학습 속도를 높이는 것이었다. 만약 큰 기회가 아니라고 판단되면 회사를 접고 남은 돈을 돌려줄 생각이었다고 그는 말한다.
이런 발언은 일부 VC에게 낮은 야망처럼 들렸을 수 있지만, Simon에게는 게임의 규칙을 모를 때 카드를 공개하고 대화하는 방식이었다. 이후 Turbopuffer는 그해 수익성을 확보했고, 계속 채용을 이어갔다. 그는 자본 조달의 이유를 여섯 가지로 정리한다. R&D funding, growth funding, founder ego, employee reward, strategic partnership, M&A가 그것이다. 다만 그는 특히 founder ego를 위험한 이유로 본다. 큰 round와 press는 창업자에게 status game이 될 수 있지만, 동시에 기존 직원의 지분을 희석하고 미래 직원의 upside 가격을 바꾸기 때문이다. Turbopuffer가 첫 번째로 자금을 받은 이유는 R&D였고, 두 번째 이유는 직원들이 IPO 같은 먼 event를 기다리지 않고 일부 equity를 현금화할 수 있게 하기 위한 liquidity 제공이었다.
49:13 - 자본 조달의 여섯 가지 이유를 분류하며 R&D, growth, founder ego, employee liquidity 등을 설명하는 구간
원격 조직은 오프라인의 부재가 아니다
Turbopuffer는 원격 조직으로 시작했고, 지금도 원격 문화를 유지한다. Simon은 Shopify 인프라 팀도 초창기부터 원격에 가까웠기 때문에, distributed model이 자신에게 자연스러웠다고 설명한다. 다만 데이터베이스 회사를 빠르게 만들 수 있는 도시가 San Francisco나 New York 정도라고 느꼈기 때문에, 그 도시들에 모이지 않을 것이라면 distributed model에 완전히 진지하게 접근해야 한다고 보았다. 여기서 중요한 점은 원격이 곧 대면 만남의 부재를 의미하지 않는다는 것이다.
Turbopuffer는 1년에 두 번 전체 offsite를 열고, Banff나 Mexico City 같은 장소에서 팀이 함께 시간을 보낸다. 여기에 더해 “campfire”라는 개념을 운영한다. 몇 명의 직원이 특정 도시에 우연히 모이게 되면 그것을 campfire로 부르고, 원하는 사람은 누구든 합류하도록 장려한다. 예를 들어 Simon이 San Francisco conference에 참석하면, 그 주의 San Francisco는 Turbopuffer campfire가 되고, 팀원들은 고객 미팅이나 dinner에 함께 참여할 수 있다.
이 방식은 모든 사람에게 같은 수준의 travel을 요구하지 않는다. 어떤 직원은 1년에 두 번 offsite에만 참석하고 나머지 시간은 가족과 함께 집에서 집중해 일한다. 반대로 어떤 직원은 2주마다 비행기를 타며 고객과 팀을 만난다. Simon은 New York에서 campfire가 열렸다는 것을 보고 Ottawa에서 바로 공항으로 가 New York으로 날아온 직원의 사례를 소개한다. 조직은 이런 행동을 강제하지 않지만, 원하는 사람에게는 자연스럽게 팀과 고객을 만날 수 있는 구조를 제공한다.
Turbopuffer는 이를 더 장려하기 위해 “turbo credit”이라는 제도도 만들었다. conference talk, blog post, 고객-facing 활동처럼 업무 외적이지만 회사에 중요한 기여를 하면 turbo credit을 받고, 이를 다음 비행기 business class upgrade에 쓸 수 있다. Simon은 이것이 나중에는 중앙은행, 이자율, betting market 같은 장난스러운 내부 경제로 발전할 수도 있다고 농담한다. 그러나 제도의 핵심은 분명하다. 원격 조직이 빠르게 움직이려면 문서와 비동기 커뮤니케이션만으로는 부족하고, 구성원이 자발적으로 만나고 고객을 접할 동기를 설계해야 한다.
마무리 / 핵심 정리
이 대담의 중심에는 AI라는 단어보다 엔지니어링 태도가 더 크게 자리 잡고 있다. Simon Eskildsen은 PowerPoint와 FrontPage에서 시작해 Shopify의 대규모 인프라, 장애 주입 테스트, 데이터베이스 확장, Napkin Math를 거쳐 Turbopuffer를 만들었다. 그의 일관된 방식은 추상적인 유행을 좇는 것이 아니라, 실제 기계의 비용과 성능을 계산하고, 계산과 현실이 어긋나는 지점을 끝까지 추적하는 것이다.
Turbopuffer의 흥미로운 점은 벡터 데이터베이스를 “AI 시대의 필수 인프라”라는 마케팅 언어로만 설명하지 않는다는 데 있다. 오히려 이 회사는 S3의 저렴한 내구성, CPU와 NVMe의 실제 처리량, P99 latency의 누적 효과, cache의 hot/cold 분리 같은 오래된 시스템 설계 문제를 AI workload에 맞게 재조합한다. Cursor 사례는 이런 접근이 단지 기술적으로 아름다운 아이디어가 아니라, 고객의 비용을 95% 줄이는 실질적 사업 가치로 이어질 수 있음을 보여준다.
또한 Simon의 창업 철학은 단순함과 정직함에 가깝다. 그는 완벽한 데이터베이스를 만든 뒤 출시한 것이 아니라, 핵심 invariant를 지키는 가장 단순한 제품을 먼저 공개했고, 고객이 나타나자 빠르게 학습하며 개선했다. 자본 조달에서도 큰 숫자와 press를 목표로 삼기보다, R&D 학습 속도와 직원 보상을 중심에 두었다. 이 대화가 남기는 가장 큰 takeaway는 기술 스타트업의 경쟁력이 특정 알고리즘 하나에서만 나오지 않는다는 점이다. 깊게 파고드는 학습 습관, 실패를 테스트하는 문화, 숫자로 검증하는 직관, 고객에게 직접 도움을 주는 태도가 결합될 때, 작은 팀도 거대한 인프라 시장에서 의미 있는 균열을 만들 수 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO) |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-08-05 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.