코딩후 기도하기

Posted on Tuesday, April 6, 2010.

오늘도 어김없이 세 시간여 디버깅으로 고생하였다.

일찍 들어가서 아이랑 놀거나 맛있는 것을 먹으며 유유로이 시간을 보내고 싶은 것이 사실인데, 왜 맛없는 회사식당밥을 먹고서 머리를 쥐어뜯으며 디버깅에 시간을 보내야 하는가. 그것은 많은 양의 코드가 “코딩후 기도하기"라는 접근자세로 만들어져 있기 때문이다. 그리고 그렇게 작성된 코드를 디버깅 하는 데에는 “디버깅후 기도하기"가 될 수 밖에 없기 때문이다.

코딩 후 기도를 하는 이유는 단순하다. 코드를 잘 모르기 때문이다. 잘 모른다고 비난해선 곤란하다. 사람은 원래 자신이 만들어 놓은 것도 시간이 지나면 이해하기 곤란해한다. 흔히 들어보거나 말하지 않았던가! “나 왕년엔 날렸었어.” 왕년에 반짝이는 머리로 작성해 놓은 로직/코드/Hack이 몇일, 몇달, 혹은 몇년 지나 약간이나마 노쇠해진 머리로는 따라가는데에 벅차게 되는 것이다. “오오, 내가 이런 (훌륭한) 코드를 만들어내다니.. 감탄이로세"를 외치는 것도 종종 보았다. 자기가 만든 것조차 이리되면 다른 사람이 만든 코드는 더 말해 무엇하랴. 다른 사람이 자신과 비슷한 능력, 혹은 비슷한 사고방식을 가지면 그나마 다행이로되, 많이 떨어지거나 아니면 많이 훌륭한 두뇌의 소유자인 경우는 더더욱 이해하는 것이 저 먼 별나라 이야기가 되어버린다. 많이 훌륭한, 천재의 코드를 보는 경우는 훨씬 더욱. 이해가 안되는 것이다. 천재의 코드는 그 답게 가독성을 희생하여 성능을 이끌어내는 경우도 많고, 범인의 경우 따라가기 어려울만한 여러 컨셉을 달필.. 이 아니라 달코드로 풀어내기 때문에, 그를 따라가다가 머리가 터질 것 같은 경우가 생긴다.

이러한 코드베이스에 기능을 추가하게 되는 경우 어떻게 해야 할 것인가. 당연히 최대한 공부를 한다. 웬만큼의 구조 및 각 함수의 기능도 모두 파악하였다. 그럼 이제 고치면 되는데, 가끔 가끔 왜 그런지 모르는 부분이 눈에 들어온다. 원래의 코드 작성자가 많은 생각을 해서 그렇겠지. “If it doesn’’t break, don’t fix it”.이라는 SE시간에 배운 경구를 되살리면서 최대한 원본을 살리도록 한다. 리팩토링이 뭔지도 알고 왜 좋은지도 아는데, 잘못 고치면 프로그래밍 로직이 바뀌어 버릴까 겁이 난다. 그래서 제대로 리팩토링 할 수도 없다. 최대한 그대로 둬야 한다. 왜냐, 완벽히는 모르기 때문에… 이리 하다보면 수천라인짜리 몬스터 함수가 쉽게 나타나고, 로직이 꼬이고 꼬이고 꼬여버린다. 알렉산더라면 칼로 다 잘라버리고 싶은, 그런 상태가 되어버리는 것이다. 그러나 다시 시작하는 것은 사실 최악의 선택중의 하나이다. 98~99%이상 코드도 이해하고 있고, 버그 수정도 상당히 많이 진척되어서 내재된 버그도 얼마 없을 것 같고… 즉 항상 “이 언덕만 넘어가면 저 너머에는 무지개가 있어"라는 생각에 꾸역꾸역 진행한다. .

그래서 기도한다. 코딩 후에 기도하게되고, 디버깅 후에 기도하게된다. 왜 그럴까? 그 1~2%를 모르기 때문이다. 그러면 코드에 완벽한 자신을 가질 수 없고, 그래서 기도하게 되는 것이다. 엔지니어링에서 기도라니! 허나, 자신이 짜 놓은 코드도 이해하기 어려워지는것이 인간이다. 완벽한 이해는 있을 수가 없다. 특히 팀으로 작업한다면 팀원들의 능력도 다들 다르기 때문에 더욱. 그러면 방안은 두가지이다. 

• 모듈화, 구조화된 설계
• 함수수준의 유닛테스트

둘 중 더 중요한 것을 고르라면 후자를 고르겠다. 소프트웨어 개발에 있어 기도하는 삶을 살지 않기 위해서는 절대적으로 후자이다.