프로젝트 재너두는 왜 실패했나: 50년 하이퍼텍스트 꿈의 교훈

2024년 12월 샌프란시스코에서 테드 넬슨의 1974년 저작 『Computer Lib/Dream Machines』 발간 50주년을 기념하는 작은 파티가 열렸다. 하이퍼텍스트에 강한 의견을 가진 사람들이 모인 이 자리에는 넬슨이 구상한 하이퍼미디어 시스템 '프로젝트 재너두(Project Xanadu)'의 여러 구현판을 돌리는 빈티지 컴퓨터들이 놓였다. 87세의 넬슨 본인은 참석하지 못했지만, 오토데스크 시절(약 1988~1993년) 재너두 개발에 참여했던 프로그래머가 당시의 이야기를 들려주었다. 이 회고는 오래전 소프트웨어 프로젝트의 실패를 오늘의 기준으로 함부로 재단하기 전에, 그 시절의 제약을 먼저 이해해야 한다는 점을 일깨운다.

낭만화된 과거, 혹독했던 제약

웹의 원형으로 종종 거론되는 재너두는 여러 명의 풀타임 인력이 수년을 투입하고도 내놓을 결과물이 거의 없었다. 하지만 당시 하드웨어 제약을 떠올리면 사정이 달라진다. 개발팀은 재너두를 스몰토크(Smalltalk)로 프로토타이핑했다. 객체지향 모델이 하이퍼미디어와 잘 맞아떨어지는 생산적인 언어였기 때문이다. 문제는 이를 C++로 크로스 컴파일한 뒤 다시 컴파일하는 과정이었는데, 그 컴파일에만 약 일주일이 걸렸다. 몇 분도, 몇 시간도, 하루도 아닌 일주일이다. 여기에 C++ 특유의 온갖 컴파일 이슈를 처리하는 데 상당한 시간이 낭비됐다.

저장 공간의 제약은 CPU보다 더 심각했다. 1990년 중급 PC의 하드디스크는 50MB 남짓이었는데, 오늘날 한 사람이 호스팅하는 문서 상당수는 그 전체 용량을 단일 파일로 넘어선다. 1MB 미만 RAM에 맞춰 맞춤법 검사기를 욱여넣기 위해 수개월간 알고리즘을 최적화했던 사례(McIlroy, 1982)는, 지금이라면 자바스크립트 몇 줄로, 그것도 대규모 언어모델이 대신 짜줄 일이다. 이런 배경을 알면 재너두의 더딘 진척이 팀의 무능 탓만은 아니었음을 이해하게 된다.

공개됐지만 쓸모없던 소스코드

재너두의 C++ 코드베이스는 1999년 8월 유사 오픈소스 형태로 공개됐다. 하지만 그것은 스몰토크-투-C++ 컴파일러가 기계적으로 생성한 결과물이라 사실상 읽을 수도, 재사용할 수도 없었다. 초기 하이퍼텍스트 시스템에 정통했던 돈 홉킨스는 이 코드를 두고 "주석 없는 접착 코드가 접착 코드를 접착하고 있을 뿐, 재사용할 만한 것이 없다"며 오픈소스의 취지를 완전히 놓쳤다고 혹평했다. 넬슨 스스로 50년째 "나는 프로그래머가 아니다"라고 말하는 태도, 그리고 '편집 결정 목록(edit decision list)' 같은 영화 편집 은유를 즐겨 쓰는 감독 지향적 개발 방식이 이런 결과와 무관하지 않다.

문제를 찾아 헤맨 해법

그러나 이 글의 저자가 재너두 데모 화면 — 창세기 첫 구절에서 각 문장으로부터 주석과 트랜스클루전을 나타내는 선들이 오른쪽으로 지그재그로 뻗어나가는 그 유명한 장면 — 을 실제로 마주하고 얻은 깨달음은 더 근본적이다. 화면은 "완전히 읽을 수 없었다." 교차하는 선들은 어수선한 잡동사니였고, 작은 화면 탓에 어떤 주석도 제대로 읽히지 않았으며, 스크롤을 해도 선에 가려 아무것도 못 읽는 위치가 수두룩했다. UI가 형편없었다는 말로는 부족하다. 4K 대형 모니터에서조차 그런 방식을 원하지 않을 것이다.

하지만 진짜 문제는 UI도, 팀도 아니었다. 저자의 결론은 나란히 놓인 범위 지정 트랜스클루전이라는 개념 자체가 '문제를 찾아 헤맨 해법'이었다는 것이다. 창세기처럼 모든 줄에 상세한 주석과 본문 비평이 쌓인 텍스트에는 이 방식이 의미가 있다. 넬슨이 제시한 '병렬 문서' 예시들 역시 성경, 『햄릿』, 「라쇼몽」 같은 본문 비평이 대부분이고, 나머지는 성인 목록이나 조직 내 통화 기록, 코미디 TV 에피소드처럼 억지스러운 사례였다. 세상의 텍스트 중 특정 줄이나 문단을 조목조목 트랜스클루드해야 하는 경우는 극히 드물다. 대부분의 실제 인용은 대상 문서 '전체'를 가리키며, 설령 세부 인용을 모아둔들 99%는 보고 싶지도 않고 나머지 1%를 어떻게 정렬할지조차 합의하기 어렵다. 온라인 댓글을 날짜순, 인기순, 길이순 중 무엇으로 정렬할지 아무도 확답하지 못하는 것과 같은 이치다.

실무자를 위한 시사점

흥미롭게도 넬슨이 꿈꾸던 기능 자체는 이미 구현 가능하다. 사이드노트, 범위 트랜스클루전, 양방향 백링크는 Gwern.net 같은 사이트에서 며칠이면 만들 수 있고 실제로 특정 문학 분석 글에 쓰이기도 한다. 다만 '할 수 있지만 대부분 하지 않는' 이유는 정말로 그것을 필요로 하는 사람이 거의 없기 때문이다. 넬슨이 바이트 범위 지정에 집착한 것도 필름 릴에서 프레임을 잘라 붙이던 은유에서 비롯됐는데, 이는 의미론을 무시한다. 실무에서 우리가 참조하고 싶은 것은 'HTML 파일의 123~456 바이트'가 아니라 '의미 있는 특정 요소'이며, 그 요소의 바이트 위치는 편집에 따라 계속 바뀐다.

저자는 재너두가 카리스마 있는 지도자가 결코 생각을 바꾸지 않고, 오픈소스를 꺼리며, 데이터베이스·AI와 얽힌 채 '바다를 끓이려는' 장기 프로젝트라는 점에서 더그 레냇의 Cyc와 닮았다고 지적한다. 두 프로젝트 모두 '병리적 과학'의 징후를 보였다는 것이다. 실무자에게 남는 교훈은 명확하다. 기술적으로 정교하고 지적으로 매력적인 비전이라도, 반복적 디자인 개선과 실제 사용 사례, 그리고 실용성이라는 검증을 거치지 못하면 성숙한 도구로 자라나지 못한다. 화면 어디에 있든 유용한 텍스트가 보이는 좋은 '데이터-잉크 비율'처럼, 사용자가 매 순간 무언가를 읽을 수 있는지가 결국 문서 UI의 성패를 가른다.