불 태워버렸어... 하얗게
| 고양이, 사진, 프로그래밍 | 2009.05.27 |
개발 중인 게임에 빌어먹을 악질 버그 하나 잡는다고
또 새벽 4시까지 달리다가 잤다.
난 프로그래밍을 시작한 이래로 무수히 많은 버그들을 처리해 왔다.
프로그램은 1%의 새 코드와 99%의 디버깅으로 이루어진다는 말이 진리로 느껴진다.
대부분의 버그는 쉽게 발견, 해결할 수 있는 것이지만 일부 그렇지 않은 버그도 있다.
이런 놈들은 몇 가지 속성이 있다.
짜증나는 케이스.
버그가 항상 발생하지 않을 때.
항상 발생하는 버그가 아니라 가끔씩 나는 버그면 오히려 곤란하다-_-;
버그를 치워버리려면 크게 두 과정을 거쳐야한다.
일단 어떨 때 생기는 버그인지 버그 코드의 위치를 파악하는 것이 우선,
버그를 일으키는 부분을 어떻게 고칠지 해결책을 강구하는 것은 나중이다.
근데 버그가 항상 발생하는 게 아니면 어떨 때 생기는 놈인지 감 잡기가 훨씬 어려워진다.
결국 버그는 "특정 상황"에서 발생하는 놈이라 그 특정 상황이 뭔지만 알아내면
그 상황 때마다 수행되는 코드를 알아냄으로써 버그 코드의 위치를 파악할 수 있다.
근데 분명 똑같은 상황으로 보이는데 가끔씩만 버그가 나고
대부분은 정상적으로 잘 수행된다면 이게 환장하는 거다-_-
계속 속을 파고 들어가면 결국 특정 상황으로 문제가 좁혀지긴 하지만
일단 "가끔씩 생기는 버그"로 보인다면 그렇게 문제를 좁히는데 드는 시간이
다른 버그를 해결할 때보다 훨씬 오래걸릴 것이란 전조이다.
또 한 가지 속성은 불확정성의 버그.
버그를 알아내려고 시도하는 순간 버그가 바뀐다.
하이젠버그의 불확정성 원리는
상태를 측정하려는 시도가 상태를 변하게 만들기 때문에 어떤 상태를 결정할 수 없다는 것이다.
이것도 참 프로그래머를 미치게 하는 케이스다.
뭔가 버그가 있다는 걸 느낄 수는 있다.
하지만 그 버그가 뭔지 알아내려고 하는 순간!
버그가 바뀌거나 심지어 사라지기까지-_- 한다!
... 그렇다고 그 버그를 알아내려는 시도를 접으면
그 순간 예전처럼 멀쩡히 버그가 되살아나서 또 그냥 둘 수는 없다.
이건 결국 버그를 추격하기 위한 각종 함수(로그 아웃풋, 셋팅 등)의
사이드 이펙트 때문에 생기는 문제다.
그냥 상태를 찍어보려고 100% 믿을 수 있는 함수를 콜한 것이라고 생각하기 때문에
그 행위에서 사이드 이펙트가 생길 것이라는 의심을 쉽게 하지 못한다.
이 경우엔 결국 믿는 그 함수 빼고 건들 곳 다 건들여보다가
"설마 이 자식이 문젠가!?"하면서 마지막에 발견하게 된다-_- 시발.
심지어 그냥 돌리면 멀쩡히 잘 생기던 버그(?)가 브레이크 포인트만 걸면
사라지는 경우도 있는데 이런 경우는 보통 멀티 쓰레드 코드에서 생기는 타이밍 문제이다.
쓰레드 쪽을 먼저 의심해볼만 함.
날 괴롭힌 지난 밤의 그 버그는 이 두 속성을 다 갖춘 놈이었다.
웬만큼 악랄한 버그에도 익숙해진 수퍼 프로그래머를 이렇게까지 괴롭히다니.
다 합치면 한 10시간은 쓰지 않았나 싶다-_-
범인은 훈련소에 간 친구 놈이 짠 내부처리 부분이었는데
겉으로 보이는 문제는 훨씬 멀리 있었기 때문에 비이이이잉 둘러서 겨우 찾아냈다.
휴.
누가 프로그래머가 뭐냐고 묻거든 이렇게 답해주시라.
손으로 해서 3시간이면 끝날 일을
10시간 동안 벌레 잡아가며 프로그램 만들어서
1초만에 하려는 사람이라고.
