Grok 3는 발표 자료의 수학, 코딩, 지식 벤치마크에서 강한 수치를 보였지만, 베타 성능표만으로 모든 실제 작업에서 우월하다고 결론 내릴 수는 없습니다.
이 글은 2025년 2월 19일 베타 발표 당시 공개된 내용과 수치를 기준으로 읽습니다.
발표 슬라이드에서 높은 점수를 얻었다는 사실은 특정 모델, 설정, 채점 조건에서의 결과입니다. 실무 선택에는 같은 prompt의 반복 안정성, 지연 시간, 출처 검증과 현재 제공 상태를 별도로 확인해야 합니다.
발표에서는 Grok 3의 대규모 모델과 더 작은 Grok 3 Mini를 구분하고, 강화 학습을 이용한 추론과 수학, 코딩 능력을 강조했습니다. DeepSearch는 여러 정보를 찾아 종합하는 검색 기능으로 소개됐습니다.
모델을 비교할 때는 이름만 보지 말고 Beta와 Mini 중 어느 열의 수치인지 확인해야 합니다. 예를 들어 표에서 AIME’24는 Grok 3 Beta 52.2%, Mini 39.7%로 차이가 납니다. 한 변형의 결과를 Grok 3 전체의 동일한 성능으로 읽으면 안 됩니다.
| 벤치마크 | Grok 3 Beta | Grok 3 Mini | GPT-4o | Gemini 2.0 Pro | DeepSeek-V3 | Claude 3.5 Sonnet |
|---|---|---|---|---|---|---|
| AIME’24 | 52.2% | 39.7% | 9.3% | — | 39.2% | 16.0% |
| GPQA | 75.4% | 66.2% | 53.6% | 64.7% | 59.1% | 65.0% |
| LiveCodeBench | 57.0% | 41.5% | 32.3% | 36.0% | 33.1% | 40.2% |
| MMLU-Pro | 79.9% | 78.9% | 72.6% | 79.1% | 75.9% | 78.0% |
| LOFT | 83.3% | 83.1% | 78.0% | 75.6% | — | 69.9% |
| MMMU | 73.2% | 69.4% | 69.1% | 72.7% | — | 70.4% |
| EgoSchema | 74.5% | 74.3% | 72.2% | 71.9% | — | — |
AIME는 수학, GPQA는 대학원 수준의 지식, LiveCodeBench는 코드 생성, LOFT는 128K 긴 문맥, MMMU와 EgoSchema는 멀티모달, 비디오 이해를 다룹니다. 표에서 Grok 3 Beta가 가장 높은 값으로 제시됐지만, 빈칸은 상대 모델의 패배 점수가 아니라 비교값이 실리지 않은 항목입니다.
실제 선택에는 자신이 자주 쓰는 질문을 별도 시험하는 편이 낫습니다. 코드라면 실행 여부, 검색이라면 출처와 날짜, 긴 문서라면 누락률처럼 작업별 실패 기준을 정해야 합니다. 벤치마크 한 열은 이런 운영 조건을 대신하지 못합니다.
발표 당시 DeepSearch는 연구 논문과 데이터베이스 등 여러 정보를 분석해 답을 종합하는 기능으로 소개됐고, 스타십 일정이나 게임 빌드 분석 같은 사례가 제시됐습니다. 검색형 답변을 사용할 때는 결론보다 어떤 자료를 언제 확인했는지를 함께 보는 것이 중요합니다.
같은 발표에는 X Premium+ 대상 베타, 향후 Grok 3 API, 오픈소스 공개, 더 큰 클러스터, AI 게임 스튜디오 계획도 포함됐습니다. 이 중 “출시 예정”과 “공개 예정”은 2025년 2월 당시의 로드맵이지 완료된 기능 목록이 아닙니다. 이 글만 보고 지금의 제공 범위나 가격을 판단하기보다, 실제 사용 화면에서 필요한 기능이 열려 있는지 확인해야 합니다.
먼저 모델 이름이 Grok 3인지 Grok 3 Mini인지, reasoning 설정이 켜졌는지 확인합니다. 다음으로 pass@1처럼 한 번의 답을 채점했는지, 여러 시도 중 정답을 고른 값인지 봅니다. 시험 문제가 공개돼 있었는지와 외부 도구 사용 여부도 비교의 전제입니다. 이 조건이 다르면 같은 AIME라는 열에 있어도 비용과 사용자 경험이 다릅니다.
AIME는 수학 문제, GPQA는 대학원 수준 과학 질문, LiveCodeBench는 코딩 능력을 보는 식으로 과제의 성격이 다릅니다. 세 점수를 평균내 “전체 지능” 하나로 만들기보다 자신의 업무와 가까운 열을 골라야 합니다. 긴 문서 분석, 한국어 작성, 도구 권한처럼 표에 없는 능력은 별도 평가가 필요합니다.
점수 차이가 작다면 seed와 표본 변동도 봐야 합니다. 동일 문제를 여러 번 물었을 때 답이 흔들리는지, 정답이어도 근거가 잘못됐는지, 추론 시간이 얼마나 달라지는지를 기록합니다. 최고 점수 한 번보다 일정한 비용 안에서 재현되는 정답률이 실제 서비스에는 더 중요합니다.
Colossus의 GPU 규모와 짧은 구축 기간은 인프라 성과를 설명하지만 개별 답변의 사실성을 직접 보증하지 않습니다. 큰 compute는 더 큰 모델과 데이터 학습을 가능하게 해도 데이터 품질, post-training, inference 설정과 평가 오염 문제를 대신 해결하지 않습니다.
따라서 “몇 배 더 큰 학습”이라는 설명을 볼 때는 같은 architecture와 data에서 compute만 늘린 ablation이 있는지 확인해야 합니다. 그런 비교가 없다면 규모는 가능한 원인 중 하나일 뿐입니다. 배포 비용도 training GPU 수가 아니라 요청당 token, reasoning 시간, 동시 처리량으로 다시 재야 합니다.
검색형 답변은 어떤 source를 선택했는지, 주장과 source가 실제로 연결되는지, 날짜가 필요한 질문에서 최신 자료를 사용했는지가 핵심입니다. 같은 질문을 일반 답변과 DeepSearch에 주고 누락된 근거, 잘못된 인용, 응답 시간을 비교할 수 있습니다. 긴 답이 더 정확하다고 가정해서는 안 됩니다.
발표 당시의 베타 제공과 향후 API, 오픈소스 계획은 완료 상태가 아닙니다. 이 글의 날짜와 현재 제품 상태를 혼동하지 말고 실제 계정 화면과 공식 안내에서 접근 가능 여부를 확인해야 합니다. Grok 3를 선택할지는 발표 순위보다 자신의 질문 세트에서 정확도, 근거, 지연, 비용이 대안보다 나은지로 판단합니다.
아닙니다. 모델과 reasoning 설정이 다를 수 있으므로 표의 행 이름과 채점 조건을 분리해서 읽어야 합니다.
보증하지 않습니다. 학습 compute는 한 요소이며 데이터, post-training, 추론 설정과 실제 업무 평가가 함께 필요합니다.
답의 길이보다 출처 선택, 주장과 인용의 일치, 자료 날짜, 응답 시간과 잘못된 인용 비율을 확인해야 합니다.
공개 benchmark를 다시 묻기보다 실제 업무에서 이미 정답과 검수 기준이 있는 문제를 모읍니다. 짧은 계산, 긴 문서 근거 찾기, code 수정, 한국어 설명, 최신 자료 검색을 나누고 각 문제의 허용 시간과 source 요구를 적습니다. 모델 이름을 가린 채 결과를 검토하면 발표 이미지의 선입견을 줄일 수 있습니다.
검색이 필요한 질문은 사전 지식 답변과 검색 도구 사용 답변을 구분합니다. 인용된 페이지가 주장을 직접 뒷받침하는지, 서로 다른 날짜의 사실을 섞지 않았는지, 불확실한 내용을 명시했는지를 채점합니다. 코딩 문제는 설명이 아니라 실제 test, 문서 문제는 원문의 근거 위치로 완료를 판정합니다.
마지막 표에는 성공률만 아니라 실패 한 건의 영향과 사람 수정 시간을 둡니다. 평균 점수가 높아도 자신 있게 틀린 답이 잦다면 검토 비용이 커집니다. Grok 3의 선택은 경쟁 모델과 같은 조건에서 이 표를 채운 뒤에 내려야 합니다.
비교 결과를 저장할 때는 질문, model과 mode, 실행 날짜, tool 허용 범위, 원문 답과 사람 판정을 함께 보관합니다. 모델이 갱신되면 같은 세트를 다시 실행해 개선과 회귀를 확인할 수 있습니다. 제품 이름만 기록하면 나중에 어느 version을 평가했는지 알 수 없습니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
