소프트웨어 개발 회사에서 흔하게 볼 수 있고 경험하게 되는 시나리오가 한가지 있습니다.

많은 노력과 시간을 투자하여 꽤 괜찮은 제품이 하나 개발된다. 이후 제품은 새로운 요구사항들과
기술을 추가하면서 version up을 해나가고 릴리즈이후 발견되는 결함을 수정하고 언어, 기반 라이브러리 등의
업그레이드에 따른 유지보수가 이루어진다. 시간이 지나면서 담당 개발자는 하나 둘씩 떠나거나 변경되어 새로운 
개발자가 투입되고 시스템이 커지고 복잡해질수록 투입되는 인력도 점점 증가한다.  

시스템 성능이나 안정성이 떨어지고 유지보수에 투입되는 노력과 시간이 많아지는데 점점 원인 파악이 잘 안되는 심각한
결함들이 생겨난다. 새로 맡은 개발자는 아무리봐도 잘 모르겠다고 하고 시니어 개발자나 고수를 동원하여 문제점을 분석시키면
그들도 확실하게 짚어내지는 못하지만 이런 저런 원인 분석과 이를 수정하느니 차라리 다시 개발하자는 의견을 주장한다.

이런저런 토론과 회의가 이어지고 고민에 찬 관리자에게 의욕적인 몇몇 개발자들이 몇 개월만 주면 재개발을 끝낼 수 있다는
주장과 설득이 이루어진다. 현재 상태로는 유지보수가 불가능하다고 하니 결국 재개발을 추진하게 된다. 
처음에 약속했던 몇 개월은 다시 몇 개월을 더하고 더하더니 이제는 거의 다 되어 조금만 시간을 주면 끝낼 수 있다는 사실을
알려온다. 이미 접기에도 돌아가기에도 너무 많이 와 버렸다. 관리자는 이번에는 꼭 완료하겠다는 다짐을 톡톡히 받아두고
개발을 진행시킨다. 많이 지치기는 했어도 부담감으로 날밤을 지새우면 그디어 재개발을 완료한다.

이전 제품보다 휠씬 나아진 성능과 기능을 갖춘 듯 보인다. 이제 신규 제품을 기반으로 새로운 기능들이 추가되어 나간다.
그리고 완료되지 못한 기능들을 손보고 결함을 고쳐나가기 시작한다. 그러나 시간이 지나면서 예전에 경험했던 시나리오를 
다시 반복하게 된다. 

무엇보다 이런 현상을 방지하려면 우선 개발자의 코드를 그대로 방치해서는 안됩니다. 팀장이나 관리자들은 코드는 관리하지
않고 눈에 보이는 화면과 문서를 통하여 관리하려는 경항이 있는데 이는 겉모습과 옷차림으로 건강을 확인하는 것과 같습니다.
몸 속 기관과 뼈, 근육, 혈관 상태 등을 살펴 보지 않고 겉모습으로만으로 건강을 판단하려고 하는 것과 마찬가지입니다.

따라서 개발자의 코드는 될 수 있는대로 자주 동료 검토를 통하여 서로의 코드를 검토해줄 수 있도록 해주는 것이 좋습니다.
이는 결함의 발견뿐만이 아니라 남의 나의 코드를 보기 때문에 의식적으로 코드의 가독성과 코드 품질에 신경을 쓰게
만들어주고 해당 개발자가 떠나더라도 코드를 이해하지 못하여 손을 쓸 수 없게 되는 낭패를 줄이게 됩니다.
냄새가 나는 코드는 그때 그때 개선을 해주는 것이 제품과 코드의 생명력을 높여줍니다. 다른 클래스와의 인터페이스는
그대로 두고 변수명, 범위, 로직을 이해하기 쉽도록 개선해 나갑니다. 그리고 개선한 내역은 코드와 같이 주석을 달아놓는다면
다음에 볼 때 왜 이렇게 고쳐는가를 알 수 있게 됩니다.

코드 검토와 더불어 이클립스와 같은 IDE 개발 도구를 공통으로 사용한다면 PMD,CheckStyle 같은 코드 검사 도구를
플러그인을 설정하여 코딩 표준이나 중복 등 주의할 룰을 설정해 놓으면 실시간으로 인스펙션을 수행하는 효과를 볼 수 있습니다.
오래된 기존 코드들을 검사해보면 중복 기능이 20% 이상인 경우가 많습니다. 중복 코드는 점점 유지보수를 어렵게 하여 나중에는
손쓸 수 없는 스파게티 코드로 만들어 버리고 맙니다.

이클립스 플러그인에 대한 소개 및 간단한 사용 방법을 ibm에서 "이클립스 플러인으로 코드 품질 높이기"에 소개해 놓았네요.
아울러 가급적 개발된 코드에 대하여 메소드별로 단위테스트 케이스를 함께 만들어 코드와 함께 관리한다면 결함을 예방하는
것뿐만 아니라 기능들이 추가되어 어디에서 문제점이 있는가를 확인할 때도 매우 유용합니다.
언어에 따라 여러 가지 오픈 소스 테스트 프레임워크이 나와있는데 자바는 JUnit, TestNG, php는 PHPUnit, C++은 CPPUnit 등이
많이 활용됩니다.
  
먼저 회사에서도 코드 검토와 단위테스트에 대한 효과를 경험해 보았는데 개발되고 수년이 지난 제품에서 원인을 발견하지
못하고 있을 때 해당 제품에 대하여 가장 복잡하고 문제점이 많고 최근에 만들어진 코드부터 코드 검토를 시작하면서 시간이
좀 지나고 난 뒤에 그 문제점이 없어진 것을 발견합니다. 수년을 땜빵 형식으로 유지보수를 해오는 동안 코드은 얽히고
섥힌 로직과 관계들로 인하여 결함은 1 + 1 = 2 가 아니라 수십에 해당하는 상승 작용을  만들기 때문에 사소한 결함들을
제거해주면서 원인이 파악되지 않았던 문제점이 해결되는 경우가 있습니다.

사실 코드의 품질을 개선하기 위해서는 내가 만드는 코드에 문제가 없다는 것을 전제로 노력하기 보다는 오히려 내가 만든
코드에는 문제가 있다는 것을 인정하고 이를 어떻게 신속하게 처리할 것인가를 고민할 때 좀 더 나은 결과를 만들 수 있습니다.
문제가 생기면 이를 어떻게 빨리 해결할 것인가에 초점을 두는 것이 발견 결함 수에 초점을 두는 것보다 효과적이라는 말입니다.

이전 직장에서 한 직원이 저에게 탠덤(Temdem)의 역설에 대하여 들려준 적이 있습니다.

"탠덤은 99.999%의 system availability를 보장하는 non-stop system을 만든 회사입니다. 99.999%의 system availability는 1년 동안 겨우 5분 내외의 down time만을 허용하는 것입니다. 시스템이 일단 꺼지면 PC조차도 5분은 걸려야 재부팅 된다는 것을 상기할 때, 탠덤의 non stop system은 그야말로 "절대" 꺼지지 않는 시스템이라는 것을 의미합니다. 이것이 기술적으로 가능할까요? 참으로 말 안 되는 목표인 것 같은 이 목표를 탠덤이라는 회사는 이루어냅니다. 그러한 탠덤의 탄생에는 창립자의 희한한 사고 방식의 전환이 핵심이 있었습니다. 탠덤의 창립자는 이렇게 생각했습니다. 

    "컴퓨터 안의 모든 부품은 고장 난다, 반드시"
    "오늘 안 고장 나면 내일, 내일이 아니면 1년 내에,
     그것도 아니면 수 년 내에 반드시! 고장 난다"

탠덤이 직접 메인보드 위의 IC까지 만드는 회사가 아님에도 불구하고 그런 것의 고장까지를 전부 커버하면서 99.999%의 up time을 달성하기 위해서 할 수 있는 일이 무엇이었을까요. 당연히 기술적으로는 모든 것을 이중화했습니다. cpu 2개, controller 2개, 보드 2개, 하드 2개, ... 전부 다 두 개. 두 개가 동시에 고장 나면 어떻게 합니까. 직관적으로 해결합니다. Self 진단기와 modem을 달아서 실시간으로 지구상 세 곳의 탠덤 고객센터 중 가장 가까운 곳으로 자동 보고가 됩니다. 첫 번째 것이 고장 나면 두 번째 것이 고장 나기 전에 A/S 요원을 보냅니다. A/S를 하기 위해 필요한 절차는 무엇일까요. 입사 후 30분 교육을 받은 정도의 신입 사원이 가방에 부품 한 개 가지고 가서 고객을 방문하여 탠덤 기계의 앞문 열고 고장 난 거 그냥 뽑고 (물론 계속 시스템 서비스 중입니다) 가져온 부품 꽂고 문닫는 것으로 끝입니다. A/S에 역시 30분도 걸립니다.

다른 벤더들은 어땠을까요. 자기 것이 제대로 동작하려면 HDD는 물론 에러가 없어야 하고 랜카드 당연 문제 없어야 통신이 되고... 일면 말 되는 것 같지만, 탠덤은 거꾸로 생각했습니다. HDD 에러 나도! 랜카드 에러 나도! 보드 에러 나도! CPU 불량 나도! 절대 안 서도록 하겠다. 자신들 시스템은 고장 안 나고 품질 좋다고 주장하는 다른 제품들은 장애 시 긴 down time과 어려움을 겪는 반면, 탠덤은 "우리 기계는 고장 납니다"라고 인정한 결과 역설적으로 서비스 장애를 일으키지 않습니다. 이것을 "탠덤의 역설"이라 합니다."

결함이 발견되고 문제점을 3분 이내에 해결하지 못하면 이것 역시 결함으로 보고 해결하자고 하였습니다. 개발자들에게서 흔하게 보게 되는 코드와 스펙의 불일치, 넓은 변수 영역, 부정확한 에러 메시지, 에러 핸들링 미처리, 객체 지향적 프로그램밍 부재...이런 것들이 스파게티 코드의 시작이 됩니다. 웬만큼 규모가 있는 시스템이나 제품에 결함이 전혀 없을 수는 없는 법이죠. 따라서 결함은 반드시 생기고 생긴 결함을 어떻게 빨리 처리할 것인가를 목표에 두고 코드 품질을 개선하는 것이 오히려 효과적인 방안이 될 수 있습니다.

코드 품질을 개선하기 위하여 다양한 실천가능한 방법들을 찾아서 시도해 보시기 바랍니다.