[한글자막] Grok Bot은 매니저, Claude Code는 개발자: AI 에이전트를 함께 쓰는 법

한 줄 핵심

GrokBot 같은 오케스트레이터는 요구사항 정리·우선순위·검증을 맡고, Claude Code 같은 코딩 에이전트는 실제 구현을 맡기며, 강한 테스트·권한 분리·보안 규칙이 있어야 이 워크플로가 안정적으로 굴러간다.

시간별 요약

0:00
소개 영상은 여러 AI 에이전트를 함께 써서 소프트웨어 작업을 분업하는 방식, 특히 관리자 역할의 봇과 실제 코딩을 수행하는 에이전트를 어떻게 나눌지에 초점을 둔다.
0:21
봇은 매니저, 코딩은 에이전트 GrokBot은 Slack, email, X, linear 같은 여러 채널에서 의도를 수집하고 작업 상태를 관리하는 매니저 역할에 적합하며, 실제 코드 작성은 Claude code, Codex, Crusher 같은 코딩 에이전트에 넘기는 구성이 효율적이다. 작업을 분리하면 각 에이전트가 자기 컴퓨터와 컨텍스트, 종료 장치를 가지게 되어 비용과 격리 측면에서도 유리하다.
2:55
로런의 다섯 단계 작업 루프 Slack 피드백을 받아 Linear 티켓으로 만들고, Cursor Cloud agent가 버그를 재현한 뒤 fix and fuzz pull request로 검증하며, 문제가 없으면 Slack 알림 후 자동 병합하는 일상 루프가 소개된다. 다만 결제처럼 영향 범위가 큰 작업은 자동 병합하지 않고 반드시 사람 검토를 넣어야 한다.
4:48
신뢰를 쌓는 역피라미드 에이전트를 늘리기 전에 먼저 코드베이스, 정적 분석, 규칙 파일, 인간 리뷰 순서로 신뢰 기반을 쌓아야 하며, 특히 같은 실수를 반복하면 코드가 아니라 lint rule 같은 결정적 규칙으로 고쳐야 한다. 하단의 인간 리뷰에만 의존하는 방식은 확장성이 낮고, 위쪽의 자동화와 규칙이 먼저 안정돼야 대규모 에이전트 운영이 가능하다.
6:09
사람의 리뷰와 검증 투자 Anthropic 사례처럼 검토를 없앤 것이 아니라 검토의 상당 부분을 머신이 읽는 쪽으로 옮겨도, 초기에 검증 체계를 만드는 데 많은 투자와 시간이 필요하다. 실제로는 몇 주 동안 새 제품 개발을 멈추고 검증을 구축해야 할 수 있지만, 그만큼 pull request의 품질과 병합 성과가 좋아진다.
7:00
한 대화창에서 여러 봇 관리 봇을 50개처럼 과도하게 늘리기보다 Chief처럼 한 대화창에서 위임과 조정을 담당하는 중심 에이전트를 두고, 각 봇은 좁은 권한만 갖게 하는 편이 운영 부담이 적다. 또한 Rockbot은 Slack, Mac, VPS, 문서 소스까지 연결해 여러 기기와 에이전트를 조율하지만, 저장되는 기억과 스킬이 보이지 않는 점은 신뢰 측면에서 더 투명성이 필요하다.
9:27
백로그와 변경 영향 범위 Slack과 대화에서 나온 항목은 Notion 같은 백로그로 모으고, RICE scoring과 blast radius 점수로 우선순위를 정하면 작은 작업보다 영향이 큰 작업이 위로 올라온다. 다만 개선을 자동으로 많이 수집할수록 토큰 소모와 백로그 팽창이 커지므로, AI가 제안하는 항목을 무조건 늘리기보다 선별 기준을 둬야 한다.
10:53
보안과 첫 번째 운영 규칙 에이전트에게 자율성을 줄수록 환경 차원의 통제가 중요하며, 같은 cloud computer를 공유하면 파일·브라우저 세션·CLI 자격 증명이 함께 노출될 수 있어 위험하다. 따라서 샌드박스, 범위가 제한된 자격 증명, 읽기 전용 권한, pull request까지만 허용하는 규칙부터 시작하고, 한 번의 루프로 acceptance test를 붙여 코드를 넘기며, 실패하면 lint rule과 규칙 파일로 점점 아래층에 고정해야 한다.

실무 인사이트

초기에는 에이전트 수를 늘리는 것보다, 한 개의 루프를 정해 코드 작성·검증·병합 기준을 먼저 표준화하는 것이 성공 확률이 높다.
에이전트 운영의 핵심은 프롬프트보다 권한 설계와 검증 체계이며, 같은 실수를 반복하면 사람이 고치기보다 규칙으로 승격하는 편이 장기적으로 효율적이다.
변경 영향 범위와 검토 수준을 미리 분류하면 자동화 가능한 작업과 반드시 사람이 개입해야 하는 작업을 분리할 수 있다.