1장, 실패는 어떻게 일어나는가?

참조 문헌

안드레아스 젤러(Andreas Zeller) 저, Why Programs Fail:프로그램은 왜 실패하는가?. 류 광역, (주)사이텍미디어 p.001 ~ p.035

1장, 실패는 어떻게 일어나는가? 내용

1장에서는 프로그램 실패란 무엇이고, 실패 발생 과정, 일반적인 디버깅 단계, 각 단계별 설명과 해야 할 일, 추가로 할 수 있는 일을 소개 하는 내용이 담겨 있다.

책 내용상 여담 형식으로 "버그"의 용어 역사와 디버깅 툴, 그리고 참고하면 좋을 좋을만한 책이나 문서등을 소개하고 있다.

프로그램 실패란 무엇인가?

프로그램 결과가 정상이 아닌 것을 프로그램 실패라고 표현한다. 흔히 버그가 있다. 버그 났다. 등으로 표현하는데, 일반적으로 내가 겪어본 바로는 "버그"라는 용어를 더 많이 사용한다. 책 내용 중 "버그"는 프로그램 외부에서 프로그램 내부로 전달 되었다는 느낌이 있으므로, "버그" 보단 실패가 좋으며, 프로그램의 실패 과정에서 모두 버그라고 하기엔 모호한 부분이 많이 있으므로, "결함", "감염", "실패" 라는 용어가 더 좋다고 주장한다.

물론 우리나라 단어로 번역하면서, 그 느낌이 이상하다고 생각할 수 있으나, 이러한 주장 배경에 감탄이 절로 나온다.

프로그램은 어떻게 실패하는가?

1. 프로그래머가 결함을 만든다.
   
2. 결함이 감염을 일으킨다.
3. 감염이 퍼진다.
4. 감염이 실패를 일으킨다.

1번은 대체로 프로그래머가 만들지만, Y2K 처럼 예측이 힘들거나, 사용자에게 전달 후 발견 되거나, 모듈간 호환성 문제가 있거나, 분산 프로그램에서 상호 작용이 안되거나 했을 때, 발생 할 수도 있다. 2번, 3번은 1번으로 인해 프로그램 상태가 비정상적인 것을 뜻하며, 4번은 이로 인해 실패 한다는 것을 뜻한다.

일반적인 디버깅 단계란 무엇인가?

1. 문제점 추적
   - 이슈 트래커 같은 DB에서 비슷한 문제가 있었는지 찾거나, 기록하는 것을 뜻한다. 보통 나의 경우, 추적은 안하고, 실패 재현부터 한다. 따지고 보면, 실패 재현을 위해, 비슷한 문제가 있었는지 찾는게 때론 도움이 된다. 왜냐하면 더 많은 정보가 있을 때, 재현이 더 쉽기 떄문이다.
   
   
2. 실패 재현
   
3. 자동화하고 단순화
   - 자동화되고 단순화 될 수록, 감염원의 범위가 줄고, 감염원에 더 집중할 수 있다.
   
   
4. 감염원 찾기
5. 감염원 집중
   
6. 감염 사슬 격리
   - 이 3단계가 프로그램 디버깅에서 제일 많은 시간과 노력이 사용된다. 내 경험으로 3일 내내 감염원만 찾은 적도 있었다.
   
   
7. 결함 수정
   - 대체로 경험 수정은 쉽다. 하지만 결함이 구조를 변경해야 할 때는 매우 어렵다.

책에선 단계별 해야할 일과, 추가로 할 있는 일들을 소개하지만, 2장 부터 이 부분을 설명하므로, 나는 생략한다.

여담

1장을 읽어도, 용어 부분에 있어서, 버그, 결함, 에러, 오류 등에 별 생각이 없다. 왜냐하면 내 경험적으로 버그 이외에 다른 용어는 잘 사용되지 않고 있다. 하지만 용어 정리가 이해는 된다. 그리고 책에 "버그" 용어에 대한 역사 부분은 재미있었다.

:wq