예외 수집기

이전의 처리를 통해 예외를 한군데로 모을 수 있었으면 이제 다음 단계의 예외 처리 프레임워크로 들어갈 준비가 된 것이다. 프레임워크를 만든다는 것은 어찌보면 왼쪽 그림을 오른쪽 그림으로 만드는 것에 불과하다.

언뜻보기에 클래스의 무작위적인 메시지 교환에서 추상적인 공통점을 찾아내고 이를 단계적인 체인으로 풀어내는 것이다. 이를테면 웹 프레임워크는 브라우저에서 서버 프로그램까지의 과정을 쪼개고 공통점을 묶어서 몇단계의 연결된 과정으로 바꾼다. 이러한 연결된 과정으로 바꾸는 과정에서 중간중간 오른쪽의 세모 그림처럼 request의 접합점을 담당하는 클래스가 생기는데 - 웹프레임워크의 경우 Controller가 이 역활을 한다 - 이 세모 부분의 역할에 따라 프레임워크의 질이 결정된다. 여기서 제 5계를 말할 수 있는데 클래스간의 복잡한 메시지 교환을 횡으로 단계를 가지도록 바꾸면 복잡성이 대폭 감소한다. 이 단계의 과정에서 접합점 역할을 하는 단계에 주의해라.

다시 예외 얘기로 돌아가서 우리는 앞의 글에서 모든 예외가 거쳐가게 되는확장포인트를 만들었다. 중간에 현명한 처리를 할 수 있는 일부 checked exception을 제외하고 마땅한 처리방법이 없는 다른 모든 checked exception 예외와 runtime exception을 하나의 접함점으로 모으면 로그 형식이나 알람 정도 말고도 다양하게 할수 있는게 생긴다.

보통의 프로그램에서는 예외가 생각보다 많이 발생한다. 순간적으로 DB 네트웍이 막혀서 접속이 안될 수도 있고 정기적인 다운타임을 기다리기 귀찮은 누군가 몰래 프로그램을 고칠 수도 있다. "이봐 예외가 발생하지 않는 프로그램을 만들어야지" 라고 주장할 수도 있겠지만 아무리 노력해도 테스트환경에서는 잡히지 않았던 예외들이 사용자의 이상야릇한 PC환경에서는 발생하고 이러한 예외들은 실험실에서 재현하기가 아주 어렵고 사실 사용자는 귀찮기 때문에 웬만한 예외가 발생해도 보고하는 확률은 높지 않다.

보통의 경우 예외 처리 방안은 1)로그에 남긴다. 2) 어드민에게 이메일등을 통해 알린다 정도가 있을 수 있는데 이러한 방법은 모두 후속 처리에 해당한다. 즉 실제 예외가 발생한 후 상당한 시간이 지난후에야 확인이 가능하거나 혹은 지겹게 날라오는 같은 메시지에 질려서 관리자가 무시해 버리기도 해서 대응될때까지 상당한 시간이 흐른다.

두번째로 생각해 봐야 할 점은 수백메가의 예외 로그는 대부분이 중복이라는 사실이다. 넷스케이프 5.0이 처음 나왔을때 버그 리포팅 기능을 생각해보자. 전 세계 1억 2천만명이 매일 날리는 버그 리포팅을 사람이 일일히 확인해서 대응할 수 있을리가 없다.

로그에 남기거나 어드민에게 알리는 방법의 단점은 이렇게 후속처리이며 동시에 대부분의 예외는 아마도 대부분 같은 종류일터인데 사람이 일일이 확인하는 것은 비효율적 이라는 사실이다. 이런 문제를 해결하기 위해 예외 처리 프레임워크는 3가지의 주요 기능을 가져야 한다.

1) 즉시 처리가 되야 한다. 이 말은 수동적인 로그 남기기가 아닌 적극적인 처리를 말한다. 자기 수정같은 거창한 이야기가 아니라 예외가 발생했을때 과거 비슷한 패턴의 예외의 해결방안을 제공하는 시나리오를 제공한다는 말이다. 예외가 발생했을때 "알수 없는 예외가 발생했습니다." 따위는 사용자에게 전혀 도움이 되지 않는다. 사용자가 알고 싶은 것은 첫번째는 "왜 이런게 발생했지"이고 두번째는 "이걸 피하려면 어떻게 해야하나"의 이 두가지이다. 이러기 위해서는 과거 예외 발생 정보와 처리 방안이 어딘가에 저장되어 있어야 한다는 것을 말한다.

2) 예외의 발생 빈도등을 체크하여 예외를 트리아지(Triage) 분류가 가능해야 한다. 보통의 솔류션 제품이 판매되면 1개월의 로그만 모아도 수백메가의 로그 파일이 남는다. 이 로그파일에서 예외 정보는 대부분 중복된 내용일테고 그걸 일일히 살펴보는 것은 시간낭비이기 때문에 사람의 분류의 이전에 프로그램이 예외가 발생한 클래스의 패키지, 예외의 종류, 발생 빈도 등을 고려하여 오류 등급을 미리 분류해 줄 수 있어야 한다.

3) 예외가 발생했을때 자동으로 관련정보를 묶어서 제공해줄 수 있어야 한다. 이는 고객을 위해서가 아니라 이를 수정해야 하는 프로그래머를 위한 정보를 말한다. 해당 예외의 종류가 이전에도 발생한 경우가 있는가? 그에 대한 대처는 어땠는가? 해당 클래스가 이전에도 다른 예외가 발생하지 않았나? 그렇다면 그 클래스의 마지막 수정자는 누구였는가 등의 정보를 같이 제공해 주어야 한다. 또한 현재 수집할수 있는 사용자의 환경과 동작시킨 기능 등도 물론 포함되어야 한다. 사용자의 PC환경은 매우 다양하기 때문에 가능한 많은 정보를 수집해두는게 좋다. 실제로는 어떤 빌어먹을 유틸리티들이 다른 프로세스 영역에 침범함으로 오류를 발생시키기도 하기 때문에 충분하지는 않겠지만 말이다.

이 분야에 대해 조엘의 책에 따르면 자동으로 다음과 같은 자료를 수집하는걸 권장한다.
- 제품의 정확한 버전
- 운영체제 버전과 브라우저 버전
- 예외가 발생한 파일명과 행번호
- 오류 메시지
- 어떤 작업을 하고 있었는지 사용자 설명
- 필요하다면 연락 가능한 사용자 정보


단순한 분류는 사람보다 컴퓨터가 월등히 뛰어나다는 장점을 잘 활용해서 이런 과정은 자동으로 이루어져야 한다. 현재의 대부분의 버그 관리 소프트웨어는 수동으로 이루어지는데 어쩔수 없이 사람이 판단의 개입되어야 하는 일부를 제외하고 자동화 시킬수 있는 부분은 아주 많다. (사실 이 자동 예외 처리기는 AL로 만들 첫번째 소프트웨어로 생각한 것이지만 작업기간이 맞지 않아서 따로 만들고 있다.)