하루가 지났지만. 포스팅.

1945년 9월 9일 Hopper는 하버드의 Mark II 컴퓨터의 내부에서 벌레(bug)가 컴퓨터 오작동을 일으키고 있다는 것을 발견하였고 이후로 기계나 소프트웨어에 에러나 논리적인 오류를 버그(bug)라고 부르고 있다.



버그가 만들어지는 이유는 대체로 사람이 원인이다. 어떤 프로그램을 작성함에 있어서 사람이 간과한 사실이나 혹은 예상하지 못한 동작에 의해서 만들어진다. 하지만 이는 사람이 아무리 애를 써도 해결할 수 없는 문제인데 그 이유는 소프트웨어의 크기는 아무리 간단한 프로그램이라도 방대한 양의 설계가 필요하고 수많은 요소들이 영향을 미치고 있기 때문이다. 때문에 버그를 찾아내는(디버그하는) 프로그램은 존재하지 않는다. 왜냐면 디버그를 위해서 검사해야할 요소들이 너무나 많기 때문이다. 마치 바둑을 두는 프로그램에 한계가 있는 것과 마찬가지로 일정 정도의 복잡도를 지닌 버그만을 찾을 수 있을 뿐이다.

앞으로도 버그는 문제가 될 것이다. 소프트웨어를 만드는 사람들은 버그를 줄이기 위해 코드(설계도)를 쓰는 스타일에 신경을 쓴다. 그리고 실수 할 가능성이 높은 습관을 고치는 일까지 한다. 개발의 순서나 개발 방법도 버그를 줄이기 위해 혹은 버그를 빠르게 고치기 위해서 바꾸기도 한다. 그 뿐 아니라 프로그램을 설계하는 설계 언어마저도 실제 설계와는 큰 관련이 없지만 버그를 찾아내는데 유용한 요소를 넣고 있다. 이렇게 버그를 고치기 위해서 노력하지만 버그는 끊임없이 생겨난다.


과연 버그를 완전히 해결할 수 있을까? 그렇지 않다. 이 주제에 어울리는지 모르겠지만 유명한 문제로 정지 문제(Halting problem)가 있다. 정지 문제는 "어떤 프로그램(계산)에게 입력값을 주면 그 프로그램이 계산을 계속할지 아니면 멈추게 될지 판단하라" 라는 단순한 의문이다. 즉 어떤 프로그램에 무한히 실행하게 될 버그가 존재하고 있는지 알 수 있을지를 판단할 수 있게 만든다. 하지만 이 문제는 이미 판단할 수 없다고 증명이 되어있다. 간단히 살펴보면,




앞으로 버그를 찾는 노력은 계속될 것이다. 오래전부터 프로그램을 설계하는 시간보다 버그를 고치는 시간이 더 길어졌다. 지금은 소프트웨어의 크기가 방대해지면서 버그가 없는 것을 보장할 수 없게 되었다. 이제는 거의 모든 소프트웨어가 배포 후에 버그를 고쳐나가고 있다. 버그는 논리적으로 반드시 찾아낼 수 있다는 것을 보장할 수 없지만 사람의 손에 의해 소프트웨어 버그를 찾는 것을 돕는 프로그램이 많이 나오고 있으며 이제 간단한 버그는 프로그램이 찾아서 도와줄 수 있다.


더 읽을거리:
[한글 위키: 소프트웨어 버그]
[한글 위키: 정지 문제]
[텀즈: 버그]
[정지 문제]