메아리 저널

어떻게 하면 프로그래밍에 대해 가르칠 수 있는가에 대해서 고민하고 있다. 과연 프로그래밍이 어려운 것일까? 라는 생각도 해 보고 있고.

기본적으로 프로그래밍은, 당연하지만, 컴퓨터에게 어떻게 어떻게 하라고 지시하는 방법일 뿐이다. 어머니가 자식한테 심부름을 시키면 -- 요즘은 이런 심부름 안 시키겠지만 그건 또 다른 이야깃거리고 -- 뭐 슈퍼에 가서 두부 한 모 사오고 식용유 한 통 사오고 남은 돈은 니가 까먹지 말고 그냥 가져 와라. 뭐 이러시겠지. 슈퍼에 가려면 먼저 집 밖에 나와서 큰 길가로 나온 뒤 좌회전해서 한 블럭 지나치기 전에 나오는 건물 1층을 가면 되고... 뭐 이런 것이 구조적인 프로그래밍이고, Design by contract(DBC)를 예로 들면 슈퍼에 가기 전에 돈이 충분히 있는지 확인하고 돌아 와서 예상한 만큼의 잔돈이 있는지 확인하고... 다 평범한 말로 풀어 쓰면 솔직히 아무 것도 아닌 얘기 뿐이다.

컴퓨터가 사람과 다른 점이라면 말귀를 도통 못 알아 먹는다는 점일 것이다. (하긴 좀 개구장이라면 두부 한 모 사오고 식용유 대신 간장을 산 뒤 남는 돈으로 아이스크림 하나 사 먹고 돌아 올 지도 모르겠다. 하지만 최소한 뭔가 사 오려고 하긴 할 거 아닌가.) 그래서 우리는 컴퓨터에게 매우 명확하게 우리의 의도를 설명해 줄 필요성을 느끼고, 이게 프로그래밍이 어려운 이유라 할 수 있겠다.

프로그래밍은 두부 한 모 사오는 것보다 훨씬 어려운 주제를 다루기 때문에 다양한 방법으로 이걸 간명하게 풀어 쓰려고 하게 마련이다. 이 과정에 들어 가는 것이 추상화인데, 추상화의 본질은 "간접적"인 방법으로 "직접적"인 것을 다루는 것이고 -- 예를 들어 사과 두 개와 세 개를 더할 때 산수를 배운 우리는 사과를 늘어 놓고 세는 게 아니라 2+3=5라는 "간접적"인 식을 통해 합하면 다섯 개가 된다는 "직접적"인 사실을 깨닫게 된다 -- 직접적인 건 우리가 잘 아는 거니까 제끼면 "간접"(indirection)이 남는다. 포인터와 레퍼런스, 서브루틴과 함수 포인터, 클래스와 메소드, 뭐 좀 다른 얘기를 하면 모나드라든지. 이런 것들이 모두 "간접"을 다루는 것이기 때문에 간접적인 것에 대해 사고를 할 수 없으면 프로그래밍은 배로 어려워진다.

프로그래밍을 가르칠 때 해 줘야 하는 가장 첫번째 일은 물론 프로그래밍에 대해 흥미를 갖게 해 줘야 하는 것이겠지만, 그 다음으로 해야 하는 일은 이 간접에 대한 것을 가르치는 것이라고 생각한다. 지금 계획하고 있는 프로그래밍 세미나는 이 과정을 원래 요구되는 세미나 주제(게임 개발)와 잘 꿰어 맞춰서 하려고 하고 있는데, 간접에 대한 내용은 현재 1/4 지점, 즉 간단한 문법을 가르친 직후(!)로 하려고 한다. 이게 가능한 이유는 게임 개발은 결국 뭔가 상호작용을 기대하는 것이고, 따라서 상호작용을 가르치려면 간접적으로 참조되는 객체에 대한 개념은 필수적이기 때문이다. 흥미를 잃지 않게 하기 위해 최대한 실제 게임을 빠른 시간 내에 만들면서 하려고 하는데 잘 될지는 모르겠지만... 한 번 해 봐야 할 일이긴 하다.