잘 알려지지 않은 한 단계 위의 문제
2026년에 MLX로 일할 때 숨기기 어려운 문제가 하나 있어. LLM 코딩 도우미에게 MLX 코드를 부탁하면 그럴듯하지만 틀린 답을 자신 있게 내놓곤 해. 존재하지 않는 mx.linalg.det를 쓰거나, 두 버전 전에 바뀐 함수 인자를 제시하거나, 그대로 옮길 수 없는 PyTorch 습관을 섞지. 문법상 올바른 Python처럼 보여도 실행하면 깨져.
이 현상을 LLM 탓으로만 돌리기는 어려워. MLX는 아직 젊고 PyTorch와도 상당히 달라서, 오래된 프레임워크만큼 풍부한 예제가 사전학습 데이터에 들어 있지 않아. torch.tensor.to(device) 예제는 수천 개지만 mlx.core.array 예제는 훨씬 적어. 그러면 모델은 여러 관습을 평균 내다가 그럴듯한 거짓 답을 만들어.
이 레슨은 그런 답에서 살아남는 현장 안내서야. LLM이 만든 MLX 코드는 완성품이 아니라 검증이 필요한 초안으로 다뤄야 해. 아래 절차를 따르면 코드와 판단을 모두 제대로 검증할 수 있어.
환각의 냄새를 맡아
잘못 생성된 MLX 코드에는 자주 보이는 무늬가 있어.
- 존재하지 않는 함수 — LLM은 PyTorch, NumPy, JAX에서 짐작해 그럴듯한 MLX 대응물을 지어내.
mx.linalg.det,mx.tensor,mx.no_grad(),mx.cuda.is_available()가 대표적이야. ‘이 함수가 실제로 있다는 데 돈을 걸 수 있나?’ 싶으면 직접 찾아봐. - 섞여 버린 API —
torch.tensor와mx.array를 한 코드에서 쓰거나,mlx.nn as nn과torch.nn as nn을 동시에 가져오기도 해. 여러 프레임워크의 습관을 이어 붙였다는 신호야. - 낡은 API 이름 — mlx-lm이나 mlx-vlm의 최근 버전에서 이미 바뀐 이름을 써. LLM의 학습 시점은 빠르게 변하는 MLX와 잘 맞지 않아.
- 근거 없이 단정하는 구조 세부값 — ‘양자화의 기본
group_size는 32’라고 말하지만 mlx-lm의 실제 기본값은 64야. 불확실성을 인정하는 대신 빈칸을 숫자로 채운 거지.
검증 절차
- 항상 실행해. 지어낸 함수를 가장 빨리 잡는 방법은 코드를 돌리는 거야. Python의 가져오기 오류는 이럴 때 냉정해서 유용해.
- 실제 소스를 확인해.
mlx_lm의 GitHub 저장소는 함수 이름을 직접 검색하기에 충분히 작아. 의심하면 구현을 찾아. --help와dir()을 써.python -m mlx_lm convert --help는 실제 선택지를 보여 주고, REPL의dir(mlx.core)는 정말 공개된 이름을 알려 줘.- 버전을 밝혀. LLM에 물을 때 ‘mlx 0.31.x 기준’처럼 버전을 앞에 붙여. 문제가 사라지지는 않지만 낡은 예제를 꺼낼 가능성은 줄어들어.
- LLM 답보다 mlx-examples와 mlx-lm 소스를 믿어. 기준은 참조 저장소고, LLM의 설명은 그 기준을 풀어쓴 초안이야.
이 퀘스트의 코드를 다룬 방식
MLX 퀘스트의 모든 코드 블록은 작성 전에 검증 환경에서 실제로 실행했어. 머릿속으로만 컴파일한 게 아니라 출력까지 확인하고 주석에 반영했지. 배우라고 건네는 코드를 믿을 수 있게 만드는 유일한 방법이야. 운영 코드도 똑같이 다뤄. 내보내기 전에 실행해.