개발을 하다보면 디버깅을 해야할 일이 생깁니다.
디버깅을 하는 방법이야 다양하겠지만, IDE와 통합된 디버거를 사용하면 작업 효율을 크게 올릴 수 있습니다.
스스로 짠 코드의 동작을 확인할 때도 디버거는 유용하지만, 특히 내가 작성하지 않은 코드를 탐색하며 어플리케이션의 상태를 추적할 때 디버거가 큰 도움이 됩니다.
Step into 버튼을 눌러서 조금씩 깊은 프레임으로 들어가고 있다보면, 낯선 코드의 조각들이 화면에 떠오릅니다. 깊은 바다로 다이빙을 하는 게 이런 느낌일까요?
얕은 프레임에는 비교적 익숙한 고수준(high level)의 코드가 있습니다. 햇빛이 닿아 산란하는 바다의 표층처럼 밝고 따뜻한 느낌입니다. 물론 고수준에서도 그동안 모르고 지냈던 새로운 모퉁이나 교차로를 만나게 되는 일도 있습니다만, 일반적으로는 조금씩 프레임의 깊이가 깊어질수록, 문제가 나기 전까지는 별로 들여다 볼 일이 없던 저수준(low level)의 코드가 나타납니다. 그동안 개발자가 들여다보지 않았지만 묵묵히 어플리케이션 코드를 지탱해오던 프레임워크와 라이브러리의 코드입니다. 느슨한 결합을 위해 인터페이스로 추상화된 코드가 아니라, 실제로 런타임에 의해 실행되는 구현체의 코드입니다. 심해처럼 햇빛과 사람의 눈으로부터는 멀리 떨어져있어도, 분명히 그곳에서 언제나 살고 있던 코드입니다. 그러고보면 전산학에서 ‘level’의 번역어로 물의 높이를 뜻하는 ‘수준(水準)’이라는 단어가 채택된 것도 참 적절한 것 같습니다.
때로 프레임 사이를 오가며 디버깅을 하다보면 코드에서 의외의 동작을 알게 되기도 하고, 디버거가 이끄는대로 돌아다니다가 멋진 설계를 발견하기도 합니다. 하지만 그런 반짝임에 눈이 멀어 디버깅의 목적을 잊어서는 안됩니다. 개발자가 디버깅 중에 찾고 있는 것은 어디까지나 버그의 원인입니다.
디버깅에 들이는 시간이 길어지면 길어질수록, 버그의 원인을 예상치 못한 곳에서 찾아내게 되는 경우가 많은 것 같습니다. 애초에 원인이 짐작가는 범위 안에 있었다면 디버깅에 긴 시간을 들일 일 자체가 없었을테니 어쩌면 당연한 일입니다.
찾아헤메던 버그의 원인을 의외의 장소에서 조우했을 때의 짜릿함은 개발의 중요한 즐거움 중 하나라고 생각합니다. 버그가 발생하는 시나리오에서 서사적인 면을 발견할 수 있다면 더 즐겁습니다. 잘 알고 있다고 믿어왔던 익숙한 구성요소(component)의 배신을 마주하는가 하면, 각 구성요소들이 아무 잘못 없이 자신의 책임을 다했을 뿐임에도 아주 특정한 조건에서는 각각의 구성요소가 결과적으로 조금씩 버그에 기여하기도 합니다. 이런 케이스를 분석할 때는 흥미진진한 범죄물을 보고 있는 기분도 듭니다.
오늘처럼 하루 종일 비가 오는 어두운 주말 밤이면 왠지 깊은 생각에 빠지게 됩니다. 말하자면 멀지 않은 과거의 사건들을 디버깅해보는 것입니다. 비가 내려서 가라앉는 공기와 침침한 하늘 때문에 깊은 프레임까지 단숨에 ‘step into’ 할 수 있습니다.