평균을 뛰어넘는 법 | undefined | 폴 그레이엄의 에세이

스타트업을 시작하고 싶으신가요? Y Combinator에서 자금을 지원받으세요.

2001년 4월, 2003년 4월 개정

(이 글은 2001년 Franz 개발자 심포지엄에서 발표된 강연을 바탕으로 작성되었습니다.)

1995년 여름, 제 친구 로버트 모리스와 저는 Viaweb이라는 스타트업을 시작했습니다. 저희 계획은 최종 사용자가 온라인 상점을 구축할 수 있도록 하는 소프트웨어를 만드는 것이었습니다. 당시 이 소프트웨어의 참신한 점은 일반 웹 페이지를 인터페이스로 사용하여 저희 서버에서 실행된다는 것이었습니다.

물론 많은 사람이 동시에 이런 아이디어를 떠올릴 수 있었겠지만, 제가 아는 한 Viaweb은 최초의 웹 기반 애플리케이션이었습니다. 저희에게는 너무나 참신한 아이디어여서 회사 이름도 거기서 따왔습니다: Viaweb, 저희 소프트웨어가 데스크톱 컴퓨터에서 실행되는 대신 웹을 통해 작동했기 때문입니다.

이 소프트웨어의 또 다른 특이한 점은 주로 Lisp이라는 프로그래밍 언어로 작성되었다는 것입니다. Lisp은 그때까지 주로 대학과 연구실에서 사용되었는데, Viaweb은 Lisp으로 작성된 최초의 대규모 최종 사용자 애플리케이션 중 하나였습니다. [1]

비밀 병기

에릭 레이먼드는 "해커가 되는 법"이라는 에세이를 썼는데, 그 글에서 그는 해커 지망생들에게 어떤 언어를 배워야 하는지 알려줍니다. 그는 배우기 쉽기 때문에 Python과 Java로 시작할 것을 제안합니다. 진지한 해커라면 Unix를 해킹하기 위해 C를 배우고, 시스템 관리 및 CGI 스크립트를 위해 Perl도 배우고 싶어 할 것입니다. 마지막으로, 정말 진지한 해커는 Lisp을 배울 것을 고려해야 합니다:

Lisp은 마침내 그것을 이해했을 때 얻게 될 심오한 깨달음의 경험 때문에 배울 가치가 있습니다; 그 경험은 Lisp 자체를 많이 사용하지 않더라도 남은 평생 동안 당신을 더 나은 프로그래머로 만들어 줄 것입니다.

이것은 라틴어를 배우는 것에 대해 흔히 듣는 주장과 같습니다. 라틴어는 고전학 교수 외에는 직업을 얻게 해주지 않겠지만, 당신의 정신을 향상시키고 영어처럼 당신이 사용하고 싶은 언어로 더 나은 작가가 되게 해줄 것입니다.

하지만 잠깐만요. 이 비유는 그렇게까지 확장되지 않습니다. 라틴어가 직업을 얻게 해주지 않는 이유는 아무도 그것을 말하지 않기 때문입니다. 라틴어로 글을 쓰면 아무도 당신을 이해할 수 없습니다. 하지만 Lisp은 컴퓨터 언어이고, 컴퓨터는 프로그래머인 당신이 시키는 어떤 언어든 말합니다.

그러니 Lisp이 그가 말한 것처럼 당신을 더 나은 프로그래머로 만들어준다면, 왜 그것을 사용하고 싶지 않겠습니까? 만약 화가가 자신을 더 나은 화가로 만들어 줄 붓을 제안받는다면, 그는 모든 그림에 그것을 사용하고 싶어 할 것 같지 않습니까? 저는 여기서 에릭 레이먼드를 비웃으려는 것이 아닙니다. 전반적으로 그의 조언은 훌륭합니다. 그가 Lisp에 대해 말하는 것은 거의 통념과 같습니다. 하지만 통념에는 모순이 있습니다: Lisp은 당신을 더 나은 프로그래머로 만들어 줄 것이지만, 당신은 그것을 사용하지 않을 것입니다.

왜 안 될까요? 프로그래밍 언어는 결국 도구일 뿐입니다. Lisp이 정말 더 나은 프로그램을 만들어낸다면, 당신은 그것을 사용해야 합니다. 그리고 그렇지 않다면, 누가 그것을 필요로 하겠습니까?

이것은 단지 이론적인 질문이 아닙니다. 소프트웨어는 자연 독점에 취약한 매우 경쟁적인 사업입니다. 소프트웨어를 더 빠르고 더 잘 작성하는 회사는 다른 모든 조건이 동일하다면 경쟁사를 사업에서 몰아낼 것입니다. 그리고 스타트업을 시작할 때, 당신은 이것을 매우 절실히 느낍니다. 스타트업은 모든 것을 걸거나 아무것도 얻지 못하는 제안인 경향이 있습니다. 당신은 부자가 되거나, 아무것도 얻지 못합니다. 스타트업에서 잘못된 기술에 베팅하면 경쟁사가 당신을 짓밟을 것입니다.

로버트와 저는 둘 다 Lisp을 잘 알고 있었고, 우리의 직감을 믿고 Lisp을 사용하지 않을 이유를 찾을 수 없었습니다. 우리는 다른 모든 사람들이 C++나 Perl로 소프트웨어를 작성하고 있다는 것을 알고 있었습니다. 하지만 그것이 아무 의미도 없다는 것도 알고 있었습니다. 그런 식으로 기술을 선택한다면 Windows를 실행하고 있을 것입니다. 기술을 선택할 때는 다른 사람들이 무엇을 하는지 무시하고, 무엇이 가장 잘 작동할지만 고려해야 합니다.

이것은 스타트업에서 특히 그렇습니다. 대기업에서는 다른 모든 대기업이 하는 대로 할 수 있습니다. 하지만 스타트업은 다른 모든 스타트업이 하는 대로 할 수 없습니다. 많은 사람이 심지어 스타트업에서도 이것을 깨닫지 못한다고 생각합니다.

평균적인 대기업은 연간 약 10% 성장합니다. 따라서 당신이 대기업을 운영하고 다른 평균적인 대기업이 하는 모든 방식을 따른다면, 평균적인 대기업만큼 잘할 것으로 예상할 수 있습니다-- 즉, 연간 약 10% 성장할 것입니다.

물론 스타트업을 운영할 때도 마찬가지입니다. 평균적인 스타트업이 하는 모든 방식을 따른다면, 평균적인 성과를 기대해야 합니다. 여기서 문제는 평균적인 성과는 당신이 사업을 접게 될 것이라는 의미입니다. 스타트업의 생존율은 50%보다 훨씬 낮습니다. 따라서 당신이 스타트업을 운영하고 있다면, 뭔가 특이한 일을 해야 합니다. 그렇지 않으면 곤경에 처할 것입니다.

1995년으로 돌아가서, 우리는 경쟁사들이 이해하지 못했고 심지어 지금도 거의 이해하지 못하는 것을 알고 있었습니다: 당신의 서버에서만 실행되어야 하는 소프트웨어를 작성할 때는 어떤 언어든 원하는 대로 사용할 수 있다는 것입니다. 데스크톱 소프트웨어를 작성할 때는 운영체제와 동일한 언어로 애플리케이션을 작성하려는 강한 편향이 있습니다. 10년 전에는 애플리케이션을 작성한다는 것은 C로 애플리케이션을 작성한다는 것을 의미했습니다. 하지만 웹 기반 소프트웨어의 경우, 특히 언어와 운영체제 모두의 소스 코드를 가지고 있다면, 원하는 어떤 언어든 사용할 수 있습니다.

그러나 이 새로운 자유는 양날의 검입니다. 이제 어떤 언어든 사용할 수 있으므로, 어떤 언어를 사용할지 생각해야 합니다. 아무것도 변하지 않은 척하려는 회사들은 경쟁사들이 그렇지 않다는 것을 알게 될 위험이 있습니다.

어떤 언어든 사용할 수 있다면, 어떤 것을 사용하시겠습니까? 우리는 Lisp을 선택했습니다. 한 가지 이유는 이 시장에서 빠른 개발이 중요하다는 것이 분명했기 때문입니다. 우리는 모두 맨 처음부터 시작하고 있었으므로, 경쟁사보다 먼저 새로운 기능을 완성할 수 있는 회사가 큰 이점을 가질 것이었습니다. 우리는 Lisp이 소프트웨어를 빠르게 작성하는 데 정말 좋은 언어라는 것을 알고 있었고, 서버 기반 애플리케이션은 완성되는 즉시 소프트웨어를 출시할 수 있기 때문에 빠른 개발의 효과를 증폭시킵니다.

다른 회사들이 Lisp을 사용하고 싶어 하지 않는다면, 더욱 좋았습니다. 그것은 우리에게 기술적 우위를 줄 수 있었고, 우리는 얻을 수 있는 모든 도움이 필요했습니다. Viaweb을 시작할 때, 우리는 사업 경험이 전혀 없었습니다. 마케팅, 인력 채용, 자금 조달, 고객 확보에 대해 아무것도 몰랐습니다. 우리 둘 중 누구도 소위 말하는 '진짜 직업'을 가져본 적이 없었습니다. 우리가 잘하는 유일한 것은 소프트웨어 작성뿐이었습니다. 우리는 그것이 우리를 구해줄 것이라고 희망했습니다. 소프트웨어 부문에서 얻을 수 있는 어떤 이점도 우리는 취할 것이었습니다.

그래서 Lisp을 사용하는 것은 일종의 실험이었다고 말할 수 있습니다. 우리의 가설은 Lisp으로 소프트웨어를 작성하면 경쟁사보다 기능을 더 빠르게 완성할 수 있고, 경쟁사들이 할 수 없는 일들을 우리 소프트웨어에서 할 수 있을 것이라는 것이었습니다. 그리고 Lisp이 매우 고수준이었기 때문에, 큰 개발 팀이 필요하지 않아 비용이 더 낮을 것이었습니다. 만약 그렇다면, 우리는 더 적은 비용으로 더 나은 제품을 제공하고도 이익을 낼 수 있을 것이었습니다. 결국 모든 사용자를 확보하고 경쟁사들은 아무도 얻지 못하며, 결국 사업을 접게 될 것이었습니다. 어쨌든 그것이 우리가 바라던 일이었습니다.

이 실험의 결과는 어땠을까요? 다소 놀랍게도, 그것은 성공했습니다. 우리는 결국 20~30개 정도의 많은 경쟁사를 가졌지만, 그들의 소프트웨어 중 어느 것도 우리와 경쟁할 수 없었습니다. 우리는 서버에서 실행되면서도 데스크톱 애플리케이션처럼 느껴지는 WYSIWYG 온라인 상점 빌더를 가지고 있었습니다. 경쟁사들은 CGI 스크립트를 가지고 있었습니다. 그리고 우리는 항상 기능 면에서 그들보다 훨씬 앞서 있었습니다. 때로는 절박한 마음에 경쟁사들이 우리가 가지고 있지 않은 기능을 도입하려고 시도했습니다. 하지만 Lisp 덕분에 우리의 개발 주기는 너무 빨라서 경쟁사가 보도 자료로 발표한 지 하루나 이틀 만에 새로운 기능을 복제할 수 있었습니다. 보도 자료를 다루는 기자들이 우리에게 전화할 때쯤이면, 우리도 이미 새로운 기능을 가지고 있었습니다.

경쟁사들에게는 우리가 어떤 종류의 비밀 병기를 가지고 있는 것처럼 보였을 것입니다-- 마치 우리가 그들의 에니그마 암호를 해독하고 있는 것처럼 말입니다. 사실 우리는 비밀 병기를 가지고 있었지만, 그들이 깨달은 것보다 훨씬 간단했습니다. 아무도 그들의 기능에 대한 소식을 우리에게 유출하지 않았습니다. 우리는 단지 누구도 가능하다고 생각하지 못했던 속도로 소프트웨어를 개발할 수 있었을 뿐입니다.

제가 아홉 살쯤 되었을 때, 우연히 프레데릭 포사이스의 _자칼의 날_이라는 책을 손에 넣었습니다. 주인공은 프랑스 대통령을 암살하기 위해 고용된 암살자입니다. 암살자는 대통령의 경로가 내려다보이는 아파트로 가기 위해 경찰을 지나쳐야 합니다. 그는 목발을 짚은 노인으로 변장하고 그들 옆을 지나가지만, 그들은 그를 전혀 의심하지 않습니다.

우리의 비밀 병기도 비슷했습니다. 우리는 이상한 AI 언어로, 괄호로 가득 찬 기이한 구문을 가진 소프트웨어를 작성했습니다. 수년 동안 Lisp이 그런 식으로 묘사되는 것을 듣는 것이 저를 짜증 나게 했습니다. 하지만 이제 그것은 우리에게 유리하게 작용했습니다. 사업에서 경쟁사들이 이해하지 못하는 기술적 우위보다 더 가치 있는 것은 없습니다. 사업에서, 전쟁에서처럼, 기습은 힘만큼이나 가치가 있습니다.

그래서, 좀 부끄럽지만, Viaweb에서 일하는 동안 Lisp에 대해 공개적으로 아무 말도 하지 않았습니다. 우리는 언론에 그것을 언급한 적이 없었고, 우리 웹사이트에서 Lisp을 검색해도 제 이력에 있는 두 권의 책 제목만 찾을 수 있었을 것입니다. 이것은 우연이 아니었습니다. 스타트업은 경쟁사에게 가능한 한 적은 정보를 주어야 합니다. 그들이 우리 소프트웨어가 어떤 언어로 작성되었는지 몰랐거나 신경 쓰지 않았다면, 저는 그 상태를 유지하고 싶었습니다.[2]

우리 기술을 가장 잘 이해한 사람들은 고객이었습니다. 그들은 Viaweb이 어떤 언어로 작성되었는지 신경 쓰지 않았지만, 그것이 정말 잘 작동한다는 것을 알아차렸습니다. 그것은 그들이 말 그대로 몇 분 만에 멋진 온라인 상점을 구축할 수 있게 해주었습니다. 그래서 주로 입소문을 통해 우리는 점점 더 많은 사용자를 확보했습니다. 1996년 말까지 우리는 약 70개의 온라인 상점을 운영했습니다. 1997년 말에는 500개였습니다. 6개월 후, Yahoo가 우리를 인수했을 때, 우리는 1070명의 사용자를 가지고 있었습니다. 오늘날 Yahoo Store로서 이 소프트웨어는 시장을 계속 지배하고 있습니다. 그것은 Yahoo의 가장 수익성 높은 부분 중 하나이며, 그것으로 구축된 상점들은 Yahoo Shopping의 기반입니다. 저는 1999년에 Yahoo를 떠났기 때문에 지금 몇 명의 사용자가 있는지 정확히는 모르지만, 마지막으로 들었을 때는 약 20,000명 정도였습니다.

블럽 역설

Lisp은 무엇이 그렇게 대단할까요? 그리고 Lisp이 그렇게 대단하다면, 왜 모두가 그것을 사용하지 않을까요? 이것들은 수사적인 질문처럼 들리지만, 실제로는 간단한 답이 있습니다. Lisp이 그렇게 대단한 것은 헌신적인 사람들만이 볼 수 있는 어떤 마법 같은 특성 때문이 아니라, 단순히 사용 가능한 가장 강력한 언어이기 때문입니다. 그리고 모두가 그것을 사용하지 않는 이유는 프로그래밍 언어가 단순히 기술이 아니라 사고방식이기도 하며, 그 어떤 것도 더 느리게 변하지 않기 때문입니다. 물론, 이 두 가지 답 모두 설명이 필요합니다.

충격적으로 논란이 될 만한 진술로 시작하겠습니다: 프로그래밍 언어는 그 힘이 다양합니다.

적어도 고수준 언어가 기계어보다 더 강력하다는 점은 거의 논쟁의 여지가 없을 것입니다. 오늘날 대부분의 프로그래머는 일반적으로 기계어로 프로그래밍하고 싶어 하지 않을 것이라는 데 동의할 것입니다. 대신, 고수준 언어로 프로그래밍하고 컴파일러가 그것을 기계어로 번역하도록 해야 합니다. 이 아이디어는 이제 하드웨어에도 내장되어 있습니다: 1980년대 이후로 명령어 세트는 인간 프로그래머보다는 컴파일러를 위해 설계되었습니다.

모든 사람이 전체 프로그램을 기계어로 손으로 작성하는 것이 실수라는 것을 알고 있습니다. 덜 자주 이해되는 것은 여기에 더 일반적인 원칙이 있다는 것입니다: 여러 언어 중에서 선택할 수 있다면, 다른 모든 조건이 동일하다면, 가장 강력한 언어 외의 다른 언어로 프로그래밍하는 것은 실수라는 것입니다. [3]

이 규칙에는 많은 예외가 있습니다. 특정 언어로 작성된 프로그램과 매우 밀접하게 작동해야 하는 프로그램을 작성하는 경우, 새 프로그램을 동일한 언어로 작성하는 것이 좋은 생각일 수 있습니다. 숫자 계산이나 비트 조작과 같이 매우 간단한 작업만 수행해야 하는 프로그램을 작성하는 경우, 특히 약간 더 빠를 수 있으므로 덜 추상적인 언어를 사용하는 것이 좋습니다. 그리고 짧고 일회성 프로그램을 작성하는 경우, 해당 작업에 가장 적합한 라이브러리 함수를 가진 언어를 사용하는 것이 더 나을 수 있습니다. 그러나 일반적으로 애플리케이션 소프트웨어의 경우, 얻을 수 있는 가장 강력한 (합리적으로 효율적인) 언어를 사용해야 하며, 다른 것을 사용하는 것은 기계어로 프로그래밍하는 것과 정확히 같은 종류의 실수이며, 정도는 덜할 수 있습니다.

기계어는 매우 저수준이라는 것을 알 수 있습니다. 그러나 적어도 일종의 사회적 관습으로서, 고수준 언어는 종종 모두 동등하게 취급됩니다. 그렇지 않습니다. 기술적으로 "고수준 언어"라는 용어는 매우 명확한 의미를 가지지 않습니다. 한쪽에는 기계어가 있고 다른 쪽에는 모든 고수준 언어가 있는 구분선은 없습니다. 언어는 추상성의 연속체 [4]를 따라 가장 강력한 것부터 기계어까지 이어지며, 기계어 자체도 그 힘이 다양합니다.

Cobol을 생각해 보세요. Cobol은 기계어로 컴파일된다는 의미에서 고수준 언어입니다. Cobol이 예를 들어 Python과 동등한 힘을 가지고 있다고 진지하게 주장할 사람이 있을까요? 아마 Python보다 기계어에 더 가깝습니다.

아니면 Perl 4는 어떻습니까? Perl 4와 Perl 5 사이에 렉시컬 클로저가 언어에 추가되었습니다. 대부분의 Perl 해커는 Perl 5가 Perl 4보다 더 강력하다는 데 동의할 것입니다. 하지만 일단 그것을 인정했다면, 하나의 고수준 언어가 다른 고수준 언어보다 더 강력할 수 있다는 것을 인정한 것입니다. 그리고 특별한 경우를 제외하고는, 얻을 수 있는 가장 강력한 언어를 사용해야 한다는 것이 필연적으로 뒤따릅니다.

하지만 이 아이디어는 결론까지 거의 따르지 않습니다. 특정 나이가 지나면 프로그래머는 자발적으로 언어를 거의 바꾸지 않습니다. 사람들이 익숙해진 어떤 언어든, 그들은 충분히 좋다고 생각하는 경향이 있습니다.

프로그래머들은 자신이 가장 좋아하는 언어에 매우 애착을 가지며, 저는 누구의 감정도 상하게 하고 싶지 않으므로, 이 점을 설명하기 위해 가상의 언어인 Blub을 사용하겠습니다. Blub은 추상성 연속체의 중간에 위치합니다. 그것은 가장 강력한 언어는 아니지만, Cobol이나 기계어보다 더 강력합니다.

그리고 사실, 우리의 가상 Blub 프로그래머는 둘 중 어느 것도 사용하지 않을 것입니다. 물론 그는 기계어로 프로그래밍하지 않을 것입니다. 그것은 컴파일러가 하는 일입니다. 그리고 Cobol에 대해서는, 그는 아무도 그것으로 어떻게든 일을 해낼 수 있는지 모릅니다. 그것은 x (당신이 선택한 Blub 기능)조차 가지고 있지 않습니다.

우리의 가상 Blub 프로그래머가 힘의 연속체를 아래로 내려다보는 한, 그는 자신이 아래를 내려다보고 있다는 것을 압니다. Blub보다 덜 강력한 언어는 그가 익숙한 어떤 기능이 없기 때문에 분명히 덜 강력합니다. 하지만 우리의 가상 Blub 프로그래머가 다른 방향, 즉 힘의 연속체를 위로 올려다볼 때, 그는 자신이 위를 올려다보고 있다는 것을 깨닫지 못합니다. 그가 보는 것은 단지 이상한 언어들일 뿐입니다. 그는 아마도 그것들을 Blub과 거의 동등한 힘을 가지고 있지만, 다른 모든 복잡한 것들이 추가된 것으로 생각할 것입니다. Blub은 그에게 충분히 좋습니다. 왜냐하면 그는 Blub으로 생각하기 때문입니다.

그러나 힘의 연속체에서 더 높은 언어를 사용하는 프로그래머의 관점으로 전환하면, 그 역시 Blub을 내려다봅니다. Blub으로 어떻게든 일을 해낼 수 있습니까? 그것은 y조차 가지고 있지 않습니다.

귀납적으로, 다양한 언어 간의 모든 힘의 차이를 볼 수 있는 위치에 있는 유일한 프로그래머는 가장 강력한 언어를 이해하는 사람들입니다. (이것이 아마 에릭 레이먼드가 Lisp이 당신을 더 나은 프로그래머로 만들어준다고 말한 의미일 것입니다.) 다른 사람들의 의견은 신뢰할 수 없습니다. Blub 역설 때문입니다: 그들은 자신이 사용하는 어떤 언어든 만족합니다. 왜냐하면 그 언어가 프로그램에 대해 생각하는 방식을 지시하기 때문입니다.

저는 고등학생 때 Basic으로 프로그램을 작성하면서 저 자신의 경험을 통해 이것을 알고 있습니다. 그 언어는 재귀조차 지원하지 않았습니다. 재귀를 사용하지 않고 프로그램을 작성하는 것을 상상하기 어렵지만, 당시에는 그것을 놓치지 않았습니다. 저는 Basic으로 생각했습니다. 그리고 저는 그것에 능숙했습니다. 제가 아는 모든 것을 마스터했습니다.

에릭 레이먼드가 해커들에게 추천하는 다섯 가지 언어는 힘의 연속체에서 다양한 지점에 위치합니다. 그들이 서로 상대적으로 어디에 위치하는지는 민감한 주제입니다. 제가 말할 것은 Lisp이 가장 위에 있다고 생각한다는 것입니다. 그리고 이 주장을 뒷받침하기 위해 다른 네 가지 언어를 볼 때 제가 부족하다고 느끼는 것 중 하나에 대해 말씀드리겠습니다. 매크로 없이는 어떻게 그 언어들로 무엇이든 할 수 있습니까? [5]

많은 언어에 매크로라는 것이 있습니다. 하지만 Lisp 매크로는 독특합니다. 믿거나 말거나, 그들이 하는 일은 괄호와 관련이 있습니다. Lisp의 설계자들은 단지 다르게 보이려고 모든 괄호를 언어에 넣은 것이 아닙니다. Blub 프로그래머에게 Lisp 코드는 이상하게 보입니다. 하지만 그 괄호들은 이유가 있어서 거기에 있습니다. 그것들은 Lisp과 다른 언어들 사이의 근본적인 차이의 외적인 증거입니다.

Lisp 코드는 Lisp 데이터 객체로 만들어집니다. 소스 파일에 문자가 포함되어 있고 문자열이 언어에서 지원하는 데이터 유형 중 하나라는 사소한 의미가 아닙니다. Lisp 코드는 파서에 의해 읽힌 후, 탐색할 수 있는 데이터 구조로 만들어집니다.

컴파일러가 어떻게 작동하는지 이해한다면, 실제로 일어나는 일은 Lisp이 이상한 구문을 가지고 있다기보다는 Lisp이 구문이 없다는 것입니다. 다른 언어가 파싱될 때 컴파일러 내에서 생성되는 파스 트리로 프로그램을 작성합니다. 하지만 이 파스 트리는 당신의 프로그램에 완전히 접근 가능합니다. 그것들을 조작하는 프로그램을 작성할 수 있습니다. Lisp에서는 이러한 프로그램을 매크로라고 부릅니다. 그것들은 프로그램을 작성하는 프로그램입니다.

프로그램을 작성하는 프로그램? 언제 그런 일을 하고 싶을까요? Cobol로 생각한다면 그리 자주 없을 것입니다. Lisp으로 생각한다면 항상 그럴 것입니다. 여기서 강력한 매크로의 예를 들고 "이것 봐요!"라고 말할 수 있다면 편리할 것입니다. 하지만 그렇게 한다면 Lisp을 모르는 사람에게는 그저 의미 없는 소리로 들릴 것입니다; 여기서 그것이 무엇을 의미하는지 이해하는 데 필요한 모든 것을 설명할 공간이 없습니다. Ansi Common Lisp에서 저는 가능한 한 빨리 진행하려고 노력했지만, 160페이지가 되어서야 매크로에 도달했습니다.

하지만 설득력 있는 주장을 할 수 있다고 생각합니다. Viaweb 편집기의 소스 코드는 아마도 20-25% 정도가 매크로였습니다. 매크로는 일반 Lisp 함수보다 작성하기 어렵고, 필요하지 않을 때 사용하는 것은 나쁜 스타일로 간주됩니다. 따라서 그 코드의 모든 매크로는 반드시 있어야 하기 때문에 거기에 있습니다. 그것이 의미하는 바는 이 프로그램 코드의 최소 20-25%가 다른 어떤 언어에서도 쉽게 할 수 없는 일들을 하고 있다는 것입니다. Blub 프로그래머가 Lisp의 신비한 힘에 대한 저의 주장에 대해 아무리 회의적이라 할지라도, 이것은 그를 궁금하게 만들어야 합니다. 우리는 우리 자신의 즐거움을 위해 이 코드를 작성한 것이 아니었습니다. 우리는 작은 스타트업이었고, 경쟁사들과 우리 사이에 기술적 장벽을 두기 위해 가능한 한 열심히 프로그래밍했습니다.

의심 많은 사람은 여기에 어떤 상관관계가 있는지 궁금해하기 시작할 수 있습니다. 우리 코드의 상당 부분이 다른 언어에서는 매우 어려운 일들을 하고 있었습니다. 그 결과로 나온 소프트웨어는 경쟁사 소프트웨어가 할 수 없는 일들을 해냈습니다. 아마도 어떤 종류의 연결이 있었을 것입니다. 저는 당신이 그 실마리를 따라가 보시기를 권합니다. 목발을 짚고 절뚝거리는 그 노인에게는 눈에 보이는 것 이상의 것이 있을지도 모릅니다.

스타트업을 위한 아이키도

하지만 저는 누구도 (25세 이상) Lisp을 배우러 나가도록 설득할 것이라고 기대하지 않습니다. 이 글의 목적은 누구의 마음을 바꾸는 것이 아니라, 이미 Lisp 사용에 관심이 있는 사람들, 즉 Lisp이 강력한 언어라는 것을 알지만 널리 사용되지 않기 때문에 걱정하는 사람들을 안심시키는 것입니다. 경쟁 상황에서는 그것이 이점입니다. Lisp의 힘은 경쟁사들이 그것을 이해하지 못한다는 사실에 의해 배가됩니다.

스타트업에서 Lisp을 사용하는 것을 고려한다면, 그것이 널리 이해되지 않는다는 것을 걱정할 필요가 없습니다. 당신은 그것이 계속 그렇게 유지되기를 바라야 합니다. 그리고 그럴 가능성이 높습니다. 프로그래밍 언어의 본질은 대부분의 사람들을 현재 사용하는 것에 만족하게 만드는 것입니다. 컴퓨터 하드웨어는 개인적인 습관보다 훨씬 빠르게 변하기 때문에 프로그래밍 관행은 보통 프로세서보다 10년에서 20년 뒤처져 있습니다. MIT와 같은 곳에서는 1960년대 초에 고수준 언어로 프로그램을 작성했지만, 많은 회사들은 1980년대까지도 기계어로 코드를 계속 작성했습니다. 저는 많은 사람들이 프로세서가 마치 문을 닫고 집에 가고 싶어 하는 바텐더처럼 RISC 명령어 세트로 전환하여 마침내 그들을 쫓아낼 때까지 기계어를 계속 작성했다고 확신합니다.

일반적으로 기술은 빠르게 변합니다. 하지만 프로그래밍 언어는 다릅니다: 프로그래밍 언어는 단순히 기술이 아니라 프로그래머가 생각하는 방식입니다. 그것들은 절반은 기술이고 절반은 종교입니다.[6] 그래서 중간 언어, 즉 중간 수준의 프로그래머가 사용하는 어떤 언어든 빙산처럼 느리게 움직입니다. 약 1960년에 Lisp에 의해 도입된 가비지 컬렉션은 이제 널리 좋은 것으로 간주됩니다. 런타임 타이핑도 마찬가지로 인기가 높아지고 있습니다. 1970년대 초 Lisp에 의해 도입된 렉시컬 클로저는 이제 막, 간신히, 레이더 화면에 나타나고 있습니다. 1960년대 중반 Lisp에 의해 도입된 매크로는 여전히 미지의 영역입니다.

분명히, 중간 언어는 엄청난 추진력을 가지고 있습니다. 저는 당신이 이 강력한 힘과 싸울 수 있다고 제안하는 것이 아닙니다. 제가 제안하는 것은 정반대입니다: 아이키도 수련자처럼, 당신은 그것을 상대방에게 역이용할 수 있다는 것입니다.

대기업에서 일한다면 이것은 쉽지 않을 수 있습니다. 뾰족머리 상사가 20년 전 Ada처럼 세상을 장악할 준비가 되어 있다는 다른 언어에 대한 기사를 방금 읽었을 때, 그에게 Lisp으로 무언가를 만들도록 설득하기 어려울 것입니다. 하지만 아직 뾰족머리 상사가 없는 스타트업에서 일한다면, 우리처럼 Blub 역설을 당신에게 유리하게 바꿀 수 있습니다: 경쟁사들이 중간 언어에 움직이지 않게 고정되어 결코 따라잡을 수 없는 기술을 사용할 수 있습니다.

만약 당신이 스타트업에서 일하게 된다면, 경쟁사를 평가하는 유용한 팁이 있습니다. 그들의 채용 공고를 읽으세요. 그들의 사이트에 있는 다른 모든 것은 스톡 사진이거나 그에 상응하는 산문일 수 있지만, 채용 공고는 그들이 원하는 것에 대해 구체적이어야 합니다. 그렇지 않으면 잘못된 후보자를 얻게 될 것입니다.

Viaweb에서 일했던 몇 년 동안 저는 많은 채용 공고를 읽었습니다. 매달 새로운 경쟁사가 어디선가 나타나는 것 같았습니다. 제가 가장 먼저 한 일은 라이브 온라인 데모가 있는지 확인한 후, 그들의 채용 공고를 보는 것이었습니다. 몇 년 동안 이렇게 한 후에는 어떤 회사를 걱정해야 하고 어떤 회사를 걱정하지 않아도 되는지 알 수 있었습니다. 채용 공고에 IT 분위기가 강할수록 그 회사는 덜 위험했습니다. 가장 안전한 종류는 Oracle 경험을 원하는 회사였습니다. 그런 회사들은 결코 걱정할 필요가 없었습니다. C++나 Java 개발자를 원한다고 말해도 안전했습니다. Perl이나 Python 프로그래머를 원한다면 조금 무서웠을 것입니다-- 그것은 적어도 기술적인 측면이 진짜 해커들에 의해 운영되는 회사처럼 들리기 시작합니다. Lisp 해커를 찾는 채용 공고를 본 적이 있다면, 저는 정말 걱정했을 것입니다.

주석

[1] Viaweb은 처음에는 두 부분으로 구성되었습니다: 사람들이 사이트를 구축하는 데 사용했던 Lisp으로 작성된 편집기와 주문을 처리하는 C로 작성된 주문 시스템. 첫 번째 버전은 주문 시스템이 작았기 때문에 대부분 Lisp이었습니다. 나중에 우리는 C로 작성된 이미지 생성기와 주로 Perl로 작성된 백오피스 관리자라는 두 개의 모듈을 더 추가했습니다.

2003년 1월, Yahoo는 C++와 Perl로 작성된 새로운 버전의 편집기를 출시했습니다. 하지만 이 프로그램을 C++로 번역하기 위해 말 그대로 Lisp 인터프리터를 작성해야 했기 때문에, 이 프로그램이 더 이상 Lisp으로 작성되지 않았다고 말하기는 어렵습니다. 제가 아는 한, 모든 페이지 생성 템플릿의 소스 파일은 여전히 Lisp 코드입니다. (그린스펀의 열 번째 법칙 참조.)

[2] 로버트 모리스는 제가 비밀스러울 필요가 없었다고 말합니다. 왜냐하면 경쟁사들이 우리가 Lisp을 사용하고 있다는 것을 알았더라도, 그들은 그 이유를 이해하지 못했을 것이기 때문입니다: "그들이 그렇게 똑똑했다면 이미 Lisp으로 프로그래밍하고 있었을 것입니다."

[3] 모든 언어는 튜링 동등하다는 의미에서 동등하게 강력하지만, 그것은 프로그래머들이 중요하게 생각하는 의미가 아닙니다. (아무도 튜링 기계를 프로그래밍하고 싶어 하지 않습니다.) 프로그래머들이 중요하게 생각하는 종류의 힘은 공식적으로 정의할 수 없을 수도 있지만, 그것을 설명하는 한 가지 방법은 덜 강력한 언어에서 더 강력한 언어용 인터프리터를 작성해야만 얻을 수 있는 기능을 의미한다고 말하는 것입니다. 언어 A에 문자열에서 공백을 제거하는 연산자가 있고 언어 B에는 없다면, 그것이 아마 A를 더 강력하게 만들지는 않을 것입니다. 왜냐하면 B에서 그것을 수행하는 서브루틴을 작성할 수 있을 것이기 때문입니다. 하지만 A가 예를 들어 재귀를 지원하고 B가 지원하지 않는다면, 그것은 라이브러리 함수를 작성하여 해결할 수 있는 문제가 아닐 가능성이 높습니다.

[4] 괴짜들을 위한 참고: 또는 상단으로 갈수록 좁아지는 격자일 수도 있습니다; 여기서 중요한 것은 모양이 아니라 적어도 부분 순서가 존재한다는 아이디어입니다.

[5] 매크로를 별도의 기능으로 취급하는 것은 다소 오해의 소지가 있습니다. 실제로는 렉시컬 클로저 및 가변 인자(rest parameters)와 같은 다른 Lisp 기능에 의해 그 유용성이 크게 향상됩니다.

[6] 결과적으로, 프로그래밍 언어에 대한 비교는 종교 전쟁의 형태를 띠거나, 너무나 단호하게 중립적이어서 실제로는 인류학 연구에 가까운 학부 교과서의 형태를 띠게 됩니다. 평화를 소중히 여기거나 종신 재직권을 원하는 사람들은 이 주제를 피합니다. 하지만 이 질문은 절반만 종교적인 것입니다; 특히 새로운 언어를 설계하고 싶다면 연구할 가치가 있는 무언가가 있습니다.