Tomcat 느린 시작? 주요 4가지 원인과 해결책

Tomcat 느린 시작은 파일 스캔, TLD 탐색, Spring Bean 초기화와 I/O 병목이 주된 원인입니다.

Tomcat 느린 시작? 주요 4가지 원인과 해결책

‘Tomcat 서버의 느린 시작 시간’ ,“Tomcat 시작이 느리다” 문제에 대해 심층적으로 다루어보고자 합니다. 시스템의 안정성과 서비스 가용성은 물론, 개발 생산성에도 지대한 영향을 미치는 이 현상은 단순히 기다림의 문제를 넘어, 비즈니스 연속성에 직접적인 위협이 될 수 있습니다.

Tomcat이 부팅될 때 핵심적으로 두 부류의 작업이 시간을 잡아먹습니다.

하나는 컨테이너 레벨 스캐닝—클래스패스에 있는 수많은 JAR과 리소스를 훑어 서블릿 3.x의 플러거빌리티 요소(애너테이션, ServletContainerInitializer, web-fragment.xml)와 JSP 태그라이브러리(TLD)를 찾는 단계입니다.

다른 하나는 애플리케이션 레벨 초기화—Spring 컨텍스트가 수백~수천 개 빈, JPA/Hibernate, Liquibase/Flyway, 메시징/보안/관측성 오토컨피그 등을 올리는 단계입니다. 운영체제/런타임 측면에선 난수 초기화(SecureRandom), 파일 I/O, 컨테이너 파일시스템(overlay) 특성도 영향을 미칩니다. 이 셋이 겹치면 “정상이나 느린” 수준과 “멈춘 듯한” 수준의 체감 차이가 발생합니다.

운영 서버에 여러 개의 웹앱을 올리거나, 하나의 대형 WAR 안에 라이브러리가 과다할수록 Jar/TLD 스캐닝 비용은 기하급수적으로 늘어납니다. Tomcat은 시작 시점엔 어떤 파일이 변경되었는지 알 수 없어 새 파일처럼 모두 검사하려 하므로, 자동 배포·언팩 설정과 결합되면 부팅 구간의 I/O가 급격히 커집니다.

1. 파일 스캐닝(File Scanning)에 의한 성능 저하

Tomcat은 표준 JarScanner로 클래스패스를 훑습니다. 대상은 크게 두 갈래입니다.

첫째, 플러거빌리티 스캔으로 SCI(예: WebSocket 지원), 애너테이션(@WebServlet,@HandlesTypes) 및 META-INF/web-fragment.xml이 있는 모든 JAR을 점검합니다.

둘째, TLD 스캔으로 JSP 태그 라이브러리를 찾습니다.

스캔은 WAR 내부와 lib/의 JAR 수, 파일 개수, 압축 방식, 기저 디스크/네트워크 속도에 선형 영향을 받습니다.

Tomcat이 시작될 때, 애플리케이션의 클래스, 리소스, 라이브러리 등을 찾기 위해 수많은 파일과 디렉토리를 스캐닝하는 과정은 필수적입니다. 이 과정에서 파일 시스템의 I/O 성능이 좋지 않거나, 스캔해야 할 파일의 양이 방대할 경우, 서버 시작 시간이 현저히 길어지는 현상이 발생할 수 있습니다.

주요 원인 분석:

과도한 JAR 파일:
WEB-INF/lib 디렉토리나 Tomcat의 lib 디렉토리에 불필요하거나 중복된 JAR 파일이 많이 존재할 경우, Tomcat은 이 모든 JAR 파일들을 열어보고 클래스, 리소스, TLD(Tag Library Descriptor) 등을 검색하게 됩니다. 각 JAR 파일을 여는 것은 I/O 작업이며, 그 수가 많아질수록 누적되는 시간이 길어집니다.
WAR 파일 자동 배포:
Tomcat의 webapps 디렉토리에 많은 수의 WAR 파일이 존재하거나, 용량이 큰 WAR 파일이 배포될 경우, Tomcat은 이들을 압축 해제하고 스캐닝하는 데 상당한 시간을 소요합니다. 특히 개발 환경에서 테스트용 애플리케이션들이 정리되지 않고 쌓여있을 때 이러한 문제가 두드러집니다.
느린 I/O 환경:
물리 디스크의 성능이 낮거나, NFS(Network File System)와 같은 네트워크 기반 스토리지에 Tomcat이 설치되어 있을 경우, 파일 스캐닝 작업은 더욱 느려질 수 있습니다. 가상화 환경이나 클라우드 환경에서 I/O 대역폭이 충분히 확보되지 않을 때도 유사한 문제가 발생합니다.
antiResourceLocking 설정:
context.xml 파일에서 antiResourceLocking=”true” 설정은 윈도우 환경에서 배포된 WAR 파일의 잠금을 방지하여 재배포 시 편리함을 제공하지만, 이는 Tomcat이 WAR 파일을 복사하고 임시 디렉토리에서 작업을 수행하게 만듭니다. 이 과정에서 추가적인 I/O와 복사 오버헤드가 발생하여 시작 시간을 늘릴 수 있습니다.

기술적 해결 방안:

불필요한 JAR/WAR 파일 제거:
- 애플리케이션의 WEB-INF/lib 디렉토리에서 실제 사용하지 않는 라이브러리 JAR 파일을 식별하여 제거합니다. Maven이나 Gradle과 같은 빌드 도구의 의존성 분석 기능을 활용하여 사용하지 않는 라이브러리를 찾아낼 수 있습니다.
- Tomcat의 webapps 디렉토리에서 불필요하거나 오래된 WAR 파일을 삭제하거나 다른 곳으로 이동합니다.
JAR 스캐닝 최적화 (catalina.properties):
- Tomcat은 catalina.properties 파일에 정의된 tomcat.util.scan.DefaultJarScanner.jarsToSkip 목록을 기반으로 특정 JAR 파일에 대한 스캐닝을 건너뛸 수 있습니다. 애플리케이션에서 특정 JAR 파일이 TLD, ServletContainerInitializer, WebFragment 등의 메타데이터를 포함하지 않는다면, 이 목록에 추가하여 스캐닝 오버헤드를 줄일 수 있습니다. 예를 들어, JDBC 드라이버, Lombok, CGLIB 등은 대부분 스캐닝이 필요 없습니다.
- 반대로 tomcat.util.scan.StandardJarScanner.jarsToScan을 통해 스캐닝이 필요한 JAR 파일을 명시적으로 지정하여 불필요한 스캔 범위를 줄일 수도 있습니다.
WAR 파일 배포 방식 최적화:
- server.xml의 Host 엘리먼트 내에 deployIgnore 속성을 사용하여 특정 패턴의 WAR 파일이나 디렉토리 스캔을 무시하도록 설정할 수 있습니다.
- 운영 환경에서는 autoDeploy=”false” 및 deployOnStartup=”false”로 설정하여 자동 배포를 비활성화하고, 관리자 스크립트나 CI/CD 파이프라인을 통해 명시적으로 애플리케이션을 배포하는 것이 좋습니다.
- 개발 환경이 아니라면 antiResourceLocking=”false”로 설정하여 WAR 파일 복사 오버헤드를 줄이는 것을 고려할 수 있습니다.
I/O 성능 개선:
- Tomcat이 설치된 디스크의 I/O 성능을 점검하고, 필요한 경우 더 빠른 스토리지를 사용하거나 RAID 구성 등을 고려합니다. 클라우드 환경에서는 프로비저닝된 IOPS(Input/Output Operations Per Second)를 확인하고 증설을 고려할 수 있습니다.

핵심: 파일 스캐닝은 기본적으로 I/O 작업의 집합이므로, 스캔 대상의 양을 줄이고 I/O 성능을 최적화하는 것이 가장 중요합니다.

2. TLD(Tag Library Descriptor) 스캐닝에 의한 성능 저하

JSP(JavaServer Pages) 를 사용하는 시스템에서는 Tomcat의 TldScanner가 클래스패스를 샅샅이 훑어 .tld와 태그 파일을 찾습니다. TLD 메타데이터는 JSP 컴파일·검증에 필요하기 때문에, 불필요한 JAR에 흩어진 TLD가 많거나 압축 내부 탐색이 잦으면 시작 시간이 늘어납니다.

TLD는 보통 JAR 파일 내의 META-INF 디렉토리에 위치하며, Tomcat은 모든 JAR 파일을 열어 이 TLD 파일을 찾습니다. Tomcat은 TLD 스캔을 더 세밀히 통제할 수 있도록 로거와 필터를 제공합니다.

주요 원인 분석:

과도한 TLD 포함 JAR 파일:
Spring Framework, JSTL, Struts 등 여러 프레임워크와 라이브러리들은 자체적인 태그 라이브러리를 가지고 있으며, 이들이 모두 JAR 파일 내에 TLD를 포함하고 있습니다. 애플리케이션에 많은 수의 이러한 라이브러리가 포함되어 있다면, Tomcat은 모든 JAR 파일을 대상으로 TLD를 스캔하게 됩니다.
불필요한 JSP 태그 라이브러리:
실제 애플리케이션에서 사용하지 않는 태그 라이브러리임에도 불구하고, 의존성으로 인해 JAR 파일이 포함되어 TLD 스캐닝 대상이 되는 경우가 있습니다.

기술적 해결 방안:

TLD 스캐닝 대상 제한 (catalina.properties):
- 파일 스캐닝 최적화와 동일하게 tomcat.util.scan.DefaultJarScanner.jarsToSkip 및 tomcat.util.scan.StandardJarScanner.jarsToScan 속성을 활용하여 TLD 스캔 대상에서 제외할 JAR 파일을 지정할 수 있습니다.
- 애플리케이션에서 JSP를 사용하지 않거나, 특정 JAR 파일이 TLD를 포함하지 않음을 확실히 아는 경우 해당 JAR 파일을 jarsToSkip 목록에 추가하면 스캐닝 시간을 단축할 수 있습니다.
web.xml을 통한 명시적 TLD 정의 (권장하지 않음, 이해 차원):
- 과거에는 web.xml에 요소를 사용하여 TLD를 명시적으로 정의함으로써 Tomcat의 자동 스캔을 우회할 수 있었습니다. 그러나 현대적인 애플리케이션 개발에서는 이러한 수동 설정보다는 자동 스캔에 의존하는 경향이 강하며, 관리 포인트가 늘어나므로 일반적으로 권장되지는 않습니다. 하지만 원리를 이해하는 데 도움이 됩니다.
불필요한 태그 라이브러리 의존성 제거:
- 애플리케이션의 의존성 중 실제로 사용하지 않는 JSP 태그 라이브러리 관련 JAR 파일을 식별하고 제거합니다. 이는 전체 JAR 파일 수를 줄이는 효과도 가져와 파일 스캐닝 성능에도 긍정적인 영향을 미칩니다.

핵심: TLD 스캐닝은 JSP 태그 라이브러리 사용을 전제로 하는 작업입니다. 만약 애플리케이션이 JSP를 거의 사용하지 않거나, 특정 라이브러리의 TLD가 불필요하다면 이를 스캔 대상에서 제외하는 것이 중요합니다.

3. 과도한 Spring Bean 로딩에 의한 성능 저하

Spring Boot 기반 애플리케이션은 “의존을 추가하면 기능이 따라온다”는 장점만큼 오토컨피그 빈 증가라는 부작용도 큽니다. Spring Framework 기반의 애플리케이션은 IoC(Inversion of Control) 컨테이너가 시작될 때 모든 Bean들을 초기화하고 의존성 주입을 수행합니다. 이 과정에서 Bean의 개수가 매우 많거나, 일부 Bean이 초기화 시점에 복잡하고 리소스 집약적인 작업을 수행한다면, Tomcat의 시작 시간이 크게 지연될 수 있습니다.

주요 원인 분석:

방대한 Bean 개수 및 복잡한 의존성 그래프:
마이크로서비스 아키텍처가 아닌 모놀리식 애플리케이션에서 모든 기능이 하나의 Spring 컨텍스트에 담겨 있다면, 수백, 수천 개의 Bean이 존재할 수 있습니다. 이 Bean들의 생성과 의존성 주입 과정은 결코 가볍지 않습니다.
초기화 시 무거운 작업 수행:
일부 Bean은 @PostConstruct 메서드나 생성자에서 데이터베이스 연결, 외부 API 호출, 파일 시스템 접근, 복잡한 캐시 초기화, 대용량 데이터 로딩 등 시간이 오래 걸리는 작업을 수행하도록 설계될 수 있습니다. 이러한 작업들이 동기적으로 순차 실행될 경우 시작 시간은 기하급수적으로 늘어납니다.
컴포넌트 스캔 범위:
@ComponentScan의 범위가 너무 넓게 지정되어 실제 Bean이 아닌 클래스까지 스캔하게 되거나, 불필요한 패키지를 스캔하게 되면 탐색 시간이 늘어납니다.
Lazy Loading 미적용:
모든 Bean이 애플리케이션 시작 시점에 초기화되도록 기본 설정되어 있는 경우, 실제로는 나중에 사용될 Bean까지 미리 초기화되어 불필요한 오버헤드를 발생시킵니다.

기술적 해결 방안:

지연 로딩(Lazy Loading) 적극 활용:
- @Lazy 어노테이션을 사용하여 특정 Bean이 실제로 사용될 때까지 초기화를 지연시킵니다. 특히 시작 시점에 반드시 필요하지 않은 서비스, 리포지토리, 컨트롤러 등에 적용하면 효과적입니다.
- 클래스 레벨에 @Lazy를 적용하거나, @Configuration 클래스에 @Lazy를 적용하여 해당 설정 클래스 내의 모든 Bean을 지연 로딩할 수도 있습니다.
초기화 로직 최적화 및 비동기 처리:
- @PostConstruct 메서드나 생성자 내에서 수행되는 무거운 초기화 작업을 식별하고 최적화합니다. 가능한 한 경량화하거나, 필요하다면 별도의 스레드에서 비동기적으로 실행되도록 변경합니다. Spring의 @Async 어노테이션이나 ApplicationRunner, CommandLineRunner를 활용하여 애플리케이션 시작 후 별도의 백그라운드 작업으로 수행하도록 구성할 수 있습니다.
- 데이터베이스 연결 풀 초기화 등은 WAS 컨테이너의 설정(예: Tomcat JNDI DataSource)을 활용하거나, connection-pool 라이브러리(HikariCP 등)의 최적화된 초기화 방식을 활용합니다.
컴포넌트 스캔 범위 최소화:
- @ComponentScan의 basePackages 또는 basePackageClasses 속성을 명확하게 지정하여 실제 Bean이 위치한 패키지만 스캔하도록 제한합니다. 이는 불필요한 클래스 탐색 시간을 줄여줍니다.
애플리케이션 모듈화 및 마이크로서비스 전환 고려:
- 단일 거대 모놀리식 애플리케이션이라면, 기능을 여러 개의 작은 모듈이나 마이크로서비스로 분리하는 것을 장기적인 관점에서 고려할 수 있습니다. 각 서비스의 컨텍스트 크기가 줄어들어 시작 시간이 단축될 뿐만 아니라, 서비스의 독립적인 배포 및 확장성에도 이점을 제공합니다.
Spring Boot Actuator 활용:
- Spring Boot 애플리케이션의 경우, Spring Boot Actuator를 사용하여 Bean 초기화 시간을 프로파일링할 수 있습니다. /actuator/beans 엔드포인트나 ContextRefreshedEvent 리스너를 통해 어떤 Bean이 초기화에 가장 많은 시간을 소요하는지 파악하여 최적화 대상을 식별합니다.

핵심: Spring Bean 로딩은 애플리케이션 로직의 핵심입니다. 시작 시 반드시 필요한 최소한의 Bean만 초기화하고, 나머지는 지연 로딩하거나 비동기 처리하여 시작 부담을 분산하는 전략이 중요합니다.

4. 정확한 진단을 위한 쓰레드 덤프 분석

위에서 설명드린 각 원인들은 Tomcat 시작 지연의 일반적인 원인들이지만, 실제 운영 환경에서는 여러 요인이 복합적으로 작용하거나 예상치 못한 지점에서 병목 현상이 발생할 수 있습니다. 이때 가장 정확하고 확실하게 문제의 원인을 파악할 수 있는 도구가 바로 쓰레드 덤프(Thread Dump) 입니다. 쓰레드 덤프는 특정 시점에 JVM 내에서 실행 중인 모든 쓰레드의 스택 트레이스(Stack Trace)를 기록한 스냅샷으로, 어떤 쓰레드가 어떤 메서드에서 무엇을 하고 있는지 명확하게 보여줍니다.

쓰레드 덤프 획득 방법:

Tomcat이 느리게 시작하는 도중에 다음과 같은 방법으로 쓰레드 덤프를 생성할 수 있습니다.

jstack 유틸리티 사용 (권장):
- 가장 보편적이고 권장되는 방법입니다. 먼저 ps -ef | grep java 명령 등으로 Tomcat 프로세스의 PID를 확인합니다.
- jstack > thread_dump_$(date +%Y%m%d%H%M%S).txt 명령을 실행하여 쓰레드 덤프를 파일로 저장합니다.
kill -3 명령 사용 (리눅스/유닉스 환경):
- kill -3 명령을 실행하면, 해당 시점의 쓰레드 덤프가 Tomcat의 표준 에러(stderr) 로그(일반적으로 catalina.out 파일)에 기록됩니다.
JVM 모니터링 도구 활용:
- VisualVM, Java Mission Control(JMC)과 같은 GUI 기반의 JVM 모니터링 도구를 사용하여 실시간으로 쓰레드 덤프를 생성하고 분석할 수 있습니다.

쓰레드 덤프 분석 방법:

쓰레드 덤프는 한 번만 찍는 것보다, 문제가 발생하는 시점에 짧은 간격(예: 5초 간격)으로 3~5회 정도 연속적으로 찍는 것이 중요합니다. 여러 개의 덤프를 비교 분석하면 어떤 쓰레드가 일관되게 특정 작업에 묶여 있는지, 또는 어떤 자원을 놓고 경쟁하는지 파악하기 용이합니다.

분석 시 중점적으로 봐야 할 내용들은 다음과 같습니다.

쓰레드 상태(Thread State) 확인:
- RUNNABLE:
  현재 CPU를 사용하고 있거나 사용할 준비가 된 상태입니다. RUNNABLE 상태의 쓰레드가 특정 메서드에서 오랫동안 머물러 있다면, 해당 메서드가 CPU를 많이 소모하거나 무한 루프에 빠진 것은 아닌지 의심해봐야 합니다.
- BLOCKED:
  다른 쓰레드가 보유하고 있는 락(Lock)을 얻기 위해 대기 중인 상태입니다. 이는 동기화(Synchronization) 문제나 데드락(Deadlock)의 징후일 수 있습니다.
- WAITING 또는 TIMED_WAITING:
  특정 조건이 충족되기를 기다리거나, 일정 시간 동안 기다리고 있는 상태입니다. I/O 작업(네트워크, 디스크), 데이터베이스 연결 대기, 가비지 컬렉션, Thread.sleep(), Object.wait(), LockSupport.park() 등의 메서드 호출 시 이 상태가 됩니다.
스택 트레이스(Stack Trace) 분석:
- 각 쓰레드의 스택 트레이스를 통해 어떤 클래스의 어떤 메서드를 호출하고 있는지 역추적할 수 있습니다. Tomcat 시작 지연의 경우, main 쓰레드나 ContainerBackgroundProcessor 쓰레드, 또는 애플리케이션 관련 쓰레드들에서 반복적으로 나타나는 특정 메서드 호출을 주시해야 합니다.
- 파일 I/O 관련:
  java.io.FileInputStream, java.io.FileOutputStream, java.util.zip.ZipFile 등 파일 시스템과 관련된 호출이 자주 보인다면 파일 스캐닝이나 WAR 파일 압축 해제 관련 문제일 가능성이 높습니다.
- 네트워크/데이터베이스 관련:
  java.net.SocketInputStream, java.sql.DriverManager.getConnection 등 네트워크 또는 데이터베이스 연결 관련 호출이 오랫동안 WAITING 상태라면 외부 자원(DB 서버, 외부 API)과의 통신 지연이 원인일 수 있습니다.
- Spring Bean 초기화 관련:
  애플리케이션 고유의 클래스(com.yourcompany…) 내에서 @PostConstruct나 생성자 로직이 호출되는 스택 트레이스가 길게 이어진다면 Spring Bean 초기화 지연일 가능성이 높습니다.
- Class Loading 관련:
  java.lang.ClassLoader.loadClass와 같은 클래스 로딩 관련 스택이 자주 나타난다면, 클래스패스나 라이브러리 구성에 문제가 있을 수 있습니다.
- Garbage Collection 관련:
  Full GC가 너무 자주 발생하거나 오래 걸리는 경우, 쓰레드 덤프에서 GC 관련 메시지나 VM Thread가 RUNNABLE 상태로 오래 보이는 경우가 있습니다.

분석 예시:

만약 여러 쓰레드 덤프에서 일관되게 http-nio-8080-exec-1와 같은 Tomcat 워커 쓰레드가 org.apache.jasper.servlet.TldScanner.scanJar 메서드에서 WAITING 상태로 나타난다면, TLD 스캐닝이 병목의 주원인임을 강하게 시사합니다.

핵심: 쓰레드 덤프는 서버의 ‘현재 상황’을 가장 정확하게 보여주는 진단 도구입니다. 육안으로 문제를 추정하는 것을 넘어, 구체적인 메서드 호출 스택을 통해 문제의 뿌리를 찾아낼 수 있는 결정적인 증거를 제공합니다. 여러 번의 덤프를 통해 ‘반복되는 패턴’을 찾는 것이 분석의 핵심입니다.

결론 및 제언

Tomcat의 느린 시작 시간은 단순히 기다림의 문제를 넘어, 시스템의 전반적인 운영 효율성과 안정성, 그리고 서비스 제공 능력에 직접적인 영향을 미치는 중요한 성능 이슈입니다. 본 글에서 다룬 파일 스캐닝, TLD 스캐닝, 그리고 Spring Bean 로딩과 같은 주요 원인들은 대부분 불필요한 작업의 수행, 최적화되지 않은 설정, 또는 리소스 집약적인 로직 설계에서 비롯됩니다.

특히 고가용성과 안정성이 최우선시되는 애플리케이션 환경에서는 이러한 잠재적 문제를 사전에 진단하고 해결하는 것이 매우 중요합니다. 느린 시작 시간은 배포의 어려움과 재시작 실패의 위험을 높여 서비스 중단으로 이어질 수 있으며, 이는 국민들에게 제공되는 핵심 서비스의 품질 저하로 직결될 수 있기 때문입니다.