[SpringBoot] 로깅을 System.out.println()으로 하면 안되는 이유

그동안 프로젝트를 하면서 log를 찍을 때 System.out.println()을 사용했다.

회사에서 처음으로 서비스를 개발할 때도 log를 찍기 위해 System.out.println()을 사용했는데, 코드리뷰에서 바로 피드백을 받을 수 있었다. 이번 포스팅에서는 왜 log를 찍기 위해 System.out.println()은 지양되어야 할까를 주제로 적기로 했다.

 

왜 편하게 표준출력이 가능한 System.out.println() 메소드를 두고 로깅 프레임워크를 사용하는 것일까?

그리고 왜 System.out.println()은 지양해야하는 것일까?

---

System.out.println()을 사용할 때의 문제점은 다음과 같다.

1. 휘발된다.

2. 에러 발생 시 추적할 수 있는 최소한의 정보가 남지 않는다.

3. 로그 출력 레벨을 사용할 수 없다.

4. 성능 저하의 원인이 될 수 있다.

 

 

1. 휘발된다.

System.out.println()은 로그가 표준 출력으로 출력된다. 즉, 파일로 저장되지 않고 휘발된다.

=> 로그는 에러가 발생한 상황을 기록하고, 추후 확인하여 문제를 진단하여 고치기 위해 사용한다.

때문에 표준 출력으로 한 번 출력되고 어디에도 저장되지 않으면 로그의 제 역할을 할 수 없다.

"로그된 데이터는 실제로 기록되어야 하지만, System.out.println()은 기록되지 않고 휘발된다."

 

2. 에러 발생 시 추적할 수 있는 최소한의 정보가 남지 않는다.

System.out.println()은 인자로 전달한 문자열만을 출력한다.

때문에 필요한 최소한의 정보인 문제발생일, 시각, 수준, 발생위치에 대해서는 기록되지 않는다.

=> 물론 이런 정보도 인자로 전달할 수 있다. 하지만 매번 그런 정보를 일일이 남기기에는 번거롭다.

 

3. 로그 출력 레벨을 사용할 수 없다.

로컬에서 개발할 때에는 디버깅을 위한 상세한 정보가 출력되어 확인할 수 있어야 한다.

하지만 상용에서 동작하는 코드는 에러가 발생할 때 문제를 진단할 수 있는 정보만을 남겨야 한다.

 

개발 시에만 사용되는 정보와 문제 상황에 대한 정보가 함께 로깅된다면,

문제 해결을 위한 정작 중요한 정보를 얻기 힘들 뿐더러,

민감한 정보를 로그로 남길 수도 있다.

또한 의미 없는 로그가 쌓여 서버 용량을 차지할 수도 있다.

 

따라서 로깅 라이브러리는 환경에 맞게 로그가 출력될 수 있도록 로그 출력 레벨이라는 기능을 제공한다.

많이 사용되는 Logback이라는 라이브러리는 TRACE, DEBUG, INFO, WARN, ERROR, FATAL을 제공한다.

하지만 System.out.println()은 제공하지 않는다. 어떤 환경에서든 동일한 로그가 출력된다.

프로덕션에서 이런 로그를 제거하려면 일일이 제거, 주석, 별도 조건문 등 번거로운 일을 해야한다.

 

4. 성능 저하의 원인이 될 수 있다.

System.out.println()의 구현을 살펴보면,

synchronized가 붙어있다. => 동기이며 순차적으로 진행되는 방식(직렬)이다.

이 때 newLine() 메소드는 임계영역(critical section)이 된다.

멀티 쓰레드 환경에서 A쓰레드가 newLine() 메소드를 실행하면, 메소드는 잠기게 된다.

다른 쓰레드는 A쓰레드가 모두 사용하고 잠금을 풀어준 뒤에서야 newLine()메소드를 실행할 수 있다.

오버헤드가 발생하는 것이다.

(여러 개의 쓰레드를 사용할 때, 사용할 수 있는 System.out.println()이 1개 밖에 없는 것임.)

 

Spring을 실행하는 Tomcat은 멀티쓰레드로 동작한다.

요청이 들어오면 쓰레드 풀에서 쓰레드를 하나 가져와 요청을 처리한다.

System.out.println()을 여러 쓰레드가 사용하면 그만큼 오버헤드가 발생하고 처리가 느려진다.

 

따라서 실제 상용에서 작동하는 코드에서는 System.out.println()을 절대 사용해서는 안된다.