. 노운 버그

앞에서 예를 든 덮어쓰기 모드와 캐럿의 문제처럼 개발자가 이미 알고 있는 버그를 알려진 버그(Known Bug)라고 하는데 애써 번역하지 말고 그냥 원주민 발음대로 노운 버그라고 하자. 이런 용어가 존재한다는 사실만 해도 무척 흥미롭다. 모든 버그를 발견하는 즉시즉시 해결해야 한다면 사실 알고 있는 버그란 있을 수 없다. 물론 모르는 버그는 어쩔 수 없이 존재하지만 말이다.

그래서 노운 버그를 정확하게 다시 정의한다면 알고 있지만 고치지 않는 버그라는 뜻이다. 아주 작은 프로젝트가 아닌 한, 일반적으로 한두 개쯤의 노운 버그는 반드시 존재한다. 노운 버그가 존재할 수 밖에 없는 이유가 몇 가지 있는데 어떤 경우인가 보자.

 

첫째로 효용보다 비용이 월등히 클 때이다. 여기서 비용이라는 것은 구체적으로 시간을 의미하며 유지, 보수의 어려움 등도 일종의 비용이라고 할 수 있다. 버그를 고쳐서 얻을 수 있는 개선 효과는 극히 미미한데 고치는 시간은 1년이 걸린다거나 고친 후에 코드가 2배 이상 복잡해진다면 현실적으로 이 버그를 고치기는 무척 어렵다. 버그를 고치다가 오히려 더 많은 버그를 양산할 위험도 배제할 수 없다.

두 번째로 장래에 고쳐질 예정이라면 당장 해결하지 않는 것이 더 낫다. 자료구조로 배열을 사용했는데 배열의 특수성으로 인해 사소한 문제가 발생했다고 하자. 그런데 지금은 배열을 사용하지만 장기적으로는 연결 리스트를 사용할 계획을 가지고 있다면 배열로 인한 사소한 버그를 지금 굳이 수정해야 할 필요가 없다. 자료구조가 바뀌면 자연히 해결될 문제이므로 알면서도 그냥 남겨 두게 되고 그래서 노운 버그가 된다.

무한 메모리관리 코드가 작성된 ApiEdit9 이전에는 64KB 이상의 텍스트를 편집할 수 없었다. 만약 이 상태에서 64KB이상의 텍스트를 붙여넣으면 ApiEdit는 즉시 사망한다. 이런 증상은 분명히 파악되었지만 수정할 계획이 있었기 때문에 그대로 둔 것이며 그래서 ApiEdit8까지 64KB 버퍼 제한은 노운 버그로 남아 있었다. 이외에 ApiEdit2에서 GetXPosOnLine 함수 이전에 상하이동시 한글 중간에 캐럿이 걸치는 것도 같은 이유의 노운 버그였다.

세 번째로 아주 특수한 환경에서만 재현되는 버그는 그냥 남겨둘 수 있다. 모든 윈도우즈 버전에서 제대로 동작하는데 윈도우즈 95 IE 3.1이 설치되어 있고 플러스팩이 깔려 있지 않고 램상주 백신이 실행중일 때만 증상이 나타난다면 이런 경우는 무시할 만하다. 또 그래픽 카드나 프린터 등의 장비가 특수할 때도 디바이스 드라이버와의 충돌이나 버그로 인해 증상이 나타나기도 한다.

네 번째로 기술적인 이유에 의해 노운 버그가 있을 수 있다. 문제와 증상은 알고 있는데 해결책을 몰라 노운 버그가 되는 경우인데 바람직하지 않지만 불가피하게 이렇게 되는 경우가 가끔 있다. 이 경우는 고치지 않는 버그라고 할 수는 없고 고치지 못하는 버그가 된다.

 

이런 이유 외에도 프로젝트 기간이 촉박한데다 더 큰 문제가 많아 우선 순위가 밀려 노운 버그가 되는 시간적인 이유도 있다. 또 개발 의뢰자가 치사하게 굴어 일부러 버그를 고쳐주지 않는 정치적인 이유가 있을 수도 있다. 농담인 것 같지만 현실 세계에서는 다양한 이유로 노운 버그가 존재할 수 밖에 없다.

버그를 해결 하기 어려운 상황이라면 굳이 애써 해결하려고 하지 말고 노운 버그로 그냥 남겨 두면 된다. 그렇다고 해서 아무 버그나 노운 버그로 남겨둘 수는 없는 노릇이고 최소한 다음 요건들은 만족되어야 남겨둘 만한 버그라 할 수 있다.

 

심각하지 않은 버그여야 한다. 어떤 경우라도 프로그램이 다운된다거나 리소스가 누출된다거나 해서는 안된다. 보안상의 결함이나 데이터 훼손 등의 버그도 노운 버그가 될 수 없다. 이런 치명적인 버그는 비용과 기술적 한계에 상관없이 수단 방법을 가리지 않고 반드시 수정해야 한다. 프로그램이 동작하지 않는데 그것을 노운 버그라고 우길 수는 없다. 사용자들이 버그를 목격하더라도 애교로 봐 줄 수 있는 정도여야 비로소 노운 버그라고 변명할 수 있다.

빈도가 지극히 낮아야 한다. 아무리 사소한 문제라도 하루에 수십 번씩 발생한다면 짜증이 날 수밖에 없다. 어쩌다가 아주 특수한 상황에서만 발생해야 하며 개발자가 자수하기 전에는 사용자들이 눈치챌 수 없는 정도여야 한다. 예를 들어 200년에 한 번 발생할 수 있는 정도의 확률이라면 노운 버그가 될 자격이 있다.

개발자는 노운 버그의 원인을 정확하게 파악하고 있어야 하며 이 버그로 인해 어떤 문제점이 있는지도 완전히 알고 있어야 한다. 모르고 있는 또 다른 문제가 발생할 가능성이 있다면 이 버그가 치명적인지 아닌지를 먼저 조사할 필요가 있다. 그렇지 않고서 불확실한 상태로 노운 버그로 남겨 두어서는 안된다.

 

지금 여러분들이 자주 사용하는 프로그램들은 대부분 노운 버그가 있으며 어떤 제품은 아예 설명서에 노운 버그 목록을 기재해놓기도 한다. 어떤 이유로라도 해결하지 않은 버그가 있다면 이것을 숨기는 것보다는 사용자에게 솔직히 알리는 것이 훨씬 더 양심적이며 사용자들의 신뢰를 잃지 않는 방법이 된다. 운영체제도 마찬가지로 노운 버그가 있으며 개발자들은 그 목록을 정확하게 파악하고 있을 것이다.

혹자는 노운 버그는 버그가 아니라고도 하는데 개발자가 알고 있다는 사실만으로도 그 버그는 문제가 되지 않는 것이다. 노운 버그는 당연히 있을 수 있는 것이므로 여러분들도 개발중에 골치 아픈 문제를 만나면 잠시 노운 버그로 남겨 놓도록 하자. 긴급하게 해결하려고 조급하게 굴 필요가 없으며 심지어는 노운 버그를 남겨둔 채로 제품을 릴리즈하는 경우도 있다. 단 어쨌든 문제가 되기는 하므로 철저하게 관리를 해야 하며 여력이 된다면 수시로 해결하도록 노력해야 한다.