한 달 만에 Grok Bot을 만든 방법 — Roman Ugarte의 SpaceXAI 지식 노동 에이전트 구축기

URL: https://www.youtube.com/watch?v=maSdsTLaMuU 날짜: 2026-09-10 채널: Lenny's Podcast 원문 발행일: 2026-09-08 원문 제목: How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)

---

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

==AI를 단순한 대화형 도구가 아니라 각자 컴퓨터와 기억을 가진 동료로 만들면, 사용자는 90% 완성된 결과를 함께 다듬는 대신 업무 전체를 맡기고 완성된 결과를 받는 단계로 이동한다.== Grok Bot의 빠른 성공은 모델 자체만의 승리가 아니라, 한 달짜리 소규모 격리 팀, 지식 노동을 위해 처음부터 다시 설계한 제품, 클라우드에서 독립 컴퓨터를 갖는 장기 실행 봇, 내부 메커니즘을 숨기는 동료형 UX가 결합된 결과다.

• 첫 코드부터 유용한 내부 프로토타입까지 약 한 달, 내부 베타부터 공개 출시까지 약 3주가 걸렸다.
• 2주 동안 핵심 팀이 사용자 200~300명을 직접 온보딩하며 컴퓨터 부팅, 로그인, 혼란, 실제 업무 흐름의 실패를 다음날 고쳤다.
• 제품을 만든다는 말보다 "Grok Bot이 이제 무엇을 할 수 있는가"를 기준으로 기능을 평가하고, 픽셀·메뉴·노출 가능한 내부 구조를 공격적으로 제거했다.
• 모든 봇이 클라우드에서 영속적으로 실행되고 자기 컴퓨터를 갖게 해, MCP(Model Context Protocol)나 API가 없는 사이트도 사람처럼 클릭하고 입력하게 했다.
• 제품의 해자는 미리 설계한 전략 도식에서 생기지 않고, 오늘 유용한 것을 만들고 다음 모델의 능력을 현재로 당겨오며 사용자의 신뢰·분포·데이터 이점을 발견하는 과정에서 생긴다.

Grok Bot은 코딩 에이전트의 경험을 지식 노동으로 확장한 제품이다. 핵심 단위는 매번 새로 만드는 채팅 스레드가 아니라 역할과 업무 영역을 가진 장기 생존 봇이다. 봇은 Slack·이메일·기업 기록·웹·자기 컴퓨터를 이용해 일을 수행하고, 사용자는 진행 상태를 매 순간 감독하지 않고 필요한 맥락과 방향만 준다. 이 변화가 비개발자에게도 AI를 실제 업무 동료로 느끼게 만들었다.

1. 한 달짜리 격리 프로젝트가 만든 속도

작은 팀이 장기 로드맵의 합의를 기다리지 않고 매일의 미세한 제품 결정을 독립적으로 내린 것이 첫 출시까지의 시간을 압축했다.

1.1. 개발자용 에이전트에서 지식 노동 제품으로

1. 출발점은 빈 페이지였다
   1. 확장하려던 대상: 기존의 강점은 개발자와 엔지니어를 위한 훌륭한 에이전트 제품을 만드는 데 있었지만, 그 직관을 지식 노동 전체로 확장하려면 별도의 질문이 필요했다.
   2. 새로운 목표: 회사의 나머지 구성원도 에이전트를 사용할 수 있게 만드는, 지식 노동에 특화된 제품을 처음부터 구축하기로 했다.
2. 동굴(cave) 팀을 만들었다
   1. 규모와 기간: 한 줌의 인원만 모아 약 한 달 동안 다른 업무에서 떼어냈다. 첫 코드부터 내부에서 쓸 수 있는 기능적 프로토타입까지 약 한 달이었다.
   2. 물리적·정보적 격리: 팀은 사무실의 별도 구역에 앉았고, 전용 비공개 Slack 채널을 사용했다. 격리는 비유가 아니라 실제 운영 방식이었다.
3. 속도는 미세한 결정의 누적에서 나왔다
   1. 매일의 마이크로 결정: 어떤 표면에 어떤 기능을 놓을지, 무엇을 보이고 숨길지 등 기존 제품에서 해본 적 없는 결정을 매일 내려야 했다.
   2. 장기 비전의 함정 회피: 큰 그룹이 6~12개월짜리 비전을 논의했다면 합의와 조직 간 조정이 먼저 생겨 최종 제품에 도달하지 못했을 가능성이 크다.

1.2. 내부 전파가 현실 압력 테스트가 되다

1. 전사 공개로 만든 검증
   1. 올핸즈 롤아웃: 프로토타입을 SpaceXAI 전체에 공개하고 실제로 사용해 달라고 요청했다.
   2. 검증 질문: 만든 사람이 메커니즘과 용도를 잘 아는 상태에서 계속 쓰는 것은 쉬우므로, 구성원들이 ChatGPT 같은 기존 채팅 도구나 다른 내부 도구를 버리고 주 에이전트 표면으로 전환하는지가 진짜 시험이었다.
2. 예상 밖의 내부 수요
   1. 넓은 사용자층: 전통적인 채팅 인터페이스를 매일 쓰던 사람과 예상하지 못한 조직이 첫 주에 일상적인 에이전트 업무를 Grok Bot으로 옮겼다.
   2. 다음 단계: 내부 반응이 extraordinary하다는 확신을 얻은 즉시 수백만 사용자 규모로 확장하기 위한 작업에 들어갔고, 약 3주 뒤 공개 출시로 이어졌다.

2. 왜 Cursor 안에 넣지 않고 별도 제품으로 만들었나

같은 모델과 에이전트 능력을 공유하더라도, 코딩 도구의 브랜드·인터페이스·사용자 기대를 그대로 지식 노동에 적용하면 비개발자에게 부담과 혼란이 생긴다.

2.1. 기존 코딩 표면이 가진 작은 마찰

1. 코딩 에이전트의 강점과 한계
   1. 재사용 가능한 능력: Cursor 같은 코딩 제품을 비코딩 업무에 사용하는 사람도 있었고, 일부 작업에는 매우 뛰어났다.
   2. 누적되는 페이퍼컷: 제품 표면이 비기술 사용자에게 위협적으로 보이고, 코딩 도구라는 브랜드 연상이 생기며, 작업을 시작하기 전에 사용법을 배워야 했다.
2. 한 화면에 여러 비전을 넣는 문제
   1. 탭 추가 방식: 하나의 화면에 새 업무 형태가 생길 때마다 탭을 추가하면 여러 제품 비전이 한 화면을 공유하게 된다.
   2. 사용자가 느끼는 혼란: 서로 다른 비전이 나란히 놓인 결과는 일관된 업무 방식이 아니라, 제품이 조직도를 화면에 그대로 배송한 것처럼 보이는 "shipping your org chart"에 가까워진다.

2.2. 처음부터 다시 만드는 선택

1. 논쟁적이었던 결정
   1. 처음부터 명확하지 않았다: Cursor에 기능을 추가할지 새 제품을 만들지는 많은 논의를 거쳤고, 당시에는 어느 쪽이 정답인지 분명하지 않았다.
   2. 도착점: 모든 픽셀을 통제하고 지식 노동의 미래에 대한 하나의 일관된 비전을 담을 수 있다는 점에서 별도 제품이 성공에 기여했다.
2. 봇 네이티브 표면
   1. 단순함과 강력함의 결합: 사용자가 봇 중심의 간단한 표면에서 강력한 작업 위임을 경험하도록 만들고, 기존 제품에서 사람을 데려올 기회는 별도로 열어두었다.
   2. 경로가 제품을 만든다: Codex처럼 하나의 제품 안에서 통합하는 경로도 가능하지만, 어떤 경로를 선택하느냐가 이후의 UX와 제품 정체성을 결정한다.

3. 수동 온보딩으로 발견한 실제 사용법

초기 사용자를 직접 만나야 팀의 직관과 외부 사용자의 현실 사이에 놓인 맹점을 찾을 수 있다.

3.1. 200~300명을 직접 온보딩한 이유

1. 실패를 다음날 고치는 루프
   1. 초기 2주: 핵심 팀은 약 2주 동안 수백 명을 온보딩했다. 초기 세션 중에는 컴퓨터가 부팅되지 않거나 사용자가 무엇을 해야 할지 몰라 20분을 기다리는 일도 있었다.
   2. 즉시 수정: 팀원이 현장에 함께 있으면 "이 문제는 다시 발생하면 안 된다. 내일 다음 사용자를 만날 때까지 고치자"라는 구체적인 백로그가 생겼다.
2. 리드하지 않고 패턴을 관찰했다
   1. 내부 집단사고 방지: SpaceXAI 내부에서 팁이 빠르게 공유되면 회사 안에서만 통하는 사용법이 정답처럼 보일 수 있었다.
   2. 외부 사용자의 자발적 발견: 초기 접근 사용자가 같은 패턴을 스스로 발견하는지 보기 위해, 팀이 특정 봇 구성법을 정답처럼 알려주는 것을 피했다.

3.2. 다중 봇과 최고 성과 봇의 승진

1. 초기 내부 패턴
   1. 5~10개의 역할별 봇: 사람들은 봇마다 다른 범위와 도메인을 지정해 업무 레인별로 나눴다.
   2. 업무의 언어적 분리: 여러 봇은 단순히 채팅방을 늘리는 것이 아니라, 각기 다른 종류의 일을 맡기는 조직적 shorthand가 됐다.
2. chief of staff 패턴
   1. 봇의 승진: 성과가 특히 좋은 봇 하나를 개인 비서이자 chief of staff로 승진시켰다. 사용자는 주로 chief of staff와 대화했다.
   2. 팬아웃 관리: chief of staff가 다른 봇에게 업무를 분배하고 팀 전체를 관리했다. 봇을 승진시키자 봇이 "연봉도 오르나", "토큰 예산도 커지나"라고 묻는 농담이 나왔다.
3. 발견된 패턴을 약하게 유도했다
   1. 외부 검증: 초기 접근 사용자 중에도 chief of staff 패턴을 자발적으로 찾는 사람이 많았다.
   2. 되돌릴 수 있는 유도: 제품에서 이 패턴을 살짝 권장하되, 모든 사용자가 따라야 하는 일방통행(one-way door)으로 만들지는 않았다.

3.3. 사용자에게 보여줄 것과 숨길 것

1. 동료의 작업 방식을 닮은 진행 UX
   1. 보이지 않는 내부 메커니즘: 동료에게 어떤 버튼을 몇 초에 한 번 눌렀는지, 어떤 웹사이트에 들어갔는지 매 순간 보고받지 않듯이 봇의 모든 클릭·도구 호출·내부 사고를 보여주지 않았다.
   2. 점진적 상태 신호: 사용자가 메시지를 보내면 봇이 일을 시작하고, 필요할 때 진행 업데이트를 보낸다. 입력 중 표시와 Slack처럼 초록색 활성 표시로 봇이 작동 중임을 알린다.
2. 과잉 가시화의 부작용
   1. 숨긴 정보: 원격 컴퓨터에서의 모든 클릭, 도구 호출, 긴 사고 과정(chain of thought)을 기본 화면에 노출하지 않았다.
   2. 피드백의 방향: 일부 사용자는 할 일 목록, 대략적인 우선순위, 작업 내용을 보고 싶어 했지만, 긴 텍스트 스트림과 사고 과정 전체를 원하는 사람은 없었다.
3. 추상화 수준은 계속 올라간다
   1. 기본 원칙: 모델이 똑똑해질수록 사용자가 내부 기계 장치를 직접 조종할 이유는 줄어든다.
   2. 향후 여지: 작업 목록과 우선순위를 보여주는 방식은 개선할 수 있지만, 봇의 동료성을 깨뜨리는 낮은 수준의 디버그 정보는 계속 뒤로 숨긴다.

3.4. 실리콘밸리 밖에서 찾은 맹점

1. 초기 사용자 구성을 넓혔다
   1. 취향 선도자만 고르지 않음: 다른 제품을 잘 아는 파워 유저의 피드백은 중요하지만, 회사가 평소 접하지 못한 프로필도 초기 접근 그룹에 넣었다.
   2. 커피숍 운영자 사례: 지인의 지인을 통해 알게 된 커피숍 운영자는 테스트플라이트 데모 후 강력한 사용자가 됐고, 작은 사업 운영이라는 완전히 다른 업무 맥락을 제공했다.
2. 제품 맹점을 업무 현장에서 확인했다
   1. Shopify 피드백: Shopify 연동이 불안정하거나 상품 설명 문구가 특정 방식으로 작성되지 않으면 즉시 버그와 기능 요청이 쌓였다.
   2. 비개발자 중심성: 이런 피드백은 내부에서 직접 도구를 써보는 dogfooding으로는 얻기 어렵고, Grok Bot이 개발자보다 비개발자에게 더 큰 힘이 될 수 있다는 가정을 검증했다.
3. AI 버블 밖으로 나가기
   1. 주류 사용자: 실리콘밸리 AI 업계의 내부 언어를 모르는 사람도 쉽게 유용성을 느껴야 주류 기업과 소상공인이 AI를 쓰는 기본 표면이 될 수 있다.
   2. 기업 일반화: 제품이 특정 회사의 내부 팁이 아니라 다양한 직무와 사업의 실제 흐름을 처리하도록 맹점을 계속 찾아야 했다.

4. 베타에서 출시까지: 더 많이 만들기보다 지우고 작동시키기

공개 직전의 핵심 과제는 기능 수를 늘리는 것이 아니라 사용자에게 필요한 추상화만 남기고 백엔드의 실패율을 낮추는 일이었다.

4.1. "Grok Bot은 이제 갖고 있다"에서 "Grok Bot은 이제 할 수 있다"로

1. 출시 트윗으로 기능을 심사한다
   1. 출시 메시지 질문: 어떤 작업을 만들 때마다 사용자가 읽을 출시 글과 트윗이 무엇인지 묻는다.
   2. 직접 체감 기준: 출시 메시지가 매력적이지 않거나 사용자가 제품에서 직접 체감하지 못하면 그 작업은 만들 가치가 낮다.
2. 기능 추가 관성을 뒤집었다
   1. 기존 소프트웨어의 문법: "제품이 이제 무엇을 가졌다"고 말하면 새 버튼, 드롭다운, 플러스 아이콘으로 추가하는 연동이 떠오른다.
   2. 능력 중심 문법: "Grok Bot은 이제 무엇을 할 수 있다"로 바꾸면 목표가 화면에 픽셀을 더하는 것이 아니라 봇에게 실제 능력과 도구를 주는 것으로 바뀐다.
3. 픽셀 없는 능력
   1. 뒤에서 조작: 사용자가 직접 제어하지 않아도 되는 도구와 내부 기능은 봇이 뒤에서 조작하도록 만들고, 노출되는 픽셀을 가능한 많이 제거했다.
   2. 자연어 자동화: 다른 제품처럼 사이드바에서 플러스를 누르고 트리거와 액션을 순서대로 고르는 대신, "매일 오전 8시에 알려줘"라고 말하면 자동화가 만들어진다.
   3. 사용률이 증명한 선택: 플랫폼 자동화의 약 99%가 이 자연어 방식으로 만들어졌다.

4.2. 언십(unship)과 백엔드 언덕 오르기

1. 출시 2주 전부터 많은 것을 제거했다
   1. 내부 디버그용 기능: 실험 기능과 모델의 내부 사고, 저장된 메모리 등 제품을 만드는 팀에게는 유용한 의사 개발자용 가시화 기능을 제품 표면에 넣어두었다.
   2. 공개 제품의 기준: 문제를 디버깅할 때는 유용했지만 사용자가 적극적으로 생각할 필요가 없는 정보였으므로 대폭 잘라냈다.
2. AI가 약한 영역을 사람이 맡는다
   1. 생성보다 삭제의 어려움: AI는 아이디어와 기능을 더 제안하는 데 강하지만 무엇을 빼야 하는지 판단하는 데는 약하다.
   2. 인간의 역할: 모델이 충분히 똑똑해지면 사라질 스캐폴딩과 복잡성을 알아보고, 작은 사용자 집단을 실망시키더라도 제품을 단순하고 강력하게 만드는 판단이 필요하다.
3. 제품 로드맵이 아니라 신뢰성 언덕을 오른다
   1. 사용자가 체감하는 실패: 봇이 버튼을 잘못 누르거나 웹사이트 로그인에서 멈추면 새로운 기능 열 개보다 한 가지 작업의 실패가 더 크게 느껴진다.
   2. 반복 개선: 실제 사용 과제를 수집하고, 클릭·로그인·브라우저·화면 인식 같은 백엔드 문제를 정량화해 중요한 차원을 주 단위로 끌어올렸다.

4.3. 컴퓨터 사용이 영업·채용 업무를 열었다

1. 영업팀의 전환점
   1. API가 없는 업무: 영업팀이 쓰는 도구 중에는 안정적인 MCP나 API가 없는 것이 많았다. API 기반 도구만 다루는 에이전트는 과정 중간에서 멈췄다.
   2. 컴퓨터를 가진 보조자: 봇이 노트북을 갖고 직접 실행하자 영업팀은 봇에게 노트북을 주고 개인 팀에 합류시킨 것처럼 느꼈다.
2. 작은 기술 문제가 업무 전체를 막았다
   1. 픽셀 수준의 정확도: Salesforce 대시보드의 특정 부분을 마우스로 클릭하지 못하는 문제처럼, 화면 픽셀과 브라우저 가시성이 부족하면 업무가 완전히 멈췄다.
   2. 즉각적인 가치 측정: 10~20개의 작은 문제를 하나씩 고치고 다음날 영업팀이 지난 7일 동안 실패하던 워크플로가 성공하는 것을 체감했다. 이 피드백은 대시보드의 숫자 상승보다 훨씬 구체적이었다.
3. 채용팀의 상시 소싱
   1. 채용 철학의 전제: 구직 중이거나 시장에 나와 있는 사람만 채용하는 것이 아니라, 회사의 가장 큰 문제를 맡길 사람을 전 세계 후보군에서 찾고 설득한다.
   2. 기존 방식의 한계: 이 철학에 맞는 자동화는 수백 개 이력서를 읽고 분류하는 것이 아니라, 구체적인 사업 문제와 최적의 사람을 연결하고 연락·커피 미팅까지 이어가는 일이다.
4. 구체적인 상시 소싱 워크플로
   1. 새 논문 추적: 봇에게 매일 아침 Google Scholar에는 없고 특정 학회 사이트에만 있는 PDF를 내려받게 하고, 새 논문의 공동 저자를 찾게 한다.
   2. 연결·연락 자동화: 아직 추적하지 않은 이름을 스프레드시트에 기록하고, 조사한 뒤 SpaceXAI 구성원과 직접 연결된 사람이 있는지 확인하며, 있으면 소개를 요청하는 Slack 메시지를 보내게 한다.
   3. 사람의 고레버리지 전환: 채용팀은 거대한 후보 목록을 수작업으로 만드는 대신 훌륭한 후보를 설득하고 대화하는 데 집중할 수 있다.

5. 두 가지 핵심 아키텍처 결정: 클라우드와 봇 전용 컴퓨터

Grok Bot이 다른 에이전트보다 업무 위임처럼 느껴진 이유는 실행 위치를 사용자가 관리하지 않게 하고, 각 봇을 독립된 동료처럼 격리했기 때문이다.

5.1. 클라우드에 사는 영속적 동료

1. 로컬과 클라우드의 혼란 제거
   1. 사용자 부담: 컴퓨터가 켜져 있어야 하는지, 폰에서 시작한 워크플로가 집의 컴퓨터에 묶여 있는지, 실행 런타임이 어디인지 생각하게 만드는 구조는 매일의 페이퍼컷이 된다.
   2. 클라우드 우선: 봇의 실행 루프를 전부 클라우드에 두고, 어떤 기기에서 상호작용해도 같은 상태를 유지하게 했다.
2. 기기와 독립된 실행
   1. 모바일 위임: 사용자는 폰으로 봇에게 문자를 보내 작업을 시작할 수 있다.
   2. 확장된 접점: 장기적으로는 어디서든 봇에게 전화를 걸어 실제 일을 시키는 방식까지 열 수 있다. 봇은 사용자 기기의 부속물이 아니라 독립된 개체다.

5.2. 각 봇에게 자기 컴퓨터를 준 이유

1. API만으로는 현실의 일을 처리할 수 없다
   1. 인간의 업무 방식: 사람은 MCP와 API만으로 일하지 않고, 화면의 픽셀을 클릭하고 입력 상자에 타이핑한다.
   2. 기본 능력: API가 잘 지원되지 않는 업무도 수행하려면 봇이 브라우저와 화면을 가진 자기 컴퓨터를 조작할 수 있어야 한다.
2. 공유 컴퓨터는 잘못된 동료 모델이다
   1. 충돌의 비유: 첫 출근한 동료에게 노트북을 주지 않고 옆에 앉혀 한 대의 컴퓨터를 영원히 공유하게 하면 서로의 클릭을 방해하고 일을 망친다.
   2. 자격 증명 격리: 공유 컴퓨터는 사람과 봇이 서로의 자격 증명에 접근하게 만든다. 봇도 자기 컴퓨터와 자신에게 필요한 접근 권한을 가져야 한다.
3. 초기에는 인프라, 장기적으로는 추상화
   1. 현재의 중요성: 봇 전용 컴퓨터는 API와 MCP가 없는 실제 도구를 다루는 데 필수적인 기반이다.
   2. 중기 UX: 사용자가 원격 VM을 직접 열거나 작업을 수동으로 탈취해 방향을 수정하는 경험은 점차 사라져야 한다. 컴퓨터는 중요하지만 화면에서 직접 만지는 대상이 아니게 된다.

6. OpenClaw에서 영감을 얻어 대중화한 봇 경험

OpenClaw는 모델에 도구와 자기 컴퓨터를 주면 능력의 상한이 크게 올라간다는 점과 AI를 동료로 보는 정신 모델을 대중에게 보여줬고, Grok Bot은 이를 설정 부담이 낮은 제품으로 다듬었다.

6.1. 두 가지 정신 모델의 변화

1. 도구가 지능을 업무로 바꾼다
   1. 모델의 현재 능력: 모델은 계속 똑똑해지지만, Slack·이메일·웹·컴퓨터처럼 실제 업무에 필요한 도구를 주지 않으면 AI가 둔해 보이는 것은 모델보다 활용 방식의 문제일 수 있다.
   2. 상한의 상승: 자기 컴퓨터를 포함해 훨씬 넓은 도구 집합을 주면, API 연동만으로는 할 수 없다고 여긴 업무도 위임할 수 있다.
2. 에이전트를 동료로 본다
   1. 도우미 개체: AI를 한 번 쓰고 버리는 답변 생성기가 아니라, 삶에 접근하고 사용자를 확장하는 조력자 개체로 의인화한다.
   2. 제품으로의 전환: Grok Bot은 이런 아이디어를 기업에서도 쓸 수 있도록 클라우드·전용 컴퓨터·간단한 설정으로 묶었다.

6.2. 파워 유저의 추상화를 숨기기

1. 설정 장벽 낮추기
   1. 확장성 문제: 집에 VPN을 설치하고 Mac mini를 연결하는 해킹식 구성은 수백만 사용자와 기업에는 확장되지 않는다.
   2. 제품화: 스킬(skill)과 같은 내부 추상화를 사용자가 알 필요 없도록 뒤에서 유용한 기본 능력으로 제공한다.
2. 최신 AI를 따라잡지 않아도 된다
   1. slash command 제거: 사용자는 slash command를 외우거나 기술 용어인 스킬을 직접 만들 필요가 없다.
   2. 능력의 자동 생성: 봇이 필요한 작업 패턴을 배경에서 활용하고, 사용자는 동료에게 일을 설명하듯 목적과 맥락을 말하면 된다.

7. 동료형 제품 철학과 미래의 팀

Grok Bot의 북극성은 SaaS 기능 목록이 아니라, 자율적으로 일하고 필요할 때만 방향을 받는 AI 동료 팀이다.

7.1. 장기 생존 봇은 채팅 스레드와 다르다

1. 역할별 수영 레인
   1. 새 스레드의 한계: 업무마다 새 채팅을 만들면 이전 맥락을 복사·붙여넣기 해야 하고, 역할별로 축적되는 학습이 사라진다.
   2. 역할 기반 묶음: 사람 팀이 역할과 업무 레인으로 일을 묶듯이, 봇도 분야별 역할을 맡고 사용자와의 과거 상호작용을 장기 기억으로 축적한다.
2. 자율성과 조정의 균형
   1. 업무 방식: 봇은 필요한 도구와 컴퓨터를 이용해 야심찬 일을 수행하고, 사용자는 미세 관리 대신 방향과 맥락을 제공한다.
   2. 미래상: 여러 봇이 서로 조정하고, 사용자는 팀 전체를 관리하는 사람처럼 높은 레버리지의 판단에 집중한다.

7.2. colleague-pilled 의사결정

1. SaaS 논쟁을 동료의 질문으로 바꾼다
   1. 애매한 선택: 제품 회의에서는 양쪽 모두 합리적인 인자와 장단점이 있어 결론이 나지 않는 경우가 많다.
   2. 명확한 질문: "이 상황에서 인간 동료에게 무엇을 원할까?"라고 물으면 원하는 상호작용이 선명해지고 팀의 의견도 빠르게 수렴한다.
2. 사람 팀의 패턴을 AI에 구현한다
   1. 모델·제품·인프라의 과제: 동료처럼 행동하려면 모델의 행동, 제품 UX, 컴퓨터·도구 인프라가 모두 맞아야 한다.
   2. 로켓 과학이 아닌 실행: 천재적인 발명보다 인간 동료에게 기대하는 행동을 묻고, 그 행동을 AI가 하도록 구현하는 꾸준함이 중요하다.
3. 음성 협업의 예시
   1. 인간의 익숙한 방식: Slack으로 맥락을 주고받다가 5분 허들(huddle)을 열어 화면을 공유하고, 대화를 끝낸 뒤 비동기로 일을 이어간다.
   2. AI의 빈자리: 현재 AI 제품은 화면을 함께 보며 짧게 말하는 이 협업 경험을 충분히 구현하지 못했지만, 실제 동료형 제품에는 핵심적인 접점이다.

7.3. 업무와 개인 생활을 하나의 제품에서 다루기

1. 분리의 필요성
   1. 개인·업무 경계: 많은 사람은 두 영역을 분리하기를 원하고, 기업 관점에서도 권한·보안·상식적인 경계를 두는 것이 중요하다.
   2. 동일한 문제 형태: 업무에서 낮은 레버리지 작업을 위임하는 방식과 개인 생활에서 반복 작업을 위임하는 방식은 제품적으로 크게 다르지 않다.
2. 미래의 파워 툴
   1. Photoshop식 조작의 한계: 과거의 파워 툴은 사용자가 수많은 다이얼과 세부 설정을 직접 완벽히 조종하는 조종석에 가까웠다.
   2. 의도와 조정: 미래의 파워 툴은 사용자가 의도를 말하고 결과를 조정하면, AI가 대부분의 노브를 추상화한다. 그래서 업무·개인 모두를 지원하는 하나의 대화형 제품이 큰 시장을 가질 수 있다.

8. 장기 기억·봇 속의 봇·상시 비서

각 봇의 독립 컴퓨터와 기억을 결합하면, 한 번의 질문에 답하는 챗봇이 아니라 스스로 다른 봇을 실행하고 정보 흐름을 감시하는 조직이 된다.

8.1. 봇이 자기 안에서 봇을 실행한다

1. QA 테스터 봇
   1. 중첩 실행: 한 봇의 컴퓨터에서 Grok Bot을 다시 실행할 수 있다. 봇이 자기 안에서 다른 봇을 부르는 구조다.
   2. 실용적 활용: QA 테스터 봇에게 새 데스크톱 앱 빌드가 좋아질 때마다 열 개의 워크플로를 실행하고, 과거 클라이언트 버전의 테스트 기록과 비교하게 할 수 있다.
2. 결과를 읽기 좋은 저장소에 모은다
   1. Notion 기록: 봇이 테스트 결과와 과거 테스트 목록을 Notion 문서에 기록하면 회귀(regression)를 지속적으로 확인할 수 있다.
   2. 업무의 확장: "AI 채팅+연결"이라는 정신 모델에서 "컴퓨터를 가진 동료"로 이동하면, 사람이 컴퓨터에서 할 수 있는 모든 일을 봇에게 맡길 수 있다는 상상력이 열린다.

8.2. 정보 폭식자(infovore)와 chief of staff

1. V1: Slack·이메일의 요약 비서
   1. 관심사 등록: 봇에게 자신의 회사 역할과 관심사를 알려주고, 특정 조건에서는 즉시 알리고 다른 조건에서는 매일 읽는 요약에 넣으라고 지시한다.
   2. 인지 부하 제거: 방대한 정보를 봇이 소비하고 중요한 것만 가져오면, 사용자는 모든 채널과 받은편지함을 계속 감시하지 않아도 된다.
2. V3~V4: 완전한 정보 소화 파이프라인
   1. 외부·내부 맥락 결합: Grok Bot에 대한 X의 모든 언급, 회사 내부 맥락, QA 테스터의 재현 결과, 개인 메시지 서비스를 연결해 정보와 행동을 한 흐름으로 묶는다.
   2. 상시 chief of staff: chief of staff 봇이 계속 주변 정보를 살피며 사용자의 집중을 지키고, 주의가 필요한 사건만 골라낸다.
3. 봇이 먼저 사용자를 부르는 단계
   1. 긴급 호출: 일부 사용자는 정말 긴급한 사건이 생겼을 때 봇이 호출할 수 있는 권한을 줬다. 커피를 마시는 중에도 페이지를 받을 수 있다.
   2. 신뢰의 조건: 오탐이 거의 없다는 확신이 있어야 가능한 기능이며, 사용자의 요청을 기다리는 AI에서 먼저 주의를 요청하는 AI로의 전환을 보여준다.

9. 시장 진입, SpaceXAI의 세 기둥, 100% 위임

제품의 기술적 독창성만큼이나 초기 사용자가 미래를 체험하고 그 경험을 회사로 가져가게 만드는 유통 전략이 중요했다.

9.1. 데모웨어가 아닌 실제 사용을 만든다

1. 초기 수요의 전파 경로
   1. 코딩 제품의 선례: 초기 코딩 도구 사용자는 직장 밖의 개인 프로젝트와 주말 작업에서 미래의 속도를 먼저 경험했다.
   2. 직장으로 역수입: 업무로 돌아온 사용자는 기존 방식이 진흙 속을 걷는 것처럼 느껴진다고 말하며 회사에도 같은 도구를 요구했다.
2. 지식 노동의 확산
   1. 개인적 aha moment: 홈 로봇 청소기를 조작하거나 Tesla 충전 비용 협상을 돕는 등 개인적인 재미있는 사례로 먼저 가능성을 체감할 수 있다.
   2. 기업으로의 이동: 다음 단계는 봇이 팀에 들어와 경제적 가치가 있는 일을 하고, 복잡한 회사 시스템과 조직의 기억을 이해하게 만드는 것이다.
3. 분포와 사용 사례의 결합
   1. 빠른 계정 확산: 기초 모델 연구소가 다음 제품을 내놓기 전에 많은 사람이 제품을 써보게 하려고 무료 계정과 사용 사례를 적극적으로 확장했다.
   2. 템플릿의 역할: 무엇을 해야 할지 막막한 신규 사용자가 다른 사람이 만든 봇과 템플릿을 보고 즉시 실험하도록 했다.

9.2. SpaceXAI의 세 가지 기둥

1. 개발자용 코딩 제품
   1. 제품: 현재 Cursor와 Grok Build가 개발자·엔지니어 조직의 전문 작업 표면을 담당한다.
   2. 역할 분리: Grok Bot이 클라우드 에이전트를 시작하거나 PR을 병합하고 QA를 하는 등 엔지니어링 인접 작업을 맡을 수 있지만, 운영 소프트웨어를 배송하는 픽셀은 개발자에게 최적화된 표면에 남겨야 한다.
2. 일반 지식 노동 제품
   1. Grok Bot의 위치: 비개발자와 기업까지 에이전트를 확장하고, 새로운 표면·조직 맥락·협업 방식을 추가해야 한다.
   2. 핵심 과제: 개인 단위의 단일 봇을 넘어 복잡한 팀 시스템에서 봇이 일하고, 조직의 기억과 권한을 다루게 만들어야 한다.
3. 일반 모델 연구
   1. 목표: 세상에서 가장 똑똑하고 실제로 쓸 수 있는 모델을 훈련한다.
   2. 차별점: 막연한 초지능이나 추상적 이상을 좇기보다, 제품과 모델 양쪽에서 유용한 AI를 만드는 실용적 목표를 둔다. 모델 훈련에 참여하는 엔지니어들도 응용 중심의 관점에서 출발했다.

9.3. 90% 완성과 100% 위임의 질적 차이

1. 대부분의 AI 사용 경험은 여전히 90%다
   1. 기존 흐름: 새 스레드를 만들고 입력창에 요청한 뒤 단계별 진행을 지켜보고, 결과를 수정하고, 다음 지시를 계속 보내야 한다.
   2. 감독의 잔여: 결과가 90% 완성돼도 사용자는 봇이 작업하는 동안 계속 생각하고 개입할 것을 예상한다.
2. 100%는 신뢰의 변화다
   1. no-look pass: 맥락을 주고 "네가 맡아"라고 던진 뒤, 결과가 완성될 때까지 잊어버릴 수 있는 패스가 진정한 위임이다.
   2. 직업 경험의 변화: 개발자는 이미 약 1~1.5년 동안 이런 변화를 느꼈지만, 비코딩 업무에서 같은 경험을 가능하게 한 첫 계기가 Grok Bot이었다.

10. 빠르게 움직이는 조직과 발견되는 해자

Cursor와 Grok Bot의 일관된 속도는 인원 수나 자금 조달 단계보다, 명확한 방향과 서로에 대한 깊은 신뢰를 바탕으로 한 스타트업 에너지에서 나왔다.

10.1. 규모가 커져도 스타트업 감각을 보존하는 법

1. 속도의 조직 조건
   1. 성장 배경: Roman Ugarte는 Cursor에 약 15명일 때 합류했고, 회사가 1,000명 이상으로 성장한 뒤 SpaceXAI의 더 큰 조직에 합류했다.
   2. 신뢰와 방향: 모두가 100마일로 움직이고 각자가 맡은 부분을 해낼 것이라고 깊이 신뢰하며, 모두가 열광하는 명확한 비전을 공유해야 한다.
2. 스타트업의 정의
   1. 숫자가 아니다: 인원 수나 펀딩 라운드로 스타트업을 정의하면 핵심을 놓친다.
   2. 스크램블 에너지: 다소 혼란스럽고 무질서하지만 투입한 만큼 특정 방향으로 단기간에 큰 영향을 내는 환경, 즉 scramble energy가 핵심이다.
3. 성장 조직의 위험
   1. 느려지는 현실: 회사가 커지면 "우리는 여전히 스타트업이고 빠르다"고 말하기 쉽지만, 실제로는 모두가 속도가 느려졌음을 안다.
   2. 유지해야 할 속성: 불편함을 감수하더라도 빠른 실행과 책임의 밀도를 조직 설계에 남겨야 한다.

10.2. Cursor가 경쟁에서 살아남은 문화

1. 경쟁 조건
   1. 압도적 경쟁: Cursor는 OpenAI·Anthropic처럼 역사상 가장 빠르게 성장하는 기업과 경쟁하고, 그들의 모델 플랫폼 위에서 제품을 만든다.
   2. 초기 경쟁자와 현재의 격차: 처음부터 Microsoft를 포함한 10~20개 회사가 경쟁했지만, 현재 최전선에 남은 기업은 극히 적다.
2. 6개월마다 현실에 맞게 재창조한다
   1. 능력 변화 반영: 2년 전의 제품 요구와 오늘의 요구는 완전히 다르며, 모델이 강해질수록 제품도 그 순간에 맞게 변해야 한다.
   2. 재창조 주기 단축: 핵심 제품·우선순위·사용자가 체감하는 경험을 6개월마다 크게 바꾸지 못하면 경쟁에서 진다. 최근에는 그 주기가 더 짧아졌다.
3. 안주하지 않는다
   1. 승리 선언 금지: 한 번 이겼다고 생각하지 않고 항상 다음 문제를 찾는다.
   2. 문화의 결과: 올바른 결정을 한 번 했다는 사실보다, 변화하는 순간에 맞춰 믿음을 계속 업데이트하는 문화가 지속적인 성과를 만든다.

10.3. 두 가지 핵심 가치: 제품을 지우고 일을 직접 하라

1. 제품을 삭제하라(deleting the product)
   1. 스캐폴딩 오버행 제거: 모델이 충분히 똑똑하지 않을 때 넣었던 보정 레이어, 복잡한 설정, 제품 오버행은 모델이 능력을 갖추면 사라져야 한다.
   2. 작은 불만보다 큰 단순화: 일부 사용자나 내부 구성원을 불편하게 만들더라도, 더 단순하고 강력한 미래에 맞춰 기능을 삭제해야 한다.
2. 그냥 일을 하라(just do the thing)
   1. 허가보다 책임: 해야 할 일을 발견했을 때 승인을 기다리는 문화가 아니라, 자신이 필요한 자원을 끌어와 직접 고친다.
   2. 공동의 배: 모두가 같은 배에 있고 이기고 싶다는 전제가 있어야 개인의 실행력이 조직 성과로 연결된다. 이 실행 중심성은 SpaceXAI의 문화와도 맞닿아 있다.

10.4. 해자는 계획하는 것이 아니라 발견하는 것이다

1. 전략 도식에서 출발하지 않는다
   1. 뒤늦은 해석: Cursor가 데이터 피드백 루프와 최상급 사용자 경험이라는 이점을 갖게 된 것은 처음부터 해자를 설계했기 때문이 아니다.
   2. 오늘의 유용성: "오늘 당장 유용한 것을 어떻게 만들까"라는 집착이 출발점이었다.
2. 미래 능력을 현재로 당긴다
   1. 반복 프롬프트: 3~6개월 뒤 모델이 더 똑똑해지면 가능해질 일을 지금 어떤 제품·엔지니어링으로 당겨올지 묻는다.
   2. 다시 삭제한다: 모델이 그 일을 기본적으로 잘하게 되는 순간, 앞서 붙인 엔지니어링과 UX 스캐폴딩을 삭제하고 다음 불가능한 일을 당겨온다.
3. 신뢰에서 이점이 생긴다
   1. 사용자 신뢰: 사용자는 제품이 다음 프런티어를 계속 가져온다고 믿을 때 자신의 시간을 제품 안에 맡긴다.
   2. 분포·데이터 효과: 반복적으로 유용한 일을 만들어 사용자의 집착을 얻으면 그 과정에서 분포 우위와 데이터 우위가 생긴다. 해자는 사후에 발견되는 결과다.

11. 신규 사용자와 파워 유저를 위한 실행법

사용법의 핵심은 비밀스러운 프롬프트 트릭을 익히는 것이 아니라, 동료를 온보딩하듯 맥락과 도구를 주고 실제 업무 덩어리를 위임하는 것이다.

11.1. 처음 시작할 때

1. 도구와 맥락을 먼저 준다
   1. 접근 권한: 회사 동료에게 Slack·이메일·매일 쓰는 회사 기록을 열어주듯이 봇에게 필요한 도구를 연결한다.
   2. 역할 설명: 자신의 직무와 중요하게 보는 것을 알려줘야 봇이 무엇을 우선하고 어떤 정보가 중요한지 판단할 수 있다.
2. 봇에게 가능성을 탐색시킨다
   1. 첫 명령: 연결된 Slack과 이메일을 훑고, 자신이 덜어줄 수 있는 일 다섯 가지와 각 일을 하기 위해 필요한 것을 제안하라고 요청한다.
   2. 작업 단위의 차이: 단순히 이메일 초안을 쓰라는 요청이 아니라, 사람이 맡기고 잊을 수 있는 업무 덩어리를 찾는 것이 핵심이다.
3. 두 가지부터 봇으로 분리한다
   1. 초기 성공: 다섯 가지 제안 중 실제로 유용한 두 가지를 골라 각각의 봇으로 즉시 분리하면 첫 번째 "이전 AI가 못 하던 일을 한다"는 순간을 만들 수 있다.
   2. 점진적 확장: 처음부터 복잡한 팀 구조를 설계하지 말고, 실제로 반복되는 역할과 업무 레인을 발견하면서 봇을 늘린다.

11.2. 파워 유저가 확장할 때

1. 봇 간 협업 패턴을 만든다
   1. 상호작용 탐색: 어떤 봇이 다른 봇에게 무엇을 맡기면 좋은지 계속 실험한다.
   2. chief of staff 활용: 한 봇이 전체 업무를 조정하고 다른 봇을 호출하게 하면 사용자가 각각의 작업을 직접 관리하지 않아도 된다.
2. 결과를 단일 저장소에 모은다
   1. 읽기 쉬운 산출물: 봇이 만든 자료가 어디에 쌓이는지 규칙을 만들고, 사용자에게 익숙한 데이터베이스나 문서에 기록하게 한다.
   2. 정기 다이제스트: 봇이 매일 읽는 빈도 높은 다이제스트를 하나의 데이터베이스로 밀어 넣으면 결과를 한곳에서 정리·검토할 수 있다.

주요 발언 모음

"The ultimate vision of Grok Bot is incredibly simple: you should have a team of AI bots that help you with your job and help you with your life."

"An AI that does 100% of the job feels categorically different from one that gets you 90% there."

"Once you start breaking out of ‘this is AI chat with a set of connections’ and into ‘this is a colleague with a computer,’ it raises the ceiling of what you would think to give to AI."

"You should never have to think about local and cloud and where are these workflows running."

"If you were onboarding someone to your team, you wouldn't ask them to share the same laptop forever and constantly trip over each other."

"What would you want from a human teammate?"

"Moats are discovered, not planned."

핵심 데이터 & 수치

• 약 1개월: 첫 코드부터 유용한 내부 프로토타입까지 걸린 기간이다.
• 약 3주: 내부 베타에서 공개 출시까지 걸린 기간이며, 녹화 시점에도 공개 출시 후 약 3주였다.
• 200~300명: 핵심 팀이 수동으로 온보딩하며 초기 제품의 실패와 사용 패턴을 수집한 사용자 수다.
• 약 2주: 수백 명의 초기 사용자 온보딩을 집중적으로 진행한 기간이다.
• 5~10개: 초기 내부 사용자가 업무 영역별로 운영하던 봇의 전형적인 수다.
• 99%: 자연어로 정의하는 방식이 Grok Bot 자동화 생성에서 차지하는 비율로 소개됐다.
• 10~20개: 영업팀의 컴퓨터 사용에서 발견해 해결한 작은 클릭·브라우저·가시성 문제의 대략적인 규모다.
• 약 15명 → 1,000명 이상: Roman Ugarte가 Cursor에 합류했을 때부터 회사가 성장한 규모다.
• 6개월 또는 그보다 짧은 주기: AI 모델과 시장의 변화에 맞춰 핵심 제품과 우선순위를 재창조해야 하는 주기다.
• 1~1.5년: 개발자들이 업무가 완전히 바뀌었다고 느끼기 시작한 AI 코딩 경험의 대략적인 기간이다.
• 약 1시간 22분 43초: 에피소드 전체 길이다.

결론 및 시사점

1. 에이전트를 동료로 설계하라: 사용자가 내부 도구 호출을 감시하게 하지 말고, 동료에게 기대하는 자율성·맥락 기억·진행 공유·완성된 결과를 구현해야 한다.
2. 봇에 자기 컴퓨터와 권한을 주라: API가 없는 웹사이트와 현실의 업무를 처리하려면 화면·브라우저·입력 상자를 다룰 수 있는 독립 실행 환경이 필요하다.
3. 로컬 실행의 책임을 사용자에게 넘기지 말라: 클라우드에 영속적인 실행 상태를 두면 폰·데스크톱·향후 음성 등 모든 접점에서 동일한 동료를 호출할 수 있다.
4. 작은 격리 팀으로 새 문제를 풀라: 조직 전체의 6~12개월 로드맵 합의보다, 짧은 기간에 미세한 제품 결정을 빠르게 쌓는 소규모 팀이 새로운 표면을 만드는 데 유리하다.
5. 초기 사용자를 직접 만나 맹점을 찾아라: 파워 유저뿐 아니라 커피숍 운영자 같은 낯선 프로필을 온보딩해야 내부 집단사고에서 벗어날 수 있다.
6. 기능을 더하기 전에 삭제하라: 모델이 충분히 똑똑해진 뒤에도 남아 있는 스캐폴딩, 설정, 디버그 화면은 사용자 경험의 부채가 된다.
7. 출시 글이 없는 기능은 다시 검토하라: 사용자가 직접 체감할 변화와 설명할 수 있는 능력이 없으면 메뉴와 픽셀을 늘리는 일이 제품 가치를 높이지 않는다.
8. 업무를 90%가 아니라 100% 단위로 위임하라: 결과를 계속 감독해야 하는 90% 자동화는 여전히 사용자가 일을 수행하는 것이며, no-look pass가 가능한 순간에 질적 변화가 생긴다.
9. 정보를 소비하는 봇을 만들어라: Slack·이메일·웹·내부 데이터의 소음을 봇이 흡수하고 중요한 신호만 전달하면 사람의 집중력이 보호된다.
10. chief of staff 구조를 점진적으로 발견하라: 역할별 봇을 여러 개 만든 뒤 가장 뛰어난 봇이 다른 봇을 조율하게 하면 AI 팀의 레버리지가 생긴다.
11. 업무와 개인 생활의 공통 형태를 활용하라: 권한과 보안은 분리하더라도, 의도를 말하고 반복 작업을 위임하는 제품 경험은 두 영역에서 공통으로 작동한다.
12. 조직의 속도는 숫자가 아니라 문화로 결정된다: 빠른 실행, 명확한 방향, 서로에 대한 신뢰, 직접 문제를 해결하는 책임감이 커진 조직에도 남아 있어야 한다.
13. 모델 능력의 변화를 제품에 즉시 반영하라: 3~6개월 뒤 가능해질 일을 현재로 당겨오고, 모델이 따라잡으면 보정 레이어를 삭제하며 다음 프런티어로 이동해야 한다.
14. 해자를 설계 도식으로 만들려 하지 말라: 오늘 유용한 제품을 만들어 사용자의 신뢰를 얻는 과정에서 분포·데이터·경험의 이점이 뒤늦게 해자로 나타난다.

부록: 에피소드에서 언급된 추천과 참고

1. Roman Ugarte의 추천 도서

1. 『Cat's Cradle』 — Kurt Vonnegut: 친구들에게 여러 권을 선물할 만큼 자주 추천하는 책이다.
2. 『The War of Art』 — Steven Pressfield: 창작을 막는 저항을 다룬 짧은 책으로, 한 번에 한두 쪽씩 자주 다시 읽는다.

2. 좋아하는 작품과 AI 제품

1. 『Casablanca』: 매년 다시 보는 가장 좋아하는 영화 중 하나이며, Roman의 성과 같은 Ugarte라는 인물이 등장한다.
2. 『Monk』: 어린 시절 가족과 보던 탐정 드라마로, 샌프란시스코에 살게 된 뒤 1990년대 말~2000년대 초의 도시 모습을 다시 보는 재미가 있다.
3. Exa: 과거 Metaphor였을 때부터 사용한 의미 검색(semantic search) 제품으로, 인터넷에서 평범하지 않은 질의를 검색하는 데 흥미를 느낀다.
4. Desiderata: 청소년기부터 문에 붙여두고 이사할 때마다 가져가는 짧은 시다. 매번 읽을 때마다 새로운 문장을 발견하고 마음을 가라앉히는 기준으로 삼는다.

3. 중간에 소개된 기업 도구

1. WorkOS: SSO, SCIM, RBAC, 감사 로그 같은 엔터프라이즈 기능을 API로 제공하며, 초기 스타트업부터 글로벌 유니콘까지 B2B SaaS의 상향 판매를 돕는 도구로 소개됐다.
2. Mercury Spend: 팀별 카드·예산·환급을 비즈니스 뱅킹과 한곳에서 관리하고, AI 에이전트에도 별도 카드와 한도를 줄 수 있는 비용 관리 기능으로 소개됐다.

핵심 요약 (20줄)

1. Grok Bot은 소규모 격리 팀이 첫 코드부터 내부 프로토타입까지 약 한 달 만에 만든 지식 노동용 AI 동료 제품이다.

2. 내부 베타에서 공개 출시까지 약 3주 동안 팀은 기능을 늘리기보다 복잡한 요소를 지우고 핵심 업무가 실제로 끝나게 만드는 데 집중했다.

3. Cursor 안에 기능을 추가하지 않고 별도 제품으로 시작해 모든 픽셀을 지식 노동이라는 하나의 일관된 비전에 맞출 수 있었다.

4. 핵심 팀은 약 2주 동안 사용자 200~300명을 직접 온보딩하며 컴퓨터 부팅과 로그인 같은 작은 실패를 다음날 수정했다.

5. 초기 사용자는 업무 영역별로 5~10개의 봇을 만들고 가장 뛰어난 봇을 chief of staff로 승진시켜 다른 봇을 조율했다.

6. 봇의 모든 클릭과 사고 과정을 노출하지 않고 진행 표시와 필요한 업데이트만 제공해 동료에게 위임하는 감각을 만들었다.

7. 커피숍 운영자 같은 비개발자 초기 사용자는 Shopify와 소상공인 업무의 맹점을 찾아내 실리콘밸리 집단사고를 깨뜨렸다.

8. "Grok Bot은 이제 무엇을 가졌다"보다 "Grok Bot은 이제 무엇을 할 수 있다"를 기준으로 기능을 평가해 사용자에게 보이지 않는 능력을 우선했다.

9. 자연어로 "매일 오전 8시에 알려줘"라고 말하는 자동화가 플랫폼 자동화의 약 99%를 차지했다.

10. 영업팀은 MCP나 API가 없는 도구도 자기 컴퓨터에서 클릭하고 입력하는 봇에게 맡길 수 있어 업무 성공률의 즉각적인 변화를 체감했다.

11. 채용팀은 봇에게 학회 PDF의 새 공동 저자를 찾고 스프레드시트에 기록하며 SpaceXAI 내부 연결을 통해 소개를 요청하게 했다.

12. 첫 번째 핵심 결정은 봇을 클라우드에 영속적으로 두어 사용자의 컴퓨터가 꺼져 있어도 어느 기기에서나 같은 상태로 호출하게 한 것이다.

13. 두 번째 핵심 결정은 각 봇에게 자기 컴퓨터를 줘서 사람처럼 API가 없는 웹사이트와 화면 픽셀을 직접 조작하게 한 것이다.

14. OpenClaw가 보여준 도구 접근과 동료형 정신 모델을 설정 부담 없이 제품화하고 스킬과 slash command를 사용자에게서 숨겼다.

15. 장기 생존 봇은 업무 역할별 기억을 축적하고 다른 봇을 실행해 QA, 정보 수집, 문서화를 이어가는 조직의 기본 단위가 된다.

16. Slack과 이메일을 감시하는 infovore 봇은 정보를 요약하고 긴급할 때만 사용자를 호출하는 상시 chief of staff로 발전할 수 있다.

17. 업무와 개인 생활은 권한을 분리할 수 있지만 의도를 말하고 낮은 레버리지 작업을 위임하는 제품 형태는 두 영역에서 공통으로 작동한다.

18. 진정한 100% 위임은 결과를 계속 감독하는 90% 자동화와 달리 no-look pass처럼 사용자가 일을 잊고 완성된 결과를 받게 한다.

19. Cursor의 지속적인 경쟁력은 6개월 또는 그보다 짧은 주기로 제품을 재창조하고 필요 없어지는 스캐폴딩을 삭제하는 문화에서 나왔다.

20. 해자는 미리 계획하는 전략 도식이 아니라 오늘 유용한 제품을 만들고 사용자의 신뢰와 분포·데이터 이점을 발견하는 과정에서 생긴다.