해커 뉴스에서 1,058포인트. 얼마나 많은 개발자가 같은 문제에 대해 조용히 분노해왔는지를 정확히 보여주는 숫자다.

상황을 있는 그대로 말하면 이렇다. iOS, macOS, 혹은 어떤 Apple 플랫폼에서든 버그를 발견한다. 책임감 있게 행동해서 Apple의 Feedback Assistant를 통해 재현 단계, sysdiagnose 로그, 화면 녹화까지 첨부한 상세 리포트를 제출한다. 그리고 기다린다. 몇 달이 지난다. 그러다 어느 날, 최신 OS 릴리스에서 해당 버그가 여전히 존재하는지 "확인"해 달라는 이메일이 온다. 정해진 기간 안에 응답하지 않으면 Apple은 리포트를 해결 완료로 처리한다.

버그는 고쳐진 게 아니다. 행정적으로 사라진 것뿐이다.

오랜 Apple 생태계 블로거 Michael Tsai에 따르면, 이 패턴은 최근 몇 달간 가속화되었으며, 개발자들은 품질 보증이라기보다 자동화된 일괄 정리에 가까운 "확인 요청" 메일을 무더기로 받고 있다고 한다. 이 관행은 Apple의 가장 헌신적인 외부 테스터들—플랫폼이 진정으로 나아지길 바라서 버그를 보고하는 사람들—을 자신의 리포트가 살아남도록 싸워야 하는 무급 QA 관리자로 전락시켰다.

정확히 무슨 일이 벌어지고 있는가?

왜 이 문제가 이토록 큰 반발을 사는지 이해하려면, Apple 시스템 내부에서 버그 리포트의 생명주기를 알아야 한다.

개발자가 Feedback Assistant를 통해 리포트를 제출하면 대기열에 들어간다. Apple 엔지니어링이 이를 분류할 수도 있고 아닐 수도 있다. 공개 버그 트래커는 없다. 상태에 대한 투명성도 없다. 개발자가 프로세스를 들여다볼 수 있는 유일한 창구는 "Open," "유사한 리포트가 이미 접수됨," 또는 "Resolved"로 표시될 수 있는 상태 필드뿐이다.

새로운 문제점—Tsai가 기록하고 해커 뉴스와 Apple 개발자 포럼의 수십 명의 개발자가 확인한—은 Apple이 이제 주기적으로 개발자에게 보고한 버그가 최신 소프트웨어 버전에서도 여전히 존재하는지 확인해 달라는 자동 요청을 보낸다는 것이다. 응답하지 않으면 시스템이 리포트를 닫아버린다.

이건 그냥 일반적인 버그 트래커 관리 아닌가?

표면적으로는 그렇다. 모든 대규모 조직은 오래된 리포트를 정리해야 한다. Mozilla도 하고, Google도 한다. 차이는 구현 방식과 인센티브 구조에 있다.

Chromium이 버그를 "추가 정보 필요"로 표시하고 결국 닫을 때, 전체 이력은 공개된 채로 남는다. 누구나 다시 열 수 있다. 누구나 그것이 수정되었기 때문이 아니라 행정적 이유로 닫혔음을 볼 수 있다.

Apple의 시스템은 불투명하다. 개발자가 확인 기간을 놓쳐서 리포트가 닫히면, 그 종결은 실제 수정과 구별할 수 없다—Apple이 추적하는 내부 지표에서 말이다. 리포트를 제출한 개발자에게는 종결에 이의를 제기할 공개 포럼이 없다. 새 리포트를 제출해서 처음부터 다시 시작하는 수밖에 없다.

한 해커 뉴스 댓글 작성자의 표현을 빌리면: "이건 버그 분류가 아니다. 버그 소모전이다."

Apple이 왜 수정되지 않은 버그를 닫으려 하는가?

정확히 짚어보자. 쿠퍼티노 어딘가에 "숫자를 좋게 보이려고 모든 버그를 닫아라"라고 지시하는 메모가 존재한다고는 생각하지 않는다. 더 가능성 높은 설명은 구조적인 것이다.

Apple의 Feedback Assistant 팀은 아마도 백로그를 줄이라는 지침을 받았을 것이다. 확인 요청은 그렇게 하기 위한 합리적으로 들리는 메커니즘이다. 그러나 이 시스템 설계의 하류 효과는 왜곡된 인센티브다: 버그를 많이 보고할수록 더 많은 유지 관리 작업을 떠안게 된다. 모든 리포트는 주기적으로 관리하지 않으면 잃게 되는 의무가 된다.

1년에 50건의 상세 리포트를 제출하는 개발자는 이제 자신이 이미 문서화한 50개의 버그가 아직 존재한다는 것을 확인하는 데만 몇 시간을 쓴다. 리포트를 한 건도 제출하지 않는 개발자는 그런 부담이 없다.

개발자들이 실제로 말하고 있는 것

좌절감은 깊으며, 가벼운 불평꾼들에게서 나오는 게 아니다. 10년, 15년, 20년간 Apple 버그를 보고해온 사람들의 이야기다.

10년 넘게 비공식적인 Apple 개발자 관계 기록 역할을 해온 블로그의 Tsai는, Apple 자체 엔지니어링 팀이 확인한 버그가 나중에 확인 프로세스를 통해 자동 종결된 여러 사례를 조명했다. 한 개발자는 2021년에 인정받은 Core Data 버그를 보고했고, 2025년 말에 확인 요청을 받았으며, 출장 중이라 기한 내에 응답하지 못하는 사이에 해결 완료로 표시되는 것을 지켜봐야 했다.

해커 뉴스 스레드에서, WebKit 기여 이력이 긴 한 개발자는 이렇게 썼다: "2년 전에 버그 보고를 그만뒀습니다. 버그를 찾지 못해서가 아닙니다. 리포트를 유지하는 것 자체가 파트타임 잡이 됐기 때문입니다."

전직 Apple 엔지니어라고 밝힌 또 다른 댓글 작성자는 다른 시각을 제시했다: "내부 버그 데이터베이스는 정말로 압도적입니다. 수백만 건의 리포트가 있어요. 확인 시스템은 악의적인 게 아닙니다—실제 규모 문제에 대한 잘못된 해결책인 겁니다."

다른 플랫폼 벤더들은 버그 리포트를 어떻게 처리하는가

여기서 대조가 선명해진다. Google, Microsoft, 그리고 대부분의 주요 오픈소스 프로젝트는 공개 또는 반공개 버그 트래커를 운영한다. Chromium의 이슈 트래커는 완전히 검색 가능하다. .NET 런타임의 이슈는 GitHub에 있다. Android의 이슈 트래커는 완벽하지는 않지만 공개적인 가시성과 토론을 허용한다.

Apple은 리포트가 한 번 닫히면 보고자에게 사실상 구제 수단이 없는 완전히 비공개 버그 보고 시스템을 유지하는 유일한 주요 플랫폼 벤더로 남아 있다.

가장 가까운 비유는 학술 논문 심사일 것이다—다만 학술지가 당신의 연구 결과가 아직 유효하다고 믿는지 물어봐서 논문을 반려하고, 2주 안에 답하지 않으면 이를 철회로 간주하는 버전을 상상해보라.

소프트웨어 품질에 대한 실제 비용

이것은 어떤 홍보 위기보다 Apple이 더 우려해야 할 질문이다. 가장 상세하고, 가장 재현 가능한 버그 리포트를 제출하는 개발자들이 바로 확인 시스템에 가장 큰 부담을 지는 개발자들이다. 50건의 열린 리포트를 관리해야 하는 사람들이다. Apple의 QA 작업을 무료로 해주는 사람들이다.

그 개발자들이 떠나면—여러 증언에 따르면 이미 일어나고 있다—버그가 사라지는 건 아니다. 단지 보고되지 않을 뿐이다. 지표는 개선된다. 소프트웨어는 아니다.

버그 추적에 적용된 굿하트의 법칙이다: 플랫폼 품질의 척도가 열린 버그 리포트 수가 되면, 그 숫자를 줄이는 것은 더 이상 플랫폼 품질의 의미 있는 척도가 아니게 된다.

해결책은 어떤 모습일 수 있는가

개발자 커뮤니티에서 여러 제안이 돌고 있다. 가장 많이 요청되는 변경 사항들은 단순명쾌하다.

첫째, 확인 기간을 더 길고 유연하게 만들어야 한다. 본업이 있고, 출장 일정이 있거나, 단순히 휴가를 가는 개발자에게 2주는 너무 짧다.

둘째, Apple이 추적하는 내부 지표에서 "무응답으로 종결"과 "수정되어 종결"을 구분해야 한다. 이 두 카테고리가 하나의 "해결됨" 버킷으로 합쳐지면, 인센티브 문제는 데이터 자체에 내재되는 것이다.

셋째—이것이 구조적 개혁인데—어떤 형태로든 공개 버그 트래커를 고려해야 한다. Apple은 보안 우려와 경쟁적 민감성을 이유로 수십 년간 이를 거부해왔다. 하지만 현 시스템의 불투명성은 Apple이 받는 피드백의 질을 적극적으로 저하시키고 있다.

전직 Apple 개발자 관계 직원이 Tsai에게 익명을 조건으로 밝혔는데, 문제에 대한 내부 인식은 외부의 침묵이 시사하는 것보다 훨씬 높다고 한다: "내부 사람들은 시스템이 망가져 있다는 걸 압니다. 하지만 이를 고치려면 지표가 오해의 소지가 있었다는 걸 인정해야 하는데, 아무도 그 슬라이드를 발표하는 사람이 되고 싶어 하지 않습니다."

더 큰 그림

이건 단지 Apple만의 이야기가 아니다. 대규모 조직이 품질을 어떻게 측정하는지—그리고 그 측정이 어떻게 바로 그들이 의존하는 커뮤니티에 적대적으로 변할 수 있는지에 대한 이야기다.

Apple의 서드파티 개발자들은 사실상 소프트웨어 역사상 가장 큰 무급 QA 팀이다. 그들은 Apple이 내부적으로 재현할 수 없는 하드웨어 조합에서 테스트한다. 어떤 자동화된 테스트 스위트도 잡아내지 못할 엣지 케이스를 발견한다. Apple의 플랫폼 위에서 제품을 출시하고 그 플랫폼이 제대로 작동해야 하기 때문에 이 일을 한다.

확인 시스템은 그 노동을 일회용으로 취급한다. 그리고 개발자들은—오랜만에 처음으로—그 의견에 동의하기 시작했다.

해커 뉴스 스레드는 12시간도 안 돼 1,000포인트를 넘겼다. 이건 단순한 참여가 아니다. 이건 신호다.