무슨 일이 있었나요?
FeralFirmware라는 GitHub 계정에서 TailTalk이라는 프로젝트를 공개했어요. 한 줄로 설명하면 'AppleTalk 프로토콜 스택을 Rust와 Tokio로, 커널이 아닌 사용자 공간(user space)에서 비동기로 구현한 것'이에요. 이 문장에 낯선 단어가 세 개쯤 들어 있을 텐데요, 하나씩 풀어볼게요.
먼저 AppleTalk이 뭐냐면, 애플이 1985년에 만든 네트워크 프로토콜 묶음이에요. 지금 우리가 쓰는 TCP/IP가 개인용 컴퓨터에 자리 잡기 훨씬 전에, 맥끼리 파일을 주고받고 레이저 프린터를 공유하려고 만든 거예요. 특이한 점은 설정이 거의 필요 없었다는 거예요. 케이블만 꽂으면 알아서 주소를 받고, 알아서 주변 기기를 찾았어요. IP 주소를 손으로 적고 DNS 서버를 지정하던 시절에 이건 꽤 혁신이었죠. 애플은 2009년 맥OS X 스노 레퍼드에서 AppleTalk 지원을 완전히 뺐고, 그 뒤로는 공식적으로 죽은 프로토콜이 됐어요.
그런데 왜 2026년에 이걸 새로 짜냐고요? 레트로 컴퓨팅 때문이에요. 매킨토시 SE, 클래식, LC 같은 30년 넘은 맥을 수집하고 실제로 쓰는 사람들이 전 세계에 꽤 있는데요, 이 기계들은 TCP/IP를 모르거나 아주 서툴러요. 이 기계들과 파일을 주고받으려면 결국 현대 컴퓨터가 AppleTalk을 '말할 줄' 알아야 하는 거예요.
기존 방식은 뭐가 문제였나요?
지금까지는 리눅스 커널에 들어 있는 AppleTalk 모듈과 netatalk이라는 파일 서버를 조합해서 썼어요. 그런데 이 조합이 좀 삐걱거려요. 커널 모듈은 1990년대에 짜인 코드가 큰 손질 없이 남아 있는 수준이라 배포판에 따라 아예 빠져 있기도 하고, 간간이 보안 버그가 나와서 '이거 그냥 지워버리자'는 얘기가 나오기도 했어요. netatalk도 3.x 버전에서 AppleTalk 지원을 뺐다가 커뮤니티 요청으로 2024년 4.0에서 다시 넣는 우여곡절을 겪었고요.
TailTalk이 다른 길을 택한 지점이 여기예요. 커널 모듈에 기대지 않고 사용자 공간에서 이더넷 프레임을 직접 받아서 처리해요. 이게 왜 중요하냐면, 첫째로 커널 모듈이 없는 시스템이나 컨테이너 안에서도 돌릴 수 있고, 둘째로 프로그램에 버그가 있어도 커널이 통째로 죽는 게 아니라 그 프로세스만 죽어요. 셋째로 Rust로 짰기 때문에 옛날 C 코드에서 흔했던 메모리 오류 자체가 컴파일 단계에서 걸러져요. 30년 된 프로토콜을 다루는데 도구는 최신이라는 게 재밌는 조합이죠.
Tokio는 Rust의 비동기 런타임이에요. 이게 뭐냐면, 네트워크 프로그램은 대부분 시간을 '패킷이 오기를 기다리는' 데 쓰는데요, 그 기다리는 시간 동안 스레드를 붙잡고 있지 않고 다른 일을 하게 해주는 도구예요. AppleTalk처럼 이름 찾기, 에코, 트랜잭션, 파일 세션이 동시에 오가는 프로토콜에서는 이 구조가 잘 맞아요.
AppleTalk은 어떻게 생겼나요?
AppleTalk도 TCP/IP처럼 층층이 쌓인 구조예요. 익숙한 개념에 빗대면 이렇게 돼요.
- DDP(Datagram Delivery Protocol): IP에 해당해요. 주소를 붙여서 패킷을 배달하는 가장 기본 층이에요.
- NBP(Name Binding Protocol): DNS 역할인데 방식이 달라요. 중앙 서버 없이 '여기 프린터 있는 사람?' 하고 네트워크에 외치면 해당 기기가 대답하는 식이에요.
- ZIP(Zone Information Protocol): 큰 네트워크를 '영업부', '디자인팀' 같은 존으로 나눠 관리하는 층이에요.
- AEP(AppleTalk Echo Protocol): ping이에요.
- ATP(AppleTalk Transaction Protocol): 요청과 응답을 묶어서 신뢰성 있게 주고받는 층으로, TCP보다는 가벼운 RPC에 가까워요.
- ASP/AFP: 그 위에서 실제로 파일 공유가 이루어지는 층이에요.
업계 맥락에서 보면요
이 프로젝트는 혼자 튀어나온 게 아니에요. 최근 몇 년간 레트로 맥 커뮤니티에서는 마이크로컨트롤러로 LocalTalk 브릿지를 만드는 TashTalk, 무선으로 옛 맥을 연결하는 AirTalk, 에뮬레이터용 LToUDP 같은 프로젝트가 계속 나왔어요. netatalk 4.0의 부활도 그 흐름의 일부고요. 그리고 다른 한편에서는 '오래된 네트워크 코드를 Rust로 다시 쓰는' 흐름이 있어요. 임베디드용 TCP/IP 스택인 smoltcp가 대표적이죠. TailTalk은 이 두 흐름이 만나는 지점에 있어요.
한국 개발자에게는 어떤 의미일까요?
솔직히 AppleTalk을 실무에서 쓸 분은 거의 없을 거예요. 그런데 이 프로젝트는 교재로서 가치가 있어요. 프로토콜 스택을 처음부터 끝까지 사용자 공간에서 짜는 구조, raw 소켓으로 이더넷 프레임을 직접 다루는 방법, Tokio로 여러 프로토콜 세션을 동시에 굴리는 패턴을 실제 동작하는 코드로 볼 수 있거든요. 네트워크 프로그래밍을 책으로만 배웠다면 이런 규모의 프로젝트를 읽는 게 훨씬 빨리 늘어요.
그리고 의외로 현실적인 쓸모도 있어요. 공장 장비, 병원 기기, 방송 장비 중에는 아직도 옛 프로토콜로만 통신하는 것들이 있는데요, 그런 장비를 현대 시스템에 붙이는 일은 생각보다 자주 생겨요. '죽은 프로토콜을 안전한 언어로 다시 구현한다'는 접근은 그런 상황에서 그대로 응용할 수 있는 방법론이에요.
정리하면
TailTalk은 40년 전 프로토콜을 가장 현대적인 도구로 다시 만든 프로젝트예요. 레트로 취미이면서 동시에 Rust 비동기 네트워크 프로그래밍의 좋은 실전 예제이기도 하고요.
여러분은 '굳이 왜?' 싶은 기술을 새로 구현해본 경험이 있으세요? 그런 프로젝트에서 뭘 배웠는지 이야기해주시면 재밌을 것 같아요.
🔗 출처: Hacker News