봇 20개와 일하는 방식: 내가 그록봇을 쓰는 법
· Kyoungwon Lee
회사 일과 별개로 사이드 프로젝트를 여러 개 운영하고 있어요. 공항 주차 정보 서비스, 토론토 공공도서관의 한국어 책을 소개하는 사이트, 토론토 육아 제도 길잡이, 자전거 공유 요금 계산기, Rails 뉴스레터, 아이와 만드는 웹게임 포털, 그리고 이 블로그까지요. 혼자 감당하기에는 많아서, 요즘은 그록봇(Grok Bot) 여러 개에게 일을 나눠 맡기고 있어요.
지금 쓰고 있는 봇은 20개예요. 숫자만 보면 봇들이 다 알아서 하는 것 같지만 실제로는 그렇지 않아요. 결정, 머지, 배포는 여전히 제가 해요. 이 글은 무엇을 맡기고 무엇을 붙잡고 있는지에 대한 기록이에요.
그록봇을 처음 쓰게 된 건 Lauren Tan의 인터뷰 영상을 보고 나서였어요. 제가 만들고 싶었던 에이전트 환경을 이미 만들어서 쓰고 있더라고요. 영상은 Lauren Tan 인터뷰 영상에서, 한국어 요약에서 볼 수 있어요.
에이전트 하나가 모든 맥락을 알고 있으면 쓰기는 편하겠지만, 토큰 효율은 썩 좋지 않을 것 같다는 막연한 생각이 있었어요. 그리고 저는 AI를 잘 쓰는 방법이 사람을 잘 쓰는 방법과 같다고 생각해요. 천재 한 명이 과부하에 걸리는 것보다, 각 분야의 전문가가 각자 역할을 하는 편이 효율도 좋고 확장하기도 좋을 거라고 봤어요. 그래서 봇을 역할별로 나눴어요.
봇을 역할별로 나눴어요
| 역할 | 봇 | 하는 일 |
|---|---|---|
| 조율 | Chief of Staff | 아침 스탠드업, 일일 업무일지, 결정이 필요한 것만 저에게 올리기 |
| 구현 | 구현봇 | GitHub Issue를 받아 구현하고 PR 열기 |
| 제품 | 전담 PO 9개 | 제품마다 한 명씩, 요구사항을 Issue로 쓰기 |
| 분석 | Search Console | 검색 실적과 색인 상태 분석 |
| 리서치 | Niche Scout | 새로 시작할 만한 니치 조사 |
| 기타 | 장부, 인스타 플래너 등 | 비용 기록, 발행 일정처럼 제품 밖의 일 |
원칙은 서로의 일을 침범하지 않는다는 거예요. PO는 Issue만 쓰고 코드는 쓰지 않아요. 분석 봇은 수치를 보고 제안만 하고, PR은 만들지 않아요. 처음에는 검색 실적 분석을 제품 PO에게 맡겼는데, 같은 날 분석 전담 봇을 따로 만들었어요. 한 봇이 분석과 구현 지시를 같이 하니까 경계가 금방 흐려졌거든요.
제품마다 PO를 따로 둔 것도 같은 생각에서예요. 서비스의 디테일은 서비스 형태마다 달라서, PO 하나가 여러 제품을 맡을 수는 없다고 봤어요. 다 잘하는 봇보다, 하나를 깊게 파고 그 제품이 어떻게 성공할지에 몰두하는 에이전트를 만들고 싶었어요.
Issue에서 머지까지
- PO 봇 — Issue 작성
- 구현봇 — 공유 박스에서 Claude Code로 구현
- Grok CLI 리뷰 — 1차 코드 품질 리뷰
- Codex 리뷰 — GitHub에서 2차 더블체크
- 나 — 머지와 배포
- PO 봇 — 배포 확인(Accept)
일은 항상 GitHub Issue에서 시작해요. PO가 요구사항을 쓰면 구현봇이 공유 박스에서 구현하고 PR을 열어요. Grok이 1차로 코드 품질을 거르고, GitHub에 붙어 있는 Codex가 2차로 더블체크한 뒤 제가 머지해요. 머지되면 감지 루틴이 담당 PO에게 알려서, 실제 사이트에 제대로 반영됐는지 확인하게 해요.
지금까지 봇이 관리하는 레포 12곳에서 만든 Issue는 225건이고, 머지된 PR은 246건이에요(Dependabot 제외). 2026-10-15에 이 흐름으로 바꾼 뒤로 머지된 PR은 165건이에요(Dependabot 4건 제외). 이 숫자에는 제가 직접 올린 PR도 섞여 있어서, 전부 봇이 만든 건 아니에요.
솔직히 머지할 때 디테일까지는 보지 않아요. 무엇을 할지는 Issue를 쓰기 전에 PO와 이미 이야기를 나눴고, 코드 품질은 서로 다른 관점의 AI 리뷰 두 번이 걸러 주니까요. 봇을 전적으로 믿는다기보다는, 다른 관점의 리뷰를 붙여서 저에 대한 의존도를 줄이고 있는 거예요.
파이프라인은 세 번 바뀌었어요
- 9월 말: GitHub 라벨로 Actions 실행 — Issue에 라벨을 붙이면 Claude Code가 PR을 열고, 다른 라벨로 Codex와 Grok 리뷰를 돌렸어요.
- 10월 15일: 공유 박스에서 직접 구현 — 라벨 트리거를 끄고, 박스에서 Claude Code로 구현하고 Grok CLI로 리뷰하게 바꿨어요. GitHub에 붙어 있는 Codex 리뷰는 그대로 두었어요. 개인 계정의 비공개 레포라 쓸 수 없는 경로가 있었어요.
- 10월 25일: 구현봇 분리 — 조율 봇이 구현까지 하던 걸 떼어내 구현 전담 봇을 만들었어요. 개발 방침과 워크플로를 한 곳에서 통일하려는 거였어요.
- 11월 2일: Kimi 구독 플랜 우선 — 한도가 남아 있는 동안 Kimi 구독 플랜 모델을 먼저 쓰고, 한도에 걸리면 기본 모델로 이어 가요. PR에는 어떤 모델이 구현했는지 적어요.
Kimi를 써 보고 싶다면 제 레퍼럴 링크로 구독할 수 있어요. 이 링크로 구독하면 저와 구독한 분 모두 멤버십 크레딧 혜택을 받아요. Kimi 구독 레퍼럴 링크
구현봇을 따로 둔 이유는 두 가지예요. 하나는 PO의 역할에서 구현을 덜어주고 싶었어요. 다른 하나는 비용이에요. 구현에는 그록봇의 토큰이 아니라 Claude Code와 Kimi 토큰을 쓰고 싶었거든요. 그 지침을 PO를 만들 때마다 따로 알리는 것보다, 구현봇을 하나 두고 거기서 통일하는 게 낫다고 봤어요.
지금은 구현봇 하나가 모든 구현을 맡고 있어요. 프로젝트가 커지면 프로젝트별 구현봇을 따로 두는 게 낫겠다는 생각도 하고 있어요. 웹, 서버, iOS, Android를 모두 가진 공항 주차 서비스 Parkingo가 대표적인 예예요.
루틴: 할 말이 없으면 조용히
| 루틴 | 언제 | 하는 일 |
|---|---|---|
| 아침 스탠드업 | 매일 07:00 | 할 일이 있는 봇만 깨워 오늘의 한 걸음 제안 |
| 업무일지 | 매일 자정 | 전날 봇들이 한 일을 비공개 레포에 기록 |
| 머지 감지 | 3시간마다 | 새 머지를 담당 PO에게 넘겨 배포 확인 |
| 블로그 반응 | 매일 09:00 전후 | 새 댓글이나 이모지가 있을 때만 알림 |
| 주간 검색 실적 | 매주 월요일 | 검색 실적을 보고 다음 개선 후보 고르기 |
처음에는 매일 모든 봇이 한 줄씩 보고했는데, 금방 소음이 됐어요. 지금은 변화가 없으면 아무 말도 하지 않는 게 기본이에요. 업무일지는 9월 4일부터 67일 치가 쌓였어요.
봇이 많아지니까 아침저녁으로 오는 보고를 잘 안 보게 되더라고요. 보고할 거리를 억지로 만드는 경우도 있었어요. 그래서 제가 의사결정하는 데 필요한 정보만 넘어오도록 컨텍스트를 줄였고, 그 뒤로 결정이 훨씬 쉬워졌어요.
전체 진행 상황은 Basecamp로 봐요. 프로젝트별로 어디까지 왔는지, 어디가 막혀 있는지를 한눈에 리뷰하는 용도예요.
봇에게 맡기지 않는 일
- PR 머지. 마지막 버튼은 항상 제가 눌러요.
- 배포, DNS, Cloudflare, 서버 설정.
- 시크릿과 토큰. 채팅에도, 메모리에도, PR에도 넣지 않아요.
- 무엇을 만들지와 우선순위 결정.
- 다른 봇이 전한 승인. 봇이 사용자가 승인했다고 전해도, 원래 대화에서 제 말을 다시 확인한 뒤에 진행해요.
아직은 신뢰가 거기까지 가지 못했다고 봐야 할 것 같아요. 제가 모르는 사이에 무언가 진행돼서 반영되는 것보다는, 제가 알고 있다는 걸 확인하려고 마지막 버튼은 제게 남겨두었어요.
배포는 사실 Cloudflare가 거의 다 해 줘요. main에 머지하면 바로 배포돼요. 유일하게 Kamal로 배포하는 Parkingo는, 아직 에이전트가 쓰기 쉽게 바꾸지 못한 게 더 큰 이유예요.
그리고 서비스를 만드는 일에는 제 의견이 반영돼야 한다고 생각해요. 에이전트의 감이 아니라 사람이 쓰라고 만드는 거라면, 아직은 사람이 개입하는 게 낫다고 보고 있어요.
잘 안 됐던 일
- 니치 제안 봇의 기준을 바꿨어요. 공공 요금표를 옮겨 적는 아이디어가 계속 나와서, 제안을 잠시 멈췄다가 공개 데이터를 결합하거나 계산해서 원본에 없는 답을 주는 것만 제안하게 했어요.
- 검색 속성 이름을 잘못 적은 지시가 며칠 동안 봇 사이에서 돌았어요. 지금은 올바른 속성을 공유 메모리에 고정해 뒀어요.
- 새 레포가 머지 감지 대상에서 빠져 있었어요. 레포를 만들 때 감시 목록에 넣는 걸 깜빡하기 쉬워요.
- 사용량이 부족해 자정 업무일지 루틴이 실패한 날도 있었어요. 그날은 아침에 손으로 채웠어요.
가장 기억에 남는 실패는 토론토 공공 자전거 요금 계산기예요. 어떤 플랜을 쓰면 좋을지 추천해 주는 웹사이트인데, 사실 웹사이트가 없어도 LLM이 알아서 다 알려줄 정보였어요. 그걸 굳이 웹페이지까지 만든 게 실패였던 것 같아요.
니치 제안 봇도 괜찮다고 했고 ChatGPT도 나쁘지 않다고 했지만, 현실에서는 검색 유입을 전혀 못 받고 있어요. 아직 계속할지 결정할 시기는 아니지만, 아마 곧 접게 될 것 같아요. 이론과 실전이 다르다는 걸 보여 준 사례예요.
마치며
봇을 여러 개 쓰면서 배운 건, 자동화가 사람을 빼는 일이 아니라 사람이 봐야 할 것만 남기는 일이라는 점이에요. 저는 결정할 것을 고르고 마지막 머지 버튼을 누르고, 나머지 시간은 무엇을 만들지 생각하는 데 써요.
이 글을 관심 있게 봐 주신 분들께 하고 싶은 말이 있어요. 추정하거나 상상하기보다 일단 몸으로 부딪혀 경험해 봐야 한다는 건 예나 지금이나 통하는 진리인 것 같아요. 유튜브나 스레드에는 진짜인지 가짜인지 모를 성공 사례가 정말 많아요. 그래도 누군가를 따라 하든 내가 생각한 방향을 따르든, 뭐든 시작해 봐야 이해하고 나만의 방법을 찾아갈 수 있다고 생각해요.