첫번째 모임에서 우리는 먼저 프로그래밍 언어를 빠르게 숙달하기 위한 방법에 대해 논의하고자 합니다. 물론 여기서 논의된 방법이 공식적으로 증명된 최선, 최효율의 방법은 아닐 것입니다. 아무래도 제 발표이다 보니 저의 경험이 보다 더 우선시될 수 있겠습니다.

그래도 어느 정도는 저를 믿어 주셨으면 좋겠습니다. 그동안 프로그래밍을 공부하면서 겪은 시행착오를 통해 얻은 경험은 그래도 많은 것을 설명해 줄 수 있다고 생각합니다.

저는 남창우입니다. 프로그래밍을 접한 것은 초등학교, 컴퓨터 학원을 통해 GW-BASIC을 배운 것부터 시작합니다. 그 때는 아무런 논리적인 트레이닝 없이 그냥 재밌어서 시작한 프로그램 공부였지만, 그래도 가장 밑바닥에 위치한 제 프로그래밍의 첫 경험입니다.

군대에서 취미로 프로그래밍을 공부했습니다. VBA나 자바, C 같은 걸 마구 헤집었는데, 군대라는 환경에서는 쉽지 않았습니다. 원래 저는 건축과였지만, 건축과가 너무 맞지 않아서 컴퓨터공학과로 전과를 결심했지요. 그렇게 전과를 준비하는 중에서도 PHP4, MYSQL, HTML 같은 걸 이용해 학교 학생회 전산관리도 맡았습니다. 순전히 취미였죠.

학부를 졸업하고 대학원의 석사 과정을 거쳤습니다. 컴퓨터 그래픽스 쪽에서 3D 모델링 쪽을 잡고 공부를 했지만 아쉽게도 더 깊은 공부를 거치지는 못했습니다. 조금 미련이 많이 남네요.

취미가 프로그래밍이라서 그런지 다양한 언어와 다양한 것들을 즐겨 합니다. 지금은 프리랜서로 활동하고 있답니다. 그다지 많은 프로젝트를 한 편은 아니지만, 그래도 여러 방면에서 프로그래밍에 있어서는 많은 경험을 가지고 있습니다.

어떻게 프로그래밍 언어를 빠르게 배울까 하는 논의를 하기 전에 우선 그 '프로그래밍'이 무엇인지 이야기를 하지 않을 수 없을 것 같네요. 프로그래밍이라는 말 부터 이야기해 볼까 합니다.

컴퓨터 프로그램이란 컴퓨터를 동작시키기 위한 명령들을 말합니다. 다르게 표현하자면 우리가 컴퓨터에게 시키고 싶은 일들을 컴퓨터에게 지시하기 위한 수단입니다.

이런 명령들을 만들기 위해 만들어진 것이 프로그래밍 언어입니다. 프로그래밍 언어는 컴퓨터와 사람이 동시에 이해할 수 있는 컴퓨터에게 명령을 내리기 위해 설계된 언어입니다.

여기서 상당히 의미심장한 표현이 있습니다. '사람'과 '컴퓨터'가 '이해'할 수 있는 언어라는 점이죠. 사람이 언어를 이해하는 것은 우리가 어떤 언어를 이해한다는 것과 거의 유사하기 때문에, 이 부분은 쉽게 받아들일 수 있을 겁니다. 그런데 도대체 컴퓨터는 언어를 어떻게 이해하는 걸까요?

결론적으로 말하자면 컴퓨터는 사람처럼 언어를 이해하는 것이 아닙니다. 이해하는 것처럼 동작하는 것일 뿐이죠. 그리고 잘 아시겠지만 그 언어 또한 사람의 언어처럼 '우유 하나 사 와' 식으로 문맥을 전달하는 것이 아닙니다. 하나에서 열까지 일일이 가르쳐 주고 정해 주지 않으면 안 되는 것이 컴퓨터의 언어입니다.

컴퓨터에게는 사람이 이해하는 것과 같이 이를테면 '사과, 우유, 건물, 컵'과 같은 단어와 그 단어에 대한 문맥이란 것이 존재하지 않습니다. 모든 것이 숫자로 표현되고, 그 수와 수 끼리의 수학적인 연산이 있을 뿐입니다. 요즘은 스마트폰을 통해 사물도 인식하고 음성도 인식하는 기능이 있긴 하지만, 그렇다고 해서 스마트폰이 사람의 말을 알아듣는 것은 아닙니다. 그저 사람의 말을 어떤 식으로든 숫자로 표현해 미리 정해진 대로의 계산을 할 뿐인 겁니다.

컴퓨터 입장에서 봤을 때 프로그램은 세 가지 부분으로 나눠 생각할 수 있습니다. 그 세가지란 입력, 출력, 그리고 과정입니다. 일을 시키려면 그 일에 대해 어떤 입력이 필요합니다. 그리고 그 일에 대한 결과를 내 주어야 합니다. 입력과 출력 사이에는 미리 정해진 동작이 있을 것입니다. 입력, 출력, 그리고 과정. 이 셋은 프로그래밍 로직 구성을 위해 가장 중요한 개념입니다.

그러면 언어를 빠르게 공부하기 위해서는 어떡해야 할까요?

프로그래밍 언어 또한 언어입니다. 사람의 언어와는 그 패턴이 조금 다르지만, 아무튼 언어인 것 틀림없습니다. 다시 말하면 많이 습득하고 많이 반복할수록 언어 표현은 더욱 유연해지고 미려해집니다. 글도 많이 써 본 사람이 잘 쓰는 것처럼 프로그래밍을 많이 해 본 사람이 더 잘 할 수 있습니다.

그리고 한 언어에 대해 충분히 공부를 해서 개념을 잡게 된 사람은 다른 프로그래밍 언어를 보다 쉽게 배울 수 있습니다. 프로그래밍 언어의 종류는 많지만 세상의 언어처럼 그렇게 다양한 패턴을 보이지는 않기 때문입니다. 때로는 사람 골탕 먹으라고 만드는 이상한 프로그래밍 언어도 있지만, 뭐 그런건 예외로 둡시다.

다작을 하는 것처럼 프로그래밍도 많이 만들어 봐야 합니다. 제가 생각하는 가장 훌륭한 프로그래밍 학습 방법은 역시 “hack”입니다. 해킹을 하는 거죠. 아, 여기서 해킹을 한다는 말은 남의 시스템을 불법적으로 들어가서 옳지 못한 행위를 한다는 뜻이 아닙니다. 주어진 프로그램을 다각도로 분석해보고, 이런 것도 해 보고 저런 것도 해 보고 여러 가지 것들을 시도해 보란 뜻에서의 핵입니다.

이렇게 핵을 하려면 사실 단순 반복도 많이 수반됩니다. 그러나 핵이라는 행위 자체는 “이러면 어떨까?, 또 저러면 어떨까?”라는 호기심이 있어야 하기 때문에 어쩌면 매우 창의적이고 적극적인 학습 방법이라 할 수 있습니다. 여기도 왕도는 없다고 생각합니다. 많이 해 보고 시도해 보는 방법이 최고라고 생각합니다.

많이 프로그램을 작성하고, 많은 '핵'을 통해 호기심과 창의력을 폭발시키란 말이죠. 그러나 때로는 핵이 너무 지루하고 괴로울 수도 있습니다. 이 때는 핵이 아니라 소위 '삽질'이라 흔히 표현하는 행위가 되죠. 네, 너무 지나친 '삽질'은 사람의 심신을 피폐하게 만듭니다.

자잘한 디버깅 때문에 심신이 녹초가 될 때도 있겠지만, 가끔 가다 프로그래머는 반복적인 코드 수정에만, 자신이 뭘 하고 있는 건지 갈피를 잘 잡지 못한 채 몰두하고 있을 때도 있습니다. 혹은 자기가 무얼 만들어야 되는 건지 아리송한 상태에서 코드를 작성하는 경우도 있습니다. 그런데 이건 별로 좋지 못한 상황입니다.

프로그래머는 자신이 해야 할 것들에 대한 개념을 명확하게 파악해야 합니다. 목적과 관련된 개념 모두를 완벽하게 파악해야 할 필요는 없습니다. 어떤 것의 개념을 저신의 목적에 맞게 잘 이해하는 것이 중요하죠. 흔히 이런 예를 듭니다. 우리가 운전을 할 때 자동차에 대한 모든 것을 이해하고 운전하지는 않습니다. 우리가 매일 지하철이나 버스를 이용하지만 지하철 시스템이나 버스의 구조 모두를 잘 알고 타야 할 필요는 없습니다. 그저 지하철과 버스에 대해서는 승객의 입장에서 어떻게 하는 것만 알면 충분합니다.

프로그램도 마찬가지입니다. 컴퓨터와 컴퓨터 프로그래밍을 둘러싼 수많은 기술과 용어가 있습니다. 우리가 그 모든 것을 이해해야만 프로그래밍을 할 수 있는 걸까요? 그렇게 하자면 세상의 거의 모든 프로그래머는 프로그래밍을 해서는 안 될 겁니다. 물론 더 잘 알면 더 좋은 프로그램을 작성할 수 있긴 합니다만, 각자 자신과 관련된 부분에서 필요한 부분에 관해서는 명확하게 그 개념을 알면 될 뿐인 것이죠. 우리가 프로그래밍을 하면서 배우게 될 수많은 기술과 용어들을 우리가 모두 다 이해할 수는 없습니다. 그러나 그러한 용어가 말하고자하는 개념, 그것만 명확하게 이해할 수 있도록 하면 됩니다.

그리고 인터페이스가 있습니다! 인터페이스란 그 시스템과 상호작용하기 위한 수단입니다. 자동차 운전을 하려면 핸들을 잡고 돌려야 하죠. 자동차 핸들이 자동차를 원하는 방향으로 돌리기 위한 인터페이스입니다. 우리가 어떤 모르는 것에 대해 어느 정도 이해한다고 할 수 있는 것은 그 인터페이스에 대해 능숙해지는 것과 매우 유사합니다. 운전에 능숙해졌다는 말은 자동차의 인터페이스에 능숙해졌다는 거라고 볼 수 있습니다. 어떤 응용프로그램을 매우 능숙하게 다룬다는 말은 그 인터페이스를 잘 알게 되었다는 말과 거의 흡사합니다.

보다 전문가가 되려면, 더욱 세밀한 것들을 조작하려면 그 인터페이스와 그것을 넘어서야 할 필요는 있습니다. 그러나 우리가 모든 것을 알 필요는 없습니다. 그것이 제대로 동작하려면 어떻게 해야 하고, 또 내가 이렇게 동작시켰을 때 어떤 결과를 도출한다는 것 정도만 잘 알아도 큰 문제는 없습니다.

프로그래밍은 여러 다른 프로그램들과 상호동작하기 마련입니다. 그 말은 내 프로그램은 여러 미리 짜여진 프로그램을 기반으로 동작할 것이며, 그러므로 그 다른 프로그램이 제시하는 인터페이스를 준수해야 한다는 뜻입니다. 그 모든 것을 알 필요도 없고, 알아서도 안 됩니다. 다시 말씀드리지만 필수적인 것들은 당연히 자세하게 알아야 합니다! 다만 그렇게 일일이 모든 것을 다 자세히 알기란 불가능하기 때문이죠.

바로 이겁니다. '핵'을 많이 하고 많이 프로그램을 짜라는 뜻은 프로그래밍에 대한 개념을 명확히 잡고 또 그 인터페이스를 숙달하라는 뜻인 겁니다.

인터페이스는 다음 세 부분이 있다는 것을 의미합니다. '입력', '출력', 그리고 '과정' 이 세 단어를 마음 속 깊이 새겨두시기를 바랍니다. 언제나 프로그램을 작성하기 전에, 또 어쩌다 프로그램이 잘 작성되지 않을 때 이 세 단어를 떠올리시기를 바랍니다.

모든 프로그램은 입력을 받고 출력을 내 놓습니다. 간혹 출력이 없거나 입력이 존재하지 않는 경우도 있을 수 있는데, 그 '없는' 것이 입력이 되고 출력이 되는 겁니다(숫자 0을 생각해 보세요).

프로그램은 항상 이 세 부분으로 나눠집니다. 설계를 하더라도 항상 입력이 무엇인지, 출력이 무엇인지, 그리고 그 과정은 어떻게 되는지를 딱딱 나누어서 명쾌하게 각각의 개념을 설명해야 합니다. 엄청나게 중요합니다. 입력이 올바르지 않은데 출력이 제대로 나올 리도 없고, 아무리 입력이 올바르게 나오더라도 과정이 엉망이면 출력도 엉망이겠죠.

여기까지는 매우 일반적인 이야기를 한 것 같습니다. 사실 위에서 기술된 이야기는 단지 프로그램이란 분야에만 국한되는 이야기가 아닐 겁니다. 무슨 공부를 하거나 새로운 것을 받아들일 때 공통적인 패턴이라고 생각할 수 있습니다.

그럼 파이썬의 경우는 어떨까요? 저는 Real Group의 'Small Talk'라는 노래를 들으면서 파이썬 프로그래밍을 생각했습니다. 사실 Small Talk라는 언어도 있긴 한데요… 그 가사 중에 이런 말이 있습니다.

...
We use the same familiar phrases over and over again
...
Still we love those empty words
...

물론 파이썬은 훌륭한 언어이고 가치 있는 일이 쓰이고 있으며, 다른 프로그래밍 언어가 하는 것 만큼, 혹은 그 이상으로 공헌하는 언어이긴 합니다. 그렇지만 우리가 일상에서, 혹은 파이썬을 배우면서 작성하게 될 모든 코드가 그런 중대한 임무를 맡은 건 아니잖습니까? 물론 언젠가는 우리 모두 그런 '심각한' 코드를 작성하지 않으면 안 될 날이 올겁니다.

네, 살면서 때때로는 중대한 발표를 할 때가 있긴 하지만, 인생에선 사실 친구들끼리 하는 가벼운 잡담이 더 많고 중요할 때가 있습니다. 저는 파이썬을 그렇게 생각합니다. 이걸로 정말 일생일대의 중대한 코드를 짜지 못하는 건 아니지만, 파이썬을 볼 때면 그냥 친구들과 하는 잡답 같은 느낌이 더 강합니다. 초보자들이 쉽게 시작하기 쉬운 언어로 파이썬이 좋다는 말과 매우 같은 맥락입니다.

일상에서 무의미한 잡담 같은 거라도 친구들과의 대화에 있어서는 필요합니다. 친구들끼리 정말 용건만 딱딱 끊어서 말하면 그게 무슨 친한 친구입니까(개중에 그런 친구도 있을 수는 있지만…)? 이런 말 저런말 많이 꺼내면서 여러 이야기를, 때로는 시시한 빈말이라도 나누는 것이 친구 아니겠습니까?

파이썬으로 많은 것들을 쉽게 할 수 있습니다. 그 말은 아주 시시하거나 공허해 보이기까지 한 매우 작고 가벼운 것들을 파이썬으로 쉽게 작성할 수 있다는 뜻입니다. 파이썬을 공부하면서 그런 시시한 프로그래밍을 짜는 것을 저는 매우 좋다고 생각합니다. 어차피 연습인데 어떻습니까? 물론 아주 실없는 프로그래밍만 하면 소중한 시간을 낭비하게 되니까 조심은 해야겠지만요.

이 meet-up을 통해 '재미로 하는' 파이썬이 되었으면 좋겠습니다. 너무 심각한 걸 생각할 필요는 없는 것 같습니다. 그냥 간단하고, 쉽고, 단순한 거라도 파이썬 프로그래밍을 통해 표현되었으면 좋겠습니다. 그리고 그것들이 서로에게 표현되었으면 좋겠습니다. '이런 걸 말하면 내가 형편 없어 보일거야' 같은 생각 하지 않았으면 좋겠습니다. 처음에는 보잘 것 없지만 그렇게 표현하는 과정에서 아이디어를 얻어 점차 근사해질 수도 있는 것 아니겠습니까.