Mac 게임을 만드는 팀에게 Rosetta는 꽤 이상한 존재였습니다. 플레이어는 거의 의식하지 않지만, 뒤에서는 Intel용 실행 파일을 Apple silicon Mac에서 돌아가게 해 주는 번역층이었습니다. 그래서 많은 팀은 “일단 돌아가니까 괜찮다”는 상태로 몇 년을 보낼 수 있었습니다. 특히 오래된 Unity 프로젝트, 업데이트가 느린 인디 게임, Mac 빌드를 주력 플랫폼이 아니라 보조 출시 채널로 관리하는 팀이라면 더 그렇습니다.
그런데 이 조용한 완충지대가 끝나는 쪽으로 가고 있습니다. Unity Apple Platform 팀은 2026년 7월 2일 공식 Discussions 글에서 Mac Desktop 게임을 내는 Unity 개발자에게 Rosetta deprecation 대응을 다시 안내했습니다. 핵심은 단순합니다. Universal Mac 바이너리나 Apple silicon 전용 바이너리를 이미 내고 있다면 큰 문제가 아닙니다. 하지만 Mac Intel x86_64 바이너리만 배포하고 있고, 실제 고객은 Apple silicon 하드웨어에서 Rosetta로 플레이하고 있다면 이제 빌드 전략을 바꿔야 합니다.
이 글은 “Apple이 Intel을 버린다”는 식의 플랫폼 감상문이 아닙니다. 게임 개발팀이 지금 바로 확인해야 할 빌드, QA, 플러그인, 스토어, 플레이어 커뮤니케이션 체크리스트에 가깝습니다. Unity 이야기를 중심에 두지만, Unreal, Godot, 자체 엔진을 쓰는 팀에도 질문은 비슷합니다. 우리 빌드는 어떤 CPU 아키텍처를 포함하고 있는가. 네이티브 플러그인과 런처는 같은 방향으로 준비되어 있는가. 플레이어가 업데이트하지 않은 오래된 Mac 게임을 실행할 때, 우리는 어디까지 책임질 것인가. 그리고 이 변경이 단순한 기술 부채 정리가 아니라, 앞으로 Mac에서 게임을 어떻게 유지할지 결정하는 신호라는 점을 같이 보려고 합니다.
1. 먼저 우리 게임이 어느 그룹인지 나눕니다
이 이슈를 다룰 때 가장 위험한 반응은 “Mac 빌드는 우리에게 작으니까 나중에 보자”입니다. 작은 플랫폼일수록 더 늦게 문제가 발견되고, 발견될 때는 대개 플레이어 문의나 스토어 리뷰 형태로 옵니다. 그래서 첫 단계는 기술 해결이 아니라 분류입니다. 현재 배포 중인 Mac 게임을 세 그룹으로 나눠야 합니다.
첫 번째 그룹은 이미 Universal Mac 바이너리를 배포하는 게임입니다. Intel과 Apple silicon 코드를 모두 포함하고 있으므로 Apple silicon Mac에서는 Rosetta 없이 네이티브로 실행될 수 있습니다. 이 경우에도 안심만 할 일은 아닙니다. 메인 실행 파일은 Universal인데 런처, 크래시 리포터, 네이티브 플러그인, DRM, 오디오 미들웨어, 영상 재생 모듈 중 일부가 Intel-only인 경우가 있습니다. 플레이어 입장에서는 “게임은 업데이트되었다”라고 생각하지만 실제로는 작은 보조 프로세스 하나가 Rosetta에 기대고 있을 수 있습니다.
두 번째 그룹은 Apple silicon 전용 빌드로 이동한 게임입니다. 이 선택은 Rosetta 의존성을 확실하게 끊지만, Intel Mac 하드웨어를 가진 기존 고객을 버리는 결정이기도 합니다. 신규 게임이나 앞으로 오래 운영할 라이브 게임이라면 합리적일 수 있지만, 이미 Intel Mac 고객이 의미 있는 비중을 차지하는 게임이라면 공지, 최소 사양 변경, 환불/지원 정책까지 같이 정리해야 합니다.
세 번째 그룹이 이번 Unity 안내의 핵심입니다. Mac Desktop 빌드를 Intel x86_64로만 내고, Apple silicon 플레이어는 Rosetta를 통해 실행하는 게임입니다. Unity는 2026년 7월 2일 글에서 이 상태의 프로젝트가 가장 직접적인 대응 대상이라고 설명했습니다. Unity 2020.3 이후 버전에서 계속 업데이트할 게임이라면 최소한 Universal 바이너리로 이동하고, 상황이 맞으면 Apple silicon 전용 빌드까지 검토하라고 권합니다. 반대로 Unity 2020.3 이전의 오래된 프로젝트처럼 Apple silicon export 자체가 현실적으로 어렵고 업데이트 계획도 없다면, Apple의 macOS 27 베타용 legacy game test tooling으로 실제 동작 여부를 확인해야 합니다.
이 분류가 중요한 이유는 해결책이 서로 다르기 때문입니다. 적극적으로 업데이트하는 게임은 빌드 파이프라인을 바꾸는 것이 맞습니다. 오래된 게임은 보존과 지원 범위를 정하는 것이 먼저입니다. 스토어에 계속 팔고 있는 게임은 플레이어 공지가 필요하고, 내부 프로젝트나 무료 배포물은 보관 정책이 더 중요할 수 있습니다. 한 팀 안에서도 모든 Mac 게임을 같은 규칙으로 처리하면 과한 업데이트와 방치가 동시에 생깁니다.
2. 날짜를 릴리즈 캘린더로 바꿔야 합니다
Apple Support 문서는 2026년 2월 16일 기준으로 Rosetta가 Apple silicon Mac에서 Intel 기반 앱을 실행할 수 있게 해 주지만, 향후 macOS에서 지원이 끝난다고 안내합니다. 같은 문서에서는 Rosetta가 forthcoming macOS 27까지 제공되고, macOS 28부터는 Intel 기반 프레임워크에 의존하는 일부 오래된 미관리 게임을 위한 기능만 남는다고 설명합니다. Apple Developer의 2026년 5월 Hello Developer 글도 비슷하게, macOS 27이 Rosetta를 지원하는 마지막 릴리즈이며 그 이후 Intel-only 앱은 Apple silicon Mac에서 실행되지 않는다고 말합니다. 다만 오래된 게임 예외가 언급됩니다.
Unity의 7월 2일 안내는 이 흐름을 게임 개발자용 일정으로 다시 풀어 줍니다. 지금 macOS 26.4와 26.5에서는 Intel-only 앱을 실행할 때 향후 Rosetta가 사라질 것이라는 경고를 이미 볼 수 있습니다. macOS 27 Golden Gate의 2026년 가을 공개 릴리즈는 일반 목적 Rosetta를 포함하는 마지막 macOS가 됩니다. macOS 28 이후, Unity 글은 2027년 가을로 예상되는 시점을 언급하며, 대부분의 용도에서 Rosetta가 제거되고 오래된 미관리 게임 일부를 위한 제한된 기능만 남는다고 정리합니다.
이 날짜를 블로그 뉴스처럼 읽고 넘기면 별 도움이 되지 않습니다. 팀은 이를 릴리즈 캘린더로 바꿔야 합니다. 예를 들어 2026년 하반기에 대형 업데이트가 예정된 Mac 게임이라면, 그 업데이트 안에 Universal 또는 Apple silicon 빌드 검증을 넣는 것이 좋습니다. 2027년 초에 DLC나 시즌 업데이트가 있다면, 그때까지 네이티브 플러그인 목록과 CI 빌드 설정을 정리해야 합니다. 2027년 하반기까지도 Intel-only Mac 빌드가 남아 있다면, 그때는 기술 부채가 아니라 고객 지원 리스크입니다.
일정 관리에서 특히 조심할 점은 macOS 27이 “마지막 완충지대”라는 사실입니다. macOS 27에서 여전히 돌아간다고 해서 끝난 것이 아닙니다. 오히려 그때가 실제 전환 테스트를 끝내야 하는 기간입니다. 플레이어가 macOS 28로 넘어간 뒤에야 문제를 확인하면, 이미 스토어 빌드, 엔진 버전, 플러그인 업데이트, QA 장비 확보, 고객 공지가 모두 늦어집니다.
라이브 서비스 게임이라면 이 일정은 더 엄격해야 합니다. Mac 플레이어 비중이 작더라도, 업데이트 런처나 계정 시스템이 실패하면 게임 접속 자체가 막힙니다. 패키지 게임도 다르지 않습니다. Steam, Epic Games Store, App Store 같은 배포 채널에 올라간 오래된 Mac 빌드는 어느 날 갑자기 “구매했는데 실행 안 됨” 문의가 될 수 있습니다. 기술 뉴스가 고객 신뢰 문제로 바뀌는 시점은 생각보다 빠릅니다.
3. 첫 번째 체크: Universal 빌드가 정말 모든 조각을 포함하는가
적극적으로 업데이트하는 Unity Mac 게임이라면 첫 목표는 Universal 바이너리입니다. Unity의 안내도 최소 대응으로 Universal binary 전환을 제시합니다. Universal 빌드는 Intel과 Apple silicon 실행 코드를 모두 포함하므로, 아직 Intel Mac 사용자를 버리지 않으면서 Apple silicon 사용자는 Rosetta 없이 실행할 수 있습니다. 겉으로 보면 가장 균형 잡힌 선택입니다.
하지만 제작팀이 실제로 확인해야 할 것은 “Player Settings에서 Architecture를 바꿨는가” 수준이 아닙니다. 첫째, 빌드 산출물 전체를 확인해야 합니다. 메인 실행 파일, UnityPlayer, 네이티브 플러그인, 별도 런처, 크래시 업로더, 안티치트, DLC 다운로더, 로컬 서버 프로세스, 외부 SDK helper가 모두 같은 방향으로 준비되어 있는지 봐야 합니다. 특히 오래된 플러그인은 이름만 macOS 지원이고 내부 바이너리가 x86_64만 들어 있는 경우가 있습니다.
둘째, CI와 자동 빌드 머신이 Universal 빌드를 재현할 수 있어야 합니다. 한 개발자 Mac에서 수동으로 만든 빌드가 잘 돌아가는 것은 충분하지 않습니다. 릴리즈 브랜치, 핫픽스 브랜치, QA 빌드, 스토어 업로드용 빌드가 같은 아키텍처 규칙을 따라야 합니다. 빌드 스크립트가 Intel only 경로를 하드코딩하고 있거나, 서명과 notarization 단계에서 특정 아키텍처만 처리하고 있다면 나중에 조용히 실패할 수 있습니다.
셋째, 저장 데이터와 호환성 확인이 필요합니다. CPU 아키텍처가 바뀐다고 세이브 포맷이 자동으로 깨지는 것은 아니지만, 네이티브 플러그인이나 직렬화 코드가 endian, struct packing, 포인터 크기, 파일 경로 처리에 민감하다면 문제가 생길 수 있습니다. 특히 오래된 C/C++ 플러그인, 오디오 엔진, 커스텀 압축 라이브러리, 영상 디코더, 네트워크 라이브러리는 “빌드됨”과 “기존 유저 세이브를 안전하게 읽음” 사이에 거리가 있습니다.
넷째, 스토어 패키지 크기와 다운로드 정책을 다시 봐야 합니다. Universal 바이너리는 두 아키텍처를 포함하므로 산출물이 커질 수 있습니다. 게임 본체가 이미 큰 경우에는 큰 문제가 아닐 수 있지만, 작은 인디 게임이나 빠른 다운로드를 장점으로 삼는 게임에서는 의미가 있습니다. 이때 단순히 Apple silicon only로 가면 용량은 줄지만 Intel Mac 고객을 잃습니다. 그래서 Universal은 기술 옵션이 아니라 제품 옵션입니다.
VFX나 technical art 관점에서도 Universal 전환은 무시할 수 없습니다. 렌더링 결과가 같아 보여도 shader variant, Metal backend, native texture plugin, video playback, capture tool, frame debugger, profiling tool의 동작이 달라질 수 있습니다. Mac 빌드를 “한 번 켜 봤다”로 검증하면, 실제 플레이 중 특정 컷신, 특정 이펙트, 특정 오디오 이벤트에서만 터지는 문제를 놓치기 쉽습니다.
4. 두 번째 체크: Apple silicon only는 성능 선택이자 고객 선택입니다
Universal 빌드가 과도하게 복잡하거나, 앞으로 Intel Mac 고객을 더 이상 지원하지 않기로 했다면 Apple silicon only가 더 깔끔한 선택일 수 있습니다. Apple silicon 전용 빌드는 Rosetta 의존성을 제거하고, 팀이 하나의 현대적인 Mac 하드웨어 기준으로 성능과 QA를 관리하게 해 줍니다. 특히 새 프로젝트, 장기 운영 게임, 높은 그래픽 품질이나 Metal 성능 최적화가 중요한 게임이라면 이 선택이 자연스러울 수 있습니다.
다만 이 결정은 기술팀 안에서만 끝나면 안 됩니다. 먼저 실제 플레이어 데이터를 봐야 합니다. Mac 전체 플레이어 수, 그중 Intel Mac 비중, 최근 90일 접속률, 유료 DLC 구매자 비중, 고객 지원 티켓, 지역별 하드웨어 편차를 확인해야 합니다. Intel Mac 비중이 낮더라도, 오래된 Mac에서 꾸준히 플레이하는 충성 유저가 있을 수 있습니다. 반대로 거의 없는 플랫폼을 계속 붙잡느라 빌드 복잡도가 커지고 있다면, Apple silicon only로 정리하는 것이 장기적으로 더 건강할 수 있습니다.
두 번째로 스토어 설명과 최소 사양을 바꿔야 합니다. 플레이어는 엔진 내부 사정을 모릅니다. 어느 날 업데이트 후 게임이 실행되지 않으면 “개발사가 게임을 망가뜨렸다”고 느낄 수 있습니다. Mac 최소 사양에 Apple silicon requirement를 넣고, 업데이트 노트에 Intel Mac 지원 종료 시점을 명확히 쓰고, 기존 구매자에게 마지막 지원 빌드나 롤백 브랜치를 제공할지 결정해야 합니다.
세 번째로 QA 기준을 새로 잡아야 합니다. Apple silicon only로 바꿨다고 QA가 줄어드는 것은 아닙니다. 오히려 M1, M2, M3, M4, M5 세대, 메모리 용량, macOS 버전, 외장 디스플레이, 컨트롤러, 고주사율 모니터, Metal feature set 차이를 다시 봐야 합니다. Rosetta가 사라진다고 모든 성능 문제가 사라지는 것이 아니라, 이제 네이티브 환경에서의 진짜 병목이 드러납니다.
게임 디자인 쪽에서는 이 선택이 플레이 감각에도 연결됩니다. Apple silicon Mac을 기준으로 성능 여유가 생기면 그림자 품질, 화면 효과, 포스트 프로세스, VFX density를 더 공격적으로 가져갈 수 있습니다. 하지만 Mac 플레이어가 모두 고급 장비를 쓰는 것은 아닙니다. 배터리, 발열, 팬 소음, 노트북 사용 환경을 감안하면 “네이티브니까 더 화려하게”보다 “네이티브라서 더 안정적으로”가 더 좋은 목표일 때가 많습니다.
5. 에디터와 런타임을 분리해서 봐야 합니다
Unity 관련 Rosetta 이슈에서 혼동이 자주 생기는 지점이 있습니다. 게임 런타임 문제와 Unity Editor 문제는 서로 연결되어 있지만, 완전히 같은 문제는 아닙니다. 2026년 4월 21일 Unity는 Apple silicon Unity Editor가 macOS 27 이후 Rosetta 2 의존에서 벗어나도록 전환하겠다고 공식 안내했습니다. 이 글은 에디터와 내부 도구 일부가 아직 Rosetta에 기대고 있는 지점을 정리하는 흐름이었습니다.
반면 2026년 7월 2일 글은 Mac Desktop 게임을 출시하는 개발자에게 더 직접적입니다. 플레이어에게 배포되는 게임이 Intel-only인지, Universal인지, Apple silicon only인지에 초점을 둡니다. Unity Discussions 답변에서도 iOS와 Android 앱 개발자는 이 Mac Desktop 출시 안내의 직접 대상이 아니며, Mac에서 Unity Editor를 사용하는 개발 환경 문제는 별도 Rosetta 전환 thread를 보라고 설명합니다.
이 구분은 작은 팀에게 특히 중요합니다. 예를 들어 팀이 Apple silicon MacBook으로 iOS/Android 게임을 개발하고 있다면, 플레이어 런타임은 iOS/Android이므로 Mac Desktop 배포 문제와는 다릅니다. 하지만 Unity Editor 자체가 future macOS에서 Rosetta 없이 잘 돌아가야 하므로, 개발 환경 업데이트 계획은 여전히 필요합니다. 반대로 Mac용 Steam 게임을 실제로 팔고 있다면, 에디터가 돌아가는지보다 플레이어 빌드가 어떤 아키텍처인지가 더 급합니다.
팀 내부 체크리스트는 두 줄로 나누는 편이 좋습니다. 개발 환경 라인에서는 “우리가 쓰는 Unity 버전, 패키지 매니저, 라이트매퍼, 네이티브 에디터 확장, Asset Store 도구가 Apple silicon 네이티브로 준비되는가”를 봅니다. 제품 런타임 라인에서는 “플레이어에게 나가는 빌드, 런처, SDK, 플러그인, 스토어 패키지가 Rosetta 없이 실행되는가”를 봅니다. 이 둘을 섞으면 QA가 흐려집니다.
Unreal이나 Godot 팀도 같은 사고방식을 가져갈 수 있습니다. 에디터가 Apple silicon에서 돌아가는 것과, shipped game이 Apple silicon native로 안전하게 돌아가는 것은 다릅니다. 자체 툴, asset cooker, shader compiler, build farm, crash reporter, patcher까지 포함해 봐야 합니다. Mac에서 개발하지 않더라도 Mac 빌드를 내고 있다면, 출시 산출물 중심으로 검증해야 합니다.
6. 아트와 technical art는 “켜짐”보다 “같은 장면이 같은 의도로 보임”을 확인해야 합니다
Rosetta 종료는 얼핏 프로그래머와 빌드 엔지니어의 일처럼 보입니다. 하지만 게임은 실행 파일만으로 출시되지 않습니다. 아티스트, 디자이너, technical artist, VFX artist에게 중요한 질문은 “Apple silicon native 빌드에서 같은 장면이 같은 의도로 보이는가”입니다.
예를 들어 Metal에서 shader precision, texture format, render target 설정, post-processing order, video texture handling이 바뀌면 특정 장면의 색감이나 이펙트 타이밍이 달라질 수 있습니다. 대부분의 프로젝트에서는 큰 차이가 없겠지만, 스타일라이즈드 셰이딩, 커스텀 toon ramp, VFX Graph, Shader Graph, native render plugin, command buffer를 많이 쓰는 프로젝트라면 실제 장면 비교가 필요합니다. Rosetta가 번역하던 CPU 코드가 사라지고 네이티브 코드가 실행되는 것은 좋은 방향이지만, 좋은 방향이라는 말이 자동으로 “완전히 같은 결과”를 보장하지는 않습니다.
특히 Mac 빌드가 오래 방치된 프로젝트에서는 문제가 더 복잡합니다. 예전에는 Intel Mac에서 한 번 테스트했고, 이후 Apple silicon 플레이어는 Rosetta가 알아서 처리했을 수 있습니다. 그 사이에 엔진 버전, 렌더 파이프라인, 그래픽 API, 플러그인, OS 권한 정책, notarization 요구사항이 바뀌었습니다. 이제 native 전환을 하려면 과거에 쌓인 차이를 한 번에 정리해야 합니다.
아트팀이 도와줄 수 있는 실무 방법은 명확합니다. 대표 장면을 정해 비교 캡처를 만듭니다. 어두운 장면, 밝은 HDR 장면, 투명 파티클이 많은 장면, UI가 많은 장면, 영상 재생 장면, 컷신, 로딩 직후 장면, 장시간 플레이 후 메모리가 오른 장면을 포함합니다. QA는 프레임 수치만 보는 것이 아니라, 색, 알파, 후처리, 텍스처 스트리밍, 애니메이션 끊김, 오디오 싱크를 같이 봅니다.
디자이너도 참여해야 합니다. 빌드 아키텍처가 바뀌면서 컨트롤러 입력, 창 모드, 해상도 선택, 화면 전환, 저장/불러오기, 접근성 옵션이 달라질 수 있습니다. 플레이어가 느끼는 문제는 “ARM64 빌드에서 특정 dylib가 빠졌다”가 아니라 “전체 화면 전환 후 UI가 안 눌린다” 또는 “세이브가 날아간 것처럼 보인다”입니다. 기술 이슈를 플레이어 언어로 번역하는 작업이 필요합니다.
이 지점은 포트폴리오와 교육 콘텐츠로도 좋습니다. 많은 학생과 주니어 개발자가 그래픽 퀄리티만 보여 주려 하지만, 실제 스튜디오에서는 플랫폼 전환, 빌드 검증, 네이티브 플러그인 리스크, QA 매트릭스를 이해하는 사람이 귀합니다. “Mac Universal 빌드 전환 체크리스트를 만들고 실제 장면 비교까지 했다”는 경험은 단순한 스크린샷보다 훨씬 실무적입니다.
7. 오래된 게임 예외를 유지보수 전략으로 착각하지 말아야 합니다
Apple과 Unity 안내에서 오래된 게임 예외가 언급되기 때문에, 일부 팀은 “게임은 예외라니까 괜찮겠지”라고 생각할 수 있습니다. 이 해석은 위험합니다. Unity의 7월 2일 글은 macOS 28 이후 일부 오래된 미관리 게임을 위한 제한된 Rosetta 기능이 남는다고 설명하면서도, 업데이트를 계속하는 게임이라면 Universal 또는 Apple silicon 전환을 권합니다. 또한 macOS 27 beta에서 제공되는 legacy game test tool은 베타 전용이고, 일반 공개 릴리즈에는 남지 않으며, Rosetta를 비활성화해 다른 non-game 프로세스에 영향을 줄 수 있다고 주의합니다.
즉 이 도구는 “우리 게임이 영원히 괜찮은지 확인하는 인증서”가 아닙니다. 오래된 미관리 게임이 제한된 호환층에서 여전히 돌아가는지 보는 테스트 도구에 가깝습니다. 지금도 업데이트를 하고, 스토어에서 판매하고, 플레이어 문의를 받는 게임이라면 이를 장기 전략으로 삼으면 안 됩니다. 플레이어 입장에서는 예외 조건을 알 수 없고, 개발자는 Apple이 어느 범위까지 오래된 게임을 계속 살려 둘지 세밀하게 통제할 수 없습니다.
오래된 게임을 가진 팀은 다른 결정을 해야 합니다. 첫째, 업데이트 가능한가. 가능하다면 Universal 또는 Apple silicon 전환 계획을 세웁니다. 둘째, 업데이트가 불가능한가. 그렇다면 스토어 설명에 지원 OS와 알려진 제한을 명확히 적고, 마지막으로 확인된 macOS 버전을 기록합니다. 셋째, 판매를 계속할 것인가. 더 이상 유지보수하지 않는 게임을 계속 판매하면, 플랫폼 변경 때마다 고객 신뢰를 잃을 수 있습니다. 넷째, 보존 가치를 어떻게 둘 것인가. 교육용, 아카이브용, 무료 배포용이면 상업용 지원과 다른 기준을 세울 수 있습니다.
이런 결정은 게임 개발자에게 불편합니다. 우리는 새 기능을 만들고 싶지, 오래된 빌드의 생명 연장을 논의하고 싶지는 않습니다. 하지만 플레이어에게는 오래된 게임도 구매한 제품입니다. 특히 인디 게임과 실험적인 작품은 출시 후 오랫동안 천천히 발견되기도 합니다. Mac 빌드를 방치한 채 “언젠가 돌아가겠지”라고 두는 것은, 나중에 그 작품을 발견한 플레이어에게 좋지 않은 첫인상을 줄 수 있습니다.
마케팅과 커뮤니티 담당자에게도 준비가 필요합니다. “Apple 정책 때문에 안 됩니다”라고만 말하면 책임을 회피하는 것처럼 들립니다. 더 좋은 설명은 “Mac Intel-only 빌드는 Apple silicon 전환과 Rosetta 종료 일정 때문에 장기 지원이 어렵고, 우리는 어떤 버전부터 Universal/Apple silicon을 지원하며, 기존 Intel Mac 사용자는 어떤 선택지를 갖는다”는 식입니다. 기술 변경을 플레이어가 이해할 수 있는 약속으로 바꾸는 것이 중요합니다.
Rosetta가 사라지는 Mac 게임 환경: Unity 개발자가 지금 점검해야 할 빌드 전환 작업 메모
Rosetta 종료는 화려한 신기능 뉴스가 아닙니다. 하지만 실제 게임 운영에서는 신기능보다 이런 변화가 더 오래 남습니다. 게임이 멋지게 보이는 것보다 먼저 켜져야 하고, 켜진 뒤에는 같은 장면이 같은 의도로 보여야 하며, 업데이트 후에도 기존 플레이어가 자신의 구매와 세이브를 신뢰할 수 있어야 합니다.
Unity의 2026년 7월 2일 안내는 Mac Desktop 게임을 내는 팀에게 좋은 경고등입니다. 지금 할 일은 거창하지 않습니다. 배포 중인 Mac 게임을 Intel-only, Universal, Apple silicon only로 분류합니다. macOS 27과 macOS 28 일정을 릴리즈 캘린더에 넣습니다. 네이티브 플러그인과 보조 프로세스를 포함해 실제 산출물을 검사합니다. 대표 장면과 저장 데이터, 입력, UI, 성능을 Apple silicon 환경에서 다시 봅니다. 그리고 오래된 게임은 업데이트할지, 마지막 지원 상태를 명확히 표시할지 결정합니다.
VFX Diary 관점에서 이 이야기는 단순한 Unity 공지가 아니라 제작 문화의 문제로 보입니다. 플랫폼 전환은 언제나 옵니다. 엔진 버전, 렌더 파이프라인, 그래픽 API, 스토어 요구사항, 하드웨어 아키텍처는 계속 바뀝니다. 좋은 팀은 그때마다 “이번에 뭐가 깨졌나”만 보는 것이 아니라, 앞으로 같은 종류의 변화가 왔을 때 흔들리지 않는 체크리스트를 만듭니다. Mac Rosetta 이슈는 그 체크리스트를 만들 좋은 타이밍입니다.
참고 출처
- Unity Discussions, Apple Rosetta deprecation and your Mac Intel-based games: what to do and when, 2026년 7월 2일: https://discussions.unity.com/t/apple-rosetta-deprecation-and-your-mac-intel-based-games-what-to-do-and-when/1724774
- Apple Support, Using Intel-based apps on a Mac with Apple silicon, published 2026년 2월 16일: https://support.apple.com/en-us/102527
- Apple Developer, Hello Developer May 2026, Update your Intel-based Mac apps to Apple silicon: https://developer.apple.com/hello/may26/
- Unity Discussions, Announcing the Transition of Apple silicon Unity Editor from Rosetta 2, 2026년 4월 21일: https://discussions.unity.com/t/announcing-the-transition-of-apple-silicon-unity-editor-from-rosetta-2/1717433
- Apple Developer Documentation, Building a universal macOS binary: https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary