개발&Development/프로그래밍 일반

BSI - Bug Scene Inspector

겐도 2007. 8. 3. 12:21

역시 퍼나르기.

글쓴이: gendoh (ご,ご;;;)                                     [/writers/gendoh]
날  짜: 2004년 11월 10일 (수) 08시 01분 08초
제  목: BSI - Bug Scene Inspector                                             

CSI(Crime Scene Inspector)를 보다가 문득 든 생각이 바로 BSI.
살인현장의 증거를 수집하듯... 프로그램을 죽게 만든 버그(살인자)를 찾기 위해
증거를 수집하는 과정이 나름대로 비슷하지 않을 까란 생각이 든다.

1. 살인자를 찾아라.
우선 베이스가 되는 생각은 프로그램이 죽는 이유는 살인코드가 있거나
살인코드들(!)이 있다는 것이다. 의도적이거나(오타, 실수) 사고(Side Effect,
Mis-understand 등)에 의한 것일 수도 있다. 아무튼 문제를 일으킨 부분은 존재할
것이며 반대로 그 부분을 찾기 전에 단순한 추측으로 이것 저것 고치는 것은 해당
문제를 숨겨 버릴 가능성이 높다는 것이다. 잠시 해결된 것처럼 보일 뿐
내부적으로는 살인범이 거리를 활보하고 다니는 것이다. 그냥 아무일도 일어나지
않을 수도 있지만 어느순간 재발할 수도 있다.

2. 사인을 찾아라.
스택이 깨지거나 파일의 내용을 알아볼 수 없게 되거나 재부팅이 되거나 하는
것들이 사인은 아니다. 시체가 부패하는 것일 뿐이다. 1차 사인이 뭔지를 찾는
것이 중요하다. 버퍼가 오버플로우가 되면서 스택이 깨지고 블루스크린까지
연관되었다면 일단 버처가 오버된 것이 직접적인 사인이라 할 수 있다. 메모리
포인터가 잘못들어가 있거나 이미 지워진 객체에 대한 엑세스는 직접 사인에 많이
근접 하였다. 하지만 1차 사인은 아니다. 왜 이미 지워진 객체를 해당 변수가 들고
있었느냐 혹은 왜 객체가 사라져 버렸느냐에 대한것이 바로 사인일 것이다.

포인터가 잘못되어 있는 것을 보고는 거기에 메모리 확인 코드를 넣어버리고
사건을 종결시키게 되면 결국 엉뚱한 용의코드를 범인으로 지목한 것이 된다.
1번에서 지적하였듯이.. 살인코드를 찾아야 한다. 살인코드를 발견하지 못했다면
해당 사건은 해결된 것이 아니다.

3. 증거에 의존하라.
우선 사망 현장에서 중요한 것은 증거의 수집이다. 하드웨어 장비의 스펙부터
조사하는 것이 급선무이다. CPU, 메모리, 하드 용량 및 사용량 등등 사고 현장에
있는 모든 것들이 증거에 속한다. 너무 사고와 직접적인 것들만 보는 것은 주의해야
한다. 정책, 설정, 레지스트리 뿐만 아니라 하드디스크의 풀이 스왑파일 증가를
하지 못하게 하여 메모리 얼로케이션에 문제가 생겼을 수도 있다.

또한... 사인에 대한 많은 가정들을 하겠지만 증거중 하나라도 그것을 부정한다면
그것을 인정해야 한다. 반대로 어떤 가정이 맞다라고 결론을 내릴때는 증거의
뒷바침이 있어야 한다. 조사자의 경험이 많은 도움이 될 수 있지만 그것은 증거를
찾는데 활용해야 하지 섣불리 결론을 내려버리는데 사용되어서는 안된다. 무고한
코드가 사형대로 보내질 수 있음을 명심해야 한다.

4. 가정의 검증
어떤 원인이 용의자로 지목되었다면 그것이 실제 프로그램의 사망까지 연관 될 수
있음을 증명해야 한다. "현장 검증"을 하듯 용의코드가 실제로 사망을 유발하는지
검증해야 한다.

5. 용의코드 색출
살인사건이 나면 1차적으로 주변 인물들을 조사한다. 코드도 마찬가지이다. 가장
먼저 살인현장을 발견해야 한다. 최종적으로 어디서 죽었는지 알게되면(보통은
C0000005 익셉션이 일어난 곳이나 Segmentation Fault가 난 부분) 위아래의 코드,
그리고 문제가 된 변수와 연관된 변수들이나 앞뒤로 붙어있는 변수들이 1차
용의자가 된다. 1차 용의코드에 대한 수색이 끝나도 별다른 성과가 없다면 수색
범위를 늘이는 수 밖에는 없긴 하다.

6. 전과자 검색
동일 유형의 버그를 조사해 본다. 이때 유용한 것이 Bug Tracking System이다.
이전에 발견된 버그들이 어떤 증상을 보였고 어디에 문제가 있었고 어떻게
해결되었는지에 대한 히스토리는 상당한 도움을 줄수도 있다. 또한 미결 사건으로
남은 것들이 있다면(사고 재현이 안되고 이후 증상 없음) 동일범일 가능성도 크다.

7. 증거는 최대한 있는 그대로...
CSI에서 보면 증거를 연구소 까지 옮기 위한 에피소드들을 가끔씩 나오는데
프로그램이라고 해서 별로 다를 것은 없다고 보인다. 실례로 단 한명의 고객이
비정상 작동을 보고했는데 도저히 찾을 수 없어서 그사람의 컴퓨터를 개발팀이
사버렸다는 일화도 있다. 본인도 증거를 찾기 위해서 사이트에 직접 나가거나
해당 장비를 들고 온적도 많다.

비슷하게.. 메모리 덤프나 각종 시스템 로그, 당시의 파일 상황들, 프로세스
정보등 가능한한 모든 것들이 조사 가능 하거나 보존되어야 한다. 해당 시스템이
재부팅 되는 순간 많은 증거들이 날라갈지 모른다. 반대로 익셉션 로그를 남기도록
프로그래밍 되어 있다면 가능한 많은 것들을 남기도록 설정하는 것이 좋을 것이다.
또하나의 부분이 소스코드와 컴파일된 코드인데 해당 버젼의 프로그램이 생성될때
남긴 흔적들도 모두 증거의 일부가 될 수 있다. Release 모드(디버깅 정보가 빠진
바이너리)라고 할지라도 남길 수 있는 것들은 최대한 남겨두는 편이 나중에 증거를
찾는데 도움이 될 것이다. Visual C++를 사용한다면 Map 파일을 만들어 두느냐
아니냐가 제품 안정화에 상당한 차이를 유발할 수도 있다. 버젼 관리 시스템의
사용도 중요하다.

8. 사고의 발생부터 해결까지의 기록
모든 사고는 기록되어야 한다. 위에서 Bug Tracking System을 이야기 했지만 이런
기록은 많은 도움이 될 수 있다. 왠만한 프로젝트는 여러사람이 참여하고 상황에
따라 오랜 기간이 걸리기도 하면서 사람이 바뀌기도 한다. 또한 한사람이 한다고
해도 예전의 상황을 모두 기억하기는 어렵다.
사고가 발생했을대 이전 기록들을 검사해 보고 어떻게 찾고 해결하였는지에 대한
정보가 있다면 따라 해보고 동일 사건인지 확인한 후 같은 방법 혹은 그것을
참조하여 해결할 가능성이 상당하다.

반대로 지금 조사과정이라면 미래를 위해 그것들을 모두 기록으로 남기는 것이
좋다.

~~~~~~~~~~~
CSI는.. 정말 재밌다. 가끔씩 팀원들이 길 그리썸을 닮아가는거 아니냐고 구박중.
맨날 야근에 힘든 일만 시키고 이해하기 힘든 말을 하고 하기 싫은 일만
시킨다고... ;;;;;
                  (^^)("  )(  ")(--)(..  )(  ..)(--)(^^)
                        소개팅 적령기 --> 맞선 적령기

글쓴이: toro (커피는나의힘)                                   [/writers/gendoh]
날  짜: 2004년 11월 10일 (수) 09시 26분 04초
제  목: Re: BSI - Bug Scene Inspector                                         

정말 훌륭한 글입니다!!

그런데 실제 고객들은 문제를 해결하기 보다는 무마 내지는 책임
덮어씌우기를 하려는 경향이 있던데, (물론 무마하려는 경향은 영업쪽이 더
크겠지만) 그런 경우에는 어떤 식으로 해결할 수 있을지 참 난감합니다.
특히 다음과 같은 상황은...

- "왜 죽었는지 1시까지 보고서 작성해!"
= (씨불... 그걸 알면 죽게 만들었겠냐..)

글쓴이: penny (^-_-^)                                         [/writers/gendoh]
날  짜: 2004년 11월 10일 (수) 12시 59분 27초
제  목: Re: BSI - Bug Scene Inspector                                         

마지막 하나 더..

체포된 범인을 사주한 자를 찾아 적절한 응징을...
(SCS의 history이용)

ex) 털털이, VIPS, ...

@ 단 유지보수 계약을 맺지 않은 알바의 코드는 무효 -_-

~~~~
        Restart

글쓴이: handrake (최진성)                                     [/writers/gendoh]
날  짜: 2004년 11월 10일 (수) 15시 54분 17초
제  목: Re^2: BSI - Bug Scene Inspector                                       

penny님의 글 "Re: BSI - Bug Scene Inspector"에서 :
>
> 마지막 하나 더..
>
> 체포된 범인을 사주한 자를 찾아 적절한 응징을...
> (SCS의 history이용)
>
> ex) 털털이, VIPS, ...
>
> @ 단 유지보수 계약을 맺지 않은 알바의 코드는 무효 -_-
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  정규 사원이던 시절의 코드는 유효??

 음허허.. 얼른 올라와서 고기+술이나 쏴요~~

참고.
VIPS : 당시 회사 근처에 있던 레스토랑. VIPS라 함은 거기서 팀원 전체에게 음식을 쏜다는 의미로 자칫 한달 월급이 날라갈 수도 있는 형벌
털털이 : 대가 끊길수도 있는 무서운 형벌. 일단 행동대장이 사람을 넘어뜨리면 네사람이 각각 팔과 다리를 잡으며 최후의 1인이 거기를 발로 밟아주는... 생각만 해도 무서운...

'개발&Development > 프로그래밍 일반' 카테고리의 다른 글

Greatest problem in computing today  (1) 2007.10.01
Escaping String  (3) 2007.08.14
글자 크기  (4) 2007.07.31
코더로서 적응해 간다는 것  (20) 2007.06.20
무섭고도 어려운 Scalibility  (0) 2007.05.30