자바(Java) 기반의 스프링(Spring)이나 스프링 부트(Spring Boot) 웹 애플리케이션을 배포할 때 가장 많이 사용하는 오픈소스 웹 애플리케이션 서버(WAS)가 바로 아파치 톰캣(Apache Tomcat)입니다. 톰캣은 전 세계 수많은 엔터프라이즈 시스템의 기반을 담당하고 있을 정도로 안정적이지만, 운영 도중 어플리케이션 코드가 꼬이거나 데이터베이스 연결 스트림이 끊어지면 웹페이지에 접속 장애를 일으킵니다.
톰캣 환경에서 발생한 내부 연산 에러나 자바 가상머신(JVM)의 치명적인 장애 원인을 밝혀내기 위해서는 톰캣이 실시간으로 출력하는 표준 시스템 로그 파일의 내부를 들여다보아야 합니다. 특히 모든 자바 에러 스택 트레이스가 집약되는 catalina.out 파일의 제어는 인프라 관리의 핵심입니다. 본 가이드에서는 우분투 환경에서 톰캣 로그를 실시간으로 확인하는 방법과 대용량 로그 파일로 인한 디스크 장애를 방지하는 관리 노하우를 상세히 정리합니다.
1. 톰캣 로그의 심장: catalina.out 파일의 개념 이해
톰캣 서버를 구동하면 내부적으로 여러 가지 종류의 로그 파일이 생성됩니다. localhost_access_log 포맷의 접속 기록 파일이나 관리자 전용 manager 로그 등이 있지만, 장애 조치(트래블슈팅) 관점에서 가장 중요한 파일은 단연 catalina.out입니다.
catalina.out 파일은 톰캣 카탈리나 서블릿 컨테이너가 구동되면서 내뱉는 모든 표준 출력(System.out)과 표준 에러(System.err) 스트림을 통째로 받아서 기록하는 일종의 통합 쓰기 파일입니다. 개발자가 소스 코드 내에 심어둔 e.printStackTrace() 형태의 자바 예외 처리 메시지나 스프링 프레임워크의 내부 로깅 라이브러리(Logback, Log4j2 등)가 쏟아내는 실시간 에러 기록이 모두 이 한 파일에 누적됩니다. 따라서 백엔드 어플리케이션이 뻗었을 때 가장 먼저 점검해야 하는 핵심 기지입니다.
2. 톰캣 내부 에러 실시간 추적: tail -f 명령어 활용법
운영 중인 웹사이트에 갑자기 에러가 발생하거나 사용자가 특정 요청을 보냈을 때 백엔드 내부에서 자바 예외가 터지는지 실시간으로 모니터링하려면 리눅스의 tail -f 명령어를 사용해야 합니다.
우분투 환경에서 패키지 수동 설치 또는 공식 바이너리 압축 해제를 통해 톰캣을 구축했다면, 표준 로그 디렉터리 경로는 대개 /var/log/tomcat9/ (또는 톰캣 버전 숫자에 따른 경로)이거나 설치 폴더 하위의 logs/ 디렉터리 매핑을 따릅니다.
터미널을 열고 아래 명령어를 입력하여 실시간 로그 모니터링을 시작합니다.
Bash
tail -f /var/log/tomcat9/catalina.out
만약 스프링 부트 어플리케이션이 구동되는 시점의 대규모 초기 로딩 로그(Bean 생성 과정 등)부터 흐름을 파악하고 싶다면, 화면에 미리 뿌려줄 줄 수를 지정하는 -n 옵션을 결합하는 것이 실무 팁입니다.
Bash
tail -n 200 -f /var/log/tomcat9/catalina.out
이렇게 하면 이전 기록 200줄을 먼저 화면에 출력한 상태에서, 사용자가 웹사이트를 클릭할 때마다 실시간으로 찍히는 데이터베이스 쿼리 로그나 널 포인터 예외(NullPointerException) 같은 자바 에러 스택 트레이스를 실시간 영상 보듯 추적할 수 있어 디버깅 효율성이 극대화됩니다. 화면을 빠져나올 때는 Ctrl + C를 누릅니다.
3. 대용량 로그로 인한 디스크 풀 장애 예방: catalina.out 비우기
catalina.out 파일은 치명적인 단점을 하나 가지고 있습니다. 톰캣 시스템이 켜져 있는 동안 이 파일은 날짜별로 쪼개지지 않고 단 하나의 파일에 끝없이 용량이 누적되는 누적형 구조로 작동한다는 점입니다.
트래픽이 많은 상용 서비스 환경에서는 몇 주 혹은 몇 달만 방치해도 catalina.out 파일 하나의 크기가 수십 기가바이트(GB) 이상으로 비대해집니다. 이는 결국 리눅스 전체 디스크 용량을 100% 가득 채워 서버를 마비시키는 ‘Disk Full’ 장애의 주범이 됩니다.
용량이 너무 커진 로그 파일을 정리할 때 가장 많이 하는 실수가 바로 rm catalina.out 명령어로 파일을 그냥 삭제해 버리는 것입니다. 리눅스 운영체제는 톰캣 프로세스가 가동되면서 이 파일을 쓰기 모드로 계속 붙잡고(오픈) 있기 때문에, 디스크에서 강제로 파일을 지워버리면 화면상에는 파일이 사라지지만 실제 메모리와 디스크 공간은 해제되지 않는 유령 용량 현상이 발생합니다.
따라서 파일의 형태와 소유 권한, 리눅스 파일 디렉터리 구조를 완벽히 유지하면서 알맹이 용량만 즉시 0바이트로 초기화하는 아래의 안전한 널(Null) 주입 방식을 사용해야 합니다.
Bash
sudo cat /dev/null > /var/log/tomcat9/catalina.out
위 명령어를 실행하면 톰캣 웹 서버를 재시작하는 다운타임(서비스 중단) 없이도 가동 중인 상태에서 즉시 수십 기가바이트의 디스크 여유 공간을 안전하게 확보할 수 있습니다.
결론: 안전한 자바 웹 인프라 관리를 위한 실무 제언
아파치 톰캣 환경에서의 웹 서버 장애 대응은 catalina.out의 실시간 흐름을 얼마나 빠르고 정확하게 분석하느냐에 달려 있습니다. 장애 경보가 발생했을 때 웹 소스 코드만 들여다보는 대신, tail -f 명령어로 시스템 내부의 목소리를 실시간으로 경청하는 습관이 필요합니다.
장기적으로는 인프라 관리자가 매번 수동으로 로그 파일을 비우는 번거로움을 없애기 위해, 리눅스 자체 내장 스케줄러 도구인 로그로테이트(Logrotate) 설정을 적용해 두는 것을 강력히 권장합니다. /etc/logrotate.d/tomcat 설정 파일을 생성하여 주 단위나 일 단위로 catalina.out 파일을 압축 분리하고, 오래된 로그는 자동 삭제되도록 코드를 빌드해 둔다면 디스크 풀 장애의 위협으로부터 영구적으로 벗어나는 단단하고 고도화된 웹 서버 인프라 환경을 완성할 수 있을 것입니다.