macOS의 UNIX 인증이 실제로 무엇을 의미하는지, 그리고 Apple이 인증 테스트를 통과하기 위해 어떤 예외적 설정과 변경을 요구하는지 살펴본다.
홈>Unix>Apple의 macOS UNIX 인증은 거짓말이다
Thom Holwerda2025-01-29Unix댓글 52개
온라인 토론이 길어질수록 누군가가 macOS는 UNIX라고 언급할 확률은 1에 수렴한다. 실제로 바로 지난해 말에도 The Open Group은 macOS 15.0이 다시 한번 UNIX 인증을 받았다고 발표했다. 이는 Apple이 macOS 릴리스를 “진짜” UNIX®로 인증받아 온 오랜 전통을 이어가는 것이다. 그런데 이 모든 것이 실제로 무엇을 의미할까? 결론부터 말하자면, macOS의 UNIX 인증에 관한 Apple의 적합성 문서를 실제로 들여다보면, 사실상 아무 의미도 없다는 것이 드러난다.
무엇보다 먼저, UNIX 인증이 실제로 무엇을 뜻하는지 이해해야 한다. UNIX 상표를 사용할 수 있으려면 운영체제가 Single UNIX Specification(SUS)을 준수해야 한다. SUS는 C용 프로그래밍 인터페이스, 명령줄 셸, 사용자 명령들을 정의하며, 대체로 POSIX와 거의 동일하고, 여기에 X/Open Curses 명세도 포함한다. 최신 버전은 SUS version 4로, 원래는 2008년에 발표되었고 2013년과 2016년에 수정 사항이 발표되었으며, 이것들이 2018년에 version 4에 통합되었다. 이렇게 존재하는 여러 SUS 버전은 각각 특정 UNIX 상표에 대응한다. 표로 정리하면 다음과 같다.
**상표SUS 버전SUS 최초 발표 연도:**SUS 마지막 수정 연도: UNIX® 93 n.a.n.a.n.a. UNIX® 95 Version 1 1994 n.a. UNIX® 98 Version 2 1997 n.a. UNIX® 03 Version 3 2002 2004 UNIX® V7 Version 4 2008 2016 (2018 for roll-up)
macOS가 인증된 UNIX라고 들으면, 여러분은 이 중 어떤 버전과 상표를 macOS가 준수한다고 생각하는가? 당연히 최신 상표와 최신 SUS 버전을 목표로 했다고 생각할 것이다. 그렇게 하면 macOS는 2016년 기준인 SUS version 4를 준수해 UNIX® V7 상표를 달 수 있어야 한다. 하지만 실제 답은 macOS 15.0이 SUS version 3만 준수한다는 것이다. 이 버전은 무려 2004년까지 거슬러 올라가는 오래된 규격이며, 따라서 macOS는 UNIX® 03일 뿐이다(Intel과 ARM 모두). 물론 이건 단지 형식상의 문제라고 주장할 수도 있다. UNIX와 POSIX가 자주 바뀌는 편은 아니기 때문이다.
이제 여러분은 UNIX 괴짜답게 이 모든 것을 직접 확인해보고 싶어진다. 여러분은 macOS를 사용하고 있고, Linux나 BSD를 쓰는 농노들과 달리 자신은 진짜 UNIX®를 쓰고 있다는 확신도 있다. 그러니 테스트 스위트를 전부 내려받아(살 수만 있다면 말이다. 하지만 그건 또 다른 문제다) 실행하면 되고, Apple의 적합성 테스트를 재현해서, 자신의 macOS 15 설치본이 진짜 UNIX®라는 사실을 직접 확인할 수 있어야 할 것 아닌가? 하지만 아니다. 그럴 수 없다. Apple이 인증받는 macOS 15 버전은 모든 지원되는 Mac에서 돌아가는 그 버전이 아니기 때문이다.
Apple은 macOS에 대해 그토록 자랑하는 UNIX 인증을 얻기 위해 속임수를 쓴다. 그것도 엄청나게 많이.
UNIX 인증 절차의 일부로 Apple이 The Open Group에 제출해야 하는 여러 문서는 자유롭게 공개되어 있다. 대부분은 macOS의 UNIX 및 POSIX 준수 여부에 대한 아주 구체적인 측면을 다루는, 매우 기술적인 질문들로 가득하다. 우리 중 대다수는 광범위한 조사와 macOS, UNIX, POSIX에 대한 깊은 지식 없이는 이를 검증할 수 없을 것이다. 그러나 이 적합성 문서들 각각의 끝부분에는 신청자가 “공급업체가 제공한 추가 설명 자료”를 적을 수 있는 텍스트 필드가 있다. 그리고 바로 이 부록들에서 Apple이 macOS가 각종 UNIX® 03 인증 테스트를 통과하게 만들기 위해 얼마나 많은 속임수를 써야 하는지 확인할 수 있다.
이 네 문서 중 첫 번째인 _Internationalised System Calls and Libraries Extended V3_에서 Apple의 “추가 설명 자료”는 다음과 같다.
Question 27: By default, core file generation is not enabled. To enable core file generation, you can issue this command:
sudo launchctl limit core unlimited
Testing Environment Addendum: macOS version 15.0 Sequoia, like previous versions, includes an additional security mechanism known as System Integrity Protection (SIP). This security policy applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted.
To run the VSX conformance test suite we first disable SIP as follows:
– Shut down the system.
– Press and hold the power button. Keep holding it while you see the Apple logo and the message “Continue holding for startup options”
– Release the power button when you see “Loading startup options”
– Choose “Options” and click “Continue”
– Select an administrator account and enter its password.
– From the Utilities menu in the Menu Bar, select Terminal.
– At the prompt, issue the following command: “csrutil disable”
– You should see a message that SIP is disabled. From the Apple menu, select “Restart”.
By default, macOS coalesces timeouts that are scheduled to occur within 5 seconds of each other. This can randomly cause some sleep calls to sleep for different times than requested (which affects tests of file access times) so we disable this coalescing when testing. To disable timeout coalescing issue this command:
sudo sysctl -w kern.timer.coalescing_enabled=0
By default there is no root user. We enable the root user for testing using the following series of steps:
– Launch the Directory Utility by pressing Command and Space, and then typing “Directory Utility”
– Click the Lock icon in Directory Utility and authenticate by entering an Administrator username and password.
– From the Menu Bar in Directory Utility:
– Choose Edit -> Enable Root User. Then enter a password for the root user, and confirm it.
– Note: If you choose, you can later Disable Root User via the same menu.
↫ Apple’s appendix to Internationalised System Calls and Libraries Extended V3
두 번째 적합성 문서인 _Commands and Utilities V4_에는 또 다른 부록이 있는데, 이건 정말 가관이다([…]는 앞선 부록과 반복되는 내용을 뜻하며, 간결함을 위해 삭제했다).
Testing Environment Addendum:
[…]
By default, the APFS file system updates a file’s atime lazily. To run the Conformance Test Suites, or more generally to get UNIX Standard atime behavior, mount the test partitions (including /System/Volumes/Data) with the “strictatime” option: mount -o strictatime
APFS file systems can be formatted as either case-sensitive or case-insensitive. Always format as case-sensitive for UNIX Conformant behavior.
macOS has a file indexing service, Spotlight, that runs in the background and may affect file access times. For UNIX Conformance Testing we disable Spotlight. You can do that with this command: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Spotlight can be re-enabled with:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
- […]
- […]
- In macOS Sequoia the root volume is authenticated and immutable. Because of this, and because of the way that you have to configure uucp, you should take the following steps before using uucp (and we do these before running the uu* tests): * Copy the following binaries from /usr/bin to /usr/local/bin
uucp
uuname
uustat
uux * Copy the following binaries from /usr/sbin to /usr/local/bin:
uucico
uuxqt * In /usr/local/bin, turn on the setuid bit for these binaries:
sudo chmod +s /usr/local/bin/uu*
(This is the step that you cannot perform within /usr/bin or /usr/sbin) * Add /usr/local/bin to your PATH preceding /usr/bin and /usr/sbin * Enable the uucp service:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.uucp.plist
세 번째와 네 번째 적합성 문서에는 부록이 없다.
흥미롭게도, 부록들 외에도 Apple은 네 개의 “Temporary Waivers”를 가지고 있다. 이것은 The Open Group이 전적인 재량으로 부여하는 면제로, “상호운용성이나 이식성에 미치는 영향이 무시할 만한 수준인 사소한 구현 오류”의 “제한된 수”에 대해 인정된다. 이 면제는 12개월 동안 유효하며, 그 이후에는 신청자가 제품에서 해당 오류를 제거해야 한다. 이 면제들과 그 해결 내용은 공개되어야 하지만, 아마 등록된 유료 고객에게만 공개되는 듯하다. 그래서 나는 직접 내려받아 살펴볼 수 없었다. 솔직히 말해 아주 흥미로운 내용일 것 같지는 않지만, 그래도 언급할 가치는 있다고 생각했다.
즉, 여러분이 자신의 macOS 15.0 설치본을 UNIX® 03 인증 테스트 스위트를 통과하게 만들고 싶다면, System Integrity Protection을 비활성화하고, root 계정을 활성화하고, core file 생성을 활성화하고, timeout coalescing을 비활성화하고, 모든 APFS 파티션을 strictatime 옵션으로 마운트하고, APFS 파티션을 대소문자 구분 방식으로 포맷해야 한다(기본값인 APFS는 대소문자를 구분하지 않으므로 재설치가 필요하다). 또한 Spotlight를 비활성화하고, uucp, uuname, uustat, uux 바이너리를 /usr/bin에서 /usr/local/bin으로 복사하고, uucico와 uuxqt 바이너리를 /usr/sbin에서 /usr/local/bin으로 복사하고, 이 모든 바이너리에 setuid 비트를 설정하고, /usr/local/bin이 /usr/bin과 /usr/sbin보다 먼저 오도록 PATH를 조정하고, uucp 서비스를 활성화하고, 네 개의 Temporary Waivers에 나열된 정체불명의 문제들까지 처리해야 한다.
그 다음에야, 오직 그 다음에야, 여러분의 macOS 15.0은 실제로 UNIX® 03 인증을 받은 것이 된다.
이건 완전히 제정신이 아니다. macOS 역사 전체를 통틀어 단 한 개의 macOS 설치본도, 하물며 macOS 15.0만 놓고 보더라도, 이런 변경 사항의 절반조차 적용한 적이 없다고 나는 100% 확신할 수 있다. System Integrity Protection을 영구적으로 꺼 둔 사람은 분명 소수 있을 것이고, root 계정을 활성화한 사람은 그보다 더 적을 것이며, 둘 다 해 둔 사람은 더더욱 적을 것이다. 하지만 거기까지다. 나머지 변경 사항들은 너무 난해하고 지나치게 특수해서 누구에게도 실질적인 쓸모가 없다.
공정성을 위해, 나는 다른 UNIX 인증 운영체제들의 적합성 문서도 살펴보았다. UNIX® V7 인증을 받은 운영체제와 버전은 IBM의 AIX 7.2 TL5(또는 이후 버전)가 유일하며, IBM의 메모도 단 하나뿐이다. AIX 7.2 TL5가 UNIX® V7 인증을 통과하려면 적용해야 하는 변경은 딱 하나다.
Full response to Question 28: The AIX default socket listen queue length is 1024, the maximum is 32767, the value must be modified by using the “no -o somaxconn=5” command to set UNIX03 conforming length of 5.
↫ IBM’s appendix to Internationalised System Calls and Libraries Extended V4
다른 UNIX® 03 인증 운영체제 가운데 하나인 Itanium용 HP-UX 11.31을 보면, 부록에 몇 가지 언급은 있지만 정보 제공 목적일 뿐이고, HP-UX가 UNIX® 03 인증 테스트를 통과하기 위해 적용해야 하는 변경 사항은 명시하지 않는다. Solaris의 경우에는 x86용 Solaris와 SPARC용 Solaris의 차이, 그리고 그 아키텍처들에서 32bit와 64bit 변형 간 차이에 관한 언급이 많지만, 그게 전부다. AIX, HP-UX, Solaris는 UNIX 인증 테스트를 통과하기 위해 의미 있는 변경을 요구하지 않는다.
나는 macOS 15.0의 UNIX® 03 인증이 거짓말이라는 결론밖에 내릴 수 없다. 운영체제를 UNIX® 03 인증 테스트에 통과시키기 위해 이 정도로 많은 급진적 변경을 적용해야 한다면, 그것은 사실상 UNIX® 03 준수라고 할 수 없다. 아주 분명하게 말하지만, 이것은 무슨 “잡았다!”, 스캔들, 혹은 “-게이트” 같은 이야기가 아니다. macOS의 UNIX 인증은 Apple의 C급 임원들이 순진한 고객들을 UNIX 인증 Mac 구매로 유인하려고 꾸며낸 사악한 마케팅 음모 같은 것이 아니다. Tim Cook이 The Open Group이 대체 누구인지조차 알고 있을지 나는 의심스럽다. 차갑고 냉혹한 진실은, 우리 같은 약간의 괴짜 몇 명을 제외하면 문자 그대로 아무도 이 문제에 관심이 없다는 것이다. 그리고 심지어 우리조차도 그 관심의 정도는 아주 미미하다.
하지만 나는 이것이 UNIX 상표가 실제로 얼마나 가치가 있는지, 그리고 어떤 운영체제가 UNIX 인증을 받았다는 것이 실제로 무엇을 뜻하는지에 대해 꽤 심각한 의문을 제기한다고 생각한다. 전 세계의 단 하나의 macOS 설치본도 애초에 인증 테스트를 통과할 수 없는 상황인데도 macOS가 “진짜” UNIX가 될 수 있다면, 우리는 지금 대체 무엇을 하고 있는 걸까?
이쯤 되면 왜 Apple이 이렇게나 부담스러운 단서 조항들을 잔뜩 열거하고도 UNIX® 03 상표 사용 권한을 얻을 수 있는지 궁금해진다. 솔직히 나는 전혀 모르겠다. The Open Group과 그 인증 체계에는 돈 내고 들어가는 구조라는 분위기가 분명 있지만, Apple은 겨우 silver member일 뿐이고, 그 비용도 연 22000달러에 불과하다. Apple에게는 말 그대로 푼돈이다. 인증 비용은 Apple이 어떤 항목을 사용하는지에 따라 조금 더 늘 수 있지만, 많아야 연 수십만 달러 수준일 것이고, 실제로는 그보다 훨씬 적을 가능성이 크다. 전체적으로 봐도 Apple에게는 그저 푼돈이다. 게다가 gold와 silver 회원 목록의 길이, 그리고 platinum 회원들의 거대한 이름값을 보면, Apple이 회원에서 빠진다 해도 The Open Group 입장에서는 거의 티도 나지 않을 것이다. silver 회원들만으로도 매년 수백만 달러의 수익을 창출하니, Apple의 기여가 그렇게 결정적이라고 보이지도 않는다.
내 생각에 현실은 훨씬 덜 흥미롭다. Apple 내부 어딘가에는 아마도 아직 이 문제를 정말 중요하게 여기는 소수의 강경한 UNIX 사람들이 남아 있을 것이다. 그리고 그들은 분명 인증 열차를 계속 굴리기 위해 업무 시간을 쓰는 것을 개의치 않는 듯하다. ARM용 인증 문서는 CoreOS 그룹의 비교적 신입 Apple 소프트웨어 엔지니어인 Mansi Agarwal이 작성했다(2023년 6월 Apple에 입사했다). 반면 Intel용 macOS 인증 문서는 Fred Zlotnick이 작성했는데, 그는 2015년에 Apple에 합류했고, UNIX 제품 분야에서 아주 긴 경력을 가지고 있다.
그는 1989년부터 1995년까지 Accredited POSIX Testing Laboratory였던 Mindcraft라는 회사에서 일했고, 이후 거의 15년 동안 Sun Microsystems에서 Solaris 운영체제 작업을 하며 수십 명 규모의 커널 엔지니어 팀을 이끌었다. Sun에 있는 동안 그는 Solaris의 핵심 I/O 서브시스템, InfiniBand 스택, IP, TCP, UDP 스택 같은 것들, ZFS 등 다양한 분야에서 일했다. 다른 회사들에서 짧게 몇 차례 근무한 뒤, 그중에는 Nexenta에서 Illumos 커널 팀을 이끈 경력도 포함되며, 결국 Apple에 정착했고 2023년 은퇴할 때까지 일했다.
정말 대단한 경력이다. 그런 사람들이 macOS를 어떻게든 UNIX 모양의 구멍에 억지로 밀어 넣기 위해 macOS를 부수고, 비틀고, 꺾고, 망가뜨리는 일을 마다하지 않는다고 상상하는 것은 어렵지 않다. 다만 문제는, 그게 과연 언제까지 가능하겠느냐는 것이다.
Mastodon에서 팔로우하기 @[email protected]
2025-01-29 6:06 pm NaGERST
이거 HP나 SPaRC 직원이 분노해서 쓴 글 같은 건가?* 맞아, 당신들은 적극적으로 방해받았고, 성공해서도 안 되는 입장이었다. Itanium은 역사상 최고의 물건이 될 예정이었다(실제론 기본 코드조차 별로였고, 마법 같은 jit 컴파일러가 있지 않은 이상 형편없었다). 하지만 그건 대부분의 RISC 프로젝트를 죽였다.여전히 살아남은 RISC 프로젝트 중에서는 ARM이 가장 좋은 예다. 일부 부분은 CISC 영역에 가까워지고 있어서 아키텍처의 순수성을 지키려면 도려내야 하긴 하지만.
2025-01-29 7:18 pm Adurbe
솔직히 말해, 이건 속임수나 거짓말처럼 느껴지지 않아요. 다른 감사나 인증 절차와 똑같이 느껴집니다. 웹사이트에 ISO나 비슷한 배지를 달고 있는 회사들이 실제로 그 모든 걸 다 하고 있다고 생각한다면, 현실을 보고 크게 놀라게 될 겁니다.
* 2025-01-29 8:27 pm [andyprough](https://osnews.com/profile/?user=andyprough)
그런데 Thom은 UNIX 인증을 충족하기 위해 그런 조작을 전혀 하지 않는 완전한 운영체제 셋을 예로 들었잖아요. 그냥 “뭐, 어차피 다들 그런 건 안 하니까”라고 말하는 건 핵심을 흐리는 겁니다. 어떤 운영체제들은 실제로 그런 걸 하지 않고도 되는데, Apple은 아주 분명히 그렇지 않다는 점이 중요하죠.
* 2025-01-30 4:37 am [Adurbe](https://osnews.com/profile/?user=Adurbe)
이 답변들에 대해서는 그렇지만, 다른 부분에서는 그들도 똑같이 합니다.
표준 인증은 돈벌이예요. 통과하게 해주고 돈 받는 게 그들 이익에 맞죠.
질문들은 모든 것이 기본값으로 켜져 있어야 한다고 묻지 않아요. 그저 켤 수 있어야 한다는 거죠.
예를 들어 CIS를 보세요. Redhat과 Ubuntu는 호환되게 만들 수 있고, 그래서 인증을 받습니다. 하지만 기본 설치 상태에서는 모든 옵션이 켜져 있지 않죠. 다른 배포판들 중에는 그게 기본인 것도 있겠지만요. 그렇다고 Redhat이 CIS 호환성이 떨어지는 건 아니죠.
* 2025-01-31 3:24 am [The123king](https://osnews.com/profile/?user=The123king)
여기 있는 사람들 중 실제로 AIX나 HP-UX를 직장에서 몇 대 남아 있는 레거시 장비 말고 다른 용도로 쓰는 사람이 있다면 놀랄 것 같네요. 그런 운영체제를 일상적으로 쓰는 사람은 없고, 그 시스템들의 설치 수가 빠르게 늘고 있는 것도 아니죠.
Linux 배포판이나 BSD 같은 자유 운영체제들이 진짜 UNIX를 사실상 대체했고, 이제는 레거시 틈새나 특수 용도를 제외하면 그다지 중요하지도 않습니다. 누군가가 IBM 메인프레임에 새 AIX 설치를 올리는 모습은 상상할 수 있어도, 사무실 파일 공유와 웹 스토어 백엔드를 그 위에서 돌리지는 않을 겁니다.
2025-01-29 8:06 pm kurkosdr
밝은 면을 보자면, Apple이 MacOS에 대해 UNIX® 인증을 계속 추구하는 한, MacOS에는 root 계정과 그것을 활성화하는 공식 절차가 계속 남게 됩니다. Android 같은 다른 운영체제들, 심지어 Google Pixel에서 돌아가는 순정 Android에 대해서는 그렇게 말할 수 없죠.그리고 Apple이 “개방성”에 신경 쓰지 않게 된 지 수십 년이 지났는데도 왜 아직 UNIX® 인증을 추구하는지 뭔가 이유가 있다고 믿고 싶어요. 제 환상을 깨지 말아 주세요. 예전에 MacOS를 UNIX라고 광고했고, 그래서 이제는 계속 책임지고 있는 거라고 해야 할까요. 잘 모르겠네요.
참고로, 아래 항목들에 대해서는 Apple을 비난할 수 없다고 생각합니다.
– APFS를 대소문자 비구분으로 출하하는 것: 같은 디렉터리에 Cat.jpg와 cat.jpg라는 두 파일이 있는 건 대다수 사용자에게 정말 혼란스럽습니다. 게다가 그런 디렉터리를 FAT32나 exFAT 파티션(둘 다 대소문자 비구분)으로 복사하면 무슨 일이 일어나는지도 문제죠. 저도 예전에 데스크톱 Linux에서 겪어봤는데, “file already exists error”가 났습니다. 맞아요, “디렉터리 복사 중에” “파일이 이미 존재합니다 오류”요. 이걸 일반 사용자에게 설명해 보세요. 그러니 Apple이 MacOS 사용자에게 MicroSD 카드(그리고 대개 FAT32나 exFAT인 USB 드라이브)에서 좋은 경험을 주고 싶다면, 대소문자 비구분이어야 합니다.
– core file 생성을 비활성화하는 것: 대부분의 사용자는 core file을 들여다보지 않고, core file이 뭔지도 모른다면 저장 공간만 금방 차지하게 됩니다. 그래서 이 기능을 기본으로 꺼 둔 이유는 이해합니다.
– root 파티션을 불변으로 만드는 것: UUCP 하나 때문에 그렇게 하지 않는다면 극소수의 필요를 다수의 필요보다 우선하는 셈이죠. 요즘 누가 UUCP를 쓰나요? 쓴다면 아마 uucp 유틸리티를 직접 /usr/local/bin으로 복사할 만큼은 아는 사람일 겁니다.
그러면 남는 건 Single Unix Specification이 현대 운영체제 기능들과 충돌하는 부분들입니다. 여기서 말하는 건 system integrity protection이나 파일 인덱싱 같은 필수 기능들이에요. 아, 그리고 좋은 성능과 배터리 수명을 위해 필수적인 파일시스템 캐싱 같은 성능 최적화와의 충돌도 있고요(힌트: 데스크톱 Linux조차 파티션을 strictatime으로 마운트하지 않습니다. 성능도 죽이고 SSD도 죽입니다). 접근 시간이 그렇게 중요하다면, 시스템을 약간 비최적화하는 수고는 직접 해야 하는 거겠죠.
그래서 Apple이 실제로 망가뜨린 건 다음뿐입니다.
그리고
대소문자 비구분. 이건 다른 Unix에서의 파일 전송을 깨뜨릴 수 있고, 엉성하게 짜인 셸 스크립트를 무작위로 망가뜨릴 수는 있습니다. 미안해요 Unix 사람들, FAT32와 exFAT가 세계를 정복했습니다. 이 두 파일시스템은 MicroSD부터 USB 메모리, MP3 플레이어까지 어디에나 있어요. 대소문자 구분이 필요하면 운영체제를 case-insensitive로 다시 설치해야 합니다.
2025-01-29 8:14 pm kurkosdr대소문자 구분으로 운영체제를 다시 설치해야 합니다 (죄송)
2025-01-29 8:24 pm andyprough
정리하면 “네, 동의합니다. MacOS는 분명 Unix가 아닙니다”를 길게 말한 거네요. Thom의 모든 지적에 동의하면서 그걸 ‘사용자에게 더 낫다’고 변호한다고 해서 더 Unix스러워지는 건 아닙니다.
2025-01-29 8:37 pm kurkosdr
기본 출하 상태의 MacOS는 분명 Unix가 아닙니다. system integrity protection과 대소문자 비구분만으로도 이미 탈락이죠. 그런데 뭘 기대하셨나요? SUS는 현대 사용자가 현대 운영체제에서 기대하는 것들과 양립할 수 없다는 게 제 요점이었습니다. Apple의 안내를 따라 약간의 수고를 들이면 Unix로 만들 수 있고, Apple은 진짜 root 접근을 얻는 방법에 대한 안내를 제공해야 하니, 그건 나름 가치가 있다고 생각합니다.그리고 MacOS가 왜 자신을 UNIX라고 부를 수 있느냐는, 그 인증을 부여하는 사람들의 문제이지 Apple의 문제가 아닙니다. Single UNIX Specification이 시스템이 비준수 상태로 출하되는 것을 허용하고, 업체가 12개월 동안 버그 있는 제품을 출하하는 것도 허용한다는 사실은, 예전에도 아무도 SUS를 진지하게 받아들이지 않았던 이유 중 하나입니다. 당시 Unix 벤더들이 원했던 것도 바로 그것이었죠. 실제로는 호환되지 않으면서 서로 호환되는 척하는 것.
* 2025-01-30 7:31 am [zde](https://osnews.com/profile/?user=zde)
하지만 당신은 Android에는 “root” 사용자가 없다고 불평하면서도, 전체 재설치를 하면 아주 쉽게 만들 수 있다는 점은 무시하네요. 공식 안내를 열고( https://source.android.com/docs/setup/build/building ) “eng” 빌드를 만들면 끝입니다. 이제 “root”가 생기죠.
복잡하냐고요? 물론이죠. 하지만 인증을 통과하기 위해 MacOS를 완전히 다시 설치해야 하는 것도 마찬가지로 복잡합니다.
Google도 똑같이 인증을 통과하는 데 필요한 안내와 조정을 추가할 수 있었겠지만, 그냥 그 문제에 관심이 없는 겁니다.
* 2025-01-30 8:43 am [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
위 안내대로 하면 Play Store나 Play Services는 못 얻고 AOSP만 얻게 됩니다. 그리고 Play Services가 필요한 앱들(예를 들면 Google Maps나 CityMapper)은 실행할 수 없죠. 실제로 Google은 최근 “인증되지 않은” Android ROM에 Play Services를 설치하는 걸 더 어렵게 만들었고, 그래서 개발자 키를 생성하고 이것저것 우회해야 합니다.
반면 Mac에서는 미리 설치된 운영체제 안에 이미 root 사용자가 있고, 그걸 그냥 활성화하기만 하면 됩니다.
* 2025-01-30 1:52 pm [zde](https://osnews.com/profile/?user=zde)
그렇죠. 하지만 그건 인증 때문이라기보다는, 재설치 없이 root 사용자를 만들지 못하게 하는 수고를 아무도 들이지 않았기 때문이죠. 어차피 대소문자 비구분 모드에서 대소문자 비구분 모드로 바꾸려면 macOS를 재설치해야 하잖아요. 그렇다면 Android처럼 root 생성도 그 동일한 과정에 포함하면 안 될 이유가 뭔가요?
* 2025-01-30 6:34 pm [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
아니요, 아직도 요점을 이해 못 하신 것 같네요. Google은 root 사용자와 Play Services가 둘 다 있는 ROM을 얻는 방법을 알려주지 않습니다.
Apple은 제품을 손상시키지 않은 상태로 MacOS에서 완전한 root를 얻는 방법을 알려줍니다. 그리고 뭔가를 컴파일할 필요도, 재설치할 필요도 없습니다. 안내를 다시 읽어보세요. 재설치는 파일시스템을 대소문자 구분으로 바꾸고 싶을 때만 필요한 것이지, root를 얻기 위해 필요한 게 아닙니다. 그 경우에도 뭔가를 컴파일하거나 운영체제를 망가뜨릴 필요는 없고, 기존 운영체제 이미지를 다시 설치하기만 하면 됩니다.
* 2025-01-31 8:52 am [zde](https://osnews.com/profile/?user=zde)
제 생각엔 이해를 못 하는 건 당신 쪽입니다. 제가 쓴 걸 읽어보세요. 제가 말하는 건, macOS에서 무엇을 할 수 있고 없는지는 인증된 버전에서 무엇을 허용해야 하고 말아야 하는지와 완전히 별개라는 점뿐입니다!
당신은 “재설치는 파일시스템을 대소문자 구분으로 바꾸고 싶을 때만 필요하지, root를 얻기 위해서는 아니다”라고 말했지만… 인증을 통과하려면 둘 다 필요합니다! Apple이 재설치 없이 root를 추가하는 기능을 제거하더라도… 인증을 받는 능력에는 아무 영향도 없을 겁니다. 즉, 당신이 그토록 소중하게 여기는 MacOS에서 root를 얻을 수 있는 능력은 인증이 아니라 Apple의 선의에 달려 있다는 뜻이고, 인증은 마케팅 목적일 뿐이라는 얘기죠. 그리고 Google도 이미지 두 개가 필요한 인증 요건은 쉽게 우회할 수 있습니다. 그냥 둘을 붙여서 설치 프로그램이 알맞은 부분을 고르게 하면 되죠. Google Play도 본질적으로 같은 범주입니다. Microsoft는 Windows NT 4.0을 POSIX 호환 운영체제로 인증받기 위해 네트워킹을 꺼 버렸는데… 그렇다면 Google은 왜 인증 버전에서 Google Play를 끄면 안 되죠? 어차피 인증은 나올 텐데요.
* 2025-02-03 9:18 am [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
why Google couldn’t disable Google Play in the certified version? Certificate would be given anyway.
좋은 지적입니다. 미래의 MacOS 버전에서는 “system integrity protection”을 끄는 순간 다른 수많은 것들도 꺼질 수 있겠죠. 예를 들어 UI가 사라지고 CLI 전용 운영체제로 떨어진다든가요. 그러니 완전한 root 접근을 켰을 때도 기능하는 MacOS를 계속 제공할지는 결국 Apple의 선의에 의존하는 셈이겠네요.
그리고 SIP를 끄면 Widevine L1(Netflix UHD에 필요) 같은 것도 동작하지 않을 가능성이 높다고 생각해요. Android에서 루팅된 폰에서 은행 앱이 안 돌아가는 것처럼요.
Microsoft certified Windows NT 4.0 to be a POSIX compliant OS by disabling networking…
이 경우 Microsoft가 뭔가를 비활성화한 건 아닙니다. Windows NT 4.0에 구현된 POSIX 버전 자체가 네트워크나 디스크 접근용 API를 정의하지 않았어요. POSIX 쪽 사람들은 네트워킹이나 파일시스템 접근에는 Unix 비슷한 기능을 쓸 거라고 가정했지만, 그건 명세 어디에도 정의되어 있지 않았죠. 그래서 Microsoft는 그 허세를 그대로 받아쳤고, 네트워킹이나 파일시스템 접근을 위한 Unix식 API를 아예 구현하지 않았습니다. 그들은 정부 요건을 충족하기 위해 POSIX 명세만 정확히 구현했고, 그 이상은 하지 않았던 겁니다.
* 2025-01-29 9:34 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
kurkosdr,
Let’s look at the bright side: For as long as Apple pursues UNIX® certification for MacOS, MacOS will have a root account and an official process to enable it, which cannot be said for other operating systems such as Android (even stock Android running on the Google Pixels).
And I want to believe that there is something forcing Apple to still seek UNIX® certification decades after they stopped caring about “openness”, don’t spoil it for me. I guess it’s the fact they advertised MacOS as UNIX once and now they are commited, I dunno,
Apple에게 UNIX 인증이 그렇게 중요해서, Apple의 거대한 설계와 충돌하더라도 절대 버리지 않을 것이라고는 저도 확신하지 못합니다. 하지만 최소한 UNIX 인증이 사용자에게 파일시스템에 대한 root 제어권 같은 어느 정도의 개방성을 요구한다는 당신의 전제에는 동의합니다.
So, the only things Apple has really broken are:
- Making turning off System Integrity Protection a bit harder than it needs to be (because Apple, duh)
제 생각에는 Apple의 의도는 App Store 경쟁을 덜 가능하게 만드는 것이었습니다. 저도 macOS에서 다운로드한 소프트웨어를 실행해야 했을 때 SIP 때문에 고생한 적이 있어요. Unix처럼 동작하지 않았거든요. 그래도 방법을 알면 sideload는 아직 가능합니다. 아니었다면 훨씬 더 큰 반발이 있었겠죠.
- Case-insensitivity, which can indeed break file transfers from other Unixes and can randomly break poorly-coded shell scripts. Sorry Unix people, FAT32 and exFAT conquered the world, those two filesystems are everywhere from MicroSDs to USB thumb drives to MP3 players. if you want case-sensitivity, you have to re-install your OS as case-insensitive.
저도 파일이 대소문자만 다르게 해서 같은 이름으로 존재하는 건 별로 좋아하지 않습니다. 하지만 대소문자 비구분의 문제는 Unicode가 계속 진화하는 표준이라는 점입니다. 그래서 두 운영체제가 파일명 충돌 여부에 대해 정당하게 서로 다른 판단을 내릴 수 있죠. 대소문자 구분 파일시스템에서는 모든 파일명이 일관되게 허용되기 때문에 일관성 문제 자체가 사라집니다. 하지만 대소문자 비구분을 도입하는 순간, Unicode가 지원하는 모든 알파벳의 대소문자 규칙을 파일명 충돌 여부 판단에 반영해야 합니다.
문제는 기본 알파벳 문자만이 아니라 그 모든 변형까지 포함된다는 겁니다. 예를 들어 라틴 문자 e만 해도 HTML 코드로 붙여보면…
e è é ê ë E È É Ê Ë
요즘 Unicode 업데이트의 대부분은 핵심 언어보다는 이모지와 관련이 있을 가능성이 높다는 점은 인정합니다. 하지만 여전히 두 대소문자 비구분 파일시스템이 파일명 충돌에 대해 서로 다르게 판단할 수 있다는 건 난감하죠. 이 주제는 OSNews에서도 논의된 적이 있는데, 그때 Windows NT 세부 구현 이야기가 나왔습니다. 운영체제의 문자 맵은 포맷 시점에 파일시스템에 하드코딩되기 때문에, 다른 운영체제에서 열더라도 더 새롭거나 더 오래된 규칙이 아니라 원래 Unicode 규칙이 적용됩니다. 대소문자 표를 업데이트하려면 매체를 다시 포맷해야 하죠.
하지만 이건 아주 기묘한 파장을 낳습니다. 특히 애플리케이션이 대소문자 비구분 매칭을 수행하려고 할 때요. 애플리케이션, 운영체제, 파일시스템이 서로 파일명 충돌 여부에 대해 모두 다른 결론을 내리는 상황도 생길 수 있습니다. 이런 구석진 사례가 흔할 거라고 말하는 건 아니지만, 그런 결과가 가능하다는 것 자체가 이상합니다.
* 2025-01-29 10:05 pm [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
대소문자 구분 여부에는 찬반 논거가 모두 있습니다. 대소문자 비구분은 이름을 인식하는 인간의 방식에 더 가깝고, 대소문자 구분은 이름을 구성하는 모든 코드포인트가 완전히 동일하지 않으면 두 파일명이 같지 않다는 장점이 있죠(당신 표현대로라면, 비교 로직의 가정 때문에 충돌이 생기지 않는다는 뜻입니다). 하지만 제 요점은 훨씬 단순합니다. FAT32와 exFAT가 이겼습니다. 끝난 이야기예요. 대소문자 구분을 선택하면, 대소문자 비구분인 FAT32와 exFAT와 상호작용해야 하는 엄청난 골칫거리를 스스로 들여오는 겁니다.
그리고 System Integrity Protection과 어떤 소프트웨어에서 문제를 겪으셨나요? 그냥 궁금해서요. 소프트웨어가 불변 디렉터리를 수정하려는 게 아니라면, System Integrity Protection이 장애물이 될 일은 없어야 하거든요.
* 2025-01-29 10:41 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
kurkosdr,
Also, what issues did you have with System Integrity Protection and with what software? Just curious, unless software tries to modify immutable directories, System Integrity Protection shouldn’t be a hurdle.
그건 postgresql이었습니다. 제 기억이 맞다면 홈 디렉터리 설치였는데, 솔직히 자세한 내용은 잘 기억나지 않네요. Mac은 제 전문 분야가 아닙니다. 제가 Mac에서 작업할 때는 대개 고객이 Mac 환경을 쓰고 있어서 장비를 제공해 줄 때뿐이에요. 아마 macOS가 처음부터 UNIX03 호환이었다면 저에게 더 도움이 되었겠죠. 어쨌든 다른 사람들의 도움을 받아 결국 동작하게 만들긴 했습니다.
* 2025-01-30 9:35 pm [Flatland_Spider](https://osnews.com/profile/?user=Flatland_Spider)
It was postgresql. IIRC it was a home directory install, but honestly I don’t recall the details.
아. 저는 그런 건 Macports나 Pkgsrc에 맡깁니다. 제 생각에 서명되지 않았다고 불평한 걸 거예요. LibreWolf도 비슷한 문제가 있는데, 제가 생각하는 그 문제라면 실행하려면 xattr을 하나 추가해야 합니다.
* 2025-01-31 5:52 am [pepa65](https://osnews.com/profile/?user=pepa)
제가 보기에는 (ex)FAT에도 불구하고 대소문자 구분이 이미 이긴 것 같습니다. USB 메모리에 파일을 넣을 때면 제가 공룡이 된 기분이 들고, 그 일도 1년에 한 번 있을까 말까예요. Unicode/UTF8/UTF16 시대에 파일명에서 ‘E’와 ‘e’를 같다고 보는 건 광기입니다. 컴퓨터를 아는 사람이라면 누구나 대문자와 소문자를 구분하는 중요성을 자동으로 알죠. Mac이 아직도 기본으로 대소문자 비구분이라는 게 저에겐 믿기지 않습니다. Windows도 오래전에 바뀌지 않았나요?
2025-01-29 8:31 pm Xanady Asem
물론 Apple은 당신 개인의 주관적 해석에 맞는 “Unix 인증”을 받는 것은 아닙니다. 하지만 Apple은 그 인증을 부여하는 권한 기관이 요구하는 인증을 목표로 하고, 실제로 통과합니다. 그런 인증에 관심 있는 고객들이 찾는 것도 바로 그거죠.* 2025-01-29 8:58 pm [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
Which is what the customers, that may care for such a cert, are looking for.
그러면 흥미로운 질문이 생깁니다. 그런 고객들은 MacOS가 SUS 테스트를 통과하게 만드는 데 필요한 모든 설정을 실제로 하긴 하나요? 애초에 그런 설정이 필요하다는 사실조차 알고 있을까요? 이건 그리스 당국이 2004년 하계 올림픽을 위해 SAIC와 Siemens로부터 값비싼 C4I 시스템을 샀는데(온갖 인증도 갖췄지만) 실제로는 한 번도 제대로 동작하지 않았던 사건이 떠오르게 합니다. 그래도 인증은 있었고, 그게 중요한 거였죠. 마찬가지로, UNIX 시스템으로서 MacOS를 사는 고객들이 그 UNIX 인증 시스템을 기본 상태 그대로(대소문자 구분도 없고 root 계정도 꺼진 상태로) UNIX 시스템처럼 쓰려고 하지는 않기를 바랍니다.
* 2025-01-30 12:26 am [Xanady Asem](https://osnews.com/profile/?user=javiercero1)
이 경우 그 인증은 소비자 제품에서 기본 제공 상태나 즉시 사용 가능한 상태에 대해 아무 말도 하지 않습니다.
참고로 HP-UX, AIX, Solaris도 인프라나 애플리케이션 역할에 맞게 배치할 때는 꽤 많은 “손질”이 필요합니다.
* 2025-01-30 5:57 am [bert64](https://osnews.com/profile/?user=bert64)
정부 분야에서는 이런 일이 아주 흔합니다… 어떤 상황에서는 특정 보안 인증을 받은 제품을 써야 하는데, 정작 인증받은 설정은 기본값과는 너무 다르고, 대개 인증받은 버전은 꽤 오래된 버전입니다(즉, 보안 패치가 빠져 있습니다). 인증 절차가 느리기 때문이죠.
게다가 인증받은 설정은 쓰기 어렵거나 문제를 일으키는 경우가 많습니다. 예를 들어 예전 Windows NT의 C2 인증은 시스템이 네트워크에 연결되어 있지 않고 이동식 저장매체도 없어야 했습니다.
그러니 모두가 속이는 셈이죠. 이론적으로는 인증 가능한 소프트웨어를 돌리지만, 실제로 인증된 버전이나 설정을 쓰는 일은 없습니다.
* 2025-01-30 9:41 pm [Flatland_Spider](https://osnews.com/profile/?user=Flatland_Spider)
맞아요. 악마는 세부사항 속에 있고, 작은 글씨와 각주 속에도 숨어 있죠.
FIPS도 또 다른 예입니다. 많은 소프트웨어가 FIPS 호환이고, 또 많은 FIPS 호환 소프트웨어는 실제로 FIPS 호환 상태가 되려면 설정이 필요합니다.
2025-01-29 11:27 pm Sarreq Teryx
이 중 몇 가지는 건전한 보안 설정처럼 들립니다. 그런 걸 꺼야만 Unix 인증을 받을 수 있다면, 문제는 인증 자체에 있는 것 같습니다.그 외에는, Unix 인증 기관이 Apple을 회원으로 붙잡아 두려고 안달이 난 것처럼 보이네요. 설령 Silver 등급뿐이라 해도요.
* 2025-01-30 8:45 am [kurkosdr](https://osnews.com/profile/?user=kurkosdr)
Some of these sound like sound security settings. If they need to be disabled to get Unix certification, something’s wrong with the certification, itself.
Unix 인증은 사용자가 진짜 root를 필요로 하고, 그에 따르는 위험도 알고 있다고 가정합니다. 그러니 맞아요. Single UNIX Specification은 사용자(root 포함)가 /bin이나 /sbin 같은 디렉터리를 수정하지 못하게 막는 보안 설정들과는 양립할 수 없습니다.
2025-01-30 4:05 am Alex Seifert물론 테스트를 통과시키려면 몇 가지 단계를 거쳐야 합니다. 하지만 첫째, 그런 단계들은 그걸 시도해보고 싶은 사람들에게는 쉽게 수행할 수 있고 문서화도 잘 되어 있습니다. 테스트를 돌리거나 macOS를 가능한 한 SUS 호환 상태에 가깝게 만들고 싶은 사람은 시스템을 그렇게 조정하는 데 몇 분만 쓰면 됩니다. 그럴 능력이 없는 사람은 애초에 그런 것에 관심도 없을 겁니다.
둘째, 이런 기능들 대부분은 Mac의 주 타깃층인 일반 소비자를 보호하기 위해 설계된 것입니다. 다른 사람들은 AIX, Solaris, HP-UX 같은 운영체제는 테스트를 통과하기 위해 많은 조정이 필요 없다고 언급했죠. 하지만 여기서 언급되지 않은 것은 그들의 대상 사용자층입니다. 그런 운영체제들은 전문직 종사자나 열성 사용자만 사용하며, 그들은 시스템 보안을 강화할 수 있고, 자신이 내려받아 실행하는 것에 더 신중할 가능성이 큽니다. 반면 macOS는 매우 다양한 사람들이 사용하고, 그 대다수는 자신이 무엇을 하는지 모르기 때문에 기본으로 활성화된 보안 기능이 필요합니다.
저는 10.0이 나온 이후 줄곧 macOS를 주 운영체제로 써 왔고, Unix 호환성 문제를 겪은 적이 없습니다. Mac OS X로 넘어오기 전에는 Irix, Solaris, 초기 Linux 버전들을 많이 다뤘기 때문에, Unix 계열 운영체제에 낯선 사람도 아닙니다.
2025-01-30 5:00 am j0scher
저는 사실 MacOS가 UNIX 인증을 받는 것 자체에는 화가 나지 않습니다. 오히려 BSD나 Illumos 같은 진짜 혈통의 Unix들이 인증을 받지 못하는 점이 더 짜증나요. 주된 이유는 인증 비용 때문이죠. The Open Group이 비상업적 오픈소스 Unix 시스템들에 대해서는 무료로 해주면 좋겠습니다.
2025-01-30 5:19 am r_a_trip
그 인증은 거짓말이 아닙니다. MacOS를 SUS에 맞게 설정할 수 있으니까요. 그러니 MacOS는 “진짜 Unix”입니다. 다만 그것이 SUS 준수가 필요한 상황을 제외하고, 더 큰 맥락에서 실제로 무슨 의미가 있는지는 의문입니다.
UNIX에 대해 유난히 경외감을 가진 좀 더 괴짜스러운 집단이 있다는 건 알지만, 지금은 2025년이고 컴퓨팅 세계 전체가 UNIX를 애타게 원하고 있지는 않습니다. MacOS는 인증이 없어도 지금만큼 성공했을 겁니다. 그리고 인증이 없다고 해서 Unix 계열 운영체제들이 타격을 입는 것 같지도 않고요.
* 2025-01-30 1:51 pm [dark2](https://osnews.com/profile/?user=dark2)
맞아요. 질문이 “OSX를 Unix 호환 상태로 만들 수는 있지만, 왜 그래야 하지?”라면, 거기에 합당한 답이 나올 것 같지는 않네요. 그리고 실제 Unix나 Linux가 훨씬 더 잘 해결해 주지 못하는 사용 사례도 분명 없을 겁니다.
2025-01-30 7:05 am [email protected]
저는 Apple 옹호론자는 아닙니다. 하지만 수십 년 동안 Thom의 이상주의는 그냥 웃음이 나옵니다. 맞아요, 현대 운영체제는 낡은 표준을 완벽히 만족시키면서도 단순하고 안전한 사용자 경험을 동시에 제공할 수 없습니다. Apple은 그 오래된 표준을 완전히 맞추고 싶어 하는 열두 명쯤 되는 사람들을 위해 운영체제를 완전 호환 상태로 만드는 방법을 제공합니다. 뭐, uucp를 돌리고 싶을 때 말이죠. 기술 세계는 Thom이 바라는 방식으로 돌아가지 않습니다. 그는 절대 만족하지 않겠지만, 우리 대부분에게 이건 문자 그대로 중요하지 않습니다.* 2025-01-30 8:07 am [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
I am not an Apple apologist. But over the decades you just have to laugh at Thom’s idealism. Yes, modern OSes can’t comply with an outdated standard and deliver an simple, secure user experience.
완전히 잠긴 macOS에 대해 많은 Mac 사용자들조차 압도적으로 반대할 것이라고 저는 생각합니다. “자신들의 안전을 위해” 모든 열쇠를 넘겨서 macOS를 완전히 iOS처럼 만들고 싶어 하는 사람들은 소수예요.
Apple provides a way for the dozen people who care to make the OS entirely compatible with this outdated standard, when you want to run ‘uucp’ I guess.
표준은 이식성을 위해 존재합니다. 당신이 개인적으로 이식성에 관심이 없을 수도 있다는 점은 이해합니다. 그렇다면 물론 그건 당신 자유죠. 하지만 관심이 있다면, 플랫폼이 표준을 무시하고 최종 사용자에게서 제어권을 빼앗을 때 정말 골치 아픕니다.
…but for most of us, this literally doesn’t matter.
Apple에는 이 문제를 매우 중요하게 생각하는 상당한 기술 사용자 기반이 있다고 생각합니다. 그들은 바로 잘 지원되는 하드웨어 위의 Unix와 거슬리지 않는 GUI 때문에 Mac OS를 선택한 거예요. 기술 커뮤니티의 Unix 사용자들이 없었다면, 솔직히 macOS가 아직도 존재했을지조차 확신할 수 없습니다. Apple은 키보드 붙은 iPad 쪽으로 가려고 macOS를 접어 버렸을 수도 있어요.
* 2025-01-30 4:18 pm [[email protected]](https://osnews.com/profile/?user=jvanderberg@gmail.com)
거의 모든 Unix/Linux 앱은 수정 없이도 MacOS로 크로스 컴파일됩니다. 방금 제 Mac에서 git 소스 코드를 체크아웃하고, 터미널을 열고, ‘make’를 입력했더니, 몇 분 뒤 동작하는 git 바이너리가 생겼습니다. 이걸 Windows 명령 프롬프트에서 해보세요.
저도 MacOS에서 온갖 Unix/Linux 명령줄 앱을 씁니다. 다만 ‘uucp’를 돌려본 적은 없네요.
* 2025-01-30 4:53 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
Almost every Unix/Linux app cross compiles to MacOS with no modification. I just checked out the source code to git on my mac, launched a terminal, typed ‘make’, and a minutes later a working git binary was there. Try this at the windows command prompt.
크로스 호환성은 당신이 무시하는 Unix 표준들 덕분에만 가능합니다. Unix 표준 준수(공식적이든 아니든)가 없다면 macOS의 크로스 호환성은 성립하지 못했을 겁니다. 그러니 macOS가 아직도 Unix 표준에 맞출 수 있다는 사실에 오히려 감사해야 해요.
그리고 말 나온 김에 덧붙이자면, Windows는 WSL2 덕분에 macOS보다 Linux와 더 호환됩니다.
* 2025-01-30 6:40 pm [[email protected]](https://osnews.com/profile/?user=jvanderberg@gmail.com)
저는 Unix 호환성을 무시하는 게 아닙니다. MacOS에는 그게 있어요. 제가 무시하는 건 완벽을 강요하는 지나치게 꼬치꼬치한 이상주의입니다. MacOS의 Unix 호환성은 충분히 좋고, 실제로 꽤 훌륭합니다. WSL이 Linux와 더 호환적인 건, 그게 Linux이기 때문이죠. 저도 MacOS에서 VM으로 Linux를 돌릴 수 있습니다.
* 2025-01-30 8:15 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
I am not dismissive of unix compatibility. MacOS has it. I am dismissive of nit picky idealism that dictates perfection. MacOS has more than good enough Unix compat, it’s really quite good.
음, 이 입장 자체에는 저도 크게 반대하지 않습니다. 다만 원래 글은 macOS 호환성에 대한 Unix 표준과 그 중요성을 깎아내리는 듯한 느낌이어서 그게 거슬렸어요.
macOS 도구들 중 일부는 더 현대적인 도구 대신 과거에 머물러 있기도 합니다. 또 Apple의 GPL3 코드 보이콧도 도움이 되지 않고요…
https://news.ycombinator.com/item?id=18852887
그나마 다행인 건 macports와 homebrew 같은 서드파티 소프트웨어 저장소가 있다는 점입니다. 그 유지보수자들은 소프트웨어를 최신 상태로 유지하는 데 더 좋은 일을 하고 있죠. 대부분의 파워 유저들은 최신 도구를 쓰기 위해 이런 저장소를 활용하는 데 익숙할 거라고 생각합니다.
WSL is more compatible with Linux because, it’s Linux. I can run Linux in a VM on MacOS too.
“WSL”은 Microsoft의 Linux 구현이었습니다. “WSL2”는 Microsoft가 Windows 데스크톱 환경과 통합하기 위한 확장을 더한 실제 Linux 운영체제를 돌리는 방식입니다(일반적인 VM과는 다르죠). Apple에도 그런 게 있나요? macOS에는 그런 게 보이지 않는데, 저 말고도 이걸 묻는 사람들이 있더군요.
* 2025-01-30 10:33 pm [Flatland_Spider](https://osnews.com/profile/?user=Flatland_Spider)
Some of the macos tooling is stuck in the past rather than more modern tools.
macOS는 결국 특정 시점에 고정된 운영체제니까요.
The saving grace here is that 3rd party software repos including macports and homebrew are available. Their maintainers do a better job keeping software up to date. I imagine most power users are familiar with using these repos for updated tools.
Apple이 기본 제공 소프트웨어를 줄이기 시작했을 때 사람들은 화를 냈지만, macOS용 네이티브 소프트웨어 빌드에 꼭 필요하지 않은 것들은 패키지 관리자 쪽으로 보내는 편이 더 합리적입니다. 기본 제공 Python과 Ruby는 있으면 좋긴 했지만, 사실 별 의미는 없었어요. 기본 제공 구버전과 씨름한 뒤 패키지 관리자를 설치하는 편이 더 성가시죠.
이건 특정 시점에 고정된 Linux 배포판들과도 같은 상황입니다. 쉽게, 필요에 따라 업그레이드할 수 있도록 기본 구성에서 빼내야 해요.
* 2025-01-30 10:49 pm [Flatland_Spider](https://osnews.com/profile/?user=Flatland_Spider)
“WSL2” is running a real linux OS with microsoft’s extensions to integrate it into the windows desktop environment (unlike a standard VM). Does apple have that?
제가 WSL2를 해부해 본 건 아니라 틀릴 수도 있지만, 제 이해로는 대부분의 수정은 Hyper-V 확장이고, 그건 대부분의 저장소에 있으며 VirtIO 드라이버 작업 위에 얹힌 것 같습니다.
macOS에도 내장 하이퍼바이저 프레임워크는 있지만, 자체 하이퍼바이저는 없습니다.
https://developer.apple.com/documentation/hypervisor
Apple도 이미 잘 알려진 VirtIO 드라이버를 활용해서 WSL과 비슷한 무언가를 만들 수 있을 겁니다.
또는 Apple이 UNIX 노선을 계속 밀고 나가면서 운영체제 자체에 더 많은 *nix 호환성을 넣을 수도 있겠죠. 제가 보고 싶은 건 하이퍼바이저와 OCI 컨테이너 두 가지입니다. 내장 하이퍼바이저로 VM을 띄우는 건 Linux를 떠나와 있을 때 아쉬운 점 중 하나예요.
* 2025-01-30 9:21 am [Thom Holwerda](https://osnews.com/profile/?user=Thom_Holwerda)
이 글에는 이 문제가 얼마나 중요하지 않은지에 대해 따로 한 문단 전체를 할애해 두었습니다. 글을 안 읽으셨나요?
2025-01-30 10:28 am chriscox
AIX가 떠오르네요. “SVR2 기반입니다.” 정말요??
2025-01-30 11:21 am noworrieseh
이 글은 인증 절차에 대해 놀라울 정도로 치졸하고 무지합니다.
클릭베이트식 “__blank__는 거짓말이다” 대신, “MacOS가 UNIX 인증을 받는 방식을 깊이 들여다보기” 같은 제목이었다면 디테일은 흥미로웠을 겁니다. 의견 섞인 빈정거림은 그렇지 않았고요.
2025-01-30 11:28 am RumblePony
macOS가 인증된 UNIX라는 건 거짓말이 아닙니다. 테스트를 모두 통과했고 인증을 받았어요. 그게 전부죠. 여기서 무슨 문제가 있는지 저는 잘 모르겠습니다.* 2025-01-30 3:20 pm [pfgbsd](https://osnews.com/profile/?user=pfgbsd)
동의합니다. 실용적인 관점에서 보면, uucp가 없다고 아쉬워할 macOS 사용자가 있을 거라고는 도저히 생각되지 않지만, 내부에 표준 POSIX 인터페이스가 있는 건 모두가 좋아하죠.
아, 그리고 좀 파고들어 본 끝에, 그들이 준수를 위해 FreeBSD에 적용했던 변경 사항들 중 상당수를 제가 병합했습니다. 다만 FreeBSD는 uucp 같은 걸 base system에 넣는 걸 한 번도 고려한 적이 없어요.
2025-01-30 2:08 pm iluvcrap2000
괴짜들아, 아무도 신경 안 써. 아마 1000명쯤이나 쓰겠지, 그래서 뭐. 다른 사람들은 터미널 앱에 가본 적도 없어. 한 번도. emacs -q –no-splash -f tetris* 2025-01-30 5:20 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
iluvcrap2000,
Nerds, nobody cares. About 1000 people probably uses it, big woop. Every body else haven’t even been to the terminal app. EVER. emacs -q –no-splash -f tetris
macOS 개발자들을 비난하는 건 무슨 의미인지 모르겠습니다. 어쨌든 그 “괴짜들”이야말로 macOS가 아직 존재하는 유일한 이유일 가능성이 높아요. 파워 유저가 중요하지 않다는 생각을 진지하게 받아들이면, macOS라는 플랫폼은 Apple에게 중복물이 됩니다. 파워 유저 시장이 없다면 macOS는 iOS로 흡수되겠죠. 그건 당신에게는 괜찮을지 몰라도, 파워 유저에게는 아닙니다. macOS의 파워 유저적 측면, 터미널을 포함해서요, 그걸 가볍게 여기는 건 정말 근시안적이라고 생각합니다.
2025-01-30 3:56 pm cpcf
이제 Apple은 Linux로 넘어가려는 소수이자 계속 줄어드는 사용자들을 붙잡으려는 건가요? “우리는 Unix다” 전략인가요, 아니면 “우리는 MS가 아니다” 전략인가요? 좀 흐릿해 보이네요.하지만 정말로, 소유주가 MacOS에 왕의 새 옷 같은 걸 입히려는 모습은 MacOS의 미래에 좋은 징조가 아닙니다. 우리 중 나이 든 사람들은 이런 종류의 일을 이전에도 모두 봐 왔죠.
2025-01-30 10:14 pm Flatland_Spider
macOS는 제가 익숙한 대부분의 *nix 도구를 호환성 계층이나 마법의 VM 없이 돌릴 수 있으니, 제 아주 느슨한 기준으로는 꽤 괜찮은 *nix입니다.그렇다고 해도 macOS는 Unix가 아닙니다. LOL
오래전에 저는 FOSS *nix들, FreeBSD와 여러 Linux 배포판들을 가지고 놀았지만, 기업용 소프트웨어 지원이 되는 데스크톱을 원했습니다. 최소한 당시의 FreeBSD나 Linux보다는 더 지원이 되는 환경이요.
그래서 OS X 10.4 Tiger가 깔린 리퍼비시 12인치 PowerBook과 OS X missing manual 책을 샀습니다. 책을 읽으며 일반적인 FOSS *nix 설치에서 하던 여러 작업을 해 봤죠. 당시 저는 Unix 계열 운영체제에 아주 능숙한 편은 아니었지만, 돌아다니고 서비스 다루고 소프트웨어 설치하고 하는 정도는 할 수 있었습니다. 그런데 책을 읽다 보니 깨달았어요. 이건 Unix가 아니구나. FreeBSD와 Debian/RHEL이 Unix다. macOS는 Unix가 아니다. FOSS *nix들, 즉 사실상의 Unix 표준 전달자들처럼 동작하지 않으니까요.
macOS는 대부분의 FOSS *nix와 호환되지만 전혀 다른 무언가이고, 그건 괜찮습니다. 운영체제를 약간만 손보면 쉽게 작업할 수 있을 정도로는 *nix스럽거든요. 반면 Windows는 마법의 VM 없이 *nix 도구를 쓰려 하면 고통의 불경한 수렁이니, macOS가 어느 정도 Unix 같은 정도면 충분합니다. 🙂
2025-01-31 4:18 am Z_God
어쩌면 그 temporary waivers는 Open Group 회원에게는 접근 가능한 걸까요? 여기 링크된 페이지들을 보면 없는 것 같긴 합니다만: http://www.opengroup.org/csq/search/t=XY1.html표준 macOS라도 최소한 어느 버전의 UNIX에는 맞게 유도할 수 있다는 점 자체는 가치가 있어 보입니다.
2025-01-31 9:37 am decuser
하품… 저는 MacOS, Linux, FreeBSD, v6, v7를 쓰면서 제가 하고 싶은 걸 정확히 합니다. 제가 원하는 *nix 경험을 얻기 위해 Mac의 ‘기능들’을 조금 우회하는 건 다른 것들과 다를 바 없어요. 징징거릴 사람은 언제나 징징거립니다.
2025-01-31 10:02 pm acoopersmith
Apple이 이 절차를 거치는 이유는, MacOS를 광고에서 UNIX라고 부르면서 상표 라이선스를 받지 않았다는 이유로 The Open Group이 제기한 소송의 합의 때문입니다. 배경 이야기는 https://www.osnews.com/story/3767/unixs-courtroom-adventures-continue/ 와 https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified 를 보세요.
참고로 Solaris 11.4는 출시 당시 UnixV7 인증을 받았지만, 이후 인증 갱신을 하지 않아서 목록에 없습니다. https://www.opengroup.org/openbrand/register/brand3642.htm 를 보세요. 예를 들어 파일을 삭제해도 이전 ZFS 스냅샷의 일부일 수 있으므로 디스크 공간이 반드시 바로 반환되지 않는 문제 같은 예외가 있었죠. POSIX 파일시스템 명세는 copy-on-write 파일시스템과 스냅샷보다 더 오래된 것입니다.
* 2025-01-31 10:33 pm [Alfman](https://osnews.com/profile/?user=Alfman)verbose=1
acoopersmith,
Apple goes through this process due to the settlement of the lawsuit from the Open Group for claiming that MacOS was UNIX in advertising without having a license for the trademark
와, 기억력이 정말 좋으시네요. Apple이 상표를 오용했다는 옛 법적 사건이 오늘날에도 의미가 있는지는 잘 모르겠지만, 그래도 정말 흥미로운 기사들이네요. 더 읽고 싶었는데, 인용된 businessweek 링크가 죽어 있어서 아쉬웠어요.
또 macOS를 준수 상태로 만드는 데 들어간 작업 규모를 설명하는 Terry Lambert의 글도 정말 흥미롭네요. 링크해 주셔서 감사합니다!
* [Patreon 후원자가 되기](https://www.patreon.com/osnews)
* [OSNews 굿즈 구매](https://www.bonfire.com/store/osnews/)
* [계정 만들기](https://www.osnews.com/wp-login.php?action=register)
* [로그인](https://www.osnews.com/wp-login.php)
주제
* [SysV init 3.09 released](https://www.osnews.com/story/138976/sysv-init-3-09-released/) 2024년 3월 25일 • 댓글 2개
* [AIX Commands you Should not Leave Home Without](https://www.osnews.com/story/16292/aix-commands-you-should-not-leave-home-without/) 2006년 10월 25일 • 댓글 5개
* [Terminal Emulator Settings](https://www.osnews.com/story/9531/terminal-emulator-settings/) 2005년 1월 27일 • 댓글 14개
* [Future Computing, Part II: Unix vs. the world](https://www.osnews.com/story/5342/future-computing-part-ii-unix-vs-the-world/) 2003년 12월 8일 • 댓글 22개
* [1972 UNIX V2 “beta” resurrected from old tapes](https://www.osnews.com/story/141769/1972-unix-v2-beta-resurrected-from-old-tapes/) 2025년 2월 20일 • 댓글 없음
* [Why do I not use “AI” at OSNews?](https://www.osnews.com/story/144405/why-do-i-not-use-ai-at-osnews/) 2026년 2월 15일 • 댓글 74개
* [The great license-washing has begun](https://www.osnews.com/story/144547/the-great-license-washing-has-begun/) 2026년 3월 5일 • 댓글 68개
* [Never bet against x86](https://www.osnews.com/story/144527/never-bet-against-x86/) 2026년 3월 3일 • 댓글 50개
* [The official unplanned emergency OSNews fundraiser!](https://www.osnews.com/story/144352/the-official-unplanned-emergency-osnews-fundraiser/) 2026년 2월 9일 • 댓글 51개
* [Windows native application development is a mess](https://www.osnews.com/story/144650/windows-native-application-development-is-a-mess/) 2026년 3월 23일 • 댓글 48개
* [Is 2024 the year of Windows on the desktop?](https://www.osnews.com/story/139987/is-2024-the-year-of-windows-on-the-desktop/) 2024년 6월 20일
* [Apple intentionally kills web applications for EU users in iOS 17.4 onward to spite its EU users](https://www.osnews.com/story/138605/apple-intentionally-kills-web-applications-for-eu-users-in-ios-17-4-onward-to-spite-its-eu-users/) 2024년 2월 15일
* [Made O’Meter helps you easily and quickly avoid American products](https://www.osnews.com/story/141877/made-ometer-helps-you-easily-and-quickly-avoid-american-products/) 2025년 3월 6일
* [$HOME, not so sweet $HOME](https://www.osnews.com/story/136717/home-not-so-sweet-home/) 2023년 8월 19일
* [Some personal news](https://www.osnews.com/story/138936/some-personal-news/) 2024년 3월 23일
© OSnews Inc. All Rights Reserved.
OSnews와 OSnews 로고는 OSnews의 상표입니다.
테마 커스터마이징: Adam Scheinberg
Wordpress 기반으로 구동됩니다.
독자 댓글의 소유권은 작성자에게 있습니다.
우리는 그 내용에 대해 어떤 책임도 지지 않습니다.
이 웹사이트에 표시되거나 언급된 모든 상표, 아이콘, 로고의 소유권은 해당 소유자에게 있습니다.
OSnews 기사 복제는 OSnews의 명시적 허가가 있을 때만 허용됩니다.
복제물에는 적절한 출처 표기가 있어야 합니다.
아카이브에서
OSnews Copyright © 2026.
© OSnews Inc · 테마: Adam Scheinberg