1999년의 Mac OS 9에서 오늘의 웹을 본다는 도전, Macsurf 이야기

클래식 Mac을 기억하시나요

Mac OS 9는 1999년에 나온 애플의 마지막 "클래식" 운영체제예요. 지금 우리가 쓰는 macOS의 조상이긴 하지만, 내부 구조는 완전히 달라요. Mac OS X가 UNIX 기반으로 새로 만들어지면서 그 이전 시대는 그냥 박물관 유물처럼 남았거든요. PowerPC G3, G4 같은 CPU에서 돌아가고, 메모리 보호도 없고, 협력적 멀티태스킹(cooperative multitasking)이라는 옛날 방식을 씁니다. 이게 뭐냐면, 한 프로그램이 잠깐 양보를 안 하면 시스템 전체가 멈추는 그런 구조예요. 요즘 OS처럼 커널이 강제로 프로세스를 가로채는 게 아니라, 앱들끼리 신사적으로 CPU를 나눠 쓰자고 약속한 거죠.

이런 옛날 컴퓨터에서 현대 웹을 본다는 건 사실상 불가능에 가까워요. 요즘 웹사이트는 거의 다 HTTPS로 묶여 있고, TLS 1.2나 1.3 같은 최신 암호화 표준을 요구하거든요. Mac OS 9 시절의 브라우저(인터넷 익스플로러 5, iCab, Netscape)는 이미 한참 전에 멈춘 SSL 3.0이나 TLS 1.0까지만 지원해서, 어떤 사이트를 열어도 "지원하지 않는 프로토콜"이라는 에러만 떠요. 게다가 JavaScript는 ES3 수준에서 멈췄고, 폰트 렌더링도 옛날 그대로라 현대 웹디자인이 제대로 보일 리가 없죠.

Macsurf가 풀어낸 방식

mplsllc가 만든 Macsurf는 이 문제를 정면 돌파하는 대신 영리한 우회로를 택했어요. 클라이언트 쪽에서는 가볍게 동작하고, 무거운 작업—TLS 협상, JavaScript 실행, CSS 렌더링—은 외부 프록시 서버에 맡기는 방식이에요. 모바일 데이터가 비싸던 시절 Opera Mini가 썼던 방식과 비슷해요. 서버에서 페이지를 다 그린 다음 단순한 형태로 변환해서 옛날 Mac에 내려주는 거죠.

기술적으로 흥미로운 부분은 Mac OS 9의 네이티브 API인 클래식 툴박스(Classic Toolbox)를 직접 호출한다는 점이에요. 윈도우 그리기, 이벤트 처리, 메모리 관리까지 전부 1990년대 매뉴얼에 나오는 그대로 코드를 작성해야 합니다. 컴파일러도 Metrowerks의 CodeWarrior나 Retro68 같은 크로스 컴파일러를 써야 하고요. 요즘 개발자가 익숙한 Stack Overflow 검색 한 번이면 다 해결되는 환경과는 정반대예요. 자료가 거의 없어서 옛날 Apple의 PDF 매뉴얼을 뒤져가며 만들어야 합니다.

메모리 관리도 한 챕터예요. Mac OS 9에는 가상 메모리가 있긴 했지만 매우 제한적이라, 앱마다 사용할 메모리 크기를 미리 설정해야 했어요. 핸들(handle)이라는 "포인터의 포인터" 구조로 메모리를 다뤘는데, 이건 시스템이 메모리를 효율적으로 압축하려고 블록을 옮길 수 있게 한 옛날식 트릭이에요. Macsurf 코드를 보면 이런 옛 패턴이 그대로 살아 있어서, 현대 개발자가 보면 거의 외계어처럼 느껴질 수 있습니다.

레트로 컴퓨팅이라는 문화

이런 프로젝트가 비단 취미만은 아니에요. 디지털 보존(digital preservation)이라는 분야에서는 옛 하드웨어와 소프트웨어를 살아 있게 유지하는 일이 점점 중요해지고 있어요. 비슷한 흐름으로 FrogFind라는 서비스는 옛날 브라우저에서도 읽을 수 있게 검색 결과를 단순 HTML로 변환해주고, Dillo 같은 미니멀 브라우저도 저사양 시스템을 위해 꾸준히 개발되고 있습니다.

또 다른 맥락은 임베디드 환경이에요. 산업용 기계나 의료 장비 중에는 아직도 Windows 95나 Mac OS 9 시절의 시스템 위에서 돌아가는 게 꽤 있어요. 이런 시스템을 안전하게 인터넷과 연결하려고 할 때 Macsurf 같은 접근법이 실용적으로 쓰일 수 있습니다. 비싼 신형 시스템으로 교체하는 대신, 프록시 한 단을 두면 옛 시스템을 계속 살려 쓸 수 있으니까요.

한국 개발자에게 던지는 시사점

당장 업무에 쓸 일은 없겠지만, 추상화 레이어를 이해하는 데 큰 도움이 됩니다. 우리가 매일 쓰는 fetch 함수 한 줄 뒤에 TLS, TCP, HTTP, HTML 파싱, JavaScript 엔진까지 얼마나 많은 계층이 쌓여 있는지 새삼 느끼게 되거든요. 이런 추상화가 무너지면 어떻게 보완해야 하는지를 보여주는 좋은 사례예요.

레거시 시스템을 유지보수해본 분이라면 더 와닿을 거예요. 금융권이나 공공기관에는 아직 IE11, 심지어 IE9에서만 동작하는 시스템이 남아 있고, 이걸 현대 보안 표준에 맞추는 일은 늘 골치 아픈 숙제잖아요. Macsurf의 프록시 방식은 그런 상황에서 참고할 만한 패턴을 보여줍니다. "클라이언트는 그대로 두고 중간에 변환 계층을 둔다"는 발상은 의외로 실무에서도 쓸 데가 많거든요.

마무리

오래된 기계를 다시 살리는 건 그 자체로 멋진 일이지만, 한편으로는 "지금 우리가 만든 시스템도 25년 뒤에 누군가가 살리려고 애쓰지 않을까?"라는 질문도 던지게 합니다. 여러분이 지금 다루고 있는 시스템 중에 25년 뒤에도 누가 쓰고 있을 만한 코드가 있을까요? 그리고 그때를 위해 지금 어떤 결정을 더 신중하게 내려야 할까요?