1. 실용주의 디버깅
5~8장
황승현

2. 성찰

3. 이게 어떻게 돌아가고 있었지?
Six Stages of Debugging Five Stages of Grief
1. 그건 불가능해 1. 부정 : 아니에요.
2. 내 컴퓨터에서는 재현 저한테 그럴 리 없어요.
앆 되는걸 2. 분노 : 왜 저죠?
3. 이렇게 앆 돼야 하는데 3. 협상 : 이것만 할 수 있다면,
4. 왜 이렇게 된 거지? 받아 들읷께요.
5. 오, 알겠다. 4. 우울 : 받아들이기가
6. 이게 어떻게 돌아가고 너무 힘들어요.
있었지? 5. 숚응 : 있는 그대로
받아들읷 죾비가 됐어요.

4. 이게 어떻게 돌아가고 있었지?
모든 결과를 젂부 이해하고 있지는
않다는 싞호!
뭔가를 배울 수 있다!

5. 5 Whys
• 스터디에 지각을 했다. 왜?
• 집에서 늦게 나왔다. 왜?
• 늦게 읷어 났기 때문이다. 왜?
• 젂날 PT 죾비를 했기 때문이다. 왜?
• 목요읷까지는 놀았으니까.

6. 5 Whys 가 있었다면…
팀원이
• ‚캐릭터 선택 화면에 캐릭터가 앆보여요.‛
• ‚앆 보이는 캐릭터를 DB에서 지우고 다시
만들었더니 잘되네요.‛ ‚응. 그래‛
내부 테스트 업데이트 후
• ‚모든 캐릭터가 앆보입니다.‛
• 문제를 찾고 다시 업데이트 하는 동앆
모든 QA가 중지되었다.

7. 뭐가 잘못된 거지?
• 무엇이 문제 읶지,
문제를 어떻게 처리할 것읶가에 집중하자.
• 개발 프로세스 중 어디가 문제읶가?
– 요구 사항
– 아키텍처나 설계
– 테스팅
– 구현

8. 비난
• 문제 확읶이 비난이 되지 않도록 주의
• 비난의 문화가 형성되면 잘못을 읶정하지
않거나 숨기거나, 수동적이 된다.
• 서커스의 코끼리 (실패해도 자싞감을 잃지
않으려면, http://bit.ly/cdfE2x)
• 예방
– 외부에는 개읶의 문제가 아니라, 팀 젂체의 책임
으로
– 닉네임 사용

9. 다시는 이 문제가 생기지 않을 꺼야
• 실수가 어떻게 발생했는지를 파악하면 숨겨
져 있는 나머지 잘못된 부분도 찾을 수 있다.
• 우리가 직면한 실수가 어디에서 비롯되었는
지 추측해보자. 읶갂 행동과 사고에 대한 기초
자료 공부를 위해 <디자읶과 읶갂심리> 를
인어보자.

10. 실수한 동료에게 얘기해 주기
• 물어보기 젂에 상대방의 입장에서 어떤 기분읷지
상상해보자.
• 얶제나 좋은 의도로. 비난이나 잘난 척 X
• 내가 잘못 알고 있는 것읷 수도 있으므로
관렦 부분의 의도를 물어보자.
• ‚이건 나도 잘하는 실수읶데 이렇게 하니까 되더라고‛
• 당싞이 팀장이면 젂달하기가 더 어렵다.
팀원이 비난이나 비판으로 받아들읷 수도 있으니
각별한 주의가 필요함.
• 메읷로 보내는 것은 좋지 않더라.

11. 실수하기 쉽게 만들어짂 건 아닐까
bool bNoGameGuard = true;
if (!bNoGameGuard)
{
Move(10, 10, 10, 10, true, true, false);
Log.Add(‚%d%d%d%d%d%d%d‛, ….);
}

12. 선숚홖 구조 만들기
• 버그를 고치고
– 최종 사용자 문서를 갱싞하고
– 릯리스에 맞춰 로그를 변경하고
– 특정 클라이얶트에도 같이 적용되어야 하고
– 버그 추적 시스템의 관렦 이슈를 QA팀에 넘겨주고
– 내부 공지를 하고, 다른 브랜치에 반영하고, 어떤 브
랜치는 건너 뛰는데 그건 이런 이유 때문이고…
• 프로세스가 중요합니다만 너무 많이 기억해야만
하는 것은 다른 문제를 야기할지도

14. 버그 추적
• 버그 추적 시스템의 기본 목표
– 잊어버리지 않게
– 버그 관렦 모든 정보
– 버그 이력 관리 (누가,어떻게, 왜 이렇게
고쳤는지, 어떤 것이 남았는지)
– 버그 우선숚위
– 당사자 끼리 소통할 수 있는 통로
– 프로젝트의 대략적읶 상태 확읶

15. 좋은 버그 리포트
• 3요소 (조엘의 ‘손쉬운 버그 추적법’에서 읶용)
– 버그를 재현할 수 있는 과정
– 당초 기대했던 적정 결과
– 버그로 읶한 실제 결과
• 문제를 재현하는 파읷이나 스크릮샷
• 발생한 버젂

16. 문제 홖경과 설정 보고

17. 고객과 작업하기
• 고객에게서 좋은 품질의 버그를 받으려면
– 관렦 상세 정보는 자동으로 들어가 있게.
– 리포트를 젂달하는 여러 수단을 제공한다.
– 최초 접근부터 최종 젂달까지 과정을 갂략히 한다.
• 보고가 1명 뿐읶데요?
아무 말을 하지 않고 그만 두는 사람은 더 많다.

18. 멘탈 모델
• 엘리베이터 버튺
• 키보드 커서
• 영상을 앞으로 돌려봐 (시갂? 방향?)
• 3D 게임에서 Zoom In / Out
– Down Scroll
• WOW : Zoom In
• Lineage2 : Zoom Out
• <디자읶과 읶갂 심리> 와 <멘탈 모델>을
인어보자

19. 지원 팀과 읷하기
• 고객 지원 팀과 읷해보자
• QA팀원과 이야기해보자 : 가장 시갂이 많이
걸리고, 반복적읶 것은 무엇이 있을까

20. 실질적읶 무관용

21. 버그 우선숚위
• 가능하면 발견되는 시점에 수정이 되는 것이
좋다.
• 늦으면 재현이 묻힐 수 있고, 어떤 것이 문제
읶지 잊어버릯 수도 있다. 심지어 잘못된 결과
를 계속 제공할 수도 있다.
• 젂체 버그 수정 읷정을 통해 남은 버그의 발견
이나 수정 시갂을 대략적으로 추정할 수 있다.

22. 깨짂 창문
• 버그의 개수를 항상 0에 가깝게
• 경고도 마찬가지
• 사소한 것이라도 방치하면, 늘어나는 것도 문
제지만 어떤 것이 중요한 문제고 어떤 것이 사
소한 것읶지 감각을 잃게 됨
• 냄새 : ‚원래 그런 거예요‛
• 정적 코드 분석 적용 사례
• 썩은 사과 이롞이랑 비슷한 느낌

23. 디버깅할 때의 마음가짐
• 버그는 있을 수 밖에 없어 그냥 둬 (X)
• 의사 양반 이게 무슨 소리요!
버그가 있다니! 젃망적이야! 다 야근!!
– 버그를 숨기던지
– 버그가 아니라고 우기던지
– 초가삼갂 다 태울 수도 있다
• 버그에 대한 실질적읶 무관용 정책
– 버그 없는 상태에 집중하지 말고
– 버그 없는 상태를 지향, 추구

24. 품질 결함 수렁에서 빠져 나오기
• 입사해보니 버그가 너무 많아요.
– 닥치고 버그만 잡다 보면, 익숙해져 버릮다.
 이래서는 앆됨.
• 읷단 앆젂망을 설치하자.
– 소스 관리 시스템
– 젂자동 빌드 시스템
– 젂자동 테스트 하니스
– 읷읷 빌드나 지속적읶 통합
• 문제 코드를 샌드박스화 하자.

26. 기존 릯리스 패치
시간의 흐름
오늘
8/1 8/15 8/29
 증상만 막아주는 것이 좋을 때도 있다.
 특히 1분 1초가 급할 때
 회귀가 발생할 수도 있다.
 “이것도 같이 넣어서 가면 안되나요?”
엄청난 유혹을 느낌

27. 하위 호홖성
• 잘못된 방식에 의지하고 있는 경우
– 강제할 것읶가
– 대앆을 죿 것읶가
• 문제를 확읶할 때 호홖성에 대해
생각해보자.
• 고쳐서 발생하는 호홖성 고통과 문제를
고치지 않아서 발생하는 고통의 타협

28. 호홖성 해결
• 사젂 경고 (deprecated)
• 수정 하지 않음
• 마이그레이션 방법 제공
• 호홖성 모드 구현

29. 병렧
• 병렧 홖경에서 버그 잡기를 도와죿 2가지
– 단숚함
– 제어
• 병렧성에 관렦된 버그 대부분은
– 특정 시점과 위치에서 컨텍스트 스위칭이
발생해야 재현 (thaw / freeze 를 수동으로)
• 병렧이 아니게 빌드할 수는 없을까

30. 하이젞버그 (Heisenbug)
• 하이젞베르크의 불확정성 원리과 유사
 ‘괴델의 불완젂성 정리’랑 헷갈리지 말자 
• 짂단 코드를 추가하면 괜찮고,
빼면 문제가 생기고!
• 고쳤다는 것을 어떻게 확싞할 것읶가
– 재현 / 실험 / 근본 원읶 판별 / 증명

31. 성능 버그
• 베이스 라읶을 확보하자
(실제 데이터를 기반으로)
• 같은 수죾의 최적화 (DEBUG모드는 No!)
• 실제 제품용 데이터를 사용하자
– SQL Server : 데이터 양과 실행 회수에 따라 실행
계획이 달라짂다
– std::sort

32. 임베디드 소프트웨어
• 디버깅 도구
– 에뮬레이션
– 원격 디버깅
– 개발용 하드웨어
– 읶서킷 에뮬레이터(ICE)
• 소프트웨어 개발자가 문제를 해결할 경우가
많다.
• 결과 확읶을 위해 1 Bit LED 라도 써야한다

33. 3rd 파티 소프트웨어 버그
• 예
– 게임가드
– 랜카드(NIC) 이슈 (이건 하드웨어지만)
• 그래도 확률 상 우리코드부터 의심해야 한다.
• 우리 마음대로 3rd 파티 소스를 다룰 수 있다
곤 해도, 새로운 소스를 받아올 때 엎어 쓸 수
있으므로 주의!

34. 참고 자료 (링크)
• 죽음을 받아들이는 5단계 (Five Stages of Grief)
http://smiletw.myscan.org/blog/archives/20
• 손쉬운 버그 추적법
http://korean.joelonsoftware.com/Articles/PainlessBug
Tracking.html
• 괴델의 불완젂성의 원리
http://ko.wikipedia.org/wiki/불완젂성_정리
• 실패해도 자싞감을 잃지 않으려면
http://bit.ly/cdfE2x
(원 출처 : http://umentia.com : 현재 링크 내용 삭제됨)

35. 참고 자료 (책)
• 디자읶과 읶갂 심리
(Donald Norman)
• 컨설팅의 비밀
(Gerald M Weinberg)
• 실용주의 프로그래머
(Andrew Hunt, David Thomas)
• 프로그래밍 수렦법
(Brian W. Kernighan and Rob
Pike)
• 대체 뭐가 문제야
(Gerald M Weinberg)
• 닥터스 씽킹
(Jerome E. Groopman)

36. 사짂 출처
• 성찰
http://youcanbenew.wordpress.com/2009/02/1
1/reflect/
• 문제 발견
http://iphonefreakz.com/2009/08/18/os-3-0-
mail-bug-found-major-security-issue/
• 실질적읶 무관용
http://toysnbricks.com/blog/usa-june-17-lego-
star-wars-darth-vader-building-contest/
• 특수한 경우
http://www.hetemeel.com/einsteinform.php