사례 개요
이 사례는 약 한 달의 연속 가동 뒤에만 충돌하는 Windows 애플리케이션 문제를 다룹니다.
중요했던 것은 원인을 빨리 추측하는 일이 아니라, 어떤 관찰 지점이 있어야 원인을 신뢰성 있게 좁힐 수 있는가 를 먼저 결정하는 일이었습니다.
증상
- 장기 가동 후에만 충돌이 나타난다
- 실패의 형태만으로는 메모리·핸들·그 밖 중 무엇인지 즉시 알 수 없다
- 한 달을 기다리는 것은 비현실적이어서 재현을 압축해야 한다
제약
- 문제 경로에 카메라 재접속과 이상 동작이 얽힌다
- 정상 경로의 로그만으로는 부족하다
- 충돌 순간뿐 아니라 시간 축 위에서 자원 증가를 관찰해야 한다
관찰한 것
Handle Count,Private Bytes,Thread Count같은 하트비트 지표- 세션 시작, 재접속, 종료를 중심으로 한 경계 로그
- create/open/register 와 close/dispose/unregister 의 짝을 의식한 수명 로그
어떻게 좁혔는가
장기 운용 크래시로만 막연히 다루지 않고, 재접속과 이상 경로 주변에서 재현을 압축했습니다.
그 결과 핸들 누수 조사 로 다루는 것이 충분히 합리적이 되었습니다.
어떻게 개선했는가
- 최종 크래시 전에 증가 추세가 보이도록 감시를 강화
- 소유권 경계를 로그에서 따라가기 쉽게 정리
- 이상 경로 테스트가 뒤에 쌓일 수 있도록 결과를 정리
이 사례가 이어지는 서비스
재현이 어려운 장기 운용 장애를 대상으로 하는 장애 조사 & 근본 원인 분석, 그리고 제품 내부의 로깅·재접속 동작·운용 가시성을 개선하는 Windows 앱 개발 로 이어집니다.