Apple만이 사랑받던 비주얼 프로그래밍 환경을 만들었다가 가장 인기 있을 때 없애 버린 것은 아니었다.
development Apple만이 사랑받던 비주얼 프로그래밍 환경을 만들었다가 가장 인기 있을 때 없애 버린 것은 아니었다.
내 마음을 깊이 파고들어 정말로 스스로를 돌아보면, 나는 Bill Gates나 Elon Musk 같은 사람들이 가진 어떤 것을 그저 갖고 있지 않다는 결론에 이른다. 우리 대부분은 누군가의 삶 하나 둘쯤 건드렸고, 누군가의 존재를 조금 더 즐겁게 만드는 데 도움을 주었으며, 그런 작은 기적들에 대해 우주에 감사할 수 있다는 사실만으로도 만족한다고 생각한다.
어떤 사람들은 영향력, 권력, 부를 획득하는 데 한계가 없는 듯 보인다. 그들에게는 단지 하나의 산업을 이끄는 것만으로는 충분하지 않다. 그들은 그 산업 그 자체가 되어야 한다. 이 제로섬 게임에서 그들의 갈망에는 상한선이 없다.
Musk가 최초의(이 단어를 쓰려니 목이 메인다) trillionaire 가 되기 전, Gates는 수십 년 동안 세계에서 가장 부유한 사람이었다. Musk처럼 그도 1999년에 “순자산이 $100 billion을 넘은 첫 번째 인물”이라는 특정 금전적 이정표를 넘어섰는데, 이는 2026년 기준 화폐 가치로 약 $200B에 해당한다. 그가 어떻게 그 돈을 벌었고 또 그것으로 무엇을 했는지는 수많은 다큐멘터리, 책, 영화, 인터뷰, 증언 녹취, 그리고 몹시 불길한 소문들의 주제가 되어 왔다. 적어도 오늘 이야기와 관련해 언론이 한 가지에는 동의할 수 있다고 본다. Bill Gates는 개인용 컴퓨팅 지형 전체를 손에 넣겠다고 이를 갈고 있었다.
그는 실제로 그렇게 말했다. 큰 소리로, 무대 위에서, 업계 관계자들 앞에서, 언론이 보는 가운데. Jacqui Morby는 The Computer Chronicles 에서 그 일화를 회상했다. “Gary (Kildall)가 (Rosen Forum 패널 토론에서) 일어나 CP/M에 대한 자신의 계획과 회사의 향방에 대해 이야기한 뒤, ‘글쎄요, 이건 아주 큰 시장이고, 많은 회사가 들어설 자리가 있습니다’라고 말했어요. 그러자 Bill Gates가 끼어들며 말했죠. ‘아니요, 회사는 하나뿐일 겁니다.’”
잠시 Gates와 Kildall의 몸짓을 음미해 보자. 진짜 상어와 먹잇감 같은 분위기 아닌가?
그는 혁신적인 것을 만드는 데 특별히 관심이 있었던 것 같지 않다. 오히려 다른 이들의 혁신에 대해 Microsoft식 대응을 반드시 만들어야 한다는 쪽에 더 가까웠다. 원래 Macintosh용 소프트웨어를 개발하기 위해 Apple과 협력하던 시절, Andy Hertzfeld는 Gates가 Microsoft가 만들던 비즈니스 애플리케이션과는 사실상 별 관련도 없는 시스템 세부사항을 집요하게 캐물었던 일화를 회상했다. 그리고 얼마 지나지 않아 Windows 1.0이 출시되었고, 이는 Steve Jobs를 대단히 좌절하게 만들었다. Jobs는 Microsoft의 아이디어 “가져가기” 때문에 뒤통수를 맞았다고 느낀 마지막 인물이 아니었다.
왼쪽은 Macintosh System 1.0이고, Windows 1.0은 창을 “바둑판식 배치”만 할 수 있었다. Windows 2에 이르러 Mac의 겹쳐지고 크기 조절 가능한 창을 갖게 되었고, 그 결과 Apple CEO John Sculley는 Microsoft를 상대로 소송을 제기했다. 다만 그보다 앞서 Microsoft가 Macintosh 지원을 전면 철수하겠다고 압박하자, Apple은 Macintosh의 “시각적 표시물” 사용 권리를 허용해 준 바 있었다.
Gates가 구사한 또 다른 전술은 흡수였다. 없는 장난감을 빨리 손에 넣는 검증된 지름길이다. Alan Cooper의 이야기를 보자. 우연히도 그가 비주얼 애플리케이션 빌더의 아이디어를 “문득 떠올린” 시점은 HyperCard 가 데뷔한 1987년이었다. Microsoft가 DLL, 즉 동적 링크 라이브러리를 채택하겠다고 발표한 것이 계기였는데, 이는 원하는 사람 누구나 핵심 운영체제 기능에 손쉽게 접근할 수 있게 해 주었다. Cooper는 이것을 기업용 DOS 비주얼 셸의 꿈을 구축할 수 있는 일종의 “구성 세트”를 세울 독특한 기반으로 보았다. 기본 Windows 셸이 마음에 안 드는가? 직접 만들면 된다!
Microsoft 엔지니어 Gabe Newell은 당시 Tripod 라고 불리던 이 구성 세트의 데모에 크게 감탄했고, Gates에게 보여 줄 자리를 주선했다. Ryan Lucas의 훌륭한 글 “Something Pretty Right” 에서 인용하면.
“그는 완전히 충격을 받았어요. 그런 건 한 번도 본 적이 없었죠.” Cooper는 Gates의 반응을 이렇게 회상한다. “어느 순간 그는 수행원들을 돌아보며 ‘왜 우리는 이런 걸 못 하는 거지?’라고 물었어요.”
“왜 우리는 이런 걸 못 하는 거지?”라는 표현은, 내 생각에 소파에 앉아 심리 분석하는 입장에서는 꽤 많은 걸 드러낸다. 이 대사를 배우 1,000명에게 주면, 좌절과 동경 사이의 긴장을 저마다 다르게 조율한 1,000개의 연기가 나올 것이다. 아주 부유한 사람™으로서 Gates가 원하지만 가질 수 없었던 것은 없었다. 남에게 돈을 주고 RPG 캐릭터를 대신 육성시키는 사람처럼, US$1M과 계약서 하나 뒤에 Tripod (이후 Ruby 로 개명됨)는 그의 것이 되었다.
Cooper는 HyperCard 가 Tripod 제작에 아무 영향도 주지 않았다고 주장하지만, Gates는 분명히 그것을 떠올리고 있었다. 그는 BYTE Magazine 1989년 10월호에 실린 “The 25th Birthday of BASIC”이라는 글에서 이렇게 썼다. (Visual Basic 은 1991년에 데뷔한다.)
HyperCard provides an interesting example of this combination of visual and more standard procedural programming. (HyperTalk) lets you create procedures that relate to the card and the information that the card links with. . . it forms an understandable intermediate step between procedural and object-level programming.
- Bill Gates, for BYTE Magazine
Ruby 는 Tripod 와는 겨우 스쳐 지나가는 유사성만 남긴 채 다른 무언가로 재구성되었다. 맞춤형 스크립트 언어는 BASIC의 변형으로 대체되었고, 프로그램의 목표도 더 이상 Microsoft DLL 위에 셸을 만드는 것이 아니라 Microsoft의 자체 셸인 Windows 3.0용 애플리케이션을 만드는 것이 되었다. 그렇게 Visual Basic 이 탄생했다. 논쟁의 여지는 있겠지만, 이것은 Cooper의 원래 비전보다 더 깊은 제품이었다. 인정할 건 인정하자. Gates는 Cooper 자신도 보지 못한 잠재력을 보았다.
하지만 돌이켜보면, Cooper가 가장 인상 깊게 본 것은 Gates의 전략적 비전이었다. “나는 꽤 멋진 소프트웨어를 썼다고 생각했어요.” Cooper는 말했다. “하지만 그것이 오늘날 Microsoft 성공의 핵심에 있는 프로그래밍 제어판이 될 거라고는 상상도 못 했죠. . . 그러니까 Bill Gates가 그런 Bill Gates인 겁니다.”
- GO TO, by Steve Lohr
얼마 전 나는 Apple의 HyperCard 를 파고들었다. Visual Basic 은 Microsoft의 관점에서 이와 비슷한 1사 독점 비주얼 프로그래밍 해법을 들여다볼 흥미로운 기회를 제공한다. HyperCard 처럼 Visual Basic 에도 전용 잡지가 있었고, Microsoft가 2008년에 지원을 중단한 한참 뒤까지도 수많은 개발자들에게 영감을 주었다. 무려 2023년에도 Microsoft는 “classic” Visual Basic 지원 계획에 대해 공식 입장을 내야 했다. 이 언어는 대규모의 맞춤형 레거시 애플리케이션들을 여전히 살아 있게 만들고 있는데, 이건 HyperCard 가 주장할 수 없는 부분이다.
당시의 Microsoft 대 Apple 전쟁은 거의 편을 들도록 강요하는 분위기였지만, 사실은 양쪽 모두 서로에게서 배울 점이 있었다.
가격 정보의 상당 부분은 _Visual Basic_ 계열에 대한 이 훌륭한 정리 글에서 가져왔다.
DOSBox-X 2026.01.02, Windows x64 빌드.
Windows 3.1, 기본 설치
mem 명령은 총 RAM을 262,144K로 보고하지만, Free는 1,609K만 보고한다. 오늘 쓰기에는 충분하지만, 16-bit Windows라면 2MB가 아니라 4MB는 인식할 수 있어야 한다.Visual Basic 3.0
60320 KB로 보고됨Visual Basic 3.0은 이 계열에서 마지막 순수 16-bit 애플리케이션이었고, 강력한 데이터베이스 기능을 처음 포함한 버전이기도 하다. 제품의 진정한 잠재력이 여기서 열렸다. 이 OS/애플리케이션 조합이야말로 이 블로그의 분위기와 훨씬 잘 맞는다고 느낀다.
배울 것이 많다. HyperCard 를 공부했을 때, 나를 기다리고 있는 1,000페이지짜리 책을 언급한 적이 있다. Visual Basic 은 무려 3,000페이지를 제공한다. 여기에 방대한 3rd party 출판물까지 더하면, 그 자체로 하나의 산업이다.
최근 또 한 해를 먹고 하늘의 거대한 Blue Screen을 향해 한 걸음 더 다가간 사람으로서, 초침이 한 번 움직일 때마다 내 뼈가 살짝 덜컹거리는 기분이다. 이런 큰 프로젝트를 할 때면 얼마나 빨리 감을 잡을 수 있을지를 생각해야 한다. 뭐, 당시 학습서들의 기질을 생각하면 제대로 된 첫 질문은 이거겠지. “나는 얼마나 멍청한가?”
블로그 글에서 나는 스스로를 “big dummy”라고 부르곤 하고, 그 주장에는 지금도 동의한다. 하지만 남이 나를 멍청하다고 부르는 건 싫다. 더 복잡한 자료도 소화할 수는 있지만, 아까 말했듯 시간이 많지 않다. Visual Basic 을 얼마나 빨리 배울 수 있을까?
그건 흡수 불가능할 정도로 빠른데 .
잠을 안 자면 가능하려나?
월요일이 되면 다 잊어버릴 것 같다.
화요일쯤에도 마찬가지일 테고.
“Proglaming”은 재밌어 보이지만, 일주일도 여전히 내 속도에는 너무 빠르다.
조금 가까워지고 있다.
완벽하다. 늙은이가 따라가기엔 충분히 느리고, 양로원에 비자발적으로 입소하기 전에 여유 있게 끝내기엔 충분히 빠르다. 내가 40년만 덜 늦었어도 “나는 big dummy다”와 “이걸 빨리 배우고 싶다”를 결합해 직접 출판 시장에 뛰어들었을 것이다.
Gary Larson에게 줄 로열티가 이 시리즈 수익의 100%를 먹어치울 것이다.
내가 마지막으로 Windows 3.1을 만진 지도 꽤 오래됐다. 웃긴 건, 그것에 대한 내 기억이 오늘 직접 써 본 경험과 잘 맞지 않는다는 점이다. 기억 속에서는 훨씬 더 못생겼다. 물론 지금도 터무니없이 큰 제목 표시줄 때문에 고생하긴 하는데, 정보나 효용은 별로 제공하지 않는다. 그래도 그 (VGA mode) powder blue는 마음에 든다.
어쩌면 영감은 부족할지 몰라도 제법 말쑥하다. OS/2의 Presentation Manager를 위해 Microsoft와 IBM이 함께 작업한 결과물이기 때문이다. 이건 Windows 2.0보다도 앞선다. 양사의 “Joint Development Agreement”는 두 회사 사이에 공유된 코드를 양쪽이 라이선스 비용 없이 꽤 폭넓게 사용할 수 있게 해 주었다. 나는 법에 대해 조금도 아는 바가 없지만, 문서에는 일부 이렇게 적혀 있다.
This Agreement shall in no way precludeeither party from independently developing or acquiring materialsand programs which are competitive, irrespective of their similarities, with the Code and Documentation or from making similar arrangements with others.
그 덕분에 Windows 1.0의 실패 이후 Windows 2와 3는 꽤 멋진 단장을 할 수 있었다. 처음에는 Microsoft조차 자사 개발자들을 설득해 Windows 애플리케이션을 만들게 하는 데 어려움을 겪었다. Windows 앱을 쉽게 만들게 해 줄 뿐 아니라, 그 과정마저 즐거운 경험이 되게 할 수 있는 도구를 손에 넣었을 때 Gates가 얼마나 안도했을지 상상할 수 있다.
Visual Basic 에 들어가자마자 드는 첫인상은 이거다. “이건 나도 하겠다.”
점들은 스냅 투 그리드를 이룬다.
접근하기 쉬워 보인다. 툴바의 모든 버튼이 뭘 하는지 설명할 수는 없지만, 기본적인 것들 중 일부는 HyperCard 에서처럼 알아보기 쉽다. 텍스트 필드 같은 컨트롤을 추가하는 것은 더블클릭 한 번이면 된다. 선택된 컨트롤의 특성을 조정하는 “Properties” 패널은 직관적으로 이해되는데, 이건 HyperCard 에는 없는 것이다. 컨트롤에 코드를 붙이는 것도 창 안의 해당 인스턴스를 더블클릭하는 것만큼 간단하다.
“Properties”는 문맥을 인식해서, 선택한 객체에서 조정 가능한 것만 보여 준다. 업계는 대체로 이런 문맥 기반 접근을 버렸다. 왜일까? PageMaker 는 제어 패널에서 그런 방향으로 기울고 있었는데, InDesign 은 곧바로 그걸 버리고 현재 문서 문맥과 무관한 것들까지도 늘 떠 있는 지속형 컨트롤을 택했다. 예를 들어 Affinity 에서 현재 문서에 텍스트 상자조차 없는데 왜 화면에 텍스트 커닝 도구가 있어야 하는가? Figma, Apple의 Pages 같은 도구는 문맥의 불씨를 살려 둔 것 같아서 보기 좋다. “프로들은 모든 도구가 항상 화면에 떠 있길 원합니다.”라고 어떤 UX 컨설턴트가 아주 진지한 얼굴로 말하더라.
툴바는 좀 더 잘 정리될 필요가 있고, 버튼을 사랑하는 Microsoft를 놀리는 그 밈 이미지를 향해 손짓하기 시작한다. 가능한 많은 기능을 쑤셔 넣기 위한 만능 수단으로 이 UI 은유에 꽤 의존한 것이 분명하다. 때로는 혼란스럽다. (“picture box”가 있는데 또 “images”도 왜 있지?) 하지만 이 프로그램 버전과 이 운영체제 조합에서는 아직 완전히 통제 불능까지는 아니다.
“음, 사실 Comic Sans는 Windows 95 이후에 도입됐습니다.” 붉게 물든 항목들은 “Professional Edition”에 포함된다.
오늘은 컨트롤과 그것들과 상호작용하는 방법에 대해 속도를 올리고 있다. Visual Basic 의 접근 방식에서 좋은 점들을 생각해 보자.
나는 버튼과 슬라이더 같은 UI 요소를 위한 키보드 단축키를 빠르게 좋아하게 되고 있다. Visual Basic 은 화면상의 컨트롤에 키보드 후크를 붙이는 일을 엄청나게 쉽게 만든다. 헷갈리게도 “caption”이라는 이름이 붙은 속성에서 버튼 라벨에 &만 넣어 주면, 그 다음 문자가 Alt + 문자 조합으로 단축키가 된다. 따라서 “Exit” 버튼의 “caption”이 &Exit라면 _E_xit처럼 보이고 Alt + E가 마우스로 그 버튼을 클릭한 것과 똑같이 동작한다.
내가 “똑같이”라고 할 때는 정말 똑같다는 뜻이다. 버튼에 내장된 click() 메서드가 호출되며, 마우스로 눌렀을 때와 동일하다. 이런 상호작용에서 키보드와 마우스 사이에 제어 로직을 둘로 갈라서 걱정할 필요가 없다.
네안데르탈인 교육하기
“정보를 출력하고 입력하는 과정을 프로그램의 _user interface_ 측면이라고 부른다.”
이어서 앞으로 닥쳐올 약간 어긋난 일들의 아뮤즈부슈가 제공된다. 체크박스와 라디오 버튼은 둘 다 켜짐/꺼짐 상태를 가지는데, 체크박스는 여러 개가 동시에 켜지거나 꺼질 수 있는 반면, 한 묶음의 라디오 버튼에서는 오직 하나만 켜질 수 있다. 그런데 이 컨트롤들을 프로그래밍할 때 체크박스는 체크 여부를 나타내기 위해 0 또는 1을 반환한다. 라디오 버튼은 각 선택지마다 True 또는 False 불리언을 반환한다. 일단은 이것을 “나로 하여금 의심스러운 옆눈질을 하게 만드는 것들” 폴더에 넣어 두자.
그래, 딱 그런 식으로.
며칠 함께 보내고 나니, 내장 텍스트 에디터가 날 미치게 만들고 있다. 이것은 Visual Basic 이 HyperCard 와 공유하는 “기능”인데, 둘 다 별로다. 자동완성 부재는 Visual Basic 5 에서야 등장하는 도구이므로 “아직 발명되지 않은 무언가”라고 봐 줄 수 있다. 하지만 들여쓰기 보조와 줄바꿈 부재는 용서할 수 없다. 둘 다 당시 워드 프로세서에서는 이미 흔한 기능이었다. Microsoft는 텍스트 에디터로서 절대적 최소치보다 아주 조금 더만 제공했다.
코드를 깔끔하고 읽기 좋게 유지하려면 내가 상당하고도 꾸준한 노력을 들여야 한다. 나에겐 그게 쉽게 되지 않는다. 자동 대문자화(Basic은 대소문자를 구분하지 않지만)와 언어 키워드 색상 표시는 고맙지만, 커서를 다시 배치하자마자 구문을 검사하고 한 줄 텍스트 형식을 잡아 버리는 건 성가시다.
미완성 줄은 인터프리터 문제를 경고하는 모달 대화상자를 띄운다. 커서를 잠깐 위아래로 움직이는 것만으로도 쉽게 발동된다. 그 끊임없는 방해 속에서는 나중에 세부사항을 채워 넣기 위해 코드 블록의 뼈대를 먼저 스케치하는 일이 너무 불편하다. 파서를 필요할 때만 직접 실행할 수 있으면 좋았을 텐데.
내가 “Dim”을 “Dum”으로 잘못 쳤더니, 계속 진행하기 전에 그 문제부터 처리하도록 강요받는다. 또한 형편없는 창 관리가 얼마나 시각적 혼란을 만드는지도 느낄 수 있다. 저 창들 중 상당수는 _Visual Basic_ 의 일부조차 아니다.
오늘은 마우스와 마우스 이벤트를 처리하는 법을 배우고 있다. 프로그래밍 관점에서는 꽤 기본적인 내용이다. 코드 에디터의 좋은 점 하나는, 상단 툴바의 풀다운 메뉴가 선택된 UI 요소에 대해 가능한 모든 함수를 보여 준다는 것이다. 함수의 정확한 이름과 철자를 기억하려 애쓸 필요가 없다. 편집하고 싶은 것을 골라 바로 시작하면 된다.
이론적으로 흥미로운 설정 하나는 요소의 기본 측정 단위다. 지금까지 나는 “twips”라는 것을 들어 본 적이 없었다. 이것은 “포인트의 20분의 1”이다. 포인트가 1인치당 72이므로, 1인치에는 1,440 twips가 있다. Windows는 이것을 장치 독립적인 표준 측정 단위로 사용했다. 화면에서는 픽셀로 변환되었고, 인쇄 시에는 프린터 해상도로 변환되었다. Visual Basic 에서 설계한 어떤 form이든 간단한 Basic 호출 하나로 프린터에 보낼 수 있으며, 화면 해상도가 아니라 프린터 해상도로 인쇄된다.
하지만 가장 멋진 묘기는 “edit and continue”다. 프로그램이 컴파일되는 것이 아니라 지속적으로 인터프리트되기 때문에, 우리는 프로그램을 실행하고 멈춘 뒤 코드를 수정하고 다시 이어서 실시간 실행을 계속할 수 있다. 짜증 나는 버그에 대한 해결책을 반복적으로 다듬기엔 정말 유용하다. Microsoft에 충성하는 사람들은 사실상 이런 세상 없이 살아 본 적이 없다. Apple 쪽 사람들은 이런 매혹적인 열매가 몇 번이나 눈앞에 매달렸다가 약속을 완전히 실현해 주지는 않는 경험을 했다. 나는 이 기능이 마음에 든다.
네안데르탈인 교육하기
“(스스로 그림을 그릴 재능이 없다고 생각한다면), 여러 판매처에서 전문가용 그림을 구입할 수 있다. 이런 제3자 그림 제품을 ‘clip art’라고 부른다.”
WIMP 애플리케이션을 만드는 데에는 그 약어 중 “M” 부분도 채워 넣어야 한다. 오늘은 “Menu Design Window”를 사용해 메뉴를 만드는 법을 배운다. 이 도구는 유능하긴 하지만 조금 우아하진 않다.
처음에는 키보드에서 손을 떼지 않고도 애플리케이션의 메뉴 구조 개요를 대략적으로 빠르게 짤 수 있다. 마우스 없이 할 수 있다는 건 언제나 반갑다. 메뉴 항목을 입력하고 RETURN, 다음 항목을 입력하고 RETURN, 또 다음 항목을 입력하는 식이다. 그다음 화면의 화살표 도구로 요소를 들여쓰기하거나 재배치하면서 구조를 입힌다. 아쉽게도 메뉴 항목 입력 시점에 TAB으로 들여쓰기할 수는 없다. 계층은 나중에 별도의 단계에서 설정해야 한다.
나는 “Ogg” 사무용 애플리케이션 시리즈로 세상을 뒤흔들 계획이다. 사람들이 다시 워드 프로세서에 US$199를 내기 시작하도록 설득할 수만 있다면 말이다.
실망스러운 부재 중 하나는 메뉴 요소들 사이의 관계성이다. 하위 메뉴 항목을 가진 메뉴 항목을 옮겨도 그 하위 메뉴들은 함께 이동하지 않는다. ThinkTank 식의 “아웃라이너” 편집은 여기 없다. 폼 컨트롤에서는 가능한 다중 선택 그룹 편집도 메뉴 항목에는 적용되지 않는다. 우리가 얻는 것은 느리고, 참을성 있게, 하나씩 수정하는 방식뿐이다. 공정하게 말하자면 메뉴는 프로그래밍으로 생성할 수 있고, 여러 면에서 그 편이 솔직히 더 나을지도 모른다. 다만 그 경우 Visual Basic 의 “Visual”에서 조금 멀어지지 않나?
디자인 창은 또한 세로 편집을 가로 보기 안에 억지로 밀어 넣는다. 이것 역시 “나로 하여금 의심스러운 옆눈질을 하게 만드는 것들”이다. 스크린샷 속 예시는 3단계 메뉴인데, 나는 그 가로 공간을 전혀 채우지도 못하고 있다. 낭비되는 화면 공간이다. 더 짜증 나는 건 메뉴 디자인 창이 크기 조절도 안 된다 는 사실이다. 업계의 많은 사람들이 이제는 체화했듯, 에디터 뷰는 주요 콘텐츠를 전면 중앙에 두고, 다듬는 요소들은 보조 역할을 맡겨야 한다. 메뉴 항목 속성은 창의 오른쪽을 채우는 편이 훨씬 낫고, 메뉴 자체는 왼쪽에서 세로로 숨을 쉴 여지를 가졌어야 한다.
이건 아마 세월이 지나며 나아졌을 것이지만, 제품의 3번째 버전치고는 눈에 띄게 덜 익었다. “괜찮긴 한데, 버전 3이면 더 나았어야지”는 앞으로 계속 반복될 테마다.
이제 일주일째 이걸 붙잡고 있으니, 비주얼 프로그래밍에 대해 HyperCard 와 Visual Basic 이 각각 취하는 접근 각도가 더 선명하게 보이기 시작한다. 처음에는 피상적 유사성 때문에 둘 사이에 더 직접적인 동등성이 있으리라 예상했다. 둘 다 인터페이스 설계를 위한 비주얼 툴킷을 제공한다. 둘 다 각 플랫폼의 핵심 언어보다 더 단순한 언어를 사용한다. 둘 다 진정한 “object oriented”는 아니다. (그게 당신에게 중요하다면.) 둘 다 크고 열정적인 추종자를 모은 뒤 결국 죽임을 당했다.
툴바만 단순히 비교해 봐도 두 접근법의 철학적 차이가 드러난다. HyperCard 툴박스의 대부분은 그림 그리기에 할당되어 있고, 컨트롤은 버튼과 텍스트 필드로 축소되어 있다. 그렇게 제한된 UI 컨트롤 집합으로 얼마나 많은 것을 해내는지 나는 여전히 놀랍다.
반면 Microsoft는 애플리케이션에 추가하고 싶을 법한 모든 것 각각에 대해 툴바 버튼을 제공한다. 둘은 정반대 접근을 취한다. HyperCard 에서라면 내가 일반 버튼을 하나 추가하고, 시스템 파일 브라우저를 호출하는 스크립트를 붙일 텐데, Visual Basic 은 미리 만들어진 파일 브라우저 컨트롤을 내 앱으로 끌어다 놓게 해 준다.
나는 “컨트롤을 정의할 사각형을 끌어내는” Visual Basic 의 접근이 더 좋다. 특히 버튼과 텍스트 필드에서 그렇다. UX 측면에서 더 현대적으로 느껴진다. HyperCard 는 풀다운 메뉴를 통해서만 컨트롤을 추가하게 하고, 그 뒤 시각적 표시도 거의 없는 상태에서 버튼 모서리를 끌어 새 크기로 바꾸어야 한다. 의외로 불편하다.
Visual Basic 은 요소를 위치에 맞춰 스냅시키는 그리드를 제공한다는 점에서도 점수를 얻는다. 그래서 HyperCard 보다 요소 정렬과 크기 맞춤이 훨씬 쉽다. HyperCard 쪽에서는 눈대중을 많이 써야 한다. 그쪽의 그리드는 페인트 모드에서만 작동한다.
그 결과 계산기 같은 레이아웃을 짜는 일은 Visual Basic 에서 훨씬 더 빠르고 쉽다. 그 대가로(?) 역대 모든 Windows 프로그램과 정확히 똑같이 생긴 무언가가 나온다. (물론 데모 계산기는 실제 Windows 계산기와 전혀 닮지 않았지만?)
왼쪽은 _Visual Basic_ 에 포함된 데모 계산기, 오른쪽은 Windows 3.1에 포함된 진짜 계산기다.
오해하지 말자. 기업적 동질성에 맞추는 것이 때로는 정확히 필요한 일일 수 있고, Visual Basic 은 눈 깜짝할 사이에 “전문적으로 보이는” 무언가를 만들어 낼 수 있다. 어쩌면 개성은 없을지 몰라도, Windows 사용자가 보고 신뢰할 수 있는 것을 만들어 준다. 그런 다소 경직된 제약에서 벗어나려면 Visual Basic 에서는 의식적인 노력이 필요하지만, HyperCard 는 거의 미친 듯이 날뛰라고 부추기는 수준이다.
여기서는 완전히 “Basic을 배우는 중” 영역이다. 애플리케이션 자체는 그리 많은 것이 더 있지 않다. 우리의 .exe 파일을 내보내는 패널은 상상 가능한 한 가장 최소한이다. 색상 팔레트도 있는데, 왜 있는지는 완전히 명확하지 않다. 컨트롤 색상은 Properties 팔레트의 자체 팝업 색상 팔레트를 통해 설정할 수 있기 때문이다.
내장 Help 시스템도 칭찬해 두어야겠다. 문맥 인식이면 더 좋았겠지만, 10파운드짜리 매뉴얼을 펼치지 않고도 Windows 안에서 바로 접근 가능한 정보가 터무니없을 정도로 많다.
Help 시스템 역시 곳곳이 하이퍼링크로 연결되어 있어서, 너무 오래 머리를 긁적이게 내버려 두지 않는다.
HyperCard 에는 Balloon Help가 있어서 귀엽고 좋기는 하지만, 빈약하기도 하다. 두세 문장 안에 들어가는 정도의 설명만 얻을 수 있다. 반면 Visual Basic 의 Help 시스템은 코드 샘플과 함께 긴 주제 설명을 제공하고, 검색 가능하며, 북마크도 가능하고(!), 프로그램의 원리를 이해하기 위한 튜토리얼까지 갖추고 있다. 꽤 훌륭하다.
내 학습서의 마지막 주는 make 파일, 데이터베이스 연결, MDI (multiple document interface), DDE (dynamic data exchange), DLL과의 인터페이스 등등의 논의로 급격히 빡세진다. 지금까지 우리는 버리는 장난감 같은 앱만 만들었고, 솔직히 말해 이 책이 이런 더 까다로운 논의에 대비할 수 있도록 내 머리를 잘 준비시켜 주었다는 느낌은 들지 않는다. 제품이 약속했던 단순함에서 꽤 큰 인지적 도약이 필요하다.
요컨대, 나는 간신히 버틸 만큼의 Basic을 배우며 그 리듬과 문법의 감을 잡고는 있지만, 처음 쓰는 사용자 입장에서는 HyperTalk보다 더 압도적으로 느껴진다.
HyperCard 와 Visual Basic 은 각각 600페이지가 넘는 언어 레퍼런스 가이드를 제공한다. Microsoft는 여기에 세 권의 매뉴얼을 더 얹어 총 2,400페이지 이상을 더 던져 준다. Visual Basic 4 에서는 언어 가이드만 1,000페이지를 넘기게 된다. 간결함이야말로 겁쟁이의 미덕이라는 태도였던 것 같다.
언어 레퍼런스 가이드의 길이는 비슷하지만, Microsoft 쪽은 훨씬 더 밀도 높고 건조한 책이다. Apple은 앞의 150페이지를 “도대체 프로그래밍이 뭐지?” 이야기하는 데 쓰고, 뒤의 150페이지는 HyperTalk의 범위를 벗어나는 주제에 할애한다. 언어 자체를 설명하는 데는 날씬한 300페이지 정도만 쓰는 셈이다.
구체적인 예를 좀 보자. HyperCard 에서 버튼 클릭 시 시스템 beep를 세 번 울리는 코드는 이렇다.
on mouseUp
beep 3
end mouseUp
그리고 Visual Basic 3 에서 (겉보기에는) 같은 일을 하는 코드는 이렇다.
Sub btn_BeepThree_Click ()
Dim I
For I = 1 to 3
Beep
Next I
End Sub
전부 털어놓자면, 이 코드는 작동하지 않았다. “Programmer's Guide”에 실린 예제인데도 말이다. 무언가가 세 번의 비프음을 하나로 합쳐 버리고 있다. DOSBox-X 문제일까?
스크립트가 각자의 HyperCard 객체 안에 일종의 “내장” 형태로 들어가 있기 때문에, 우리는 서브루틴 앞에 접두사를 붙여 구분할 필요가 없다. 각각의 스크립트는 자신과 연결된 GUI 객체에 정확히 범위가 한정된다. 객체 지향의 La Croix 같은 것이다. 그 맛의 힌트만 살짝 풍긴다.
HyperCard 의 접근은 가볍게 만지작거리며 놀아 보기에 더 적합하지만, 코드 에디터에서 애플리케이션의 모든 함수를 드러내 준다는 점에서는 Visual Basic 이 우위다. HyperCard 에서는 어떤 객체에 어떤 코드 블록이 들어 있는지 기억해야 하거나, 원하는 코드를 찾기 위해 객체들을 하나씩 뒤져야 한다.
Visual Basic 의 접근은 모든 서브루틴에 고유 이름을 요구한다. 덕분에 객체 간 이벤트를 발동시키는 일은 꽤 단순해진다. 버튼 하나가 다른 버튼을 대리 클릭하게 만들고 싶다면, HyperTalk에서는 이런 식이 될 것이다.
on mouseUp
send "mouseUp" to button "beepButton" of card "someCard"
end mouseUp
가끔은 HyperTalk도 객체 지정자 체인에 dot-syntax를 허용했으면 좋겠다고 생각한다.
Visual Basic 에서는 고유 이름이 붙은 함수를 직접 호출하면 끝이다.
Sub btn_ProxyButton_Click()
btn_BeepThree_Click()
End Sub
HyperTalk가 부드럽고 영어 같은 접근을 취하는 반면, Visual Basic 은 훨씬 더 “프로그래머스럽게” 가는 것을 두려워하지 않는다. HyperTalk 개발자들은 인터프리터를 우회해 특정 목표를 달성하기 위한 정확한 주문을 알아내려다 자기들만의 잡초밭에 빠질 수 있다. 반대로 Visual Basic 개발자들은 금세 메모리 관리, DLL, 배치 파일, make 파일의 세계로 굴러들어갈 수 있다. 둘 다 고통을 느끼지만, 그 고통의 방향은 서로 꽤 직교한다. 어느 쪽을 선호할지는 당신이 어떤 종류의 악마를 잡는 걸 즐기는지에 달렸을지 모른다.
Voyager 소프트웨어 시리즈와 MYST 가 분명히 보여 주듯, HyperCard 로도 매우 전문적인 소프트웨어를 만들 수 있었다. 그렇다 해도 Visual Basic 의 상한선은 훨씬 더 높게 느껴진다. 간단한 예로, Declare 키워드를 사용하면 Windows Kernel (혹은 존재하는 어떤) DLL에 직접 손을 뻗어 호출할 수 있다. 물론 이것이야말로 Alan Cooper가 애초에 이 프로그램을 개발하게 만든 킬러 기능이었다.
Declare Function GetProfileString Lib "Kernel" (ByVal SName$,
> ByVal KName$, ByVal Def$, ByVal Ret$, ByVal Size%) As Integer
... and later we use it like this
Success = GetProfileString(SName$, KName$, "", Ret$, Len(Ret$))
이건 HyperCard 로는 기본 상태에서 불가능하다. Macintosh Toolbox에 그렇게 능숙하게 접근할 수 없기 때문이다. 데이터베이스 데이터도 마찬가지다. Visual Basic 은 dBASE 나 FoxPro 같은 다양한 종류의 데이터를 가져올 유연성을 제공한다. HyperCard 에도 이런 작업을 도와주는 특수 스택이나 XCMDs (plugins)이 있을 수는 있겠지만, 프로그램에 기본 내장된 것은 아니다.
하지만 HyperCard 는 개발자가 별도의 특별한 노력을 하지 않아도 활용할 수 있는 자체 내장 데이터베이스를 무료로 제공한다. 주소록 같은 것을 만드는 일은 카드에 텍스트 필드 몇 개를 추가하는 것만으로 끝난다. 그것들은 기본적으로 데이터베이스의 필드처럼 작동하며, 사용자 데이터 저장/불러오기 같은 동작도 투명하게 처리된다. 검색 같은 기능을 더하려면 몇 단계가 더 필요하지만, 다음과 같은 HyperTalk 명령을 통해 개념적으로는 단순하다.
find string "Ogg"
Visual Basic 은 “Data Manager” 모듈을 제공하며, 이를 통해 애플리케이션의 뼈대로 사용할 간단한 Access 데이터베이스를 만들 수 있다. 이 모든 것은 보조 매뉴얼인 300페이지가 넘는 “Visual Basic 3.0 Professional Features, Book 2”에서 자세히 설명된다. 데이터베이스가 만들어지고 나면, “Data Control” 도구를 사용해 그 레코드와 상호작용하는 일은 직관적이다.
데이터베이스가 제대로 연결되면, 이미지나 텍스트 필드 같은 컨트롤을 데이터베이스 스키마의 해당 필드에 직접 연결할 수 있는데, 이를 “bound controls”라고 부른다. 데이터베이스 위젯 자체가 레코드 사이를 이동하는 버튼을 제공하고, 해당 데이터는 자동으로 연결된 레이아웃 요소에 채워진다.
만약 당신의 데이터베이스 요구가 “둘러보기” 수준에서 끝난다면, 꽤 괜찮다. 하지만 대부분은 그 이상을 원할 것이다. 아마 필드를 추가하거나 검색 질의를 하고 싶을 것이다. 그럴 생각이라면 마음 단단히 먹는 게 좋다. 순식간에 아주 험악해지기 때문이다.
그냥 이렇게만 말하겠다. 책이 300페이지가 넘는 데는 이유가 있다. Dynasets, Snapshots, Tables, JET 엔진, SQL 질의 등 복잡한 주제가 쏟아진다. HyperCard 보다 훨씬 더 강력해서, 우리의 VB 애플리케이션 안에서 여러 데이터베이스를 다룰 수도 있고 원격 데이터베이스에 접근할 수도 있다. 하지만 그 힘에는 그에 상응하는 학습 곡선이 따라붙고, 드래그 앤드 드롭 컨트롤이 제공하는 범위를 조금만 넘어가도 그 곡선은 개발자에게 그대로 덮쳐 온다.
전체적으로 보자면 이 IDE를 “유능하다”라고 부르는 것은 공정하다. 필요한 도구들을 팔레트별로 갖추고 있고, 버튼 추가 같은 몇몇 동작은 더블클릭만으로도 할 수 있다. 뭐가 문제냐고? 이 도구들이 각자의 문제에 대한 다소 성의 없는 설계 해법처럼 느껴진다는 점이 나를 답답하게 만든다.
예를 들어 “Properties” 팔레트를 보자. 내 눈에는 이것이 “선택된 객체의 속성은 편집 가능해야 합니다.”라는 말을 들은 개발자가 그 속성들을 글자 그대로 목록으로 나열하고, 색상 속성 편집 시 색상 선택기를 띄우는 식의 기본적 편의만 얹은 것처럼 보인다.
Height와 Width도 논리적으로는 관련된 항목인데 서로 엄청 멀리 떨어져 있다는 점도 보라. 아마 WindowHeight와 WindowWidth라고 이름 붙였으면 WindowState 근처로 모을 수 있었을 것이다. 그런데 잠깐, 이 IDE의 언어에서는 이걸 “Windows”가 아니라 “Forms”라고 부르는 것 아니었나?
실제로 써 보면 대부분의 속성은 전혀 손대지 않게 된다. 특히 Form 객체 같은 경우가 그렇다. 반면 내가 실제로 필요한 것들은 긴 목록을 스크롤하며 찾아야 한다. 목록 뒤쪽에 있는 속성들, 심지어 모든 컨트롤에 공통적인 속성들조차, 선택한 컨트롤이 얼마나 많은 속성을 갖느냐에 따라 위치가 계속 바뀐다. 나는 그 목록을 끊임없이 훑으며 “Name” 속성을 찾는다. 여기서 컨트롤의 프로그래밍용 이름을 정하기 때문이다. 이건 사실상 가장 중요한 속성 인데도 숨바꼭질을 하고 있다.
새 form을 만들면 ("form"은 창이다. 왜 “form”이라고 부르는지 모르겠다) 나는 바로 몇 가지를 설정해야 한다. 크기, 제목, 프로그래밍 참조 이름이다. 그다음에는 가끔 배경색도 지정하고 싶다. 속성 이름들이 말이 안 된다는 사실은 일단 무시하자. UI와 UX라는 말이 아직 흔한 일상어가 되기 전 시대였으니, 작명 규칙이 단단히 자리 잡지 않았을 수도 있다.
순수하게 “사용자가 가장 필요로 할 법한 것은 무엇인가?”라는 관점에서 보면, 이 단순한 알파벳순 목록은 설계 과제에 대한 가장 게으른 해법이다. 제품의 버전 3이라면, 솔직히 말해 나는 1사 독점 솔루션에서 더 많은 고민을 기대한다. 어쩌면 불공평할 정도로 말이다.
나만 그 점이 궁금했던 게 아니라니 다행이다. _Compute_, issue 152.
이 답답함은 메인 툴박스에도 이어진다. 그저 조직 구조 없이 버튼만 잔뜩 늘어놓은 것에 불과하다. 오늘날 우리가 이해하는 의미의 툴팁과 비슷한 것은 Macintosh System 7에서 “Balloon Help”라는 이름으로 VB3 출시와 같은 해에 도입되었으니, Microsoft가 이번 릴리스에서 그것을 “구현하지 못했다”고 비난할 수는 없다. 그래도 가능한 한 많은 아이콘을 툴바에 밀어 넣겠다는 목표 앞에서, 아이콘만으로 처리하는 방식은 게으르다.
Windows 개발을 위한 비슷한 비주얼 IDE인 Asymetrix Toolbook 3 는 이 작업을 위해 더 강력하고 논리적으로 배치된 도구들을 제공한다. 아래는 텍스트 에디터와 객체 속성 패널이다.
특히 몇 가지를 주목하라.
Visual Basic 자체도 “Crystal Reports” 도구처럼 애플리케이션의 다른 부분에서는 비슷한 문맥 도움말을 제공한다. 그래서 메인 앱에서 그게 빠져 있다는 사실이 더더욱 짜증 난다. 도구와 컨트롤이 이런 식으로 여기저기 들쑥날쑥 적용된 느낌은 어수선하고, 그게 내가 이야기하고 싶었던 다른 무언가를 떠올리게 한다.
Visual Basic 공식 매뉴얼들을 읽어 가는 동안, 계속 뭔가가 거슬렸다. 처음엔 정확히 뭔지 짚지 못했지만, 한 번 보이고 나니 내 눈은 영원히 저주받았다. 이것은 사소한 불만이다. 어떤 이는 “쪼잔하다”고 할 것이고, 어떤 이는 “정신 자원의 엄청난 낭비”라고 비웃을지도 모른다. 하지만 어느 정도의 꼬치꼬치 따짐 없는 테크 블로그가 무슨 재미겠는가?
나는 그런 꼬치꼬치함을 부끄러워하지 않는다.
여기서 우리는 Visual Basic 3 매뉴얼이 Helvetica와 Times로 조판되어 있는 것을 본다. 아, 벌써 지루하다. 어쨌든, 지극히 평범한 폰트 선택을 넘어선 문제도 있다. (공정하게 말하자면 이들은 3,000페이지가 넘는 자료를 조판해야 하긴 했다.) 뭔가 “이상하다”. 특히 그 Helvetica가 엉성한 커닝과 불균형한 획 때문에 형태가 망가진 것처럼 보인다. 좀 더 자세히 보자.
Helvetica Neue는 맞지 않고, Arial도 (내 최초의 용의자였지만) 대문자 “C”의 끝 처리 때문에 탈락이다. Helvetica Condensed도 아니다. 아, 무슨 일이 벌어졌는지 알겠다. 이것은 내가 사용자 인터페이스에서 느끼는 문제와 같은 것이다. 매뉴얼에 나타난 형태로 말이다. 이건 Helvetica Condensed가 아니라, Helvetica를 물리적으로 눌러 찌그러뜨려 가짜 condensed 버전으로 만든 것이다. 세상에서 가장 부유한 사람이 자기 회사에 쓸 제대로 된 condensed 폰트 하나 살 수 없었던 건가? “아니면 이것은 더 깊은 문제의 징후인가?”라고 그는 말하며 다시 대중심리학 소파 의자로 미끄러져 돌아갔다.
이건 ‘충분히 괜찮음’의 냄새가 난다. ‘위대함’을 향해 애쓰지 않는 태도 말이다.
이것이야말로 이 시기의 Windows와 Windows 애플리케이션에 대한 내 감정을 잘 요약한다. 물건은 작동했고 분명한 성공도 거뒀지만, 늘 사려 깊은 숙고의 결과물처럼 느껴지진 않았다. 이런 세부에 대한 무심함은 비용 절감에서 왔을까, 아니면 어떤 문화적 맹목에서 왔을까? 결함을 보고도 무시한 걸까, 아니면 애초에 보이지도 않았던 걸까?
그리고 그것은 내가 이야기하고 싶었던 또 다른 것을 떠올리게 한다.
PBS 다큐멘터리 시리즈 Triumph of the Nerds 에서 Steve Jobs는 Microsoft를 두고 유명한 말을 했다. “그들은 취향이 없다.”
“Microsoft의 유일한 문제는 그들에게 취향이 없다는 겁니다. 정말로 취향이 전혀 없어요. 그리고 그게 무슨 뜻이냐면, 이걸 사소한 의미로 말하는 게 아니라 아주 큰 의미로 말하는 겁니다. 그들은 독창적인 아이디어를 생각하지 않고, 자신들의 제품에 많은 문화를 담아 오지 않아요. 나는 그들이 그저 아주 3류 제품을 만든다는 사실이 문제라고 생각합니다.”
- Steve Jobs, Triumph of the Nerds
_Triumph of the Nerds_ 에서. Spielberg는 아직도 그 모자를 가지고 있을까?
나는 진심으로 Bill Gates가 Jobs의 비난이 무슨 뜻인지 이해하지 못했을 거라고 생각한다. 아니, 정확히는 왜 “취향”이 자신의 계산식에 들어가야 하는지 아예 상상하지 못했을 것이다. 취향이 없어도 그는 세계에서 가장 부유한 사람이 되는 데 성공했다. 취향이 주주 가치와 무슨 상관이란 말인가?
Apple이 새 OS X 릴리스를 놀리며 “Redmond, start your photocopiers”라고 했을 때, Gates는 아마 “물론 그러겠지. 무료 R&D 고맙군.”이라고 생각했을 것이다. 그는 베꼈다고 공개적으로 꾸지람을 들을 때 발끈했지만, 내 해석으로는 사실 이렇게 말하고 싶었던 것 같다. “우리가 Apple을 베끼면 어때서? 왜 그러면 안 되는데? 우리의 성공을 보고도 그게 좋은 전략이 아니었다고 말할 수 있나?” Jobs가 창조적 파산으로 본 것을 Gates는 사업적 효율로 보았다. 자신의 성공을 Jobs의 기준으로 설명하라는 요구가 Gates의 심기를 건드린 것이다.
Jobs가 한때 “위대한 예술가는 훔친다”고 (원 출처도 틀리게) 의역했던 것을 생각하면, 조금은 아이러니하다.
Jobs는, 그리고 나도 동의하듯, 혁신이란 “예”라고 말하기 전에 1000가지에 “아니오”라고 말하는 것이라고 했다. “과정”이란 바로 그 행위다.
“과정”은 가능성의 공간을 가지치기하는 일이다. “충분히 괜찮음”과 “위대함”을 구분할 자기 인식이다. 작업에서 한 걸음 물러나 비판적인 냄새나는 시선으로 바라보고 취향을 적용하는 순간이다 . 애초에 취향이 없다면 그건 불가능한 과제다.
그래, 다시 말하지만 바로 그거다. 하지만 이번에는 _자기 자신의_ 작업을 향해서.
그렇다면 취향 없는 기업은 뭘 해야 할까? Microsoft는 과정 자체에는 그다지 신경 쓰지 않았을지 몰라도, 제조 는 완전히 익숙하게 해냈다. PenPoint OS를 넣으면 Windows for Pen Computing이 튀어나오고, OS X 10.3을 넣으면 Windows Vista가 튀어나오고, Java를 넣으면 J++가 튀어나오고, Dreamcast를 넣으면 Xbox가 튀어나온다. 오늘날에도 비슷한 “공장식 생산” 비난이 그들에게 쏟아진다. 내가 말하고 싶은 것은 그들이 아이디어를 “훔쳤다”기보다는, 다른 이들이 대신 1,000번의 “아니오”를 말하는 힘든 작업을 하도록 내버려 두는 데 만족했던 것 같다는 점이다.
창조 과정은 지름길로 건너뛰었을지 몰라도, 그들은 여전히 제품을 어떻게 제조하는지는 배워야 했다. 그 과정에서 우연히 약간의 취향도 함께 익히게 되었고, 이는 때때로 꽤좋은물건들을 만들게 했다.
이것은 수십 년 동안 업계의 구조 일부였고, 이제는 타인의 창조적 작업물로부터 무미건조한 제품을 제조하는 횃불이 generative AI로 넘어갔다. 심지어 대규모로 말이다. 그 여파는 내 머릿속을 무겁게 짓누른다. 특히 누군가 내 작업을 생성형 AI 장치에 흡수하자고 공개적으로 말할 때 더 그렇다. 기분이 좋으면서도 소름 끼친다.
평균적으로 내가 이 글들의 도입부를 몇 번이나 다시 쓰는 것 같나? 내가 정말로 하고 싶었던 말을 향해 가기 위해 몇천 단어를 버려 왔을까? 나는 보통 도입부를 3번이나 4번쯤 다시 쓴다. 정말 말 그대로다. 각 다시 쓰기는 서로 완전히 다르다. 이 글 하나만 해도 나는 대략 5,000단어를 버렸다.
어떤 사람들은 그 5,000단어가 과정의 비용이라고 생각할지 모르지만, 그건 틀렸다. 그것들은 바로 과정이다. 출판되지 않은 단어들이 중요한 것이다. 그 단어들이 나를 이 단어들로 데려왔다. 그걸 알고 나면, 어떤 창작물이든 생성형 파쇄기에 던져 넣었을 때 왜 결과물이 원본에 미치지 못하는지가 분명해진다.
거기엔 1,000개의 “아니오”가 없기 때문이다.
https://bsky.app/profile/kierongillen.bsky.social/post/3mmvgs45w5k2l
이 책의 결말은 실망스럽다. Day 21이 와서 지나가지만, 우리가 이 시련을 통과했다는 암시조차 없다. 그리고 모든 것을 마친 뒤에도 우리는 가치 있는 무언가를 만들지 못했다. 각 장은 특정 개념을 설명하기 위한 작은 아기 프로그램들을 만들 뿐이었다. 몇 번의 얕고 피상적인 외형 개선을 제외하면, 어떤 프로젝트도 이전 프로젝트 위에 쌓이지 않았다.
그 점은 HyperCard 와 대조적이다. 거기서는 데이터베이스, 검색, 직접 만든 그림, 저장/불러오기를 갖춘 완전한 주소록을 만들었다. Visual Basic 에서는 HyperCard 에서 느꼈던 그 같은 불꽃 을 한 번도 느끼지 못했다.
Visual Basic 은 만들고 싶은 것이 명확할 때는 훌륭해 보인다. 하지만 드로잉 도구의 부재와 “걱정 마, 내가 알아서 해 줄게” 식의 데이터베이스가 없다는 점은, 공부를 시작할 때 내가 예상했던 것보다 훨씬 더 창의적 탐색을 제한한다. 그런 세부를 신경 쓰지 않아도 된다는 것은 “잠깐, 이거 한번 빠르게 해 보자” 식의 실험과 반복에 더 넓은 세계를 열어 준다.
이상적인 제품이라면, 나는 HyperCard 의 프로토타이핑 강점과 Visual Basic 의 전문성을 결합하고 싶다. 그런 다음 나중에 기본 데이터베이스를 Access로 바꾸거나, 임시 그림을 내보내 전문 아티스트가 다음 개정판에서 이미지 자산으로 다듬게 할 수 있을 것이다.
개인적으로 나는 Visual Basic 을 마음속에 자리 잡게 만들 수는 없지만, 왜 그것이 크게 성공했는지는 충분히 이해할 수 있다. 그것은 프로그래밍 지형의 큰 공백을 메우며, 아마추어와 준전문가들이 스스로를 위한 도구를 만들도록 도왔고, 심지어 한 세대의 COBOL 엔지니어들에게도 급히 전환할 생명줄을 던져 주었다. Apple이 HyperCard 에 그랬듯, 제품 중단은 그 공백을 다시 열어젖혔고 수많은 개발자들, 그리고 어쩌면 그만큼 중요한 잠재적 개발자들까지 내버렸다.
영원한 것은 없다고 할 수 있겠지만, 이 회사들은 여러 번 (다시 그 단어를 말하려니 목이 멘다) TRILLIONS of US dollars의 가치를 지닌다. 그런 평가와 우리가 바치는 충성을 생각하면, 나는 가능한 한 넓은 사용자 기술 수준을 강화해 주는 훌륭한 도구를 제공하는 것이 그들의 도덕적 의무 라고 본다. 그런 도구를 제공하지 않는 것은 선택 이다.
다른 각도에서 생각해 보자면, 마지막으로 이 열린 질문을 남기고 싶다. Apple과 Microsoft가 오늘 제공하는 소프트웨어 중, 25년 뒤에 HyperCard 와 Visual Basic 처럼 같은 경외심 속에서 회자될 것은 무엇일까?
설마.
경험을 개선할 방법, 눈에 띄는 결함, 우회책, 그리고 이 소프트웨어를 현대 워크플로에 통합하는 것에 대한 메모들(가능하다면).
beep 명령은 시스템 비프음을 하나만 냈다. 내 추측으로는 에뮬레이트된 환경 어딘가에서 이것이 억제되고 있다.SHARE.EXE의 에뮬레이트된 버전을 사용하기 때문일 수 있다. 이상하게도 딱 한 번 작동하는 걸 봤는데, 시작된 것만큼 갑자기 멈췄고 다시는 작동하지 않았다. 제대로 설치한 MS-DOS 위에 Windows를 설치하면 이 문제는 해결될지도 모른다.
끝내 넘어설 수 없었던 파일 읽기 오류. 여담이지만, 나는 모든 “OK” 버튼은 사실 “OK 🤷♂️”라고 적혀 있어야 한다고 생각한다.
Visual Basic 3, 2, 1, 그리고 DOS 1.0으로 만드는 애플리케이션은 16-bit 전용이므로, 64-bit Windows에서는 가상 환경 안에서만 실행할 수 있다. 이것이 당신의 작업 방식과 맞는다면, 아주 좋다.
옛 방식을 유지하면서도 현대 하드웨어에서 창작물을 실행할 가능성을 남겨 두고 싶다면, Visual Basic 6 을 Windows 2000? XP?에서 실행해야 할 것이다. 나는 Windows 98SE에서 시도했지만 실행되지 않았다. VB6 는 32-bit 애플리케이션을 독립형 컴파일 실행 파일로 빌드할 수 있고, Internet에 연결할 수 있으며, Windows 10/11에서 실행되는 빌드를 만들어 낸다.
Windows 11은 VB6 로 만들어진 애플리케이션을 실행하겠다고 약속하지만, VB6 자체를 실행하겠다고 약속하지는 않는다는 점을 알아 두자. 그래도 나는 시험 삼아 시도해 봤고, 설치 과정에 문제가 있고, IDE도 약간 이상하게 굴고, 실행 시 누락된 OLE 파일에 대해 불평하긴 하지만, 실제로 실행되었고 Windows 11에서 실행 파일을 빌드할 수 있었다.
0:00
/0:08
광고와 브로슈어를 뒤져 보며 흥미로웠던 점 하나는, Microsoft가 개발자들이 직원들과 이야기하기 얼마나 쉽게 만들었는가였다. 개발자와 Microsoft 엔지니어를 직접 연결해 주는 CompuServe 포럼이 따로 있었다.
저 툴박스 안에 펜 입력 컨트롤처럼 보이는 것이 보이는데, v3.0 Professional Edition에는 그런 것이 포함되지 않는 것 같다.
Visual Basic 계열에는 Visual Basic, Visual Basic for Applications, 그리고 VBScript가 포함되었다. 마지막 것은 특히 ILOVEYOU worm을 낳은 것으로 악명이 높다.
“먼 친척”이라는 표현은 정확하다. 여기서도 이것이 “Visual BASIC” (전부 대문자)으로 불리지 않는다는 점에 주목하라. Microsoft는 결국 “Basic”이 약어라기보다 분위기라고 판단한 듯하다.
1993년에 어떤 사람이, 역사적으로 업계를 바꿔 놓은 무언가를 두고, 내가 AI에 대해 품는 생각들 일부를 말하는 걸 읽자니 좀 아프긴 하다. _Infoworld_, June 28, 1993.
재미 삼아, Gates와 Jobs가 각자의 비주얼 프로그래밍 환경을 시연하는 영상도 남겨 둔다.
Gates가 막 발표된 _Visual Basic 1.0_ 을 담담하게 시연한다. 0:33에서 목소리가 갈라지는 건 _사랑스럽다_.
Jobs는 Apple이 NeXT를 인수한 뒤 막 복귀한 참이었고, 여기서 Apple이 미래를 걸고 있는 기술을 보여 준다. 오늘날 우리는 이것을 _Xcode_ 로 알지만, 처음 이름은 _Interface Builder_ 였다. 데모에서 그가 구성 요소들 사이에 그은 선은 “binding”이라고 불렸고, 그 개념은 오늘날 SwiftUI에서 다시 떠오르고 있다.