ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 디버깅하는 법
    개발론 2024. 9. 11. 14:00

     

    필자는 코드 컴플리트라는 책을 읽고 있다.

    여기서는 다음과 같이 말하고 있다.

     

    고급 제품을 만드는 가장 좋은 방법은 요구사항을 주의 깊게 개발하고 잘 설계하고 고급 코드 작성 방법을 사용해야 한다. 디버깅은 최후의 수단이다.

     

     

    뭔가 와닿지 않는다.

    그 이유는 내가 만들었든 외부의 프로젝트를 받아서 하든

     결함이 있었고 디버깅은 언제나 해야 했기 때문이다.

     

    그렇다면 디버깅은 어떻게 하는 것일까?

    어디서도 디버깅하는 법에 대해서 배워본 적이 없기 때문에

    그것을 어떻게 하면 잘하는 것인지 모른다.

     

    다음은 책에서 본 4년 이상의 전문적인 개발자들이 

    얼마나 효과적으로 디버깅하는지 비교한 표이다.

     

      가장 빠른 세 명의 개발자 가장 느린 세 명의 개발자
    평균 디버깅 시간(분) 5.0 14.1
    미발견된 평균 결함 수 0.7 1.7
    결함 수정 중에 발생시긴 결함의 평균 수 3.0 7.7

    출처: Some Psychological Evidence on How People Debug Computer Programs (Gould 1975)

     

    이는 숙련된 개발자들 사이에서도 완전히 문제를 해결할 때까지는 14배까지도 차이가 난다고 하고 

    숙련되지 않은 개발자와의 시간은 대략 20배나 차이난다고 한다.

     

    그렇다면 디버깅 고수들은 어떻게 디버깅을 할까?

     

    디버깅 관련한 2024년 인프콘 배휘동님의 강의에서 알 수 있었다.

     

    디버깅은 마법이 아닌 마술과 같이, 트릭(고수들의 인지적 작업)과 손기술(행동 패턴 훈련)을 익히면 누구나 배울 수 있는 기술이다

     

    하지만 전문가들도 트릭과 손기술에 대해서 명확히 인지하지 못하고 정리되어 있지 않은 경우 대부분이었다고 한다.

     

    발표자분은 인지 심리학계의 거장인 개리 클라인이 논문에서 발표한 

    Critical Decision Method 줄여서 cdm 이라 부르는 분석방법을 사용해서

    전문가들의 인터뷰를 하면 그들의 머릿 속에 숨은 안목이나 무의식적으로 인식하는 패턴 아니면 저도 모르게 하는 습관 같은 것들을 효과적으로 뽑아냈다고 한다.

     

    디버깅의 3단계는 다음과 같다.

    1. 원인 파악

    2. 문제 해결

    3.사후 처리

     

     전문가들은 원인 파악에 많은 시간을 투자한다

     

    고수들의 디버깅 능력은 풍부하고 질 높은 심적 표상(mental representation)에서 비롯된다.

     

    ⁠⁠우리 마음 속에 존재하는 일종의 지식 구조를 뜻하는데

    이것의 양과 질이 전문가와 비전문가의 큰 차이를 만든다고 한다.

    이런 심적 표상을 통해 문제를 풀면 이 경험이 누적되어 더 양질의 심적 표상을 만들어져서 

    머릿 속 디시전 트리가 업데이트되며 그 패턴의 문제에 대해 더 똑똑해 진다!

     

     

     

    좋은 심적 표상을 쌓으며 디버깅 하는 방법을 설명해주셨는데

     

    1. 문제 정의


    중간 회고 시 메타인지 활성화하기 ("내가 지금 뭘 하고 있지?")
    다른 사람에게 문제를 설명하고 공유할 때 유용
    Yak Shaving 문제 방지

     


    2. 정상 동작 정의


    정상적으로 동작한다면 어떤 상황에서 어떤 것이 되어야 한다.


    3. 최소 재현 환경 구축 및 관찰


    직접 재현하여 문제의 핵심을 파악
    문제 발생 시점 정확히 확인
    사용자 환경과 동일하게 구현하여 패턴 관찰
    재현되지 않는다면 추가 정보 수집

    4. 다양한 원인 탐색


    두 환경의 차이가 어디에서 왔을지 생각해보기
    3개 정도의 가설 세우기
    추가 정보 수집이 필요할 경우 다양한 소스 활용


    5. 검증 가능한 가설로 문장화 및 실험

    가설을 실제로 테스트하여 관찰
    전이되면 1단계부터 재시작
    가설이 틀리면 새로운 가설 시도
    여전히 원인 파악이 안 된다면 추가 정보 수집

     

     

    이 목록 중에서 

    2번은 약간 의아하다.

    왜냐하면 문제를 정의했다는 것은

    문제라는 것을 인식했다는 것이고 

    이는 정상 동작의 정의가 끝나야 문제라는 것을 알 수 있는 것일텐데 

    라는 생각이 든다.

     

    여기까지는 기법에 관한 설명이었고

    구현에 관해서는 코드 컴플리트라는 책에서 매우 자세하게 설명하고 있었는데

    그중 인상깊었던 악마의 지침을 작성하며 마무리 해보겠다.

     

    디버깅에 대한 악마의 지침

     

    1. 추측으로 결함을 찾아라.

    출력을 여기저기 찍고 안되면 동작하는 것처럼 보이도록 프로그램을 변경한다.

    이 때 백업하지도, 기록을 남기지도 않는다.

     

    2. 문제 이해에 시간을 쓰지 말아라

    그냥 문제는 찾으면 그만이다.

     

    3. 가장 명백한 수정으로 오류를 수정하자.

    전체에 가해질 영향을 찾기 보다는 특정 문제 수정에 집중하자.

     

    x = compute(y)
    if(y = 17)
    	x = $25.15

     

     이와 같이 y가 17일 때만 문제가 생기는데 

    굳이 저 compute() 함수에 관심가질 필요가 있나?

     

     

Designed by Tistory.