왜 Windows는 여전히 핵심에서 POSIX를 거부하는가 (그리고 아마도 앞으로도 그럴 것이다)

발행: 1주 전 (2025년 12월 30일 오후 10:09 GMT+9)

8 min read

Source: Dev.to

번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

Windows는 Unix에서 진화하지 않았다

Unix‑like 시스템은 공유 머신에서 발전했으며, Windows는 개인용 컴퓨터에서 발전했습니다. POSIX가 표준이 되었을 때, Windows는 이미 방대한 설치 기반과 DOS 및 초기 Windows API를 중심으로 구축된 호환성 레이어를 가지고 있었습니다. Unix 의미 체계에 맞게 기반을 재작성하면 그 호환성이 파괴되었을 것이며, Windows는 깨끗한 POSIX 구현보다 생존을 선택했습니다.

POSIX는 철학이며, 단순한 API가 아니다

POSIX는 프로세스 관리, 파일 시스템 의미론, 그리고 프로세스 간 통신에 관한 일련의 가정을 구현합니다. Windows는 객체‑지향 핸들, 통합 네임스페이스, 그리고 별개의 보안 모델이라는 다른 아이디어 집합을 중심으로 설계되었습니다. 이러한 차이는 단순히 API 불일치 수준을 넘어 운영 체제의 핵심 아키텍처에 영향을 미칩니다.

Windows NT는 이미 “Too Far Gone”

Microsoft가 Windows NT를 구축할 때, 팀은 Unix과 차별화된 의도적인 설계 선택을 했습니다. NT는 마이크로커널에서 영감을 받은 아키텍처, 다른 I/O 모델, 그리고 접근 토큰과 임의 ACL에 기반한 보안 서브시스템을 도입했습니다. 그 시점에서는 POSIX 호환성을 네이티브 구현으로 제공할 수 없었고, 에뮬레이션이나 호환성 레이어를 통해서만 제공될 수 있었습니다.

Microsoft Actually Tried POSIX (More Than Once)

POSIX Subsystem (Windows NT 3.5) – 초기 시도로 Unix와 유사한 환경을 제공했지만 채택이 거의 없었습니다.
Interix (Windows Services for UNIX) – Windows Server 2003 및 이후 버전과 함께 제공된 보다 완전한 POSIX 서브시스템입니다.

두 솔루션 모두 기술적으로는 작동했지만, Windows 사용자는 주요 워크로드에 Unix 의미론이 필요하거나 원하지 않았기 때문에 경제적으로는 실패했습니다.

The Compatibility Trap (Windows’ Greatest Strength)

Windows의 가장 큰 장점은 하위 호환성입니다. 수십 년 전에 작성된 소프트웨어도 최신 Windows 릴리스에서 여전히 실행됩니다. 완전한 POSIX 호환성을 달성하려면 프로세스 종료, 파일 권한, 경로 처리와 같은 기본 시스템 동작을 변경해야 하며, 이는 수많은 레거시 애플리케이션을 깨뜨릴 것입니다. 호환성을 깨는 비용은 POSIX 일치에서 얻을 수 있는 어떤 이점보다도 더 큽니다.

Why WSL Exists (And Why It’s Not “POSIX Windows”)

The Windows Subsystem for Linux (WSL) is often misunderstood as “POSIX Windows.” In reality:

WSL is not a native POSIX implementation inside the NT kernel.
WSL runs a genuine Linux user space alongside Windows, translating system calls to the Windows kernel without contaminating the core.

Microsoft’s lesson was clear: “Don’t modify the NT core; contain Unix instead.” WSL provides developers with a Linux environment while preserving Windows’ native architecture.

POSIX vs. NT: Security Models Clash Hard

POSIX 보안은 사용자/그룹 ID, 파일 모드 비트, 그리고 임의 접근 제어에 의존합니다.
Windows 보안은 액세스 토큰, 보안 식별자(SID), 그리고 풍부한 ACL 시스템을 사용합니다.

각 모델은 장단점이 있지만 근본적으로 호환되지 않습니다. 하나를 다른 쪽에 매핑하면 정보가 손실되기 때문에 원활한 POSIX 보안 계층을 구현하기는 현실적으로 어렵습니다.

전체 POSIX가 Windows에 도움이 되기보다 해를 끼치는 이유

If Windows가 완전한 POSIX‑compliant가 되려면, 레지스트리 기반 구성, COM, NT object manager, 그리고 세분화된 보안 모델 등 핵심 기능들을 많이 포기해야 합니다. 이 트레이드‑off은 비즈니스 가치가 거의 없습니다. 왜냐하면 엄격한 POSIX 준수를 요구하는 시장(고성능 컴퓨팅, 임베디드 Unix 시스템)은 이미 네이티브 Linux 배포판으로 충족되고 있기 때문입니다.

현실: Windows는 POSIX 없이도 승리한다

Windows는 데스크톱 생산성, 엔터프라이즈 애플리케이션, 게임, 클라우드 인프라스트럭처에서 지배적입니다. POSIX의 우위는 주로 서버‑사이드, 과학, 임베디드 환경에서 중요하며—Microsoft가 이미 Azure, Kubernetes, WSL을 통해 Linux를 수용하고 있는 영역입니다. Windows를 재작성하는 대신 Linux가 뛰어난 부분에 통합함으로써 Microsoft는 핵심 아키텍처를 포기하지 않고 시장 위치를 유지합니다.

개발자들이 놓치는 큰 교훈

POSIX는 도덕적 기준이 아니라 특정 환경에 최적화된 설계 선택입니다. Windows NT는 다른 현실—대중 시장 데스크톱 컴퓨팅, 광범위한 이전 버전 호환성, 그리고 포괄적인 보안 모델—에 최적화되어 있습니다. Windows가 POSIX를 거부하는 이유는 이를 채택하려면 생태계를 깨뜨리는 근본적인 재작성(리라이트)이 필요하기 때문입니다.

Final Thought

질문은 “Why doesn’t Windows fully support POSIX?”가 아니라 “Why would Windows abandon the platform that makes it successful?”이다. 운영 체제는 설계의 우아함이 아니라 해결하는 문제에 의해 평가된다. Windows는 너무 많은 의존자가 있어 그 본질을 다시 쓰기 어렵고, 핵심을 포기하기보다 적응함으로써 계속 번성한다.