1. 핵심 주장
- 대규모 시스템 엔지니어링에서 "냅킨 계산(napkin math)"은 직관과 벤치마크의 오류를 바로잡는 가장 강력한 도구다.
- S3 위에 구축된 벡터 검색 DB는 기존 DRAM 중심 솔루션 대비 비용을 95% 낮출 수 있으며, 내구성과 단순함이라는 구조적 이점을 동시에 얻는다.
- 스타트업이 자본을 모을 때는 정직하게 '6가지 이유' 중 어떤 것인지 밝히고, ego가 아닌 실제 필요에 따라 접근해야 한다.
- 데이터베이스를 SaaS처럼 출시하고, 고객의 인프라 문제부터 진심으로 해결하면 초기 신뢰를 쌓을 수 있다.
- AI 인프라의 병목은 GPU뿐 아니라 RL과 에이전트 수요로 인한 CPU 및 NVMe SSD 부족으로 빠르게 이동하고 있다.
2. 세부 내용 / 근거
2.1 Simon Ericsson의 커리어 시작: PowerPoint에서 Shopify까지
- PowerPoint의 슬라이드 전환 기능으로 Turing-complete한 게임을 만들면서 처음 프로그래밍에 빠졌다.
- Microsoft FrontPage의 HTML 뷰를 통해 웹 개발에 입문했고, 이후 Dreamweaver, PHP로 나아갔다.
- 대학 대신 고등학교 시절부터 일하기 시작했고, 국제 정보올림피아드(IOI)를 통해 알고리즘 사고를 익혔다.
- 2013년 iPhone 대신 Nokia feature phone을 쓴 경험을 글로 썼다가 뉴욕타임스에 실리면서 Shopify 채용 담당자의 눈에 띄었다.
- 18세에 Shopify에 합류해 8년간 인프라팀에서 근무하며 컨테이너화, 샤딩, 멀티 데이터센터, 세션 스토어 분리 등을 경험했다.
2.2 Shopify에서의 문제 해결과 Toxyroxy
- Shopify는 매년 블랙프라이데이를 대비해 물리 서버를 미리 주문하고, 데이터베이스 확장을 준비해야 했다.
- 상태를 가진 데이터베이스의 장애는 단순히 목(mock)으로 재현할 수 없어, GDB를 이용해 실제 프로세스의 DB 파일 디스크립터를 닫는 방식의 테스트를 고안했다.
- 이 경험을 바탕으로 Layer 4/7 프록시인 Toxyroxy를 만들어, CI에서 네트워크/DB 장애를 실제처럼 주입할 수 있게 했다.
- Toxyroxy는 MySQL 드라이버, Rails 등에서 수십 가지 연결 실패 처리 버그를 발견했으며, 당시 Shopify의 CI에 적용되었다.
2.3 Napkin Math 프로젝트
- GitHub에 하드웨어/클라우드 비용, 대역폭, 지연 시간 등을 정리한 테이블과 Rust 기반 벤치마크 스크립트를 공개했다.
- 핵심 신념: "벤치마크가 10초라면 냅킨 계산상 10ms여야 하는지 물어야 한다." 둘 중 하나는 틀렸거나, 잘못 측정한 것이다.
- 예시: MySQL의 write throughput이 fsync 횟수와 같아야 한다고 생각했으나, 실제로는 4KB 단위 배칭 덕분에 10배 이상 높게 측정됐다.
- 냅킨 계산은 단순한 추정이 아니라, 실제 하드웨어 한계와 소프트웨어 동작의 불일치를 파헤치는 진단 도구다.
2.4 Turbopuffer의 탄생
- Shopify를 떠난 후 Readwise의 추천 엔진 프로토타입을 만들었는데, 벡터 저장 비용이 월 3만 달러로 계산되면서 사내 다른 인프라 비용(5천 달러)을 압도했다.
- "S3에 벡터를 저장하면서도 검색 지연 시간을 낮출 수 없을까?" 하는 질문에서 시작해 2023년 여름 집중적으로 해결책을 탐구했다.
- S3의 P99 지연 시간이 256~512KB 객체 기준 약 200ms이므로, 트리 탐색 같은 다중 요청 구조에서는 요청 수를 최소화하는 것이 핵심이었다.
- 2023년 7월 end-to-end 동작하는 버전을 얻었고, 두 차례 재작성 끝에 10월에 출시했다.
2.5 초기 아키텍처의 단순함
- 첫 버전은 클러스터링 알고리즘으로 벡터를 그룹화하고, 각 클러스터와 중심점(centroids)을 JSON 파일에 저장하는 매우 단순한 구조였다.
- 검색 시 중심점을 내려받아 가까운 N개의 클러스터를 다운로드하는 방식이었다.
- 성능 향상을 위해 NGINX 기반 역프록시 캐시를 앞에 두고, 캐시 무효화가 필요할 때는 shell로 nginx 캐시 디렉토리를 직접 조작하는 식으로 운영했다.
- 처음에는 단일 GCP T-Mox 인스턴스에 불과했으며, "실제 운영을 하면 제대로 설치하겠다"는 마인드로 MVP를 출시했다.
2.6 Cursor와의 첫 고객 사례
- 첫 고객은 Cursor였다. Cursor는 기존에 Postgres/Aurora 기반 인프라로 벡터를 관리하다 비용과 안정성 문제를 겪고 있었다.
- Twitter 출시 직후 Simon이 San Francisco로 직접 찾아가, 우선 PG Analyze 설치부터 도와주며 Postgres autovacuum 문제를 해결해 신뢰를 쌓았다.
- Shopify 동료였던 공동창업자 Justine이 합류해 NGINX 캐시를 파일 기반 캐시로 교체하는 등 개선을 진행했다.
- 이전 벤더 대비 95% 비용 절감을 약속했고 실제로 달성했다.
- Swell(?)의 조언: "스타트업의 유일한/가장 큰 고객이 되는 것에 사업을 걸어선 안 된다. 단, Turbopuffer는 예외다."
2.7 AI 인프라에서의 CPU/NVMe 쇼티지
- GPU 부족만이 문제가 아니다. RL(강화학습)과 에이전트 워크로드는 수많은 CPU 코어를 필요로 한다.
- AI 랩들이 GPU 서버에 필요한 DRAM, CPU, NVMe SSD까지 확보하면서 클라우드 CPU 할당 경쟁이 심화되고 있다.
- Turbopuffer는 CPU와 NVMe SSD, S3만 있으면 동작하므로 다양한 인스턴스 SKU에서 유연하게 운영할 수 있다.
- 현재 선호하는 인스턴스: GCP C4-force, Z4D, ARM 기반 C4A 등.
- 클라우드는 작을 때는 무한해 보이지만, 중형 이상이 되면 전력 공급, 지역, 장기 계약 등 실질적 제약에 직면한다.
2.8 벤처캐피털에 대한 6가지 관점
Simon은 기업이 자본을 모으는 이유를 6가지로 구분했다.
- R&D 투자 — 첫 라운드의 이유. 기회비용과 직접 비용을 감수하다가 Buen, Morgan을 고용하기 위해 70만 달러를 모았다.
- 성장 투자 — 제품을 세상에 알리고 확장하는 비용.
- 창업자의 ego — 위험한 이유. 직원 희석과 미래 채용에 부정적 영향을 준다.
- 직원 유동성(liquidity) — 12월 라운드의 이유. IPO 등 먼 미래를 기다리지 않고 우수 인재에게 보상을 제공한다.
- 전략적 파트너십
- M&A 등 거래
- 첫 투자 유치 시 "연말까지 PMF가 없으면 그냥 문 닫고 돈을 돌려주겠다"고 말해 실리콘 밸리 VC들을 놀라게 했다.
- 결론: VC를 받는다면 어떤 이유(1~6)인지 정직하게 인식해야 한다.
2.9 완전 원격 근무와 "Campfire" 문화
- 2023년 창업 직후 완전 원격으로 시작했으며, Shopify 인프라팀도 원격 문화에 익숙했다.
- 1년에 두 번 전체 오프사이트를 진행하고, 그 외에는 "Campfire(모닥불)"이라는 개념을 운영한다.
- Campfire: 누군가 특정 도시에 모이면 Slack 등으로 알리고 원하는 사람들이 자유롭게 합류하는 짧은 오프라인 모임.
- 일부 직원은 2주에 한 번 비행기를 타는 반면, 다른 직원은 1년에 두 번만 참여해도 괜찮다.
- Turbo Credit이라는 재미 요소를 도입해, 컨퍼런스 발표나 고객 대응 등 추가 활동 시 다음 비행기를 비즈니스석으로 업그레이드할 수 있게 했다.
3. 사례 / 실행 포인트
- 벤치마크 대신 냅킨 계산: 새로운 데이터베이스나 스토리지를 도입할 때, 하드웨어 한계와 이론상 지연 시간부터 계산해 실제 측정값과 비교하라.
- DB 장애를 실제처럼 테스트: Toxyroxy처럼 프록시나 fault injection 도구를 만들어 드라이버/프레임워크의 실패 처리를 CI에서 검증하라.
- 초기 고객에게 먼저 가치를 주기: Cursor 사례처럼 제품 판매보다 고객의 Postgres 문제부터 해결하면 신뢰를 얻는다.
- S3 기반 검색 설계의 핵심: S3 P99 지연 시간(약 200ms)을 감안하면 요청 횟수를 줄이는 것이 P50보다 P99/P999 설계가 중요하다.
- 단순함 우선: LSM 트리 같은 정교한 구조보다 클러스터+중심점 파일이라는 단순한 구조로 먼저 동작을 증명하고, 이후 개선하라.
- 자본 모금의 정직한 프레임워크: 6가지 이유 중 어느 것에 해당하는지 명확히 하고, ego나 status game에 휘둘리지 말 것.
- 원격 팀의 오프라인 접점 설계: 의무가 아닌 자율적 모임(Campfire)과 소소한 보상(Turbo Credit)으로 만남의 빈도를 조절하라.
4. 시사점 / 연결
- "데이터 중심 AI"의 인프라 비용: RAG, 추천, 검색 증강 생성 등 벡터 검색은 AI 제품의 핵심이며, DRAM 기반 벡터 DB의 비용 구조는 많은 스타트업의 마진을 압박한다. S3 기반 설계는 이 구조적 문제에 대한 대안이 될 수 있다.
- CPU가 새로운 병목: AI 붐이 GPU 중심으로 논의되지만, RL 환경과 에이전트 실행은 범용 CPU 자원을 대량으로 소진한다. CPU 최적화가 다시 중요해지고 있다.
- 실리콘 밸리 외의 창업자 서사: Simon은 덴마크 출신, 캐나다 기반, VC 관계 없이 시작해 첫 고객과 직접 만나 성장한 사례다. 지리적/네트워크적 열세를 첫 원칙 사고와 실행력으로 극복했다.
- SaaS처럼 데이터베이스 운영하기: 데이터베이스라고 해서 처음부터 완벽해야 한다는 선입견을 버리고, 실제 사용자가 생기면 제대로 운영하겠다는 실용주의가 MVP를 가능하게 했다.
- 인프라 스타트업의 신뢰 형성: 복잡하고 높은 가용성을 요구하는 데이터베이스 분야에서 초기 고객은 기술적 능력보다 문제 해결 의지와 빠른 대응으로 얻는다.
- 단순함과 성능의 균형: 현대 데이터베이스는 LSM, B-tree, ANN index 등 복잡한 구조를 갖추지만, Turbopuffer의 사례는 문제의 본질(클러스터링 + 객체 스토리지 + 캐싱)으로 돌아가 단순한 구조에서 시작하는 가치를 보여준다.
원문 메타
- 출처: YouTube — pragmaticengineer
- 영상 제목: From "napkin math" to turbopuffer
- 영상 URL: https://www.youtube.com/watch?v=h8TBLKyo7Rs
- 영상 ID: h8TBLKyo7Rs
- Drop Date: 2026-07-25
- Duration: 3338초 (약 55분)