Zaplib이 스타트업으로서의 핵심 가설이 왜 무너졌는지, 초기 사용자들과의 파일럿 과정에서 얻은 교훈과 이후 방향을 정리한 사후 분석 글.
음, 이건 좀 이상한 블로그 글입니다! 정말 예상치 못하게도, Zaplib이 스타트업으로서 성립하기 위해 필요했던 몇 가지 핵심 가설이 빠르게 무너졌습니다.
피치는 대략 이랬습니다:
파일럿 사용자들과 함께 일하기 시작하면서 우리는 이 이야기의 구멍을 발견했습니다. 느린 JS를 JS만으로도 빠르게 만드는 것이 언제나 가능 하다는 점은 우리도 알고 있었습니다. Rust에서 점진적으로 앱을 가속하는 것이 10배 더 사용하기 쉽고(ergonomic) 할 거라는 데 베팅했던 거죠. 하지만 실제 구현에서는 이 가설이 성립하지 않았습니다.
사용자 1 - 이들은 결국 앱 전체를 Rust로 포팅한다는 “전체 비전”까지도 이해했고, 점진적으로 포팅 가능한 가속 기회가 있는 듯 보였습니다. 우리는 일주일을 들여 그들의 시뮬레이터를 Rust로 포팅했고, 처음부터 눈에 띄게 빨라지길 기대했습니다. 결과는 5% 더 빠른 정도였습니다. 더 빠르게 만들려면 주된 방법은 더 빠른 선형대수 라이브러리를 쓰는 것인데, 그런 라이브러리는 JS에도 있습니다. 여기서는 Rust가 의미 있는 도움을 주지 못했습니다.
사용자 2 - 우리는 그들의 렌더러를 GPU 가속 2D 렌더러로 포팅했습니다. 결과는 훌륭했습니다! 하지만 여기서의 성능 향상은 Rust/Wasm이 아니라 WebGL 덕분에 렌더러가 GPU 가속이었기 때문입니다. 실제로 필요하지 않은데도 코드베이스에 Rust 툴체인 전체를 추가하는 것에 대해 그들이 조심스러워한 것은 당연했습니다.
사용자 3 - 이들은 Zaplib의 훌륭한 사용자가 될 수 있었지만, 점진적 방식으로는 아니었습니다. 우리가 완전 신규(그린필드) 앱을 타깃으로 했다면 좋은 사용자가 될 수도 있었겠지만, 이는 좋은 스타트업 전략이 아닙니다. 이유는 1) 시작부터 엄청난 API 표면적이 필요하고, 2) 기존 비즈니스와 함께 일하기가 어렵기 때문입니다.
사용자 4 - 프로토타입을 벤치마크했을 때는 10배 개선을 보기도 했습니다. 하지만 그 프로토타입을 처음부터 새로 만들었기 때문에, 근본적으로 더 빠르게 설계할 수 있었고—따라서 진짜로 공정한 사과 대 사과(apples-to-apples) 비교가 아니었습니다. 다시 말해 JS로 다시 작성해도 비슷한 가속을 얻었을지도 모릅니다. 성능 향상의 또 다른 큰 원천은 GPU 가속 렌더러였는데, 이는 (사용자 2와 마찬가지로) Rust/Wasm 없이도 가능합니다. 네이티브 빌드에서는 더 좋은 사용성(스레딩, 제로 코스트 추상화)과 2배 정도의 속도 향상도 보긴 했지만, 이런 것들은 있으면 좋은 수준이지 사람들이 새로운 스택으로 갈아탈 만큼 충분한 이유는 아니었습니다.
Rust가 JS보다 빠른 경우가 있긴 하지만, 우리가 예상했던 것보다 그런 경우는 드물었고, 성능 향상도 대개 10배가 아니라 많아야 2배 수준인 경우가 종종 있었습니다. 정말 큰 10배 향상은 Rust의 제로 코스트 추상화에 강하게 의존할 때 나타나긴 합니다. 예를 들어 아주 작은 Rust 구조체를 백만 개 처리하는 것은, 메모리 레이아웃과 GC 회피 같은 이유로 백만 개의 JS 오브젝트를 처리하는 것보다 빠릅니다. 하지만 이는 드문 케이스이고, 특히 우리가 말하던 점진적(Incremental) 이야기와는 잘 맞지 않습니다. 10배 개선이 없다면, 엔지니어들이 팀이 배우고 유지보수해야 하는 새롭고 실험적인 툴체인을 스택에 추가하기 위한 투자를 할 거라고는 상상하기 어렵습니다. 우리도 그렇게 하지 않을 것이고, 다른 누구에게도 그렇게 하라고 권할 수 없습니다. 대개 Rust/Wasm보다 더 단순한 방식으로 성능을 개선할 수 있습니다.
맞습니다. 하지만 자세히 보면 그들이 Wasm을 쓰는 이유는 결정적인 성능 요구라기보다, 네이티브 앱을 대비해 C++로 만들고 싶었던 역사적 우연에 더 가까워 보입니다. Figma 파일은 C++/Wasm에서 처리되는데 이는 아마도 큰 속도 향상이 맞겠지만, Figma의 성능 ‘마법’ 대부분은 WebGL 렌더러에서 나옵니다.
우리가 Rust/Wasm에서 벗어나 Zaplib의 WebGL 렌더러만 떼어내 별도의 프레임워크로 피벗할 기회가 있는지 궁금할 수 있습니다. 실제로 일부 사용자에게 유용했던 건 그쪽이었습니다. 우리도 이걸 고민하고 있습니다! 다만 그걸로 비즈니스 기회가 있을지는 회의적이지만, 검토 중입니다.
마지막 시도로, Hacker News에 “런칭”해 보고 Zaplib에 대한 흥미로운 사용 사례가 어디선가 튀어나오는지 보기로 했습니다. 우리는 이틀 연속 HN에 오르는 데 성공했습니다: Typescript as fast as Rust: Typescript++&Show HN: Zaplib – Speed up your webapp with Rust+Wasm. 하지만 그 트래픽은 “장난감(toy)” 수준의 사용조차도 어떤 실사용으로도 전환되지 않았습니다. 우리는 이것이 꽤 치명적인 결과라고 느꼈습니다.
JP는 이 사실들을 발견하는 데 1년이나 걸린 것이 부끄럽습니다. 오해를 부르는 벤치마킹과 고객 인터뷰로 스스로를 속이기가 얼마나 쉬운지 보여줍니다. Steve도 비슷한 방식으로 부끄럽습니다. (그의 지난 프로젝트인) Compose도 초기 사용자들에게서 비슷한 열광을 얻었지만, 결국 스타트업으로서는 작동하지 않았습니다. 우리는 둘 다, 스스로를 속이지 않는 데 더 능숙해지기로 다짐합니다!
이번 경험의 놀라운 결과 중 하나는 우리(JP와 Steve)가 함께 일하는 것을 정말 좋아한다는 사실을 발견했다는 점이며, 다른 프로젝트를 함께 하기 위해 계속 붙어 있길 희망한다는 점입니다. 우리는 약 30개의 아이디어를 브레인스토밍했고, 그중 몇 개는 꽤 진지하게 검토했습니다.
고성능 프로 도구를 만드는 전문성을 활용해 보자는 생각으로, JP는 기계 엔지니어를 위한 Figma 같은 3D CAD 도구 시장의 빈틈을 찾느라 일주일을 보냈지만, 결국 뚜렷한 기회가 없다고 결론 내렸습니다. Solidworks, AutoDesk 등이 꽤 잘 커버하고 있는 것처럼 보입니다.
더 먼 분야로, Steve는 그 주에 소비자 조명 회사 아이디어를 조사했습니다. 소비자 하드웨어는 매우 어려운 비즈니스이고 우리의 경험과 전문성에서 크게 벗어나 있기 때문에, 매우 진지하게 보고 있진 않습니다.
지난주에는 영감을 얻기 위해, 그리고 특히 크립토에 흥미를 가질 수 있을지 보기 위해 Miami Tech Week로 마이애미에 다녀왔습니다. 거긴 확실히 개발자 도구(devtools)가 필요한 것 같긴 합니다! JP와 저는 지금까지 web3에 그다지 설레지 않았지만, 열린 마음을 유지하려고 합니다.
지금은 SF로 돌아와서 트위터를 CMS로 바꾸는 아주 바보 같은 아이디어를 만지작거리고 있습니다. 아마 ~1주일짜리 해커톤 프로젝트일 뿐이겠지만, 곧 우리의 트위터 피드에서 보게 될지도 모릅니다.
혹시 우리에게 흥미로울 것 같은 아이디어가 있다면 알려주세요! 우리는 브레인스토밍과 뚝딱거림 모드로 완전히 들어와 있습니다.
이게 우리 모두가 원했던 결말은 아니지만, 두 번째로 좋은 일은 분명합니다. 빠르게 실패하는 것이 느리게 실패하는 것보다는 확실히 낫습니다!
Steve & JP
