이 영상은 그록봇을 직접 코드를 작성하는 개발자가 아니라, 작업을 계획하고 코딩 에이전트를 관리하며 결과를 검증하는 관리자로 활용하는 방법을 소개한다. 핵심은 에이전트 수를 늘리는 것보다 먼저 자동 검사, 위험도별 검토, 접근 권한 제한을 갖춰 결과를 신뢰할 수 있는 환경을 만드는 것이다. 발표자는 로런 탄의 사례와 자신의 설정을 보여주면서, 작은 작업 흐름 하나부터 시작하라고 권한다.

1. 왜 그록봇을 관리자로 쓰는가

발표자는 pstack 제작자이자 그록봇과 커서의 엔지니어인 로런 탄이 그록봇으로 에이전트들을 관리하며 매달 수천 건의 풀 리퀘스트를 처리한다고 소개한다. 풀 리퀘스트(PR)는 코드 변경 사항을 기존 프로젝트에 반영하기 전에 제안하고 검토하는 단위다.

다만 로런은 해당 도구들을 알리는 역할을 맡고 있으므로, 사례를 볼 때 그 점을 감안해야 한다고 짚는다. 또 T3 Code를 만든 개발자 유튜버 테오도 그록봇과 직접 관련이 없음에도 비슷하게 에이전트들을 관리하는 모습을 보여줬다고 덧붙인다.

발표자 역시 여러 도구와 에이전트를 시험한 끝에, 단순하게 쓸 수 있다는 이유로 그록봇을 계속 사용하게 됐다고 말한다. 사업의 여러 업무에 활용하면서 기존 업무 흐름도 상당 부분 대체했고, 최근 몇 주 동안은 클로드 코드와 커서를 활용하는 자신의 소프트웨어 개발 체계를 조율하는 역할도 맡겼다.

다만 로런의 규모를 그대로 따라 하기는 어렵다. 발표자에 따르면 로런은 월 2,000건이 넘는 PR을 처리하고 사실상 매우 넉넉한 토큰 예산을 사용한다. 그럼에도 그의 접근법은 일반 개발자가 받아들일 수 있는 아이디어와 기술의 향방을 보여준다는 것이다.

2. 계획과 검증은 봇에게, 코딩은 전문 에이전트에게

발표자가 제안하는 역할 분담은 명확하다.

"여기서 여러분의 봇은 코더가 아니라 관리자입니다."

그록봇이 특히 유용한 곳은 작업의 시작과 끝이다. 시작 단계에서는 무엇을 만들어야 하는지, 즉 개발의 목적과 요구사항을 파악한다. 슬랙, 이메일, X, 리니어 같은 여러 채널을 연결해 대화와 문제 제기를 살피면, 다음에 만들 기능과 해결할 문제의 맥락을 모을 수 있다.

마지막 단계에서는 작업 결과를 확인하고, 진행 상황을 보고하며, 할 일 목록을 관리한다. 그 사이의 실제 코딩은 클로드 코드, 코덱스, 커서 같은 코딩 에이전트에 맡긴다. 그록봇은 계획을 세워 작업을 전달하고, 결과가 돌아오면 확인한 뒤 사용자에게 알려주는 식이다.

로런이 소개한 방법처럼 팀용 엔지니어 봇을 슬랙에 연결해 두고, 코딩 작업이 필요할 때 태그하는 방식도 가능하다. 발표자는 자신이 살펴본 스트라이프 등의 기업도 슬랙을 에이전트 관리 창구로 사용한다고 설명한다.

"그록봇이 계획하고 작업을 넘깁니다. 작업이 돌아오면 결과를 확인하고 무슨 일이 있었는지 알려줄 수 있죠."

반드시 그록봇을 써야 하는 것은 아니다. 직접 만든 에이전트나 다른 프로젝트 도구를 조율자로 사용해도 같은 원칙을 적용할 수 있다.

발표자가 실제 코딩을 클로드 코드 구독이나 커서 클라우드 에이전트에 맡기는 이유에는 비용도 있다. 영상에서 설명하는 그록봇의 사용량은 그록과 커서가 공유하는 주간 사용량에 속하므로, 모든 코딩을 그록에 맡기면 크레딧이나 할당량이 빨리 소진될 수 있다는 것이다.

작업을 분리하면 격리에도 도움이 된다. 각 에이전트가 별도의 컴퓨터와 작업 맥락, 중단 수단을 가질 수 있기 때문이다. 발표자는 맥의 로컬 컨테이너와 VPS에 각각 환경을 구성해 그록봇과 연결했다고 한다.

3. 스폰서 소개: Neon Realtime

이어지는 부분은 Neon의 유료 스폰서 소개다. 발표자는 자신이 에이전트로 만드는 프로젝트 대부분에 Neon 데이터베이스를 사용한다며, 새 기능인 Neon Realtime을 소개한다.

채팅 메시지, 알림 숫자, 동료의 문서 수정처럼 화면이 실시간으로 바뀌는 기능은 보통 별도 시스템을 구축해야 해서 복잡할 수 있다. 발표자의 설명에 따르면 Neon Realtime은 데이터베이스가 이런 갱신을 처리하도록 해, 예를 들어 읽지 않은 메시지를 한 번 조회한 뒤에는 결과가 자동으로 업데이트되게 한다.

에이전트 작업의 진행 상황을 실시간으로 보여주는 데에도 활용할 수 있으며, 영상 설명의 링크에서 무료로 사용해 볼 수 있다고 안내한다.

4. 로런의 일상: 피드백에서 자동 병합까지

로런이 운영하는 일상적인 작업 흐름은 피드백 수집부터 수정과 검증까지 다섯 단계로 이어진다.

1. 앱에 관한 피드백이 올라오는 슬랙 채널을 지켜본다.
2. 그록봇이 문제를 발견하면 리니어에 티켓을 만든다.
3. 리니어나 지라의 티켓을 계기로 커서 클라우드 에이전트가 실행되고, 자기 환경에서 문제를 재현한다.
4. 에이전트가 버그를 수정하고, 여러 에이전트가 함께 검증하는 '픽스 앤 퍼즈(fix and fuzz)' PR을 만든다.
5. 퍼징 검사가 문제없이 끝나면 로런에게 슬랙으로 알리고, 별도 수정 요청이 없을 경우 한 시간 뒤 자동 병합한다.

여기서 퍼징은 수정된 기능을 여러 방식으로 사용해 보며 문제를 찾아내는 과정이다. 에이전트들이 무작위로 클릭하거나 Playwright 같은 도구로 실제 사용자처럼 조작하면서, 수정한 부분이 깨지지 않는지 확인한다.

"에이전트 팀이 풀 리퀘스트를 열고, 그것을 망가뜨리거나 오류를 찾아내려고 시도합니다."

발표자는 이 방식을 모든 변경 사항에 똑같이 적용해서는 안 된다고 강조한다. 변경이 잘못됐을 때 피해가 퍼지는 범위인 블라스트 레이디어스를 기준으로 위험도를 나눠야 한다는 것이다. 작은 버그 수정은 자동 병합할 수 있어도, 거래처럼 중요한 부분은 사람이 개입해 검토해야 한다.

로런은 이런 체계를 '소프트웨어 공장'보다 미슐랭 레스토랑의 주방에 비유하는 것을 선호한다고 한다. 개발자는 모든 요리를 직접 만들지 않더라도, 팀의 작업을 이끄는 총괄 셰프처럼 최종 결과에 책임을 진다는 뜻이다.

"팀이 요리하더라도, 모든 접시에는 여러분의 이름이 걸려 있습니다."

5. 에이전트를 믿기 위한 네 층의 검증 체계

발표자는 에이전트를 많이 돌리는 기업들이 단순히 에이전트 수만 늘린 것이 아니라, 그 전에 신뢰할 수 있는 기반과 검증 체계를 쌓았다고 설명한다.

"에이전트 하나도 믿을 수 없다면, 50개는 어떻게 관리하겠습니까?"

로런이 제시한 '역피라미드'는 네 층으로 구성되며, 위쪽의 기반에 더 많은 노력을 투자하는 방식이다.

1. 코드베이스: 구조를 잘 잡고, 타입을 엄격하게 사용하며, 구성 요소 사이의 경계를 명확하게 만든다. 에이전트가 기존 코드를 복사하거나 가장 쉬운 경로를 택하는 경향을 고려해, 쉬운 방법이 곧 올바른 방법이 되도록 설계한다.
2. 자동 검사: 린트 규칙, 테스트, 지속적 통합(CI)처럼 일정한 기준으로 결과를 확인하는 기존 도구를 활용한다. 에이전트가 같은 실수를 반복하면 사람이 매번 고치는 대신 자동 검사 규칙으로 만든다.
3. 문서로 된 지침: AGENTS.md, CLAUDE.md 같은 규칙 파일과 스킬, 버그 검토 봇, 보안 봇을 활용한다. 발표자는 관련 자료로 클라우드플레어 보안 스킬 영상도 추천한다.
4. 사람의 리뷰: 여전히 필요하지만, 가장 확장하기 어려운 단계이므로 여기에만 의존하지 않는다.

"에이전트는 기존 것을 복사하고 가장 짧은 길을 택하는 걸 좋아합니다. 그러니 쉬운 방법이 올바른 방법이 되게 만드세요."

발표자는 앤트로픽에서도 비슷한 변화를 관찰했다고 소개한다. 영상에서 인용한 자료에 따르면 6월부터 9월까지 클로드 코드의 병합 PR은 두 배 이상 증가했고, 되돌려야 했던 비율은 40% 이상 감소했다. 발표자가 강조하는 요점은 리뷰가 사라진 것이 아니라, 리뷰 작업의 상당 부분을 기계에 맡기도록 바뀌었다는 것이다.

이 수준의 신뢰를 얻으려면 선행 투자가 필요하다. 발표자는 세 명의 팀을 운영하는 앨런 웰스의 사례도 소개한다. 이 팀은 사람의 코드 리뷰 없이 PR을 배포하는 체계를 만들기 위해, 약 6주 동안 신규 제품 개발을 멈추고 검증 절차 구축에 집중했다고 한다.

6. 발표자의 설정: 대화는 치프와, 작업은 여러 봇에게

발표자는 회사 업무별로 봇을 나누되, 관리해야 할 봇을 50개씩 만들지는 않으려 한다고 말한다. 사용자가 주로 대화하는 봇은 치프(Chief) 하나이고, 치프가 뒤에서 다른 전문 봇들에게 일을 나눠 준다. 필요하면 봇들이 서로 대화하는 그룹 채팅도 만들 수 있다.

각 봇에는 연결할 수 있는 대상에 제한을 두어, 다른 사람과 공유할 때도 권한을 좁게 유지하려고 한다. 다만 그록봇의 자격 증명 보관함, 메모리, 스킬이 어떻게 관리되는지 충분히 들여다볼 수 없다는 점은 우려한다.

"무슨 메모리가 쌓이고 어떤 스킬이 있는지, 내 보관함이 어떻게 관리되는지 볼 수 없다는 점은 아쉽습니다."

발표자는 편리함을 누리면서도 장기적으로 신뢰하려면 더 많은 투명성과 증거가 필요하다고 말한다. 현재는 가능성을 시험하고 시청자와 결과를 공유하기 위해 위험을 감수하고 있다는 입장이다.

예를 들어 마케팅 사이트를 수정할 때는 치프에게 요청하고, 치프가 조건에 따라 커서 클라우드 에이전트나 맥에서 실행되는 클로드 코드 인스턴스를 시작하게 한다. VPS도 연결해 두었다. 어떤 조건에서 어떤 에이전트를 쓰고, 클로드 코드에는 어떤 기본 모델을 사용할지 지정하면 그록봇이 이를 스킬로 저장하는 것처럼 작동한다고 설명한다.

다만 그 스킬이 정확히 어디에 저장돼 있는지는 볼 수 없다고 한다. 이런 불투명함이 불편하다면 같은 역할의 에이전트를 직접 구성할 수도 있다.

그록봇의 장점으로는 휴대전화, 맥 데스크톱, 다른 PC에서 쉽게 접근하고 작업을 조율할 수 있다는 점을 꼽는다. 비슷한 연결은 Tailscale 같은 도구로도 구현할 수 있다. 각 폴더와 실행 환경에는 별도의 보안 권한과 규칙을 두고, 필요하면 그록봇이 선택한 모델로 클로드 코드를 화면 조작 없이 실행하는 헤드리스 모드를 사용한다.

또 그록봇은 슬랙과 문서에 연결돼 있으므로, 하위 에이전트가 질문에 막혔을 때 발표자 대신 일부 답을 찾아 작업을 이어갈 수 있다. 발표자는 테오 역시 T3 Code로 여러 기기를 그록봇에서 제어하는 비슷한 흐름을 실험 중이지만, 아직 초기 단계라고 소개한다.

7. 백로그를 우선순위와 위험도로 정리하기

치프가 슬랙과 대화에서 모은 정보는 발표자의 백로그, 즉 앞으로 처리할 일의 목록으로 들어간다. 발표자는 이를 Notion에 저장하지만, 리니어나 지라를 사용해도 된다고 설명한다.

우선순위는 RICE 점수로 정한다. 각 작업이 얼마나 많은 사람에게 영향을 주는지인 도달 범위, 효과, 추정에 대한 확신, 필요한 노력의 네 요소를 살피는 방식이다. 여기에 변경이 잘못됐을 때의 피해 범위인 블라스트 레이디어스 점수도 추가한다.

이렇게 하면 예를 들어 작은 노력으로 많은 사람에게 도움이 되는 작업을 더 우선할 수 있다. 봇에게 다음에 할 일을 능동적으로 제안하라고 요청할 수도 있다. 다만 발표자는 제안 자체가 목적이 되면 불필요한 일로 백로그가 빠르게 채워질 수 있다고 주의를 준다.

로런도 슬랙의 버그 보고와 X의 불만을 수집해 장기적인 개선 작업 흐름에 넣는다. 그러나 이런 수집 루틴을 너무 자주 실행하면 토큰이 많이 든다. 자원이 넉넉한 사람에게는 가능해도, 개인이 매시간 실행하는 것은 비용을 고려해야 한다는 것이다.

발표자는 각 변경의 위험도에 따라 사람이 검토할지, 어느 수준의 AI 리뷰를 적용할지, Playwright 테스트와 보안 테스트를 얼마나 할지 정하도록 에이전트에 지시한다.

8. 공유 환경의 보안을 잠그고 작은 루프부터 시작하기

발표자는 그록봇의 여러 봇이 하나의 클라우드 컴퓨터를 공유할 수 있다는 점을 강조한다. 이 환경에는 파일, 브라우저 로그인 세션, 명령줄 자격 증명이 들어갈 수 있다. 따라서 그 컴퓨터에서 코딩 도구에 API 키로 로그인하면, 다른 봇들도 그 키를 사용할 수 있다는 것이다.

많은 도구를 연결하고 에이전트에 폭넓은 권한을 주는 것은 강력하지만, 빠르게 움직이다가 결국 자신에게 문제가 돌아올 수 있다고 경고한다. 이어 Docker와 보안 기업들이 발표한 보안 소프트웨어 개발 체계의 참고 설계를 언급하며 이렇게 요약한다.

"에이전트에 더 많은 자율성을 줄수록, 자기 자신을 감시하리라고 믿어서는 안 됩니다. 통제는 실행 환경 안에 있어야 합니다."

실천 방법은 에이전트를 샌드박스 같은 격리된 환경에서 실행하고, 자격 증명을 제한하며, 가능하면 읽기 전용 권한을 주는 것이다. 검증 체계를 충분히 신뢰하기 전에는 에이전트가 PR을 열 수는 있어도 스스로 병합하지는 못하게 하라고 권한다. 그록봇 하나가 보안 문제를 모두 해결해 주는 것은 아니며, 각 코드베이스의 위험도에 따라 사람이 결정해야 한다.

처음 시작하는 사람에게는 수십 개의 에이전트 대신 작업 루프 하나를 만들라고 조언한다. 봇에 넣을 기본 규칙도 제시한다.

"간단한 질문보다 큰 작업은 직접 코딩하지 마세요. 인수 테스트와 함께 코딩 에이전트에 넘기고, 증거를 확인한 뒤 풀 리퀘스트를 열어 보고하세요."

여기서 인수 테스트는 요청한 작업이 완료됐다고 판단할 기준을 확인하는 검사다. 이후 에이전트의 실수를 바로잡을 때마다 해결책을 가능한 한 체계의 앞쪽으로 옮긴다. 먼저 코드 구조로 막을 수 있는지 보고, 그다음 자동 검사 규칙, 지침 파일, 마지막으로 사람의 리뷰에 반영하는 순서다.

9. 마무리와 패트릭 스튜어트를 향한 인사

발표자는 같은 방식의 시스템을 다른 사람들과 구축하고 싶다면 자신의 Switch Dimension 강좌와 커뮤니티를 살펴보라고 안내한다. 이전 영상에서 다룬 콘웨이의 법칙과 하위 에이전트 구성에 관한 내용도 추천한다.

영상 끝에서는 패트릭 스튜어트에 관한 비보를 접했다며 개인적인 추모를 전한다. 어린 시절 스카이 TV에서 《스타 트렉: 더 넥스트 제너레이션》을 보기 위해 집으로 서둘러 돌아가곤 했고, 스튜어트가 연기한 피카드 함장은 좋은 지도자의 모습을 보여줬다고 회상한다. 또한 진 로든베리가 그린 미래 속에서 그가 지적이고 명확하며 강인하고 공정한 인물을 보여줬다고 말한다.

"패트릭, 모든 것에 감사드립니다. 안녕히 가세요."