[Android] 로그에 대한 개인적인 생각

개발자라면 업무 중에 무조건 볼 수 밖에 없는 것이 로그다. 개발을 하면서 로그를 좀 더 현명하게 사용할 수 있지 않을까라는 생각 때문에 이 글을 쓰게 되었다.(안드로이드 기준이지만 다른 분야에도 적용가능한 부분일 듯......)

 

로그에 대해 아무런 생각이 없었을 때

- 단순하게 디버깅을 위한 용도로 많이 사용

- 안드로이드의 Logcat에서 내가 찍은 Debug 로그와 죽을 때 받는 Error 로그들만 주로 확인.

 

아마 대부분 초보 개발자 분들이나 혹은 구현이 목표인 개발자 분들은 로그를 위와 같이 생각하고 대하지 않을까 싶다.

하지만 서비스를 운영하고 유지보수하게 되면 위와 같이 생각할 경우 매일 버그와 뒹굴다가 지치는데 많은 힘을 쏟게 되는 경우가 흔한 것 같다.(정말 잘 개발하시는 분이 아니고서야......)

 

1~2년차 때 실서비스를 운영해보면서 버그에 크게 데인 경험이 있고 나서 로그에 대한 생각이 좀 바뀌었는데 그 생각은 다음과 같다.

 

- 로그의 Level을 적극 활용할 것

여태까지 접했던 초보 개발자분들의 경우 디버깅을 하기 위해 단순히 Log.d를 많이 썼었다. 그리고 색깔이 보기 좋다고 Log.e를 쓰신 분들도 있었다. 당장 개발하긴 편하겠지만 나중에는 해당 Exception이 어떤 수준의 위험성을 가지고 있는지 판단하기 쉽지 않다.

안드로이드 로그 Level에는 Verbose, Debug, Info, Warning, Error, Assert가 있으며 개인적으로는 Debug, Info, Warning, Error, Assert까지 쓰는데 쓰는 용도는 다음과 같이 쓰고 있다.(개인 차가 있을 수 있음)

Debug : 디버깅을 위해 임시적으로 쓰는 경우 Info : 어떤 기능의 진행 단계를 표시하는 경우(예 : Activity, Fragment의 LifeCycle 혹은 복잡한 기능의 단계 표시 등) Warning : 기능 수행 중 어떤 오류로 인해 Exception이 발생했고 try catch 구문에 해당 Exception에 대한 처리가 있는 경우(예 : 인앱 결제 라이브러리에서 결제 에러가 발생한 경우 사용자에게 결제 에러가 발생했음을 알림) Error : 기능 수행 중 어떤 오류로 인해 Exception가 발생했고 try catch 구문에 해당 Exception에 대한 처리가 없는 경우(단순히 로그 찍는 건 의미가 없음) Assert : 해당 Exception은 발생하면 안 되는 경우. 안드로이드에서는 Log.wtf가 해당(예 : 데이터가 무조건 있어야 하는 상황인데 없는 상황이 발생하는 경우)

위와 같은 의미로 쓴다면 버그가 발생했을 때 어느 단계에서 발생했는지 그리고 해당 Exception에 대한 위험성에 대해서도 어느 정도 파악할 수 있을 것이다.

 

- 단순하게 Exception을 찍는 것이 아닌 그 상황에서 필요한 데이터 혹은 정보 그리고 설명까지 같이 포함할 것

보통은 Exception에 대해서 찍고 끝내는 경우가 많을 것이다. 하지만 그 Exception이 왜 발생했는지에 대한 정보는 포함하지 않을 경우 발생 원인을 모르기 때문에 그 상황을 재현해야하는 수고를 할 수 밖에 없다. 특히 그 상황을 재현하기가 어려운 경우에는 그 버그가 당신을 끝까지 괴롭힐 것이다. 그래서 보통은 해당 Exception과 그 Exception은 어떤 의미를 가지는지 그리고 그 상황에 대한 데이터를 같이 첨부한다.

예 : Type에는 1, 2, 3이 있고 나머지는 들어오지 말아야 하는 경우

switch (type) {
	case 1:
    	// Type이 1인 경우 처리
	    break;
    case 2:
    	// Type이 2인 경우 처리
	    break;
    case 3:
    	// Type이 3인 경우 처리
        break;
    default:
    	Log.wtf(TAG, "Unknown Type! type=" + type, new Exception("Unknown Type!");
}

 

위와 같은 기준으로 로그를 찍다보면 버그를 찾거나 혹은 Exception의 위험성을 판단할 때 도움이 좀 더 되지 않을까 싶다. 끝.