Tomcat 로그 보는 법 — 서버 로그로 에러 추적하기 실무 가이드

Tomcat 로그 보는 법 — 서버 로그로 에러 추적하기 실무 가이드

웹 개발을 하다 보면 ‘로컬에서는 잘 되는데 서버에서는 안 돼요’라는 말을 수없이 듣습니다.

그럴 때 가장 먼저 확인해야 할 곳이 바로 Tomcat 로그입니다.

이번 글에서는 초보 개발자도 쉽게 따라 할 수 있는 Tomcat 로그의 구조, 종류, 에러 분석 순서, 그리고 실무에서의 활용 팁까지 단계별로 정리했습니다.

 

1. Tomcat 로그의 위치와 구조

Tomcat을 설치하면 기본적으로 /logs 폴더가 생성됩니다.

이 안에는 여러 종류의 로그 파일이 있으며, 각각 역할이 다릅니다.

tomcat/
 └── logs/
      ├── catalina.out
      ├── localhost_access_log.2025-11-10.txt
      ├── localhost.2025-11-10.log
      ├── manager.2025-11-10.log
      └── host-manager.2025-11-10.log

💡 핵심 로그 구분:
- catalina.out: Tomcat 전체의 표준 출력 로그 (System.out.println 포함)
- localhost.log: 애플리케이션 로드 시점의 에러, JSP 컴파일 오류
- access_log: 클라이언트 요청/응답 기록 (IP, 상태코드, 응답시간)
- manager.log: Tomcat 관리 콘솔(Manager App) 관련 로그

2. catalina.out — 서버의 “심장 박동” 로그

은 Tomcat 실행 중 발생하는 모든 로그가 모이는 메인 로그입니다.

Spring Boot를 내장 Tomcat으로 실행하면, 콘솔에 찍히는 내용이 바로 이 파일에도 기록됩니다.

10-Nov-2025 10:12:01.567 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [3,421] milliseconds
10-Nov-2025 10:15:02.014 ERROR [http-nio-8080-exec-10] o.s.web.servlet.DispatcherServlet - Servlet.service() for servlet [dispatcherServlet]
in context with path [/app] threw exception [Request processing failed] with root cause
java.lang.NullPointerException: Cannot invoke "String.length()" because "name" is null

💡 읽는 순서:
1️⃣ 날짜/시간 확인
2️⃣ 로그 레벨(INFO, WARN, ERROR)
3️⃣ 스레드명 확인 (http-nio-8080-exec-10 등)
4️⃣ 예외의 root cause(맨 마지막 줄) 추적

 

💬 Tip: Tomcat이 오래 켜져 있으면 catalina.out이 수백 MB까지 커집니다. 이럴 땐 로그 회전(rotation)을 설정해 일자별로 분리하세요.

 

 

3. localhost_access_log — 요청 흐름 분석

이 로그는 Apache의 access.log와 유사합니다.

클라이언트가 서버에 어떤 요청을 보냈는지, 그 요청이 언제, 어떤 상태코드로 처리되었는지를 보여줍니다.

127.0.0.1 - - [10/Nov/2025:11:23:45 +0900] "GET /app/api/user HTTP/1.1" 200 532
127.0.0.1 - - [10/Nov/2025:11:24:02 +0900] "POST /app/api/login HTTP/1.1" 500 124

 

💡 해석법:
- 첫 번째 IP: 요청자 주소 - 대괄호: 요청 시간 - “GET / POST”: 요청 방식 - 200 / 500: 상태 코드 (200 성공, 500 서버 오류) - 마지막 숫자: 응답 크기(Byte)

여기서 500 에러가 있다면, 같은 시각의 catalina.out 로그를 열어 예외 원인을 찾아야 합니다.

이 두 로그를 연결하는 것이 실무 서버 분석의 핵심입니다.

4. 로그 회전(log rotation) 설정하기

Tomcat의 로그 파일은 별도 설정 없이는 계속 누적됩니다.

Linux 환경에서는 logrotate를 이용하거나, Tomcat의 내부 설정을 수정하여 일자별 파일을 자동 분리할 수 있습니다.

<Valve className="org.apache.catalina.valves.AccessLogValve"
       directory="logs"
       prefix="localhost_access_log"
       suffix=".txt"
       pattern="%h %l %u %t "%r" %s %b"
       fileDateFormat=".yyyy-MM-dd"/>

💡 설명:
- fileDateFormat을 지정하면 날짜별로 자동 분리됨
- prefix/suffix로 파일 이름 패턴 지정 가능
- pattern은 로그 형식 템플릿

💬 추천: 운영 서버는 하루 단위 로그 분리 + 30일 보관이 표준입니다.

5. 자주 발생하는 에러 패턴 3가지

① NullPointerException

가장 흔한 예외입니다. JSP, Controller, Service 어디서든 발생 가능.

로그에서 root cause를 찾아 스택트레이스의 마지막 줄을 보세요.

Caused by: java.lang.NullPointerException: Cannot invoke "String.length()" because "name" is null
at com.example.UserService.save(UserService.java:52)

👉 UserService.java 52번째 줄의 name 변수 null 여부 확인.

② Port already in use

Tomcat 시작 시 포트(기본 8080)가 이미 다른 프로세스에서 사용 중일 때 발생합니다.

SEVERE [main] org.apache.catalina.startup.Catalina.start Server startup in [1234] milliseconds
java.net.BindException: Address already in use: bind

해결: 다른 Tomcat 프로세스를 종료하거나 server.xml의 포트 변경.

③ OutOfMemoryError

로그 끝부분에 java.lang.OutOfMemoryError가 보인다면 JVM 힙 메모리가 부족한 상태입니다.

Exception in thread "http-nio-8080-exec-5" java.lang.OutOfMemoryError: Java heap space

💡 해결: setenv.sh 또는 setenv.bat에 다음 옵션 추가.

export CATALINA_OPTS="-Xms512m -Xmx1024m"

6. 실무 로그 분석 루틴

Tomcat 로그를 볼 때는 다음 순서를 기억하세요.

1. Access_log에서 요청 시각과 상태코드(예: 500) 확인
2. 같은 시간의 catalina.out 에러 스택 확인
3. NullPointer / SQL / OutOfMemory 등 원인 분류
4. StackTrace의 “내 코드 경로”를 먼저 점검

💡 팁: 로그 분석 시 grep ERROR 또는 grep Exception 명령어로 필요한 줄만 추출하면 시간을 크게 단축할 수 있습니다.

grep "ERROR" catalina.out | tail -20

그리고 IDE에서도 Remote Console 플러그인이나 서버 SSH 연결을 통해 실시간 로그 모니터링을 설정하면 편리합니다.

7. 로그를 데이터처럼 다루기

Tomcat 로그는 단순한 텍스트가 아니라 “운영 데이터”입니다.

ELK(Elasticsearch + Logstash + Kibana)나 Grafana Loki 같은 도구로 수집·시각화하면 서비스 상태를 실시간으로 모니터링할 수 있습니다.

💡 실무 예시:
- 5분 간격으로 500 에러 발생 건수 알림 - IP별 접속 빈도 그래프 - 특정 URI 응답시간 평균 계산

 

마무리

Tomcat 로그는 백엔드 개발자의 현미경입니다.

이 로그를 읽을 줄 아는 순간, 서버에서 벌어지는 일들을 눈으로 볼 수 있게 됩니다.

이제 단순히 “에러났다”가 아니라 “무엇이, 언제, 왜, 어디서 발생했는가”를 말할 수 있는 개발자가 되세요.

다음 글에서는 “SQL 튜닝 입문 — 실행계획(EXPLAIN)으로 성능 분석하기”를 다룰 예정입니다.

이제 로그를 통해 원인을 찾는 단계를 넘어, 쿼리 성능까지 개선하는 방법을 함께 배워봅시다.