Windows 95에서 리눅스를 돌린다고? WSL9x라는 황당하고도 멋진 프로젝트

추억의 Windows 95가 갑자기 왜?

이번에 Codeberg에 공개된 WSL9x라는 프로젝트가 좀 웃기면서도 흥미로워요. 이름만 봐도 짐작이 가시죠? Microsoft가 만든 WSL(Windows Subsystem for Linux), 그러니까 Windows 10/11에서 리눅스 명령어와 바이너리를 그대로 돌리게 해주는 기능 있잖아요. 그걸 Windows 95/98/Me 시절로 거꾸로 가져간 거예요. 1995년에 나온 운영체제 위에서 리눅스 ELF 바이너리를 실행시키는 거죠.

잠깐, ELF가 뭔지부터 풀게요. ELF(Executable and Linkable Format)는 리눅스에서 쓰는 실행 파일 포맷이에요. Windows의 .exe(PE 포맷)랑 다른 형식이라서, 보통은 Windows에서 그냥 실행할 수 없어요. WSL9x는 이걸 Windows 9x 환경에서 어떻게든 돌게 만든 해킹 같은 프로젝트예요.

어떻게 동작하는가

Windows 9x는 16비트와 32비트가 섞인, 지금 기준으론 정말 원시적인 운영체제예요. 메모리 보호도 엉성하고, 멀티태스킹도 제대로 안 되고, 무엇보다 POSIX 호환성 같은 건 전혀 없거든요. 리눅스 바이너리가 호출하는 시스템 콜(open, read, write, fork 같은 것들)을 받아줄 친구가 OS 안에 없는 거죠.

그래서 WSL9x는 시스템 콜 에뮬레이션 레이어를 직접 구현했어요. 리눅스 바이너리가 int 0x80 같은 인터럽트로 커널에게 "파일 열어줘"라고 부탁하면, WSL9x가 중간에서 그걸 가로채서 Windows 9x의 Win32 API로 번역해주는 식이에요. 마치 통역사처럼요. 진짜 WSL1이 NT 커널 위에서 비슷한 일을 했던 것에서 영감을 받은 구조예요.

구현체는 주로 어셈블리어와 C로 짜여 있고, Windows 9x의 VxD(가상 디바이스 드라이버) 메커니즘을 활용해서 저수준 후킹을 한다고 해요. 이게 정말 만만치 않은 작업인데, Windows 9x가 메모리 모델이나 스레드 처리에서 NT 계열이랑 완전히 다르거든요. 예를 들어 fork() 같은 시스템 콜은 Windows 9x에선 흉내 내기가 무지하게 어려워요. 진짜 fork는 프로세스 메모리 공간을 통째로 복제하는 건데, 9x는 그런 개념이 없으니까요.

왜 이런 걸 만드는 걸까

실용적인 이유? 솔직히 별로 없어요. 2026년에 Windows 95 머신을 업무에 쓰는 사람은 거의 없잖아요. 그럼에도 이런 프로젝트가 의미 있는 건, 운영체제 내부 동작을 가장 깊은 수준에서 이해해야만 만들 수 있는 결과물이라는 점이에요. 시스템 콜 인터페이스, 메모리 매핑, 동적 링커, ELF 로더 같은 걸 처음부터 끝까지 다 다뤄야 하거든요.

비슷한 정신을 가진 프로젝트들이 있어요. Cygwin은 Windows에서 POSIX 환경을 제공하는 오래된 도구고, MSYS2는 그걸 좀 더 현대화한 거고요. 반대로 Wine은 리눅스에서 Windows 바이너리를 돌리는 프로젝트죠. WSL9x는 Wine과 비슷한 발상인데, 시간을 거꾸로 돌려서 "옛날 OS에 새 시대 바이너리를" 얹는다는 점이 독특해요.

레트로 컴퓨팅 씬에서도 비슷한 시도가 계속 있어요. 예를 들어 누군가는 Apple II에서 Doom을 돌리고, 또 누군가는 닌텐도 DS에서 리눅스를 부팅시키죠. WSL9x도 그 계보에 속한다고 보면 돼요. "왜 하느냐"가 아니라 "되는지 보자"가 동기인 거예요.

기술적으로 배울 만한 포인트

이 프로젝트 소스 코드를 한 번 훑어보면 좋은 공부거리가 정말 많아요. 첫째, 시스템 콜 ABI(Application Binary Interface)가 어떻게 정의되는지 실감할 수 있어요. 리눅스 x86의 syscall 번호 테이블, 레지스터에 어떤 인자가 들어가는지, 반환값이 어떻게 돌아오는지 같은 게 코드에 그대로 드러나거든요.

둘째, 동적 링킹의 실체를 볼 수 있어요. ELF 바이너리가 실행될 때 ld-linux.so라는 동적 링커가 어떻게 라이브러리들을 메모리에 올리고 심볼을 연결하는지, 이걸 직접 구현하면서 깨닫게 돼요. 평소엔 그냥 "libc가 자동으로 붙겠지" 하고 넘어가던 부분이거든요.

셋째, 운영체제 호환성 레이어 설계의 어려움을 체감할 수 있어요. 단순히 함수 이름만 매핑하는 게 아니라, 시그널 처리, 파일 디스크립터 관리, 권한 모델 같은 근본적인 차이를 어떻게 우회하거나 흉내 낼지 결정해야 해요.

한국 개발자에게 주는 시사점

당장 실무에 쓸 일은 없지만, 시스템 프로그래밍이나 임베디드 쪽에 관심 있는 분이라면 코드를 읽어볼 가치가 충분해요. 특히 요즘은 eBPF, Wasm 런타임, 컨테이너 런타임(runc, containerd) 같은 "호환성 레이어" 기술이 실무에서 점점 중요해지고 있거든요. WSL9x 같은 프로젝트로 기초 체력을 쌓으면, 그런 모던한 기술도 훨씬 깊게 이해할 수 있어요.

또 사이드 프로젝트로 "쓸데없어 보이지만 깊이 있는 것"을 만드는 문화도 본받을 만해요. 한국 개발자 커뮤니티에선 "실용성"이 너무 강조되는 경향이 있는데, 가끔은 이렇게 순수한 호기심으로 깊게 파보는 경험이 실력을 한 단계 끌어올려 주거든요.

마무리

WSL9x는 30년 전 OS에 현대 리눅스 바이너리를 얹는, 실용성보다는 장인 정신에 가까운 프로젝트예요. 시스템 콜 에뮬레이션과 ELF 로딩의 본질을 공부하기엔 더없이 좋은 교재이기도 하고요.

여러분이라면 시간이 남을 때 어떤 "쓸데없지만 멋진" 프로젝트를 만들어 보고 싶으세요?