HyperCard가 매킨토시에서 어떤 의미를 가졌는지, 그 역사와 도구성, HyperTalk, 현대의 노코드·바이브 코딩과의 비교를 통해 살펴보는 회고이자 평가.
Throughout the Computer Chronicles's 19 years on-air, various operating systems had full episodes devoted to them, like Macintosh System 7, UNIX, and Windows 95. Only one piece of consumer software had an entire episode devoted to it. You can see and hear Stewart Chiefet's genuine excitement watching Bill Atkinson show it off.
Chiefet, Bill Atkinson의 _HyperCard_ 시연을 몹시 즐기고 있다.
나중에 Chiefet는 이것으로 두 번째 전체 에피소드까지 만들었다. _HyperCard_는 “대단한 일”이었다.
크고 새로운 것들은 무섭다. Compute Magazine 1988년 4월호에 실린 통렬하고, 편집증적이며, 의도치 않게 예언적이기까지 한 글에서 저자 Sheldon Leemon은 _HyperCard_에 대해 이렇게 썼다. “하지만 이 (하이퍼텍스트) 흐름이 계속된다면, 우리는 곧 상호작용하는 가전제품 같은 것도 보게 될지 모른다. 기분이나 전날 밤 잠을 얼마나 잘 잤는지에 따라 빵 굽기 정도를 고르는 토스터를 상상해 보라. _HyperCard_와 hypertext는 둘 다 hype라는 단어로 시작한다는 사실을 모두 기억해야 한다. 그리고 hype에 관한 한, 내 조언은 ‘그냥 거절하라’이다.”
뭐, Leemonade를 만들려면 Leemon 몇 개는 짜야 하는 법이고, 이 Leemon도 마땅히 짜였다.
“정말로 우리는 이미 산만한 요소가 충분히 많은 어린 학생들에게 하이퍼텍스트까지 줘야 할까? 우리는 그 아이가 중국인이 화약을 발명한 부분을 클릭했다가 결국 지하실에서 불꽃놀이를 만드는 방법에 대한 화학 수업으로 가버리길 원하지 않는다.” (의무적인 아이러니 링크)
분명히 Leemon 지지자들은 소수파였다. Steve Wozniak는 Atkinson의 걸작을 “지금까지 쓰인 최고의 프로그램”이라고 불렀다.David Dunham도 그렇게 말했다. 그것만을 위한 잡지 전체가 존재했다. Douglas Adams는 이렇게 말했다. “(_HyperCard_는) 내 작업 생활을 완전히 바꾸어 놓았다.” 그것이 세상에 남긴 영향은 오늘날에도 여전히 느껴진다.
Cyan은 HyperCard 스택 개발자로 시작했고 지금도 게임을 만든다.
Wikipedia는 _HyperCard_에서의 초기 실험들에서 태어났다.
초기의 웹은 _HyperCard_의 (HyperTalk) 비전에 강한 영향을 받았다.
Cory Doctorow의 첫 프로그래밍 직업은 _HyperCard_였다.
Bret Victor는 “HyperCard in the World”를 만들었고, 그것은 Dynamicland로 발전했다.
위와 같은 혈통을 보면 _HyperCard_가 훌륭하다는 말은 전혀 스포일러가 아니다. 하지만 나는 향수의 안경을 벗고 공정하게 평가해야 한다. 그것의 흥망 이후 기술적으로도 문화적으로도 많은 일이 일어났다. 바이브 코딩된 TypeScript 세계에서도 _HyperCard_는 여전히 통할까?
Mini vMac v36.04 for x64 on Windows 11
4배속으로 실행
확대 비율 2배
Macintosh System 7.5.5 (_Mini vMac_이 지원하는 마지막 버전)
8MB 가상 RAM (Mini vMac 기본값)
스크립팅 추가 기능이 포함된 HyperCard 2.2
HyperCard 2.2는 몇 가지 주목할 만한 이유로 중요하다. 첫째, AppleScript 지원이 추가되었고, 그다음 스크립트 디버거가 추가되었으며, 마지막으로 _HyperCard_가 Claris에서 다시 Apple 품으로 돌아온 시점을 나타낸다.
매킨토시 운영체제가 2.5MB RAM 안에 들어가던 시절을 기억하는가? 나는 잊고 있었다!
_HyperCard_를 리뷰하고 평가하는 일은 “인터넷”을 리뷰하고 평가하려는 것과 조금 비슷하다. 그리고 MacPaint. 그리고 완전한 애플리케이션 개발 제품군도 마찬가지다. Danny Goodman의 _The Complete HyperCard 2.0 Handbook, 3rd Edition_이 무려 1,000(!)페이지라는 사실을 보고도 정상인이라면 도망쳤겠지만, 이 사람은 아니었다. 그걸 어떻게 받아들일지는 당신에게 맡긴다.
이 글에서 어떤 구체적인 작업을 할지 고르기가 어렵다. 나는 _Handbook_의 샘플 프로젝트를 만들어 볼 생각이지만, 책이 자기 프로젝트에 대해 뭐라고 말하는지도 짚고 넘어가자. “어떤 의미에서 이 장에서 우리가 해볼 연습은 인위적이다. 왜냐하면 그것은 우리가 최종 스택의 모습에 대해 매우 분명한 비전을 가지고 있었을 뿐 아니라, 그 비전을 한 치도 벗어나지 않고 추구했다는 뜻을 암시하기 때문이다. 실제로는 진실과 거리가 한참 멀다.”
나에게는 그런 분명한 비전이 없다. 마치 빈 종이를 바라보며 스스로에게 “뭘 만들어야 하지?”라고 묻는 느낌이다. 종이접기로 접을 수도 있고, 수채화의 캔버스로 쓸 수도 있고, Coleco ADAM SmartWriter에 넣고 시를 타이핑할 수도 있다. 예술에는 경계가 필요하고, 나는 아직 _HyperCard_의 경계를 모른다.
그러니 그냥 처음부터 시작해서, 실행하고, 어디로 데려가는지 보기로 하자.
Lori Loughlin (맞다, _그_ Lori Loughlin이다)는 ADAM의 출력물에 신이 나 있다. 눈에 띄게 _시연되지 않은_ 것은 그 도트 임팩트 프린터가 얼마나 시끄러운지다.
_HyperCard_를 실행하면 Home “스택”으로 들어가는데, 여기서 “스택”은 서로 관련된 “카드”들의 모음이고 카드란 상호작용으로 강화된 데이터다. 초보자 관점에서 보면 스택을 하나의 애플리케이션으로 생각해도 무방하지만, 실행에는 _HyperCard_가 필요하다. (_HyperCard_는 독립 실행형 앱도 만들 수 있지만, 그것은 첫 사용자 경험이 아니다.)
Atkinson은 실제로 3x5 색인 카드 더미의 문자 그대로의 이미지를 떠올리게 하려 했다. 각 카드에는 정보가 담기고, 당신이 정의한 관계로 연결된다. 버튼은 카드에서 동작을 수행하는 수단이 되어, 순서대로 카드를 넘기고, 키워드로 관련 카드를 찾고, 카드 데이터를 검색하고, 애니메이션을 트리거할 수 있게 한다. 이 모든 것이 가능하고, 심지어 아주 쉽게 가능하다.
처음 들으면 그다지 흥미롭지 않게 느껴질 수도 있지만, _MYST_가 이것으로 만들어졌다는 사실을 생각하면, 이것이 체급 이상으로 강력하다는 데 의심의 여지가 없다.
오늘날 나는 스택을 “웹사이트 같은 것”, 각 카드를 “그 사이트의 페이지 같은 것”이라고 설명할 수 있다. 이런 지적 약어는 HyperCard 전성기에는 존재하지 않았다. 또 다른 현대적 약어를 쓰자면, “Home”은 스마트폰의 홈 화면과 비슷하다. 놀라울 정도로 그렇다. 심지어 관심 있는 개인용 스택을 추가하거나 삭제해서 자기만의 것으로 꾸밀 수도 있다.
0:00
/0:36
__(강렬한 점멸 스트로브 효과 포함) Beyond Cyberpunk__는 자기만의 방식으로 __HyperCard__의 경계를 밀어붙였다. 웹 버전도 있다. 원작의 매력 대부분은 빠졌지만.
Home 카드를 둘러보면, 포함된 스택들이 HyperCard 개발 도구의 힘을 보여주는 구체적인 예시를 제공한다. 주목할 만한 기능이 두 가지 있는데, 둘 다 너무 미묘하게 소개되어 있어서 놓치기 쉽다.
비트맵 Bookman Light (“Welcome to HyperCard”)에 짧게라도 찬사를 보내고 싶다. 정말 아름답게 배열된 픽셀 세트다.
첫 번째는 이 프로그램이 공짜로 제공하는 데이터베이스 기능이다. Appointments나 Addresses 스택을 열고 정보를 입력하면, 다음 실행 때 검색 가능한 데이터로 그대로 남아 있다. 플랫 파일에 저장되며 특별히 화려한 것은 아니지만, 이미 꽤 쉬웠던 _Superbase_보다도 더 쉽다.
두 번째는 스택에 새 데이터를 입력한 뒤 저장할 필요가 없다는 점이다. _HyperCard_가 자동으로 저장한다. 너무 투명하게 작동해서 거의 모든 앱이 원래 이렇게 동작한다고 착각하게 만들 정도지만, 아니다. Atkinson은 저장이라는 개념 자체를 특별히 싫어했다. 그는 컴퓨터에 데이터를 입력한 뒤 전원 플러그를 뽑아도, 데이터는 가능한 한 완벽에 가깝게 남아 있어야 한다고 생각했다.
이 “당신의 데이터는 안전하다”는 동작은 사용하거나 만드는 모든 스택에 본질적으로 내장되어 있다. 따로 활성화할 필요도 없다. 플래그를 설정할 필요도 없다. 컨테이너를 초기화할 필요도 없다. 데이터베이스 서버를 띄울 필요도 없다. 심지어 데이터를 다른 시스템으로 어떻게 옮길지 걱정할 필요도 없다. 데이터는 모두 스택 자체의 데이터 리소스 안에 저장되기 때문이다. 그냥 그 스택을 다른 컴퓨터로 복사하면, 데이터도 함께 따라간다고 안심하면 된다.
하지만 전형적인 Macintosh 최종 사용자 입장에서는 이 동작에 단점 하나가 있다. 스택을 이리저리 만져보고, 분해해 보고, 어떻게 만들어졌는지 보려면 반드시 그 스택의 복사본으로 작업하고 있는지 확인해야 한다! 저장이 자동으로 일어나기 때문에, 변경 사항이 영구적이라는 사실을 잊기 쉽다. “저장도 안 눌렀는데! 내 스택에 무슨 일이 생긴 거지?”
그래서 원본 스택은 실험 때문에 잡동사니가 쌓이거나 심하면 복구 불가능하게 망가질 위험이 있다. “변경 사항을 저장하시겠습니까?”라는 동작은 다른 모든 Macintosh 프로그램이 우리에게 가르쳐온 것이지만, _HyperCard_는 Mac 사용자가 오랜 세월 학습해 온 그 조심스러운 조건화를 거부했다.
자신만의 스택을 만들 생각조차 없더라도, 가장 기본적인 수준에서 _HyperCard_는 상당히 많은 것을 제공한다. 기본 제공 스택은 사용자에게 주소록, 전화번호부, 일정 캘린더, 간단한 그래프 작성기, 그리고 다른 사람들이 만든 수천 개의 스택을 실행하고 (심지어 들여다볼 수도 있는!) 능력을 제공한다.
번들 스택은 사용하기 쉽지만, “견고한” 유틸리티와는 거리가 멀다. 그래도 8비트 시대의 타이핑 입력 프로그램들보다 더 보기 좋고 사용하기도 쉽다. 필요에 맞게 수정할 수도 있고, 심지어 단지 미적으로 바꾸는 것도 가능하다. 무료 스택은 BBS 시스템, 책 부록, 잡지 부록 디스크 등에서 구할 수 있었다.
_HyperCard_는 초기 월드 와이드 웹에 비스듬히 인접한 무언가를 처음으로 엿보게 해주었다. Archive.org에는 수천 개의 스택이 있어서, 공동체의 폭넓음을 느껴볼 수 있다. 자연주의를 배우고, _Hitchhiker's Guide to the Galaxy_를 읽고 (공식 출시판이다!), 독일어를 연습할 수 있다. 보라색 어린이 공룡 Barney를 죽이는 데 바쳐진 스택도 무려 두 개나 있다. 클램과 조개껍데기 예술에 대해 더 배우고 싶은 사람을 위해 잡지형 간행물, 기본 스택의 확장판, 게임, 그리고 기타 별난 것들이 제공되었다. 내가 “사랑하지 않을 이유가 뭐가 있나?”라고 말할 때, 정말 진심이다.
어젯밤 저녁에 먹고 남은 조개껍데기로 인형 만드는 정보를 퍼뜨리는 더 나은 방법이 있다면 한번 보여달라.
콘텐츠 소비도 좋지만, _HyperCard_가 에너지의 대부분을 쏟는 곳은 콘텐츠 _창작_이다. 너무나 많은 아이디어를 담은 수많은 스택들을 보고, 그중 많은 것들이 프로그래밍 경험이 전혀 없는 평범한 사람들에 의해 만들어졌다는 이야기를 읽다 보면, 그 공동체에 참여하고 싶은 충동이 압도적으로 밀려온다.
카드는 개념적으로 두 영역으로 나뉜다. 배경과 전경이다. 현대의 프레젠테이션 소프트웨어인 _PowerPoint_나 Google _Slides_로 치면, 각각 템플릿 테마(대체로 고정되어 있는 것)와 슬라이드 자체(슬라이드별 동적 속성)에 해당한다.
각 영역의 레이어는 “뒤쪽”에 고정된 그래픽 레이어에서 시작한다. 버튼 같은 객체를 추가하면, 그 객체는 그래픽 레이어 위의 고유 번호를 가진 레이어에 배치되며 순서를 다시 조정할 수 있다.
개념 자체는 충분히 이해하기 쉽지만, 도구는 카드 요소들의 현재 순서를 사용자가 시각화하도록 특별히 잘 도와주지는 못한다. 각 요소를 일일이 검사해야만 다른 레이어들(객체들)에 비해 어디에 놓여 있는지 알 수 있다. “Inspector” 패널이 있었으면 정말 좋았을 것이다.
웹 브라우저가 첫날부터 웹 페이지를 만들 수 있는 시각 도구를 함께 내장해서 출하되었다고 상상해 보라. 그런 것들이 우리에게서 빼앗겼다는 사실 자체가 거의 모욕처럼 느껴진다.
_HyperCard_에는 카드를 구성하는 세 가지 주요 요소, 즉 텍스트, 그래픽, 버튼을 만들기 위한 기본 및 고급 도구가 있다. 이 요소들은 원한다면 배경과 전경 양쪽 모두에 존재할 수 있다. 단, 전경 요소가 사용자 동작에 먼저 प्रतिक्रिया할 권리를 가진다는 점은 염두에 두어야 한다.
텍스트는 “field”로 배치되며, 서식을 지정하고, 입력하고, 편집하고, 복사/붙여넣기할 수 있고, 검색 대상이 되게 만들 수도 있다. 그래서 스택은 즉시 데이터베이스 초능력을 얻는다. 보통 필드는 카드 안에 시각적으로 들어맞는 양의 텍스트를 담지만, 카드 크기가 고정되어 있어 아이디어가 너무 커질 때는 훨씬 더 큰 텍스트 블록을 담는 스크롤 가능한 하위 창으로 표시할 수도 있다.
텍스트 서식 제어는 기대 이상으로 탄탄하다. 커닝은 없지만, 글꼴, 크기, 문자 스타일, 정렬, 줄 간격을 지정할 수 있다. Macintosh 비트맵 글꼴은 미리 만들어진 크기로 제공되었고, 그 크기에서 가장 보기 좋게 보이도록 손으로 그려졌다. 텍스트 확대/축소도 가능하지만, 미적 자존심은 조금 접어야 할지도 모른다. 아니면 직접 그리든가?
이 _HyperCard_ 사본에는 14pt만 들어 있었다. 33pt로 확대해도 괜찮긴 하지만, 간격이 이상해지고 추가 픽셀 해상도를 제대로 활용하지 못하는 것이 분명하다. 인터넷 댓글은 잠시 접어두시라. __Adobe Type Manager__는 나중 글에서 다룰 예정이다.
“텍스트를 직접 그려라”는 건 실제 가능한 선택지다. 사실상 _MacPaint 1.x_의 완전한 구현처럼 보이는 것이 포함되어 있기 때문이다. 익숙한 도구들이 모두 있다. 선택 가능한 브러시 두께, 페인트/채우기 패턴, 올가미 도구, 채워진 도형과 빈 도형, 스프레이 캔, 비트맵 글꼴까지. (단, 그 텍스트를 검색 가능하게 만들 필요가 없다면.) 그렇다. Atkinson의 첫 MacPaint 공개 시연에서 그토록 큰 감탄을 자아냈던 전설적인 지우개조차 여기 있다. 어제의 대사건은 _HyperCard_에서는 “별것 아닌 것”이다.
이 도구들은 처음 보이는 것보다 훨씬 더 풍부하다. 수정 키를 누르면 온갖 유용한 변형이 열리기 때문이다. 연필 도구로 그릴 때 SHIFT를 누르고 있으면 수평 또는 수직으로 제한된다. 브러시 도구 사용 중 OPTION을 누르면 지우기처럼 반전된다. 이런 식이다.
자유형 왜곡이 가능하다는 사실에 나는 충격을 받았다. 메뉴 막대 주변의 질감은 내가 스택의 배경을 수정하고 있음을 보여준다. 이 데모에서는 자동 저장이 나를 물었다. 임시 변형이 영구적인 것이 되어버렸다.
도구 팔레트 자체는 메뉴에서 “떼어낼” 수 있고, 그 상태가 훨씬 더 유용하다. 팔레트 아이콘을 더블클릭하면 추가 비법이 드러난다. 연필 도구는 “fat bits” 모드를 열고, 지우개는 화면 전체를 지운다. _Handbook_은 그리기 기능에만 80페이지 넘게 할애한다. 나는 그냥 이렇게 말하겠다. 생각할 수 있는 것이라면 그릴 수 있다.
다만 두 가지 함정은 기억하라. undo는 단 한 단계뿐이고, 모든 자유 손그림은 단일 레이어에서 이루어진다. 당신이 찍어놓은 픽셀은 그 자리에 있던 픽셀을 덮어쓴다. 끝이다.
완전한 페인트 프로그램이 포함되어 있다는 사실은, 아이디어가 떠오르면 스케치해 보고, 어떻게 보이는지 확인하고, 직접 시도하고, 예술 도구와 디자인 도구(그리고 코딩 도구) 사이를 매끄럽게 오갈 수 있게 해주기 때문에 정말 즐겁다. 맥락을 전환하는 감각이 자연스럽고, 문자 그대로의 스케치는 즉시 상호작용하는 프로토타입이 된다. 아니면 최종 아트가 되어도 된다! 내가 무슨 판단을 하겠는가?
창작은 탄생이고, 탄생은 지저분하다. (참고로 저 스케치 화살표 버튼들은 실제로 동작한다)
도구에서 이렇게 많은 자유를 준다는 사실은 약간 충격적이다. 여담이지만, 현대의 노코드 편집기 _AirTable_을 잠깐 들여다보며 간단한 주소록을 만들어 보려 했다. 의무적인 가입 절차와 도구를 찔러보며 느낀 답답함을 넘어서, 구독료를 내지 않으면 헤더 그래픽 하나도 배치할 수 없었다. 진보라니!
하이퍼링크 없는 하이퍼미디어가 무슨 의미가 있을까? _HyperCard_에서는 이것이 버튼으로 구현되며, 웹에서 Javascript를 조금이라도 만져본 적 있다면 이미 그것이 어떻게 작동하는지 좋은 “감” (wink wink)을 가지고 있을 것이다. 텍스트 필드처럼 고유 ID, 시각 스타일을 갖고, 스크립트를 트리거할 수 있다. 기억하자. _HyperCard_는 1987년에 스크립팅과 함께 데뷔했고, 비슷한 클라이언트 측 스크립팅은 웹 브라우저에서 Netscape Navigator 2.0 c irca 1995가 되어서야 나타났다. 당시로서는 최첨단이었다.
버튼이 독자를 다른 카드로 이동시키기만 하면 된다면, Script...를 전혀 건드리지 않고도 설정할 수 있다. 전환 애니메이션(Effect...)까지 포함해서 말이다.
버튼에 아이콘을 추가하는 일은 고전 Macintosh의 “resource forks” 때문에 조금 이상하다. 모든 이미지는 이 특별한 컨테이너 안에 저장되며, 그것은 스택 파일 자체 내부에 있다. 스택 옆 폴더에 이미지들을 잔뜩 던져 넣고 자유롭게 접근하는 식은 불가능하다. 여러 단계 undo가 없는 것과 마찬가지로, 이것은 “미래에서 온 방문자여, 당신이 아는 것을 잠시 잊으라”는 종류의 요구다.
아이콘 수정이 꽤 귀찮다는 점을 알고 있었기에, Atkinson은 _HyperCard_에 아예 아이콘 편집기 미니 프로그램 전체를 넣어두었다. 보통 이런 것은 Apple의 인기 무료 도구인 _ResEdit_로 수정했을 텐데, 이 프로그램은 사용자가 애플리케이션의 resource fork를 시각적으로 검사할 수 있게 해주었다. 이것에 관한 543페이지짜리 매뉴얼이 있다. (그 시절 저자들은 혹시 부피로 원고료를 받았던 걸까?)
뭐, 나보다 더 못 그린 것도 봤다.
_ResEdit_를 이용하면 애플리케이션과 Finder 안의 온갖 재미있는 것들을 조정할 수 있었다. 시스템 수준 경고창이나 bomb 이벤트 때 보이는 아이콘을 다시 그릴 수도 있고, 진행 표시 막대를 그리는 데 쓰이는 채우기 패턴을 바꿀 수도 있었다. 애플리케이션의 메뉴를 숨기거나 보이게 하고, 효과음을 바꾸는 것도 가능했다. 시스템 리소스를 건드리는 건 위험한 일이지만, 바로 그 위험함 때문에 재미있기도 하다. 시스템을 해킹하라!
이상하네. 내 _SimpleText c_ opy에는 관심이 절실한 저자가 뻔뻔하게 구독을 구걸하는 내용이 들어 있다.
버튼은 얼마든지 일반적이고 전형적이며 Macintosh다운 방식으로 스타일링할 수 있지만, 투명하게 만들 수도 있다. 투명 버튼은 단지 화면 위의 “핫스팟”을 정의하는 사각형일 뿐이며, 시각적으로 이미 “클릭 가능”해 보이는 이미지 위에 특히 유용하다. 텍스트에 하이퍼링크를 추가하고 싶다면, 그 텍스트 위에 투명 버튼을 그려 올리고 연결하면 끝이다. 아마 벌써 문제가 보일 것이다.
텍스트를 다시 써보자.
그러면 이제 버튼을 수동으로 다시 옮겨서, 새로운 위치에 놓인 수정된 텍스트 위를 덮도록 맞춰야 한다. 그리고 그 상태는 텍스트가 절대로 이동되거나 편집되지 않는 한에서만 유지된다. 이동 과정에서 텍스트가 두 줄로 갈라지지 않았기만을 바랄 뿐이다.
_HyperCard_에는 이것을 프로그래밍적으로 살짝 흉내 내는 교활한 방법이 있긴 하지만, 텍스트 안의 HTML 하이퍼링크는 의심할 여지 없이 더 나은 개선이었다. 그럼에도 _HyperCard_는 아직 오지 않은 HTML보다 다시 한번 앞서나가는데, 바로 이미지 하이퍼링크 때문이다.
유럽 지도 같은 그림을 그리거나 붙여 넣은 다음, 각 나라 위에 직접 투명 버튼을 그려라. 작업을 마치면 겉보기엔 평범한 지도처럼 보이지만, 이제 각 나라는 클릭 가능하며, 스크립트 하나 건드리지 않고도 클릭한 나라의 정보 페이지로 wipe 전환을 걸어 이동시킬 수 있다.
사진 몇 군데를 매핑하는 방법을 보여주는 W3Schools 예제다. _HyperCard_ 버튼 만세.
_HyperCard_의 링크는 조금 멍청한 구석이 있는 것이 사실이지만, 개념적으로는 정말, 정말 이해하기 쉽다. 내가 HyperCard 방식에서 특히 좋아하는 것은, 기존 GUI에 대한 지식을 활용하고 그것을 조금 확장해서 익숙하면서도 훨씬 더 강력한 무언가로 만든다는 점이다.
네안데르탈인 교육하기
책에서 이렇게 말한다. “대부분의 Macintosh 애플리케이션 사용자는 화면에 나타나는 많은 이미지에서 어떤 깊이감이나 입체감을 느낀다. 심지어 풀다운 메뉴조차 화면에 나타날 때 겹쳐지는 느낌이 있다. 대부분의 경우, 이 효과는 drop shadow라고 부르는 것 때문에 생긴다.”
이것은 아마도 HyperCard 도구 집합에서 가장 큰 공백일 것이다. 그렇다고 음향 효과가 완전히 빠져 있다는 뜻은 아니지만, 그래픽과 스크립팅에 쏟아진 것과 같은 세심한 배려를 거의 받지 못했다. 참고로, 그래픽은 매뉴얼에서 80페이지 이상을 차지하는 반면 사운드는 10페이지도 되지 않는다.
카드에 음향 효과를 붙이는 방법은 스크립팅뿐이다. 단순한 beep, 악기 음색으로 이루어진 음표 시퀀스, 혹은 미리 녹음된 사운드 파일이 될 수 있다. 드로잉 도구가 그렇게 풍부하다는 점을 생각하면, 나는 솔직히 최소한 간단한 작곡을 입력할 피아노 건반 정도는 있을 것이라고 기대했다.
단순 작곡을 돕는 음악 제작 스택들이 존재했고, 그 책임은 제3자 소프트웨어로 넘어갔다. 그 자체가 죄는 아니지만, 이 외에는 탄탄한 도구 집합이라는 점을 감안하면 꽤 눈에 띄는 공백처럼 느껴진다.
__HyperComposer__는 전적으로 __HyperCard__로 만들어진 전문 스택 애플리케이션으로, __HyperCard__의 난해한 음악 작곡 스크립팅을 단순화하는 데 도움을 주었다. 시각적으로 곡을 만들면, 스크립트가 내장된 버튼이 튀어나와 자신의 스택에 바로 놓을 수 있다. 그 버튼을 클릭하면 작곡한 곡이 재생된다. 1990년에 $70, 2025년 기준으로는 $173.
매뉴얼의 노코드 튜토리얼에서는 30페이지 만에 사용자 지정 일일 To-Do 스택을 만든다. 하이퍼링크 버튼, 검색 가능한 텍스트, 사용자 정의 아트를 넣어서 말이다. 튜토리얼이 끝날 무렵이면 사용자는 자기 사양에 맞는 유용한 애플리케이션을 손수 만들게 되며, 원한다면 세상과 공유할 수도 있다. 나쁜 하루 일과는 아니고, 솔직히 말해 오늘날 이 정도 성과를 그대로 재현하라면 나도 쉽지 않을 것이다.
이것은 매우 깊이 있는 힘을 주는 프로그램이다. 단지 30분만 작업해도 사용자는 이미 흥미로운 무언가의 시작점을 갖게 된다. 사용자가 매일 쓰는 앱들과, 주말 동안 자신이 만들 수 있는 것 사이의 간극이 적어도 10 PRINT "Hello World"와 일상 앱들 사이의 간극보다 더 작게 느껴진다. 성공이 실현 가능해 보인다.
거의 즉시 무언가를 할 수 있고, 게다가 제법 그럴듯한 것도 할 수 있습니다. 그래픽, 애니메이션, 사운드 같은 것들요. 즉각적인 피드백을 받으니까 바로 보거나 들을 수 있어요. 그냥 기분이 좋아요. 재미있죠.
- Jan Lewis, 1990년 HyperCard 에피소드,
Computer Chronicles
할 일 목록, 주소록, 레시피 카드 같은 것들도 모두 좋지만, 모든 예술가는 결국 더 앞으로 밀고 나가 _그 너머_로 가고 싶은 충동을 느낀다. 이 시점에서 나는 아직 책의 3분의 1밖에 읽지 않았는데, 나머지 600페이지는 대체 무엇을 이야기할 수 있을까? 이 글의 나머지와 같은 것, 바로 프로그래밍이다.
안다, 안다. 많은 사람에게 이건 지루하고 난해한 주제다. 믿어달라. 나도 이해한다. 많은 사람들이 _HyperCard_가 프로그래밍을 접근 가능하게 만들기 전까지는 프로그래밍에 질려 있었다. 1988년 1월의 _Compute Magazine_에서 (Leemon의 rant는 몇 달 뒤에 나온다) David D. Thornburg는 이렇게 썼다. “이것은 언어의 적절한 설계가, 스스로를 프로그래머라고 생각하지 않았을 사람들에게도 프로그래밍을 열어줄 수 있음을 증명한다.”
이것은 _HyperCard_의 25주년 당시의 직접적인 증언들로도 뒷받침된다.
생일 축하해 Hypercard!!! 이번 주말은 HyperCard 25주년이에요. 제 Mac 프로그래밍 세계로 들어가는 첫걸음이었죠!
- Geppy
아이디어를 떠올리고, Hypercard로 그것을 쉽게 구현할 수 있었다는 경험은 분명 제 평생의 프로그래밍 관심에 영향을 주었습니다.
- Alex Seville
25년 전 Bill Atkinson의 HyperCard 데모에서 너무 큰 영감을 받아서, 저는 모든 걸 제쳐두고 Mac 프로그래머가 되었습니다.
- Andrew Stone
사실은 이렇다. 만약 _HyperCard_를 조금이라도 만져봤다면, 당신은 이미 프로그래밍을 하고 있었던 것이다. 단지 몰랐을 뿐이다. 우리는 지금 그것을 “노코드”라고 부르지만, 내 생각에 _HyperCard_는 “코딩 집사”에 더 가깝다. 코드는 있다. 다만 흔한 작업에 대해 당신이 직접 쓸 필요가 없을 뿐이다.
0:00
/0:22
“노코드”는 최종 사용자인 __당신__에게만 해당한다. __HyperCard__는 당신을 대신해 프로그래밍하고 있다.
HyperTalk는 Dan Winkler가 이 프로젝트에 기여한, _HyperCard_만의 전용 스크립팅 언어다. 당시 Macintosh에서 인기 있던 개발 언어 Pascal을 본떠 만들어졌으며 (_Photoshop_도 원래 Pascal로 개발되었다), 읽고 쓰기 최대한 쉽게 설계되었다. 그렇게 함으로써 프로그래밍의 문턱을 허물고, 공동체에 동등한 접근권을 주려 한다.
핵심적으로 _HyperCard_는 메시지를 주고받는 객체들의 집합이다. HyperTalk는 스택 개발에 객체지향적 접근을 취한다.
HyperCard 객체는 네 종류가 있다. stack, card, button, text field다. 소박한 버튼을 생각해 보자. 버튼은 “사용자가 나를 클릭했다” 같은 메시지를 받을 수 있다. 그런 일이 일어나면, 버튼은 그 메시지에 어떤 방식으로든 응답할 기회를 갖는다. 그래픽 이미지를 표시할 수도 있고, 소리를 재생할 수도 있고, 다른 객체에 자기 메시지를 보내 다른 일을 하게 할 수도 있다.
스크립트는 객체가 언제, 어떻게 메시지를 처리하는지 정의한다. _HyperCard_의 시각 편집기에서 스크립트는 일종의 “객체 안쪽”에 들어 있다. 버튼을 더블클릭해서 내부 해부학을 들여다보면, 스크립트가 그 버튼의 “뇌”인 셈이다.
비록 HyperTalk 스크립트를 _작성_할 줄은 몰라도, 아마 큰 어려움 없이 읽을 수는 있을 것이다.
on mouseUp
beep
end mouseUp
아주 작은 걸음부터. 마우스 버튼을 누르면 그 버튼은 물리적으로 “아래로” 내려가고, 손가락을 떼면 다시 “위로” 올라간다. 그러니 이 스크립트는 “마우스 버튼이 놓이면, beep 하라”는 뜻이다.
beep를 세 번 하고 싶은가?
beep 3
beep는 잊고, 이 스택의 다음 카드로 가보자.
go to the next card of this stack
아니다, 이 스택 말고 다른 스택의 마지막 카드로 가자.
go to the last card of the stack "Stone Tools"
시각 전환 효과도 넣고, 다른 일도 하게 하고 싶은가?
on mouseUp
visual effect checkerboard very slowly
beep 3
go to the last card of the stack "Stone Tools"
end mouseUp
이런 조합적인 개발 방식은 자연스러운 속도로 기술을 쌓게 해준다. 배울수록 새로운 동작을 추가하고 결과를 즉시 확인하라. 새것을 시도하라. 만지작거려라. 어떻게 하는지 추측해보라. 다른 스택에서 멋진 걸 봤는가? 열어서 마음에 드는 부분을 복사하라. 실험하라. 공유하라. 놀아라.
_HyperCard_는 우리가 즐겁게 놀기를 바란다. 나는 즐겁다.
HyperTalk는 아이디어를 빠르게 반복하게 해주고, 최종 사용자로서 오랜 시간 배워온 것과 비슷한 용어로 우리의 의도를 표현하게 해준다. 그 과정에서 “원함”과 “실행” 사이의 체감 거리는 크게 줄어든다. 물론 예상 못 한 함정이 따르더라도 말이다.
큰 함정은 영어 비슷한 언어가 흔히 그렇듯 꽤 무례한 각성의 순간이 될 수 있다. 처음엔 너무 단순해 보이지만, 사실은 진짜 자연어만큼 유연하지 않다. 앞서 예제로 돌아가 보자. 다음 중 무엇이 동작하고 무엇이 에러를 낼지 직감할 수 있는가?
on mouseUp
beep 3 times
end mouseUp
on mouseUp
very slowly visual effect checkerboard
go to the next card
end mouseUp
on mouseUp
repeat 3 times
beep
end repeat
end mouseUp
셋 다 그럴듯해 보이지만, 실제로 동작하는 것은 세 번째뿐이다. 바로 여기서 영어 흉내 내기가 언어에 해를 끼친다. 영어 비슷한 외양은 초심자에게 자유로운 사고 표현이 가능할 것처럼 암시하지만, HyperTalk는 그런 것을 이해할 수 없다.
프로그래머는 함수 이름과 그것을 움직이는 매개변수가 필연적으로 엄격하고 순서가 정해져 있다는 사실을 안다. visual effect 명령의 좀 더 프로그래머다운 정의는 아마 이렇게 될 것이다.
void visualEffect(EffectType type, EffectSpeed speed)
|----------| |-------------| |---------------|
command type speed
이렇게 드러내 놓으면, 일반적인 코딩 관례에 익숙한 사람은 HyperTalk도 명령에 대해 비슷하게 특정한 매개변수 순서를 (자주) 요구한다는 점을 즉시 이해한다. 우리는 이렇게 할 수 없다.
very slowly visual effect checkerboard
|---------| |-----------| |----------|
speed command type
우리는 오히려 언어의 숨은 순서를 따라야 한다.
visual effect checkerboard very slowly
|-----------| |----------| |---------|
command type speed
_HyperCard_에는 검색 가능한 스택 형태의 도움말 문서가 포함되어 있고, 거의 영어 같지만 완전히 영어는 아닌 감각에 익숙해질 수 있도록 테스트하고 가져다 쓸 수 있는 샘플 스크립트도 들어 있다. 그래도 beep 3 times처럼 분명 유효해 보이는 것이 실패할 때는 분명히 짜증날 수 있다.
HyperTalk의 HyperCard 내 구현에 대한 또 다른 불만은 코드 편집기 자체다. 프로그램을 설치할 때 뭔가 놓친 줄 알 정도로 너무 앙상하다. 코드를 자동으로 들여쓰기해 주는 것, 그게 전부다. 어떤 실수에 대해서도 어떤 경고도 받지 못한다. 무엇을 쓰든 기꺼이 받아들인다.
오직 스크립트를 실행하려고 할 때만 오류가 드러난다. 한편으로는 스크립트를 빨리 쓰고 바로 테스트하기 쉽다. 하지만 Mac OS에 번들로 들어 있던 AppleScript 개발 도구 _Script Editor_처럼 조금만 더 행동했어도 피할 수 있었던 추가 단계가 여전히 필요하다. _Script Editor_는 조금 더 성실하게 당신을 챙긴다.
왼쪽의 __Script Editor__는 내가 “Check Syntax”를 클릭하자 “times” 사용에 대해 경고해 준다. 한편 오른쪽의 _HyperCard_ 형제는 그런 도움을 주지 않는다. 심지어 _AppleScript도_ 받아들일 수 있는데도 말이다.
완전한 영어가 아닌 데서 오는 좌절이 있더라도, 그 시대의 다른 어떤 선택지보다 여전히 훨씬 앞서 있다. _HyperCard_의 “Hello World”는 완전히 기능하는 할 일 관리 애플리케이션이다. 개발의 물에 조심스레 발끝을 담그는 Mac 사용자에게 이것이 얼마나 좋은 감정을 주는지 모른다. 그 감정은 시스템과 자기 자신에 대한 신뢰를 쌓고, 어쩌면 계속 배우고 싶다는 마음까지 키운다.
HyperTalk로 할 수 있는 일 전체 목록은 여기서 다룰 수 없을 만큼 방대하다. 식욕을 돋우기 위해, 훨씬 더 긴 목록 중 극히 작은 일부만 맛보기로 보자.
| Command | Effect |
|---|---|
| drag from <point> to <point> [with <modifier key>] | 마우스 움직임을 시뮬레이션한다. 예를 들어 option 키를 “누른 채” 움직이는 것까지 가능하다 |
| click at <point> [with <modifier key>] | 마우스 클릭을 시뮬레이션한다 |
| doMenu<menu item> [<menuName/>] [without dialog] | 애플리케이션 메뉴를 조작한다 |
| ask<question> | 텍스트 입력이 있는 대화상자를 띄운다 |
| repeat<number of times> [times] | 어떤 동작 집합을 여러 번 수행한다 |
| wait for <number> [seconds] | 일정 시간 그냥 기다린다 |
| dial<phone number> | 문자 그대로 전화를 걸어 통화한다 |
| open file <name of file> | 파일을 읽기 위해 열거나, 없으면 만든다 |
| hide menubar | 언제나 떠 있는 Macintosh 메뉴 막대를 끈다 |
| choose<tool name> tool | 사용을 시작할 HyperCard 도구를 선택한다 |
| set the <property> of <object> to <value> | 시각적 속성이든 아니든 객체의 어떤 속성이든 조작한다 |
객체에 설정할 수 있는 몇 가지 속성 예시:
| Object type | Settable properties |
|---|---|
| window에 대해 | rectangle, dithering, visible, scroll |
| painting 중에는 | brush, pattern, textFont |
| text field에 대해 | textAlign, textStyle, dontWrap, script |
| button에 대해 | icon, visible, name, style |
내장 함수의 일부만 조금 맛보자면:
| Function | What it does |
|---|---|
| the date | 10/30/99 형식의 날짜 |
| the long date | Thursday, October 30, 1999 형식의 날짜 |
| the log2 of <number> | <number>의 밑이 2인 로그값 |
| the clickText | 텍스트 필드 안에서 마우스가 클릭한 단어 |
| the ticks | Mac이 켜진 뒤 몇 tick이 지났는가? 60 fps 기준으로 1 tick은 1/60초다. |
| the trunc of <number> | <number>의 소수 부분을 제거한다 |
불리언, 산술, 논리, 문자열, 타입 연산자가 충분히 있어서 다양한 일반 문제를 해결할 수 있다. 필요한 함수가 없다면 새 함수를 만들어 네이티브 명령처럼 스크립트에서 사용하면 된다. 핵심 기능이 빠져 있다면 _HyperCard_는 XCMD와 XFCN을 통해 확장할 수 있는데, 이것들은 네이티브 코드로 만든 새로운 명령과 함수다. 색상 지원을 추가하거나, SQL 데이터베이스에 접근하거나, 사운드를 디지타이즈하거나, 심지어 HyperCard 안에서 _HyperCard_를 이용해 XCMD를 컴파일하게 하는 일도 가능하다. 진짜 우로보로스 같은 이야기다.
HyperCard 2.2에서는 AppleScript가 동등한 개발 언어로 추가되었다. 한때는 HyperTalk가 단지 _HyperCard_의 스크립팅 언어가 아니라, Macintosh 생태계 전체의 시스템 전역 스크립팅 언어가 될 수도 있다는 이야기가 있었다. 대신 AppleScript가 개발되었고, HyperTalk에서 분명한 영감을 받으면서도 Dave Winer의 (또 그 사람이다!) _Frontier_에 꽤 그늘을 드리웠다. 결국 ,Frontier는 Sherlocked되었다.
AppleScript는 시스템과 애플리케이션을 스크립트로 제어할 수 있게 해준다. 예를 들어 이런 식이다. (System 7.5.5 기준)
tell application "Scriptable Text Editor"
select word 5 of paragraph 4 of the first document
set font of selection to "Helvetica"
end tell
HyperTalk처럼, 이것도 바로 쓸 수는 없어도 아마 무슨 뜻인지는 이해할 수 있을 것이다. 이 시너지를 통해 외부 애플리케이션을 _HyperCard_에서 직접 제어할 수 있다. _PageMaker 5.0_은 아예 HyperCard 스택을 동봉해 출하하기도 했다.
아래 영상에서는 내가 HyperCard 버튼을 클릭하고, 텍스트를 입력받은 다음, 그 텍스트를 외부 텍스트 편집기에 밀어 넣고 스타일을 적용하고 있다.
0:00
/0:13
이제 평이한 영어로 프로그래밍한다는 이야기를 하니, 많은 사람이 화면을 향해 소리치고 있을 것이다. 걱정 마라. 나도 잘 들린다. 동의한다. 현대의 자연어 프로그래밍 환경에 대해서도 이야기해야 한다. Inform 7을 이야기해 보자.
모르는 사람을 위해 설명하자면, Inform은 수십 년 동안 인터랙티브 픽션 개발을 위한 굳건한 프로그래밍 언어였다. (Zork 같은 텍스트 어드벤처를 떠올리면 된다.) 오랫동안 Inform 6이 표준이었고, 세미콜론까지 갖춘 “진짜 프로그래밍 코드”처럼 보였으니, 다들 “진지한” 언어라고 여겼다.
Object foyer "Foyer of the Opera House"
with description
"You are standing in a spacious hall, splendidly decorated in red
and gold, with glittering chandeliers overhead. The entrance from
the street is to the north, and there are doorways south and west.",
s_to bar,
w_to cloakroom,
n_to
"You've only just arrived, and besides, the weather outside
seems to be getting worse.",
has light;
이 코드는 플레이어에게 방을 설명하고, 출구가 어디로 이어지는지 정의하며, 그 방에 빛이 있음을 지정한다. “Cloak of Darkness” 샘플 프로젝트에서 가져온 것이다.
2000년대 초반, Inform 제작자 Graham Nelson은 번뜩이는 깨달음을 얻었다. 텍스트 어드벤처 엔진에는 영어 플레이어 입력을 받아 코드에 매핑하는 게임 내 파서가 있다. 그렇다면 비슷한 파서를 사용해 영어 코드를 받아 코드에 매핑할 수 있지 않을까?
절차적 코드의 문자 그대로의 바꿔 말하기로서의 자연어는 양쪽의 결함을 모두 떠안을 수 있다. 그리고 겉보기만 자연어를 흉내 낸 많은 프로그래밍 언어들(예를 들어 COBOL이나 AppleScript)은 C 같은 정통 코딩 언어와 감각적으로 설득력 있게 “다르다”고 느껴지지 않는다. 이는 아마도 진정한 언어학적 특징을 담고 있지 않기 때문일 수 있다. 그럼에도 나는 새로운 시스템 설계에서 자연어가 문법 옵션으로서 너무 쉽게 간과된다고 느낀다.
- Graham Nelson, “Natural Language, Semantic Analysis, and Interactive Fiction”, 2006
Inform 7은 그 연구의 결과이며, HyperTalk보다 훨씬 더 극적인 시도를 한다. 아까의 같은 방을 어떻게 묘사하는지 보자.
Foyer of the Opera House is a room. "You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west."
Instead of going north in the Foyer, say "You've only just arrived, and besides, the weather outside seems to be getting worse."
The Cloakroom is west of the Foyer.
The Bar is south of the Foyer.
믿기 어려울지 모르지만, 이것은 실제로 컴파일되고 플레이되는 정식 Inform 7 코드다.
Inform 7은 HyperTalk의 흉내보다 훨씬 더 자연스러워 보인다. 마치 시스템과 대화하듯 원하는 것을 말하면 그대로 해줄 것처럼 보인다.
The Rain Forest is a room.
The player is in The Rain Forest.
The stone is an object. The player has the stone.
If the player has the stone say "Your pocket feels very hot!"
시도 1. 이건 동작하지 않는다.
민망하군. 다시 해보자.
The Rain Forest is a room.
The player is in The Rain Forest.
The stone is an object. The player holds the stone.
If the player holds the stone say "Your pocket feels very hot!"
시도 2. 플레이어에게 stone을 주려면 “has”가 아니라 “holds”라고 해야 한다. 그런데 “if” 부분은 여전히 실패한다.
에헴!
The Rain Forest is a room.
The player is in The Rain Forest.
The stone is an object. The player holds the stone.
Every turn:
If the player carries the stone:
say "Your pocket feels very hot."
성공! 다만 그게 작동하게 만들려면 꽤 수상할 정도로 프로그래머다운 접근을 취해야 했다. 게다가 객체를 주는 데는 “holds”를 쓰면서, 인벤토리를 확인할 때는 “carries”를 쓴다.
분명 강조점은 “무엇이든 원하는 대로 쓸 수 있을 것처럼 보인다”는 데 있다. 하지만 조금만 자세히 들여다보면 이런 모든 시스템의 속임수가 드러난다. 프로그래밍에는 프로그래밍이 필요하고, 프로그래밍에는 구조가 필요하다. 기대한 대로 작동하는 프로그램을 만들기 위해 자신의 생각을 어떻게 구조화할지 배우는 것이야말로 진짜 배워야 할 교훈이다. 친절한 언어들은 때때로 그 교훈을 가려버릴 수 있다.
좋다, 좋다. 바이브 코딩 이야기를 하겠다. 하지만 현실적으로 무슨 말을 더 할 수 있을까? 이건 아주 새로운 현상이고, 그 효용 주장을 뒷받침하거나 반박할 경험적 증거도 거의 없다. 그것이 없애 줄 수 있는 장벽 하나는 개발 작업의 기반 언어로서 영어에 대한 의존일 수 있다. 다국어 HyperCard 비슷한 무언가가 나온다면 정말 특별할지도 모른다.
나는 ChatGPT에게 다음 프롬프트로 HyperCard 스택을 HTML로 재현해 달라고 요청했다.
“HyperCard에서는 카드에 데이터를 로컬 저장하는 사용자 지정 주소록을 아주 간단히 만들 수 있다. 웹 브라우저에서 그걸 가장 간단하게 복제하는 방법은 무엇인가? 항목마다 한 페이지씩, name, address, phone number 필드가 있다고 가정하자. 항목을 하나씩 넘겨볼 수도 있어야 하고, 검색으로 정보를 찾을 수도 있어야 한다. 예를 들어 name 필드에서 “Drum”을 찾는 식이다.”
결과는 이랬다.
코드는 이렇다.
겉보기에는 동작하는 것 같지만, 나는 웹 개발을 충분히 알지 못해 그것을 검증할 수 없다. 그렇다고 그것을 이해하기 위해 배워야 할 동기도 생기지 않는다. 이 목적에 “가장 적합한 언어”로 해달라고 요청했어도 마찬가지였을 것이다. HyperTalk와 달리, 이 접근은 결과를 얻는 과정에 내가 참여하라고 요구하지 않는다. 내가 평가해야 하는 것은 결과물 자체뿐이다. 변경을 요청했을 때는 전혀 다른 디자인과 레이아웃이 돌아왔지만, 기능 변경은 들어 있었다. 그 전투는 이긴 걸까, 진 걸까?
또한 이것을 어떻게 테스트해야 할지도 전혀 모르겠다. 내 사양 자체도 역시 vibes였기 때문이다. 물론 완전한 사양서를 써서 그에 맞춰 LLM에게 만들라고 할 수는 있겠다. 실제로 그렇게 하는 사람들이 소프트웨어 개발에 존재하며, 그들을 “코더”라고 부르지는 않는다.
이것은 “바이브 제품 관리”다.
그게 충분히 좋은지 판단할 자격은 내게 없지만, 적어도 한 사람은 그 결과에 꽤 만족하는 것처럼 보인다. 그녀의 프로젝트는 아마 _HyperCard_에서 한 시간 안에 만들 수 있을 거라고 나는 꽤 확신하지만, _HyperCard_는 존재하지 않는다. 당연히 그녀 같은 초보자는 LLM으로 향할 것이다. 다른 선택지가 무엇이 있겠는가?
하지만 나는 한 가지를 지적하고 싶다. “바이브 코딩”으로는 HyperCard 등장 이후 우리가 봤던 것 같은 캄브리아기 대폭발의 새로운 생명체 출현은 보이지 않는다.
자, 나는 자연어를 프로그래밍 언어로 사용하는 함정과 늪에 대해 꽤 많은 시간을 들여 이야기했다. 간단한 도구를 쉽게 만들고 나면, 더 고급 기술을 시도하면서 우리가 프로그래밍에 대해 얼마나 모르는지 금세 깨닫게 된다. 어떤 장벽이 있고, 그 너머에서는 오히려 개발이 더 어려워지는 것처럼 보인다.
이 문제는 이곳과 저곳, 그리고 또 다른 곳에서 오랫동안 많은 사람들에 의해 다뤄져 왔다.
_ThinkTank_로 유명한 Dave Winer도 이 문제에 대한 생각을 남겼다. “_HyperCard_도, COBOL도 이런 식으로 팔렸다. 영어로 시스템에 원하는 것을 말하면 시스템이 그것을 만들어 줄 거라는 식이었다. 문제는 그 프로그래밍 언어들이, 프로그래밍을 전혀 모르는 사람의 눈에는 겉모습만 영어처럼 보였을 뿐이라는 점이다. 일단 들어가 보면, 결국 프로그래밍이었다.” 맞는 말이다.
1988년 2월 _Compute Magazine_에서 Thornburg는 HyperCard 리뷰를 마무리하며 이렇게 썼다. “현재 내 생각으로는 _HyperCard_가 Mac용 애플리케이션 제작의 장벽을 상당히 낮추긴 하지만, 여전히 어떤 프로그래밍 작업에나 필요한 규율과 계획은 요구한다.” 공정한 평가다.
Edsger W. Dijkstra도 자연어를 프로그래밍 언어로 쓰는 문제에 대해 생각이 있었다. 그는 이런 추구에 대해 이렇게 말했다. “모든 것을 다 말하고 나면, 우리가 모국어를 사용할 때 느끼는 ‘자연스러움’이라는 것은 결국, 그 말로 진술을 만들었을 때 그 진술의 헛소리성이 명백하지 않다는 이유로 쉽게 말할 수 있다는 데로 귀결된다.”
맞는 말이다. 다른 인간에게 우리가 원하는 것을 설명하는 것조차 어려울 때가 많으니, 컴퓨터에게야 더 말할 것도 없다. 인간은 말과 행동 양쪽에서 걸어 다니는 모순 그 자체니까.
괜찮다면, 나는 이 모든 것에 대해 내 대담한 반론을 제시하고 싶다.
그래서 뭐? 이런 언어들이 “진지한” 프로그래밍을 하기엔 수학적으로 충분히 엄밀하지 않다면?
그래서 뭐? 확장하기 어렵다면?
그래서 뭐? 우리가 가끔 영어 비슷한 함정에 빠진다면?
그래서 뭐? 이런 도구를 쓰면서 “나쁜” (Dijkstra의 표현을 빌리자면) 습관이 생기고, 나중에 고치기 어렵다면?
나는 순진하지 않다. HyperTalk로 원자로를 돌리지는 않을 것이다. 하지만 프로그래밍의 “순수성” 운동들이 취미 수준의 인구를 배제해 온 것도 걱정된다.
수천 명의 사람들이 _HyperCard_에서 수천 개의 스택을 만들었다. 거기서 기업도 태어났다. 일도 실제로 이루어졌다. 프로그래머가 아닌 사람들이 자신이나 다른 사람을 돕는 소프트웨어를 만들었다. 프로그래밍의 핵심 목적이 사람들의 문제 해결을 돕는 것이라면, 그게 바로 전부 아닌가? _HyperCard_와 HyperTalk는 우리의 컴퓨터가 상자에서 꺼내자마자 기본으로 해야 하는 일의 새로운 기준선이 되었어야 했다.
이것이 당신이 생각하는 노코드의 낙원이라면, 나는 당신을 막지 않겠다. _함께하진 않겠지만,_ 막지는 않겠다.
대형 소매 광고 부서에서 일하던 한 Photoshop 아티스트의 사례가 있다. 그는 수차례 시도했지만 프로그래밍을 전혀 이해하지 못했다. 그런데 바로 AppleScript의 영어 비슷한 언어 덕분에 프로그래밍의 원리와 구조가 마침내 “딱 맞아떨어졌다.” 그는 이제 거의 20년째 전문 iOS 개발자로 일하고 있다. 당신은 아마 “그 신비한 인물이 대체 누구지?!” 하고 손톱을 물어뜯고 있지는 않을 것이다. 그건 나였다.
AppleScript를 처음 접한 경험과, 지금 내가 iOS 엔지니어라는 직업을 갖게 된 것 사이에는 직접적인 연결선, 음모론 코르크보드 위의 단 하나의 붉은 실이 있다. 내가 만든 AppleScript 도구들로 사람들의 일이 조금이라도 쉬워지는 모습을 보는 것은 невероят히 큰 만족이었다. 그 이점은 눈에 보였고 측정 가능했다. 내가 만든 것은 어떤 “정통” 애플리케이션 못지않게 진짜였다.
AppleScript를 넘어설 만큼 성장했을 때, 나는 다음 단계로 옮겨갔다. 내가 배운 나쁜 습관이 무엇이든, 나는 그것을 다시 고쳤다. 이것이 소프트웨어 공학의 깨달음으로 가는 어려운 길이었을까? 아마도 그랬을 것이다. 하지만 그것은 내 길이었고, 나를 반쯤 만나 주려 했던 도구들 덕분에 가능했다.
나는 모두가 반드시 _HyperCard_를 써봐야 한다고 생각한다. 하지만 아마 당신이 생각하는 이유 때문은 아닐 것이다. _HyperCard_가 가장 끈질긴 레트로 애호가를 제외하고는 유용한 일상 도구가 될 수 있다고 나는 착각하지 않는다. 다른 레트로 소프트웨어와 마찬가지로, 자신을 위해 무언가를 만들고 그것이 유용하다면 훌륭하다. 하지만 하이퍼텍스트 전쟁은 브라우저가 이겼다. 그걸로 끝이다.
나는 모든 긍정적 리뷰를 인용할 수 있다. 모든 기능을 열거할 수 있다. 움직이는 스택을 보여줄 수도 있다. 그리고 당신이 어깨를 으쓱한다고 해도 틀린 게 아니다. 이해한다. 당신은 세상 물정 아는 사람이다. 이미 다 본 것이다.
하지만 느껴본 적은 없을 것이라고 나는 생각한다. _HyperCard_는 만져봐야 이해된다. 그러니 해보라. 카드 몇 장을 만들고, 작은 스택도 하나 만들어 보라. 그리고 _HyperCard_의 유동성이 인간 표현의 유동성과 얼마나 잘 맞아떨어지는지 느껴보라. 아이디어가 얼마나 쉽게 현실이 되는지 느껴보라. 아름다운 것을 하나 만들어 보라.
그리고 전부 버려라.
그다음.
그다음!
그다음에야 당신은 그것의 천재성을 이해하는 유일한 방법이, 그것을 빼앗기는 것이라는 사실을 알게 될 것이다.
다시 현재로 돌아와서, 왜 20GB짜리 애플리케이션이 이 1MB짜리 괴물 같은 소프트웨어만큼의 유연성조차 감당하지 못하는지 의아해질 때, 그때 이해하게 될 것이다. “왜 나는 이걸 바꿀 수 없지? 왜 내 것으로 만들 수 없지?” 그런 질문들이 날마다 당신을 열두 번씩 작은 상처로 베어, 결국 상처 조직밖에 남지 않을 때, 그때 이해하게 될 것이다.
나는 당신이 마음 깊은 곳에서 “상황은 더 나아질 수 있다”는 믿음을 갖고 있지 않다면 이 블로그를 읽고 있지 않을 거라고 생각한다. _HyperCard_는 그 믿음을 뒷받침하는 구체적 증거다. 그리고 그것은 “1984” 광고에서 _정확히 같은 “상황은 더 나아질 수 있다”는 확신_을 외쳤던 그 회사에 의해 만들어지고 죽임당했다. Apple은 혁명을 외쳤다.
나는 다음 혁명을 외친다.
0:00
/0:22
내 최종 “To Do” 스택. 책의 내용을 넘어서, 크고 애니메이션되는 일일 탭(32x32px 최대 아이콘 크기를 넘기 때문에 _HyperCard_의 경계를 탐색하는 까다로운 작업이었다)과 검색 필드를 만들었다.
이번에는 작업 환경을 꾸리는 데 꽤 애를 먹었다. 가장 큰 걸림돌은 처음에는 Mac 환경 설정을 아주 쉽게 만들어 줬던 _Basilisk II_가 Windows 타이밍 버그를 가지고 있어서 HyperCard 애니메이션을 쓸 수 없을 정도로 느리게 만든다는 점이었다.
_Mini vMac_은 _HyperCard_와는 아주 잘 맞고 체감상도 매우 경쾌했지만, 2GB가 넘는 디스크를 처리하지 못했다. (나는 Basilisk II용으로 20GB 하드 드라이브를 만들어 둔 상태였다.) 그래서 Mini vMac 안에서 새 디스크 이미지를 만들려고 했는데, 이상하게도 여러 디스크를 쓰는 설치는 “작동”하긴 하지만, 설치 과정에서 다음 디스크를 “받아들이기” 위해 시스템이 처음 본 디스크를 꺼내 버리는 문제가 있었다. 그런데 그 디스크가 바로 내가 운영체제를 설치하려던 디스크였으니, 전체 작업은 코미디 같은 연쇄 사고가 되어버렸다. 결국 _Mini vMac_에서 쓸 2GB 디스크를 만들기 위해 다시 _Basilisk II_로 돌아가야 했다.
이건 사실 완벽하게 확실한 방법이 없다. _HyperCard_의 스택 포맷은 리버스 엔지니어링되었고, 플랫폼을 되살리려는 몇몇 현대적 시도들이 사후적으로 호환성을 만들어 왔다. 스택을 현대 플랫폼으로 가져오는 것도 가능하고, HTML로 변환하는 것도 가능하다. 이 과정에는 많은 예외 상황과 깨진 부분이 생길 것이지만, 그 스택이 멋지다면 그럴 가치가 있다. 당신, 멋진 스택을 만들었지? 그렇지?! (다만 이 중 어느 것도 AppleScript의 강을 건너게 해주진 않을 것 같다.)
그 “열린” 파일 포맷은 결국 실현되지 않은 것 같다.
HyperCard 1주년 포스터. 출처 링크.
파스타와 Batman 사이에서 __당신__은 어떤 연상을 하는가?
MacWorld 1987 출처. 메시지는 조금 난해하지만 그림은 귀엽다. 공정하게 말하자면, __HyperCard__라는 개념 자체가 아직 인터넷을 접해보지 못한 대중에게는 팔기 어려운 상품이다. 이미지는 Smithsonian 소장품에서..
HyperCard를 발표하는 치즈 같은 “뉴스캐스트” 홍보 영상. 솔직히 말해, 나는 이런 자기과장적인 연출에 대한 향수는 없다. https://archive.org/details/Hypercard-Introduction