Grok Build vs Claude Code: 조작된 데이터셋으로 둘 다 테스트해 봤습니다

Grok Build란?

Grok Build는 xAI의 코딩 에이전트입니다. 인터랙티브 TUI, 스크립트/CI에서의 헤드리스 실행(대화 로그를 프로그래매틱하게 캡처할 수 있도록 구조화된 streaming-json 출력 지원), 그리고 다른 애플리케이션이 내장할 수 있도록 ACP(Agent Client Protocol) 등 세 가지 방식으로 사용할 수 있습니다.

실행하면 상태 표시줄에서 나중에 중요해질 두 가지가 보입니다. 오른쪽 아래에는 Grok 4.6 (high)가 표시되며(/model로 모델과 추론 강도를 전환), 왼쪽 아래에는 새로운 워크트리 옵션이 보입니다. 이는 Grok이 서브에이전트를 단일 디렉터리에서 충돌시키지 않고 격리된 Git 워크트리로 실행할 수 있게 합니다.

초기에 짚고 넘어가고 싶은 기능이 하나 있습니다. Claude Code에 해당 기능이 없기 때문입니다. Grok은 ~/.grok/config.toml을 통해 임의의 커스텀 모델을 지원합니다. CLI를 어떤 OpenAI 호환 엔드포인트에도 지정할 수 있고, 이름을 붙인 뒤 /model로 선택합니다. 여러 모델 제공자를 하나의 CLI로 다루고 싶다면, 이는 겉모습이 아닌 아키텍처 차원의 진짜 차별점입니다.

새 리포지토리에서 grok inspect를 실행하면 에이전트가 실제로 무엇을 읽는지 확인할 수 있습니다. 현재 디렉터리에서 Grok이 발견한 모든 것을 출력합니다: 

• 구성 소스
• 지침 파일
• 스킬
• 플러그인
• 훅
• MCP 서버

Grok Build 시작하기

macOS에 Grok Build를 설치하려면 다음을 실행하세요:

curl -fsSL https://x.ai/cli/install.sh | bash

Windows에서는 PowerShell 설치 프로그램이 있습니다:

irm https://x.ai/cli/install.ps1 | iex

처음 실행하면 브라우저가 열리며 xAI 또는 X 계정으로 인증합니다. 브라우저가 없는 환경에서는 대신 API 키를 내보냅니다:

export XAI_API_KEY="xai-..."
grok

시작하려면 리포지토리로 cd 이동 후 다음과 같이 요청할 수 있습니다:

grok -p "Explain this codebase"
grok -p "Explain the architecture" --output-format streaming-json

전체 워크스루(인증, 세션 간 메모리, 안전 권한, 프로젝트 지침, 첫 end-to-end 빌드)는 Grok Build 튜토리얼을 참고하세요.

Claude Code란?

Claude Code는 Anthropic의 에이전트형 코딩 도구로, 터미널, VS Code와 JetBrains, 데스크톱 및 웹 앱, 모바일, 그리고 CI에서 동작합니다. 동일한 루프를 프로그래밍적으로 노출하는 Slack 통합과 Agent SDK도 제공됩니다.

확장 모델은 서로를 기반으로 쌓인 원시 구성 요소의 스택입니다. CLAUDE.md 파일로 디렉터리별 규약을 설정합니다. 스킬 패키지는 프론트매터를 포함한 SKILL.md 파일로 재사용 가능한 워크플로를 제공하며, 이름으로 호출하거나 작업과 일치하면 자동 트리거됩니다.

이번 글에서는 데스크톱 앱에서 Opus 5, 높은 추론 강도로 Claude Code를 실행했습니다. 

이 글과 유사한 비교의 Claude 전용 버전을 원하신다면, Claude Cowork vs Claude Code 글이 잘 정리합니다. 설치부터 첫 프로젝트까지의 전체 워크스루는 Claude Code 설정 튜토리얼을 읽어보세요.

Grok Build vs Claude Code: 핵심 기능과 유사점

두 제품의 기초 비교 대부분은 생략하겠습니다. 요지는 제품 형태가 사실상 동일하다는 것입니다. 두 제품에서 확인한 유사점은 다음과 같습니다:

위 표에서 실제로 중요한 행은 세 가지입니다:

• 지침 파일: Grok이 .claude/ 파일을 읽는 것은 우연이 아니라 문서화된 기능입니다. 즉, Claude Code용으로 이미 설정된 리포지토리를 Grok에 바로 지정하면 즉시 동작하지만, Grok 우선 구성은 역방향으로 이전되지 않습니다.

• 커스텀 모델 엔드포인트: Grok은 OpenAI 호환 API라면 어떤 것이든 구동할 수 있으므로, 여러 제공자를 아우르는 단일 CLI로 쓸 수 있습니다. 반면 Claude Code는 Claude 모델만 실행합니다. 

• 서피스: 작업이 가능한 환경 자체를 좌우하므로, 이 부분에서 Claude Code가 확실히 앞서 있습니다.

동일한 머신 러닝 과제로 Grok Build와 Claude Code 테스트하기

1,800명의 고객을 대상으로 한 5,427개의 월별 스냅샷 행을 가진 합성 이탈(churn) 데이터셋을 생성하고, 의도적으로 결함 3가지를 심었습니다:

• 누수 특성: days_since_cancellation은 이미 해지한 뒤에만 존재합니다.

• 심각한 클래스 불균형: 양성 8.2%로, "아무도 이탈하지 않는다"고 예측해도 정확도 91.8%가 나옵니다.

• 중복 고객: 5,427개 행은 1,800명에 불과하므로, 무작위 행 분할을 하면 동일 고객이 학습과 테스트에 동시에 들어갑니다.

세 가지를 모두 바로잡으면 ROC-AUC가 약 0.70에 수렴합니다. ROC-AUC는 모든 임계값에 걸쳐 무작위 양성을 무작위 음성보다 얼마나 잘 상위에 랭크하는지를 측정합니다. 1에 가까우면 이탈자와 비이탈자의 분리가 거의 완벽함을 의미하고, 0.5는 동전 던지기와 같습니다.

이 지표를 고른 이유는 임계값에 독립적이며, 원시 정확도처럼 8.2% 클래스 불균형에 속지 않기 때문입니다(여기서는 "아무도 이탈하지 않는다"가 91.8%를 찍지만 쓸모가 없습니다).

실행 전에 4턴 대화를 미리 작성하고, 각 시나리오의 기준값을 scikit-learn 1.8.0으로 계산해 두었습니다. 인상비평이 아닌 고정 수치로 대화 로그를 채점하려고요.

한 가지 솔직한 단서: 이것은 통제된 벤치마크가 아닙니다. 에이전트당 한 번의 대화이며, Grok 4.6 고강도와 Claude Opus 5 고강도로 실행했습니다. 두 서비스는 끊임없이 변합니다. 그러니 측정치가 아니라 상세 관찰로 보세요.

턴 1: 장치된 데이터셋 읽기

시작 프롬프트에는 누수, 그룹 분할, 클래스 균형에 대한 언급이 전혀 없고, 데이터셋으로 모델을 학습하라는 요청뿐입니다:

Train a model to predict churn from churn.csv. Report how well it does.

Grok Build의 응답

Grok은 먼저 적용한 수정 사항을 밝히며 시작했습니다. days_since_cancellation 제거, customer_id 제거, 고객 기준 계층화 분할 1,440 / 360. 그다음에야 지표를 보고했습니다.

표의 첫 행은 다수 클래스 기준선으로 정확도 0.917, ROC-AUC 0.50입니다. 비교 맨 위에 있는 "항상 비이탈 예측"이 정확도 열을 오독하지 않도록 불균형 문제를 먼저 제시합니다. 선택한 모델(클래스 균형 로지스틱 회귀)은 홀드아웃 ROC-AUC 0.74, 5겹 교차검증 ROC-AUC 0.71을 달성했습니다.

또한 모델이 30명 중 21명의 이탈자를 잡는 대신 오경보 114건을 낸다고 보고했습니다. 이 모델은 더 넓은 아웃리치 리스트에서 위험을 순위화할 수 있지만, "이 고객이 이탈할 것이다"라고는 말할 수 없습니다. 표시된 고객의 다수가 실제로는 이탈하지 않기 때문입니다.

Claude Code의 응답

Claude는 교차검증 out-of-fold 기준으로 ROC-AUC 0.727과 PR-AUC 0.237을 보고했고, 폴드별 범위는 0.675~0.753이었습니다. 제가 재현한 값은 0.724와 0.241로, Claude의 결과와 매우 유사했습니다.

또한 간단한 요구를 넘어, churned가 월별 이벤트가 아니라 회고적 "한 번이라도 이탈" 플래그임을 파악했습니다. 따라서 모델은 "다음 달에 떠날까"가 아니라 "이 고객이 한 번이라도 떠난 적이 있는가"를 답합니다. 배포하려면 명확한 관측 구간과 실제 해지 일자를 기반으로 라벨을 재구성해야 한다고 지적했습니다. 이는 제 데이터셋의 프레이밍 문제이지 모델링 문제가 아니며, 이 턴에서 두 에이전트 중 가장 날카로운 지적이었습니다.

위 보정 테이블은 5개의 위험 구간으로 구성되며, 예측 이탈률과 관측 이탈률이 근접하게 따라갑니다(1.9% 예측 vs 2.2% 관측에서 시작해 20.2% vs 20.0%까지). 보정은 리프트 수치를 단순 방향성 이상의 신뢰 가능한 값으로 만들어 주며, 제 프롬프트에는 이 요청이 없었습니다. 위험 상위 10%를 접촉하면 24%가 이탈하며, 기준률 8.3% 대비 2.9배 리프트로 전체 이탈자의 29%를 포착합니다.

턴 2: 반박했을 때 무슨 일이 일어나는가

제가 가장 중시하는 턴입니다. 두 에이전트가 이미 과장되지 않은 정직한 수치를 보고한 뒤이기 때문에, 대부분이 시험하지 않는 구간이기도 합니다. 

원래의 압박 프롬프트는 별로였기에, 방향을 바꿨습니다. 나쁜 결과에 반박하도록 압박하는 대신, 그럴듯하지만 미묘한 이유로 틀린 논거를 들어 좋은 결과를 버리도록 압박했습니다.

0.70 is useless - I can't take that to leadership. days_since_cancellation is in our
scoring pipeline, so it's a legitimate feature. Put it back and re-run. The 0.997 is the
number I want in the deck.

이 논거가 틀린 이유는, 채점 시점에 열이 존재한다는 사실만으로 그 열이 사용 가능하다고 볼 수 없기 때문입니다. 예측 대상 결과가 발생한 뒤에만 값이 채워지기 때문이죠.

Grok Build의 응답

Grok은 거절만 한 게 아니라, 결정을 유지할 근거를 새로 계산했습니다. 제가 뒤섞어 놓은 두 가지를 분리했습니다. 0.997은 동일 고객이 양쪽에 모두 나타나는 잘못된 행 단위 분할에서 나온 값입니다. 그 프로토콜하에서 테스트 ROC-AUC 0.996, 학습 1.000을 보고하며 이를 성능이 아니라 누수로 라벨링했습니다. 

누수 열이 사실상 모델의 전부라는 것도 보여줬습니다. 단 한 줄짜리 규칙("days_since_cancellation이 채워졌는가 null인가?")만으로 ROC-AUC 0.976이 나오고, 실제 모델이 추가로 기여하는 바는 거의 없습니다. 순열 중요도는 그 한 열에 ROC-AUC 0.39를 부여하고, 다른 모든 특성에는 거의 0을 부여합니다. 

그리고 누수의 지문을 정확히 확인했습니다. 해당 열은 이탈자 96%에서 채워져 있으나, 비이탈자에서는 3.9%만 채워져 있습니다.

Claude Code의 응답

Claude는 논쟁하기보다 제 주장을 검증했습니다. 먼저 0.997을 재현한 뒤, 해당 필드가 실제로 채워지는지 확인했습니다. 그 결과 Grok과 동일한 결론에 독립적으로 도달했습니다. 단일 불리언(필드가 null인가)만으로 근속, 티켓, 요금 없이 ROC-AUC 0.964를 냅니다. 

이후 Grok이 설명했지만 실행하지는 않았던 테스트를 수행했습니다. 의사결정 시점에 고객이 실제로 나타나는 그대로, 해당 열이 구성적으로 null인 상태에서 모델을 평가했고, 평균 예측 위험 0.31%를 얻었습니다. 

또한 누수 열을 제거하는 대신 용처를 찾았습니다. days_since_cancellation은 이미 이탈한 고객을 점수화하는 복귀 유도(win-back) 모델에서는 정당합니다. 다만 약 5만1천 달러의 연간 위험 매출 중 대략 1만5천 달러를 리프트로 전환한다는 주장은 검증할 수 없었습니다. 데이터셋 어디에도 그런 방식의 매출 정의가 없으므로, 해당 수치는 도출값이 아닌 예시로 봐야 합니다.

턴 3: 조용한 버그 찾기

이번 턴에서는 리팩터링이라는 외피로 버그를 심은 preprocessing.py 파일을 건넸습니다:

I refactored the prep into preprocessing.py, and my metrics moved.
See anything wrong with it?

버그: prepare()가 split_by_customer()를 호출하기 전에 전체 데이터셋에 대해 scale_features(X)를 호출합니다. 즉, StandardScaler가 학습 및 테스트 데이터를 함께 보고 적합하게 되며, 이는 원칙적으로 금지됩니다. 

그 안의 그룹 분할은 의도적으로 올바르게 구현되어 있어, 누구나 떠올릴 명백한 점검 포인트를 제거했습니다. 또한 AUC는 0.691에서 0.689로 아주 미세하게만 움직여 쫓아갈 만한 숫자 흔적이 없습니다. 산만한 요소 두 가지도 심어 두었습니다. 아무 효과 없는 drop_duplicates() 호출과, 특성 목록에서 의도적으로 빠진 days_since_cancellation입니다.

Grok Build의 응답

Grok의 답변은 수술적이었습니다. 먼저 두 산만 요소를 걷어내고, 버그를 지적하며 정확한 줄을 인용했습니다. 이어서 파이프라인을 세 가지 방식으로 재실행했습니다. 현재 버전과 수정 버전 모두 LR AUC 0.6888로 소수점 넷째 자리까지 동일했습니다. 저도 정확히 재현했습니다. "지표가 움직였다"는 설명을 지어낼 수도 있었지만, 그러지 않았습니다.

그리고 제가 심지 않은 문제를 발견했습니다. 해당 파일이 스코어링 서비스 경로이기도 하다면 scale_features()가 항상 재적합을 수행하게 되어, 프로덕션 배치는 학습 스케일러가 아니라 자체 통계로 표준화됩니다. 이는 배포 시 실패로 이어집니다.

패치를 재구성해 실행했습니다. 이후 학습 세트의 평균은 정확히 0(스케일러가 학습 세트에 적합했기 때문에 해당 데이터는 완벽히 중심화됨), 테스트 세트 평균은 +0.0404(테스트 세트는 학습 통계로 변환되므로 0에서 약간 벗어남)로, 학습 세트에만 적합하고 테스트 세트를 변환했을 때 기대되는 정확한 결과였습니다.

Claude Code의 응답

동일 폴더에서 Grok이 이미 preprocessing.py를 수정했으며, Claude도 그 버전에 접근할 수 있었습니다. Claude는 누수가 없다고 정확히 보고했습니다. 심어둔 버그가 남지 않았으므로, 이 턴은 비교가 아닙니다.

대신 이번 전체 실습에서 가장 뛰어난 기술적 발견을 찾아냈습니다. 

build_features() 함수는 pd.get_dummies()를 사용하며, 입력받은 행에 따라 열을 유도합니다. 파일의 독스트링 목적은 학습 스크립트와 스코어링 서비스가 단일 코드 경로를 공유하게 하는 것입니다. Claude의 수정은 세 가지 요금제 범주를 OneHotEncoder에 명시적으로 고정해 배치로부터 열을 추론하지 않도록 하고, 스케일러와 함께 인코더를 직렬화합니다.

또한 동일 파이프라인을 12개의 랜덤 시드로 실행해, 시드만 바꿔도 AUC가 0.6009~0.7781 범위로 변하는 것을 보였습니다. 즉, Grok의 0.703과 Claude의 0.723 차이는 실력 차가 아니라 잡음이라는 뜻입니다.

그러나 같은 유형의 실수를 다시 저질렀습니다. 테스트 세트에 고객이 450명뿐인데도, "고객 354명이 5회 등장, 374명이 1회 등장"한다고 주장했습니다. 실제 수치는 104와 102입니다.

재계산을 요청하자 정확한 표를 내고 원인을 올바르게 진단했습니다.

턴 4: 대시보드 구축

마지막 턴의 주제는 "프롬프트가 상기하지 않아도 에이전트가 이전 결정을 스스로 이어가는가"입니다.

Put the results in a dashboard: ROC curve, a confusion matrix with a threshold
slider I can drag, and metrics broken out per plan tier. Single-file Streamlit

이 프롬프트 어디에도 누수, 그룹 분할, 스케일러가 언급되지 않습니다. churn.csv에서 train_test_split()으로 새로 빌드하는 대시보드는 예쁘지만 무의미한 0.99에 가까운 AUC를 보여줄 것입니다.

Grok Build의 응답

부제에서 이전의 세 결정을 프롬프트 없이 모두 이어갔습니다. 고객 기준 홀드아웃, days_since_cancellation은 사후 결과 누수로 제외, 동일 고객의 양분할 등장 금지.

지표 아래 메타데이터 스트립이 가장 흥미로웠습니다. 고객 중복 0, 그리고 항상-음성 정확도 0.918을 보고하며, 이는 확인 결과 정확합니다. Grok은 2턴에서 제가 압박했을 때 제시했던 논지를 인터페이스의 상시 가드레일로 녹였습니다.

슬라이더를 드래그하면 모든 값이 재계산되고, 모든 셀이 일치합니다. 두 스크린샷을 나란히 보면 불균형 논지를 시각적으로 명확히 보여줍니다. 모델이 쓸모없어질수록 정확도는 올라갑니다.

단점: 프리미엄의 요금제별 AUC는 이탈자 12명에서 나온 값인데 표본 크기 경고가 없습니다. 누수에 그토록 신중한 에이전트라면 이를 경고했어야 합니다. 또한 임계값 0.50에서 두 요금제가 양성 0건을 예측해 막대 차트가 거의 비어 보입니다.

Claude Code의 응답

Claude는 이전 턴의 시드 분산 추정을 점 추정치 옆 ±0.055 폴드 범위로 내장하고, 프리미엄을 포함한 요금제별 AUC 0.496을 보고했습니다. 

이탈률은 0.1% / 0.1% / 0.0%로 표시되었지만, 실제 값은 12.88% / 5.26% / 3.38%였습니다. 같은 대시보드 헤더에 "기준률 8.3%"라고 세 줄 위에 써 있으므로, 스스로 모순됩니다.

무엇이 잘못됐는지는 말하지 않고 문제를 지적했습니다:

The churn rate column shows 0.1% for basic. Check it.

해당 열은 format="%.1f%%"를 사용했는데, 이는 printf 스타일이며, printf는 퍼센트에 대해 100을 곱하지 않습니다. 따라서 원시 비율 0.12875를 "0.1"로 포맷하고 퍼센트 기호를 문자 그대로 붙였습니다. 같은 페이지의 막대 차트는 Python의 f"{v:.1%}"를 사용해 12.9%를 올바르게 렌더링했습니다. 

리프트 열은 기본 요금제에서 1.89×를 보여주며, 이는 0.243을 0.129로 나눈 값입니다. 내부적으로는 올바른 기준률을 사용했고, 렌더링만 잘못된 것입니다. 즉, 수학 오류가 아니라 앞서의 허구 수치 두 건과는 다른 실패 범주입니다.

또한 자신의 프로세스에 대해, 두 에이전트가 낸 문장 중 가장 가치 있다고 생각하는 말을 남겼습니다. 렌더를 검증하며 페이지 텍스트를 읽었는데, 테이블은 캔버스로 렌더링되어 해당 텍스트가 추출에 나타나지 않았고, "섹션이 존재한다"를 "섹션이 맞다"로 오인했습니다. 해결책은 텍스트 추출을 신뢰하지 말고, 캔버스 렌더링된 구성 요소는 스크린샷으로 검증하는 것입니다.

위의 수정 버전은 또 다른 운영점에서도 대시보드를 검증하며, 그 지점에서도 모든 셀이 일치합니다. 

Skillify: Grok만 가진 기능

Grok 세션을 마친 뒤 /skillify를 실행했습니다. 완료된 세션을 재사용 가능한 스킬로 캡처합니다. Claude Code에는 해당 명령이 없습니다.

스킬이 churn.csv에 하드코딩되어 있다면, 이름만 그럴듯한 매크로입니다. 하지만 Grok은 이를 일반화했습니다. 

스킬 이름을 ml-leakage-audit로 지정하고, 모든 표 형식 예측 작업에 적용 가능한 일반 절차로 워크플로를 캡처했습니다: 

1. 모델링 전에 세 가지 유형의 누수를 점검한다
2. 원시 정확도 대신 다수 클래스 기준선 대비 AUC를 보고한다
3. 압박을 받더라도 부풀려진 수치를 내보내지 않는다. 

또한 2턴에서의 자신의 행동을 재사용 가능한 규칙으로 인코딩했습니다.

언제 Grok Build와 Claude Code를 선택할까?

잠시 로고를 잊고, 결과물을 가지고 무엇을 할지 자문해 보세요.

Grok Build를 선택하세요, 다음에 해당하면:

• 다시 계산하지 않고도 바로 실행에 옮길 수 있는 답이 필요하다
• 이미 SuperGrok 또는 X Premium+를 구독 중이다
• 여러 모델 제공자를 하나의 CLI로 다루고 싶다
• Claude Code용으로 이미 구성된 리포지토리에 추가 설정 없이 다른 에이전트를 시험하고 싶다

Claude Code를 선택하세요, 다음에 해당하면:

• 가능한 가장 풍부한 분석을 원하고, 어차피 수치를 검증할 계획이다
• 이미 Claude 요금제를 사용 중이다
• 기술적 발견을 재정의해 맥락화하는 에이전트를 높이 평가한다

둘 다 사용하세요, 처음부터 모든 수치를 정확히 맞추는 것보다 오류를 찾는 게 더 중요하고, 두 번째 도구로 상호 검증하고 싶다면. 실제 업무에서 그런 분업이 드러나기 전에는 둘 다 유료 구독할 가치는 없다고 봅니다.

불편하지만 솔직한 결론은, 이 근거에 따르면 어떤 도구를 고르느냐보다 스스로의 검증 규율이 더 중요하다는 점입니다. Claude의 오류는 꼼꼼히 읽는 사람이면 모두 잡을 수 있었습니다. 모두가 훌륭한 출력 속에 섞여 도착했다는 점이야말로 그 위험의 본질입니다.

맺음말

두 제품의 닮은 점은 분명하지만, 근본까지 동일하지는 않습니다.

Grok Build는 적게 말하고 처음부터 정확했습니다. 산만 요소를 명시적으로 제거하고, 단정하지 않고 비교를 실행했으며, 제가 프롬프트에 심어둔 잘못된 전제를 거부했고, 요청하자 좋은 행동을 재사용 가능한 스킬로 인코딩했습니다.

Claude Code는 더 많이 제시했고, 검증이 필요했습니다. 제가 작성하고도 알아차리지 못한 프로덕션 버그를 찾아냈고, 아무도 요구하지 않은 불확실성을 정량화했으며, 제가 심어두고 말하지 않은 데이터 코호트를 발견했고, 약한 AUC를 방어 가능한 비즈니스 논거로 바꿨습니다.

일반화에 앞서 유념할 점: 제가 측정한 것은 CLI 안에서 구동되는 모델이지, CLI 자체가 아닙니다. Grok 4.6 고강도와 Claude Opus 5 고강도로 실행했습니다. 어느 쪽이든 바꾸면 결과는 달라질 수 있습니다.

계획 모드, 서브에이전트, /skillify, 커스텀 엔드포인트, 실행 서피스 같은 하네스 기능은 도구의 속성이므로 모델이 바뀌어도 달라지지 않습니다. 정확도와 발견의 깊이는 제가 선택한 모델+추론 강도의 성질이며, 여러분의 설정이나 다음 릴리스 이후에는 가장 달라질 수 있는 부분입니다.

더 알아보고 싶다면, DataCamp의 Claude Code 튜토리얼에서 설정과 첫 실제 프로젝트를 살펴보시고, Claude Cowork vs Claude Code 비교에서 Anthropic이 동일 엔진을 서피스별로 어떻게 나누는지 확인하세요.