▲

Apple, 사용자가 직접 ‘미수정 확인’을 하지 않으면 버그 리포트를 임의로 닫는 문제

 (lapcatsoftware.com)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 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의 버그 리포트 관리 방식은 개발자에게 불필요한 부담을 주며, 실제 문제 해결보다 리포트 수 감소에 초점을 맞춘 구조로 작동함
  • 장기간 응답 없는 리포트, 불합리한 확인 요구, 비효율적인 정보 요청 등으로 인해 개발자 신뢰와 협력 의지가 약화되고 있음
▲
GN⁺ 7시간전  [-]
Hacker News 의견들

  • 작성자가 엔터프라이즈 소프트웨어를 경험해보지 않았을 것 같음
    개발자가 버그 리포트를 받으면 “재현이 안 되는데 최신 버전에서 확인해보셨나요?”라며 아무것도 안 하고 시간을 끄는 전형적인 수법임
    확인이 안 되면 “사용자 오류”나 “재현 불가”로 닫아버림
    유일한 대응책은 “네, 확인했습니다”라고 말하면서 실제로는 확인하지 않는 것뿐임

    • 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 엔지니어가 실제로 수정 시도를 했다고 보긴 어려움

  • 회사에서 동료들과 함께 백로그 정리 회의를 하며
    오래된 일회성 버그들을 정리했음
    이런 프로세스는 매우 일반적임

답변달기