3. 이 발표에서는
• 유저용 오류보고 시스템(X)
• 개발팀 내부용 오류보고 시스템(O)
• 운용하면서 얻은 노하우 중심
• 구현 기술은 설명이 필요한 부분만
2010-05-26 3M2프로젝트의 오류보고시스템
4. 개발자들이 자기가 만들고 있는 게임을 안해보는 이유
2. 실행이 안된다
개발기간 동안 개발자들은 '우리 게임은 제대로 작동하지 않는다'는
사실을 점차적으로 '학습'한다. 개발중인 코드라서 실행 파일만 클릭
해도 클라가 뻗는다. 실행-다운을 반복적으로 경험하는 개발자들은
심리상자 속의 쥐가 레버누르기-전기충격을 학습하여 결국 레버를
누르지 않게되는 것과 비슷하게 행동한다. 디버깅은 다음다음다음
마일스톤에...
http://www.minamza.net/1741
2010-05-26 4M2프로젝트의 오류보고시스템
17. 오류코드
• 코드가 추가변경되면서 오류주소는 계속 변한다
• 오류코드는 변하지 않는다
– 여러 프로그래머가 작성하므로 GUID로 중복을 피함
• 오류를 발생시킨 코드를 쉽게 검색가능
– 오류 정보에 코드 위치 정보가 있지만 이쪽이 편리
2010-05-26 17M2프로젝트의 오류보고시스템
18. 오류실명제
• 오류를 고칠 사람을 쉽게 특정 가능
• 하부에서 발생하는 경우 익셉션을 던지고
상부에서 캐치해서 처리
2010-05-26 18M2프로젝트의 오류보고시스템
19. 오류설명
• 이것만 보고도 기본적인 대처가 가능
• 특히 데이터 오류에 유용
– 설명을 잘 적어놓으면 프로그래머의 손이 필
요 없어 진다.
2010-05-26 19M2프로젝트의 오류보고시스템
21. 오류 무시
• 사소한 문제로 못 띄우면 안되니
2010-05-26 M2프로젝트의 오류보고시스템 21
22. 2차 재해
• 모든 오류 상황에서 중단하면 좋겠지만
– 리소스 생산성에 타격
• 2차 재해 가능성 여부를 잘 생각해서 무시
할 수 있는지 여부를 정해야 한다
• 오류레벨
– Warning 무시 가능
– Error 무시 불가
2010-05-26 M2프로젝트의 오류보고시스템 22
24. 오류 메일 자동 발송
이 발표에서 제일 중요한 노하우입니다
2010-05-26 M2프로젝트의 오류보고시스템 24
오류메일을 사용자가 명시적으로 보내지 않아도 자동으로 보냄
오류발생을 보고하지 않던 사람들의 오류정보를 알 수 있게 된다
25. 오류당번제
• 모든 프로그래머가 돌아가며 당번
• 그 날의 오류 메일을 처리
2010-05-26 25M2프로젝트의 오류보고시스템
26. 오류당번제
• 자신의 작업과 관련 없는 코드들을 보게 된다.
• 추적 과정에서 자연스럽게 코드 리뷰
• 전체에 대한 이해도 상승
2010-05-26 M2프로젝트의 오류보고시스템 26
27. 오버레이
• 창이 뜨니까 너무 심각하게 받아들인다
– 좀 덜 심각해 보이는 것을 추가
– 무시해도 클라이언트 동작에 큰 문제가 없는
것들은 이것으로 처리
2010-05-26 27M2프로젝트의 오류보고시스템
28. 그래도 메일은 날아온다
• 오류를 겪은 사람에게는 중요하지 않은 정보
• 오류의 원인을 만든 사람에게는 필요한 정보
2010-05-26 M2프로젝트의 오류보고시스템 28
29. 오류보고 시스템은 제일 하부
상부에서 핸들러를 설치해서 화면출력 처리
2010-05-26 M2프로젝트의 오류보고시스템 29
30. 오류 발생을 모를 것 같은데요?
• 지나간 오류는 클라이언트 로그에서 확인 가능
• 커스텀 핸들러에서 로거에 기록하도록 구현
2010-05-26 M2프로젝트의 오류보고시스템 30
31. 커스텀 핸들러
• 오류보고 시스템이 처리하기 전에 커스텀
핸들러에게 먼저 처리할 기회를 준다
• 커스텀 핸들러의 리턴값으로 오류보고 시
스템이 계속해서 처리해야할지를 알려줌
2010-05-26 31M2프로젝트의 오류보고시스템
32. 커스텀 핸들러가 있으면
• 툴에서도 유용하게 사용
– 리소스 빌드 시 개별 오류에 반응하지 않고 빌
드 종료시 오류가 있었던 파일 목록을 출력
• 커스텀 오류 정보를 추가 가능
– 문제를 일으킨 리소스 파일을 오류 메일에 첨
부하도록 지시하는 것도 가능
2010-05-26 32M2프로젝트의 오류보고시스템
33. 로컬 에러
• 리소스 작업자가 작업 도중에 발생하는 오
류의 경우 메일을 보내지 않도록
– 체크인하지 않은 리소스에서의 오류는 다른
사람에게는 중요하지 않다
• 오류보고메일을 보내지 않음으로서
– 리소스 작업자의 심적 부담 경감
– 오류 담당자의 처리 부담 경감
2010-05-26 33M2프로젝트의 오류보고시스템
34. 로컬 에러
• 작업자 별로 다른 설정 파일
– GUID 기반으로 필터링
• 오버레이로 지정되어도 오류창을 띄움
– 작업자가 놓치지 않도록
2010-05-26 M2프로젝트의 오류보고시스템 34
36. 직접 만드실 분들을 위해
• 의외로 괴로운 부분이 있는 작업
– 최하부 레이어
• 다른 자가 라이브러리를 쓸 수 없다
– 디버깅이 매우 불편
• OuputDebugString 을 활용
2010-05-26 M2프로젝트의 오류보고시스템 36
37. 스택 오버플로우
• 메모리가 없는데 어떻게 오류 처리를 해
– 사실 메모리가 전혀 없지는 않지만
– 그래도 오류 처리를 하기에는 무리
2010-05-26 37M2프로젝트의 오류보고시스템
38. 스택 오버플로우
• 스택 메모리는 쓰레드 단위
– 새 쓰레드를 만들어서 거기서 처리
– 새 쓰레드를 띄우기까지 과정을 최소화
2010-05-26 38M2프로젝트의 오류보고시스템
39. 멀티쓰레드
• M2는 멀티쓰레드
– 초기에는 싱글쓰레드였지만
2010-05-26 M2프로젝트의 오류보고시스템 39
김주복, NDC2010,
M2아키텍쳐 리뷰: 완벽한 설계에의 도전
40. 멀티쓰레드 그거
락만 걸면 되는거 아닌가요?
• 다른 쓰레드의 작업이 끝나기를 대기
– 윈도우 메시지를 처리하는 쓰레드가 블럭됨
• 오류보고 창이 안 뜬다!
2010-05-26 M2프로젝트의 오류보고시스템 40
41. 오류보고 창을 별도 프로세스로
– 오류로그를 파일로 쓴다
• 로그는 XML로 쓰고 있음
• 오류 설명에 무슨 문자가 들어갈지 모르므로 XML
세이프 하게 문자 변환
– 오류보고 프로세스에는 파일명을 넘김
• 덤으로 나중에도 오류로그를 다시 확인할 수 있다
– 의도한 것은 아니지만…
2010-05-26 M2프로젝트의 오류보고시스템 41
42. 여러 쓰레드에서 동시 오류
• 락으로 한번에 오류창은 하나만 뜨게
• 사실은 오류발생 순간에 다른 쓰레드를 모
두 멈추고 싶지만…
– 아직 해결책을 못 찾았음
2010-05-26 42M2프로젝트의 오류보고시스템
43. 오류정보에 프로세스/쓰레드 ID를 추가
• 오류간의 연관성을 판단하기 쉬워짐
• 싱글스레드라도 프로세스 ID는 꼭 기록
– 한번 수행에서의 연속적인 오류인가?
– 프로그램을 여러 번 기동했는데 같은 오류가
반복적으로 발생했는가?
2010-05-26 M2프로젝트의 오류보고시스템 43
44. 디버거가 붙어있을 때
• 멈춰준다.
• OutputDebugString으로 정보 출력
• 디버거에서 오류 정보의 값을 열어보지 않아도 됨
2010-05-26 44M2프로젝트의 오류보고시스템
45. 디버거가 붙어있을 때
• 덤프 안 남김
– 필요 없으니까
• 메일 안 보냄
– 보통 자신이 빌드한 것이라 보내도 소용 없음
2010-05-26 45M2프로젝트의 오류보고시스템
47. 실행파일 버전
• 오류를 일으킨 프로그램이 최신 버전인가?
– 기존에는 타임스탬프로 확인
• AlienBrain의 불안정성으로 트러블
– 파일 시간을 받은 시간으로 세팅하게 설정
– 타임스탬프에만 의지하기 힘들어졌다
2010-05-26 47M2프로젝트의 오류보고시스템
48. 실행파일 버전
• MD5
– MD5의 신뢰성으로 충분
• 변조방지가 목적이 아님
– 빠르고 가벼운 해시가 좋다
2010-05-26 M2프로젝트의 오류보고시스템 48
49. 빌드한 머신 이름
• 왜 필요?
프로그래머가 속도를 이유로
릴리즈 버전으로 빌드해서
디버거를 붙이지 않고
테스트 중 발생한 오류메일을 무시하기 위해
2010-05-26 49M2프로젝트의 오류보고시스템
50. 디버거 연결
• 우선 순위가 낮아서 미뤄지고 있는 기능
– 프로그래머들은 VS에서 프로세스에 디버거
연결이 가능
– 비 프로그래머들에게는 디버거가 없음
2010-05-26 50M2프로젝트의 오류보고시스템
51. 디버거 연결
• 이런 것 쓰면 된다고 하나
– .Net에서 무슨 일이 있을지는 해봐야 알지...
2010-05-26 M2프로젝트의 오류보고시스템 51
52. 스크린샷 찍기
• 매우 도움이 되는 정보
– 꼭 가지고 싶다
• 해당 프로그램은 오류를 일으킨 상황
– 오류보고 시스템이 찍어주어야 한다
2010-05-26 52M2프로젝트의 오류보고시스템
53. 스크린샷 찍기
• 전화면 스크린샷은 어렵지 않다
• 해당 프로그램 영역을 알아내기가 곤란함
– .NET에서 보안관련 이유로 다른 프로세스의
정보를 얻는 것이 제한
– 같은 이유로 오류창을 해당 프로그램 창 옆에
띄워줄 수 없다
2010-05-26 M2프로젝트의 오류보고시스템 53
54. 스크린샷 찍기
• 전화면 스크린샷은 곤란
– 개인의 프라이버시
• 회사는 일하는 곳이기는 하지만
– 상급자의 화면이 캡쳐되면 보안문제
2010-05-26 M2프로젝트의 오류보고시스템 54
