재사용이라는 성배

"성배"는 단순히 종교의 문제를 벗어나 인디아나 존스나 트레져 헌터, 최근의 다빈치 코드에 이르기까지 영화나 소설에까지 흔히 소재로 체택되곤 한다. 성배는 예수가 최후의 만찬에 사용했다는 은으로 만든 잔을 뜻한다. 영화“다빈치 코드”의 저자는 성배는 인디아나 존스에서 나온것처럼 하나의 보물로서의 찻잔이 아니라 성배가 예수와 막달레나 사이에서 태어난 혈통을 가리킨다고 주장한다.

머 영화이야기를 하려는건 아니지만 IT업계에도 성배를 찾아헤매는 트레져 헌터처럼 끝없이 갈구하는 소재가 있다. 바로 "재사용"이다. 20년전의 객체지향 10년전의 패턴이나 CBD 그리고 그나마 최근인 프레임워크나 SOA에 이르기까지 주제에 상관없이 항상 그 논란의 핵심에는 "재사용"이라는 성배가 있었다.

사실 재사용이라는 개념은 소프트웨어라는 개념이 존재할때부터 파생된 오래된 말이다. 1950년 IBM 메인프레임 시대에 - 소프트웨어는 하드웨어에 딸려나오는 엑세서리 쯤으로 생각되던 그 시기에 이미 Share라는 공유 라이브러리를 제작하던 사용자 조직이 있었다.

갑자기 이 얘기를 왜 하냐면 오늘날의 재사용의 의미가 사실 매우 오래된 아이디어이며 현재의 재사용의 성공과 실패를 인식하는데 있어 아주 중요하기 때문이다.

앞서 말했듯 처음 재사용이라는 단어가 사용된건 1950년이며 이미 Ada라는 언어부터 구조적 프로그래밍이라는 패러다임이 이미 존재했다. 당시의 주류 언어이던 어셈블리어가 코드의 라인수가 점차 커짐에 따라 동일하거나 비슷한 코드를 함수와 라이브러리 단위로 묶어서 재사용의 시초라면 이후 SOA까지 재사용은 항상 그 중심에 있었다.

초기에 라이브러리 함수까지는 재사용에 있어서 그 찬란한 미래를 보장해 주는듯 했다. "바퀴를 재 발명할 필요는 없다"라는 구호를 가지고 객체지향이 나올때까지도 그 미래는 현실이 되는듯 했다. 하지만 CBD에서부터 먼가 삐걱거리는 조짐이 일어났다. 전병선씨가 그의 책에 상.상.한 CBD 미래는 10년전이나 지금이나 요원해 보인다.

작은 규모의 재사용이 아주 효과적이었다고 해서 대규모의 재사용도 충분히 효율적이라고 생각하는 것은 억지가 되버렸다. 규모의 문제는 무시해도 좋을만큼 단순한 문제가 아니었던 것이다. 어릴적에 난 과학 기술의 발전으로 40m의 크기가 된 울트라맨이나 마징기 제트 - 비록 그게 일본문화이더라도 - 만화를 보고 자랐다. 지금 보면 그 만화들은 만화라는 상상력을 벗기면 형편없는 오류를 저지르고 있다. 짧게 말하면 발의 평면은 2차원인데 부피가 3차원으로 자라면 ^2과 ^3의 차이만큼 발에는 추가적인 압력이 가해지고 어느 순간에는 그 차이가 견딜수 있는 수치를 넘어가게 된다. 예컨데 산양과 코끼리의 다리는 그 크기의 차이만큼이 아니라 그 부피만큼의 비율 이상이 유지되야 지상을 걸어다닐 수 있게된다. (발의 평면 크기가 ^2이 아니라 ^3으로 증가해야 되고 따라서 발의 부피는 ^3이 아니라 ^4가 되어야 한다.) 단순히 발의 크기뿐 아니라 들숨과 날숨의 문제로 인한 허파의 크기 등 수많은 문제가 있다.


이야기가 많이 빠졌지만 소규모 재사용과 대규모의 재사용은 전혀 비슷한 난이도가 아니었고 따라서 그 효율성도 달성하기 어렵다. 얼마나 어려운가 하면 O의 n승 만큼 어려워진다. 이는 단순히 가능 불가능의 문제가 아니라 효율성의 문제이기 때문이다. 일반적으로 공통 코드는 보통의 코드에 비해 3배의 노력이 든다는 것이 정설이다. 라이브러리 단위의 작은 코드일때는 이 정도도 효율적이라고 할 수 있지만 2배 정도의 긴 코드를 작성해야 할때 공통 코드는 단순히 6배가 아니라 9배 이상이라고 했을때는 문제는 전혀 달라지는 것이다.

전병선씨나 대규모 재사용의 지지자들은 이미 만들어 놓은 컴포넌트들을 조립하여 마치 레고블럭을 쌓는 방식이 프로그래밍의 미래라고 생각하지만 사실 그건 이룰수 없는 꿈과 같다고 생각한다.. 컴포넌트 지향의 성과가 없는 것은 아니지만 그보다 훨씬 더 빠르게 코드의 크기와 시간이 갈수록 다양해지는 소프트웨어의 요구사항들을 생각해 볼때 이는 자동차와 로켓의 속도 차이만큼 그 거리는 점점 멀어지고 있기 때문이다.