Grok Bot에게 모든 자동화를 맡겨봤습니다

URL: https://www.youtube.com/watch?v=c80XdvftRD4 날짜: 2026-08-17 채널: 코드팩토리 영상 길이: 15분 54초 자막: 한국어 자동 자막을 기준으로 정리함. ASR 오인식은 문맥에 맞게 보정했으며, Grok Bot·Group Thread·VM·Routine·Teach Task 등 제품 기능명은 원문 의미를 살려 표기함.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Grok Bot의 가장 강력한 기능은 봇 하나의 성능이 아니라 실제 업무의 가장 작은 단위마다 독립 봇을 만들고, Group Thread에서 필요한 봇들을 협업시키는 구조다. 봇별 기억과 권한을 분리하면 정보가 섞이지 않으면서도 한 번의 지시로 여러 봇이 병렬 실행과 핸드오프를 수행할 수 있다.

• 하나의 봇에 여러 캠페인을 넣으면 정보와 리포트가 섞이므로 캠페인별 봇으로 분리해야 한다.
• VM과 로그인된 브라우저 덕분에 API나 MCP가 없는 서비스도 브라우저를 통해 자동화할 수 있다.
• YouTube 협업·계약 검토·리서치·인보이스처럼 역할이 다른 봇을 Group Thread로 묶으면 한 요청 안에서 서로 작업을 넘긴다.
• 각 봇에는 해야 할 일과 하지 말아야 할 범위, 승인 전송 금지 같은 하네스(harness) 규칙을 명확히 넣어야 한다.
• 한국어 품질, 작업 진행 상태 표시, 초기 불안정성, 최소 200달러 수준의 비용은 아직 큰 제약이다.

발표자는 Grok Bot을 출시 직후부터 약 일주일 미만, 실제 집중 사용 기준으로 약 3일 사용했다. Meta 광고, YouTube 협업, 계약서, 인보이스, Airbnb·건물 리서치 등 기존에 GPT·Claude Desktop·LMS에서 돌리던 자동화를 Grok Bot으로 옮기며, 그룹 스레드가 제품의 핵심 사용 방식이라고 평가한다.

1. Grok Bot의 최소 단위는 봇이다

Grok Bot을 잘 쓰려면 봇을 큰 카테고리로 뭉치는 대신, 실제로 수행하는 가장 작은 독립 업무 단위에 맞춰 만들어야 한다.

1.1. 봇과 Group Thread의 관계

1. 봇은 시스템의 최소 단위다

   1. Create New Bot으로 봇을 바로 만들 수 있다.
   2. 봇 하나는 하나의 업무, 하나의 데이터 범위, 하나의 책임을 가진 독립 실행 단위로 설계한다.
   3. 봇들을 묶어 Group Thread를 만들면 독립적인 봇들이 하나의 대화와 작업 흐름 안에서 협업한다.

2. 독립성과 조합을 동시에 확보한다

   1. 봇마다 독립 메모리와 역할을 유지한다.
   2. Group Thread에서는 여러 봇에게 같은 요청을 전달할 수 있다.
   3. 각 봇은 자기 업무에 해당하는 답변만 하고, 필요할 때 다른 봇에게 작업을 넘긴다.
   4. 따라서 정보가 섞이지 않는 분리 환경과 여러 봇을 유기적으로 조합하는 협업 환경을 동시에 얻는다.

1.2. 봇을 카테고리로 묶지 말아야 하는 이유

1. 큰 카테고리 하나에 다 넣는 실수

   1. 처음에는 Meta 계정 하나를 봇에 연결하고 모든 광고 캠페인을 일·주·월 단위로 요약하게 했다.
   2. VM(Virtual Machine)과 로그인 브라우저를 이용하면 API나 MCP로 접근하기 어려운 정보도 가져올 수 있으므로, 한 봇에 많은 업무를 넣기 쉽다.
   3. 하지만 A 캠페인과 B 캠페인이 하나의 봇과 스레드에서 섞이면 리포트와 변경 작업의 범위를 확인하기 어려워진다.

2. 작업물 단위로 쪼개기

   1. A 캠페인용 봇과 B 캠페인용 봇을 별도로 만든다.
   2. 각 봇에 담당 캠페인 ID를 알려 주고, 자기 캠페인만 보도록 범위를 제한한다.
   3. 광고 캠페인은 서로 섞어 분석하거나 변경하지 않는 것이 일반적이므로, 실제 작업 단위와 봇 단위를 일치시키는 편이 안전하다.
   4. 여러 캠페인을 함께 비교할 필요가 있을 때만 두 봇을 Group Thread로 묶는다.

2. Meta 광고 캠페인으로 본 봇 분리

봇별 범위 제한은 정보 정리뿐 아니라 잘못된 캠페인을 읽거나 수정하는 사고를 줄이는 안전장치다.

2.1. 하나의 Meta 봇에서 캠페인별 봇으로

1. 초기 방식

   1. 발표자는 LMS에서 하던 방식처럼 Meta 계정 하나를 봇에 연결했다.
   2. 모든 캠페인을 읽고 일별·주간·월간 리포트를 만들도록 요청했다.
   3. Grok Bot의 Routine 기능을 이용하면 주간·월간 작업을 저장해 반복 실행할 수 있다.

2. 문제와 개선

   1. A와 B 캠페인이 한 봇에 들어오면 어느 캠페인의 데이터인지 확인하기 어렵다.
   2. A 캠페인 봇과 B 캠페인 봇을 만들고 각각의 캠페인 ID만 읽게 했다.
   3. A 봇은 A 캠페인에 대해서만, B 봇은 B 캠페인에 대해서만 답변한다.
   4. 최근 3일 성과를 요청해도 각 봇은 담당 캠페인의 성과만 보고하며, 다른 캠페인은 보지 않겠다고 범위를 확인한다.

2.2. Group Thread에서 독립 봇을 함께 호출하기

1. 태그 호출의 한계

   1. 개별 봇을 따로 열어 같은 작업을 시키는 방식은 번거롭다.
   2. 메시지 안에서 @로 다른 봇을 태그하면 현재 컨텍스트의 일부가 요약되어 전달된다.
   3. 하지만 매번 봇을 태그하는 것도 반복 작업이 된다.

2. Meta A Team 구성

   1. A 캠페인 봇과 B 캠페인 봇을 Meta A Team 같은 Group Thread에 고정한다.
   2. 그룹에 “CP를 개선하려면 어떤 접근이 좋은가”라고 묻는다.
   3. A 봇은 A 캠페인만 분석하고, B 봇은 B 캠페인만 분석한다.
   4. 두 봇의 독립적인 메모리와 답변을 유지하면서도 하나의 질문에 동시에 응답하게 된다.

3. YouTube 협업 팀의 병렬 업무

발표자는 실제 업무를 YouTube 협업에 맞춰 네 가지 봇으로 나누고, Group Thread에서 한 번의 요청으로 협업시키는 과정을 보여 준다.

3.1. 역할별 봇 구성

1. YouTube Collaboration Bot

   1. 이메일을 확인하고 협업 제안과 진행 중인 협업을 찾는다.
   2. 협업 내용을 Notion에 정리하고 새로운 협업을 발표자에게 리포트한다.
   3. 전체 협업 흐름을 관리하는 리더 역할을 한다.

2. YouTube Content Researcher

   1. 발표자가 특정 주제를 던지면 해당 주제를 조사한다.
   2. 조사 결과와 콘텐츠 아이디어를 협업 봇에 전달한다.
   3. 다른 봇이 요청한 자료를 찾아 브리핑 형태로 돌려준다.

3. Contract Reviewer

   1. PDF 계약서를 읽고 발표자에게 불리하거나 분리해 검토해야 할 조항을 찾는다.
   2. 법인명과 계약서 안의 반복적인 입력 항목을 채운다.
   3. 검토 결과를 콘텐츠 리서처와 공유해 콘텐츠 방향이나 협업 판단에 반영하게 한다.

4. Invoice Issuer

   1. 업무가 완료된 뒤 금액과 입금 계좌를 적은 인보이스를 만든다.
   2. 인보이스 이메일 초안을 작성한다.
   3. 발표자가 승인하기 전에는 이메일을 보내지 않는 하네스 규칙을 지킨다.

3.2. 한 문장으로 시작되는 협업

1. 리더가 업무를 분배한다

   1. 발표자가 “다음 YouTube 작업이 무엇인지 확인해 보라”고 Group Thread에 한 번 말한다.
   2. 협업 봇은 이메일을 확인하고 현재 필요한 작업을 파악한다.
   3. 협업 봇은 같은 스레드 안에 Content Researcher가 있다는 사실을 인식하고 리서치 작업을 넘긴다.

2. 동시에 진행되는 독립 작업

   1. Content Researcher는 주제 리서치를 시작하고 결과를 협업 봇에 돌려준다.
   2. Contract Reviewer는 같은 대화에서 계약 PDF를 병렬로 읽고 문제 조항과 주의해야 할 내용을 찾는다.
   3. 계약 검토 결과는 콘텐츠 리서처에게 전달되어 콘텐츠와 협업 조건을 함께 조정한다.
   4. Invoice Issuer는 자기 역할인 인보이스 작성까지만 진행하고 승인 전 발송하지 않는다.

3. 역할 경계가 있는 팀워크

   1. 발표자는 각 봇의 역할과 요구 사항을 미리 명확하게 설정했다.
   2. 봇들은 서로 협업하지만 담당 범위를 넘어 임의로 다른 업무를 수행하지 않는다.
   3. 이 구조가 봇이 각자 만든 하네스와 계약(contract)을 지키며 팀워크를 하는 방식이다.

3.3. 결제 링크 봇으로의 확장

1. 실제 결제 링크가 필요하면 별도의 Payment Link Bot을 추가한다.
2. 이 봇은 Stripe나 Toss Payments의 결제 링크를 생성하고 승인된 이메일에 링크를 넣는다.
3. 콘텐츠 작업이 완료되면 협업 봇이 Notion에 완료 상태를 업데이트한다.
4. Invoice Issuer와 Payment Link Bot이 이어서 인보이스·결제 링크를 준비하지만, 최종 발송은 승인 뒤에만 수행한다.

4. 건물·숙박업 리서치 팀

Group Thread는 광고와 콘텐츠뿐 아니라 여러 부동산 매물을 반복 조사하고 수익성을 계산하는 업무에도 적용된다.

4.1. Airbnb Researcher의 숙박률 조사

1. 리서치 목표

   1. 숙박 매물의 평일·주말 가격과 숙박률(occupancy)을 조사한다.
   2. 매물이 한두 개면 수작업으로 가능하지만 여러 매물을 계속 비교하면 반복 비용이 커진다.
   3. 특정 지역의 평균 가격과 예상 점유율을 구해 실제 점유율별 수익을 예측하는 것이 목표다.

2. 브라우저 기반 범위 설정

   1. Airbnb Researcher 봇에 로그인된 브라우저를 연결한다.
   2. 특정 지역을 지시하면 Guest Favorite·Superhost 기준으로 매물을 찾는다.
   3. 평일·주말 가격과 최근 일정의 예약 상태를 조사하도록 범위를 정한다.
   4. API나 MCP가 없어도 VM 안의 로그인 브라우저를 이용해 필요한 정보를 수집한다.

4.2. Building Brief의 PDF·OCR·스프레드시트 흐름

1. 매물 자료 구조화

   1. 매물 정보가 PDF로 들어오면 Building Brief 봇에 PDF를 넣는다.
   2. OCR로 건물 호가, 면적, 건폐율, 용적률, 연면적, 숙박업에 필요한 용도·허가 관련 정보, 엘리베이터 유무를 추출한다.
   3. 건물을 몇 개의 객실로 나눌 수 있는지, 객실별 면적을 어떻게 구성할지 예측한다.

2. 수익성 계산 연결

   1. 추출한 정보를 스프레드시트에 기록한다.
   2. 스프레드시트는 매물별 계산을 통해 예상 수익률을 산출한다.
   3. 현재 시세와 비교해 해당 건물을 검토할 만한지 판단할 수 있다.
   4. Airbnb Researcher가 가격·숙박률을 넣고 Building Brief가 건물·객실·수익성 계산을 맡는 식으로 역할을 분리한다.

4.3. 여러 건물을 한 번에 분석하기

1. 첫 번째 매물 테스트

   1. 발표자는 Building Team에 새로 추가한 첫 번째 건물을 조사하라고 지시한다.
   2. Airbnb Researcher는 스프레드시트에 매물이 추가된 것을 확인하고 브라우저에서 평일·주말 가격과 숙박률을 조사한다.
   3. Building Brief는 리서치가 끝난 뒤 수익률 계산에 필요한 정보를 처리한다.

2. 전체 매물로 확장

   1. 첫 번째 건물에서 흐름이 작동하는 것을 확인한 뒤 모든 건물을 분석하라고 요청한다.
   2. Airbnb Researcher와 Building Brief가 각자의 역할을 수행하며 여러 건물을 순차·협업 처리한다.
   3. 사용자는 매물마다 두 봇에 반복해서 지시하지 않고 Group Thread에 전체 작업을 맡긴다.

5. 하네스와 Teach Task로 업무를 재현하기

자동화 품질은 봇의 수보다 봇이 할 일과 하지 말아야 할 일을 얼마나 정확하게 정의했는지에 달려 있다.

5.1. 범위와 프로세스를 먼저 고정하기

1. 작은 실제 업무 단위로 만들기

   1. 실무에서 운영하는 가장 작은 단위를 Grok Bot의 봇 단위로 만든다.
   2. “부동산 전체”처럼 넓은 카테고리로 만들지 않고, “특정 지역 Airbnb 숙박률 조사”처럼 구체적인 작업으로 만든다.
   3. 봇마다 접근 가능한 데이터, 출력 형식, 금지 행동을 지정한다.

2. 하네스의 계약

   1. Invoice Issuer가 승인 전 이메일을 보내지 않는 것처럼, 중요한 외부 행동에는 승인 게이트를 둔다.
   2. 캠페인 봇이 다른 캠페인을 읽지 않도록 범위를 제한한다.
   3. 역할을 넘는 행동을 하지 않도록 각 봇의 작업 계약을 설정한다.

5.2. Teach Task로 브라우저 절차 기록하기

1. 작업 절차 녹화

   1. VM에 들어가 상단의 Teach Task 기능을 선택한다.
   2. Airbnb 사이트에 들어가 지역을 검색하고 인원 수를 입력하는 흐름을 직접 수행한다.
   3. Guest Favorite·Superhost 필터를 선택하고 캘린더를 열어 최근 두 달의 예약 상태를 확인하는 과정을 녹화한다.

2. 에이전트의 절차 학습

   1. 녹화한 과정을 봇에게 전달하면 봇이 화면과 클릭 순서를 인식한다.
   2. 이후 같은 업무를 다른 지역이나 다른 매물에 반복 적용한다.
   3. API가 없는 서비스도 사람이 한 번 보여 준 브라우저 절차를 하네스로 만들어 자동화할 수 있다.

3. Group Thread와 결합하기

   1. 개별 봇은 Teach Task로 배운 자기 절차를 수행한다.
   2. 협업이 필요한 봇들을 Group Thread에 묶는다.
   3. 한 번의 요청으로 리서치·OCR·스프레드시트 계산·보고서 생성이 연결된다.

6. 사용량과 비용

6.1. 실제 사용 조건

1. 발표자는 Grok Bot을 약 3일 사용했으며, 일요일에는 버그 때문에 거의 사용하지 못했다.
2. 현재는 약 300달러 모델인 SuperGrok을 사용하고 있어 주간 사용량 제한을 적용받는다.
3. 처음 자동화를 설정할 때는 봇과 대화를 많이 해야 하지만, 구조가 완성되면 필요한 시점이나 루틴에 따라 실행한다.
4. 반복 업무만 맡기는 일반 사용자는 설정 이후 충분히 만족할 수 있을 것이라고 평가한다.

6.2. 비용의 진입 장벽

1. 최소 접근 비용이 약 200달러 수준이라 많은 사람이 시험하기에는 비싸다.
2. 발표자는 약 30달러 수준의 입문 요금제가 있다면 훨씬 많은 사용자가 경험할 수 있을 것이라고 말한다.
3. 자동화의 강력함과 별개로, 비용이 제품 확산을 제한하는 가장 큰 단점이라고 평가한다.

7. Grok Bot의 단점과 리스크

7.1. 한국어 결과물의 품질

1. 대화는 이해 가능하지만 어색하다

   1. Grok은 한국어를 자연스럽게 쓰지 못하고 예전 Claude에서 느꼈던 듯한 어색한 표현이 나온다.
   2. 영어는 상대적으로 큰 불만 없이 사용할 수 있다고 평가한다.
   3. 한국어 대화의 의미를 이해하지 못할 정도는 아니지만 단어 선택과 문장이 다소 어색하다.

2. 아티팩트는 후처리 필요

   1. 실제 문서·리포트·코드·외부 결과물을 만들 때는 한국어 품질을 한 번 더 확인해야 한다.
   2. Codex나 Claude로 결과물을 다시 다듬거나 사람이 직접 수정하는 방식을 권한다.

7.2. 작업 진행 상태를 알기 어렵다

1. 봇에게 일을 시킨 뒤 현재 작업 중인지, 완료했는지, 문제가 발생했는지 바로 알기 어려운 경우가 있다.
2. 사용자가 “아직 진행 중이냐”고 물으면 봇이 진행 중인지, 완료했는지, 오류가 생겼는지 알려 준다.
3. 긴 브라우저 작업과 여러 봇이 참여하는 Group Thread에서는 진행 상태와 다음 핸드오프를 표시하는 기능이 특히 중요하다.

7.3. 초기 제품의 불안정성

1. 일요일에 VM 접근이 되지 않는 문제가 있었다.
2. Routine 생성이 되지 않거나 플러그인에 접근할 수 없는 문제가 몇 시간 동안 발생했다.
3. 출시 직후라서 생긴 중요한 버그로 보이지만, 자동화 서비스는 한 번의 접근 실패가 전체 업무 흐름을 멈출 수 있다.
4. 발표자는 앞으로 개선될 것으로 기대하면서도, 현재 사용자는 VM·Routine·플러그인 접근 실패를 고려해야 한다고 말한다.

7.4. 자동화 권한의 경계

1. 로그인된 브라우저로 API나 MCP가 없는 서비스에 접근할 수 있는 만큼, 계정·개인정보·광고·계약 데이터의 권한 범위를 명확히 해야 한다.
2. 캠페인별 봇, 승인 전 발송 금지, 역할별 하네스는 기능 분리이자 권한 격리 장치다.
3. 봇이 어디까지 읽고, 어디까지 쓰고, 외부에 언제 발송할 수 있는지를 작업 계약으로 기록해야 한다.

주요 발언 모음

“그룹 스레드 기능이 그록봇의 가장 강력한 기능입니다.”

“여러분들이 실제로 업무하는 단위에 가장 작은 단위로 봇을 만드는 게 좋습니다.”

“카테고리로 그냥 묶어 버리지 마세요. 각각 독립적인 작업 단위로 봇을 생성한 다음 그룹으로 묶어 주세요.”

“각자 생성된 하네스 안에서 컨트랙트를 서로 지키면서 팀워크를 해 나가는 상황을 만들 수 있습니다.”

“범위를 정확하게 정해 주세요. 그리고 프로세스를 정해 주세요.”

“한국어로 아티팩트를 만들 때는 Codex나 Claude로 한 번 더 돌리거나 직접 수정하는 게 좋습니다.”

핵심 데이터 & 수치

• 약 일주일 미만: 발표자가 출시 직후부터 Grok Bot을 사용한 기간.
• 약 3일: 영상에서 실제로 집중 사용했다고 설명한 기간.
• 약 300달러 모델: 발표자가 사용하는 SuperGrok 요금 수준.
• 약 200달러: 일반 사용자가 접근하기 어려운 최소 비용 수준으로 언급된 금액.
• 약 30달러: 발표자가 희망하는 입문 요금제 수준.
• 몇 시간: VM·Routine·플러그인 접근 문제가 지속된 시간.
• 여러 매물: Airbnb 가격·숙박률과 건물 수익성을 자동 분석한 리서치 범위.
• 최근 두 달: Teach Task로 캘린더 예약 상태를 확인하는 예시 기간.

결론 및 시사점

1. Grok Bot을 단순한 챗봇으로 사용하지 말고, 실제 업무의 최소 단위마다 봇을 만들고 Group Thread에서 조합해야 한다.
2. 하나의 봇에 여러 캠페인·매물·업무를 넣으면 기억과 권한이 섞이므로, 데이터 범위와 작업 계약을 봇별로 제한해야 한다.
3. Group Thread는 독립 봇의 메모리를 유지하면서 하나의 요청으로 병렬 실행과 핸드오프를 가능하게 한다.
4. YouTube 협업 팀처럼 리서치·계약·인보이스를 분리하면 각 봇이 자기 역할에 집중하고 승인 전 외부 발송을 막을 수 있다.
5. VM과 로그인 브라우저는 API나 MCP가 없는 서비스까지 자동화하는 강력한 수단이지만, 권한·보안·접근 실패를 별도로 관리해야 한다.
6. Teach Task로 사람이 한 번 수행한 브라우저 절차를 기록하면 반복 가능한 하네스로 만들 수 있다.
7. 봇의 역할은 넓게 잡기보다 범위·입력·출력·금지 행동·승인 조건을 구체적으로 지정해야 한다.
8. 제품은 한국어 품질, 진행 상태 표시, 초기 안정성, 높은 최소 요금이라는 단점을 아직 가지고 있다.
9. 자동화가 성숙하면 초기 설정 대화보다 Routine과 Group Thread를 통한 반복 실행이 중심이 된다.
10. Grok Bot의 핵심 가치는 개별 모델의 답변보다, 업무를 작은 봇으로 분해하고 팀처럼 실행하게 만드는 오케스트레이션에 있다.

핵심 요약 (20줄)

1. Grok Bot의 가장 강력한 기능은 여러 봇이 협업하는 Group Thread다.
2. 봇은 시스템의 최소 단위이므로 실제 업무의 가장 작은 독립 작업마다 만들어야 한다.
3. 여러 캠페인을 하나의 봇에 넣으면 데이터와 리포트가 섞이므로 캠페인별 봇으로 분리해야 한다.
4. 각 봇에 캠페인 ID를 지정하면 담당 캠페인 외의 정보에 접근하지 않게 할 수 있다.
5. 독립 봇들을 Group Thread로 묶으면 같은 요청에 각자 자기 범위의 답변을 병렬로 제공한다.
6. YouTube 협업 팀은 협업 관리, 콘텐츠 리서치, 계약 검토, 인보이스 발행 봇으로 구성된다.
7. 협업 봇은 이메일과 Notion을 확인하고 콘텐츠 리서처에게 다음 작업을 넘긴다.
8. 계약 리뷰 봇은 PDF를 병렬로 읽고 문제 조항과 입력이 필요한 정보를 찾는다.
9. 인보이스 봇은 승인 전 이메일을 보내지 않는 하네스 규칙을 지킨다.
10. 결제 링크가 필요하면 Stripe나 Toss Payments를 전담하는 별도 봇을 추가할 수 있다.
11. Airbnb Researcher는 로그인된 VM 브라우저로 지역별 평일·주말 가격과 숙박률을 조사한다.
12. Building Brief는 PDF의 면적·건폐율·용적률·연면적·엘리베이터 정보를 OCR로 추출한다.
13. 추출한 건물 정보는 스프레드시트와 연결되어 객실 수와 예상 수익률 계산에 사용된다.
14. Teach Task로 브라우저 검색·필터·캘린더 확인 과정을 녹화하면 봇이 절차를 반복할 수 있다.
15. 봇의 범위·프로세스·금지 행동·승인 조건을 정확히 정하는 것이 자동화 품질을 결정한다.
16. 발표자는 약 300달러 수준의 SuperGrok을 사용했으며 최소 200달러 비용은 큰 진입 장벽이다.
17. Grok은 영어보다 한국어 결과물이 어색해 문서·코드 아티팩트는 후처리가 필요하다.
18. VM 접근·Routine 생성·플러그인 연결이 몇 시간 중단되는 초기 불안정성이 있었다.
19. 긴 작업에서 현재 진행 중인지 완료됐는지 알기 어려운 것도 중요한 사용성 문제다.
20. Grok Bot의 본질적인 강점은 모델 답변이 아니라 작은 봇과 그룹 스레드로 업무를 오케스트레이션하는 구조다.

관련 자료

• 오늘의 썸네일을 만든 AI 딱테잎: https://youtu.be/6WtHXFG7sQM
• 코드팩토리 통합 링크: https://links.codefactory.ai
• Grok Bot 관련 이전 영상: https://www.youtube.com/watch?v=MzObKXUaSbc