https://www.youtube.com/watch?v=kY7-T8OeJQE

## Great Hackers by Paul Graham (한글 번역)

[음악]

안녕하세요, IT Conversations에 오신 것을 환영합니다.

IT Conversations는 정보 기술의 핫 토픽에 대한 인터뷰, 녹음 및 대본 시리즈입니다.

저는 여러분의 호스트 Doug K입니다.

오늘 특별 프로그램에서는 2004년 7월 26일부터 30일까지 오리건주 포틀랜드에서 열린 O'Reilly 오픈 소스 컨벤션의 프레젠테이션을 여러분께 제공하게 되어 기쁩니다.

감사합니다.

음, 이 강연이 여러분에 대한 것이기를 바랍니다.

왜냐하면 이 강연의 제목은 그레이트 해커들이기 때문입니다.

사실 누군가에 대한 것이라면, 많은 분들에 대한 것일 겁니다.

몇 달 전에 새 책을 완성했는데, 리뷰에서 '도발적', '논란의 여지가 있는', '멍청한'과 같은 단어들을 계속 보게 되더군요.

책을 논란의 여지가 있게 만들려는 의도는 없었습니다.

효율적으로 만들려고 했죠.

이미 알고 있는 것을 말하며 사람들의 시간을 낭비하고 싶지 않았습니다.

차이점만 알려주는 것이 더 효율적이죠.

하지만 그러다 보니 사람들이 불안하게 생각하는 책이 된 것 같습니다.

어떤 아이디어가 가장 논란의 여지가 있는지에 대해서는 논란의 여지가 없습니다.

프랑스 문학 교수에 대한 것이 아닙니다.

그건 바로 부의 불균형이 우리가 생각하는 것만큼 나쁜 문제가 아닐 수도 있다는 생각입니다.

책에서 부의 불균형 자체가 좋은 것이라고 말하지 않았습니다.

어떤 경우에는 좋은 것의 징후일 수 있다고 말했습니다.

머리가 지끈거리는 것은 좋은 일이 아니지만, 좋은 일의 징후일 수 있습니다.

예를 들어 머리를 맞고 의식을 회복하고 있다는 징후일 수 있죠.

부의 불균형은 생산성의 불균형을 나타낼 수 있습니다.

1인 사회에서는 부의 불균형과 생산성의 불균형은 동일합니다.

그리고 그것은 확실히 좋은 일입니다.

왜냐하면 사회에 생산성의 불균형이 전혀 없다면 그것은 아마도 모든 사람이 토마스 에디슨이기 때문이 아니라 토마스 에디슨이 없기 때문일 것입니다.

저기술 사회에서는 생산성의 불균형이 그다지 크지 않습니다.

불을 피우기 위해 막대기를 모으는 유목민 부족이 있다면 가장 뛰어난 막대기 수집가가 가장 못하는 수집가보다 얼마나 더 생산적일까요? 두 배 정도겠죠.

반면 사람들에게 컴퓨터와 같은 복잡한 도구를 넘겨주면 사람마다 할 수 있는 일의 차이가 엄청나게 큽니다.

음, 이것은 새로운 아이디어가 아닙니다.

프레드 브룩스는 1974년에 이것에 대해 썼고 그가 인용한 연구는 1968년에 수행되었습니다.

하지만 그는 그 점을 충분히 강조하지 않았다고 생각합니다.

그는 코드 라인 수로 생산성에 대해 썼습니다.

최고의 프로그래머는 일반 프로그래머보다 10분의 1의 시간 안에 문제를 해결할 수 있습니다.

하지만 문제가 주어지지 않았다면 어떨까요? 상상력은 측정하기 어렵지만 실제로는 코드 라인 수로 측정되는 생산성을 압도합니다.

어떤 분야에서든 생산성은 다릅니다.

하지만 여러분 자신의 경험에서 알 수 있듯이 프로그래밍만큼 생산성의 차이가 큰 분야는 거의 없습니다.

프로그래밍에 내재된 것이라고 생각하지 않습니다.

기술이 모든 분야에서 생산성의 차이를 증폭시키고 프로그래밍 분야에서 우리는 단지 많은 기술적 레버리지를 가지고 있다고 생각합니다.

하지만 모든 분야에서 레버리지가 커지고 있기 때문에 프로그래밍에서 보이는 차이는 시간이 지남에 따라 점점 더 많은 분야에서 나타날 것입니다.

그리고 기업과 국가, 모든 종류의 조직의 성공은 점점 더 그들이 그것을 어떻게 다루는지에 달려 있을 것입니다.

기술에 따라 생산성의 차이가 커진다면 가장 생산적인 개인의 기여도는 실제로 시간이 지남에 따라 증가할 것입니다.

그룹 산출량의 90%가 구성원의 1%에 의해 생성되는 지점에 도달하면 바이킹의 습격이나 중앙 계획과 같은 것이 그들의 생산성을 평균 수준으로 끌어내리면 큰 손실을 입게 됩니다.

그들로부터 최대한 많은 것을 얻고 싶다면 이러한 특히 생산적인 사람들을 이해해야 합니다.

그들에게 동기를 부여하는 것은 무엇일까요? 그들은 자신의 일을 하기 위해 무엇이 필요할까요? 어떻게 그들을 알아볼 수 있을까요? 어떻게 그들이 당신을 위해 일하게 만들 수 있을까요? 그리고 물론 어떻게 그들 중 하나가 될 수 있을까요? 라는 질문도 있습니다.

저는 몇 명의 슈퍼 해커를 알고 있기 때문에 앉아서 그들이 무엇을 공통적으로 가지고 있는지 생각해 보았습니다.

그들을 정의하는 특징은 아마도 그들이 정말 프로그래밍을 좋아한다는 것입니다.

일반 프로그래머는 돈을 벌기 위해 코드를 작성합니다.

그레이트 해커는 프로그래밍을 재미있는 일로 생각하고 사람들이 돈을 지불해준다는 사실에 기뻐합니다.

훌륭한 프로그래머는 때때로 돈에 무관심하다고 합니다.

음, 이것은 완전히 사실은 아닙니다.

그들이 정말로 관심 있는 것은 흥미로운 일을 하는 것이지만, 돈을 충분히 벌면 원하는 일을 할 수 있기 때문에 훌륭한 프로그래머는 정말 많은 돈을 버는 데 관심이 있습니다.

그러나 매일 출근해야 하는 한 그들은 아마도 받는 돈보다 하는 일에 더 신경 쓸 것입니다.

경제적으로 이것은 매우 중요한 사실입니다.

왜냐하면 그레이트 해커에게 그들의 가치만큼 돈을 지불할 필요가 없다는 것을 의미하기 때문입니다.

훌륭한 프로그래머는 일반 프로그래머보다 10배 또는 100배 더 생산적일 수 있지만, 3배 더 많은 돈을 받으면 운이 좋다고 생각할 것입니다.

나중에 설명하겠지만, 이는 부분적으로 그레이트 해커가 자신이 얼마나 뛰어난지 모르기 때문이기도 하지만, 돈이 그들이 원하는 유일한 것이 아니기 때문이기도 합니다.

그렇다면 해커는 무엇을 원할까요? 모든 장인과 마찬가지로 해커는 좋은 도구를 좋아합니다.

사실 그것은 엄청난 절제된 표현입니다.

그레이트 해커는 잘못된 도구를 사용하는 것을 참을 수 없어 합니다.

잘못된 인프라를 사용하면 프로젝트에서 일하기를 거부할 것입니다.

제가 한때 일했던 스타트업에서는 게시판에 IBM 광고를 붙여 놓았습니다.

그것은 AS/400의 사진이었는데, 제 생각에는 일종의 컴퓨터였습니다.

그리고 그 위에 해커들은 그것을 경멸한다는 말이 쓰여 있었습니다.

프로젝트에 사용할 인프라를 결정할 때 기술적인 결정만 내리는 것이 아닙니다.

사회적인 결정도 내리는 것이죠.

그리고 이것이 둘 중 더 중요할 수 있습니다.

예를 들어 회사에서 소프트웨어를 작성하려는 경우 Java로 작성하는 것이 현명한 결정처럼 보일 수 있습니다.

하지만 Java로 프로그램을 작성하면 Python으로 작성하는 경우보다 똑똑한 사람을 고용할 수 없습니다. (청중 폭소)

그리고 해커의 자질은 아마도 선택하는 언어보다 프로젝트의 성공에 더 중요할 것입니다.

해커들이 자바보다 파이썬을 선호한다는 사실은 이 두 언어의 상대적 장단점에 대해 무언가를 말해줍니다. 모든 책이 세제 상자처럼 생긴 언어를 누가 쓰고 싶어 하겠습니까?

비즈니스 유형들은 가장 인기 있는 언어를 선호합니다. 그들은 언어를 표준으로 보기 때문입니다. 그들은 회사의 운명을 베타맥스에 걸고 싶어 하지 않습니다. 하지만 언어에 대해 중요한 점은 그것들이 단순한 표준이 아니라는 것입니다. 네트워크를 통해 비트를 옮기고 싶다면 물론 TCP/IP를 사용하세요. 하지만 언어는 단순한 형식이 아닙니다.

프로그래밍 언어는 표현의 매체입니다. 자바가 방금 코볼을 제치고 가장 인기 있는 언어가 되었다고 들었습니다. 표준으로서는 더 바랄 게 없겠지만, 표현의 매체로서는 훨씬 더 많은 것을 원할 수 있습니다.

제가 아는 모든 훌륭한 프로그래머 중에서 자발적으로 Java로 프로그래밍할 사람은 한 명뿐입니다.

제가 아는 모든 훌륭한 프로그래머 중에서 Sun에서 Java로 작업하는 그레이트 해커는 없습니다.

그레이트 해커는 일반적으로 오픈 소스 소프트웨어로 작업하기를 고집합니다.

단지 오픈 소스 소프트웨어가 더 좋기 때문만이 아니라 더 많은 제어권을 제공하기 때문입니다.

좋은 해커는 제어권을 요구하며, 이것이 그들을 좋은 해커로 만드는 부분입니다.

무언가 잘못되면 고쳐야 합니다.

당신이 그들이 당신을 위해 작성하는 소프트웨어에 대해 이런 식으로 느끼기를 원한다면, 그들이 실행 중인 운영 체제에 대해서도 똑같이 느끼는 것에 놀라서는 안 됩니다.

몇 년 전에 제 벤처 투자자 친구가 자신이 참여하고 있는 새로운 스타트업에 대해 말해주었습니다.

유망해 보였지만 다음에 그와 이야기를 나눴을 때 그는 Windows NT를 기반으로 구축하기로 결정했고 저명한 Windows NT 개발자를 최고 기술 책임자로 고용했다고 말했습니다.

저는 '이 친구들은 망했군'이라고 생각했습니다.

첫째, 이 사람이 저명한 Windows NT 개발자가 되려면 자발적으로 여러 번 Windows NT를 사용했어야 했을 텐데, 그레이트 해커가 그렇게 하는 것을 상상할 수 없었습니다.

둘째, 그가 뛰어난 개발자라고 해도 프로젝트를 NT에서 구축해야 한다면 그들을 위해 일할 훌륭한 사람을 고용하기가 어려울 것입니다.

실제로 그들은 망했습니다.

몇 달 후에 문을 닫았습니다.

소프트웨어 다음으로 해커에게 가장 중요한 도구는 사무실입니다.

대기업에서 사무실의 기능은 자신의 직급을 나타내는 것입니다.

하지만 해커는 사무실을 그 이상으로 사용합니다.

해커는 사무실을 생각하는 장소로 사용합니다.

그리고 기술 회사라면 그들의 생각이 당신의 제품입니다.

따라서 해커가 시끄럽고 산만한 환경에서 일하게 하는 것은 공기 중에 먼지와 모래가 가득한 페인트 공장을 운영하는 것과 같습니다.

만화 딜버트는 칸막이 사무실에 대해 할 말이 많습니다.

그리고 그럴 만한 이유가 있습니다.

제가 아는 모든 해커는 칸막이 사무실을 경멸합니다.

방해를 받을 수도 있다는 생각만으로도 해커는 어려운 프로젝트를 시작하지 못할 수 있습니다.

칸막이 사무실에서 진짜 일을 하고 싶다면 두 가지 선택 사항이 있습니다.

집에서 일하거나 아무도 없는 이른 아침이나 늦은 저녁, 또는 주말에 출근하는 것입니다.

이게 익숙하지 않은가요? 회사는 이것이 무언가 잘못되었다는 신호라는 것을 깨닫지 못할까요? 사무실 환경은 일하는 곳이지, 일하기 싫은 곳이 아닙니다.

시스코와 같은 회사는 CEO조차 칸막이 사무실을 사용한다는 사실을 자랑스럽게 생각합니다.

하지만 그들이 생각하는 것만큼 진보적이지 않습니다.

분명히 그들은 여전히 사무실을 직급의 표현으로 보고 있습니다.

시스코가 사내에서 제품 개발을 거의 하지 않는 것으로 유명하다는 점도 주목하세요.

그들은 새로운 기술을 만든 스타트업을 인수하여 새로운 기술을 얻습니다.

아마도 그곳에서 해커들은 조용히 일할 곳이 있었을 것입니다.

해커에게 무엇이 필요한지 아는 대기업 중 하나는 마이크로소프트입니다.

한때 문 사진이 크게 실린 마이크로소프트 채용 공고를 본 적이 있습니다.

마이크로소프트에서 일하세요.

전제는 '실제로 일할 수 있는 곳을 제공하겠습니다'였습니다.

그리고 아시다시피 마이크로소프트는 대기업 중에서도 사내에서 소프트웨어를 실제로 개발할 수 있다는 점에서 주목할 만합니다.

잘하지는 못하지만 충분히 잘합니다.

회사에서 해커가 생산성을 높이기를 원한다면 집에서 무엇을 하는지 살펴봐야 합니다.

집에서 해커는 스스로 일을 정리하여 최대한 많은 일을 할 수 있습니다.

그리고 집에서 일할 때 해커는 시끄러운 열린 공간에서 일하지 않습니다.

문이 닫힌 방에서 일합니다.

주변에 사람들이 있고 생각할 때 산책할 수 있는 아늑한 동네에서 일합니다.

주차장 한가운데 있는 유리 상자에서 일하지 않습니다.

책상에 앉아 혼수상태에 빠진 척하며 일하는 대신 피곤하면 낮잠을 잘 수 있는 소파가 있습니다.

매일 황금 시간대에 사무실을 돌아다니며 시끄럽게 청소하는 청소부들이 없습니다.

회의나, 세상에, 기업 워크숍이나 팀워크 훈련도 없습니다.

그리고 그들이 컴퓨터에서 무엇을 하는지 살펴보면 도구에 대해 앞서 말한 내용이 강화된다는 것을 알게 될 것입니다.

직장에서는 Java와 Windows를 사용해야 할 수도 있지만, 스스로 선택할 수 있는 집에서는 Perl과 Linux를 사용하는 경우가 더 많습니다.

실제로 Cobol이나 Java가 가장 인기 있는 언어라는 통계는 오해의 소지가 있습니다.

최상의 도구가 무엇인지 알고 싶다면 해커가 자유롭게 선택할 수 있을 때 무엇을 선택하는지 살펴봐야 합니다.

그 질문을 해보면 오픈 소스 운영 체제가 이미 시장 점유율을 장악하고 있으며 가장 인기 있는 언어는 아마도 Perl일 것입니다.

좋은 도구와 함께 해커가 원하는 것은 흥미로운 프로젝트입니다.

무엇이 프로젝트를 흥미롭게 만들까요? 음, 분명히 스텔스기나 특수 효과 소프트웨어와 같은 노골적으로 섹시한 애플리케이션은 작업하기에 흥미로울 것입니다.

하지만 새로운 기술적 과제를 제기한다면 어떤 애플리케이션이든 흥미로울 수 있습니다.

따라서 해커가 어떤 문제를 좋아할지 예측하기는 어렵습니다.

왜냐하면 어떤 문제는 그것을 연구하는 사람들이 새로운 종류의 솔루션을 발견했을 때만 흥미로워지기 때문입니다.

Orbitz 내부 소프트웨어를 작성한 ITA 이전에는 항공료 검색을 연구하는 사람들은 아마도 그것이 데이터 처리처럼 상상할 수 있는 가장 지루한 애플리케이션 중 하나라고 생각했을 것입니다.

50년대의 데이터 처리를 기억하시나요? 그 당시에는 그렇게 불렀습니다.

몇 번 이름이 바뀌었죠.

음, 하지만 ITA는 문제를 더 야심 차게 재정의함으로써 문제를 흥미롭게 만들었습니다.

Google이 설립되었을 때도 비슷한 일이 일어났다고 생각합니다.

소위 포털 사이의 일반적인 통념은 검색이 지루하고 중요하지 않다는 것이었습니다.

하지만 Google의 사람들은 그렇게 생각하지 않았고, 그래서 그들이 검색을 그렇게 잘하는 것입니다.

이것은 관리자가 차이를 만들 수 있는 영역입니다.

부모가 아이에게 "내기할래? 10분 안에 방을 다 치울 수 없을걸?"이라고 말하는 것처럼 좋은 관리자는 때때로 문제를 더 흥미로운 문제로 재정의할 수 있습니다.

스티브 잡스는 특히 이 부분에 뛰어난 것 같습니다.

단순히 높은 기준을 가지고 있기 때문입니다.

Mac 이전에는 작고 저렴한 컴퓨터가 많았습니다.

그는 문제를 '아름다운 컴퓨터를 만드는 것'으로 재정의했고, 그것은 아마도 어떤 채찍보다 개발자들을 더 열심히 일하게 만들었을 것입니다.

그들은 확실히 해냈습니다.

Mac이 처음 등장했을 때, Mac이 처음 등장했을 때를 기억하는 사람이 몇 명이나 될까요? 세상에, 제 인생이 바뀌었습니다.

Mac이 처음 등장했을 때는 켜보지 않아도 좋다는 것을 알 수 있었습니다.

케이스만 봐도 알 수 있었죠.

몇 주 전에 케임브리지 거리를 걷고 있었습니다.

예전에는 경제적인 필요였던 것이 이제는 취미가 되었습니다.

케임브리지 거리를 걷다가 누군가의 쓰레기통에서 Mac 휴대용 케이스처럼 보이는 것을 보았습니다.

열어보니 Mac SE가 있었습니다.

집에 가져가서 전원을 연결했더니 부팅이 되었습니다.

그리고 Finder와 웃는 얼굴, 웃는 Macintosh 얼굴과 Finder가 있었습니다.

아시다시피 너무 간단했습니다.

Google과 같았습니다.

해커는 기준이 높은 사람을 위해 일하기를 좋아하지만, 엄격하기만 해서는 충분하지 않습니다.

옳은 것을 요구해야 합니다.

그것은 보통 당신 자신도 해커여야 한다는 것을 의미합니다.

프로그래머를 관리하는 방법에 대한 기사를 가끔 봤습니다.

사실 두 개의 기사가 있어야 합니다.

하나는 자신이 프로그래머인 경우 어떻게 해야 하는지에 대한 것이고, 다른 하나는 프로그래머가 아닌 경우 어떻게 해야 하는지에 대한 것입니다.

후자는 아마도 네 단어로 요약할 수 있지만, 두 단어 버전을 알려드리겠습니다.

포기하세요.

혹시 청중 중에 아이들이 있을까 봐서요.

문제는 일상적인 관리가 아닙니다.

정말 그레이트 해커는 사실상 자기 관리를 합니다.

문제는 해커가 아니라면 누가 좋은 해커인지 알 수 없다는 것입니다.

비슷한 문제가 미국 자동차가 왜 그렇게 못생겼는지 설명해줍니다.

저는 이것을 디자인 역설이라고 부릅니다.

훌륭한 디자이너를 고용하기만 하면 아름다운 제품을 만들 수 있다고 생각할 수도 있습니다.

문제는 자신에게 좋은 취향이 없다면 어떻게 좋은 디자이너를 알아볼 수 있을까요? 정의상 알 수 없습니다.

포트폴리오를 보고 알 수 없고, 그들이 했던 일이나 받았던 상을 보고도 알 수 없습니다.

왜냐하면 디자인을 포함한 대부분의 분야에서 이러한 것들은 유행과 아첨에 좌우되는 경향이 있고, 실제 능력은 훨씬 뒤처져 있기 때문입니다.

피할 수 없습니다.

아름다운 것을 만들어내기 위한 프로세스를 관리하려면 아름다움이 무엇인지 알아야 합니다.

미국 자동차가 못생긴 이유는 미국 자동차 회사가 취향이 나쁜 사람들이 운영하기 때문입니다.

덧붙이자면, 여기 오는 길에 택시를 탔는데 Pontiac Aztec 뒤에 있었습니다.

너무 못생겨서 Edsel 이후로 취소된 유일한 자동차입니다.

미국인들이 사지 않았기 때문입니다.

저는 '세상에, 저것 좀 봐'라고 생각했습니다.

그리고 아래쪽을 내려다봤는데 부시/체니 범퍼 스티커가 붙어 있는 것을 발견했습니다.

[박수] 저는 정치적으로 엄격하게 중립입니다.

이 나라의 많은 사람들은 취향을 파악하기 어렵거나 심지어 경 frivol거운 것으로 생각합니다.

음, 둘 다 아닙니다.

이만큼 간단합니다.

디자인을 주도하려면 관리자가 회사 자체 제품의 가장 까다로운 사용자여야 합니다.

그리고 스티브 잡스처럼 정말 좋은 취향을 가지고 있다면 똑똑한 사람들이 기꺼이 해결하고 싶어 하는 종류의 문제를 만들어낼 수 있습니다.

음, 어떤 종류의 문제가 작업하기에 흥미롭지 않은지 말하기는 매우 쉽습니다.

몇 가지 크고 명확한 문제를 해결하는 대신 많은 성가신 작은 문제를 해결해야 하는 문제입니다.

버그가 많은 소프트웨어에 대한 인터페이스를 작성하는 것이 최악의 프로젝트 중 하나입니다.

또 다른 하나는 개별 고객의 무작위적이고 불특정한 요구 사항에 맞게 무언가를 사용자 지정해야 할 때입니다.

해커에게 이러한 종류의 프로젝트는 천 개의 상처로 인한 죽음과 같습니다.

성가신 작은 문제의 특징은 그것들로부터 아무것도 배우지 못한다는 것입니다.

컴파일러를 작성하는 것은 컴파일러가 무엇인지 알려주기 때문에 흥미롭습니다.

하지만 버그가 많은 소프트웨어에 대한 인터페이스를 작성하는 것은 아무것도 가르쳐주지 않습니다.

왜냐하면 버그는 무작위적이고 패턴이 없기 때문입니다.

좋은 프로그래머가 성가신 작은 문제를 피하는 것은 단순히 까다로워서가 아닙니다.

자기 보존의 문제입니다.

성가신 작은 문제를 연구하면 바보가 됩니다.

좋은 해커는 모델이 치즈버거를 피하는 것과 같은 이유로 성가신 작은 문제를 피합니다.

물론 어떤 문제는 본질적으로 이러한 특징을 가지고 있고, 수요와 공급 때문에 특히 많은 돈을 지불합니다.

따라서 정말 똑똑한 사람들이 정말 지루한 문제를 연구하게 만들 수 있는 회사는 매우 성공할 것입니다.

음, 어떻게 하면 그렇게 될 수 있을까요? 이런 일이 일어나는 곳 중 하나는 스타트업입니다.

스타트업이 뛰어난 이유 중 하나입니다.

우리 스타트업에서는 Robert Morris가 시스템 관리자로 일했습니다.

그것은 마치 바르 미츠바에서 롤링 스톤스가 연주하는 것과 같습니다.

덧붙이자면, 우리는 그에게 보안도 맡겼습니다.

사람들, 상인들은 "서버에 신용 카드를 저장해도 안전할까요?"라고 물었습니다.

"걱정하지 마세요.

전문가가 담당하고 있습니다.

그는 그 분야에 대해 모든 것을 알고 있습니다." 젠장, 어디였더라? 네, 사람들은 자신이 설립한 회사에서라면 어떤 지루한 일이든 할 것입니다.

더 큰 회사는 회사를 분할하여 문제를 해결합니다.

직원이 고객의 성가신 작은 문제를 직접 처리할 필요가 없는 별도의 R&D 부서를 설립하여 똑똑한 사람들을 고용합니다.

이 모델에서 연구 부서는 광산과 같은 기능을 합니다.

새로운 아이디어를 생산하죠.

어쩌면 회사의 나머지 부서에서 그 아이디어를 활용할 수 있을 것입니다.

이렇게 극단적으로 할 필요는 없습니다.

상향식 프로그래밍은 회사를 분할하는 또 다른 방법을 제시합니다.

똑똑한 사람들이 도구 제작자로 일하게 하세요.

회사에서 X를 수행하는 소프트웨어를 작성해야 하는 경우 한 그룹은 해당 유형의 애플리케이션을 구축하기 위한 도구를 작성하고 다른 그룹은 해당 도구를 사용하여 실제 애플리케이션을 구축하게 하세요.

이렇게 하면 똑똑한 사람들이 소프트웨어의 99%를 작성하게 하면서도 기존의 R&D 부서에서처럼 실제 사용자로부터 보호할 수 있습니다.

사용자가 있겠지만 회사 자체 개발자뿐입니다.

예를 들어 마이크로소프트에서 이러한 접근 방식을 사용했다면 소프트웨어에 보안 취약점이 그렇게 많지 않았을 것입니다.

왜냐하면 실제 애플리케이션을 작성하는 덜 똑똑한 사람들이 메모리 할당과 같은 저수준 작업을 수행하지 않을 것이기 때문입니다.

C로 직접 작성하는 대신 Word 언어 Duplo의 큰 블록을 연결할 것입니다.

제 생각에는 그게 기술적인 용어입니다.

흥미로운 문제와 함께 좋은 해커가 좋아하는 것은 다른 좋은 해커입니다.

그레이트 해커는 함께 모이는 경향이 있습니다.

때로는 Xerox PARC처럼 엄청나게 모이기도 합니다.

즉, 해커를 위해 만드는 환경이 얼마나 좋은지에 비례하여 좋은 해커를 유치할 수 없다는 것을 의미합니다.

모이는 경향이 있다는 것은 제곱에 가깝다는 것을 의미합니다.

따라서 승자 독식입니다.

어느 시점에서든 해커가 정말로 일하고 싶어 하는 곳은 약 10~20곳뿐입니다.

그리고 그중 하나가 아니라면 더 적은 수의 해커, 더 적은 수의 그레이트 해커를 얻는 것이 아니라 아무도 얻지 못할 것입니다.

그레이트 해커를 보유하는 것만으로는 회사를 성공시키기에 충분하지 않습니다.

현재 가장 인기 있는 곳 중 두 곳인 Google과 ITA에서는 효과가 있지만, Thinking Machines나 Xerox에는 도움이 되지 않았습니다.

Sun은 한동안 잘 나갔지만 비즈니스 모델은 내리막길입니다.

그리고 그런 상황에서는 최고의 해커조차도 당신을 구할 수 없습니다.

다른 모든 조건이 동일하다면 그레이트 해커를 유치할 수 있는 회사는 엄청난 이점을 누릴 것이라고 생각합니다.

하지만 이에 동의하지 않는 사람들도 있습니다.

1990년대에 벤처 캐피털 회사를 돌아다니는 동안 그중 몇몇은 소프트웨어 회사가 훌륭한 소프트웨어를 작성해서가 아니라 브랜드와 유통 채널을 장악하고 올바른 거래를 함으로써 성공한다고 말했습니다.

그들은 정말로 그렇게 믿는 것 같았고, 그 이유를 알 것 같습니다.

제 생각에는 많은 VC가 적어도 무의식적으로 찾고 있는 것은 다음 마이크로소프트입니다.

그리고 마이크로소프트가 당신의 모델이라면 훌륭한 소프트웨어를 작성하여 성공하기를 바라는 회사를 찾아서는 안 됩니다.

하지만 더 안 좋은 점이 있습니다.

음, 하지만 VC가 다음 마이크로소프트를 찾는 것은 잘못된 것입니다.

왜냐하면 다른 회사가 적절한 시기에 굴복하여 다음 IBM이 되어주지 않는 한 어떤 스타트업도 다음 마이크로소프트가 될 수 없기 때문입니다.

마이크로소프트가 IBM을 혼냈다는 뜻입니다.

마이크로소프트를 모델로 사용하는 것은 잘못된 것입니다.

왜냐하면 그들의 문화 전체가 그 한 번의 행운에서 비롯되었기 때문입니다.

마이크로소프트는 나쁜 데이터 포인트입니다.

마이크로소프트를 제외하면 좋은 제품이 시장에서 이기는 경향이 있다는 것을 알 수 있습니다.

VC가 찾아야 하는 것은 다음 Apple이나 다음 Google입니다.

빌 게이츠도 이것을 알고 있다고 생각합니다.

그가 Google에 대해 걱정하는 것은 브랜드의 힘이 아니라 Google에 더 똑똑한 해커들이 일하고 있다는 사실입니다.

그렇다면 그레이트 해커는 누구일까요? 어떻게 알 수 있을까요? 음, 그것은 매우 어려운 것으로 밝혀졌습니다.

저는 이제 제 친구 Trevor Blackwell이 그레이트 해커라는 것을 확신합니다.

여러분 중 일부는 Slashdot에서 그가 어떻게 자신의 Segway를 만들었는지에 대한 글을 읽었을 것입니다.

이 프로젝트의 놀라운 점은 그가 모든 소프트웨어를 하루 만에 Python으로 작성했다는 것입니다.

덧붙이자면, 그에게는 일상적인 일입니다.

하지만 처음 만났을 때는 그가 완전히 바보라고 생각했습니다.

그는 Robert Morris의 사무실에 서서 뭔가에 대해 횡설수설하고 있었습니다.

저는 Robert 뒤에 서서 그 미친놈을 사무실에서 내쫓아서 점심을 먹으러 갈 수 있도록 필사적으로 손짓했던 기억이 납니다.

Robert도 처음에는 그를 오해했습니다.

분명히 그가 처음 Trevor를 만났을 때 Trevor는 자신의 삶의 모든 면에 대한 모든 것을 카드 뭉치에 적어서 항상 가지고 다니는 새로운 방식을 채택했습니다.

그는 방금 캐나다에서 왔고 강한 캐나다 억양과 멀릿 헤어스타일을 하고 있었습니다.

문제는 해커가 사회적으로 둔감하다는 평판에도 불구하고 때로는 똑똑해 보이려고 많은 노력을 기울인다는 사실 때문에 더욱 악화됩니다.

대학원 시절에 저는 가끔 MIT AI 연구소에 들렀습니다.

처음에는 꽤 위협적이었습니다.

이 사람들은 모두 말이 너무 빨랐습니다.

하지만 얼마 후 저는 빨리 말하는 요령을 터득했습니다.

더 빨리 생각할 필요는 없습니다.

모든 것을 말할 때 단어를 두 배로 사용하면 됩니다.

이렇게 많은 노이즈가 있는 신호에서는 좋은 해커를 만났을 때 알아보기가 어렵습니다.

저도 지금도 알 수 없습니다.

이력서를 보고도 알 수 없습니다.

해커를 판단하는 유일한 방법은 함께 일해 보는 것 같습니다.

그리고 이것이 첨단 기술 분야가 대학 주변에서 시작되는 경향이 있는 이유입니다.

여기서 중요한 것은 교수가 아니라 학생들입니다.

대학은 지적인 만남의 장소와 같습니다.

유망한 젊은이들을 모아서 함께 프로젝트를 수행하게 한 다음, 해커, 좋은 해커는 함께 일해 보지 않으면 알 수 없기 때문에 그들은 스스로 새로운 프로젝트를 시작합니다.

해커 자신도 자신이 얼마나 뛰어난지 알 수 없습니다.

대부분의 분야에서 어느 정도는 사실입니다.

무언가에 뛰어난 사람들은 자신의 위대함을 확신한다기보다는 왜 다른 모든 사람들이 그렇게 무능해 보이는지 의아해하는 경우가 많다는 것을 알게 되었습니다.

하지만 해커가 자신이 얼마나 뛰어난지 아는 것은 특히 어렵습니다.

왜냐하면 그들의 작업을 비교하기가 어렵기 때문입니다.

100미터 달리기에서는 10초 만에 누가 가장 빠른지 알 수 있습니다.

수학에서도 어떤 문제가 해결하기 어려운지, 무엇이 좋은 솔루션인지에 대한 일반적인 합의가 있는 것 같습니다.

하지만 해킹은 글쓰기와 더 비슷합니다.

두 소설 중 어느 것이 더 나은지 누가 알 수 있을까요? 확실히 작가는 알 수 없습니다.

해커의 경우에는 적어도 다른 해커가 알 수 있습니다.

왜냐하면 소설가와 달리 해커는 프로젝트에서 협업하기 때문입니다.

인터넷에서 누군가와 함께 몇 가지 어려운 문제를 해결하다 보면 그들이 얼마나 뛰어난지 금방 알 수 있습니다.

하지만 해커는 자신이 일하는 모습을 볼 수 없습니다.

따라서 그레이트 해커에게 자신이 얼마나 뛰어난지 물어보면 거의 틀림없이 "모르겠어요"라고 대답할 것입니다.

그냥 겸손한 척하는 것이 아닙니다.

정말 모르는 것입니다.

그리고 우리도 함께 일해 본 사람 외에는 아무도 모릅니다.

그래서 우리는 이상한 상황에 처하게 됩니다.

우리의 영웅이 누구여야 하는지 모릅니다.

해커는 홍보상의 우연한 사고로 유명해지는 경향이 있습니다.

가끔 그레이트 해커의 예를 들어야 할 때가 있는데 누구를 말해야 할지 모르겠습니다.

먼저 떠오르는 이름은 항상 제가 개인적으로 아는 사람들입니다.

하지만 그들을 예로 드는 것은 좀 그렇습니다.

그래서 Richard Stallman이나 Alan Kay와 같은 유명한 사람을 말해야 할까 생각해 봅니다.

하지만 이 사람들이 그레이트 해커인지 모르겠습니다.

그들과 함께 일해 본 적이 없기 때문입니다.

따라서 해킹 분야의 마이클 조던이 있다면 아무도, 그 사람 자신도 모릅니다.

마지막으로 질문입니다.

죄송합니다.

뭐라고요? 마지막으로 해커들이 모두 궁금해하는 질문입니다.

어떻게 하면 그레이트 해커가 될 수 있을까요? 음, 스스로 그레이트 해커가 될 수 있는지는 모르겠지만, 스스로를 바보로 만드는 일은 확실히 할 수 있습니다.

그리고 스스로를 바보로 만들 수 있다면 아마도 스스로도 만들 수 있을 것입니다.

좋은 해커가 되는 비결은 아마도 좋아하는 일을 하는 것일 겁니다.

제가 아는 그레이트 해커들을 생각해 보면 한 가지 눈에 띄는 점은 그들이 원하지 않는 일을 하도록 만드는 것이 극도로 어렵다는 것입니다.

이것이 원인인지 결과인지 모르겠습니다.

둘 다일 수도 있습니다.

무언가를 잘하려면 그것을 좋아해야 합니다.

따라서 해킹을 좋아하는 일로 유지할 수 있는 한 해킹을 잘할 가능성이 높습니다.

14살 때 프로그래밍에 대해 가졌던 감정을 유지하려고 노력하세요.

현재 하고 있는 일이 뇌를 썩게 한다고 걱정된다면 아마도 그럴 것입니다.

최고의 해커는 물론 똑똑한 경향이 있지만, 다른 많은 분야도 마찬가지입니다.

해커에게만 있는 특별한 자질이 있을까요? 친구들에게 물어봤더니 그들이 가장 많이 언급한 것은 무엇이라고 생각하시나요? 그들이 가장 많이 언급한 것은 호기심입니다.

저는 항상 똑똑한 사람들은 모두 호기심이 많다고 생각했습니다.

그것은 단지 지식의 1차 도함수일 뿐입니다.

음, 하지만 분명히 해커는 특히 사물이 어떻게 작동하는지에 대해 호기심이 많습니다.

프로그램은 사실상 사물이 어떻게 작동하는지에 대한 거대한 설명이기 때문에 이해가 됩니다.

몇몇 친구들은 해커의 집중력을 언급했습니다.

항상 칭찬하는 것은 아니었습니다.

한 친구는 해커의 능력을 '머리 밖의 모든 것을 차단하는 능력'이라고 표현했습니다.

저도 확실히 그런 점을 느꼈고, 몇몇 해커들이 맥주 반 잔만 마셔도 프로그래밍을 전혀 할 수 없다고 말하는 것을 들었습니다.

따라서 해킹에는 집중력이라는 특별한 능력이 필요한 것 같습니다.

아마도 그레이트 해커는 머릿속에 많은 양의 맥락을 불러올 수 있기 때문에 프로그램의 한 줄을 볼 때 그 줄만 보는 것이 아니라 주변의 전체 프로그램을 보는 것일 수도 있습니다.

John McPhee는 농구 선수로서 Bill Bradley의 성공은 부분적으로 그의 경이로운 주변 시력 덕분이라고 썼습니다.

완벽한 시력은 약 47도의 수직 주변 시력을 의미합니다.

Bill Bradley는 70도였습니다.

그는 바닥을 내려다볼 때도 바구니를 볼 수 있었습니다.

아마도 그레이트 해커도 비슷한 선천적인 능력을 가지고 있을 것입니다.

저는 매우 밀도가 높은 언어를 사용하여 속임수를 씁니다.

이것은 칸막이 사무실에 대한 의견 차이를 설명할 수 있습니다.

어쩌면 깨뜨릴 집중력이 없는 시설 담당자들은 칸막이 사무실에서 일하는 것이 해커에게는 믹서기에 뇌를 넣는 것처럼 느껴진다는 것을 깨닫지 못하는 것일 수도 있습니다.

반면 빌은 자폐증에 대한 소문이 사실이라면 그 고통을 너무나 잘 알고 있을 것입니다.

제가 그레이트 해커와 일반적으로 똑똑한 사람들 사이에서 발견한 한 가지 차이점은 그레이트 해커가 정치적으로 덜 올바르다는 것입니다.

좋은 해커들 사이에 비밀 악수가 있다면 그것은 서로를 잘 알고, 대중에게 돌로 맞아 죽을 만한 의견을 표현할 만큼 서로를 잘 알 때입니다.

그리고 왜 정치적 불 correctness가 프로그래밍에서 유용한 자질이 될 수 있는지 알 수 있습니다.

프로그램은 매우 복잡하고, 적어도 좋은 프로그래머의 손에 들어가면 매우 유동적입니다.

그런 상황에서는 가정에 의문을 제기하는 습관이 도움이 됩니다.

이러한 자질을 기를 수 있을까요? 모르겠습니다.

하지만 적어도 억누르지는 마세요.

그래서 여기 제가 생각해 낸 최선의 방법이 있습니다.

스스로 그레이트 해커가 될 수 있다면 그렇게 하는 방법은 자신과 다음과 같은 거래를 하는 것일 수 있습니다.

가족이 굶어 죽지 않는 한, 물론 그렇지 않다면, 지루하다고 생각하는 일에는 절대 일할 필요가 없습니다.

음, 그리고 그 대가로 절대 어설픈 일은 하지 않을 것입니다.

제가 아는 모든 그레이트 해커들은 이 거래를 한 것 같습니다.

비록 그들 중 누구도 선택의 여지가 없었을 수도 있지만요.

감사합니다.

[박수] [음악] [박수] 이 특별판 IT Conversations를 들어주셔서 감사합니다.

이 에피소드는 2004년 7월 26일부터 30일까지 오리건주 포틀랜드에서 열린 O'Reilly 오픈 소스 컨벤션에서 녹음되었습니다.

이 컨퍼런스 및 향후 O'Reilly 컨퍼런스에 대한 자세한 내용은 conferences.oreilly.net을 방문하세요.

이 프로그램은 발표자, O'Reilly Media 및 RDS Strategies LLC의 저작권입니다.

저는 Doug K이고 다음 IT Conversations 에피소드에서 다시 만나 뵙기를 바랍니다.

[음악]
