[Java] printStackTrace()를 사용하면 안되는 이유

---

printStackTrace()를 사용하면 안되는 이유

---

1. 오류 출력 대상의 불확실성

'System.err'는 'System.setErr()'를 통해 재설정될 수 있으므로, 오류 출력이 실제로 어디로 가는지 확실하지 않다. 이는 로그가 예상치 못한 위치로 출력되어 디버깅 및 문제 추적을 어렵게 만들 수 있다.

 

2. 높은 오버헤드

printStackTrace는 내부적으로 동기화(synchronized)를 사용하며, 성능 저하를 유발할 수 있다.

 

3. 보존 정책 부재

printStackTrace로 출력된 로그는 별도의 보존 정책을 설정할 수 없다. 기본적으로 로그는 응용 프로그램의 생명 주기와 함께 소멸하며, 파일 저장이나 전송, 필터링이 불가능하다. 이는 중요한 오류 로그가 손실될 가능성을 높인다.

 

4. 보안성 저하

printStackTrace는 예외의 스택 트레이스를 그대로 출력하기 때문에 내부 메서드 호출 정보와 구조가 외부에 노출될 수 있다. 이러한 정보는 공격자에게 프로그램의 취약점을 분석할 단서를 제공할 수 있다. 특히, 민감한 시스템에서는 printStackTrace를 사용하는 것이 보안상 위험하다.

 

 

[ 'synchronized'의 오버헤드]

스레드 경합: 여러 스레드가 임계 구역에 접근하려고 할 때 문맥 전환 비용이 발생
락 관리 비용: JVM이 객체의 모니터 락을 관리하는 데 추가적인 리소스를 소모
비효율적인 동기화: 불필요한 락 사용으로 병렬 처리 성능 저하

 

 

권장 대안 : 로깅 라이브러리 사용

---

logback, slf4j, java.util.logging, log4j2 등 로그가 기록되는 위치와 보존 정책을 설정할 수 있는 로깅 라이브러리를 사용하는 것이 좋다.

 

이유는 다음과 같다.

1. 안정성과 성능 개선

로깅 라이브러리는 성능 최적화 및 스레드 안정성을 보장한다. printStackTrace와 달리 스레드 안전한 동기화 처리와 빠른 로깅 처리가 가능하다.

 

2. 로그 출력 위치 및 포맷 제어

로깅 라이브러리를 사용하면 콘솔, 파일, 원격 서버 등 다양한 출력 위치 설정이 가능하다. 또, 로그 포맷 커스터마이징 기능으로 가독성과 분석성을 높일 수 있다.

 

3. 로그 보존 정책 설정

로깅 라이브러리를 활용해 로그 롤링, 압축, 삭제 정책 및 로그 보존 주기를 설정하고, 디스크 공간 관리 정책을 통해 리소스를 효율적으로 관리한다.

 

4. 보안성 강화

로깅 라이브러리를 사용하여 로그 출력 시 민감한 정보를 마스킹 처리하는 등의 보안 처리가 가능하다. 사용자 에러 메시지에는 불필요한 스택 트레이스를 노출하지 않도록 커스터마이징이 가능하다.

 

5. 확장성과 유지보수성

대부분의 로깅 라이브러리는 플러그인 기반 아키텍처를 사용하여 필요에 맞게 확장이 가능하다. 프로젝트 요구사항에 맞는 Log4j2, SLF4J, Logback 등을 선택적으로 사용할 수 있다.

 

 

[추천 로깅 라이브러리]

SLF4J: 표준화된 로깅 인터페이스
Logback: SLF4J의 기본 구현으로 성능과 기능이 뛰어남
Log4j2: 고성능 비동기 로깅 시스템