Asahi Linux M3 지원: 설치는 열렸다, GPU와 잠자기는 아직이다

Asahi Linux가 M3 맥의 설치 문을 열었다. 업무용 리눅스 노트북으로 바로 갈아타도 된다는 뜻은 아니다. 9월 6일 발표는 M3·M3 Pro·M3 Max 기반 MacBook과 iMac을 대상으로 하지만, Expert 모드가 필요하고 GPU와 완전한 디스플레이 제어 지원은 아직 남아 있다. 잠자기와 해당 MacBook의 HDMI 출력에도 제한이 있다. Asahi 공식 발표

개발 환경을 옮길 때 설치 완료 화면은 반갑다. 다음 날 회의실에서 뚜껑을 열었을 때도 반가울지는 별도의 시험이다. 이번 소식은 바로 그 두 시험 사이에 있다.

VLSI Korea view: 칩이 명령을 실행하는 것과 제품의 작업 흐름이 완성되는 것은 서로 다른 검증 항목이다.

1. 설치 지원을 어디까지 읽어야 하나

이번 변화는 이미 M3 맥을 가진 커널·드라이버 개발자에게 실용적이다. 새 SoC를 직접 다루는 실험 환경을 마련할 수 있기 때문이다. 반면 영상 회의, 외부 모니터, 이동 중 절전이 하루 업무에 묶여 있는 사용자는 설치 가능 여부만으로 주력 장비를 바꾸기 어렵다. 같은 기계라도 독자의 작업이 다르면 도입 판단이 달라진다.

판단의 기준은 세 층이다. 설치 프로그램에 기종이 들어가는 것, 필요한 장치가 동작하는 것, 실제 애플리케이션이 그 장치를 올바르게 쓰는 것이다. 첫 층을 통과했다고 마지막 층의 성능·안정성까지 확인한 것은 아니다. 이 구분은 맥에만 적용되는 예외가 아니라 새 하드웨어를 지원할 때 반복되는 문제다.

공식 자료끼리도 읽는 시점을 맞춰야 한다. 현재 M3 지원 표에는 설치 프로그램의 WIP 표시와 비디오 디코더의 ‘no AV1’ 표시가 남아 있다. 반면 날짜가 명확한 이번 발표는 설치 지원과 AV1 디코딩을 설명한다. 이 글은 발표 범위를 전달하되, 그 차이를 모든 배포판과 앱에서 검증이 끝났다는 뜻으로 합치지 않는다.

실무에서는 ‘지원됨’이라는 단어 옆에 기종, 배포판 이미지, 커널, 펌웨어, 사용자 공간 패키지 버전을 함께 적는 편이 낫다. 그래야 문제가 생겼을 때 무엇이 달라졌는지 찾을 수 있다. 출시 당일의 발표와 계속 수정되는 표는 역할이 다르며, 서로 어긋나는 항목은 원인을 확인할 때까지 보수적으로 취급해야 한다.

2. 영상이 풀리는 것과 화면이 그려지는 것은 다르다

비디오 디코더는 압축된 영상에서 프레임을 만든다. GPU는 그래픽 작업을 처리하고, 디스플레이 제어기는 결과를 화면으로 내보낸다. 이들을 모두 ‘그래픽 지원’이라고 묶으면 어느 부분이 준비됐는지 놓치기 쉽다. AV1 지원 소식만으로 3D 앱이나 GPU 연산 작업의 준비 상태를 판단할 수 없는 이유다.

Linux의 stateless decoder 인터페이스에서는 사용자 공간이 스트림을 해석하고 필요한 제어 정보를 요청에 넣어 전달하는 역할을 맡는다. 디코딩 하드웨어가 있다는 사실만으로 모든 플레이어가 자동으로 이 경로를 이용하지는 않는다. 앱이 사용하는 API와 드라이버가 제공하는 API를 연결하는 작업도 필요하다.

Asahi의 8월 26일 개발 보고는 AVD와 데스크톱 앱 사이의 VA-API 변환 계층을 설명하면서, 당시에는 Fedora Asahi Remix 기본 구성이 아니며 Firefox의 비디오 샌드박스와도 맞지 않는다고 밝혔다. 이번 설치 발표만으로 그 앱 단위의 제약까지 해소됐다고 확인할 수는 없다. 샌드박스를 끄는 방법을 도입 해법으로 삼을 일도 아니다.

영상이 재생되더라도 CPU의 소프트웨어 디코딩으로 돌아갔을 수 있다. 반대로 디코더를 사용했더라도 화면 합성이나 출력 쪽에서 추가 작업이 발생할 수 있다. 검증할 때는 영상이 나오는지만 볼 것이 아니라 실제 디코딩 경로, 프레임 누락, CPU 사용량, 소비전력을 같은 입력으로 나누어 관찰해야 한다. 이 글은 해당 장비의 측정 결과를 제시하지 않는다.

한국의 SoC·멀티미디어 IP 검증 업무에도 이 구분은 유용하다. 디코더 단품의 정답 비교와 최종 제품의 재생 시험을 따로 통과시켜야 한다. 프레임은 맞게 나왔는데 브라우저가 다른 경로를 사용한다면, IP의 기능 시험은 통과해도 제품 요구사항은 충족하지 못할 수 있다. 병목을 실리콘에만 돌리면 소프트웨어 경계의 문제를 놓친다.

3. 같은 메모리를 써도 픽셀의 약속은 맞춰야 한다

통합 메모리라는 설명을 보면 복사가 전부 사라질 것처럼 느껴진다. 그러나 메모리가 물리적으로 가깝다는 것과, 두 장치가 같은 바이트를 같은 그림으로 이해한다는 것은 다른 조건이다. 생산자가 만든 버퍼를 소비자가 읽으려면 포맷과 배치, 사용 순서가 맞아야 한다.

Linux의 픽셀 버퍼 교환 문서는 pixel format과 modifier를 구분한다. 전자는 색을 표현하는 방법이고, 후자는 메모리에 배치하는 방법이다. 모든 참여자가 쓸 수 있는 조합의 교집합이 없으면 직접 공유 대신 변환이나 복사 경로가 필요하다. 교집합이 있다는 것만으로 모든 import 조건이 충족되는 것도 아니다.

이 차이는 드라이버 인터페이스 검토에서 바로 질문으로 바뀐다. 디코더가 내보낼 수 있는 포맷을 디스플레이 쪽도 받을 수 있는가. 압축·타일 배치까지 같은가. stride와 offset은 맞는가. 지원 목록에서 같은 이름 하나를 발견하는 것보다, 실제 사용 목적에 맞는 조합이 있는지 확인하는 편이 정확하다.

dma-buf 문서는 버퍼 공유와 비동기 작업의 동기화를 함께 다룬다. 생산자가 쓰기를 끝내기 전에 소비자가 읽지 않도록 완료 신호도 필요하다. 주소를 전달하는 일, 작업 완료를 기다리는 일, CPU 접근 시 캐시 일관성을 확보하는 일을 하나의 ‘공유’로 뭉뚱그리면 검증 항목이 빠진다.

VLSI Korea view: 같은 메모리를 본다고 같은 프레임을 바로 읽을 수 있는 것은 아니다. 포맷과 사용 순서까지 맞아야 한다.

따라서 zero-copy는 특정 버퍼 전달 경로에 대한 주장으로 읽어야 한다. 시스템 전체의 메모리 트래픽이 0이라는 뜻이 아니고, 모든 합성 작업이 없어졌다는 뜻도 아니다. 설계 리뷰에서는 어느 두 단계 사이의 복사를 없앴는지 먼저 그리는 편이 좋다. 그러면 남아 있는 변환 비용과 측정해야 할 구간도 드러난다.

4. 복사 한 번의 크기를 계산해 보면

다음은 M3 벤치마크가 아니라 버퍼 크기를 이해하기 위한 가정 계산이다. 3840 × 2160 해상도의 이미지를 픽셀당 4바이트인 비압축 ARGB로 저장하고, padding 없이 초당 60프레임을 처리한다고 놓자. 한 프레임은 33,177,600바이트, 약 33.18MB다.

이 프레임을 매번 한 방향으로 읽거나 쓰는 논리적 데이터량은 33,177,600 × 60 = 1,990,656,000바이트/초, 약 1.99GB/s다. 별도 버퍼로 한 번 복사하면 읽기와 쓰기를 합쳐 약 3.98GB/s의 논리적 데이터 이동이 된다. GB는 10억 바이트 기준이며, 이 수치는 실제 DRAM 버스에서 측정한 값이 아니다.

캐시, 압축, 정렬, 실제 영상의 픽셀 포맷에 따라 하드웨어가 처리하는 트래픽은 달라진다. 영상 버퍼를 언제나 ARGB로 가정해서도 안 된다. 계산의 목적은 비용의 규모를 드러내는 것이지, 특정 SoC가 병목에 걸렸다고 판정하는 것이 아니다. 그래서 이 숫자를 메모리 대역폭 사양으로 나누어 성능 저하율을 만들지 않는다.

도입 평가라면 입력을 하나씩 바꾸어 본다. 같은 영상·같은 표시 조건에서 경로만 바꾸고, 프레임 누락과 지연, 전력을 함께 측정한다. 버퍼 복사가 줄어도 다른 단계가 병목이면 최종 프레임률은 그대로일 수 있다. 반대로 프레임률이 같아도 전력이 줄었다면 모바일 제품에서는 의미가 있을 수 있다. 둘 다 측정 전에는 가설이다.

기관투자자에게도 필요한 구분이다. 통합 작업이 줄면 제품을 지원하는 비용이나 사용성이 개선될 가능성은 있다. 다만 실제 사용자 수, 지원 비용, 구매 전환율이 없으면 이 가능성을 Apple 매출이나 마진의 변화로 연결할 수 없다. 커뮤니티의 플랫폼 지원 진전과 상장사의 실적 추정 사이에는 확인해야 할 단계가 더 있다.

5. AArch64 바이너리라는 조건도 끝은 아니다

화면 다음에는 프로그램이 있다. 같은 CPU 명령어 집합을 대상으로 빌드됐다는 표시만 보고 기존 실행 파일이 모두 동작한다고 가정하면 곤란하다. Asahi의 소프트웨어 호환성 문서는 16K 페이지를 제대로 고려하지 않은 바이너리 문제를 설명한다. 일부 문제는 프로그램 본문을 실행하기도 전에 로더에서 드러난다.

예를 들어 16K는 16,384바이트, 16진수로 0x4000이다. 문서는 ELF의 LOAD 구간 정렬을 확인하는 방법을 안내한다. 0x1000처럼 4K 정렬만 가정한 라이브러리를 발견했다면, CPU 성능 시험을 시작하기 전에 빌드와 로딩 조건부터 검토할 이유가 생긴다. 정렬만 고쳤다고 앱의 전체 호환성이 보장되는 것은 아니다.

칩 엔지니어가 가져갈 작업은 명확하다. 보유한 개발 도구와 라이브러리의 지원 아키텍처를 확인하고, 해당 OS와 페이지 크기에서 실행되는지 분리해 검증하는 것이다. 상용 EDA 도구의 지원 OS·CPU·라이선스 조건은 공급사의 현재 문서를 기준으로 판단해야 한다. 이 발표를 특정 EDA 제품의 지원 인증으로 읽을 근거는 없다.

드라이버 개발을 위한 실험 장비와 회사의 signoff 환경은 같은 구매 항목이 아니다. 전자는 관찰 가능성과 수정 자유도가 중요할 수 있고, 후자는 재현성, 공급사 지원, 정해진 도구 버전이 먼저일 수 있다. 어느 쪽이 더 좋은지 순위를 매기기보다, 장비가 맡을 작업을 먼저 정해야 비용 비교가 의미를 갖는다.

6. 지금 도입할 사람과 다음 확인점

VLSI Korea의 판단으로는 기존 M3 맥을 가진 플랫폼 개발자가 별도 실험 환경에서 평가할 이유는 생겼다. GPU 작업이나 안정적인 이동 사용이 필요한 사람은 필요한 기능의 완료와 실제 앱 검증을 기다릴 이유가 더 크다. 예산표에는 새 장비 가격뿐 아니라 재설치·복구·검증에 쓰는 시간도 들어간다. 다만 그 시간을 임의의 금액으로 환산하지는 않았다.

설치 전에는 공식 파티션 안내와 복구 절차를 읽고 백업을 준비해야 한다. 이 글은 디스크를 변경하는 명령을 실행하도록 유도하는 설치 설명서가 아니다. 특히 업무용 원본 환경을 지운 뒤 호환성을 확인하는 순서는 실험 비용을 키운다.

Product economics & specifications

Share-price context

주가 그래프: 검증 가능한 시계열을 확보하지 못했다. Apple IR and Nasdaq returned no usable historical observations in the checked public pages; a current90-day series and reuse basis could not be verified.

공개 행사 일정에서는 XDC 2026의 M3 GPU 역공학 발표가 9월 29일로 예정돼 있다. 사용자 공간과 커널 드라이버 포팅 현황을 다루겠다는 소개가 있지만, 현재 발표 자료는 없다. 발표 예정은 드라이버 출시일이나 성능 보장이 아니다.

앞으로 6-12개월의 관찰 대상도 기능 이름의 개수보다 경계의 완성도다. Expert 조건이 해제됐는지, DCP·GPU 지원이 실제 배포판에 들어왔는지, 앱의 안전한 기본 설정으로 영상 경로가 연결됐는지, suspend/resume과 출력 장치 조합이 반복 시험을 통과하는지를 본다. 이는 프로젝트의 일정 약속이 아니라 우리가 확인할 항목이다.

이 판단이 바뀌는 조건은 구체적이다. 필요한 기능이 들어간 패키지 버전과 재현 가능한 앱 시험이 공개되면, 실험 장비에서 일상 장비로 옮길 근거가 커진다. 오늘은 새 맥을 사라는 신호보다, 갖고 있는 맥에서 무엇을 시험할 수 있게 됐는지 범위를 정확히 읽을 때다.

관련 읽기: VLSI Korea Engineering. 원출처와 지원 상태는 2026년 9월 7일 확인했다. 본문 도식과 계산은 VLSI Korea의 설명용 제작물이며 실제 장비 측정치가 아니다.

Disclosure

본 글은 정보 제공만을 목적으로 하며, 특정 증권의 매수 또는 매도를 권유하는 것이 아닙니다. 본 글에 포함된 수치와 사실은 기업 공시, 언론 보도, 시장 조사 등 공개적으로 이용 가능한 자료를 바탕으로 작성되었으며, 해당 자료 또는 작성 과정에서 오류가 발생할 수 있습니다. 필자는 언급된 기업의 주식을 보유하고 있을 수 있습니다. 모든 투자 결정 및 그에 따른 결과는 독자의 책임입니다.