큰 일을 계획하고 여러 에이전트가 병렬 실행한 뒤 독립 검증을 거쳐 통합 보고로 모으는 Grok Build 워크플로

이슈 백로그가 100개를 넘거나, 리뷰할 diff가 수천 줄이면 한 채팅에 일을 다 넣기 어렵다.

처음에는 “한 번에 더 길게 물어보면 되지”라고 생각하기 쉽다. 그런데 대화가 길어질수록 앞 단계 판단이 묻히고, 중간 조사 결과가 최종 결론과 섞이며, 어디까지 끝났는지 사람이 다시 정리하게 된다.

이때 필요한 것은 더 긴 한 번의 대화가 아니라, 큰 일을 나눠 돌리고 마지막에 한 보고로 모으는 실행 방식이다. Grok Build 워크플로(workflow)는 그 방식을 제품 기능으로 묶은 것이다.

읽고 나면 “에이전트를 여러 명 부른다”와 “워크플로를 돌린다”가 어떻게 다른지, 어디에 쓰면 맞는지가 정리된다.

한 줄로 보면 이것이다

한 대화에 안 들어가는 큰 일을 단계로 계획하고, 여러 에이전트를 병렬로 돌린 뒤, 검증을 거쳐 한 보고로 돌려주는 실행 묶음이다.

SpaceXAI(xAI) 공식 발표(2026-07-23) 기준으로 보면, 워크플로는 큰 작업을 여러 에이전트에 나눠 돌리고 결과를 검증한 뒤 배경 실행 한 번으로 보고하는 오케스트레이션 스크립트다. 공식 계정 설명도 같은 그림을 쓴다. 이슈 100개 이상 triage, 수천 줄 상세 리뷰처럼 한 대화가 버티기 어려운 일을 넘기면, 계획하고 병렬로 돌린 뒤 한 보고를 돌려준다.

중요한 점은 “똑똑한 에이전트 한 명”이 아니라 “여러 에이전트를 묶는 실행 단위”라는 점이다.

큰 일 한 덩어리
-> 단계(phase)로 나눔
-> 단계마다 에이전트를 병렬로 돌림
-> 독립 검증으로 소견을 다시 봄
-> 한 보고로 합침

서브에이전트와 병렬 실행 글에서 말한 구분을 그대로 가져오면, 역할 나누기와 동시 실행을 먼저 가르고 본다. 워크플로는 그 위에 단계 계획, 예산, 저장, 통합 보고까지 한 실행 단위로 올린다.

언제 쓰는가

공식 안내는 기준을 단순하게 잡는다. 일이 여러 독립 조각으로 나뉘고, 끝이 한 보고여야 하면 워크플로 후보다.

맞는 예시는 이런 쪽이다.

  • 큰 PR의 기능을 영역별로 나눠 리뷰하고 소견을 하나로 모을 때
  • 최근 이슈 100개를 triage 해서 우선순위 10개 목록을 받을 때
  • 인증 누락 같은 한 종류의 버그를 여러 경로에서 찾고, 각 소견을 다시 검증할 때

맞지 않는 예시도 분명하다.

  • 한 파일 작은 버그 수정
  • 아직 목표 자체가 흔들리는 탐색 대화
  • 사람이 문장마다 방향을 바꿔야 하는 설계 토론

워크플로는 애매한 대화를 대신 정리해 주는 채팅 업그레이드가 아니다. 이미 “독립적으로 나눠 볼 조각”이 보이는 일에 붙일 때 힘이 난다.

안에서 돌아가는 순서

공식 설명의 로컬 작성 가이드를 같이 보면, 흐름은 대략 네 칸이다.

1. 계획: 단계, 단계별 에이전트, 결과 합치는 방식을 잡는다
2. 분산: 각 에이전트는 좁은 문맥에서 자기 일만 본다
3. 검증: 다른 에이전트가 소견을 다시 공격적으로 확인한다
4. 통합: 살아남은 결과만 한 보고로 모은다

여기서 자주 놓치는 칸이 검증이다. 에이전트를 많이 돌리면 소견도 많이 나온다. 그런데 소견 수가 곧 품질은 아니다. 공식 발표도 독립 회의론자(skeptic)가 각 소견을 다시 검증한다고 적고, 로컬 워크플로 작성 가이드도 증거가 없으면 확인된 것으로 보지 말라고 못 박는다.

진행 중에는 /workflows로 단계별 실행을 볼 수 있다. 진행 상태가 저장되므로, 중간에 멈추고 다시 시작할 때 끝난 일을 처음부터 다시 하지 않는다고 공식 문서는 설명한다.

에이전트 예산도 있다. 기본 예산은 128이고, 큰 작업에서는 최대 1,024까지 올린다고 안내된다. 그래서 “수백 개”를 매번 꽉 채운다고 보지 말고, 상한이 그 근처까지 열린다고 보면 된다.

저장하면 반복 실행 단위가 된다

한 번 잘 돈 워크플로는 저장해 둔다.

공식 안내에 따르면 프로젝트 쪽 저장은 팀과 공유되고, 사용자 쪽 저장은 여러 프로젝트에서 따라다닌다. 저장한 워크플로는 인자를 받는 슬래시 명령이 된다. 예를 들어 PR 리뷰 워크플로를 한 번 잡아 두면, 다음엔 번호만 바꿔 다시 돌린다.

기본 사용 경로는 평범한 말로 큰 일을 맡기는 쪽이다. 공식 발표도 Grok이 요청을 보고 워크플로를 작성하고, 실행 전에 smoke-check를 한 뒤 돌린다고 설명한다. 고급 사용에서는 스크립트를 직접 다듬기도 하지만, 처음엔 “저장 가능한 다단계 병렬 실행”으로 보면 된다.

내장 예시로 /deep-research가 있다. 조사 질문을 병렬로 나눠 보고, 주장마다 출처를 다시 확인한 뒤 인용 보고서를 돌려준다. 코딩 리뷰뿐 아니라, 조사가 여러 갈래로 갈라지는 일에도 같은 뼈대를 쓴다.

그냥 여러 에이전트를 부르는 것과 뭐가 다른가

비슷한 말들이 쉽게 섞인다.

  • 서브에이전트: 메인 대화에서 중간 일을 빼 역할만 나눈다.
  • 병렬 실행: 독립 작업을 동시에 돌린다.
  • 워크플로: 단계 계획, 병렬 실행, 검증, 통합 보고, 저장/재실행까지 한 실행 단위로 묶는다.
  • 하네스: 일이 끝났다고 말할 조건, 중단 조건, 검증, 승인을 운영 구조로 고정한다.

하네스 엔지니어링 글에서 말한 여섯 칸(작업, 기준, 검증, 기록, 재시도, 승인)을 떠올리면 자리가 보인다. 워크플로는 그 칸 중 실행과 기록, 재시도에 가까운 도구다. 승인까지 자동화해 주지는 않는다.

그래서 최종 질문 순서는 이렇게 잡는 편이 낫다.

이 일을 독립 조각으로 나눌 수 있는가?
조각마다 성공/실패를 어떻게 확인하는가?
마지막 보고에서 사람이 무엇을 승인하거나 버리는가?

에이전트 수를 먼저 정하지 않는다. 나눌 수 있는 일과 회수할 보고 형식이 먼저다.

과대평가하기 쉬운 지점

발표 직후 반응에는 “AI 팀”, “오케스트레이션 엔진” 같은 큰 말이 붙기 쉽다. 유용한 기능일 수는 있어도, 그 말만 믿고 쓰면 비용과 검증 구멍이 먼저 커진다.

먼저 접근 조건이 있다. 공식 계정 답변 기준으로 워크플로는 SuperGrok과 X Premium+ 구독자 대상으로 열려 있다고 안내된다. 무료 체험과 유료 한도는 바뀔 수 있으므로, 쓰기 전에 현재 안내를 다시 본다.

다음으로 비용이다. 에이전트를 많이 돌리면 토큰 사용량도 커진다. 커뮤니티 반응에서도 “퍼즐은 맞춰졌지만 토큰 소모가 클 수 있다”는 지적이 바로 나왔다. 큰 병렬 실행은 속도 도구인 동시에 비용 도구다.

품질 문제도 남는다. Grok Build 사용자들은 계획 미완료 보고, 수동 개입이 필요한 루프, 검증 없이 끝난 것처럼 보이는 실행을 지적해 왔다. 워크플로에 검증 단계가 있어도 최종 보고서는 항상 맞지 않는다. 코드 변경까지 이어서 적용할 때는 사람이 diff와 테스트로 다시 본다.

마지막으로 “많이 돌리면 더 안전하다”는 착각이다. 검증 없는 병렬 실행은 소견 더미만 키운다. 공식 흐름도 검증과 통합을 전제로 하고, 로컬 작성 가이드는 실패하거나 비어 있는 검증 결과를 긍정 투표로 세지 말라고 한다. 증거가 없으면 확인된 소견이 아니다.

다음에 이렇게 쓰면 된다

큰 일을 에이전트에게 넘기기 전에 아래 네 줄만 적어 본다.

목표 보고: 마지막에 어떤 한 장 보고를 받을 것인가
독립 조각: 서로 기다리지 않고 나눌 단위는 무엇인가
검증 방식: 각 소견을 무엇으로 다시 확인할 것인가
사람 회수: 머지, 배포, 우선순위 결정 중 무엇이 사람 몫인가

네 줄이 안 채워지면 워크플로보다 먼저 목표 정리나 작은 단일 작업이 맞다. 네 줄이 보이면 그때 워크플로 후보로 올린다.

한 문장으로 남기면 이렇다.

워크플로는 에이전트를 많이 부르는 기능이 아니라,
나눈 일을 검증해 한 보고로 모으는 실행 묶음이다.

설치와 최신 기능 범위는 Grok Build 문서와 워크플로 발표문을 기준으로 다시 확인한다. 이 글은 2026-07-23~24에 확인한 공개 설명 범위만 다룬다.