한빛출판네트워크

저자: 임백준 (루슨트 테크놀로지스)

썬마이크로시스템즈의 제임스 고슬링은 자바 언어를 개발한 것으로 널리 알려진 프로그래머이다. 장난기 넘치는 웃음을 머금고 있는 그의 모습은 밝아서 얼굴만 봐서는 나이를 가늠하기가 쉽지 않다. 하지만 금발이 찰랑거리던 젊은 시절의 모습과 달리 세월의 무게에 밀려 뒤로 벗겨진 머리는 C++ 언어를 개발한 뱐 스트라우스트럽을 닮았고 턱 밑에 수북한 수염은 C 언어를 개발한 데니스 리치를 닮았다.

캐나다의 캘거리 대학에서 컴퓨터공학을 공부하고 미국의 카네기 멜론 대학에서 컴퓨터공학 박사를 획득한 고슬링은 말하자면 "엘리트 코스"를 제대로 밟은 프로그래머였다. 야전(野戰)을 통해서 실력을 쌓은 해커들과 달리 탄탄한 제도권 안에서 내공을 쌓은 그가 훗날(처음에 비해서 의미가 모호해지긴 했지만) 해커라는 이름으로 불릴 수 있게 된 까닭은 대부분 자바 언어 덕분이었다. 개인용 PC 운영체제 시장을 독점한 MS의 전횡에 지친 프로그래머들에게 특정한 운영체제에 구애받지 않는 자바 언어는 "해방군"처럼 느껴졌기 때문이다.

소프트웨어 발명가

여담이지만 1991년에 썬 마이크로시스템즈의 프로그래머 13명이 모여서 차세대 셋톱 TV를 위한 기술을 개발하는 "그린 프로젝트"가 자바 언어의 탄생 배경이었다는 사실은 유명하다. "그린 팀"의 목적은 새로운 언어를 개발하는 것과 거리가 멀었으며 자바는 다만 프로젝트의 진행을 돕기 위해서 고안된 프로그래밍 도구에 불과했다. 그런 자바가 90년대에 C와 C++의 아성에 도전하는 새로운 프로그래밍 언어로서 성공을 거두게 된 데에는 인터넷이라는 환경이 작용한 바가 크지만, 당시 프로그래머들 사이에서 더 명료한 객체지향 언어에 대한 요구가 존재했기 때문이기도 하다.

자바의 성공에 자극받은 MS는 C++의 뒤를 잇는 객체지향 언어인 C#을 발표했지만 이미 자바대 비(非)자바의 양강 구도로 정착된 대세를 바꾸기에는 역부족이었다. 제임스 고슬링은 MS가 C# 언어를 준비하고 있다는 소식을 처음 접했을 때 몹시 긴장할 수밖에 없었다고 고백했다.

하지만 C# 언어가 모습을 드러낸 이후인 2002년 1월에 CNET과의 인터뷰를 할 때에는 C#을 일컬어서 "안정성(reliability), 생산성(productivity) 그리고 보안성(security)을 제거한 자바 언어에 불과하다"고 일축했다. 뿐만 아니라 자바를 폄하하던 MS가 뒤늦게나마 자바와 비슷한 언어를 설계했다는 것은 결국 "자바에 대해서 최대의 찬사를 보낸 것"이라고 말하여 익살을 부리기도 했다.

고슬링은 자바의 초기 문법 구조를 설계하고 컴파일러와 자바 가상기계를 구현한 핵심 프로그래머였기 때문에 흔히 "자바의 발명가(Inventor of Java)"라고 불린다. 자바를 발명한 것은 분명히 제임스 고슬링 한 사람이 아니었지만 C의 데니스 리치와 C++의 뱐 스트라우스트럽처럼 고슬링의 이름 앞에는 항상 자바가 따라다니게 되었다. 프로그래밍 언어가 아니더라도 유닉스의 켄 톰슨, 리눅스의 리누스 토발즈, 넷스케이프의 마크 엔드리슨, GNU의 리차드 스톨만처럼 한 시대를 풍미한 소프트웨어의 "발명가"로 불리는 것은 프로그래머에게 있어서 무엇과도 바꿀 수 없는 최고의 영광임에 틀림없다(GNU는 물론 한 개의 소프트웨어가 아니다).

프로그래머들의 논쟁

그래서 프로그래머들은 종종 특정한 소프트웨어나 알고리즘의 구현을 둘러싼 "크레딧(credit)"을 놓고 격렬한 논쟁을 벌이기도 한다(철학자 헤겔이 말했던 "인정 투쟁"을 벌이는 셈이다). 리누스 토발즈의 자서전인 "리눅스 그냥 재미로(Just For Fun)"에서 소개된 리누스 본인과 앤드류 타넨바움 사이의 논쟁은 건설적인 논쟁의 예가 된다.

운영체제 학습을 위한 소형 운영체제였던 미닉스의 저자 타넨바움과 새롭게 부상하는 차세대 운영체제인 리눅스를 설계한 토발즈가 "마이크로 커널"과 "모놀리틱 시스템"의 장단점을 놓고 한판 논쟁을 벌이는 과정은 논쟁의 내용을 떠나서 그 자체로 많은 사람들에게 흥분과 관심의 대상이 되었다(그리고 이 논쟁은 서로에 대한 예의를 잃지 않은 적정한 선에서 정리가 되었다).

그러나 프로그래머 사이의 논쟁은 때때로 감정을 자극하는 파괴적인 다툼으로 발전하여 서로에게 상처만 입히는 싸움으로 끝나는 경우도 많다(크레딧을 둘러싼 이러한 다툼은 유명한 프로그래머 사이에서만 일어나는 일이 아니다. 필자와 같은 평범한 프로그래머, 특히 회사에서 월급을 받으며 생활하는 프로그래머에게 있어서 크레딧을 잘 관리하고 논쟁의 수위와 방향을 조절하는 능력은 프로그램을 잘 짜는 일 못지않게 중요하다).

유닉스 환경에서 vi와 함께 널리 사용되는 문서 편집기인 이맥스(Emacs)를 둘러싸고 제임스 고슬링과 자유 소프트웨어 운동의 대부(代父) 리차드 스톨만 사이에 있었던 크레딧 논쟁은 수위가 잘못 조절되어 파국으로 끝난 잘못된 논쟁의 예에 속한다.

스톨만이 지난 1986년에 스웨덴에 있는 대학에서 강연할 때 이맥스와 관련해서 다음과 같은 일화를 밝힌 적이 있다. 다음은 GNU의 웹 사이트에 있는 원고에서 강연 내용의 일부를 발췌하여 내용을 일부 번역한 것이다.

"두 해 전에 한 친구가 자신은 고슬링 이맥스의 초기 개발에 관여했기 때문에 고슬링이 자기에게 이맥스를 배포할 수 있는 권리를 허락했다고 말했다. 고슬링은 내가 원래 이맥스를 가지고 시작했던 철학을 따르겠다는 입장을 취했기 때문에 많은 사람들의 협력을 구할 수 있었다. 그렇지만 그는 자신의 소프트웨어에 카피라이트를 적용함으로써 모든 사람들의 등에 칼을 꽂았다. 아무도 그것을 재배포할 수 없도록 만든 다음 자신은 그것을 한 소프트웨어 회사에 팔아넘겼다. 내가 고슬링과의 개인적인 교류를 통해서 확인한 것은 바로 이와 같은 사실로부터 알 수 있듯이 그가 비열하고 천박한 종류의 인간이라는 점이었다."

프로그래머 중에서 리차드 스톨만을 모르는 사람은 거의 없을 것이다. 또한 유닉스 환경에서 프로그래밍을 하는 사람이라면 GNU에서 개발하여 무료로 배포하는 소프트웨어 도구를 한 번쯤 사용하지 않았을 가능성이 거의 없다. 오픈소스 운동보다 먼저 시작된 자유 소프트웨어 운동의 지도자에 해당하는 스톨만은 "자유"와 "저항"이라는 해커 정신의 핵심을 포기하지 않았기 때문에 프로그래머들보다 오히려 인터넷이나 사이버스페이스 같은 열쇠 말을 연구하는 사회학자나 철학자에게 더 많이 알려져 있을 정도이다.

많은 사람들에게 크레딧을 받고 있는 스톨만은 이렇게 강력한 어조로 또 다른 일군의 프로그래머들에게 "리더"로서의 존경을 받는 제임스 고슬링을 비판했다. 이러한 스톨만의 비판에 대해서 고슬링의 입장을 변호하는 사람들은 스톨만이 GUI는 물론 마우스의 사용까지 혐오하는 고지식한 "텍스트 모드" 마니아이며, 고슬링은 따라서 스톨만이 제작했던 조야한 초기 버전을 사용자들에게 더 친숙한 소프트웨어로 개선할 수밖에 없었다고 항변했다.

그리고 그에 덧붙여서 스톨만은 (GNU/Linux의 예에서 볼 수 있듯이) 자기가 조금도 관여하지 않은 소프트웨어를 통해서 크레딧을 얻으려고 애를 쓰며, 다른 사람이 자기보다 성공하거나 주목받는 것을 견디지 못하는 속 좁은 인간이라는 인신공격에 가까운 비판을 퍼부었다.

이런 식의 주장은 이미 기술적인 측면에 초점을 두는 건설적인 논쟁의 궤도를 벗어나서 서로의 철학과 정치적 입장 혹은 인간성에 대한 비판으로 나아가는 위험천만한 다툼에 해당한다. 양쪽의 주장이(구체적으로 입증할 수 없는 근거를 기초로 해서) 팽팽하게 맞서고 있기 때문에 사람들은 누구의 말을 들어야 할지 쉽게 판단하기 어렵다. 따라서 사람들 중에는 이맥스의 "발명가"를 스톨만으로 알고 있는 사람도 있고 고슬링으로 알고 있는 사람도 있다.

하지만 이와 같은 경우에는 크레딧을 누가 가져가든 당자를 제외한 3자에게는 아무 의미가 없다(스톨만의 비판은 고슬링이 자유 소프트웨어 정신을 배신했다는 점에 핵심이 놓여 있다. 반면 고슬링 쪽에서는 스톨만이 크레딧에 집착한 나머지 다른 사람의 정당한 공헌을 왜곡한다는 점, 그리고 절실히 요구되는 기술적 개선을 외면한다는 점을 지적하고 있다. 하지만 이런 것은 차원이 다른 문제이다. 이맥스의 주인공이 스톨만이든 고슬링이든 사용자들은 개의치 않는다!).

논쟁의 수위 조절

프로그래밍은 속성상 다른 분야의 일에 비해서 "공(功)"과 "과(過)"가 비교적 뚜렷하게 구분된다. 예를 들어서 고객이 사용하고 있는 소프트웨어에 중대한 결함이 생겨서 일정한 기간 내에 결함을 반드시 수정해야 하는 경우가 발생했다고 하자. 이 경우 문제가 간단하게 해결될 수 있는 성질의 것이 아니라면 실력이 뛰어난 프로그래머 몇 사람이 달라붙어서 밤을 새우며 디버깅을 해야 할 지도 모른다.

이 때 문제를 해결한 사람은 영웅이 되고 그 문제를 야기한 코드의 주인공은 졸지에 역적이 된다. 약간 과장된 표현이긴 하지만 프로그래밍을 하는 사람이라면 영웅이 되는 우쭐한 기분도, 역적으로 내몰리는 서글픈 기분도 맛본 적이 있을 것이다.

필자가 일하는 프로젝트의 구성원들은 미국에 있는 직원들과 영국에 있는 직원들이 반씩 섞여 있기 때문에 대개 5~6시간의 시차를 두고 일을 한다. 아무래도 얼굴을 맞대고 있는 사람들끼리 나누는 의사소통이 편하기 때문에 소프트웨어를 몇 개의 큼직한 컴포넌트로 나눈 다음, 몇 개는 미국 부서에서 구현하고 나머지 몇 개는 영국 부서에서 구현한다.

이렇다 보니 사용자 필드에서 치명적인 문제가 보고 되었을 때 문제의 원인이 어느 컴포넌트에 존재하는지를 규명하는 일은 항상 (두 지역의 프로그래머 사이에서) 심각한 수준의 논쟁을 수반한다. 이 때 필자가 늘 마음속으로 긴장하면서 노력하는 것은 논쟁의 "수위"를 알맞게 조절하여 합리적인 결론을 도출하는 일이다.

필자와 함께 일하는 미국 친구 중 한명은 매우 뛰어난 프로그래밍 실력을 갖추고 있음에도 불구하고 이와 같은 논쟁의 상황이 전개되면 쉽게 이성을 잃고 흥분하여 크레딧을 스스로 까먹는 경우가 많다. 유심히 살펴보면 프로그래밍 실력이 뛰어나고 자아가 강한 사람일수록 자기의 의견에 맞서는 논쟁을 견디지 못하는 경우가 더 흔하다. 이런 사람들은 쉽게 흥분하여 합리적인 근거에 입각한 주장보다 인신공격에 가까운 표현을 구사하여 논쟁의 발전적 가능성을 차단시킨다.

필자는 스톨만을 매우 존경했고 지금도 존경하고 있지만, 그가 자바에 대해서 비교적 냉담한 자세를 취하는 이유의 상당 부분이 고슬링과의 개인적인 악연에 기인한다는 주장을 (어느 곳에선가) 읽고 크게 실망한 적이 있었다. 논쟁을 논쟁 자체로 끝내지 못하고 그 이후의 개인 감정으로 끌고 들어오는 것은 상당히 잘못된 일이기 때문이다.

논쟁도 즐겨라

결론을 내려 보자. 지난 컬럼에서 필자는 "기쁨"이 있는 프로그래머와 그렇지 않은 프로그래머 사이에는 큰 차이가 있을 수밖에 없다고 말했다. 예술적 창의력이 있는 사람과 없는 사람의 차이에 대해서도 언급했다(참고로 지난 글의 말미에서 분명히 밝혔음에도 불구하고 필자가 "설계에 앞서는 코딩이 예술이다" 혹은 "코딩이 설계에 앞서야 한다"고 주장한다고 잘못 이해한 사람도 있었다. 상대방의 이야기를 이렇게 엉뚱하게 이해하는 것도 잘못된 논쟁 방식의 예가 된다!).

이번에 이야기하고자 하는 내용은 "논쟁"을 건설적으로 이끌어 가며 즐길 수 있는 프로그래머와 그렇지 않은 프로그래머 사이에는 시간이 흐르면 큰 차이가 생길 수밖에 없다는 점이다. 자신의 의견에 맞서는 "논쟁"을 고맙게 생각하여 힘껏 즐기고 또한 (지위 고하를 막론하고) 자신의 생각과 다른 의견에 대해서 끊임없이 의심하여 논쟁을 제기하기를 두려워하지 말 일이다. 예의를 잃지 않는 논쟁은 프로그래밍 실력을 키우는 가장 큰 지름길이기 때문이다.

- 출처 : 월간 마이크로소프트웨어 2004년 2월호