[패러디] 모듈 짜던 노인

0 | 1/s/e | 2012. 11. 28. 16:52
Posted by oveRock

페이스북에 올려 보았다가 반응이 좋길래 조금 손봐서 포스팅


벌써 사십여 년 전이다. 내가 IT회사에 취직한 지 얼마 안 돼서 의정부에 내려가 살 때다. 서울 왔다 가는 길에 청량리역으로 가기 위해 동대문에서 일단 전차(電車)를 내려야 했다.
동대문 맞은쪽 길 가에 앉아서 모듈을 짜서 파는 노인이 있었다. 프레임워크를 한 벌 사 가지고 가려고 짜 달라고 부탁을 했다. 값을 굉장히 비싸게 부르는 것 같았다. 좀 싸게 해 줄 수 없느냐고 했더니, 

"프레임워크 하나 가지고 값을 깎으려오? 비싸거든 다른 데가 사우."

대단히 무뚝뚝한 노인이었다. 더 깎지도 못하고 짜 달라고만 부탁했다.
그는 잠자코 열심히 짜고 있었다. 처음에는 빨리 짜는 것 같더니, 저물도록 이 TC를 돌려보고 저 TC를 볼려 보고 굼뜨기 시작하더니, 이내 마냥 늑장이다. 내가 보기에는 그만하면 잘 돌아가는데, 자꾸만 테스트만 하고 있다. 인제 다 됐으니 그냥 달라고 해도 못 들은 체한다. 차 시간이 바쁘니 빨리 달라고 해도 통 못 들은 체 대꾸가 없다. 점점 차 시간이 빠듯해 왔다. 갑갑하고 지루하고, 인제는 초조할 지경이다. 
더 짜지 아니해도 좋으니 그만 달라고 했더니, 화를 버럭 내며,

"끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥이 되나?"
하면서 오히려 야단이다. 나도 기가 막혀서,
"갑이 좋다는데 무얼 더 짠단 말이오? 노인장, 수퍼을이시구려. 차 시간이 없다니까……."
노인은
"다른 데 가 사우. 난 안 팔겠소." 하는 퉁명스런 대답이다.

지금까지 기다리고 있다가 그냥 갈 수도 없고, 차 시간은 어차피 늦은 것 같고 해서, 될 대로 되라고 체념(諦念)할 수밖에 없었다.
"그럼 마음대로 짜 보시오."
"글쎄, 재촉을 하면 점점 에러 나고 늦어진다니까. 코드란 제대로 짜야지, 테스트하다가 놓으면 되나?"
좀 누그러진 말투다.

이번에는 IDE를 숫제 닫아놓고 태연스럽게 브라우저를 열지 않는가? 나도 그만 지쳐 버려 구경꾼이 되고 말았다. 얼마 후에, 노인은 또 짜기 시작한다. 저러다가는 프레임워크는 너덜너덜해질 것만 같았다. 또, 얼마 후에 TC를 이리저리 돌려 보더니, 다 됐다고 내준다. 사실, 다 되기는 아까부터 다 되어 있던 프레임워크다.

차를 놓치고 다음 차로 가야 하는 나는 불쾌하기 짝이 없었다. 그 따위로 장사를 해 가지고 장사가 될 턱이 없다. 납기일 본위(本位)가 아니고 자기 본위다. 불친절(不親切)하고 무뚝뚝한 노인이다. 생각할수록 화가 났다.

그러다가 뒤를 돌아보니, 노인은 태연히 허리를 펴고 콘솔 터미널을 바라보고 있다. 그 때, 어딘지 모르게 노인다워 보이는, 그 바라보고 있는 옆 모습, 그리고 부드러운 눈매와 흰 수염에 내 마음은 약간 누그러졌다. 노인에 대한 멸시와 증오심도 조금은 덜해진 셈이다.

회사에 와서 프레임워크를 내놨더니, 사수는 잘 짰다고 야단이다. 기존에 쓰던 프레임워크보다 참 좋다는 것이다. 그러나 나는 전의 것이나 별로 다른 것 같지가 않았다. 그런데 사수의 설명을 들어 보면, API 세트가 너무 수직적이면  코드를 작성할 때 지나치게 abstract해지고, 같은 코드라도 이해하기가 힘이 들며, 너무 수평적이면 코드를 작성할 때 예외처리가 발생하고, 유지보수가 어려우며, 요렇게 꼭 알맞은 것은 좀처럼 만나기가 어렵다는 것이다. 나는 비로소 마음이 확 풀렸다. 그리고 그 노인에 대한 내 태도를 뉘우쳤다. 참으로 미안했다.

옛날부터 내려오는 클래스는, 입출력 포맷이 바뀌면 신규 메소드를 정의하고 polymorph하고 신규 메소드를 기존 메소드에 wrapping 처리하면 다시 동작해서 좀처럼 에러가 떨어지지 않는다. 그러나 요사이 클래스는, 한 번 메소드가 버려지기 시작하면 걷잡을 수가 없다. 예전에는 클래스에 메소드를 붙일 때, 잘 정의된 argument type을 나열해서 history를 정리한 뒤에 비로소 붙인다. 이것을 "documentation한다"고 한다.

알고리즘만 해도 그렇다. 옛날에는 비전 라이브러리를 사면 openCV는 공짜, 그보다 나은 것은 얼마의 값으로 구별했고, optimization한 것은 3배 이상 비쌌다. optimization이란, 로직이 간결하고 수행 성능이 좋도록 코드를 재설계한 것이다. 눈으로 보아서는 O(n^5)인지 O(n^10)인지 알 수가 없다. 말을 믿고 사는 것이다. 신용이다. 지금은 그런 말조차 없다. 남이 코드를 보지도 않는데 복잡도가 O(nlogn)이라고 할 리도 없고, 또한 말만 믿고 3배나 값을 더 줄 사람도 없다.

옛날 해커들은 납기는 납기요, 야근은 야근이지만, 코드를 만드는 그 순간만은 오직 훌륭한 코드를 을 만든다는 그것에만 열중했다. 그리고 스스로 보람을 느꼈다. 그렇게 순수하게 심혈(心血)을 기울여 공예(工藝) 코드를 만들어 냈다. 이 프레임워크도 그런 심정에서 만들었을 것이다. 나는 그 노인에 대해서 죄를 지은 것 같은 괴로움을 느꼈다. "그 따위로 해서 무슨 개발자를 해 먹는담." 하던 말은 "그런 노인이 나 같은 갑에게 멸시와 증오를 받는 세상에서 어떻게 아름다운 코드가 탄생할 수 있담." 하는 말로 바뀌어 졌다.

나는 그 노인을 찾아가 추탕에 탁주라도 대접하며 진심으로 사과해야겠다고 생각했다. 그래서 그 다음 일요일에 상경(上京)하는 길로 그 노인을 찾았다. 그러나 그 노인이 앉았던 자리에 노인은 와 있지 아니했다. 나는 그 노인이 앉았던 자리에 멍하니 서 있었다. 허전하고 서운했다. 내 마음은 사과드릴 길이 없어 안타까웠다. 콘솔 디스플레이를 바라다보았다. 푸른 창공으로 날아갈 듯한 바탕화면 끝으로 recycle bin 아이콘이 피어나고 있었다. 아, 그 때 그 노인이 저 아이콘을 보고 있었구나. 열심히 코드를 짜다가 유연히 터미널 끝의 아이콘을 바라보던 노인의 거룩한 모습이 떠올랐다.

오늘, 회사에 출근했더니 사수가 코드를 뜯고 있었다. 전에 레거시 코드를 라이브러리로 쿵쿵 포팅해서 돌리던 생각이 난다. 라이브러리를 구경한 지도 참 오래다. 요사이는 디버깅하는 소리도 들을 수가 없다. 애수(哀愁)를 자아내던 그 소리도 사라진 지 이미 오래다. 문득 사십여 년 전, 모듈 짜던 노인의 모습이 떠오른다.

댓글을 달아 주세요

블로그 이미지

oveRock

(life) = ∫(decision)dt

카테고리

분류 전체보기 (129)
Kaffa (13)
Muzik (18)
Skeptic (4)
Foto (10)
0 | 1 (16)
Etc... (68)