저장된 로그에서 원인 구간 좁히기 — 타임라인·기준선·PID로 훑는 순서

로그 분석 방법론 · 원인 좁히기 · 보고 양식 · 민감정보 처리 · 2026년 9월

로그를 처음부터 읽기 시작하는 것은 가장 흔하고 가장 비효율적인 방법입니다. 오류 줄은 수백~수천 개인데, 그중 원인은 보통 한두 개이고 나머지는 그 결과로 따라 나온 연쇄 반응이기 때문입니다. 이 글은 저장된 로그 파일에서 "어디부터 볼 것인가"를 정하는 순서를 정리합니다. 큰 그림에서 시작해 점점 좁혀 들어가는 방식입니다.

0. 시작 전에 정할 것: 무엇을 찾는가

"증상 · 발생 시각(대략) · 재현 여부" 세 가지를 먼저 적습니다. "가끔 화면이 멈춘다"보다 "어제 저녁 8시쯤 재생 중 화면이 멈췄고, 재부팅 후 복구됐다"가 수십 배 빠르게 원인 구간을 찾게 해 줍니다. 시각을 모른다면 아래 1단계가 그것을 알려 줄 수 있습니다.

1. 큰 그림: 언제 오류가 몰렸는가

로그 분석 대시보드의 일별 결함 발생 추이는 하루 단위로 E·F가 몇 건 났는지 보여 줍니다. 평소보다 유독 높은 날이 있다면 그날이 조사 구간입니다. 반대로 이상하게 조용한 날도 의심하세요. 수집이 끊긴 날일 수 있습니다 (로그가 없다고 문제가 없었던 것이 아닙니다).

여러 파일을 올렸다면 파일별 결함 건수 그래프로 어느 기기·어느 회차에서 튀었는지 먼저 봅니다.
건수의 절대값보다 평소 대비 변화가 중요합니다. 원래 하루 2,000건이 나는 기기라면 2,300건은 이상 신호가 아닙니다.

2. 기준선과 비교하기 (가장 강력한 방법)

"이 오류가 정상인가?"는 로그만 봐서는 판단이 어렵습니다. 그래서 문제가 없었던 시기의 로그(기준선)를 함께 올려 비교합니다.

정상 시기 로그와 문제 시기 로그를 둘 다 불러옵니다(같은 이름의 파일은 덮어쓰니 파일명을 구분하세요).
파일 필터를 바꿔 가며 오류 태그별 건수를 비교합니다.
기준선에는 없고 문제 로그에만 나타난 태그, 또는 건수가 급증한 태그가 1순위 후보입니다.
기준선에도 똑같이 있는 오류는 "원래 나던 오류"이므로 일단 후순위로 미룹니다.

기준선이 없다면 재현 테스트를 하는 것이 빠릅니다. 버퍼를 비운 뒤(adb logcat -c) 재현 절차 1회만 수행하고 수집하면, 그 로그에는 조사와 무관한 잡음이 거의 들어 있지 않습니다. (수집 방법: adb logcat 수집 가이드)

3. 첫 오류 우선 원칙

결함 상세 표를 시간 순으로 놓고, 조사 구간 안에서 가장 먼저 나타난 E·F를 찾으세요. 한 번 무너지면 그 뒤로 연쇄적으로 오류가 쏟아지기 때문에, 건수가 많은 것이 아니라 시간이 앞선 것이 원인일 가능성이 높습니다.

10:15:31.900  I  MediaPlayer   : prepare complete            ← 정상
10:15:32.123  E  MediaCodec    : codec error -38             ← 첫 오류 (원인 후보)
10:15:32.130  E  ExoPlayer     : Playback error              ← 위의 결과
10:15:32.131  E  Player-UI     : failed to show error toast  ← 위의 결과의 결과

결과 쪽 오류를 고치려고 하면 끝이 없습니다. 위 예에서는 세 줄이 모두 "결함 3건"으로 집계되지만 고쳐야 하는 것은 첫 줄 하나입니다.

4. 앞뒤 문맥 살피기

직전 5~10초 — 오류 직전에 어떤 동작(채널 변경, 앱 전환, 네트워크 끊김)이 있었는지 봅니다. 표에서 시각을 확인한 뒤 원본 로그 파일에서 그 시각 앞뒤를 엽니다.
PID를 따라가기 — 오류가 난 프로세스의 PID를 기억해 두면 그 프로세스의 전후 이야기를 이어 볼 수 있습니다. 같은 앱의 PID가 갑자기 바뀌었다면 프로세스가 죽었다가 다시 뜬 것입니다. PID가 바뀐 시점이 곧 크래시·강제 종료 시점입니다.
TID — 같은 PID 안에서 어느 스레드가 말하는지 보면, 메인 스레드(TID = PID)의 지연인지 백그라운드 작업인지 구분됩니다.
W(경고)의 반복 — E가 없더라도 재시도·지연 경고가 수백 번 이어지다가 끊기는 패턴이 원인 구간일 수 있습니다.

5. 증상별로 먼저 볼 것

증상	먼저 찾을 패턴
앱이 갑자기 꺼짐	`FATAL EXCEPTION`(자바), `Fatal signal`(네이티브), `lowmemorykiller`/`lmkd`(메모리 부족으로 종료됨)
화면이 멈추고 반응 없음	`ANR in`, 메인 스레드 지연, `Watchdog`
기기가 스스로 재부팅됨	로그가 끊긴 시점 직전의 `Watchdog`·`Fatal signal`, 이후 부팅 관련 로그의 시작 시각
재생이 끊기거나 화질이 떨어짐	디코더(`MediaCodec`) 오류, 네트워크·재시도 경고
가끔만 발생	재현 조건을 좁히는 것이 먼저: 시각·동작 기록과 함께 여러 번 수집해 기준선과 비교

6. 결과를 정리하는 양식

분석 결과는 보고나 이슈 등록으로 이어져야 가치가 있습니다. 다음 다섯 항목이면 대부분 충분합니다.

증상      재생 중 화면 멈춤 후 앱 재시작 (2026-08-23 20:12경, 1회)
근거 로그  [파일명 device_0823.log, 12,345행 부근]
           20:12:04.881 E AndroidRuntime: FATAL EXCEPTION: main
           20:12:04.881 E AndroidRuntime: Process: com.example.app, PID: 2211
           ...at com.example.player.Renderer.draw(Renderer.java:118)
가설      Renderer.draw에서 null 참조 (직전 20:12:04.5에 화면 전환 동작)
확인 방법  화면 전환 직후 재생 종료를 반복하는 재현 테스트
영향 범위  파일 3개 중 1개에서만 발생, 같은 앱 버전 1.4.2

원문 로그 3~5줄을 그대로 붙이는 것이 핵심입니다. 대시보드의 결함 상세에서 "원문 보기"로 스택트레이스 전체를 복사할 수 있습니다. 요약문만 있으면 받는 사람이 다시 로그 파일을 열어 같은 작업을 반복해야 합니다.

로그에는 생각보다 많은 개인·기기 정보가 들어 있습니다. 외부 협력사·커뮤니티·AI 서비스에 붙여 넣기 전에 반드시 확인하세요.

계정 ID·이메일·전화번호, 로그인 토큰이나 세션 값, URL의 쿼리 파라미터
IP 주소, MAC 주소, 기기 일련번호·고유 식별자
사용자가 본 콘텐츠 제목·검색어·위치 정보

# PowerShell 예: 이메일과 IPv4 주소를 가린 사본 만들기 (원본은 그대로 둔다)
(Get-Content device.log -Encoding utf8) `
  -replace '[\w.+-]+@[\w-]+\.[\w.]+', '[email]' `
  -replace '\b\d{1,3}(\.\d{1,3}){3}\b', '[ip]' |
  Set-Content device_masked.log -Encoding utf8

이 대시보드는 파일을 서버로 보내지 않고 브라우저 안에서만 처리하므로, 분석을 위해 로그를 외부 서비스에 붙여 넣는 것보다 민감정보 노출 위험이 낮습니다. 다만 결과 화면을 캡처해 공유하거나 원문을 복사해 전달할 때는 같은 주의가 필요합니다.

정리

증상·시각·재현 여부를 적는다.
일별 추이로 이상한 날, 그리고 이상하게 조용한 날을 찾는다.
정상 로그와 비교해 새로 나타난 태그·급증한 태그를 후보로 삼는다.
시간이 가장 앞선 E·F(첫 오류)를 원인 후보로 본다.
PID·시각으로 앞뒤 문맥을 확인하고, 원문 로그를 근거로 붙여 보고한다.

레벨과 대표 패턴이 낯설다면 logcat 레벨과 태그 읽는 법을 먼저 읽어 보세요.