[펌글] 벤처에서 일한다면 – 평균 뛰어넘기

Beating the Averages

평균 뛰어넘기

http://www.paulgraham.com/avg.html

Copyright © 2001, 2003 Paul Graham

(이 논설은 2001년 프란츠(Franz) 개발자 심포지엄에서 했던 발표에서 시작된 것이다. 여기에서는 우리가 리스프(Lisp)를 써서 어떻게 비어웹 스토어(Viaweb Store)를 만들었는지 설명하고 있다. 이것은 현재 야후! 스토어(Yahoo! Store)로 발전하여 20,000여개의 상점을 운영하고 있는, 여전히 가장 인기 있는 전자상거래 소프트웨어이다.)

1995년 여름, 친구 로버트 모리스(Robert Morris)와 나는 비어웹(Viaweb)이라는 벤처회사를 시작했다. 우리 계획은 최종 사용자들이 온라인 상점을 직접 세울 수 있게 해 주는 소프트웨어를 만드는 것이었다. 이 소프트웨어가 그 당시에 참신했던 것은, 우리 서버에서 동작하면서 일반 웹 페이지를 인터페이스로 사용한다는 점이었다.

물론 그 당시 많은 사람들이 이런 생각을 했을 수도 있지만, 내가 아는 한에는, 비어웹이 최초의 웹 기반 응용프로그램이었다. 우리에게는 무척이나 참신한 생각이었기 때문에 회사 이름도 그것을 따서 비어웹이라고 지었다. 우리 소프트웨어는 데스크톱 컴퓨터에서 동작하는 대신에 웹(Web)을 통해(via) 동작하기 때문이다.

이 소프트웨어의 또 다른 유별난 점은 그것을 대부분 리스프(Lisp)라는 프로그래밍 언어로 만들었다는 사실이다. 이것은 리스프로 만들어진 최초의 최종 사용자용 대형 응용프로그램이었다. 그 때까지 리스프는 대부분 대학이나 연구실에서 사용되어 왔다. 우리는 리스프를 사용함으로써 그것보다 덜 강력한 언어를 사용하는 경쟁자들에 대해 상당한 우위에 설 수 있었다.

주: 비어웹은 처음에 두 부분, 즉 리스프로 만든 사이트 제작용 편집기와, C로 만든 주문(ordering) 시스템이 있었다. 주문 시스템의 비중이 적었기 때문에 첫 판은 대부분 리스프였다. 그 후 우리는 두 모듈을 추가했는데, 하나는 C로 만든 그림 생성기였고, 다른 하나는 대부분 펄(Perl)로 만든 사무(back-office) 관리 도구였다.

2003년 1월에 야후는 C++와 펄로 만든 편집기의 새 판을 내놓았다. 하지만 그 프로그램이 더 이상 리스프로 만들어지지 않았다고 말하기는 어렵다. 이 프로그램을 C++로 번역하기 위해 문자 그대로 리스프 해석기(interpreter)를 만들어야 했다. 모든 페이지 생성 템플릿의 소스 파일들은 내가 아는 한 아직도 리스프 코드이다. (필 그린스펀(Phil Greenspun)의 프로그래밍의 열 번째 법칙: “충분히 복잡한 C나 포트란(Fortran) 프로그램 개발 하다보면, 커먼 리습의 절반정도를 엉터리로 구현하게 되는데, 그 구현은 임시방편적이고 제대로된 스펙도 없고 버그도 있고 또한 느리다.”)

1 비밀 무기 #

에릭 레이먼드(Eric Raymond)는 “해커가 되는 방법(How to Become a Hacker)”이라는 글을 썼는데, 그 글에서 그는 무엇보다 해커가 되고자 하는 사람들이 배워야 하는 언어들에 대해 말하고 있다. 그는 파이썬(Python)과 자바(Java)가 배우기 쉬우므로 그것부터 시작하라고 제안한다. 진지한 해커라면 유닉스를 해킹하기 위해 C를, 시스템 관리와 CGI 스크립트를 위해 펄(Perl)을 배울 필요도 있을 것이다. 마지막으로 정말 진지한 해커들은 리스프 배우는 것을 생각해 봐야 한다.

이것은 라틴어를 배워야 하는 까닭으로 들어 봤을 바로 그 근거와 같다. 그것이 고전문학 교수 자리 외에는 일자리를 얻는 데 도움이 되지 않겠지만, 생각을 발전시키고 영어로 글을 잘 쓰는 데에는 도움이 되기 때문이다.

하지만 잠깐. 이 은유는 그렇게 넓게 적용되는 것이 아니다. 라틴어가 일자리를 얻어 주지 않는 이유는 아무도 그 말을 쓰지 않기 때문이다. 라틴어로 글을 쓴다면 아무도 이해하지 못할 것이다. 하지만 리스프는 컴퓨터 언어이며, 컴퓨터는 프로그래머가 하는 모든 언어로 말할 수 있다.

그래서 그가 말한 대로 리스프를 통해 더 좋은 프로그래머가 될 수 있다면 왜 그것을 사용하지 않겠는가? 더 좋은 화가가 될 수 있는 붓을 얻는다면 어떤 화가라도 자기 모든 그림에 그 붓을 사용하고 싶어 할 것이다. 그렇지 않겠는가? 나는 여기서 에릭 레이먼드를 비웃으려는 것이 아니다. 전체적으로 그의 조언은 좋다. 그가 리스프에 대해 말한 것은 전통적인 지혜와 매우 가깝다. 하지만 그 전통적인 지혜에는 모순이 있다. 리스프는 좋은 프로그래머를 만들어 주지만, 실제로는 그것을 쓰지 않는다?

왜 안 쓰는가? 프로그래밍 언어는 결국 도구일 뿐이다. 리스프가 정말로 좋은 프로그램을 낳는다면, 그것을 써야 할 것이다. 그렇지 않다면 그것이 누구한테 필요하겠는가?

이것은 단지 이론적인 질문이 아니다. 소프트웨어는 매우 경쟁적인 사업이고, 자연스럽게 독점으로 흐르는 경향이 있다. 다른 모든 조건이 같다면, 소프트웨어를 더 빠르고 더 좋게 만드는 회사가 경쟁자들을 사업에서 밀어낼 수 있다. 벤처회사를 시작하려고 할 때 이것을 뼈에 사무치게 느낄 것이다. 벤처회사들은 모 아니면 도의 위치에 있게 된다. 부자가 되거나 망하거나 둘 중의 하나이다. 벤처회사가 잘못 짚은 기술에 투자했다가는 경쟁자들에게 짓밟히고 말 것이다.

로버트와 나는 모두 리스프를 잘 알고 있었고, 우리의 직관에 따라 리스프로 시작하지 않을 이유를 찾을 수 없었다. 우리는 다른 모든 사람들이 C++이나 펄로 소프트웨어를 만들고 있다는 것을 알고 있었다. 하지만 우리는 그것이 아무 의미가 없다는 것도 알았다. 기술을 그런 식으로 선택하는 사람이라면 지금 윈도우즈를 사용 중일 것이다. 기술을 선택할 때는 다른 사람들이 무엇을 하는지는 무시해야 하고, 무엇이 가장 효과적일 것인지만 생각해야 한다.

이것은 특히 벤처회사에 진리이다. 큰 회사에서는 다른 큰 회사가 하고 있는 것을 해도 된다. 하지만 벤처회사는 다른 모든 벤처회사들이 하는 것을 따라 하면 안 된다. 그런데 많은 사람들이, 벤처회사들조차도, 이것을 깨닫고 있는 것 같지 않다.

평균적인 큰 회사는 1년에 10퍼센트 정도 성장한다. 그래서 큰 회사를 운영하면서 평균적인 큰 회사가 하는 대로 모두 따라 하면, 그 평균적인 큰 회사가 하는 만큼은 할 수 있으리라고 기대된다. 즉, 1년에 10퍼센트 성장할 수 있을 것이다.

벤처회사를 운영할 때도 물론 같은 일이 일어날 것이다. 평균적인 벤처회사가 하는 대로 모두 따라 하면 평균적인 성과를 기대할 수 있을 것이다. 여기에서 문제는, 평균적인 성과라는 것이 사업에서 밀려나는 것이라는 사실이다. 벤처회사의 생존율은 50퍼센트보다 훨씬 낮다. 그래서 벤처회사를 운영한다면 어떤 색다른 것을 하는 것이 좋다. 그렇지 않다면 문제이다.

1995년 당시 우리는 경쟁자들이 이해하지 못할 만한 것을 알고 있었다. 지금도 이해하는 사람은 거의 없다. 그것은 자기 서버에서 돌아갈 소프트웨어를 만들 때에는 원하는 어떤 언어를 사용해도 된다는 사실이다. 데스크톱 소프트웨어를 만들 때에는 운영체제와 같은 언어로 응용프로그램을 만들게 되는 경향이 크다. 10년 전에는 응용프로그램을 만든다는 것이 C로 만든다는 것을 의미했다. 하지만 웹 기반 소프트웨어라면, 특히 언어와 운영체제의 소스 코드를 모두 갖고 있다면, 원하는 어떤 언어라도 사용할 수 있다.

하지만 이 새로운 자유는 양날의 검이다. 어떤 언어를 사용해도 되기 때문에, 어떤 것을 사용할지 고민해야 한다. 아무것도 달라진 것이 없는 척하려는 회사들은 나중에 경쟁자들이 그렇게 하지 않는다는 것을 알게 되어도 그것을 감수한다.

어떤 언어를 써도 된다면, 어떤 것을 쓸 것인가? 우리는 리스프를 선택했다. 한 가지 이유는 이 시장에서 쾌속 개발(rapid development)이 중요하다는 것이 분명했기 때문이다. 우리는 모두 무에서 시작했으므로, 경쟁자들보다 먼저 새로운 기능을 만들어내는 회사가 크게 유리해질 것이었다. 우리는 리스프가 소프트웨어를 신속하게 만들기에 정말 좋은 언어라는 것을 알고 있었으며, 소프트웨어가 완성되는 순간 배포할 수 있기 때문에 서버 기반 응용프로그램들은 쾌속 개발의 효과를 증대한다.

다른 회사들이 리스프를 사용하고 싶어 하지 않는다면 더욱 더 좋았다. 이렇게 우리는 기술적인 첨단에 서게 되었지만, 필요한 도움은 모두 얻을 수 있었다. 우리가 비어웹(Viaweb)을 시작했을 때, 우리는 사업의 경험이 없었다. 우리는 마케팅이나 직원 고용이나 돈을 마련하는 것이나 고객을 확보하는 것에 대해 아무것도 몰랐다. 우리 둘 다 진짜 직업이라고 할 만한 것을 가져 본 적도 없었다. 우리가 잘 하는 것은 오직 소프트웨어를 만드는 것이었다. 우리는 그것이 우리를 구할 것이라고 기대했다. 소프트웨어 부문에서 우리가 취할 수 있는 유리한 점이 있다면 우리는 그것을 모두 이용했다.

리스프를 사용하는 것은 실험적인 일이었다고 말할 수도 있을 것이다. 우리의 가설은 우리가 리스프로 소프트웨어를 만든다면 우리는 경쟁자들보다 기능들을 더 빨리 완성할 수 있고, 그들이 할 수 없는 것도 우리 소프트웨어로 할 수 있으리라는 것이었다. 그리고 리스프는 상당한 고급(high-level) 언어였기 때문에 우리는 대형 개발 팀이 필요하지 않을 것이고, 그래서 비용도 절감할 수 있을 것이었다. 정말로 그렇게 된다면, 우리는 더 좋은 제품을 더 낮은 가격에 제공하면서도 이익을 낼 수 있을 것이다. 우리는 마침내 모든 사용자들을 확보하고, 경쟁자들은 아무도 확보하지 못하여 결국 업계를 떠나게 될 것이다. 어떻게든 일이 이렇게 될 것이라고 우리는 기대했다.

이 실험의 결과가 어땠을까? 조금 놀랍게도 성공적이었다. 우리는 결국 이삼십 개쯤 되는 많은 경쟁자가 생겼지만, 그들의 소프트웨어는 우리와 경쟁이 되지 않았다. 우리는 위지위그(WYSIWYG) 온라인 상점 제작 도구(builder)가 있었는데, 그것이 서버에서 돌아가기는 했지만 데스크톱 응용프로그램과 같은 느낌을 주었다. 우리 경쟁자들은 CGI 스크립트가 있었다. 그러나 우리는 그들보다 기능면에서 언제나 훨씬 앞서 있었다. 때때로 경쟁자들이 우리가 없는 기능을 도입하려고 필사적으로 노력하기도 했다. 하지만 리스프 덕에 우리의 개발 주기는 매우 빨랐으므로 어떤 때는 경쟁자가 새로운 기능을 보도 자료로 알린지 하루 이틀 만에 그 기능을 똑같이 만들어냈다. 그 보도 자료를 취재한 기자들이 우리에게 전화해 보려고 할 때쯤에는 우리도 그 새로운 기능을 갖고 있었다.

우리 경쟁자들에게는 우리가 일종의 비밀 무기가 있어서 그들의 암호문을 가로채서 해독하거나 하는 것처럼 보였을 것이다. 실제로 우리는 비밀 무기가 있었지만, 그것은 그들이 실감한 것보다 더 간단했다. 아무도 그 기능들에 대한 뉴스를 우리에게 흘려주지 않았다. 우리는 누구나 가능하리라고 생각하는 것보다 더 빨리 소프트웨어를 개발할 수 있었을 뿐이다.

내가 아홉 살쯤 되었을 때 나는 프레더릭 포사이드(Frederick Forsyth)의 소설 “자칼의 날(The Day of the Jackal)”이라는 책을 손에 쥐게 되었다. 주인공은 프랑스 대통령을 살해하도록 고용된 암살자이다. 그 암살자는 대통령이 지나는 길을 내려다볼 수 있는 아파트로 올라가기 위해 경찰들을 지나가야 한다. 그는 나무다리를 한 노인의 차림으로 경찰들 바로 옆을 걸어가고, 그들은 그를 전혀 의심하지 않는다.

우리의 비밀 무기도 그와 비슷했다. 우리는 괄호가 가득한 기괴한 문법의 묘한 인공지능 언어로 우리 소프트웨어를 만들었다. 나는 여러 해 동안 리스프가 그런 식으로 묘사되는 것을 들을 때마다 마음이 불편했다. 하지만 이제 그것이 우리에게 유리하게 작용했다. 사업에서는 경쟁자가 이해하지 못하는 기술적 우세함보다 더 가치 있는 것이 없다. 사업에서는 전쟁에서처럼 기습이 무력만큼 가치가 있다.

그래서, 말하기가 조금 난처하기는 하지만, 우리가 비어웹 작업을 하는 동안 나는 리스프에 대해 공개적으로 한 마디도 하지 않았다. 우리는 언론에도 그것을 언급하지 않았고, 우리 웹 사이트에서 리스프를 찾아 봐도 나의 이력에 있는 두 권의 책 제목만 찾을 수 있을 뿐이었다. 이것은 우연이 아니었다. 벤처회사는 경쟁자에게 최소한의 정보만 줘야 한다. 그들이 우리 소프트웨어가 무슨 언어로 만들어졌는지 모르거나 관심이 없으면, 나는 그 상태 그대로 두기를 원했다. 주: 로버트 모리스(Robert Morris)는, 우리 경쟁자들이 우리가 리스프를 사용한다는 것을 알았어도 왜 그러는지 이해하지 못했을 것이므로, 내가 비밀을 지킬 필요도 없었다고 말한다. “그들이 그렇게 똑똑했다면 이미 리스프로 프로그래밍을 하고 있었어야지.”

우리 기술을 가장 잘 이해한 사람들은 고객들이었다. 그들은 비어웹이 어떤 언어로 만들어졌는지 전혀 상관하지 않았지만, 그들은 이것이 정말 잘 돌아간다는 것을 알았다. 그들은 이것으로 훌륭해 보이는 온라인 상점을 문자 그대로 몇 분 만에 만들 수 있었다. 그래서, 대부분은 입소문에 의해, 우리는 점점 더 많은 사용자를 확보하였다. 1996년 후반에는 온라인에 상점이 70개가 있었고, 1997년 후반에는 500개가 되었다. 6개월 후에 야후가 우리 회사를 샀을 때 1,070명의 사용자가 있었다. 오늘날, 야후 스토어(Yahoo Store)로서 이 소프트웨어는 이 시장을 계속 주도하고 있다. 이것은 야후에서 이익을 많이 내는 부분 중 하나이고, 이것으로 만들어진 상점들은 야후 쇼핑(Yahoo Shopping)의 기초가 된다. 나는 1999년에 야후를 떠났기 때문에, 지금 사용자들이 얼마나 되는지 정확히는 모르지만, 최근에 들은 바로는 약 20,000명이 되었다고 한다.

2 저러쿵의 역설 #

리스프가 무엇이 그렇게 훌륭한가? 리스프가 그렇게 훌륭하다면, 왜 모든 사람이 그것을 사용하지 않는가? 이것은 수사적인(rhetorical) 질문 같기도 하지만, 실제로는 여기에 대한 직설적인 답이 있다. 광신도들만 볼 수 있는 어떤 마술적인 특성 때문이 아니라 손에 넣을 수 있는 가장 강력한 언어이기 때문에 리스프는 그렇게 훌륭한 것이다. 그리고 모든 사람들이 그것을 사용하지 않는 이유는 프로그래밍 언어가 단순한 기술이 아니라 생각의 습관이며, 그것보다 천천히 변하는 것이 없기 때문이다. 물론 이 두 가지 답은 설명이 필요하다.

먼저 지독한 논쟁을 불러일으킬 만한 발언을 하겠다. “프로그래밍 언어들은 그 능력에 차이가 있다.”

고급 언어가 기계어보다 더 강력하다는 것에 대해 논쟁을 벌일 사람은 별로 없을 것이다. 오늘날 대부분의 프로그래머들은 거의 기계어로 프로그래밍을 하고 싶어 하지 않는다. 그 대신 고급 언어로 프로그래밍을 하고, 컴파일러가 대신 기계어로 번역해 줄 것이다. 오늘날에는 이 생각이 하드웨어에 적용되기까지 한다. 1980년 이래로 명령어 집합(instruction set)들은 인간 프로그래머보다는 컴파일러를 위해 설계되어 왔다.

모든 프로그램을 기계어를 써서 손으로 작성하는 것이 잘못이라는 것은 누구나 알고 있다. 이것보다 더 일반적인 원리가 있는데 그것을 이해하는 사람은 많지 않다. 그것은, 몇 가지 언어 중에서 하나를 선택할 수 있다면, 다른 모든 조건이 같을 때, 가장 강력한 것이 아닌 언어로 프로그래밍을 하는 것은 잘못이라는 것이다. 주: 튜링 기계와 동등하다는(Turing equivalent) 점에서 모든 언어는 능력이 같지만, 프로그래머들이 관심을 갖는 것은 그런 뜻이 아니다. (튜링 기계의 프로그래밍을 하고 싶은 사람은 없다. 역자 주: 튜링 기계(Turing machine)는 어떤 위치에서 입력 값과 자신의 상태에 따라 특정 값을 출력하거나 다음 위치로 이동하거나 자신의 상태를 바꾸는 일을 순서대로 해 나가는 추상적인 장치를 말한다.) 프로그래머들이 관심을 갖는 종류의 능력이 무엇인지 형식을 갖춰 정의하기는 어렵겠지만, 능력이 떨어지는 언어로는 더 강력한 언어를 위한 인터프리터를 만들어야 겨우 얻을 수 있는 기능이라고 하면 어느 정도 그것을 설명했다고 볼 수 있겠다. 어떤 A라는 언어에는 문자열에서 공백을 제거하는 연산자가 있고 B에는 없다고 해서 A가 더 강력하다고 할 수는 없을 것이다. B로도 그런 일을 하는 서브루틴을 만들 수 있을 것이기 때문이다. 하지만 A는 이를테면 재귀(recursion)를 지원하는데 B는 그렇지 않다면, 이것은 라이브러리 함수를 만들어서 고칠 수 있는 일이 아닐 것이다.

이 법칙에는 예외가 많이 있다. 특정한 언어로 만들어진 프로그램과 매우 긴밀하게 동작해야 하는 프로그램을 만들어야 한다면, 새 프로그램도 똑같은 언어로 만드는 것이 좋을 것이다. 숫자 되풀이(number crunching)나 비트 조작(bit manipulation)처럼 아주 간단한 일만 하면 되는 프로그램을 만들어야 한다면, 덜 추상적인 언어를 사용하는 것이 특히 속도가 약간 더 빨라질 것이므로 더 좋을지도 모른다. 짧은 일회용 프로그램을 만들어야 한다면, 그 일에 가장 잘 맞는 라이브러리 함수가 있는 언어를 사용하는 것이 가장 좋을지도 모른다. 하지만 일반적으로 응용 소프트웨어를 만든다면, 구할 수 있는 가장 강력한 (상당히 효율적인) 언어를 사용하고 싶을 것이며, 그것과 다른 언어를 사용하는 것은 기계어로 프로그래밍을 하는 것보다는 덜 하겠지만 그것과 비슷한 잘못이다.

기계어가 매우 저급의 언어라는 것은 잘 안다. 하지만 적어도 일종의 사회적 관습에 따라 고급 언어들은 모두 동등한 것처럼 취급된다. 그러나 그렇지 않다. 기술적으로 “고급 언어”라는 용어는 별로 뚜렷한 의미가 없다. 한쪽에 기계어를 놓고 반대쪽에 고급 언어들을 다 갖다놓는 것은 아무 구분이 없는 것이다. 언어들은 추상성에 대해 가장 강력한 것에서부터 기계어에까지 이르는 연속선 위에 놓이며, 능력에서도 차이가 있다. 샌님(nerd)들을 위한 주: (연속선이 아니라) 위로 올라갈수록 좁아지는 격자(lattice)일 수도 있다. 여기서 중요한 것은 모양이 아니라 최소한 부분적으로는 순서가 있다는 생각이다.

코볼(Cobol)을 보자. 코볼은 기계어로 컴파일이 된다는 점에서 고급 언어이다. 그런데 누가 코볼이 이를테면 파이썬(Python)과 능력이 동등하다고 진지하게 주장하겠는가? 이것은 파이썬보다는 기계어에 더 가까울 것이다.

펄(Perl) 4는 어떤가? 펄 4에서 펄 5로 넘어가면서 사전 닫힌 함수(lexical closure)가 추가되었다. 역자 주: 래리 월(Larry Wall) 등의 “Programming Perl” 2판, 253쪽 참고. 대부분의 펄 해커들은 펄 5가 펄 4보다 더 강력하다는 사실에 동의한다. 그런데 이것을 인정한다는 것은 어떤 고급 언어가 다른 고급 언어보다 더 강력할 수 있다는 것을 인정하는 것이다. 이것은 무정하게도, 사회적인 경우를 제외하면, 구할 수 있는 가장 강력한 것을 사용해야 한다는 결론에 이르게 된다.

하지만 이런 생각이 그 결론으로 이어지는 경우는 드물다. 어느 정도 나이가 들면 프로그래머들은 언어를 자발적으로 바꾸지 않는다. 어떤 다른 언어에 익숙하게 되더라도 그저 좋다고 생각할 뿐인 경우가 많다.

프로그래머들은 자기 마음에 드는 언어에 무척 집착한다. 나는 어느 누구의 마음도 상하게 하고 싶지 않으므로, 이 점에 대해 설명하기 위해 ‘저러쿵(Blub)’이라고 불리는 가설적 언어를 사용하겠다. 역자 주: Blub은 이러쿵저러쿵(blah, blub)에서 나온 표현이므로 ‘저러쿵’이라고 번역한다. ‘저러쿵’은 추상성의 연속선 위에서 한가운데 놓인다. 이것은 가장 강력한 언어는 아니지만, 코볼이나 기계어보다는 강력하다.

그리고 실제로 우리의 가설적 ‘저러쿵’ 프로그래머는 그 둘 중 어느 것도 사용하지 않을 것이다. 그는 기계어로 프로그래밍을 하지 않는다. 그것은 컴파일러가 할 일이다. 코볼에 대해서도 그는 어떻게 그런 언어로 일을 할 수 있는지 이해가 되지 않는다. 또 코볼은 (‘저러쿵’의 선택받은 기능인) x도 없다.

우리의 가설적 ‘저러쿵’ 프로그래머가 능력의 연속선 아래를 보는 한, 그는 자신이 내려다보고 있다는 것을 안다. ‘저러쿵’보다 능력이 떨어지는 언어들은 틀림없이 능력이 떨어지는 것이다. 그 언어들은 그가 익숙한 어떤 기능들이 빠져 있기 때문이다. 그런데 우리의 가설적 ‘저러쿵’ 프로그래머가 능력의 연속선 위쪽으로 고개를 돌릴 때, 그는 올려다보고 있다는 것을 깨닫지 못한다. 그가 보는 것은 기묘한 언어들일 뿐이다. 그는 그것들이 여러 가지 텁수룩한 것들이 덤으로 붙었을 뿐, ‘저러쿵’과 능력은 동등하다고 생각한다. ‘저러쿵’은 그에게 딱 좋다. 그가 ‘저러쿵’으로 생각하기 때문이다.

그런데 우리가 능력의 연속선 위쪽에 있는 언어를 사용하는 프로그래머의 관점에서 볼 때, 그는 반대로 ‘저러쿵’을 내려다본다. 도대체 ‘저러쿵’으로 뭘 할 수 있지? 그건 y도 없잖아.

귀납적으로 보면, 다양한 언어들의 능력의 차이를 제대로 보는 위치에 있는 프로그래머들은 오직 가장 강력한 언어를 이해하는 사람들이다. (리스프를 통해 더 좋은 프로그래머가 될 수 있다고 한 에릭 레이먼드의 말은 이런 의미일 것이다.) 이 ‘저러쿵의 역설’ 때문에 다른 사람들의 의견을 무작정 믿을 수는 없다. 그들은 자기가 어쩌다 사용하게 된 언어에 만족한다. 그 언어가 그들이 프로그램에 대해 생각하는 방식을 지배하기 때문이다.

나는 베이직(Basic)으로 프로그램을 만들던 고등학생 시절의 경험에서도 이것을 잘 알 수 있다. 베이직은 재귀(recursion)도 지원하지 않았다. 지금은 재귀를 사용하지 않는 프로그램을 만든다는 것을 상상하기 어렵지만, 그 당시에는 그것이 없어서 불편한 적이 없었다. 나는 베이직으로 생각했고, 나는 베이직의 명수였다. 모르는 것만 빼면 나는 모든 것을 다 알고 있었다.

에릭 레이먼드가 해커들에게 추천한 다섯 언어는 능력의 연속선 위의 여러 지점에 놓인다. 그것들이 상대적으로 어느 위치에 놓이는가는 민감한 문제이다. 나는 리스프가 맨 위에 놓인다고 말할 것이다. 이 주장을 뒷받침하기 위해 다른 네 언어에 없기 때문에 불편한 것들 중 한 가지를 말해 보겠다. 도대체 매크로도 없는 그런 언어들로 어떻게 일을 할 수 있는가? 주: 매크로를 독립된 기능으로 취급하는 것은 오해의 소지가 조금 있다. 실제로 그 유용성은 사전 닫힌 함수(lexical closure)나 잔여 매개변수(rest parameter) 같은 리스프의 다른 기능들에 의해 더욱 강화된다.

많은 언어에 매크로라고 불리는 것이 있다. 하지만 리스프의 매크로는 독특하다. 그리고 믿거나 말거나, 매크로가 하는 일은 괄호들과 관계가 있다. 리스프 설계자들은 그 많은 괄호들을 다른 언어와 달라 보이게 하기 위해 넣은 것이 아니다. ‘저러쿵’ 프로그래머에게는 리스프 코드가 기묘하게 보일 것이다. 그러나 그 괄호들이 있는 것은 다 이유가 있다. 그것들은 리스프와 다른 언어들 사이의 근본적 차이를 보여 주는 외관상의 증거이다.

리스프 코드는 리스프 데이터 객체들로 이뤄진다. 소스 파일이 문자들을 포함하고 있다는 사소한 의미에서가 아니라, 문자열은 이 언어가 지원하는 자료형들 중 하나이다. 리스프 코드는, 파서(parser)를 거치고 나면, 순회(traverse)할 수 있는 자료 구조들로 만들어진다.

컴파일러가 어떻게 동작하는지 이해한다면, 리스프의 문법이 이상하다기보다는 문법이 없다고 하는 것이 실제에 가깝다. 프로그램은 파스 트리(parse tree)에 만드는 것이다. 다른 언어들이 파싱될 때는 컴파일러 안에서 파스 트리가 생성된다. 그런데 이 파스 트리는 프로그램에서 얼마든지 접근할 수 있다. 파스 트리를 조작하는 프로그램을 만들 수도 있다. 리스프에서는 이 프로그램을 매크로라고 부르는 것이다. 매크로는 프로그램을 만드는 프로그램이다.

프로그램을 만드는 프로그램? 도대체 언제 그런 것이 필요하다는 말인가? 코볼로 생각한다면 그렇게 흔한 일이 아니다. 리스프로 생각한다면 항상 필요하다. 여기서 강력한 매크로의 예제를 제시할 수 있다면 편리할 것이다. 어떤가, 한 번 해 볼까? 하지만 그렇게 한다면, 리스프를 모르는 사람들에게는 횡설수설하는 것으로 보일 것이다. 그것이 무슨 뜻인지 이해하기 위해 알아야 하는 모든 것을 설명할 여유는 없다. 내가 쓴 “ANSI Common Lisp”에서 나는 최대한 빨리 진행하려고 했지만, 그렇게 해도 160쪽에 가서야 매크로를 다룰 수 있었다.

하지만 설득력 있는 일종의 논거를 제시할 수는 있을 것 같다. 비어웹(Viaweb) 편집기의 소스 코드는 약 20-25%가 매크로였다. 매크로는 일반 리스프 함수들보다 만들기가 어렵고, 필요 없을 때 사용하는 것은 안 좋은 버릇으로 간주된다. 그래서 그 코드에 있는 매크로들은 모두 있어야 하기 때문에 있는 것이었다. 즉, 이 프로그램의 코드에서 적어도 20-25%는 다른 어떤 언어로도 쉽게 할 수 없는 일들을 하고 있다는 말이다. ‘저러쿵’ 프로그래머가 리스프의 신비한 능력에 대한 내 주장에 대해 아무리 회의적이더라도 이것만큼은 궁금해 할 것이다. 우리는 우리 혼자 즐기려고 이런 코드를 만들지 않았다. 우리는 조그만 벤처회사였고, 우리와 경쟁자들 사이에 기술적인 장벽을 놓기 위해 최대한 열심히 프로그래밍을 했다.

의심 많은 사람은 여기에 무슨 상관관계가 있는지 궁금해질 것이다. 우리 코드의 많은 부분은 다른 언어들로는 하기 어려운 일들을 할 수 있었다. 그 결과로 나온 소프트웨어는 경쟁자들의 소프트웨어가 하지 못하는 일들을 했다. 아마도 이 둘 사이에는 어떤 종류의 연결이 있었을 것이다. 그 연결된 끈을 따라가 보기 바란다. (포사이드의 소설에서) 나무다리를 하고 절뚝거리며 가는 노인에게는 눈에 잘 띄는 것 이상의 무엇이 있을지도 모른다.

3 벤처회사들을 위한 합기도 #

하지만 나는 누군가가 당장 리스프를 배우기로 마음먹을 것을 기대하지는 않는다. 이 논설의 목적은 누군가의 생각을 바꾸려는 것이 아니라, 리스프를 사용하는 것에 이미 관심을 갖고 있는 사람들에게 다시 확신을 주려는 것이다. 그들은 리스프가 강력한 언어임을 알고 있지만 그것이 널리 쓰이지 않기 때문에 고민하고 있다. 그런데 경쟁적인 상황에서는 그것이 유리하다. 리스프의 능력은 경쟁자들이 그것을 모른다는 점에서 더욱 커진다.

벤처회사에서 리스프를 사용할 것에 대해 생각 중이라면, 그것이 널리 이해되고 있지 않은 것을 걱정할 필요가 없다. 그 상태가 그대로 유지되기를 바라기만 하라. 그리고 실제로도 그럴 것이다. 프로그래밍 언어의 속성상 사람들 대부분은 자기가 현재 사용하고 있는 것에 만족한다. 컴퓨터 하드웨어는 개인적인 습관보다 훨씬 빨리 변하기 때문에 프로그래밍 습관은 프로세서보다 보통 10년에서 20년은 뒤쳐진다. MIT와 같은 곳에서는 1960년대 초반에 고급 언어로 프로그램을 만들었지만, 대부분의 회사들은 1980년대까지도 계속 기계어로 코드를 작성했다. 프로세서가 문 닫고 집에 가고 싶어 하는 바텐더처럼 RISC 명령어 집합으로 사람들을 쫓아낼 때까지 많은 사람들이 계속 기계어를 썼을 것이 틀림없다.

대개 기술은 빨리 변한다. 하지만 프로그래밍 언어는 다르다. 프로그래밍 언어는 단순한 기술이 아니다. 프로그래머는 그것으로 생각한다. 절반은 기술이고 절반은 종교라고 하겠다. 주: 그 결과, 프로그래밍 언어를 비교하는 것은, 종교 전쟁의 형태가 되든가 아니면 대학 학부 교재처럼 중립적인 입장을 견지하여 실제로는 인류학 저술이 되어 버린다. 마음의 평화를 중시하거나 자기 자리를 지키려는 사람들은 이런 화제를 피한다. 하지만 문제가 되는 것은 항상 절반은 종교적이다. 세상에는 공부할 가치가 있는 것이 있다. 새로운 언어를 설계하고 싶다면 특히 그렇다. 그래서 중간의(median) 언어, 즉 중간의 프로그래머가 사용하는 언어는 빙산처럼 천천히 움직인다. 가비지 수집(garbage collection)은 1960년경에 리스프에 의해 도입되어, 지금은 좋은 것으로 널리 인식되고 있다. 실행 시간 자료형 설정(runtime typing)도 마찬가지였는데, 이제 점점 인기를 얻고 있다. 사전 닫힌 함수(lexical closure)는 리스프에 의해 1970년 초에 도입되었는데, 이제 겨우 레이더 화면에 잡히고 있다. 매크로는 리스프에 의해 1960년대 중반에 도입되었는데, 여전히 미지의 세계이다.

분명히, 중간의 언어는 막강한 추진력이 있다. 이 강력한 힘에 맞서 싸울 수 있다고 말하는 것이 아니다. 내 말은 정확하게 그 반대이다. 즉, 합기도 수련자와 같이 그 힘을 상대방에게 역이용할 수 있다는 것이다.

큰 회사에서 일한다면, 이것은 쉽지 않을 수도 있다. 잘난 체하는(pointy-haired) 상사가 신문에서, 20년 전 에이다(Ada)가 그랬듯이, 어떤 언어가 이 세상을 접수할 준비가 됐다는 기사를 막 읽었을 때, 그에게 리스프로 무엇을 만들게 해 달라고 설득하기는 힘들 것이다. 하지만, 아직 잘난 체하는 상사들이 없는 벤처회사에서 일한다면, 우리가 그랬듯이 ‘저러쿵의 역설(Blub paradox)’을 유리하게 이용할 수 있을 것이다. 중간의 언어에만 매달려 있는 경쟁자들이 전혀 대적할 수 없을 만한 기술을 사용할 수 있는 것이다.

벤처회사에서 일한다면, 경쟁자를 쉽게 평가할 수 있는 요령이 있다. 그들의 구인 목록(job listing)을 읽어 보라. 그들의 사이트에 있는 다른 것들은 모두 어디서 가져온 사진(stock photo)이거나 평범한 글에 다름없는 것(prose equivalent)이지만, 구인 목록에는 그들이 원하는 것이 명확하게 드러날 수밖에 없다. 그렇지 않으면 엉뚱한 지원자들만 올 것이기 때문이다.

우리가 비어웹(Viaweb) 작업을 하는 몇 년 동안 나는 수많은 구인 안내문(job description)을 읽었다. 거의 매달 새로운 경쟁자가 웅크리고 있다가 튀어나오는 것처럼 보였다. 그러면 내가 우선 하던 일은 실제 동작하는 온라인 시연 제품이 있는지 확인한 다음에 그들의 구인 목록을 보는 것이었다. 이렇게 2, 3년을 한 뒤에는 어떤 회사에 대해 걱정해야 하는지 그렇지 않은지 구분할 수도 있었다. 구인 안내문에 IT의 냄새가 많이 날수록 그 회사는 덜 위험했다. 가장 안전한 유형은 오라클(Oracle) 경력자를 찾는 회사들이었다. 이런 회사들은 전혀 걱정할 필요가 없었다. 그들이 C++나 자바 개발자들을 찾는다고 할 때도 안심이었다. 그들이 펄이나 파이썬 프로그래머를 찾는다면 조금 놀랐다. 이 때부터 그 회사에서 최소한 기술 부문은 진짜 해커들이 잡고 있다는 소리로 들리기 시작한다. 내가 리스프 해커를 찾는 구인 공고(job posting)를 한 번이라도 봤다면 나는 정말로 걱정했을 것이다.