SICP, 그리고 HTDP
어떻게 하면 프로그래밍을 제대로 배울 수 있을까?
Structure and Interpretation of Computer Programs(이하 SICP)는 MIT의 기초
프로그래밍 교육 과정을 엮어 낸 책이다.
SICP 6.001은 2008년부터 MIT에서도 개설되지 않는다.
SICP. Harold Abelson and Gerald Jay Sussman with Julie Sussman, Structure and Interpretation of Computer Programs, 1984, MIT Press
이 책의 신선한 교육 철학과 완성도 높은 내용은 기존의 프로그래밍 입문 교재들과
차원을 달리했다. 그리하여 ‘강호를 평정’했다고 표현해도 될 만치 수많은 (이 글을
쓸 때만해도 100여개 넘는) 교육 기관에서 이 과정을 채택했고, 이른바 프로그래밍
입문 교육의 표준이 됐다.
제대로 하는 프로그래밍, 그리고 SICP #
어떻게 해야 프로그래밍을 제대로 배울 수 있을까? 그리고 어떤 식으로 해야 프로그래밍을 제대로 가르칠 수 있을까? 프로그래밍 기술 서적이 무더기로 쏟아져 나오지만 정작 위와 같은 질문에 바른 답을 주는 책은 드물다. 무엇이 ‘제대로’인지 깨닫지 못하는 바에야 무작정 프로그래밍 기술을 집어 삼키는 것이 무슨 의미가 있을까? 이 문제를 진지하게 고민하지 않는 이에게는 세상에 둘도 없이 못써먹을 책이겠지만, 그렇지 않다면, 어떻게 프로그래밍을 배우고 가르쳐야 할지 그 바른 출발점을 찾지 못해 진지하게 헤매는 누군가가 있다면, SICP는 오아시스 같은 해답이라고 해도 좋다.
SICP의 신선한 교육 철학 #
SICP의 무엇이 그렇게 상큼했을까? 이 책은 프로그래밍 언어의 선택부터가 남달랐다. 당시 산업에서 인기를 끌고 있던 언어나, 교육용 언어로 널리 인정받았던 Pascal 등을 쓰지 않고 MIT에서 개발한 새로운 언어—Scheme을 실습 언어로 과감하게 선택하였다. 프로그래밍 언어 Scheme은 LISP의 전통을 이어받아 설계된 언어이나 Static Scoping옮겨쓸 알맞은 우리말을 찾지 못했다. 을 채택하고, 함수 계산 결과가 함수가 될 수 있도록 기능을 확장한 면이 다르다. 그렇다면 하고 많은 언어 중에 왜 하필이면 Scheme을 실습 언어로 선택하였을까? 그것도 처음 프로그래밍을 훈련하는 과정에서 왜 그런 독선이 필요했을까?
첫 번째 프로그래밍 언어의 선택은 아주 중요하고도 민감한 문제다. 처음 배우는 언어는 프로그래머에게 모국어와 같아서, 프로그래머가 생각하는 사고의 기틀이 된다. 다시 말해서 프로그래머는 평생동안 처음 배운 프로그래밍 언어의 영향을 쉽사리 벗어나지 못한다. Sapir-Whorf 가설을 빌어, APL을 만든 Kenneth Iverson이 FORTRAN으로 시작하면 명령을 내리는 사고 방식, Lisp으로 시작하면 함수로 조립하는 사고 방식에 익숙해진다고 주장하였다. 또 코드만 봐도 쓴 사람이 누군지 알아맞힐 수 있을 만큼 첫 언어의 패러다임과 관용구가 생각을 지배한다는 고찰도 있다. 하지만 그럴 법한 주장이지만 입증된 사실이 아니므로 단언하는 표현을 쓰지 말았어야 했다. - 2026년 1월 26일, 김재우
만일 표현 수준이 낮은 언어를 선택하여 프로그래밍을 배우게 되면, 문제를 푸는 데 집중하지 못할 가능성이 크다. 다시 말해서, 문제 푸는 사고를 익히기 전에 일단 낮은 표현 수준을 문제의 해법에 가까운 표현 수준으로 끌어올리는 작업에 더 많은 노력을 기울여야 할 수 있다. 물론 그 또한 꼭 익혀야할 기술이겠으나 처음 프로그래밍을 배워, 문제를 풀어내는 사고를 가꾸어내고자 하는 교육 목표와는 거리가 멀다. 다시 말해, 문제 해결력을 목표로 하는 프로그래밍 입문 과정에서 다루어야 할 주제는 아닌 것이다.
그렇다면, 표현 수준이 비교적 높은 언어만을 골라 쓰면 달리 문제가 없을까? 대부분의 상용 프로그래밍 언어는 충분히 표현 수준이 높지만, 다양한 문제 풀이법에 고르게 유리하지 않아서 문제다. 즉, 비교적 표현력이 뛰어난 실습 언어라도 편협한 해법을 강요하게 된다면 문제를 유연하게 해결하는 사고력을 가르치는 데 방해가 된다. 일단 한 쪽으로 치우친 문제 풀이법에 익숙해지면, 나중에 완전히 다른 방식의 해법을 공부하게 되더라도 처음 익힌 사고의 편향성 때문에 새로운 방식에 적응하기 매우 힘들다. 나도 뒤늦게 SICP를 공부하면서 받은 부담이 프로그래밍을 처음 배웠을 때보다 훨씬 더 컸다.
그러므로, 가능하면 아예 처음부터 복합 사고를 익히게 하는 게 옳다. 즉, 하나의 문제 풀이에 가능한 해법을 총동원해 보고, 그 중 가장 유리한 해법 몇 개를 섞어 쓰도록 유도하는 것이 바람직하다. 그런데, 이런 종합적 사고를 가르칠 때에도 조심해야 할 점이 있다. 가르치는 이는 배우는 이로 하여금 서로 다른 사고가 구분되는 것이 아니요, 본래 그 문제를 푸는 데 그와 같은 방식을 적용해야 바람직하다는 점을 문제 풀이 과정에서 스스로 체득할 수 있도록 인도해야 한다. 여러 방식을 가르친다는 것을 자랑삼다가 부질없이 이 논리와 저 논리, 이 기법 저 기법을 구분짓도록 하면 되려 역 효과가 날 수 있다. 다시말해 가르치는 데 있어 패러다임을 구분지어 설명하는 것은 중요하지 않다. 그저 문제를 잘 풀 수 있는 한 가지 방법으로 소개하면 충분하다.
Scheme은 앞의 두 가지 문제를 균형 있게 해결할 수 있는 훌륭한 답이다. 문법이 간결하고 구문의 의미가 명확하다 보니 다른 언어에서처럼 ‘문법의 횡포’에 시달릴 이유가 적다. 즉, 언어를 익히느라 시간을 허비하지 않아도 되므로 교육의 취지에 맞게 프로그래밍(또는 문제해결력)을 익히는 데 더 많은 노력과 시간을 기울일 수 있다. 만일 이 글이 언어 선택에 대한 확신을 심어주기에 모자라다고 생각하면, Alan J. Perlis가 쓴 SICP의머리말과 참고자료1을 읽어봐 주었으면 한다.
SICP의 두 번째 자랑거리는 주옥같은 예제에 있다. 이 책은 예제로 시작해 예제로 끝난다고 해도 과언이 아닐 정도로 풍부한 예제를 제공한다. 그 완성도가 뛰어남은 물론이고, 하나 하나 확실한 교육 목표를 염두에 두고 설계되어 있다. 즉, 프로그래밍 기법이나 새로운 응용 분야를 말로 드러내어 설명한다기보다, 주어진 문제의 해결책을 찾아가는 과정에서 해당 분야의 지식과 전형적인 해결책을 스스로 발견하기를 기대한다.
이는 가르치는 데 있어 시중에서 흔히 볼 수 있는 프로그래밍 책들과 크게 다른 접근 방식이다. 보통 프로그래밍 패러다임이나 설계 원리를 설명하는 책들은, 이해시키고자 하는 대상에 지나치게 집중한 나머지 예제 선택의 중요성을 간과한다. 예제 자체를 이해하는 데 부담을 줄이고, 주제를 드러내어 이해시키고자 하는 목적에 충실다. 그러나, 원리 해설에는 이런 방식이 유리할지 몰라도, 그 원리가 실제 문제에 어떻게 적용되는 지, 그리고 아주 중요한 문제해결능력—하나의 완전한 응용속에 여러 가지 다른 문제가 꼬여서 발생할 때 그 각각의 실타래를 원리에 대응하도록 솎아내는 훈련에 도움이 되지 않는다. 줄여 설명하자면, 결코 헛갈려서는 안되는 목적—“프로그래밍 언어"를 가르치고자 하는 것인지 “프로그래밍"을 가르치고자 하는 것인지를 원칙없이 뒤섞어 놓은 경우가 많다.
다형성 예제: 복소수 #
SICP의 2.4~2.5절은 SICP의 그런 장점을 보여주는 좋은 예다. 이 두 절은 복소수를 예로 들어 다형성 문제를 취급하고 있는데, 무작정 다형성을 소개하는 것이 아니라 ‘한 종류(형, type)의 데이터라도 왜 여러 개의 표현이 필요한지’를 프로그램 개발 과정에서 요구 변화에 따라오는 필연적 개선 과정으로 설명한다.
복소수는 직각좌표계에서 표현할 수 있지만, 극 좌표계에서도 표현 가능하다. 그런데 이 두 표현 방식은 쓰임새에 따라 어느 한 쪽이 더 유리해질 가능성이 있다. 예를 들어, 복소수를 덧셈/뺄셈 할 때는 직각좌표로 표현하는 것이 좋고, 곱셈/나눗셈에는 극좌표가 자연스럽다.
복소수 덧셈에는 직각좌표 표현이 유리하다.
$$c_1 + c_2 = \bigl(\text{Re}(c_1) + \text{Re}(c_2)\bigr) + \bigl(\text{Im}(c_1) + \text{Im}(c_2)\bigr)i$$
복소수 곱셈에는 극좌표 표현이 유리하다.
$$c_1 \cdot c_2 = r \cdot e^{iA} \quad \text{where} \quad r = |c_1| \cdot |c_2|, \quad A = \angle c_1 + \angle c_2$$
그러므로, 이 중 단 한 가지 표현만 고집하면 성능과 편의성 면에서 어느 한 쪽 연산에만 유리하게 된다. 하지만, 복소수로 복잡한 계산을 하게되면 당연히 두 표현을 동시에 섞어 써야할 상황에 처하게 되고, 연산의 특성을 고려하여 고르게 유리한 복소수 데이터를 만들고자 애쓸 수 밖에 없다. 이런 경우, 같은 데이터를 표현의 차이 때문에 두 개의 데이터로 완전히 갈라놓는 것은 제대로된 해결책이 아니다. 표현이 달라진다고 해서 복소수의 의미도 달라지는 것이 아니기 때문에, 표현이 여러 가지라고 해도 하나의 그릇에 섞어야 바람직하다. 즉, 이 데이터를 사용하는 코드는 같은 데이터를 쓰고 있다는 점만 기억하도록 해주어야 한다. 이 문제를 가장 간단하게 해결하는 방법은 내부에서는 한 쪽 표현에 따라 구현하고, 다른 표현은 인터페이스로만 제공하는 것이다.
$$\begin{aligned} c &= x + yi \quad \text{(복소수를 직각좌표로 표현했을 경우)} \\[0.5em] \text{Re}(c) &= x \\ \text{Im}(c) &= y \\ |c| &= \sqrt{\text{Re}(c)^2 + \text{Im}(c)^2} \\ \angle c &= \arctan\bigl(\text{Im}(c),\, \text{Re}(c)\bigr) \end{aligned}$$
이 방법은 극좌표 표현을 직각좌표 표현으로부터 계산해 내기 때문에 곱셈 연산을 자주하는 경우 계산 효율이 크게 떨어진다. 본래 연산에 따라 더 적합한 표현을 선택할 수 있는 ‘표현 선택의 자유’를 제공하려는 목적을 만족시키지 못하지만, 우선 사용자 인터페이스를 표현과 분리하여 설계해놓고, 일단 돌려 보는 용도로는 적합하다. 그리고 곱셈이 실제로 빈번하게 사용되지 않는다라고 확신할 수 있다면, 이 기법만으로도 한 가지 데이터 형에 표현은 여러 가지로 제공한다는 목적은 일단 달성한 셈이다. 어쨌거나 사용자는 입맛에 맞게 극좌표, 직각좌표 인터페이스를 골라 쓸 수 있으니 내부에서 실제 어찌 짜맞추었는 지를 알 도리도 없고, 알 필요도 없다. 다시 말해, 목표를 이루었으니, 좀더 유리한 기법을 탐구하고 실험해 볼 수 있는 여유를 챙긴 셈이라 하겠다.
자, 이제 좀 더 깊은 문제를 논해보자. 인터페이스에는 아무런 변화를 주지 않고, 진정 서로 다른 연산에 유리한 서로 다른 표현을 한 바구니에 담으려면 (하나의 형처럼 취급하려면) 어떤 마술을 부려야 할까? 실제 복소수 데이터를 사용하는 코드를 조사해 보니 덧셈과 곱셈을 고루 사용하는 것으로 드러났다고 하자. 그리하여, 곱셈에 유리한 극좌표 구현을 쓰지 못하면 계산 성능을 끌어올리기가 어렵다고 하자. 이런 경우라면, 그저 껍질(인터페이스)만 두 가지 표현을 받아들인양 프로그램해서는 안된다. 실제 다양한 연산에 대응해서 두 가지 다른 표현을 하나의 형처럼 바꾸어가며 사용할 수 있어야 한다. 동시에 이미 앞서 제공한 복소수 인터페이스를 쓰던 코드에 아무런 영향을 주지 않아야, 그 프로그램 설계가 올바르다 하겠다.
SICP는 이런 문제의 해법으로 정책이 전혀 다른 세 가지 프로그래밍 기술인 Tagged Data, Data-Directed Programming, Message-Passing을 소개한다. 그러나 어느 것이 절대 유리하다고 편협한 판단을 강요하지 않는다. 단지, 다음과 같은 질문을 던져 학생 스스로 상황에 따라 유리한 기법을 고를 수 있는 안목을 기르라고 소리 없이 가르친다.
- 추가 변동 사항이 없다면 가장 효율 있는 방법은 무엇인가?
- 만일 직각좌표, 극좌표 외에도 새로운 복소수 표현을 추가할 필요가 있다면 어떤 기법이 가장 유리한가?즉, 또 다른 표현이 필요하다고 해도, 이미 만들어 놓은 코드를 전혀 손댈 필요가 없는 기법은 무엇인가?
- 만일 표현의 종류에는 변화가 없으나 연산이 새로 추가되어야 한다면 어떤 기법을 쓰는 것이 가장 유리한가?즉, 복소수 연산이 더 필요할 때, 나머지 코드에 전혀 손상을 가하지 않는 기법은 무엇인가?
이 문제에 대한 해답은 독자들의 몫으로 남겨둔다. 당연히 그 해답은 SICP 속에 있다.
읽기 능력 훈련 #
이제 책 내용에 대한 설명은 접고 SICP의 교육 철학에 대한 얘기를 마무리 짓도록 하자. SICP가 보기 드물게 훌륭한 예제를 풍부하게 제공한다는 점은 앞에서 이미 얘기했다. 그런데 이 책에서 좋은 예제가 차지하는 역할이 하나 더 있다. 읽기 능력 훈련이 바로 그 것이다. SICP는 다른 많은 프로그래밍 연습용 서적처럼 작은 문제를 바닥부터 홀로 만들어 올라가는 방식을 취하지 않는다. 그보다는 어느 정도 규모를 갖춘 예제와 그 예제에 걸맞은 프로그램을 구조를 보여주고, 이를 완성하거나 개선하는 방식의 문제를 제시한다. 배우는 이가 책이 제시하는 예제를 충분히 이해하고 온전히 자기 것으로 소화하지 못하면, 문제의 의도는 물론이고 적절한 답을 찾기 어렵다. 이는 좋은 프로그래머라면 코드를 읽고, 그 동작 방식을 제대로 그려낼 줄 알아야 한다. 즉, 프로세스 시각화(process visualization) 능력을 갖추도록 하려는 교육 의도를 충실히 담아낸 접근 방식이라 하겠다.
SICP 현황과 문제점 #
SICP의 철학과 우수성은 앞에서 충분히 설명했다고 본다. 이제 그 문제점과 대안을 알아볼 차례가 됐다. 세상에 완벽한 해결책이란 없는 법이다.
우선 이 멋진 책(또는 과정)을 얼마나 많은 대학에서 쓰고 있는지 살펴보자. 현재 SICP를 가르치는 대학은 약 100여개 정도 된다. 나라 별로 그 수가 많은 것부터 늘어놓아보면 단연코 미국이 가장 많다. 미국은 모두 93개 대학으로 컬럼비아, 코넬, 프린스턴, (물론) MIT 등이 여기에 포함된다. 그리고 영국에서는 옥스포드를 포함해 총 7개 대학, 독일은 9개 정도다. 이어서 이탈리아와 덴마크가 각 2개, 네덜란드·핀란드·벨기에·스페인이 각 한 개씩인 것으로 되어 있다.
이에 비해 우리나라를 포함한 아시아권은 그 수가 적다. 일본은 동경대, 싱가포르는 싱가포르 국립대에서 이 과정을 채택하고 있고, 우리나라에서는 KAIST(이광근 교수 2026년 서울대학교 재직 ), 고려대학교에서 채택하고 있다. 등록되어 있지 않지만 창원대(이수현 교수)에서 SICP를 가르치고 있다는 사실을 들어서 알고 있다. 또한, 현재는 다른 과정으로 대체됐으나 한 때, 동아대학교에서 김명호 교수가 1995년부터 신입생 프로그래밍 강좌로 이 강좌를 개설해 한 해 5개 강좌 약 300명이 수강하기도 했다.
총 100여개에 이르는 대학이 한 대학에서 개발한 과정을 채택하고 있다고 보면 여전히 많은 축에 속하기는 하지만 예전만큼 ‘강호를 평정’하고 있다고 하기는 어렵다. 지난 10여 년간 SICP를 채택하거나, 적어도 Scheme을 실습 언어로 선택하는 대학이 많이 줄어든 것이 사실이다. 이는 많은 대학에서 이 분야의 급격한 기술 변화를 무시하지 못하고, 예전처럼 유행하는 프로그래밍 언어를 가르치는 방식으로 돌아섰기 때문에 생긴 결과라 하겠다.또, Scheme의 교육 효과를 대체하고도 남을 만한 좋은 언어나 과정들이 많이 생겨났기 때문이기도 하다. 그러나 이런 슬픈 현상을 추세 탓으로만 돌릴 수는 없는 법이다. SICP를 채택한 이후에 겪게 된 여러 가지 문제점이 그런 변절의 빌미를 제공했다고도 볼 수 있기 때문이다.
SICP의 문제점은 2002년에 발표된 참고자료1에 비교적 잘 설명되어 있다. 다만, SICP 방식 교육에 깊은 관심이 있는 사람이라면, 그전에 Philip Wadler의 논문2을 읽어 보는 것이 좋다. 이 논문에서 몇 가지 눈에 뛸 만한 것을 나름대로 정리해 보면 이렇다. 아마도 SICP를 약 4장 정도까지라도 따라가 본 사람은 이 논문이 주장하는 바를 공감할 수 있을 것이다.
SICP의 가장 큰 문제는, 과정 자체가 너무 따라가기 어렵다는 데 있다. 프로그래밍 자체가 어려운 것이야 당연한 것이지만, 프로그래밍 기법을 설명하기 위해 드는 예제들이 문제다.
SICP는 컴퓨팅를 전공하는 학생들만을 위한 기초 서적이 아니다. 프로그래밍이 꼭 필요한 분야라면 전공에 관계없이 채택할 수 있는 기초 기술 서적(또는 과정)이다. 그런데, 수록된 예제가 때때로 너무 깊고도 넓다. 특정 분야에 치우침 없이 고루 응용할 수 있는, 다양한 문제와 해법을 다루고 있기 때문에 전산 전반에 걸친 기초 기술 모두를 한 번씩은 건드리고 넘어간다고 봐도 좋을 정도다.물론 전기·전자 공학과 관련된 주제를 지나치게 많이 다룬다는 비판도 있다. 게다가 신입생을 대상으로 하는 책이라고 할 때, 그 완성도가 높아서 분야별 사전 지식(domain knowledge)을 먼저 학습하지 않고서는 문제 자체를 이해할 수 없는 경우가 대부분이다. 잘 훈련된 선생을 만나 균형 잡힌 지도를 받지 못한다면 초심자들은 이 책이 분야별 사전 지식과 프로그래밍 기법 중 어느 쪽에 중점을 두고 있는지 스스로 깨닫지 못할 가능성이 높다.
처음 배우는 이를 더욱 당혹스럽게 만드는 점은 이 책의 ‘보물찾기’ 식 내용 구성이다. 프로그램 설계를 그 어느 서적보다 중요하게 다루지만 드러내어 떠들지 않는다. 너무 고상한 방법으로 목표를 달성하려고 하다가 선문답 식 가르침이 되어버린 셈이다. 가르치고자 하는 모든 것을 예제 속에서 엮어 놓았기 때문에 배우는 사람 스스로 그 참뜻을 찾아내려 애써야 한다. 사실, 학생 대부분은 숨겨놓은 교육 의지(제대로 프로그래밍하기)를 찾아내지 못하고, 표면 지식(이를테면, 언어 그 자체나 특정 응용 분야)에 더 중점을 두기 쉽다. 더욱이 가르치는 사람조차 그 의도를 충분히 알아차리지 못한다면, SICP의 숨겨진 교육 의도는 무시되기 쉽다. 내용상의 연계성을 고려하지 않고 교육 의도—‘왜 그렇게 프로그래밍 하는 것이 옳은가’를 충분히 전달할 수 없기때문에, 주어진 예제를 단순히 풀어내려가는 평범한 (그러나 아마도 아주 혹독한) 문제 풀이 훈련으로 전락할 수 있기 때문이다. 이런 문제 때문에, 이 과정을 제대로 이끌어갈 수 있는 교수진을 구성하기도 어렵다.
HTDP와 Dr. Scheme #
앞서 SICP 과정의 문제점은 다음 두 가지로 요약할 수 있다.
- 특정 분야 지식을 과하게 요구할 뿐만 아니라, 그 지식을 설명하는 데 너무 많은 지면을 할애한다.
- 프로그램 설계를 드러내 가르치지 않으므로, 학생들에게 교육 목표를 제대로 전달하는 데 어려움이 많다.
How To Design Programs(이하 HTDP)Matthias Felleisen, et. al, How To Design Programs, 2003, MIT Press 는 이와 같은 SICP 과정의 문제점을 개선하는 데 목표를 두고 만들어 낸 책(또는 교육 과정)이다. 더 자세한 개발 동기 및 설계 *원칙, 교수법 등에 대한 설명은 참고자료1에 잘 정리되어 있다.
HTDP를 개발한 사람들은 모두, PLTProgramming Language Technology, http://www.plt-scheme.org/who 라 불리는 단체의 구성원들이다. PLT는 다양한 Scheme 구현을 제공할 목적으로 만든 자원 단체로, 현재까지 EdScheme 또 MzScheme 등을 개발해 공개 배포하고 있다. 특히 이 그룹에서 개발한 Dr. Scheme은 재미있는 소프트웨어다. Dr. Scheme은 여러 Scheme 구현 위에 돌아가는 일종의 Scheme IDE라 할 수 있는데, 애초부터 프로그래밍을 가르칠 목적으로 설계하였다. 그래서, 프로그래밍 훈련의 재미와 효과를 높일 수 있는 여러 가지 기능이 있다. HTDP(또는 SICP) 같은 과정과 Dr. Scheme 같은 실습 소프트웨어는 정말 찰떡궁합이라 할 수 있다.
정리해서 SICP의 난이도가 부담스럽거나 참신하다 못해 독선적인 전개 방식이 적합하지 않다고 판단한다면, HTDP는 좋은 대안이다. 그러나, 두 책은 교육 철학과 내용에서 너무나 성격이 다른 과정이므로 대체 교과라기 보다, 서로 부족한 부분을 메꾸어 주는 것으로 받아들이는 것이 옳다.
HTDP와 우리 프로그래밍 교육 #
우리나라의 많은 교육 기관이 이론 교육과 실무 기술 교육 사이의 균형점을 찾지 못하고 우왕좌왕하고 있다고 보는 게, 내 솔직한 견해다. 컴퓨터 공학(과학)과 정보 처리학(소프트웨어 공학)~~은 엄연히 다른 것인데도, 하나의 과정 속에 분별없이 섞어놓고, 학생들이 어디로 가야 할지 해답의 실마리를 쥐어 주지 않는다. 취업 문제로 고민하는 학생들에게 나름대로 해결책을 제시하기 위해 실무 기술을 가르치겠다는 의지 자체는 충분히 공감하는 바다. 그러나, 기존 교육 체계는 그대로 두고서 실무 기술 교육을 강화하겠다는 것(교육 내용만 유행하는 것으로 살짝 바꿔치기하겠다는 것)은 헛수고다.
전에 따로 소개한 바 있는 The Pragmatic Programmer3의 서문에 쓰인 말대로, 개발자의 능력은 기초 컴퓨팅 이론 바탕 위에 다양한 실무 프로젝트를 개발하는 경험이 차곡 차곡 쌓이고 녹아서 배양된다. 철저한 실무 교육을 목표로 하더라도, 기초 이론 교육을 무시한다면 창의성 있는 인력을 길러낼 수 없다. 연구 중심의 이론 교육을 강조한다고 해도 현업에서 사용하는 실무 기술과의 연계성을 고려하지 않으면, 머리만 크고 손발이 없는 기형적 인력을 낳게된다. 그리고, 산업과 연구가 서로를 무시하고 배격하는 아주 우스꽝 스런 기술 사회가 형성된다. 슬프지만 바로 지금 우리가 그 모습과 크게 다르지 않다.
이런 점에서, HTDP가 추구하는 프로그래밍 교육의 원칙은 주목할 만하다. 프로그래밍의 원리 교육과 실무 기술 훈련이 하나의 과정 속에 어떻게 배치되어야 하는지 한 가지 해법을 제안하고 있기 때문이다. 참고자료1은 HTDP가 추구하는 프로그래밍 교육 목표를 다음과 같이 기술하고 있다.
변하는 기술 환경에 빠르게 적응할 수 있고, 수십 년 동안 소프트웨어 관련 직종에서 살아남을 수 있는, 유능한 소프트웨어 개발 인력을 양성하는 것이 프로그래밍 교육의 목표다.
너무 뻔한 얘기라서 식상하기까지 하지만, 우리네 교육기관 중 저 목표를 향해 진정 땀 흘려 달리는 곳이 과연 몇 군데나 될까? 참고자료1에서는 이와 같은 교육 목표를 달성하기 위해, 다음과 같은 구조로 교육 과정을 구성하는 것이 바람직하다고 주장한다.
프로그래밍 커리큘럼은 근본 원리를 가르치는 데 중점을 두어야 한다. 그리고 첫 해 두 번째 학기와 마지막 학년에서 산업이 요구하는 기술에 적응할 수 있도록 실용 기술을 훈련한다.
이와 같은 제안이 우리네 교육 기관이 처해있는 여러 가지 문제를 정말 해결해 줄 수 있는지를 함부로 판단할 수는 없는 법이다. 그러나 SICP나 HTDP와 같은 해법이, 프로그래밍 기술의 본질을 바로 알고 더 나은 프로그래밍 교육을 시도하는 가치 있는 실천임에는 의문의 여지가 없다고 믿는다.
여러분에게 드리는 선물 #
여기까지 글을 읽어주셨으니 이제 몇 가지 선물을 드리고 이 글을 접을까 한다. 이 글에서 소개한 두 권의 책은 모두 웹에 전문이 올라와 있다.
앞 글에서도 말한바 있지만, SICP를 제대로 익히려면 좋은 선생이 필요하다. 한데, 다행스럽게도 (그리고, 너무 고맙게도) 저자(Harold Abelson) 및 다른 MIT 교수진의 SICP 강의를 동영상으로 보고 들을 수도 있다.
http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/
강의도 들을 수 있고, 책도 마련했으니, 이제 실습용 프로그래밍 환경만 있으면 완벽하겠다. 이왕 책이 권하는 대로 Scheme을 써보기로 했다면, 다음 주소에서 Dr. Scheme을 내려받을 수 있다.실습 언어로 꼭 Scheme을 써야하는 것은 아니지만, 다른 언어를 쓴다고 해도 책을 읽고 예제를 풀기위해 책속에 있는 Scheme 프로그램은 잘 읽고 이해할 수 있어야 함은 물론이다.
“어떻게 하면 제대로 프로그래밍을 배울 수 있는 가?“란 물음에, 이 글은 SICP와 HTDP로 답하였다. SICP와 HTDP가 프로그래밍의 마법을 익히는 지고의 보물임에는 의심할 여지도 없다. 심지어 그 보물은 모두 공짜로 얻을 수 있다! 이제 훌륭한 마법사가 될 수 있을 지 말지는, 온전히 배우는 자의 몫이다. 명심하시라. 마법서는 누구나 볼 수 있지만, 좋은 마법사가 되기란 여간하지 않다.
Matthias Felleisen, et. al, “The Structure and Interpretation of the Computer Science Curriculum,” 2002 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Philip Wadler, “A Critique of Abelson and Sussman: Why calculating is better than scheming,” SIGPLAN Notices 22(3)(1987) 83-94 ↩︎
Andrew Hunt, David Thomas, Ward Cunningham, The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley ↩︎