Apple은 버그가 아직 안 고쳐졌다는 걸 네가 직접 “확인”하지 않으면 버그 리포트를 멋대로 닫아 버린다

source https://lapcatsoftware.com/articles/2026/3/11.html

2026년 3월 25일

내가 왜 Apple Feedback Assistant에 버그 리포트를 올리냐고? 미쳤다고밖에 할 말이 없다. 아니면 중독이겠지. 한동안은 끊었다가도 또다시 손을 대는 걸 반복한다. 사용자 경험을 개선하라며 요구사항 목록까지 붙여 공개적으로 Feedback Assistant 보이콧을 조직해 보려 한 적도 있지만, 다른 개발자들 사이에서는 전혀 호응을 얻지 못했다. 그래도 버그 리포트를 올릴 이유는 남아 있다. Apple이 내 버그 중 일부는 실제로 고치긴 하기 때문이다. 내가 버그 신고 절차에서 가장 불만인 건 버그가 안 고쳐진다는 사실 자체가 아니다. 버그 리포트와 그걸 올리는 사람들을 대하는 태도, 바로 그 무례함이다. Apple은 아무 거리낌 없이 우리 시간을 낭비시킨다. 마치 우리 시간에는 아무 값어치도 없고, 우리가 무슨 Apple을 위해 봉사할 의무라도 있는 것처럼.

2023년 3월, 나는 FB12088655 “Privacy: Network filter extension TCP connection and IP address leak.”를 등록했다. 당시 나는 이 버그 리포트를 블로그 글 하나에서도 언급했는데, Apple에 제출한 것과 똑같은 재현 절차와 예제 Xcode 프로젝트를 거기에도 실어 두었다. 버그를 올린 뒤 3년 동안 Apple은 아무 답도 하지 않았다… 몇 주 전까지는. 그러다 몇 주 전, Apple은 macOS 26.4 beta 4에서도 문제가 여전한지 내가 직접 “확인”하고 버그 리포트를 업데이트해 달라고 했다.

나는 해마다 6월이면 WWDC 베타를 설치하지만, 9월에 주요 OS 업데이트가 정식 출시되고 나면 그 뒤로는 OS 베타를 돌리지 않는다. 1년 내내 무급 테스터 노릇을 할 만큼 시간도 없고, 솔직히 말해 Apple 기기도 그만큼 많이 갖고 있지 않다. 그래서 베타에서 문제를 확인해 달라는 요청은 내게 꽤 번거롭다. 예전에도 이런 요청 때문에 데인 적이 있다. Apple이 고치지도 않은 문제를 베타에서 확인해 달라고 했던 적이 있었기 때문이다. 그래서 나는 Apple에 beta 4에서 이 버그가 고쳐졌는지 직접 물었다. 재현 절차를 이미 넘겨줬으니 그쪽이 먼저 알고 있어야 맞다! 하지만 돌아온 답변은 질문을 피해 가기만 했고, 내 물음에 정면으로 답하지도 않았다. 게다가 2주 안에 내가 확인하지 않으면 버그가 해결된 걸로 간주하고 리포트를 닫겠다고 으름장까지 놨다! 다시 말하지만, 그 전에 Apple은 내 버그 리포트를 3년 동안 조용히 묵혀 두고 있었다.

내가 직접 beta를 설치하지는 않았지만, macOS 베타를 운용하는 Little Snitch 개발사와 이야기해 봤고, 그들은 친절하게도 자신들의 테스트에서 macOS 26.4 beta 4에서도 내 문제가 여전히 재현된다고 알려 주었다. 그래서 Apple이 어제 정식 공개한 macOS 26.4로 업데이트한 뒤에도 내가 내 재현 절차와 예제 프로젝트로 여전히 버그를 재현할 수 있었던 건 전혀 놀라운 일이 아니었다. Apple은 자신들이 아무것도 고치지 않은 버그를 내가 직접 “확인”하라고 몰아붙이며, 사실상 쓸데없는 헛고생을 시킨 셈이다. 혹시 자기들이 아무 노력도 안 했는데 버그가 저절로 사라졌기를 속으로 빌고 있었던 건 아닌가 싶다.

참고로 몇 주 전 나는 또 다른 버그, FB22057274 “Pinned tabs: slow-loading target=”_blank” links appear in the wrong tab,”에 관한 블로그 글을 올렸다. 이 문제도 100% 재현되는데, Apple은 여기에 “Investigation complete - Unable to diagnose with current information.”이라는 결론을 붙여 버렸다. 3월 9일 나는 버그 리포트를 업데이트하며 Apple이 내게 추가로 무엇이 필요한지 물었다. 그들은 추가 정보를 요청한 적조차 없었기 때문이다. 하지만 아직도 아무 답을 받지 못했다.

나는 Apple 경영진 어딘가에 버그가 실제로 고쳐졌는지와 상관없이, 일단 버그 리포트 수부터 줄이라고 아랫사람들을 몰아붙이는 얼간이들이 있다고밖에 생각할 수 없다. 눈에 안 보이면 없는 일 취급인 셈이다. 아마 Apple 내부 지표는 소프트웨어 품질에 아무 문제가 없다고 말해 줄 것이다. 열려 있는 버그 리포트 수를 인위적으로 낮게 유지하고 있으니 말이다.

아이러니하게도 iPadOS 26.4 베타에서는 한 달 전에 내가 신고했던 Safari 크래시 버그가 새로 생겼는데, Apple은 그 버그를 정식 출시 전에 고치지도 못했다. 도대체 베타는 왜 하는 건가? 내가 보기엔 버그를 신고하는 사람들만 짜증 나게 할 뿐, 정작 쓸모 있는 일은 아무것도 안 하는 게 베타의 존재 이유다.

2026년 3월 26일 덧붙임

어제 이 블로그 글이 Hacker News 첫 화면에 올라간 직후, 내 “Investigation complete - Unable to diagnose with current information” Feedback FB22057274가 Apple에 의해 업데이트됐다. 참 놀라운 우연이다! 안타깝게도 그 업데이트는 도움이 되지 않았다. Apple이 sysdiagnose를 요구했기 때문이다. 사용자 인터페이스 문제에 말이다! 이건 정확히 내가 이전 블로그 글에서 우려했던 일이었다.

솔직히 이걸 진단하는 데 Apple이 내게서 무슨 추가 정보를 더 필요로 하는지 모르겠다. 나는 재현 절차뿐 아니라 이를 보여 주는 화면 녹화도 여러 개 첨부했다. 내 짐작엔 Apple은 내 버그 리포트를 아예 읽지도 않은 것 같다. sysdiagnose 보고서를 붙이지 않았다는 이유로 말이다. 하지만 개인정보를 침해하는 sysdiagnose가 이 경우에 무슨 도움이 되는거냐?

[…]

내 버그 리포트에서 유일한 요령이라고 할 만한 건 Little Snitch를 써서 느리게 로드되는 링크를 흉내 냈다는 점뿐이다. 그 버그를 안정적으로 재현하는 가장 쉬운 방법이 그거였기 때문이다. 물론 느리게 로드되는 링크를 흉내 내는 방법은 얼마든지 있다. 하필 Apple Safari 엔지니어들이 그런 것조차 알아내지 못한다면 자기 일을 할 자격이 없는 사람들이다. 하지만 더 그럴듯한 설명은, 내 피드백이 구색 맞추기용 sysdiagnose가 없다는 이유로 그냥 무시당했다는 쪽이다. 물론 누가 알겠나. Apple은 내게 어떤 종류의 추가 정보도 요청하지 않았으니까.

오늘 아침 Apple의 요청에 내가 이렇게 답했다.

sysdiagnose는 필요 없다고 생각합니다. 사용자 인터페이스 버그에 sysdiagnose가 어떻게 도움이 될 수 있는지도 모르겠습니다.

Little Snitch 없이도 문제를 쉽게 재현하는 방법을 찾았습니다. Xcode Additional Tools 다운로드에 들어 있는 Network Link Conditioner 환경설정 패널을 사용한 뒤, Uplink Delay 3000 ms로 프로필을 하나 만들면 됩니다.

여러 유용한 유틸리티가 들어 있는 Xcode Additional Tools는 Apple Developer Downloads에서 받을 수 있다(로그인 필요).