평소에는 AutoCAD를 비롯한 CAD에서 동작하는 AI 에이전트를 개인적으로 개발하고 있습니다.

LLM에게 CAD를 어떻게 조작하게 할지 고민하는 과정에서, 제 머릿속에 계속 머무는 것은 "LLM에게는 의도를, 결정론적인 처리에는 기하·검증·상태를 맡긴다"라는 역할 분담입니다.

그러던 중 "AI가 루비크 큐브를 푸는" 영상을 보게 되었습니다.

CAD 에이전트를 다루는 감각으로 보았을 때, AI가 정말로 자력으로 풀고 있는 것인지에 대해서는 약간의 의구심이 들었습니다. 궁금해진 나머지, 직접 루비크 큐브와 그것을 회전시키는 MCP를 준비하여 직접 확인해 보기로 했습니다.

아래 영상처럼, "6면을 맞춰줘"라고 부탁하기만 해도 확실히 6면이 단색으로 맞춰져 갑니다.

그렇다면, 이때 AI는 무엇을 하고 있었을까요?

결론부터 말하자면, "AI가 머릿속으로 해법을 생각했다"라는 의미에서는 풀지 않았습니다.

그리고 그 "풀지 못함"의 정체가 제가 CAD 에이전트를 다루며 매일 부딪히고 있는 문제와 맞닿아 있었기에, 실험 기록으로서 남겨둡니다.

해법을 내놓은 것은 AI가 아니라 라이브러리

이번에 AI에게 전달한 MCP에는 큐브를 조작하기 위한 도구들을 몇 가지 준비했습니다.

관련된 것만 발췌하면 다음과 같은 구성입니다.

요컨대 "판면을 본다", "1수를 돌린다", "완성되었는지 확인한다"만 하는 단순한 도구 세트입니다.

이 상태에서 "6면을 맞춰줘"라고 부탁했을 때, Claude가 실제로 했던 일은 다음과 같았습니다.

• observe_cube로 판면을 읽어들임
• pip install kociemba (루비크 큐브의 기성 솔버(Solver)) - 판면을 kociemba가 요구하는 54글자 형식으로 변환
• kociemba.solve()를 호출
• 돌아온 절차를 한 수씩 rotate_cube로 실행

여기서 돌아온 해법은 이것이었습니다.

SOLUTION: B' U' R' U' B'

루비크 큐브에서 B, U, R은 각각 Back(뒤), Up(위), Right(오른쪽)의 회전 기호이며, '는 역회전을 나타냅니다. 즉 B' U' R' U' B'는 뒤, 위, 오른쪽, 위, 뒤의 면을 차례대로 역회전시키는 5수의 절차입니다.

이 5수를 순서대로 실행하면 큐브는 맞춰집니다.

즉 여기서 Claude가 했던 일은 "솔버를 호출하고, 돌아온 절차를 확인하여 실행하는 것"이었습니다. 해법 그 자체를 내놓은 것은 Claude가 아니라 kociemba였던 것입니다.

AI가 큐브를 풀었다 ≠ AI가 큐브 푸는 법을 생각했다

이것은 비난받을 일이 아니라, 오히려 올바른 판단입니다.
확실하게 풀 수 있는 도구가 있다면 그것을 사용하는 것이 합리적입니다. 실무에서도 그래야 합니다.

다만, "AI가 루비크 큐브를 풀었다"라고 들었을 때, 많은 사람이 상상하는 것은 AI 스스로가 "어떻게 돌려야 맞춰질까"를 생각하며 풀어가는 모습일 것입니다.

그것이 솔버를 호출하여 절차를 실행하는 것과 동일한 것으로 이야기되고 있다는 느낌이 들었기에, 이번에는 솔버 없이 AI 스스로 생각하게 하는 조건으로 풀게 해 보았습니다.

솔버를 금지하고, 동일한 판면을 풀게 하기

동일한 스크램블(B U R U B, 5수로 섞은 판면)에 대해 조건을 변경했습니다.

• 코드를 작성하거나 실행하는 것은 금지
• 외부 솔버 및 라이브러리 이용은 금지
• 해법은 AI 자신의 사고만으로 도출
• observe_cube를 통한 판면 확인은 자유
• rotate_cube는 1회당 1수만 가능
• 최대 150수까지

요컨대 솔버라는 "확실한 처리의 핵심"을 제거하고, 추론만으로 풀게 하는 조건입니다.

결론부터 말하자면, 풀었습니다. 다만 수치는 다음과 같습니다.

이 판면은 적어도 5수면 되돌릴 수 있는 상태입니다.
그것을 AI의 자력으로는 110수를 들여 풀었습니다.
동일한 판면에서 22배의 수입니다.

그 과정이 관찰 기록으로서 흥미로웠기에 아래에 남깁니다.

풀기 전에, 먼저 "규칙을 실험으로 확인하고 있었다"

Claude는 갑자기 풀기 시작한 것이 아니었습니다.

첫 11수를 해법이 아닌 **교정 (Calibration)**에 사용하고 있었습니다.

각 회전(U, R, F, D, L, B)을 한 수씩 실제로 돌리며, 상태(board state)가 어떻게 변하는지 관찰합니다.

그리고 "이 상태 표기법에서는 각 회전 시 어떤 스티커가 어떻게 움직이는가"를 확인하고 있었습니다.

시도한 수는 역수로 되돌려, 스크램블(scramble)을 유지한 채 6면 전부를 조사하는 방식입니다.

본인의 설명은 다음과 같았습니다. (요약)

이 환경의 상태 텍스트가 각 회전 시 구체적으로 어떤 스티커를 어떻게 움직이는지 사전에 확신할 수 없었다. 특히 뒷면과 바닥면에서는 열의 반전이 일어나기 때문에, 회전 법칙을 잘못 이해하면 이후의 예측이 모두 무너진다. 그래서 먼저 신뢰할 수 있는 "머릿속 시뮬레이터"를 확립할 필요가 있었다.

솔버(Solver) 사용을 금지당한 결과, 회전 규칙이라는 토대를 관찰을 통해 수작업으로 다시 구축하고 있었던 것입니다. kociemba를 사용할 때는 전혀 필요 없었던 공정입니다.

"예측 → 1수 실행 → 관찰로 정답 확인"의 반복

토대가 마련된 후에는 초보자용 층별법(Layer-by-layer method)으로 진행합니다.

노란색 십자가 → 노란색 코너 → 중간층 에지 → 최종층 순서입니다.

진행 방식은 일관되었으며, 매번 다음과 같았습니다.

• 맞추고 싶은 조각이 현재 어디에 있는지 관찰한다
• 그것을 목표 위치로 옮기는 절차를 머릿속으로 시뮬레이션한다
• "이 수를 두면 상태는 이렇게 변할 것이다"라고 예측한다
• 1수를 실행한다
• observe_cube로 실제 상태와 예측을 대조한다

숙련된 인간이 손기술을 몸으로 익혀 막힘없이 돌리는 것과는 다릅니다.

그보다는, 배운 매뉴얼을 한 손에 들고 매 수마다 "맞게 하고 있나"를 확인하며 나아가는 초보자의 이미지에 가깝습니다.

지식은 있지만, 운용이 자동화되어 있지 않습니다.

그래서 관찰이라는 보조 바퀴를 항상 필요로 하는 것처럼 보였습니다.

관찰이 암산의 오류를 잡아내고 있었다

이 해법에서 효과를 발휘한 것은 의심할 여지 없이 "매 수마다의 관찰"이었습니다.

도중에 Claude는 어떤 손기술을 머릿속으로 7수 분량 시뮬레이션했을 때, 결과 코너가 "흰색을 포함하지 않으면서 파란색과 초록색(=대색)을 동시에 가진다"는 물리적으로 불가능한 배색을 내놓았습니다.

큐브의 한 조각에 대색이 공존할 수는 없으므로, 이는 내부 시뮬레이션의 실수입니다.

Claude는 이를 깨닫고 "긴 절차를 암산으로 밀어붙이는 것"을 그만두고, "실제 상태에서 실행하고 관찰로 확인하는" 방침으로 전환했습니다. 본인의 말에 따르면,

처음 한 번밖에 상태를 볼 수 없다면 안정적으로 풀 자신이 없다.

교정도 할 수 없고, 100수가 넘는 과정을 한 번도 대조하지 못한 채 머릿속으로만 돌려야 하게 된다.

이 부분이 가장 중요한 포인트라고 생각한다.

이 해법은 LLM이 어려워하는 "긴 절차의 상태 추적"을 머릿속에 담아두지 않고, 관찰이라는 외부 참조에 대신 맡김으로써 성립되었습니다. 이는 Claude 스스로 선택한 진행 방식입니다.

오차가 쌓이기 전에 매 수마다 리셋하고 있습니다.

관찰할 수 없었다면 아마 풀지 못했을 것입니다.

스코어 추이에서 나타나는 솔버와의 차이

스코어(54에서 완성)의 추이를 보면 해법의 구조가 그대로 드러납니다.

22에서 시작하여 골짜기를 거치며 54로 향함

주요 변곡점을 뽑아내면 다음과 같습니다.

22(시작) → 32(제1층) → 37(제2층) → 42(흰색 십자가)
→ 45(코너 방향) → 51(코너 위치) → 54(완성)

흥미로운 점은 그래프가 깔끔하게 우상향하는 것이 아니라, 여러 번 골짜기로 떨어지면서 54에 도달했다는 것입니다. 특히 최종층을 처리하는 중에는 스코어가 일시적으로 크게 떨어지는 국면이 있습니다. 이는 무너진 것이 아니라 손기술 도중의 중간 상태입니다.

솔버가 짧은 해법을 한 번에 내놓는 것에 반해, 자력 해법은 "일단 무너뜨리고 다시 조립하는" 과정을 여러 번 거칩니다. 이 지그재그 형태야말로 양자의 질적인 차이를 나타내고 있다고 생각합니다.

CAD 에이전트와도 맞닿아 있는 이야기

여기까지 보면, 이번 큐브에서 Claude가 했던 일은 결국 "올바른 조작을 올바른 순서로 쌓아 올리는 것"이었습니다.

회전을 한 수씩 겹쳐 나가며 최종적으로 6면을 맞춘다.

이 "조작 이력을 쌓아 올리는" 구조는 3D CAD에서 스케치, 돌출(Extrude), 필렛(Fillet), 구멍 뚫기(Hole) 등으로 이력을 쌓아가는 작업과 상당히 유사한 면이 있습니다.

다만, CAD 쪽이 훨씬 더 어렵습니다.

루비크 큐브는 조작 카테고리로서 기본적으로 "면을 돌리는 것"뿐입니다. 상태 또한 54개의 스티커로서 관찰할 수 있습니다. 그럼에도 불구하고, 솔버(Solver)를 제외하고 스스로 풀게 하면 110수, 약 3시간, 매 수마다 관찰하며 아슬아슬하게 진행하는 줄타기가 되었습니다.

그렇다면, CAD에서 LLM에게 자유롭게 명령을 쌓게 하는 것만으로는 상당히 불안정해질 것입니다. CAD에서는 회전뿐만 아니라 스케치(Sketch), 구속(Constraint), 돌출(Extrude), 필렛(Fillet), 불 연산(Boolean operation), 참조 선택(Reference selection) 등 많은 조작을 올바른 순서로 선택해야 합니다.

이력 트리의 이미지 (출처: monoist)

이번 실험을 통해 제가 특히 필요하다고 느낀 것은 다음 두 가지입니다.

첫 번째는, Observe를 통한 현상황 확인입니다.

Claude가 풀 수 있었던 이유는 매 수마다 observe_cube로 판면을 확인하고, 자신의 예측과 대조할 수 있었기 때문이었습니다. 긴 절차를 머릿속으로만 따라가는 것이 아니라, 조작마다 확정적인 상태를 취득하여 확인하는 메커니즘이 필요합니다.

두 번째는, **확실한 롤백(Rollback)**입니다.

큐브는 실수하더라도 역회전으로 되돌릴 수 있습니다.

하지만 CAD에서는 필렛이나 불 연산처럼 단순한 역조작으로는 되돌리기 어려운 처리도 있습니다. 그렇기에 조작 전의 상태로 확실하게 되돌릴 수 있는 메커니즘이 필요합니다.

이전에 썼던 "CAD를 더럽히지 않는 롤백 설계"에 관한 이야기도 바로 이러한 문제의식에서 나온 것입니다.

정리하면 다음과 같습니다.

이번에 강하게 느낀 점은, LLM에게 "생각해서 조작을 쌓아 올려"라고 맡기기만 해서는 단순한 큐브조차 상당히 힘들다는 것입니다.

큐브에는 kociemba라는 확실한 솔버(Solver)가 있었습니다.

그것을 사용하면 5수 만에 끝날 일이, 솔버를 제외하고 AI에게 맡기면 관찰하고, 망설이고, 확인하면서 110수를 들여서야 겨우 푸는 움직임이 되었습니다.

CAD에서도 마찬가지로 LLM에게 전적으로 맡기는 것이 아니라, 기하학적으로 결정되는 처리, 검증, 상태 관리, 롤백과 같은 부분은 결정론적인 메커니즘에 가깝게 가져갈 필요가 있다고 생각합니다.

경우에 따라서는 태스크의 종류별로 작은 솔버와 같은 처리를 여러 개 준비해 두어야 할지도 모릅니다.

어디까지를 AI에게 맡기고, 어디서부터를 확실한 메커니즘으로 뒷받침할 것인가.

이번 큐브 실험은 그 경계선을 생각하는 데 있어 상당히 좋은 소재였습니다.

마치며

처음의 의문으로 돌아가겠습니다.

"AI가 루비크 큐브를 푸는" 영상을 보았을 때, 제가 걸렸던 부분은 그것이 정말 AI 자신의 능력인가 하는 점이었습니다. 실제로 만들어 확인해 보니 답은 명확했습니다. 역시 **풀고 있었던 것은 AI 자신이 아니라, AI가 호출한 솔버(Solver)**였습니다.

그리고 AI 스스로 풀게 해보니, 적어도 5수면 되돌릴 수 있는 판면에 110수, 약 3시간이 걸렸습니다. 솔버가 있었다면 순식간에 사라졌을 공정, 즉 규칙의 교정, 매 수의 관찰, 수법의 구성, 오류의 검지가 솔버를 제거하자마자 전부 겉으로 드러났습니다.

AI가 큐브를 푸는 영상을 보게 된다면, 한 번 화면 구석에서 pip install이 돌아가고 있지는 않은지 살펴보는 것도 재미있을 것 같습니다. 풀고 있는 것이 AI 자신인지, AI가 호출한 라이브러리인지. 그 차이는 CAD와 같이 "조작 이력을 쌓아가는" 태스크를 AI에게 맡길 수 있을지를 고민할 때 의외로 그대로 적용될 것 같다는 느낌이 듭니다.

회전이라는 한 종류의 동작뿐인 큐브조차 자력으로는 이토록 고전합니다.

여기에 무엇을 준비해야 AI가 안정적으로 쌓아 올릴 수 있을 것인가. 그 답은 아직 찾아가는 중이지만, 생각의 실마리로서 상당히 좋은 소재였습니다.

Huan-ang Gao, Zikang Zhang, Tianwei Luo, Kaisen Yang, Xinzhe Juan, Jiahao Qiu, Tianxing Chen, Bingxiang He, Hao Zhao, Hao Zhou, Shilong Liu, Mengdi Wang, "CubeBench: Diagnosing Interactive, Long-Horizon Spatial Reasoning Under Partial Observations", arXiv:2512.23328, 2025. 루비크 큐브를 소재로 LLM 에이전트의 공간 추론 (Spatial Reasoning), 장기 상태 추적 (Long-horizon State Tracking), 부분 관측 (Partial Observation) 하에서의 탐색을 진단하는 벤치마크. 긴 단계의 태스크에서는 코드 실행 (Code Execution)을 허용한 조건에서도 모든 모델의 합격률이 0%였다고 보고하고 있다. ↩︎

Discussion