Unity 크래시 로그 어디서 찾나 — 에디터·빌드·모바일 완전판

정상적으로 돌아가던 게임의 로그와, 크래시가 난 순간에만 생성되는 산출물은 다른 파일입니다. Editor.log·Player.log는 매 세션 갱신되지만, 크래시 덤프와 시스템 크래시 리포트는 그 순간에만, 별도 위치에 생깁니다. 평소 로그 파일 위치는 별도 글에서 이미 정리했으니, 이 글은 "게임이 죽었을 때 무엇이 남는가"만 다룹니다.

에디터 크래시와 플레이어 크래시는 다른 사건이다

먼저 구분해야 할 게 있습니다. 검색해서 여기 오신 분들이 가장 많이 헷갈리는 지점입니다.

• 에디터 크래시는 Unity Editor 프로세스 자체가 죽는 겁니다. Editor.log는 크래시 직전까지의 내용만 남고, 크래시의 원인은 별도의 크래시 리포트에 있습니다.
• 플레이어 크래시는 빌드된 게임이 죽는 겁니다. Player.log와 별개로, 플랫폼마다 정해진 위치에 크래시 리포트가 생깁니다.

두 경우 모두 "로그 파일이 멀쩡한데 왜 크래시 원인이 안 보이지"라는 질문으로 이어집니다. 답은 간단합니다 — 로그와 크래시 리포트는 애초에 다른 파일이기 때문입니다.

Windows — 크래시 폴더

Windows에서는 Unity Editor 프로세스가 죽었는지, 빌드된 Player가 죽었는지에 따라 경로가 다릅니다. Unity 6.6의 로그 파일 문서는 Editor 크래시 파일의 기본 경로를 %TMP%\Unity\Editor\Crashes\로 안내하며, -crash-report-folder 인자로 변경할 수 있다고 설명합니다. 같은 버전의 Windows.CrashReporting.crashReportFolder API 문서는 Player 크래시 리포트의 기본 경로를 %TMP%\<CompanyName>\<ProductName>\Crashes\로 안내합니다. Unity 버전과 실행 옵션에 따라 달라질 수 있으므로, Player에서는 이 API로 실제 경로를 확인하는 편이 정확합니다.

%TMP%\Unity\Editor\Crashes\                    (Unity 6.6 Editor 기본 경로)
%TMP%\<CompanyName>\<ProductName>\Crashes\    (Unity 6.6 Player 기본 경로)

생성되는 크래시 산출물의 종류는 Unity 버전과 설정에 따라 달라질 수 있습니다. 폴더를 실제로 채우는 프로세스가 따로 있는데, 다음 글에서 다룹니다. QA에게 요청할 때는 먼저 Editor와 Player 중 어느 쪽이 종료됐는지 확인하고, 해당 경로의 최신 Crashes 폴더를 통째로 보내 달라고 하는 편이 정확합니다.

macOS — 시스템 크래시 리포트

macOS는 Unity 자체 크래시 폴더가 아니라 OS의 시스템 크래시 리포터가 처리합니다. 에디터·플레이어 구분 없이 위치는 같습니다.

~/Library/Logs/DiagnosticReports/

.ips 확장자 파일로 남고, 파일명에 프로세스 이름과 타임스탬프가 들어갑니다. Finder의 Go to Folder로 바로 이동할 수 있고, Console.app에서도 조회됩니다.

Android — logcat이 현실적인 답이다

Android는 네이티브 크래시(엔진 레벨) 발생 시 시스템이 /data/tombstones/ 아래에 상세 리포트를 남깁니다. 다만 이 경로는 루트 권한 없이 일반 접근이 어렵습니다. 실무에서는 크래시 직후 logcat을 덤프하는 쪽이 현실적입니다.

adb logcat -d > crash.txt

네이티브 크래시는 로그에 시그널 정보와 백트레이스가 함께 찍힙니다. Unity의 -androidChainedSignalHandlerBehavior 인자는 네이티브 크래시를 처리하는 핸들러 체인의 동작을 설정합니다. Unity 6.6에서는 legacy 값이 제거됐으므로, 사용 중인 버전의 Unity 공식 문서를 확인하세요.

iOS — Xcode Organizer

iOS에서는 기기에 직접 연결하는 경로와 배포 빌드의 보고 경로를 구분해야 합니다. 연결된 기기의 로그는 Xcode의 Window → Devices and Simulators → 기기 선택 → View Device Logs에서 확인할 수 있습니다. TestFlight 또는 App Store 배포 빌드의 크래시 리포트는 Xcode Organizer의 Crashes에서 볼 수 있으며, TestFlight 리포트가 자체 파일 로깅에만 의존하는 것은 아닙니다. 기기에서는 설정 → 개인정보 보호 및 보안 → 분석 및 향상 → 분석 데이터에서 로그를 찾아 공유할 수도 있습니다. Apple의 크래시 리포트 수집 안내를 참고하세요.

정리 — QA에게 요청할 것

이 네 플랫폼 모두 공통점이 있습니다 — 크래시 순간이 지나면 사라지거나 덮인다는 것. Android logcat은 순환 버퍼라 오래 두면 덮이고, Windows·macOS 리포트도 앱을 재실행하면 새 크래시가 쌓여 예전 것을 찾기 번거로워집니다. 목격 직후 확보하는 습관이 경로를 외우는 것보다 중요합니다.

저희 Rekon은 이 산출물을 모으는 절차 자체를 우회합니다 — 이상을 목격한 순간 핫키 한 번으로 직전 영상·로그·게임 상태를 캡처합니다. 다만 핫키를 누를 틈조차 없는 즉사성 하드 크래시에는 이 캡처도 닿지 않습니다. 그런 경우에는 위 표의 경로들이 여전히 유일한 단서입니다.