Logcat 한 줄 쿼리로 새벽 디버깅이 15분으로 줄었습니다

어제 새벽 2시, 릴리즈 직전 크래시 하나 잡겠다고 Logcat 스크롤만 30분째 내리고 있었거든요. package:mine is:crash 한 줄 치자 바로 잡혔습니다.

 

안드로이드 스튜디오 Logcat이 비효율적이었던 이유

안드로이드 스튜디오(Android Studio)에서 Logcat 창을 열면 예전엔 시스템 로그, 라이브러리 로그, 다른 앱의 로그까지 다 섞여서 흘러내렸어요. Ctrl+F 문자열 검색은 오탐이 잦았고, 비슷한 단어가 들어간 다른 로그까지 같이 잡혀서 의미가 없었습니다.

 

태그도 레벨도 없이 println 으로 박아둔 로그가 섞이면 더 답이 없죠. 어떤 게 내 로그인지부터 가려내야 하니, 정작 크래시 원인을 보기 전에 시야 정리에만 시간을 다 썼더라고요.

 

 

Logcat 쿼리 문법, package:mine 한 줄부터 잡기

안드로이드 스튜디오 Dolphin 부터 들어간 새 Logcat 쿼리 문법은 정말 강력합니다. 키-값 형태로 노이즈를 한 번에 걷어낼 수 있어요.

 

핵심 필터 몇 개만 정리해보면 이렇습니다.

 

• package:mine — 현재 디버깅 중인 앱 로그만 표시. PID를 찾을 필요 없이 시스템·라이브러리 노이즈가 한 번에 사라집니다.
• level:WARN — 지정 레벨 이상만. 평소엔 INFO 이상으로 띄워두는 게 편해요.
• tag:HomeViewModel — 특정 태그만 추리기.
• is:crash — ANR, 미처리 예외만. 진짜 죽은 자리만 보입니다.
• is:stacktrace — try-catch 로 잡아서 출력한 스택까지 포함.

 

연산자도 직관적이라 좋더라고요. 공백은 AND, | 는 OR, - 는 NOT, () 는 그룹화입니다. package:mine (tag:HomeViewModel | tag:LoginRepo) -message:heartbeat 처럼 쓰면 내 앱 로그 중 두 태그만 보면서 heartbeat 노이즈는 빼는 식으로 한 줄에 다 담을 수 있어요.

 

특히 is:crash 와 is:stacktrace 의 차이는 정확히 잡아두시면 좋습니다. 실제로 앱이 죽었는지(is:crash), 아니면 코드에서 잡아서 출력만 한 건지(is:stacktrace)가 디버깅 진입점이 완전히 다르거든요.

 

구조화 로그로 message: 검색이 가능해집니다

필터를 잘 짜도 로그 자체가 자연어면 검색이 안 됩니다.

 

// Bad — 검색 불가
Log.d(TAG, "로그인 성공!")

// Good — message:user_id=123 으로 정확 검색
Log.d(TAG, "event=login user_id=$uid result=success")

 

차이가 보이시죠. 자연어로 박아두면 나중에 "그 로그인 성공 로그 어디 있더라" 하면서 또 스크롤을 내리게 되는데, 키-값으로 박아두면 message:user_id=12345 한 줄로 정확히 그 사용자 세션만 잡힙니다.

 

팀 안에서 키 컨벤션을 미리 정해두는 게 중요하다고 봅니다. event, user_id, result, error_code 정도만 합의해도 검색 정확도가 확 올라가요. 다만 이메일이나 실명 같은 개인정보는 그대로 박지 말고 해시 처리하거나 마스킹해야 해요.

 

성능에 민감한 함수에서는 if (BuildConfig.DEBUG) 가드로 꼭 감싸야 합니다. onDraw, onBindViewHolder 같은 빠른 실행 경로에 그냥 Log.d 를 박으면 프레임 드롭이 생길 수 있어요.

 

if (BuildConfig.DEBUG) {
    Log.d(TAG, "event=bind position=$position item_id=${item.id}")
}

 

 

자주 쓰는 필터는 별표로 저장해두세요

좋은 필터를 짜놨으면 매번 다시 타이핑하지 마시고, Logcat 검색창 옆 별 아이콘으로 즐겨찾기에 저장하시면 됩니다. "내앱-크래시만", "결제플로우-warn이상" 같은 이름을 붙여두면 한 클릭으로 불러올 수 있어요.

 

뷰 모드도 상황 따라 바꿔쓰면 좋더라고요. 평소엔 시간·레벨·메시지만 보이는 Compact 모드로 공간을 확보하고, 스택 추적할 땐 Standard 로 전환하는 식입니다. Modify Views 에서 컬럼을 직접 골라 쓸 수도 있는데 저는 잘 안 쓰게 되네요.

 

개인적으로는 필터 텍스트를 팀 깃허브 저장소의 docs/logcat-filters.md 에 같이 적어두고 관리합니다. 같은 모듈을 보는 팀 후배가 새벽에 같은 버그를 만났을 때 그 한 줄만 복붙하면 바로 진입할 수 있도록요. CI 환경처럼 안드로이드 스튜디오가 없는 자리에서는 adb logcat --pid=$(adb shell pidof com.your.app) 스니펫을 따로 만들어두는 게 안전합니다 (macOS/Linux 셸 기준, Windows PowerShell 에서는 다른 방식이 필요해요).

 

프로덕션 크래시는 Crashlytics, 릴리즈 빌드 Log 제거까지

마지막으로 짚어두고 싶은 게 있어요. Logcat 은 디바이스가 재부팅되거나 버퍼가 넘치면 그대로 사라지는 휘발성 데이터입니다. 개발 단계의 1차 도구로 쓰는 건 맞는데, 실제 사용자 단말에서 일어난 크래시를 추적하려면 파이어베이스 크래시리틱스(Firebase Crashlytics) 같은 원격 수집 도구가 따로 필요하다는 얘기입니다.

 

그리고 Log 호출이 릴리즈 빌드에 그대로 남으면 민감정보 유출 위험이 큽니다. ProGuard·R8 규칙으로 릴리즈에선 android.util.Log 의 메서드들이 통째로 제거되도록 설정해두시는 게 안전해요. 저 같은 경우엔 -assumenosideeffects 규칙으로 Log.d, Log.v 를 빌드 단계에서 들어내고 있습니다.

 

---

다음 릴리즈 전날 새벽 두 시, 슬랙에 또 크래시 리포트가 뜨더라도 평소처럼 Logcat 창을 끝없이 내릴 일은 없을 거예요. 저장해둔 별표 필터를 한 번 누르면 죽은 자리만 정확히 추려져 떠 있고, 키-값으로 박아둔 한 줄에서 error_code= 가 바로 눈에 들어옵니다. 어제까지 30분 걸리던 자리가 15분 안에 닫히는 새벽, 그게 package:mine is:crash 한 줄이 만들어주는 풍경이라고 봅니다.