일기 앱 충돌 보고서에는 어떤 내용이 포함될 수 있을까요?
일기 앱 충돌 보고서에는 충돌 스택 추적(stack trace), 기기 및 앱 버전, 타임스탬프, 인접한 진단 이벤트와 같은 기술적 세부 정보가 포함될 수 있습니다. 운영체제, 보고 서비스 및 앱 설정에 따라 앱에 입력되거나 표시된 콘텐츠를 노출할 수 있는 로그, 첨부 파일 또는 세션 리플레이 데이터가 포함될 수도 있습니다. 보고서에 항상 일기 내용이 자동으로 포함되는 것은 아니지만, 절대 포함되지 않는다고 단정해서도 안 됩니다. 보고서를 공유하기 전에 해당 보고서의 구체적인 내용과 앱 구성 방식을 확인하세요.
표준 충돌 보고서에는 무엇이 표시되나요?
스택 추적(stack trace)은 충돌과 관련된 함수 호출 목록을 보여줍니다. 이는 개발자가 문제가 발생한 코드 경로를 찾는 데 도움이 되지만, 일반적으로 그 자체만으로 전체 정황을 설명하거나 사용자가 무엇을 하고 있었는지 명확히 증명하지는 못합니다. 보고서에는 앱 및 운영체제 버전, 기기 모델, 충돌 시간 및 기타 환경 세부 정보도 식별될 수 있습니다. Apple은 충돌 보고서를 충돌 시점의 앱 상태에 대한 기록으로 설명하며 전체 운영체제 보고서를 분석할 것을 권장합니다. Apple의 가이드라인에는 기기, 앱, OS 정보와 같은 필드가 명시되어 있습니다. 자세한 내용은 Apple의 [충돌 보고서 분석 가이드](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report)를 참조하세요.
보고서 형식은 출처에 따라 다릅니다. Xcode를 통해 수집된 Apple 충돌 보고서와 Android 버그 보고서는 서로 다른 결과물입니다. Android 공식 가이드에 따르면 버그 보고서에는 기기 로그, 스택 추적, 시스템 서비스의 진단 출력, 오류 로그, Android의 `Log` 클래스를 사용하는 앱의 시스템 메시지가 포함될 수 있습니다. 이는 충돌 전용 기록보다 훨씬 광범위합니다. 개별 보고서의 내용은 여전히 수집 및 포함된 항목에 따라 달라집니다. 자세한 내용은 [Android의 버그 보고서 캡처 및 읽기 가이드](https://developer.android.com/studio/debug/bug-report)를 참조하세요.
보고서에 일기 텍스트가 포함될 수 있나요?
일부 설정에서는 포함될 수 있지만, 충돌 보고서가 존재한다는 사실 자체만으로 일기 텍스트가 포함되어 있다고 단정할 수는 없습니다. 핵심은 앱이 충돌과 함께 무엇을 기록하는지, 그리고 보고서 형식이 무엇을 캡처하는지입니다.
예를 들어 앱 개발자는 진단 로그 메시지나 맞춤 이벤트를 추가할 수 있습니다. 이러한 메시지에 일기 항목, 제목, 검색어 또는 편집기에서 복사한 텍스트가 포함되어 있다면 해당 정보가 이벤트와 함께 전송될 수 있습니다. Sentry는 브레드크럼(breadcrumbs)을 문제가 발생하기 전의 이벤트 기록으로 설명하며, 각 이벤트에는 메시지와 임의의 구조화된 데이터가 포함될 수 있습니다. 브레드크럼은 활성화된 연동 기능을 통해 자동으로 수집되거나 앱에 의해 직접 추가될 수 있습니다. 자세한 내용은 [Sentry의 브레드크럼 문서](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/)를 참조하세요. Android 버그 보고서에도 시스템 메시지 로그가 포함되어 있으며, 여기에 앱이 작성한 메시지가 들어 있을 수 있습니다. 두 가지 사실 모두 모든 앱이 비공개 텍스트를 기록한다는 의미는 아닙니다. 이는 앱의 구현 및 설정에 따라 달라집니다.
로그, 브레드크럼, 첨부 파일, 리플레이란 무엇인가요?
이러한 용어들은 서로 다른 유형의 진단 데이터를 나타냅니다. 로그는 앱이나 시스템이 기록한 메시지입니다. 브레드크럼은 오류 발생에 이르기까지의 선별된 이벤트 시퀀스로, 타임스탬프, 카테고리, 메시지, 키-값 데이터를 포함할 수 있습니다. 둘 다 앱이 기록하는 내용에 따라 스택 추적보다 더 많은 맥락을 드러낼 수 있습니다.
첨부 파일은 로그 파일, 스크린샷, 충돌 덤프(crash dump) 등 이벤트와 함께 전송되는 파일입니다. Sentry는 네이티브 미니덤프(minidumps)에 환경 변수, 로컬 경로, 입력 필드의 메모리 내 표현과 같은 민감한 정보가 포함될 수 있다고 명시합니다. 관련 문서에 따르면 미니덤프는 이벤트를 생성하는 데 사용된 후 기본적으로 폐기되지만, 해당 설정을 활성화하면 첨부 파일로 저장될 수 있습니다. 또한 첨부 파일은 Sentry의 데이터 스크러빙(data scrubbing) 대상에 포함되지 않는다고 명시되어 있습니다. 자세한 내용은 [Sentry의 충돌 데이터 문서](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) 및 [첨부 파일 문서](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/)를 참조하세요.
세션 리플레이(Session replay)는 별도의 선택적 기능이며 모든 충돌 보고서의 표준 구성 요소는 아닙니다. Sentry의 JavaScript 리플레이 문서에서는 이를 DOM 상태 및 상호작용을 포함하여 브라우저 활동을 비디오처럼 재구성하는 것으로 설명합니다. SDK는 기본적으로 DOM 텍스트, 이미지, 사용자 입력을 마스킹 처리하지만 다양한 설정 옵션도 제공합니다. 마스킹 설정과 지원 플랫폼이 중요합니다. 실제 제공자 설정과 개인정보 보호 구성을 확인하지 않은 채 일기 콘텐츠가 보이지 않거나 보호되고 있다고 섣불리 짐작하지 마세요. 자세한 내용은 [Sentry의 JavaScript 세션 리플레이 가이드](https://docs.sentry.io/platforms/javascript/session-replay/)를 참조하세요.
보고서를 공유하기 전에 무엇을 검토해야 할까요?
실제 파일이나 보고서 미리보기에서 다음 체크리스트를 확인하고, 보고서 내용이 명확하지 않은 경우 앱이나 서비스 제공자의 개인정보 보호 문서를 확인하세요:
이 체크리스트는 일기 앱 사용자가 보고서를 전송하기 전에 검토할 수 있는 실용적인 가이드입니다. 이는 개발자용 지침과는 별개입니다. 개발자는 자체 로깅, 리플레이, 첨부 파일 설정을 직접 제어하며, 이러한 기능이 무엇을 수집하는지 문서화하고 진단 필드에 사용자가 입력한 콘텐츠가 포함될 수 있는지 검토해야 합니다.
앱과 기기마다 보고서가 다른 이유는 무엇인가요?
운영체제마다 서로 다른 보고서 형식과 수집 경로를 사용하며, 개발자가 맞춤 설정이 적용된 서드파티 SDK를 사용할 수도 있습니다. Apple에 따르면 App Store 및 TestFlight 충돌 보고서는 Xcode를 통해 확인할 수 있지만, 기타 진단 로그는 기기에서 직접 가져와야 할 수 있습니다. Android는 전체 버그 보고서와 Google Play 또는 Firebase와 같은 서비스를 통해 제공되는 충돌 보고서를 구분합니다. 또한 서비스 제공자 설정에 따라 캡처 및 저장되는 이벤트, 브레드크럼, 첨부 파일, 리플레이 데이터가 달라질 수 있습니다. 모든 서비스가 동일한 필드를 전송한다고 가정하지 말고, 해당 앱의 개인정보 처리방침과 실제 보고서를 특정 사례의 기준으로 삼으세요.