LLM 코딩 비교 실험: 같은 마리오카트 프롬프트로 본 Opus·GPT·Gemini·Grok 차이

핵심 메시지

• Cursor라는 동일한 코딩 도구 안에서 Opus 4.8, Composer 2.5, Kimi 2.5, Gemini 3.1 Pro, Grok build 0.1, GPT 5.5에게 똑같은 마리오카트 제작 프롬프트를 주고 비교했다.
• 규칙은 단 한 번의 핵심 프롬프트와 최대 한 번의 보정 프롬프트, 동일한 에셋·설정·최대 추론 모드, 그리고 파일 하나만 열면 바로 실행되는 '제로 셋업' 조건이었다.
• 1차 결과는 대부분 실망스러웠고 GPT 5.5만 유일하게 플레이 가능한 결과를 냈다.
• 보정 프롬프트 후 클로드 Opus가 사운드·아이템·드리프트·충돌까지 갖춘 가장 완성도 높은 결과로 역전했다.
• 단, Opus는 23분으로 가장 오래 걸렸고 GPT는 그 1/4 시간에 쓸 만한 결과를 냈다는 점에서 속도·품질의 트레이드오프가 드러났다.

쉽게 이해하기

유튜버 Tim은 'Claude Code나 Codex 같은 별도 하네스 대신 Cursor라는 동일한 환경'에서 여섯 개 최신 모델을 같은 조건으로 비교했다. 모델 자체의 차이만 보기 위해 도구를 통일한 것이다. 평가 항목은 코드 품질(AI 모델이 독립 채점), 완료 시간, 파일 수, 코드 줄 수, 그리고 실제 게임이 얼마나 잘 동작하는지였다.

과제는 '재미있고 시각적이며 중간 난이도'라는 기준으로 고른 마리오카트였다. 제작자는 스프라이트 시트와 타일셋, 위험요소 등 에셋과 매니페스트를 미리 준비해 모든 모델에게 동일하게 제공했고, 한 줄짜리 핵심 프롬프트 하나만 주되 결과물이 쓸 수 없을 때만 짧은 보정 프롬프트를 한 번 더 허용했다.

1차 실행 결과는 좋지 않았다. Opus 4.8은 초록 화면만 뜨고 오류로 멈췄고, Composer 2.5도 깨졌다. Gemini 3.1 Pro는 빠르게 동작했지만 조작이 어설펐고, Grok은 사운드는 있었지만 벽을 그대로 통과했으며, Kimi 2.5는 아예 움직이지 않았다. GPT 5.5만 이동·아이템 발사·드리프트가 되며 4등으로 완주까지 가능했지만, 제공된 에셋은 쓰지 않았다.

'플레이가 안 된다, 동작하게 만들어 달라'는 모호한 보정 프롬프트를 한 번 더 주자 판도가 바뀌었다. Opus 4.8은 사운드 효과, 아이템 사용, shift 드리프트, 충돌 처리까지 갖춘 가장 완성도 높은 결과로 올라섰고, 알고 보니 에셋을 분석하는 파이썬 도구까지 만들고 모듈식으로 분리된 자체 게임 엔진을 생성하고 있었다. 나머지 모델은 조금씩 나아지는 정도에 그쳤다.

통계상 시간은 Gemini 3분 56초, OpenAI 6분 15초, Kimi 6분 24초, Composer 8분 45초, Grok 21분, 클로드 23분 18초였다. 클로드는 7~8분이 지나서야 코드를 쓰기 시작했다. 품질 점수는 클로드가 사실상 전 항목 1위였고, 품질에 소요 시간을 반영한 '정규화 속도 점수'에서도 클로드가 1위를 지켰지만 격차는 크게 좁혀졌다. 제작자는 이 실험이 과학적이지 않으며 특정 과제에 한정된 재미 위주의 결과임을 거듭 강조했다.

주요 인사이트

• 한 줄 프롬프트만으로 중간 복잡도의 완성형 앱을 만드는 일은 여전히 최상위 모델에게만 현실적이며, 덜 강력한 모델들은 에셋과 구조를 제대로 처리하지 못했다.
• 1차 실패 후 단 한 번의 보정 프롬프트로 결과가 크게 달라진 점은, 모델 성능만큼이나 '재시도 여지'를 설계에 포함하는 것이 중요함을 보여준다.
• 클로드 Opus의 강점은 단순 결과물이 아니라 에셋 분석 도구와 모듈형 게임 엔진까지 만들어내는 '과제를 넘어선' 접근에서 나왔지만, 그 대가는 23분이라는 긴 실행 시간이었다.
• GPT 5.5는 깔끔한 아키텍처와 견고한 물리 처리로 1/4 시간 만에 쓸 만한 결과를 냈으나 지정 에셋을 사용하지 않는 한계를 보였다.
• 코드 품질 채점에 여러 AI 모델을 동원하고 사람이 다시 검증하는 방식은 단일 평가의 편향을 줄이려는 시도지만, 제작자 스스로 결과를 일반화하지 말라고 못 박았다.

자주 묻는 질문

관련 AI 소식