Grok 4.7 리뷰: 가격, 벤치마크, API 접근성 및 변경 사항

간단한 답변

Grok 4.7은 코딩 및 난이도 높은 지식 작업 과제를 목표로 하는 xAI의 2026년 9월 21일 출시 업그레이드 버전입니다. xAI는 Grok 4.6과 동일한 가격 및 처리 속도를 유지하면서도, 난이도 높은 문제에 더 많은 시간을 할애하고, 작업 결과를 더 꼼꼼하게 점검하며, 새로운 안전 장치 스택을 추가했다고 밝혔습니다. 출시 페이지에서는 이 모델이 동급 모델보다 두 배 빠르고 가격은 절반 수준이라고 소개하고 있으나, 이러한 벤더 비교는 해당 모델이 수행하는 기본 작업과 처리 경로를 고려하여 해석해야 합니다. Independent Artificial Analysis의 데이터에 따르면, 이 모델은 Grok 4.6 대비 전반적으로 소폭 향상된 성능을 보였으며 50만 단어의 컨텍스트 윈도우를 기록했습니다. 당사의 3가지 작업 API 테스트에서 Grok 4.7은 디버깅 및 소스 경계 준수 측면에서 가장 뛰어난 성능을 보였으며, 프로젝트 계획은 불확실성을 잘 반영했으나 요청된 수준보다는 실행 가능성이 다소 낮았습니다. 이는 유용한 실증적 증거일 뿐, 모든 경쟁 모델을 능가한다는 증거는 아닙니다.

Grok 4.7이란 무엇인가요?

Grok 4.7은 2026년 9월 21일에 발표된 xAI의 Grok 제품군 중 최신 모델입니다. 이 xAI 공식 발표 이를 코딩 및 지식 업무에 있어 회사에서 가장 뛰어난 성능을 자랑하는 모델로 포지셔닝하고 있습니다. 의미 있는 변화는 소비자를 대상으로 한 새로운 기능 목록이 아닙니다. 이는 모델이 노력을 어떻게 분배할 것으로 기대되는지에 대한 변화입니다. 즉, 어려운 작업에 더 많은 시간을 할애하고, 자체 점검을 더 많이 수행하며, 이러한 향상된 기능을 보다 효과적으로 제어할 수 있도록 설계된 안전 장치가 추가된 것입니다.

이러한 포지셔닝이 중요한 이유는, 이는 챗봇의 개성보다는 워크플로우 모델을 설명하기 때문입니다. Grok 4.7은 디버깅, 계획 수립, 기술 문서 작성, 연구 종합, 그리고 모델이 여러 제약 조건을 지속적으로 고려해야 하는 긴 프롬프트 등, 지속적인 분석이 필요한 작업에 적합한 모델로 판매되고 있습니다.

그 경계 역시 마찬가지로 중요합니다. xAI의 발표는 의도된 동작에 대한 공급업체의 진술일 뿐입니다. 이는 Grok 4.7이 모든 경쟁 모델, 모든 프롬프트, 또는 모든 코딩 저장소를 능가한다는 독립적인 증거가 아닙니다. 출시 페이지를 xAI의 주장에 대한 출처로 간주한 다음, 독립적인 측정 결과와 여러분이 직접 설정한 과제를 바탕으로 그러한 주장이 타당한지 판단하시기 바랍니다.

Grok 4.7 대 Grok 4.6: 실제로 무엇이 달라졌을까?

가장 타당한 요약은 ‘노력과 신뢰성을 높인 것’이지, ‘완전히 다른 제품’이 아니라는 점입니다.

이는 구매자에게 유용한 구분 기준입니다. 만약 Grok 4.6 버전이 이미 귀사의 워크플로우에 적합했다면, 4.7 버전은 부담 없이 검토해 볼 만한 업그레이드입니다. 반면, 생태계, 지연 시간, 안정성 또는 접근성 제약으로 인해 4.6 버전이 적합하지 않았다면, 벤치마크 점수가 높아졌다고 해서 그 문제들이 해결되는 것은 아닙니다.

더 포괄적인 모델 구매 프레임워크를 위해서는, GPT-5.6 가격 안내서 그리고 GPT-5.6 비교 이는 모델의 품질과 계획의 경제성, 워크플로우 적합성을 구분하는 데 유용한 지침이 됩니다.

기능: Grok 4.7이 도움이 될 부분

코딩 및 디버깅

xAI의 가장 강력한 출시 전략은 코딩입니다. Grok 4.7이 단순히 더 많은 코드를 작성한다는 것이 아니라, 어려운 엔지니어링 문제를 더 오랫동안 다루고, 자체 답변을 검토한 후, 더 신중하게 고려된 패치나 설명을 제공할 수 있다는 점이 바로 그 핵심입니다. 이것이 바로 실제 리포지토리에서 기대해야 할 행동입니다. 기존 설계를 보존하고, 근본 원인을 파악하며, 유용한 테스트를 추가하고, 아직 알 수 없는 부분을 명확히 밝히고 있는가?

“할 일 앱 만들기”와 같은 완전히 새로운 주제의 프롬프트로 모델을 평가하지 마십시오. 테스트가 실패하는 명확한 버그, 소수의 파일, 그리고 명시적인 제약 조건을 제시하십시오. 패치를 요청하기 전에 먼저 진단 결과를 요청하십시오. 이렇게 하면 긴 추론 과정이 검토 작업을 줄여주는지, 아니면 단순히 문장이 길어질 뿐인지 더 쉽게 파악할 수 있습니다.

서로 다른 코딩 방식을 비교하는 팀에게도 동일한 규칙이 적용됩니다. A DeepSeek V4 Pro 리뷰 및 GLM 코딩 계획 검토 유용한 비교 기준을 제공하지만, 어느 쪽도 실제로 사용하는 저장소와 툴체인을 직접 테스트하는 것을 대체할 수 있는 것으로 간주되어서는 안 됩니다.

장기간에 걸친 지식 업무

Artificial Analysis는 Grok 4.7 버전에서 50만 토큰 규모의 컨텍스트 윈도우를 지원한다고 밝혔습니다. 이는 방대한 원본 자료를 다루는 작업 방식에 변화를 줄 만큼 충분한 규모입니다. 긴 기술 사양서, 회의록 모음, 코드베이스의 일부, 또는 연구 자료 모음 등은 반복적으로 요약될 필요 없이 하나의 대화 내에서 그대로 다룰 수 있습니다.

문맥 처리 능력은 문맥의 질과 같은 것이 아닙니다. 모델은 방대한 양의 입력을 처리할 수 있더라도 문서 중간 부근의 제약 조건을 놓치거나, 마지막 단락에 지나치게 비중을 두거나, 출처 확인이 필요한 자신감 넘치는 요약을 생성할 수 있습니다. 이를 검증하는 실질적인 방법은 압박 상황에서의 검색 능력입니다. 긴 문서의 여러 부분에 몇 가지 결정적인 사실을 배치한 뒤, 제약 조건이 있는 결정을 요구하고, 답변에 올바른 구절이 인용되었는지 확인하는 것입니다.

스페이스XAI의 공식 X 계정은 9월 22일, Grok 4.7이 동일한 가격과 속도에서 Grok 4.6에 비해 눈에 띄는 개선을 이뤘다고 재차 강조하며, 모델 비교 그래픽을 공유했습니다. 해당 게시물은 독립적인 검증이나 커뮤니티의 합의가 아닌, 회사의 공개적인 포지셔닝을 보여주는 유용한 증거입니다.

이 모델을 연구 목적으로 사용할 경우, 증거 루프가 명확히 드러나도록 하십시오. 저희의 Gemini 대 Perplexity 비교 그리고 Perplexity 대체품 안내서 모두 같은 실질적인 요점을 지적합니다. 즉, 세련된 답변이 출처 검증이 아니라는 것입니다.

자가 점검 및 안전

xAI에 따르면, Grok 4.7 버전은 작업 결과를 더 꼼꼼하게 점검하고 새로운 안전 장치 스택을 도입했다고 합니다. 특히 모델이 긴 의사결정 체인을 수행해야 할 때, 이러한 목표들은 매우 중요합니다. 하지만 이것이 출력이 정확하거나 자동 실행에 안전하다는 것을 보장하는 것은 아닙니다.

실제 운영 환경에서는 모델 주변에 일반적인 통제 수단(테스트, 권한 관리, 수동 검토, 인용 확인, 명확한 중단 조건 등)을 유지해야 합니다. 모델의 자체 점검 기능은 검토해야 할 또 다른 신호일 뿐, 모델 주변의 통제 수단을 대체하는 것이 아닙니다.

Grok 4.7 벤치마크: 수치가 보여주는 것

이 카드들을 참고 자료로 삼으십시오. 데이터셋 구성, 도구 접근성, 표본 추출 및 모델 설정에 따라 순위가 달라질 수 있습니다.

현재 가장 유용한 독립적인 현황 정보는 다음에서 제공되고 있습니다. Artificial Analysis의 ’Grok 4.7’ 벤치마킹 기사, 2026년 9월 21일자.

추세는 고무적이다. 독립적인 지표는 이전 버전보다 개선된 모습을 보이고 있으며, AA-Briefcase에서 나타난 더 큰 엘로 점수 차이는 해당 평가에서 더욱 뚜렷한 성과 향상을 시사한다. 하지만 이 표는 여전히 두 개의 데이터셋을 다루고 있을 뿐, 보편적인 순위를 나타내는 것은 아니다. 벤치마크 구성, 도구 접근성, 표본 추출, 모델 설정 등에 따라 결과가 달라질 수 있다.

xAI의 공식 출시 페이지에는 Grok 4.7이 CursorBench 4.0에서 46.3% 비교 표에는 40.4%를 기록한 Grok 4.6, 41.7%를 기록한 GPT-5.6 Sol, 그리고 51.8%를 기록한 Fable 5.1이 함께 나열되어 있습니다. 또한 이 페이지에는 DeepSWE v1.1에서 높은 노력 수준에서 71.0%, EEBench에서 64.0%, AA-Briefcase v1.1에서 1,657을 기록한 결과도 나와 있습니다. 이 수치는 공급업체가 제시한 비교 자료이므로, 독립적인 재현 실험을 대체하는 것이 아니라 공식 보고된 결과로 간주해야 합니다. 보다 신중한 결론은 xAI가 본격적인 코딩 및 전문 지식 작업을 목표로 하고 있다는 점이며, 독립적인 측정 결과에서는 일부 작업에서 의미 있는 개선이 나타난 반면 다른 작업에서는 그다지 두드러지지 않는 결과를 보였습니다.

Grok 4.7 실기 시험 실습: 세 가지 실습 과제

우리는 다음 모델에 대해 세 가지 고정 프롬프트를 적용하여 grok-4.7 2026년 9월 23일, OpenAI 호환 테스트 API를 통해 모델 ID를 확인했습니다. 이는 단일 경로 평가였으며, 직접적인 xAI API 평가도 아니고, 경쟁사 모델과의 비교 테스트도 아니었습니다. 각 실행 결과에서 확인 가능한 답변은 아래에 그대로 제시되어 있으며, 비공개 추론 기록은 제외되었습니다.

지연 시간 수치는 이 경로와 이 프롬프트에만 해당됩니다. 코딩 작업은 처음에 비스트리밍 게이트웨이 타임아웃이 발생했으나, 이후 스트리밍을 활성화하여 완료되었습니다. 이는 전송 및 타임아웃 처리에 관한 실질적인 배포 경고일 뿐, Grok 4.7 속도 점수를 나타내는 것이 아닙니다.

테스트 1: TypeScript 동시성 디버깅

과제 1 — TypeScript API 핸들러 동시성 디버깅

작은 규모의 TypeScript 핸들러에서 두 개의 요청이 짧은 시간 간격으로 도착할 때, 간헐적으로 본문이 비어 있는 HTTP 200 응답을 반환합니다.

제공된 파일:

src/cache.ts
```ts
let current: Promise | null = null;

export async function getPayload(load: () => Promise): Promise {
  if (!current) {
    current = load();
  }
  const value = await current;
  current = null;
  return value;
}
```

src/handler.ts
```ts
import { getPayload } from './cache';

export async function handler(load: () => Promise) {
  const payload = await getPayload(load);
  return { status: 200, body: payload };
}
```

실제 환경에서 나타나는 증상은 두 요청이 겹칠 때만 간헐적으로 발생합니다. 로더 자체는 동시 호출해도 안전하며, 각 요청마다 서로 다른 페이로드를 반환합니다. 다른 파일은 없습니다.

다음 섹션만을 정확히 제시하십시오:
1. 근본 원인
2. 가장 작은 안전한 패치 (통합 diff 표시)
3. 회귀 테스트 2개 (TypeScript 또는 Jest 스타일 코드)
4. 가정 및 제한 사항
코드를 실행했다고 주장하지 마십시오.

1. 근본 원인

`current`는 모든 호출에서 공유되는 모듈 수준의 상태입니다. 자바스크립트의 한 실행 단위 내에서 null 확인과 할당은 원자적이므로, 서로 겹치는 두 호출이 모두 `load()`를 실행하지는 않습니다. 첫 번째 호출은 자신의 프롬라이스를 저장하고, 그 프롬라이스가 해결되기 전에 도착한 두 번째 호출은 자체 `load()`를 건너뛰고 동일한 프롬라이스를 기다립니다. 그러면 `handler`는 두 번째 요청의 페이로드가 아닌 첫 번째 호출의 문자열을 `body`로 가진 HTTP 200을 반환합니다. 이 상황은 호출이 진행 중인 동안에만 발생하므로, 요청이 겹칠 때만 오류가 나타납니다.

`current = null`은 `await`가 이미 프로미스를 캡처한 후 각 연속체에서 실행됩니다. 이는 다른 대기자가 변수를 다시 읽게 만들지 않으므로, 이 파일들만으로는 해당 대기자를 `null`이나 `""`으로 해결하지 않습니다. 중복 발생 시 이 코드들이 실제로 초래하는 결과는 공유된 해결과 요청별 로드 건너뛰기입니다. 또한 이 방식은 슬롯을 비효율적인 단일 실행 캐시로 만듭니다. 재개되는 첫 번째 연속 처리가 `current`를 해제하면, 다른 호출자가 여전히 풀림(unwind) 중인 동안 후속 호출자가 다른 `load()`를 시작할 수 있기 때문입니다.

2. 가장 작은 안전한 패치 (통합 diff 표시)

각 요청은 `load()`를 직접 호출해야 합니다. 병렬 `load()` 호출이 허용되며, 각각 다른 페이로드를 반환하므로 하나의 공유 프로미스에 대한 중복 제거는 안전하지 않습니다. `handler.ts`는 변경할 필요가 없습니다.

```diff
--- a/src/cache.ts
+++ b/src/cache.ts
@@ -1,10 +1,3 @@
-let current: Promise | null = null;
-
 export async function getPayload(load: () => Promise): Promise {
-  if (!current) {
-    current = load();
-  }
-  const value = await current;
-  current = null;
-  return value;
+  return await load();
 }
```

3. 회귀 테스트 2개 (TypeScript 또는 Jest 스타일 코드)

```ts
import { handler } from '../src/handler';

function deferred() {
  let resolve!: (value: T) => void;
  let reject!: (reason: unknown) => void;
  const promise = new Promise((res, rej) => {
    resolve = res;
    reject = rej;
  });
  return { promise, resolve, reject };
}

test('중복 요청 시 각각 실행되고 각자의 본문을 유지함', async () => {
  const first = deferred();
  const second = deferred();
  const started: string[] = [];

  const p1 = handler(() => {
    started.push('a');
    return first.promise;
  });
  const p2 = handler(() => {
    started.push('b');
    return second.promise;
  });

  expect(started).toEqual(['a', 'b']);

  second.resolve('payload-b');
  first.resolve('payload-a');

  await expect(p1).resolves.toEqual({ status: 200, body: 'payload-a' });
  await expect(p2).resolves.toEqual({ status: 200, body: 'payload-b' });
});

test('거부된 중복 요청이 다른 응답에 영향을 주지 않는다', async () => {
  const failed = deferred();
  const ok = deferred();
  let started = 0;

  const p1 = handler(() => {
    started += 1;
    return failed.promise;
  });
  const p2 = handler(() => {
    started += 1;
    return ok.promise;
  });

  expect(started).toBe(2);

  failed.reject(new Error('upstream failed'));
  ok.resolve('payload-b');

  await expect(p1).rejects.toThrow('upstream failed');
  await expect(p2).resolves.toEqual({ status: 200, body: 'payload-b' });
});
```

4. 가정 및 제한 사항

저는 이 코드나 테스트를 직접 실행해 보지 않았습니다. 이 테스트는 Jest 스타일의 러너와 `src/`와 같은 수준에 위치한 파일(예: `test/cache.test.ts`)을 전제로 합니다.

저는 “각 요청마다 다른 페이로드”를, 중복되는 `getPayload` 호출이 하나의 `load()` 결과를 공유해서는 안 된다는 요구사항으로 간주했습니다. 올바른 단일 실행 재작성(`load().finally(() => { current = null; }); return current`)은 여전히 해당 요청들을 결합하게 되므로, 이를 사용하지 않았습니다. 캐시 키는 존재하지 않으며, 중복 제거 요구 사항도 명시되어 있지 않습니다.

`load`가 비어 있지 않은 문자열로 평가되는 경우, 표시된 문장들만으로는 리터럴 빈 HTTP 본문이 작성되지 않습니다. 해당 현상이 이 파일들 외부의 어댑터에서 비롯된 것이라면, 여기서는 확인되지 않습니다. 이 패치는 해당 파일들이 실제로 구현하고 있는 중복 의존성만을 제거할 뿐입니다. 잠금, 재시도 또는 키 기반 캐시를 추가하지는 않습니다.

Grok 4.7은 모듈 수준에서 현재 promise를 사용하면 각 요청마다 고유한 페이로드가 필요함에도 불구하고, 중복되는 요청들이 하나의 로더 결과를 공유하게 됩니다. 이에 따라 가장 최소한의 안전한 변경 사항, 즉 공유되는 promise를 제거하고 다음을 호출하도록 제안했습니다. load() 요청에 따라. 두 가지 회귀 테스트는 서로 다른 동시 페이로드와, 한 로더가 요청을 거부할 때의 격리 문제를 다루었습니다. 이 답변의 가장 뛰어난 점은 절제된 태도였습니다. 즉, 제시된 코드가 요청 간 결합을 입증한다는 점은 분명히 밝혔지만, 로더가 항상 비어 있지 않은 문자열을 반환하는 경우 본문이 문자 그대로 비어 있는 현상을 그 자체만으로는 설명하지 못한다고 명시했습니다.

평결: 근본 원인 정확도, 패치 범위, 회귀 테스트 범위 및 불확실성 처리에 대해 ‘합격’ 판정을 받았습니다.

시험 2: 상충되는 출처를 바탕으로 한 연구 메모

과제 2 — 상충되는 연구 메모를 종합하여 의사결정 메모를 작성하십시오.

다음 여섯 가지 메모만을 사용하되, 모든 사실 진술 옆에 출처명을 명시하십시오:

- 공급업체 A, 가격 페이지, 2026-09-20: 팀 플랜은 좌석당 월 $40이며, 100,000건의 작업이 포함됩니다.
- 공급업체 B, 비교 게시물, 2026-09-21: 공급업체 A의 팀 플랜에는 좌석당 월 120,000건의 작업이 포함됩니다.
- 고객 인터뷰, 2026년 9월 18일: 저희 팀은 8석이며 지난달 710,000건의 작업을 사용했습니다.
- 재무 스프레드시트, 2026년 9월 19일: 현재 예산 상한선은 월 $360입니다.
- 공급업체 A, 한도 페이지, 2026년 9월 20일: 포함된 할당량을 초과한 사용량에 대해서는 액션당 $0.004가 청구됩니다.
- 조달 메모, 2026-09-22: 월간 총량이 예산 범위 내에 머물고 할당량이 확인된 경우에만 전환이 허용됩니다.

다음 섹션을 정확히 반환하십시오:
1. 확인된 사실
2. 귀속된 청구 사항
3. 상충 표
4. 독립적인 계산 (8 × 100,000 및 8 × 120,000 시나리오 모두 계산하고, 초과분도 포함)
5. 권고 사항
6. 상충 사항이 권고 사항을 변경하는 경우에만 한 가지 명확화 질문
100,000 대 120,000의 상충 사항을 묵과하지 마십시오.

1. 확인된 사실
- 팀 플랜은 좌석당 월 $40입니다(공급업체 A, 가격 페이지, 2026년 9월 20일).
- 해당 팀은 8석이며, 지난달 710,000건의 액션을 사용했습니다(고객 인터뷰, 2026년 9월 18일).
- 현재 예산 상한선은 월 $360입니다(재무 스프레드시트, 2026-09-19).
- 포함된 할당량을 초과한 사용량에 대해서는 액션당 $0.004가 청구됩니다(공급업체 A, 한도 페이지, 2026-09-20).
- 월간 총량이 예산 범위 내에 머물고 할당량이 확인된 경우에만 공급업체 변경이 허용됩니다(조달 메모, 2026-09-22).

2. 할당된 청구 항목
- 팀에는 100,000건의 포함된 작업이 포함됩니다(공급업체 A, 가격 페이지, 2026-09-20). 해당 참고 사항에는 “좌석당”이라는 문구가 명시되어 있지 않습니다.
- 공급업체 A 팀에는 월간 좌석당 120,000건의 작업이 포함됩니다(공급업체 B, 비교 게시물, 2026-09-21).

3. 상충 사항 표
| 항목 | 주장 | 출처 | 상태 |
| --- | --- | --- | --- |
| 포함된 액션 | 100,000건의 포함된 액션; “좌석당”이라는 표현은 명시되지 않음 | 공급업체 A, 가격 페이지, 2026-09-20 | 미해결 |
| 포함된 작업 수 | 월간 시트당 120,000건의 작업 | 공급업체 B, 비교 게시물, 2026-09-21 | 미해결 |

100,000건 대 120,000건의 상충 사항은 해결되지 않았습니다. 이 메모만으로는 어느 수치가 정확한지 알 수 없습니다.

4. 독립적인 계산
두 시나리오 모두 동일한 기본 라이선스 비용: 8개 라이선스 (고객 인터뷰, 2026-09-18) × 라이선스당 월 $40 (공급업체 A, 가격 페이지, 2026-09-20) = 월 $320.

아래의 두 배수는 요청에 따라 산출된 것입니다. 이는 공급업체 A가 좌석당 허용치를 명시했다는 결론을 의미하지 않습니다.

- 100,000이라는 수치(공급업체 A, 가격 페이지, 2026-09-20)를 사용하여 8 × 100,000 = 800,000건의 포함된 작업.
- 사용량 710,000(고객 인터뷰, 2026-09-18)은 800,000보다 90,000 적으므로, 초과 사용 횟수 = 0입니다.
- 초과 사용 요금 = 0 × $0.004 = $0 (공급업체 A, 한도 페이지, 2026-09-20).
- 월간 합계 = $320 + $0 = $320이며, 이는 $360 상한선 이내입니다 (재무 스프레드시트, 2026-09-19).

- 120,000이라는 수치를 적용할 경우, 8 × 120,000 = 960,000건의 조치가 포함됩니다(공급업체 B, 비교 게시물, 2026년 9월 21일).
- 사용량 710,000(고객 인터뷰, 2026-09-18)은 960,000보다 250,000 적으므로, 초과 사용 건수 = 0입니다.
- 초과 사용 요금 = 0 × $0.004 = $0 (공급업체 A, 한도 페이지, 2026-09-20).
- 월간 합계 = $320 + $0 = $320이며, 이는 $360 상한선 내에 있습니다(재무 스프레드시트, 2026-09-19).

5. 권고 사항
아직 전환을 승인하지 마십시오. 두 가지 산정된 허용 한도 기준 모두에서, 지난달 710,000건의 작업 (고객 인터뷰, 2026-09-18)는 초과분을 발생시키지 않으며, 월간 합계 $320은 $360 상한선 내에 있습니다(재무 스프레드시트, 2026-09-19). 이러한 비용 결과는 100,000을 선택하든 120,000을 선택하든 상관없습니다. 전환은 여전히 두 번째 조건을 충족하지 못합니다. 할당량은 반드시 검증되어야 하며(조달 메모, 2026-09-22), 이 메모들에는 100,000 (공급업체 A, 가격 페이지, 2026-09-20)과 120,000(공급업체 B, 비교 게시물, 2026-09-21) 간의 상충이 남아 있습니다.

6. 상충 사항이 권고 사항을 변경하는 경우에만 한 가지 확인 질문
확인 질문 없음. 100,000 대 120,000의 상충은 권고 사항을 변경하지 않습니다.

이 연구 자료는 좌석당 허용치가 100,000건인지 120,000건인지에 대해 의도적으로 상반된 내용을 담고 있었다. Grok 4.7은 두 출처를 별도로 다루었으며, 첫 번째 출처에 “좌석당”이라는 표현이 명시적으로 언급되지 않았음을 확인하고, 8석 시나리오 두 가지를 모두 계산한 결과, 제공된 사용량에 대한 초과분 없이 두 경우 모두 $320을 유지하는 것으로 나타났습니다. 그럼에도 불구하고 조달 부서에서 허용량을 검증해야 한다는 점을 근거로 승인을 보류할 것을 권고했습니다. 이는 수치적으로 일관된 권고 사항과 아직 해결되지 않은 계약상 사실 사이를 올바르게 구분한 것입니다.

평결: 귀속, 산술, 갈등 처리 및 의사결정 규율에 대한 탁월한 수행.

테스트 3: 실행 계획에 대한 산만한 메모

과제 3 — 이 산만한 프로젝트 메모를 700단어 미만의 1주일 실행 계획으로 정리하세요.

참고 사항:
- 랜딩 페이지 출시: 금요일 17:00; 제품 소유자는 이후 메모에서 목요일 오전이라고 밝혔습니다.
- 미나: 헤드라인 및 가격표 작성. 미나는 또한 수요일 오후에야 문안을 검토할 수 있다고 밝혔습니다.
- 아르준: 분석 이벤트; 중복된 메모에 따르면 분석 담당자는 미정입니다.
- 디자인 팀에는 “모바일 헤로 크롭”과 “모바일 헤로 크롭 최종”이라는 두 개의 중복된 작업이 있습니다.
- 공개 출시 전 반드시 법적 검토가 이루어져야 합니다.
- QA는 분석 이벤트 데이터가 확보된 후 하루의 시간이 필요합니다.
- 오마르는 화요일 오후에 자리를 비울 예정입니다.
- 출시 이메일 발송은 금요일 16:00로 예정되어 있습니다.
- 미정: 최종 진행/중단 결정 권한이 누구에게 있는지.

요구 사항: 중복된 작업을 그룹화하고, 담당자가 미정인 항목은 ‘TBD’로 표시하며, 두 가지 엄격한 마감 기한을 모두 유지하고, 모순 사항을 묵묵히 해결하기보다는 표시하며, 5가지 항목으로 구성된 위험 목록으로 마무리하십시오.

다음 섹션들을 정확히 그대로 반영하십시오:
1. 1주일 계획
2. 모순 사항 및 미정 사항
3. 5가지 위험 요소
담당자나 날짜를 임의로 추가하지 마십시오.

1. 1주일 계획

메모에 달력 날짜가 없으므로 날짜는 추가하지 않습니다. 명시된 기준점과 종속 관계만 사용합니다. 중복된 디자인 작업은 하나의 작업으로 처리합니다. 담당자가 미정인 항목은 “TBD’로 유지합니다. 충돌하는 출시 일정은 모두 유지합니다.

- 카피: 미나가 헤드라인과 가격표를 작성합니다. 그녀의 카피 검토는 수요일 오후에만 진행됩니다.
- 디자인: 하나의 작업으로, ”최종“ 검토를 포함한 모바일 헤로 이미지 자르기입니다. 별도의 담당자는 지정되지 않았습니다.
- 분석 이벤트: QA 전에 반드시 설정되어야 합니다. 담당자가 확정되지 않았습니다(한 메모에는 아르준, 다른 메모에는 미정(TBD)으로 표기됨).
- QA: 하루 전체 소요되며, 분석 이벤트가 준비된 후에만 진행됩니다. 담당자 미정. 여기에는 QA 일정이 할당되지 않았습니다.
- 법적 검토: 공개 출시 전에 필수입니다. 담당자 미정. 노트에 일정이 기재되어 있지 않습니다.
- 진행/중단 결정: 담당자 미정. 결정된 사항으로 간주되지 않습니다.
- 공개 출시 주요 일정, 두 가지 모두 유지: 목요일 오전(제품 담당자) 및 금요일 17:00(랜딩 페이지).
- 출시 이메일: 금요일 16:00. 담당자 미정.
- 오마르는 화요일 오후에 부재중입니다. 이 메모에 오마르에게 할당된 작업이 없으므로, 이동된 작업도 없습니다.

새로운 일정을 반영하지 않은 순서: 미나의 초안은 수요일 오후 검토를 위해 준비되어야 함; 디자인 팀은 단일 히어로 이미지 크롭 작업을 완료해야 함; 분석 이벤트는 아직 담당자가 정해지지 않은 담당자가 전달해야 함; QA 팀은 그 후 하루 종일 시간을 가짐; 법적 검토는 공개 출시 전에 완료되어야 함; 진행 여부(미정)는 여전히 담당자가 정해지지 않음. 목요일 오전, 금요일 17:00, 금요일 16:00 일정은 절대 변경하지 마십시오.

2. 모순 및 미정 사항

모순 (미해결):
- 랜딩 페이지 출시 시각이 금요일 17:00로 되어 있으나, 이후 제품 소유자의 메모에는 목요일 오전으로 기재되어 있습니다.
- 한 메모에서는 분석 담당자로 Arjun을 명시했으나, 중복된 다른 메모에서는 ”미정’으로 표기되어 있습니다.

미정 사항:
- 최종 진행 여부(go/no-go) 담당자.
- 확정된 분석 담당자.
- 법적 검토 담당자.
- QA 담당자.
- 출시 이메일 담당자.
- ‘디자인’ 이외에 명시된 디자인 담당자.
- 오마르의 역할; 화요일 오후에 부재한다는 사실만 명시되어 있습니다.
- 어떤 출시 시간이 공식적인지, 그리고 금요일 16:00 이메일 발송이 두 시간 중 어느 하나와 일치하는지 여부. 해당 평일 시간 이외의 날짜는 명시되어 있지 않습니다.

3. 다섯 가지 위험 요소

1. 목요일 오전과 금요일 17:00을 모두 랜딩 페이지 출시 시간으로 정할 수는 없습니다. 결정 없이 둘 중 하나를 사용하면 출시가 너무 빨라지거나 다른 마감 시간을 놓칠 수 있습니다.
2. 출시 이메일 발송 시간은 금요일 16:00로 고정되어 있으며, 이는 금요일 17:00보다 앞선 시간이고 메모상 목요일 오전과도 일치하지 않으므로, 페이지가 의도된 상태에 아직 도달하지 않았거나 더 이상 해당 상태가 아닐 때 이메일이 발송될 수 있습니다.
3. 분석 업무 담당자에 대한 이견이 있어 이벤트 기록이 누락될 수 있습니다; QA는 이벤트 종료 후에도 여전히 하루 전체가 필요하므로, 두 출시 시점 중 어느 하나에도 맞출 수 없을 수 있습니다.
4. 공개 출시 전에는 반드시 법적 검토가 선행되어야 하지만, 담당자나 할당된 시간이 정해져 있지 않아 출시가 차단되거나 검토 없이 진행될 수 있습니다.
5. 진행/중단 결정권자가 지정되지 않았으므로, 두 가지 엄격한 마감일 모두 출시를 승인하거나 중단할 책임자가 명시되어 있지 않습니다.

Grok 4.7은 중복된 mobile-hero 작업을 병합하고, 목요일 오전과 금요일 17:00 출시 일정의 충돌을 유지하며, 금요일 16:00 이메일 마감 기한을 그대로 두었으며, 미확정 담당자를 ‘TBD’로 표시하고, 총 5개의 위험 요소를 남겼습니다. 이 버전은 일정 날짜나 담당자를 임의로 추가하지 않았습니다. 약점은 실행 가능성 측면이었습니다. 월요일부터 금요일까지의 일정에 걸쳐 작업을 할당하는 대신, 순서대로 정렬된 종속성 목록을 반환하고 QA 일정을 할당할 수 없다고 답변했습니다. 이러한 신중한 접근은 타당하지만, 프롬프트에서는 1주일 단위의 실행 계획을 요청했기 때문에 이 답변은 요청된 형식을 부분적으로만 충족했습니다.

평결: 부분 통과: 제약 조건 보존은 탁월하지만, 스케줄링 측면에서의 유용성은 다소 떨어짐.

Grok 4.7이 실제 워크플로우에 어떤 변화를 가져오는지

이번 출시를 해석하는 가장 유용한 방법은 이를 워크플로우의 관점에서 바라보는 것입니다. 즉, 지속적인 추론이 검토 작업을 어디에서 줄여주고, 어디에서는 단순히 더 긴 답변을 만들어낼 뿐인지 살펴보는 것입니다. 세 가지 API 과제는 실용적인 패턴을 시사합니다. Grok 4.7은 특히 프롬프트가 사실과 가정을 구분하도록 요청할 때, 여러 제약 조건을 한 번에 명확히 파악하는 데 능숙합니다. 반면, 소스 노트에 완전히 명시되지 않은 구체적인 일정이나 실행 순서가 필요한 과제의 경우, 그 성능은 다소 미흡한 편입니다.

코딩 및 디버깅

리포지토리 작업의 경우, 이 모델은 개방형 “앱 구축” 요청보다는 범위가 한정된 진단 요청에 더 적합합니다. 가장 작은 유용한 파일 세트를 제공하고, 오류 증상을 설명하며, 패치를 적용하기 전에 근본 원인을 요구하십시오. 변경 전에는 실패하고 변경 후에는 통과하는 테스트 사례를 요청하십시오. 우리의 핸들러 테스트에서, 답변은 제공된 코드에 가깝게 유지되었으며, 빈 본문 증상에 대해 외부 원인을 억지로 만들어내는 것을 피했습니다.

이러한 행동이 중요한 이유는 코딩 품질이 단순히 코드를 생성하는 것만이 아니기 때문입니다. 유용한 코딩 대응은 국소적인 설계를 유지하고, 변경 내역(diff)을 최소화하며, 가정을 명확히 밝히고, 검증 비용을 절감해야 합니다. Grok 4.7은 하나의 작은 작업에서 이러한 요소들을 모두 충족시켰지만, 단일 작업만으로는 리포지토리 전체 차원의 신뢰성을 확보할 수는 없습니다. 팀은 실제 버그, 리팩토링, 다중 파일 변경, 보안에 민감한 경로에 대해 동일한 평가 기준을 반복적으로 적용한 후에야 프로덕션 작업을 진행해야 합니다.

연구 및 문헌 종합

이 연구 과제는 또 다른 강점, 즉 ‘출처 경계 준수’를 드러냈다. Grok 4.7은 공급업체가 주장한 10만 건의 조치와 비교 게시물의 12만 건이라는 수치를 아무런 설명 없이 무작정 합치지 않았다. 또한 두 시나리오 모두에서 일관성을 유지하는 계산과 여전히 검증이 필요한 조달 조건을 명확히 구분해 냈다.

이는 연구가 많이 필요한 작업에 적합한 방식입니다. 모델에게 검증된 사실, 출처가 명시된 주장, 해결되지 않은 상충점, 계산 결과 및 권고 사항을 각각 별도로 분류하도록 요청하십시오. 세심하게 다듬어진 메모라도 2차 주장을 출처가 명시되지 않은 사실로 위장한다면 여전히 잘못된 것이 될 수 있습니다. Grok 4.7의 답변은 산술적 결과는 변하지 않았음에도 불구하고 상충점을 명확히 드러냈기 때문에 유용했습니다.

기획 및 운영

계획 단계에서 한계가 더욱 뚜렷해졌습니다. 이 모델은 모든 마감일과 미확인 소유자를 그대로 반영했지만, 월요일부터 금요일까지의 일정을 직접 생성하는 단계까지는 이르지 못했습니다. 이는 날짜를 임의로 정하는 것보다 안전하지만, 사용자가 여전히 종속 관계를 달력 할당으로 변환해야 한다는 것을 의미합니다.

운영 관련 안내 사항에는 계획 기간, 이용 가능한 근무일, 소유자의 가용성, 의사결정권자 등을 포함하십시오. 해당 항목이 누락된 경우, 먼저 종속성 맵을 요청하고 그 다음으로 달력을 요청하십시오. 이러한 두 단계로 진행되는 워크플로를 통해 모델이 제시하는 주의 사항을 단순히 결단력 부족으로 간주하지 않고 유용하게 활용할 수 있습니다.

긴 문맥 검색

50만 단어의 컨텍스트 창은 한 번의 요청에 포함될 수 있는 내용을 바꾸지만, 확인 없이 신뢰할 수 있는 내용은 바꾸지 않습니다. 긴 컨텍스트를 다루는 작업에서는 검색 프로브를 사용해야 합니다. 즉, 패킷의 시작, 중간, 끝 부분에 결정적인 사실을 배치하고, 의도적으로 상충되는 내용을 하나 추가한 다음, 출처 위치와 함께 결정을 요청해야 합니다. 리콜과 경계 준수도를 모두 측정해야 합니다.

긴 컨텍스트 경로를 처리할 때, 단순히 대용량 요청을 수용하는지 여부로만 평가해서는 안 됩니다. 모델이 어떤 사실을 놓치는지, 마지막 섹션에 지나치게 비중을 두는지, 입력 크기에 따라 지연 시간이 얼마나 증가하는지, 그리고 제공자가 요청을 잘라내거나 변환하는지 여부를 기록해 두어야 합니다. 광고된 큰 윈도우는 용량에 대한 주장일 뿐, 한계 상황에서도 안정적인 추론이 보장된다는 의미는 아닙니다.

Grok 4.7을 스스로 평가하는 방법

프로덕션 기본값을 변경하기 전에 소규모의 재현 가능한 테스트 세트를 활용하십시오. 목표는 순위표를 다시 만드는 것이 아니라, 이미 비용을 지불하고 있는 평가 경로 및 검토 프로세스와 모델을 비교하는 것입니다.

1. 입력을 고정하십시오. 정확한 프롬프트, 파일, 소스 패킷, 모델 ID, 온도, 추론 설정 및 도구 권한을 저장하십시오. 프롬프트를 변경하는 동안 직접 경로와 제공자 경로를 비교하지 마십시오.
2. 글의 문체가 아니라 작품 자체를 평가하라. 코딩의 경우, 근본 원인 정확도, 패치 범위, 테스트, 가정 사항에 대해 점수를 매깁니다. 연구의 경우, 인용 범위, 산술적 정확성, 상충 사항, 권고 사항의 품질에 대해 점수를 매깁니다. 계획의 경우, 마감일 준수, 책임 소재, 종속성, 실행 가능성에 대해 점수를 매깁니다.
3. 운송 내역은 별도로 기록하십시오. 첫 토큰 획득까지 걸린 시간, 총 소요 시간, 스트림/비스트림 모드, HTTP 상태 및 재시도 동작을 라우트 로그에 기록하십시오. 게이트웨이 타임아웃이 반드시 모델 품질상의 오류는 아니지만, 여전히 운영 비용으로 간주됩니다.
4. 오류 발생 시 동작을 확인하십시오. 모호한 입력값 하나, 상충되는 출처 하나, 의도적으로 불완전하게 구성된 파일 세트 하나를 포함시킵니다. 여기서 중요한 점은 모델이 불확실성을 표시하는지, 아니면 확신에 찬 추측으로 그 공백을 메우는지 여부입니다.
5. 비용과 소요 노력을 종합적으로 검토하십시오. 입력 토큰, 출력 토큰, 캐시된 입력, 노출된 추론 토큰, 그리고 사람에 의한 검토 소요 시간을 추적합니다. 검증하는 데 두 배의 시간이 걸리는 응답이 비용 면에서 더 저렴하다고 해도, 실제로는 그렇지 않을 수 있습니다.
6. 전환하기 전에 다시 한 번 수행하십시오. 팀 기본 설정을 변경하기 전에 각 과제를 최소 두 번 이상, 또는 몇 가지 대표적인 예시에 대해 실행해 보십시오. 다른 검토자가 해당 결정을 재현할 수 있도록 원본 답안과 채점 메모를 보관해 두십시오.

이 리뷰에서 다룬 세 가지 실행 결과는 초기 샘플일 뿐, 팀의 평가 세트를 대체하는 것은 아닙니다. 이 결과들은 Grok 4.7이 하나의 코딩 과제, 하나의 소스 충돌 메모, 그리고 하나의 계획 패킷에서 어떻게 작동하는지를 보여줄 뿐이며, 보편적인 순위를 확립하는 것은 아닙니다.

Grok 4.7 가격 및 API 이용

가격 정보는 모델 리뷰가 종종 오해를 불러일으키는 부분입니다. 독자가 접하게 될 수 있는 가격 정보는 적어도 세 가지가 있습니다. xAI의 직접 API 가격, 애그리게이터의 경로 가격, 그리고 소비자 구독 가격입니다. 이 세 가지는 서로 대체할 수 있는 것이 아닙니다.

xAI의 발표에 따르면, Grok 4.7은 Grok 4.6과 동일한 가격 및 속도로 제공됩니다. 출시 페이지에 따르면 표준 모델의 가격은 입력 토큰 100만 개당 $2 그리고 출력 토큰 100만 개당 $6; ‘Artificial Analysis’에서는 동일한 직행 경로 수치를 별도로 나열하고 있으며, 캐시된 입력 토큰 100만 개당 $0.50. xAI는 또한 고속 버전을 사용하면 가격은 두 배이지만 출력 속도도 두 배로 빨라진다고 밝혔습니다. 다음을 사용하세요. 공식 개발자 문서 프로덕션 트래픽을 전송하기 전에 현재 API 계약 및 계정별 이용 가능 여부를 확인하십시오.

OpenRouter의 Grok 4.7 페이지 표시 입력 토큰 100만 개당 $1.60 그리고 출력 토큰 100만 개당 $4.80 해당 경로에 대한 가격입니다. 이는 OpenRouter/공급업체의 가격이며, xAI의 직접 정가에 대한 조정 가격이 아닙니다. 라우팅, 마크업, 캐싱, 제한 사항 및 가용성은 공급업체에 따라 다를 수 있습니다.

경로를 명시하지 않고는 “Grok 4.7의 가격은 얼마인가요?”라는 질문에 대해 확실한 정답을 제시할 수 없습니다. API 구매자라면 다음을 비교해 보시기 바랍니다:

• 입력 및 출력 토큰 비율;
• 캐시된 입력 처리;
• 컨텍스트 및 출력 제한;
• 요금 상한 및 지역별 이용 가능 여부;
• 제공자가 추론 제어 기능을 노출하는지 여부;
• 로그 기록, 보존 및 데이터 처리 관련 용어.

소비자가 서비스를 이용할 때는 API 요금이 X 또는 Grok 구독 요금을 나타낸다고 가정하지 마십시오. 소비자 요금제, API 경로, 제3자 통합 서비스에 따라 액세스 규칙이 다를 수 있습니다.

어떤 API 경로를 선택해야 할까요?

실습 섹션에 사용된 호환 경로는 다음과 같이 반환되었습니다. grok-4.7 그리고 스트리밍을 지원했습니다. 스트리밍이 아닌 인코딩 요청이 스트리밍 재시도가 완료되기 전에 게이트웨이 대기 시간 한도를 초과했습니다. 이러한 관찰 결과는 클라이언트를 설계할 때 유용하지만, 이를 그대로 가져와 xAI 지연 시간에 대한 주장으로 삼아서는 안 됩니다.

Grok 4.7에 접속하는 방법

가장 깔끔한 방법은 다음부터 시작하는 것입니다. xAI 발표 그리고 xAI 개발자 페이지, 그런 다음 Grok Build, Cursor, 직접 API 또는 애그리게이터 중 어떤 것이 필요한지 확인하십시오. xAI에 따르면, Grok 4.7은 Cursor 및 Grok Build, Grok API, 그리고 타사 코딩 하네스, 모델 라우터 및 클라우드 플랫폼을 통해 이용할 수 있습니다. 이러한 구분은 청구 방식, 모델 제어, 개인정보 보호 약관 및 사용 가능한 도구를 결정합니다.

애그리게이터를 사용하는 경우, 해당 모델 페이지를 열어 프로바이더 경로, 토큰 가격, 컨텍스트 제한 및 모델 식별자를 확인한 후 이를 기반으로 모델을 구축해야 합니다. OpenRouter는 문서화된 경로 중 하나이지만, 해당 가격 정보는 xAI 청구 표에 복사해서는 안 됩니다.

하나의 작업 공간에서 여러 모델 계열을 비교해 보고 싶은 독자분들을 위해, GlobalGPT의 다중 모델 작업 공간 프롬프트를 나란히 비교 평가하는 데 유용할 수 있습니다. 이 기사는 not 해당 지역에서는 이미 Grok 4.7 경로가 이용 가능하다고 주장합니다. 확인된 카탈로그 경로의 이용 가능 여부는 별도의 문제이므로, 구매 전에 제품 UI에서 확인해야 합니다.

Grok 4.7 대 ChatGPT, Claude 및 Gemini

이 리뷰에는 Grok 4.7의 세 가지 과제 결과가 포함되어 있지만, ChatGPT, Claude 또는 Gemini와의 비교 결과는 없습니다. “Grok 4.7이 우세하다”는 식의 포괄적인 결론은 여전히 분석이 아니라 마케팅에 불과할 것입니다. 더 나은 판단은 해당 모델을 둘러싼 연구 결과에 달려 있습니다:

그리고 “어떤 AI에 돈을 쓸 가치가 있을까?” 가이드 올바른 구매 판단 기준을 적용합니다. 즉, 어떤 반복적인 업무가 개선되어 구독료나 API 비용을 회수할 수 있을 만큼의 가치를 창출할 수 있는가 하는 질문입니다. 이는 최신 순위표 순위를 쫓는 것보다 훨씬 더 지속 가능한 의사결정 기준입니다.

한계점 및 미해결 문제

Grok 4.7은 출시된 지 얼마 되지 않아 독립적인 전문가들 사이에서 광범위한 합의가 형성되기에는 시기상조입니다. 현재까지 확보된 증거만으로는 몇 가지 의문점이 남아 있습니다:

1. 코딩, 연구, 글쓰기, 다중 모드 과제에 걸친 개선 정도는 어느 정도 일관성이 있는가?
2. 500K 컨텍스트는 한계점에 가까워져도 여전히 신뢰할 수 있는가요, 아니면 그보다 더 일찍 검색 성능이 저하되나요?
3. 가장 높은 수준의 추론 작업은 얼마나 많은 추가 지연 시간을 유발하나요?
4. 어떤 소비자 플랜, 지역, 도구 및 요청 제한이 이 모델을 노출시키나요?
5. 합법적이지만 민감한 기술적 작업에 대해 새로운 안전장치는 어떻게 작용하나요?
6. Direct xAI, OpenRouter 및 기타 제공업체들은 결과나 제한 사항에 있어 실질적으로 다른 결과를 반환하나요?

이러한 질문들은 해당 모델을 배제할 근거가 되지 않습니다. 오히려 워크플로를 전환하거나 비용 절감을 약속하기 전에, 소규모이지만 대표성을 갖춘 평가를 수행해야 하는 이유입니다.

Grok 4.7은 어떤 사람이 사용해야 할까요?

다음과 같은 경우, 먼저 Grok 4.7을 테스트해 볼 가치가 있습니다:

• 오랫동안 코드를 디버깅하거나 기술 자료를 분석하는 일;
• 일반 채팅 창 크기를 초과하는 소스 패킷을 처리하고;
• 어려운 프롬프트에 더 많은 노력을 기울이려는 모델을 높이 평가하며;
• 출력물을 바로 생산 환경으로 전송하는 대신 검토할 수 있으며;
• 직접 API와 애그리게이터의 경제성을 비교하고 있다.

성숙한 통합 기능, 명확하게 문서화된 소비자용 계획, 또는 기존 스택에 포함된 모델에 비해 동일한 작업에서 입증된 우위가 필요하다면 이 모델은 적합성이 다소 떨어집니다. 이러한 경우, 2포인트의 인덱스 향상보다 액세스 및 워크플로 계층이 더 중요할 수 있습니다.

자주 묻는 질문

Grok 4.7이란 무엇인가요?

Grok 4.7은 xAI가 2026년 9월 21일에 출시한 코딩 및 지식 업무용 모델입니다. xAI에 따르면, 이 모델은 Grok 4.6과 동일한 가격 및 처리 속도를 유지하면서도, 어려운 작업에 더 오랜 시간을 할애하고, 작업 결과를 더 꼼꼼하게 검토하며, 새로운 안전 장치 스택을 추가했다고 합니다.

Grok 4.7은 언제 출시되었나요?

xAI는 2026년 9월 21일에 Grok 4.7을 발표했습니다. 출시 현황, 모델 이용 가능 여부 및 API 변경 사항에 대해서는 공식 출시 페이지와 개발자 문서를 참고하시기 바랍니다.

Grok 4.7이 Grok 4.6보다 더 좋은가요?

Artificial Analysis는 지능 지수 46을 보고했는데, 이는 Grok 4.6보다 2포인트 높은 수치이며, AA-Briefcase Elo는 1,657으로 4.6보다 111포인트 높습니다. 이는 유용한 지표일 뿐, 모든 워크플로우에 적용되는 보편적인 결과는 아닙니다.

Grok 4.7의 컨텍스트 창이란 무엇인가요?

Artificial Analysis에 따르면 Grok 4.7 버전의 컨텍스트 윈도우 크기는 50만 토큰입니다. 윈도우 크기가 크다고 해서 완벽한 검색 결과가 보장되는 것은 아니므로, 자료가 방대한 작업을 수행하기 전에 긴 문서 내 여러 지점에 사실을 배치하여 모델을 테스트해 보시기 바랍니다.

Grok 4.7 API의 가격은 얼마인가요?

Artificial Analysis에 따르면, 직접 API 경로의 처리량은 입력 토큰 100만 개당 $2, 출력 토큰 100만 개당 $6이며, 캐시된 입력의 경우 토큰 100만 개당 $0.50입니다. 실제 운영에 사용하기 전에 xAI의 최신 문서를 확인하시기 바랍니다.

OpenRouter의 Grok 4.7 모델 가격은 xAI의 가격과 같은가요?

아닙니다. OpenRouter는 해당 경로의 경우 입력 토큰 100만 개당 $1.60, 출력 토큰 100만 개당 $4.80을 표시합니다. 이는 공급자별 가격이므로 xAI의 직접 API 가격과는 별도로 비교해야 합니다. 또한 OpenRouter는 공급자별 캐시, 지연 시간, 처리량 및 개인정보 보호 관련 항목도 표시하며, 이러한 요소들은 경로의 실질적인 비용에 영향을 미칠 수 있습니다.

Grok 4.7에 어떻게 접속할 수 있나요?

먼저 xAI의 공식 발표와 개발자 문서를 확인한 다음, 소비자용 Grok 제품, 직접 xAI API, 또는 OpenRouter와 같은 애그리게이터 중 하나를 선택하세요. 실제로 사용할 경로의 모델 ID, 리전, 요청 제한, 컨텍스트 및 청구 정보를 확인하세요.

Grok 4.7은 GlobalGPT에서 사용할 수 있나요?

이 리뷰는 GlobalGPT에서 Grok 4.7 경로가 검증되었다고 주장하지 않습니다. GlobalGPT는 사용 가능한 모델 계열을 비교하는 데 활용할 수 있지만, 구매 전 제품 UI에서 최신 카탈로그와 정확한 모델 재고 상황을 확인해야 합니다.

Grok 4.7은 코딩 에이전트에 적합한가요?

에이전트가 가정을 설명하고 테스트를 생성해야 하는 범위 지정 디버깅, 코드 검토, 다중 파일 추론과 같은 영역을 평가해 볼 가치가 있습니다. 실습 코딩 과제는 훌륭했지만, 도구 실행, 리포지토리 편집, 권한 관리, 또는 전체 에이전트 루프는 평가하지 않았습니다.

코딩 시험에 스트리밍이 필요한 이유는 무엇이었나요?

첫 번째 비스트리밍 요청이 테스트 경로의 게이트웨이 대기 시간 한도를 초과했습니다. 스트리밍을 활성화한 상태에서는 동일한 프롬프트가 정상적으로 완료되었습니다. 이는 운영 환경의 클라이언트가 스트리밍과 명시적 타임아웃을 지원해야 하는 이유를 보여줄 뿐, 모든 Grok 4.7 경로가 동일한 지연 시간 특성을 보인다는 것을 증명하는 것은 아닙니다.

500K 컨텍스트 윈도우를 어떻게 테스트해야 할까요?

결단력 있는 사실들을 시작, 중간, 끝에 배치하고 의도적인 상충점을 하나 포함한 고정된 패킷을 사용하십시오. 광고된 최대값에만 의존하지 말고, 여러 입력 크기에서 출처 위치, 기억력, 상충점 처리 능력, 지연 시간을 평가하십시오.

Grok 4.6에서 Grok 4.7로 업그레이드할 가치가 있을까요?

초기 결과는 의미 있는 수준이지만 점진적인 업그레이드를 뒷받침합니다. 독립적인 측정 결과가 개선되었으며, 실제 실행 결과 디버깅과 소스 합성 측면에서 뛰어난 성능을 보였습니다. 자신의 작업에서 검토 작업량이 줄어들거나 정확도가 향상되는 것이 확인되고, 이를 정당화할 수 있는 경로별 비용이 발생했을 때에만 업그레이드를 진행하십시오.

최종 판결

Grok 4.7은 지속적인 노력을 보상하는 코딩 및 지식 업무라는 명확한 목표를 가진, 실질적인 점진적 모델 업그레이드로 보입니다. 공식 발표는 이러한 변화에 대해 설득력 있는 설명을 제시하고 있으며, Artificial Analysis의 초기 수치에 따르면 Grok 4.6에 비해 퇴보하기보다는 개선된 것으로 나타났고, 당사의 API 실행 결과에서도 미미하지만 실질적인 신호가 확인되었습니다. 이 모델은 동시성 버그와 출처 충돌 메모를 특히 잘 처리했으나, 계획 수립 결과는 신중하기는 했지만 요청된 만큼 실행 가능하지는 않았습니다.

솔직한 평가는 아직 잠정적인 단계입니다. 이번 테스트는 특정 테스트 경로를 세 번 단 한 번씩만 실행한 결과이며, 가장 느린 작업의 경우 스트리밍이 지원되지 않는 게이트웨이 타임아웃 이후 스트리밍이 필요했고, 이에 상응하는 경쟁사의 실행 결과나 폭넓은 독립적 합의도 없습니다. 실제 워크플로우에서 어려운 작업 하나를 선정하여, 이미 사용 중인 모델과 결과물 및 검토 시간을 비교한 뒤, 해당 경로별 비용을 감수하고 업그레이드할 가치가 있는지 판단하십시오.