URL: https://www.youtube.com/watch?v=R7VLniokQCA 날짜: 2026-09-04 채널: lifeofluba 영상 ID: R7VLniokQCA 원문 제목: He Put AI Inside The Terminal Before Codex Existed- Zach Lloyd 자막: 영어 자동 자막 기반 전체 내용 번역·정리
핵심 질문 / 이 영상이 다루는 핵심 논점
==개발자 도구의 다음 단계는 사람이 터미널에서 코드를 직접 작성하는 일이 아니라, 팀의 목표를 이해한 클라우드 에이전트들이 소프트웨어 개발 공장 전체를 운영하도록 만드는 것이다.== Zach Lloyd는 Google Sheets와 Warp를 만들며 얻은 제품·조직·창업 경험을 바탕으로 이 전환에 베팅한다.
- Zach Lloyd는 Google Sheets를 초기 5명 규모의 팀에서 키웠고, Google Docs 제품군 전체의 엔지니어링을 이끈 뒤 Warp를 창업했다.
- Warp는 ChatGPT가 나오기 전부터 영어 문장을 터미널 명령어로 바꾸는 AI 기능을 제공했지만, 기존 사용자를 소외시킬까 우려해 AI에 100% 베팅하지 못했다.
- 현재 Warp는 업무의 약 30%를 자동화하며, 다음 목표를 터미널 내부 AI가 아니라 클라우드 소프트웨어 공장(Cloud Software Factory)으로 정의한다.
- 코드 생산 비용이 0에 가까워져도 제품 판단, 시스템 안전성, 사용자 문제 정의, 에이전트 공장 개선은 사람의 핵심 역할로 남는다.
좋은 창업은 유행을 좇는 일이 아니라 자신이 신뢰하고 오래 다룰 수 있는 문제를 선택하는 데서 출발한다. SelfMade에서 믿지 못하는 문제를 다루며 겪은 3년의 운영·창업자 갈등·고객 이탈은 Warp의 출발점을 만들었다. Warp의 사업 모델은 협업 터미널에서 AI 에이전트 플랫폼으로 이동했고, OpenAI·Anthropic과 모델 자체로 경쟁하기보다 다양한 모델을 고객이 선택해 쓸 수 있는 중립적 인터페이스와 인프라를 제공하려 한다. 이 변화가 성공하려면 명확한 포지셔닝, 훌륭한 제품, 엔터프라이즈 영업, 거시 환경 대응이 동시에 필요하다.
1. 사업가 집안에서 형성된 Zach의 성향
Zach의 가족 경험은 관계를 만드는 영업 감각과 직접 무언가를 구축하는 성향을 함께 형성했다.
1.1. 두 할아버지와 아버지가 보여 준 사업의 여러 형태
-
Lloyd K. Lloyd의 관계 중심 영업
- 사업 배경: 샌프란시스코에서 보험업을 하며 성공적인 사업을 운영했지만, Zach는 그를 ‘유명인’이라기보다 성공한 사업가로 기억한다.
- 성격과 강점: 매우 사교적이고 재미있으며 이야기가 많았다. 사람들과 좋은 관계를 만드는 능력이 영업의 핵심이라고 Zach는 해석한다.
- 가족과의 시간: Lloyd K. Lloyd는 Zach가 13살쯤 되었을 때 세상을 떠났지만, 대화를 나누며 보낸 기억이 많이 남아 있다.
-
초등학교 잡지 판매와 큰 화면 TV
- 잡지 판매 행사: 초등학교에서 이웃이나 친구에게 잡지 구독을 방문 판매하는 ‘magazine drive’가 열렸고, Zach는 판매에 깊이 빠져들었다.
- 보상보다 판매 자체의 재미: Game Boy를 받으려고 시작했지만 판매량이 많아져 결국 큰 화면 TV를 받았다. 필요하지 않은 잡지까지 할아버지에게 팔 만큼 적극적으로 영업했다.
- 할아버지의 반응: Lloyd K. Lloyd는 Zach가 집집마다 찾아가 물건을 파는 모습을 매우 자랑스러워했다. Zach는 이 장면을 영업 능력보다 사람을 만나 관계를 맺는 태도의 기억으로 간직한다.
-
영업보다 구축에 가까운 본능
- 창업자의 영업: 투자자에게 돈을 받도록 설득하고, 누군가 회사에 합류하도록 설득하는 일까지 포함하면 회사를 운영하는 일 자체가 여러 형태의 영업이다.
- 자기 평가: Zach는 자신을 뛰어난 세일즈맨이라고 보지는 않지만, 창업을 하며 영업 실력은 분명히 좋아졌다.
- 핵심 성향: 자신의 ‘DNA’는 판매보다 구축(building)에 가깝다. 엔지니어링과 제품을 직접 만드는 성향은 만나지 못한 다른 할아버지에게서 물려받았다고 느낀다.
-
LA의 다른 할아버지와 사업가 친척
- 섬유 사업: LA에 살던 다른 할아버지는 큰 섬유 사업을 운영했다. 두 할아버지 모두 꽤 성공적인 사업을 했지만 거대 기업을 만든 정도는 아니었다.
- Marc Benioff와의 관계: Zach의 사촌은 Salesforce 창업자 Marc Benioff다. Marc는 Zach보다 나이가 많고, Zach의 경력 여러 단계에서 실질적인 후원자 역할을 했다.
- 어린 시절의 기억: Zach가 8살쯤 되었을 때 USC에 다니던 Marc가 흰색 BMW 컨버터블로 데리러 와서 태워 주던 장면이 선명하게 남아 있다. Marc는 어린 Zach에게 ‘멋있는 사촌’이었다.
- 영업·마케팅의 모범: Marc는 영업뿐 아니라 마케팅에도 뛰어나다. Zach는 가족 안에 좋은 사업가가 많다는 사실을 인정하면서도, 사업가가 되라는 직접적인 압력을 받지는 않았다.
-
아버지의 다양한 창업과 안전한 진로에 대한 기대
- 아버지의 경력: 아버지는 한동안 영상 제작 사업을 했고 여러 사업을 시작했으며, 경력의 대부분은 홍보(PR) 분야에서 보냈다.
- 창업에 대한 가족의 태도: 사업을 시작하는 일이 가족에게 익숙한 선택이기는 했지만, 부모가 Zach에게 창업을 요구한 것은 아니다.
- 법학과의 충돌: Zach가 법학대학원(law school)을 1년 만에 그만두자 부모는 꽤 화를 냈다. 부모는 변호사가 더 안전한 진로라고 생각했고, Zach가 법학을 계속하기를 바랐다.
- 뒤늦은 안도: Zach는 법학을 계속하지 않은 일을 매우 다행스럽게 생각한다.
1.2. 여러 관심사를 거쳐 기술로 돌아온 과정
-
대학 이후의 우유부단함
- 두 마음: 졸업할 때 기술 분야로 갈지, 인문학·철학 쪽으로 갈지 확신이 없었다. 동료들처럼 학교를 마치자마자 창업하거나 학교를 중퇴할 정도의 확신은 전혀 없었다.
- 학업의 폭: 학부 전공은 수학·철학·컴퓨터과학을 섞은 독특한 학제간 과정이었다. 철학 석사 과정을 거쳤고, 논리학(logic) 박사 과정에 거의 진학할 뻔했다.
- 초기 경험: NASA에서 제트 추진(jet propulsion) 관련 업무를 했고, 해외에서 1년 살았으며, 녹음 스튜디오에서도 일했다.
- 관심의 공존: 순수한 컴퓨터과학 전공자는 아니었지만 공학적인 일, 글쓰기, 기술 밖의 분야를 모두 좋아했다. 한 길을 고르면 다른 길을 잃을 것 같다는 약한 헌신의 두려움이 선택을 늦췄다.
-
폭넓은 경험을 낭비로 보지 않는 관점
- 서두르지 않을 이유: 철학 학위, NASA 근무, 해외 생활, 녹음 스튜디오 경험은 각각 다른 방식으로 사고와 감각을 넓혔다. 22살에 훌륭한 회사를 시작했다면 멋졌겠지만, 30대에 시작하는 것도 충분히 멋지다.
- 열정을 찾는 사람에게 주는 첫 조언: 여러 경험을 쌓는 동안 자신을 괴롭히지 말아야 한다. ‘완벽한 선택’을 당장 찾아야 한다는 압박보다 직접 여러 일을 시도하며 자신이 무엇에 반응하는지 확인하는 편이 낫다.
- 결국 필요한 헌신: 어느 시점에는 자신이 중요하게 생각하는 일에 commit해야 한다. 모든 것을 영원히 열어 두는 것이 목표는 아니다.
-
프로그래밍을 다시 선택한 계기
- 현실적 동기: 돈을 벌어야 할 때 ‘내가 무엇을 할 줄 아는가’를 생각했고, 프로그래밍을 할 줄 안다는 사실을 떠올렸다.
- 만드는 즐거움: 다시 프로그래밍을 시작하자 실제로 재미있고, 무언가를 만드는 일이 좋다는 사실을 발견했다.
- 가치 판단: 구축하는 일이 세상에 긍정적인 일이 될 수 있다고 느끼면서 기술에 머물렀다. 완벽한 진로를 찾기보다 흥미롭다고 느끼는 일을 하는 데 집중하게 됐다.
-
AI 시대에 오래 남을 역량
- 덜 안전한 베팅: AI가 매우 잘할 수 있는 특정 직무 기술(niche vocational skill), 특히 코딩 같은 한 가지 기능에만 기대는 것은 위험하다.
- 더 안전한 베팅: 넓게 생각하는 능력, 시스템 사고(systems thinking), 문제 해결(problem solving), 적응력(adaptability)을 키워야 한다.
- 좋은 학문적 훈련: 철학은 제1원리(first principles) 방식의 사고와 분석, 글쓰기 훈련을 제공한다. 수학과 물리학을 포함한 STEM 학위도 명확하게 추론하는 법을 배우게 해 유용하다.
- AI에 의도를 전달하는 글쓰기: AI에게 일을 시키는 세상에서는 자신의 의도를 정확히 글로 전달하는 능력이 매우 중요하다. 좋은 추론과 좋은 글쓰기가 핵심 역량이다.
- 진로 선택의 경고: 지식 노동의 많은 직무가 AI의 영향을 받을 수 있으므로 특정 직업 기술에 지나치게 고정되지 않는 편이 낫다.
1.3. 빠른 AI 시대의 신뢰·컴플라이언스 문제
-
속도만으로는 차별화되지 않는 환경
- 창업자의 이전 집착: 빠르게 움직이는 것 자체가 창업자의 차별화 요소라고 생각했지만, AI 시대에는 모두가 매우 빠르게 움직인다.
- 새로운 질문: 고객 데이터를 맡아도 되는 회사인지, 빠른 개발 과정에서 생긴 신뢰와 컴플라이언스(compliance) 공백을 해소했는지가 중요해진다.
-
Vanta의 제안
- 자동화 범위: Vanta는 컴플라이언스의 고통스러운 부분을 자동화한다고 소개됐다.
- 지원 프레임워크: SOC 2, ISO 27001, HIPAA 등을 포함해 35개가 넘는 프레임워크를 지원한다고 홍보됐다.
- 지속 모니터링: 모델, 고객, 인프라가 변화하는 동안 백그라운드에서 상태를 계속 모니터링한다.
- 고객 사례와 혜택: RAMP, Cursor, Harvey를 포함한 16,000개 이상의 고성장 기업이 신뢰한다고 소개됐으며,
vanta.com/luba에서 1,000달러 할인 혜택을 제공한다고 안내됐다.
2. Google Sheets에서 배운 제품·리더십
Zach의 Google 경험은 기술적 구축뿐 아니라 사람에게 권한을 주고 팀의 목표를 정렬하는 관리 원칙을 만들었다.
2.1. Google Sheets 초기 팀과 Fuzzy의 관리 방식
-
Google Sheets에 합류한 시점
- 초기 규모: Zach가 Google Sheets에 들어갔을 때 팀은 약 5명이었다.
- Google 내부의 위치: Google의 랩(lab)에 속한 매우 초기 제품이었고, 정식 출시된 제품이 아니었다. Google 제품치고 사용자가 매우 적었다.
- 인수의 배경: Fuzzy와 Jonathan Rochelle이 시작한 회사에서 Google Sheets의 뿌리가 나왔다. 원래 제품은 완전히 같은 협업 스프레드시트가 아니라 다른 제품이었지만 유사한 방향을 갖고 있었다.
- 성장 경로: Fuzzy와 Jonathan은 초기 버전을 많이 만들었고, Google이 그 회사를 인수하면서 Google Sheets가 형성됐다.
-
Fuzzy가 만든 권한 부여의 구조
- 경력에 대한 관심: Fuzzy는 부하의 경력을 어떻게 발전시키고 어떤 기술을 키울지 진지하게 생각하는 사람이라는 느낌을 줬다.
- 어려운 일의 기회: 해야 할 일을 세세하게 지시하기보다 더 어려운 일을 맡을 공간을 만들었다. 개인이 영향력을 내면서 성장하도록 돕는 방식이었다.
- 공감과 대인관계: Fuzzy는 공감 능력과 대인관계 기술이 뛰어났고, 함께 일하고 싶은 팀과 모두가 중요하다고 느끼는 목표를 세웠다.
- 관리자의 핵심 임무: 뛰어난 사람을 많이 가진 조직에서 관리자는 직접 통제하기보다 각자가 힘을 발휘할 수 있게 만드는 역할을 해야 한다.
-
준비되기 전의 엔지니어링 리드 임명
- 불편함을 동반한 신뢰: Fuzzy는 Google Sheets의 엔지니어링 리드를 매우 이른 시기에 Zach에게 맡겼다. Zach는 자신이 준비됐다고 생각하지 않았고, 이미 팀에 오래 있던 사람들도 있어 약간 불편했다.
- 창업자가 자기 코드에서 물러남: Fuzzy는 자신이 시작하고 초기 버전을 만든 제품의 엔지니어링을 Zach에게 맡겼다. Zach는 이를 큰 신뢰의 표시로 받아들였다.
- 코드를 없애는 일을 자랑한 태도: Fuzzy는 Zach가 자신의 코드를 모두 없앴다는 사실을 불쾌해하지 않고 오히려 자랑했다. ‘전부 없애라’는 태도는 창업자의 자존심보다 제품을 우선한 겸손을 보여준다.
-
마사지 의자 일화가 보여 준 인간적인 관리
- 초기의 압도감: Zach는 Sheets 기술이 어떻게 작동하는지 배우느라 완전히 감당하지 못하는 상태였다.
- 밤 8시의 장면: 어느 날 밤 8시쯤 Google의 마사지 의자에 앉아 있던 Zach를 Fuzzy가 발견했다. Fuzzy는 ‘Zach가 괜찮은가?’라고 걱정했다.
- 관리 원칙으로의 전환: Fuzzy는 나중에 자신의 코드 때문에 Zach가 Google을 그만둘까 걱정했다는 일화를 반복해서 말했다. 유머와 겸손을 함께 사용하면서도 사람의 부담을 살폈다.
- Zach가 이어받은 원칙: 사람을 성장시키고, 잘 대하며, 자신이 만든 영역도 기꺼이 넘기는 태도가 Zach의 엔지니어링 팀 관리 방식에 남았다.
2.2. 일반주의자와 성장 기회를 주는 조직
-
Michelle의 경로
- 초기 합류: Michelle은 대학을 졸업하자마자 Warp에 합류한 매우 똑똑하고 재능 있으며 추진력 있는 인재였다.
- 역할의 확장: 엔지니어링을 한 뒤 성장팀을 이끌었고, 잠시 제품을 맡았으며, 초기 영업도 담당했다.
- 능력의 원천: 여러 역할을 잘한 이유는 특정 직무의 전문가라서가 아니라 학습 속도가 빠르고 도전을 원하며 새로운 일을 배워내는 역량이 있었기 때문이다.
-
스타트업 초기 채용 원칙
- 슈퍼 재능 있는 일반주의자: 초기 스타트업은 한 분야만 깊게 아는 사람보다 여러 핵심 문제를 넘나들 수 있는 뛰어난 일반주의자를 채용해야 한다.
- 회사와 개인의 동시 성장: Michelle에게 다양한 역할을 맡긴 것은 Warp에 이로웠고, 언젠가 창업하고 싶다는 Michelle에게 창업에 필요한 여러 경험을 제공했다.
- 기회의 의미: 좋은 관리자는 구성원에게 지시 목록만 주는 사람이 아니라 영향력 있는 일을 해볼 자리를 찾아주는 사람이다.
3. SelfMade에서 얻은 실패의 교훈
SelfMade는 매출과 투자 유치에는 성공했지만 Zach가 믿는 제품·문제·운영 형태를 제공하지 못했다. 이 경험은 Warp에서 같은 실수를 피하려는 기준이 됐다.
3.1. Google 이후 첫 창업과 공동창업자 갈등
-
Google에서 떠난 시점
- Google에서의 경력: Google에 7~8년 정도 있었고, 퇴사할 때는 Google Docs 제품군 전체의 엔지니어링을 이끌고 있었다.
- 다른 도전에 대한 욕구: 오래전부터 무언가를 시작하고 싶었고, Google에서 얻은 경험 이후 다른 종류의 도전을 원했다.
-
사진 공유 앱이라는 첫 아이디어
- 아이디어의 한계: 모바일 사진 공유 앱을 직접 만들겠다는 생각은 돌이켜보면 꽤 나쁜 아이디어였다. Instagram이 이미 존재한 뒤 ‘Instagram 같은 것’을 만들려 했기 때문이다.
- 혼자 만든 6개월: Google을 떠나 직접 만들겠다고 결심하고 약 6개월 동안 작업했다.
- 초기 사용성: 몇 천 명 정도가 사용했지만 제품이 어디로 가는지 알 수 없었다. Google의 수억 명 사용자와 비교하면 괜찮아 보일 수도 있지만, 스스로는 성장이 없다고 판단했다.
-
공동창업자 탐색과 SelfMade 합류
- 네트워크 확장: 무엇을 하는지 잘 모르겠다는 판단 뒤 네트워크를 넓히고 창업이 어떻게 작동하는지 더 배우려 했다.
- 공동창업자 매칭: 뛰어난 세일즈맨이자 회사를 시작하려는 사람과 연결됐고, 기술 공동창업자 역할을 제안받았다. Zach는 그 사업을 할 만한 일이라고 설득돼 합류했다.
- 역할에 대한 불만: 첫 회사에서 CTO였던 Zach는 두 핵심 인물 중 한 명이지만 최종 결정을 내리는 사람은 아닌 위치가 불편했다. 이 경험은 훗날 Warp를 단독 창업하려는 결정으로 이어졌다.
-
사진 편집 서비스에서 출발한 사업
- 사업 모델: AI가 사진 편집을 대체하기 전, 모바일 앱으로 사진을 보내면 사람이 사진을 보정하거나 마케팅용 이미지처럼 개선해 주는 사진 편집 서비스였다.
- 피벗과 규모: 사업은 여러 번 피벗했고, 매출은 수백만 달러 규모로 늘었으며 Series A 투자도 유치했다.
- 제한적인 제품-시장 적합성: 수요는 있었다. 고객은 서비스를 원했고 팀은 계속 판매할 수 있었다. 그러나 폭발적으로 성장하는 로켓십은 아니었고, 진정한 product-market fit을 얻었다고 보기는 어려웠다.
3.2. 믿지 않는 문제를 팔 때 생기는 비용
-
개인적 관심과 고객 문제의 불일치
- 고객층: 고객은 소셜미디어에 적극적이거나 인플루언서가 되고 싶어 하는 사람들이 많았다.
- Zach의 무관심: Zach는 인플루언서가 더 좋은 사진을 올리는 문제에 거의 관심이 없었다.
- 영업의 난점: 믿지 않는 것을 판매하는 일은 어렵다. 제품의 필요성을 설명할 때 창업자의 확신이 흔들리기 때문이다.
-
운영 중심 사업과 소프트웨어 성향의 충돌
- 조직 규모: SelfMade에는 약 150명이 일했고, 그중 약 100명이 인도네시아 자카르타에서 사진을 편집했다.
- 운영 복잡성: 제품 개발보다 대규모 인력 조정과 작업 배분이 사업의 큰 부분을 차지했다.
- 개인적 부적합: Zach는 운영 중심 사업이 자신의 열정이나 강점이 아니며, 소프트웨어 사업을 만들고 싶다는 사실을 분명히 깨달았다.
- 비슷한 경고 신호: Airbnb에서 약 4년 반을 일한 뒤 동유럽 엔지니어를 기업에 연결하는 아웃소싱 사업을 시도한 사례에서도, 프로젝트가 정해질 때까지 인력을 대기시키고 채용 운영을 관리하는 일에 강한 거부감을 느꼈다는 대화가 이어졌다. 운영이 무거운 사업은 같은 경고를 반복해서 보여줬다.
-
제품이 훌륭하지 않을 때의 악순환
- 고객 이탈: SelfMade는 고객을 계속 유치했지만 제품 자체가 훌륭하지 않았다. 그 결과 churn이 많았고 고객 불만도 많았다.
- 매출과 제품의 분리: 매출이 수백만 달러이고 Series A를 받았다는 사실만으로 진짜 제품-시장 적합성이 증명되지는 않는다.
- 창업자의 감정: 고객에게 판매할 수는 있지만 자신이 믿지 않는 일을 하고 있다는 감각은 지속적인 스트레스를 만들었다.
-
퇴사 후 한 달 동안 쓴 비공개 사후 분석
- 기록의 규모: SelfMade를 떠난 직후 한 달을 들여 약 40쪽의 긴 postmortem을 작성했다.
- 기록한 내용: 무슨 일이 벌어졌고 무엇을 배울 수 있는지, 다시 같은 상황에 놓이면 무엇을 다르게 할지 정리했다.
- 공개하지 않는 이유: 글에는 매우 검열되지 않은 생각과 사람·상황에 대한 솔직한 내용이 담겨 있어 공개하지 않기로 했다.
- 기억 보존의 기능: 적어 두지 않았다면 잊었을 경험을 기록으로 남겼다는 점에서, 공개 여부와 별개로 사후 분석은 가치가 있었다.
-
Warp로 가져간 핵심 기준
- 믿는 일을 선택하라: ‘요가 강사가 Instagram에 더 좋은 사진을 올리도록 도왔다’고 자녀에게 설명하는 것보다 자신이 중요하게 여기는 일을 만들었다고 말할 수 있어야 한다.
- 소프트웨어를 만들라: 운영 인력 조정이 중심인 사업보다 직접 소프트웨어를 구축하는 일이 Zach에게 맞았다.
- 동기와 미션을 연결하라: 세상을 긍정적으로 만드는 일이라는 믿음이 제품을 오래 밀고 갈 동력이 된다.
- 같은 실수는 피하고 다른 실수는 감수하라: Warp를 시작할 때 SelfMade에서 반복한 특정 실수는 다시 하지 않겠다고 결심했다. 다른 실수까지 모두 없앨 수는 없지만, 이미 비용을 치른 실수는 의식적으로 피하려 했다.
4. Warp를 선택한 아이디어 탐색과 단독 창업
Warp는 이미 널리 쓰이지만 사용자 경험이 낡은 개발자 도구를 현대화하고, Zach가 잘 알고 중요하게 생각하는 개발자 문제를 다루려는 선택이었다.
4.1. Google Sheets와 터미널의 평행선
-
제품 선택 기준
- 넓은 사용성: 많은 사람이 매일 여는 제품이어야 한다.
- 개선 여지: 현재 제품이 충분히 좋지 않아 더 나은 경험을 만들 수 있어야 한다.
- 경제적 가치: 사용자가 그 도구 안에서 실제로 가치 있는 일을 만들어야 한다. 스프레드시트가 사업 가치를 만들어내는 것처럼 개발자의 터미널 작업도 경제적 가치가 크다.
-
터미널을 고른 이유
- 오래된 경험의 문제: 기존 터미널은 개발자가 거의 매일 열지만, 명령어·작업 흐름·오류 처리가 불편하다.
- 개선 가능성에 대한 확신: Zach는 좋은 터미널을 직접 만들 수 있고, 자신의 기술과 도메인 지식이 문제에 잘 맞는다고 판단했다.
- Google Sheets와의 평행선: Google Sheets가 스프레드시트를 다시 정의한 것처럼 Warp는 터미널을 현대화하려 했다.
- 초기 협업 방향: 원래 Warp의 개념에는 터미널을 협업 도구로 만드는 목표도 포함돼 있었다. 다만 이후 협업은 강한 사업 모델이 되지 못했다.
4.2. 관심 영역과 고통 지점으로 좁힌 아이디어 미로
-
먼저 정한 영역
- 소프트웨어 중심: Zach는 소프트웨어를 만들고 싶었다.
- 두 고객군: 지식 노동자를 돕거나 개발자를 돕는 일을 선택지로 정했다.
- 개인적 적합성: 두 영역은 자신이 알고 관심을 가지며, 일을 마친 뒤에도 자부심을 느낄 수 있는 분야였다.
-
그 안에서의 필터
- 직접 겪은 고통: 자신의 삶과 업무에서 실제로 불편을 경험한 문제를 찾았다.
- 유용한 것을 만들 수 있는가: 단순히 흥미로운 아이디어가 아니라, 자신이 유용한 제품을 만들 수 있는지 검토했다.
- 개발자 영역으로의 수렴: 지식 작업 공간을 만들 수도 있었지만, 개발자 도구에 대한 지식이 더 깊다고 느껴 터미널로 좁혔다.
-
아이디어를 다듬은 방식
- 주간 프로토타이핑: 일주일 동안 아이디어를 생각하고 프로토타입을 만들었다.
- 정기 피드백: 1~2주마다 신뢰하는 사람들과 대화하며 ‘이 아이디어가 어떤가’를 확인했다.
- 최종 선택: 여러 후보를 돌고 돌아 사용 빈도, 경제적 가치, 기술적 자신감, 개인적 관심이 겹치는 터미널을 선택했다.
4.3. 투자자와 사용자 사이에서 아이디어를 검증하는 법
-
초기 조언자
- Sky와 BoxGroup: BoxGroup의 시드 단계 투자자 Sky가 아이디어 탐색을 도왔다.
- Eric과 GV: GV의 Eric도 매주 또는 1~2주 간격으로 피드백을 줬다. Eric은 과거 Google의 엔지니어였고 두 사람 모두 SelfMade 전부터 알던 사이였다.
- 친구에 가까운 신뢰: 두 사람이 투자자가 되려 했지만, Zach에게는 오랫동안 알고 지낸 친구처럼 대화할 수 있는 관계였다.
-
VC와 이야기할 때의 균형
- 정답인 시스템은 없음: VC와 대화하는 방식이 유일하게 맞는 방법은 아니다.
- 대안: 잠재적 공동창업자와 논의하거나, 잠재 사용자를 직접 만나 아이디어를 보여주는 방식도 충분히 유효하다.
- 인센티브 인식: 투자자는 투자하고 싶어 하는 사람이라는 사실을 잊지 말아야 한다. 친밀한 관계라도 조언자의 이해관계와 창업자의 이해관계가 완전히 같지는 않다.
-
공동창업자를 찾지 않은 이유
- 첫 회사의 경험: CTO였던 SelfMade에서 최종 의사결정자가 아닌 핵심 인물로 일한 경험을 반복하고 싶지 않았다.
- 필요한 보완 역량의 부재: Warp는 개발자 중심 제품이므로 자신이 제품 대부분을 이끌 수 있다고 생각했다.
- 도메인 지식: 개발자 도구에 대한 지식이 있었고, 제품 판단을 외부에 의존할 필요가 크지 않았다.
- 채용 자신감: SelfMade에서 배운 채용 경험 덕분에 필요한 사람을 잘 뽑을 수 있다고 믿었다.
5. 사람을 뽑고 비전으로 설득하는 법
초기 스타트업의 채용은 돈을 제시하는 거래가 아니라, 뛰어난 사람이 회사의 승리 가능성과 미션을 믿도록 만드는 영업이다.
5.1. 채용은 영업이며 미션을 파는 일이다
-
뛰어난 사람에게 선택권이 있다
- 기회의 풍부함: 정말 뛰어난 사람은 선택할 수 있는 기회가 많다.
- 돈만으로 부족함: 높은 급여만 제시해서는 그 사람이 위험한 초기 스타트업을 선택하게 만들기 어렵다.
- 설득해야 할 항목: 회사가 성공할 가능성이 있고, 미션이 매력적이며, 좋은 직장이 될 것이라는 믿음을 줘야 한다.
-
보상과 소유권
- 미션 중심 인재: 최고의 인재는 돈보다 미션에 강하게 동기 부여되는 경우가 많다.
- 지분 선호: 스타트업에 오는 사람은 회사의 소유권(equity)과 승리에 참여하기를 원한다. 급여를 무리하게 높이기보다 지분을 통해 이해관계를 맞추는 편을 선호한다.
- 현실적인 급여: 생활비가 필요하므로 회사는 가능한 한 경쟁력 있는 급여를 지급해야 한다. 다만 큰 연봉만을 원하는 사람은 스타트업의 위험과 소유권 구조를 제대로 받아들이는지 확인해야 한다.
-
채용 피치의 구성
- 제품 비전: 무엇을 만들고 왜 중요한지 설명해야 한다.
- 사업 기회: 시장의 크기와 회사가 이길 수 있는 이유를 보여줘야 한다.
- 리더십 신뢰: 창업자가 유능한 관리자이자 리더라는 점을 입증해야 한다.
- 초기부터 최고 인재 확보: 자본이 있어 팀을 채용할 수 있다면 처음부터 가능한 최고의 사람을 끌어오는 데 집중해야 한다. 이 과정은 상당한 시간과 노력을 요구한다.
5.2. 터미널이라는 비직관적 아이디어의 투자 논리
-
투자자 논리
- 매일 열리는 도구: 거의 모든 개발자가 매일 터미널을 열고, 그 안에서 사업에 중요한 일을 한다.
- 낮은 제품 품질: 기존 터미널은 Zach의 기준으로는 제대로 작동하지 않는 부분이 많았다. 일부 개발자는 기존 터미널을 사랑하지만 Zach는 강하게 낮게 평가했다.
- 초기 사용자 확보 가능성: 매일 쓰는 도구의 경험을 크게 개선하면 많은 개발자를 사용자가 될 수 있다.
-
비직관성과 경쟁 방어력
- 낮은 경쟁 압력: 모든 창업자가 터미널 재설계를 선택하지는 않으므로, 초기에 극심한 경쟁 없이 좋은 제품을 만들 기회가 있었다.
- 기술적 난이도: 좋은 터미널을 만드는 일은 기술적으로 어렵다. 제대로 만들면 쉽게 복제하기 어렵다.
- 투자자의 패턴 매칭: 투자자들은 Warp를 Figma나 Airtable처럼 기존 범주를 다시 정의하는 제품과 비교했다.
-
초기의 사업 모델 문제
- 협업 가설: Warp는 터미널 협업 기능을 중심으로 사업 모델을 만들 수 있다고 생각했다.
- 검증 결과: 터미널에서 협업하려는 수요는 생각보다 강하지 않았다. 몇 가지 가치 있는 사용 사례를 가정했지만 실제 pull은 약했다.
- 현재의 재평가: 에이전트 개발이 부상하면서 협업의 의미는 다시 커지고 있지만, 초기 터미널 협업 가설이 그대로 사업 모델이 된 것은 아니다.
5.3. 사용자 견인력에서 AI 사업 모델로
-
터미널 제품의 견인력
- 빠른 사용자 반응: 좋은 터미널에 대한 판단은 맞았고, Warp는 초기부터 많은 사용자를 얻었다.
- 사용자 수: Warp 사용자는 약 100만 명에 가까워졌다. Instagram과 비교하면 작아 보이지만 개발자 전체 시장을 고려하면 매우 큰 수치다.
- 비교 기준: Claude Code의 정확한 사용자 수는 알지 못하지만 약 500만 명 규모로 언급됐다. 개발자 도구에서 100만 명은 상당한 도달 범위다.
-
2020년 시작과 AI의 등장
- 초기 시점: Warp는 2020년에 시작했고, 처음부터 에이전트 시대를 예측한 것은 아니었다.
- ChatGPT 이전 기능: ChatGPT가 등장하기 전부터 영어로 입력한 문장을 터미널 명령어로 바꾸는 기능을 제공했다.
- 문제 적합성: 터미널에는 이해하기 어려운 명령어, 복잡한 워크플로, 각종 오류가 많다. 터미널 안에 AI를 직접 넣는 일은 자연스러운 제품 경험이었다.
-
ChatGPT 이후의 단계적 전환
- 한 달 안의 기능 출시: ChatGPT가 나온 뒤 약 한 달 만에 Warp에 유용한 AI 기능을 추가했다.
- 초기 형태: 처음 기능은 터미널에 자연스럽게 녹아든 것이 아니라 별도 채팅 패널에 가까웠다.
- 네이티브 경험의 발견: 시간이 지나면서 채팅창을 붙이는 것보다 터미널과 개발 흐름 자체에 AI를 통합하는 편이 훨씬 낫다는 사실을 깨달았다.
- 2023년 말의 방향 전환: 2023년 말에는 협업보다 AI를 중심으로 회사의 방향이 거의 완전히 정렬됐다.
-
Codex·Claude Code보다 먼저 보았지만 충분히 베팅하지 못한 미래
- 선행 기능: Warp에는 Claude Code(자막의 ‘Cloud Code’)나 Codex처럼 작동하는 기능이 이들보다 약 6개월 먼저 있었다.
- 제한된 범위: 그 기능은 실제 코드 작성보다 터미널 작업만 처리했다. 개발 전체를 자동화하는 방향으로 확장하지 못한 것이 실수였다.
- 후회: 미래를 일찍 본 순간이 여러 번 있었지만 더 세게 밀어붙이지 못했다. AI를 50% 정도의 추진력으로 다뤘고, 사실상 100%의 추진력으로 가야 했다.
- 기존 사용자에 대한 두려움: AI에 회의적인 기존 사용자를 소외시킬까 걱정했다. 개발자 사이에는 AI가 서툰 코드를 만들 것이라는 반감이 오랫동안 있었다.
- 현재의 결단: 이제 Warp는 터미널 기능에만 머무르지 않고 AI만을 중심으로 움직인다. 과거처럼 기회를 보고도 위험을 충분히 감수하지 않는 일을 반복하지 않으려 한다.
6. 클라우드 소프트웨어 공장과 ‘팩토리 엔지니어’의 탄생
소프트웨어 개발은 대화형 코딩 도구를 사용하는 개인 작업에서, 팀 전체를 위해 클라우드 에이전트가 개발 수명 주기를 수행하는 자동화된 공장으로 이동한다.
6.1. 다음 큰 일: 개발 자동화
-
개인용 코딩 에이전트에서 팀용 에이전트로
- 현재의 방식: 개발자가 노트북 앞에 앉아 Claude Code나 Codex에 무엇을 할지 직접 입력한다.
- 다음 방식: 에이전트가 클라우드에 살며 팀의 목표와 코드베이스를 중심으로 움직인다.
- 자동화 범위: 버그에 응답하고, 서버 크래시를 고치며, 원인을 진단하고, 수정안을 만들고, 가능한 경우 배포까지 수행한다.
-
사람이 승인하는 예외와 에이전트가 처리하는 반복
- 단순한 수정: 단순한 버그라면 에이전트가 수정하고 merge할 수 있다. 사람은 검토할 수도 있고 생략할 수도 있다.
- 복잡한 문제: 제품 방향, 올바른 구현, 위험한 변경처럼 어려운 문제는 인간이 판단한다.
- 사후 감시: 에이전트는 수정 이후에도 문제가 해결됐는지 모니터링한다.
-
Warp의 현재 자동화율
- 약 30% 자동화: Warp는 현재 업무의 약 30%를 완전히 자동화하고 있다.
- 개발자의 역할 변화: 엔지니어가 코드를 직접 작성하는 빈도는 크게 줄었지만, 흥미로운 엔지니어링 일이 사라진 것은 아니다.
- 시스템 개선: 엔지니어는 자동화 시스템과 그 순환 구조를 더 유용하고 빠르며 저렴하게 만드는 데 집중한다.
- 비용 문제: 지능을 실행하는 도구는 매우 비싸기 때문에 자동화 시스템을 효율화하는 일이 중요하다.
6.2. 엔지니어는 제품 관리자보다 ‘시스템의 수호자’가 된다
-
제품 사고의 비중 확대
- 모든 엔지니어의 제품 인터뷰: Warp는 엔지니어 채용 과정에서 모든 엔지니어에게 제품 관리(product management) 인터뷰를 받게 한다.
- 항상 존재한 원칙: 제품을 중요하게 생각하는 사람을 채용해 왔고, 자동화 시대에는 이 기준이 더 중요해진다.
- 좋은 문제 정의: 무엇을 만들어야 하는지, 그것이 실제 사용자 문제를 해결하는지 결정하는 능력이 중심이 된다.
-
시스템 사고와 안전성
- 치명적 실패의 위험: 에이전트가 일을 자동화해도 시스템을 이해하지 못하면 재앙적인 변경을 만들 수 있다.
- 지켜야 할 속성: 앱이 느려지거나 버그가 늘거나 충돌하거나 사용자 데이터를 잃지 않는지 확인해야 한다.
- 두 가지 역할: 엔지니어는 제품 방향을 제시하면서 자동화 공장이 합리적인 시스템을 만들도록 안내하는 사람이 된다.
-
팩토리 엔지니어(factory engineer)
- 새로운 직업의 정의: 엔지니어는 제품 자체만 만드는 사람이 아니라 제품을 만드는 시스템을 구축하고 관리한다.
- 조립 라인 비유: 직접 제품을 만드는 일은 자동차 조립 라인에서 차를 빼내 문 하나를 망치로 달아 붙이는 것과 같다.
- 더 나은 레버리지: 원하는 일은 문 1,000개를 달 수 있는 로봇과 조립 라인을 만드는 것이다.
- 사고방식의 전환: ‘제품을 어떻게 만들까’에서 ‘제품을 만드는 시스템을 어떻게 만들고 개선할까’로 엔지니어링의 중심이 이동한다.
6.3. 엔지니어 수와 소프트웨어 생산량의 역설
-
인력의 증감은 불확실함
- 직업의 변화: 엔지니어링이 줄어들지, 늘어날지는 아직 알 수 없다. 확실한 것은 업무의 내용이 바뀐다는 사실이다.
- 생산 비용의 하락: 코드의 비용, 더 정확히는 소프트웨어를 생산하는 비용이 0에 가까워진다.
-
무한한 소프트웨어 수요
- 기업의 backlog: 모든 회사에는 제품과 고객 경험을 개선하고 싶어 하는 일의 목록이 끝없이 쌓여 있다.
- 새 사업의 생성: 기존 제품 개선뿐 아니라 새 사업을 시작하기 위한 소프트웨어 수요도 계속 생긴다.
- 가능한 결과: 생산량이 폭발하면 개발자가 줄어들 수도 있지만, 수요가 더 빨리 커져 같은 수의 개발자가 훨씬 다른 일을 하게 될 가능성도 있다.
6.4. 앱의 쇠퇴와 아이디어에서 결과로의 직접 이동
-
온디맨드 앱의 극단
- 현재의 시작점: 사람은 프롬프트를 입력해 Claude Code, Codex, Warp에게 앱을 만들어 달라고 할 수 있다.
- 극단까지 밀어붙인 결과: 모든 앱이 누군가 필요로 하는 순간에 만들어지고, 특정 사용자의 정확한 용도에 맞게 맞춤화될 수 있다.
- 기존 앱 대비 이점: 여러 사람이 평균적인 사용자를 위해 만든 앱보다, 개인의 순간적인 문제를 정확히 해결하는 경험이 더 나을 수 있다.
-
Google Sheets UI를 거치지 않는 데이터 분석
- 기존 방식: Google Sheets를 열고 수식을 입력하고, 글자를 굵게 만들고, 행과 열을 드래그하며 인터페이스 사용법을 배워야 했다.
- 새 방식: CSV를 에이전트에 붙여 넣고 ‘이 데이터에서 XYZ를 분석해 달라’고 요청하면 된다.
- 결과 요청: 그래프를 만들거나, 인사이트를 설명하거나, 원하는 통계 분석을 수행하라고 바로 말할 수 있다.
- 중간 생산성 앱의 약화: 사용자가 인터페이스를 배우며 많은 조작을 해야 하는 중간 단계의 생산성 앱은 시간 낭비가 될 수 있다.
-
남는 것과 사라지는 것
- 물리적 가치: 로봇이 더 널리 보급되기 전까지 물리적 전달·현장 운영의 가치는 안전하다. DoorDash는 순수 소프트웨어 회사라기보다 소프트웨어가 활성화한 배송 회사다.
- 네트워크 효과: Stripe처럼 복잡한 통합과 거대한 네트워크 효과를 보유한 회사는 안전하며, AI 전환의 수혜를 볼 수 있다.
- 데이터·업무 로직: Salesforce의 UI는 훌륭하지 않지만, 그 안에 축적된 데이터·비즈니스 로직·워크플로는 여전히 가치 있다.
- UI의 대체: Salesforce나 Google Sheets 자체가 사라진다기보다, 사용자가 UI를 직접 조작하는 방식이 일반 에이전트 인터페이스에 의해 잠식될 가능성이 크다.
- 취약한 범주: 데이터베이스 위에 얹은 기본적인 SaaS UI는 불필요해질 수 있다. 데이터베이스는 계속 유용하지만, 단순한 조작 화면은 에이전트가 대신할 수 있다.
7. 단독 창업자의 결단, 압박과 자기 관리
단독 창업자는 최종 책임을 피할 수 없으며, 시장 신호를 해석하고 자신의 약점을 보완하면서도 가족과 건강을 지켜야 한다.
7.1. 100% 베팅을 방해한 헤지 성향
-
전면 베팅의 어려움
- 최근의 개선 과제: Zach는 리더로서 한 가지에 완전히 commit하는 능력을 더 키워야 한다고 말한다.
- 반복된 패턴: Warp에서 여러 일을 동시에 하려는 경향이 있었고, 하나를 고른 뒤 ‘망설이지 말고 가자’고 하지 못한 순간이 있었다.
- 개인적 뿌리: 철학과 상징 시스템을 모두 하고 싶어 했던 20대의 성향이 회사 운영에도 나타났다.
-
헤지보다 큰 베팅이 필요한 이유
- 최대 집중: 선택한 큰 베팅에 최대한 집중해야 한다.
- 실패 가능성의 수용: 틀릴 수는 있지만 맞았을 때의 결과는 여러 방향으로 분산한 경우보다 훨씬 크다.
- 현재의 선택: Warp는 하고 싶은 수많은 일 중 클라우드 소프트웨어 공장이라는 한 개념에만 집중한다.
- 사용자 기반의 전환: 기존 터미널 사용자 기반을 새로운 방향으로 데려오되, 미래를 봐 놓고도 위험을 충분히 감수하지 않는 일은 피한다.
-
누가 창업자를 견제하는가
- 배우자의 역할: 배우자는 Zach가 좋은 아버지인지, 일만 하다 불행해지지 않는지 지켜본다.
- 시장의 역할: 회사가 실제로 작동하는 사업을 만들어야 한다는 점에서 궁극적으로 창업자를 평가하는 것은 시장이다.
- 투자자의 한계: 투자자는 창업자를 관리하지 않는다. 투자하고 실행을 지원하지만 일상적인 결정을 대신하지 않는다.
- 자기 관리: 결국 무엇을 만들고 어떻게 실행할지 관리하는 사람은 창업자 자신이다.
7.2. 창업자의 고통과 장기적 관점
-
팀의 이탈
- 떠나는 사람에 대한 감정: 좋은 사람이 회사를 떠나면 자신이 무언가를 망쳤다고 느낀다.
- 이탈의 여러 이유: 번아웃, 더 좋은 기회, Anthropic 같은 회사의 영입 등으로 사람이 떠날 수 있다.
- 채용의 어려움: 좋은 사람을 다시 뽑는 일은 어렵기 때문에 팀의 이탈은 특히 큰 좌절감을 준다.
-
성과 그래프와 통제감
- 항상 모두를 만족시킬 수 없음: 팀의 사기를 유지하고 모든 사람을 늘 행복하게 만드는 일은 어렵다.
- 숫자의 진동: 지표가 올라갈 때도 내려갈 때도 있으며, 매일 그래프를 바라보면 삶 전체가 그래프에 잠식될 수 있다.
- 통제할 수 있는 것: 결과를 완전히 통제할 수는 없다. 통제할 수 있는 것은 실행의 질과 방식이다.
- 장기 관점: 하루의 숫자보다 장기적인 실행을 바라보는 정신적 거리를 만들어야 한다.
-
커뮤니케이션 코치
- 역할: Warp에는 임원 커뮤니케이션(executive communication)을 전문으로 하는 외부 컨설턴트가 있다.
- 지원 범위: 언론과 대화하는 방법, 회사에 메시지를 전달하는 방법, 전체적인 프레이밍을 돕는다.
- 부재한 역할: 현재 정식 CEO 코치나 임원 코치는 없다.
-
몸과 마음을 끊어 내는 방법
- 운동: 허리가 아프지 않을 때 매일 운동하려고 한다. 운동이 가장 좋은 스트레스 해소 수단이다.
- 아이와의 시간: 아이는 회사에 전혀 관심이 없다. 그래서 아이와 함께 있으면 회사의 숫자와 지위에서 벗어날 수 있다.
- 요리와 TV: 요리를 좋아하고, 요리할 때
Top Chef,Beat Bobby Flay같은 아무 생각 없이 볼 수 있는 요리 경연 프로그램을 즐긴다. - 농촌 생활: 현재 사는 곳은 시골이라 Domino’s 피자조차 배달되지 않는다. 요리는 취미이면서 필요에 의한 일이기도 하다.
7.3. 가족에게 요구되는 지원과 단독 창업의 책임
-
결혼·가족의 시간표
- 창업 당시: Warp를 시작했을 때 Zach와 배우자는 아직 결혼하지 않았고, 몇 년 뒤 결혼했다.
- 배우자의 생활: 두 사람은 배우자가 일할 수 있는 곳으로 이주했고, 배우자는 겨울에 스키 강사로 일한다.
- 육아 분담: Zach도 아이를 많이 돌보지만 배우자가 더 많이 한다. 배우자는 주말에 아이를 맡아 Zach가 일할 수 있도록 돕는다.
-
우선순위와 압박
- 우선순위: Zach에게 가장 중요한 것은 아이이고, 그다음이 회사다.
- 배우자의 이해: 회사가 단순한 직장이 아니라 매우 치열하고 중요한 일이라는 점을 배우자가 이해하고 지지한다.
- 책임감: 직원, 투자자, Warp를 사용하는 사람과 제품을 좋아하는 사람들에게 가능한 한 성공적인 회사를 만들어 오래 유지할 책임을 느낀다.
- 압력의 실체: 세상을 구하는 일은 아니지만, 여러 사람의 기대가 걸린 회사이므로 상당한 압박이 계속된다.
-
단독 창업자의 고립
- 동료 창업자의 부재: 고민을 같은 위치에서 공유할 공동창업자가 없다는 점이 가장 큰 고립감 중 하나다.
- 투자자와의 대화: 투자자에게 매우 솔직하게 말할 수는 있지만, 투자자는 회사의 일상적인 혼란 속에서 같은 위험을 사는 동료가 아니다.
- 통제 불가능성: 성공을 위해 할 수 있는 일을 모두 해야 한다는 압박은 크지만, 결과는 완전히 통제되지 않는다.
7.4. 서로 다른 강점을 가진 투자자 네 명
-
Eric
- 소프트웨어 개발자 출신이라 제품과 개발자 피드백에 대한 관점이 좋다.
- Google에서 엔지니어로 일했던 인연 덕분에 Zach가 오래 신뢰해 온 조언자다.
-
Andrew Reed
- 전략과 큰 그림에 매우 강하다.
- 좋은 회사에 많이 투자한 경험을 바탕으로 세상에서 무엇이 중요한지, Warp가 어느 방향으로 가야 하는지에 대한 판단을 제공한다.
-
Greg
- Zach가 가장 가까이 지내는 투자자 중 한 명이다.
- Greg가 없었다면 Warp는 존재하지 않았을 것이라고 생각하며, 사람 관리 문제 등이 생기면 가장 먼저 전화할 사람이다.
-
투자자의 거리감
- 세 투자자와의 조언은 서로 보완적이고 Zach는 이 조합을 매우 운 좋게 생각한다.
- 그러나 투자자는 내부 정보와 일상적 ‘혼란 속에서 사는 경험’, 동일한 수준의 skin in the game을 갖지 않는다.
- 공동창업자가 있었다면 가장 유용했을 부분은 바로 같은 책임을 지는 동료와 대화하는 일이었을 것이다.
8. OpenAI·Anthropic과의 공존, 개발자 시장의 미래
Warp는 모델을 직접 판매하는 경쟁보다 여러 모델을 활용할 수 있는 개발 인프라와 자동화 플랫폼에 집중한다.
8.1. 모델 회사와 경쟁하지 않는 포지셔닝
-
초기의 경쟁 인식
- OpenAI와 Anthropic은 Warp의 공급자이면서 잠재적인 경쟁자처럼 보였다.
- 그러나 이 회사들은 너무 크고 고객 견인력이 강하며, 토큰과 추론(inference)을 훨씬 낮은 비용으로 제공할 수 있다.
-
피벗의 이유
- 토큰 재판매의 한계: Warp가 추론이나 토큰을 재판매하는 사업은 원가 구조상 경쟁하기 어렵다.
- 보완 관계: Warp는 모델 회사와 경쟁하기보다 그들이 제공하는 지능을 사람들이 더 잘 사용하게 만드는 인터페이스와 인프라를 맡는다.
-
‘스위스’ 전략
- Bring your own inference: 기업 고객이 자신의 추론 환경이나 토큰을 가져와 Warp를 사용할 수 있게 한다.
- 오픈 웨이트 모델: 오픈 웨이트 모델이 시장의 역학을 빠르게 바꾸고 있으므로 특정 공급자에 고정되지 않는 구조를 지향한다.
- 장기적 선택권: 미래에 가장 좋은 추론 엔진·모델·에이전트가 무엇이 되더라도 고객은 Warp의 플랫폼과 인프라를 계속 사용할 수 있어야 한다.
- 고객 메시지: ‘우리와 그들 중 하나를 고르라’가 아니라 ‘원하는 모델과 함께 우리를 써라’가 핵심 포지셔닝이다.
8.2. 개발자의 제품·시스템·공장 역할
-
미래의 엔지니어
- 기업에는 여전히 엔지니어링 팀이 남지만, 엔지니어는 매우 제품 지향적(product-minded)이 된다.
- 손으로 코드를 쓰는 일은 거의 끝나고, 랩톱에서 코딩 에이전트에게 명령하는 일조차 자동화된다.
-
개발 수명 주기의 자동화
- 서버가 충돌하면 에이전트가 원인을 진단한다.
- 에이전트가 수정안을 만들고 단순한 변경은 merge한다.
- 수정의 효과를 계속 관찰하며 문제가 재발하는지 확인한다.
- 사람은 무엇을 만들어야 하는지, 사용자 경험이 맞는지, 시스템 확장이 가능한지, 자동화 공장이 올바른 제품을 만드는지를 관리한다.
-
제품 관리자와 다른 점
- 엔지니어가 제품 사고를 해야 하지만 순수한 제품 관리자가 되는 것은 아니다.
- 제품 판단과 시스템 설계·안전성·성능을 동시에 책임지는 혼합형 역할이 된다.
- 자동화에 대한 깊은 이해가 없으면 에이전트가 만든 치명적 변경을 발견하지 못할 수 있다.
8.3. 개발자 시장의 구조적 특성
-
파편화
- 개발자는 하나의 통일된 시장처럼 보이지만 실제로는 본질적으로 파편화돼 있다.
- 모든 개발자가 좋아하는 제품이 오래도록 시장을 지배한 사례는 거의 없다.
- 잠시 지배했던 제품은 있어도 영속적인 지배자는 없다. 가장 가까운 사례가 GitHub였지만 GitHub조차 다시 혁신으로 대체될 위험이 있다.
-
개발자의 성향
- 최신 도구를 시험하고 싶어 한다.
- 도구의 설계 방향에 대해 강한 의견을 갖는다.
- 자신의 방식으로 커스터마이즈하기를 원한다.
- 어떤 사람은 제품을 사랑하고 어떤 사람은 싫어하므로 개발자 한 명을 평균적인 ‘개발자’로 묶어 이해하면 안 된다.
-
매우 가치 있는 고객
- 개발자는 회사에서 가장 영향력 있는 구매자다.
- 현재 Anthropic과 OpenAI의 폭발적 성장을 이끄는 구매층도 개발자다.
- 따라서 개발자용 제품을 만드는 일은 어렵지만 나쁜 시장을 고르는 일은 아니다. 파편화와 강한 취향을 제품 전략에 반영해야 한다.
8.4. AI 생산성의 측정 문제
-
서로 다른 생산성 추정치
- 낮은 추정치: 여러 보고서는 AI가 생산성을 2~5% 높였다고 말한다.
- 개발 현장의 체감: Zach가 대화하는 엔지니어링 리더들은 개발팀의 throughput을 merge된 변경 사항 수 등으로 측정한다.
- Warp의 관찰: 개발 영역에서는 velocity가 2~3배 증가했다는 사례를 보며, 단순한 몇 퍼센트 상승보다 훨씬 큰 변화라고 느낀다.
-
생산량과 사업 성과의 비선형 관계
- 매출로 직결되지 않음: 소프트웨어를 더 많이 배포한다고 돈을 선형적으로 더 버는 것은 아니다.
- 동일 기술의 확산: 경쟁사도 같은 AI 도구를 쓰므로 모두가 2~3배 더 많이 배포하면 상대적인 경쟁 우위는 생기지 않는다.
- ROI 압박: 기업은 개발자 도구와 토큰에 수백만 달러를 지출한 뒤 실제 사업 가치와 투자수익률(ROI)을 확인하고 싶어 한다.
-
측정하기 어려운 원인
- 더 많은 PR이 merge됐다는 사실과 회사 은행 계좌에 더 많은 돈이 들어왔다는 사실 사이에는 직접적인 인과관계가 없다.
- 특정 기능 출시나 버그 수정이 사업 성장에 기여한 정도를 Y라는 숫자로 정확히 분리하기 어렵다.
- 개발자 생산성 측정 도구의 오래된 질문, 즉 ‘측정값이 실제로 무엇을 개선했는가’라는 문제는 AI에서도 해결되지 않았다.
- 다만 Warp 내부에서 업무의 30%를 자동화하고 출력량이 확실히 증가했다는 사실은 관찰된다.
9. 거대한 베팅의 이유와 Warp가 넘어야 할 것
Warp의 야망은 특정 개발자 틈새에서 돈을 버는 것보다 소프트웨어가 만들어지는 방식을 바꾸는 데 있다.
9.1. 작은 틈새보다 큰 미션을 선택한 이유
-
틈새 사업도 가치 있음
- Zach는 작은 개발자 틈새를 골라 많은 돈을 버는 선택에 반대하지 않는다.
- 규모가 큰 회사가 된다는 사실 자체가 유일한 목표는 아니다.
-
Warp의 미션
- 개발자가 더 많은 소프트웨어를 배포하도록 돕는다.
- 세상에 더 좋은 소프트웨어가 존재하도록 한다.
- 클라우드 소프트웨어 공장은 이 미션을 가장 직접적으로 달성할 수 있는 방향이다.
-
경제적 기회
- 사람은 한 번의 커리어에서 몇 번의 큰 베팅을 할 수 있다.
- 소프트웨어는 사실상 모든 사업을 움직이는 기반이므로, 소프트웨어를 더 효율적으로 만들도록 돕는 일은 현재 가장 큰 경제적 기회 중 하나다.
- 이 문제는 어렵고 전략적이며, Warp가 이길지는 알 수 없지만 시도할 가치가 있다.
9.2. 성공에 필요한 조건과 통제 불가능한 변수
-
Warp가 통제할 수 있는 조건
- 제품을 훌륭하게 만들어야 한다.
- Warp만의 독특하고 가장 가치 있는 부분을 시장이 이해하도록 포지셔닝해야 한다.
- 제품이 엔터프라이즈 영업 중심으로 이동하는 만큼 마케팅과 세일즈 역량을 크게 키워야 한다.
- 개발자에게 직접 만드는 제품이 강점인 회사가 엔터프라이즈 판매를 잘해야 한다는 긴장을 해결해야 한다.
-
통제할 수 없는 변수
- AI 버블에 대한 시장 분위기와 거시 경제는 통제할 수 없다.
- 규제의 방향도 통제할 수 없으며, Warp는 그 결과에 영향을 받는다.
- OpenAI·Anthropic을 중심으로 한 AI 생태계 전체의 변화 속도도 예측하기 어렵다.
-
큰 시장의 완충 효과
- 소프트웨어 개발 자동화 시장은 매우 크다.
- Warp가 시장의 80%를 차지하지 않아도 의미 있는 대형 사업이 될 수 있다.
- 다만 경쟁사들도 같은 시장의 크기를 보고 있으므로 경쟁은 매우 치열하다.
- Anthropic과 OpenAI가 역사상 가장 빠르게 성장하는 기업에 속하는 시기에 Warp는 그 생태계에 크게 의존한다.
10. 짧은 질문에 담긴 개인적 기준
10.1. 이름, 말하기, 살지 않을 곳
-
Warp라는 이름
- 놀라운 유래나 숨겨진 이야기가 있는 이름은 아니다.
- 짧고 기억하기 쉬우며, 속도와 미래주의(futurism)를 떠올리게 하는 이름을 원했다.
- Cursor도 후보였지만 결국 Warp를 선택했다. 이후 Cursor가 거대한 회사가 된 사실을 보며 이름 선택의 우연을 웃으며 돌아본다.
-
가장 고마운 특성
- Zach는 사람들이 불안해하는 공개 연설(public speaking)을 좋아한다.
- 공개 연설은 긴장시키기보다 에너지를 준다.
- 최근 공개 연설을 점점 더 많이 하고 있으며, 창업자로서 유용한 능력이라고 생각한다.
-
다시는 살지 않을 곳
- 뉴욕의 St. Mark’s에 다시 살고 싶지 않다.
- 20대에는 재미있을 것 같아 선택했지만, 파티가 끊이지 않는 거리라 잠을 잘 수 없었다.
- 아파트가 너무 작아 변기에 앉아서도 몸을 똑바로 세울 수 없었다는 농담 같은 기억이 남았다.
10.2. 한 문장으로 압축한 삶의 철학
- 유용하고 영향력 있는 일을 선택하라: 다른 사람에게 유용하거나 영향력 있는 일을 하고, 그 영향력을 만들기 위해 정말 열심히 시도했다는 감각을 원한다.
- 결과를 통제하지 못해도 노력은 통제하라: 최종 결과를 완전히 통제할 수는 없다.
- 만족의 조건: 유용한 일을 골랐고 최선을 다했다는 확신이 있으면, 결과가 완벽하지 않아도 삶에 만족할 수 있다.
주요 발언 모음
“무언가를 파는 일은 정말 관계에 의해 움직이는 일이다.”
“내 DNA는 판매보다 구축에 더 가깝다.”
“자신을 괴롭히지 마라. 여러 가지를 시도해 볼 시간은 있다.”
“AI에게 잘할 수 있는 특정한 틈새 기술에만 베팅하지 말고, 넓게 생각하고 시스템적으로 사고하며 문제를 해결하고 적응하는 능력에 베팅하라.”
“회사를 운영하는 일은 어떤 방식으로든 영업이다.”
“믿지 않는 것을 판매하는 일은 매우 어렵다.”
“우리는 AI의 미래를 꽤 일찍 봤지만, 더 세게 밀어붙였어야 했다.”
“이제 우리는 100% 우리가 다음 큰 일이라고 생각하는 것에 집중한다.”
“엔지니어는 제품을 만드는 사람이 아니라 제품을 만드는 시스템을 구축하는 사람이 되어 간다.”
“직접 제품을 만드는 일은 조립 라인에서 차를 꺼내 문 하나를 망치로 달아 붙이는 것과 같다.”
“사람이 통제할 수 있는 것은 실행이고, 결과는 결과대로 받아들여야 한다.”
“개발자는 하나의 시장이 아니다. 개발자마다 다르다.”
“더 많은 소프트웨어를 배포한다고 더 많은 돈을 버는 것은 선형적인 관계가 아니다.”
“유용하거나 영향력 있는 일을 고르고, 그 일에 최선을 다했다면 나는 만족할 것이다.”
핵심 데이터 & 수치
- 약 13세: Zach가 샌프란시스코 보험 사업가였던 할아버지 Lloyd K. Lloyd를 잃은 나이.
- 약 8세: Marc Benioff가 흰색 BMW 컨버터블로 Zach를 태워 주던 어린 시절의 기억이 남은 시기.
- 1년: 법학대학원에 다닌 기간. 이후 중퇴했다.
- 7~8년: Google에서 근무한 기간. 퇴사할 때 Google Docs 제품군 전체의 엔지니어링을 이끌었다.
- 약 6개월: Google 퇴사 후 사진 공유 모바일 앱을 혼자 만든 기간.
- 수천 명: 사진 공유 앱의 초기 사용자 규모.
- 약 3년: SelfMade에서 일한 기간.
- 약 150명: SelfMade에서 사진 편집 업무를 수행한 전체 인력.
- 약 100명: SelfMade의 자카르타 근무 인력.
- 약 40쪽 / 1개월: SelfMade를 떠난 뒤 작성한 비공개 postmortem의 분량과 기간.
- 2020년: Warp를 시작한 시점.
- ChatGPT 이전: Warp가 영어 문장을 터미널 명령어로 바꾸는 AI 기능을 제공한 시점.
- 약 1개월: ChatGPT 공개 후 Warp에 초기 AI 기능을 추가하기까지 걸린 기간.
- 약 6개월: Warp의 터미널 에이전트형 기능이 Claude Code·Codex보다 앞서 있었다고 말한 시간 차이.
- 약 100만 명: Warp를 사용하는 개발자 규모. 개발자 도구 시장에서는 상당한 사용자 수다.
- 약 500만 명: 대화에서 Claude Code의 예시 사용자 규모로 언급된 수치이며 정확한 공식 수치는 아님.
- 약 30%: Warp가 현재 완전히 자동화하고 있다고 말한 업무 비중.
- 2~3배: 개발팀의 merge된 변경 사항 등으로 측정했을 때 고객들이 관찰하는 개발 속도(velocity) 증가폭.
- 2~5%: 다른 생산성 보고서에서 AI 효과로 제시되는 생산성 증가폭.
- 35개 이상: Vanta가 지원한다고 소개된 컴플라이언스 프레임워크 수.
- 16,000개 이상: Vanta를 신뢰한다고 소개된 고성장 기업 수.
- 1,000달러: Vanta 프로모션 할인 금액.
- 80%: Warp가 거대한 시장에서 반드시 차지할 필요는 없다고 말한 시장 점유율의 예시.
결론 및 시사점
- 관심사가 넓다는 사실을 결함으로 취급하지 말아야 한다: NASA, 철학, 논리학, 글쓰기, 스튜디오 경험은 하나의 직무에 즉시 연결되지 않아도 창업자의 사고 폭과 적응력을 만든다.
- 다만 언젠가는 중요한 문제에 commit해야 한다: 완벽한 진로를 기다리기보다 자신이 흥미롭고 유용하다고 느끼는 문제를 선택하고, 그 선택에 충분히 집중해야 한다.
- 창업자는 자신이 믿는 문제를 골라야 한다: 수요와 매출이 있어도 제품을 믿지 못하면 영업·채용·조직 운영의 모든 단계가 소모적으로 변한다.
- 사후 분석은 실패를 자산으로 바꾼다: SelfMade의 약 40쪽 postmortem은 공개되지 않았지만, 다음 회사에서 피할 실수를 선명하게 만들었다.
- 채용은 미션·비전·리더십을 파는 영업이다: 최고의 인재는 급여만으로 움직이지 않으며, 회사가 이길 가능성과 자신의 소유권을 함께 믿어야 한다.
- AI 시대에는 코딩보다 시스템 사고와 의도 전달이 중요해진다: 에이전트가 코드와 반복 작업을 맡을수록 인간은 문제 정의, 제품 판단, 안전성, 품질 보증을 담당한다.
- 개발자의 미래 직무는 팩토리 엔지니어에 가깝다: 제품을 손으로 하나씩 만드는 대신 제품을 지속적으로 생산·검증·개선하는 자동화 시스템을 설계한다.
- 소프트웨어의 생산 비용 하락은 수요의 폭발을 부른다: 엔지니어 수가 줄어들지 여부는 불확실하지만, 만들어야 할 소프트웨어가 무한히 많기 때문에 엔지니어링 업무는 더 높은 수준의 판단으로 이동한다.
- 앱의 UI보다 데이터·워크플로·네트워크 효과가 오래 남는다: 단순한 SaaS 화면은 에이전트에 의해 대체될 수 있지만, Salesforce의 데이터·업무 로직이나 Stripe의 통합·네트워크 효과는 지속적인 진입장벽이 된다.
- AI 생산성은 출력량만으로 평가하면 안 된다: merge 수와 velocity는 늘어도 매출·고객 가치로 자동 전환되지 않으므로, 개발 산출물과 사업 성과를 연결하는 측정 방법이 필요하다.
- 모델 회사와의 경쟁보다 중립적 인프라가 현실적인 전략일 수 있다: OpenAI·Anthropic의 원가·규모와 경쟁하기보다 고객이 원하는 모델과 추론 환경을 선택하게 하는 플랫폼이 더 지속 가능한 위치가 된다.
- 큰 베팅에는 헤지하지 않는 용기가 필요하다: 미래를 먼저 보았다는 사실만으로는 충분하지 않다. 기회를 확인했다면 기존 사용자와 단기 불확실성을 감수하고 100% 집중해야 한다.
- 단독 창업은 시장의 피드백과 자기 관리가 동시에 필요하다: 투자자는 조언할 수 있지만 대신 책임질 수 없고, 시장은 냉정하게 사업을 평가한다.
- 가족·건강·업무 밖의 활동은 지속 가능성의 조건이다: 운동, 아이와의 시간, 요리처럼 회사 성과와 무관한 삶의 영역이 창업자의 관점을 회복시킨다.
- 최종 성공의 기준은 결과만이 아니다: 다른 사람에게 유용하거나 영향력 있는 일을 고르고 그 일에 최선을 다했다는 감각이 장기적인 만족의 핵심이다.
