Mii QR 코드 포맷: FFL 바이트와 0x04
평범한 휴대폰 스캐너로 Mii QR 코드를 스캔하면 알아볼 수 없는 문자 더미가 나옵니다. 같은 코드를 3DS로 스캔하면 얼굴, 이름, 체형을 갖춘 캐릭터와 함께 '누가 복제하고, 누가 공유하고, 누가 편집할 수 있는지'라는 보이지 않는 규칙까지 한 번에 도착합니다. 이 경험의 격차가 바로 작은 바이너리 공학의 덩어리이고, 우리의 Mii QR Unlocker가 존재하는 이유입니다. 이 글은 도구가 실제로 걷는 길을 따라 포맷을 훑습니다. QR 계층, FFL 데이터 블록, 0x01과 0x04 같은 오프셋의 권한 필드, 그리고 콘솔이 "이 Mii는 편집할 수 없습니다"라고 말하는 정확한 이유까지. 아래의 모든 결론은 도구 안에서 돌아가는 바로 그 디코더에서 나왔습니다. 위키에서 옮겨온 문장은 하나도 없습니다.
첫 번째 의외의 사실: Mii QR 코드는 텍스트가 아니다
일상에서 스캔하는 QR 코드 대부분은 순수 텍스트를 담습니다. URL 하나, Wi-Fi 비밀번호 하나, 식당 메뉴판 하나. Mii QR 코드는 다릅니다. 안에는 Byte Mode 페이로드, 즉 포맷을 아는 콘솔에만 의미가 통하는 날것의 바이너리 덩어리가 들어 있습니다. 휴대폰 스캐너가 이것을 읽으면 바이트열을 어떤 문자 인코딩의 텍스트로 해석하려다 중간에 무너지고, 여러분이 본 적 있는 그 문자 더미를 출력합니다.
기술적 차이는 QR 규격 안에 있습니다. QR 코드는 데이터를 여러 모드로 담을 수 있습니다. 숫자, 영숫자, 바이트, 한자. 일반 텍스트는 UTF-8 페이로드로 영숫자 또는 바이트 모드를 쓰지만, Mii는 바이트 모드를 쓰면서도 페이로드가 애초에 텍스트가 아닙니다. 우리 디코더는 jsQR로 코드를 읽고, 디코딩된 문자열 대신 날것의 binaryData 배열을 가져옵니다. 구현 전체에서 가장 중요한 한 줄이 바로 여기입니다. Mii QR 코드를 문자열로 다루는 순간, 그것은 이미 망가진 것입니다.
코드를 다시 만들 때도 같은 함정이 반대 방향에 서 있습니다. URL용으로 만들어진 QR 생성기는 바이너리를 텍스트 층에 통과시켜 재인코딩하고, 아무렇지 않게 망가뜨립니다. 그래서 우리 인코더는 버퍼를 Byte Mode로, 고정된 QR 버전과 오류 정정 레벨로 통과시키고, 3DS 카메라가 휴대폰 화면에서 안정적으로 읽을 수 있는 크기로 맞춥니다. 바이너리로 들어와 바이너리로 나갑니다. 페이로드가 문자열을 거치는 일은 한 번도 없습니다.
FFL: 모든 미이 뒤에 있는 얼굴 라이브러리
QR 코드 안의 데이터는 FFL(Face Library) 포맷으로 미이를 기술합니다. 닌텐도가 여러 콘솔에 걸쳐 쓰는 캐릭터 렌더링 라이브러리이고, 커뮤니티가 공개 자료로 정리해 왔으며, Wii·3DS·Wii U·Switch 게임이 소비하는 같은 Mii 데이터의 토대입니다. FFL은 미이를 컴팩트한 구조체로 저장합니다. 이름과 성별 같은 식별 필드, 얼굴 부위·체형·색상을 담은 외형 필드들, 그리고 다른 콘솔이 이 캐릭터에게 무엇을 할 수 있는지 통제하는 작은 권한 플래그 블록입니다.
이 포맷의 두 가지 성질이 나머지 모든 내용을 결정합니다. 첫째, 세대를 건너 안정적입니다. 3DS 시절의 Mii QR 코드는 Wii U에서도 읽히고, Switch 게임도 같은 저층 데이터를 소비합니다. 그래서 포맷 해설은 한 번 써두면 오래 씁니다. 둘째, 위치에 극도로 민감합니다. 모든 필드는 블록 시작점으로부터 고정 오프셋에 놓이고, 그 위치는 세대마다 조금씩 밀립니다. 오프셋을 하나만 틀려도 약간 이상한 미이가 아니라 스캔 자체가 안 되는 미이가 됩니다. 이 엄격함이 포맷이 콘솔 교체기를 무사히 넘긴 이유이기도 합니다. 게임은 포맷을 다시 만들지 않고, 캐릭터 데이터를 같은 라이브러리에 넘길 뿐입니다.
헤더 필드 하나씩 보기
도구는 무엇이든 수정하기 전에 블록의 앞쪽 바이트를 읽어 미리보기를 보여 줍니다. 포맷이 정의하는 헤더 필드는 다음과 같습니다:
| 오프셋 | 필드 | 내용 |
|---|---|---|
0x00 | 버전 바이트 | 이 블록이 쓰는 Mii 데이터의 세대 |
0x01 | 옵션 플래그 | bit 0이 복사 허용 플래그이고, 나머지 비트는 비속어 플래그와 지역 잠금을 담습니다 |
0x02–0x03 | 슬롯 헤더 | Mii 스튜디오의 몇 페이지·몇 번 슬롯에 저장됐는지 |
0x04–0x0B | 시스템 ID | 소유 콘솔을 식별하는 8바이트. 편집 제한이 확인하는 필드이며 언록 패스가 다시 쓰는 대상입니다 |
0x18 | 성별·개인 비트 | 성별 비트와 생년월일, 선호 색상 |
0x1A–0x2D | 이름 | UTF-16, 최대 10자, null 종료 |
0x30 | 공유 플래그 | bit 0이 공유 금지 스위치입니다(출처: 3dbrew의 Mii 포맷 문서) |
이름 필드에 한마디 덧붙일 가치가 있습니다. 손으로 바이트를 고치다가 가장 자주 넘어지는 지점이기 때문입니다. '10자'는 '10바이트'가 아닙니다. UTF-16에서 한 글자는 두 바이트이고, 남는 자리는 null로 채우며, 디코더는 첫 null에서 멈춥니다. UTF-8로 이름을 쓰면 일본어든 독일어든 콘솔 위에서 글자가 깨지고, null 종료를 빠뜨리면 이름이 뒤따르는 데이터를 집어삼킵니다.
헤더 뒤쪽이 미이 본체입니다. 얼굴형, 머리, 눈, 눈썹, 코, 입, 안경, 키, 체형, 선호 색상까지 수십 개의 외형 필드가 각자의 비트에 꽂혀 있습니다. 도구는 미리보기를 그릴 만큼만 읽고, 그다음부터는 의도적으로 건드리지 않습니다. 얼굴의 픽셀 하나라도 바꾸는 언록은 신용할 수 없는 언록입니다.
스캔한 미이가 "편집할 수 없습니다"라고 말하는 이유
권한 시스템이 존재하는 이유는 단순합니다. Mii QR 코드는 공유 장치이고, 닌텐도는 '공유의 범위'를 창작자가 정하도록 했습니다. 미이가 콘솔에서 태어날 때 그 선택이 FFL 데이터 안에 플래그로 새겨집니다. 다른 콘솔이 이 QR을 스캔하면 도착한 미이에게는 수신됨 표식이 붙습니다. 콘솔은 원래 만든 이를 작가로 대우하고, 플래그를 읽고, 그대로 집행합니다:
- 복사 허용 — 창작자가 복제를 막아두었다면, 받는 콘솔은 이 미이를 복제하거나 다른 곳에 저장하지 못하게 합니다.
- 공유 금지 — 공유가 꺼져 있으면 이 미이로 새 QR 코드를 만들어 다음 사람에게 넘길 수 없습니다.
- 편집 — 나머지 두 플래그와 무관하게, 받은 미이는 받는 콘솔에서 영원히 편집할 수 없습니다. 편집 권한은 미이가 태어난 콘솔의 소유입니다. 같은 소유 논리가 성격과 목소리 기본값에도 흐르고 있으며, 우리의 음성 합성 가이드가 이를 분해했습니다.
사람을 놀라게 하는 것은 세 번째 규칙입니다. 미이를 스캔하고, 감상하고, 게임에서 쓰는 것은 가능합니다. 그런데 편집기를 열려는 순간 콘솔은 "이 Mii는 편집할 수 없습니다"라고 거절합니다. 고장이 아니라, 플래그가 만든 이의 부탁을 그대로 수행하고 있는 것입니다.
공식 우회로는 딱 하나 있고, 창작자가 복사를 허용했을 때만 작동합니다. 3DS에서 미이를 자신의 Mii 스튜디오로 복사한 뒤 부품부터 다시 조립하는 것. 다시 조립된 미이는 여러분 콘솔 출생이 되고 완전히 편집 가능해집니다. 다만 간단한 수정 수준을 넘기면 번거롭고, 복사 자체가 잠겨 있으면 애초에 불가능합니다. '공식적으로 가능'과 '실전에서 쓸 만' 사이의 이 간극이 모든 언록 도구가 서식하는 공간입니다.
언록 도구가 바꾸는 것, 절대 건드리지 않는 것
필드 지도를 알면 언록 작업이 일부러 작게 설계되었다는 뜻도 보입니다. 도구는 페이로드를 읽고 0x04의 시스템 ID 첫 바이트를 다시 씁니다. 이는 소유 콘솔을 식별하는 정보로, 콘솔이 수신된 미이를 편집할 수 있는지 판단하는 근거입니다. 교체 뒤에는 미이가 더 이상 원래 소유자와 연결되지 않습니다. 이름을 바꾸고 싶다면 같은 패스에서 이름 필드를 올바른 UTF-16으로 다시 씁니다. 이어서 블록을 새로운 Byte Mode QR 코드로 재인코딩합니다. 그 밖의 모든 바이트는 하나하나 그대로 통과합니다.
재인코딩 단계가 들리는 것보다 중요합니다. 새 QR은 바이트 모드로 고정 버전·오류 정정 레벨 M으로 생성되고, 3DS 카메라가 휴대폰 화면에서 읽도록 크기가 조율되어 그려집니다. QR 설정을 잘못 고르면 코드는 멀쩡해 보이는데 정작 겨눈 콘솔은 읽지 않는 일이 생깁니다. 오류 정정 레벨은 스캔 견고성과 데이터 용량을 맞바꾸는 설정이고, Mii 페이로드는 용량 한계 바로 아래를 붙어 다니므로 이 선택은 미관의 문제가 아닙니다.
이 왕복 전체가 브라우저 안에서 끝납니다. 끌어다 놓은 이미지에서 페이로드를 디코딩하고, 메모리에 담아 수정하고, 다시 그려냅니다. 세션 기록은 브라우저 자신의 IndexedDB에 저장됩니다. 중간에 서버가 없습니다. 이것은 프라이버시 배려를 넘어, 도구가 누군가의 미이 복사본을 몰래 보관하는 경로 자체가 존재하지 않는다는 뜻입니다. 여러분의 미이도 마찬가지입니다.
3DS에서 Switch로: 카메라, QR 코드, 액세스 키
오늘날 Mii 공유를 둘러싼 혼란의 대부분은 하드웨어 연혁으로 설명됩니다. 3DS에는 카메라가 두 개 달려 있었고, QR 코드를 스캔하는 일은 그 세대의 기본 동작이었습니다. Mii 스튜디오도, Tomodachi Life도, Miitopia도, 교신 통신도 모두 이 코드를 소비했습니다. Switch는 카메라를 아예 떼어냈습니다. Switch의 Mii 스튜디오는 3DS나 Wii U의 Mii QR 코드를 여전히 읽을 수 있습니다. 다만 그것을 읽어줄 카메라가 이제 없습니다. Switch가 지켜낸 것은 FFL 데이터 그 자체입니다. 그래서 이 글의 포맷 지식이 아직도 유효합니다. 바뀐 것은 공유 계층입니다.
Switch판 Miitopia에서 닌텐도는 QR 코드를 액세스 키로 대체했습니다. 짧은 코드를 입력하면 온라인 서비스에서 미이를 내려받고, 자신의 미이를 공개할 때는 별도의 키가 발급됩니다. Switch 2도 이 방식을 이어갑니다. 액세스 키는 카메라 없음의 문제를 깔끔하게 해결하지만, 같은 권한 철학도 그대로 물려받습니다. 내려받은 미이는 남의 작품이라는 것. 그리고 이 서비스를 지원하는 게임에서만 쓸 수 있습니다.
두 시대를 잇는 실전 다리는 3DS 시절 포맷을 지납니다. Mii QR 코드를 준비하고, 플래그가 닫혀 있으면 언록하고, 카메라 없는 Switch의 Mii 스튜디오로 플레이어들 저마다의 방법으로 넘기는 것입니다. 개조 콘솔에서 에뮬레이트 스캔을 하든, 디코딩된 미리보기를 보고 눈으로 재현하든. 한 번 Switch 위에 미이가 자리 잡으면 그 데이터는 네이티브이고, Switch의 Mii 지원 전부에서 통합니다. 『Tomodachi Life: Living the Dream』에서도 Miitopia에서도. 성격 시스템이 같은 Mii 데이터를 타고 돌기 때문에, 우리의 Tomodachi Life MBTI 매핑 내용은 이식된 캐릭터에게도 그대로 성립합니다.
헥스 에디터로 손수 고치면 대개 실패하는 이유
여기까지 읽었다면 도구를 건너뛰고 헥스 에디터에서 바이트를 직접 뒤집고 싶어집니다. 그곳에는 세 가지 실패 모드가 기다리고 있고, 셋 모두 조용합니다. 파일은 무엇이 잘못되었는지 끝까지 말해 주지 않습니다.
- 1세대가 다르면 오프셋이 다릅니다. Wii, 3DS, Switch 세대마다 필드 위치가 밀립니다. 잘못된 레이아웃을 전제로 만든 패치는 잘못된 바이트를 고칩니다. 그리고 가장 먼저 희생되는 것은 여러분이 건드릴 생각도 없었던 외형 필드입니다.
- 2문자열의 함정. 헥스 에디터는 기본적으로 텍스트로 생각합니다. 페이로드를 열고 이름을 ASCII로 고치고 저장하면, UTF-16 이름 필드는 정렬이 어긋나고 그 뒤의 바이트까지 무너집니다.
- 3재인코딩의 함정. 바이트를 고친 뒤에도 QR 코드를 만들어야 합니다. URL용 생성기는 텍스트 층을 거쳐 인코딩하므로 바이너리 페이로드를 부숩니다. 올바른 버전과 오류 정정 레벨의 Byte Mode 인코더만이 콘솔이 받아들이는 코드를 만듭니다.
전용 도구는 이 세 가지가 원리적으로 일어나지 못하게 하려고 존재합니다. 고정 오프셋, 바이트 모드 입출력, 올바른 인코딩과 패딩으로 쓰이는 이름 필드. 우리의 언록 도구가 문서의 각주가 아니라 한 페이지로 존재하는 이유가 그것입니다.
Mii QR 코드에 대해 사람들이 자주 묻는 질문
Mii QR 코드 언록은 합법이고 안전한가요?
안전성 측면에서는 구조가 여러분 편입니다. 언록이 다시 쓰는 것은 권한 관련 바이트뿐이고 외형 블록은 그대로이므로, 수정된 코드는 '같은 미이 + 새 권한'으로 읽히거나 아예 읽히지 않거나 둘 중 하나입니다. 합법성 측면에서 이 포맷은 커뮤니티가 공개 자료로 정리한 것이고, 도구는 여러분이 이미 가진 Mii 데이터 위에서 동작합니다. 그다음은 모든 팬 활동과 같은 규율을 따릅니다. 원작자를 존중하고, 남의 캐릭터를 내 작품인 양 행세하지 마세요. 수정된 Mii 데이터에 대한 닌텐도의 입장은 콘솔 파일 시스템의 나머지 부분에 대한 입장과 같습니다. 공식 지원 밖의 영역이며, 판단은 각자의 몫입니다.
Miitopia나 스매시브라더스 미이도 되나요?
됩니다. Miitopia와 대난투 스매시브라더스 SPECIAL은 Tomodachi Life나 3DS Mii 스튜디오와 같은 FFL 포맷의 Mii 데이터를 소비합니다. 그래서 어떤 게임용으로 만든 QR 코드는, QR 입력을 받는 콘솔이라면 다른 게임에도 스캔됩니다. 포맷이 공용 언어이고, 게임들은 그 언어의 다른 독자들일 뿐입니다.
콘솔 카메라가 언록된 QR 코드를 못 읽습니다
열 번 중 아홉 번은 데이터가 아니라 광학 문제입니다. 화면 밝기를 최대로 올리고, QR이 프레임을 채우면서도 흐릿해지지 않는 거리를 잡고, 렌즈를 닦고, 천장 조명의 반사를 피하세요. 그래도 안 되면 다시 생성하세요. QR 코드의 스크린샷은 압축 노이즈를 실어 디코딩을 무너뜨릴 수 있습니다. 늘 렌더링된 원본 이미지를 보관하는 것이 정답입니다.
언록된 미이는 게임 안 모습이 달라지나요?
달라지지 않습니다. 외형 블록은 바이트 단위로 통과합니다. 얼굴, 머리, 색상, 키, 이름, 목소리 설정이 모두 창작자가 지정한 그대로 도착합니다. 눈에 보이는 변화는 여러분이 요청한 것뿐입니다. 이름 변경 같은 것이요. 스캔 뒤 모습이 이상하면 어딘가에서 QR 이미지 자체가 손상된 것입니다. 데이터를 의심하기 전에 재생성하고 다시 스캔하세요.
Switch에서 바로 미이를 편집할 수 있나요?
수신된 미이는 안 됩니다. Switch의 Mii 스튜디오는 그 콘솔에서 만든 미이를 편집할 수 있지만, 액세스 키든 스캔이든 외부에서 온 미이는 작가 보호를 위해 잠깁니다. 3DS와 똑같습니다. 편집 가능한 사본으로 가는 길은 여전히 포맷을 거칩니다. 원본 QR을 언록해 로컬에서 편집 가능한 미이로 인식되게 만들고, 여러분의 환경에서 가능한 방법으로 Switch로 옮기면 됩니다.
Switch 2의 새 Mii 시스템은요?
Switch 2는 Miitopia용 액세스 키 방식을 계속 쓰고, 그 밑의 Mii 데이터는 같은 FFL 혈통입니다. QR 코드라는 물리적 공유 매체는 카메라를 단 3DS와 Wii U의 것입니다. 그래서 포맷 이해의 가치는 사라지지 않았습니다. 그 QR 코드가 실어 나르던 데이터가, 오늘 여러분의 Switch 게임이 소비하는 데이터와 같은 것입니다.
원래 권한을 나중에 되돌릴 수 있나요?
원본 QR 이미지를 보관하세요. 언록은 원본 파일을 덮어쓰지 않습니다. 플래그를 연 새 코드를 만들 뿐입니다. 나중에 제한을 되찾고 싶다면 원본 이미지가 여전히 창작자의 설정을 갖고 있으니 그대로 스캔하면 됩니다. 반대로 이미 콘솔 위에 사는 미이를 다시 잠그는 것은 불가능합니다. 언록 스캔을 통해 여러분 콘솔에 한 번 넘어간 편집 권한은 그 미이의 것으로 남습니다. 친구에게 빌린 미이를 언록하기 전에 이 비대칭을 기억하세요.
직접 해보기
이 포맷을 가장 빨리 체감하는 방법은 자신의 미이 한 명을 도구에 넣고 필드들이 떠오르는 것을 보는 것입니다:
- Mii QR Unlocker — 코드를 끌어다 놓으면 이름과 권한 플래그가 해석되고, 편집 가능한 코드를 다시 만들어 줍니다.
- Mii 크리에이터 — FFL 기반 라이브 렌더링으로 미이를 처음부터 만들고 내보냅니다.
- Mii 눈 편집기 — 미이의 표정을 결정하는 눈 모양만 집중적으로 다룹니다.
- 보이스 랩 — Tomodachi Life가 성격을 어떻게 합성 음성으로 바꾸는지 귀로 확인합니다.