거의 완벽한 인공물은 조금씩만 개선된다: APL은 영어보다 프랑스어에 가깝다

거의 완벽한 인공물은 조금씩만 개선된다: APL은 영어보다 프랑스어에 가깝다 Alan J. Perlis 교수 Yale University  

나는 ALGOL의 배교자다. ALGOL 계열의 프로그래밍 언어를 배우며 자랐지만, 나는 꽤 늦은 나이에 APL의 영향을 받게 되었다. 인생의 늦은 시기에 흥미로운 것에 발을 들이는 사람은 누구나 그렇듯, 사람은 아주 빠르게 자기 역량을 넘어가려는 경향이 있다. 내가 어떻게 APL의 영향을 받게 되었는지 이야기하는 것이 흥미로울지도 모른다. 여러분 중에도 같은 길을 걸어온 사람이 많을 것이기 때문이다.

나는 영국 Newcastle의 한 모임에 있었는데, 나와 함께 Stanford의 Don Knuth, IBM의 Ken Iverson, 그리고 몇몇 다른 사람들도 강연자로 초청받았다. 나는 청중석에 앉아 있었고, 컴퓨터 과학과 계산 분야에서 매우 존경받는 두 사람 사이에 끼어 있었다. 한 사람은 Munich 본부에서 Bavaria의 계산 업무를 이끌던 Fritz Bauer였고, 다른 한 사람은 Holland 본부에서 전 세계의 계산 업무를 이끌던 Edsger Dijkstra였다.

Ken은 슬라이드를 보여주고 있었고, 그중 한 슬라이드에는 나중에 내가 APL 한 줄짜리라고 알게 된 것이 들어 있었다. 그는 이것을 APL 표기법의 표현력을 보여주는 예로 가볍게 던졌다. 그 한 줄짜리는 대수식에서 괄호의 중첩 수준을 나타내는 표준적인 예 중 하나였던 것으로 기억한다. 하지만 그것은 열 글자쯤의 아주 짧은 한 줄이었다. 나는 그런 것을 오랫동안 프로그래밍해 왔고, 그것에 상당한 양의 코드가 필요하다는 것을 알고 있었기에 그것을 보고 말했다. “세상에, 이 언어에는 분명 뭔가가 있군.” 내 왼쪽의 Bauer는 그것을 보지 못했다. 그가 보고 들은 것은 APL이 대수를 가르치기에 몹시 적합한 언어라는 Ken의 말이었고, 그는 내가 결코 잊지 못할 말로 내게 낮게 중얼거렸다. “내가 살아 있는 한, Munich에서는 절대로 APL을 쓰지 않을 겁니다.” 내 반대편에 앉아 있던 Dijkstra는 Bauer 쪽으로 몸을 기울여 말했다. “Holland에서도 마찬가지입니다.” 우리 셋은 같은 강연을 듣고 있었지만, 분명 서로 다른 것을 들었다.

그때 나를 APL로 끌어들인 것은, 아마도 APL을 통해 우리가 자연언어에서 숭상하는 프로그래밍의 몇몇 차원을 얻기 시작할 수 있으리라는 느낌이었다. 즉 구성의 즐거움, 우아하게 말하는 즐거움, 간결하고 시적이며 예술적으로 말하는 즐거움 말이다. 바로 그런 점이 우리의 자연언어를 그토록 소중하게 만든다. 프로그래밍의 그 측면은 내가 오래전부터 관심을 가져 왔지만, FORTRAN, ALGOL, PL/I 계열 언어를 경험하면서는 가까이 다가갈 만한 수준조차 찾지 못했던 것이었다. 그런 언어에서는 프로그래밍이 사실상 배관 작업이라는 점이 분명했다. 사람은 복잡한 물건을 만들고 있었으며, 주된 문제는 그저 물에 빠지지 않고 고개를 내미는 것이었다. 그러나 그런 언어로는 고개를 물 위로 내미는 일 자체가 너무 어려워서, 프로그래밍에 쓰는 언어의 이 측면은 결코 수면 위로 떠오르지 못한다. 당시 Ken의 말을 들으며, 그리고 전에도 그에게서 들은 적이 있었지만, 그 순간 내게는 오직 계시라고만 부를 수 있는 것이 찾아왔다.

나는 1963년 Princeton에서 열린 프로그래밍 언어 회의에서 Ken의 강연을 들었고, 그는 APL에 관해 이야기했다. 그러나 그때 APL은 어떤 컴퓨터에서도 실행되고 있지 않았으며, 그는 그것이 컴퓨터에서 실행될 필요는 없다고 단호하게 주장했다. 그것은 그에게 알고리즘 개념을 표현할 수 있는 표기법이었고, 당시 그에게는 그것으로 충분해 보였다. 실제 컴퓨터에서 프로그램을 작동시키는 데 관심이 있던 우리에게는 그것이 한참 모자라는 이야기처럼 보였다. 몇 년 뒤, 하늘의 별들이 유리하게 결합한 덕분에, 즉 매우 훌륭한 프로그래머들, Harvard가 Ken에게 종신 재직을 주지 않아 그가 IBM으로 간 일, 360이 उपलब्ध했고 사람들은 그것으로 시분할을 할 수 있어야 한다고 생각한 일 덕분에, 재능 있는 프로그래머들과 Ken, Adin Falkoff, 몇몇 다른 사람들의 존재, 그리고 360의 결합이 우리 모두에게 APL을 가져다주었다. 그리고 오늘날 우리는 APL이 그러한 결합 때문에 지금의 모습이 되었다는 점을 모두 깨달아야 한다고 생각한다. APL이 실행되던 시스템은 시분할이 극도로 불안정한 활동이던 시절에도 사람들이 합리적인 운영 연속성을 실제로 믿을 수 있을 만큼 견고하게 안정적이었다. 최초의 360 구현으로 대표된 언어, 그리고 IBM 밖에서 그 언어를 잠수함처럼 퍼뜨린 열렬한 신도들의 집단도 있었다. 당시 IBM은 마땅히 그래야 했던 것만큼 수용적이지 않았기 때문이다. 하지만 그것은 줄곧 IBM의 역사였다. 모든 대기업과 마찬가지로 IBM은 사후적 지혜를 많이 지니고 있다. 그러나 그것은 우리, 특히 IBM에서 일하는 여러분이 언제나 다음 사실을 의식해야 한다는 뜻이다. IBM은 좋은 생각을 받아들일 수 있지만, Goliath의 관성을 이겨 내는 데는 시간, 아주 많은 시간이 든다.

이제 APL을 언어로 보는 문제로 돌아가 보자. 나는 사람들과 이야기할 때 끊임없이 놀란다. 돌이켜 보면 놀랄 일도 아니지만, 내가 APL에 관해 이야기하면 마치 우리가 서로 다른 두 가지, 즉 그들의 APL상과 나의 APL상에 관해 말하고 있는 듯하다. 여러분의 심포지엄 논문을 보면, 여러분 중 다수가 내게는 전혀 흥미롭지 않은 APL의 측면에 관심을 두고 있고, 나 역시 아마 여러분에게는 전혀 흥미롭지 않을 측면에 관심을 둔다. 그것은 무엇을 뜻하는가? 내 생각에 그것은 APL이 언어로서 좋은 풍부한 언어에서 기대하는 일종의 완결성에 다가가고 있다는 뜻이다. 언어를 가치 있게 여기는 크고 지적이며 유용한 사람들의 집단들이 존재하고, 그들이 공유하는 관심사의 교집합은 거의 공집합에 가깝다. 그것은 나쁜 일이 아니다. 나는 그것이 좋고 필연적이라고 생각한다. 그리고 APL의 미래 발전을 마련하려 할 때 우리는 아마도 그 과제가 엄청나게 어렵다는 사실을 발견하게 될 것임을 보여준다. APL을 쓰는 우리는 너무나 많은 서로 다른 길에서 그것에 접근하고, 언어가 어떻게 변해야 하는가에 관해 너무나 많은 서로 다른 지점에 관심을 두기 때문이다. 어떤 의미에서는 언어가 이토록 훌륭하고 아주 천천히 변한다는 것이 매우 다행이다. 프로그래밍에 종사하는 우리는 세월이 흐르며 한 가지 사실을 확실히 알게 되었다. 사람들은 나쁜 언어나 불완전한 언어로 프로그래밍하는 것을 개의치 않는다. 거기서 유용한 작업과 약간의 즐거움을 얻는 한, 훨씬 더 나은 언어적 수단이 있어도 그 언어를 계속 써야 한다는 온갖 합리화를 찾아낼 것이다. FORTRAN이 번성한다는 사실이 그 증거다. 나는 프로그래밍 언어 자체에 관심 있는 사람 중 FORTRAN의 영향력과 사용이 계속 커지고 있다는 점 외에 그것을 좋게 말하는 사람을 거의 모른다. 그러나 그것은 어떤 언어에 대해서든 대단히 좋은 평가다. 물론 FORTRAN에 일어난 일은 그것이 계산 세계의 공통어가 되었다는 것이다. 모든 사람이 어느 정도의 세부 수준까지 이해하는 유일한 언어이며, 모든 나라의 모든 컴퓨터에 있고 모든 제조사가 만든다. 지구 표면의 모든 언어로 쓰인, 모든 복잡도 수준의 책을 읽으며 FORTRAN 사용법을 배울 수 있다. 그것은 우리가 숨 쉬는 공기처럼 보편적이며, 앞으로도 오랫동안 대체되지 않을 것이라고 생각한다. 그것이 대체되지 않을 이유 중 하나, 어쩌면 대체되어서는 안 될 이유는 FORTRAN이 모국어와 같은 새로운 프로그래머 집단이 언제나 생겨나기 때문이다. FORTRAN 50줄만큼 잘하는 APL 한 줄짜리를 그들 앞에 던져 놓아도 아무 소용이 없다. 우선 사람들은 그 한 줄짜리를 사용하는 법을 배우는 데 오랜 시간이 걸리고, 그것을 쓰는 데는 더 오랜 시간이 걸릴 것이다. 따라서 FORTRAN은 계속 성장하고 성공할 것이다. 그리고 나는 APL이 그 지위를 빼앗으리라고 생각하지 않는다. 그럴 이유도 없다. APL을 쓰는 사람들이 나서서 “우리가 이토록 소중하고 우아하며 내게 큰 즐거움을 주는 것을 여기 갖고 있는데, 왜 당신들 바보들은 이런 열등한 언어적 수단을 쓰는가? 어떻게 그렇게 눈멀고 어리석을 수 있는가?”라고 말하는 것이 목표가 되어서도 안 된다. 여러분은 그 논쟁에서 결코 이기지 못하며, 시도해서도 안 된다고 생각한다.

오늘날 APL이 거의 완벽한 도구이므로 그것을 완벽하게 만들자는 이야기가 매우 많다. 우리는 성공하지 못할 것이다. 단순한 이유는 우리 모두에게 APL이 성숙이나 완성에 이를 수 있는 길이 너무나 많이 다르기 때문이다. 단 하나의 길은 없다. 어떤 사람들은 가장 중요한 현안이 APL의 자료 구조를 개선하는 것이라고 말한다. 다른 사람들은 APL에 필요한 것은 약간의 Franglais, 즉 우리의 용어로 APLGOL이라고 말한다. “APL에 while문이나 if-then-else나 for문만 있었다면, 그토록 완벽한 언어가 되었을 텐데.” 터무니없는 말이다. APL에 배열의 배열이 있으면 우리의 모든 문제가 사라질 것이라고 말하는 것도 어리석다. 실제로는 그런 일이 일어나면 문제의 양이 거의 지수적으로 늘어날 것이다.

그럼에도 이 방향과 다른 방향으로 언어를 확장하려 시도하는 일은 중요하다. 그리고 내가 무슨 말을 하든, 여러분이 무엇을 하든 사람들은 그렇게 할 것이다. IBM 내부에서 이루어지지 않으면 다른 곳에서 이루어질 것이다. 언어를 վերց고 오늘 몇 가지를 바꾸고 내일 몇 가지를 더 바꾸면 사람들을 무지개 끝의 황금 단지로 이끌 수 있다고 믿는 일에는 엄청난 매혹이 있기 때문이다. 우리 중 많은 이가 잊는 것, 물론 결코 잊어서는 안 되는 것은, 단계별 프로그래밍이 언젠가는, 어떻게인지는 알 수 없지만, 적어도 사물을 하는 방법에 대한 처방을 내리는 일과 관련되는 한 우리의 생각을 보편적으로 표현할 수 있는 지점에 도달해야 한다는 사실이다. 프로그래밍은 사고다. 아직 모든 사고는 아니며, 어쩌면 결코 모든 사고가 아닐 것이다. 그러나 컴퓨터 앞에 앉았을 때 프로그래밍하기 전에는 결코 떠올리지 못했던 수많은 매력적인 가능성과 마주하게 되는 한, 우리는 우리가 가진 프로그래밍 언어에 불만을 느낄 것이다. 여기에는 지금까지 만들어진 모든 언어와 앞으로 나올 언어가 포함된다. 앞으로도 다른 언어들이 나올 것이다. 따라서 APL이 어떻게 바뀌어야 한다는 나의 견해는 필연적으로 여러분의 견해와 다를 것이다. 그리고 그럴 이유가 없지 않다. APL에서 내게 흥미로운 것들이 반드시 여러분에게도 흥미로운 것은 아니며, 바로 그것이 이 언어를 그토록 영광스럽게 만든다고 생각한다.

교수로서 내가 관심을 두는 일 중 하나는 사람들에게 프로그래밍하는 법을 가르치는 것이다. 하지만 그것은 단순히 프로그래밍하는 법을 가르치는 것 이상이다. 사람들에게 프로그래밍하는 법을 가르치려는 목적이라면 어떤 프로그래밍 언어든 충분하기 때문이다. 오직 하나의 언어 또는 어떤 특정 언어만이 프로그래밍이 무엇인지 배우는 데 결정적이라는 생각은 틀렸다. 목표가 사람들에게 프로그램을 만드는 법을 가르치는 것이라면 BASIC으로도 완벽히 충분하다. 거기서는 할 수 없는 일들이 있고, 따라서 그것을 하기 위한 구성을 발명하게 되며, 그 구성을 발명하는 일이 프로그래밍을 배우는 것이다. 머지않아 모든 언어에서 우리는 언어의 구성 요소를 가지고 힘들고 고되게 만들어 낸 구성으로 나아가야 한다. 그리고 언어에 그것들이 처음부터 없다는 사실을 저주한다. 그러나 그것들은 지금도 모두 있지 않고, 앞으로도 결코 모두 있지 않을 것이다. 내가 프로그래밍과 연관시키는 단어, 그리고 모두가 프로그래밍과 연관시킨다고 확신하는 단어는 “좌절”이다. 모든 것은 가능하고, 아무것도 쉽지 않다. 우리는 프로그램을 쓰기 위해 앉고, 우리의 처음 아름다운 생각은 곧 사용할 수 없는 구성이라는 진창에 빠져든다. 우리는 프로시저나 함수나 그 밖의 것을 쓰고, 더 많은 함수를 쓴다. 자료 구조를 발명하고, 더 많은 자료 구조를 발명한다. 처음에는 그렇게 멋지고 우아했던 프로그램은 곧 수렁에 빠져 구조를 잃는다. 우리는 그것들이 무엇을 하는지 다른 사람에게 설명하기 어렵다는 것을 깨닫는다. 그리고 말한다. “내가 다르게 프로그래밍했다면, 예를 들어 ‘구조적 프로그래밍’을 썼다면 이런 일은 일어나지 않았을 텐데… 배열의 배열이 있었다면 이런 일은 일어나지 않았을 텐데… while문이 있었다면 이런 일은 일어나지 않았을 텐데…” 터무니없는 말이다. 오늘 일어나지 않는다면, 그런 것들이 모두 있어도 내일 일어날 것이다. 프로그래밍은 본질적으로 일종의 자기 끌어올리기 활동이기 때문이다. Iverson과 신이 오늘 여러분에게 주는 것은 내일이면 불충분해 보일 것이다.

그러므로 내가 “구형 언어”라고 부르는 완벽한 것을 찾는 탐구, 즉 오늘 우리가 생각할 수 있는 모든 방향과 내일 우리의 후손, 또 그 뒤의 사람들이 생각할 모든 방향으로 우아하고 균등하게 성장하는 언어는 현실이 될 가능성이 낮다. 그리고 우리는 너무 조급해해서는 안 된다. 어떤 언어를 다루든, 프로그래밍에 관해 정말 하고 싶은 말은 모두 할 수 있다는 것이 사실이라고 생각하기 때문이다. 그중 일부는 언제나 구성적 수준, 즉 언어의 원시 기능 바깥에 있을 것이다. 그러나 APL에는 뭔가가 더 있다. 적어도 나는 그렇게 느낀다.

몇 해 전 Carnegie에 이름을 잊어버린 MIT 사람이 방문한 적이 있다. 그는 작은 사무실에서 LISP의 몇몇 프로그래밍 문제에 관한 강연을 시작했다. 그는 칠판으로 가서 LISP로 말했다. 그가 설명하고 싶은 모든 것을 괄호와 CONS, CARS, CDRS로 설명했다. 그는 자신이 프로그래밍하는 언어로 자신의 생각을 표현하는 데 전혀 부족함이 없었다. 그가 우리에게 강연한 삼십 분 남짓 동안, 나는 반쯤 영어로 글이 쓰인 채 칠판에 나타나는 피할 수 없는 블록 도표나 순서도를 단 한 번도 보지 못했다. 그에게는 필요 없었다. 그리고 당시 나는 속으로 말했다. “만일 어떤 사람들이 자신이 프로그래밍하는 언어로 다른 사람에게 프로그래밍 생각을 표현할 수 있다면, LISP에는 매우 소중한 특성이 있다.” 나는 ALGOL로는 그렇게 할 수 없다. ALGOL로는 한 번도 그렇게 할 수 없었다. ALGOL로 프로그래밍하면서 내가 쓰고 있는 프로그램에 관해 몇 가지 진술을 하고 싶을 때면, 나는 언어 바깥으로 나가 영어, 수학, 블록 도표나 다른 무엇인가를 써야 했다. APL에서는 내가 사용해 본 다른 어떤 언어보다 훨씬 더 큰 정도로, 내가 쓰고 있는 프로그램에 관한 진술을 APL로 할 수 있다는 것을 발견한다. 사실 정확히 APL은 아니고, 그 순간에 내가 생각해 내지만 구현할 생각은 결코 하지 않을 멋진 작은 확장을 더한 APL이다. 하지만 대체로 그 언어는 내가 다루는 것에 관해 언어 안에서 나를 표현하게 해 준다. 나는 그것이 프로그래밍 언어의 매우 소중한 속성이라고 생각한다.

APL과 관련해 내가 발견한 두 번째 소중한 속성은 SIAM News에 실린 그 짧은 글에서 내가 사용한 표현, 즉 “서정적”이라는 말이다. 나는 APL 프로그래밍이 재미있다고 느낀다. 매력적이고 즐겁다. 프로그래밍은 더 이상 고역이 아니며, 그렇지 않은 이유 중 하나는 내게 언제나 선택지가 아주 많기 때문이다. 반면 구조적 프로그래밍을 하는 사람들은 프로그램에 충분한 구조를 넣으면 이 방의 모든 사람이 같은 ALGOL 프로그램이나 PASCAL 프로그램을 쓸 것이라고 말한다. 그러면 읽기는 더 쉬워지겠지만, 또한 따분해질 것이다.

신은 우리 모두를 다르게 만들었다. 우리 마음 중 정확히 똑같이 작동하는 것은 둘이 없으며, 영어의 위대한 힘 중 하나는 그것으로 지성을 벼리고 올바르게 사용하는 법을 배운 사람들이 다른 사람과 다르게 말할 수 있다는 데 있다. 따라서 그런 재능을 지닌 사람이 쓴 영어를 읽는 것은 즐겁다. 얼마 전 나는 신문에서 예술 분야의 누군가가 쓴 기사를 읽었다. 거기에는 Shakespeare가 오늘날 살아 있다면 TV를 위해 글을 쓰고 있을 것이라고 적혀 있었다. 나는 그것을 읽고 속으로 말했다. “그렇지 않다. Shakespeare가 오늘날 살아 있다면 그는 프로그래머가 되어 APL 한 줄짜리를 쓰고 있을 것이다.”

아주 단순한 문제라도 վերց어 50명으로 된 학급에 APL로 프로그래밍하게 하면, 서로 다른 해답이 35개에서 40개 나올 가능성이 아주 높다. 어떤 이들에게 그것은 끔찍한 상황이다. 내게 그것은 언어가 정말 힘과 가치를 지녔다는 표시다. 사물에 관해 독창적으로, 비록 서투를지라도, 생각하기 좋아하는 사람들이 쓰기에 어떤 의미에서 완벽한 언어다. 이용할 수 있는 이러한 변이와 선택은 APL 프로그래밍에 내가 다른 어떤 프로그래밍 언어에서도 찾지 못한, 거의 문학적이라고 부를 만한 성격을 부여한다. 이제 사람들은 언제나 말한다. “문학적 성격은 집어치워라. 우리는 마감일을 맞춰야 하고, 프로그램을 컴퓨터에서 돌려야 한다. 7분 대신 10분이 걸리면 그 3분은 돈으로 치러야 한다” 등등. 그것은 사실이며, 내가 그것이 중요하지 않다고 말하는 것은 아니다. 그러나 내가 말하는 것은 APL로 작업을 프로그래밍하려고 할 때, 처음에는 엄청나게 많은 대안이 눈앞에 놓인다는 것이다. 그것은 나쁜 것이 아니라 좋은 일이다. 그 대안들 가운데에서 우리는 수많은 기준을 충족할 수 있고, 내가 주장하건대 기계 효율성은 그중 하나일 뿐이다.

내가 처음 프로그래밍을 배웠을 때는 모두가 어셈블리 언어를 썼다. 우리는 기계어로 프로그래밍했다. 지금 돌이켜 보면 FORTRAN이 들어오면서 프로그래밍에서 무언가가 사라졌다는 것을 알겠다. 사라진 것은 우아하고 영리한 프로그램을 쓰는 즐거움, 좌절, 도전이었다! 우아하고 영리한 데에는 아무 잘못이 없다. 사실 내가 아는 거의 모든 분야에서 그것은 칭찬할 만한 일로 여겨진다. 왜 소프트웨어에서는 그래서는 안 되는지 모르겠다. FORTRAN이 들어오면서 실제로 사람이 한 일은 DO나 INTEGER I라는 문장으로 프로그램을 시작하는 것이었다. 나는 ALGOL 친구들에게 이렇게 말하곤 한다. 그들은 동네 문구점에서 산 편지지를 가지고 있는데, 그 편지지의 오른쪽 위에는 자기 이름이 있고, 왼쪽 위에는 begin이라는 단어가 있으며, 그 아래에는 integer i,j라는 말이 있고, 오른쪽 아래 끝에는 end가 있으며, 그 뒤에는 서명을 위한 자리가 있다는 것이다. 그리고 ALGOL로 프로그래밍할 때, 정말이지 그 양식이 여러분의 두개골 안에 있다. begin으로 시작해서 i와 j를 정수로 선언하고, “이제 다음에는 무엇을 하지?”라고 말한다. APL에서는 연산의 폭포가 마음속을 번쩍이며 지나간다. 배열을 통해 자료를 몰아넣으면 반대편 끝에서, 그러니까 절뚝이고 멍든 채로, 일곱 개의 수가 나온다. 계수 여덟의 배열들을 구축하고 작업 공간이 가득 차기 직전이 된 뒤, 반대편 끝에서 이 일곱 수가 나온다. 그리고 그것들은 거의 고통스럽게 끌려 나온다. 그러면 여러분은 속으로 말한다. “세상에, 정말 멋지군! 이건 하나의 장치야!”

한 줄짜리 증후군에 대한 비판이 많다는 것을 안다. Phil Abrams는 “APL 포르노그래피”라는 표현을 썼다. 하지만 세상물정을 아는 사람인 우리는 모두 알다시피 포르노그래피는 번성한다! 그것은 우리가 사악해서가 아니라 인간이기 때문에 번성한다. 마찬가지로 한 줄짜리는 우리가 그것에 어떤 딱지를 붙이든 번성할 것이다. APL이라는 언어가 한 줄짜리를 만들도록 초대하며, 그것을 쓰는 것보다 그 언어를 배우거나 감상하는 더 나은 방법은 없기 때문이다. 실제로 내가 믿기로 APL은 한 줄짜리를 써 봄으로써만 배울 수 있다. 어떤 의미에서는 한 줄에 무엇을 압축할 수 있는지 봄으로써만 배울 수 있다. 물론 시간이 지나면 세상에 더 익숙하고 더 지치게 되어 i=3 같은 짧은 것을 쓰기 시작한다. 그러나 적어도 처음 열광할 때는 한 줄짜리를 써야 그 언어를 가장 잘 감상할 수 있다. Yale에 온 뒤 우리가 계속해 온 APL 교육에서 나는 학생들에게 끊임없이 강조한다. “루프는 하나도 보고 싶지 않고, go to도 안 된다.” 학생들이 그렇게 쓴 프로그램이 효율적이기 때문은 아니다. 실제로 많은 경우 한 줄짜리보다 훨씬 잘 실행되는 루프 프로그램을 쓸 수 있다. 하지만 10,000개의 수를 통과시켜 둘이나 다섯을 얻는 이 압착기를 만들려고 시도해야만, 그것들을 만들어야만 APL의 절대적으로 아름다운 조화를 감상하기 시작하기 때문이다. 나는 학생들이 내게 와서 이렇게 말하기를 바란다. “5줄짜리 이 프로그램에서 저는 모든 APL 원시 기능을 썼습니다. 알맞았기 때문입니다. decode가 알맞은 자리가 있었고, 그래서 그것을 썼습니다.”

실제로 우리는 짧은 시간이 지나면 학생 프로그래머들이 언어의 모든 원시 기능이 말하자면 동등한 역할을 한다고 느끼기 시작한다는 것을 관찰했다. transpose는 더 이상 그들을 겁먹게 하지 않는다. [dyadic] transpose는 늘 사용된다. 그저 알맞다. 모든 것이 알맞다. 이제 앞으로 몇 년간 분명히 일어날 APL의 변경에서, 우리는 언어에 유지하고 싶은 모든 것 가운데 내가 “구형 조화”라고 부르는 것을 지켜야 한다. APL이 내가 “언어의 아령 모형”이라고 부르기로 한 것이 되게 해서는 안 된다. 즉 여기 한 덩어리, 저기 또 한 덩어리가 있고, 둘은 좁은 통과 대역을 통해 소통하며, 프로그래머가 프로그램을 쓸 때는 거의 모든 시간을 이쪽이나 저쪽에서 보내고 그 사이에서는 거의 시간을 보내지 않는 상태 말이다. 우리의 자연언어에서는 이런 일이 일어나지 않았고, APL에서도 일어나서는 안 된다.

물론 APL을 살펴보면서 내가 좋아하지 않는 점도 있다. 어떤 언어도 완벽하지 않다. 그리고 내가 좋아하지 않는 점들은 나와 몇몇 학생이 바꾸려 노력하는 점들이다. 하지만 그것들이 APL을 바꾸는 데 있어 최우선의 것들이거나 지적으로 가장 중요한 것들을 대표하는 것은 결코 아니다. 나는 그렇게 말할 수 없다. 지금 나는 APL에 관해 누구도 그런 말을 할 수 없다고 말한다. APL은 이미 말하자면 공공 영역의 일부가 되었고, APL 프로그램의 너무 많은 측면이 우리가 프로그램의 상거래라고 부를 수 있는 것을 다룬다. 특정 변경과 그 변경들만으로 언어가 현재 수준에서 더 높은 수준으로 옮겨 갈 것이라고 누구도 말할 수 없다.

예를 들어, 내가 APL에서 처음으로 관찰했고 나를 괴롭히던 점은 문장을 실행할 때 거대한 배열들을 만들고, 반대편 끝에서 세 개의 수가 절뚝이며 나온다는 사실이었다. 그 사이에는 많은 저장 공간이 쓰인다. 그래서 내게 가장 먼저 떠오른 것은 그 저장 공간을 쓰지 않을 방법을 찾아야 한다는 것이었다. 우리는 저장 공간의 양을 대폭 줄일 수 있게 해 주는 아주 단순한 해법을 찾았다. 그것은 언어를 크게 바꾸지 않았고, 그것이 APL에 큰 영향을 미칠지 나는 알지 못한다.

두 번째로 우리에게 떠오른 것은 APL 기계가 필요하다는 것이었다. APL은 지금 FORTRAN 기계에서 실행되고 있기 때문이다. FORTRAN이 지금과 같은 모습인 것은 FORTRAN이 발명되었을 때 컴퓨터가 그러한 모습이었기 때문이다. FORTRAN을 살펴보면 당시 우리가 가진 컴퓨터에 이상적으로 맞는 언어를 발견하게 된다. 하나의 누산기, 곱셈의 두 번째 부분과 나눗셈의 나머지를 처리하는 오버플로 레지스터, 몇 개의 인덱스 레지스터, 단 하나의 프로그램 계수기, 대략 백 개쯤의 명령으로 이루어진 명령 부호 말이다. 그리고 FORTRAN은 바로 그것, IBM 704에서 잘 작동하도록 만들어졌다. APL은 다른 발전 계통에서 나오지 않았기 때문에 전혀 다른 문제다. Iverson이 APL을 연구할 때, 내 생각에는, 나는 그에게 직접 들은 적은 없지만, 당시의 컴퓨터에 맞아야 하는 언어를 개발하고 있지 않았다. 그는 Mark IV나 Mark III 같은 Mark 기계 중 하나에서 성장한 것으로 믿는데, APL과 그 기계들 사이에는 관계가 거의 없다. 그 결과 APL은 등장한 뒤 당시 상업적으로 이용할 수 있던 하드웨어에 맞춰졌다. 그런데 그 하드웨어는 FORTRAN 계열을 따라 직접 발전해 온 것이었다. 그러면 이런 질문이 나온다. “APL을 이 기계들보다 훨씬 잘 실행할 수 있는 기계가 있어야 한다. 그런 기계는 어떤 모습이어야 하는가?” 여기서도 이 세 개의 수를 압착기로 밀어 넣는다는 생각을 따라, 내가 본 APL은, 그리고 다른 사람들도 분명 그렇게 보았겠지만, 자료의 흐름을 처리하는 스트림 처리 언어였다. 따라서 우리가 가져야 할 기계는 이런 흐름을 실행하도록 만들어진 기계다. 거기서 비교적 쉽게 기계 설계를 매우 빠르게 도출할 수 있다. 그런 기계가 올해 Cal Tech의 몇몇 사람에 의해 만들어지고 있다. 그러면 그것이 정말 우리가 바라는 만큼 좋은지 보게 될 것이다. 아마 그렇지 않을 것이다!

APL에 관해 우리 마음에 떠오른 세 번째 문제는 물론, 비교적 작은 작업 집합으로 프로그램을 교체하고 자료를 페이지화할 수 있게 하려고 운영체제에서 우리에게 온 가상 메모리가 APL 같은 배열 언어에 맞는 메모리 구성 방식은 결코 아니라는 사실이었다. 큰 배열은 어떻게 다루어야 하는가? 글쎄, 우리에게 떠오른 방법은, 그리고 다른 사람들에게도 분명 떠올랐을 방법은, 이 APL 한 줄짜리를 통과하는 자료의 스케줄링을 연구하는 것이었다. 다시 말해 수들이 압착기를 통과해 반대편으로 나오는 이 스트림 모형을 사용하는 것이다. 자료는 어떤 순서로 필요한가? 그리고 비교적 작은 버퍼를 사용하면서, 현재 실행하고 있는 식의 부분을 실행하는 데 필요한 자료가 언제나 메모리에 있도록 보조 메모리에서 그것들을 어떻게 가져오는가? 우리는 이 종류의 모형을 사용하면 자료 저장에 필요한 메모리 양이 가상 메모리 기계에서 필요하다고 익숙하게 생각해 온 양의 작은 일부라는 점을 보여 주는 매우 좋은 결과를 얻었다.

이 모든 개발의 배경에는, 내 마음과 학생들의 마음속에는, 공립 학교 체계에서 BASIC을 몰아내야 한다는 생각이 있었다. BASIC은 젊은이들에게 정말 해롭다. 오래된 세대에게는 괜찮다. 하지만 고등학교 11학년과 12학년, 전문대학, 대학교의 젊은이들에게, BASIC 프로그램을 작성함으로써 자신들이 사용할 수 있는 시간 안에 할 수 있는 연습 수준에서 프로그래밍의 아름다움을 감상하고 있다는 믿음은 해롭다. 게다가 매우 위험하다. 우리는 반문맹 집단을 만들고 있으며, 불행히도 IBM에 있는 여러분이 그들을 재교육하려 애써야 할 것이다. BASIC에 노출되어, 그래서 이제 자신이 열쇠를 가졌다고 믿는 사람을 데려와 APL의 관점에서 생각하는 법을 가르치기는 매우 어렵다. 정말 어렵다. 마치 뇌의 한 엽을 다른 엽으로 바꾸라고 요구하는 것과 거의 같으며, 그들은 그럴 준비가 되어 있지 않다. 따라서 우리 마음속 배경에는 이런 문제가 있었다. 사람들이 APL의 서정적 성격을 감상하기 시작할 수 있도록, 이 나라의 공립 학교 체계에서 사용할 수 있을 만큼 저렴한 APL 기계를 어떻게 얻을 것인가? 우리는 한 가지를 배웠고, 모두가 그것을 배웠다고 생각한다. 일단 APL을 배우면 BASIC을 알고, FORTRAN을 알고, ALGOL을 안다. 사실 나는 모든 프로그래밍 언어를 알게 된다고 생각한다. 어떻게 아는지는 모르지만 안다. 이런 물건들, 이 조립 장난감을 함께 놓는 복잡성을 숙달하는 일은 모든 프로그래밍을 포괄하는 함의를 지닌다. 반면 BASIC으로 프로그래밍할 때 지적으로 작동하는 낮은 수준은 APL로 옮겨 갈 때 수반되는 미학을 감상하게 해 주지 못한다. 실제로 그것은 여러분이 풀 준비가 되어 있지 않은 고된 퍼즐처럼 보인다.

대학에서 지금 ALGOL이나 PASCAL로 프로그래밍하는 아주 많은 사람에게서, APL을 배우는 데 필요한 시간의 문턱 투자가 너무 크기 때문에 배우려 하지 않는다는 말을 들었다. 그들은 APL로 프로그래밍하려면 배워야 한다고 내가 생각하는 방식, 말하자면 배열을 수학적 객체가 아니라 운반체로 생각하는 데 필요한 시간을 쓰려 하지 않는다. APL로 프로그래밍할 때 깨닫는 것 중 하나는 대체로 배열을 연산 순서를 폭발적으로 통과시키는 제어 운반체로 쓴다는 사실이기 때문이다. 그리고 계수의 사용은 더 큰 배열의 등에 작은 배열을 실어 나르는 편리한 방법일 뿐이다. BASIC과 ALGOL 같은 언어로 자란 사람들에게 그렇게 생각하게 하는 것은 매우 어렵고, 교수로서 나는 그것이 괴롭다. 그러나 해법은 물론 5100이 아니다. 그것은 너무 비싸다. 해법은 많아야 $1000 또는 $2000 수준에서, 적당한 양의 메모리와 사람들이 APL을 합리적으로 효율적으로 실행할 수 있는 보조 디스켓이나 그와 비슷한 것을 갖춘 컴퓨터를 내놓는 것이다. 그리고 그러려면 APL 기계가 필요하다. 반복해서 할 일들을 결합해 아주 빠르게 처리할 수 있도록 어떤 종류의 APL 컴파일러가 필요하다. 그리고 보조 메모리를 합리적으로 다루는 방법이 필요하다.

그것들이 우리가 풀려고 시도한 문제들이다. 그것들이 APL을 다루는 데 가장 중요한 문제인 것은 결코 아니다. APL은 우리 프로그래밍 세계의 상거래 대상이기 때문이다. 그리고 우리 모두는 그것이 사람들이 서로 대화하고, 프로그램을 교환하며, 합리적인 효율성을 보장받고, 같은 언어가 다양한 기계에서 작동함을 보장받는다는 뜻임을 안다. 그런 것들은 여러분의 상거래 세계에서는 그만큼 중요하거나 훨씬 더 중요하다. 그러나 사람들을 그 세계로 끌어들이려면, 대학과 고등학교에서 그 세계로 들어오게 하려면, BASIC에 오염되기 전에 APL을 배우는 일이 필수적이다. 나는 그것을 아주 진지하게 말한다.

글쎄, 최근 내 마음에 떠오른 다른 문제들이 있고, 여러분의 마음에도 아마 떠올랐으리라고 확신한다. 오늘날 우리는 계산 분야에서 임박한 혁명에 맞닥뜨리고 있다. 더 나은 단어나 구절이 없어 그렇게 부르자면, 그 혁명은 초대규모 집적 회로다. 하드웨어 분야 사람들은 수년 동안 우리에게 많은 것을 약속했고, 대체로 그것들을 제공했다. 내가 당연하게 여기며 나를 이끄는 한 가지는 하드웨어가 우리 분야를 이끈다는 사실이다. 소프트웨어가 아니라 하드웨어다. 하드웨어 분야 사람들이 우리에게 주는 것이 우리가 이용할 수 있는 기회의 집합을 결정한다. 그들은 앞으로 5년 정도 안에 작은 면적 위에 엄청난 수의 회로 소자를 우리에게 줄 것이다. 그 회로 소자가 무엇을 해야 하는지, 어떻게 결합되어야 하는지, 어떤 프로그래밍 언어가 그 기계들에서 실행될지 전혀 알지 못한 채, 그들은 엄청난 자원을 우리에게 제공할 것이다. 여러분 모두 짐작하겠지만, APL은 그 면적을 활용하기에 이상적인 언어이며, 적어도 다른 어떤 언어보다 거기에 가깝다. 따라서 소프트웨어에 종사하는 우리 모두가 마주한 문제 중 하나는, 말하자면 사람들이 쓸 수 있는 언어를 제공하는 스펙트럼의 우리 쪽 끝에서 발생하는 소프트웨어 요구와, 물리학자와 전기 공학자가 우리에게 제공할 반대편 끝의 하드웨어 사이의 간격을 어떻게 잇느냐는 것이다. 그 하드웨어는 잠재적으로 아주 많은 일을 할 수 있지만, 우리가 무엇을 해야 하는지 말해 주지 않으면 아무것도 하지 않는 고체 상태 장치다. 그렇게 많은 일을 할 수 있는 기계를 받고서 그것이 칩 위에 복제된 IBM 704나 IBM 360에 지나지 않는다는 것을 발견하는 것보다 덜 만족스러운 일은 상상하기 어렵다. 나쁘지는 않지만, 분명 우리는 그보다 더 높은 희망을 품고 있다고 생각한다. 따라서 앞으로의 세월에 내가 보기에는 APL에 가해질 주요한 추동은 그 방향에서 올 것이다. 즉 APL은 이 실리콘 칩에서 우리에게 제공될 엄청난 면적 증가에 적응할 언어로서 매우 좋은 후보가 될 것이다.

1978-03-29 California Los Altos의 Foothill College에서 열린 APL’78 Conference에서 Perlis 교수가 한 강연의 기록.

생성:   2011-09-19 18:45 수정: 2020-03-15 09:05