웹 개발을 깊이 파고들수록 지금의 인터넷이 누구의 어깨 위에 서 있는지를 실감하게 된다. 캐나다 캘거리에서 활동하는 한 블로거는 최근 SDF의 ARPA 회원이 되었다며, 1987년부터 지금까지 끊이지 않고 운영돼 온 이 비영리 공공 접속 유닉스 시스템에 대한 애정을 글로 남겼다. SDF가 무엇인지 이해하려면 현대 인터넷 이전, BBS(전자게시판) 시대로 거슬러 올라가야 한다.
전화선 한 가닥에서 시작된 커뮤니티
1987년 6월 16일, 테드 울레만(아이디 'iczer')은 생일 선물로 받은 전화선에 애플 IIe의 300보드 모뎀을 연결하고 애플소프트 BASIC으로 작성한 BBS를 띄웠다. 그는 자신이 좋아하던 애니메이션 '초시공요새 마크로스'(서구에서는 로보텍의 일부로 알려짐)의 이름을 따 시스템을 SDF-1이라 불렀고, 애니메이션과 인더스트리얼 음악, 그리고 서브지니어스 교회 팬들을 끌어모으려 했다. 시작은 1200bps 모뎀 한 대와 각각 280킬로바이트짜리 플로피 드라이브 두 개가 전부였다.
검색 엔진이 없던 시절, 접속할 BBS를 찾으려면 컴퓨터 잡지나 다른 게시판의 텍스트 파일을 뒤져야 했다. '사이트 주소'란 지역 전화번호 일곱 자리였고, 터미널 프로그램에서 명령을 입력해 모뎀이 그 번호로 전화를 걸게 했다. 집 전화선을 쓰는 방식이었으니 접속 중에는 가족 누구도 전화를 쓸 수 없었다. 두 모뎀이 주고받는 그 거친 기계음을 직접 들어가며 연결을 기다리던 경험은, 개인용 컴퓨터가 값비싼 장난감에서 사람과 사람을 잇는 필수 관문으로 바뀌는 과정 그 자체였다. 북미 BBS는 전성기에 15만 개가 넘었지만 2005년에는 수백 개만 남았다.
상업화하지 않고 살아남은 40년
현재 SDF는 회원들의 후원만으로 운영되는 501(c)(7) 비영리 단체로, 수만 명이 계정을 보유한 다중 사용자 NetBSD 시스템이다. 2006년 bsdtalk 인터뷰에서 한 오랜 회원은 "SDF는 셸 계정 이상이며, 초기 인터넷처럼 전혀 기업적이지 않은 방식으로 운영되는 컴퓨팅 환경"이라고 설명했다. SDF 자체에 올라온 2019년 공공 접속 유닉스 시스템 연구는 이곳을 "완전히 짜인 사회적 공동체"로 묘사하며, 아마추어 무선(SDFARC), 파이썬, 고퍼, 마인크래프트 등 다양한 관심사 그룹이 공존한다고 전한다. 네트워크에는 DEC 알파와 AMD 옵테론 기반 NetBSD 서버뿐 아니라 TOPS-20, 심볼릭스 제네라, ITS 같은 레트로컴퓨팅 환경도 살아 있으며 이들 모두 무료 계정을 제공한다. SDF는 하드웨어 고장과 수많은 DDoS, 자사 ISP의 서비스 종료, 미국 내 여러 차례의 이전을 겪으면서도 한 번도 상업화하지 않았고 사용자 기반을 잃지 않았다.
회원이 되면 셸 접속부터 시작한다. ssh로 접속하면 NetBSD 환경에서 bash·zsh 등 여러 셸과 ed부터 emacs까지의 편집기, ping·dig·finger 같은 도구를 쓸 수 있다. mkhomepg 명령으로 ~/html 폴더를 만들면 you.sdf.org 주소로 사이트가 즉시 공개되고, ARPA 회원은 pdp10.org, twenex.org 등 약 60개 중에서 베니티 도메인을 고를 수 있다. 고퍼와 제미니 프로토콜도 mkgopher 한 번으로 하나의 디렉터리를 두 프로토콜로 동시에 서비스한다. 과거에는 스팸 방지를 위해 1달러 지폐를 시애틀 사서함으로 우편 발송해야 가입이 승인됐지만, 지금은 페이팔 후원으로 간단해졌다. 36달러 한 번이면 평생 ARPA 회원 자격이 주어진다.
CGI 방명록, 그리고 '작아진' 웹
저자는 ARPA 회원에게 열리는 Perl CGI로 간단한 방명록을 직접 만든 과정도 공개했다. CGI는 1990년대 말에서 2000년대 초 정적 HTML을 동적 웹으로 바꾼 핵심 기술이지만, 방문자 클릭마다 새 프로세스를 띄우는 구조 탓에 트래픽이 몰리면 메모리를 대량 소모해 지금은 사실상 폐기된 방식으로 취급된다. 그러나 개인 홈페이지라면 '확장성'이나 '자원 효율' 같은 고민은 접어둬도 된다는 게 저자의 생각이다. 그는 데이터 파일을 웹 루트 바깥 한 단계 위에 두고, suexec 환경에서는 $ENV{HOME}이 설정되지 않는 점을 고려해 절대 경로를 하드코딩했다. 핵심 Perl과 Fcntl 파일 잠금만으로 폼을 직접 파싱하고, 거의 쓰이지 않는 \x01 제어 문자를 필드 구분자로 삼았으며, CSS로 숨긴 허니팟 필드로 봇 제출을 걸러낸다. 데이터베이스도 프레임워크도 빌드도 없는, 저자의 표현대로 "2026년 기준으로 조금 조악하지만 사랑스러운" 결과물이다.
이 글의 또 다른 축은 자바스크립트를 전혀 지원하지 않는 초경량 브라우저 Dillo다. Dillo의 코드베이스는 크로미움의 약 0.2% 크기에 불과하고 메모리 사용량이 극히 낮은 대신, 상당수 웹 페이지가 제대로 렌더링되지 않는다. 저자는 이 한계를 오히려 장점으로 본다. 와 인라인 이벤트 핸들러는 버려지고 iframe·canvas·video는 렌더링되지 않으며, CSS 변수(var())·플렉스박스·그리드도 지원되지 않아 레이아웃은 테이블과 float으로 짜야 한다. @font-face 웹폰트 대신 serif·sans-serif 등 다섯 가지 기본 글꼴 계열만 쓰인다. 다만 저자는 공식 호환성 표를 찾지 못했다며, 이 목록을 참고 수준으로 받아들일 것을 당부한다.
한국 실무자에게 SDF와 Dillo의 이야기가 곧장 생산 환경의 선택지가 되긴 어렵다. 평생 회원이라 해도 특정 비영리 시스템에 개인 데이터를 묶어 두는 일에는 지속성·백업·거버넌스 측면의 고려가 따르고, 자바스크립트를 배제한 사이트는 오늘날 대다수 서비스가 기대하는 상호작용성을 포기해야 한다. 그럼에도 이 사례가 던지는 질문은 가볍지 않다. 프로세스마다 메모리를 통째로 쓰는 CGI와 프레임워크 없이 짠 수백 줄짜리 방명록은 역설적으로 코드가 무엇을 하는지 투명하게 드러낸다. 좋은 코드는 군더더기 없는 코드이며, 인터페이스는 없음에 가까울수록 낫다는 저자의 믿음은, 끝없이 무거워지는 웹 스택을 다루는 이들이 한 번쯤 되짚어 볼 만한 반론이다.