본문 바로가기
개발 환경 & 생산성 도구

IntelliJ 테스트 실행 속도 느릴 때 10초 만에 해결하는 체크리스트

by CodeByJin 2026. 5. 4.
반응형

사실 개발하다 보면 이 부분이 가장 번거로우시죠? 코드는 다 짰고 검증만 하면 퇴근인데, IntelliJ에서 테스트 버튼 하나 눌렀을 뿐인데 한참을 멍하니 모니터만 보고 있어야 하는 상황 말이에요. 17년 넘게 코딩하면서 느낀 건데, 테스트가 느리면 결국 테스트를 안 짜게 되고, 그게 나중엔 거대한 버그로 돌아오더라고요.

 

빌드 도구가 꼬였거나 설정 하나만 잘못되어도 1~2초면 끝날 유닛 테스트가 10초, 20초씩 걸리곤 합니다. 오늘은 제가 현업에서 후배들 자리 불려 다닐 때마다 가장 먼저 확인시켜 주는, '느려진 인텔리제이 테스트'를 심폐소생술 하는 실전 팁들을 정리해 드릴게요.

Step 1. 빌드 위임 설정부터 확인하세요 (가장 빈번한 원인)

가장 먼저 확인해야 할 건 "누가 테스트를 실행하느냐"입니다. 기본적으로 IntelliJ는 Gradle이나 Maven 같은 빌드 도구에 실행을 위임하는 경우가 많은데, 이게 생각보다 무겁습니다.

  • Settings (Ctrl+Alt+S) -> Build, Execution, Deployment -> Build Tools -> Gradle로 이동해 보세요.
  • 'Build and run using'과 'Run tests using' 항목이 Gradle로 되어 있다면, 이걸 IntelliJ IDEA로 바꿔보세요.
  • 직접 해보면 차이가 꽤 납니다. Gradle은 전체 생명주기를 다 훑지만, 인텔리제이는 증분 컴파일을 기막히게 활용하거든요.

실제로 제가 진행하던 프로젝트에서 이 설정 하나 바꿨더니 전체 테스트 실행 시간이 45초에서 12초로 줄어든 경험이 있습니다. 다만, Querydsl처럼 별도의 코드 생성이 복잡한 환경에서는 간혹 빌드 오류가 날 수 있으니 그럴 땐 다시 Gradle로 돌리시는 게 정신 건강에 이롭습니다.

Step 2. 힙 메모리(Xmx) 할당의 마법

컴퓨터 사양은 좋은데 인텔리제이가 벅벅거린다면 십중팔구 메모리 부족입니다. 특히 테스트가 많아질수록 JVM이 가비지 컬렉션(GC) 하느라 정작 테스트는 뒷전이 되는 경우가 많아요.

 

상단 메뉴의 Help -> Edit Custom VM Options를 열어서 -Xmx 값을 확인해 보세요. 요즘 나오는 2026년형 랩탑들은 램이 넉넉하니 최소 4GB(4096m) 이상으로 잡아주는 걸 추천합니다.

인텔리제이 테스트 속도

📌 테스트 속도 저하의 주요 원인과 해결책 비교

구분 주요 원인 해결 방법 기대 효과
빌드 도구 Gradle/Maven 위임 실행 IntelliJ IDEA로 실행 주체 변경 매우 높음 (즉시 체감)
메모리 낮은 Heap Memory 할당 VM Options에서 -Xmx 증설 중간 (대규모 테스트 시 유리)
컨텍스트 무거운 @SpringBootTest 남용 Mock 객체를 활용한 단위 테스트 최상 (설계적 개선)

 

표를 보면 알 수 있듯이, 설정 변경(빌드 도구)은 즉각적인 효과를 주고, 설계 개선(컨텍스트 관리)은 장기적인 생산성을 결정합니다. 솔직히 말씀드리면, 툴 설정만 만진다고 무거워진 스프링 컨텍스트가 가벼워지지는 않거든요.

사람들은 왜 테스트가 느리다고 생각할까요?

Q: 테스트 실행 시 'Scanning for files to index'가 너무 오래 걸려요. A: 이건 IntelliJ가 프로젝트 전체 파일을 인덱싱하느라 발생하는 문제입니다. 테스트와 상관없는 대용량 로그 폴더, build 폴더, node_modules 등이 인덱싱 대상에 포함되어 있지 않은지 확인하세요. 해당 폴더를 우클릭하고 Mark Directory as -> Excluded로 지정하면 인덱싱 지옥에서 탈출할 수 있습니다.

Step 3. @SpringBootTest 대신 Slice Test 활용하기

이건 툴 설정보다는 습관의 문제인데, 모든 테스트에 @SpringBootTest를 붙이고 계시진 않나요? 이건 마치 라면 하나 끓이는데 호텔 주방 전체를 세팅하는 것과 같습니다.

  • 웹 레이어만 검증할 때는 @WebMvcTest
  • JPA 쿼리만 볼 때는 @DataJpaTest
  • 비즈니스 로직은 순수 JUnit5와 Mockito만 사용

이렇게만 구분해도 전체 빌드 시간이 기하급수적으로 줄어듭니다. 불필요한 Bean을 로드하지 않는 것만큼 확실한 속도 향상 기법은 없습니다. 특히 데이터베이스 연동이 필요한 테스트라면 H2 인 메모리 DB를 적절히 활용하는 것도 방법이죠.

나에게 맞는 해결 방법은 무엇일까요?

지금 처한 상황에 따라 우선순위를 정해드릴게요.

  • 지금 당장 1초가 급한 직장인: 'Run tests using'을 IntelliJ IDEA로 즉시 변경하세요. 가장 가성비 좋은 해결책입니다.
  • 프로젝트 규모가 커져서 빌드가 고통스러운 팀: 무분별한 Context Caching 파괴 주범(@MockBean 남용 등)을 찾아서 최적화해야 합니다.
  • 컴퓨터 팬 소리가 너무 큰 분: IntelliJ VM 옵션에서 힙 메모리를 늘려주세요. GC가 열 일 하느라 CPU를 갉아먹고 있을 확률이 높습니다.

개발자의 시간은 곧 비용입니다. 테스트가 느리다는 건 그만큼 사고의 흐름이 끊긴다는 뜻이고, 이건 장기적으로 코드 퀄리티 저하로 이어져요. 오늘 알려드린 내용 중 딱 하나만 실천해 보셔도 훨씬 쾌적한 개발 환경을 느끼실 수 있을 겁니다. 안 되면? 그때는 진짜 하드웨어를 의심해 볼 때니 장비 업그레이드를 고민해 보세요.

 

VSCode 단축키 외우기 힘들다면? 뇌 용량 아껴주는 나만의 키 바인딩 정리 노하우

VSCode 단축키 안 외워져서 스트레스 받나요? 이제 외우지 말고 시스템을 만드세요코딩 공부나 실무를 하다 보면 "단축키를 많이 알아야 고수"라는 압박감을 은근히 받게 됩니다. 그런데 사실 수

byteandbit.tistory.com

 

반응형