다시는 안그럴께요...

Mozilla rebuts Firefox 2 bug reports

아이들이 잘못을 저지르곤 부모에게 비오는날 먼지날리게 맞으면서 하는 말이 "다시는 안그럴께요"일 것이다. 물론 대부분의 경우 몇번 더 저지르고는 그것을 고치기 전에 어른이 되어버려 할 필요가 없어지는게 대부분이긴 하다.

어플리케이션의 메이저 버전업의 초기에 보는 현상이 이와 비슷하다. 직전 버전의 마이너 업데이트에서 실컷 고쳤던 버그가 다시 나타나곤 한다. 비단 FF뿐만이 아니라 MS의 윈도우에서도 무려 몇년의 간격을 두고 똑같은 버그가 발견되고 Critical Security Patch라는 이름의 프로그램이 전송된다. 최근의 해커들은 메이저 업때는 기존 버전의 모든 해킹 방법들을 다시 테스트 해 본다. QA 담당자들은 왜 안해보나 몰라 @.@;

형상관리(Configuration Management) 혹은 버전관리에서 브랜치(Branch)를 사용하는 릴리징(Releasing) 과정을 가지는 공정(Process)을 사용하는 개발팀에서 흔히 볼 수 있는 현상이다. 그들은 얼핏 보기엔 형상관리가 매우 잘 일어나는 것 처럼 보이지만 각 릴리즈간에 동일한 코드에서 발생하는 동일한 코드에 대한 수정(Fix)을 필요한 모든 곳에 적용(Patch or Apply)하는 작업에서 문제가 생기는 것이다. 이것은 보통 새로운 것을 추구하는 개발자의 특성 때문이기도 하다. 현재 자신이 만들어 나가고 있는 버전을 새롭게 만드는 것만 신경을 쓰고 다른 쪽에서 만드는 과거 릴리즈의 마이너 업 버전이나 메이저 업 버전에 대해선 신경을 쓰지 않기 때문이다. 특히 메이저 업을 하는 경우 새로 추가되는 기능에만 99.9999999%(9-9) 신경을 쓰고 기존의 기능에 대해서는 눈길 한번 주지 않는다. 구 기능에 버그가 없는 지는 커녕 잘 동작하는지도 신경을 쓰지 않아 문제를 일으키기도 한다.

사실 TDD(Test Driven Development)에서는 개발자는 현재 개발할 때 그 기능에 대해 적절히 처리할 수 있다는 가정하에 기능을 만듬과 동시에 테스트를 수행하는 프로그램까지 같이 작성하게 한다. 그리고 시간이 흘러 기능의 존재조차 까먹게 되는 시점이 와도 해당 기능은 테스트 케이스에 대해 문제없이 돌게 만든다라는 의도라고 할 수도 있다. 허나 문제는 시간이 지나고 세상이 바뀌면 해당 모듈에 들어가는 인풋이 달라질 수도 있는데 테스트케이스는 변하지 않는다라는 점으로 인해 역시 한계는 생기게 된다.

현 시점에서는 일단 다시는 안그러겠다고 외쳤다면 반드시 QA의 테스트목록에 넣고 메이저 업이 되든 기존 코드를 버리고 새로 만들었든 그 약속을 지키는 수밖에는 없을 것이다.


개인적으로는 "결함허용모델"을 선호한다. 이세상에 버그 없는 프로그램은 존재할 수 없고 심지어 프로그래머의 등급에 따라 10줄에서 아무리 잘하는 프로그래머 조차 한 화면이 넘어가는 코드라면 50% 이상의 존재가능성이 있다고 본다. 뭐 이 모델 이야기는 좀더 정형화 되면 꺼내기로 하고....

잘짜자!