Grok Bot 팀의 한 엔지니어는 한 번에 15 개의 클라우드 에이전트를 돌리던 것에서, 200 개 이상을 동시에 실행하는 단계로 넘어갔습니다.
봇 200 개로요? 아닙니다. 단 6 개로 해냈습니다.
각자 하나의 도메인을 전담하는 엔지니어 봇 5 개와, 코드를 단 한 줄도 작성하지 않는 운영(ops) 봇 1 개입니다. 같은 팀의 Lauren Tan 은 한 달 만에 2,000 개 이상의 PR 을 머지했습니다.
대부분의 사람들이 놓치는 부분이 바로 여기입니다. 첫 번째 봇이 잘 돌아가니 두 번째를 추가하고, 다섯 번째, 열 번째까지 늘립니다. 결국 채팅 창 10 개가 생기고, 그 창들을 읽는 새로운 풀타임 일자리가 하나 더 늘어나 버립니다.
봇을 잔뜩 쌓아두는 것은 인원수일 뿐이고, 팀은 구조입니다. 이 가이드는 xAI 직원들이 실제로 자신들의 봇을 운영하는 방식에서 가져온 '구조'입니다.
30 초 요약 버전
- 봇 하나는 직원 한 명을 채용한 것입니다. 팀이 되려면 다섯 가지가 필요합니다: 출입구, 전문가들, 보드, 시계, 그리고 관문.
- 당신은 봇 하나와만 대화합니다. 그 봇이 나머지에게 작업을 분배합니다.
- 각 전문가는 하나의 도메인을 전담하며 고유의 메모리를 유지합니다.
- 작업은 채팅창이 아니라 보드에 존재합니다.
- 루틴은 당신이 잠든 사이에도 작업을 진행시키고, 승인 과정은 무엇이 밖으로 나갈 수 있는지를 결정합니다.
- xAI 의 실제 팀들은 약 6 개의 봇으로 이를 운영합니다. 60 개가 아닙니다.
파트 1. 두 번째 봇을 언제 채용해야 할까
첫 번째 봇이 바빠졌을 때가 아닙니다. 봇은 사람처럼 '바빠지지' 않습니다.
Kevin Niparko 는 SpaceXAI 에서 PM 으로 일하며 완전한 봇 팀을 운영하고 있는데, 그의 가이드에서는 작업을 여러 봇으로 나눌 세 가지 이유를 제시합니다: 참조 가능성("누가 무엇을 하는지 아는 것"), 병렬 처리, 그리고 범위가 지정된 메모리입니다.
세 번째가 진짜 핵심입니다. 그의 말을 빌리자면 이렇습니다:
Chief of Staff 가 computer-use evals 를 디버깅해서는 안 됩니다.
하나의 봇 메모리가 두 가지 직무를 담기 시작할 때 두 번째 봇을 채용하세요.
이름 붙이기 전에 먼저 체감하게 될 겁니다. 인박스 봇이 코드 리뷰어의 말투로 대답하기 시작합니다. 캘린더 설정이 리서치 브리핑에 섞여 들어옵니다. 메시지를 열 때마다 봇에게 "오늘 네 역할은 이것이다"라고 상기시켜야 합니다.
Grok Bot 으로 Grok Bot 을 만드는 Lingxi Li 역시 엔지니어링 관점에서 같은 이야기를 합니다. 봇은 "단일 도메인에 집중할 때 최고의 성능을 발휘한다"고 말이죠.
테스트: 스킬인가, 봇인가?
공식 문서에서는 스킬을 "작업을 수행하는 방법에 대한 재사용 가능한 지침 세트"로 정의하며, 프라이빗 스킬은 모든 봇이 공유하는 하나의 라이브러리입니다.
따라서 새로운 작업은 스킬입니다. 하지만 고유한 메모리를 가진 새로운 도메인은 봇입니다. 해당 도메인을 세 단어 이내로 설명할 수 없다면, 아직 새 봇은 필요 없습니다.
파트 2. 팀을 구성하는 다섯 가지 요소
1. 출입구 (The front door)
당신이 실제로 대화하는 단 하나의 봇입니다. Josh Kim 의 가이드에서는 이를 Bot Boss, 즉 "유일한 출입구"라고 부릅니다. Niparko 는 Chief of Staff 라 부르며 두 문장으로 설명합니다. "유일한 제너럴리스트. 아무 변화가 없으면 침묵한다."
출입구는 라우팅만 합니다. 직접 만들지는 않습니다. Kim 의 프롬프트에도 이렇게 명확히 적혀 있습니다. "너는 허브 앤 스포크(hub and spoke) 방식의 EA 이지, 개발자도 감사관도 아니다."
바로 복사해서 쓸 수 있는 프롬프트입니다:
너는 나의 Chief of Staff 이며 내가 대화하는 유일한 봇이다. 모든 요청을 담당 전문가에게 전달하고, 결과를 취합하여 내가 요구한 내용과 대조한 뒤, 다섯 줄로 보고하라. 아무 변화가 없으면 침묵하라.
2. 전문가들 (The specialists)
Niparko 의 라인업은 다음과 같습니다: Chief of Staff, Emily 라는 이름의 엔지니어링 매니저, 엔지니어 봇 5 개, 데이터 분석가, PM 봇, 그리고 채용 담당자. Li 의 라인업은 서페이스별로 나뉜 엔지니어 봇 5 개(iOS, 데스크톱, 인프라, Android, 하네스)와 운영 총괄 Jenny 입니다.
두 팀의 공통점을 살펴보세요. 직접 실무를 하지 않는 매니저가 있다는 점입니다. Emily 는 업무를 쪼개고 위임한 뒤, 결과물이 목표에 부합하는지 확인합니다. Jenny 는 새로운 봇을 온보딩하고 사후 검토(postmortem)를 주도합니다. 둘 다 코드는 작성하지 않습니다.
첫 팀이라면 전문가 3 명이면 충분합니다. Eric Zakariasson 은 모든 프로젝트 채널의 봇을 최대 6 개로 제한하는데, 이 숫자를 "그냥 임의로 정한 수치"라고 말합니다. 임의적이지만, 정확한 판단입니다.
3. 보드 (The board)
채팅은 흘러가 버립니다. 팀에는 작업 상태가 머무는 단 하나의 공간이 필요합니다.
Li 의 팀은 Notion 의 공유 트래커를 사용합니다. 30 분마다 봇들이 각 PR 의 CI 실패 여부, 리뷰 코멘트, 병합 충돌을 확인합니다. 문제가 있으면 다시 Working 으로 돌아갑니다. 깔끔한 항목은 Ready for Review 로 이동합니다.
Zakariasson 은 Projects 와 Tasks 라는 두 개의 데이터베이스를 운영하며, 프로젝트당 하나의 채널을 둡니다. 막힌 봇은 자신의 태스크를 Blocked 로 표시하고 사람에게 알림을 보냅니다. 나머지 시간 동안 사람은 카드가 움직이는 것을 지켜보기만 하면 됩니다.
모든 가이드를 통틀어 가장 인상적인 문장은 여기서 나옵니다:
흥미로운 점은, 이 위에 무언가를 더 구축할수록 처음에는 사람을 위해 만들어졌던 시스템과 점점 닮아간다는 것입니다.
4. 시계 (The clock)
문서에 따르면 루틴은 "하나의 봇에게 워크플로를 언제 실행할지 알려주는" 기능입니다. 각 봇은 최대 50 개까지 보유할 수 있고, 5 분 간격으로도 실행할 수 있으며, 노트북을 덮어둬도 계속 작동합니다.
Li 의 시계는 이렇습니다. 새벽 3 시에는 야간 감사가 실행됩니다: 데드 코드, 로드 시간, 번들 크기. 새벽 5 시에는 Jenny 가 팀의 모든 봇과 1:1 미팅을 갖고 플레이북을 검토하며 블로커를 수면 위로 끌어올립니다. 그가 밝힌 결과는 이렇습니다. 봇들은 "몇 주가 지나도 복잡한 워크플로를 거의 잊지 않는다"고 합니다.
새벽 5 시 스탠드업은 이 전체 세팅에서 가장 과소평가된 아이디어입니다. 봇의 컨텍스트는 제한적입니다. 반복이야말로 팀이 기준을 유지하는 방법인데, 여기서는 봇이 그 반복을 대신해주니 사람이 직접 할 필요가 없습니다.
5. 관문 (The gate)
여전히 사람의 손길이 필요한 부분에 대해 Niparko 는 이렇게 말합니다:
외부 이메일 발송, 구매, 삭제와 같은 파괴적 작업에 대해서는 여전히 제가 최종 검토를 맡고 있습니다.
Kim 은 한 발 더 나아갑니다. 인박스 봇은 읽기 전용이며, 그 순간 "send"라는 단어를 직접 입력하기 전까지는 절대 아무것도 보내지 않습니다.
관문을 설계하는 방식을 완전히 바꿔놓는 문서 속 두 가지 사실:
- 백그라운드 승인은 만료됩니다. 루틴이나 다른 봇이 당신의 승인이 필요한 작업을 트리거하면, 약 10 분 후 요청이 소멸되어 작업이 실행되지 않습니다. 새벽 3 시 작업이 당신을 기다리다 보면 그대로 죽어버립니다. 미리 결정하세요: 허용 규칙을 작성해 두거나, 루틴이 초안(draft) 단계에서 멈추도록 설정해야 합니다.
- 모든 봇은 하나의 클라우드 컴퓨터를 공유합니다. 파일, 브라우저 세션, 로그인 정보는 팀 전체에서 접근 가능합니다. 문서에서도 명시합니다: 개별 봇을 보안 경계로 취급하지 마세요.
봇을 나누는 이유는 집중력과 메모리 때문입니다. 안전성은 관문이 보장합니다.
파트 3. 5 일 만에 구축하기
1 일 차. 출입구. 위의 프롬프트를 사용해 첫 번째 봇을 Chief of Staff 로 승격시키세요. 이제부터 당신이 여는 채팅창은 이것뿐입니다.
2 일 차. 메모리 기준으로 분리하기. 현재 봇 하나가 하고 있는 모든 일을 나열하고 도메인별로 그룹화하세요. 가장 큰 두 그룹이 첫 번째 전문가 두 명이 됩니다. 봇 설정은 Name, Title, Description 세 가지 필드입니다. 채용 공고 쓰듯 채워 넣으세요.
3 일 차. 보드. Task, Owner, Status(Todo, Working, Blocked, Ready for Review, Done) 열이 있는 테이블 하나를 만드세요. 그런 다음 모든 봇에게 똑같이 지시합니다: 보드에 기록되기 전까지는 완료된 것이 아니며, 막히면 Blocked 로 설정하고 나에게 알림을 보내라.
4 일 차. 시계. 세 가지 루틴으로 시작하세요: Chief of Staff 가 제공하는 모닝 보드, 30 분 단위 보드 점검, 그리고 야간 감사 1 개. 각각 안전한 입력값으로 먼저 테스트해 보세요. 문서는 테스트 실행도 "실제 작업을 수행한다"고 경고합니다.
5 일 차. 관문. 먼저 물어보게 할 규칙을 작성하세요: 발송, 구매, 삭제, 게시, 프로덕션 환경에서의 모든 작업. 그리고 이미 연속 5 번 승인했던 작업에 대해서는 허용 규칙을 하나 추가하세요.
그런 다음 네 번째 봇을 채용하기 전까지 일주일간 손을 떼고 지켜보세요.
봇 팀을 망치는 다섯 가지 실수
클론 군단. 같은 제너럴리스트를 5 개 복제해 두는 것. 범위가 지정된 메모리도, 도메인도, 얻는 것도 없습니다. 비용만 곱절로 늘리고 혼란은 그대로 유지한 셈입니다.
보드 없는 단체 채팅방. 봇들은 서로 메시지를 보내고 트리거할 수 있습니다. 하지만 공유된 상태(보드)가 없다면 그것은 업무가 아니라 회의일 뿐입니다.
직접 뛰어드는 보스. 출입구가 역할을 맡아 직접 작업을 시작하는 경우. Chief of Staff 가 코드를 작성하는 순간, 라우팅도 검증도 사라집니다.
열린 리스너. 새 메시지가 올 때마다 트리거가 걸리는 구조. 노이즈를 만들고 사용량을 낭비하기 때문에 문서에서도 정확히 이 부분을 경고합니다. 좁은 범위로 매칭하세요.
보안의 착각. 재무 봇이 리서치 봇의 로그인 내역을 볼 수 없을 거라 믿는 것. 같은 컴퓨터, 같은 세션입니다.
조직도가 곧 제품이다
Grok Bot 을 만든 사람들은 자기 팀을 위해 새로운 아키텍처를 발명하지 않았습니다. 세상에서 가장 오래된 구조를 다시 조립했을 뿐입니다: 매니저, 전문가, 보드, 스탠드업, 그리고 결재.
차이점이 있다면, 이 팀은 새벽 5 시에 스탠드업을 해도 아무도 불평하지 않는다는 것입니다.
출입구부터 시작하세요. 전문가를 하나 추가하세요. 보드가 갖춰지기 전에는 세 번째를 추가하지 마세요.
추신: 아직 첫 번째 봇도 채용하지 않았다면, 제 이전 가이드인 "Grok Bot: How to Hire Your First AI Employee"부터 시작하세요. 여기에 인용된 모든 내용은 xAI 의 공개 Grok Bot 가이드 및 공식 문서에서 가져왔습니다.
