프로그래밍을 시작한 지 얼마 안되었을 때에는 어려워 보이는 코드가 멋있어 보였습니다. 그러다가 색다른 충격을 몇 번 받고는 쉬워 보이는 코드가 멋있어 보이더군요. 지금은 단순히 쉬워 보인다, 어려워 보인다라는 일차원적 평가가 위험하다는 생각을 하고 있습니다. 그 이야기를 좀 해볼까 합니다. (기우에서 말씀드리면, 제가 제시하는 모형도 단순화한 것이기에 절대적으로 받아들이기에는 위험성이 있다는 점을 염두에 두시면 좋겠습니다)

다음 도표를 보시죠. 여기에서 E는 쉽다, D는 어렵다를 말합니다. 또, 처음 접했을 때 얼마나 쉬운지, 또 시간이 지난 후(일정한 노력을 기울인 후)에 얼마나 쉬운지를 구분하여 행에 처음 접한 난이도, 열에 나중에 느끼는 난이도를 표시했습니다. 이때 쉽다 어렵다는 것은 상대적인 것이며 코드를 읽는 사람(혹은 관리할 사람)을 기준으로 합니다.

(1) 이런 간단한 방법이 있었다니!

(1)은 처음 봤을 때도 쉬워 보이고, 시간이 지난 후에도 여전히 쉬워 보이는 코드입니다. 제가 앞에서 말한 "색다른 충격"이 이 경우였습니다. 주로 스몰토크 문화 배경을 가진 사람들의 코드가 이렇더군요. 내가 애초에 이런 코드를 생각 못했다는 것이 멍청하게 느껴지게 만드는 코드입니다. 간결하고, 투명합니다.

(2) 앗, 속았다!

(2)는 처음에는 쉬워 보였지만, 시간이 지나보니 사실은 어려운 코드입니다.

어설프게 자연언어를 모방하려고 한 코드(사실 자연언어는 오해를 많이 발생할 소지가 있는 위험한 언어입니다)가 그렇습니다. 스파게티를 깔끔한 포장지로 치장한 것에 비유할 수 있습니다. 코드를 처음에 보면, 어라! 줄줄 읽힙니다. 나름대로 머리속에 모형을 만들게 되죠(mental model). 하지만 이 모형이 실제 모형과 거리가 있습니다. 실제는 그렇게 단순하거나 아름답지 않을 수 있거든요. 조금만 예외적인 경우를 다루려고 해도 이 머리속 모형을 포기해야 합니다. 또 내부적으로 제대로 이해를 못하고 표면적으로만 흉내를 내다 보면 오해도 생기고 실수도 하게 됩니다. 코드의 행동을 정확하게 예측하기가 힘듭니다.

더 깊은 소스 코드를 자주 들여다 봐야 하고, 레퍼런스나 메뉴얼을 자주 참조해야 합니다.

부분적으로는 이해하기 쉽지만 전체적으로는 이해하기 어려운 코드도 여기에 속합니다. 여기저기 간단해 보이는 로직을 복사/붙여넣기한 코드도 그렇습니다. 일견 쉬워보입니다. 하지만 그런 코드 속에서 한 달 정도만 살다보면 악몽을 꾸기 시작합니다.

(3) 아, 알겠다!

(3)은 처음에는 어려워 보이지만 나중에는 쉬워 보이는 코드입니다.

생소한 개념들 때문에 처음에는 낯설고 어려워 보이지만, 몇 가지 핵심적 개념을 이해하면 어느 순간, 따악! 죽비 맞고 네오가 메트릭스에서 득도하여 만물을 꿰뚫어보는 듯한 경지에 달할 수 있는 코드입니다. 시간이 가면서 눈이 점점 트이고 전체 "와꾸"가 확하고 와닿는 코드입니다.

새롭고 유용한 추상적 개념을 사용한 코드, 개념적 일관성과 개념의 시스템이 있는 코드가 그렇습니다. square(제곱), root(제곱근), cube(세제곱) 등의 개별적 개념들을 따로 익히는 것은 일견 쉬울 수 있습니다. 반대로 power(거듭제곱)를 익히는 데에는 시간이 더 걸릴 수 있겠죠. 하지만 일단 power라는 개념을 알게 되면 기존의 square, root, cube들이 하나로 확 관통이 될 뿐 아니라, 실수, 허수 거듭제곱까지도 쓰임을 연장할 수 있습니다.

이 코드를 이해하면 스스로 좀 더 똑똑해졌다고 느끼고, 또 그 느낌이 지속됩니다.

이런 코드의 초기 학습 속도를 높이기 위해서는 트레이닝이나, 멘토링, 개념적 문서 등이 제공되면 도움이 되긴 하지만 원래의 필요 학습량 자체를 줄이는 것은 무척 어렵습니다. 기본적으로 "나"(혹은 나의 뇌)의 변화를 요구하기 때문입니다.

(4) 예나 지금이나 어려워

(4)는 처음에도 어렵고 시간이 지나도 계속 어려운 코드입니다.

복잡도가 지나치게 높고 추상화도 안 된 코드입니다. 이런 코드는 익숙해지기가 무척 어렵습니다. 좀 익숙해졌다 싶어도 하루 지나면 다 까먹습니다.

시간이 지나면서 계속 덧대기 작업을 한 코드가 이렇게 되기 쉽습니다. if문이 여러겹이라 한 1시간 걸려 코드 읽고는 if문 하나 새로 추가합니다. 전역변수 사용도 많아서 도무지 전체 그림을 한 사람의 뇌 위에 올려놓을 수가 없습니다.

우리가 지향해야 할 코드는

저는 우리가 (1)번과 (3)번 영역의 코드를 지향하는 것이 바람직하다고 생각합니다. 1번만 추구하려는 사람은 쉬운 코드가 장땡이라고 생각하는 경우인데, 이것은 우리 스스로를 발전시킬 기회를 놓치는 것이라고 봅니다. 3번을 같이 추구할 때 우리 스스로 더 똑똑해지고, 더 속도를 낼 수 있다고 생각합니다. 또 2번을 추구하는 사람(대개 자신이 2번을 추구한다고 생각하지는 않는데, 의심해 볼 필요가 있음)은 1번이나 3번의 대안이 가능한가를 생각해 보는 것도 유익하다고 생각합니다.

마지막으로 한 마디만 더 달자면, 2번과 4번 영역도 경우에 따라 쓸모가 있다고 생각합니다. 어쩔 수 없는 선택일 경우도 있고요(이 경우, 시스템의 한정적인 부분에서 의식적으로 사용하고 영향이 퍼지지 않게 관리, 제어하는 것이 필요합니다). 하지만 1번이나 3번의 존재를 의식하고, 그쪽을 모색하고 실험하고 또 거기로 가려고 노력하는 자세가 필요하다고 생각합니다.

p.s. 이 글은 코드뿐만 아니라 언어, 혹은 쉽고 어렵고가 내 선택의 중요한 기준 중 하나가 되는 그 밖의 것들에도 적용 가능합니다

--김창준

올 2월부터 NOO 스터디를 시작했습니다. 책이 드디어 끝났습니다. 책걸이 기념으로 발표회를 합니다.

NOO에 대해 지식이 전무한 분들 대상으로 저희가 5개월 동안 쌓은 지식과 경험을 농축해 드리겠습니다. 금주 토요일 저녁 7시부터 9시까지이고, 서울 MS 본사(포스코 건물)에서 열립니다. 무료이고요. 스터디원 중 대부분이 IT업계에 있는 분(프로그래머, 기획자, 미디어아티스트, 컨설턴트 등)이기 때문에 그런 분들에게 가까운 이야기도 있을 것이고, 책 자체가 건축 이야기라 건축에 대한 이야기, 또 디자인, 아름다움 등에 대한 이야기도 할 것입니다.

관심있는 분들의 참여 기대합니다. 참가신청

--김창준

애자일컨설팅의 컨설팅을 무료로 받을 수 있는 기회가 생겼습니다. http://groups.google.com/group/xper/browse_thread/thread/5944f7069997acb3

안타깝지만 마감일이 얼마 안남았네요.

좋은 기회, 인연이 되기를 바랍니다.