URL: https://www.youtube.com/watch?v=xZ5TEaleUdg
날짜: 2026-09-29
채널: Peter Yang
원문 제목: We Built Grok Bot. Here Are Our 14 Best Bots | Peng Zheng & Lauren Tan

핵심 질문/논점

==개인별로 역할·기억·도구를 갖춘 영속형 봇을 만들고, 관찰과 교정을 거쳐 반복 업무를 스킬(Skill)과 루틴(Routine)으로 전환하면 한 사람이 여러 봇을 지휘하는 자율적인 업무 시스템을 구축할 수 있다.==

• Peng Zheng는 Chief of Staff, Designer, Writer, Podcast, 개인 프로젝트용 파이프라인을 조합해 일상 업무와 창작 업무를 Grokbot에 위임한다.
• Lauren Tan은 가상 머신 제어, 플러그인·스킬 평가, 엔지니어 봇 계층, 소셜 모니터링을 하나의 에이전트 조직으로 연결한다.
• 자율성의 한계는 모델 성능만으로 결정되지 않고, 사용자가 얼마나 관찰하고 교정했으며 봇이 같은 업무를 반복해서 잘 수행한다는 신뢰를 쌓았는지에 따라 결정된다.

본문

1. 영속형 개인용 컴퓨터로서의 Grokbot

1.1. 인터뷰의 출발점과 제품 관점

1. Grokbot을 매일 쓰는 개인용 컴퓨터로 정의하기

   1. Peter Yang은 Grokbot을 지금까지 본 제품 중 첫 번째로 영속적인(persistent) 개인용 컴퓨터 제품이라고 설명하며 매일 사용한다고 말했다.
   2. 영속성은 일회성 프롬프트 세션이 아니라 이름과 역할, 기억, 도구를 가진 봇이 계속 살아 있고 여러 프로젝트에서 재사용된다는 뜻이다.
   3. Peter Yang은 Peng Zheng과 Lauren Tan에게 개인용 Grokbot 구성, 업무·개인 작업에 쓰는 봇, Grokbot 자체를 설계·제작하는 방식, 커뮤니티가 만드는 가장 놀라운 봇을 차례로 보여 달라고 요청했다.

2. 봇을 사람처럼 구분하는 인터페이스

   1. 일반적인 AI 도구는 세션·작업·프로젝트 단위로 나뉘어 대화가 소모되지만, Grokbot은 이름 붙은 에이전트를 역할 단위로 추상화한다.
   2. 자동차 사고 때 보험사 담당자에게 연락하고, 건강 문제가 생기면 병원·의사에게 연락하는 현실 세계의 접점처럼, 사용자는 내부 모델 구조를 알지 않아도 맡길 역할을 선택할 수 있다.
   3. 도구·커넥터·스킬은 재사용되지만, 각 봇의 기억과 선호는 개별 봇에 로컬로 남는다. 이 분리가 역할과 개인적 관계를 함께 만든다.

1.2. Peng Zheng의 기본 구성

1. 업무와 생활로 나눈 봇 구조

   1. Peng Zheng은 디지털 세계에서 거의 모든 일을 Grokbot에 맡기며, 봇을 크게 업무(work)와 생활(life)로 분류한다.
   2. 어떤 봇이 일을 맡아야 할지 모르겠으면 Chief of Staff에 보내는 것이 기본 규칙이다. Chief of Staff는 다른 봇을 관리하는 범용 진입점이다.
   3. Chief of Staff에는 디지털 세계의 거의 모든 작업을 지시할 수 있다.

2. 3D 프린터 필라멘트 구매와 재고 갱신

   1. Peng Zheng은 며칠 전 Chief of Staff에게 3D 프린팅 필라멘트를 사 달라고 요청했다.
   2. 봇은 구매만 수행하지 않고, 색상별 필라멘트를 추적하는 Notion 재고 데이터베이스에 구매 결과까지 기록했다.
   3. 하나의 명령이 외부 구매와 내부 기록을 함께 처리하면서, 단일 작업 위임이 아니라 상태(state)를 갱신하는 업무 자동화가 된다.

3. Facebook Marketplace의 DJI 마이크 판매

   1. Peng Zheng은 DJI 마이크 사진을 보내고 Facebook Marketplace에 판매 글을 올려 달라고 요청했다.
   2. 봇은 공식 웹사이트에서 해당 모델의 최신 가격을 확인하고, 지역에서 판매 중인 최저가와 경쟁 상품을 조사한다.
   3. 과거 Peng Zheng이 작성한 Marketplace 상품 설명을 Writer 봇에게 물어본 뒤 자신의 문체로 새 설명을 작성한다.
   4. 조사를 마친 뒤 새 상품을 게시하고, 관심을 받지 못하면 매주 가격을 5달러씩 자동으로 낮춘다.
   5. 과거에는 최신 가격 확인, 경쟁 조사, 문체 파악, 설명 작성, 게시, 가격 조정까지 여러 단계를 직접 했지만, 이제는 한 프롬프트로 연결된 작업 흐름을 실행할 수 있다.
   6. 핵심 변화는 개별 작업을 위임하는 데 그치지 않고, 봇에게 작업을 수행하는 절차 자체를 학습시키는 데 있다.

4. 이메일과 캘린더를 대신하는 Chief of Staff

   1. Peng Zheng은 “오늘 받은 편지함의 액션 아이템이 무엇인가?”라고 물으며 이메일을 정리한다.
   2. 친구와 저녁을 먹고 돈을 보내야 하는 경우 봇에게 송금을 요청한다.
   3. 필요한 권한이 없으면 봇이 로그인 페이지를 열고, Peng Zheng이 봇의 컴퓨터를 직접 인계받아 로그인한 뒤 작업을 이어갈 수 있다.
   4. 캘린더에서는 커피챗 일정 생성·수정, 빈 시간 찾기, 회의실 예약 등을 스크린샷과 지시만으로 처리한다.
   5. 봇은 캘린더에 일정을 추가하고 기존 일정을 수정하는 등 시각적 인터페이스의 후속 작업까지 실행한다.

1.3. Peng Zheng의 Designer와 Writer 봇

1. Designer 봇으로 아이디어에서 실행까지 연결하기

   1. Designer 봇은 Peng Zheng이 매일 사용하는 디자인 도구 안에서 브레인스토밍하고 여러 디자인 선택지를 만들어 주는 기본 파트너다.
   2. 아이디어를 논의하는 데서 멈추지 않고 실제 디자인 도구에 적용해 결과물을 실행한다.
   3. Peng Zheng은 Figma, 캔버스 기반 도구, 자체 프로토타입 환경을 상황에 따라 사용하며 때로는 직접 Pull Request(PR)도 제출한다.
   4. Designer 봇은 Figma MCP 커넥터를 통해 프레임을 직접 바꾸고, 디자인 토큰을 적용하고, 디자인 시스템에 맞춰 색상·타이포그래피·간격을 선택한다.
   5. Designer 봇의 스킬에는 Peng Zheng의 Figma 파일 구조와 디자인 시스템이 담겨 있어 매번 처음부터 설명하지 않아도 올바른 컴포넌트와 토큰을 고를 수 있다.

2. 첫 5%를 사람이 만들고 나머지를 확장하기

   1. 한 가지 방식은 사람이 시스템을 설계하고 핵심 프레임 하나를 만든 뒤 Designer 봇에게 전체 플로우와 엔드투엔드 화면으로 확장하도록 하는 것이다.
   2. Peter Yang이 말한 “첫 80%를 봇이 하고 나머지를 사람이 다듬는가?”라는 질문에 Peng Zheng은 오히려 “첫 5%를 사람이 하고 나머지를 봇이 확장한다”고 설명했다.
   3. 첫 5%에 디자인 의도와 기준을 심어 두면 봇이 그 기준을 전체 화면과 사용자 흐름에 반복 적용할 수 있다.
   4. Peng Zheng의 개인 스킬은 “Peng mode”로, Lauren Tan의 스킬은 “Lauren mode”로 불리며 각자의 작업 방식과 기준을 재사용한다.

3. Writer 봇으로 비원어민의 커뮤니케이션 보완하기

   1. Peng Zheng은 영어 원어민이 아니므로 이메일과 Slack 메시지를 보내기 전에 Writer 봇으로 다듬는다.
   2. Slack·이메일 채팅 위젯 안에서 봇이 작성한 초안을 인라인으로 확인하고, 전송 전에 직접 검토·수정할 수 있다.
   3. Writer 봇은 Peng Zheng의 과거 문체를 참조해 단순한 문법 교정이 아니라 본인의 표현 습관에 맞는 메시지를 만든다.

2. 여러 봇을 한 팀처럼 일하게 만드는 작업 방식

2.1. 그룹 채팅과 다중 관점 검토

1. 고양이 울음 번역 앱 아이디어를 검토하는 봇 팀

   1. 큰 작업에서 서로 다른 역할과 관점을 가진 봇들이 각자 기여하도록 세 봇을 하나의 그룹 채팅에 넣는다.
   2. 예시로 “고양이 울음소리를 영어로 번역하는 앱”을 만들 때, PM·디자인 등 서로 다른 역할의 봇을 그룹에 추가해 아이디어를 검토한다.
   3. 봇들은 아이디어를 논의하고 서로 반론하며 설계 방향을 발전시킨다.
   4. 특정 봇에게만 답을 받고 싶으면 해당 봇을 @멘션한다. 일반 메시지를 그룹에 보내면 각 봇이 내용을 읽고 자신이 답해야 할지 판단한다.
   5. 각 봇이 독립적인 컨텍스트를 유지하면서 서로 대화하는 구조는 다른 AI 앱에서 구현하기 어려운 기능으로 제시됐다.

2. 역할은 영속적이고, 대화는 프로젝트별로 분리하기

   1. 동일한 Designer 봇을 메일 앱 프로젝트와 바크 앱 프로젝트에서 각각 사용할 수 있다.
   2. 프로젝트마다 별도의 채팅을 만들면 마감과 목적이 다른 작업의 컨텍스트가 섞이지 않는다.
   3. Designer 봇이라는 동일한 개체는 여러 채팅에서 동시에 작업하며, 그룹 채팅에서 상태가 바뀐 내용은 해당 봇과의 DM에서도 확인된다.
   4. 역할·기억·도구처럼 재사용 가능한 요소는 봇으로 추상화하고, 개별 프로젝트의 단기 실행 맥락은 전용 세션으로 분리하는 방식이다.
   5. 일반적인 에이전트 제품에서 오래된 채팅은 소모품처럼 사라지고 사용자는 적극적으로 진행 중인 상위 3~5개 대화만 기억한다. 영속 봇과 프로젝트 세션의 결합은 이 문제를 완화한다.

2.2. 팟캐스트 변환과 멀티모달 파일 처리

1. 기사 링크를 들을 수 있는 팟캐스트로 변환하기

   1. Peng Zheng은 팟캐스트를 많이 듣지만, 운전하거나 샤워할 때 읽은 기사도 듣고 싶어서 Podcast 봇을 사용한다.
   2. 기사 링크를 Podcast 봇에 보내면 봇이 오디오 팟캐스트 형식으로 변환해 언제든 들을 수 있게 한다.
   3. Grokbot은 여러 파일 형식 사이를 자동으로 변환하는 범용 번역기처럼 동작한다.

2. 사람이 인터페이스가 아니라 파일과 링크를 입력하기

   1. 입력은 채팅에 보낸 링크·사진·스크린샷일 수 있고, 출력은 캘린더 일정·상품 게시물·오디오·웹사이트 콘텐츠가 될 수 있다.
   2. 사용자가 각 서비스의 화면을 따로 열고 복사·붙여넣기하지 않아도 봇들이 각자의 커넥터와 기억을 이용해 연결된 작업을 수행한다.

3. 사진 한 장에서 웹사이트 체크인 앱까지

3.1. 샌프란시스코 차이나타운의 3D 점토 미니어처

1. 우연한 이미지 실험에서 개인 프로젝트가 시작되다

   1. Peng Zheng은 약 2주 전 버스를 기다리며 샌프란시스코 차이나타운의 한 가게 사진을 찍었다.
   2. AI로 사진을 3D 점토 미니어처(3D clay miniature)처럼 변환했고, 결과가 재미있어 개인 웹사이트에 올렸다.
   3. 웹사이트에는 차이나타운의 JBC 마켓에서 찍은 사진이라는 짧은 문구를 넣었지만, 방문자는 한 번 보고 다시 오지 않았고 Peng Zheng 자신도 자주 방문하지 않았다.

2. 개인 웹사이트를 인터넷 체크인 앱으로 바꾸기

   1. 장소를 방문할 때마다 체크인하고 위치·가게·동행인을 웹사이트에 자동 게시하는 인터넷 체크인 앱 아이디어가 생겼다.
   2. 장소 사진과 동행인의 소셜 핸들을 텍스트로 보내면 파이프라인이 두 장의 이미지, 즉 낮 모드와 밤 모드 이미지를 만든다.
   3. 파이프라인은 이미지 배경을 제거하고, 결과물을 개인 웹사이트에 게시한다.
   4. Peng Zheng은 이 작업을 위해 별도의 포털이나 CMS를 만들고 백엔드에서 수동 업로드하지 않고, Grokbot을 서비스를 호스팅하는 주 인터페이스로 사용했다.
   5. 봇은 private repository에서 최신 플레이북(playbook)을 가져와 절차를 따르고, 이미지 생성·정리·게시를 순서대로 수행한다.

3.2. Grokbot을 빌딩 블록으로 사용하기

1. 아이디어를 단계별 파이프라인으로 구체화하기
   1. Grokbot은 단순히 최종 결과를 생성하는 도구가 아니라 아이디어를 실행 가능한 단계로 쪼개고 각 단계를 안내하는 빌딩 모듈(building module)이다.
   2. 입력 사진과 사람 정보를 받아 이미지 변환, 배경 제거, 웹사이트 게시까지 연결하면서 한 번의 채팅이 장기적으로 실행되는 제품 파이프라인이 된다.
   3. Peter Yang은 낮·밤 모드를 함께 생각하고 이미지를 배치하는 디자이너식 사고가 인상적이라고 반응했고, Peng Zheng은 이 작업을 “변덕스럽고 재미있는 개인 프로젝트”라고 표현했다.

4. Lauren Tan의 엔지니어링 봇 체계

4.1. Omachi Linux 가상 머신을 봇이 직접 제어하기

1. Omachi 지원 개발

   1. Lauren Tan은 DHH와 오픈소스 개발자들이 만드는 Linux 배포판 Omachi를 더 잘 지원하는 작업을 최근 진행하고 있다.
   2. Mac에서 가상 머신(virtual machine)으로 실행되는 Omachi 특별 빌드를 사용하며, 당시 구현은 매우 알파 단계였지만 꽤 잘 작동했다.
   3. Grokbot이 가상 머신을 스크립트하고 직접 제어할 수 있어, 봇에게 Omachi를 열고 설치하며 Linux 경험을 점검하게 했다.
   4. 화면에서 봇이 실제로 Omachi 환경을 열고 Grokbot을 설치하는 과정을 확인할 수 있었다.

2. 로컬 실행 데몬과 자기 검증

   1. Grokbot은 자체 컴퓨터를 갖지만, 사용자 컴퓨터에서는 로컬 실행 데몬(local execution daemon)이 동작한다.
   2. Lauren Tan의 crumb 봇은 하드디스크 공간이 부족할 때 디스크를 훑어 용량을 차지하는 파일을 찾아 삭제한다.
   3. 컴퓨터 전체 접근 권한은 사용자가 부여한 권한에 따라 제한되며, 가상 머신 제어도 같은 권한 모델 안에서 이뤄진다.
   4. 에이전트가 자신의 작업을 스스로 검증해야 한다는 원칙이 핵심이다. 코드나 설명만 생성하는 것이 아니라 실제 컴퓨터의 Linux 가상 머신에서 설치·실행 결과를 확인할 수 있어야 한다.
   5. 자체 컴퓨터 화면을 사용자가 살펴보는 것과 사용자 컴퓨터의 가상 머신에서 결과를 검증하는 것이 서로 보완된다.

4.2. Pstack 플러그인과 평가 기반 Pull Request

1. 개인 플러그인 스택(Pstack)

   1. Lauren Tan은 자신이 사용하는 플러그인 묶음을 Pstack이라고 부르며, 플러그인과 스킬 개선 작업을 그 안에서 관리한다.
   2. Cursor Cloud Agents를 실행해 변경사항의 평가(evaluation)를 수행한다.
   3. 스킬을 바꿀 때 실제 성능이 좋아졌다고 신뢰하려면, 단순히 프롬프트가 그럴듯하게 보이는지를 보는 대신 재현 가능한 평가 절차가 필요하다.

2. 여러 모델을 활용하는 eval playbook

   1. Pstack의 eval playbook은 에이전트에게 평가 절차를 가르친다.
   2. 에이전트는 서로 다른 모델을 사용하는 여러 하위 에이전트를 생성한다.
   3. 하위 에이전트들이 프롬프트를 실행하고, 처음 설정한 의도와 목표를 실제로 달성했는지 확인한다.
   4. 목표가 달성된 경우에만 Pull Request를 실제 코드베이스에 병합한다.
   5. 플러그인·스킬의 품질 개선을 “모델에게 맡기고 믿는 일”이 아니라 평가를 통과한 경우에만 배포하는 소프트웨어 엔지니어링 과정으로 만든다.

4.3. 봇 이름과 역할 분리

1. Dr. Eggbot과 음식 테마

   1. Lauren Tan은 봇 이름에 Peng Zheng의 단순한 역할명보다 개성이 강한 음식 테마를 붙인다.
   2. Dr. Eggbot은 봇을 설계하는 봇(bot designer bot)이다. Lauren Tan이 원하는 엔지니어링 엄격성을 반영해 새 봇을 설계한다.
   3. 음식 이름을 붙이는 이유를 “아시아인은 음식을 좋아한다”는 농담으로 설명하며, Dau Fuku와 Gza 같은 귀여운 음식 테마 이름을 예로 들었다.

2. Chief of Staff·개인 비서·엔지니어 봇

   1. Lauren Tan도 Chief of Staff를 두고 다양한 잡무를 맡긴다.
   2. 개인 비서 Suki는 점심, 항공편, 호텔 예약을 처리한다. Lauren Tan이 비서를 무시하면 비서가 약간 새침하게 반응한다는 농담이 나왔다.
   3. 사이드바에는 여러 엔지니어 봇과 소셜 봇이 있고, 주요 업무는 Chief of Staff, 엔지니어 리드 Matcha, 개인 비서 Suki를 통해 흐른다.
   4. 아직 개인 비서 팀을 만들지 않은 이유는 그 정도로 바쁘지 않아 봇 여러 명이 필요한 수준은 아니기 때문이다. Suki 한 명만으로도 현재는 매우 잘 작동한다.

4.4. Dr. Eggbot의 봇 리팩터링 루틴

1. 한 봇에 너무 많은 맥락이 쌓일 때

   1. Lauren Tan은 한 에이전트에게 너무 다양한 일을 맡기면 서로 다른 맥락이 뒤섞여 혼란스러워질 수 있다고 설명했다.
   2. Dr. Eggbot은 사용자가 가진 봇 전체와 각 봇과 나눈 대화 기록을 살핀다.
   3. 특정 봇이 반복적으로 잘하지 못하는 일이 있으면 해당 문제를 찾아낸다.

2. 스킬·새 봇·루틴을 제안하기

   1. Dr. Eggbot은 문제를 해결하기 위해 새 스킬을 추가할지, 새 역할의 봇을 만들지, 기존 루틴을 조정할지 제안한다.
   2. 기존 루틴도 점검해 효율성을 개선한다.
   3. 루틴을 10분마다 실행하면 에이전트를 계속 깨우게 되어 사용량과 비용이 커진다. Dr. Eggbot은 불필요하게 잦은 wake-up을 줄이는 역할도 한다.

5. 업무를 쪼개고 봇 군집을 지휘하는 소프트웨어 조직

5.1. Suki가 수행한 복잡한 출장 예약

1. London·Amsterdam 출장 전체 예약

   1. Lauren Tan은 Compile on the Road 컨퍼런스에서 London과 Amsterdam 강연을 앞두고 Suki에게 출장 전체를 맡겼다.
   2. 여행 경로는 단순한 Orange County–London 왕복이 아니라 Orange County→Denver→London→Amsterdam→집으로 이어지는 복수 구간이었다.
   3. 기업 출장 예약 서비스 Navan을 사용해 각 항공 구간과 호텔을 찾았다.
   4. Suki는 컨퍼런스 Slack 메시지 링크와 “항공편과 호텔을 예약하라”는 지시만 받고 최적의 구간, 가능한 좌석 등급, 적절한 시간대, 행사장과 가까운 호텔을 조사했다.
   5. 예약을 확정하기 전 Lauren Tan에게 제안안을 보여 주고 승인받도록 설정했으며, Lauren Tan이 “예”를 누른 뒤 전체 예약이 진행됐다.
   6. 당시 Grokbot을 통한 가장 큰 구매였지만, 완전히 무감독으로 결제하지 않고 예약 직전 사람의 승인을 거쳤다.

2. 자율성과 통제의 균형

   1. Lauren Tan은 원치 않는 심야 항공편이나 비행기 뒤쪽 좌석을 피하기 위해 결과를 확인하고 승인했다.
   2. Peng Zheng도 일본 휴가 항공편을 찾을 때 Google Flights의 가격 알림보다 봇이 더 똑똑하다고 설명했다.
   3. 봇은 사용자가 직접 설정하지 않은 다른 경로까지 찾아 최근 항공료를 절약해 줬다.

5.2. 생활비 결제와 점심 리마인더

1. 소모품 자동 주문

   1. 화장지가 떨어지면 “Amazon 주문을 다시 넣어 달라”고 말해 재주문한다.
   2. 구매 봇은 단순히 검색 결과를 보여 주는 것이 아니라 사용자의 기존 주문과 선호를 바탕으로 생활용품 구매를 실행한다.

2. 봇에게 전화번호를 주고 문자 받기

   1. 초기 Grokbot 개발에서 봇이 사용자에게 먼저 문자를 보낼 수 있는지가 논점이 됐다.
   2. Lauren Tan은 제3자 서비스를 통해 Suki에게 별도의 전화번호를 부여했다.
   3. Lauren Tan은 점심을 자주 잊기 때문에 Suki가 문자로 점심을 상기하도록 했다.
   4. Mac이 방해 금지 모드여서 알림을 못 볼 때도 문자 메시지가 소리를 내므로 점심을 주문해야 한다는 사실을 알아차릴 수 있다.
   5. Suki에게 DoorDash 사용법도 가르쳐 점심을 직접 주문하도록 했다.
   6. Peter Yang은 점심이 하루의 하이라이트라 절대 잊지 않는다고 농담했고, Lauren Tan은 일에 몰입하면 식사를 잊는다고 답했다.

5.3. 엔지니어 리드가 만드는 에이전트 스웜

1. 업무를 직접 하지 않는 리드 봇

   1. Lauren Tan은 대부분의 대화를 Chief of Staff와 나누고, Chief of Staff가 엔지니어 리드와 협업하도록 구성했다.
   2. 엔지니어 리드의 핵심 역할은 일을 직접 처리하는 것이 아니라 큰 작업을 작은 조각으로 나누고, 다른 봇에게 위임하고, 결과를 감독하는 것이다.
   3. 리드 봇 설명에는 연결된 네 엔지니어 봇의 ID가 명시돼 있으며, “스스로 작업하지 말고 항상 네 봇에게 위임하라”는 지시가 들어 있다.

2. Cloud Agent와 작업별 모델 선택

   1. 각 엔지니어 봇은 실제 구현을 위해 Cloud Agent를 생성하고, 사용자는 Cursor나 웹에서 해당 에이전트를 열어 확인할 수 있다.
   2. 단순한 작업에는 빠른 모델과 낮은 지연 시간을 선택한다.
   3. 계획·추론이 필요한 작업에는 더 높은 reasoning level을 설정한다.
   4. Cloud Agent는 작업 종류에 따라 모델과 추론 수준을 세밀하게 조절하게 해 준다.
   5. 엔지니어 봇은 서로 메시지를 전달하고 하위 Cloud Agent를 생성하므로, 사용자는 Chief of Staff 한 곳에서 대규모 에이전트 스웜(agent swarm)을 지휘할 수 있다.

3. 대형 프로젝트의 분해와 검토

   1. Lauren Tan은 거대한 프로젝트를 Chief of Staff에게 주고 먼저 Notion 문서에서 계획을 세우도록 한다.
   2. Chief of Staff는 프로젝트의 단계와 작업을 구상한 뒤 엔지니어 리드에 넘긴다.
   3. 엔지니어 리드는 작업을 더 작은 단위로 분해해 여러 봇에게 나눠 준다.
   4. 각 봇은 변경사항과 Pull Request를 만들고, 다른 봇들이 먼저 검토한다.
   5. Grokbot 코드베이스 자체가 에이전트 친화적(agent-friendly)으로 설계되어 있어 일부 PR은 자동 병합된다.
   6. Lauren Tan은 때때로 PR이 이미 병합된 뒤에야 확인하고 “오, 괜찮네”라고 말한다고 농담했다.

5.4. 소프트웨어 공장이 아닌 Michelin Kitchen

1. 품질을 규모와 함께 만드는 비유
   1. Peter Yang이 여러 봇이 코드를 생산하는 구조를 “software factory”라고 부를지 묻자 Lauren Tan은 “Michelin Kitchen”이라는 표현을 선호한다고 답했다.
   2. 미슐랭 식당 주방은 50석이나 100석 규모의 손님을 처리하면서도 음식의 품질과 장인정신을 유지해야 한다.
   3. 단순한 factory라는 말은 대량생산과 낮은 품질, 소위 slop을 연상시킬 수 있지만, Michelin Kitchen은 품질을 규모 있게 재현한다는 목표를 담는다.
   4. Pstack과 Grokbot의 결합은 “많이 만들기”보다 “높은 품질을 대규모로 만드는 방법”을 찾는 작업이다.
   5. Peter Yang은 봇이 “지역 농장에서 온 PR을 큐레이션했다”고 말하는 컨시어지 바를 농담으로 제안했고, Lauren Tan은 장인(artisan) PR을 검토하라는 식의 대사를 상상하며 웃었다.

6. 개인 스킬과 제품 아키텍처

6.1. Pstack·Peng mode·Lauren mode

1. 개인의 업무 방식을 스킬로 패키징하기

   1. 오픈소스에서 Lauren Tan의 공개 스킬은 Potato mode라고 불리고, 회사 내부에서는 Lauren mode라고 불린다.
   2. Peng Zheng에게는 Peng mode가 있고, 엔지니어·디자이너·PM도 각자의 작업 방식을 담은 mode 스킬을 만들 수 있다.
   3. 한 사람의 암묵적인 판단 기준을 스킬로 저장하면 다른 봇과 도구가 그 사람의 방식으로 반복 작업할 수 있다.

2. Grokbot과 Cursor 사이의 스킬 재사용

   1. Grokbot과 Cursor의 플러그인은 상호운용된다.
   2. Pstack 같은 플러그인을 두 환경에 모두 설치하면 동일한 스킬을 Grokbot과 Cursor에서 재사용할 수 있다.
   3. / 슬래시 명령으로 // potato mode 같은 스킬을 호출할 수 있다.
   4. Marketplace에서 스킬과 플러그인을 찾을 수 있으며, Pstack처럼 스킬 자체가 플러그인인 경우도 있다.
   5. X 플러그인처럼 MCP 서버와 함께 하나 이상의 스킬을 포함하는 플러그인도 있다.
   6. 플러그인은 MCP 도구 하나에 그치지 않고, 봇 인스턴스를 확장하는 여러 기능 묶음이 될 수 있다.

6.2. 엔지니어가 아니어도 기여하는 코드베이스

1. 고수준 기여를 가능하게 하는 재설계

   1. Grokbot 코드베이스를 다시 설계하고 아키텍처를 바꾼 큰 동기는 엔지니어뿐 아니라 모든 사람이 높은 수준으로 기여할 수 있게 하는 데 있었다.
   2. mode 스킬은 이미 코드베이스에 축적된 도메인 지식과 작업 방식을 봇이 활용하게 해 준다.
   3. 사용자는 Grokbot이나 Cursor에서 에이전트를 시작할 수 있고, 두 환경의 플러그인 생태계를 통해 동일한 작업 체계를 유지할 수 있다.

2. 소셜 봇과 제품 피드백 루프

   1. Lauren Tan의 소셜 봇은 X와 LinkedIn에 연결돼 있지만 LinkedIn보다 X를 더 자주 사용한다.
   2. Potato 봇은 X의 모든 멘션을 확인한다. X에서 “potato”를 세 번 말하면 알림이 온다는 개인 밈에서 이름과 동작이 나왔다.
   3. Potato는 약 30분마다 X를 확인하고, Lauren Tan이 직접 답해야 할 멘션을 모은다.
   4. 같은 버그를 다섯 명의 사용자가 보고하면 이를 하나의 신호로 묶어 “이 문제를 살펴보라”고 알릴 수 있다.
   5. 소셜 채널은 단순한 네트워크 관리가 아니라 제품의 바깥 루프(outer loop)다. 사용자 불만, 버그, 혼란스러운 신규 기능이 엔지니어의 안쪽 루프(inner loop)로 전달된다.
   6. Lauren Tan은 Matcha에게 “Potato가 이런 말을 했으니 가서 확인하고 이 문제를 고칠 디자인 제안을 가져오라”고 할 수 있다.
   7. X의 맥락을 직접 복사해 붙여넣지 않아도 Potato에 저장된 내용을 다른 봇이 찾아오므로, 여러 데이터 소스의 풍부한 컨텍스트가 자동으로 결합된다.

3. Potato라는 이름의 유래

   1. Lauren Tan은 몇 년 전 MMO 게임을 하면서 이름을 떠올리기 귀찮아 Potato를 선택했다.
   2. 음식 이름을 좋아하는 성향도 영향을 줬다.
   3. 일반 철자 potato가 이미 사용 중이어서, 당시 일본어를 배우던 Lauren Tan은 가타카나식 표기를 떠올려 potatO처럼 변형된 핸들을 선택했다.

7. 싱글플레이어 AI에서 인간·봇 조직으로

7.1. 세 단계의 업무 방식

1. 사람이 직접 조작하는 단계

   1. 과거에는 사람이 Figma에서 사각형을 그리고, Notion에 글을 입력하고, Slack으로 메시지를 보냈다.
   2. 사람은 도구 내부의 원리를 모두 알지 않아도 화면을 직접 조작해 작업을 완료했다.

2. 사람이 AI에 프롬프트를 보내는 단계

   1. 현재 많은 사용자는 AI에게 Figma·Notion·Slack 작업을 수행하도록 프롬프트를 보낸다.
   2. 여전히 사람이 모든 봇을 직접 관리하고, 각 작업의 순서를 지시하는 구조가 흔하다.

3. 시스템과 가드레일을 설계하는 단계

   1. 다음 단계에서는 사람이 개별 봇을 수동 관리하는 대신, 봇들이 다른 봇·사람과 협력하도록 시스템과 가드레일을 설계한다.
   2. 지능과 에이전시(agency)를 장시간 실행되는 워크플로에 넣고 사람이 필요할 때만 방향과 피드백을 제공한다.
   3. AI 에이전트 제품은 오랫동안 모델 중심(model-centric)이었다. 모델 주위에 하네스(harness)를 만들고 그 위에 제품을 올렸기 때문에, 사용자에게는 모델 내부의 기술 용어가 노출됐다.
   4. “솔드아웃 MD” 같은 기술 개념을 부모 세대가 알 필요 없이, 현실에서 보험 담당자나 의사를 부르듯 이름 있는 봇에게 요청하는 사용자 정신모형(user mental model)이 더 자연스럽다.

7.2. 실제 내부 워크플로의 에이전트화

1. 버그 캡처에서 엔지니어 봇의 작업까지

   1. Peng Zheng은 버그를 발견하면 스크린샷을 찍고 주석을 단다.
   2. 주석이 달린 스크린샷을 봇에 던지면 봇이 Notion 페이지를 만들고 내용을 게시한다.
   3. 엔지니어 봇은 Notion 페이지를 찾아 작업을 시작한다.
   4. 사람은 모든 구현 단계를 직접 입력하지 않고, 증거와 컨텍스트를 연결하는 역할을 한다.

2. 맥락을 전달하는 인간의 역할

   1. 여러 봇이 같은 집에 사는 것처럼 각자 다른 방에서 일하고 서로 컨텍스트를 전달한다.
   2. 인간은 완전히 빠지는 것이 아니라 봇 사이에 맥락을 넘기고 결과에 피드백을 주는 루프에 남는다.
   3. “잠자리에 들면서 봇에게 앱 전체를 만들라고 하고 아침에 완벽한 결과를 받는다”는 식의 무감독 낙관에는 Lauren Tan도 회의적이다.

8. 신뢰를 쌓아 자율성을 확대하는 방법

8.1. 관찰·교정·스킬화

1. 자율성은 신뢰의 함수다

   1. 봇에게 어느 정도 자율성을 줄지는 모델의 이름보다 사용자가 그 봇을 얼마나 신뢰하는지에 달려 있다.
   2. 사용자가 봇의 작업을 한 번도 보지 못한 상태에서 바로 장시간 자율 실행을 허용하면 결과를 믿기 어렵다.
   3. 봇이 일하는 과정을 직접 관찰하고 잘못된 부분을 교정해야 반복 가능한 절차가 된다.

2. Expense report 사례

   1. 처음에는 “이번 달 지출을 모두 찾아 영수증을 이메일에서 찾고 비용 도구에 입력해 경비 보고서를 제출하라”는 식으로 봇과 함께 업무를 수행한다.
   2. 여러 번 반복하며 결과를 관찰하고 프롬프트와 절차를 고친다.
   3. 잘 다듬은 절차를 재사용 가능한 스킬로 저장한다.
   4. 이후 /expense report 같은 슬래시 명령 한 번으로 안정적인 결과를 얻을 수 있을 때까지 반복한다.
   5. 원샷(one-shot)으로 업무가 잘 되면 그때 새 영수증 이메일이 들어올 때마다 자동으로 보고서를 작성하는 루틴을 설정할 수 있다.

3. 범용 신뢰 형성 원칙

   1. 디자인·엔지니어링·생활 관리 업무 모두 관찰→교정→스킬화→루틴화의 단계를 거친다.
   2. 스킬과 프롬프트는 봇이 올바르게 일한다는 신뢰를 만드는 장치다.
   3. 봇이 한두 번 같은 작업을 안정적으로 반복한 뒤에야 사용자는 자리를 비우고 다른 일을 할 수 있다.

8.2. 점진적 온보딩과 개인화

1. 작은 작업에서 반복 작업으로

   1. Peng Zheng은 단순한 작업부터 시작하라고 권한다.
   2. 자신이 키보드와 마우스로 하는 모든 작업을 봇에게 맡겨 한계를 실험하고, 필요하면 의도적으로 능력을 한계까지 밀어붙인다.
   3. 그다음 단발 작업을 반복 작업으로 바꾸고, 반복 작업을 루틴으로 자동화한다.

2. 비용·도구·스킬을 조절하기

   1. 루틴이 토큰을 너무 많이 사용하면 실행 빈도와 범위를 낮춘다.
   2. 점차 더 많은 도구·커넥터·스킬을 연결하고, 역할에 맞게 봇을 커스터마이즈한다.
   3. 모든 기능을 처음부터 붙이는 것이 아니라 결과와 비용을 보며 성숙도를 높인다.

3. 봇과 사용자의 상호 온보딩

   1. Peng Zheng은 이 과정을 봇과 사용자가 관계를 만드는 일이라고 표현했다.
   2. 각 봇은 공유된 기능을 사용하지만 기억과 선호는 개별적으로 가지므로, 사용자의 작업 습관에 따라 서로 다른 어시스턴트가 만들어진다.
   3. Lauren Tan은 새 직원을 온보딩하는 것과 같다고 비유했다. 새 직원에게 일을 가르치고 충분히 믿을 수 있을 때 자율성을 주듯 봇도 훈련 후 자율화해야 한다.
   4. 신뢰가 쌓이면 사람은 “제품의 CEO”처럼 실행을 위임하고 더 높은 수준의 전략적 일에 집중할 수 있다.
   5. Peter Yang이 “이제 모두가 제품의 CEO가 될 수 있겠다”고 말하자 Lauren Tan은 웃으며 동의했다.

주요 발언 모음

“How much trust are you willing to give your agent or your bot to be able to do a task for you?”
“에이전트나 봇이 당신의 일을 대신하도록 얼마나 신뢰를 줄 의향이 있는가?”

“Spend the time to sort of observe the bot or agent doing the work, and then you course correct it.”
“봇이나 에이전트가 일하는 과정을 직접 지켜보고, 그다음 방향을 교정하라.”

“I will do the first 5% … and then ask it to scale it into the whole flow and make it an end-to-end range.”
“내가 첫 5%를 만들고, 전체 플로우와 엔드투엔드 화면으로 확장하라고 요청한다.”

“I want to set a Michelin kitchen, not just a factory.”
“단순한 공장이 아니라 미슐랭 주방을 만들고 싶다.”

“Start a simple task, then start a recurring task, and then set up routines; let it automate it.”
“간단한 작업으로 시작하고, 반복 작업으로 옮겨 간 뒤, 루틴을 설정해 자동화하라.”

“It’s like onboarding an employee… you would have to train a new employee before you let them be autonomous.”
“직원을 온보딩하는 것과 같다. 자율적으로 일하게 하기 전에 새 직원을 훈련해야 한다.”

핵심 데이터 & 수치

• 14가지 봇: 제목이 Peng Zheng과 Lauren Tan이 사용하는 14가지 최고의 봇 사례를 소개한다는 구성이다.
• 약 45분: 전체 대화 길이는 약 45분이다.
• 첫 5%: Peng Zheng은 핵심 시스템과 프레임 하나를 직접 만든 뒤 봇에게 나머지 전체 플로우를 확장시킨다.
• 80%: Peter Yang은 봇이 디자인의 첫 80%를 하는지 물었지만, Peng Zheng의 실제 방식은 사람이 첫 5%를 만들고 봇이 확장하는 방식이다.
• 주 5달러: DJI 마이크 판매 글이 관심을 받지 못하면 Facebook Marketplace 가격을 매주 5달러씩 내린다.
• 두 장: 체크인 파이프라인은 장소 사진에서 낮 모드와 밤 모드 두 장의 이미지를 만든다.
• 10분: 루틴을 10분마다 실행하면 에이전트 wake-up이 지나치게 많아져 사용량과 비용이 커질 수 있다.
• 약 30분: Potato 소셜 봇은 X의 멘션을 약 30분마다 확인한다.
• 5명: 같은 버그를 다섯 명이 보고하면 Potato가 반복 신호로 묶어 Lauren Tan에게 전달할 수 있다.
• 3~5개: 일반적인 AI 채팅에서는 사용자가 적극적으로 관리하는 최근 대화가 대략 상위 3~5개로 제한되며, 오래된 대화는 소모되는 경향이 있다.
• 50석·100석: Michelin Kitchen 비유에서 식당은 50석이나 100석 규모의 손님을 받으면서 품질을 유지해야 한다.
• 네 봇: 엔지니어 리드는 연결된 네 엔지니어 봇에 일을 위임하고 직접 구현하지 않도록 설계됐다.
• 복수 구간 출장: Lauren Tan의 출장 경로는 Orange County→Denver→London→Amsterdam→집으로 이어졌다.
• 세 단계: 사람이 직접 조작하는 단계, AI에 프롬프트를 보내는 단계, 시스템·가드레일을 설계해 봇 조직을 자율 운영하는 단계로 업무 방식이 진화한다.

결론 및 시사점

1. 역할·기억·도구를 가진 영속 봇은 단순한 채팅 상대가 아니라 개인용 컴퓨터의 새로운 인터페이스가 된다.
2. 이메일·캘린더·쇼핑·항공권·호텔·소셜 모니터링·디자인·코드 작성처럼 서로 다른 앱의 작업을 하나의 역할 기반 조직으로 묶을 수 있다.
3. 그룹 채팅은 PM·디자이너·개발자 등 여러 관점을 한 장소에 모으고, 개인 DM과 프로젝트 채팅을 분리해 컨텍스트 오염을 줄인다.
4. 봇이 외부 컴퓨터와 가상 머신에서 실제로 작업하고 결과를 검증하게 하면 생성만 하는 에이전트보다 신뢰 가능한 자동화가 된다.
5. 대규모 소프트웨어 작업은 Chief of Staff→엔지니어 리드→전문 엔지니어 봇→Cloud Agent의 계층으로 분해할 수 있다.
6. 품질을 유지하려면 대량생산형 “소프트웨어 공장”보다 평가와 장인정신을 갖춘 “Michelin Kitchen”이 되어야 한다.
7. 개인의 문체·디자인 기준·업무 절차를 mode 스킬로 패키징하면 비원어민의 커뮤니케이션부터 전문 엔지니어링까지 개인화된 자동화가 가능하다.
8. 소셜 봇은 잡음을 대신 읽어 주는 필터이자 제품 사용자와 엔지니어를 연결하는 외부 피드백 루프가 된다.
9. 자율화를 서두르지 말고 관찰→교정→스킬화→원샷 실행→루틴화 순서로 신뢰를 쌓아야 한다.
10. 최종 목표는 사람이 봇을 계속 클릭하는 것이 아니라, 훈련된 봇 조직에 실행을 위임하고 사람은 전략·제품 방향·품질 기준에 집중하는 것이다.

핵심 요약 (20줄)

1. Peng Zheng과 Lauren Tan은 Grokbot을 이름·역할·기억·도구를 가진 영속형 개인용 컴퓨터로 사용한다.

2. Peng Zheng의 Chief of Staff는 어떤 봇이 맡을지 모르는 디지털 업무를 먼저 받아 적절한 봇에 연결한다.

3. 3D 프린팅 필라멘트 구매 봇은 결제와 Notion 재고 데이터베이스 갱신을 한 번에 수행한다.

4. DJI 마이크 판매 봇은 공식 가격, 지역 경쟁가, 과거 문체를 조사하고 상품 게시와 주간 5달러 인하까지 처리한다.

5. 이메일 액션 아이템, 친구에게 보낼 저녁 식사비, 캘린더·회의실 예약도 봇에게 위임할 수 있다.

6. Designer 봇은 Figma MCP와 디자인 스킬을 사용해 프레임·토큰·색상·타이포그래피·간격을 직접 수정한다.

7. Peng Zheng은 핵심 시스템과 프레임의 첫 5%를 만들고 봇에게 전체 엔드투엔드 플로우를 확장시킨다.

8. Writer 봇은 Peng Zheng의 과거 문체를 참조해 Slack과 이메일 초안을 다듬고 인라인 검토를 받는다.

9. PM·디자이너 등 여러 봇은 고양이 울음 번역 앱 아이디어를 그룹 채팅에서 토론하고 서로 다른 관점을 제시한다.

10. 영속 역할은 유지하면서 프로젝트별 채팅을 나누면 재사용 가능한 기억과 단기 업무 컨텍스트를 함께 관리할 수 있다.

11. Podcast 봇은 기사 링크를 오디오로 바꾸고, 체크인 파이프라인은 사진을 낮·밤 이미지로 변환해 웹사이트에 게시한다.

12. Lauren Tan은 Grokbot으로 Omachi Linux 가상 머신을 설치·제어하고 에이전트가 자신의 작업을 실제 환경에서 검증하게 한다.

13. crumb는 하드디스크 용량을 조사해 불필요한 파일을 정리하고, Pstack eval playbook은 여러 모델의 하위 에이전트로 스킬을 평가한다.

14. Dr. Eggbot은 봇을 설계하고 대화 기록을 분석해 새 스킬·새 봇·루틴 개선안을 제안한다.

15. Suki는 Orange County·Denver·London·Amsterdam을 잇는 출장과 호텔을 조사하고 예약 직전 사람의 승인을 받았다.

16. 엔지니어 리드는 직접 코딩하지 않고 작업을 쪼개 네 봇과 Cloud Agent에 위임해 대규모 에이전트 스웜을 만든다.

17. Lauren Tan은 대량생산의 낮은 품질보다 50석·100석 규모에서도 품질을 유지하는 Michelin Kitchen을 지향한다.

18. Potato는 X를 약 30분마다 읽고 반복되는 버그 보고를 모아 소셜의 외부 루프를 엔지니어의 내부 루프로 전달한다.

19. 사람의 업무 방식은 Peng mode·Lauren mode 같은 스킬로 저장되고 Grokbot과 Cursor에서 재사용된다.

20. 단순 작업을 관찰하고 교정한 뒤 스킬과 루틴으로 만들면 봇에 대한 신뢰와 자율성을 단계적으로 확대할 수 있다.