Mac에서 앱이 강제 종료되는 일은 생각보다 드문 편입니다. 그래도 한 번 발생하고 나면 원인을 추적해보고 싶어지죠. 특히 개발자라면 자신이 만든 앱이 왜 충돌하는지 정확히 이해해야 합니다. 이 글에서는 macOS 충돌 보고서를 확인하고 난해한 용어들을 해석하는 방법을 소개합니다.
충돌 보고서 열기
Mac에서 앱이 충돌하면 시스템이 자동으로 충돌 보고서를 생성합니다. 앱이 종료된 직후 "[앱 이름]이(가) 예기치 않게 종료되었습니다"라는 경고 대화상자가 나타나는데, 이 창에서 "보고..." 버튼을 클릭하면 즉시 보고서를 확인할 수 있습니다. 콘솔(Console) 앱에서도 동일한 보고서를 열람할 수 있습니다.
1. Spotlight에 "Console(콘솔)"을 입력하거나 "응용 프로그램 -> 유틸리티 -> 콘솔.app"으로 이동해 콘솔 앱을 실행합니다.
2. 왼쪽 메뉴에서 "사용자 보고서(User Reports)"를 클릭한 뒤, 확인하고 싶은 충돌 보고서를 선택하세요. 모든 파일은 ".crash" 확장자로 끝나며, 파일명에 날짜와 충돌한 애플리케이션 이름이 포함됩니다. 파일을 선택하면 오른쪽 패널에서 상세 내역을 확인할 수 있습니다.
macOS 충돌 보고서 읽는 법
충돌 보고서를 위에서부터 차례대로 살펴보겠습니다.
무엇이 충돌했는가?
보고서의 첫 번째 부분은 어떤 "프로세스", 즉 어떤 애플리케이션이 충돌했는지 알려줍니다. 일반적인 문제 해결 과정에서 가장 중요한 정보는 프로세스 이름입니다.
Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: aText [11473] User ID: 501
언제 충돌했는가?
두 번째 부분은 충돌 발생 시점을 알려주며, 사용 중인 시스템에 대한 정보도 함께 제공합니다.
Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
무엇이 충돌을 일으켰는가?
다음 부분이 가장 많은 단서를 제공합니다. 애플리케이션이 반환한 "예외 유형(Exception Type)"이 충돌의 원인을 알려줍니다. 로그에는 어떤 스레드가 충돌했는지도 기록되어 있습니다. 여기서는 스레드 0입니다.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0]
Apple은 기술 문서에서 자주 발생하는 예외 유형들을 다음과 같이 설명하고 있습니다.
- 잘못된 메모리 접근(Bad Memory Access,
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – 프로그램이 잘못된 방식이나 유효하지 않은 주소로 메모리에 접근하려 할 때 발생합니다. 메모리 문제를 설명하는 코드가 함께 표시됩니다. - 비정상 종료(Abnormal Exit,
EXC_CRASH/SIGABRT) – 주로 처리되지 않은 C++ 예외나abort()호출로 인한 비정상 종료입니다. - 트레이스 트랩(Trace Trap,
EXC_BREAKPOINT/SIGTRAP) – SIGABRT와 유사하지만, 디버거가 연결되어 있다면 중단점에서 프로세스를 멈추고 오류를 추적할 기회를 제공합니다. - 잘못된 명령(Illegal Instruction,
EXC_BAD_INSTRUCTION/SIGILL) – 프로세스가 이해할 수 없거나 처리할 수 없는 명령을 실행했을 때 발생합니다. - 종료 요청(Quit,
SIGQUIT) – 충분한 권한을 가진 다른 프로세스에 의해 종료된 경우입니다. 보통 감시(watchdog) 프로세스가 비정상적으로 동작하는 프로세스를 종료시킵니다. - 강제 종료(Killed,
SIGKILL) – 시스템의 요청으로 프로세스가 종료된 경우입니다. 종료 사유를 설명하는 코드가 함께 표시됩니다.
위 충돌 보고서를 보면 애플리케이션이 매핑되지 않은 메모리에 접근하려 했음을 알 수 있습니다. 이는 앱 내부의 프로그래밍 오류 또는 특이한 사용자 환경으로 인해 메모리 매핑이 잘못된 경우에 발생합니다.
무엇이 충돌로 이어졌는가?
그다음에는 충돌 직전까지의 상황이 최신 순으로 역정렬된 목록이 나타납니다. 항목들은 스레드별로 정렬되며 스레드 0부터 시작합니다.
이 보고서는 네 개의 열로 구성됩니다. 첫 번째 열은 0부터 시작해 역순으로 매겨진 이벤트 번호, 두 번째는 프로세스 식별자, 세 번째는 메모리상의 프로세스 주소, 네 번째는 프로그램 작업(task)의 이름입니다.
이 "백트레이스(backtrace)"는 다소 난해할 수 있습니다. 백트레이스는 "심볼릭화(symbolicated)"되어 있는데, 이는 일부 메모리 주소가 함수 이름이나 앱 작업 이름으로 대체되었다는 뜻입니다. 하지만 항상 완벽하게 처리되지 않아 읽을 수 없는 메모리 주소가 곳곳에 남아 있기도 합니다.
위 충돌 보고서에서도 com.trankynam.aText는 심볼릭화되지 않았습니다. 심볼릭화가 완전하더라도 백트레이스를 해석하기 어려운 경우가 많습니다. 개발자가 앱 작업과 이벤트에 대한 유용한 설명을 남긴 경우도 있지만, 의미를 알 수 없는 이름이나 숫자 코드로 남는 때도 있습니다. 심볼릭 정보를 해석할 수 있다면 무슨 일이 일어났는지 파악할 수 있겠지만, 결국 백트레이스를 온전히 이해하려면 해당 앱을 직접 개발한 사람만 가능할 수도 있습니다.
결론: 이 보고서가 실제로 도움이 될까?
개발자에게 충돌 보고서 분석은 필수입니다. 앱의 어느 부분이, 왜 충돌하는지 파악하는 데 결정적인 단서를 제공하기 때문입니다. 일반 사용자에게는 상대적으로 덜 유용하지만, 반복적으로 발생하는 충돌이라면 문제를 진단하거나 개발자와 협력해 해결하는 데 큰 도움이 됩니다. 검색에 활용할 만한 에러 코드를 얻거나, 기술 지원팀에 정확한 정보를 전달할 수도 있습니다. 더 깊이 있는 내용이 궁금하다면 Apple의 공식 기술 노트에서 충돌 관련 상세 문서를 확인해 보세요.