Debugging Strategies: A Systematic Approach to Finding Bugs — txt1.ai

세 시간. 지난 화요일에 47,000줄 코드베이스에서 단 하나의 잘못 배치된 세미콜론을 찾는데 소비한 시간이다. 임베디드 시스템부터 분산 마이크로서비스에 이르기까지 14년의 경험을 가진 수석 소프트웨어 아키텍트로서, 세 시간의 악몽과 세 분의 수리 간의 차이는 운이 아닌 방법론이라는 것을 배웠다. 나는 마커스 천이며, 3 AM에 생산 사고를 디버깅한 경험이 헤아릴 수 없을 만큼 많고, 첫 번째 중대한 버그를 겪는 수십 명의 주니어 개발자들을 멘토링했으며, 지난 2년 동안 우리 팀의 평균 버그 해결 시간을 68% 줄이는 체계적 접근 방식을 개발했다.

사실 대부분의 개발자는 눈을 가리고 건초 더미 속에서 바늘을 찾는 것처럼 디버깅에 접근한다. 그들은 무작위 변수를 변경하고, 곳곳에 인쇄문을 추가하며, 뭔가 맞아떨어지기를 바란다. 그러나 디버깅은 희망이 아니라 체계적 제거, 패턴 인식, 시스템의 근본적인 행동을 이해하는 것이다. , 복잡한 문제를 디버깅하기 위해 내가 사용하는 정확한 프레임워크와 수많은 시간을 절약해준 사고 모델, 효율적인 디버거와 어려움을 겪는 개발자를 구별하는 실용적인 기법을 공유할 것이다.

디버깅의 심리학: 왜 당신의 두뇌가 당신에게 역효과를 낼까요

기술에 대해 깊이 파고들기 전에, 효과적인 디버깅의 가장 큰 장애물에 대해 이야기할 필요가 있다: 당신 자신의 두뇌. 나는 박사 학위를 가진 뛰어난 엔지니어들이 인지 함정에 빠져 몇 시간입니다. 이러한 심리적 함정을 이해하는 것이 체계적인 디버거가 되기 위한 첫 번째 단계이다.

가장 위험한 함정은 확증 편향이다. 버그를 유발하는 원인에 대한 이론이 있을 때, 당신의 두뇌는 그 이론을 지지하는 정보를 적극적으로 필터링한다. 나는 한 번 메시지 큐의 경쟁 조건으로 인해 간헐적 실패가 발생한다고 확신하며 오후 내내 시간을 보냈고, 실제 문제는 전혀 다른 서비스에서 잘못 구성된 시간 초과 값이었다는 것을 발견했다. 나는 그것들이 내 정신 모델과 맞지 않았기 때문에 시간 초과를 가리키는 세 가지 명확한 지표를 무시했다. 소프트웨어 엔지니어링 연구에서 개발자들이 약 35-50%의 디버깅 시간을 잘못된 가설을 추구하는 데 소비한다고 나타나 있으며, 확증 편향이 주된 원인이다.

또 다른 인지 함정은 매몰 비용 오류이다. 한 가지 가정에 기반하여 두 시간을 디버깅한 후, 그 접근 방식을 포기하고 새롭게 시작하는 것이 심리적으로 어려워진다. 나는 개인적으로 규칙을 개발했다: 45분 간 의미 있는 진전을 이루지 못하면 물러나서 커피를 마시고 완전히 빈 상태로 돌아온다. 이 간단한 관행은 내 경력에서 아마도 수백 시간을 절약했다.

세 번째 함정은 내가 "복잡성 편향"이라고 부르는 것으로, 복잡한 문제는 복잡한 원인이 있어야 한다는 가정이다. 사실, 나는 생산 시스템의 약 70%의 버그가 부끄럽게도 간단한 근본 원인을 가지고 있다는 것을 발견했다: 오타, 한 개 차이 오류, API 동작에 대한 잘못된 가정, 또는 구성 오류. 지난 화요일에 세 시간을 소모한 버그는? JSON 구성 파일에서 세미콜론이 아니라 쉼표였다. 시스템은 그것을 유효한 구문으로 해석했지만 완전히 잘못 해석하고 있었다.

이러한 편향을 극복하기 위해, 나는 모든 버그에 대해 "초심자의 마음"을 가지고 접근하도록 훈련했다. 즉, 나는 아무 것도 모른다고 가정하고 증거가 나를 안내하도록 한다. 이 사고 방식의 변화만으로도 나는 내 초기 경력 시절 경험만으로 해결책을 직관할 수 있다고 생각했던 때보다 최소 두 배는 더 효과적인 디버깅을 할 수 있게 되었다.

코드에 적용된 과학적 방법

내가 발견한 가장 효과적인 디버깅 프레임워크는 단순히 소프트웨어에 엄격하게 적용된 과학적 방법이다. 이것은 비유가 아니다. 나는 문자 그대로 고등학교 과학 수업에서 배운 동일한 과정을 따르며, 복잡한 시스템에서 버그를 찾는 데 놀라울 정도로 잘 작동한다.

디버깅은 희망이 아니라, 체계적 제거, 패턴 인식, 시스템의 근본적인 행동을 이해하는 것이다.

첫 번째 단계는 관찰이다. 코드를 건드리기 전에, 나는 정확히 무슨 일이 일어나고 있는지를 문서화하는 데 시간을 보낸다. 증상은 무엇인가? 언제 시작되었는가? 최근에 무엇이 변경되었는가? 나는 디버깅 저널을 유지하며 모든 관찰을 기록한다, 아무리 사소해 보이더라도. 그 세미콜론 버그에 대해 내 저널에는 "오류가 생산 환경에서만 발생한다", "14:23 UTC에 배포 이후 시작되었다", "약 12%의 요청에 영향을 미친다", "오류 메시지가 '예상치 못한 토큰'을 언급한다"와 같은 항목이 포함되어 있다. 이러한 관찰들은 중요한 단서가 되었다.

두 번째 단계는 가설을 세우는 것이다. 내 관찰에 기반하여 버그를 유발하는 것에 대한 테스트 가능한 이론을 생성한다. 여기서의 핵심 단어는 "테스트 가능성"이다. "데이터베이스에 문제가 있다"와 같은 모호한 이론은 유용하지 않다. 좋은 가설은 구체적이어야 한다: "데이터베이스 연결 풀은 시간 초과 값이 너무 낮아 부하에서 소진되고 있다." 나는 일반적으로 3-5개의 경쟁 가설을 생성하고 그 가능성에 따라 순위를 매긴다.

세 번째 단계는 가설을 테스트하기 위한 실험을 설계하는 것이다. 많은 개발자들이 여기에 잘못 빠진다. 그들은 코드 변경에 바로 뛰어들며, 어떻게 변경이 실제로 문제를 해결했는지를 알 수 있을지를 생각지 않는다. 각 가설에 대해, 나는 그것을 확인하거나 반박할 수 있는 특정 테스트를 설계한다. 만약 연결 풀이 문제라고 생각되면, 부하에서 풀 메트릭을 모니터링하거나 풀 크기를 일시적으로 늘리고 결과를 관찰할 수 있다.

네 번째 단계는 실험을 실행하고 데이터를 수집하는 것이다. 나는 한 번에 하나의 변경만 한다. 절대 여러 변경 사항을 동시에 하지 않으며, 결과를 주의 깊게 관찰한다. 나는 개발자들이 한 번에 세 가지를 변경하고 버그가 사라지는 것을 보고, 어떤 변경이 실제로 그것을 수정했는지 전혀 모르는 경우를 보아왔다. 그것은 디버깅이 아니다. 그것은 도박이다.

다섯 번째 단계는 결과를 분석하고 반복하는 것이다. 가설이 확인되면 좋다. 나는 버그를 찾았다. 그렇지 않으면, 그 가설을 명확하게 거부하고 왜 잘못되었는지를 문서화하며 다음으로 넘어간다. 이 체계적 제거는 놀라울 만큼 강력하다. 내가 틀리더라도, 나는 검색 공간을 좁힘으로서 진전을 이루고 있다.

나는 이 프레임워크를 사용하여 C++ 애플리케이션의 메모리 누수에서부터 분산 시스템의 미세 타이밍 문제에 이르기까지 디버깅해왔다. 그것은 당신이 직관이나 추측에 의존하는 것이 아니라, 방법론적이고 증거 기반이 되도록 강제하기 때문에 작동한다. 내 경험에 따르면, 이 과학적 접근 방식을 채택한 개발자들은 몇 달간의 연습 안에 디버깅 시간을 40-60% 줄인다.

재현 가능한 테스트 케이스 구축: 효과적인 디버깅의 기초

내가 디버깅에 대한 조언을 딱 하나 할 수 있다면, 그것은 이것이다: 아무것도 하기 전에 최소한의 재현 가능한 테스트 케이스를 만드는 데 많은 투자를 하라. 나는 개발자들이 제대로 된 재현 사례로 한 시간 안에 문제를 해결할 수 있었던 생산 환경에서 문제를 디버깅하려고 하루를 낭비하는 것을 여러 번 보았다. 이것은 내가 내 팀의 주니어 개발자들에게 가르치는 가장 중요한 기술이다.

재현 가능한 테스트 케이스는 버그를 지속적으로 보여주는 시스템의 단순화된 버전이다. 주요 특징은: 최소한으로 구성(버그를 유발하는 데 필요한 코드만 포함), 고립됨(가능할 경우 외부 서비스나 상태에 의존하지 않음), 일관성 있음(실행할 때마다 같은 결과를 생성함)이다. 이것을 만드는 데 규율이 필요하다. 왜냐하면 복잡성을 없애야 하기 때문이다. 하지만 보상은 엄청나다.

재현 사례를 구축하는 과정은 다음과 같다. 먼저 버그가 발생하는 전체 시스템을 시작으로 하나씩 구성 요소를 제거해 나간다. 데이터베이스 없이 재현할 수 있는가? 메시지 큐 없이? 인증 계층 없이? 내가 성공적으로 제거한 각 구성 요소는 단순화 과정을 한다.