디버깅 원칙
(kciter.so)- 디버깅은 사실상 개발자의 필수 역량
- 디버깅은 어떻게 접근할 것인가라는 마인드셋이 중요
- 디버깅이란 주어진 상황과 데이터를 기반으로 문제의 원인을 찾아나가는 과정
- 글쓴이는 이를 직관이라고 표현한다
- 직관이란 내가 아는 지식을 문제와 연결하는 것
- 경험은 지식이 직관으로 통하는 숏컷 역할
- 개발자는 디버깅은 예상하지 못한 동작의 원인을 찾기 위하여 본능적으로 가능성을 좁혀나가는 행위를 하게됨
- 글쓴이는 원칙을 가지고 하나씩 좁혀나가는 것이 효율적이라 생각
-
문제를 찾기 위한 네 개의 단계를 소개
- 첫 번째, 의심하기
- 코드, 로그, 에러 메시지, 모니터링 데이터, 요구사항, 하드웨어 등 모든 것은 문제 해결을 위한 정보를 수집하는 것
- 체크리스트를 작성하면 좋음
- 두 번째, 분류하기
- 수집한 정보 중 아는 것과 잘 모르는 것 나눌 것
- 정보를 수집하는 단계에서 바로 여과되는 정보는 작은 직관으로 인한 것
- 글쓴이는 논리적 결함, 의존 기술 결함, 기반 기술 결함, 물리적 결함 네 가지로 분류
- 세 번째, 학습하기
- 수집한 정보를 기반으로 지식 공백을 찾고 학습할 것
- 네 번째, 연결하기
- 정보를 바탕으로 문제에 대한 가설을 세우고 실험할 것
- 이 과정에서 새로운 통찰이 생기면 다시 네 단계를 도는 피드백 루프를 이용할 것
- 첫 번째, 의심하기
- 앞서 소개한 내용은 앞서 언급한 직관을 연습하기에 유용한 방법
- 나만의 디버깅 원칙이 없다면 이 글을 기반으로 만들어도 좋고 새롭게 만들어도 좋음. 좋은 팁을 공유한다면 더 좋음
글쓴이는 원칙을 가지고 하나씩 좁혀나가는 것이 효율적이라 생각
굉장히 공감합니다. 그리고 디버깅에 관한 일반론적인 접근법을 잘 정리해서 제안해주신 것 같습니다.
실제로 디버깅을 해나가는 과정 속에는 굉장히 다양한 원인과 배경지식이 복잡하게 맞물려있기 때문에, 이 안에서 필요한 단서를 찾기 위해 포커스를 좁혀가는 과정이 정말 중요하다고 생각합니다.
본문에선 그런 과정에서 직관과 통찰력을 갈고 닦아야 한다고 하였는데, 직감적으로 어디가 원인인지, 어디를 중심으로 조사해야 하는지 그 시작점을 잡는 데에 있어 경험과 감으로 다져진 직관이 여기서 많은 지분을 차지하는 듯 합니다.
추론이 되는 사람은 되고 안 되는 사람은 안 된다는 생각.
한 30년쯤 전이었나 봅니다.
IT는 3년쯤 하면 실력이 다 똑같아진다는 소리를 선배들이 하고는 했죠.
지금 생각해보면 ....
정보를 연결하는 것은 직관의 영역이라기보다 추론 또는 논리적 증명으로 생각하는 게 더 자연스럽지 않을까요? 증명을 반복숙달하게 되면 구구단 외우듯이 중간과정은 생략하고 답이 바로 나와서 직관처럼 보일수는 있겠지만 둘은 구별하는 게 맞지 않나 생각합니다.
나머지 의심, 분류, 학습은 경험과 배경 지식이 쌓이게 되면 향상되는 걸 경험했기 때문에 동의합니다
글을 한번 더 읽어보고 덧붙입니다
필자께서 주장하시는 직관의 정의가 사회적으로 통용되는 직관의 정의와는 다른 것으로 보입니다. 생각의 과정이 없이 문제를 이해하는 게 일반적인 직관의 정의라 이해하고 있는데요. 글을 읽다보니 순간 제가 직관의 뜻을 잘못 이해하고 있나 싶어서 다시 확인해보게 되더라구요. 디버깅에 생각의 절차가 필요하다는 전체적인 논지와도 모순되지 않나 생각합니다. 디버깅이 정말 온전히 직관으로 수행할 수 있는 작업이라면 디버깅시에 로그나 데이터 확인, 형상관리가 전혀 필요없다는 주장도 참이어야 하지 않을까요?
안녕하세요. 글에 관심 주셔서 감사합니다.
말씀하신 것처럼 일반적으로 직관이란 직접적인 사고 활동 없이 대상을 파악하는 것을 의미합니다. 그렇다고 정말 아무 지식이 없는 상태에서 정답까지 갈 수는 없다고 생각합니다.
먼저 직관이라는 단어에 대한 제 생각을 적어보자면, 디버깅에 관한 이야기를 하다 보면 '갑자기 떠올랐다', '왠지 그 부분이 문제인 것 같았다'와 같은 말을 동료에게 듣거나 스스로 해봤다는 이야기를 자주 듣습니다. 저는 이 부분이 직관이라 생각했어요. 갑자기 떠오른 것을 그냥 넘기지 않고 하나씩 짚어보면 결국 해당 부분에 대한 경험이 있었거나 관련 지식을 잘 이해하고 있다는 것을 깨달을 수 있었습니다. 그래서 직관이라는 단어를 사용했고 오해가 있을 수 있으니 '내가 아는 지식을 문제와 연결하는 것이 직관'이라는 문장을 추가했습니다.
그래서 말씀 주신 몇 가지 의문에 제 생각을 말씀드리자면,
'디버깅에 생각의 절차가 필요하다는 전체적인 논지와도 모순'에 대해서는 제가 글에서 표현한 직관이란 이미 경험했거나 알고 있는 사실로 큰 생각없이 생략하는 것으로 묘사했습니다. 따라서 생각의 절차가 필요 없다는 뜻이 아닌, 생각을 빠르게 할 수 있는 도구로 표현하고자 했습니다.
다음으로 '디버깅이 정말 온전히 직관으로 수행할 수 있는 작업이라면 디버깅시에 로그나 데이터 확인, 형상관리가 전혀 필요없다는 주장도 참이어야 하지 않을까요?'에 대해선 온전히 직관으로 수행할 수 있다고 표현하지는 않았습니다. 오히려 '디버깅이란 주어진 상황과 데이터를 기반으로 문제의 원인을 찾아나가는 과정'이라는 문장을 추가했습니다. 다만, 디버깅 때마다 글에서 주장하는 네 단계 추론 과정을 거치는 개발자는 거의 없을 것으로 생각합니다. 어느 정도 경험과 지식이 있다면 자신의 판단으로 생략하는 경우도 있겠죠. 언급하신 로그, 데이터 등은 경험이나 지식이 있다면 이를 상기시켜 주는 역할을 하거나 경험이나 지식이 없다면 추론에 도움을 주는 역할 두 가지를 가지고 있다고 생각합니다. 따라서 글에서 언급한 직관을 위해서라도 없어선 안 되는 중요한 정보입니다.
이 글에서 사용한 직관이란 단어 자체가 애매모호할 수 있다고 생각합니다. 어쩌면 제 생각을 나타내기에 글의 구성이나 빌드업이 안 좋았을지도 모르겠습니다. 우선 구체적이지 않았던 부분은 수정하려고 합니다. 그러나 직관이라는 단어를 교체하는 것이 좋을지는 아직 판단이 잘 안서네요. 글을 쓸 때부터 직관이라는 단어를 핵심으로 꼽았기에 대체할 다른 단어가 생각나지 않습니다. 혹시 좋은 의견이 있으시다면 말씀 주시면 감사하겠습니다. :)
디버깅에 직관과 추론 작용이 둘 다 필요하다는 배경 설명을 서론에, 문제를 찾는 방법과 직관/추론의 연관성을 본론에 추가하면 글의 완결성을 높일 수 있을 것으로 판단합니다
변경 전
- 디버깅이란 주어진 상황과 데이터를 기반으로 문제의 원인을 찾아나가는 과정이다
- 디버깅을 통한 문제 해결은 보통 개발자의 직관에서 나온다
- 문제를 찾기 위한 네 개의 단계가 존재한다
변경 후
서론
- 디버깅이란 주어진 상황과 데이터를 기반으로 문제의 원인을 찾아나가는 과정이다
- 디버깅에는 문제 인식과 문제 해결 두 가지 세부 작업이 순차적으로 필요하다
- 문제 인식에는 직관이, 문제 해결에는 추론이 작용한다. 이를 뒷받침하는 이론으로 이중처리이론(dual process theory)가 있다
- 문제 인식 과정에 추론만을 사용하게 되면 시스템의 형상 등의 기술 세부사항을 일일이 확인하고 검증해야 하기 때문에 생산성을 높이는 데에 제약이 있다. 대신 문제 인식 과정에 직관을 보조적으로 사용하는 것이 디버깅 전략에 유리하다
- 직관의 실효성을 높이기 위해 평소에 경험과 통찰, 즉 휴리스틱을 축적하는 것이 중요하다.
- 직관이 틀리거나 상황에 맞지 않는 가능성은 언제나 존재하며, 인지 편향에서 벗어나는 훈련도 중요하다
본론 (디버깅 절차)
- 정보 수집
- 분류 - 직관과 휴리스틱이 작용함
- 학습
- 가설 수립 및 검증 - 추론이 작용함