본문으로 건너뛰기
블로그로 돌아가기
슈퍼마리오 64 혼합현실, 어디까지 사실일까요? AI 코드 이식 한계 정리 (2026 기준)
[TUTORIAL]

슈퍼마리오 64 혼합현실, 어디까지 사실일까요? AI 코드 이식 한계 정리 (2026 기준)

퀀텀점프클럽 정상록퀀텀점프클럽 정상록14분 읽기2 views

무료 자료

PDF · 무료

마리오 64 사례로 배우는, 옛 시스템을 AI로 옮기는 순서

긴 글을 다 읽기 전에, 실무 가이드부터 먼저 챙겨가세요.

슈퍼마리오 64 혼합현실, 어디까지 사실일까요? AI 코드 이식 한계 정리 (2026 기준)

슈퍼마리오 64가 PICO 헤드셋 혼합현실에서 돈다는 영상은 실재하지만 코드는 공개되지 않았습니다. 90FPS와 AI 활용은 개발자 주장이고, 옛 코드를 옮길 때 지킬 절차는 따로 있어요.

슈퍼마리오 64 혼합현실 영상, 정말 AI가 쉽게 만든 걸까요?

먼저 답부터 드리면, 영상과 보도는 있지만 따라 해 볼 코드가 없어서 "쉬웠다"는 말은 아직 개발자 주장에 머뭅니다. 이 소식을 본 분이라면 이런 질문이 먼저 떠올랐을 거예요. "이거 진짜야?" 그리고 "우리 회사 옛 시스템도 AI로 옮기면 되는 거 아닌가?" 둘 다 자연스러운 반응이에요. 이 글은 확인된 사실과 주장을 나누고, 옛 코드를 AI로 옮길 때의 절차와 한계, 법적 경계까지 차례로 짚습니다.

베를린에서 활동하는 XR 개발자 Lucas Martinic이 2026-10-27 X에 영상을 올렸습니다. 슈퍼마리오 64가 PICO(바이트댄스의 XR 브랜드) 헤드셋의 혼합현실, 곧 현실 공간 위에 가상 물체를 겹쳐 보여 주는 화면에서 돌고, 책상 위에서도 돈다는 내용이에요. X 원글 좋아요는 2026-10-29 수집 시점에 7409개였어요.

한 줄 답: 영상은 실재하고 보도도 두 건 있습니다. 하지만 90FPS, 디컴파일 기반, Opus 5.5 활용은 모두 개발자 주장이고, 코드는 2026-10-29 기준 공개되지 않았어요.

어디까지가 사실이고 어디부터가 주장인가요?

Road to VR(2026-10-28)과 VR.org(2026-10-28)는 둘 다 개발자의 영상과 발언을 근거로 썼고, 독립 기관이 직접 실행해 본 기록은 없습니다. 아래 표는 출처 기록을 말하는 주체별로 나눈 거예요.

항목내용주체
영상 공개2026-10-27 X 게시물, 영상 1개확인된 사실
코드·APK·다운로드2026-10-29 기준 없음, 개인 사이트에는 "Coming soon…"확인된 사실
진짜 3D, 90FPS 네이티브화면이 초당 90프레임으로 돈다는 설명개발자 주장
Opus 5.5 + PICO CLI조합으로 꽤 수월했다("quite straightforward")는 설명개발자 주장
디컴파일 기반Jonas Jakobi의 Quest 3용 구현에서 출발했다가 디컴파일 버전으로 새로 시작기자가 전한 개발자 설명
"no stereoscopic crap"의 뜻교대 프레임이나 깊이 정보로 두 번째 눈 영상을 만드는 꼼수를 안 썼다는 해석기자 해석
진짜 입체 렌더링가능성이 높다는 추정기자 추정
헤드셋 모델, AI 기여 비중, 걸린 시간어느 출처에도 없음확인 불가

Martinic이 X에 쓴 문장은 "Running in real 3D (no stereoscopic crap) natively at 90FPS"입니다. 직역하면 '입체 꼼수 없이 진짜 3D로, 네이티브 90FPS로 돈다'는 말이에요. 다만 "네이티브"가 무엇인지는 본인이 설명하지 않았어요. Road to VR는 이 문구를 AFR이나 깊이 버퍼 꼼수를 쓰지 않았다는 뜻으로 "we take to mean" 읽었고, 진짜 입체 렌더링도 "likely"라는 추정으로만 적었습니다.

VR.org에 따르면 이 사례는 "There is no download and no date" 상태이고, 같은 기사는 "A demo nobody can install proves nothing about a toolchain."이라고 짚었어요. 설치할 수 없는 데모는 도구가 얼마나 쓸 만한지 증명하지 못한다는 말입니다.

90FPS는 원작보다 3배 빨라졌다는 뜻인가요?

아니요, 기준선을 붙여서 읽어야 해요. TASVideos에 따르면 원작은 "Super Mario 64 is a 30 Frame-Per-Second Game"입니다. 개발자 주장이 맞다면 화면은 초당 90프레임이고, 원작 30FPS 대비 3배(90÷30)예요. 이것은 화면 프레임레이트 주장일 뿐, 마리오의 움직임을 계산하는 게임 로직까지 90으로 도는지는 공개되지 않았습니다.

TASVideos는 속도를 프레임당 단위로 정의하고 한 프레임을 1/30초로 둡니다. 원작 물리가 30프레임 단위로 짜여 있다는 뜻이에요. 제 해석으로는, 로직은 그대로 두고 화면만 90으로 그리는 구성이라면 머리를 돌릴 때는 부드러워도 게임 속도가 3배가 되지는 않습니다. 어느 쪽인지는 개발자가 밝히지 않았으니 "3배 빨라졌다"는 표현은 피하는 게 맞아요.

AI와 PICO CLI는 실제로 어떤 일을 했나요?

비유하면 디컴파일은 완성된 요리만 남은 상태에서 레시피를 거꾸로 받아 적은 거예요. n64decomp/sm64 저장소에는 그 레시피(소스 코드)가 있고, 그래픽·사운드 같은 재료(에셋)는 없습니다. Tom's Hardware(2026-10-11)가 보도한 Zune HD 이식도 같은 계열이에요. 저장소 첫 커밋이 "Co-Authored-By: Claude Opus 5.5"로 끝나고, sm64ex에 패치 14개를 얹었다고 합니다.

제 정리로는 이번 사례에서 AI의 몫은 게임을 처음부터 해독한 일이 아니라, 공개된 소스 위에 새 기기용 렌더링·입력·혼합현실 상호작용을 붙이는 플랫폼 작업으로 보는 편이 출처와 맞아요. 사람이 어느 부분을 맡았는지는 공개되지 않았습니다.

PICO CLI는 PICO 공식 개발자 블로그가 2026-09-15 공개한 0.5.0 버전의 명령줄 도구로, 공식 설명은 "a command-line tool PICO built for AI-driven development"입니다. 공식 GitHub 저장소(Apache-2.0)는 Claude Code, Cursor, Codex를 포함한 에이전트 호스트 10종을 지원해요. VR.org는 MCP 서버를 돌리는 이 CLI가 익명 사용 통계를 기본으로 수집한다는 README 문구도 전했습니다. 회사에 들일 때는 이런 데이터 수집 설정부터 확인하세요.

비용도 빼놓을 수 없어요. Good Virtual Reality(2026-08-20)에서 Martinic은 VR 실험용으로 Claude Max 요금제 3개에 월 약 600달러를 쓴다고 말했어요(개발자 발언). 수월했다 해도 공짜는 아니라는 점은 기억해 둘 만합니다.

옛 코드를 AI로 옮길 때 지킬 절차는 무엇인가요?

레거시 코드 이식 절차는 Anthropic 공식 Code Modernization 플러그인 README(2026-09-25 마지막 커밋)가 가장 구체적입니다. 이 문서는 옛 코드베이스를 두고 이해, 승인받는 계획, 새 코드, 그리고 새 코드가 옛 것처럼 동작한다는 증거 4가지를 얻는 것을 목표로 적어요. 절차는 환경 점검, 평가, 구조 지도, 업무 규칙 추출, 사람 검토, 단계 계획, 빌드, 증명, 보안 점검까지 9단계입니다.

옛 코드를 AI로 옮길 때 지킬 절차는 무엇인가요?옛 코드를 AI로 옮길 때 지킬 절차는 무엇인가요?

환경 점검부터 보안 점검까지 9단계를 시범 모듈 하나로 시작해 거친다

자료: github.com · QJC 재구성

핵심 문장은 세 가지예요.

  • "Start with one module or one unit as a pilot, not the whole estate." 모듈 하나를 시범으로 시작하고, 전체를 한꺼번에 건드리지 말라는 뜻입니다.
  • "Nothing edits your legacy source." 원본 소스는 수정하지 않고, 새 코드를 따로 만듭니다.
  • "A person decides at six points, and the plugin never decides them for you." 사람이 6개 지점에서 결정하고, 플러그인은 대신 정하지 않아요.

한계도 같은 문서에 있습니다. "Modernization fails quietly: the new code passes the tests someone wrote, and differs on the inputs nobody thought of." 새 코드가 누군가 써 둔 테스트는 통과하는데, 아무도 생각 못 한 입력에서는 다르게 동작한다는 경고예요. 옛 시스템을 지금 돌릴 수 없으면 기록된 출력과만 비교할 수 있고, 이때 최선의 판정은 "PARTLY PROVEN"(부분 증명)입니다.

이 사례에 대입해 보면(제 분석이에요), 슈퍼마리오 64는 비교가 상대적으로 쉬운 편입니다. 에뮬레이터로 원작을 돌릴 수 있고, 디컴파일 프로젝트는 원본과 같은 ROM을 다시 만드는 것을 목표로 하기 때문이에요. 반대로 마리오를 집어 책상에 놓는 혼합현실 상호작용은 원작에 없는 기능이라 비교할 원본이 없습니다. 새 기능으로 따로 검증해야 하고요. 30프레임 단위 로직을 90FPS 화면에 맞추는 일도 "아무도 생각 못 한 입력"에서 조용히 달라질 수 있는 지점입니다. Good Virtual Reality 체험기(2026-08-20)는 이전 Quest 3판에서 마리오를 성 안으로 보내자 "That's where the magic ended."라고 적었는데, 원인이 프레임이나 로직인지는 출처에 없어요.

우리 회사 레거시 코드에 적용하려면 무엇부터 확인하나요?

위 README와 이번 사례에서 뽑은 7가지입니다. 제 정리이고, 회사마다 항목은 달라질 수 있어요.

  1. 시범 대상은 모듈 하나로 정합니다. 시스템 전체를 한 번에 옮기지 않아요.
  2. 원본 소스는 건드리지 않고, 새 코드는 별도 저장소나 브랜치에서 만듭니다.
  3. 옛 시스템을 지금 돌릴 수 있는지 먼저 확인합니다. 돌릴 수 있으면 같은 입력을 양쪽에 넣어 비교하고, 못 돌리면 기록된 출력과 비교하되 결과를 "부분 증명"으로 보고합니다.
  4. 사람이 결정할 지점을 미리 정하고 담당자를 붙입니다. 6개 지점의 구체 내용은 README 원문으로 확인하세요.
  5. 테스트에 없는 입력(오래된 데이터, 경계값)을 별도로 모아 양쪽에 넣어 봅니다.
  6. 옛 시스템에 없던 새 기능은 비교 대상이 없으니 별도 기준으로 검증합니다.
  7. 쓰려는 AI 도구가 어떤 데이터를 수집하고 어디로 보내는지 README나 약관으로 확인합니다. PICO CLI의 익명 통계 수집이 한 예예요.

결과를 남에게 보여 줄 때도 같은 원칙이 적용됩니다. 재현할 수 없는 결과는 VR.org의 지적처럼 도구에 대해 아무것도 증명하지 못해요. 사내라면 같은 입력과 같은 출력 기록을 문서로 남겨 두세요.

법적으로는 어디까지가 선인가요?

게임의 저작권은 닌텐도에 있고, 디컴파일 저장소는 에셋을 담지 않습니다. n64decomp/sm64 README는 "A prior copy of the game is required to extract the assets."라고 적어요. 게임의 사본이 먼저 있어야 에셋을 뽑을 수 있다는 뜻입니다. 같은 계열 프로젝트(Jakobi의 Quest 3판, Tom's Hardware가 전한 Zune 이식)도 모두 사용자가 공식 ROM을 따로 준비하도록 요구해요(Zune 이식은 자기 카트리지 덤프를 명시). Martinic은 원본 실물 카트리지를 갖고 있다는 면책 문구를 붙였습니다. 이것도 개발자 주장이에요.

닌텐도는 2020-05에 이미 행동한 적이 있어요. PC Gamer(2020-05-08)에 따르면 디컴파일 기반 슈퍼마리오 64 PC 포트가 공개된 직후 닌텐도 측이 파일 호스팅 사이트들에 저작권 신고를 냈고, 신고문은 "The reported file contains an unauthorized derivative work based on Nintendo's copyrighted work."라고 적었습니다. 신고 대상은 실행 파일 배포였어요. 소스 저장소 자체의 법적 지위에 대한 판결이나 공식 입장은 이번 조사에서 찾지 못했습니다.

이번 PICO판이 닌텐도의 허락을 받았다는 근거는 어느 출처에도 없어요. 자기 카트리지 백업의 적법성은 나라마다 다르고, 한국법 검토는 이 글의 범위 밖입니다. 외부에 배포하거나 사업에 쓸 계획이라면 먼저 법률 전문가에게 확인하세요. 이 글은 법률 자문이 아닙니다.

마무리

슈퍼마리오 64 혼합현실 사례에서 확인된 것은 2026-10-27 영상과 두 건의 보도까지입니다. 90FPS와 Opus 5.5 활용, 디컴파일 기반은 개발자 주장이고, 기자의 해석과 추정이 그 위에 얹혀 있어요. 이 사례가 주는 쓸모 있는 교훈은 AI 자체가 아니라 절차예요. 작게 시작하고, 원본을 지키고, 사람이 정할 지점을 남기고, 아무도 생각 못 한 입력을 따로 보는 것입니다.

비슷한 고민을 하는 팀이 많습니다. 우리 회사의 가장 작은 모듈 하나를 골라 위 체크리스트 7개 중 몇 개에 답할 수 있는지 세어 보세요. 그 숫자가 첫 점검 결과가 됩니다.


자주 묻는 질문

슈퍼마리오 64 혼합현실 데모를 누구나 따라 할 수 있나요?

지금은 할 수 없어요. Road to VR는 공개 시점이 정해지지 않았다고 전했고, VR.org는 다운로드도 일정도 없다고 밝혔습니다. 2026-10-29 기준 코드·APK·빌드 방법이 모두 공개되지 않았어요.

90FPS면 게임이 원작보다 3배 빠르게 움직이나요?

그렇게 단정할 수 없어요. 90FPS는 개발자가 밝힌 화면 프레임레이트로, 원작 30FPS(TASVideos 표기) 대비 3배입니다. 게임 로직까지 90으로 도는지는 공개되지 않았습니다.

옛 회사 시스템도 AI로 새 환경에 옮길 수 있나요?

가능성은 있지만 절차가 필요해요. Anthropic의 Code Modernization README는 모듈 하나를 시범으로 시작하고, 원본은 수정하지 않으며, 사람이 6개 지점에서 결정하라고 안내합니다. 옛 시스템을 돌릴 수 없으면 최선의 판정이 "PARTLY PROVEN"이라는 점도 알아 두세요.

PICO CLI는 Claude Code에서만 쓸 수 있나요?

아니요. PICO 공식 GitHub 저장소는 Claude Code를 포함해 Cursor, Codex, GitHub Copilot 등 에이전트 호스트 10종을 지원합니다. 다만 Martinic이 어떤 호스트와 헤드셋을 썼는지는 어느 출처에도 나오지 않아요.


참고 자료