방어 코딩?

첫번째 회사에 근무할때 완전히 다른 파트를 담당하느라 바쁘긴 해도, 사수분이 내 코드의 리뷰를 이따금 해 주곤 했었다. 또 아이러니하게도 그런 리뷰를 받는 날에는 항상 시간에 좇겨 어쩔수없이 짜거나, 진퇴양난으로 인해 만들어진 자부심이라곤 눈꼽만큼도 남아있지 않은 슬픈 코드들이 항상 비류 대상이었고, 항상 부끄러운 배움의 시간이었다.

어쩌면 내가 울상이거나 한숨을 쉬거나 '이런 코드를 정말로 라이브시켜도 되나' 하는 표정이었을때 리뷰를 해주셨던게 아닐까 글을 쓰다보니그런 생각이 흘러간다.

아무튼 이러한 리뷰시간을 갖으면서, 나는 짧은 개발자 인생에서 처음듣는 단어가 있었는데 바로 방어코딩 이라고 그는 불렀다.

그당시 내 보수중인 코드는 spring java였었으며, expected value가 다를수 도 있었기 때문에, 또 내 개발 커리어의 경험에 따라 - 특히 그당시 javascript의 undef value 로 크게 혼이 난적이 있었기 때문에 - 나는 가지고오는 value나 params 를 검사부터 하는것을 지향했었다.

예컨데 이런 함수의 형태를 만들어야 한다면 :

private foo getFooValueFromBar ( Bar bar ) {
 return FooMaker(bar);
}

난 대게 이러한 방식으로 함수 안을 보강했었다.

foo myFoo = null;
if ( bar == null || bar == '' ) {
 throw new Error("givin param is null");
} else {
 myFoo = FooMaker(bar);
 if ( myFoo != null ) return myFoo;
 else throw new Error("returned foo is null");
}

난 아직도 이게 그렇게 틀린 코드라고 생각하지는 않는다.

사수 역시 동의했다. 예외를 모두 under control 하는점은 좋으나, 굳이 이런게 필요하지 않은 경우까지 모두 한다는것이 내 사수분의 의견이었다.

그의 주장은 이해할 수 있었다. 왜냐하면 그 당시 메인 프로젝트는 이미 수많은 코드들의 스파게티로 엉망인 상태였으며, 우리는 이 스파게티코드를 대대적으로 변경하는 v2.0 작업을 진행하기 전까지는 '최대한 덜 지저분하게 판을 벌려가며 새 기능을 넣을것' 이라는 둘만의 목표의식을 지나고 있었다. (하지만 잘 지켜지지는 못했다 적어도 난)


최근 내 여자친구의 사수가 방어코딩이라는 언급을 하며 코드를 소개한 적이 있었다.
그녀는 spring java를 담당하던 이전직장의 나와는 달리, javascript를 담당하는 포지션이었으며, 그녀의 사수는 최적화와 숏 코딩에 대한 상당한 지지와 자부심을 가진 자신감 넘치는 사수였다.

그는 반대로 방어코딩에 대하여 매우 긍정적이며, 오히려 더 세밀하게 해야한다는 취지의 주장을 했다( 적어도 그렇게 이해했다. 내가 들은 이야기는 아니니깐 말이다 ) 그 역시 외주를 통해 만든 말라비틀어진 스파게티 수준의 코드들로 surrounded되어, 매일을 히스테리성 발작을 보일정도로 괴로워하는 사람이었으며, 내 사수분과 같은 생각인 2.0까지만 이 코드들을 최대한 아름답게 보강하며, 이후에는 새 버전을 올리며 버리자는 주장을 했었다.

이러한 글을 쓰기전에 나는 어떻게 두명의 3년차 4년차 개발자 선배들이 각기 다른 의견을 제시하는지에 대해 생각을 해 봤었고, 무엇이 이들을 상반된 주장을 하게 되는가 하는 호기심에 정리를 해 보기 위해 쓴 단순한 글이다.

java개발자로 5년차가 되어가고 있던 그는, 한 스타트업의 모든 프로덕트를 혼자서 2년넘게 관리해 오며, 언제나 스스로를 낮추며 공부를 멈추지 않은 훌륭한 사수였으며,
javascript 개발자로 3년차를 보내고 있는 그는, 상당히 유능한 실력으로 인정받아, 그 역시 또 다른 스타트업의 프론트앤드를 총괄하고있는 팀장이며, 항상 자신감 넘치고, 배움에 대해서 즐거움을 느끼는 타입이다.

둘다 이전에 만들어진 '완성하기 급급한' 프로덕트들로 괴로워하며, 여유만 생긴다면 새 프로덕트로 갈아탈 기회만을 노리고 있는 사람들이었다.

그렇기에 난 개발환경과 언어에 따라 두 가지 상반된 의견이 나왔으리라 라는 추측을 하고있다.

개인적으로 느끼는 java와 javascript의 차이점중 하나로 이것을 드는데,
java는 예외발생에 대해서 매우 민감하게 반응을 하고 오류를 뱉고 죽어버리는 반면,
javascript는 예외가 발생해도 은근슬쩍 계속 작동이 되어버리기 떄문에, 실제 오류발생 부분에서 상당히 지난 뒤에, 완전히 코드가 꼬인뒤에에 모든게 폭발한 뒤에에 오류가 나타나버리는것이다.

그런이유로 java는 발생하는 예외에 대해 민감하기 때문에, 추가적으로 개발자가 공들여야 하는 예외사항의 범위가 작으나, javascript는 모든 예외사항을 다 고려해야하기 때문에, 후자가 더 방어코딩이 필요한것이 아닐까 한다.

그래서 방어코딩, 해야하는가 말아야 하는가의 결론은

언제나 그렇듯 '지금 내 상황에 맞게'  ...