인간은 도구를 사용할 줄 아는 동물이라 했던가? 사람이 지금처럼 문명의 혜택을 누리고 살 수 있는 것은 하루 종일 먹을 것을 찾기 위해 헤매지 않아도 될만큼 생산성이 좋아졌기 때문이다. 그러한 생산성은 바로 도구의 사용에서 비롯한다. 기왕이면 같은 일을 하더라도 좀더 빠르게, 적은 노력으로 할 수 있게 해주는 것이 도구다.

현대인들은 거의 대부분이 컴퓨터를 사용한다. 나처럼 직업적으로 컴퓨터를 '연구'하는 사람도 있지만 그 정도는 아니더라도 인터넷 서핑, 게임, 문서 작업 같은 건 거의 누구나 하는 일이다. 그런 사실을 가만히 들여다보면, 컴퓨터의 목적도 도구임을 알 수 있다. 다만 할 수 있는 일이 아주 많은 조금 비싼 도구라는 정도?

사람들이 컴퓨터로 하는 일 중에서 문서 작업을 예로 들어보자. 대부분 MS워드나 아래아한글 같은 워드프로세서를 이용할 텐데, 여러 문단의 서식을 한번에 바꾸거나 자동 목차 생성에 활용할 수 있는 '스타일' 기능을 제대로 쓰는 사람은 몇이나 될까? 또, 인터넷 서핑을 예로 들면 웹브라우저에 확장기능을 설치해 광고를 차단한다거나 마우스 제스처로 서핑을 좀더 편하게 하는 사람은 과연 몇이나 될까? 워드프로세서나 웹브라우저는 매우 많은 사람들이 사용하는 도구이지만, 의외로 이들 도구를 속속들이 잘 쓰는 사람은 많지 않다.

아무래도 나는 전산을 공부하는 사람이고 직업적으로 다루는 사람이다보니, 남들하고 똑갈은 소프트웨어를 쓰더라도 어떻게 하면 그걸 더 잘 쓸 수 있을까를 고민하며 쓴다. (때론 직접 만들기도 하고.) 그러한 고민의 순간에는 약간의 시간과 노력이 소모되지만 대부분 시간이 지날수록 비약적인 생산성 향상을 가져온다는 것을 경험적으로 체득하고 있다.

한 가지 아쉬운 것은, 위에서 이야기했듯 컴퓨터와 거기에 올려진 소프트웨어라는 아주 좋은 도구들---표현하자면, 인류 문명의 가장 최첨단을 달리는---을 제대로 쓰는 사람이 생각 외로 적다는 것이다.

그 이유는 여러가지가 있는데, 그런 더 좋은 사용방법이 존재한다는 것 자체를 모르는 경우가 가장 많은 것 같다. 옆에서 누가 알려주기라도 하면 시도라도 해볼 텐데 말이다. 하지만 반대로 배울 의지도 있고 가르쳐줄 사람도 있지만 여러 현실적 여건(특히 시간부족) 때문에 그냥 넘어가는 경우도 많다. 그리고 대부분 이런 사용방법들은 책이나 매뉴얼을 그냥 읽는 것으로 습득되는 것이 아니라 자기 손으로 직접 그렇게 써봐야 익혀지는 경험적 지식이라서 더 전파속도가 느리다. RTFM("Read the fucking manual")이라는 말이 있긴 하지만, 결국 써보지 않으면 남지 않는다.

내가 학부 때 SPARCS 동아리 활동과 Textcube 개발 활동을 하면서 얻은 소득이라면, 전산분야에서 많이 사용되는 여러 소프트웨어 도구들을 상당한 수준으로 쓸 수 있게 되었다는 점이다. 안타깝게도 학교 수업만으로는 그런 도구를 잘 쓰게 되기 매우 어렵고, 교수님들이 학생들에게 일일이 그런 것을 가르치는 것 또한 더 중요한 지식 전달에 방해가 될 뿐이다. 하지만 동아리에서는 몇몇 선배님들이 도구 사용의 중요성을 끊임없이 역설했고, 나또한 그러한 경험을 쌓으면서 그에 공감할 수 있었다. (좀더 넓은 인간관계를 경험해본다는 점에서도 동아리 활동이 중요하지만, 전산을 하는 사람이라면 도구를 제대로 익힌다는 점에서도 매우 중요하다.)

아무리 이론적 지식이 많아도, 요즘엔 너무나 많은 아이디어가 쏟아지기 때문에 자기 아이디어를 prototype이라도 남에게 직접 보여주고 경험시켜주지 않으면 인정받기 어렵다. 그렇기 때문에 주어진 도구를 잘 사용하는 것은 자기 아이디어를 재빠르게 구현하는 데 이르는 가장 중요한 첫걸음이다. 그래서 도구를 잘 사용하기 위한 노력과 시간에 투자를 아끼지 않아야 한다.

하지만 도구의 함정에 빠지는 것은 또 경계해야 할 일이다. 전산 분야에서 유명한 농담 중에 '야크 털깎기(Yak shaving)'라는 것이 있다. 원래 하려던 일은 나무를 깎으려던 것인데, 도끼가 더 잘 들면 나무를 더 빨리 벨 텐데 해서 도끼 날을 세우다가, 좋은 숫돌이 있으면 도끼 날을 더 잘 세울 텐데 해서 좋은 숫돌이 있는 곳을 수소문하고, 저 멀리 어디 있단 얘길 들어 야크를 타고 가려다가 야크 털을 깎고... 로 이어지는 무한삽질(...)을 비유한 것이다.

한 마디로, 도구를 잘 다듬고 잘 배우는 것도 중요하지만 도가 지나치면 안 된다는 이야기다. 좀 불편하긴 해도 주어진 도구로 주어진 시간 내에 일을 끝낼 수 있다면 굳이 새로운 도구를 찾아나설 필요는 없다. 헌데 사람 마음이라는 게 그렇게 논리적으로만 동작하는 것은 아니라서 나도 가끔은 본래 목적과 상관 없는 엉뚱한 곳에 시간과 노력을 들이곤 한다. (바로 이전 글에서 이야기한 '쓸데없는 장인정신'이 이런 걸 두고 하는 말이다) 뭐... 내 나름대로는 그런 작은 삽질들이 인류 발전에 기여한다고 위로하기도 하지만;;¹

아무튼 하고 싶은 이야기는, 우리가 일상에서 흔히 쓰는 소프트웨어들도 잘 알고 쓰면 좋은 기능이 많다는 것과 바쁠 땐 어쩔 수 없더라도 자신이 쓰는 도구를 좀더 잘 사용할 수 있도록 하는 노력을 게을리 하지 않는 자세를 가졌으면 하는 것이다. 괜히 평생교육이란 말이 나온 게 아니지 않을까.

요즘 연구실에서 워크샵 논문을 하나 준비하고 있다. 얼핏 보면 그리 어렵지 않은 듯하면서도, 막상 실제로 구현하려면 꽤 생각해야 할 것이 있어서 생각보다 어려움을 겪고 있다. 이미 있는 코드 분량이 꽤 되고 리눅스 커널 드라이버도 함께 맞물려 돌아가는 프로그램인데다 성능도 민감하기 때문에 생각보다 고려해야 할 것이 많은 것이다.

문제는 추상화다. 나도 '추상화의 덫'에 걸리지 않도록 조심해야 한다는 사실 정도는 알고 있지만, '나중에 유지보수할 일'을 생각해서 코드를 짤 때 되도록이면 기본적인 추상화는 하려고 하는 편이다. 하지만 프로그래밍에 데드라인이 생기면서부터는 이것이 만만치 않은 일이 된다. 추상화는 잘 할수록 나중에 좋지만, 데드라인이 있는 일에서는 결국 어느 정도 수준까지만 하고 포기해야 하는데, 가끔 이럴 때 장인정신(...)이 발휘되면 곤란한 상황에 처한다.

이쪽 시스템 분야로 내공을 쌓으신 연구실 선배와 이야기하다보면 많이 느끼는 차이점이 있다. 프로그램의 어떤 부분에서 임의의 16-bit integer key로 table lookup을 해야 하는데 나는 이것을 hash table로 짜야 되나, 그럼 이걸 어떻게 간단하게(적은 노력으로) 짤 수 있을까, 라이브러리를 쓴다면 뭘 쓰는 게 좋을까, C++ 인터페이스를 쓰는 게 좋을까 그냥 C로 하는 게 좋을까, random dereference를 하면 그 자체가 lookup 오버헤드가 되지는 않을까 등등등을 꼬리에 꼬리를 물고 고민하는데, 선배들과 이야기해보니 간단하게 그 table에 들어가는 item 개수가 많아야 수백개 정도일 것이므로 그냥 array에 때려박고 index로 접근하게 한 다음 table 변경될 때도 일부만 잘 고치려 할 필요 없이 전체 다 재생성하도록 해보고 나중에 성능 보고 더 나은 방법을 쓸지 말지 결정하자는 결론이 나왔다.

그러니까 요는 처음부터 너무 미래의 걱정을 하지 말라는 이야기다. 일단 지금 필요한 수준에 맞게만 구현하고 문제가 있으면 그때 가서 고치자는 것. 이 이야기를 건축에 비교해볼 수 있다. 물리학이나 공학이 지금처럼 발전하기 전에는 (상징성이나 예술성이 목적인 경우를 제외하면) 같은 기능적 목표를 충족시키기 위해 지금보다 훨씬 많은 재료가 들어갔으나 기술이 발전할수록 점점 그것이 최소한 필요한 만큼만 쓰게 되는데---사실 건축뿐만 아니라 많은 분야가 그렇다---처음부터 프로그램을 모든 경우를 대비해서 비대하게 짤 필요 없이 필요한 만큼씩만 덧붙여나가는 것이 이와 비슷하다.

그나마 '얼핏 보기에 간단한' 정도의 일도 이런 고민을 하게 만드는데, '얼핏 보기에도 어려운' 정도의 일을 하려면 아직도 내공을 더 많이 쌓아야 할 것 같다. 프로그래밍이라는 게 항상 끊임없는 의사결정의 과정인지라 개발자 자신이 처한 사회적 맥락, 프로그램 코드가 속해있는 기술적 맥락 모두를 잘 꿰뚫어보지 않으면 여러 의미로 좋은 코드가 나오기가 정말 어렵다.

(살짝 덧붙이자면, 그래도 ipv4와 ipv6를 하나의 인터페이스로 통합하려고 했던 시도는 그나마 빨리 접어서(...) 다행이다. -0-)