니클라우스 비르트의 2005년 논문 ‘Good Ideas Through The Looking Glass’를 바탕으로, 프로그래밍 언어의 ‘=’ 사용, 소프트웨어 위저드, 표현 스택 등 세 주제를 중심으로 비판적 논평과 보완적 관점을 제시하는 서평입니다.
이 글은 내가 구엘프 대학교에서 수강한 CIS*4500 - Programming Languages 과목의 과제로 처음 작성되었다. 내가 검토하는 논문은 니클라우스 비르트의 오래된 컴퓨터 과학 논문으로, 여기에서 볼 수 있다.
이 과제를 준비하는 데 실제로 글을 쓰는 데보다 훨씬 더 많은 시간을 쏟았다. 여러 논문의 큰 부분을 읽으면서, 지나치게 주관적으로 흐르지 않으면서도 타당한 비판으로 내 리뷰를 뒷받침하는 일이 얼마나 어려운지 깨달았다. 특히 디익스트라, 홀트, 비르트, 호어, 리치 같은 우리 시대의 가장 저명한 프로그래머들이 남긴 발언을 검토할 때는 더욱 그렇다. 이런 이유로, 형식적 비평 대신, 나는 저자의 인용문 중 모호하거나 불명확했거나 혹은 악마의 변호인(바로 나 같은)이 필요해 보였던 부분을 확장해 논의한다.
“Good ideas, through the looking glass”는 니클라우스 비르트가 2005년에 쓴 컴퓨터 과학 논문이다. 많은 인기 있는 STEM 글과 달리, 비르트는 특정 컴퓨터 시스템이나 패러다임의 소개, 장점, 단점에 초점을 맞추지 않았다. 대신 비르트는 “지난 수십 년의 컴퓨터 과학과 컴퓨터 기술에서 나온 온갖 아이디어들을” 논하고자 했다. 특히 역사적으로 독특하거나 참신한 아이디어들, 그리고 그것들이 시간의 시험을 견뎌냈는지에 주목했다. 비르트가 지적하듯, “진보를 위해서건, 지적 자극을 위해서건, 혹은 재미를 위해서건 과거로부터 배우려 노력하는” 것이 중요하다 (Wirth, 2006).
이 글은 훌륭한 읽을거리이며, 잊혀진 개념들에 마땅한 공을 돌린다. 다만 비르트의 몇몇 진술은 다소 불분명하거나 과장된 면이 있었다. 구체적으로, 내 리뷰는 글의 세 개 섹션 각각에서 한 문장씩을 골라 논의한다. Programming Language Features에서는 등호를 대입으로 쓰는 것이 “나쁜 아이디어의 악명 높은 예”라는 진술을 다룬다. Miscellaneous Techniques에서는 위저드(wizard)가 대체로 “악마처럼 완고하고 불멸”하다는 생각을 살펴본다. 마지막으로 Computer Architecture에서는 “표현식 스택이라는 아이디어가 꽤나 의문시되었다”는 관점을 논한다. 이 진술들이 틀렸다는 뜻은 전혀 아니지만, 주관적 성격이 강하기에 더 깊이 탐구할 가치가 있다. 내 코멘트는 비르트의 원 논문을 대체하기보다는 보완하는 추가 의견으로 받아들여지길 바란다.
“나쁜 아이디어의 악명 높은 예는 대입을 나타내는 기호로 등호를 선택한 것이다. 이는 1957년 FORTRAN으로 거슬러 올라가며, 수많은 언어 설계자들이 맹목적으로 따라 했다. 왜 나쁜 아이디어인가? 등호
=는 평등(동등) 비교, 곧 참 또는 거짓인 술어를 나타내는 기호라는 백 년 묵은 전통을 뒤엎었기 때문이다.”
비르트는 1957년 포트란이 등호의 전통적이고 널리 받아들여진 용례를 잘못 바꾸어 대혼란을 일으켰다고 말한다. 포트란(뿐 아니라 C, Perl, Python 등)이 등호를 대입에 쓰고, 파스칼 계열(Ada, Eiffel, APL)은 비교에 썼다는 사실은 맞다 (Germain, 2006). 하지만 등호의 올바른 용법에 관한 논쟁이 이들 언어에서 시작되었다고 암시하는 것은 지나친 단순화다. 현재 수학에서 동등을 보편적으로 나타내는 = 기호는 웨일스 수학자 로버트 레코드가 The Whetstone of Witte에서 처음 기록했다(Recorde, 1557). 레코드는 ‘쌍선’ 디자인이 “is equal to(…와 같다)”라는 문구의 반복을 피하기 위한 것이라 설명한다. 그는 “나는(내 작업에서 자주 하듯) 같은 길이의 평행선, 즉 두 줄(=)을 쓰겠다. 두 사물이 이보다 더 같을 수는 없기 때문이다”라고 적었다 (Recorde, 1557). 이를 조건부 대입(예: “x가 y와 같다고 할 때”)으로 볼 여지도 있지만, 문맥상 레코드는 등호를 절대적 선언(예: “x는 y와 같다”)로 쓰려 했던 듯하다.
그러나 기호가 발명되자마자 곧바로 오해도 뒤따랐다. 역사적으로는 방대한 주목을 받지 않았는데, 대체로 식의 문맥이 등호의 의도된 사용을 암시했기 때문이다. 1800년대 이후 등호가 일반적으로 조건(동등 비교)로 받아들여지게 된 것은 사실이지만, 대입을 위한 보편 기호가 있었던 것은 아니며 문서에는 여전히 ‘부적절한’ 용례가 가득했다. 이 구분은 계산(computation)의 도입과 함께 주목과 중요성을 얻게 되었다. 다음 코드를 보자. 5행의 이어붙인 식을 제외하면, 대부분은 문맥 덕분에 대입과 조건을 구분하며 무리 없이 이해할 것이다. 하지만 컴퓨터는 차이를 명시적으로 알아야 하므로, 대부분의 프로그래밍 언어는 이 코드를 컴파일하지 못한다.
x = 5
y = x + 5 + 2
if (y = x + 7)
printf("TRUE")
y = x + 5 = 10 + 2 = 12
비르트는 또한 ++ 같은 다른 기호에 대한 불호도 확장한다. 이것은 우결합성처럼 실제로 좋지 않은 설계 결정인데, 문(statement)과 식(expression)을 구분하지 못하게 만들기 때문이다. 등호의 어떤 용례가 최선인지(이는 주관적이다!)를 논할 수는 없지만, 조건과 절대적 대입을 서로 배타적으로 표현하는, 보편적으로 합의된 두 개의 기호가 있어야 한다는 점은 분명하다.
“이 저자가 위저드와 겪은 경험은 대체로 불운했다. 그는 텍스트 에디터에서 위저드를 마주치는 일을 피할 수 없었다. 최악인 것은 글쓰기를 끊임없이 방해하는 위저드들이다… 차라리 쉽게 비활성화할 수 있으면 좋겠지만, 보통 그것들은 악마처럼 완고하고 불멸이다.”
비르트는 Miscellaneous Techniques 섹션에서 위저드의 형편없는 구현을 지적하며, 대체로 도움이 되기보다 해가 되는 경우가 많다고 암시한다. 그는 위저드가 필요하다는 점은 인정하지만, 대체로 잘못 실행된다고 옹호한다. 나 역시 세상에는 지금도 매우 ‘악랄한’ 소프트웨어 위저드가 존재한다고 보지만, 동시에 ‘괜찮은 위저드’에게 정당한 공도 돌려야 한다고 생각한다. 위저드(Assistant, Helper라고도 함)는 사용자 입력을 바탕으로 복잡한 작업을 자동화하는 소프트웨어 패키지의 도움 기능이다 (Christensson, 2006). 위저드(데몬과 달리)는 프로그램 내부의 프로세스나 기능이지, 독립 실행 프로그램이 아니다. 신규 소프트웨어 설치 시 설정 도우미로 가장 흔하지만, 텍스트 에디터에서의 맞춤법 검사, 자동 들여쓰기, 자동 대문자화, 자동 저장 등 소프트웨어 내부의 작업 자동화에도 자주 쓰인다. 요컨대 사용자가 명시적으로 지시하지 않아도 발생하는 거의 모든 동작이 해당된다 (Scott, 2011).
비르트가 위저드에 대해 가장 크게 불만을 제기하는 지점은, 일반적으로 사용자화가 불가능하고 영구적이라는 점이다. 하지만 이것이야말로 위저드를 위저드답게 만드는 거의 유일한 특징이기도 하다! 사용자가 위저드를 일일이 초기화하거나 시작해야 한다면, 그것은 단순히 별도의 작업이나 프로세스일 뿐이다. 우리는 위저드의 놀라운 효용에 익숙해져 버렸다는 사실을 자각할 필요가 있다. 사람들은 오작동하는 위저드(부정확한 자동 수정, 특정 문자열을 임의로 기호로 바꿔버리는 일 등)는 잘 알아차리지만, 필요할 때 자동으로 대문자를 쓰고, 저장하고, 여닫는 따옴표를 적절히 골라주는 등 셀 수 없이 많은 이점은 더 이상 인식하지 못한다. 나도 비르트의 정서에 공감한다. 당면 작업을 방해하는 위저드는 신속히 재평가하거나 제거해야 한다. 그러나 그렇다고 해서 우리의 위저드들이 수행해 온 모든 일에 영원히 감사하지 말아야 할 이유는 없다. 애초에 그들을 위저드라고 부르는 데는 다 이유가 있으니까!
“그럼에도 표현식 스택의 아이디어는 꽤나 의문시되었다. 특히 1960년대 중반 레지스터 뱅크 아키텍처가 등장한 이후로는 더욱 그랬다. 이제 컴파일의 단순성이 실행 속도의 이득과 맞바뀌었다. 스택 구성은 희소 자원의 활용을 고정된 전략에 제한했다.”
컴퓨터 아키텍처의 시대를 초월했으나 결함도 있는 아이디어들을 묘사한 비르트의 섹션은 놀라울 정도로 통찰력 있고 잘 쓰여 있었다. 비판하거나 최소한 보탤 만한 인용문을 찾으려 여러 번 읽어야 했다. 내가 이 문장을 선택한 이유는, 당시 기준으로 표현식 스택의 ‘의문스러움’을 다소 과장했을 가능성이 있다고 느꼈기 때문이다.
F. L. 바우어와 E. W. 디익스트라는 임의의 표현식을 평가하는 동일한 방식을 각각 독립적으로 제안했다. 우선순위 규칙을 따르며 왼쪽에서 오른쪽으로 표현식을 평가할 때, 마지막 항이 가장 먼저 필요해지므로 스택이 된다. 당시는 이 방식이 편리했고, 이를 레지스터 뱅크에 구현하는 것도 간단했다. 이것이 스택 컴퓨팅의 도입이었다 (Koopman, 1994). 스택 머신의 중대한 문제는 사전 정의된 레지스터 수를 필요로 하여, 때로는 소중한 자원을 낭비한다는 점이었다. 아키텍처는 한동안 상당히 성공적이었으나, 레지스터 머신이 등장하자 빠르게 대체되었다.
비르트는 이러한 전개를 글에서 잘 설명하며, 레지스터 뱅크를 갖춘 아키텍처가 표현식 스택에 비해 가진 장점을 개괄한다. 그러나 스택 머신에도 장점이 있으며, 이를 논하지 않고 표현식 스택을 평가절하하는 것은 공정하지 않다. 스택 머신은 레지스터 머신보다 피연산자 로드가 더 클 수 있지만, 명령어가 더 작고 전체 오브젝트 코드도 더 작다 (Shannon, 2006). 스택 머신의 콤팩트한 코드는 자연스럽게 더 많은 명령어를 캐시에 담아, 캐시 효율을 높이고 메모리 비용을 낮추거나 같은 비용으로 더 빠른 메모리 시스템을 가능하게 한다. 또한 성능에서 부족한 부분을, 컴파일러 효율로 보완하기도 했다. 이러한 이점들 다수가 레지스터 컴퓨팅이 제공하는 막대한 성능 향상에 가려지긴 했지만, 가치가 없는 것은 아니다. 스택 머신은 오늘날에도 일부 연구, 소형 하드웨어, 하이브리드 머신에서 여전히 사용된다. 표현식 스택은 당시로서는 참신한 해법이었으며, 더 나은 하드웨어의 등장으로 보다 동적인 접근이 가능해진 뒤에야 비로소 퇴장했다 (Sinnathanby 2012). 나는 “표현식 스택이 꽤나 의문시되었다”기보다는, 스택 머신이 우리의 컴퓨팅에 최적의 아키텍처라는 생각이 의문스러웠다고 말하고 싶다.
니클라우스 비르트의 “Good ideas, through the looking glass”는 훌륭한 글이었다. 그는 지난 한 세기 동안의 컴퓨팅에서 가장 중요한 아이디어들을 성공 여부가 아니라 그 참신함과 기발함으로 조망했다. 컴퓨터 아키텍처, 언어 기능, 기타 기술들을 논하며 각 아이디어의 장점과 단점을 가능한 한 풍부하게 제공하려고 노력한다. 글에서 무엇을 바꾸고 싶다는 생각은 전혀 없었지만, 몇몇 주제는 더 깊게 탐구하고 다르게 제시할 여지가 있다고 느꼈다. 등호의 대입 사용, 위저드, 표현식 스택에 대한 그의 진술은 유익하고 정확했다. 그러나 그는 섹션을 마무리하며 그것들을 나쁜 혹은 의문스러운 아이디어(대놓고 악마라 부르지는 않더라도)로 규정하는 경향이 있었다. 이는 잠재적으로 타당하지만, 나는 이 아이디어들이 좀 더 많은 공을 받아야 하며 그 장점도 더 탐구될 수 있었다고 믿는다. 주관성을 잠시 제쳐두더라도, 니클라우스 비르트의 또 하나의 훌륭한 글이었다.
References
Christensson, P. (2006). Wizard 정의. 2016년 2월 28일에 http://techterms.com 에서 검색
Scott, B. (2011). Main menu. 2016년 2월 29일에 http://designinginterfaces.com/ patterns/wizard/ 에서 검색
Wirth, N. (2006). Good ideas, through the looking glass [computing history]. Computer, 39(1), 28-39.