확실하다고 생각하는 것을 부수기

온갖 상상이 난무하고, 추측과 확신이 교차하는 작업이 디버깅이라고해도 과언이 아니다. 디버깅은 아는 것 만큼 혹은 조금 더 상상한 것 만큼만 해결 가능하고, 그 외의 것들은 모두 우연한 실수일 뿐이다. 어쩌다 문제를 해결했어도 그것은 실수로 해결한 것이리라. 잔인한가?

디버깅이야말로 책으로 보아왔던 지식이 살아나는 현장이고, 디버깅이야말로 책을 들여다보게 만드는 작업이다. 디버깅을 하면서 가장 중요한 자세 하나를 생각해보고자 한다.

디버깅의 가장 큰 적은 "그 부분은 문제없을텐데"라고 믿게되는 근거를 알 수 없는 자기확신이다. 만일 디버깅을 잘하고자한다면, 지금까지 확실하다고 생각했던 부분을 다시 한 번 보라.

프로그래머가 가져야할 가장 중요한 덕목 중에 하나는 논리적인 무결성과 실제 데이터의 무결성에 대한 차이를 알고 그것을 상황에 따라 적절히 펼치는 것이다. 누구나 프로그래머라면 프로그램의 무결성을 추구한다. 즉, 오류에 적절히 처리하는 루틴이 삽입된다. 그런데, 가끔 명령한 동작의 결과가 성공일 것이라는 맹신을 할 때가 있고, 그것은 논리적으로 아무 오류가 없을 것이라는 생각으로 슬쩍 넘어가게 된다. 그러나 실행시간에 실제 데이터가 그 동작을 보장할 수 없는 값으로 넘어 왔고, 여기에는 논리적으로 있을 수 없다는 것에서 오류처리를 하지 않았고, 이것 때문에 버그가 생기는 것이다.

물론 디버깅을 획일화할 생각은 없지만, 가장 도움이 되는 버그 퇴치자세를 논하기 위해 다른 상황은 잠시 무시하자. 그렇다면, 논리적 무결성과 실데이터의 무결성에 대한 차이는 무엇일까?

논리적으로 무결한 예는 이렇다.
정수를 입력받고, 이 값을 2로 나누면 짝수 아니면 홀수임을 알 수 있다.

하지만 다음은 논리적으로 무결하지 않다.
내가 지금 300바이트를 TCP/IP를 통해서 한번에 전송하였다. 그러면 수신쪽에서도 한 번 읽을 때 300바이트가 읽혀질것이다.

다음은 어떠한가?
두 개의 쓰레드가 돌아가는데, 한 쓰레드에서 스택에 생성된 자동변수 두개의 값을 바꾸기 위해 하나를 더 잡아서 임시 보관용으로 사용하면 두 개의 값을 바꿀 수 있다
스택은 쓰레드마다 고유한 것이고, 따라서 위 말은 아무런 문제가 없다. 논리적으로 아무런 문제가 없으니 이런 루틴은 설마 버그가 있었으랴하고 지나치는 것이 우리의 상식이다. 하지만, 좀더 염세적으로 생각해보자, 쓰레드는 다른 쓰레드의 스택에 접근할 수 있는 권한이 있다. 혹시 이전 작업이 같은 함수내의 자동변수에 대한 포인터가 다른 쓰레드에 넘어 갔고 그쪽에서 오버플로라도 일어났다면? 심각한 문제이다.

인생은 디버깅이다. 적절히 assert 뿌려가면서 사는 것이지.