한 줄 목표만 던지면 끝이라는 말이 왜 솔깃할까
개발자 커뮤니티를 보다 보면 반응이 꽤 비슷하다. 어떤 사용자는 Grok Build가 빠르고 사용량도 넉넉하다고 했지만, 큰 작업에서는 문맥을 놓치거나 안 건드려도 되는 코드를 다시 쓰는 경우가 있었다고 적었다. 다른 글에서는 모델 자체보다 에이전트를 감싸는 도구 흐름이 더 중요하고, 여러 세션을 오래 돌릴수록 마찰이 커진다고 짚었다. 기대와 피로가 같이 붙어 있는 셈이다. Reddit 사용 후기 (영어주의) Hacker News 사용 후기 (영어주의)
이런 분위기에서 /goal 같은 이름은 아주 강하게 들린다. xAI는 2026년 6월 22일 /goal을 소개하면서, 긴 구현 작업을 에이전트에게 맡기고 완료와 검증까지 이어가게 해 준다고 설명했다. 코드 리뷰, 웹페이지 확인, 스크립트 실행까지 이어서 하며 끝까지 달리는 모드라는 얘기다. xAI `/goal` 발표, 2026년 6월 22일 (영어주의)
짧은 소개만 보면 이제는 한 줄만 던지면 혼자 끝낸다로 받아들이기 쉽다. 그런데 실제 문서들을 붙여 보면 이 기능은 분명 전보다 자율적이지만, 완전히 손을 떼도 되는 단계로 읽기엔 아직 선을 그어야 할 부분이 있다.
왜 이렇게 크게 들릴까
이 이슈가 부풀어 보이는 건 자율 실행이라는 말을 너무 크게 받아들이기 쉬워서다.
/goal은 그냥 새 모델 이름이 아니다. xAI가 2026년 5월 25일 공개한 Grok Build라는 별도 코딩 에이전트 안에 들어간 실행 방식이다. 이 도구는 처음부터 터미널 기반 코딩 작업, 계획 검토, 병렬 서브에이전트, 플러그인과 MCP 연결 같은 흐름을 전제로 만들어졌다. Grok Build 발표, 2026년 5월 25일 (영어주의) Grok Build 개요 문서 (영어주의)
/goal도 대화를 없애는 기능이라기보다 대화 간격을 늘리는 쪽에 가깝다. 발표문을 보면 에이전트가 계획을 세우고 체크리스트를 만들고 실행을 이어가지만, 사용자는 중간에 추가 지시를 줄 수 있고 상태 확인, 일시정지, 재개, 초기화 명령도 따로 있다. 사람 손이 완전히 빠지는 구조라기보다, 계속 붙들고 있지 않아도 되는 흐름에 더 가깝다. xAI `/goal` 발표 (영어주의)
원래 제품 방향도 이미 그쪽이었다. xAI는 Agent Dashboard로 여러 세션을 한 화면에서 보고, 필요한 세션에만 답하고, 나머지는 계속 돌려둘 수 있다고 설명한다. 그러니 /goal이 갑자기 모든 걸 바꾼 마법 버튼이라기보다, 이미 자율 실행 쪽으로 기울어 있던 제품 위에 올라간 확장 기능으로 보는 쪽이 자연스럽다. Agent Dashboard 발표, 2026년 6월 15일 (영어주의)
문서로 다시 보면 실제 범위가 좀 또렷하다
가장 먼저 확인되는 건 /goal이 실제 기능이라는 점이다. 2026년 6월 22일 xAI 발표에는 /goal Migrate the auth module to the new API 같은 예시와 함께 status, pause, resume, clear 명령이 공개돼 있다. 단순한 데모 문구가 아니라, 장시간 작업용 제어 패널을 붙인 모드라고 보는 편이 자연스럽다. xAI `/goal` 발표 (영어주의)
Grok Build 자체의 범위도 넓다. 개요 문서는 이 도구를 대화형 TUI뿐 아니라 스크립트용 headless 실행, 봇 연결, ACP 연동까지 지원하는 코딩 에이전트로 설명한다. /goal은 채팅창에서 한 번 눌러보는 보조 기능보다, 자동화 흐름 안에 넣을 수 있는 CLI 성격이 더 강하다. Grok Build 개요 문서 (영어주의) Headless & Scripting 문서 (영어주의)
다만 여기서 바로 혼자 끝낸다로 넘어가면 과하다. xAI의 명령 문서를 보면 Grok Build는 여전히 계획 모드, 승인 모드, 권한 설정, 세션 분기, 컨텍스트 확인 같은 장치를 많이 둔다. always-approve도 별도 설정이며 기본값은 ask다. 이런 구조는 xAI 스스로도 장기 작업에서 권한과 검토를 완전히 없애지 않는다는 뜻에 가깝다. Modes and Commands 문서 (영어주의) Settings 문서 (영어주의)
병렬성도 장점이지만, 같은 이유로 관리 포인트가 늘어난다. Grok Build는 서브에이전트, 워크트리, 플러그인, 스킬, MCP 서버를 함께 읽고 움직일 수 있다. xAI는 이것을 기존 개발 흐름과 바로 맞물린다는 장점으로 소개한다. 반대로 말하면 저장소 규칙, 외부 도구, 승인 정책이 복잡한 팀에서는 그냥 켜두기보다 범위를 잘라서 맡기는 편이 안전하다. Grok Build 발표 (영어주의) Skills, Plugins, and Marketplaces 문서 (영어주의)
접근 조건도 생각보다 넓지 않다. Grok Build 발표 시점에는 SuperGrok과 X Premium Plus 구독자 대상의 early beta로 열렸고, CIO Dive도 같은 맥락에서 개발자 대상 베타라고 정리했다. 그러니 Grok가 있으니 누구나 바로 쓰는 기능으로 보면 틀어진다. 처음부터 개발 도구 구독 흐름 안에 붙은 기능이다. Grok Build 발표 (영어주의) CIO Dive 보도, 2026년 5월 15일 (영어주의)
데이터 처리 쪽도 가볍게 넘길 문제는 아니다. xAI의 엔터프라이즈 문서는 팀이나 기업 단위에서 Zero Data Retention을 별도 기능으로 제공한다고 적고 있다. 민감한 저장소에서 어차피 로컬 CLI니까 괜찮겠지라고 바로 생각하기보다, 어떤 팀 설정과 정책이 붙는지 먼저 확인해 두는 편이 낫다. Enterprise Deployments 문서 (영어주의)
정리하면 /goal은 허상이 아니라 실제로 더 길게 맡길 수 있게 만든 자율 실행 모드다. 다만 아무 저장소에나 걸어두고 아침에 오면 다 끝난다는 뜻까지 자동으로 따라오진 않는다.
써볼 생각이면 먼저 볼 것
- 작업을 아주 크게 던지기보다, 완료 조건을 눈으로 확인할 수 있는 단위로 자르는 편이 낫다.
- 승인 기본값이
ask인지, 작업 중에always-approve를 켤지부터 정하는 게 좋다. - 플러그인, 스킬, MCP, 워크트리까지 같이 읽는 구조라면 저장소 규칙과 외부 도구 범위를 먼저 점검해 두는 편이 안전하다.
- 자동화 스크립트에 넣을 생각이면 headless 실행과 세션 재개 방식을 같이 보는 게 좋다.
- 민감한 코드라면 성능 얘기보다 데이터 보관 정책과 팀 설정을 먼저 확인하는 쪽이 낫다.
내 생각
이 기능은 생각보다 긍정적으로 볼 부분이 있다. xAI가 /goal을 내놓으면서 말한 방향은 단순한 과장이 아니라, 실제로 코딩 에이전트를 한 턴씩 지시하는 도구에서 한동안 맡겨두는 도구로 옮기려는 흐름에 가깝다. 계획, 체크리스트, 상태 패널, 재개 명령이 따로 있는 걸 보면 제품 방향은 꽤 또렷하다.
다만 이 기능의 진짜 값어치는 완전 무인이 아니라 감독 간격을 벌려준다는 데 있는 것 같다. 작은 작업에서는 체감이 좋을 수 있고, 반복적인 정리나 검증 흐름에도 잘 맞을 수 있다. 큰 리팩터링이나 민감한 코드베이스까지 같은 감각으로 맡기면 금방 무거워진다. 켜두고 자리 비워도 되는가라는 질문에는, 조심해서 범위를 자르면 어느 정도는 그렇다 정도가 지금 시점에 가장 맞는 답처럼 보인다.
관련 글
같은 맥락에서 이어서 읽기 좋은 글들입니다.