Teach Yourself Programming in Ten Years 원문 클릭
10년 동안 스스로에게 프로그래밍을 가르쳐라
피터 노빅
번역 채규병
왜 모두가 그렇게나 서두르는가?
어느 서점에나 들어가보면 당신은 '혼자서 하루만에 자바(Java) 마스터하기' 와 비슷하고 수많은 책을 볼 수 있을 것이다. 그리고 자바 뿐만이 아닌 C, SQL, Ruby, Algorithms 등 다른 프로그래밍 언어를 몇 시간 혹은 며칠만에 마스터하기와 같은 책을 볼 수 있을 것이다. 아마존에서 [제목: 마스터하기, 혼자서, 몇 시간, 2000년 이후 발행]으로 검색해보면 512권의 책을 찾을 수 있다. 그리고 그 책들 중 최고 판매량 10위를 살펴보면 아홉 권의 책이 프로그래밍 책이다(다른 하나는 회계부기에 관한 것이다). "혼자 공부하기"를 "배우기" 혹은 "몇 시간, 며칠"으로 바꿔도 비슷한 결과가 나온다.
이러한 결과는 사람들이 프로그래밍을 배우는 데에 굉장히 서두른다는 것과 프로그래밍이 다른 것에 비해서 어느 정도는 굉장히 배우기 쉽다는 것을 뜻한다. Felleisen et al 는 이러한 트랜드에 대해서 "나쁜 프로그래밍은 쉽다. 멍청이도 3주 안에 배울 수 있다. 비록 그것이 빈껍데기일지라도 말이다."라고 그들의 책 '어떻게 프로그램을 디자인하는가'에 써놓았다. The Abruse Goose는 이것에 관해 만화까지 그렸다.
자, 이제 '하루만에 C++ 혼자 마스터하기'가 의미하는 것에 대해 분석해보자:
- 혼자서 마스터하기: 하루만에 당신은 중요한 프로그램들을 직접 쳐볼 수도 없을 뿐더러, 시행착오를 통해 프로그램들을 배울 수도 없을 것이다. 당신은 경험있는 프로그래머랑 일 해볼 수 없을 거고, C++ 환경에서 사는 것이 어떤 건지도 이해할 수 없을 것이다. 짧게 말해, 당신은 하루만에 많은 것을 배울 수 없을 거다. 그러니 이러한 종류의 책들은 깊은 이해가 아닌 단순히 피상적인 친숙함에 대해서만 이야기할 수 있다. 알렉산더 포프가 말했듯이, 짧은 배움은 위험한 것이다.
- C++: 하루만에 C++의 문법을 어느 정도 배우는 게 가능할 수도 있다 (만약 다른 컴퓨터 언어를 이미 알고 있다면 말이다). 하지만 당신은 어떻게 그 문법을 사용해야 하는지에 대해서 많이 배울 수는 없다. 다시 말해, 당신이 소위 초보 프로그래머라면, C++ 문법을 이용해 프로그램을 짤 수는 있지만 C++가 어디에 실제로 좋은지 (그리고 나쁜지)를 알 수는 없다. 요점이 무엇이냐? 알렌 펠리스 말을 인용한다: "당신이 프로그래밍에 대해 생각하는 법에 영향을 미치지 못하는 컴퓨터 언어는 배울 가치가 전혀 없다." 한 가지 가능한 부분은 당신이 기존의 툴을 어떤 특정한 업무를 해내기 위해서 C++ (혹은 더 가능성 있는 건 JavaScript나 프로세싱)에 대해 살짝 배워야만 할 수는 있다. 하지만 이러한 경우에도 어떻게 프로그래밍을 해야하는지를 배우지 못할 것이다; 당신은 그 업무를 성공했을 뿐이다.
- 하루만에: 불행하게도, 다음 장에서도 말하겠지만 하루는 충분하지 않다.
10년 동안 스스로를 가르쳐라
연구자들(블룸(1985), 브란 & 할터(1899), 헤이즈(1989), 시몬 & 체이스(1973))은 어떤 영역에서든지 전문성을 기르는 것은 약 10년이 걸린다고 말한다. 체스, 음악작곡, 통신작용, 그림, 피아노 연주, 수영, 테니스 그리고 신경과학과 위상심리학 연구까지 포함해서 말이다. 중요한 점은 의식적인 연습이다: 이는 단순히 반복해서 하는 게 아니라, 어려운 문제를 통해 스스로의 한계에 도전하고 시도하고 끝난 뒤에는 당신의 성과를 분석하고 실수를 고쳐나가는 것을 뜻한다. 반복해라. 그리고 다시 반복해라. 지름길은 없다: 심지어 4살부터 천재적인 작곡을 했던 모차르트도 월드클래스의 음악을 작곡하는 데에는 13년이 넘게 걸렸다. 다른 장르의 예를 들면, 비틀즈는 단번에 1위를 하는 수많은 히트송을 만들어내고 1964년에 에드 설리번 쇼에 나타난 것처럼 보인다. 하지만 그들은 1957년부터 리버풀과 함부르크의 작은 클럽에서부터 연주해왔고, 일찍부터 인지도를 가지고 있었지만 그들의 의미있는 첫 성공은 1967년에 나온 Sgt. Peppers였다.
말콤 글래드웰은 이러한 아이디어를 대중화했다. 비록 그가 10년이 아닌 1만 시간에 더 집중했지만 말이다. 헨리 카티어-브레슨(1908-2004)는 다른 단위를 가지고 있었다: "당신의 첫 1만장의 사진은 당신의 최악일 것이다." (그는 몇몇 사람들이 디지털 카메라를 가지고 1주만에 그것을 해낼 것이라고 예상하진 못했다..) 진실된 전문성은 평생이 걸릴지도 모른다: 사무엘 존슨(1709-1784)는 말했다. "어떤 분야든 탁월함은 오직 평생의 노동으로써만 얻어진다; 그것은 그보다 낮은 가격으로는 살 수 없는 것이다." 그리고 체이서(1340-1400)는 불평했다. "인생은 짧고 기술은 배우는 데에 너무나도 오래 걸린다." 히포크라테스(기원전 400)는 말했다. "인생은 짧고, 기술은 오래걸리고, 기회는 순식간에 지나가고, 경험은 믿을 수가 없고, 판단은 어렵다."
물론, 어떤 숫자도 마지막 정답이 될 수는 없다: 어떤 스킬들(예를 들어, 프로그래밍, 체스, 장기, 음악연주 등)이 마스터하는 데에 정확히 같은 양의 시간이 걸린다거나, 모든 사람이 같은 시간이 걸린다고 생각하는 건 이성적이지 않아 보인다. K 안더스 에릭슨 교수는 다음을 강조한다. "대부분의 영역에서 가장 재능있는 개인이 최고 수준의 성과에 도달하기 위해 얼마나 많은 시간이 걸리는지는 놀랍다. 1만 시간이라는 숫자는 단지 당신에게 감을 주기 위한 것이다. 선천적으로 재능있는 사람도 최고 수준에 도달하기 위해서는 매주 10-20시간씩 여러 해가 걸린다는 사실을 말이다."
그래서 프로그래머가 하고 싶니
여기에 프로그래밍 성공을 위한 나의 레시피가 있다:
- 프그래밍에 흥미를 가져라, 그리고 재미있는 무언가를 해라. 그것이 충분히 계속 재밌고 그래서 당신이 기꺼이 당신의 10년/1만시간을 거기에 투자할 것인지를 확실히 해라.
- 프로그램. 배움에 있어서 가장 좋은 방법은 직접 해보면서 배우는 것이다. 좀더 기술적으로 이야기하자면, "주어진 영역에서 개인의 최고 수준의 성과는 오랜 경험만 넣으면 결과가 나오는 함수처럼 자동으로 얻어지지 않는다. 그 수준의 성과는 굉장히 숙련된 사람에 의해서도 의식적인 연습을 통해서만 나온다." (p. 336) 그리고 "가장 효과적인 배움은 적절한 난이도의 잘 정의된 문제와 유익한 피드백, 그리고 반복을 위한 기회와 틀린 것에 대한 교정이다." (p. 20-21) '의식적인 연습'에서
- 다른 프로그래머와 소통하기; 다른 프로그램을 읽어라. 이것은 어떠한 책 혹은 훈련과정보다 중요하다.
- 만약 당신이 원한다면, 4년을 대학(혹은 석박사)에 쏟아 부어라. 이는 당신에게 증명서가 필요한 직업을 줄 것이고, 그 분야에 관한 더 깊은 이해를 줄 것이다. 하지만 당신이 학교에 흥미가 없다면, 당신은 (어느 정도 희생을 가지고) 스스로 혹은 현 직업에서 비슷한 경험을 할 수 있다. 어떠한 경우에도, 혼자 책에서 배우는 것은 충분치가 않다. "컴퓨터 과학 교육은 붓과 미술 도구를 연구하는 것이 누군가를 전문 화가로 만드는 것 이상으로는 누구도 전문적인 프로그래머로 만들 수 없다." 새로운 해커의 백과사전의 작가 에릭 레이몬드는 말했다. 내가 고용해 본 최고의 프로그래머들 중 한 명은 단지 고등학교 졸업장만 가지고 있다; 그는 훌륭한 소프트웨어를 많이 만들었고 그만의 뉴스 집단을 가지고 있으며, 그리고 그만의 나이트클럽을 사기 위한 스톡옵션을 충분히 받았다.
- 다른 프로그래머와 프로젝트를 해라. 어떤 프로젝트의 최고 프로그래머가 되어라; 어떤 다른 프로젝트에선 최악이 되어라. 당신이 최고일 때, 당신은 프로젝트를 이끌고 다른 누군가를 당신의 비전을 가지고 영감을 주는 당신의 능력을 시험해 볼 수 있다. 당신이 최악일 때엔, 장인들이 무엇을 하는지 그리고 그들이 무엇을 안 좋아하는지를 알 수 있다(왜냐하면 장인들은 그들을 위해서 당신이 그것을 해내도록 할 것이기 때문에).
- 다른 프로그래머들의 프로젝트를 보아라. 다른 누군가에 의해 쓰여진 프로그램을 이해해라. 이해하기 위해 무엇이 필요한지 보라. 그리고 본래 프로그래머들이 근처에 없다면 그것을 고쳐라. 그 프로그램을 당신 이후에 사용할 사람들을 위해 더 쉽게 디자인할 방법에 대해 생각해봐라.
- 최소한 6개 이상의 프로그래밍 언어를 배워라. 하나는 (Java 혹은 C++와 같은) 클래스 개념(class abstraction)을 강조하는 언어를, 하나는 (Lisp 혹은 ML 혹은 Haskell와 같은) 기능적 개념(functional abstraction)을 강조하는 것, 하나는 (Lisp와 같은) 문법적인 개념을 지원하는 것, 하나는 (Prolong 혹은 C++templates와 같은) 서술적인 사양(declarative specification)을 지원하는 것, 그리고 이것들을 배웠다면 (Clojure 혹은 Go와 같은) 유사성(parallelism)을 강조하는 것을 익혀라.
- 컴퓨터 과학에서 "컴퓨터"가 있다는 점을 기억해라. 당신의 컴퓨터가 지시을 실행하는 데에 얼마나 걸리는지를 알아라, (캐시 누락이 있건 없건) 메모리에서 단어를 가져오고, 디스크로부터 오는 연속적인 단어들을 읽어라. 그리고 디스크의 새로운 장소를 찾아라.(Answers here.)
- 언어 표준화에 참여해라. ANSI C++ 커뮤니티가 될 수도 있고, 당신의 로컬 코딩 스타일이 2개 혹은 4개의 공백을 가질 것인지 정하는 것이 될 수도 있다. 마찬가지로, 당신은 다른 사람들이 이 언어에서 좋아하는 게 무엇인지, 얼마나 그들이 깊이 공감하는지 그리고 아마도 약간은 왜 그들이 왜 그렇게 느끼는지에 대해서도 배울 수 있다.
- 언어 표준화에 언제 손을 뗄 지에 대한 좋은 감각을 가져라.
위의 것들을 모두 고려하면, 책을 통한 배움에서 당신이 어느 정도를 얻을 수 있는지가 궁금해질 수 있다. 내 첫째 아이가 태어나기 전에, 나는 '어떻게 할 것인가'라는 책을 모두 읽었지만, 여전히 노답 초보자처럼 느껴졌다. 30 달 후에, 둘째 애가 태어날 때 즈음, 내가 그 책들을 다시 읽었을까? 아니다. 대신에, 나는 내 개인적인 경험에 의존했고 그러한 경험은 전문가들에 의해 쓰여진 수천 페이지의 책보다 나에게 유용했고 안심이 되었다.
프레드 브룩은 그의 에세이 '은 총알은 없다'에서 훌륭한 소프트웨어 디자이너를 찾는 3 부분의 계획을 정의했다.
- 최대한 일찍이 최고의 디자이너를 시스템적으로 찾아라.
- 디자이너들의 발전과 가능성에 책임 있는 커리어 지도자와 계약해라.
- 성장하는 디자이너에게 상호작용하고 서로를 자극할 수 있는 기회를 주어라.
이것은 몇몇 사람들이 이미 좋은 디자이너가 되기 위한 필요한 자격을 가졌다는 것을 가정하지만; 그 직업은 적절히 달래기 위함이다. 알렌 펠리스는 더 간결하게 표현했다: "모두가 조각가로 가르침을 받을 수 있다: 미켈란젤로는 그렇게 되는 법을 배우지 말아야겠지만 말이다. 그러니 프로그래머도 마찬가지이다." 펠리스는 위인들은 어느 정도 훈련을 뛰어넘는 내적인 자질이 있다고 말한다. 하지만 그 자질은 어디에서 오는가? 선천적으로? 그렇지 않으면 그들의 성실함을 통해 자질을 발전시켜야 하는가? 어거스트 구스티우(라따뚜이의 쉐프)는 말한다. "누구든 요리할 수는 있다. 하지만 겁없는 자만이 홀륭한 쉐프가 된다." 내 생각에 이것은 기꺼이 그들의 삶의 많은 부분을 의식적인 연습에 헌신하는 것이라고 생각한다. 하지만 아마도 겁없음은 이것을 요약한다. 혹은, 구스티우의 비판으로써, 안톤 에고는 말했다: "모두가 훌륭한 예술가가 될 순 없다. 하지만 훌륭한 예술가는 어디서나 나올 수 있다"
그러니 어서 시작해라. Java/Ruby/Javascript/PHP 책을 사라; 당신은 아마 책을 통해서 익숙해질 순 있을 것이다. 하지만 하루만에 혹은 3주만에 당신은 프로그래머으로서의 삶으로 바꿀 수 없을 것이고, 리얼한 전문성을 가지지도 못할 것이다. 2년 동안 연속적으로 열심히 해보는 것은 어떠한가? 글쎄, 이제 당신은 어느 정도에 도달하기 위해 시작하는 중일 뿐이다.
댓글
댓글 쓰기