나는 왜 디버깅을 못할까?
인프콘2024 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기를 보고 느낀 점을 정리한 글입니다.
1만 시간의 법칙의 진실
1만 시간의 법칙; 어떤 분야의 전문가가 되기 위해서는 1만 시간의 훈련이 필요하다는 법칙
1만 시간을 꾸준히 투자하면 누구라도 전문가가 될 수 있다는 이야기를 들어보았을 것이다. 그러나 이 법칙의 핵심은 '1만 시간'이 아니라 '훈련'에 있다. 의도적인 행동과 피드백을 통해 개선을 반복하는 것을 1만 시간을 한다면 어느 분야에서든 전문가가 될 수 있다는 것이다.
프로페셔널 프로그래머가 되려면?
'코드 작성'만 잘 한다고해서 전문가가 되는 것은 아니다. 개발자에게 있어서 일의 본질은 소프트웨어를 만들어 고객에게 제공하는 것. 소프트웨어 제작도 중요하지만 운영도 큰 몫이다. 그리고 운영의 큰 부분 중 하나는 '디버깅'이라고 생각한다. 사용자로부터 에러 문의가 들어오면, 빠르게 문제를 파악하고 해결해야 한다. 그러나 나는 디버깅을 잘 못한다. 에러 문의가 들어오면 심장이 두근두근. 전문가로 거듭나기 위해서 넘어야할 큰산이 바로 디버깅인 것이다.
결국 디버깅 마인드셋 강의에서 말하는 것을 한문장으로 정리하면 다음과 같다고 생각한다.
디버깅 실력을 향상시키기 위해서는
무작정 코드에 뛰어들 것이 아니라(시간을 투자하는 것이 아니라)
키보드에서 손을 떼고 생각해보는 시간(의도적인 훈련)이 필요하다.
나는 왜 디버깅을 못할까?
-
문제 정의를 하지 않는다.
일단 해당 문제가 발생한 코드로 가서 무작정 console.log를 찍어가며 문제를 파악할 때가 많았다.
-
코드를 수정하면서 문제를 파악한다.
코드를 직접 수정하면서 문제를 구체화하는데 운이 좋으면 빨리 해결할 수 있었지만 운이 나쁘면 하루종일 고생하기도 했다.
-
디버깅 도구를 제대로 활용하지 않는다.
js에도 debugger가 있는데 절대 활용하지 않았다.
알고리즘 문제를 풀 때에도 무조건 코드를 작성하려고 하지말고 생각을 먼저 해봐야한다.
그런데 나는 알고리즘 문제를 풀 때에도, 디버깅을 할 때에도 침착하게 앉아서 상황을 살펴보고, 깊이 생각해보는 과정이 전혀 없었던 것 같다.
문제 정의가 없으니 정상 동작에 대한 정의도 매우 단편적이고, 때로는 그런 해결이 사이드이펙트를 유발하기도 했다.
디버깅 과정 시각화
디버깅 고수 따라잡기
회사 동료들과 인프런 영상을 함께 보고 이야기를 나눴던 내용이다. 디버깅을 잘한다고 생각했던 분은 대략 위의 과정을 거치셨고, 그 중에서도 '사이드이펙트 조사'가 정말 중요하다고 말씀해주셨다. 처음 발견했던 단편적인 문제가 해결되었다고 끝이 아닌 것이다. 특히, 이 과정에 대해 회귀 테스트를 작성해놓으면 큰 도움이 되는 것 같다.
이 일련의 과정을 실천하기 위해서 디버깅 노트 템플릿을 만들어보았다.
디버깅 노트 템플릿
먼저 목표 시간을 정하고, 주어진 시간동안 무엇을 할 건지 목표를 세운다. 그 다음 내 생각을 노트에 적고, 정해진 시간이 되면 짧은 회고를 작성한다.
할 수 있다! 디버깅 YES I CAN!
실제로 이 노트 템플릿대로 디버깅을 해보았는데 생각보다 효과가 좋았다.
나의 첫 디버깅 노트
버그를 재현해보며 특이 동선을 발견했고, 그 동선에서 힌트를 얻어서 원인이 RTK Listener에서 업데이트 해주는 부분이라는 것을 발견했다. 평소 디버깅을 생각하면 머리가 깜깜해지고, 어느 순간 길을 잃는데 이 템플릿에 맞춰서 생각하니 그 과정들이 정리가되는 느낌이라 좋았다.
바로 훈련의 효과가 나타나는 건가...? 싶었다.
문제를 구체화 해보는 것에 대해서 긍정적인 경험이어서 앞으로도 이 템플릿을 활용해보려고 한다.
다음 버그 드루와
노트 없이도 자연스럽게 디버깅 마인드 셋을 갖추는 그날까지...!