턴마다 승인하던 방식에서 목표 선언으로: /goal 이 달라진 점
/goal은 단계별 승인을 하나의 선언된 목표로 바꾸는 Grok Build 모드입니다. 목표가 달성되고 검증될 때까지 계속 실행됩니다. 사용자는 상위 수준의 지시 하나를 입력합니다. xAI의 대표 예시는 /goal Migrate the auth module to the new API입니다. 그러면 에이전트는 각 단계마다 프롬프트와 승인을 기다리는 대신, 스스로 계획하고 실행하며 작업을 점검합니다 .
이는 에이전트와 사용자가 맺는 작업 방식의 실질적인 변화입니다. /goal 이전의 Grok Build는 턴 단위로 작동했습니다. 각 단계마다 프롬프트가 필요했고, 단계별로 수락하거나 거절해야 했습니다. 새 모드는 이 반복 구조를 하나의 목표 선언과, 하위 작업 전반의 상태를 추적하는 지속적인 목표 객체로 대체합니다 .
시작 시 에이전트는 진행 체크리스트를 만들고 이를 실시간으로 추적합니다. 패널은 단순히 코드가 생성되었을 때가 아니라, 모든 체크리스트 항목이 체크되고 내장 검증을 통과했을 때에만 Complete로 바뀝니다 .
더 깊은 작동 방식을 보기 전에 알아둘 실무적인 사항은 다음과 같습니다.
- 이용 대상: 2026년 6월 22일 기준 SuperGrok 및 X Premium Plus 구독자에게 제공됩니다 .
- 사용자 개입 가능: 목표를 포기하지 않고도 하위 작업 사이에 에이전트에게 추가 지시를 넣을 수 있습니다 .
- 새 모델은 아님:
/goal은 2026년 5월 25일 초기 베타로 출시된 기존 Grok Build 인프라 위의 런타임 계층입니다 .
마지막 지점은 기억해둘 만합니다. /goal은 파운데이션 모델을 새로 도입하는 기능이 아닙니다. 실제로 밑에서 실행되는 것은 여전히 사용자가 선택한 기존 모델에 의해 좌우됩니다. 입력 토큰 100만 개당 1달러, 출력 토큰 100만 개당 2달러로 책정된 grok-build-0.1일 수도 있고 , 2026년 6월 1일 /model을 통해 선택 가능해진 Composer 2.5일 수도 있습니다 . 새로워진 것은 오케스트레이션이지, 엔진 자체는 아닙니다.
/goal 실행 흐름: 목표 입력부터 완료까지
이 오케스트레이션이 실제로 하는 일은 세 단계의 루프를 실행하는 것입니다. 먼저 Grok Build는 선언된 목표를 읽고 접근 방식을 만든 뒤, 이를 진행 체크리스트로 나눕니다. 다음으로 그 체크리스트 항목을 하나씩 실행합니다. 마지막으로 작업 완료 표시를 하기 전에 결과물을 검증합니다. 완료 조건과 검증 조건이 모두 충족될 때까지 이 사이클이 반복됩니다 .
체크리스트는 고정 템플릿에서 가져오는 것이 아니라 동적으로 생성됩니다. 2차 해설들은 이 패턴을 하위 작업을 이어 붙이는 observe–plan–act 사이클로 설명합니다. 계획 단계에서 그때그때 작업 분해가 만들어지고, 구현과 검증은 작업이 끝나고 테스트될 때까지 파이프라인처럼 진행됩니다 . 이 차이는 중요합니다. 에이전트가 저장소를 보기 전에 정해둔 순서를 그대로 실행하는 것이 아니라, 발견한 내용에 맞춰 다시 계획하기 때문입니다.
여기서 말하는 검증은 형식적인 검증이 아니라 운영상의 확인에 가깝습니다. 에이전트가 CI에 준하는 테스트 스위트 통과를 반드시 요구하는 것은 아닙니다. 대신 자신이 만든 코드를 검토하거나, 웹페이지를 살펴 동작을 확인하거나, 스크립트와 테스트를 실행해 결과물이 단지 생성된 데 그치지 않고 실제로 작동하는지 확인할 수 있습니다 . 실행이 끝나면 진행 패널은 모든 체크리스트 항목이 체크된 상태로 Complete로 바뀝니다.
xAI는 출시 문서에서 이 루프를 다음과 같이 설명합니다.
"목표를 받은 뒤 에이전트는 접근 방식을 계획하고, 작업을 진행 체크리스트로 나눈 다음, 항목을 하나씩 실행합니다. 작업이 완료되고 검증될 때까지 반복합니다." — xAI, /goal 출시 보도.
그렇다면 검증이 계속 실패하면 어떻게 될까요? 이 부분이 공백입니다. 출시 사양에는 에이전트가 어떤 항목을 통과시키지 못할 때의 최대 재시도 횟수나 루프 종료 조건이 문서화되어 있지 않습니다 . 턴 단위 어시스턴트라면 각 단계를 사용자가 승인하므로 큰 문제가 아닙니다. 하지만 unattended 상태로 오래 실행되는 실행기라면, 끝이 정해지지 않은 재시도 동작은 프로덕션 사용에서 가장 중요한 미확정 요소입니다.
실무적으로는 이렇게 보는 편이 맞습니다. 검증은 보증이 아니라 신뢰 신호로 다루어야 합니다. 큰 마이그레이션을 맡기기 전에 알아둘 점은 다음과 같습니다.
- 체크리스트는 실행 중 만들어집니다.
/goal status에서 보는 계획은 에이전트가 코드베이스를 더 알아가면서 바뀔 수 있습니다. - "Verified"는 에이전트가 실행할 수 있었던 범위 안의 검증입니다. 실제 테스트 스위트를 실행하지 못했다면, 검증은 코드 리뷰나 페이지 점검을 의미할 수 있습니다.
- 문서화된 루프 상한은 없습니다. xAI가 재시도와 종료 의미론을 공개하기 전까지는 목표를 직접 점검할 수 있을 만큼 작게 잡고, 실행이 한 항목에서 멈춘다면
/goal pause를 사용하세요.
실행 중인 /goal을 조정하는 방법
실행 중인 /goal 작업은 그 작업을 시작한 같은 Grok Build 세션 안에서 입력하는 네 가지 세션 명령, 즉 /goal status, /goal pause, /goal resume, /goal clear로 조정할 수 있습니다 . 이 명령들은 터미널을 종료하지 않고도 진행 상황 확인, 중단, 재개, 포기를 모두 처리합니다.
| 명령 | 동작 |
|---|---|
/goal status | 현재 진행 패널과 체크리스트를 엽니다 |
/goal pause | 작업을 멈추지만 목표와 그 상태는 보존합니다 |
/goal resume | 멈춘 지점부터 이어서 진행합니다 |
/goal clear | 목표 자체를 완전히 포기합니다 |
기억해 둘 차이는 이렇습니다. pause는 목표 객체와 체크리스트를 그대로 유지해 resume이 멈춘 곳에서 다시 시작하게 하지만, clear는 목표를 버립니다 . 실행이 특정 항목에서 막혔을 때는 pause를 쓰고, 더 이상 진행하지 않기로 한 목표에만 clear를 쓰는 편이 좋습니다.
실행 중이라고 해서 사용자가 손을 댈 수 없는 것은 아닙니다. xAI 문서에 따르면 에이전트가 작업하는 동안에도 추가 지시를 넣을 수 있으므로, 목표를 버리지 않고 하위 작업 사이에서 방향을 바로잡을 수 있습니다 . 마이그레이션처럼 실행 도중 에이전트가 놓친 규칙을 발견하는 일이 잦은 작업에서는 이 점이 중요합니다.
여러 작업을 동시에 돌릴 때는 Agent Dashboard를 사용합니다. 2026년 6월 15일 출시된 이 대시보드는 grok dashboard, /dashboard, 또는 Ctrl+\로 열 수 있으며, 병렬 세션을 관리하고 입력 대기 중인 세션을 맨 위로 정렬하며 화면을 떠나지 않고 바로 답변할 수 있게 해 줍니다 . 대시보드를 닫아도 세션은 계속 실행됩니다.
대시보드는 세션별 상태를 보여 주기 때문에 한눈에 우선순위를 정할 수 있습니다.
- working — 체크리스트 항목을 실제로 실행 중
- thinking — 실행 전에 계획하거나 추론 중
- running commands — 예: 검증 중
cargo test --workspace실행 - awaiting input — 사용자의 승인이나 답변을 기다리며 막힌 상태
- idle — 진행 중인 작업 없음
실무적으로 대시보드는 감독을 확장하는 곳입니다. 여러 /goal 실행을 시작한 뒤, awaiting input으로 표시된 세션에만 개입하고 나머지는 계속 순환하게 두면 됩니다.
/goal이 승인 없이 접근할 수 있는 범위: Grok Build의 권한 계층
/goal이 사용자에게 묻지 않고 접근할 수 있는 범위는 /goal 자체가 아니라 Grok Build의 기존 권한 및 샌드박스 계층이 결정합니다. 자율 루프는 모든 도구 호출을 제어하는 동일한 프레임워크 안에서 실행됩니다. 권한 모드는 에이전트가 행동하기 전에 물어볼지를 정하고, 샌드박스 프로필은 어떤 파일과 네트워크에 접근할 수 있는지를 정합니다. 보수적으로 해석하면 /goal은 계획, 체크리스트 상태, 검증을 조율하고, 실제로 어디까지 갈 수 있는지는 기존 제어 장치가 제한합니다 .
기본 권한 모드는 ask입니다. 에이전트는 각 도구 호출 전에 사용자에게 묻고, 이 프롬프트는 /goal 실행 중에도 그대로 표시됩니다 . 정말로 무인 실행을 하려면 이 설정을 완화해야 합니다. 설정에는 permission_mode = "ask" 또는 "always-approve"를 사용할 수 있으며, always-approve는 프롬프트를 완전히 건너뜁니다 .
엔터프라이즈 Grok Build에는 두 가지 모드가 더 있습니다. dontAsk는 명시적인 허용 규칙이 없는 모든 것을 조용히 거부하고, acceptEdits는 파일 편집은 자동 승인하지만 셸 명령은 여전히 확인을 요청합니다. 무인 /goal 실행에 가장 방어적으로 타당한 프로필은 acceptEdits입니다. 에이전트가 코드는 자유롭게 고칠 수 있지만, 셸에 닿는 작업은 사람이 막아 주기 때문입니다 .
| 모드 | 동작 | /goal에 적합한 경우 |
|---|---|---|
ask (기본값) | 모든 도구 호출 전에 묻습니다 | 감독형 실행 |
acceptEdits (엔터프라이즈) | 편집은 자동 승인하고, 셸은 묻습니다 | 권장 무인 실행 |
always-approve | 모든 프롬프트를 건너뜁니다 | 완전 무인, 더 높은 위험 |
dontAsk (엔터프라이즈) | 허용되지 않은 호출을 조용히 거부합니다 | 잠금형 허용 목록 |
샌드박스 프로필은 두 번째 벽을 세웁니다. read-only는 Linux에서 자식 프로세스의 네트워크를 차단하고 쓰기 범위를 ~/.grok/와 tmp로 제한합니다. strict는 읽기 범위를 작업 디렉터리와 시스템 경로로 제한하고, 쓰기 범위는 CWD, /tmp, ~/.grok/로 제한합니다 .
"~/.ssh, ~/.gnupg, ~/.aws 및 클라우드 설정 폴더 같은 민감한 디렉터리는 프로필과 관계없이 항상 쓰기 보호됩니다." — Grok Build 엔터프라이즈 문서 (source: Grok Build CLI)
마지막 보장은 자율 실행에서 특히 중요합니다. always-approve 모드에서도 자격 증명 유출은 구조적으로 차단됩니다. 목표가 무엇을 요구하든 에이전트는 SSH, GPG, AWS 또는 클라우드 설정 폴더에 쓸 수 없습니다 . 아직 열린 질문은 하나 남아 있습니다. xAI는 /goal이 이 동작을 바꾸는지, 아니면 단순히 그대로 상속하는지 밝히지 않았습니다 .
/goal이 거는 지속 실행 작업의 승부수 — 경쟁 도구와 다른 점
가장 가까운 비교 대상은 Anthropic의 Claude Code와 OpenAI의 Codex CLI입니다. 세 도구 모두 터미널 기반의 다중 파일 에이전트형 코딩 도구이며, xAI는 Grok Build를 이들과 직접 맞붙는 도구로 포지셔닝합니다 . /goal을 가르는 차이는 새 모델이라기보다 더 좁은 범위에 있습니다. 이름이 붙은 상태 저장 목표 객체, 명시적인 pause/resume/clear 생명주기, 그리고 패널이 완료를 보고하기 전 반드시 거치는 검증 단계입니다 .
그 아래 런타임은 전용으로 따로 만든 것이 아니라 공유됩니다. xAI는 2026년 5월 29일 공개 베타로 API를 통해 grok-build-0.1을 출시했으며, 가격은 입력 토큰 100만 개당 1달러, 출력 토큰 100만 개당 2달러이고, 초당 100개 이상의 토큰을 처리한다고 밝혔습니다 . 장시간 실행되는 지시 체인에서 빠르다고 설명된 Composer 2.5는 2026년 6월 1일 Grok Build에 들어왔고, /model로 선택할 수 있습니다 . 따라서 /goal은 기존 모델 선택지 위에 얹힌 CLI 모드입니다.
아키텍처의 승부수는 단일 차단형 채팅이 아니라 감독 방식에 있습니다. 2026년 6월 15일 발표된 Agent Dashboard는 여러 동시 세션을 실행할 수 있게 하고, 입력을 기다리는 세션을 상단에 표시합니다 . 이는 단일 세션, 단일 대화에 초점을 맞춘 방식과 구조적으로 다릅니다.
AI Made Tools의 기술 해설은 이를 "작업이 완료되고 테스트될 때까지 계획, 구현, 검증이 하위 작업의 파이프라인으로 처리된다"고 설명합니다 (source: Grok Build complete guide).
저장소를 맡기기 전에 아직 열려 있는 공백을 따져봐야 합니다. 공개 사양은 아직 다음을 밝히지 않았습니다.
- 목표당 최대 실행 시간
- 충돌 복구 및 재시도 정책
- 토큰 또는 크레딧 예산 한도
- 헤드리스 모드 호환성과 ACP 제공 여부
또한 2026년 6월 21일에 마지막으로 업데이트된 공식 Modes and Commands 문서에도 아직 /goal이 올라오지 않았다는 점이 중요합니다. 그래서 현재는 xAI의 출시 게시물이 주요 사양 역할을 합니다 .
핵심은 분명합니다. "Complete"는 "계획했고, 실행했고, 스스로 확인했다"는 뜻으로 봐야지, 감사를 마쳤다는 뜻으로 보면 안 됩니다. xAI가 런타임, 복구, 예산 한도를 문서화하기 전까지는 /goal을 마이그레이션처럼 경계가 분명하고 테스트 가능한 작업에 한정해 사용하고, 샌드박스 프로필 아래에서 실행한 뒤, 초록 체크 표시를 믿기 전에 반드시 diff를 읽어야 합니다.
자주 묻는 질문
/goal은 일반 Grok Build 세션과 어떻게 다른가?
일반 Grok Build 세션은 턴 단위로 진행됩니다. 사용자가 프롬프트를 입력하면 에이전트가 행동하고, 각 단계를 승인합니다. /goal은 하나의 상위 목표를 받아 진행 체크리스트를 만들고, 매 턴마다 단계별 승인을 받지 않은 채 작업이 끝날 때까지 계획, 실행, 검증을 이어갑니다 . 예외는 권한 모드입니다. permission_mode가 ask로 설정되어 있으면 에이전트는 여전히 도구 호출 전에 확인을 요청합니다 (Grok Build Modes and Commands).
/goal은 작업 완료라고 표시하기 전에 실제로 무엇을 확인하나?
검증은 형식적 증명이 아니라 운영상의 확인입니다. 체크리스트 항목을 완료로 바꾸기 전에 에이전트는 자신이 만든 코드를 검토하거나, 웹페이지를 살펴 동작을 확인하거나, 스크립트와 테스트를 실행해 결과물이 단순히 생성된 것이 아니라 실제로 작동하는지 확인할 수 있습니다 . 필수 테스트 스위트나 CI 게이트는 없습니다. 저장소 안에서 접근할 수 있는 것을 확인하는 방식이므로 "Complete"는 자체 확인을 마쳤다는 뜻이지, 감사를 통과했다는 뜻은 아닙니다.
/goal을 헤드리스나 API 모드에서 무인 실행할 수 있나?
출시 시점에는 확인되지 않았습니다. Grok Build는 -p, --session-id, --resume, --always-approve 같은 플래그를 포함한 헤드리스 세션을 지원하며, 세션은 ~/.grok/sessions 아래에 저장됩니다 (Grok Build enterprise docs). 하지만 2026년 6월 22일 발표는 /goal을 헤드리스 모드, Agent Client Protocol, 또는 grok-build-0.1 API 엔드포인트를 통해 호출할 수 있는지 밝히지 않았습니다. xAI가 문서화하기 전까지 무인 /goal은 검증되지 않은 것으로 봐야 합니다.
무인 /goal 실행에는 어떤 권한과 샌드박스 설정이 가장 안전한가?
범위가 정해진 무인 실행이라면 strict 샌드박스와 acceptEdits 권한 모드를 함께 쓰는 편이 좋습니다. strict는 읽기 범위를 작업 디렉터리와 시스템 경로로 제한하고, 쓰기는 CWD, /tmp, ~/.grok/로 제한합니다. acceptEdits는 파일 편집을 자동 승인하지만 셸 명령에는 여전히 확인을 요청합니다 . ~/.ssh, ~/.gnupg, ~/.aws, 클라우드 설정 폴더 같은 민감한 디렉터리는 프로필과 관계없이 쓰기 보호 상태로 유지됩니다 .
/goal은 Claude Code의 장시간 작업 지원과 어떻게 비교되나?
둘 다 계획, 구현, 검증 단계를 가로지르며 다중 파일 에이전트 실행을 수행합니다. /goal의 차별점은 이름이 붙고 재개 가능한 목표 객체, 실시간 진행 체크리스트, 그리고 /goal pause와 /goal resume이라는 명시적 제어 명령입니다 . 아직 비어 있는 부분은 최대 실행 시간과 충돌 복구 의미론이며, xAI는 이를 아직 구체화하지 않았습니다 (Grok Build guide). 이 부분은 Claude Code가 더 명시적으로 문서화하고 있습니다.
