크롬망간이 글 쓰는 공간

회사의 주인은 주주이지만 소속감을 느끼는 것은 직원이듯, 회사에서 작성한 코드의 주인은 회사이지만 그 코드에 애착을 느끼는 것은 개발자이다. 특히나 그 코드가 30대의 내 인생의 2년 3개월을 오롯이 바쳐서 만든 코드라면 더더욱.

개발자로 일을 하다 보면 코드 전달이라는 걸 하게 될 때가 있다. 일종의 인수인계인데, 최신 코드를 설명문과 함께 전달하고 필요에 따라 코드 설명회를 여는 과정이다. 코드를 전달받는 대상은 회사 내부의 다른 직원일 수도 있고 아니면 협력사가 될 수도 있다. 내가 얼마나 오랫동안 정성을 쏟아서 만든 코드이든 나에게는 가타부타할 권리가 없다. 회사에서 작성한 모든 코드는 회사의 것이고, 그걸 다 알고 계약서에 서명을 하고 입사했으니. 모든 절차를 마치고 태연한 척 '싱숭생숭해 할 필요 없어. 우리는 다 프로잖아?' 하는 허세 가득한 마음을 속으로 먹어 주면 모든 과정은 끝이 나게 된다.

그렇지만, 조선 시대에 유씨 부인이 바늘이 부러지자 슬픔을 금할 길이 없어 조침문(弔針文)을 지었다면, 나도 이제 내 손을 떠나가게 된 코드를 위해 글 한 토막은 쓸 수 있지 않을까. 유씨 부인은 17년 간 사용했던 바늘이 부러지는 순간 정신이 아득하고 마음을 빻아 내는 듯 해서 기색 혼절하였다고 하는데, 나야 그 정도는 아니지만 어쨌든 무언가 마음 속이 허한 것은 막을 길이 없다.

하지만 보내줄 땐 보내주어야 한다. 언제가 붙잡아야 할 때이고 언제가 보내주어야 할 때인지 사람은 본능적으로 안다. 보내주어야 할 때는 아쉬움이나 미련이 없게 충분히 슬퍼하고 애타한 뒤 깔끔하게 보내주어야 한다. 유씨 부인도 부러진 바늘을 대장간에 가져가면 왜 못 고치겠냐마는 '동네 장인에게 때이련들 어찌 능히 때일손가' 라며 마음을 정리하고 바늘을 고이 보내주었듯, 나도 이젠 코드를 보내줄 때가 되었다. 기실 바늘이나 코드는 자기가 어떻게 되었는지도 모른다. 괜히 바늘 주인이, 코드 개발자가 슬퍼하는 것이지. 아직 못다한 리팩토링이, 마음에 들지 않아서 바꾸고 싶었던 변수명이, 별도 브랜치에 작성까지 했으나 결국 메인에 머지되지 못한 커밋이 머릿속에, 그리고 마음 속에 자꾸 맴돈다. 이럴 줄 알았으면 수많은 코드 사이 어딘가에 이스터 에그 하나쯤 남겨놓을걸, 하는 큰 허전함을 뒤로 하고 마지막으로 아쉬우니 괜히 git pull 한 번 하고 너를 보낼게. 가서도 잘 컴파일되고 지내야 한다. 라이브러리 의존성 안 맞는다고 심술내면서 에러 내뱉지 말고. 건강히 착하게 잘 지내렴. 나는 이제 exit 할게. 안녕.

십여 년 전, 스크립트 언어를 배워야 할 일이 생겼을 때 비주류 좋아하는 성격 탓에 당시 한창 뜨던 중인 파이썬을 안 하고 슬슬 지기 시작하던 펄을 공부했었다. C로 - 그러고보니 C++도 아니고 - 문자열 처리 코드 짜고 있던 나에게 펄은 신세계였다. 요즘은 당연하게 여겨지는 것이지만 배열 마지막 원소를 arr[-1] 같이 -1이라는 인덱스로 접근할 수 있는 것도 C에서는 상상도 못 했던 일이었다.

펄은 참 재미있는 언어였다. 한국어로 치자면 "거시기"에 해당되는 변수가 자동으로 존재한다. $_ 라는 변수인데, 그 덕에 코드를 듬성듬성 짤 수 있었다. 다른 언어에서는 명확하게 변수와 값을 지정해주었어야 할 상황에서 펄은 "거시기" 변수만 불러와 보면 얼추 필요한 값이 들어있었기 때문에 변수를 생략하는 것이 가능했다. 그리고 if문과 함께 unless 문도 있었다. Unless 문의 작동방식은 if문의 정반대. 즉 if (true)는 unless (false)와 같고... 이런 조건문을 겹쳐서 if ( unless ( if ( true ) ) ) 같은 식으로 볼썽사나운 코드를 짜는 것도 가능했다.

물론 이런 코딩이 가능하다 보니 남이 짠 펄 코드를 이해하는 건 정말 어렵고 어쩔때는 내가 예전에 짠 펄 코드도 이해가 안 가기도 했다. 그래서 펄 사용자가 많이 떨어져 나가기도 했고. 이런 펄의 특성은 "어떤 일을 하는 데에는 하나 이상의 길이 있다 (There's more than one way to do it, TMTOWTDI)" 라는 펄의 슬로건에 잘 나타나 있다. 펄 코드에는 개발자의 개성이 원없이 묻어난다. 어쨌든 나는 펄이 참 좋았고, 펄은 내 석사 연구의 꽤 많은 부분과 함께 했다.

펄과 완전 반대편에 있는 언어가 바로 파이썬이다. 파이썬에서 import this를 치면 파이썬의 철학이 죽 나오는데 그 중에 이런 말이 있다. "어떤 작업을 하기 위한 하나의, 되도록이면 단 하나의 자명한 방법이 존재한다. (There should be one-- and preferably only one --obvious way to do it.)" 그래서 파이썬은 띄어쓰기를 몇 칸으로 할 것인지까지도 한번 정하면 끝까지 지켜야 한다. 펄은? 펄 사용자들끼리 신나서 자주 하는 게 어떻게 하면 한 줄 안에 코드를 잘 구겨넣을까 하는 일이다.

이런 면에서 여러모로 펄은 한국어(와 일본어)를, 파이썬은 영어를 닮았다. 한국어에서는 온갖 생략이 가능하다. "사랑해" 라고 하면 내가 너를 사랑한다는 말인 줄 다 안다. 영어에서는 "Love" 라고 하면 못 알아듣기 때문에 단 둘이 있어도 굳이 "I love you" 라고, I가 you를 love한다고 다 꼬치꼬치 말해줘야 한다. 우리는 사과를 먹었으면 됐는데 영어에서는 굳이 사과를 한 개 (an apple) 먹었는지 두 개 이상 (apples) 먹었는지를 말해줘야 한다. 영화 황산벌에 나오는 계백 장군의 대사인 "그러니께 이번 여그 황산벌 전투에서 우리의 전략 전술적인 거시기는, 한 마디로 뭐시기 할 때꺼정 갑옷을 거시기한다, 바로 요거여. 알겄제?" 는 영어로는 말이 안 되고, 번역해 봐야 억지스럽다.

이런 다양성, 다의성은 인간의 언어에서는 언어를 풍요롭게 하고 문학의 비옥한 토양이 되는 존재이지만 프로그래밍 언어에서는 그다지 환영받지 못한다. 프로그래밍에서는 간단함과 명료함이 미덕이다. 그래서 날이 갈수록 파이썬 사용자는 많아지고 펄 사용자는 줄어만 간다.

예전, 대략 버전 관리 시스템으로 git이 아니라 cvs나 svn을 쓰던 때, 수많은 개발자들의 땀과 눈물이 서려있을 Visual C++ 6.0이 현역이었을 때, 간혹 3.5인치 디스켓 드라이브를 볼 수 있었을 때, 안드로이드는 나왔는데 안드로이드 스튜디오는 없어서 이클립스로 앱 만들던 때, 도스에서 터보C를 쓰던 때의 코딩은 참 자유로웠다. 참조할 수 있는 자료가 제한되어 있으니 다 개발자가 어떻게든 직접 해야 했고, 그러다보면 좀 삐그덕대더라도 분명 내 손에서 나왔다고 자부할 수 있는 프로그램이 생기곤 했다. 홈페이지도 메모장에 직접 html 코드를 쳐 가면서 만들곤 했지.

요즘은 컴퓨터 프로그램이 거대해지면서 많은 부분이 규격화되었다. 이미 남이 만들어놓은 코드를 "라이브러리"라는 이름으로 잘 가져다가 쓰는 게 중요한 시대가 되었다. 예전처럼 내가 다 하려다가는 "왜 바퀴를 재발명하고 있냐?" 라는 핀잔을 듣기 일쑤다. 깃허브에서 여러 코드를 받아오고 스택 오버플로우에서 이것저것 찾아서 어떻게 하다 보면 금세 프로그램 하나를 뚝딱 만들 수 있다. 요즘 간단한 스마트폰 앱은 파워포인트 만들듯이 마우스로도 만들 수 있고. 그런데 그렇게 해서 나온 결과물을 보고 있노라면 마음 속 한 구석이 왠지 허전하다. '이 프로그램에서 내가 만든 부분이 도대체 뭐지?' 하는 생각과 함께.

펄을 마지막으로 써 본 지도 거의 10년이 다 되어 간다. 옛 생각이 나서 인터넷에서 펄을 검색해 보니 5년 안에 사용자가 사라질 언어 중 하나로 펄이 꼽혀 있었다. 바퀴를 재발명하던 때가 그립다. 스택 오버플로우 없이 프로그램을 짜던 때가 그립다. 괜히 커맨드 창에서 perl을 실행시키고 이것저것 눌러보다가 창을 닫았다. 기분이 참 $_ 한 오늘이다.