Linux MMX 제거, 마지막 Pentium 시대 RAID 최적화를 겨냥
Linux 개발자들은 커널에 남은 마지막 Intel MMX 최적화를 제거할 준비를 하고 있으며, 이는 1997년 Pentium 프로세서와 함께 시작된 한 시대를 마무리하는 일이다. Linux MMX 제거 제안은 특수한 스토리지 계산을 대상으로 하되, 기존 소프트웨어 대체 경로는 유지한다. 핵심적인 절충점은 명확하다. 유지관리자의 레거시 코드는 줄어들지만, 유난히 오래된 시스템에서는 성능 저하가 발생할 수 있다.
패킹된 데이터를 처리하기 위한 Intel의 명령어 확장인 MMX는 한때 소프트웨어가 멀티미디어와 기타 반복적인 계산을 가속하도록 도왔다. 커널에 남아 있는 구현은 운영체제 제어하에 드라이브를 묶는 소프트웨어 RAID에 사용된다. 이제는 일반적인 대안이 같은 작업을 이미 수행하기 때문에, 이 구현들은 퇴출을 앞두고 있다.
예상되는 도착지는 2027년에 나올 것으로 보이는 Linux 7.5이지만, 이는 완료된 메인라인 병합이 아니라 출시 예상일 뿐이다. 영향을 받는 하드웨어의 소유자에게 이 차이는 중요하다. 이 제안은 특정 스토리지 계산이 실행되는 방식을 바꾸는 것이지, 모든 Pentium 시대 컴퓨터가 미래의 커널을 실행할 수 있음을 자체적으로 확정하는 것은 아니다.
Linux MMX 제거는 단일 XOR 루틴을 넘어선다
이 제안은 가속 대상 스토리지 기능을 비활성화하는 것이 아니라, 소수의 레거시 RAID 구현군을 제거한다.
Eric Biggers는 2026년 10월 25일 이 시리즈를 제출했다. 그의 MMX 퇴출 제안에는 XOR, RAID6, 프로세서 기능 확인을 다루는 세 개의 패치가 포함되어 있다. 제출된 변경 사항은 7개 파일에 적용되며, 12줄을 추가하고 837줄을 삭제한다.
값을 결합하는 비트 단위 연산인 XOR는 누락된 데이터를 복원하는 데 쓰이는 중복 정보인 패리티 계산에 도움이 된다. 두 드라이브의 장애를 견디도록 설계된 스토리지 구성인 RAID6는 기본 XOR를 넘어서는 추가 계산이 필요하다. 따라서 전체 시리즈를 삭제된 XOR 루틴 하나로 취급하면 그 범위를 축소하게 된다.
이 구분은 헤드라인을 과장되게 해석하는 것도 막아 준다. 최적화된 구현을 제거하면 사용 가능한 실행 경로가 바뀐다. RAID 지원을 제거하면 스토리지 기능 자체가 사라진다. 제출된 제안은 전자를 설명하며, 영향을 받는 프로세서는 기존 일반 코드를 사용하게 된다.
Phoronix는 이 작업이 Andrew Morton의 MM 개발 트리에 들어갔다고 보도했고, Linux 7.5를 유력한 도착지로 지목했다. 해당 매체의 커널 MMX 보도는 출시 목표를 예상으로 표현한다. 11월 9일 기준으로, 이 변경을 중심으로 계획을 세우는 독자에게는 그 표현이 적절하다.
개발 트리는 작업이 통합을 향해 진행되고 있다는 증거를 제공한다. 하지만 제안된 출시 목표를 무조건적인 것으로 만들지는 않는다. 검토, 통합 결정, 이후 개정은 최종 커널에 포함되는 내용을 여전히 바꿀 수 있다.
향수를 자극하는 헤드라인을 통해 Linux MMX 제거에 대한 설명을 처음 접한 독자라면, 역사보다 먼저 이 상태의 구분에 주목할 필요가 있다. 검증된 사건은 제출된 정리 시리즈와 보도된 개발 트리 반영이다. 미래의 사건은 메인라인 릴리스에 도착할 것으로 예상된다는 점이다.
실질적인 경계도 마찬가지로 중요하다. 이 시리즈는 운영체제의 핵심인 커널 내부 구현에 관한 것이다. 애플리케이션의 MMX 명령어 사용을 전반적으로 금지하는 내용을 설명하지 않으며, Intel 프로세서가 이를 더 이상 인식하지 않을 것이라고 발표하는 것도 아니다.
이 경계는 “한 시대의 끝”이라는 표현의 의미를 바꾼다. 커널은 자체 MMX 전용 최적화 작업의 퇴출을 마무리하게 된다. 역사적 애플리케이션과 보존된 운영체제를 포함한 더 넓은 소프트웨어 생태계에는 별도의 수명 주기가 있다.
유지관리자에게 이 제안은 남아 있는 코드 한 구석을 단순화할 구체적인 기회를 제공한다. 사용자에게는 더 좁은 질문을 제기한다. 자신의 특정 장비가 오늘날 이 구현 중 하나를 선택하고 있는가 하는 문제다. 이 질문은 곧바로 하드웨어 요구 사항으로 이어진다.
영향을 받는 시스템은 서로 다른 명령어 기준선 아래에 있다
관련된 구분선은 단순히 컴퓨터에 Pentium 배지가 붙어 있는지가 아니라, 프로세서 기능과 워크로드다.
Biggers의 XOR 제거 패치는 영향을 받는 경로가 SSE를 지원하지 않는 오래된 32비트 프로세서에 사용된다고 밝힌다. SSE(Streaming SIMD Extensions)는 여러 데이터 요소를 처리하기 위한 이후의 명령어 확장이다. 이 패치는 또한 실제로 RAID 어레이를 실행하는 시스템으로 관련 사용 범위를 제한한다.
RAID6 패치는 다른 경계를 제시한다. 해당 명령어 계열의 후속 확장인 SSE2가 없는 프로세서다. 그 RAID6 구현 변경 사항은 sse1.c라는 파일도 제거한다. Biggers는 이 구현이 SSE 메모리 연산으로 보완되었지만, 여전히 MMX 계산을 사용했다고 설명한다.
이 파일명은 시사하는 바가 크다. 빠르게 훑어보면 이 시리즈가 MMX와 함께 독립적이고 현대적인 대체 구현도 제거하는 것처럼 보일 수 있다. 그러나 패치 설명은 그 대신 오래된 구조를 중심으로 구축된 또 다른 구현임을 밝힌다.
Intel MMX 성능 영향을 평가하는 사람이라면 이러한 별도 기준선이 중요하다. 프로세서의 SSE 지원 여부가 시리즈의 모든 부분에 대한 영향을 자동으로 결정하지는 않는다. 선택된 구현과 관련된 RAID 계산이 비교의 기준을 정한다.
보존된 Pentium II 스토리지 장비에서 지원되는 커널 구성을 실행하는 가상의 애호가를 생각해 보자. 그 어레이가 퇴출되는 구현을 사용한다면, 실질적인 변화는 계산 성능에 관한 것이 된다. 대체 경로가 존재한다는 것은 제안된 코드 제거가 해당 계산 자체를 자동으로 없애지는 않는다는 뜻이다.
이제 같은 헤드라인을 현대적인 워크스테이션에서 읽는 개발자를 생각해 보자. MMX 명령어 확장의 연대만으로는 그 워크스테이션이 선택한 스토리지 구현에 관해 거의 알 수 없다. 유용한 근거는 실제 프로세서 기능과 커널 동작이다.
이 사례들은 측정된 결과를 확정하는 것이 아니라 노출 가능성을 보여 준다. 검토된 자료는 퇴출 경로를 사용하는 활성 장비의 목록을 제공하지 않는다. 따라서 영향을 받는 사용자의 정확한 추정치를 뒷받침할 수 없다.
의미 있는 결정을 앞둔 사람들은 오래된 프로세서 기능과 관련 스토리지 워크로드를 함께 사용하는 운영자들이다. 이들은 업그레이드가 선택된 구현을 바꾸는지, 그리고 그에 따른 성능 저하가 중요한지 확인해야 한다.
배포판 유지관리자도 관련된 소통 과제를 안고 있다. 커널 구성, 패키지 제공 여부, 프로세서 요구 사항은 이 최적화 정리와 별개의 문제로 남는다. 사용자는 미래의 릴리스를 보존 하드웨어의 업그레이드 옵션으로 해석하기 전에 이러한 세부 사항을 알아야 한다.
따라서 유지관리 절충은 잠재적으로 구체적인 요구를 가진 좁은 기술 사용자층에 영향을 미친다. 노출 범위가 작다고 해서 영향이 없다는 뜻은 아니다. 익숙한 프로세서 이름이 불러일으키는 감정적 무게가 아니라, 실제 하드웨어와 워크로드 근거에 따라 대응해야 한다는 의미다.
일반 코드는 특수 사례를 줄이면서 기능을 유지한다
이 제안은 기능을 보존하는 일과 그 기능의 모든 역사적 구현을 보존하는 일을 구분한다.
퇴출되는 MMX 구현 없이 값을 처리하는 일반 코드인 스칼라 대체 경로는 유지관리자에게 그 선택지를 제공한다. Biggers는 기존 대체 경로가 충분히 검증됐다고 설명한다. 이는 특수 경로를 제거하면서 기능을 유지하는 데 대한 작성자의 근거다.
이 표현은 적절한 범위에서 이해할 필요가 있다. 제안의 연속성 논거를 뒷받침하지만, 영향을 받는 모든 장비에 대한 공개 벤치마크는 아니다. 올바른 출력과 동등한 속도는 서로 다른 특성이다.
유지관리 논리는 구현 간 선택으로 보면 더 이해하기 쉽다. 특수 코드는 사용자에게 도움이 되거나 유용한 성능을 제공할 때 존재할 이유가 있다. 하지만 그 코드가 계속 존재하면 관련 코드가 바뀔 때 검토자가 이해해야 할 자료도 늘어난다.
일반 코드는 동작을 유지관리할 공통된 장소를 제공한다. 그렇다고 모든 특수 구현이 불필요해지는 것은 아니다. 오래된 구현을 유지하기 위해 필요한 근거가 바뀌는 것이다. 보존할 가치가 있는 실질적 이점이 있어야 한다.
이 지점에서 Linux MMX 제거는 역사적 기념일 이상의 흥미를 갖는다. 프로젝트는 남아 있는 성능 경로와 이를 계속 유지하는 복잡성 사이를 저울질하고 있다. 작동하는 대안의 존재는 결정을 비용 없는 것으로 만들지는 않지만, 기능을 잃지 않고 삭제할 수 있게 한다.
세 번째 패치는 사용 가능한 하드웨어 기능 중 적합한 구현을 선택하는 프로세서 기능 확인까지 이 단순화를 확장한다. Biggers는 중복된 선행 조건 확인을 제거하고, 같은 기능을 반복해서 확인하지 않도록 제안한다. 제출된 코드는 SSE2와 AVX2 경로를 포함한 더 새로운 구현을 유지한다.
더 이후의 벡터 명령어 확장인 AVX2는 한 번의 연산으로 여러 값을 처리하는 또 다른 방법을 제공한다. 그 존재는 브랜드 경쟁보다 기술적 비교를 더 명확히 보여 준다. 문제는 어떤 구현이 프로세서에 맞고, 계속 유지할 가치가 있는가다.
MMX를 도입한 것은 Intel이므로 역사에서는 Intel의 이름이 두드러진다. 실제 유지관리 결정은 제조사 브랜딩이 아니라 지원되는 프로세서 기능에 관한 것이다. 역사적 Intel 및 AMD 제품을 비교해도 특정 커널 구현이 여전히 자리를 지킬 만한지 판단할 수는 없다.
같은 논리는 줄 수 감소를 신중하게 해석해야 하는 이유도 설명한다. 줄 수가 줄었다는 것은 소스 변경의 규모를 보여 준다. 더 빠른 스토리지, 더 적은 결함, 또는 유지관리 시간의 구체적 감소를 직접 측정하는 것은 아니다.
따라서 이 정리 작업을 지지하는 가장 강한 근거는 구조적이다. 공통 대체 경로는 계산을 유지하고, 시리즈는 더 오래된 기능 범위를 위한 구현을 제거한다. 성능 주장은 추가 근거가 필요하다.
이렇게 보면 Linux MMX 제거 설명은 기존 기능을 중심으로 구현 부담을 줄이는 이야기다. 커널은 하나의 작업을 계속 수행하면서 그 작업을 수행하던 역사적 방법 하나를 퇴출할 수 있다. 그 균형이 적절한지는 남아 있는 사용자에게도 일부 달려 있다.
MMX의 긴 퇴출 과정은 변화하는 유지관리 조건을 반영한다
역사적 이정표는 분명하지만, MMX 출시일이 삭제되는 모든 구현의 연대나 가치를 측정하는 것은 아니다.
Intel은 1997년 1월 8일 MMX 기술을 탑재한 Pentium 프로세서를 출시했다. 당시의 Pentium MMX 출시 발표는 그래픽, 비디오, 오디오를 강조했다. 더 풍부한 개인용 컴퓨터 미디어를 중심으로 마케팅된 기술은 결국 커널 스토리지 계산에 남아 있었다.
이 역사는 이 제안이 스토리지 개발을 넘어 주목받는 이유를 설명한다. MMX는 개인용 컴퓨팅에서 알아보기 쉬운 시기와 연결된, 눈에 띄는 소비자 기능이었다. 마지막 커널 최적화는 일반적인 정리 작업이 거의 얻지 못하는 상징적 무게를 지닌다.
그러나 상징성은 실제 시간 흐름을 가려서는 안 된다. 명령어 확장은 이를 사용하는 코드보다 먼저 나올 수 있다. 이를 1997년 기술의 퇴출이라고 부르는 것은 정확하지만, 제거되는 모든 소스 줄이 1997년부터 존재했다고 가정하려면 별도의 근거가 필요하다.
이 제안은 앞선 제거 작업의 연장선이기도 하다. Biggers는 memcpy(), copy_page(), clear_page()를 포함한 메모리 함수용 MMX 최적화를 없앤 이전 커밋을 언급한다. 이 함수들은 데이터를 복사하거나 메모리를 초기화하며, 남아 있는 RAID 작업과는 별개의 활동이다.
이전 제거 작업은 현재 사건을 바라보는 관점을 바꾼다. 이는 널리 사용되던 기술을 갑작스럽게 퇴출하기로 한 결정이 아니라, 더 좁은 범위의 정리 작업을 마무리하는 과정이다. 다른 최적화 작업이 사라진 뒤에도 RAID는 예외적으로 남아 있던 커널 사용처였다.
역사적인 최적화는 시간이 지나며 원래의 근거를 서서히 잃을 수 있다. 하드웨어가 바뀌고 대체 구현이 등장하며, 가장 오래된 경로를 사용하는 집단은 파악하기 어려워진다. 이 전환 과정 내내 코드는 계속 정상적으로 동작할 수 있다.
이 때문에 반복되는 유지보수 문제가 생긴다. 실질적인 사용자가 불확실한 경로에 프로젝트는 얼마나 지속적인 관심을 기울여야 할까? 기능이 다른 곳에서 유지된다면 삭제가 하나의 답이 될 수 있다. 사용자가 의미 있는 이점을 입증한다면 코드를 유지하는 것도 또 다른 답이다.
어느 쪽 입장도 오래된 하드웨어를 폄하할 필요는 없다. 보존 작업은 현재의 범용 커널을 유지하는 것과 다른 목표를 가진다. 애호가는 그 동작이 전용 업스트림 구현을 더는 정당화하지 못하더라도 역사적 동작을 재현하는 데 가치를 둘 수 있다.
반대도 마찬가지다. 향수가 특수 코드에 활성 사용자가 있는지, 현재 테스트가 이뤄지는지, 유용한 성능상 이점이 있는지를 입증하지는 않는다. 이는 기술적 증거가 필요한 기술적 질문이다.
더 넓은 교훈은 호환성의 조건에 관한 것이다. 알고리즘을 계속 사용할 수 있게 하는 일, 프로세서별 최적화를 유지하는 일, 완전한 시스템을 지원하는 일은 서로 별개의 약속이다. 프로젝트는 하나를 바꾸면서도 나머지는 각자의 요구 사항에 맡겨둘 수 있다.
개발자에게 이는 소프트웨어가 단순히 고장 나지 않은 채 어떻게 노화하는지를 보여주는 유용한 사례다. 최적화는 필수에서 선택 사항으로, 다시 정당화하기 어려운 상태로 이동할 수 있다. 따라서 그 은퇴는 하드웨어의 역사적 중요성에 대한 판단이 아니라 달라진 유지보수의 조건을 반영한다.
부족한 증거는 영향을 받는 하드웨어에서 측정한 성능이다
보존된 폴백은 계속 운영할 수 있는 경로를 마련할 뿐, 성능이 그대로 유지된다는 보장은 아니다.
공개된 패치 설명은 Biggers가 특수 코드를 왜 구식으로 보는지 설명한다. 하지만 변경 전후에 대표적인 스토리지 워크로드를 실행한 영향을 받는 시스템의 측정 비교는 제공하지 않는다. 따라서 실제 비용은 아직 결론 나지 않았다.
이 공백은 양쪽 주장 모두를 제한해야 한다. 영향을 받는 모든 시스템이 눈에 띄게 느려질 것이라고 선언하기는 이르다. 마찬가지로 아무도 변화를 알아차리지 못할 것이라고 약속하기도 이르다.
Intel MMX의 성능 영향은 실제 작업 중 시간이 어디에 쓰이는지에 따라 달라진다. 처리가 병목일 때와 다른 구성 요소가 지배적일 때 느린 계산이 미치는 의미는 다르다. 제안만으로는 특정 시스템에서 그 균형을 확인할 수 없다.
분리된 계산 테스트는 한 가지 유용한 질문에 답할 수 있다. 통제된 조건에서 이전 구현이 대체 구현과 어떻게 비교되는가 하는 질문이다. 스토리지 워크로드는 또 다른 질문, 즉 그 차이가 운영자가 실제로 수행하는 작업을 바꾸는지에 답할 수 있다.
이 결과들을 서로 바꿔 쓸 수 있는 것으로 봐서는 안 된다. 계산 처리량에서 보이는 차이가 애플리케이션 성능에서 동등한 차이로 자동 전환되지는 않는다. 마찬가지로 일상적인 워크로드가 허용 가능하더라도, 소유자에게 중요한 빈도가 낮은 작업은 놓칠 수 있다.
보존된 스토리지 시스템에서는 유지보수 작업이 일상적인 접근만큼 중요할 수 있다. 운영자는 복구 작업, 지속적인 쓰기 또는 다른 작업 중 프로세서 가용성에 관심을 둘 수 있다. 이는 시리즈가 확정한 측정된 성능 저하가 아니라 제안된 평가 영역이다.
따라서 가장 강력한 반론은 영향을 받는 구성에서 재현 가능한 결과로 나올 것이다. 그러한 증거는 특수 경로가 실질적인 가치를 유지한다는 점을 보여줄 수 있다. 또한 오래된 시스템이 얼마나 남았는지에 관한 가정보다 더 구체적인 판단 근거를 검토자에게 제공할 것이다.
가장 강력한 지지는 관련 하드웨어에서 계속된 정확성과 허용 가능한 동작을 결합하는 것이다. 이는 공용 구현이 남은 요구를 충족한다는 주장을 강화할 것이다. 다시 말해, 제안의 존재 자체가 그러한 관찰을 대신하지는 않는다.
호환성 주장에도 비슷한 절제가 필요하다. 이 최적화 파일을 제거한다고 해서 저장된 어레이의 형식이 바뀐다는 뜻은 아니다. 또한 모든 오래된 시스템이 미래의 커널로 부팅할 수 있다고 보장하는 것도 아니다.
사용자는 배포판 요구 사항과 하드웨어 구성을 포함한 전체 업그레이드 환경을 평가해야 한다. 좁은 범위의 소스 변경만으로 시스템의 미래 지원에 관한 모든 질문에 답할 수는 없다. 이를 그렇게 제시하면 별개의 결정을 혼동하게 된다.
여기에는 광범위한 보안 개선을 홍보할 근거도 없다. 특수 코드를 줄이면 검토가 단순해질 수 있지만, 제출된 근거는 이 삭제로 수정되는 취약점을 식별하지 않는다. 추가 증거가 뒷받침하지 않는 한 유지보수 이점은 유지보수 주장에 머물러야 한다.
따라서 책임 있는 해석은 신중해야 한다. 이 시리즈는 계산을 보존하면서 레거시 복잡성을 줄이는 그럴듯한 방법을 제시한다. 남은 논쟁은 제거된 가속화의 가치와 그 가치를 판단하는 데 필요한 증거에 관한 것이다.
통합, 폴백 테스트, 배포판 제공을 지켜봐야 한다
다음으로 유용한 변화는 관찰 가능한 이정표다. 메인라인 통합, 영향을 받는 시스템에서의 테스트, 실제 커널 패키지를 통한 제공이다.
먼저 이 시리즈가 메인라인 커널에 도달하는지와 어느 릴리스에 포함되는지 지켜봐야 한다. Linux 7.5는 현재 보고된 예상 목적지로 남아 있다. 병합이 확인되면 릴리스별 설명이 강화되고 다운스트림 검토자에게 확정적인 변경 사항을 제공하게 된다.
수정, 지연 또는 철회가 발생하면 이 평가는 달라진다. 더 넓은 제안은 여전히 문서화되겠지만, 예상 릴리스 시점은 업데이트가 필요하다. 독자는 개발 트리 보고를 무조건적인 릴리스 노트로 바꾸어 받아들여서는 안 된다.
정확히 어떤 버전이 병합되는지도 중요하다. 전체 방향이 유지되더라도 검토 과정에서 범위나 구현 세부 사항은 바뀔 수 있다. 초기 제출본에 끝없이 의존하는 것보다 승인된 변경 사항을 추적하는 편이 호환성 분석의 더 단단한 근거가 된다.
둘째, 실제로 은퇴하는 경로를 사용하는 하드웨어에서 나온 정확성 및 성능 결과를 지켜봐야 한다. 관련 없는 최신 프로세서에서의 테스트로는 영향을 받는 레거시 시스템의 경험을 결론지을 수 없다. 의미 있는 비교에는 일치하는 구성과 명확한 워크로드가 필요하다.
신뢰할 수 있는 보고서는 성공적인 동작과 만족스러운 속도를 구분해야 한다. 또한 무엇을 측정했는지와 변경 전에 이전 구현이 선택됐는지도 설명해야 한다. 이 맥락이 없으면 결과는 정확하더라도 제안된 절충과 무관할 수 있다.
허용 가능한 결과는 범용 코드가 남은 요구를 충족할 수 있다는 주장을 뒷받침할 것이다. 운영상 결과를 초래하는 재현 가능한 성능 저하는 이를 약화할 것이다. 어느 결과든 가정을 증거로 대체함으로써 논의를 개선할 수 있다.
셋째, 배포판 제공을 지켜봐야 한다. 업스트림 릴리스가 사용자가 선택한 배포판이 해당 커널을 언제 패키징하거나 그 시스템을 지원할지를 확정하지는 않는다. 패키지 구성과 프로세서 요구 사항은 실질적인 업그레이드 결정의 일부로 남는다.
오래된 시스템을 유지하는 사람에게 의미 있는 이정표는 전체 환경에 맞는 사용 가능한 커널이다. 그때까지 이 제안은 하드웨어를 즉시 교체하라는 지시가 아니라 관련된 계획 정보다.
이러한 관찰은 역사적 서사도 적절한 비율로 유지한다. 이 은퇴는 커널 최적화의 알아볼 수 있는 한 장을 마무리한다는 점에서 주목할 만하다. 기술적 중요성은 무엇이 병합되는지, 남은 경로가 어떻게 동작하는지, 누가 변화를 마주하는지에 따라 달라질 것이다.
엔지니어링 팀에게 이러한 구분을 문서화해 두는 일은 헤드라인이 근거 없는 호환성 가정으로 변하는 것을 막을 수 있다. 검색 가능한 지식 베이스는 업그레이드를 평가할 때 승인된 패치, 로컬 구성 및 테스트 결과를 연결할 수 있다.
영향을 받는 하드웨어를 유지한다면, 실제로 실행 중인 구성과 수행해야 하는 스토리지 작업부터 시작해야 한다. 변경 사항이 포함된 커널을 테스트하기 전에 선택된 구현을 기록하라. 자신의 워크로드를 반영하는 결과를 비교하고, 정확성과 속도를 분리하라. 최신 시스템을 유지한다면 MMX에 대한 모든 언급을 호환성 경고로 간주하지 말고 승인된 패치를 따라가라. Linux MMX 제거는 이점과 비용이 관찰 가능한 동작에 연결된, 문서화된 유지보수 결정으로 볼 때 가장 많은 정보를 제공한다. 병합을 추적하고, 관련 테스트 보고서를 검토하며, 이 은퇴가 자신의 시스템에 무엇을 의미하는지 결정하기 전에 배포판의 요구 사항을 확인하라.
