무슨 일이 있었나요?
오랫동안 macOS와 iOS 앱을 개발해온 Jeff Johnson이 자신의 블로그에서 Apple의 버그 리포트 처리 방식에 대한 불만을 공유했어요. 핵심은 이거예요. Apple의 버그 추적 시스템인 Feedback Assistant에 버그를 제출하면, Apple이 일정 기간 후에 "이 버그가 최신 OS 버전에서도 여전히 재현되는지 확인해달라"는 요청을 보내요. 그런데 개발자가 이 요청에 일정 기간 내 응답하지 않으면, Apple은 해당 버그 리포트를 그냥 닫아버린다는 거예요. 버그가 실제로 수정됐는지와 상관없이요.
이게 왜 문제냐면, 개발자들은 바쁘거든요. Feedback Assistant에서 온 이메일을 놓칠 수도 있고, 특정 시점에 최신 베타 OS를 설치할 환경이 안 될 수도 있어요. 그런데 응답 안 했다고 버그를 자동으로 닫아버리면, 마치 그 버그가 해결된 것처럼 통계에 잡히게 돼요. 실제로는 아무것도 고쳐지지 않았는데 말이죠.
Apple Feedback Assistant의 구조적 문제
좀 더 자세히 들여다보면, 이건 단순히 "리포트 하나가 닫혔다"는 수준의 문제가 아니에요. Apple의 버그 리포트 시스템 전체에 구조적인 문제가 있다는 게 많은 개발자들의 의견이에요.
예전에 Apple은 Radar라는 내부 버그 추적 시스템을 썼고, 외부 개발자는 Bug Reporter라는 웹 인터페이스로 버그를 제출했어요. 이것도 완벽하진 않았지만, 최소한 버그 번호를 받고 상태를 추적할 수 있었죠. 2019년쯤 Feedback Assistant로 전환되면서 상황이 더 나빠졌다는 의견이 많아요.
Feedback Assistant의 대표적인 문제점들을 살펴보면, 먼저 투명성 부족이 있어요. 버그를 제출하면 피드백이 거의 없어요. "검토 중"이라는 상태가 몇 달, 심지어 몇 년씩 유지되는 경우도 흔해요. 수정 계획이 있는지, 우선순위가 어떤지 전혀 알 수 없어요.
다음으로 중복 처리의 불투명함이 있어요. "이 이슈는 기존 리포트와 중복입니다"라고 닫히는 경우가 있는데, 어떤 리포트와 중복인지, 그 리포트의 상태가 뭔지 알 수 없어요. 기존 리포트도 닫혀있을 수 있는데 말이에요.
그리고 이번에 지적된 자동 닫힘 문제도 있어요. "최신 버전에서 확인해달라"는 요청에 응답 안 하면 자동으로 닫아버리는 방식은, 버그 해결 건수를 인위적으로 부풀리는 효과가 있어요. 의도적인지는 모르겠지만, 결과적으로 그렇게 되는 거죠.
이런 환경에서 개발자들이 겪는 가장 큰 좌절감은 "내가 시간 들여서 버그를 재현하고, 샘플 프로젝트까지 만들어서 제출했는데, 아무 일도 일어나지 않는다"는 거예요. 이게 반복되면 결국 버그를 제출하지 않게 되고, Apple 생태계 전체의 소프트웨어 품질에 악영향을 미치게 돼요.
다른 플랫폼은 어떻게 하나요?
비교해보면 차이가 확연해요. Google의 Chromium 프로젝트는 공개 이슈 트래커를 운영하고, 누구나 버그의 상태 변화를 실시간으로 추적할 수 있어요. 댓글로 논의도 이루어지고, 어떤 커밋에서 수정됐는지까지 연결돼요.
Microsoft도 .NET, TypeScript 같은 오픈소스 프로젝트에서는 GitHub Issues를 활용해서 투명하게 소통하고 있어요. 물론 Windows나 Office 같은 클로즈드 제품은 다르지만, 최소한 개발자 도구 쪽은 상당히 열린 편이에요.
Mozilla의 Bugzilla는 오래됐지만 여전히 훌륭한 버그 추적 시스템이에요. 버그 하나하나의 히스토리가 다 남아있고, 20년 전 버그의 논의 과정까지 볼 수 있어요.
Apple은 개발자 생태계에 크게 의존하는 플랫폼이면서도, 정작 개발자와의 소통 채널은 가장 폐쇄적인 편이에요. WWDC에서 새로운 API를 화려하게 발표하는 것과, 기존 버그를 묵묵히 수정하는 것은 다른 차원의 문제인데, Apple은 전자에만 관심이 있다는 비판이 꾸준히 나오고 있어요.
한국 iOS/macOS 개발자에게 주는 시사점
한국에서 iOS 앱을 개발하는 분들이라면 이 상황에 깊이 공감할 거예요. Feedback Assistant에 버그를 제출해본 경험이 있다면, 그 답답함을 잘 아실 거예요.
실무적인 조언을 드리자면, 첫째로 Feedback Assistant의 이메일 알림을 놓치지 마세요. Apple이 "확인해달라"는 요청을 보냈을 때 기한 내에 응답하지 않으면 리포트가 닫힐 수 있어요. 이메일 필터를 설정해서 Apple Developer 관련 메일이 묻히지 않게 하는 게 좋아요.
둘째로 버그 리포트 제출 시 최대한 구체적으로 작성하세요. 재현 단계, 스크린샷, 샘플 프로젝트를 포함하면 그나마 관심을 받을 확률이 올라가요. sysdiagnose 로그를 첨부하라는 안내가 있으면 꼭 따르세요.
셋째로 중요한 버그는 다른 채널도 활용하세요. Apple Developer Forums, Twitter(X)에서 Apple 엔지니어를 태그하거나, WWDC Lab 세션에서 직접 문의하는 방법도 있어요. Feedback Assistant만으로는 해결이 안 되는 경우가 많거든요.
정리하자면
Apple의 버그 리포트 처리 방식은 개발자 생태계에 대한 Apple의 태도를 보여주는 단면이에요. 화려한 새 기능만큼이나 기존 문제의 투명한 관리도 중요한데, 현재 시스템은 그 부분이 크게 부족해요.
여러분은 Apple에 버그를 제출해본 경험이 있으신가요? 피드백을 제대로 받아본 적이 있는지, 아니면 블랙홀에 빠진 것 같은 경험이었는지 궁금하네요.
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공