VisiCalc가 시작했지만 1-2-3이 끝냈다. 스프레드시트의 가능성과 그 시장을 완성한 Lotus 1-2-3의 위력, 그래프·데이터베이스·매크로·HAL까지 DOS 시대의 통합 비즈니스 엔진을 직접 탐험한다.
spreadsheet VisiCalc가 시작했지만 1-2-3이 끝냈다. 여기서 "끝냈다"는 말은 스프레드시트가 무엇이 될 수 있는지에 대한 논의를 뜻하기도 하고, VisiCalc 자체를 뜻하기도 한다.
오늘날 어떤 소프트웨어가 데모를 보는 순간 여러분이 환호하고 박수치게 만들 수 있을까? 내가 말하는 것은 "기조연설에 참석 중이고, 이건 기대되는 반응이니, 피차이 씨 저를 노려보지 마세요" 같은 점잖은 사회적 박수가 아니다. 내가 말하는 것은 "이제 모든 것이 달라졌다." 같은 종류다.
그 정도가 되려면 요즘은 기준이 꽤 높다. Brad Pitt와 Tom Cruise가 종말론적 도시 풍경을 배경으로 벌이는 "사진처럼 사실적인" 전투 장면이 소원 하나만으로 생성되고, 소셜 미디어는 그 냉소적인 절박함의 냄새를 맡고도 이를 악문 찡그림 이상은 내놓지 못한다. 48시간만 지나면 그 장대한 전투의 차가운 빛은 사라지고, 남는 열기도 없다.
경이로움은 황금기 시절에는 훨씬 더 쉽게 끌어낼 수 있었다. Bill Atkinson은 _MacPaint_에서 지우개로 픽셀 몇 개를 문질러 지웠고, 우레 같은 박수가 쏟아졌다. Andy Warhol은 Debbie Harry의 캡처 이미지에 플러드 필을 했고, 관객은 황홀해했다.
어쩌면 기적은 사소할 때 가장 잘 작동하는지도 모른다.
흔한 이야기로는 Warhol이 플러드 필을 사용했을 때 엔지니어들이 패닉에 빠졌다고 하지만, 그 이야기는 논란의 여지가 있다. 특히 당시 데모된 _ProPaint_ 버전에 대해서는 더 그렇다. Warhol의 원본 Amiga 디스크는 그리 오래되지 않아 다시 발견되었다.
Mitch Kapor는 그런 찬사의 중심에 있었던 사람이다. 갓 설립된 Lotus Corporation의 CEO로서, 그들의 대표 제품인 1-2-3 데모는 군중에게 상당한 열광과 흥분을 불러일으켰다. 2004년 Computer History Museum 인터뷰에서 Kapor는 이렇게 말했다. "스프레드시트에서 원클릭으로 그래프를 볼 수 있었어요. 그전에는 그럴 수 없었죠. 우리가 데모할 때 그게 킬러 기능이었습니다. 진짜로, 사람들이 박수를 치곤 했어요. 믿기 어려울 만큼요."
그는 VisiCalc 진영의 고충을 누구보다 잘 알고 있었다. 이전에 VisiCorp를 위해 _VisiPlot_과 _VisiTrend_를 만들었기 때문이다. 그 프로그램들은 VisiCalc 데이터로 그래프를 그렸지만, 차트와 그래프를 미세 조정하려면 여러 프로그램 사이를 오가며 디스크를 끊임없이 바꿔 끼워야 했다. Apple 2의 48K 메모리로는 그 모든 소프트웨어를 한꺼번에 메모리에 넣는 것이 사실상 불가능했지만, 적어도 모든 것을 같은 디스켓에 담을 수는 있다고 Kapor는 생각했다. 그런 번거로운 절차를 없애는 것은 고객에게 유용할 터였다.
광고에서는 그것을 _말 그대로_ 노래와 춤으로 묘사했다.
_Kapor는 Founders at Work 인터뷰에서 이렇게 말했다. "여러 차례 출판사 쪽에 (_VisiCalc_와 VisiPlot_을 한 디스크에 결합하는) 아이디어를 제안했지만, 그들은 전혀 관심이 없었습니다. 그들은 저를 동등한 사람으로 본 적이 없었다고 생각해요. 제가 거기서 제품 관리자였을 때, 그들은 저를 귀찮은 존재로 봤죠. 경험이나 자격이 없는 변두리 인물, 약간 성가신 사람으로요. 그리고 아마 저도 실제로 좀 성가셨을 겁니다."
그는 감정이 상호적이었다고 했고, 그것이 사실상 Personal Software와 VisiCalc 팀에서의 고용 관계의 끝이었다. 그는 그들이 자신을 매수하도록 놔두었다. 즉, _VisiPlot_과 _VisiTrend_에서 받고 있던 달콤한 로열티를 $1.2M에 넘긴 것이다. 그리고 그 돈을 들고 자신이 제안하려 했던 더 나은 쥐덫을 만들러 떠났다.
_Lotus 1-2-3_는 곧 막 태동하던 IBM-PC의 "킬러 앱"이 되었고, 그 시스템에 대해 _VisiCalc_가 예전에 Apple에 해주었던 역할을 해냈다. _1-2-3_의 성공과 Personal Software와 VisiCorp 사이의 사내 다툼은 _VisiCalc_의 판매를 거의 즉시 바닥으로 밀어 넣었다. 2년 뒤 Lotus는 Personal Software를 인수했다. 1년 뒤 Lotus는 _VisiCalc_를 죽였다. 오늘날에도 Microsoft Excel 문서는 여전히 _Lotus 1-2-3_를 언급한다. _VisiCalc_가 아니라.
나는 이번에 들어오기 전까지 1-2-3 경험이 전혀 없다. 나는 늘 "1-2-3"이 숫자와의 관계를 뜻한다고 생각했다. "1, 2, 3. 행 번호. 스프레드시트 속 숫자. 수학적인 숫자 관련 뭔가. 알겠네." 솔직히 말해, "1-2-3"이 그보다 더 많은 뜻을 담고 있다는 걸 전혀 몰랐다.
나는 이제 _VisiCalc_가 _1-2-3_가 달릴 수 있도록 걸었고 _(VisiCalc_의 재 위를 Sherman 전차로 짓밟으며) 달렸다는 것을 배우는 중이다.
DOSBox-X 2026.01.02, Windows x64 빌드. 조사 도중 2025.12 빌드에서 업데이트했다.
Lotus 1-2-3 Release 2.01, 2.2, 2.3, 2.4, 3.4를 모두 어느 정도 사용했다. 스크린샷에도 그 점이 반영되어 있다. 나는 주로 R2.3에 끌린다. 내가 필요한 일을 해주면서도 기능 비대에 발목 잡히지 않는다.
_1-2-3_와의 호환성 테스트를 위한 dBase III Plus.
내가 _Lotus 1-2-3_를 배우는 목표는 하나다. 내가 사랑하는 _VisiCalc_를 출시 첫해에 사실상 쓸어버릴 만큼, 그것이 무엇을 그렇게 압도적으로 잘했는지 이해하고 싶다. Kapor는 첫해 1-2-3 판매를 US$1M으로 예상했지만, 실제로는 US$53M을 기록했다.
그건 단지 _VisiCalc_보다 조금 더 나은 정도가 아니라, "VisiWho?" 수준의 지배력이다.
_PC Magazine_, 1991년 4월 16일자에 따르면 Release 2.2는 경쟁 제품보다 두 배 이상 더 팔리고 있었다. 경쟁 제품에는 _Quattro Pro_, _Microsoft Excel_, 그리고 _1-2-3_ Release 3 자체까지 포함되어 있었다!
_VisiCalc_는 스프레드시트이고 _1-2-3_도 스프레드시트이니, 대체 뭐가 그리 대단했을까? 먼저, 선택된 플랫폼 자체인 IBM-PC와 PC-DOS 따로 구입한 사람들에게는 MS-DOS 는 시작부터 두 가지 큰 이점을 제공한다. 80열 텍스트 모드는 Apple 2의 40열을 답답하게 느끼게 하며, 어쩌면 조금 덜 비즈니스답게 느끼게도 한다. 16비트 PC의 대폭 확장된 메모리, 최대 640K 대 8비트 Apple 2의 48K는, 훨씬 더 복잡한 워크시트가 그 넉넉한 80열을 채우게 해준다.
Lotus Corporation과 잡지들, Wikipedia 문서들, 다른 블로그들이 즐겨 강조하듯, 진정한 게임 체인저는 프로그램 이름 자체에 담겨 있다. "1-2-3"은 이 "통합 소프트웨어" 패키지의 세 가지 구성 요소를 뜻한다.
"1"은 스프레드시트 기능이며, Release 3 전까지 x86 어셈블리로 작성되어 속도 면에서 동시대 제품 대부분을 손쉽게 앞질렀다.
"2"는 Kapor의 청중이 박수를 치게 만든 그래프 도구다.
"3"은 원래 워드 프로세서가 될 예정이었지만, 프로그래머 Jonathan Sachs의 말에 따르면, "워드 프로세싱 부분을 작업한 지 몇 주쯤 되었을 때, 점점 막히기 시작했어요. 마침 그때 _Context MBA_가 나왔고, 그들이 해놓은 걸 보게 됐죠."
"그들이 해놓은 것"은 워드 프로세서, 통신 기능, 데이터베이스를 스프레드시트와 그래픽 구성 요소와 함께 통합한 것이었다. 말하자면 _Context 1-2-3-4-5_였던 셈이다. Sachs는 그 데이터베이스를 보고 자신에게 더 자연스러운 조합처럼 느꼈고, 그래서 "3"은 데이터베이스로 다시 구현되었다. 그는 "구현하기가 훨씬 쉬울 것"이라고 말했다.
게으른 프로그래머들을 축복하소서, Woz여.
결국 _1-2-3_는 지난 글의 주제였던 _dBase_와 잘 어울리는데, 이 조합은 특히 강력하게 느껴진다. 이전 탐구에서 익힌 기술이 나중에 배당금을 돌려줄 때면 찌릿함이 느껴진다. Deluxe Paint+ _Scala_도 비슷하게 보답해줬다. 이게 바로 "레벨 업"의 느낌인가?
엄밀히 말하면 나는 블로거-개발자 이중 클래스지만, 요즘은 XP를 나눠 먹고 싶지 않다. 특히 그분이 모든 재미를 미니맥스로 최적화하고 있는 상황에서는 더더욱.
_Lotus 1-2-3_에 관한 문헌을 구하는 것은 오직 "선택 과잉"이라는 의미에서만 어렵다. 책이 많으리라 예상은 했지만, archive.org에서 검색 결과 1,000건을 보고 "내가 대체 뭘 시작한 거지?"라는 실존적 공포까지 느낄 줄은 몰랐다.
더 거대한 국제적 스모르가스보드의 식전 한입거리.
책만 있었던 게 아니다. 그 시대에는 "소프트웨어 업체가 발행한 팬 잡지"라는 흥미로운 곁현상도 있었다. Aldus, Corel, Oracle 같은 회사들은 모두 자사 이름을 건 잡지를 가판대에 올렸다. Lotus Corporation도 _LOTUS Magazine_으로 그 대열에 있었다.
Lotus Corporation이 월간으로 발행한 이 잡지는 1985년 5월호로 창간했다. 아마 가판대에는 3월 말이나 4월 초에 나왔을 것이다. 태그라인인 "Computing for Managers and Professionals"는 구매 권한을 가진 의사결정자들을 향하고 있었다. Lotus 소프트웨어 사용자 대상 설문에서는 "여러분 대부분은 컴퓨터를 기본적으로 도구로 보며, 컴퓨팅 그 자체에는 관심이 없다"는 결과가 나왔다.
그래서 이 잡지는 당시의 _BYTE_나 _PC Magazine_과는 다른 접근을 택했다. 군더더기 없고, 기술 용어 남발 없이, 짧고, 소화하기 쉬운 기사들로, 관리자 관점에서 컴퓨팅을 다루겠다는 것이었다.
"계속 듣게 되는 '플루피 디스크'니 '램'이니 '메모리'니 하는 게 다 뭐람? 이러다 멀쩡한 비즈니스 컴퓨터 사용자도 완전히 미치겠어!"라고 정신없는 기업 임원 클리셰가 말한다. 괜찮다, 걱정 말라! _LOTUS Magazine_은 그 고통을 이해하며 1호 표지 기사로 응답한다.
예술적인 잡지 표지의 시대가 그립다.
"컴퓨터 메모리의 세계는 복잡성과 첨단 기술 용어로 가득 차 있어, 가장 이성적인 비즈니스 컴퓨터 사용자조차도 혼란에 빠뜨릴 수 있다"라는 문장으로 T.R. Reid의 "An Inside Look at Computer Memory"가 시작된다. 이 기사는 RAM과 ROM, 플로피와 하드디스크의 차이 등을 설명하며, 80년대 중반의 당황한 비즈니스 임원들의 찌푸린 미간을 펴준다.
하지만 1-2-3 자체로 들어가면 _LOTUS Magazine_은 봐주지 않았다. 기사들은 짧았고 대략 네 페이지 정도였지만, IT 역량보다는 분석적 역량이 더 높다고 가정했다. 수식 차트, 설명이 달린 매크로 정의, 더 빠른 데이터 입력을 위한 팁과 요령 등으로 페이지가 채워졌다.
그 흐름은 약 7년 동안 이어졌고, 1992년 12월호에 이르러 출판 업무가 _PC Magazine_으로 넘어가 _PC Magazine: LOTUS Edition_이 되었다. 즉 PC Magazine 본지에 매달 Lotus 전용 콘텐츠를 담은 미니 잡지 분량이 특집 부록처럼 덧붙는 형태였다. 그것은 1995년 8월까지 이어졌고, 총 10년간의 발행 기록을 남겼다. 내 예상보다 대략 8년은 더 길다.
1992년 12월에 평민들이 받은 것과 Lotus 엘리트들이 받은 것.
책을 철저히 표지만 보고 판단한 끝에, 나는 1.0A, 2.2, 3.4의 공식 Lotus 매뉴얼과, _LOTUS Magazine_에 실렸던 팁과 요령을 모은 두 권의 편집본을 골랐다. 다른 자료들도 훑어보긴 하지만, 솔직히 이번에는 아무것도 내 관심을 붙잡지 못한다. 전부 똑같이 "건조하고 지루하게" 읽힌다.
어떤 책들은 1,000페이지가 넘는데, 그 안에 농담 하나 넣을 공간조차 없었던 걸까? 나는 이 글에서만 적어도 일곱 개는 약속한다. 전부 찾을 수 있는지 보시라!
프로그램 본체를 실행하자 예상했던 "나는 스프레드시트다!"라는 격자 레이아웃이 나온다. 열과 행 레이블, 화살표 키로 조작하는 셀 커서, 그리고 위쪽의 _VisiCalc_풍 공간까지. 자, 시작해보자.
중급 VisiCalc 사용자로서, 내 / 메뉴 근육 기억이 즉시 성과를 내는 것이 무척 반갑다. Lotus는 분명 탈주자를 환영하며, 80열 디스플레이를 활용해 모두의 삶을 더 쉽게 만들고 있다.
_VisiCalc_의 단일 문자 메뉴 니모닉은 _1-2-3_에서 화면에 아예 철자를 전부 써주는 방식으로 강화되었다. 전체 메뉴 항목 이름이 항상 보이면서도, 여전히 한 글자 명령으로 접근할 수 있다. 시작부터 _1-2-3_는 개선된 사용성과 발견 가능한 도구를 제공하며 강력한 자기변론을 펼친다.
이 인터페이스는 DOS에서 마우스로도 조작할 수 있다. 오른쪽의 화살표는 마우스로 워크시트 안을 이동하기 위한 것이다.
너무 깊게 파고들기 전에 언급해야 할 것이 있다. _1-2-3_는 _VisiCalc_의 모든 것을 해낸다. A1 스타일 셀 참조, 슬래시 / 메뉴, 고정 및 상대 셀 참조, 초월함수를 포함한 @ 함수, .. 범위 지정자, 값 앞의 + 접두사 등등. 더하고, 빼고, 이자를 계산한다. 그리고 그 위에서 _1-2-3_는 _VisiCalc_에 "그래, 그리고..."를 더한다.
얻는 것은 많지만 눈에 띄는 부재도 있다. 바로 오른쪽 위 상태 표시다. _VisiCalc_는 그 자리에 계산 순서, 화살표 키 토글, 남은 메모리를 보여준다. _1-2-3_에서는 전부 사라졌고, 솔직히 잘됐다. PC에서는 완전한 화살표 키가 있고 Woz보다 RAM도 많다. _1-2-3_는 내 DOS Extended 메모리 16MB를 전부 본다. 이제 나는 멈출 수 없다.
_1-2-3_는 또한 _VisiCalc_의 "계산 순서" 행 우선이냐 열 우선이냐 하는 소동에도 콧방귀를 뀌며 "최소 재계산"을 도입한다. 거의 우스울 정도로 직설적인 제목의 책 _Lotus 1-2-3, Release 2.3_에 따르면, "_1-2-3_가 워크시트를 재계산할 때는, 데이터의 변경에 직접 영향을 받은 수식만 재계산한다." 나는 지금 1989년이든 1991년이든, 혹은 이번 주 내가 가장하기로 한 어느 해든, 정말 호화롭게 살고 있다.
심지어 _VisiCalc_의 @lookup도 업그레이드된다. 오늘날 여러분은 그것을 @hlookup과 @vlookup으로 알고 있으며, 둘 다 1983년 1-2-3 Release 1에 이미 존재했다. 이 속도라면 _1-2-3_는 위험할 정도로 "2026년에 기대하는 스프레드시트 동작"에 가까워진다. Lotus, 괜히 희망고문하지 마라. 거기서부터는 내리막뿐이다.
순전히 내 개인적인 즐거움을 위한 것이다. __Lotus 1-2-3, Release 2.3__에는 "Top Ten @ Functions"라는 사이드바가 있는데, 나는 도저히 참을 수 없었다. 내가 무엇을 패러디하는지 모르는 분들께는 사과드린다.
이걸 더 많이 접할수록, 우리가 이 방식을 너무 일찍 포기한 건 아닐까 싶어진다. 이건 "주제에 과몰입한 블로거 뇌"일 수도 있지만, 나는 종종 현대 GUI 메뉴보다 두 줄짜리 가로 메뉴를 더 선호하게 된다.
GUI 메뉴에서 좌우, 상하, 좌우, 상하 하며 훑어가는 방식은 좀 피곤하다. 두 줄 메뉴에서는 좌우 화살표 키로 상위 옵션을 넘기면서, 눈은 두 번째 줄에 고정한 채 하위 항목을 스캔할 수 있다.
그리고 GUI 메뉴가 주지 못하는 것도 제공한다. 메뉴 항목의 동작을 문서에 적용하기 전에, 그 항목이 무엇을 하는지 즉시 설명해준다. 메뉴 항목이 하위 메뉴가 아니라면, 두 번째 줄이 그것을 설명한다. 낯선 프로그램의 기능을 검토하기가 쉽다.
또한 모든 메뉴 항목에는 키보드 단축키가 있다. 첫 글자만 치면 된다. 이를 위해서는 개발자가 각 메뉴 항목의 첫 글자가 모두 고유하도록 창의적으로 이름을 지어야 하지만, 그 덕분에 사용자에게는 사실상의 니모닉이 생긴다. 근육 기억을 얕보지 마라!
"단점"이 하나 있긴 한데, 나는 오히려 그것을 장점으로 변호해보겠다. 구체적으로 말하면, 현대 GUI 메뉴의 모든 것을 두 줄 체계 안에 넣는 것은 아마 불가능할 것이다. 너무 많기 때문이다! 나는 가로 메뉴 바가 바로 그 설계 제약 덕분에 이 문제를 해결한다고 생각한다. 너무 많다면, 메뉴를 단순화해야 한다.
"문제 해결," 저자가 단언했다.
이건 현대 스프레드시트에 대한 _1-2-3_의 가장 위대한 공헌 중 하나일 것이다. 지금도 살아 있다. 현대 스프레드시트를 하나 열고 직접 해보면 된다. A열에 1부터 5까지 입력하라. B2부터 수식 +$A1+A$2를 입력하고 몇 행 아래로 복사해보자. 숙련자라면 셀 참조에서 $ 기호가 그 참조의 행이나 열을 고정하고, 그렇지 않으면 참조는 상대적이라는 것을 안다.
이건 셀 참조에 대한 _VisiCalc_의 "전부 아니면 전무"식 접근보다 엄청난 발전이다. 수식을 넣고 다른 셀로 복사하면, _VisiCalc_는 수식의 모든 복사본 안에 있는 모든 셀 참조에 대해 사용자에게 "상대입니까, 고정입니까?"를 묻는다. 정말 성가시며, 그 수식을 어느 날 수정해야 하는 상황이 오면 Woz의 가호가 필요하다.
$ 방식은 훨씬 우월하다. 상대성을 수식 자체에 내장할 수 있게 해주기 때문이다. 그러면 셀을 가로질러 수식을 복사할 때 우리의 의도도 자연스럽게 함께 복사된다. 이해하기 쉽고 망치기 어려운 것, 내가 가장 좋아하는 조합이다.
비록 1-2-3 이외의 문서를 기본적으로 직접 열 수는 없지만, Lotus는 당대의 거물들로부터 데이터를 꺼내오는 데 도움이 되는 꽤 괜찮은 번역 도구를 제공한다. Stone Tools 관점에서 보면, 지금까지 내가 필요한 건 전부 처리해준다. _VisiCalc_와 _dBase_가 모두 포함되어 있고 광고한 대로 잘 작동하기 때문이다.
번역은 양방향이므로, dBase 데이터를 가져와 _1-2-3_에서 이것저것 만지다가 다시 _dBase_로 내보내는 것도 가능하다. 물론 몇 가지 주의점은 있다. 눈여겨볼 만한 것 중 하나는 "삭제된" 레코드다. _dBase_는 실제로 지우는 대신 단지 "삭제 표시"만 하고 .PACK 명령 전까지 , 그 플래그는 이동 과정에서 살아남지 못한다. 전체적으로 보면 작은 불편 정도다.
"VisiCalc on the Apple 2"의 돼지 사육 워크시트와 "_dBASE_ on the Kaypro II"의 CP/M 게임 데이터베이스는 둘 다 잘 번역되었다. 다만 데이터베이스에서는 내 불리언 필드 내용이 넘어오지 않았다. 모두 빈칸이었다.
최상위 메뉴에는 반짝이는 새 Graph 옵션이 있다. 바로 "1-2-3"의 "2"다. 내가 원하는 것은 정확하다. _dBase II_에서 가져온 게임 소프트웨어 장르의 원형 차트다.
여기에는 Release 2.4의 옵션이 보인다.
옵션은 직관적이고, 한계도 자명하다. 특히 "Ranges" 설정을 보라. 범위 X는 X축에 표시될 값 레이블을 설정한다. 범위 A부터 F까지는 그래프에 그릴 데이터 범위를 여섯 개, 오직 여섯 개만 정의한다. 끝이다. 나머지는 전부 "예쁘게 만들기"다.
내가 스스로 만든 타임캡슐의 범위 안에서, 지금까지 내 유일한 비교 대상은 _VisiCalc_와 그 복제작들이다. 그 렌즈로 보면 나는 _Lotus 1-2-3_에 감탄하지 않을 수 없다. 아니, 3-D 막대 그래프라니?! 내가 지금 _TRON_의 세계에 살고 있나?! 박수는 충분히 받을 만하다, Mitch. 브라보! 앙코르까지!
자, Kapor 씨, 잠깐만 실례하겠습니다. 독자들과 짧고 사적인 이야기를 좀 해야겠어요. 네, 죄송합니다만, 금방 끝납니다.
안녕하세요, 사랑하는 독자 여러분. Mitch는 우리 말을 못 듣죠? 안전하죠? 좋아요, 우리끼리만 말하자면, 저 그래프 도구는 좀 심심하지 않나요? 당시의 화면과 프린터에서 그래프를 최대한 예쁘게 보이게 할 수는 있지만, 정작 핵심 그래프 기능 자체는 다소 빈약하다.
아래는 _Google Sheets_가 내가 _1-2-3_도 만들 수 있기를 바랐던 원형 차트를 만드는 모습이다.
하지만 _1-2-3_는 이걸 할 수 없다. 엄격하게 숫자 값만 그래프로 그릴 수 있기 때문에, "genre" 같은 문자열은 빈 차트만 반환한다. _1-2-3_는 위의 _Sheets_가 하는 것처럼 데이터를 묶어 집계하는 것도 할 수 없다. 내 목표를 이루려면 다른 접근법을 찾아내야 한다. _(게다가 어쩌면DOSBox-X 버그를 발견한 것일지도?)
조각은 "폭발" 상태로 표시해 메인 원형에서 분리해 강조할 수 있다. 이 그리기 문제는 원형 차트 도구에서만 발생한다. 간단한 테스트에서 86Box에서는 이런 현상이 나타나지 않았지만, 다루기 훨씬 까다로운 시스템이다.
과거의 도구들이 2026년 기준에 못 미친다고 해서 "열등하다"고 판단하는 것은 공정하지 않다. 그래도 내가 하려는 일은 분명 많은 사업주들이 가장 먼저 해보고 싶어 했을 것 아닌가? 내가 아직 대중화되지 않았던 방식으로 데이터를 저장하고 있는 건가? 2026년형 내 뇌가 1991년의 분신을 불필요하게 더 힘들게 만들고 있는 걸까?
대체 각 고유 장르별 개수는 어떻게 그래프로 만들었을까?
좋다, 이제 복잡해질 테니 도식이 하나 필요할 것 같다. 이건 일반적으로 _Lotus 1-2-3_의 데이터 접근 방식, 데이터를 조작하는 방법, 질의하는 방법, 그리고 전반적으로 프로그램의 더 복잡한 기능들과 상호작용하는 방식에 대해 많은 것을 설명해준다.
이전 dBase 글에서 가져온 CP/M 게임 목록을 _dBase_에서 불러왔다고 하자. 여기서 장르가 "Simulation"인 모든 타이틀 목록을 뽑아내보자. 설명을 위해 전체 데이터의 일부만 사용해 화면에 다 들어오게 하고, /Data Query Unique 다시 말해 /dqu, 즉 악명 높은 DQU, 혹은 Query의 작은 도우미 를 실행한다.
워크시트는 단순히 데이터의 행과 열만 있는 곳이 아니다. 데이터와의 상호작용을 정의하는 제어 메커니즘 역할도 한다. 워크시트는 IV 열까지 256개 , 행은 최대 8192개다. 2,000,000개가 넘는 셀로 무엇을 할까? 진정한 _Dwarf Fortress_식으로, 우리는 영역을 나누고 1-2-3 식으로는 "ranges" , 그 영역들에 기능을 지정한다.
먼저, 주 테이블로서 데이터가 있고 맨 위에는 필드 이름이 있다. 그다음 질의 기준을 설정해야 한다. 이것은 워크시트의 별도 구역이며, 조회하려는 필드들과 그 아래 기준 정의를 넣을 공간으로 이루어진다. 작은 질의 요청 양식을 만드는 것처럼 생각하면 된다.
그다음 Lotus는 결과를 뱉어낼 장소가 필요하다. 다시 말해 데이터를 받아줄 작은 "양식"을 하나 더 마련해야 한다. 최종 데이터 수집에 관심 있는 필드 이름들을 여기에 넣는다.
그렇다면 가끔씩 재사용하고 싶은 질의가 여러 개라면? 듣기만 해도 고통스럽지만, 재사용하려는 질의마다 각각 별도의 질의 양식을 설정해야 한다. 즉, 관심 있는 필드 헤더를 워크시트의 새로운 구역에 다시 복사한다. 출력 범위를 위한 필드 헤더도 다시 복사한다. 새로운 질의 기준을 넣는다. 다시 추출한다.
워크시트를 계속 나눠, 재사용할 다양한 질의를 모두 각각의 작은 구역에 배치해야 한다. 이제 슬슬 라벨링을 시작하는 게 좋지 않을까? 머릿속으로 워크시트를 이렇게 나눠도 된다. "내 질의들은 여기, Q-타운에 살고" "내 결과들은 저기, Resultsville에 살고" 하는 식으로.
내가 처음에 말한 목표를 이루려면 게임 목록의 장르 고유 목록과 데이터 집합 안에서 각 장르의 개수가 필요하다. 앞 절에서 고유 장르 목록을 추출하는 방법은 알게 되었다. 개수를 세려면, @DCOUNT가 기준에 맞는 비어 있지 않은 모든 레코드를 세어준다. 여기서도 도식을 하나 그려보자.
__1-2-3__의 내장 문맥 도움말 시스템에 박수를 보낸다. @DCOUNT 사용법이 기억나지 않았지만, 입력하고 F1을 누르니 위에 보이는 파란 도움말 화면이 나왔다. 정말 훌륭하다!
"Genre"의 고유 값 목록을 추출하고 나면, 위 이미지의 E5..E12처럼 결과 열이 생긴다. E1..E2의 기준이 비어 있는 것에 주목하라. 아무것도 지정하지 않으면, 이는 모든 "Genre"와 일치한다는 뜻이다.
다음으로, 그 열을 @DCOUNT가 셀 수 있는 기준 형식으로 재구성해야 한다. 질의와 마찬가지로 기준은 세로로 인접한 두 셀로 이루어지며, 위쪽 셀은 필드 이름이고 아래쪽 셀은 매개변수를 담는다. 내가 세고 싶은 각각의 장르 바로 위에는 물리적으로 반드시 그 필드 이름이 있어야 한다.
/Range Trans는 세로 또는 가로 셀 범위를 거울 우주 반대편으로 전치한다. 내가 E16의 가로 목록을 만든 것이 바로 그 방법이다. 15행에 필드 이름을 /Copy해서 가로로 복사하니, @DCOUNT에 쓰기 딱 좋은 쌍들이 만들어졌다.
노란색으로 강조된 셀 수식은 본질적으로 G6..G13 전체에서 거의 같다. 각각 다른 기준 범위를 가리키도록 약간씩만 수정했다. 그것이 G열의 각 장르 개수를 계산해주고, E열에는 제목이 들어간다. 이제 내가 원했던 차트를 생성하는 데 필요한 것을 갖췄다 앞서 말한 원형 차트 그리기 버그는 제쳐두고 . 자, 여기 과거의 미래에서 온 영광스러운 3-D 그래프가 있다!
__Lotus PrintGraph__를 사용한 가상 출력물로 보면 이렇다 Y축 제목은 페이지에 다 못 넣었다 .
출력 품질이 어떻게 진화했는지 보이도록 Release 3.4에서 렌더링하면 이렇다.
짜증나게도, 이 모든 걸 알아내는 데 하루의 대부분이 걸렸다. 하지만 이제는 안다! 이걸 더 쉽게 만드는 방법만 있다면 좋을 텐데.
지금까지의 해결책에는 문제가 있다. 대부분은 질의, 결과, 변환, 데이터 등을 담아둘 물리적 공간을 어떻게 할당했는가로 귀결된다. 새로운 장르가 포함된 데이터를 가져오면, 새로운 결과 목록은 물리적으로 길어져 서로 겹칠 수 있다. 워크시트의 물리적 지도를 미리 계획하는 것이 우선 과제다.
시트를 만들어 나가는 일, 특히 셀 참조를 데이터 변경에 유연하게 유지하는 일은 번거롭다. 또한 새로운 시트 배치로부터 그래프를 생성하되, 단순한 단축키 하나로 하고 싶다. 모든 위대한 개발자처럼, 나도 게으르고 싶다.
약속된 게으름의 땅으로 가는 첫걸음은, 안타깝게도 "고된 작업"이다.
다행히 고된 작업은 캡처해 재사용할 수 있다. _Lotus 1-2-3_에는 블로그의 친구인 매크로가 있기 때문이다. _VisiCalc_에는 없었고, _1-2-3_의 구현은 너무나 강력해서 그것을 이해하고 길들이는 데만 여러 권의 책이 바쳐졌다. 잠재력을 암시하는 간단한 매크로 하나를 보자.
0:00
/0:07
사용자 정의 메뉴는 만들기 쉽다. 어떤 옵션을 선택하면 더 긴 자동화 작업을 트리거할 수 있고, 여러 단계의 과정을 단순화하거나, 혹은 단순한 도움말 메뉴 정도로도 사용할 수 있다.
매크로는 저장된다...
(이제 다 같이 말해보자)
...워크시트 안에. 맞다, 질의 관련 영지들로 워크시트를 나누기 위해 머릿속에 그려둔 그 지도, 다시 한 번 선거구를 조정해서 매크로 정의를 담을 공간까지 만들어야 한다. 사용자 정의 메뉴는 매크로 구조를 설명하기 쉬운 방식이다. 아래는 아주 멍청한 예시다.
내가 70년대 어린 시절에 기억하는 음식 세 가지는 carob, zucchini, rhubarb다.
A열의 텍스트는 대부분 워크시트와 생각을 정리하기 위한 주석이다. \m은 ALT + m으로 접근하는 매크로에 할당된 키보드 단축키를 뜻한다. menu1은 이름이 지정된 셀 범위에 대한 참조다.
이름 있는 범위는 _VisiCalc_에 비해 중요한 개선점이다. 한번 정의해두면, 범위를 기대하는 어디서나 그 이름으로 호출할 수 있다. 예를 들어 a2..a7 범위에 january 같은 이름이 할당되어 있다면, @sum(january)는 완전히 유효하다.
\m은 B1..B1로 정의된 범위다. menu1은 B3..B3으로 정의된 범위다. 범위는 매크로 정의의 첫 시작점만 가리키면 된다는 점에 주목하라. 매크로 실행은 주어진 열을 따라 셀을 순서대로 읽다가 첫 번째 빈 셀에서 멈춘다. \로 시작하는 범위 이름은 _1-2-3_에서 자동으로 매크로 키보드 단축키로 해석된다.
왼쪽에 사람이 읽을 수 있는 레이블을 두고, 그 바로 오른쪽 범위에 같은 이름을 붙이는 이 관례는 너무 흔해서 별도의 메뉴 단축키까지 있다. A열에 /Range Name Labels Right를 적용하면 B열 셀들이 A열 이름으로 자동 할당된다. 어느 정도까지는, 이름 있는 범위는 프로그래밍의 "goto"처럼 기능할 수 있다. 매크로에서는 "menu1이라는 이름의 범위로 이동해서 거기서부터 매크로 실행을 계속하라"는 뜻이다.
독자 중 프로그래머들은 이 "goto 라벨링"을 얼마나 사악하게 복잡한 방식으로 남용할 수 있을지 침을 흘리고 있을 것이다. {IF <condition>}을 통한 분기, {FOR <counter, start, stop, step, subroutine>}을 통한 반복과 결합하면 가능성의 공간은 한없이 넓어진다.
지난 글에서 dBase 작업을 하다가, 나는 의도치 않게 dBase 개발자가 되어버렸다고 적었다. dBase 스크립트 언어는 도트 프롬프트에서 입력하는 명령과 정확히 동일했기 때문이다. 하지만 _1-2-3_에서는 그렇게 운이 좋지 않다.
단순한 명령 문자열을 내보내는 매크로를 설정하는 것은 그리 어렵지 않고, 대체로 / 메뉴에서 내가 직접 입력할 방식과 비슷하게 읽힌다. Bank Street Writer의 매크로 접근법과 비슷하다. 예를 들어 /WCH~는 /를 실행해 슬래시 메뉴를 열고, (W)orksheet 메뉴로 들어간 뒤, (C)olumn 하위 메뉴로 가고, 마지막으로 (H)ide a column을 실행한다. ~는 엔터를 의미하므로, 이 시점에서 현재 커서 위치라는 기본 프롬프트를 확정한다. 그렇게 해서 현재 열 숨기기가 단일 키 입력으로 바뀐다.
또한 Learn 메뉴 도구도 있는데, 이것은 "지금부터 내가 하는 모든 키 입력을 기록하라"는 기능이다. 그 기록은 워크시트에 출력된다. 여기에 범위 이름을 붙이면 매크로로 변신한다. 아주 좋다!
그렇긴 하지만, 1-2-3 매크로는 금세 난이도 0에서 100으로 치솟고, 시각적으로 해석하고 추론하기가 어렵다. 슬래시 메뉴의 모든 명령에 극도로 친숙해야 하고, 매크로 전용 { } 어휘도 알아야 한다.
__Lotus Magazine: The Macro Book__에서 발췌.
Lotus도 상황이 금방 험악해질 수 있다는 걸 알았고, 이를 이해하기 쉽게 돕는 디버깅 도구를 추가했다. ALT-F2를 누르면 STEP 모드로 들어가며, 매크로를 한 줄씩 실행한다. 화면 하단 상태 막대가 지금 무엇이 실행되는지 설명해주므로, 뭔가 잘못되었을 때 누구를 탓해야 하는지 알 수 있다.
좋다, 이제 아까 논의했던 질의와 @DCOUNT 절차를 단순화하는 매크로를 파고들어 구현할 준비가 되었는가? <손가락 마디를 꺾으며>
음, 나는 아니다. <다시 손가락을 반대로 꺾어 뻣뻣함으로 되돌림> 매크로 시스템은 Baby's First Macro™ 수준을 넘어서면 어떤 통제감이나 숙련감을 느끼기엔 너무 복잡하다는 것이 드러났다. 몇 주만 더 공부하면 목표를 이룰 수 있을 것 같다.
하지만 안타깝게도, 이 글에서는 내가 패배했다.
"1-2-3"의 "3"인 _1-2-3_은 데이터베이스로 기능할 수 있다. 아주 단순하고 제한적인, 한 행이 하나의 레코드이며, 최대 8192개 레코드, 최대 256개 필드, 평면형 데이터베이스다. 솔직히 말해서, 많은 경우 그 정도면 충분하고도 남는다.
앞서 질의 예시는 보여주었고, 여기서는 그것이 가장 화려한 기능이다. 최대 두 개 키로 레코드를 오름차순/내림차순 정렬하고, 값을 찾고 바꾸며, 검색 질의에 맞는 레코드를 찾고, 그 레코드들을 스프레드시트의 다른 구역으로 추출할 수 있다. 그리고 그게 전부다 적어도 Release 2.x에서는 .
0:00
/0:52
장르별로 _dBase II_ 데이터를 정렬하는 모습.
내가 이 측면을 너무 짧게 다루는 것처럼 보일 수도 있지만, Lotus도 마찬가지였다. Release 2.2 공식 매뉴얼에서 매크로에는 300페이지가 할애되었다. 데이터베이스 기능에는 50페이지뿐이었고, 그중 첫 20페이지는 더미 데이터를 입력하는 방법 설명이었다. 정렬, 질의, 찾기, 추출, 즉 데이터베이스 작업의 핵심은 총 20페이지밖에 받지 못했다.
유용한 기능이고, 이 자리에 있어서 기쁘다. 내 빈약한 요구 대부분은 처리하기에 충분하다. 그 이상으로는 말할 것이 많지 않다. 다만 그 유산은 언급할 만하다. _VisiCalc_를 5분만 만져본 사람이라면 누구나 떠올렸을 법한 발상이므로, 그 발전은 필연적으로 느껴진다. 오늘 밤 _Excel_에서 데이터베이스 작업을 하게 된다면 _1-2-3_를 위해 촛불 하나 켜주길.
오늘날 우리가 "플러그인"이나 "확장 기능"이라 부를 것을 Lotus는 "add-ins"라고 불렀는데, _1-2-3_의 매우 좋은 기능 중 하나가 바로 이것이다. _1-2-3_은 몇 가지 add-in과 함께 출하되었다. 예를 들어 하나는 매크로를 메모리 상주형으로 확장해 여러 워크시트에서 사용할 수 있게 했다. 보통은 워크시트 안에서 정의된 매크로만 그 워크시트가 접근할 수 있다.
정말 _VisiCalc_는 _1-2-3_의 기발함에 계속 추월당하고 있는 느낌이 아닌가?
add-in 시장의 상태를 다룬 PC Magazine 기사에 따르면, 많은 비즈니스 사용자들은 하루 종일 1-2-3 안에서 살았고, 그 안에서 모든 것을 하고 싶어 했다. 서드파티 add-in 애프터마켓은 기꺼이 그 욕망을 상품화했다.
자동 저장/백업 유틸리티나 산업별 분석 도구 같은 당연한 아이디어 외에도, add-in은 _1-2-3_를 거의 무엇으로든 바꿔놓을 수 있었다. 완전한 워드 프로세서, 복잡한 그래프 요구를 위한 전체 그래픽 서브시스템 교체, 전문가 시스템 로직, 비선형 함수 해법기까지 프로그램 안에 주입되었다. Oracle은 _1-2-3_의 포근한 보안 담요 안에서 자사 외부 SQL 데이터베이스에 연결하는 방법까지 제공했다.
더 적은 메모리의 시대에서 태어난 Lotus의 접근은 짜증나면서도 유용하다. add-in은 기본값은 아니지만 앱 시작 시 함께 로드될 수 있다. 그리고 확장된 기능에 접근하려면 add-in을 하나씩 "활성화"해야 하며, 다른 add-in이나 더 큰 워크시트를 위한 공간을 만들려면 "비활성화"해야 한다. 나는 메모리가 충분하니 문제는 없지만, 512K 시스템에서는 수동 메모리 관리가 실제 생활이었다는 점을 상상하기는 쉽다.
매크로와 add-in을 합치면 _1-2-3_는 _dBase_나 _HyperCard_처럼 그 자체로 하나의 생태계가 된다. 다만 Lotus의 접근에서 마음에 들지 않는 점은 사용자 경험을 둘로 갈라놓을 수 있다는 것이다. 그것은 그들의 WYSIWYG add-in에서 특히 선명하게 보인다.
WYSIWYG 모드의 기본 구성은 못생겼다. 나는 "Relief" 색상 구성으로 바꿨다.
Release 2.3과 함께 Lotus는 이 add-in을 넣었다. 텍스트 인터페이스에서 OS/2, Windows, Mac GUI 인터페이스의 번쩍임과 현란함으로 넘어가던 세계를 돕기 위해서였다. GUI를 부러워하는 사람들을 위한 DOS였고, 솔직히 나는 별로였다. 우아하게 통합되어 있지 않고, 굼뜨게 느껴지며, 프로그램 사용을 더 어렵게 만든다.
WYSIWYG를 활성화하면 애플리케이션이 터미널 모드에서 그래픽 모드로 전환된다. 그래서 DOSBox-X 사용자 입장에서는 벌써부터 아름다운 TrueType 텍스트를 잃게 되어 짜증이 난다. 그건 Lotus 탓은 아니지만, 블로거에게도 기준은 있다.
가장 큰 사용성 문제는 프로그램 기능이 둘로 갈라진다는 점이다. / 메뉴는 예전처럼 작동하지만, WYSIWYG 관련 모든 것을 위한 새로운 : 메뉴도 생긴다. 그래서 어떤 메뉴 명령을 사용하려 할 때마다, 그 명령이 어느 메뉴에 들어 있는지 기억해야 한다. 많은 : 옵션은 얼핏 보면 / 메뉴의 대응 항목과 같아 보이지만, 그 기능의 WYSIWYG 전용 매개변수를 제어한다. 대개는 그렇다.
오른쪽 위에는 우리가 어떤 메뉴 모드에 있는지가 표시된다. 이것은 표준 / 메뉴다. Set-Width는 메뉴 두 번째 줄 설명 그대로 동작한다 보라, 좋은 기능이다! . Column-Range도 같은 일을 하지만 여러 열에 한 번에 적용한다.
이상하게도 : 메뉴 아래에서는 Set-Width 기능이 중복되어 있는데, 두 개의 / 메뉴 옵션을 합친 형태로 바뀌어 있다.
그렇다고 이 add-in이 셀 스타일링이나 그래프를 워크시트 안에 직접 넣는 데 쓸모없다는 뜻은 아니다. 결국 문서를 보기 좋게 만드는 일은 중요하다. 설령 Q3 전망 차트가 암울한 미래를 예고하더라도, 상사는 깊은 인상을 받아야 한다. 특히 그럴 때야말로 아마 더 그렇겠지!
Release 3은 WYSIWYG를 본격적으로 받아들여 add-in 없이도 유일하고 주된 인터페이스로 삼았다. 아마 그래서 내가 자꾸 2.x 릴리스로 돌아가게 되는 것 같다. 내가 완고한 노인이라서 그렇다고 할 수도 있겠지만, 최근 Hacker News 군중이 TUI 인터페이스를 다시 끌어안는 모습을 보면, 적어도 나는 좋은 동료들 사이에 있는 듯하다.
이 부분을 나는 2월 22일에 쓰고 있다. 이틀 전, "Pi for Excel: AI sidebar add-in for Excel"이라는 프로젝트가 공개되었고 Hacker News에서 꽤 좋은 반응을 얻었다. 내가 그 XPER 칼럼에서 언급했듯, 지금의 "AI" 붐은 가장 크지만 첫 번째는 아니다. 영어 상호작용은, 처음에는 키보드로, 그리고 기술이 우리의 바람과 꿈의 예상 경로를 따라 계속 발전한다면 언젠가 목소리로도, 다양한 프로그램의 add-in 형태로 이미 존재했다.
특히 데이터베이스는 그런 실험의 두드러진 표적이었다. _dBase_의 사용자 인터페이스가 얼마나 영어다운지 생각해보면, 개발자들이 진짜 영어에 더 가까운 무언가가 손닿을 곳에 있다고 느낀 이유를 이해하기 어렵지 않다. Symantec의 _Q&A_는 자연어 "Intelligent Assistant"를 아예 내장하고 있었다. R:BASE는 CLOUT add-in으로 그 시도를 했고, 사용자가 "어느 창고가 계획보다 더 많은 빨간색과 초록색 argyle 양말을 출하했는가?"라고 질의할 수 있다고 약속했다. 스프레드시트 _Silk_는 도구를 영어로 제어할 수 있는 기능을 내장했다고 내세웠다.
이 글 초반의 자사 잡지들처럼, Lotus도 이 영어 파서 파티를 놓치고 싶지 않았다.
살인적인 악당의 이름을 제품에 붙이는 건 좋은 생각일까? 댓글로 의견 바란다!
(이 탐구를 위해 나는 R2.01로 내려가야 한다)
1986년 말 US$150에 출시된 _HAL_은 _1-2-3_를 감싸는 메모리 상주형 래퍼다. 우리는 _HAL_을 직접 실행하고, _HAL_이 다시 _1-2-3_을 실행한다. 광고는 그 장치를 충분히 잘 설명한다. "Lotus _HAL_은 간단한 영어 구문을 사용해 1-2-3 작업을 수행할 수 있게 해줍니다." 내가 초반에 본 모습은 솔직히 꽤 마법처럼 느껴질 때가 있다. 월별 열 머리글을 얼마나 쉽게 만드는지 보라.
0:00
/0:22
이건 꽤 멋지다. 부정할 수 없다.
마찬가지로 지루한 작업들도 _HAL_에게 무거운 짐을 맡기도록 "요청"하면 훨씬 쉬워진다고 약속한다. 여기서는 빠른 튜토리얼을 따라 _HAL_에게 스프레드시트 전체를 만들게 하고 있다. 나는 수식을 한 번도 직접 만지지 않는다. 의도만 설명한다.
0:00
/1:14
HAL은 어떤 단어든 처음 세 글자만 인식한다. "Name"도, "Names"도, "Namaste"도 전부 같은 것으로 취급된다. 선의는 있지만 조금 어수룩한 HAL에게는 말이다.
당시의 다른 영어 비슷한 언어들과 마찬가지로, 이것도 후한 의미에서만 영어다. 결국 우리는 _1-2-3_만의 특정한 방언과 어휘를 배우고 있는 셈이다.
PC Magazine 1987년 2월호의 HAL 리뷰는 표지 기사였는데, 이렇게 썼다. "_HAL_에는 250페이지 분량의 매뉴얼이 포함되어 있다. 이 매뉴얼은 1-2-3 매뉴얼만큼이나 읽는 것이 중요하다. 모든 명령은 어떤 명령줄 인터페이스의 문법만큼 엄격하게 설명되어 있다." "영어"로 _HAL_과 대화하는 법을 설명하는 데 250페이지짜리 매뉴얼이 필요하다는 사실은, 오히려 그 존재 자체에 대한 반론이 될 수도 있지 않을까?
DOS의 기본 640K 안에는 두 프로그램이 동시에 들어가야 하므로, 이것은 오늘날 소프트웨어가 너무 비대해졌다고 생각하는 사람들에게 꽤 좋은 역사적 증거이기도 하다. 업계를 정의한 스프레드시트가 그래프와 현대의 기대에 가까운 데이터베이스 기능, 온라인 도움말 시스템, 자연어 인터페이스까지 모두 갖추고 함께 돌아가는데, RAM 1MB도 채 안 된다.
바로 이것이 내가 바라던 레트로 컴퓨팅 도파민이다!
_HAL_은 _1-2-3_의 기본 도구에 영어 인터페이스만 제공하는 것이 아니라, Release 2.01의 모래상자에 자기만의 독특한 장난감도 가져온다. 여기서 릴리스 버전을 꼭 강조해야 하는데, 그 이유는 일부 도구가 나중에 시간이 지나며 제품 본체에 편입되었기 때문이다. 그래도 _HAL_은 열심히 친구가 되어주려 했다.
BACKSPACE라는 점은 조금 위험하다.
왼쪽의 그 HAL은 전혀 아니지만, 그렇다고 오른쪽의 그 Hal도 완전히 아닌 것 같다.
비록 _HAL_이 _1-2-3_를 제어하긴 하지만, 인터페이스는 여전히 덧붙여 놓은 느낌이 난다. \를 누르면 HAL 대화 상자가 뜨는데, 기억하기 어렵진 않지만 결코 자연스럽게 느껴지지 않는다. HAL 요청 대화 상자를 화면에 계속 남도록 설정한 뒤에도 마찬가지다. 때로는 메뉴 옵션을 탐색한 뒤 저절로 꺼지기도 하고, 요청 상자가 내가 일반 슬래시 메뉴로 하려던 명령을 가로채기도 한다. 생각했던 것보다 더 자주 방해가 되고, "원할 때는 있고" "원치 않을 때는 없는" 균형점을 찾지 못했다.
_PC Magazine_도 _HAL_이 다소 엉성한 임시방편이라고 느꼈다. Charles Petzold는 리뷰에서 이렇게 썼다. "_HAL_은 정말 _1-2-3_의 자연어 인터페이스인가? 유용한가? 컴퓨터 산업을 혁신할 것인가? 메뉴는 죽었는가? 내 대답은 이렇다. 꼭 그렇진 않다. 종종 그렇다. 제발 좀. 절대 아니다."
이 모든 것은 학문적 이야기일 뿐이다. Lotus가 _HAL_을 죽였기 때문이다. 판매 수치를 찾기는 어려웠지만, Raymond Chen의 글에서 1986년 12월 Softsel Hot List의 한 장면을 엿볼 수 있다. _HAL_은 상위 10위 안에 들었고 다른 미래 블로그 주제들과 함께 , 이전 3주 동안 차트를 타고 올라가고 있었다. 반면 이것은 Release 1A부터 2.01까지만 제공되었고, WYSIWYG 이전 릴리스들 전용이었다. 그리고 다시 돌아오지 않았다.
앞서 나는 매크로를 건드려 보며 "장르별 개수" 차트를 더 쉽게 만들고 싶었지만 실패했다. 그러다 HAL이라면 대신 해줄 수 있을지도 모른다고 곰곰이 생각하게 되었다. 놀랍게도 HAL은 할 수 있다. 자기만의 특수 어휘인 "tabulate"를 통해서 말이다. 이전에 내가 도식으로 설명했던 복잡한 작업들이 너무나 간단해져서, 사실 매크로조차 필요 없을 정도다 만들려면 만들 수는 있지만 . 이 80년대의 마법을 보라.
0:00
/0:22
원래는 F6로 HAL 요청을 실행하면, 작업을 완료하기 위해 HAL이 조합한 1-2-3 명령들을 시스템이 출력해줘야 한다고 한다. 말하자면 _HAL_의 뇌 속을 들여다보는 것이다. _HAL_이 생각하는 걸 지켜보면, 내가 앞서 질질 끌며 처리한 잡일을 더 잘 하는 방법을 가르쳐줄 수도 있지 않을까?
내 "_1-2-3_ 실력 향상을 위한 기묘한 한 수"는 여기까지인 모양이다.
1962년의 _Diffusion of Innovations_에서 저자 Everett Rogers는 기존 문제에 대한 새로운 해결책을 사람들이 채택할 때 고려하는 다섯 가지 특성을 설명했다. _VisiCalc_가 "기존 문제"였다면, _Lotus 1-2-3_는 "새로운 해결책"으로서 자신을 얼마나 잘 설득했을까?
VisiCalc 글에서는 현대 스프레드시트에 얼마나 많은 유전자가 남아 있는지 이야기했다. 이제 나는 _Lotus 1-2-3_에도 똑같이 그런 주장을 펼칠 수 있음을 안다. 내 식으로 표현하자면, _VisiCalc_는 오늘날 우리가 기대하는 스프레드시트의 "외형"을 기여했고, _1-2-3_은 그 "감각"을 기여했다. _VisiCalc_가 숫자를 다루는 사람들의 삶을 바꿨다면, _1-2-3_은 자신을 비즈니스를 위한 엔진으로 자리매김했고, 그 비전을 거의 완벽하게 실행했다.
지난 몇 주 동안 _1-2-3_을 알아가면서, 이제 나는 "알겠다"고 말할 수 있다. 왜 그토록 떠들썩했는지 보이고, 솔직히 말하면 나는 개종했다. 미안해, VisiCalc. 내가 널 사랑하는 건 알지! 하지만 다음에 스프레드시트를 집어 들 일이 있다면, 나는 _1-2-3_을 집어 들 것이다.
사용 경험을 개선하는 방법, 눈에 띄는 결함, 우회책, 그리고 가능하다면 현대적 워크플로에 이 소프트웨어를 통합하는 데 관한 메모.
mount c <path to lotus install>를 autoexec.bat에 넣어 실행 시 자동 마운트.CPU Core > Normal, CPU Type > 286을 명시적으로 설정하기 전까지는 실행되지 않았다.Lotus.exe는 실행했지만, Release 2.3과 2.4에서는 실행하지 못했다. 123.exe는 문제 없이 실행되고 동작한다. Lotus.exe는 GraphPrint 같은 보조 프로그램을 실행하는 프런트엔드 유틸리티다.물론 무엇을 하려는지에 달려 있다. 비즈니스 작업에서는, 여러분이 CEO라서 "좋아요 여러분, 우리 이제 다 같이 DOS로 전환합니다"라고 명령할 수 있는 경우가 아니라면, 협업에 잘 맞지 않는다. 개인 프로젝트라면, 그래프 기능을 제외하면 많은 일반적인 요구를 충족하고 그리 큰 타협처럼 느껴지지도 않는다. DOS 버전은 마우스 제어도 지원하고, 언제든 WYSIWYG 모드를 켜서 현대적인 느낌을 흉내 낼 수도 있다.
그리고 다행히 Y2K 호환성도 있다. Release 1.0조차도 2099년까지의 날짜를 지원한다. 21세기에도 그 정신을 여전히 살아 숨 쉬게 만드는 또 하나의 _1-2-3_의 선견지명에 잠시 묵념과 감사의 시간을 갖자.
모든 것이 여기서 시작된다.
Release 2와 함께 진지한 사람들이 진지한 하드웨어로 진지한 일을 하고 있다.
__1-2-3__의 최소 하드웨어 요구 사항은 시간이 지나며 충분히 커져서, 많은 2.x 사용자들을 완전히 버리게 되었다. Intel은 그 간극을 현금화할 준비가 되어 있었다.
__HAL__은 아주 좁은 의미의 "작업"에 대해서는 _1-2-3_ 작업을 더 빠르게 해준다.
내 최종 분석에서 __1-2-3__는 비즈니스 엔진에 가깝다고 썼는데, 그 후에야 이 광고를 발견했다. 제품의 의도된 목표가 바로 그것이라고 노골적으로 말하고 있었다.
조사하다가 이것도 발견했다. "Multi-Tool family of programs"라는 말은 처음 들었는데, 오늘 알게 된 사실은 __Microsoft Word__의 원래 이름이 "Multi-Tool Word"였다는 점이다.
그들이 "분명히 가장 빨랐다"고 한 것은 농담이 아니었다. __Excel__은 최대 500% 더 빨랐다. __1-2-3__의 날수는 정해져 있었다.