본문으로 건너뛰기

나는 왜 디버깅을 못할까?

· 약 5분
Sewon Kim
SW Engineer @ Neurocle

1만 시간의 법칙은 틀렸다

1만 시간의 법칙; 어떤 분야의 전문가가 되기 위해서는 1만 시간의 훈련이 필요하다는 법칙

1만 시간을 꾸준히 투자하면 누구라도 특정 분야의 전문가가 될 수 있다는 이야기를 학생때부터 자주 들어왔다. 그러나 이 법칙은 틀렸다. 1만 시간을 주구장창 한다고 전문가 수준에 오를 수는 없다. 핵심은 '1만 시간'이 아니라 '훈련'에 있기 때문이다. 의도적인 행동과 피드백을 통해 개선을 반복하는 것을 꾸준히 해야 전문가가 된다.

프로페셔널 프로그래머가 되려면?

코드 작성을 잘한다고, 특정 기술을 잘 안다고해서 전문가가 되는 것은 아니다. 개발자는 소프트웨어를 만들어 고객에게 제공하는 사람이고, 소프트웨어 제작뿐만 아니라 운영까지 잘 해야한다.

디버깅을 잘 해야 프로!

소프트웨어 운영의 큰 부분 중 하나는 '디버깅'이라고 생각한다. 버그가 리포트되면, 빠르게 문제를 파악하고 해결해야 한다. 그러나 나는 디버깅을 잘 못한다. 에러 문의가 들어오면 긴장감에 심장이 두근두근 거리고, 허둥지둥 헤매기 일쑤였다. 나에게 있어서 전문가로 거듭나기 위해서 넘어야 할 큰 산은 디버깅이었다.

디버깅 마인드셋

인프콘 강연의 핵심은 다음과 같다.

디버깅 실력을 향상시키기 위해서는 
무작정 코드에 뛰어들 것이 아니라(시간을 투자하는 것이 아니라)
키보드에서 손을 떼고 생각해보는 시간(의도적인 훈련)이 필요하다.

그렇다면 나는 왜 디버깅을 못할까?

강의를 듣다보니 내가 디버깅 마인드셋이 없었다는 사실을 깨달았다. 디버깅을 잘 못하는 이유는 다음과 같다.

  1. 문제 정의를 하지 않는다.

    일단 해당 문제가 발생한 코드로 가서 무작정 console.log를 찍어가며 문제를 파악할 때가 많았다.

  2. 코드를 수정하면서 문제를 파악한다.

    코드를 직접 수정하면서 문제를 구체화하는데 운이 좋으면 빨리 해결할 수 있었지만 운이 나쁘면 하루종일 고생하기도 했다.

  3. 디버깅 도구를 제대로 활용하지 않는다.

    js에도 debugger가 있는데 절대 활용하지 않았다.

알고리즘 문제를 풀 때에도 무조건 코드를 작성하려고 하지말고 생각을 먼저 해봐야한다.
그런데 나는 알고리즘 문제를 풀 때에도, 디버깅을 할 때에도 침착하게 앉아서 상황을 살펴보고, 깊이 생각해보는 과정이 전혀 없었던 것 같다. 문제 정의가 없으니 정상 동작에 대한 정의도 매우 단편적이고, 때로는 그런 해결이 사이드이펙트를 유발하기도 했다.

디버깅 과정 시각화

디버깅 과정 시각화


디버깅 고수 따라잡기

회사 동료들과 인프런 영상을 함께 보고 이야기를 나눴던 내용이다. 디버깅을 잘한다고 생각했던 분은 대략 위의 과정을 거치셨고, 그 중에서도 '사이드이펙트 조사'가 정말 중요하다고 말씀해주셨다. 처음 발견했던 단편적인 문제가 해결되었다고 끝이 아닌 것이다. 특히, 이 과정에 대해 회귀 테스트를 작성해놓으면 큰 도움이 되는 것 같다.

이 일련의 과정을 실천하기 위해서 디버깅 노트 템플릿을 만들어보았다.

디버깅 노트 템플릿

디버깅 노트 템플릿

먼저 목표 시간을 정하고, 주어진 시간동안 무엇을 할 건지 목표를 세운다. 그 다음 내 생각을 노트에 적고, 정해진 시간이 되면 짧은 회고를 작성한다.


할 수 있다! 디버깅 YES I CAN!

실제로 이 노트 템플릿대로 디버깅을 해보았는데 생각보다 효과가 좋았다.

나의 첫 디버깅 노트

나의 첫 디버깅 노트

버그를 재현해보며 특이 동선을 발견했고, 그 동선에서 힌트를 얻어서 원인이 RTK Listener에서 업데이트 해주는 부분이라는 것을 발견했다. 평소 디버깅을 생각하면 머리가 깜깜해지고, 어느 순간 길을 잃는데 이 템플릿에 맞춰서 생각하니 그 과정들이 정리가되는 느낌이라 좋았다.

바로 훈련의 효과가 나타나는 건가...? 싶었다. 문제를 구체화 해보는 것에 대해서 긍정적인 경험이어서 앞으로도 이 템플릿을 활용해보려고 한다. 다음 버그 드루와

노트 없이도 자연스럽게 디버깅 마인드 셋을 갖추는 그날까지...!