java에서 println()을 사용하면 안되는 이유

몇 일 전, 긴 공백기를 지나 새로운 회사에 입사하게 되었습니다. 다행히도 저를 불러주는 곳이 있었고, 그 기회를 잡게 되었습니다. 해당 회사는 주로 SI 프로젝트를 수행하지만, 자체 솔루션도 함께 운영하고 있는 것으로 보입니다. 아직 구체적으로 어떤 프로젝트에 투입될지는 정해지지 않았습니다. 사전에 코드를 간단히 살펴보던 중, 로그를 println()으로 출력하는 방식이 사용되고 있는 것을 확인했습니다. 감각적으로는 println()을 로깅 용도로 사용하는 것이 적절하지 않다는 것을 알고 있었고, 실제로도 사용하지 않고 있었습니다. 다만, 왜 사용하면 안 되는지에 대해서는 명확하게 정리되어 있지 않았습니다. 그래서 출근 전에, println()을 로그로 사용하는 것이 왜 적절하지 않은지에 대해 스스로 정리하고 학습해보려고 합니다.

println을 어째서 사용하지 말라고 하는걸까?

println()은 출력 도구이지 로깅 도구가 아니기 때문입니다.
그 차이는 운영환경에서 꽤 많이 들어납니다.

성능 문제

System.out.println()은 내부적으로 동기화가 걸려 있습니다.
즉, 여러 스레드가 동시에 호출하면 병목이 생깁니다.

그렇다면, synchronized를 걸게 되면 어째서 성능 문제가 발생할까요?
동기화가 걸린다는 것은 스레드와 밀접하게 연결된 개념입니다. synchronized가 적용된다는 것은 여러 스레드가 동시에 접근하더라도, 한 번에 하나의 스레드만 해당 작업을 수행하도록 보장한다는 의미입니다. 이러한 구조는 데이터의 일관성을 맞추는 데에는 유리하지만, 동시에 여러 스레드를 직렬화시키기 때문에 성능 저하의 원인이 될 수 있습니다. 특히 요청이 많은 환경에서는 스레드들이 락을 획득하기 위해 대기하게 되고, 그로 인해 전체 처리량이 감소하는 병목 현상이 발생합니다.

그렇다면 Java는 왜 이러한 선택을 했을까요? 그 이유는 println()의 목적이 성능이 아닌 정확한 출력에 있기 때문입니다.

출력은 단순히 데이터를 내보내는 행위가 아니라, 메시지의 형태를 유지한 채 온전히 전달되는 것이 중요합니다. 만약 동기화가 없다면 여러 스레드가 동시에 출력하면서 문자열이 서로 뒤섞일 수 있습니다. 이 경우 출력 자체가 사라지는 것은 아니지만, 문장이 깨져 의미를 해석할 수 없는 상태가 될 수 있습니다. 따라서 Java는 출력의 일관성을 보장하기 위해 synchronized를 적용했고,
그 결과 각 출력이 원자적으로 실행되도록 설계되었습니다.

로그 레벨이 존재하지 않음

로그 레벨이 존재하지 않는다는 점도 중요한 문제입니다.
println()은 단순히 메시지를 출력하는 도구이기 때문에, 출력되는 정보에 대한 구분이 존재하지 않습니다.

즉, 어떤 로그가 단순한 정보인지, 디버깅을 위한 것인지, 혹은 실제 장애 상황을 나타내는 것인지 판단하기 어렵습니다.

반면, 로깅 프레임워크를 사용하면 debug, info, warn, error와 같이 로그의 성격에 따라 레벨을 나누어 관리할 수 있습니다.
이를 통해 운영 환경에서는 특정 레벨 이상의 로그만 출력하도록 설정하는 등, 상황에 맞게 로깅을 제어하는 것이 가능합니다.

하지만 println()은 이러한 제어가 불가능합니다.
출력 여부를 조정하려면 결국 코드 수정이 필요하며, 경우에 따라서는 조건문을 추가하는 방식으로 억지스럽게 제어해야 하는 상황이 발생할 수 있습니다.

또한 로깅 프레임워크를 활용하면, 이러한 로그를 단순 콘솔 출력이 아닌 파일로 저장하고 관리하는 것도 가능해집니다.
이를 통해 로그를 지속적으로 보관하거나, 장애 분석 및 모니터링에 활용할 수 있습니다.

결론

얼마나 빠르게 만들려고 했는지는 모르겠지만, 생각보다 코드가 엉망이었습니다. 패키지 구조는 상황에 따라 달라질수 있다고 여겨지지만 로깅만큼은 참을 수 없었습니다. 그래서 왜 println()을 사용하면 안되는지에 대해 학습을 진행하였습니다. 다음에는 로깅 프레임워크를 어떻게 사용하면 좋은지에 대해 학습해보겠습니다.