AI 활용 & 개발 워크플로우 SVIL 그록 봇 Grok Bot xAI 멀티 에이전트 AI 에이전트

그록 봇 활용 4회: 봇 여러 대를 팀으로 — 그리고 게임 에셋 74개를 두 시간에

SVIL - Singularity Visual Intelligence Lab 2026. 08. 15 16 min read

3편까지는 봇 한 대를 다루는 이야기였습니다. 그록 봇의 진짜 특징은 여기서부터입니다. 여러 봇을 한 작업 공간에 모아 서로 주고받게 하는 것. 그리고 이 구조가 무엇을 가능하게 하고 무엇을 위험하게 만드는지, 실제 사례 하나를 절차 단위로 분해해 보겠습니다.

일정한 간격으로 흩어져 떠 있는 여섯 개의 어두운 정육면체, 각각 청록빛 테두리를 두른 모습 — 여러 봇으로 구성된 팀을 표현한 개념 이미지

봇 한 대로는 알 수 없는 것들

봇 하나만 써 보면 이 제품은 "조금 똑똑한 자동화 도구"로 보입니다. 실제로 1편에서 본 특징 대부분은 한 대만으로도 확인됩니다.

그러나 xAI가 계속 '팀원'이라는 단어를 쓰는 이유는 다른 데 있습니다. 여러 대를 붙였을 때 사람이 하던 조율 작업이 사라지는 지점을 겨냥한 설계이기 때문입니다.

왜 여러 대를 쓰는가

이유는 두 가지입니다. 첫째, 한 프로젝트의 서로 다른 부분을 동시에 진행하기 위해서입니다. 둘째, 역할별로 지시와 스킬을 분리해 각 봇을 단순하게 유지하기 위해서입니다.

두 번째가 실무에서 더 중요합니다. 한 봇에게 열 가지 일을 시키면 지시문이 길어지고, 길어질수록 엉뚱한 판단이 늘어납니다.

병렬은 속도가 아니라 구조다

"여러 대를 쓰면 빨라진다"고 생각하기 쉽지만, 실제 이득은 속도만이 아닙니다. 각 봇의 책임 범위가 좁아진다는 점이 더 큽니다.

범위가 좁으면 잘못됐을 때 어디서 틀렸는지 찾기 쉽습니다. 봇 하나가 전부 하는 구조에서는 결과만 보고 원인을 되짚어야 합니다.

칠흑 속에서 나란히 동시에 뻗어 나가는 네 개의 밝은 청록빛 막대 — 여러 봇이 병렬로 일하는 구조를 표현한 개념 이미지

그룹 채팅이 작업 공간이 된다

여러 봇을 묶는 자리가 그룹 채팅입니다. 사람 팀이 채널에서 일하듯, 봇들이 한 채팅방에 모입니다.

이 방이 곧 작업 공간입니다. 사람은 여기서 지시하고, 봇들이 오가는 대화를 지켜보고, 필요한 순간에 끼어듭니다.

봇끼리 맥락을 주고받는다

핵심은 봇들이 서로 메시지를 주고받으며 맥락을 공유한다는 점입니다. A봇이 알아낸 사실을 B봇이 그대로 이어받습니다.

사람 입장에서 달라지는 것은 같은 설명을 여러 번 하지 않아도 된다는 것입니다. 챗봇 여러 개를 각각 쓰던 방식과 가장 크게 갈리는 지점입니다.

네 개의 어두운 정육면체가 둘러싸고 함께 쓰는 넓은 청록빛 영역 — 그룹 채팅이라는 공유 작업 공간을 표현한 개념 이미지

사람이 중간 전달자에서 빠진다

기존 방식에서 사람이 하던 일을 떠올려 보면 차이가 분명합니다. A도구의 결과를 복사해서 B도구에 붙여 넣는 일, 그게 업무 시간의 상당 부분이었습니다.

그 역할이 빠집니다. 대신 사람의 자리는 전달자에서 검수자로 옮겨 갑니다. 일이 줄어드는 게 아니라 성격이 바뀝니다.

대표 봇을 두는 구성

xAI가 예시로 든 형태는 "한 명의 대표 봇이 영역별 전문 봇을 관리"하는 구조입니다.

사람이 큰 일을 대표 봇에게 넘기면, 대표 봇이 쪼개서 배분합니다. 사람은 대표 봇 하나만 상대하면 되므로 인터페이스가 단순해집니다. 다만 얼리 베타에서 이 조율이 얼마나 안정적인지는 검증된 바가 없습니다. 처음에는 사람이 직접 배분하는 편이 예측 가능합니다.

두 개의 어두운 정육면체 사이를 끊임없이 오가는 청록빛 선 — 봇끼리 맥락을 주고받는 모습을 표현한 개념 이미지

전문 봇을 나누는 기준

봇을 어떤 단위로 나눌지가 실무의 첫 결정입니다. 권할 만한 기준은 도구 단위나 작업 성격 단위입니다.

예를 들어 "자료 조사 담당", "초안 작성 담당", "정리·검수 담당"처럼 나누는 식입니다. 반대로 권하지 않는 기준은 중요도 단위입니다. "중요한 일 담당 봇"을 따로 두어도 다음 절에서 볼 이유로 아무 보호가 되지 않습니다.

역할을 나눠도 권한은 안 나뉜다

이 시리즈에서 세 번째로 반복하는 경고입니다. 그만큼 중요합니다.

봇을 역할별로 나누는 것은 정리를 위한 것이지 격리를 위한 것이 아닙니다. 공식 문서가 FAQ와 보안 페이지 두 곳에 똑같이 적어 둔 문장 — "별개의 봇을 보안 경계로 사용하지 마십시오." 이름과 역할을 나눠도 접근 권한은 하나입니다.

아래 넓게 퍼진 세 개의 흐릿한 정육면체 위쪽 높이 자리한 하나의 밝은 청록빛 정육면체 — 대표 봇이 전문 봇을 관리하는 구성을 표현한 개념 이미지

파일을 주고받는 방식

봇들이 결과물을 넘기는 방법은 단순합니다. 같은 파일시스템에 저장하면 됩니다. A봇이 만든 파일을 B봇이 그 자리에서 읽습니다.

업로드·다운로드나 별도 연동이 필요 없습니다. 이것이 다음 절에서 볼 편의의 정체입니다.

같은 컴퓨터라서 가능한 인계

공식 FAQ의 설명을 그대로 옮기면, 봇들이 파일·브라우저 세션·로그인을 공유하기 때문에 서로 작업을 넘겨줄 수 있습니다.

그래서 A봇이 로그인해 둔 서비스를 B봇이 다시 로그인할 필요 없이 씁니다. 멀티 에이전트 제품에서 흔히 골칫거리인 인증 상태 공유 문제가 구조적으로 해결돼 있는 셈입니다.

세 개의 어두운 정육면체가 각각 서로 다른 모양의 청록빛 표식을 지닌 모습 — 역할별로 나눈 전문 봇을 표현한 개념 이미지

같은 컴퓨터라서 생기는 사고

같은 성질이 반대편에서는 위험이 됩니다. A봇에게만 보여주려던 것이 B봇에게도 보입니다.

구체적으로 공유되는 것은 브라우저 쿠키, 로그인 세션, 파일, 명령줄 자격증명입니다. "조사 전용 봇"을 만들어 두어도 그 봇이 결제 페이지에 접근하지 못하리라는 보장이 없습니다. 파일도 마찬가지여서, 한 작업의 중간 산출물이 다른 작업에 섞여 들어갈 수 있습니다.

게임 에셋 74개 사례의 전말

이제 실제 사례입니다. 1인칭 로그라이크 덱빌더를 개발하던 제품 디자이너 대니 리만세타가 그록 봇 베타에서 만든 결과가 널리 회자됐습니다. 약 2시간에 완성 에셋 74개.

숫자만 보면 놀랍지만, 중요한 건 봇이 거친 다섯 단계입니다. 이 순서를 보면 이 도구가 무엇을 잘하는지가 분명해집니다.

하나의 커다란 밝은 청록빛 고리 안에 함께 들어가 있는 여러 어두운 정육면체 — 모든 봇이 같은 컴퓨터를 공유하는 구조를 표현한 개념 이미지

1단계: 코드베이스를 읽어 맥락을 얻는다

봇은 먼저 게임 코드베이스를 읽었습니다. 각 이미지 자리표시자가 무엇을 뜻하는지 — 어떤 카드인지, 어떤 적인지, 어떤 아이템인지 — 를 코드에서 파악한 것입니다.

이 단계가 사례의 핵심입니다. 사람이 74개 자리에 대해 일일이 설명하지 않았습니다. 맥락을 스스로 수집했기 때문에 나머지가 자동화될 수 있었습니다.

2단계: 자리마다 프롬프트를 쓴다

파악한 맥락을 바탕으로 자리마다 다른 프롬프트를 작성했습니다. 같은 프롬프트를 74번 돌린 것이 아닙니다.

이 부분이 단순 배치 처리와 갈리는 지점입니다. 배치는 같은 작업의 반복이지만, 이 작업은 항목마다 내용이 다른 반복이었습니다.

좁은 간격을 두고 나란히 놓인 밝은 청록빛 사각판과 어두운 사각판 — 봇 사이의 작업 인계를 표현한 개념 이미지

3단계: 이미지를 생성한다

생성은 사용자가 직접 만든 아트 생성 웹 도구로 했습니다. 봇이 그 웹 도구를 브라우저로 열어 사람처럼 조작한 것입니다.

1편에서 본 "API 없는 서비스도 쓴다"가 여기서 그대로 작동했습니다. 개인이 만든 도구에 공식 연동이 있을 리 없는데, 화면을 쓰는 방식이라 그게 문제가 되지 않았습니다.

4단계: 잘라내고 투명 배경으로 정리한다

생성된 이미지를 그대로 쓴 것이 아니라 크롭하고 투명 PNG로 정리했습니다. 게임에 넣으려면 배경이 없어야 하기 때문입니다.

이 단계는 파일시스템과 터미널이 있어야 가능합니다. 브라우저만 있는 에이전트로는 여기서 막힙니다. 세 요소가 다 있어야 완결되는 작업의 좋은 예입니다.

빠져나올 리 없던 어두운 정육면체 옆구리로 새어 나오는 하나의 청록빛 선 — 공유 컴퓨터에서 정보가 넘나드는 위험을 표현한 개념 이미지

5단계: 게임에 다시 연결한다

마지막으로 정리된 에셋을 게임 코드에 다시 연결했습니다. 자리표시자를 실제 파일 경로로 바꾸는 작업입니다.

1단계에서 코드베이스를 읽었기 때문에 가능한 마무리입니다. 시작과 끝이 같은 맥락으로 묶여 있는 것이 이 사례가 매끄러웠던 이유입니다.

두 시간이라는 숫자를 어떻게 읽을까

"2시간에 74개"는 생성 속도가 빨랐다는 뜻이 아닙니다. 이미지 생성 자체는 어느 도구로도 빠릅니다.

줄어든 것은 사람이 붙어 있어야 하는 시간입니다. 원래는 자리 확인 → 프롬프트 작성 → 생성 → 정리 → 연결을 74번 반복하며 사람이 계속 개입해야 했습니다. 그 개입이 사라진 것이 실제 성과입니다.

빽빽하게 쌓인 어두운 정육면체 층 전체를 한 번에 훑고 지나가는 청록빛 — 코드베이스를 읽어 맥락을 파악하는 단계를 표현한 개념 이미지

이 사례가 특별했던 조건

다만 그대로 재현되리라 기대하면 곤란합니다. 이 작업에는 유리한 조건 네 가지가 겹쳐 있었습니다.

① 맥락이 코드에 명시적으로 적혀 있었고, ② 판단 기준이 단순했으며(그림이 자리에 맞으면 됨), ③ 틀려도 되돌릴 수 있었고, ④ 결과를 눈으로 즉시 확인할 수 있었습니다. 네 조건 중 하나라도 빠지면 난이도가 급격히 올라갑니다.

xAI가 제시한 다른 용도들

공식 소개가 든 용도는 넓습니다. 영업 아웃리치, 마케팅 캠페인, 온보딩, 오피스 운영, 받은 편지함 정리, 경비 처리, 채용, 버그 재현·수정입니다.

이 목록을 앞의 네 조건에 비춰 보면 선택이 쉬워집니다. 버그 재현과 받은 편지함 정리는 네 조건을 대체로 만족합니다. 반대로 경비 처리와 채용은 되돌리기 어렵거나 판단이 복잡해 초기 대상으로 적절하지 않습니다.

어두운 매끈한 개구부에서 하나씩 길게 이어져 나오는 작은 청록빛 사각형들 — 항목마다 다른 산출물이 연속 생성되는 과정을 표현한 개념 이미지

실제 사례: 콘텐츠 파이프라인에 대입하면

SVIL 연구소처럼 글과 영상을 함께 만드는 환경에 대입해 보겠습니다. 게임 에셋 사례와 구조가 상당히 닮아 있습니다.

원문을 읽어 각 자리에 필요한 것을 파악하고 → 자리마다 다른 지시를 만들고 → 생성하고 → 규격에 맞게 정리하고 → 원래 자리에 연결하는 흐름이기 때문입니다. 다만 여기엔 조건 ④가 걸립니다. 생성물이 규격에 맞는지 판정하는 일이 사람 눈을 요구한다면, 그 단계는 위임 대상에서 빠집니다.

실제 사례: 팀을 나눌 때 흔한 실수

여러 봇을 처음 구성할 때 자주 나오는 실수 셋을 정리합니다.

첫째, 보안을 위해 봇을 나누는 것입니다. 앞에서 본 대로 효과가 없습니다. 둘째, 처음부터 대표 봇에게 전부 맡기는 것입니다. 조율이 어긋나면 어느 단계에서 틀렸는지 추적하기 어렵습니다. 셋째, 봇 수를 먼저 정하는 것입니다. 작업을 쪼갠 결과로 봇 수가 나와야지, 봇 수에 맞춰 작업을 쪼개면 어색한 경계가 생깁니다.

모든 모서리가 깔끔하게 다듬어져 청록빛으로 빛나는 정육면체 — 생성물을 규격에 맞게 정리하는 단계를 표현한 개념 이미지

저시력 사용자에게 병렬 작업이 갖는 의미

여러 봇이 동시에 도는 구조는 저시력 사용자에게 양날입니다. 좋은 쪽은 분명합니다. 화면을 오가는 조작 자체가 사라집니다.

반대로 조심할 점도 생깁니다. 동시에 여러 곳에서 결과가 나오면 확인해야 할 화면도 늘어납니다. 그래서 그룹 채팅에 "작업이 끝나면 무엇을 했는지 한 문단으로 요약해 남겨라"를 공통 지시로 걸어 두시길 권합니다. 화면을 되짚는 대신 텍스트를 읽고 판단할 수 있으면 병렬화의 이득이 실제로 남습니다.

핵심 정리

왜 여러 대인가: 속도보다 책임 범위를 좁히는 것이 본질입니다. 범위가 좁으면 틀린 지점을 찾기 쉽습니다.
협업 방식: 그룹 채팅이 작업 공간이 되고, 봇끼리 메시지로 맥락을 공유합니다. 사람은 전달자에서 검수자로 역할이 바뀝니다.
구성: xAI는 대표 봇이 전문 봇을 관리하는 형태를 예시로 들었습니다. 다만 베타에서는 사람이 직접 배분하는 편이 예측 가능합니다.
공유의 양면: 파일·세션·로그인 공유 덕에 인계가 매끄럽지만, 같은 이유로 격리가 불가능합니다. 봇을 나눠도 권한은 하나입니다.
74개 사례 5단계: 코드베이스 읽기 → 자리별 프롬프트 작성 → 생성 → 크롭·투명 PNG 정리 → 코드에 재연결. 약 2시간. 줄어든 것은 생성 시간이 아니라 사람이 붙어 있어야 하는 시간입니다.
재현 조건 넷: 맥락이 명시적일 것 · 판단 기준이 단순할 것 · 되돌릴 수 있을 것 · 결과를 즉시 확인할 수 있을 것. 하나라도 빠지면 난이도가 급상승합니다.

칠흑을 가득 채우며 빽빽하고 고르게 늘어선 일흔 개의 작은 청록빛 사각형 — 두 시간에 완성된 에셋 74개를 표현한 개념 이미지

참고하실 만한 것

봇을 여러 대 두시기 전에 내 작업을 종이에 단계로 적어 보시길 권합니다. 단계가 자연스럽게 끊기는 지점이 곧 봇의 경계입니다. 봇 수를 먼저 정하고 작업을 끼워 맞추면 반드시 어색해집니다.

그리고 앞에서 본 재현 조건 네 가지를 체크리스트로 써 보세요. 74개 사례가 매끄러웠던 이유가 도구의 성능만은 아니었습니다.

다음 5편에서는 이 시리즈를 닫습니다. 보안·규정 공백·비용을 정면으로 다루고, 정반대 설계를 택한 클로드 코워크와 비교해 어느 쪽을 언제 골라야 하는지 정리하겠습니다.

출처

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/