Grok 4.6 — 필드 가이드

Grok 4.6 — 필드 가이드

eric zakariasson · 2026-08-13 · 원문 보기

Grok 4.6이 나왔다! 나는 몇 주 동안 코딩과 지식 노동이 섞인 일상 업무 전반에서 이 모델을 데일리 드라이버로 썼고, 어디에서 버티고 어디에서 무너지는지 밀어붙이기 위해 몇 가지 프로젝트를 이 모델로 직접 만들어 봤다. 전부 다 잘한다. 가장 눈에 띄는 것은 어떤 단일 능력의 도약이라기보다, 소통하는 방식과 속도다.

@SpaceXAI — 2026-08-12

"Grok 4.6을 소개한다. 최첨단 지능을 제공하며, 동일한 가격에 Grok 4.5보다 상당한 개선을 이뤘다."

정보 밀도 높은 소통 (Information dense communication)

함께 일하기 편한 방식으로 협업적이다. 요약은 과제를 나에게 되풀이해 말하는 대신 실제 정보로 빽빽하게 차 있고, 실행 중에 던지는 짧은 업데이트는 중단해야 할지 판단하기에 충분한 정보를 준다.

작은 변경에는 조용히 있다가, 많은 파일을 건드리기 시작하면 서술을 시작한다. 이 분기점을 제대로 잡는 데는 생각보다 훨씬 많은 튜닝이 필요했다. 여전히 가끔은 내가 알 필요 없는 것까지 말해주는데, 그 부분은 우리가 개선 작업 중이다.

기분 좋은 속도 (Delightful speed)

4.5도 빨랐다. 4.6은 빠르면서 눈에 띄게 더 똑똑하고, 그 조합이 나를 더 동기적인(synchronous) 작업 방식으로 밀어붙였다. 많은 컨텍스트를 앞단에 쏟아붓고 기다리는 대신, 작은 것을 요청하고, 결과를 보고, 계속 나아간다. 같은 세션이 요청 한 번만으로 더 긴 호흡(longer-horizon)의 작업으로 넘어갈 수 있다.

나는 그달에 최고 모델들이 마침 무엇을 잘하느냐에 따라 동기와 비동기 사이를 오간다. 비동기는 내가 다른 곳에 있는 동안 더 많은 일을 해내지만, 나는 흐름을 놓치고 결국 커다란 diff를 맥락 없이(cold) 리뷰하게 된다. 4.6은 나를 다시 동기 쪽으로 끌어당기는데, 결과가 중요할 때 내가 있고 싶은 곳이 바로 거기다.

그 몇 주의 대부분은 평범한 업무였다. 이 모델은 나 대신 웹사이트를 탐색했고, 프로바이더의 콘솔을 클릭해 가며 API 키를 만드는 일까지 해냈다. 실행 중인 앱의 기능 QA와 비주얼 QA도 했다. 받은편지함을 실제로 답장이 필요한 소수의 스레드만 남도록 정리해 줬는데, 이건 아무리 해도 질리지 않게 기분이 좋다. Cursor SDK Bridge와 /rename-chat의 런치 포스트 초안 작성을 도왔고, 둘을 위한 런치 비디오도 Remotion으로 함께 만들었다!

짧은 프롬프트, 엄격한 검증 (Short prompts, strict verification)

그 몇 주의 일부는 프롬프팅 스타일들을 서로 맞붙여 테스트하는 데 썼다. 긴 프롬프트 대 짧은 프롬프트, 그리고 "work very hard"(아주 열심히 해) 같은 특정 문구가 결과를 바꾸는지. 내가 발견한 것은, 문구는 사실상 아무 차이도 만들지 못했다는 것이다.

길이는 차이를 만들었다. 다만 내가 가정했던 방식은 아니었다. 긴 프롬프트는 구체성을 산다. 그러니 원하는 것을 정확히 알고 있다면 적어라. 짧은 프롬프트는 결정의 더 많은 몫을 모델의 취향(taste)에 넘긴다. 예전에는 이 트레이드오프가 모든 것을 다 써내려가는 쪽의 근거였다. 4.6에서는 취향이 충분히 좋아져서, 짧은 프롬프트에 명확한 선호 하나만 얹으면 대개 괜찮은 지점에 도달한다.

긴 스펙이 있다면 그것도 여전히 잘 작동한다. 세션 캡처, 서버 핸들러, 클라우드 에이전트 디스패치가 포함된 피드백 위젯의 상세 스펙을 줬더니, 합리적인 구조로 처음부터 끝까지 전체를 그대로 따라갔다. 다만 나눠 달라고 요청하지 않으면 컴포넌트 안에서 스스로를 반복하는 경향은 있다.

내가 만든 프로젝트 중 하나는 스프레드시트 앱이었는데, 두 모델 모두에게 두 번씩 시켰다. 한 번의 실행은 내가 생각해 낼 수 있는 모든 툴바 항목, 키보드 단축키, 수식을 담은 두 페이지짜리 명세를 받았다. 다른 한 번은 세 문장을 받았다:

"Next.js로 세련된 Sheets/Excel 스타일 앱과, 시트를 분석할 수 있는 AI 채팅을 만들어라. 모든 AI 기능에는 Cursor SDK를 사용하라. 바로 좋아 보이도록 현실적인 샘플 워크북을 미리 로드해 둬라."

두 앱은 거의 동일하게 돌아왔다. 실제로 결과를 바꾼 것은 한 문장을 추가하는 것이었다:

"구현 후에 기능과 디자인을 검증하고, 프로덕션 레디가 될 때까지 계속 반복하고 검증하라."

그 한 줄이 그 몇 주 동안 내가 찾은 가장 레버리지 높은 것이었다! 이 문장이 있으면 모델은 앱을 열고, 실제 사용자 경로를 클릭해 보고, 중첩 수식이 올바르게 평가되는지 확인하고, 발견한 것을 고친다. 이 중 어느 것도 탄탄한 브라우저 사용 능력 없이는 작동하지 않는데, 바로 그것이 이 루프를 애초에 가능하게 만드는 요소다.

출력물을 검사하기 더 어려운 경우에도 같은 원리가 성립한다. 3D 씬에 "텍스처를 개선하라"는 아무 소득이 없었지만, "현재 프레임을 캡처하고, 무엇이 잘못됐는지 나열한 다음, 그것들만 고쳐라"는 즉시 통했다.

여기서부터의 모든 비교는 같은 프롬프트를 격리된 워크스페이스에서 두 모델 모두에 돌린 것이므로, 그 무엇도 지난달에 대한 내 기억이 아니다.

열심히 일하라거나 끝날 때까지 계속 밀어붙이라고 말할 필요도 없다. 알아서 꽤 오랫동안 스스로 계속 나아간다. 그보다 훨씬 중요한 것은 "완료"가 무엇을 의미하는지 말해주는 것이다. 그러지 않으면 모델이 그것을 당신 대신 결정해 버리기 때문이다.

더 멀리 가보기 (Going further)

나는 자라면서 Age of Empires 2를 비합리적일 만큼 많이 했다. 수천 시간이다. 그래서 그것을 재현하는 것이 제일 먼저 시도해 보고 싶은 프로젝트였다. 경제, 건설, 전투, 전장의 안개(fog of war), 목표, 그리고 신규 플레이어가 설명 없이도 읽을 수 있는 HUD를 갖춘 브라우저 전략 게임을 요청했다.

4.5는 쓸 만한 평면(flat) 프로토타입을 만들었다. 4.6은 첫 시도에 HUD와 미니맵까지 이미 갖춘 아이소메트릭 3D 월드를 들고 돌아왔다. 진짜에 훨씬 가깝다!

향수 여행을 이어가서, 다음으로는 MSN 메신저를 만들었다.

두 모델 모두 레퍼런스를 분명히 알고 있었고 잘 해냈다. 4.6이 그저 더 다듬어져(polish) 있을 뿐인데, 분리된 대화 창과 윙크(winks)까지 세세하게 구현되어 있다.

나는 Excalidraw를 끊임없이 쓰고 있고, 오픈소스이기도 해서, 빈 폴더가 아닌 실제 코드베이스를 모델들이 어떻게 다루는지 보기에 당연한 선택지였다. 두 모델에게 프레젠테이션 모드를 요청했다: 이름 붙인 뷰를 저장하고, 순서를 바꾸고, 가이드 워크스루로 발표하는 기능. 프롬프트는 어떻게 만들지에 대해 의도적으로 모호하게 남겼다.

둘 다 대략 같은 지점에 도달하는데, 그렇게 모호한 프롬프트치고는 인상적이다! 4.6이 첫 패스에서 디테일에 더 주의를 기울일 뿐이고, 실무적으로는 내가 이것저것 손가락으로 짚어주는 라운드가 줄어든다는 뜻이다.

검증을 건너뛰면 물리는 지점도 바로 여기다. 이전의 한 실행에서 요약은 다 끝난 것처럼 읽혔지만, 뷰 추가가 실제로는 작동하지 않았다. "실행해서 보여줘" 한 라운드에 깨진 import가 드러났다.

일상 업무 (Everyday work)

나는 매일 덱과 보고서를 만들지는 않지만, 많은 사람들이 그렇게 일하고, 이 모델이 그런 종류의 업무를 어떻게 다루는지 보고 싶었다. 그래서 두 모델에게 같은 가상의 분기 실적을 주고 보드 덱(board deck)을 요청했다.

둘 다 유능하고, 격차는 분석이 아니라 프레젠테이션에 있다. 4.5는 대체로 숫자를 슬라이드에 늘어놓는 반면, 4.6은 구조와 위계에 진짜 공을 들인다. 그래서 데이터 덤프가 아니라 누군가가 만든 덱처럼 읽힌다.

코드로서의 영상 (Video as code)

이 부분은 더 많은 지면을 할애할 만하다. 최근 내가 여기에 많은 시간을 쓰고 있기 때문이다. Remotion은 비디오를 코드로 다룬다: 모든 프레임이 현재 프레임 번호를 기준으로 렌더링되는 React 컴포넌트이고, 전체가 헤드리스 Chromium과 FFmpeg를 거쳐 MP4로 컴파일된다. 당신의 영상이 git 안에 산다. 정말로 재미있는 작업 방식이다! 동시에 모델에게 건네주기엔 이상한 대상이기도 한데, 실행이 된다는 것을 확인하는 것만으로는 성공했는지 알 수 없기 때문이다.

X TypeScript SDK를 위한 60~90초짜리 런치 필름을 요청하고, 작업 자료로 문서를 줬다.

나는 이런 결과물을 스토리라인이 있는지, 그리고 페이싱이 유지되는지로 판단한다. 대부분의 모델은 여기서 같은 방식으로 실패한다. 전부 대문자인 타이틀, 박스에 갇힌 텍스트, 그리고 모든 것이 한꺼번에 화면에 떨어지는 식이다. 두 필름 모두 그 대부분을 피했고, 4.6 쪽이 더 몰입해서 볼 만하다.

며칠 동안 여러 모델에 걸쳐 이것을 돌려본 결과, 영상은 내가 가장 넓은 편차를 보는 영역이다. 웹 앱에서는 똑같이 유능하게 느껴지는 두 모델이 여기서는 서로 근처에도 못 갈 수 있다.

조종이 필요한 지점 (Where it needs steering)

내가 조종(steering)해야 했던 거의 모든 것은 한 가지로 귀결됐다: 모델이 자기 작업을 얼마나 쉽게 검증할 수 있는가.

웹사이트는 쉬운 경우다. DOM이 텍스트라서, 페이지를 읽고, 스크린샷을 찍고, 의도했던 것과 비교할 수 있다. UI 작업에서 검증 루프가 그렇게까지 잘 작동하는 이유가 이것이다.

3D는 더 어렵다. 읽는 것만으로는 검사할 수 없는 차원이 통째로 하나 있기 때문이다. 영상은 그보다 더 어렵다. 시간이 추가 차원이고, 작업을 확인한다는 것은 프레임의 시퀀스를 캡처해 그 사이의 델타를 추론하는 것을 의미하기 때문이다. 물리도 같은 모양의 문제를 갖는다. 모델은 세계가 어떻게 행동해야 하는지에 대해서는 좋은 감각을 갖고 있지만, 실제로 그렇게 행동했는지 확인하는 것은 스크린샷 한 장으로 답할 수 있는 일이 아니다.

실용적인 답은 모델에게 볼 수 있는 수단을 주거나, 아니면 확인하는 사람이 당신이라는 것을 받아들이는 것이다.

왜 내 기본값인가 (Why it's my default)

스파이키한 모델들, 즉 특정 한 가지에 비범한 모델들에는 진짜 가치가 있다. 하지만 내 업무의 대부분은 특정 한 가지가 아니다. 내가 일상적으로 원하는 것은 내가 잘 아는 모델이다: 어떻게 행동하는지에 대한 직관이 쌓여 있고, 무언가를 넘겨줄 만큼 충분히 신뢰할 수 있고, 단점을 충분히 이해하고 있어서 별생각 없이도 우회할 수 있는 모델.

4.6이 나에게 정확히 그런 존재가 됐다. 코딩 쪽에서는 진행되는 대로 내가 반응하는 인터랙티브·비주얼 작업과, 실제 저장소에서의 긴 세션을 감당한다. 지식 노동 쪽에서는 받은편지함, 브라우저 QA, 그리고 뒤에 API가 없는 클릭 스루 작업들이다. 그 어느 하나에서도 상상 가능한 최고의 모델은 아니지만, 전부 잘하고, 나는 무엇을 기대해야 하는지 안다.

출력물이 보이는 모습으로 판단되는 곳에서는 여전히 내가 개입한다. 모션, 3D, 최종 폴리시는 설명이 아니라 레퍼런스와 스크린샷 루프를 원한다. 그리고 나는 완료됐다는 요약을 믿는 대신, 수용 기준(acceptance criteria)을 직접 적어둔다.

써보라 (Try it)

Grok 4.6은 지금 Cursor에서, xAI API에서, OpenRouter에서, 그리고 당신이 토큰을 구하는 그 어디에서든 사용할 수 있다!

써보고 어떻게 생각하는지 알려달라. 우리는 계속 개선해 나갈 것이므로, 좋든 나쁘든 어느 쪽이든 피드백을 남겨달라. 그것이 다음에 어디를 밀어붙여야 할지 알려주는 신호다.

당신이 결국 무엇을 만들게 될지 궁금하다!