한빛출판네트워크

저자: 임백준 (루슨트 테크놀로지스)

필자는 프로그래밍을 비교적 늦은 나이인 이십대 중반에 시작했다. 따라서 독학을 통해서 익힌 "초식"이 많았는데 그래서인지 10년이 지나도록 잘 고쳐지지 않는 습관이 하나 있다. 머리 속에 알고리즘의 윤곽이 떠오르면 일단 키보드를 붙잡고 코드를 두드려야만 직성이 풀리는 것이다. 그렇게 하지 않으면 다음 내용이 잘 떠오르지 않는다. 프로그래밍 방법론이나 소프트웨어 공학의 충고에 의하면 이것은 "코딩"이 "설계"에 앞서는 대단히 잘못된 방법에 속한다. 교과서에 적힌 기본을 무시하는 철저한 아마추어리즘의 소산인 것이다.

프로그래밍의 맛

여러 명의 개발자가 함께 코딩을 하는 경우에는 물론 얘기가 다르다. 그런 경우에는 레쇼날 로즈(Rational Rose) 같은 소프트웨어나 객체 설계용 언어인 UML을 이용해서 어느 정도 설계를 마친 다음에 코딩을 시작할 수밖에 없다. 하지만 프로그래밍을 혼자서 할 때는 언제나 "코딩"이 "설계"를 앞선다. “진정한 "프로"는 설계를 마친 다음에 비로소 키보드를 잡는 거야”라고 아무리 말해도 소용이 없다. 커피를 마실 때 크림을 넣지 않으면 맛이 느껴지지 않는 것처럼 손끝에 전달되는 키보드의 감촉이 없으면 프로그래밍의 "맛"이 느껴지지 않는다.

이런 습관은 회사에서 수행하는 공식적인 프로그래밍에도 종종 연결된다. 외부의 API가 모두 결정된 상태에서 독립적인 컴포넌트의 내부를 구현하는 경우에는 예외 없이 코딩에서 부터 설계가 시작된다. 화면에 뜬 편집기(필자의 경우에는 주로 vi)라는 캔버스 위에 키보드 커서라는 연필을 조금씩 움직여 나가면 머리 속에 감추어져 있던 알고리즘이 서서히 눈앞에 모습을 드러낸다. 때로는 종이 위에 동그라미, 네모, 선 등을 그리면서 설계를 하는 경우도 있지만 그것은 어디까지나 키보드를 통해서 하는 붓질을 돕는 보조적인 조치일 뿐이다.

프로그래밍에 "조예"가 있는 개발자라면 이런 습관은 그다지 자랑할 바가 아니라고 생각할 것이다. 당연하다. 필자도 아주 최근까지 그렇게 생각했다. 그렇지만 프로그래머 중에서 이와 같은 습관을 가지고 있는 사람이 적지 않으리라는 점은 분명하다. 손끝에 키보드의 감촉이 전달될 때 비로소 프로그래밍의 맛을 느끼는 사람은 결코 필자에 국한되는 얘기가 아닐 것이다.

하지만 그런 사람들조차 대부분 "설계"에 앞서는 "코딩"은 자랑할 바가 아니라고 생각한다. 특히 프로그래밍 실력이 뛰어난 고수일수록 설계를 마치기 전에는 키보드를 넘실거리지 않을 것이라고 믿는다. 뒤집어 말하면 설계를 끝내기 전에 키보드를 만지작거리는 사람은 일종의 "하수"로 간주되는 셈이다.

프로그래밍 예술론

필자가 이와 같은 "설계"와 "코딩"의 관계를 포함하여 흔히 알려진 프로그래밍의 방법론이나 소프트웨어 공학의 "교리"를 의심하기 시작한 것은 (지난 해에 두 권의 책을 쓰면서) 프로그래밍의 본질이 "공학"에 있는가 아니면, "예술"에 있는가 하는 문제를 고민하면서부터였다.

프로그래밍이 도대체 예술일 수 있는가에 대한 답을 구하려면 우선 예술이 무엇을 의미하는지 이해해야 하는데 그것은 간단하지 않은 주제이므로 여기서 다루기 어렵다. 하지만 한 가지 분명한 것은 필자의 관점에서 볼 때 프로그래밍은 공학적 요소를 포함하고 있긴 하지만 분명히 예술에 더 가깝다는 점이다.

프로그래밍을 예술로 파악하는 것은 물론 새로운 관점이 아니다. 「프로그래밍의 예술(The Art of Computer Programming」로 유명한 스탠포드 대학의 도날드 카누스 교수는 일찍이 「문학적 프로그래밍(Literate Programming)」이라는 책에서 "프로그래밍은 예술"이라고 선언한 바 있다. 그는 이러한 선언을 한 걸음 더 밀고 나아가 프로그램 소스 코드도 다른 예술 작품들과 마찬가지로 미학적 요소와 독창성을 고려해서 "값"이 매겨지는 시대가 도래할 것이라고 예언하기까지 했다.

문학적 프로그래밍이란

카누스 교수가 말한 "문학적 프로그래밍"이란 사실 단순한 비유에서 그치는 것이 아니라 코드의 예술성을 담보하기 위한 일종의 구체적인 프로그래밍 방법론이었다. 우리나라에서는 「생각하는 프로그래밍」이라는 책으로 번역된 "프로그래밍 펄(Programming Pearl)"로 유명한 존 벤틀리는 카누스 교수가 "문학적 프로그래밍"을 설명한 글을 읽고 감명을 받은 나머지 자신의 컬럼 몇 개를 카누스 교수의 새로운 방법론을 소개하는데 바치기도 했다.

"프로그래밍은 예술"이라는 명제는 사실 수학 명제처럼 명쾌하게 증명될 수 있는 것이 아니다. 그러나 프로그래밍을 하는 사람이라면, 그 "맛"을 조금이라도 아는 사람이라면, 이 명제를 간단하게 거부하지 못할 것이다. 오픈소스 프로젝트에 참여하여 자신의 여가시간마저 프로그래밍에 바치는 해커든, 아니면 회사에 출퇴근하면서 정해진 틀에 따라 코딩을 하는 "월급쟁이"이든 상관이 없다.

프로그래밍이 단순히 기술이나 공학의 수준에 머무르지 않는다는 사실은 누구에게나 분명하다. 프로그래밍이라는 행위 안에는 꼭 집어서 설명할 수 없지만 가슴이 떨리고 흥분이 밀려오는 "창조적 긴장"의 순간이 담겨 있기 때문이다.

카누스 교수는 스스로 수학적 논리와 알고리즘에 대해서 실로 심오한 내공을 갖추고 있었다. 그런 맥락에서 그는 프로그래밍이 가지고 있는 "과학적 미학"의 측면을 강조했다. 이에 비해서 폴 그래이엄은 프로그래밍에 담겨 있는 "창조적 미학"의 측면을 날카롭게 부각시켰다. 그래이엄은 하버드에서 컴퓨터 공학 박사 학위를 받고 인공지능 언어인 LISP에 대한 교과서를 쓸 정도로 내공이 중후한 프로그래머였다. 뿐만 아니라 인터넷 붐이 한창이던 1998년에 ViaWeb이라는 회사를 야후에 팔아서 "비즈니스맨"으로서도 이름을 얻었다.

그래이엄은 프로그래밍에 담긴 예술의 측면을 설명하기 위해서 프로그래밍을 그림 그리는 행위에 비유했다. 앞에서 그를 소개하면서 내공이 중후한 "프로그래머였다고" 말한 이유는 그가 지금은 그림(painting)을 공부하여 화가의 길을 걷고 있기 때문이다.

그가 보기에 프로그래밍은 순수한 논리나 학문의 대상이라기보다는 "실천적 행위"를 통해서 몸에 익혀 가는 구체적인 "행동"에 가까웠다. 그것은 마치 텅빈 백지 위에 붓을 한 번 크게 긋는 행위와 다를 바 없었다. 그래서 그는 컴퓨터 과학이라는 표현이 프로그래밍의 진정한 속성을 정확하게 담지 못한다고 비판했다.

프로그래밍이 "컴퓨터 과학" 혹은 "컴퓨터 공학"과 같지 않은 이유는 그림을 그리는 예술적 실천이 물감의 화학적 배합을 연구하는 "학문"과 같지 않은 이유와 동일하다. 다시 말해서 그림을 그리는 화가는 물감의 화학적 성분이나 여러 화학 이론에 대해서 굳이 알 필요가 없다.

이와 마찬가지로 프로그래밍이라는 창조적 활동을 하는 사람(즉, 프로그래머)들은 컴퓨터 과학과 공학의 수많은 이론을 굳이 자세하게 알 필요가 없다. 예를 들어서 튜링 기계나 오토마타의 개념 정도는 알 필요가 있을지 몰라도 복잡성 이론(complexity theory)에 등장하는 명제를 모두 읽어야만 좋은 프로그램을 만들 수 있는 것은 아니다.

코딩이 설계에 앞선다?

그래이엄을 알기 전까지 필자는 "코딩"이 "설계"를 앞서는 습관을 "아마추어리즘"의 표현이라고 생각해 왔다. 진정한 프로라면 교과서에서 가르치는 대로 정확하게 설계를 마친 다음 비로소 코딩을 시작해야 하는 것이라고 생각했다. 이런 강박관념은 일종의 열등감마저 수반했는데 그래이엄의 통찰은 필자를 "예술"이라는 아름다운 이름과 함께 구원해 주었다.

프로그래밍을 예술로 바라보는 관점에서 생각해 보면 "판에 박힌 듯한" 소프트웨어 개발 방법론은 프로그래머 개개인의 감성을 존중하기보다는 정해진 틀에 맞는 상품을 생산하기 원하는 기업의 욕망을 반영하고 있다. "획일적인 틀"은 상품 생산을 위해서 필요할 뿐 진정한 창조와 아무런 상관이 없기 때문이다.

뛰어난 프로그래머였던 그래이엄은 자기 자신도 프로그래밍을 할 때 키보드를 붙잡고 코딩부터 시작한다고 고백했다. 그가 밝힌 방법은 우선 가볍게 키보드를 두드리면서 코드의 전체 윤곽을 잡고, 다시 처음으로 돌아가서 조금씩 각 부분의 디테일을 살려 나가는 방식으로 프로그램을 작성하는 것이었다. 그는 코딩이 설계에 앞서는 이와 같은 방식을 조금도 이상하게 여기지 않았다. 오히려 그는 모든 예술적 창조가 대개 이와 비슷한 과정을 거치면서 이루어지며 그림을 그리는 과정도 이와 다르지 않다고 말했다. 그리고 미술에서는 그것을 "스케치"라는 자연스러운 이름으로 부른다고 지적했다.

혹시 필자가 이 글을 통해서 "코딩은 설계에 앞서야 한다"는 명제를 주장하고 있다고 잘못 이해하지 않기 바란다. 그것은 손으로 달을 가리켰더니 손가락만 바라보더라는 이야기와 다를 바 없는 오해가 될 것이다. 여러 명이 함께 복잡한 소프트웨어를 만들 때 "설계"의 과정이 결정적으로 중요하다는 사실에는 이견이 있을 수 없다. 다만 필자는 소프트웨어의 "생산성"을 높이기 위한 방법론이 반드시 프로그래밍의 "예술성"을 강화시키는 쪽으로 작용하지 않는다는, 아니 정확하게 말하자면 그 반대의 방향으로 작용한다는 사실을 지적하고 싶었을 뿐이다.

그럼 프로그래밍의 "예술성"을 강조하는 프로그래머는 그렇지 않은 프로그래머에 비해서 소프트웨어 "생산성"이 떨어지는 것일까? 놀랍게도 전혀 그렇지 않다. 오히려 그 반대의 경우가 더 많다. 창조의 기쁨을 아는 사람과 그렇지 않은 사람이 발휘하는 능력에는 본질적인 차이가 존재하기 때문이다. 필자가 이 글을 통해서 말하고 싶은 것이 바로 그 차이이다. "기쁨"이 있는 사람과 없는 사람 사이에 존재하는 차이는 프로그래밍의 예술적 속성을 이해하는데 있어서 핵심적인 열쇠가 된다.