Building Turbopuffer: Gergely Orosz × Simon Eskildsen (CEO)

URL: https://www.youtube.com/watch?v=jQDXzEVHMSE 날짜: 2026-08-03 채널: AI Engineer (aiDotEngineer 컨퍼런스) 발표자: Simon Eskildsen (Turbopuffer 창업자 겸 CEO, 前 Shopify 인프라 엔지니어) × Gergely Orosz (The Pragmatic Engineer 저자, 진행자)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Turbopuffer는 어떻게 ==S3 위에 올린 "말도 안 되게 단순한 MVP"에서 출발해, Cursor 같은 대형 AI 기업의 핵심 벡터 검색 인프라로 성장==했는가. 그리고 그 배경에는 엔지니어링 실력만큼이나 ==호기심을 끝까지 파고드는 태도, 극단적 단순함 추구, 벤처캐피탈에 대한 자기 나름의 원칙==이 있었다.

• Shopify 8년 인프라 경험(샤딩, 장애 시뮬레이션, ToxiProxy)이 "napkin math(냅킨 계산)"라는 직관적 성능 추정 습관으로 이어졌고, 이게 Turbopuffer 설계의 기반이 됐다
• 창업 초기엔 회사가 아니라 "호기심을 해소하는 프로젝트"였고, 단일 서버·리버스 프록시 캐시만으로 트위터에 공개한 MVP가 Cursor라는 첫 고객을 데려왔다
• 벤처캐피탈 조달에 대해 "자본을 조달하는 6가지 이유"라는 독자적 프레임을 갖고, 그중 명확한 이유(R&D, 직원 유동성)가 있을 때만 자금을 받았다

Simon Eskildsen은 덴마크 출신으로 정규 컴퓨터공학 교육 없이 고등학생 때 Shopify에 합류해 8년간 인프라 팀에서 성장했고, 2023년 벡터 검색 데이터베이스 Turbopuffer를 창업해 Cursor의 첫 고객이자 핵심 인프라 파트너가 됐다.

---

1. 컴퓨터와의 첫 만남 — 정규 교육 없이 실력을 쌓은 과정

Simon은 대학 진학 대신 실전에서 부딪히며 컴퓨터를 배웠고, 이 경험이 이후 "궁금하면 끝까지 파고든다"는 태도의 뿌리가 됐다.

1.1. 파워포인트에서 시작된 프로그래밍

1. 파워포인트의 튜링 완전성
   1. 클릭 슬라이드 전환 게임: 파워포인트에서 도형을 클릭하면 다른 슬라이드로 이동하는 기능을 조합해 복잡하고 뒤엉킨 게임을 만들 수 있음을 발견 — 이것이 튜링 완전한 시스템이 됨
   2. Front Page로의 이행: 이후 Microsoft Office 스위트를 거치며 웹사이트 제작 도구 Front Page를 발견. Front Page는 "프론트엔드 개발자가 필요 없게 만들겠다"는 목표로 나온 도구였지만 Internet Explorer에서만 제대로 동작했음
   3. 호환성의 배신: 만든 사이트를 누군가 Firefox에서 열어보자 레이아웃이 완전히 깨지는 경험(heartbreak)을 함
2. HTML을 우연히 발견하며 심화
   1. HTML 소스 노출: Front Page에서 실수로 HTML 보기 버튼을 눌렀다가 알 수 없는 코드 더미를 보게 됨. 이후 온라인에서 커서 모양을 바꾸는 등의 작은 스니펫을 찾아 조합하며 점점 깊이 들어감
   2. Dreamweaver → PHP: Dreamweaver로 코딩을 시작했고, "페이지를 동적으로 만들려면 어떻게 해야 하나"라는 질문에서 PHP를 독학. 11~12세 무렵 덴마크어로 된 프로그래밍 자료를 모두 소진해버림

1.2. 게임과 국제정보올림피아드(IOI)를 통한 성장

1. 월드 오브 워크래프트로 영어 습득
   1. 의도치 않은 언어 학습: 덴마크어 자료가 바닥나자 4년간 월드 오브 워크래프트에 몰두했는데, 이것이 영어 실력을 크게 늘려준 계기가 됨(웃음 포인트로 언급)
2. International Olympiad in Informatics(IOI) 발견
   1. 호주 친구를 통한 우연한 발견: 호주 국가대표팀 소속 인터넷 친구를 통해 이 대회의 존재를 알게 됨. 그전까지 정보올림피아드라는 개념 자체를 몰랐음
   2. 알고리즘 문제의 낯섦: 기존에 풀던 HTML/PHP 문제와 전혀 다른 알고리즘 문제(예: n대의 트럭에 m개의 짐을 최적 배치하는 NP-complete 유형 문제)를 접하며 새로운 영역에 눈을 뜸

---

2. Shopify 합류와 8년간의 인프라 커리어 (2013~2021)

고등학생 시절 우연한 계기로 Shopify에 합류해, 스스로 "불안감"을 동력 삼아 인프라의 밑바닥까지 파고드는 학습 습관을 만들었다.

2.1. Shopify에 발탁된 계기 — 아이폰 파손 에세이

1. 뉴욕타임스에 소개된 블로그 글
   1. 아이폰에서 노키아로: 2013년 아이폰을 떨어뜨려 화면이 깨지자, 옛날 노키아 벽돌폰으로 돌아간 경험을 에세이로 씀. "사람들에게 전화를 걸고 방향 감각이 돌아왔다"는 내용
   2. 바이럴과 채용 연결: 이 글이 Hacker News에 잠깐 노출됐고 뉴욕타임스가 이를 다뤘음. 트래픽이 몰리자 눈치 빠른 Shopify 채용 담당자가 연락함. 회사는 그가 고등학생인 줄 몰랐고, 오타와 캐나다 사무실로 초청해 면접을 진행 — 합격 후 고등학교 졸업을 마치고 2013년 캐나다로 이주해 입사

2.2. "불안감"을 학습 동력으로 전환한 습관

1. 모르는 용어를 즉시 메모하고 그날 밤 공부
   1. TCP 3-way handshake 사례: 누군가 TCP를 언급하면 "다들 3-way handshake와 TLS 레이어링을 당연히 아는 것 아닐까"라는 불안감에, 모르는 용어가 나올 때마다 종이에 적고 퇴근 후 공부함
   2. 정규 교육의 공백을 메움: 대학에서 배우지 못한 컴퓨터과학 지식을, IOI에서 얻은 "논문을 읽고 시간을 들이면 스스로 풀어낼 수 있다"는 자신감으로 대체
2. 인프라 레이어에 대한 순수한 호기심
   1. 점심시간에 인프라 팀 옆자리: 자신은 프로덕트 사이드에서 일했지만, 항상 인프라(메탈에 가장 가까운 사람들) 팀 옆에 앉아 대화를 들음
   2. "reverse proxy"라는 이름조차 파고듦: "왜 reverse냐"는 질문을 스스로 던지고, 지금도 명확한 답을 못 찾았다며 유머러스하게 인정(inverted index도 마찬가지로 "왜 inverted냐" — 이름이 안 좋다고 평함)

2.3. 샤딩과 대규모 트래픽 대응 — 2010년대 SaaS 고성장의 최전선

1. Shopify의 폭발적 성장과 Black Friday 대응
   1. 연 120~140% 성장률: 매년 지난해보다 훨씬 큰 규모의 Black Friday를 준비해야 했던 시기. 당시엔 물리 서버를 직접 구매해야 했기에 미래 트래픽을 보간(interpolation)해 발주해야 했음
   2. DB 샤딩 시점: "캐시로는 쓰기(write)를 해결할 수 없다"("you can't cache rights")는 상사 Camilo의 격언처럼, 결국 단일 샤드를 넘어서야 하는 시점이 옴. Shopify는 Black Friday 1주일 전 샤딩 전환(cutover)을 감행했고 성공적으로 작동함
2. 정체불명의 "Reddish 서버" 사건
   1. 128GB RAM 미스터리 서버: 당시로선 큰 용량인 128GB RAM Redis 서버가 있었는데, 아무도 정확히 무엇이 들어있는지 모른 채 KV 스토어처럼 다들 의존하고 있었음. 어느 날 이 서버가 다운되자 공포에 빠졌고, 이후 이를 여러 컴포넌트로 분리하는 작업을 진행

2.4. 장애 시뮬레이션과 ToxiProxy 개발

1. 의존성 장애를 강제로 실험한 이유
   1. 부분 장애 시 우아한 실패(graceful degradation) 원칙: Shopify 스토어 방문 시 세션 저장소가 다운되더라도 전체 사이트가 죽으면 안 된다는 원칙을 세움 — 단, 프로그래밍 언어가 강제하지 않는 한 이는 기본 동작이 아님
   2. 컴포넌트별 장애 대응 매트릭스: "이 서비스가 다운되면 이렇게 동작해야 한다"는 매트릭스를 만들고 테스트 스위트를 작성하기 시작
2. GDB를 이용한 초기 장애 주입 실험
   1. 프로세스에 침투해 파일 디스크립터 강제 종료: 초기엔 GDB로 프로세스에 shell out해서 DB로 가는 파일 디스크립터를 닫아 DB 장애를 시뮬레이션. CI에는 반영하지 못했지만 Rails 업스트림의 수많은 커넥션 레벨 장애 처리 버그를 찾아냄
   2. ToxiProxy 탄생: 이 아이디어를 발전시켜 DB와 애플리케이션 사이에 위치하는 Layer 7 프록시 ToxiProxy를 만듦. API 호출로 "DB를 느리게 만들어라", "다운시켜라" 등을 지시할 수 있고, 데이터 손상 같은 Layer 7 수준의 장애도 흉내 낼 수 있어 CI에서 전체 장애 매트릭스를 테스트 가능하게 함
   3. 실제 성과: proxy.mysql.down() 같은 API로 세션 테이블이 다운된 상태에서 체크아웃을 시도하는 식의 테스트를 하면, MySQL 드라이버와 Rails 생태계 전반에서 아무도 테스트하지 않았던 수십 건의 이슈를 발견함. 프로덕션에서는 DB가 다운되면 "복구"에만 집중하지 "애플리케이션이 실제로 뭘 할 수 있었는지"는 보기 어려움
   4. 현재까지 운영 중: Simon이 아는 한 ToxiProxy는 지금도 Shopify CI 시스템에서 사용되고 있음

---

2.5. 국가(state)와 데이터베이스에 대한 통찰 (Gergely의 코멘트)

1. 대규모 시스템의 난제는 결국 "상태(state)"에서 비롯됨
   1. Stateless 서비스도 문제는 있지만 국지적: 노드 다운, 손상 등은 있지만 상대적으로 격리됨
   2. 상태가 있다 = 대개 DB가 있다는 것: DB를 통해 장애를 시뮬레이션할 수 있으면 많은 것을 예측할 수 있지만, 상태 관련 문제는 실제로 발생하기 전까지 시뮬레이션하기 매우 어렵다는 근본적 난제가 있음

---

3. Shopify 퇴사와 "Napkin Math" 프로젝트 (2021년)

8년 만에 새로운 자극이 필요하다고 느껴 퇴사했고, 퇴사 후 방향을 찾지 못하던 중 자신이 오랫동안 쌓아온 "직관적 성능 계산" 습관이 Turbopuffer의 씨앗이 됐다.

3.1. 퇴사 결정 배경

1. 18세부터 8년, 새로운 자극이 필요했던 시점
   1. 한 회사만 경험: 고등학교 때 잠깐의 스타트업 경험 외에는 Shopify가 유일한 조직 경험. "더 빨리 배우려면 새로움을 주입할 시점"이라 판단해 2021년 퇴사(13년 입사 ~ 21년 퇴사)
   2. 다방면 인프라 경험: 캐싱, 공동창업자가 될 Justine과 함께 Shopify 스토어프론트 전체를 새로 작성(임베드 18개월 후 거의 100% 트래픽 처리), 멀티 데이터센터 운영, 다양한 DB 스케일링 프로젝트 등을 두루 경험

3.2. Napkin Math 프로젝트 — 벤치마크를 신뢰하지 않는 이유

1. 모든 하드웨어 성능 수치를 표로 정리
   1. GitHub에 공개된 테이블: DRAM 대역폭, S3 왕복 비용/시간, NVMe SSD 대역폭, EBS 볼륨 대역폭 등 약 50개 수치를 정리하고 이를 생성하는 Rust 스크립트까지 만듦
   2. 비용 수치도 함께 암기: 메모리 1GB=2달러, S3 1GB=2센트 등, 온디맨드/스팟/3년 약정 가격까지 표로 만들고 각 셀마다 플래시카드를 만들어 암기함
2. 벤치마크 불신의 계기 — "이건 말이 안 된다"는 직관
   1. 프로덕트 팀 벤치마크 리뷰 역할: DB A vs DB B 성능 비교 요청이 왔을 때, "10초 걸린다"는 벤치마크 결과를 보면 "냅킨 계산상 10ms여야 하는데?"라며 반박하는 역할을 자주 맡음
   2. 검색 쿼리 예시: 검색어 3개, 각 텀마다 매칭 문서 수, 이를 메가바이트로 환산, 여러 코어의 DRAM 대역폭(초당 100GB) 등을 계산하면 10ms가 나와야 하는데 벤치마크는 10초를 보고함 — 즉 자신의 이해에 구멍이 있거나, 벤치마크 자체가 잘못 설계된 것(예: 100개 노드에 분산 쿼리를 던져서 P99가 치솟는 경우)
3. MySQL 초당 쓰기(write) 수수께끼 사례
   1. f-sync 계산의 함정: "초당 쓰기 수 = 초당 f-sync 수"일 거라 가정했으나, f-sync 1회에 1ms가 걸리면 초당 1,000회 쓰기만 가능해야 함. 그런데 실제로는 작은 박스에서도 MySQL이 초당 10,000회 쓰기를 처리함
   2. 배치(batching)의 발견: BPF 트레이스까지 파며(당시는 LLM 이전 시절이라 시간이 오래 걸림) f-sync가 실제로는 4K 단위로 배치된다는 것을 발견 — "인터넷은 결국 바이에른의 어느 작은 독일 마을에 사는 사람이 쓴 MySQL 내부 구조 설명 글로 돌아간다"는 농담으로 마무리

---

4. Turbopuffer 창업 — S3 기반 벡터 검색 엔진

세 가지 계기(Shopify에서의 검색 엔진 나쁜 경험, Napkin Math 습관, Readwise 프로젝트에서의 비용 충격)가 겹쳐 Turbopuffer 창업으로 이어졌다.

4.1. 창업으로 이어진 세 가지 계기

1. Shopify 마지막 프로젝트: 검색(Search)에서의 나쁜 경험
   1. 이름을 밝히지 않은 전통 검색 회사 제품: 쿼리 플래너가 없고, 성능이 냅킨 계산 수준을 맞추지 못했으며, 소스코드를 읽어봐도 왜 안 되는지 파악하기 어려웠던 운영 난이도가 높은 제품이었음. "다시는 이걸 건드리지 않을 것"이라 생각했음
2. Napkin Math로 쌓인 하드웨어 활용 감각
   1. "완벽하게 활용하면 무엇이 가능한가"를 아는 능력: 이 감각이 이후 아키텍처 설계의 기반이 됨
3. ChatGPT 등장(2022)과 Readwise 프로젝트에서의 비용 충격
   1. 좁은 컨텍스트 윈도우 시절의 검색 필요성: 당시 컨텍스트 윈도우는 모델에 따라 4~8KB로 매우 작아 검색(retrieval)에 빠르게 의존해야 했음
   2. 추천 엔진의 예상 밖 정확도: Readwise(저장한 아티클을 나중에 다시 보여주는 서비스)를 위해 만든 추천 엔진이 매우 정교해서, 공동창업자 중 한 명의 아내 임신 사실을 그의 피드 추천 결과로 알게 될 정도였음(허락받고 실험한 것)
   3. 월 3만 달러라는 비용 충격: 이 기능을 전체 유저에게 적용하면 월 3만 달러가 드는데, Readwise는 부트스트랩 캐나다 회사로 당시 인프라 전체에 월 5천 달러를 쓰고 있었음. 투자 대비 마진이 맞지 않아 결국 출시하지 않음
   4. PostgreSQL autovacuum 튜닝을 하며 "왜 벡터 저장이 이렇게 비쌀까"를 고민: 어느 날 "S3에 다 넣고 클러스터링하면 안 되나"라는 냅킨 계산을 해보고, 실제로 앉아서 코드를 쓰기 시작함

4.2. 2023년 여름 — 레이턴시와의 사투

1. S3의 근본적 트레이드오프: 내구성은 좋지만 레이턴시가 나쁨
   1. P99 200ms: 256~512KB 객체 기준 S3의 P99 레이턴시는 약 200ms
   2. P99를 봐야 하는 이유: 대규모 시스템 설계 시 한 번의 왕복이 아니라 여러 번의 요청이 발생하므로(트리 상위 레이어 200ms, 다음 레이어 200ms, 리프 노드들 200ms 식으로 누적) P99, 심지어 P999까지 봐야 라운드트립 횟수를 최소화하는 설계가 가능함
2. 개발 타임라인
   1. 2023년 7월: 처음으로 엔드투엔드로 작동하는 버전을 만듦
   2. 두 번의 재작성 후 2023년 10월 출시: 여름 내내 접근법을 스케치하고 시행착오를 거친 뒤 공개

4.3. 극단적으로 단순한 초기 아키텍처 (MVP의 MVP)

1. 가장 단순한 클러스터링 기반 설계
   1. 클러스터 파일 구조: 벡터에 클러스터링 알고리즘을 돌려 클러스터를 얻고, 각 클러스터를 "cluster1", "cluster2" 같은 파일로 저장. centroid ID들을 담은 별도 파일도 둠
   2. 검색 흐름: centroid ID들을 다운로드해 가장 가까운 centroid를 찾고, 그에 해당하는 n개의 가까운 클러스터를 다운로드하는 방식. 비용/성능 제어를 위해 일부 작은 클러스터를 JSON으로 병합하는 최적화 정도만 추가
2. 캐싱 레이어 없이 nginx 리버스 프록시로 시작
   1. S3 앞단에 nginx: 별도 캐싱 레이어를 구현하지 않고 nginx 리버스 프록시를 S3 앞에 세워 캐싱 효과를 얻음. "reverse proxy가 왜 reverse인지는 아직도 모르지만, nginx Lua는 많이 써봤다"는 유머
   2. 캐시 무효화도 원시적으로: 캐시에서 항목을 지울 때는 nginx의 디렉토리 구조를 리버스 엔지니어링해서 직접 셸 명령으로 삭제
   3. 단일 서버, T-something 인스턴스: 이 모든 것이 GCP의 8코어 노드 하나에서 도는 단일 Toxy 인스턴스로 시작. "누군가 프로덕션에 쓰기 시작하면 그때 제대로 멀티노드로 세팅하겠다"는 태도
3. 회사가 아니라 프로젝트였다는 점
   1. $10M 펀딩을 생각조차 안 함: VC가 뭔지도 잘 몰랐고, 자신이 안 하면 누군가는 할 거라는 확신에 완전히 몰입했을 뿐
   2. LSM 이론을 깊이 공부하지 않음: 문헌을 많이 읽지 않고 기본 아이디어만 파악한 뒤 구현 — "가장 단순한 버전"을 목표로 함

---

5. Cursor와의 만남 — 첫 고객이 되기까지

트위터에 공개한 원시적인 MVP가, 마침 유닛 이코노믹스 문제로 고민하던 Cursor의 눈에 띄었다.

5.1. 트위터 공개와 가격 파괴

1. "백만 벡터를 1달러에"
   1. 기존 시장가 대비 100배 저렴: 당시 실제로 작동하는 서비스 기준 최저가는 백만 벡터당 약 100달러였는데, Turbopuffer는 1달러를 제시
   2. 신뢰할 수 있는 불변식(invariant)은 갖춰져 있었음: 모든 VM을 꺼도 데이터 손실이 없고, 모든 쓰기가 오브젝트 스토리지에 직접 커밋되는 등 오늘날과 동일한 핵심 불변식은 이미 갖추고 있었음(단, "제대로 된 LSM"은 아니었음)
2. "일단 관심 있는지 보자"는 태도
   1. 트위터 발표문: "여름 내내 이것만 작업했는데, 아무도 신경 안 쓰면 계속할 이유가 없다. 관심 있으면 알려달라" 식으로 게시

5.2. Cursor가 먼저 연락해온 이유

1. Cursor의 유닛 이코노믹스 고민과 정확히 맞아떨어짐
   1. 모든 벡터를 DRAM에 올리던 기존 방식의 비용 문제: Cursor 공동창업자 Aman의 초기 트윗에서 S3를 KV 캐싱에 쓰는 아이디어를 언급한 적이 있을 정도로, Cursor는 "자주 쓰는 코드베이스는 메모리에, 나머지는 오브젝트 스토어에 두고 핫로드하면 되지 않나"라는 아이디어를 이미 갖고 있었음
   2. Turbopuffer가 정확히 그 답이었음: 이메일을 주고받다가 Simon이 직접 샌프란시스코 사무실을 방문
2. 방문 당일 겪은 신뢰 구축 — DB 트러블슈팅을 즉석에서 해결
   1. AWS Aurora(Postgres 관리형 서비스) 이슈 목격: 방문 당시 Cursor 팀이 Postgres 관련 문제(오토배큠이 충분히 돌지 않아 인덱스 스캔 대신 시퀀셜 스캔이 발생하는 전형적 문제)로 고민 중이었고, Simon이 PG Analyze를 도입해 즉석에서 도움을 줌
   2. 신뢰의 시작: "DB 문제를 도와줄 줄 안다면 DB를 만들 줄도 알겠구나"라는 신뢰로 이어짐
3. 공동창업자 Justine 합류와 마이그레이션
   1. nginx 캐시를 파일 기반 직접 캐시로 교체: Simon이 생각하는 최고의 Shopify 출신 엔지니어인 Justine이 합류해 첫 작업으로 이를 수행
   2. 1~2주 만에 전체 마이그레이션 완료: Cursor는 그날 밤 바로 마이그레이션을 결정했고, 이후 1~2주에 걸쳐 완료
4. 결과: 이전 벤더 대비 청구액 95% 절감
   1. 약속을 지킴: Simon과 Justine은 Cursor의 청구액을 95% 낮추겠다고 약속했고 실제로 첫 청구서부터 95% 절감을 달성
   2. 당시 Cursor는 작은 회사였음: 이제 막 폭발적 성장이 시작되던 시점

5.3. Cursor 창업자가 남긴 조언 — "예외는 Turbopuffer뿐"

1. "작은 스타트업에 사업을 걸지 말라"는 원칙의 유일한 예외
   1. Amman(Cursor 창업자)의 언급: "우리가 절대 하지 않는 것 중 하나가 자신이 유일하거나 최대 고객인 작은 스타트업에 사업을 거는 것인데, Turbopuffer는 예외다. 그들을 정말 사랑한다"고 말했다는 일화
2. Gergely의 해석
   1. 좋은 것을 만들면 좋은 일이 일어난다: 고품질을 만들고 계속 밀어붙이면 기회가 옴
   2. 스타트업이 비합리적으로 보이는 리스크를 감수하는 이유: 확신(conviction)이 있을 때 — Simon은 직접 찾아가고, 문제를 해결해주고, 8년간 쌓은 실력을 보여줌으로써 신뢰를 얻어냄. Cursor 입장에서 Turbopuffer는 "그냥 랜덤 벤더"가 아니었음

---

6. Jensen Huang과의 만남 — CPU 대 GPU

Turbopuffer는 대부분 CPU 기반으로 동작하는데, Nvidia HQ에서 열린 행사에서 이 특징이 재미있는 에피소드로 이어졌다.

6.1. Nvidia 행사에서의 즉흥 발언

1. "C-word(CPU)를 언급하지 말라"는 팀의 당부를 어긴 순간
   1. 회사 이름 농담으로 시작: 무대에서 "안녕하세요, Turbopuffer의 Simon입니다. 혹시 이름이 궁금하시면, 다 잘 안 되면 우리는 언제든 vape(전자담배) 사업으로 피벗할 수 있습니다"라고 농담
   2. Jensen의 즉각적인 리액션: "당신 슬라이드를 보니 정말 그래야 할지도 모르겠네요"라고 받아침(Simon은 이미 긴장한 상태였음) — 이후 팀 전체 채널에 "Simon이 방금 Jensen한테 베이프 하냐고 물어봤다"는 메시지가 돌 정도로 화제가 됨
2. CPU에 대한 애정을 숨기지 못함
   1. AVX-512, SIMD 예찬: "CPU 시대는 정말 재밌다", "CPU는 구하기 쉽다"는 말을 계속함. "GPU가 필요 없어서 정말 다행이다"라고 말할 뻔했다고 스스로 언급(참음)
   2. Jensen이 관심을 보임: 이 발언이 오히려 Jensen의 흥미를 끌었을 것이라는 추측(Gergely가 "언젠가 GPU로 전향시키는 게 목표가 됐을지도"라고 농담)

---

7. 클라우드/CPU 부족 현상 — 하이퍼스케일러 내부에서 보이는 것들

GPU 부족은 널리 알려져 있지만, CPU조차 이제는 쉽게 구하기 어렵다는 현장의 증언.

7.1. RL(강화학습)과 에이전트가 CPU 수요를 견인

1. RL 워크로드가 대량의 CPU를 소비하는 이유
   1. 모델이 "실제로 행동하고 학습"해야 함: 검색하는 법, GPU를 쓰는 법, bash를 부팅하는 법 등을 가르치려면 실제로 무언가를 실행하고 그 결과에서 학습해야 하며, 이는 CPU를 많이 소비함
   2. 응용이 확장될수록 RL 환경도 늘어남: "모델이 CAD나 조선 설계를 잘 못한다"는 식의 새로운 응용이 나올 때마다 이를 위한 RL 환경을 더 많이 구축해야 하는 순환 구조
2. 에이전트도 범용 CPU 작업을 대량 수행
   1. 에이전트는 CPU에서 매우 범용적인 작업을 수행함: 수요 곡선이 점점 더 "응용" 쪽으로 이동
3. Turbopuffer 관점: NVMe SSD와 DRAM도 함께 부족
   1. GPU 서버도 대량의 DRAM 필요: CPU뿐 아니라 NVMe SSD, DRAM까지 자원 경쟁이 심화되는 상황
   2. 큰 기업들끼리도 할당을 놓고 경쟁: Turbopuffer가 판매하는 고객사와 동시에 같은 CPU 자원을 놓고 경쟁하는 상황까지 발생

7.2. 실제 고객 사례 — Reflection의 계약 한계

1. 전날 저녁 고객 디너에서 들은 이야기
   1. Reflection(대형 AI 랩)의 사례: 이미 거대한 규모의 인프라 풋프린트를 가진 고객사가 "더 이상 GPU나 CPU를 살 수 없다"고 토로 — 가능한 최장 계약을 이미 다 맺어놓은 상태
   2. 작은 기업 → 중견/대형 기업이 될수록 클라우드 경쟁이 치열해짐: Gergely가 이 정도로 경쟁이 치열한 줄 몰랐다고 언급

7.3. Turbopuffer의 대응 전략

1. 클라우드사와 직접 협업
   1. 어느 리전에 CPU가 있는지 파악: 결국 전력(power)이 어디 있는지가 관건이며, 전력이 있는 곳에 신형 CPU가 우선 배치됨. 대형 고객들과 함께 이 문제를 조율함
2. 다양한 SKU를 유연하게 활용하는 것이 핵심 경쟁력
   1. 선호 인스턴스: 현재 GCP의 C4 시리즈를 가장 선호하며, 최적화를 마친 Z4D도 우수한 성능을 보임. ARM 기반 C4A도 활용 중
   2. 특정 CPU/인스턴스 타입에 종속되지 않는 설계: "우리는 다양한 종류의 머신 타입에서 잘 돌아갈 수 있다"는 점이 CPU 부족 시대의 핵심 방어 전략. Shopify 시절에도 Black Friday(BFCM) 몇 달 전부터 클라우드 제공사에 사용량을 미리 커밋해야 했던 경험 — "작을 때는 클라우드가 무한해 보이지만, 실제로는 그렇지 않다"

---

8. 벤처캐피탈에 대한 철학 — "자본을 조달하는 6가지 이유"

Simon은 실리콘밸리 특유의 "묻지도 따지지도 않는 조달 문화"와 다른, 손익 중심의 원칙을 갖고 있었다.

8.1. 창업 초기: "숫자가 맞아야 한다"는 단순한 원칙

1. Cursor에게 약속한 4천 달러/월이라는 목표
   1. 역산으로 나온 가격: "Turbopuffer가 더 나은 구현이라면 이 정도 비용이어야 한다"는 냅킨 계산에서 나온 가격을 그대로 Cursor에게 약속하고 출시함
   2. 소프트웨어는 신뢰할 만했지만 아직 단순했음: 이때도 "단순함이 최우선"이라는 핵심 엔지니어링 원칙을 지킴 — Gergely와 함께 이야기한 "오래 가는 소프트웨어는 단순함이 결국 이긴다"는 관점과 연결(Simon은 Shopify, Gergely는 Uber에서 각각 장기 재직하며 체득)
2. "벤처 규모 기회인지 확신이 없었다"
   1. VC 자본의 본질에 대한 이해: 아무리 화기애애해도 결국 모두가 특정 시점까지 큰 수익을 기대한다는 것 — 그 뒤에는 캐나다 연기금 같은 최종 자금 출처까지 이어지는 긴 체인이 있음을 인식
   2. 처음엔 니치 제품이라 생각함: 이 정도로 큰 회사가 될지 확신이 없었고, 그래도 괜찮다고 생각함(자기 자신에게 솔직)
3. "숫자가 같아질 때까지 최적화하겠다"는 접근
   1. Cursor 청구서 = GCP 청구서가 될 때까지: "이 두 숫자가 같아지도록 최적화하자"는 것이 초기 철학. "덴마크식 사업 101" — 이익이 나면 괜찮다는 단순한 기준
   2. 실리콘밸리 자본 문화에 대한 아웃사이더 시선: "이곳(SF)의 돈이 조금 다르게 돌아간다는 걸 그때는 몰랐다"고 회고

8.2. 첫 번째 자금 조달 — 700K 달러, 2024년 1월

1. 함께 일하고 싶었던 IOI 동료 "Buen"
   1. 북마케도니아 대표팀 동료: 2012~2013년 IOI에서 만난 인물로, 실력이 워낙 뛰어나 팀 내에서 "God"이라 불렸음. 함께 일하고 싶었지만 당시 자금 여력이 없었음(Justine과 본인 모두 6개월간 무급으로 일하며 이미 수만 달러의 GCP 청구서를 자비로 감당 중)
2. 투명하게 조건을 제시한 조달 방식
   1. 목표액을 명확히 제시: 실리콘밸리 인맥 중 한 명인 Locky에게 연락해 "70만 달러를 모으고 싶다. 엔지니어 두 명을 연말까지 고용하고, 약간의 버퍼면 된다"고 제안
   2. 연말까지 PMF가 없으면 사업을 접겠다는 약속: "올해 말까지 PMF가 없고 큰 기회가 아니라고 판단되면 접고, 투자금은 한 푼도 안 쓰고 전부 돌려주겠다"고 말함 — 상대방이 "이런 식으로 말하는 사람은 처음 봤다"는 반응을 보였다고 함
   3. 다른 VC들에게는 "야망이 낮다"는 인상: 서부 해안 특유의 문화에서는 이런 태도가 오히려 두렵게 받아들여지기도 했으나, Simon은 "게임의 룰을 모를 땐 그냥 오픈 카드로 플레이한다"는 태도로 임함
3. 결과: Buen과 Morgan을 첫 엔지니어로 채용, 그해 흑자 전환

8.3. 자본 조달의 6가지 이유 (Simon의 프레임워크)

1. ① R&D 자금 조달 — Turbopuffer의 첫 조달 이유. 이전까지는 기회비용(무급 노동)과 자비로 R&D를 감당해왔고, 더 빠르게 배우기 위해 Buen과 Morgan을 고용할 자금이 필요했음
2. ② 성장(Growth) 자금 조달 — 이미 만든 것을 세상에 알리기 위해 더 많은 자본을 쓰는 것
3. ③ 창업자의 자아(Ego) — Simon이 "매우 인기 있고 위험한 이유"라 평가. 큰 숫자, 언론 노출 등을 위한 조달은 모든 직원의 지분을 희석시키고 미래 직원의 upside 기대치를 왜곡시킨다는 점에서 문제. 이 이유에 대해 업계에서 더 솔직하게 이야기되어야 한다고 지적
4. ④ 직원 보상/유동성 제공 — 최고의 인재와 함께 긴 여정을 가려면 그들에게 보상해야 함. Turbopuffer가 2025년 12월에 추가로 자금을 조달한 이유가 바로 이것 — IPO 같은 먼 미래의 이벤트를 기다리지 않고 직원들이 지분 일부를 현금화할 수 있게 함
5. ⑤ 전략적 파트너십 — 실리콘밸리에는 전략적 제휴로 만들어진 회사들이 실제로 존재함
6. ⑥ M&A 등 — 인수합병 등을 위한 자금 조달

• Turbopuffer의 실제 조달 이유: 첫 조달(2024년 1월)은 ①R&D, 두 번째 조달(2025년 12월)은 ④직원 유동성 — Simon은 이 프레임을 통해 "당신이 지금 어떤 이유로 조달하는지 스스로에게 정직해야 한다"고 강조

---

9. 완전 원격(Remote) 문화 — "Campfire" 개념

AI 인프라/제품 기업들이 대개 SF 등지에 본사를 두고 대면 근무를 선호하는 것과 달리, Turbopuffer는 창업 때부터 완전 원격을 고수하고 있다.

9.1. 원격을 선택한 배경

1. 코로나 시기(2023년)에 창업
   1. Shopify 인프라팀도 이미 원격이었음: 모두를 오타와로 이주시키기 어려웠기 때문에 Shopify 인프라 조직은 일찍부터 원격이었고, 이 경험이 자연스럽게 이어짐
2. "DB 회사를 빠르게 만들 수 있는 도시는 SF와 뉴욕 정도뿐"이라는 인식
   1. 소수 허브 도시 집중의 한계: 특정 도시에 다 모이는 방식을 택하지 않으려면 분산 모델에 완전히 베팅해야 한다는 판단

9.2. Turbopuffer식 원격 운영 방식

1. 연 2회 전사 오프사이트
   1. 올해는 (특정 지역, 원문상 "B"로만 언급됨)와 멕시코시티에서 진행: 완전한 비대면은 아니며 정기적으로 대면 기회를 마련함
2. "Campfire"라는 자율적 소모임 개념
   1. 자연스럽게 모이는 사람들 = Campfire: 몇 명이 우연히 특정 장소에 모이면 이를 "campfire"라 부르고, 원하는 사람은 누구나 참여 가능. 예: 이번 주 샌프란시스코의 aiDotEngineer 컨퍼런스 참석을 계기로 자연스럽게 "SF 캠프파이어"가 형성돼 고객 미팅과 디너를 함께 진행
   2. 참여는 완전히 자율적: 록인(lock in)하고 텐트에 처박혀 일하고 싶은 사람은 그래도 되고, 연 2회 오프사이트만 참석하고 나머지는 가족과 집에서 보내는 사람도 있음 — 두 방식 모두 이 모델과 완전히 양립 가능
   3. 비행기를 자주 타는 사람도 있음: 2주에 한 번꼴로 비행기를 타는 직원도 있고, 어떤 직원은 뉴욕에서 열리는 캠프파이어 화상 회의를 보다가 너무 FOMO를 느껴 즉시 오타와에서 우버를 타고 공항으로 가 뉴욕행 비행기를 탄 일화도 있음(팀은 이를 긍정적으로 봄)
3. "Turbo Credit" 인센티브 시스템
   1. 컨퍼런스 발표, 블로그 포스트 등 특별활동에 대한 보상: 다음 항공편을 비즈니스 클래스로 업그레이드할 수 있는 크레딧을 지급해 팀원들이 함께 시간을 보내도록 유도
   2. 자체적으로 생태계가 생기는 중: 누군가 Turbo Credit에 대한 중앙은행/금리를 만들자거나 베팅 마켓을 만들자는 농담이 나올 정도로 회사 내 문화로 자리잡음
   3. 컨퍼런스 부스 근무 등 힘든 일에도 적용: 이틀간 엑스포 부스에서 고객을 응대하는 것처럼 힘든 일을 자원해서 하는 엔지니어에게도 Turbo Credit을 지급해 노고를 인정함

---

주요 발언 모음

"How is it possible? Because you batch. An f-sync happens on usually a 4K." — MySQL 초당 쓰기 수수께끼를 풀며

"It was not a company. It was not a project — it was to satisfy a curiosity. I did not set out to do this like I'm going to go raise $10 million." — Turbopuffer 초기를 회고하며

"It's the simplest possible version of what it could be... let's see if anyone gives a [shit]." — Turbopuffer 최초 MVP를 트위터에 공개하며

"You should never ever bet your business on a tiny startup where you are their only or biggest customer — except for Turbopuffer. I love those guys." — Cursor 창업자가 남긴 말이라고 Simon이 전함

"Judging by your slide, maybe you should [pivot into vapes]." — Jensen Huang이 Simon의 농담에 즉석에서 받아친 말

"The third reason to raise capital is for the founder's ego... I wish that it was more talked about, because you're diluting all of your employees when you do it." — 자본 조달 6가지 이유 중

"When I don't know how to play a game, I just play with open cards." — VC들에게 조달 목표와 조건을 투명하게 밝힌 이유

"I think there's kind of maybe two cities where you can build a database company fast, and that's San Francisco and maybe New York... so if you don't want to do that, you have to go all in on some distributed model." — 원격 문화 선택 배경

---

핵심 데이터 & 수치

• Turbopuffer 초기 가격: 백만 벡터당 1달러 (기존 시장 최저가는 약 100달러 수준)
• S3 P99 레이턴시: 256~512KB 객체 기준 약 200ms
• Cursor 청구액 절감률: 이전 벤더(Aurora 기반) 대비 95% 절감
• Readwise 프로젝트 견적: 전체 유저 대상 벡터 추천 기능을 배포하면 월 3만 달러 소요 예상 — 당시 회사 전체 인프라 비용(월 5천 달러)의 6배로 채산성이 맞지 않아 미출시
• Shopify 성장률: 2010년대 연 120~140% 성장
• Shopify 미스터리 Redis 서버: 128GB RAM (당시 기준 대용량)
• 첫 조달 규모: 2024년 1월, 70만 달러(2명의 엔지니어 채용 + 약간의 버퍼 목적)
• MySQL f-sync 배치 단위: 4K
• Simon의 Shopify 재직 기간: 2013~2021년, 총 8년
• Turbopuffer 창업: 2023년 여름 개발 시작, 2023년 10월 공식 출시

---

결론 및 시사점

1. 호기심의 깊이가 곧 실력이 된다: 정규 교육 없이도 "모르는 건 그날 밤 반드시 이해하고 넘어간다"는 습관을 8년간 반복한 것이 이후 모든 엔지니어링 판단력의 기반이 됐다. Simon은 지금도 엔지니어 채용 시 "레이어를 벗겨내지 않고는 못 배기는" 성향을 최우선으로 본다고 밝혔다.
2. "Napkin math"는 벤치마크를 맹신하지 않는 훈련이다: 하드웨어의 이론적 한계치를 체화하고 있으면, "벤치마크가 이렇게 나왔다"는 결과를 그대로 받아들이지 않고 "이게 말이 되나?"를 먼저 따질 수 있다. 이는 잘못된 인프라 결정을 막는 강력한 방어선이다.
3. 극단적 단순함이 초기 스타트업의 최선의 전략일 수 있다: 캐싱 레이어조차 구현하지 않고 nginx로 때운 단일 서버 MVP가, 오히려 "이게 되는지부터 보자"는 검증 속도를 극대화해 Cursor라는 결정적 고객을 만나는 계기가 됐다.
4. 신뢰는 실력을 직접 보여줄 때 생긴다: Simon이 Cursor 사무실을 직접 찾아가 눈앞의 Postgres 문제를 즉석에서 해결해준 것이, 그 어떤 세일즈 피치보다 강력한 신뢰 구축 수단이었다.
5. 벤처캐피탈은 도구이지 목적이 아니다: "왜 지금 자금을 조달하는가"에 대한 명확한 답(R&D, 직원 유동성 등)이 없다면 조달하지 말아야 한다는 원칙은, 특히 에고나 과시를 위한 조달이 만연한 환경에서 곱씹을 가치가 있다.
6. CPU 부족은 이제 GPU 부족만큼 현실적인 문제다: RL과 에이전트 워크로드의 급성장으로 CPU·NVMe·DRAM 확보 경쟁이 심화되고 있으며, 특정 SKU에 종속되지 않는 유연한 인프라 설계가 중요한 방어 전략이 되고 있다.
7. 원격 문화는 "규칙"이 아니라 "자율성을 극대화하는 설계"로 작동할 수 있다: Campfire와 Turbo Credit처럼, 강제하지 않으면서도 자발적 대면 교류를 유도하는 인센티브 설계가 완전 원격 조직에서도 강한 팀 결속을 만들어낼 수 있음을 보여준다.

---

메타데이터

• 원본 URL: https://www.youtube.com/watch?v=jQDXzEVHMSE
• 채널: AI Engineer (aiDotEngineer)
• 발행일: 2026-08-03
• 처리일: 2026-08-04
• 영상 길이: 56:29
• 자막 소스: yt-dlp 자동 생성 영어 자막 (auto-sub)