전산개론식 개발론이라고 들어 봤는가?

이 말인즉, 여러 개발자들에게 널리 알려진 개발 방식이고 다들 올바른 방식이라고 믿지만, 사실은 그 방식대로 개발하면 완전히 조지는(?) 개발 방식을 말한다. 너무나 많은 개발자들이 그 방식이 지금까지도 올바르다고 믿어왔기에 여기에 대해서 자칫 반론을 제기하면 몰매를 맞을 수도 있다. 그러나, 다수의 사람들이 옳다고 믿는 것 중에 사실은 전혀 그렇지 않는 경우가 매우 많다. 그중에 하나가 이  전산개론 개발 계획이다.

전산개론에 따르면 개발 계획을 수립할 때 다음과 같이 하라고 한다.

업무 분석 -> 설계 -> 코딩(개발) -> 테스트 -> 디버그 -> 납품

더 세분화하는 경우도 있겠지만 대부분 이 방식으로 개발 계획 기간을 세울 것이다. 그런데, 내 스스로 개발하면서도 그렇고, 타 개발업체의 개발 과정에 참여하였을때도 그랬지만, 개발 일정이 절대로 저런 식으로 진행되지 않는다. 저런 방식의 개발 계획은 계약금을 받아내기 위한 문서로 필요할 뿐이다. 실제 개발이 시작되는 순간에 가장 중요한 개념은 납기일 즉 데드라인 뿐이다. 그 이외의 모든 개발 계획 일정은 단순히 요식 행위이며 사실 종이 낭비에 더 가깝다. 그런데도 불구하고, 큰 개발 회사이든 작은 개발 회사이든 간에 천편일률적으로, "업무 분석 -> 설계 -> 코딩(개발) -> 테스트 -> 디버그 -> 납품" 방식의 개발 일정 관리를 하는 것을 보면 경이롭기 마저 하다.

저런 방식으로 개발 계획을 실제로 진행하면 실패할 확률이 거의 백프로이다. 사실 능력있는, 즉 납기일을 잘 맞추는 개발 팀장들은 제안서로 제출한 개발 일정과는 전혀 다른 일정으로 진행한다. 내말이 믿기지 않는다면 지금까지 본인이 참여한 프라젝트들의 일정을 면밀히 분석해보라. 저 전산개론식의 개발 계획이 얼마나 허구인지를 알게 될 것이다.

전산개론식의 개발 계획은 상당히 속빈 강정이지만, 오늘은 그 중 가장 잘못되게 이해되고 있는 디버그에 관해서 논해보려 한다.

전산개론식 개발 계획의 가장 큰 맹점은, 개발의 거의 마지막 단계에서 디버깅을 해야 한다고 믿게 만드는 것이다. 개발 마지막 단계에 디버깅을 하게 되면, 그 개발은 십중팔구 망할 가능성이 크다. 내 경험에 의하면 디버깅은 개발의 마지막 단계가 아니라 항상 주욱, 꾸준히 해야 한다는 것이다. 버그는 나중에 고치는 것이 아니라, 발견하는 즉시 고쳐야 한다. 특히 팀작업이라면 더욱 이 원칙을 지켜야 한다. 왜 그럴까? 다음은 버그를 발견 즉시 패치해야 하는 이유들이다.

--벌레(버그)는 종족 번식을 한다.

달리 말하면 방치된 버그는 또 다른 버그를 마구 생산해 낸다는 것이다. 개발 마지막 단계에서 100개의 버그를 발견하고 이를 디버그한다고 가정하자. 백개의 버그를 고치는 동안에 또 다른 버그가 나타나게 된다. 즉 버그를 고친답시고 수정한 코드 때문에 기존에 잘 동작하던 코드마저도 안돌아가게 한다는 것이다. 버그를 고치는 도중에 발생한 신종 버그들은 기존 버그보다 더 심각하다. 왜냐하면 기존 버그들 보다 훨씬 더 강력한 항생제(디버깅) 내성을 가지고 있을 뿐만 아니라, 엄페 능력이 더욱 뛰어나기 때문에 버그 발견이 훨씬 더 어렵다. 거짓말 같은가? 믿거나 말거나 실화이다.

--벌레 여럿이 뭉쳐서 희안한 큰 벌레를 만든다.

벌 한마리는 그다지 무섭지 않다. 그러나 백마리의 벌떼들이 내 주위에서 앵앵 댄다면 상당히 공포스러울 것이다. 방치된 버그들이 여럿 모이면 희안한 증상을 내는 버그를 만든다. 여러 버그들이 상호 반응하여 복합적으로 만들어내는 종합 버그 세트는 재현이 매우 어렵다. 디버그의 첫단계가 버그의 재현이다. 다시 말해서 그 버그가 정확히 어떤 경우에 발생하는지를 알아내는 것이다. 그런데 이런 종합 버그 세트는 재현이 무지 어렵다. 어떤 경우는 잘 동작하다가 어떤 경우 갑자기 에러가 뜨고 도무지 종잡을 수가 없다. 많은 개발자들이 황당해 하는 경우중 하나로, 자기 컴에서는 멀쩡히 잘 돌아가는 프로그램이, 왜 사용자의 컴에서만실행하면 오류가 발생하는지 그 원인을 알 수 없을 때이다.

--벌레는 똥을 싸고, 누군가는 그 똥을 밟게 된다.

파리는 유리창에 앉아서 똥을 싼다. 유리창에 있는 군데군데의 조그만 점들은 이러한 파리똥이다. 버그는 이런 더러운 똥을 아무데나 전파시킨다. "개발자 갑, 벌레 똥 밟다" 사건의 예를 들어 보자.

개발자 갑은 자신이 만든 코드가 제대로 동작하지 않음을 확인하고, 디버깅을 시작했다. 그런데 아무리 뒤져봐도 자신의 코드에서 잘못된 곳을 찾을 수가 없었다. 그러다 발견했다. 개발자 을이 만든 함수를 호출했었는데, 이 함수가 엉뚱한 값을 리턴한 것이 버그의 원인이었던 것이다. 결국, 개발자 갑은 을이 만든 똥(버그)를 밟았고 그것 때문에 상당시간 헛고생하였던 것이다. 개발자 갑은 자신이 소비한 시간이 무지 아깝고 열받았지만, 버그 없는 프로그램은 없다는 사실을 잘 알기 때문에, 개발자 을에게 그 버그를 통보해줬다. 그런데 개발자 을이 그 함수는 아무 문제가 없다고 바득바득 우긴다고 가정해보자. 아마도 개발자 갑은 개발자 을을 때려 죽이고 싶을것이다.

웃기지만 우리 업계에서 실제로 비일비재하게 벌어지는 일이다. 사실 나도 다른 개발자가 만든 함수를 신뢰하지 않는다 무조건 테스트 해보고 사용한다. 내가 만든 함수도 믿지 못하는 판에 어찌 남이 만든 함수를 믿을 수 있겠는가?

버그없는 프로그램은 없다. 그리고, 한꺼번에 모든 버그를 전부 발견할 수도 없다. 그러나 버그를 발견하고서도, 개발 일정이 바쁘다는 핑계로 나중에 이 버그들을 한꺼번에 고치자라고 맘 먹으면 개발 전체 일정을 절단낼 수 있음을 명심해야 한다.