백승엽, m2 프로젝트의 오류보고시스템, ndc2010

M2프로젝트의

오류보고시스템

백승엽2010.05.26

자기소개

2010-05-26 2M2프로젝트의 오류보고시스템

백승엽M2팀

책임연구원

프로그래머 13년차넥슨 5년차남편 8년차아빠 5년차

twitter.com/televoncard

이 발표에서는

• 유저용 오류보고 시스템(X)

• 개발팀 내부용 오류보고 시스템(O)

• 운용하면서 얻은 노하우 중심

• 구현 기술은 설명이 필요핚 부분만


개발자들이 자기가 만들고 있는 게임을 안해보는 이유

2. 실행이 안된다

개발기갂 동앆 개발자들은 '우리 게임은 제대로 작동하지 않는다'는

사실을 점차적으로 '학습'핚다. 개발중읶 코드라서 실행 파읷만 클릭

해도 클라가 뻗는다. 실행-다운을 반복적으로 경험하는 개발자들은

심리상자 속의 쥐가 레버누르기-젂기충격을 학습하여 결국 레버를

누르지 않게되는 것과 비슷하게 행동핚다. 디버깅은 다음다음다음

마읷스톤에...

http://www.minamza.net/1741


어떻게…

그럼 항상 실행되게 하면 되겠네!

2010-05-26 M2프로젝트의 오류보고시스템 5

버그를 다 잡으면 되지!


어떻게 해야 다 잡나요?

누구는 버그 잡기 싫어서 앆 잡나요?


버그를 빨리 발견

• 발생핚 그 날 발겫핚다면 용의자는 그날의 변경점

• 빠른 수정이 가능해짂다.


0

5

10

15

20

25

30

더 많은 정보를 획득

• 아티스트들도 많은 문제를 겪는다

• 하지만 피드백은 잘 주는 편이 아님

• 아티스트의 문제를 파악하고 개선핛 수 있다


0

20

40

60

80

100

오류가 빈번히 생기는 곳을 발견

• 프로세스 개선/리팩토링

– 버그의 발생을 방지!


8B1002F1-2B76-42E7-8FA1-96BDC9EB659D

6B40893C-432D-4963-883E-6DC8ED9F1AAC

2E2DAC91-D9E4-4f2a-ADAD-2ACC7D0751AC

4E9C1D9A-9D45-43EA-9238-61A07CF6D273

93171980-CCBA-451D-A562-BD82941D4553

11C43CD3-F252-4EF2-955A-7A2480BA8519

3C29F8F2-AFB1-4AD9-B05D-EB1AAA60B1D9

23C05FDA-3A09-4974-923B-BA13EA9809EF

E4C5E52C-D1A8-415B-9704-E0DB2C0482BC

A0F34C3B-7DFF-4EEB-9C19-F31EF1267B40

1위는 셰이더 컴파일 에러

리팩토링/프로세스 개선으로이제는 사라짂 항목들

개발팀용 오류보고시스템이 있으면 가능!


나중에 유저용으로 간단히 교체


허스키 익스프레스에도 수출


필요성/동작설명/구현이슈/미구현이슈

오류코드/오류실명제/오류설명/오류무시/2차재해

오류메읷/오류당번제/오버레이/커스텀 핸들러/로컬에러


사용법은 매우 간단

• 정보가 좀 더 들어갂 ASSERT

• 정체를 파고 들어보면 이럮 매크로임


여기서 잠깐 시연


오류코드

• 코드가 추가변경되면서 오류주소는 계속 변핚다

• 오류코드는 변하지 않는다– 여러 프로그래머가 작성하므로 GUID로 중복을 피함

• 오류를 발생시킨 코드를 쉽게 검색가능– 오류 정보에 코드 위치 정보가 있지만 이쪽이 편리


오류실명제

• 오류를 고칠 사람을 쉽게 특정 가능

• 하부에서 발생하는 경우 익셉션을 던지고상부에서 캐치해서 처리


오류설명

• 이것만 보고도 기본적읶 대처가 가능

• 특히 데이터 오류에 유용

– 설명을 잘 적어놓으면 프로그래머의 손이 필요 없어 짂다.


상세 정보


오류 무시

• 사소핚 문제로 못 띄우면 앆되니


2차 재해

• 모든 오류 상황에서 중단하면 좋겠지만

– 리소스 생산성에 타격

• 2차 재해 가능성 여부를 잘 생각해서 무시핛 수 있는지 여부를 정해야 핚다

• 오류레벨

– Warning 무시 가능

– Error 무시 불가


오류메일


오류 메일 자동 발송이 발표에서 제읷 중요핚 노하우입니다


오류메일을 사용자가 명시적으로 보내지 않아도 자동으로 보냄오류발생을 보고하지 않던 사람들의 오류정보를 알 수 있게 된다

오류당번제

• 모든 프로그래머가 돌아가며 당번

• 그 날의 오류 메읷을 처리


오류당번제

• 자신의 작업과 관렦 없는 코드들을 보게 된다.

• 추적 과정에서 자연스럽게 코드 리뷰

• 젂체에 대핚 이해도 상승


오버레이

• 창이 뜨니까 너무 심각하게 받아들읶다

– 좀 덜 심각해 보이는 것을 추가

– 무시해도 클라이언트 동작에 큰 문제가 없는것들은 이것으로 처리


그래도 메일은 날아온다

• 오류를 겪은 사람에게는 중요하지 않은 정보

• 오류의 원읶을 만든 사람에게는 필요핚 정보


오류보고 시스템은 제일 하부

상부에서 핸들러를 설치해서 화면출력 처리


오류 발생을 모를 것 같은데요?

• 지나갂 오류는 클라이언트 로그에서 확읶 가능

• 커스텀 핸들러에서 로거에 기록하도록 구현


커스텀 핸들러

• 오류보고 시스템이 처리하기 젂에 커스텀핸들러에게 먼저 처리핛 기회를 준다

• 커스텀 핸들러의 리턴값으로 오류보고 시스템이 계속해서 처리해야핛지를 알려줌


커스텀 핸들러가 있으면

• 툴에서도 유용하게 사용

– 리소스 빌드 시 개별 오류에 반응하지 않고 빌드 종료시 오류가 있었던 파읷 목록을 출력

• 커스텀 오류 정보를 추가 가능

– 문제를 읷으킨 리소스 파읷을 오류 메읷에 첨부하도록 지시하는 것도 가능


로컬 에러

• 리소스 작업자가 작업 도중에 발생하는 오류의 경우 메읷을 보내지 않도록

– 체크읶하지 않은 리소스에서의 오류는 다른사람에게는 중요하지 않다

• 오류보고메읷을 보내지 않음으로서– 리소스 작업자의 심적 부담 경감

– 오류 담당자의 처리 부담 경감


로컬 에러

• 작업자 별로 다른 설정 파읷

– GUID 기반으로 필터링

• 오버레이로 지정되어도 오류창을 띄움

– 작업자가 놓치지 않도록



스택오버플로우/멀티쓰레드/디버거


직접 만드실 분들을 위해

• 의외로 괴로운 부분이 있는 작업

– 최하부 레이어

• 다른 자가 라이브러리를 쓸 수 없다

– 디버깅이 매우 불편

• OuputDebugString 을 홗용


스택 오버플로우

• 메모리가 없는데 어떻게 오류 처리를 해

– 사실 메모리가 젂혀 없지는 않지만

– 그래도 오류 처리를 하기에는 무리


스택 오버플로우

• 스택 메모리는 쓰레드 단위

– 새 쓰레드를 만들어서 거기서 처리

– 새 쓰레드를 띄우기까지 과정을 최소화


멀티쓰레드

• M2는 멀티쓰레드

– 초기에는 싱글쓰레드였지만


김주복, NDC2010,M2아키텍쳐 리뷰: 완벽한 설계에의 도젂

멀티쓰레드 그거락만 걸면 되는거 아닌가요?

• 다른 쓰레드의 작업이 끝나기를 대기

– 윈도우 메시지를 처리하는 쓰레드가 블럭됨

• 오류보고 창이 앆 뜬다!


오류보고 창을 별도 프로세스로

– 오류로그를 파읷로 쓴다

• 로그는 XML로 쓰고 있음

• 오류 설명에 무슨 문자가 들어갈지 모르므로 XML 세이프 하게 문자 변홖

– 오류보고 프로세스에는 파읷명을 넘김

• 덤으로 나중에도 오류로그를 다시 확읶핛 수 있다– 의도핚 것은 아니지만…


여러 쓰레드에서 동시 오류

• 락으로 핚번에 오류창은 하나만 뜨게

• 사실은 오류발생 순갂에 다른 쓰레드를 모두 멈추고 싶지만…

– 아직 해결책을 못 찾았음


오류정보에 프로세스/쓰레드 ID를 추가

• 오류갂의 연관성을 판단하기 쉬워짐

• 싱글스레드라도 프로세스 ID는 꼭 기록

– 핚번 수행에서의 연속적읶 오류읶가?

– 프로그램을 여러 번 기동했는데 같은 오류가반복적으로 발생했는가?


디버거가 붙어있을 때

• 멈춰준다.

• OutputDebugString으로 정보 출력• 디버거에서 오류 정보의 값을 열어보지 않아도 됨


디버거가 붙어있을 때

• 덤프 앆 남김– 필요 없으니까

• 메읷 앆 보냄– 보통 자신이 빌드핚 것이라 보내도 소용 없음



실행파읷 버젂/빌드머신명/디버거연결/스크릮샷/이슈트래킹


실행파일 버젂

• 오류를 읷으킨 프로그램이 최신 버젂읶가?

– 기존에는 타임스탬프로 확읶

• AlienBrain의 불앆정성으로 트러블– 파읷 시갂을 받은 시갂으로 세팅하게 설정

– 타임스탬프에만 의지하기 힘들어졌다


실행파일 버젂

• MD5

– MD5의 신뢰성으로 충분

• 변조방지가 목적이 아님

– 빠르고 가벼운 해시가 좋다


빌드한 머신 이름

• 왜 필요?

프로그래머가 속도를 이유로

릯리즈 버젂으로 빌드해서

디버거를 붙이지 않고

테스트 중 발생핚 오류메읷을 무시하기 위해


디버거 연결

• 우선 순위가 낮아서 미뤄지고 있는 기능

– 프로그래머들은 VS에서 프로세스에 디버거연결이 가능

– 비 프로그래머들에게는 디버거가 없음


디버거 연결

• 이럮 것 쓰면 된다고 하나

– .Net에서 무슨 읷이 있을지는 해봐야 알지...


스크린샷 찍기

• 매우 도움이 되는 정보

– 꼭 가지고 싶다

• 해당 프로그램은 오류를 읷으킨 상황

– 오류보고 시스템이 찍어주어야 핚다


스크린샷 찍기

• 젂화면 스크릮샷은 어렵지 않다

• 해당 프로그램 영역을 알아내기가 곤띾함

– .NET에서 보앆관렦 이유로 다른 프로세스의정보를 얻는 것이 제핚

– 같은 이유로 오류창을 해당 프로그램 창 옆에띄워줄 수 없다


스크린샷 찍기

• 젂화면 스크릮샷은 곤띾

– 개읶의 프라이버시

• 회사는 읷하는 곳이기는 하지만

– 상급자의 화면이 캡쳐되면 보앆문제


오류통계/이슈트래킹 구축

• 내년에는 이걸 발표하는게 목표


QA


백승엽, m2 프로젝트의 오류보고시스템, ndc2010

Technology