Grok Bot(그록봇)으로 봇 팀을 꾸릴 때 핵심은 봇을 많이 만드는 것이 아니라 구조를 갖추는 것입니다. 리더가 말을 거는 창구 봇 하나, 영역별 역할 담당 봇, 일의 상태를 모아 두는 업무 보드, 정해진 시각에 일을 돌리는 루틴, 그리고 발송·게시·삭제를 막아 두는 승인 관문, 이 다섯 가지면 됩니다. 저는 시니어 AX 컨...
Grok Bot(그록봇)으로 봇 팀을 꾸릴 때 핵심은 봇을 많이 만드는 것이 아니라 구조를 갖추는 것입니다. 리더가 말을 거는 창구 봇 하나, 영역별 역할 담당 봇, 일의 상태를 모아 두는 업무 보드, 정해진 시각에 일을 돌리는 루틴, 그리고 발송·게시·삭제를 막아 두는 승인 관문, 이 다섯 가지면 됩니다.
저는 시니어 AX 컨설턴트 찰리초이입니다. 다섯 요소라는 틀은 distort(@distortgeekin)가 공식 가이드들을 묶어 정리한 X 글에서 참고했고, 사실 근거는 모두 SpaceXSI(xAI)의 공식 가이드와 공식 문서에서 직접 확인해 링크를 달았습니다.
왜 봇을 늘리기만 하면 오히려 바빠질까요?
봇이 늘수록 채팅창도 함께 늘어납니다. 그러면 여러 창을 읽는 일이 새로운 업무가 됩니다. 앞서 소개한 X 글의 문제의식이 바로 이것입니다. 그 글은 이렇게 요약합니다.
"A pile of bots is a headcount. A team is a structure." — distort(@distortgeekin), X 글
봇을 쌓아 두면 머릿수일 뿐이고, 팀이 되려면 구조가 있어야 한다는 말입니다.
그러면 봇은 어떤 기준으로 나눠야 할까요? 기준은 '할 일'이 아닙니다. '기억(메모리)이 섞이는가'입니다. SpaceXSI의 PM Kevin Niparko는 가이드에서 봇을 나누는 이유를 세 가지로 듭니다. 누가 무엇을 하는지 알 수 있고(referenceability), 일을 병렬로 처리할 수 있고(parallelism), 메모리의 범위가 나뉜다(scoped memory)는 것입니다. 그는 "Chief of Staff should not be debugging computer-use evals."라고도 말합니다. 비서 역할의 봇이 기술 검증 작업까지 떠안으면 안 된다는 뜻입니다.
SpaceXSI 엔지니어 Lingxi Li도 가이드에서 봇은 한 영역에 집중할 때 가장 잘한다고 말합니다.
정리하면 이렇습니다. 새 작업은 스킬로 추가합니다. 새 영역은 새 봇으로 나눕니다. 스킬은 공식 문서에서 "작업을 하는 방법에 대한 재사용 가능한 지시 모음"으로 정의됩니다.
리더의 봇 팀에는 어떤 다섯 요소가 필요할까요?
1. 창구 봇: 리더는 누구에게 말하면 될까요?
리더가 모든 봇과 일일이 대화하면 안 됩니다. 말을 거는 곳은 한 곳이어야 합니다. Josh Kim의 가이드에서는 Bot Boss가 이 역할을 맡습니다. 그는 이 봇을 유일한 창구("single front door")라고 부릅니다. 다른 봇들의 보고를 모아 전달하는 역할입니다. 프롬프트에는 "hub and spoke EA, not a builder and not an auditor"라고 적었습니다. 직접 만들거나 감사하지 않고 연결만 하는 비서라는 뜻입니다. 발송이나 캘린더 쓰기는 초안을 만든 뒤 승인을 기다립니다.
Niparko의 가이드에서는 Chief of Staff가 캘린더, Slack, 메일을 맡습니다. 팀에서 유일한 만능형이며, 바뀐 게 없으면 조용히 있습니다. 같은 가이드의 교훈도 있습니다. 봇에게 조용히 있다가 주의가 필요할 때만 알리라고 하라는 것입니다.
2. 역할 담당 봇: 몇 개로, 어떻게 나눌까요?
영역별로 나누고, 각 봇은 자기 영역에 집중시킵니다. Li의 사례에는 영역별 엔지니어 봇 5개(iOS, 데스크톱, 인프라, Android, 하네스)가 있습니다. 코드를 쓰지 않는 운영 책임자 봇 Jenny도 있습니다. Niparko의 팀에는 코드를 쓰지 않는 엔지니어링 매니저 봇 Emily가 있습니다. Emily는 일을 쪼개 맡기고, 결과를 목표와 대조합니다.
몇 개가 정답인지는 뒤의 FAQ에서 다루겠습니다.
3. 업무 보드: 일의 상태는 어디에 둘까요?
일의 상태는 채팅창이 아니라 보드에 둡니다. Eric Zakariasson은 글에서 프로젝트마다 채널 하나, 봇 명단, Notion 보드를 둔다고 설명합니다. Notion에는 Projects와 Tasks 두 데이터베이스가 있고, 프로젝트 매니저 봇이 보드를 최신으로 유지합니다. 막힌 봇은 작업을 Blocked로 표시하고 채널에서 사람에게 알립니다. 그는 이 방식을 "실험 중인 패턴"이라고 밝힙니다.
Li의 사례에서는 공용 Notion PR 데이터베이스를 30분마다 점검합니다. 코드 리뷰 지적, 보안 지적, CI 실패, 머지 충돌이 있으면 'Working'으로 되돌립니다. 문제가 없으면 'Ready for Review'로 올립니다. Li는 긴 채팅을 거슬러 읽지 않고도 진행 상황을 훑어볼 수 있게 이 보드를 쓴다고 말합니다.
4. 루틴: 리더가 자는 동안 무엇이 돌아갈까요?
루틴은 공식 문서에서 "한 봇에게 언제 워크플로를 실행할지 알려 주는 것"으로 정의됩니다. 일정이나 이벤트로 시작합니다. 노트북을 닫아도 백그라운드에서 실행됩니다.
예를 들어 Kim의 Intel Scout는 평일 오전 8시와 오후 5시에 브리핑을 합니다. Li의 사례에는 새벽 3시 야간 점검이 있습니다. 죽은 코드 정리, 로딩 속도, 번들 크기를 확인합니다. 매일 새벽 5시에는 Jenny가 모든 봇과 1:1로 플레이북을 검토하고 막힌 일을 확인합니다. Li는 이 덕분에 몇 주가 지나도 복잡한 워크플로를 거의 잊지 않는다고 말합니다. 봇 데일리 미팅이 매우 효과적이라는 팁도 덧붙입니다. 컨텍스트 한계 때문에 매일 반복하는 것이 도움이 된다는 이유입니다.
순서도 공식 문서가 알려 줍니다. 먼저 한 번 손으로 해 봅니다. 안정되면 스킬로 저장합니다. 그다음에 자동화합니다.
5. 승인 관문: 무엇은 꼭 리더가 확인해야 할까요?
공식 문서는 경계를 명시하라고 권합니다. 대상은 메시지 발송, 콘텐츠 게시, 구매와 송금, 삭제와 덮어쓰기, 권한 변경, 운영 환경 변경, 약관 동의입니다. Ask first 규칙은 Allow automatically 규칙보다 우선합니다.
사례도 같은 방향입니다. Kim의 Inbox Manager는 읽기 전용입니다. 본인이 그 순간 "send"를 입력하기 전에는 보내지 않습니다. Niparko도 가이드에서 외부 메일 발송, 구매, 삭제 같은 행동은 지금도 직접 최종 검토한다고 밝힙니다.
찰리초이의 봇 팀은 어떻게 돌아갈까요?
제가 실제로 함께 일하는 봇 팀 가운데 이 글과 관련된 여섯 봇입니다.
| 봇 이름 | 역할 |
|---|---|
| 찰리 | 창구 봇, 품질 검수(QC) |
| 다빛 | OSMU 게시 (유튜브 영상 공개 후 블로그, X, 스레드, 네이버로 교차 게시) |
| 책봇 | 출판 (원고 집필) |
| 영빛 | 영상 제작 |
| 촉빛 | AI 소식 발굴 |
| Researchy | 팩트체크 |
이 팀에는 창구 봇인 찰리가 맡는 '매일 아침 7시 팀 보고 루틴'을 둡니다. 지시문은 이렇습니다.
매일 아침 7시(한국 시간)에 팀 업무 보드를 읽고, 어제 끝난 일·막힌 일·오늘 내가 결정할 일을 다섯 줄로 보고해. 바뀐 게 없으면 보고하지 마. 게시·발송·삭제는 하지 말고 초안까지만 준비해.
일정은 설정의 시간대 기준으로 돌아갑니다. 그래서 한국 시간을 명시했습니다.
운영하며 배운 점이 하나 있습니다. 다른 봇이 만든 결과물은 만든 봇이 스스로 확인하게 두지 않습니다. 예를 들어 영상 자막은 찰리가 검수 기준표로 다시 확인합니다. 기준에 맞지 않으면 반려하고, 고친 버전을 받습니다. 제 경험으로는 만드는 봇과 검수하는 봇을 나눠 두는 편이 품질이 안정적이었습니다.
리더가 꼭 알아야 할 주의점 3가지는 무엇일까요?
- 백그라운드 승인은 약 10분 뒤 만료됩니다. 루틴, 트리거, 다른 봇의 메시지처럼 사용자 없이 시작된 작업의 승인 요청은 약 10분 뒤 만료되고 실행되지 않습니다(Expired). 공식 문서에 나온 내용입니다. 새벽 루틴은 초안까지만 준비하게 하거나, 만료 카드에서 좁은 자동 허용 규칙을 추가하는 방식으로 설계하세요.
- 봇을 나눠도 보안 경계는 아닙니다. 공식 문서에 따르면 모든 봇이 같은 클라우드 컴퓨터를 씁니다. 브라우저 세션, 파일, 명령줄 인증 정보도 공유합니다. 다른 봇이 쓰면 안 되는 자격 증명은 그 컴퓨터에 두지 마세요.
- 루틴 테스트도 실제 작업을 합니다. 공식 문서에 따르면 웹사이트 이동, 파일 변경, 연결된 도구 호출이 실제로 일어날 수 있습니다. 안전한 입력으로 테스트하고, 쓰기 작업은 승인 뒤에 두세요. 또 "모든 새 메시지" 같은 넓은 트리거는 소음과 사용량 소모를 부릅니다. 자주 도는 루틴이나 바쁜 채널의 Slack 트리거는 하루에 일주일치 사용량을 쓸 수도 있습니다. 조건은 좁게 잡으세요.
자주 묻는 질문
봇은 몇 개부터 시작하면 좋을까요?
정답 숫자는 없습니다. 공식 가이드 사례만 봐도 Kim은 업무용 봇 4개를 소개하면서 수십 개의 봇을 조율한다고 말하고, Li는 6개(엔지니어 봇 5개와 Jenny), Niparko는 약 10개로 다양합니다. 그룹 채팅은 봇 2~6개를 골라 만듭니다. 이것은 제 의견입니다. 저는 창구 봇과 역할 담당 봇 2~3개로 시작하기를 권합니다.
스킬과 봇은 어떻게 다른가요?
스킬은 작업 방법을 담은 재사용 가능한 지시 모음입니다. 스킬은 모든 봇에서 쓸 수 있습니다. 다만 앱 연결이나 로그인이 필요할 수 있습니다. 새 작업은 스킬로, 새 영역은 봇으로 나눈다고 기억하시면 됩니다.
노트북을 닫아도 루틴이 돌아가나요?
네, 백그라운드 루틴은 계속 실행됩니다. 다만 오래 자리를 비우면 루틴을 계속 실행할지 물을 수 있고, 응답이 없으면 일시정지될 수 있습니다. 돌아오면 멈춘 루틴이 없는지 확인하세요.
봇끼리 서로 일을 넘길 수 있나요?
네, 비동기 메시지로 넘길 수 있습니다. 받은 봇이 깨어나 처리한 뒤 나중에 답합니다. 단계마다 담당을 하나로 정하기를 권합니다. 여러 봇에 병렬로 넘기면 중복 작업과 소음이 생깁니다.
루틴은 몇 개까지, 얼마나 자주 만들 수 있나요?
봇당 최대 50개입니다. 일정은 최소 5분 간격입니다. 루틴별로 최근 실행 기록 20개가 보관됩니다.
참고 출처
- distort(@distortgeekin), 'Grok Bot: How to Build Your First AI Team (Full Guide)', X, 2026년 10월 10일, https://x.com/distortgeekin/status/2108897917729738810
- Kevin Niparko, Grok Bot for PMs, 2026년 8월 15일
- Lingxi Li, Grok Bot for Engineering, 2026년 9월 10일
- Josh Kim, Grok Bot for Work, 2026년 9월 24일
- Eric Zakariasson, How I run multiple teams of Grok Bots
- 공식 문서: Work with Grok Bot
- 공식 문서: Skills and routines
- 공식 문서: Approvals, security, and privacy
- 공식 도움말: Routines
AI 에이전트와 Grok Bot 소식을 실제 화면으로 정리하는 리서처K 유튜브 채널을 운영하고 있습니다. 이 글이 도움이 되셨다면 구독과 좋아요를 눌러 주세요. 큰 힘이 됩니다.
댓글
댓글 쓰기