불로코드
수많은 소프트웨어 엔지니어가 불로장생 코드를 고민했고, 엔지니어의 수만큼이나 다양한 약이 제조/유통되었으나, 그들의 기대 내지 믿음과는 달리 늙어 죽어가던 코드가 관짝을 깨고 요강을 부수며 여러 순진한 개발자들을 황홀경으로 떡실신시키는 기적은 일어나지 않았습니다. 가끔 공개 컨퍼런스에서 이런저런 신약(그게 생산성 도구였든 방법론이었든간에)에 대한 간증이 돌기도 했지만, 실상은 대개 문제가 되는 부분을 숨기고 일부 잘 동작하는 부분만 확대하여 보여주는 경우가 대부분입니다.
그럼에도 불구하고, 아직도 많은 개발자가 불로불사의 코드를 향한 꿈을 접지 않았습니다. 하루하루 돈을 버냐 쓰냐로 고민해야 하는 실무 프로젝트에서는 일정과 코드 품질 사이의 접경지대에서 종교전쟁이 일어나며, 상대적으로 돈의 논리에서 자유로운 아마추어 개발 그룹에서는 '이 변수를 부어 먹어야 되느냐 찍어 먹어야 되느냐' 따위의 예송논쟁이 가득합니다.
저의 꼬꼬마 개발자 시절의 일입니다. 팀에 배정받은지 한 달도 되지 않은 시점에 절 가르치던 사수는 이직을 결정하였고, 고객으로부터는 새로운 유형의 미들웨어 어댑터를 개발해 달라는 요청이 들어와 있음을 저에게 털어놓았습니다. 저에게 주어진 시간은 단 하루였죠. 다행히 사수로부터 넘겨받은 자바 클래스 중 현재 요구사항과 최대한 비슷하게 생긴 코드를 하나 발견했습니다. 전 남의 코드를 읽는 속도가 굉장히 느리기 때문에(부끄러운 일이지만 지금도 그렇습니다), 샘플 코드를 블럭 단위로 떠서 돌려 보고 읽는 작업을 반복했습니다. 그 결과, public static void main(String[] args) {} 안에 고객이 원하는 모든 로직이 들어간 기괴한 코드가 나오고 말았습니다.
몇달 뒤, 우연히 그 코드를 리뷰하게 된 새 사수가 엄청 한심하다는 표정을 지으며 '이렇게 짜면 어떻게 코드를 재활용할 것이며 고객 요구사항에 변경이 생기면 어떻게 대응할 거냐? 심지어 룰링 일부는 하드 코딩되어있지 않느냐?' 등을 지적했습니다. 그리곤 이틀인가? 사흘인가만에 드디어 자바스러운 아름다운 코드가 나오더군요! (뭐, 제 코드가 반나절짜리 코드였다는 건 여기서는 별로 중요하지 않은 거겠죠?)
이러한 새 사수의 우려는 며칠 뒤에 현실이 되었습니다! 고객이 갑자기 요구사항 변경을 요구하고 나선 겁니다. 뭐 변경이래 봐야 별로 크게 변할 건 없었습니다. 바뀐 건 단 하나, 전부죠 :-P
1대 1로만 통신하던 서버들은 순식간에 다대다 통신을 시작했으며, 그중 일부는 이제 텍스트가 아닌 DB에 써야 하고, 그럼에도 모든 입력은 여전히 애당초 텍스트 스트림이었습니다. 언제나 그랬듯이 이 모든 게 내일까지 끝나지 않으면 너도 쥬금 나도 쥬금이라는, 애정 어린 당부도 잊지 않았습니다. 사수는 지금 구조에서 말씀하신 변경 사항을 반영하려면 며칠 정도가 걸릴 것 같다. 이런 부탁을 왜 이제야 하느냐?라는 불만을 표시했습니다. 전 뭘 하고 있었을까요? 다시 반나절에 걸쳐서 새로운 public static void main을 만들었습니다. 그리고 전달했죠 :-P
각고의 노력에도 불구하고 코드의 수명이 길어지기는커녕 점점 더 짧아지는 건, 약의 문제가 아닙니다. 단지 현대의 요구사항이 미친 듯한 속도로 변덕을 부릴 뿐입니다. 코드의 사망선고는 뭔가 더 이상 손을 댈 수 없는 순간이 아니라, 코드가 사용자의 요구와 유리되는 순간에 떨어지는 법입니다. 그런데 그 요구사항에 좀 더 기민하게 대응하겠다고 도입한 소프트웨어 엔지니어링은, 꽤 많은 경우 잘못된 수요 예측과 맞물려 거꾸로 시너지를 일으킵니다. 완벽한 계획은 완벽하게 망가진다는 금언이 완벽하게 들어맞는 경우이지요.
그러므로 소프트웨어 엔지니어링이 여러분의 고객님을 (지금까지, 그리고 앞으로도) 티끌 한 점 없이 만족시키려면 둘 중 최소한 한 가지 요건을 충족해야 합니다. 여러분이 고객의 모든 요구사항을 다 예측하는 무릎팍도사가 되거나, 아니면 어떤 변덕에도 견뎌낼 수 있도록 완벽하게 말랑한 구조를 제안하는 겁니다. 하지만 그 중 하나라도 만족하는 당신이라면, 아마 지금 여기서 이따위 글이나 읽으며 시간을 보낼 만한 여유는 없을 겁니다. 아마도 엄청나게 잘 나가는 회사의 CTO가 되어, 하루 종일 전동 마사지 의자에 앉아 커밋되는 모든 소스를 검토하고 있겠죠 :-P 네! 한 마디로 너님들 수준에 그런 고수준의 엔지니어링은 불가능할 거라는 데 제 왼쪽 구슬을 걸겠습니다 ^^
소프트웨어 엔지니어링은 언젠가는 죽을 코드가 어디 아프거나 불편한데 없이 잘 살다 편히 가라고 먹는 건강보조제이지, 진시황이 찾아 헤매던 불로초가 아닙니다. 약의 오남용은 필히 부작용을 친구 삼아 데려옵니다. 소프트웨어 엔지니어링도 마찬가집니다.
