# Apple, 사용자가 직접 ‘미수정 확인’을 하지 않으면 버그 리포트를 임의로 닫는 문제 > Clean Markdown view of GeekNews topic #27892. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27892](https://news.hada.io/topic?id=27892) - GeekNews Markdown: [https://news.hada.io/topic/27892.md](https://news.hada.io/topic/27892.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-27T04:33:20+09:00 - Updated: 2026-03-27T04:33:20+09:00 - Original source: [lapcatsoftware.com](https://lapcatsoftware.com/articles/2026/3/11.html) - Points: 1 - Comments: 1 ## Topic Body - Apple이 **Feedback Assistant**를 통해 보고된 버그를, 사용자가 “아직 수정되지 않았음”을 **직접 확인(verify)** 하지 않으면 자동으로 종료함 - 3년간 응답이 없던 **네트워크 필터 확장 관련 개인정보 유출 버그(FB12088655)** 에 대해, Apple이 갑자기 확인을 요구하고 2주 내 응답이 없으면 수정된 것으로 간주함 - 그러나 **Little Snitch 개발자**들이 최신 macOS에서도 동일한 문제가 남아 있음을 확인함에도, Apple은 리포트를 닫음 - 이러한 절차는 **버그 리포트 수를 인위적으로 줄이는 구조**로 작동해, 실제 품질 문제를 가리는 효과를 냄 - 결과적으로 Apple의 **버그 관리 방식이 개발자 신뢰를 약화**시키고, 협력적 피드백 문화를 저해하는 문제로 지적됨 --- ### Apple의 버그 리포트 자동 종료 문제 - **Apple Feedback Assistant**를 통해 버그를 보고한 개발자가, Apple이 사용자의 확인 없이 임의로 리포트를 닫는 관행을 비판함 - Apple은 사용자가 “버그가 아직 수정되지 않았음”을 직접 확인하지 않으면 해당 리포트를 **자동 종료**함 - 수년간 응답이 없다가 갑자기 확인 요청을 보내며, 2주 내 응답이 없으면 “수정 완료”로 간주함 - 2023년 3월 제출된 **FB12088655 “Privacy: Network filter extension TCP connection and IP address leak”** 사례에서, 3년간 응답이 없다가 2026년 3월에야 Apple이 macOS 26.4 beta 4에서의 확인을 요청함 - 베타 OS를 상시 설치하지 않아 확인이 어려웠고, Apple에 수정 여부를 문의했으나 **명확한 답변을 받지 못함** - Apple은 “2주 내 확인하지 않으면 수정된 것으로 간주하고 리포트를 닫겠다”고 통보함 - **Little Snitch 개발자들**이 macOS 26.4 beta 4에서도 동일한 문제가 재현된다고 보고함 - 실제 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은 응답하지 않음** - iPadOS 26.4 베타에서는 **Safari 충돌 버그**가 새로 발생했으며, Apple은 이를 **공개 버전 출시 전까지 수정하지 않음** - 작성자는 “베타의 목적이 버그 수정이 아니라, 버그를 보고하는 사람을 귀찮게 하는 것 같다”고 비판함 ### Hacker News 이후의 변화와 Apple의 대응 - 이 글이 **Hacker News** 첫 페이지에 오른 직후, Apple은 FB22057274 리포트를 업데이트함 - Apple은 **UI 문제에 대해 sysdiagnose 로그 제출**을 요청함 - 이미 **재현 단계와 화면 녹화 영상**을 제공했으며, sysdiagnose는 **개인정보 침해 위험이 있고 불필요한 자료**라고 지적됨 - 작성자는 Apple의 요청에 대해 다음과 같이 응답함 - “UI 버그에는 sysdiagnose가 필요하지 않으며 도움이 되지 않는다” - **Little Snitch 없이도 재현 가능한 방법**으로, Xcode Additional Tools의 **Network Link Conditioner**를 이용해 업링크 지연 3000ms 프로필을 설정하면 동일한 현상을 재현할 수 있다고 제시함 ### Xcode Additional Tools 안내 - **Xcode Additional Tools**에는 여러 유용한 유틸리티가 포함되어 있으며, **Apple Developer Downloads** 페이지(로그인 필요)에서 다운로드 가능함 ### 종합 평가 - Apple의 **버그 리포트 관리 방식**은 개발자에게 불필요한 부담을 주며, **실제 문제 해결보다 리포트 수 감소에 초점**을 맞춘 구조로 작동함 - 장기간 응답 없는 리포트, 불합리한 확인 요구, 비효율적인 정보 요청 등으로 인해 **개발자 신뢰와 협력 의지**가 약화되고 있음 ## Comments ### Comment 53921 - Author: neo - Created: 2026-03-27T04:33:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47521876) - 작성자가 **엔터프라이즈 소프트웨어**를 경험해보지 않았을 것 같음 개발자가 버그 리포트를 받으면 “재현이 안 되는데 최신 버전에서 확인해보셨나요?”라며 아무것도 안 하고 시간을 끄는 전형적인 수법임 확인이 안 되면 “사용자 오류”나 “재현 불가”로 닫아버림 유일한 대응책은 “네, 확인했습니다”라고 말하면서 실제로는 확인하지 않는 것뿐임 - Microsoft 유료 지원을 써봤는데, 항상 **증거 제출**을 요구함 로그에 백신이 보이면 “그쪽에 문의하세요”라며 바로 닫아버림 - 내부 사정을 보면 악의적이라기보단 **비용 대비 효율** 문제임 한 명의 사용자가 제기한 버그보다 더 중요한 비즈니스 우선순위가 많기 때문임 그래도 사용자 입장에서는 안타까운 일임 - 오픈소스에서도 똑같음. **stalebot**이 자동으로 오래된 이슈를 닫아버림 - 나는 이메일에 바로 넣을 수 있는 **재현 GIF**를 잘 만드는 법을 배웠음 대부분의 개발자는 자기 제품을 테스트할 줄 모르거나 귀찮아함 - 양쪽 입장을 다 겪어봤음 엔터프라이즈 기술 지원 시절엔 하루에 최소 두 건씩 새 케이스를 받아야 했고, 20건 넘게 동시에 관리했음 아무 진전 없는 케이스를 “비활성화 종료”로 닫을 때 느끼는 해방감이 컸음 나중엔 닫기 전에 세 번 연락하라는 규정이 생겨 악몽이었음 결국 **대기업 관료주의**가 모든 걸 망침 - Apple이 버그가 **자연스럽게 사라지길 기도**하는 듯한 태도를 보임 나도 이제는 버그 리포트를 안 올림 무시당하는 건 괜찮지만, 문제는 그들이 나를 **무급 QA 인력**으로 취급할 때임 버그 존재를 증명하기 위해 엄청난 노력을 요구함 - Microsoft도 비슷함, 특히 Azure나 365 관련 이슈에서 “이건 네 소프트웨어니까 네가 디버깅해라”는 생각임 - 오픈소스 프로젝트들도 비슷하게 **stale 이슈 자동 종료**를 함 일정 기간 지나면 자동으로 해결된 것으로 간주하는 건 말이 안 됨 - 유지보수자 입장에서는 우선순위가 다를 수 있음 오픈소스의 장점은 직접 고치거나 **PR 제출**, 혹은 포크해서 해결할 수 있다는 점임 - stalebot이 닫는 게 아니라 **stale 라벨만 붙이는 것**은 괜찮음 오래된 티켓을 필터링하는 게 더 합리적임 - 사용자 입장에서 짜증나지만, 모든 버그가 쉽게 **재현 가능한 건 아님** 때로는 관련 코드 변경 후 사용자에게 다시 테스트 요청하는 게 효율적임 그래도 오래된 비실행 가능한 버그를 닫을 때는 마음이 불편함 - 예전에 Mac을 ActiveDirectory에 붙이는 작업을 했는데, Apple의 단골 답변은 “**works on 17!**”이었음 그건 Apple 내부 네트워크에서만 재현이 안 된다는 뜻이었음 - “그냥 열어두면 되지 않느냐”는 의견도 있음 닫는 건 문제를 가리는 행위일 뿐이고, **열어두는 데 비용이 들지 않음** - Apple은 “재현 불가”도 아니고 “수정 완료”도 아닌, 단지 “macOS 26.4 beta 4에서 확인해보라”고만 함 베타를 설치해야 하는 건 사용자에게 훨씬 비효율적임 나는 Xcode 샘플 프로젝트와 재현 단계까지 제공했음 Apple은 아무것도 안 했다고 확신함 아마 WWDC 전 macOS 27 준비를 위해 **버그 정리 쇼**를 하는 듯함 - Apple 같은 회사라면 **시스템 상태를 완벽히 캡처**해서 재현할 수 있는 도구가 있어야 함 - Facebook과 Google에서 일할 때 **버그 관리 꼼수**를 많이 봤음 SLA 도입 후 버그 우선순위를 인위적으로 낮추거나, “아직 문제인가요?”라며 사용자에게 떠넘김 시간이 지나면 “버전이 폐기됐다”며 닫아버림 심지어 다른 버그와 억지로 **병합**해서 책임을 회피하기도 함 결국 이런 건 **조직의 성과 지표(SLA)** 때문임 그래서 이제는 버그 리포트를 거의 안 함 - 엔지니어들은 사실 버그를 고치고 싶어함 하지만 경영진이 “지금은 AI 프로젝트에 집중하라”고 지시함 그러면서 “버그가 너무 많다”고 꾸짖음 - 나도 p2/s2를 p3/s3로 낮춘 적 있음 닫는 대신 그냥 무시하는 게 솔직하다고 생각함 리더십은 이런 식으로 **강제 트리아지**를 유도했음 자동 알림을 막는 건 문제임 - 우선순위(priority)와 심각도(severity)를 구분하는 이유는 예를 들어 사이트가 완전히 죽었어도 지금은 **비성수기**라면 P0가 아닐 수 있기 때문임 하지만 현실적으로는 데이터 품질이 낮아 보고용으로 쓸 수 없음 그래서 단일 우선순위 값이 더 실용적임 stalebot이 이런 무시된 이슈를 대신 닫아주는 셈임 - 내가 일했던 대기업에서도 비슷했음 고객용 **severity**와 내부용 **priority**를 따로 관리했음 Salesforce “Lightning Experience”는 이름과 달리 **매우 느림** 내부 도구가 훨씬 빠르고 효율적이었음 - 이 모든 건 전형적인 **대리인 문제(principal-agent problem)** 의 사례임 - ElevenLabs에서도 같은 일이 있었음 버그 리포트를 올리면 AI가 자동으로 답하고, 48시간 후 **stale 처리**됨 - ElevenLabs 직원이 등장해 “GitHub 오픈소스 리포지토리로 제출하면 사람이 직접 답변한다”고 안내함 - 곧 **LLM 에이전트**가 이런 문제를 해결할 것 같음 자동으로 “아직 안 고쳐졌습니다”라고 댓글을 달고, 주기적으로 “이건 중요한 워크플로에 영향을 줍니다”라며 **자동 bump**할 수 있음 - 만약 유지보수자가 이슈를 닫으면, 에이전트가 자동으로 **비판 블로그 글**을 올릴 수도 있음 - 예전에 Microsoft에 버그를 제출했는데, 몇 달 후 “재현 불가” 연락을 받음 사실 그 사이 다른 수정으로 간접적으로 해결된 것이었음 내가 **코끼리의 일부분만 본 맹인**이었다는 걸 깨달음 - 전 Apple 직원임 Apple 내부 버그 트래커는 **Radar**라 불리고, 모든 이슈는 “Verify” 단계를 거쳐야 닫을 수 있음 겉보기엔 품질 보증 절차 같지만, 실제로는 수많은 Radar가 Verify 상태에서 **영원히 멈춤** 팀들은 “미검증 Radar 수”로 평가받기 때문에 일정 기간 후 강제로 닫아버림 - 대부분의 팀은 Verify를 사실상 **Closed 상태처럼 사용**함 “버그 0개”라는 허상은 **왜곡된 성과지표**를 낳음 - 해결책은 “재오픈된 버그 수”도 함께 평가하는 것임 - Feedback Assistant의 “최신 베타에서 확인해보라”는 메시지는 Radar의 Verify 상태와는 별개임 Apple 엔지니어가 실제로 수정 시도를 했다고 보긴 어려움 - 회사에서 동료들과 함께 **백로그 정리 회의**를 하며 오래된 일회성 버그들을 정리했음 이런 프로세스는 매우 일반적임