버그 신고에 첨부하는 로그 파일에는 오류 메시지뿐 아니라 화면에 표시된 글, 비공개 메시지, 계정 정보 같은 민감한 내용도 들어갈 수 있다. 로그를 보내기 전에 무엇을 공유하는지 확인하고, 개발자는 명확한 경고와 안전한 기본 설정을 제공해야 한다.

로그에 무엇이 담길 수 있나

로그에는 시간과 오류 메시지, 스택 추적뿐 아니라 당시 사용자가 하던 일에 관한 정보도 기록될 수 있다. 앱과 기록 설정, 문제의 종류에 따라 화면에 표시된 글, 주고받은 메시지, 사용자 이름과 이메일 주소, 실명이 포함된 파일 경로, URL과 인증 토큰, 열어 둔 문서 이름, 클립보드 내용, 다른 앱과 서비스에 관한 정보, 내부 상태가 담길 수 있다.

앱에 따라 기록하는 정보의 양은 크게 다르다. 파일 이름이 debug.log라고 해서 내용이 안전한지는 알 수 없다. 앱은 기록할 필요가 있다고 판단한 정보를 저장하지만, 앱이 중요하다고 여기는 정보와 사용자가 비공개로 생각하는 정보는 다를 수 있다. 컴퓨터는 화면의 대화나 문서가 사적인지 알지 못한다.

화면 읽기 프로그램은 다른 앱의 내용을 접근할 수 있게 전달하므로 이메일, 사적인 메시지, 은행 계좌, 의료 기록, 업무 문서 등 화면에 나타난 정보를 접할 수 있다. 화면 읽기 프로그램에 문제가 생겼을 때 기록된 화면 내용이 원인 파악에 도움이 될 수 있지만, 유용하다고 해서 무해한 것은 아니다. 오류를 고치는 데 필요한 정보와 사용자의 다른 사생활 정보는 구분해야 한다.

로그에 화면 내용이 담길 수 있다는 경고를 보면, 실제로 담겼다고 가정하는 편이 안전하다. 어떤 버전이나 설정에서 무엇을 기록하는지 기억에 의존하지 말고, 경고에 적힌 가능성을 기준으로 공유 여부를 판단해야 한다.

로그를 보내지 않아도 버그를 신고할 수 있다

로그를 보내기 전에 전부 읽으라는 조언은 항상 현실적이지 않다. 로그는 수만 줄에 이를 수 있고, 바이너리 데이터나 인코딩된 내용처럼 만든 프로그램을 잘 알아야 해석할 수 있는 정보가 들어가기도 한다. 화면 읽기 프로그램으로 긴 로그를 확인하거나 기술적인 내용 속 민감한 한 줄을 찾아내기도 쉽지 않다.

내용을 합리적으로 확인하기 어렵다면 앱이 경고한 정보가 들어 있다고 보고 판단하면 된다. 로그를 보내지 않더라도 문제 상황과 재현 절차, 기대한 동작과 실제 동작을 설명해 버그를 신고할 수 있다. 개발자가 추가 정보를 필요로 할 수도 있지만, 더 안전하게 문제를 재현하거나 일부 진단 정보만 수집하는 방법을 함께 찾을 수 있다.

로그가 필요하다면 가능한 경우 새 로그를 시작하거나 기존 기록을 지운 뒤, 문제를 재현하기 직전에 기록을 켜고 끝난 직후 끄는 방법이 있다. 화면에 표시된 글이 문제와 관련된다면 시험용 문서나 더미 대화처럼 민감하지 않은 내용을 사용하고, 실제 정보 대신 가짜 정보를 넣어 볼 수 있다. 문서를 열 때 앱이 충돌한다면 기밀 내용이 없는, 서식이 비슷한 문서로 시험할 수도 있다.

이런 방법이 모든 문제에 통하는 것은 아니다. 간헐적으로 발생하거나 특정 데이터에 의존하는 버그도 있다. 안전하게 재현할 수 없다면 그 사실을 개발자에게 알리면 된다. 로그를 보내기로 했다면 자동으로 첨부하지 말고, 무엇을 공유할지 알고 결정해야 한다.

개발자도 수집 책임을 져야 한다

진단 정보를 수집하는 개발자는 그 정보에 무엇이 들어 있는지 파악해야 한다. 비밀번호를 기록하거나 인증 토큰을 평문 파일에 저장해서는 안 되며, 디버깅이 편하다는 이유만으로 임의의 사용자 콘텐츠를 수집해서도 안 된다. 민감한 정보가 기록될 수 있다면 개인정보 처리방침 깊숙한 곳이 아니라 전송 여부를 결정하는 시점에 분명히 알려야 한다. 가능한 경우 사용자가 수집 범위를 조절할 수 있게 하고, 기본 설정은 대체로 전송하지 않는 쪽에 두어야 한다.

디버깅에 도움이 되는 정보와 꼭 필요한 정보는 다르다. 스택 추적으로 충분하다면 그것만 수집하고, 오류 코드로 충분하다면 전체 로그를 요구하지 않아야 한다. 로그 일부만 필요하다면 필요한 부분을 구체적으로 요청해야 한다. 공개 이슈 트래커에 로그를 자동으로 첨부하는 일도 사용자가 충분히 알고 선택할 기회를 줘야 한다. 명확한 경고와 안전한 기본 설정을 함께 제공하는 것이 바람직하다.

버그 신고를 보낸 사람이 실수로 민감한 정보를 공유했을 때는 이를 퍼뜨리거나 조롱해서는 안 된다. 불필요한 로그 사본을 삭제하고, 공개된 곳에 올라갔다면 내리는 일을 도와야 한다. 인증 정보가 노출됐다면 폐기하거나 교체해야 할 수 있다고 알려야 한다. 정보를 볼 수 있다는 사실이 그 정보를 사용해도 된다는 뜻은 아니다.

개발자를 신뢰하더라도 개인정보 보호는 별개의 문제다. 신고가 어디에 저장되는지, 누가 볼 수 있는지, 첨부 파일이 공개되는지, 다른 시스템으로 복사되는지, 얼마나 오래 보관되는지도 알기 어려울 수 있다. 버그 신고는 기술 지원을 요청하는 일이지 사생활 보호를 포기하는 일이 아니다.

로그를 보낸 적이 있고 문제가 없었다는 경험도 다음 로그가 안전하다는 증거는 아니다. 과거 로그에 사적인 내용이 없었을 수도 있고, 있었지만 아무도 알아차리지 못했을 수도 있다. 그렇다고 버그 신고나 진단 정보 제공을 멈출 필요는 없다. 로그는 개발자가 문제를 찾는 데 큰 도움이 될 수 있다. 다만 경고를 진지하게 받아들이고, 내용을 확인할 수 없다면 안전하다고 단정하지 말아야 한다. 공유가 불편하다면 로그를 제외하면 된다.