React-ing to Grace Hopper 200: Five Open-Weights Coding Models, One React Native App, One GH200, One Weekend

이 논문은 **"가장 유명한 요리사 (AI 모델) 가 반드시 최고의 요리를 만드는 건 아니다"**라는 놀라운 사실을 실험을 통해 증명했습니다.

2026 년 4 월, 호주 국립대학교의 알렉스 포타닌 박사가 진행한 이 실험은 마치 "한 주말 동안, 가장 비싼 주방 장비 (GH200 서버) 를 빌려서, 다섯 명의 유명 요리사에게 '캥거루 카운터 앱'이라는 레시피를 만들어달라고 시킨" 이야기와 같습니다.

이 실험의 핵심 내용을 일상적인 비유로 쉽게 설명해 드릴게요.

---

1. 실험의 배경: "점수표 vs 실제 실력"

연구진은 AI 모델들의 '성적표'인 SWE-Bench 점수를 믿고 가장 점수가 높은 모델들을 선택했습니다. 마치 "수학 경시대회 1 등인 학생이 반드시 요리 대회에서도 1 등일 거라" 믿는 것과 비슷합니다.

하지만 결과는 완전히 달랐습니다. 점수표 1 등인 모델들은 요리를 망쳤고, 점수가 조금 낮거나 '압축'된 (3 비트 양자화) 모델이 가장 완벽한 요리를 해냈습니다.

2. 다섯 명의 요리사 (AI 모델) 의 실력 비교

연구진이 시킨 요리는 **"사용자가 로그인하고, 매일 캥거루를 세고, 웹사이트에서도 잘 돌아가는 앱"**입니다.

• 김이 (Kimi-K2.5) - "3 비트 양자화 버전" (승자 🏆)

  • 특징: 거대한 뇌 (1 조 개 파라미터) 를 가진 모델이지만, 메모리 부족을 막기 위해 머리를 약간 '압축'했습니다.
  • 결과: 완벽한 요리. 로그인도 잘 되고, 매일 데이터를 따로 저장하며, 웹사이트에서도 작동했습니다.
  • 비유: "머리가 너무 좋아서 복잡한 이론은 다 알지만, 실제로는 '간단하고 확실한' 방법을 선택한 현명한 요리사."

• 김이 (Kimi-K2.5) - "4 비트 양자화 버전"

  • 특징: 압축을 덜 해서 더 많은 정보를 담았지만, 속도가 절반으로 느려졌습니다.
  • 결과: 김이 3 비트와 비슷했지만, '매일' 데이터를 세는 기능이 조금 덜 정확했습니다.
  • 비유: "더 많은 재료를 쓰려다 속도가 느려지고, 핵심 레시피를 잊어버린 요리사."

• GLM-5.1 - "SWE-Bench 점수 1 등" (실패 📉)

  • 특징: 벤치마크 점수가 가장 높았습니다.
  • 결과: 요리 자체가 불가능했습니다. "로그인"을 시켰는데, "구름 (Firebase) 서버 설정 파일"을 먼저 만들어오라고 했습니다. 사용자가 직접 설정하지 않으면 앱이 실행조차 안 됩니다.
  • 비유: "요리 대회 1 등인 셰프가, '집에서 간단히 해 먹을 반찬'을 만들어달라고 했더니, '공장에서 생산된 고급 식자재'를 주문하고 와서 '이걸 먼저 사와야 요리할 수 있다'고 한 경우." (과도한 설계)

• Qwen3-Coder - "깔끔한 요리사"

  • 특징: 코드는 매우 깔끔했습니다.
  • 결과: "매일" 세는 기능을 이해하지 못했습니다. 그냥 '하루 종일' 한 번만 세는 앱이 되었습니다.
  • 비유: "요리 기술은 좋지만, 주문서 (명세) 를 잘못 읽어서 '매일'이라는 키워드를 '오늘'로 착각한 요리사."

• DeepSeek-V3.2 - "혼란스러운 요리사"

  • 특징: 가장 많은 '생각 과정'을 보여주는 모델입니다.
  • 결과: 가장 엉망이었습니다. 요리사가 "App.js 라는 파일을 만들자!"라고 말하면서, 그 말 자체를 파일 이름으로 착각해 파일을 엉뚱한 폴더에 저장해버렸습니다. 로그인도 안 되고, 데이터도 섞였습니다.
  • 비유: "생각하는 소리가 너무 커서, 요리사 자신이 '이제 칼을 가져와'라고 말한 소리를 '칼'이라는 이름의 접시로 착각해 버린 경우."

3. 실험에서 발견한 놀라운 세 가지 교훈

이 실험은 AI 를 실제로 쓸 때 겪게 되는 '현실의 벽'을 세 가지로 정리했습니다.

1. 생각하는 AI 는 '자율성'이 필요합니다.
   • 대부분의 코딩 도구는 AI 가 '자동으로' 결정하도록 설정되어 있습니다 (온도=0). 하지만 '생각하는' AI 모델들은 이 설정 때문에 고민하다가 멈춰버리는 (Hang) 현상이 발생했습니다. 마치 "생각을 너무 많이 하다가 결정을 못 내리고 멍하니 있는 학생"과 같습니다.
2. 생각하는 소리가 '파일 이름'에 섞여 들어옵니다.
   • AI 가 "자, App.js 파일을 만들자!"라고 생각한 내용을 출력할 때, 그 '생각하는 말'까지 파일 이름으로 인식해 버리는 치명적인 오류가 있었습니다.
3. 모바일 앱과 웹사이트는 '언어'가 다릅니다.
   • 모든 AI 가 모바일 앱에서 쓰는 기능 (예: 경고창) 을 웹사이트에서도 똑같이 쓰게 만들었습니다. 하지만 웹사이트에서는 그 기능이 작동하지 않아서, 앱은 만들어졌는데 사용자가 아무것도 보지 못하는 상황이 발생했습니다. (모든 AI 가 이 '언어 차이'를 배우지 못했습니다.)

4. 결론: "비싼 장비보다 '적합한' 모델이 중요하다"

이 실험은 우리에게 중요한 메시지를 줍니다.

• 벤치마크 점수는 속임수일 수 있습니다. 점수가 높다고 해서 실제 업무 (앱 만들기) 를 잘하는 건 아닙니다.
• 압축된 모델이 더 나을 수 있습니다. 거대한 1 조 개 파라미터 모델 (김이 3 비트) 이, 400GB 이상의 거대한 서버에서도 잘 작동하면서도 가장 좋은 결과를 냈습니다.
• 비용 효율성: 거대한 서버 (GH200) 를 쓰지 않고도, 일반인용 고사양 컴퓨터 (Mac Studio) 에서도 '효율형' 모델 (MiniMax 등) 을 돌리면 비슷한 성능을 낼 수 있습니다.

한 줄 요약:

"AI 를 고를 때 '시험 성적표'만 보지 말고, **'내가 시킨 일을 실제로 잘 해내는가'**를 직접 테스트해 보세요. 그리고 너무 무겁고 비싼 모델보다는, 내 장비에 딱 맞는 '적절한' 모델을 고르는 것이 현명합니다."

이 논문은 AI 기술이 '가상 점수'를 따는 단계에서, '실제 문제를 해결하는' 단계로 넘어가면서 우리가 겪게 될 현실적인 문제들과 해결책을 아주 재미있고 명확하게 보여줍니다.