빌드가 5분으로 늘어났는데 범인을 모를 때, Build Analyzer로 태스크를 잡았습니다

 

얼마 전에, 커밋 하나 올리려고 빌드를 돌렸는데 5분이 넘게 걸리더군요. 뭐가 느려진 건지 몰라서 로그만 멍하니 쳐다봤습니다.

 

예전엔 3분 안쪽이었거든요. 근데 어느 순간부터 슬금슬금 늘더니, 결국 커피 한 잔 타 올 시간이 돼버렸어요. 감으로 "kapt 때문이겠지" 하고 찍기엔 근거가 없었습니다. 그래서 안드로이드 스튜디오(Android Studio) 안에 들어있는 Build Analyzer 를 켰어요.

 

Build Analyzer 리포트를 빌드 창에서 여는 순서

이 도구, 따로 설치할 게 없습니다. 빌드를 한 번 돌리고 나면 하단 Build 창에 리포트가 자동으로 생겨요. 거기서 'Build Analyzer' 탭으로 들어가면 됩니다.

 

들어가 보면 전체 빌드 시간이랑 Configuration(구성) 시간이 따로 표시됩니다. 구성 단계에서 병목이 걸리는 경우도 은근히 많아서, 저는 이 숫자부터 봤어요.

 

한 가지 주의할 게 있는데요. 빌드 한 번 측정한 수치는 매번 출렁입니다. 캐시 상태, 백그라운드 프로세스에 따라 매번 달라지거든요. 그래서 같은 조건으로 3~4번 돌린 다음, 반복적으로 위에 올라오는 태스크를 병목으로 봐야 합니다.

 

Critical Path에 올라온 병목 태스크 읽는 법

Build Analyzer의 핵심은 Critical Path 예요. 전체 빌드 시간에 직접 영향을 준 태스크만 이어서 보여주는 경로입니다.

 

여기서 착각하기 쉬운 게, "제일 오래 걸린 태스크 = 범인" 이 아니라는 점이에요. 병렬로 돌아서 총 시간에는 영향을 안 준 태스크는 아예 빠지거든요. 그래서 단순 소요 시간이 아니라, 이 경로에 올라와 있는지를 봐야 합니다.

 

제 경험으로는 소요 시간 내림차순으로 정렬하면 상위 3개가 전체 시간의 절반 이상을 차지할 때가 많더라고요. 그 셋만 손봐도 체감이 확 달라집니다. 병렬 실행까지 포함한 전체 타임라인이 궁금하면 ./gradlew assembleDebug --scan 으로 Gradle Build Scan을 뽑아서 보시는 게 정확해요.

 

 

캐시를 못 타는 Always-run 태스크 골라내기

제 프로젝트의 진짜 범인은 여기 있었습니다. 리포트의 Warnings 탭을 열었더니 'Always-run tasks' 경고가 떠 있더라고요.

 

이게 뭐냐면, 매 빌드마다 무조건 재실행되는 태스크예요. 증분 빌드(Incremental build)를 방해하는 주범입니다. 문제는 자기 하나만 다시 도는 게 아니라, 자기한테 의존하는 다른 태스크의 캐시까지 무효화시킨다는 점이에요.

 

원인은 대개 태스크의 입력(inputs)이나 출력(outputs) 선언이 빠졌거나 잘못돼서, Gradle이 "얘를 다시 돌려야 하나, 말아야 하나"를 판단하지 못하는 데 있습니다. 오래된 서드파티 플러그인이나 직접 만든 커스텀 태스크에서 자주 나온다고 해요.

 

Configuration cache(구성 캐시) 미활성화 경고도 이 탭에서 같이 확인할 수 있는데요. Build Analyzer가 호환성 검사를 돌려서, 통과하면 리포트 화면에서 바로 켤 수 있게 해줍니다. 다만 호환 안 되는 태스크가 하나라도 있으면 빌드가 깨질 수 있어서, 무작정 켜지 말고 검사 결과를 따라가시는 게 안전해요.

 

 

kapt 어노테이션 처리에 드는 실제 비용

플러그인별 집계도 눈여겨봤어요. Dagger, Room 같은 걸 쓰면 kapt 기반 어노테이션 프로세서가 돌아가는데, 이게 컴파일에 수십 초씩 얹더군요. Build Analyzer가 그걸 숫자로 딱 보여줍니다.

 

이 수치를 근거로 kapt를 KSP로 옮기면 처리 속도가 크게 빨라진다고 알려져 있어요. 개인적으로는, 감으로 "kapt 무거우니 바꿔야지" 하는 것보다 이렇게 몇 초를 잡아먹는지 눈으로 확인하고 옮기는 쪽을 추천합니다. 팀 설득할 때도 근거가 되니까요.

 

다만 이 도구는 병목을 짚어줄 뿐, 처방까지 해주진 않아요. 거대한 단일 모듈을 쪼개는 것 같은 구조 문제는 Build Analyzer가 대신 풀어주지 못합니다. 그건 사람이 Gradle 지식으로 손봐야 하는 영역이에요.

 

 

수정 후 빌드 시간 재측정으로 개선폭 확인하기

고쳤으면 반드시 같은 시나리오로 다시 재보셔야 합니다. 캐시가 먹은 태스크가 'up-to-date'로 뜨는지, 아까 그 경고가 사라졌는지 확인하는 게 핵심이에요.

 

저 같은 경우엔 문제였던 Always-run 태스크의 입출력 선언을 바로잡고 나니, 증분 빌드가 2분 10초에서 55초로 줄었습니다. 2분 10초에서 55초면, 커피 타러 갈 시간이 자리에서 기지개 한 번 켤 시간으로 바뀐 셈이에요. 이렇게 전후 숫자를 기록해두면 나중에 리팩터링 우선순위 정할 때도 두고두고 써먹게 되더라고요.

 

한 가지만 덧붙이면, Build Analyzer는 로컬 빌드 진단 전용입니다. CI 빌드가 느린 건 원격 캐시나 네트워크 같은 다른 요인이라, 그건 따로 봐야 합니다.

 

빌드가 느려졌을 때 제일 위험한 건 감으로 범인을 찍는 일이에요. 로그를 노려보던 그 시간에 Build Analyzer 탭을 먼저 여는 것, 그게 제 5분을 55초로 되돌린 가장 빠른 길이었습니다.