 |
| [이미지 출처 - Univ. of Texas at Austin] |
Dijkstra : 제 아버지가 영국 캠브리지의 프로그래밍 과정에 저를 보냈을 때가 1951년 이었습니다. 모든 것은 그 때부터 시작되었습니다. 처음으로 네덜란드를 떠났을 때, 처음 영어로 말하는 사람을 만났을 때 처럼 굉장한 경험이었습니다. 모든 일들을 스스로 해결해야 했고, 완전히 새로운 주제들로 가득찬 수업을 따라 가야 했습니다. 하지만 그런 것들을 아주 좋아했습니다.
네덜란드 암스테르담 수리센터의 계산부서 책임자로 있던 Aad van Wijngaarden은 이러한 저의 상황을 알고 일 자리를 제안했습니다. 저는 그의 제안을 받아들여 1952년 3월 파트타임 형식으로 수리센터에서 프로그래머로 일하게 되었습니다. 그 당시 수리센터에는 컴퓨터가 없어 직접 만들려는 시도를 했습니다. 수리센터에서 프로그래밍으로 8년이란 시간을 보내는 동안 앞으로 탄생할 머신에 사용될 기본적인 소프트웨어를 개발했습니다. 그 기간 동안 저는 아주 신중한(conservative) 프로그래머였습니다. 프로그램을 작성하거나 종이에 명령어 코드를 기술하는 형식, 라이브러리를 구성하는 방식은 1951년 캠브리지에서 경험했던 이후 훨씬 더 모델링(much modeled) 되었습니다.
Tomas : 1957년 결혼 당시, 혼인증명서에 "프로그래머"란 단어를 쓸 수 없었나요?
Dijkstra : 네, 생각해 보면 "프로그래머"란 용어는 1960년대 초에 비로소 인식되기 시작한 것 같습니다. 그 당시 이론 물리학을 연구하기 위해 캠브리지를 선택했지만, 프로그래밍을 시작한 지 3년이 되던 1955년, 아직 학생이였던 저는 프로그래밍이 이론 물리학 보다 더 강렬한 지적 도전이란 결론을 내렸고 그 결과 프로그래밍을 선택했습니다. 프로그래밍은 저 스스로에게 굉장히 엄격한 것이었습니다. 뭔가가 잘못되면, 그러니까 0은 0이고 1은 1이어야 하는데, 뭔가가 잘못 진행되면 직접 처리해야 만족했습니다. 저는 다른 사람이 작성한 소프트웨어를 써 본적이 없었습니다. 이것이 저의 도전 정신을 일으키는 스스로에 대한 엄격함(unforgivingness)입니다.
I had never used someone else's software. If something wrong, I had done it. And it was that unforgivingness that challenged me.물리학자가 아닌 프로그래머를 선택한 1955년 당시 다소 독특한 방식으로 알게 된 또 하나의 사실은 프로그램이 아주 복잡해 지거나 다루기 힘들어 질 수 있다는 것이었습니다. 프로그래밍을 한다는 것이 과학을 하고 있다고 생각되지 않았던 그 당시 프로그래밍이란 단지 기발함과 정교함을 섞어놓은 어떤 것이었습니다. 저는 하드웨어를 다루던 친구들을 부러워 했습니다. 왜냐하면 그들에게 그들의 전문성에 관한 질문을 던지면 진공관을 비롯한 전자 장치에 관한 알고 있는 모든 것에 대해 핵심을 짚을 수 있었습니다. 하지만 저는 어떤 것도 말해줄 수 없었습니다.
1955년 Wijngaarden은 컴퓨터 프로그래밍에 명료한 과학적 요소가 없다는 저의 얘기에 공감했지만, 저는 컴퓨터 프로그래밍을 과학의 한 분야로 만들 소명을 가진 한 사람이었는지도 모르겠습니다. 그 때의 저는 그렇게 할 수 있는 사람이었고, 제가 얘기 했듯이 저는 과학자가 되기에 훈련이 잘 되어있었습니다.
Tomas : 암스테르담에서 진행한 프로젝트에 대해 얘기해 주시겠어요?
Dijkstra : 1952년에 암스테르담에 왔을 때, 그들은 ARRA(Automatic Relay Calculator Amsterdam) 프로젝트를 진행하고 있었는데 신뢰할 만한 결과를 얻지 못해 셀레니움 다이오드를 이용한 업그레이 버전을 만들었습니다. 그리고 나서 Fokker 항공기 산업에 사용할 계산 머신을 만들었는데 ARRA의 업그레이드 버전인 FERTA(Fokker Electronic Calculator In Amsterdam)가 그것입니다. 저는 그 당시 젋은 청년이었던 Gerrit Blaauw과 Gene Amdahl 그리고 Fred Brooks과 함께 FERTA를 스히폴(Schiphol) 공항에 설치하는 프로젝트를 진행했습니다. Gerrit Blaauw는 이 후 IBM 360을 설계하기도 했습니다.
F27에 관한 재미있는 에피소드 하나가 있습니다. 처음 호주를 방문했을 때 일입니다. 암스테르담에서 LA까지 747을 타고 거기서 시드니나 멜버른까지 다시 747을 이용했습니다. 마지막으로 여행의 종착지인 캔버라까지는 F27를 탔습니다. 제가 도착했을 때 이전에 한 번도 본적이 없었던 초청자를 만났는데, 그는 저에게 마지막 비행을 두 개의 너덜거리는 터보엔진을 가진 항공기를 이용하게 했다는 점에 대해 아주 미안해 했습니다. 이 일로 저는 다시는 얻을 수 없는 한 발 앞설 수 있는 소중한 기회를 가지게 되었습니다. 저는 웃으며 솔직하게 말했습니다. "Stanton 박사님, 저는 날개의 공명 진동수를 직접 계산했고 안전하다고 느꼈습니다. :) "
1956년 프로그래머가 되기를 결정하자 마자 더 이상 대학에서 시간을 보낼 수 없다고 판단하고 최대한 빨리 학업을 끝냈습니다. 물리학자들은 저를 이단아로 간주했고, 수학자들은 무시하거나 컴퓨팅에 대해 다소 경멸하기도 했습니다. 그 시대에 수학계의 분위기는 "무한"과 같은 주제를 다루어야만 어느정도 과학적인 존경을 받을 수 있었습니다.
Tomas : "최단경로(shortest path)" 알고리즘에 관한 알려지지 않은 특별한 이야기가 있다고 들었습니다.
Dijkstra : 1956년에 아주 중요한 사건 두 가지 있는데, 하나는 제가 학위를 받은 것이고 다른 하나는 축제분위기 속에 ARMAC(Automatic Calculator Mathematical Centre) 센터를 오픈한 것입니다. 우리는 시연을 해야 했고, 몇 해 전 개발한 ARRA는 신뢰 할 만한 상태가 아니었기 때문에 안전하게 보여줄 수 있는 것은 오직 난수 발생뿐이었습니다. 저는 ARMAC의 신뢰도를 위해 좀 더 야심찬 것을 준비하기로 했습니다.
컴퓨팅을 잘 모르는 사람들을 위한 시연에서는 그들이 이해할 수 있는 방식으로 문제점을 기술해야 하고, 해답도 이해할 수 있도록 해야합니다. 그래서 저는 네덜란드 축소판 지도를 이용해 임의의 두 도시 사이의 최단 경로를 찾는 프로그램을 설계하기로 했습니다. 지도상에서 총 64개의 도시를 선택했고 각 도시들을 구분하는데 6비트면 충분했습니다.
Rotterdam에서 Groningen까지 가기 위한 최단 경로는 무었일까? 이 문제가 바로 대략 20분 만에 구현한 최단경로 알고리즘입니다. 어느 날 아침, 저는 저의 약혼자와 함께 암스테르담에서 쇼핑을 하고 있었습니다. 피곤해진 저는 커피를 마시기 위해 카페 테라스에 앉아 "이걸 할 수 있을까"에 대해 잠시 생각하고 곧바로 최단경로 알고리즘을 설계했습니다. 앞서 얘기했듯 최단경로 알고리즘은 20분만에 탄생한 발명품입니다.
사실 최단경로 알고리즘이 공식적으로 발표된 것은 그로부터 3년 뒤인 1959년입니다. 그 발표는 제가 생각하기에도 아주 훌륭했는데 그 이유는 종이와 연필을 사용하지 않고 설계한 것이기 때문입니다. 종이와 연필을 사용하지 않는 경우, 대부분 회피하고 싶은 복잡성은 피하려고 합니다. 놀랍게도 이 알고리즘은 갑작스럽게 제 명성의 주춧돌 역할을 하게됩니다. 1960년대 초에 경영과학 분야 독일 책에서 "Dijstra's sche Verfahren(Dijkstra's procedure)"을 발견했습니다. 갑자기 제 이름 뒤에 알고리즘 이름이 붙어 있었습니다. 현대 들어 이 알고리즘은 이동 계획을 수립하고자 하는 많은 사람들에게 널리 사용되고 있습니다. 오늘날 만약 당신이 GSP가 장착된 차를 이용해 여기서 저기까지 가고자 한다면 제 알고리즘이 최단 경로를 알려줄 수 있습니다.
Thomas : "최단경로" 알고리즘이 가장 처음 발표된건 언제인가요?
Dijkstra : F.L Bauer의 편집을 거쳐 1959년 Numerische Mathematik지에 처음 발표되었습니다. 그 당시 수학계에서 최단경로 알고리즘은 거의 거론의 대상이 아니었습니다. A에서 B까지 가는 경로의 수는 유한하고, 그 중 최단경로가 있는건 당연한데 왜 그렇게 야단법석이냐는 식이었습니다. 최단경로 알고리즘은 Bauer의 요청으로 기여도에 대한 검증이 이루어 질 때 까지 미발표로 남겨두어야 했습니다. 그러는 동안 저는 저의 하드웨어 분야 친구들을 위해 최단경로를 가지는 부분 신장트리(shortest sub-spanning tree)를 설계하고 있었습니다. 당신도 알겠지만, 커다란 패널 위의 각 점들을 동일한 전압을 가지도록 같은 구리선으로 연결해야 합니다. 최소한의 구리선을 써서 이런 점들을 연결하는 방법은 무엇일까요? 이 문제에 대한 결과물로 "A note on two problems in connection with graphs"를 썼고 1959년 Numerische Mathematik지에 발표했습니다.
시간이 흘러 하루는 제 안과의사를 만나러 갔을때 일입니다. 그는 제가 컴퓨터 과학자였는지 조차 모르고 있었습니다. 그가 말하길 "혹시 선생님께서 GPS 알고리즘을 설계하셨나요?" 나중에 밝혀진 사실은 그가 "Scientific American of November 2000"을 읽고 나서야 제가 무슨일을 하는 사람인지 알았다고 합니다.
Thomas : 초창기에 작성한 프로그램들이 맞다고(correct) 어떻게 말할 수 있나요?
Dijkstra : 첫 5년 동안 저는 아직 생겨나지도 않은 가상의 머신에서 실행될 프로그램을 작성했습니다. We would design ... , so to speak. 제가 했던 모든 프로그래밍은 종이 위에서 이루어졌습기 때문에 테스트 과정 없이 개발하는 경우가 빈번했습니다.
프로그램을 테스트 할 수 있는 방법이 없었기 때문에 추론을 통해 프로그램에 대한 정확성을 스스로 확신할 수 밖에 없었습니다. 아직 실제 머신이 없었을 때 종이 위에 작성된 단순한 오류는 아무런 문제가 되지 않았습니다. 실제 머신에서 오류가 나타나기 시작했을 때 언뜻 보기에 수정하기 쉬워보였습니다. 그러나 1957년에 생겨난 실시간 인터럽트 개념은 재발생 하지 않는 오류와 함께 프로그램에 대한 환상을 만들어 냈는데, 이것은 실시간 인터럽트가 예상치 못한 순간에 발생했기 때문입니다. 저의 하드웨어 친구는 이렇게 말했습니다. "그래 그래, 우리는 자네의 문제가 뭔지 알고 있어, 하지만 그건 자네가 감당해야 할 문제네". 저는 그것을 극복하는 법을 배웠습니다. 그리고 실시간 인터럽트를 처리하는 완벽한 핸들러를 작성했고, 이 주제는 저의 박사학위 논문이 되었습니다. 이 후 저는 이것이 거의 반미행위로 간주될뻔 했다는 사실을 배웠습니다.(?)
Thomas : 미국의 컴퓨팅 문화는 어떻게 다른가요?
Dijkstra : 글쎄요. 미국인들의 반응은 아주 달랐습니다. IBM이 360에서 구동될 소프트웨어를 개발해야 했을때, 그들은 특별히 모니터가 달린 한 대 또는 두 대의 머신을 만들었습니다. 이 여분의 장치는 인터럽트가 발생했을 때 정확히 그것을 기록하기 위한 용도로 만들어 졌습니다. 만약 뭔가 잘못되었을 때 이전의 상황을 재현할 수 있었습니다. 네 맞습니다. 그들은 재생성 가능한 머신을 만들었습니다. 하지만 우리가 제공할 수 있는 비용을 초과하는 하드웨어 비용때문에 말 할 필요도 없이 제대로 된 OS/360을 결코 얻을 수 없었습니다.
Thomas : OS/360 모니터링 같은 아이디어를 유럽인들은 한 번도 해보지 않았나요?
Dijkstra : 네, 그러한 아이디어를 고려하기에는 너무 예산이 부족했습니다. 대신 우리는 지적 통제하에 어떤 것을 다룰 수 있도록 설계를 구조화 시키기 위해 노력했습니다. 이것이 유럽인과 미국인이 프로그래밍을 대하는 결정적인 사고방식의 차이입니다.
Thomas : "프로그램을 증명한다"는 개념은 어떻게 나오게 되었나요?
Dijkstra : 1959년 저는 수리센터의 동료들에게 다음 프로그래밍 문제에 도전해 보라고 했습니다. 두 순환적(반복적)인 프로그램이 있습니다. 매 반복마다 임계구역(critical section)이란 구역이 발생합니다. 두 프로그램은 각각 한 번 읽고, 한 번 쓰기를 통해 서로 정보를 주고 받을 수 있고, 각각에 대한 수행 속도는 모르는 상태입니다. 문제는 어느 한 시점에서 최대 하나의 프로그램이 임계구역을 점유할 수 있도록 두 프로그램을 동기화 시키는 것입니다. 저는 이 문제를 자세히 살펴보고 쉬게 해결될 문제가 아님을 알았고, 다양한 형태의 부수적인 조건들이 존재했습니다. 우리는 두 프로그램이 "After-you-after-you"(교차 실행) 되는 것은 허용하지 않았고 임계구역을 접근하기 위해 서로 경쟁(병행실행) 한다고 가정했습니다. 이 딜레마는 해결되지 않을 것 같았습니다. 수리센터의 친구들은 각자 자신의 솔루션을 제출했지만 모두 틀린 답이었습니다. 저는 제출된 각 솔루션의 오류를 밝혀내기 위한 시나리오를 만들어야 될 지경이었습니다. 그들은 프로그램을 좀 더 복잡하게 만들었고, 이것은 프로그램의 오류를 찾기 위한 반례를 만드는데 더 많은 시간을 허비하게 했습니다. 그래서 전 이 게임의 규칙을 바꿔야 되겠다는 생각을 했고 동료들에게 이렇게 말했습니다. "여러분, 죄송합니다만 지금부터는 해당 솔루션이 왜 올바른지에 대한 주장이 있는 것만 인정하겠습니다."
그 후 3시간쯤 지났을 때, Th. J. Dekker는 해답에 대한 증명과 함께 완벽한 솔루션을 내놓았습니다. 그는 어떤 종류의 증명법이 필요한지 분석했고, 증명해야 할 것이 무엇인지, 어떻게 증명할 것인지를 결정한 후 증명의 요구사항에 부합하도록 프로그램을 작성했습니다. 수학을 프로그램의 구성이나 확장이 아닌 검증 용도로만 제한적으로 사용한다면 많은 것을 잃을 수 있습니다.
1959년의 또 다른 경험으로 파리에서 열린 "0"번째 IFIP 회의에 참가하기도 했는데, 실제로 국제적인 활동을 시작한 건 1958년 겨울 ALGOL60 설계를 위한 미팅이었습니다. 당시 제 상관이었던 Wijingaarden은 심각한 자동차 사고로 미팅에 참석하지 못하게 되었고, 직속 부하였던 저와 Jaap Zonneveld는 그를 대신해야 했습니다. Zonneveld는 수치해석을, 저는 프로그래밍 작업을 수행했습니다. 그 때 ALGOL60 미팅은 자발적으로 영어 토론을 진행한 첫 번째 사건이었고, 꽤나 힘들었습니다. :)
Thomas : 지적하신대로 서로 다른 다양한 언어를 배우는 것이 프로그래밍에 도움이 된다고 하셨는데요?
Dijkstra : 아, 네, 유용합니다. 하나의 언어만 사용하는 사람과 적어도 두 개 이상의 언어를 구사하는 사람은 큰 차이가 있습니다. 일반적으로 다양한 언어의 학습은 언어 구조에 대한 자각능력을 높여줍니다. 하나의 언어로는 언어의 특정 구조를 도저히 해석할 수 없다는 사실을 발견하게 될겁니다. 저는 한 때 유능한 프로그래머의 가장 중요한 자질이 무었인가란 질문을 받은 적이 있습니다. 두 가지 대답을 했는데, 첫 번째는 "수학적 성향(mathematical inclination)"이라고 말했습니다. 왜냐하면 그 당시에는 수학이 프로그래밍 발전에 어떻게 기여할 수 있는지 명확하지 않았기 때문입니다. 두 번째는 모국어(주로 사용하는 프로그래밍 언어)에 "통달"한 사람이라고 했습니다. 왜냐하면 사람들은 그들에게 익숙한 언어의 단어와 문장으로 사고해야하기 때문입니다.
Thomas : ALGOL60이 어떻게 전환점이 되었나요?
Dijkstra : 컴퓨팅 과학은 ALGOL60과 더불어 시작되었습니다. 지금에 와서 ALGOL60이 이런 기적(?)이 된 이유는 대학 프로젝트가 아닌 국제 공동체의 협의를 통해 만들어진 프로젝트이기 때문입니다. 또한 ALGOL60 프로젝트를 통해 아주 기발한 6가지 아이디어가 소개되었습니다.
First of all, it introduced the absence of such arbitrary constraints as, say, ruling out the subscripted subscript, the example I mentioned. 두 번째는 적어도 문맥자유 문법(context-free syntax)에 대해서 형식 정의(formal definition)가 있었습니다. 이것은 ALGOL60에 엄청난 차이를 부여했는데, 구문 분석을 더 이상 수 많은 속임수로 진행하기 보다 견고한 규칙에 따라 할 수 있게 되었습니다. 하지만 더 중요한 것은 컴파일러 작성과 언어 정의가 학문적으로 관심을 가지기에 가치있는 주제가 되었다는 사실입니다. 이것은 컴퓨터 과학을 학문적 존중할 만한것으로 만드는데 중요한 역할을 했습니다.
세 번째는 "Boolean" 타입을 first-class citizen으로 정의한 것입니다. 이것은 맞거나 틀릴지도 모를 문장내의 boolean 표현식을 "true"와 "false"란 값을 가지는 표현식으로 바꿔놓았습니다. 저는 이런 변화가 얼마나 대단한 것인지 어머니의 반응을 통해 알 수 있었습니다. 어머니는 재능있는 수학자셨지만 이 단계까지는 만들어 내지 못하셨습니다. 어머니에게 있어서 "3 + 5 = 10"이 틀렸다고 말하는 것은 그리 어려운 것이 아니었습니다. 그냥 틀렸으니까요.
Potentially ......
네 번째 획기적인 아이디어는 명령형 프로그래밍 방식에 재귀(recursion)를 도입한 것입니다. Recursion은 언어의 중요한 발전 요소였는데, 다소 교묘한 방식으로 알려지게 되었습니다. 1959년 12월 마지막 한 주 동안 ALGOL60 보고서 초안이 떠돌았습니다. 우리는 초안을 연구 했고, 재귀 호출이 명시적으로 기술되어 있지는 않았지만 거의 공인된 것임을 깨달았습니다. 저는 Peter Naur에게 전화를 걸어(흥분의 도가니로 기억되는 첫 번째 국제 통화) 한 가지 제안사항을 적어두도록 했습니다. 대충 이런 것이었는데 "특정 프로시저 식별자의 또 다른 발생은 해당 프로시저의 재활성화를 의미한다." 이 문장은 교묘하게 포함되었고, 보고서를 인정한 모든 사람들은 이 문장을 보지 못했습니다. 이것이 recursion이 명시적으로 포함된 사연입니다.
Thomas : 그 당시에도 이것을 recursion이라 불렀나요?
Dijkstra : 네 맞습니다. 그 당시 부각되기 시작하던 LISP에 포함된 개념이었고, 널리 알려져 있었습니다. 하지만 우리는 recursion을 저평가 했습니다. F.L. Bauer는 recursion을 알고 있었지만 ALGOL60의 최종 보고서 버전에 포함되는 것을 결코 원하지 않았습니다. 그는 즉시 ALCOR 그룹을 설립했는데 이 그룹은 recursion이 철저히 배제된 ALGOL60의 subset을 구현하려고 했습니다.
Thmoas : ALGOL60에 포함된 다른 아이디어들은 무엇인가요?
Dijkstra : 언급하고 싶은 다섯번 째 아이디어는 블럭구조(block structure)입니다. 블럭구조는 프로그램을 구조화 시키는 도구인데, "구조"란 단어는 9년 후 "구조적 프로그래밍(structured programming)"이란 용어에 사용했던 것과 같은 단어입니다. 어휘적 가시범위(lexical scope)는 ...
번역 진행 중 ㅠㅠ
[참고문헌]
1. Interview: An Interview with Edsger W. Dijkstra, Thomas J. Misa, Communications of the ACM, Aug.2010, Vol.53, No.8
0 댓글