버그의 원인

버그는 제품이 개발되면서 생기는 자연스러운 현상이다. 이 버그는 항상 존재할 수 있음을 항상 가슴 속에 자연스럽게 담아야 하며, 버그로 인해서 어떤 문제가 생기는 것이지, 어떻게 해야해야 하는 것인지를 잘 깨달아야 할 것이다.
버그는 어떻게 생기는 것일까?

1. 요구사항의 이해 부족
요구사항이라고 할 수 있고, 표준에 대해서 제대로 이해하지 못해서 문제가 생길 수 있다.
특히 디자이너가 디자인 기획을 하고 나서, 명확한 UI 네비게이션을 생각하지 못하고, 기획을 하다가 구현을 하고 나서 문제가 생긴 경우가 종종 있다.

UI 요구사항에서 문제가 생긴 경우가 있다. 윗쪽 화살표만 가지고도 채널 업, 볼륨 업, 네비게이션에 대한 윗쪽 방향인지 구현하다가 문제의 소지를 그 때서야 발견하고, 기획자체를 수정하는 일이 생긴 적이 있다.

또는 개인적으로 자주 하는 것인데, 표준 문서에 대한 잘못된 이해에서 버그가 생길 수 있다. 분명 A, B를 이용해서 C를 만들어야 한다. 이렇게 되어 있어 있으면, A,B,C,D를 구현해서 E를 사용하게 하는 인터페이스를 만들어서 주위 프로그래머들을 고생시킨 적이 있다.

개발하기 전에 여러 시나리오에 대해서 체크하고, 잘 모르면 상급자에게 물어서 확인하고 잘 넘어갈 수 있도록 해야한다.

2. 지식의 부족
언어의 특징 혹은 개발 플랫폼에서의 특수한 상황을 인식하지 못한 상태에서 일어날 수 있는 버그가 있다.

정상적인 종료가 안되거나, 확실하게 null 또는 deconstructor를 호출하지 않아서 메모리에 조금씩 조금씩 메모리가 쌓여서 시스템이 작동이 되지 않는 현상을 발견될 수 있다.

메모리 할당을 잘못해서 스택이 엉키는 경우가 존재할 수 있으며, 한번은 CLDC의 thread와 관련된 suspend/resume을 제대로 이해하지 못해서 꼬일 수 있으며, 비동기 이벤트에 대한 처리를 잘 못해서 시스템이 깨질 수도 있다.

언어자체에 대한 공부가 필요하며, 만든 이에게 interface를 잘 사용하고 있는지 확인하거나 interface문서를 보도록 해야한다.


3. 잘못된 환경설정 파일
코드는 완벽히 잘 되어 있는데, 환경 변수를 잘못 기입하여 혼동된 값을 저장하여 문제를 일으킬 수 있는 부분이 있다.

assert를 잘 이용하거나 로그를 꼭 찍는 일이 필요하다.


4. 사명감
버그는 사람을 피곤하게 한다.
책임감과 사명감을 가지고 제품의 완벽성을 추구하려고 하는 것이 좋다.

그리고, 관리자는 적당하게 버그가 크리티컬하지 않으면, 나름대로 협상을 통해서 가이드라인을 정해서 버그를 피해 갈 수 있는 방법을 고객에게 제시하는 것이 필요하다.
모든 자동화는 복잡성을 늘리는 것이므로, 어느 정도의 수준의 합리적인 타협은 필요하다.
그렇다고 해서, 대충대충 넘어가는 것은 아니며, 제품이 완벽해 가는 과정속에서 사명감을 가지고 책임을 다해 제품이 나올 수 있도록 개발자 스스로, 관리자가 독려해야 한다.