로깅(Logging)은 왜 해야할까?

 

해당 게시글은 SOPT 35기 8차 세미나에서 후배 기수 대상으로 로깅에 대해 발표한 내용입니다.

 

 

로깅이란

시스템이 동작할 때 시스템의 상태 및 동작 정보를 시간 경과에 따라 기록하는 것

 

 

로그 레벨 (Log Level)

로그의 레벨은 총 5가지로 구분된다.

 

Error : 예상하지 못한 심각한 문제가 발생하는 경우

• DB 연결 실패
• 예상하지 못한 예외 발생
• 필수 파일이나 리소스 누락으로 인해 애플리케이션 실행 불가

 

Warn : 애플리케이션이 정상적으로 작동하지만, 주의가 필요한 경우

• 이미 예측해서 처리한 예외에 대해 남기는 로그
• 설정 파일이 누락되었으나 기본값 사용하여 동작은 가능

 

Info : 운영에 참고할만한 사항

• 서버 애플리케이션 시작/중지
• 주요 작업의 완료 여부 (ex. 스케줄러)




Debug : 개발 단계에서 디버깅 용도

• SQL 쿼리 로깅
• 외부 API 호출 요청/응답 로깅

 

Trace : Debug 레벨보다 더 세부적인 실행 흐름을 추적하는 경우

• 반복문 내부에서 변수 값 변화 추적
• 메서드 호출 체인 상세 추적
• 복잡한 비즈니스 로직의 모든 단계 로깅

 

 

 

왜 로깅을 해야할까

왜 로깅을 해야할까에 대해 고민하기 전에 반대로 생각해보자.

 

로깅을 안하면 어떤 문제가 발생할까?

간단한 예제를 통해 알아보자.

 

 

예제1. 결제

고객에게 이런 CS 문의가 들어왔습니다.
“제가 방금 결제를 했는데 돈은 나갔는데 상품 주문은 안됐어요!”

 

이 상황에서 로깅이 제대로 되어 있지 않다면, 다음과 같은 부분을 빠르게 인지할 수 없다.

• 고객이 실제로 결제를 진행했는가?
• 결제 정보를 처리하는 시스템에서 오류가 발생했는가?
• 주문 요청이 성공적으로 처리되었으나 그 결과가 고객에게 전달되지 않았는가?
• 문제의 원인이 외부 결제 시스템에 있는가, 내부 주문 시스템에 있는가?

 

로그가 남아있다면 아래처럼 빠르게 대처할 수 있었을 것이다.

”고객님께서 실제로 결제를 진행하셨지만,
결제 정보를 처리하는 시스템에서 오류가 발생해서
돈이 저희 서비스에 묶여있는 상태네요! 제가 처리해서 상품 주문 처리 해드리겠습니다.”

 

 

예제2. 디버깅

운영중인 서비스에서 에러가 발생했다.
그런데 문제는, 에러가 발생한 메서드가 여러 API에서 공용으로 사용되고 있다.

 

이 상황에서 로깅이 제대로 되어 있지 않다면, 다음과 같은 부분을 빠르게 인지할 수 없다.

• 문제가 발생한 API는 무엇인가?
• 어떤 사용자 요청이 문제를 유발했는가?
• 요청 데이터는 정상적인 값이 들어왔는가

 

결국 이러한 문제가 발생한다.

• 문제가 발생한 메서드를 사용하는 모든 API를 일일히 점검
• 디버깅 시간과 비용이 크게 증가
• 서비스 복구 시간 지연

결론적으로 이러한 문제는 '유저 이탈'이라는 치명적인 문제로 이어질 것이다.

 

 

로깅은 시스템의 ‘블랙박스’ 다.

결국 로깅은 자동차의 블랙박스와 같은 역할을 한다는 것을 알 수 있다.

 

자동차의 블랙박스가 사고 원인을 파악하는데에 효과적인 도움을 주는 것처럼,
로깅 또한 시스템에서 발생한 문제의 원인을 파악하는데에 효과적인 도움을 준다.

이렇듯 로그는 운영에 있어서 굉장히 중요한 정보로 사용된다.

 

 

 

어디까지 로깅 해야할까

그럼 어디까지 로깅을 해야하는지에 대해서도 굉장히 고민이 될 것이다.

 

현재 상황에서 필요한 것에 대해서만 로깅하라

 

이 질문에 대한 답은 "현재 필요한 것에 대해서만 로깅하라"이다.

 

불필요한 로그를 모두 남기게 되면 아래와 같은 문제로 이어질 수 있다.

• 데이터 저장공간 낭비
• 너무 많은 로그로 인해서 분석에 어려움

 

반면 필요한 정보만 로깅하게 된다면 이와 반대로 아래와 같은 장점을 얻는다.

• 데이터 저장공간 절약
• 필요한 로그만 빠르게 확인할 수 있어 분석에 용이

 

필요한 로그는 어떻게 구분하는데요?

 

처음부터 필요한 로그를 구분하긴 어렵다. 몸으로 느껴라

 

 

동일한 로직이더라도 서비스마다 해당 로직의 중요도에 따라서 로그의 필요성은 매번 다를 것이다.

때문에 아래 방법을 통한 직접 몸으로 느끼는 방식을 추천한다.

 

1. 로그 없이 개발해보기
2. 이 부분은 로그가 있으면 좋았을텐데 느껴보기
3. 하나하나 필요한 부분에 추가해보기

이런 순서대로 직접 부딪히면서 개발해나가면 좋겠다.

API 요청/응답 로깅은 해두면 굉장히 편리해서 추천하는 편이다.
관심이 있다면 여기를 참조

 

 

 

마치며

기술 선택이든 로깅이든 결국 근거가 중요하다.

필요한 부분에 대해서 근거있게 로깅하며 개발해나갔으면 좋겠다!