요약
68k 맥의 System 6에서 MacTCP 자리에 그대로 끼워 쓰는 새 TCP/IP 스택 MoofTCP가 나왔습니다.
램 4MB짜리 Mac Classic에 BlueSCSI 같은 SCSI 와이파이 어댑터를 달면 MacTCP가 느리고 메모리를 많이 먹는다는 불만에서 출발한 취미 프로젝트입니다. 작성자는 README에서 Claude Code로 개발했고 계획과 테스트는 사람이 맡았다고 밝혔습니다.
왜 중요한가
- MacTCP용 프로그램을 고치지 않고 돌릴 수 있습니다. 30년 넘게 지원이 끊긴 스택(네트워크 통신을 맡는 소프트웨어 계층)에 기대지 않아도 됩니다.
- DHCP(주소를 자동으로 받아 오는 방식)와 설치 프로그램이 들어 있어 옛 맥을 인터넷에 연결하기가 쉬워집니다.
- AI 코딩 에이전트로 레트로 컴퓨터의 네트워크 스택을 처음부터 만든 사례라서 토론도 그 지점에 몰렸습니다.
핵심 내용
- MacTCP의 .IPP 드라이버 인터페이스(TCP, UDP, ICMP 에코)와 dnrp 이름 해석기를 그대로 구현했습니다.
- 스택 본체는 이식성 있는 C로 새로 짰고, malloc과 전역 상태를 쓰지 않습니다.
- 우선순위는 안정성, 텔넷 같은 대화형 작업의 응답 속도, 처리량 순입니다.
- 상주 메모리는 MacTCP보다 많지 않게 잡았고, DHCP를 뺀 Lite 판은 약 5KB를 더 아낍니다.
- System 6.0.8과 DaynaPORT 드라이버에서만 시험했고 IPv6는 지원하지 않습니다.
HN 반응
- 원본과 비교한 수치가 없다는 지적에 작성자가 키 입력 응답 지연 중앙값 2.8ms 대 4.5ms 같은 측정값을 내놨지만, 개선 폭이 작다는 반응도 나왔습니다.
- AI로 만든 프로젝트를 두고 코딩을 문제 해결로 보느냐 기예로 보느냐의 논쟁이 이어졌고, 작성자는 프롬프트 한 번으로 끝난 작업이 아니라고 답했습니다.
저도 구형 맥을 좋아하는 사람으로서 이런 프로젝트를 보면 정말 반갑습니다. 클래식 맥 커뮤니티가 활발하게 살아 있고, 오래된 기계를 위한 새 소프트웨어가 나온다니 멋진 일입니다!
활기찬 건 AI 에이전트 커뮤니티겠죠, 아마.
사람들의 커뮤니티도 아직 살아 있어요! 저는 하드 디스크 이미지를 여러 개 갖고 있고, 시스템 6.0.7이나 7.1을 수시로 띄워서 THINK C로 이것저것 만져 보거든요.
minivmac을 몇 군데 간단히 고쳐서, 툴박스 호출로 호스트 머신에 접근할 수 있게 해 뒀어요.
jcs@openbsd가 코딩을 엄청 많이 하던데요...
AI가 아무리 발전했다 해도, 사람이 전혀 개입하지 않았는데 Claude가 스스로 68k 맥용 TCP 스택을 만들기로 했을 것 같지는 않습니다.
os8088을 보시면 놀라실 걸요.
그렇진 않겠죠. 하지만 사람마다 코딩하는 이유가 다르고, 어느 쪽이 더 '틀렸다'고 할 수도 없습니다.
어떤 사람들(대체로 AI를 좋아하는 쪽)은 코딩을 그저 문제를 해결하는 일로 보고, 그 일이 어떻게 이뤄지는지에는 별로 관심이 없습니다.
다른 사람들은 코드를 하나의 예술이자, 그 자체로 음미할 만한 여정으로 봅니다. 이들에게는 자기 지식과 경험으로 아무나 풀 수 없는 문제를 풀고 있다는 사실을 아는 것도 재미의 일부입니다. 그게 가치와 성취감을 주기 때문에 우리는 이 일을 좋아합니다.
저한테는 실제 예술이나 그림과 비슷합니다. 물론 예술가들이 AI에 화를 내는 건, 자기 업계가 자신을 뒤로 밀어내고 쓸모없거나 덜 특별한 존재로 느끼게 만드는 게 싫어서겠죠.
하지만 저와 생각이 다른 사람들을 탓하지는 않습니다... 그저 바라보는 방식이 다를 뿐입니다.
작성자입니다. 맥 자체를 복원하는 데 들어간 노력과 비용은 제쳐 두더라도, 이게 프롬프트 한 번으로 끝난 프로젝트가 아니라는 건 장담할 수 있습니다. 범위가 불어나지 않으면서 쓰기 편한 물건을 만들려면 어느 정도 계획과 방향 조율이 필요했습니다. 비결정성 때문에(혹은 그 덕분에) 프롬프트로 하는 엔지니어링에도 여전히 기술과 요령이 있습니다. C 같은 언어가 기계어를 배우고 메모리 힙을 일일이 관리하지 않고도 창의성을 발휘하게 해 준 지름길이었듯이, LLM 도구는 우리가 창의성을 구현할 수 있는 폭을 더 넓혀 줍니다.
제가 들어 본 가장 좋은 설명은 LLM이 '정신을 위한 안경'과 같다는 것입니다. 저처럼 클래식 맥용 C, retro68k 개발 환경, TCP/IP가 저수준에서 대체 어떻게 돌아가는지 같은 걸 배울 시간이 없는 사람에게 공평한 출발선을 만들어 줍니다. 직장에서도 마찬가지로, 예전에는 손댈 수 없던 코드베이스 영역에 기여할 수 있게 됐고, 제 전문 분야에 의존하던 동료들도 반대로 자기 영역 밖의 일을 할 수 있게 됐습니다.
예전에는 제가 조금 독특하거나 희소한 재능을 가졌다는 데 분명 자부심이 있었지만, 새로운 세상에서 그걸 두고 문지기 노릇을 할 필요는 느끼지 않습니다(당신이 그렇다는 말은 아닙니다). 이제는 훨씬 빠른 속도로 훨씬 많은 가치를 낼 수 있으니까요. 이런 개인 프로젝트도 마찬가지여서, 소중한 자유 시간과 가족과의 시간을 크게 잃지 않고도 마침내 이런 프로젝트를 해내고 결과를 볼 수 있게 됐습니다.
그게 뭐였는지 여쭤봐도 될까요?
전적으로 동의해요. 저는 사람이 읽을 수 있는 언어를 쓰기 시작한 순간 프로그래밍의 예술이 사라졌다고 생각하거든요.
어떤 사람들은 코딩을 그저 문제를 해결하는 일로 보고, CPU가 실제로 그걸 어떻게 해내는지에는 관심이 없어요. 또 어떤 사람들은 기계어 명령을 공들여 하나하나 배열하고, 레지스터와 클록 사이클을 속속들이 이해하고, 아무나 풀 수 없는 문제를 풀고 있다는 걸 아는 장인 정신을 높이 사요.
우리에게는 거기서 가치와 성취감이 나오죠. 고급 언어를 써서 컴파일러가 흥미로운 일을 다 하게 만드는 건 핵심을 한참 놓치는 일이에요.
그래도 Python이나 C++, 심지어 어셈블리를 쓰는 사람들까지 탓하진 않아요. 그냥 바라보는 방식이 다를 뿐이니까요.
Flynn을 만든 사람입니다(정확히는 Claude가 만들었지만요). MoofTCP를 Flynn으로 테스트해 주셨다니 정말 멋지네요.
공교롭게도 몇 주 전에 제 512Ke가 온라인에 못 들어가는 게 짜증 나서 Claude에게 talkip[1]을 만들게 했는데, 재미있었고 놀랄 만큼 잘 돌아갑니다.
Flynn 다시 한번 고마워요! 이제 거의 매일 쓰고 있고, 제 에이전트들이 68k 개발 패턴을 익히는 데도 영감이 돼 줬어요. talkIP 스택도 꼭 살펴봐야겠네요. 제 Claude가 그걸 통째로 베끼지 않았길 바라요.
4MB짜리 클래식을 온라인에 붙이는 것도 이렇게 어려운데, 512ke는 얼마나 골치 아플지 상상도 안 가네요.
90년대 중반에 MacTCP를 다뤘던 기억이 납니다. 좀 까다롭고 툭하면 먹통이 됐죠.
더 새로운 파워 맥에서는 Open Transport라는 새 구조로 대체됐습니다. 훨씬 잘 돌아가서 정말 한시름 놓았습니다.
프로젝트가 정말 마음에 들어요!
JCS가 BlueSCSI용 데스크 액세서리로 만든 와이파이 네트워크 선택기를 넣는 것도 고려해 보시겠어요? BlueSCSI가 이 오래된 맥들을 네트워크에 연결하는 아주 인기 있는 방법이 될 테니까요. 그러면 많은 구형 맥이 온라인에 접속하는 깔끔하고 간단한 원스톱 해법이 되지 않을까요?
자세한 내용은 https://jcs.org/bluescsi 를 보세요.
Claude가 자체 스택을 만들었다니 흥미롭네요. 저도 예전에 몇몇 프로젝트에서 tinytcp를 썼던 기억이 나요.
이 스택이 얼마나 '올바른지' 궁금하네요. ARP까지 구현했다는 것도 흥미롭고요. ARP가 실제 환경에서 아직 지원되는지는 저는 통 모르겠더라고요!
Claude가 블루투스 스택을 밑바닥부터 만드는 것도 보고 싶어요. 브로드컴과 퀄컴의 스택이 얼마나 엉망이라고들 하는지 생각하면요.
지구상에서 저만 이렇게 느낄 수도 있지만, 슬라이더로 넷마스크를 설정하던 게 그리워요.
https://tidbits.com/resources/iskm3html/pt4/ch17/ch17.html#aa8
(네트, 서브넷, 노드 항목이 따로 나뉘어 있던 건 별로 그립지 않지만요)
빈티지 컴퓨터 화면에 뜬 글에서 LLM 특유의 말투를 보고 있자니 기분이 묘하네요.
참고로 'moof'의 유래와 그게 옛 맥들과 어떻게 관련되는지는 여기 있습니다. https://en.wikipedia.org/wiki/Dogcow
원본과 직접 비교한 수치가 하나도 없다니 너무 아쉽네요.
(작성자입니다. 여기서는 부계정으로 올립니다)
비교하는 게 꽤 번거롭습니다. 진단 도구를 돌리고, 스크린샷을 찍고, 최신 기계에 감시 도구를 설정하고, 클래식 맥 하드웨어에서 비교를 돌린 다음, 그 결과를 맥에서 최신 기계로 다시 옮겨야 합니다(아직 맥용 네트워크 공유 환경을 구성하지 않아서, 전송할 때마다 전원을 끄고 SD 카드로 옮깁니다). 그걸 다시 에이전트에 넣어 검증과 피드백을 받고, 반복할 때마다 이 과정을 되풀이합니다.
이런 과정을 몇 차례(릴리스 후보 4개쯤) 거친 뒤에, 지금 상태면 충분하다고 판단하고 공개했습니다. Claude는 QA/검증 단계에서 가끔 '모기 할례 시키기' 식으로 사소한 데 지나치게 매달리는 경향이 있더군요.
제가 실제로 옮겨 온 테스트 로그 데이터로 측정할 수 있었던 건 다음과 같습니다.
| 측정 항목 | MoofTCP | MacTCP 2.1 |
|---|---|---|
| 에코된 키 입력의 ACK(중앙값) | 2.8 ms | 4.5 ms |
| 에코된 키 입력의 ACK(최악의 경우) | 16.8 ms | 17.6 ms |
| 대화형 데이터에서 지연 ACK 정체 | 없음 | 없음 |
| Wikipedia Reader, 링크 따라가기 | 51.7 s | 53.2 s |
| TAP으로 10 MiB 가져오기 | 약 47–49 KB/s | 약 49 KB/s |
| 광고된 TCP 윈도 | 8,192 | 4,220 |
| 실제 맥에서의 전송 정체 및 재전송 | 0 | 측정하지 않음 |
이렇게 눈에 띄게 개선할 수 있었던 이유가 뭔지 감이 오시나요? 원본의 근본적인 설계 오류였을 수도 있고, 쓸 수 있었던 더 현대적인 알고리즘 덕일 수도 있고, 거의 안 쓰이거나 전혀 안 쓰이는 기능을 건너뛸 곳(또는 핫 패스에서 뺄 곳)을 알았기 때문일 수도 있겠죠.
우리 가족의 맥은 제가 처음으로 사랑한 기계였습니다. 안타깝게도 모뎀조차 연결해 본 적이 없어서 MacTCP를 직접 써 본 경험은 없습니다.
저는 TCP/IP 프로토콜 전문가라고 할 수 없어서 에이전트에게 방법론을 물어봤습니다. 더 똑똑한 ACK 처리, 더 큰 TCP 윈도와 세그먼트, 더 나은 재전송 방식, 어셈블리 체크섬 루틴, malloc을 버리고 고정 메모리 공간을 쓴 것 등이 성능 향상으로 이어진 엔지니어링 결정이었다고 하더군요.
메모리 절감 지표와 오차 막대 없이는 미미한 개선일 뿐입니다. 뭔가를 만든 건 박수 칠 일이지만 저는 와닿지 않네요. 저도 68k 맥이 없어서, 이게 왜 대단한 일인지 못 느끼는 걸 수도 있고요.
미미한 개선이라고 해서 가질 만한 가치가 없는 건 아니잖아요?
작성자로서 말씀드리면, 주관적으로 더 나아진 느낌 말고도 DHCP 지원과 꽤 쉬운 설치도 MacTCP보다 좋은 점입니다. 그리고 30년 넘게 지원이 끊긴 물건에 의존하지 않아도 되고요.
네, 저는 개인적으로 딱히 나아진 게 없더라도 새 구현이 나오면 기쁠 거예요. 활발히 개발되는 버전이 있다는 것 자체에 가치가 있다고 생각하거든요.
뭐, 그렇긴 한데 README를 보면 하늘과 땅 차이일 것처럼 써 놨잖아요. 원본을 엄청 깎아내리고요.
? 제가 본 언급은 이게 전부인데요.
그러니까... 저는 Mac Classic이 없어서 사실이 맞는지는 말할 수 없지만, 깎아내리는 말로는 안 들리는데요.
제가 깎아내려 드리죠. MacTCP는 끔찍해요. 시스템 7.5.x와 함께 나온 Open Transport 초기 몇 버전은 어째서인지 그보다 더 심했고요. 그리고 MacPPP는 정말 가증스러운 물건이었죠.
저는 옛날 맥이 만병통치약이 아니었다는 걸 사람들에게 상기시키고 알려 주려고, Hunter Cressall이 Switchers 광고 캠페인을 패러디한 영상을 보여 주곤 해요. 정말 웃기고 딱 들어맞거든요. https://www.youtube.com/watch?v=rEvYETWVK6M
출처: 저는 그 시절(1995년쯤?) 어떤 ISP에서 어쩌다 보니 '또 다른 맥 담당자'가 됐거든요.
40년 된 희귀 하드웨어를 위한 틈새 취미 프로젝트가 '대단한 일'이길 기대하는 사람은 아무도 없을 거예요. 선생님도 재미있고 부담 없는 일을 하고 계시길 바랍니다!