Mistral Large 4가 큐브를 완성했다가, 다시 놓치다

저명한 AI 성능 테스터인 Matthew Berman은 최근 Mistral Mistral Large 4에게 브라우저 기반의 대화형 Rubik's Cube 시뮬레이션을 구축하도록 도전했습니다. 이 작업은 정적 이미지 생성을 넘어, 3D 객체를 렌더링하고 사용자 입력에 반응할 수 있는 기능적 코드를 생성할 것을 모델에 요구합니다.

성공적인 시뮬레이션은 시각적 충실도 이상의 것을 요구합니다. 다음을 수행해야 합니다:

• 큐브를 구성하는 27개의 개별 큐비(cubies) 렌더링
• 특정 면을 선택하고 회전하기 위한 사용자 입력 수용
• 복잡한 변환 과정 전반에 걸쳐 각 면의 색상과 위치를 정확하게 유지

초기에 Mistral Large 4는 완전한 카메라 회전이 가능한 시각적으로 설득력 있는 큐브를 제공했습니다. 첫 번째 반복은 유망해 보였지만, 치명적인 결함이 나타났습니다. 큐브의 상태를 무작위로 섞기 위한 "scramble" 버튼이 반응하지 않아 큐브가 계속해서 완성된 상태로 남아 있었습니다. Berman은 이를 자신의 cube test에서의 "실패"라고 설명하며, 시각적 출력과 기능적 상호작용 사이의 격차를 강조했습니다.

Mistral Large 4로부터 기능적인 Rubik's Cube를 얻어내려는 Berman의 두 번째 시도는 좌절스러운 역설을 낳았습니다. 또 다른 반복 작업 후, 생성된 코드는 side rotations을 성공적으로 구현하여 사용자가 의도대로 면을 회전할 수 있게 했습니다. 그러나 이 수정 사항은 새로운 버그를 야기했습니다. 회전할 때마다 큐브 표면의 모든 색상이 사라지는 것이었습니다.

이 결과는 3D 시뮬레이션에서 중요한 차이점을 강조합니다. 카메라는 여전히 큐브 주위를 돌며 역동적인 관점을 제공할 수 있었지만, 이러한 시각적 움직임은 퍼즐의 내부 메커니즘과는 완전히 별개입니다. 면의 위치와 색상 상태를 올바르게 업데이트하려면 렌더링된 지오메트리와 기본 데이터 모델 간의 세심한 동기화가 필요합니다.

도전 과제는 3D transforms, 큐비 식별자, 그리고 렌더링된 재질을 관리하는 데 있습니다. 26개의 보이는 "큐비" 각각은 서로 다른 면과 방향으로 이동하더라도 고유한 식별자와 색상 정보를 유지해야 합니다. Mistral Large 4의 코드로 인해 색상이 사라졌을 때, 이는 동기화가 깨졌음을 시사했습니다. 즉, 큐비는 물리적으로 회전하고 있었지만, 관련된 재질 속성이나 UV 텍스처 매핑(색상이 표면에 적용되는 방식)이 올바르게 업데이트되지 않았거나 덮어쓰여지고 있었던 것입니다.

이것은 단순히 렌더링에 관한 문제가 아니라, 지속적인 state management에 관한 문제입니다. 시뮬레이션은 큐브 중심을 기준으로 모든 큐비의 위치와 방향을 추적하여, 모든 섞기(scramble)와 비틀기(twist) 과정 전반에 걸쳐 색상 정보가 올바른 면에 일관되게 결합되도록 보장해야 합니다. 모델은 반복적인 코드 변경 과정에서 이러한 복잡하고 얽힌 상태를 유지하는 데 어려움을 겪었습니다.

"Mistral Large 4가 내 Rubik's Cube 테스트에서 실패했다"는 Berman의 영상은 LLM 평가에서 종종 간과되는 중요한 미묘한 차이를 드러냅니다. 그는 최종 실패의 원인을 Mistral Large 4 자체가 아니라, 모델과 그 "하네스(harness)" 간의 상호작용으로 돌립니다. 이러한 구분은 복잡한 AI 기반 개발을 이해하는 데 매우 중요합니다.

Harness는 모델에 컨텍스트를 제공하고, 편집 내용을 적용하며, 생성된 코드를 실행하거나 검사하는 자동화된 시스템인 주변 에이전트 워크플로우를 의미합니다. 이 동작은 특히 반복적인 디버깅 과정에서 모델이 무엇을 수정할 수 있는지에 깊은 영향을 미칠 수 있습니다. 예를 들어, Harness가 diff를 잘못 적용하거나, 모델의 지시사항을 오해하거나, 포괄적인 테스트 피드백을 제공하지 못할 수 있습니다.

이 시나리오에서 Mistral Large 4는 측면 회전을 기능하게 하는 코드를 생성했지만, 이후 Harness가 처리하는 과정에서 큐브의 시각적 상태가 손상되어 색상이 사라졌을 가능성이 있습니다. 영상은 결과를 보여주지만 근본 원인을 분리하지는 않으므로, 모델의 추론, 생성된 코드, 편집 적용, 또는 테스트 프레임워크 중 어디에 문제가 있는지 명확하게 단정하기 어렵습니다.

이는 AI 보조 개발에서 점점 커지는 과제를 강조합니다. 바로 모델의 능력과 이를 조정하는 도구의 성능을 분리하는 것입니다. 모델이 정교해질수록 상태 유지, 다중 파일 편집 관리, 정확한 피드백 제공과 같은 Harness의 품질이 병목 현상이 됩니다. Mistral의 지속적인 발전에 대한 자세한 내용은 Mistral AI - Latest News and Model Announcements에서 확인할 수 있습니다. 이러한 구분은 Rubik's cube 테스트와 같은 복잡한 작업이 강력한 모델에서도 실패할 수 있는 이유를 이해하는 데 매우 중요합니다.

Berman의 큐브 테스트는 중요한 차이점을 강조합니다. 정적 코딩 벤치마크나 매력적인 초기 렌더링은 종종 핵심적인 약점을 놓치게 합니다. 상태를 유지하는 대화형 작업은 AI가 여러 턴에 걸쳐 지속적인 데이터, 이벤트 리스너, 실시간 UI 업데이트를 어떻게 처리하는지 보여줍니다. 모델은 훌륭한 초기 코드를 생성할 수 있지만, 사용자가 상호작용하거나 시스템 자체가 코드를 반복할 때 일관성을 유지하지 못할 수 있습니다.

개발자들에게 이는 실용적인 교훈을 줍니다. AI 코딩 도구를 초기 출력물의 스크린샷만으로 판단하지 말고, 엔드투엔드 동작을 기준으로 평가하십시오. 반복적인 상호작용 전반에 걸쳐 성능을 평가하고 워크플로우에 회귀 테스트를 통합하십시오. 이러한 단계들을 통해 AI가 견고하고 유지 관리 가능한 시스템을 구축할 수 있는지, 아니면 단순히 인상적이지만 취약한 시작점만 생성하는지 확인할 수 있습니다.

Rubik's cube 테스트에서 Mistral Large 4의 성능은 시도된 워크플로우의 실패를 여실히 보여줍니다. 모델은 시각적으로 매력적인 대화형 3D 객체를 생성하고, 이후에는 기능적인 회전까지 구현할 수 있었습니다. 그러나 공간 좌표, 상태 동기화, UI 렌더링의 복잡한 상호작용은 Berman이 사용한 반복 프로세스가 감당하기에는 너무 벅찼습니다.

이 단일 데모가 Mistral Large 4가 코딩 능력이 없다는 것을 광범위하게 증명할 수는 없지만, 다중 턴의 상태 유지 코드 생성 과정에서의 어려움을 강조합니다. Berman이 제안한 바와 같이, 문제는 모델 자체의 내재적 능력보다는 모델과 그 Harness 간의 상호작용에 있을 가능성이 높습니다. AI와 운영 환경 사이의 이러한 복잡한 상호작용은 고급 AI 코딩 에이전트에게 여전히 중요한 장애물로 남아 있습니다.

Rubik's Cube 테스트에서 Mistral Large 4는 무엇을 잘못했나요?

첫 번째 버전은 큐브를 렌더링했지만 스크램블 버튼에 반응하지 않았습니다. 이후 반복 버전에서는 면 회전이 가능해졌지만 큐브의 색상이 사라졌습니다.

Mistral Large 4가 Rubik's Cube의 작동 원리를 이해하지 못한 것인가요?

테스트 결과가 그것을 입증하지는 않습니다. 다만 생성된 구현물이 상호작용과 시각적 상태를 함께 유지하는 데 어려움을 겪었음을 보여줄 뿐입니다.

이 테스트에서 “Harness”는 무엇을 의미하나요?

Harness는 편집, 컨텍스트, 코드 실행 및 반복을 관리하는 모델 주변의 도구 및 워크플로우를 의미합니다.

왜 Rubik’s Cube가 까다로운 AI 코딩 테스트일까요?

작동하는 시뮬레이션은 단순히 큐브를 그리는 것을 넘어 3D 렌더링, 면 회전, 제어, 그리고 지속적인 색상 상태를 조정해야 합니다.