다양한 로깅 레벨
로그에는 다양한 레벨이 있다. 위의 표에서 Event Level이라고 표시된 부분에서 볼 수 있듯 TRACE, DEBUG, INFO, WARN, ERROR, FATAL이 있다. 이름에서부터 알 수 있듯, 각 레벨은 로그를 남기는 이벤트의 수준을 나타낸다. 여기에 이제 로그를 표시할 설정 레벨을 정해 원하는 수준 이상의 로그만 볼 수 있다. 예를 들어 설정 레벨을 INFO로 한다면, INFO이상 이벤트 수준의 로그만 표시된다.
이렇게 로그 레벨이 있어 다양한 환경에서 원하는 수준의 로그를 적절히 사용할 수 있다. 예를 들어 로컬 환경에서는 개발의 편의성을 위해 로깅 설정을 DEBUG로 하여 더 많은 정보를 볼 수 있도록 할 수 있다. 프로덕션 환경에서는 INFO로 하여 로그가 너무 많아 오히려 방해가 되는 문제를 막을 수 있고, 또 ERROR 레벨 로그 발생 시 알림이 오도록 설정하는 등 로그 레벨을 활용할 수도 있다.
어떤 로깅 레벨을 사용해야 할까?
내가 주로 많이 본 로깅 레벨은 위 중에서도 DEBUG, INFO, WARN, ERROR인데, 처음에는 도대체 언제 어떤 로그 레벨을 사용할지 헷갈렸다. 백엔드는 멀쩡한데 요청이 잘못되어서 4XX HTTP 상태코드를 응답했다면, API는 정상이니까 정보 기록을 위해서 INFO 수준 로그를 남겨야할까 아니면 일단 오류니까 ERROR를 남겨야할까? 그것도 아니면 그 중간인 WARN으로 남겨야할까? 세상사 모든것이 그렇듯 이것도 케바케이다. 단순히 저 상황정보만으로는 정하기 어렵다.
중요한 것은 논리적 이유와 일관성
위의 상황에 어떤 로그 레벨을 사용할지 생각해보기 위해 더 많은 상황에 대한 정보를 알아보자. 프론트엔드에서 요청을 보내기전에 입력 값을 검증 한다면, 어느 정도는 검증된 입력이 백엔드 API에 들어올 것이다. 만약 잘못된 입력이 들어왔다면 다음 상황 중 하나일 수 있다. 1) 프론트엔드에서 검증하지 못한 값이 있다. 2) 일반적인 프론트엔드를 통한 사용법이 아니라 다른 경로로 요청이 들어오고 있다. 1번은 사람의 실수 또는 프론트와 백엔드의 소통 문제로 충분히 발생할 수 있는 상황이다. 또한 앞서 말했듯 API는 정상적으로 작동했으니 에러나 버그를 표시하기 위한 ERROR 레벨은 너무 높다고 생각한다. 2번의 경우도 충분히 발생할 수 있다. 이것이 악의적인 누군가에 의한 요청일 수도 있다. 하지만 이를 떠나서, 아무리 프론트엔드에서 입력을 검증한다고 해도 당연히 백엔드에서도 요청을 검증해야한다. 어찌됐든 잘못된 요청이 많이 들어온다면 이는 충분히 예의 주시할만하다고 생각해 정보를 표현하기 위한 INFO 레벨은 너무 높다고 생각한다. 결국 위 상황이라면 나는 WARN 레벨로 로깅을 할 것이다.
개개인 또는 프로젝트에 따라 어떤 레벨이 어떤 수준의 상황에 적합한지는 모두 다를 수 있다. 중요한 것은 레벨을 선택할때 논리적인 이유를 가지고 일관성 있게 하는 것이다. 개인 프로젝트가 아닌 이상 여러 사람이 로그를 남길 것이므로, 이에대해 구성원이 공통적인 시각을 가질 수 있도록 컨벤션을 정하는 것도 중요할 것 같다. 결국 로그는 문제가 발생했을 때 쉽게 문제의 원인을 파악하고 해결하기 위함이므로 일관성 있는 로그는 아주 중요하다.
로깅 메시지의 중요성도 잊지 말자
로그 메시지의 중요성도 잊어서는 안된다. 아무리 논리적이고 일관성있게 로깅 레벨을 정해 로그를 남겼다고 하더라도, 결국 남은 메시지가 별로 도움이 되지 않는다면 큰 의미가 없다. 디버깅에 용이하도록 충분한 정보를 남기고, 로그를 찾는데 불편함이 없도록 하나의 문제는 한줄로 남기자.
// 블로그 글을 생성하는 요청에서 잘못된 제목 값으로 예외 발생한 경우
// 도움이 덜 되는 로그
log.warn(e.getMessage())
// 조금 더 도움 되는 로그
log.warn("POST:CREATE:INVALID_TITLE. userId={}, invalidTitle={}, message={}", e.getUserId(), e.getInvalidTitle(), e.getMessage(), e)