개략적 디버깅 방법.

[쌍판을 내놓는 다는게 쉬운 일은 아니지만. 개인적으로 좋아하는 사진이다. 어지러진 책상과 편안한 옷차림 하나의 문제에 문제에 집중하는.]

 

1. 우선 사람에게 물어본다.

 우리가 하는 대부분의 프로젝트는 1인 프로젝트가 아니다. 최고의 디벨로퍼라도 10명은 감당할 수 있을지는 몰라도 100명은 힘들다. 즉, 사람과의 의사 소통이 가장 중요하다. 회사에서 싫은 사람이 있을지라도 일적인 것은 과감하게 물어보자. 접근 가능한 소스와 그렇지 않은 부분을 구분해서 관련 기관에 질문도 빨리 해야 한다.

 

2. 잘못된 판단이라도 일단 내린다.

 과학에서 하는 가설 검증처럼. 이럴거라고 추측해 본다. 1번에서 제대로 물어보았다면 가장 빠르고 정확한 판단이 가능할 것이다. 잘못된 판단을 따라가다보면 어떻게 디버깅 해야할지 감이 온다.

 

3. 소스 리버스 엔지니어링

 메모가 중요하다. 소스를 보다보면 자신이 짠 것이 아니기 때문에 소소한 내용이야 분석 가능하지만 큰 그림을 그리기에는 힘들다. 그래서 이렇게 짜여졌을 것이다라는 블럭 다이어그램을 그리면서(간단히 사각형만 그리면 된다) layout을 구성해 본다. 일단 큰 그림이 그려지면 어디서 문제가 발생하는지 찾을 수 있다. C의 경우 Source Insight는 필수다.

 

4. Trace32

 회사에 와서 제일 좋았던게 Trace32을 받을 수 있었다는 것이다. 물론, 전 후 내용 모르고 일단 문제점을 건너뛰고 싶다면 Trace32가 가장 강력하다. 이건 정말 밖에서 배우려면 돈이 너무 많이 든다. 나 역시 학교 지원으로 89만원짜리 강의를 들은 적이 있는데 회사 오니 그냥 동영상 강의 파일이 돌더라.

 

 정리하자면...

 

Trace32 있어야 한다. ㅡㅡ; 그게 아니라면 소스마다 Debug Msg를 심어야 하는데... 그 작업도 일이요. 심고나서 컴파일도 일이다. 가끔은 심었던 deg msg 때문에 reset이 나는 경우도 있다. 담당자한테 물어봐도 그건 자기 일이 아니라고 하기 일쑤며, 프로젝트가 클 수록 모든 layout을 아는 사람은 바쁘다. 그래서 그 다음 엔지니어에게 물어보면 자기 일이 아니기 때문에 정확하지 않은 정보도 대충 가르쳐 준다.

 

툴 하나가 이 많은 것들을 해결해 준다고 보면 되겠다.