작성자가 엔터프라이즈 소프트웨어를 경험해보지 않았을 것 같음
개발자가 버그 리포트를 받으면 “재현이 안 되는데 최신 버전에서 확인해보셨나요?”라며 아무것도 안 하고 시간을 끄는 전형적인 수법임
확인이 안 되면 “사용자 오류”나 “재현 불가”로 닫아버림
유일한 대응책은 “네, 확인했습니다”라고 말하면서 실제로는 확인하지 않는 것뿐임
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 엔지니어가 실제로 수정 시도를 했다고 보긴 어려움
회사에서 동료들과 함께 백로그 정리 회의를 하며
오래된 일회성 버그들을 정리했음
이런 프로세스는 매우 일반적임
Hacker News 의견들
작성자가 엔터프라이즈 소프트웨어를 경험해보지 않았을 것 같음
개발자가 버그 리포트를 받으면 “재현이 안 되는데 최신 버전에서 확인해보셨나요?”라며 아무것도 안 하고 시간을 끄는 전형적인 수법임
확인이 안 되면 “사용자 오류”나 “재현 불가”로 닫아버림
유일한 대응책은 “네, 확인했습니다”라고 말하면서 실제로는 확인하지 않는 것뿐임
로그에 백신이 보이면 “그쪽에 문의하세요”라며 바로 닫아버림
한 명의 사용자가 제기한 버그보다 더 중요한 비즈니스 우선순위가 많기 때문임
그래도 사용자 입장에서는 안타까운 일임
대부분의 개발자는 자기 제품을 테스트할 줄 모르거나 귀찮아함
엔터프라이즈 기술 지원 시절엔 하루에 최소 두 건씩 새 케이스를 받아야 했고, 20건 넘게 동시에 관리했음
아무 진전 없는 케이스를 “비활성화 종료”로 닫을 때 느끼는 해방감이 컸음
나중엔 닫기 전에 세 번 연락하라는 규정이 생겨 악몽이었음
결국 대기업 관료주의가 모든 걸 망침
Apple이 버그가 자연스럽게 사라지길 기도하는 듯한 태도를 보임
나도 이제는 버그 리포트를 안 올림
무시당하는 건 괜찮지만, 문제는 그들이 나를 무급 QA 인력으로 취급할 때임
버그 존재를 증명하기 위해 엄청난 노력을 요구함
“이건 네 소프트웨어니까 네가 디버깅해라”는 생각임
오픈소스 프로젝트들도 비슷하게 stale 이슈 자동 종료를 함
일정 기간 지나면 자동으로 해결된 것으로 간주하는 건 말이 안 됨
오픈소스의 장점은 직접 고치거나 PR 제출, 혹은 포크해서 해결할 수 있다는 점임
오래된 티켓을 필터링하는 게 더 합리적임
사용자 입장에서 짜증나지만, 모든 버그가 쉽게 재현 가능한 건 아님
때로는 관련 코드 변경 후 사용자에게 다시 테스트 요청하는 게 효율적임
그래도 오래된 비실행 가능한 버그를 닫을 때는 마음이 불편함
그건 Apple 내부 네트워크에서만 재현이 안 된다는 뜻이었음
닫는 건 문제를 가리는 행위일 뿐이고, 열어두는 데 비용이 들지 않음
베타를 설치해야 하는 건 사용자에게 훨씬 비효율적임
나는 Xcode 샘플 프로젝트와 재현 단계까지 제공했음
Apple은 아무것도 안 했다고 확신함
아마 WWDC 전 macOS 27 준비를 위해 버그 정리 쇼를 하는 듯함
Facebook과 Google에서 일할 때 버그 관리 꼼수를 많이 봤음
SLA 도입 후 버그 우선순위를 인위적으로 낮추거나, “아직 문제인가요?”라며 사용자에게 떠넘김
시간이 지나면 “버전이 폐기됐다”며 닫아버림
심지어 다른 버그와 억지로 병합해서 책임을 회피하기도 함
결국 이런 건 조직의 성과 지표(SLA) 때문임
그래서 이제는 버그 리포트를 거의 안 함
하지만 경영진이 “지금은 AI 프로젝트에 집중하라”고 지시함
그러면서 “버그가 너무 많다”고 꾸짖음
닫는 대신 그냥 무시하는 게 솔직하다고 생각함
리더십은 이런 식으로 강제 트리아지를 유도했음
자동 알림을 막는 건 문제임
예를 들어 사이트가 완전히 죽었어도 지금은 비성수기라면 P0가 아닐 수 있기 때문임
하지만 현실적으로는 데이터 품질이 낮아 보고용으로 쓸 수 없음
그래서 단일 우선순위 값이 더 실용적임
stalebot이 이런 무시된 이슈를 대신 닫아주는 셈임
고객용 severity와 내부용 priority를 따로 관리했음
Salesforce “Lightning Experience”는 이름과 달리 매우 느림
내부 도구가 훨씬 빠르고 효율적이었음
ElevenLabs에서도 같은 일이 있었음
버그 리포트를 올리면 AI가 자동으로 답하고, 48시간 후 stale 처리됨
곧 LLM 에이전트가 이런 문제를 해결할 것 같음
자동으로 “아직 안 고쳐졌습니다”라고 댓글을 달고, 주기적으로 “이건 중요한 워크플로에 영향을 줍니다”라며 자동 bump할 수 있음
예전에 Microsoft에 버그를 제출했는데, 몇 달 후 “재현 불가” 연락을 받음
사실 그 사이 다른 수정으로 간접적으로 해결된 것이었음
내가 코끼리의 일부분만 본 맹인이었다는 걸 깨달음
전 Apple 직원임
Apple 내부 버그 트래커는 Radar라 불리고, 모든 이슈는 “Verify” 단계를 거쳐야 닫을 수 있음
겉보기엔 품질 보증 절차 같지만, 실제로는 수많은 Radar가 Verify 상태에서 영원히 멈춤
팀들은 “미검증 Radar 수”로 평가받기 때문에 일정 기간 후 강제로 닫아버림
“버그 0개”라는 허상은 왜곡된 성과지표를 낳음
Apple 엔지니어가 실제로 수정 시도를 했다고 보긴 어려움
회사에서 동료들과 함께 백로그 정리 회의를 하며
오래된 일회성 버그들을 정리했음
이런 프로세스는 매우 일반적임