* 해당 글은 NEXTSTEP의 이펙티브 디버깅 2기 강의를 듣고 일부 정리한 내용과 느낀 점입니다.
런타임 중 에러가 났을 때 어떻게 해결하곤 하시나요? 또한, 어떤 과정으로 문제를 해결할 수 있어야 할까요?
맞닥뜨리는 수많은 문제에 대해 해결하고 그 경험을 온전히 내 것으로 만들 수 있다면 성장에 있어 더없이 소중한 기회일 것이라고 생각했습니다. 그렇게 이펙티브 디버깅 강의를 수강 신청하게 되었고, 그 내용을 남겨보고자 합니다 :D
내용을 살펴보기 전, 디버깅할 때 어떤 단계를 거치는지에 대해 행동들을 먼저 몇 가지 작성해본 뒤, 비교하며 읽으시는 것을 추천드립니다..!
아래는 제가 작성했던 예시입니다.
- 에러 메세지 확인, 내용과 에러 경로 상세하게 살펴보기
- 에러에 대한 구글링
- 콘솔 로그로 데이터 확인
- 여러가지 해결 방법을 작성 후 하나씩 실천
참고하시어 작성에 도움이 되셨으면 좋겠습니다 😊
.
.
.
.
.
'잘' 하는 사람들의 디버깅 🖐️
원인 분석 5단계 프레임워크
디버깅을 잘하는 사람들에게 디버깅 할 때 하는 행동들을 3개 ~ 5개 그려보고,
그 중 잘 하는 사람과 못 하는 사람의 차이가 큰 게 무엇인지 골라 아래의 원인 분석 5단계의 프레임워크가 만들어지게 되었습니다.
1. 문제 정의
첫번째 단계는 문제를 정의하는 단계입니다.
문제 상황을 한 두 문장으로 작성합니다.
2. 올바른 동작 정의
정상적인 동작이라면, 어떤 결과가 나와야 할 지 작성합니다.
테스트 코드를 작성할 때 사용되곤 하는 given / when / then 형식으로 기술하면 좋습니다.
(문장의 깔끔함에 신경 쓸 필요는 없습니다.)
올바른 동작을 명확히 정의할 수 없다면 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집하도록 합니다.
올바른 동작을 정의할 수 없다면 문제를 제대로 해결하는 것도 불가능합니다.
3. 최소 재현 환경 구축하며 관찰
문제 발생 시점을 정확히 확인하고, 내가 직접 재현하기 위해 노력합니다.
문제가 있는 부분을 격리시키고 재현 과정에서 생기는 일들을 관찰하며 파악합니다.
에러가 발생하는 코드를 찾는 것 외에도 슬랙 메세지 혹은 운영 환경 등 모두 고려하여 최소화합니다.
4. 차이를 발생시키는 다양한 원인 탐색
이 단계가 바로 핵심입니다.
해당 에러에 대해 구글링을 하는 등 당장 손을 바쁘게 움직이기 보다는 머릿속에서 생각을 팽팽하게 하여 문제의 원인에 대한 목록을 작성합니다.
필요한 로직의 유무, 로직의 구현 상태, 로직의 위치, 개발과 운영 환경의 차이, api 의 구현 상태, 데이터 값의 유무와 값의 상태 등 문제 목록을 끝없이 작성해봅니다. 더이상 떠오르지 않는다면 chatGPT 의 도움을 받는 것도 하나의 방법일 수 있습니다.
하지만 전부 작성해주기를 바라는 것보다 '나는 ~~ 와 같은 목록을 작성하였는데, 어떤 것들이 더 있을까?' 로 시작하여 질문하는 것이 좋겠지오.
저는 특히 해당 과정이 TDD 의 시나리오를 정의하는 과정과 비슷하다고 생각했습니다 :)
5. 가설 설정 및 검증
옵션들을 보고 하나씩 소거하고, 검증해보며 정답을 찾는 과정입니다.
옵션을 '검증 가능한 가설' 형태로 문장화합니다.
예를 들면 다음과 같습니다.
예시) A가 B로 되어 있는 게 C현상의 원인이라면, B를 B'로 변경했을 때 C가 C'로 바뀌어야 한다.
실제로 작은 변경을 가하면서 가설대로 현상이 변하는지 관찰합니다.
원인 파악이 될 때까지 다음 가설로 넘어가서 반복하고 '정상적인 동작'의 정의를 업데이트할 여지가 있는지 확인해가며 검증을 이어나갑니다.
나만의 디버깅 프레임워크 🤔
위 5단계를 살펴보았을 때 내가 어떠한 상황에 처했는지, 원인을 제대로 규정하는 것이 문제해결의 핵심이라는 걸 알 수 있습니다.
위의 5단계에 대해 무작정 따라하려고만 한다면 어려울 수 있습니다. 연습이 많이 필요하기도 하구요.
무엇보다 나만의 디버깅 프레임워크를 만드는 것이 바로 강의의 핵심 목표이므로, 글을 읽기 전 작성했던 나의 디버깅 패턴과 비교하여 나만의 디버깅 프레임워크를 만들도록 합니다.
아래는 5단계의 디버깅 프레임워크를 경험하며 깨달은 부분을 더하여 작성해본 나만의 디버깅 프레임워크 입니다.
- 에러를 맞닥뜨렸을 때 먼저 구글링을 하며 손을 바삐 움직이기 보다는 문제 상황을 정확히 규정 후, 이를 검증할 것
- 처음부터 문제를 정확하게, 완벽하게 작성하려 하다보니 많은 것을 놓치고 오히려 흐려지는 경향이 있었으므로 우선 날 것으로 작성한 후, 이를 다듬어 나가도록 하여야 한다는 점
직접 적용하고 경험해보며, 읽으시는 분의 '나만의' 디버깅 프레임워크가 만들어지길 바랍니다 :)
강의 후기
이전의 제 디버깅 과정을 되돌아보자면, 이것 저것 해보다가 운좋게 해결하면 도파민이 터지곤 하였습니다 😂
혹은 에러문구를 copy & paste 하여 관련 블로그를 우선적으로 찾곤 하였는데요...
위와 같이 해결하는 경우는 과정적으로 좋지 않다는 걸 알 수 있습니다.
반면에 위의 4. 차이를 발생시키는 다양한 원인 탐색 단계는 여러가지 가설을 세우면서 생각의 폭을 더욱 넓힐 수 있는 좋은 과정이 되고, 이는 곧 나의 성장이 된다는 걸 알 수 있습니다.
강의 중 좋은 아이디어가 있다면 그 아이디어가 왜 좋은지, 결과에 대해 어떻게 이러한 결과를 낼 수 있었는지에 대해 끊임없이 '왜?' 라는 질문을 가지는 습관이 급진적인 성장을 이루어낸다고 말씀해 주셨어요.
그리고는 곧 나는 어떤 개발습관을 가지고 있는지, 겪어왔던 배움의 순간들이 아직 내 안에 많이 남아있는지 떠올리고는 반성하게 됐답니다ㅎ..
나만의 디버깅 프레임워크를 통해 이제는 성장의 기회를 허투루 보내지 않도록 해야겠어요 :D
강의의 내용은 실습 과제를 함께 풀어보거나 팀으로 서로 의견을 나누는 등 많은 활동이 있었지만 요약, 또 요약하여 작성한 글입니다. 강의를 직접 수강하시는 것을 적!극! 권장합니다 😊
