adb logcat 제대로 수집하기 — 옵션·버퍼·저장 방법

Android 로그 수집 실무 · adb logcat 옵션 · 저장·인코딩 · 2026년 9월

로그 분석의 품질은 수집 단계에서 이미 반쯤 결정됩니다. 문제가 생긴 시점의 로그가 버퍼에서 밀려나 사라졌거나, 기기와 연결이 끊긴 동안 공백이 생겼거나, 저장 형식이 분석 도구와 맞지 않으면 아무리 좋은 분석 도구도 소용이 없습니다. 이 글은 Android(셋톱박스·TV·스마트폰 공통) 로그를 adb logcat으로 수집할 때 지켜야 할 것들을 순서대로 정리합니다.

1. 기본 명령: 형식은 threadtime으로

adb devices                                  # 기기가 "device"로 보이는지 확인
adb logcat -v threadtime > device.log        # 실시간 수집 → 파일로 저장 (Ctrl+C로 종료)

-v는 출력 형식입니다. 기본값(brief)에는 날짜와 시간이 없어 분석이 어렵습니다. threadtime은 날짜·시간(밀리초), PID, TID, 레벨, 태그, 메시지를 한 줄에 모두 담아 원인 추적에 가장 많이 쓰입니다.

08-23 10:15:32.123  1234  1256 E ActivityManager: ANR in com.example.app
│                   │     │    │ └ 태그          └ 메시지
│                   │     │    └ 레벨(V D I W E F S)
│                   │     └ 스레드 ID(TID)
│                   └ 프로세스 ID(PID)
└ 날짜 시간(월-일 시:분:초.밀리초)

기본 threadtime에는 연도가 없습니다. 연말·연초에 걸친 로그를 다루거나 여러 해의 로그를 섞어 볼 때는 -v year를 함께 주세요 (adb logcat -v threadtime -v year). 이 옵션은 안드로이드 버전에 따라 지원 여부가 다를 수 있습니다. 기기 시간대가 PC와 다르다면 -v UTC를 추가해 기준을 통일하는 방법도 있습니다.

2. 버퍼를 알아야 빠진 로그가 없다

logcat은 하나의 로그가 아니라 여러 개의 순환 버퍼입니다. 가득 차면 가장 오래된 기록부터 덮어씁니다.

버퍼	담는 내용
`main`	앱과 일반 프로세스의 로그(기본으로 보이는 것)
`system`	시스템 서비스의 로그
`crash`	앱·네이티브 크래시 정보(작지만 중요)
`events`	바이너리 형태의 시스템 이벤트
`radio`	통신(모뎀) 관련 — 셋톱박스에서는 없거나 비어 있을 수 있음

adb logcat -b main -b system -b crash -v threadtime > device.log   # 필요한 버퍼를 직접 지정
adb logcat -b all -v threadtime > device_all.log                   # 모든 버퍼 (기기가 지원하는 경우)
adb logcat -g                                                      # 각 버퍼의 현재 크기·사용량 확인

버퍼 지정을 생략하면 기본 버퍼(대개 main·system·crash)만 나옵니다. 재현이 어려운 문제라면 처음부터 필요한 버퍼를 명시해 두세요.

버퍼 크기 늘리기

기본 버퍼 크기는 기기마다 다르며, 로그가 많은 기기에서는 수 분 만에 덮어써질 수 있습니다. 문제가 발생한 뒤에 수집을 시작하면 이미 사라진 뒤일 수 있으므로, 문제가 드물게 나는 경우에는 수집 전에 버퍼를 키워 두는 것이 안전합니다.

adb logcat -G 16M      # 버퍼 크기를 16MB로 (기기 권한·정책에 따라 거부될 수 있음)
adb logcat -g          # 적용됐는지 확인

3. 저장할 때 흔히 생기는 문제

3-1. Windows PowerShell의 `>` 리다이렉션은 UTF-16으로 저장한다

Windows PowerShell 5.1에서 adb logcat ... > device.log를 실행하면 파일이 UTF-16(LE)으로 저장됩니다. 이런 파일은 글자 사이사이에 보이지 않는 널 문자가 끼어 있어 텍스트 편집기·검색·분석 도구에서 한 줄도 인식되지 않는 경우가 많습니다. 이 대시보드는 UTF-8 파일만 읽습니다. 다음 중 하나로 저장하세요.

:: 방법 1) 명령 프롬프트(cmd.exe)에서 실행 — 바이트 그대로 저장됨
adb logcat -v threadtime > device.log

# 방법 2) PowerShell에서 인코딩을 지정
adb logcat -v threadtime | Out-File -Encoding utf8 device.log

PowerShell 7 이상은 기본 인코딩이 UTF-8이라 이 문제가 없습니다. 파일을 열었을 때 글자가 띄엄띄엄 보이면 UTF-16을 의심하세요.

3-2. 저장 전에 버퍼를 비울지 결정한다

adb logcat -c는 기존 버퍼를 지웁니다. 재현 테스트에서는 비우고 시작해야 이전 로그와 섞이지 않지만, 이미 발생한 문제를 뒤늦게 확인하는 상황에서는 절대 지우면 안 됩니다. 순서는 "수집 명령을 먼저 실행 → 그 다음 재현" 또는 "adb logcat -d로 지금 버퍼를 일괄 덤프"입니다.

adb logcat -d -v threadtime > snapshot.log   # 현재 버퍼 내용을 저장하고 즉시 종료

4. 오래 수집할 때

파일이 커진다 — 몇 시간만 수집해도 수백 MB가 될 수 있습니다. 기기 안에서 회전(rotate)시키는 방법이 있습니다: adb logcat -f /sdcard/log.txt -r 4096 -n 8 (4MB씩 8개 파일을 돌려 씀. 경로 쓰기 권한은 기기에 따라 다름)
연결이 끊기면 수집도 끝난다 — USB·네트워크 adb가 끊기면 logcat 프로세스도 종료됩니다. 밤새 수집하려면 재연결 루프를 두세요.

:: reconnect.bat — 끊겨도 다시 붙어서 같은 파일에 이어 쓴다
@echo off
:loop
adb wait-for-device
adb logcat -v threadtime >> device.log
goto loop

이 방식은 재연결 시점에 공백 구간이 생깁니다. 분석할 때는 "로그가 없는 시간"이 "문제가 없는 시간"이 아니라는 점을 기억하세요. 일별 발생 추이 그래프에서 유독 조용한 날이 있다면 수집이 끊겼던 날일 수 있습니다.

5. 로그와 함께 남기면 좋은 정보

기기 정보 — adb shell getprop ro.build.fingerprint, 앱·펌웨어 버전. 같은 로그도 버전이 다르면 의미가 달라집니다.
재현 절차와 시각 — "몇 시 몇 분에 무엇을 눌렀다"는 메모 한 줄이 수만 줄 로그에서 원인 구간을 찾는 열쇠입니다.
bugreport — adb bugreport report.zip은 로그뿐 아니라 시스템 상태·메모리·서비스 덤프를 한 묶음으로 저장합니다(용량이 크고 개인정보가 포함될 수 있음).

6. 수집 체크리스트

adb devices에서 기기가 device 상태인가?
버퍼 크기가 재현 시간 동안 버틸 만큼 충분한가? (-g)
형식은 -v threadtime인가? (필요하면 -v year)
저장한 파일이 UTF-8인가? (Windows PowerShell 주의)
재현 시각과 기기·펌웨어 정보를 함께 기록했는가?

수집한 파일은 로그 분석 대시보드에 그대로 올리면 오류(E)·치명적 결함(F)을 태그·파일·날짜별로 정리해 줍니다. 결과를 어떻게 읽어야 하는지는 레벨과 태그 읽는 법, 원인 구간을 좁히는 순서는 로그 분석 순서 글에서 이어집니다.