| title | author | translator | category | excerpt | hiddenlang | status | ||
|---|---|---|---|---|---|---|---|---|
Bug Reporting |
Mattt |
김필권 |
Miscellanea |
Radar에 신고해"라는 말을 듣고 그게 어떤 의미인지 궁금했던 적이 있다면 이 주의 게시글에서 해결해드리겠습니다.
|
|
"Radar에 신고해." 애플 플랫폼에서 개발하는 분에게는 친근한 문장일 것입니다.
아마도 종잡을 수 없는 UIKit 컴포넌트에 대해 불만을 토로할 때 또는 끔찍한 오래된 문서를 공유했을 때의 반응일 수도 있습니다. 아니면 하루에 12번 넘게 Xcode를 재시작할 때 머릿속에서 나올 말일 것입니다.
"Radar에 신고해"라는 말을 듣고 그게 어떤 의미인지 궁금했던 적이 있다면 이 주의 게시글에서 해결해드리겠습니다.
Radar는 애플의 버그 추적 소프트웨어입니다. 엔지니어링 관련 분야에 종사하고 계시다면 매일 상호작용하고 있을 것입니다. Radar는 소프트웨어, 하드웨어를 포함한 모든 곳(문서, 지역화, 웹 속성, 심지어 Siri에게서 받는 응답까지)의 기능이나 버그를 추적합니다.
애플 엔지니어가 "Radar"에 대해 들으면 가장 먼저 생각나는 것은 보라색 안테나 아이콘을 가진 Radar.app 앱입니다. Radar에서 가장 중요한 기능은 앱이나 데이터베이스가 아닌 문제 보고부터 마지막 검사까지 해주는 업무 흐름을 제공해주는 것입니다.
Radar가 생성되면 유니크하고 영구적인 ID를 부여받습니다. Radar ID는 자동으로 증가하는(auto-incrementing) 정수라서 숫자만 보고도 어떤 버그인지 알 수도 있습니다. (지금 쓰고 있는 순간의 새로운 Radar는 4로 시작하는 8자리의 ID네요.)
Radar.app은
rdar://커스텀 URL 스킴을 사용합니다. 애플 엔지니어가 ID가 포함된 rdar://xxxxxxxx 링크를 누르면 바로 Radar가 열릴 것입니다. 아닐 경우엔 이 링크를 눌러도 "rdar://xxxxxxxx URL을 열 수 있는 어플리케이션이 없습니다." 정도의 메세지만 받게 될 것입니다.
불행하게도 모두가 애플에서 일하는 것은 아니기 때문에 당장 Radar에 접근할 수는 없습니다. 대신에 우리가 보고 있는 인터페이스에서 간접적으로 버그를 제보할 수 있습니다.
Apple Bug Reporter는 외부 개발자들에게 열려있는 Radar의 기본 인터페이스입니다.
Bug Reporter는 메일앱이나 iCloud.com의 다른 앱처럼 최근에 모던 웹 앱으로 업데이트 되었습니다. 이전 것을 기억하는 분이 계시다면 그 업데이트는 정말 큰 일이었다고 동의하실 것입니다.
{% asset apple-bug-reporter.png %}
제보할 문제와 연관된 제품을 고르고 문제에 대한 제목을 입력하시면 됩니다. 이 문제가 버그라면 종류(퍼포먼스, 크래시/데이터 손실, UI/사용성 등)를 구체적으로 입력해주시고 얼마나 자주 그런 버그가 발생하는지도 적어주시면 좋습니다. 마지막으로 그 문제에 대한 설명을 요약, 재현하는 방법, 예상했던 결과와 실제 일어난 결과 그리고 설정에 대한 정보와 시스템 버전에 대한 정보를 모두 포함한 설명을 입력해주세요.
입력한 정보들은 Radar에 쌓이게 되고 그 다음엔 엔지니어들에 의해 분류, 할당, 우선순위 매기기, 그리고 계획이 정해집니다.
여러분이 애플의 베타 소프트웨어 프로그램에 참가중인데 베타로 배포된 OS에 문제가 생겼다면 Feedback Assistant를 사용하세요. (macOS와 iOS의 스팟라이트에서 찾을 수 있습니다.)
{% asset feedback-assistant.png %}
Feedback Assistant는 여러분이 사용중인 플랫폼에 의견을 제공하는 것에 최적화된 경험을 제공합니다. 이 도구는 여러분이 마주한 문제를 더 정확하게 해결할 수 있도록 자동으로 여러분의 시스템에 대한 정보를 자동으로 캡쳐합니다.
Bug Reporter는 작업과 직접적으로 관련된 문제에 대한 선택지인 반면에, Feedback Assistant는 매일 매일 마주하는 버그에 대한 더 간편한 선택지입니다.
개발자가 문제를 마주했을 때 그들은 단순히 불평하는 것보다 문제를 해결하는 것에 동기 부여를 받습니다. 이것이 개발자가 처음에 버그 리포트를 제출하는 이유입니다.
또한 버그 리포팅 과정 자체의 문제를 해결하는 도구를 만드는 일에서도 비슷한 동기 부여를 받을 수 있습니다.
애플 개발자 커뮤니티에서 정한 필수적인 버그 리포팅 도구를 정리해봤습니다.
외부 개발자의 입장에서 Radar의 근본적인 문제는 투명성의 부족입니다. 그 증거 중 하나는 다른 사람들이 무엇을 보고했는지를 알 수 있는 방법이 없다는 것입니다. 자세한 요약을 작성하고 재현 가능한 테스트 케이스까지 열심히 적었지만 그 버그가 인정사정없이 중복이라고 닫히는 경우도 자주있습니다.
Tim Burks의 OpenRadar는 애플에 리포트된 버그의 공공 데이터베이스 역할을 합니다. 지난 몇 년간 OpenRadar는 버그 리포트를 조직화하는 실질적인 방법이 되었습니다.
{% asset open-radar.png %}
애플의 Radar에 신고할 때 OpenRadar에도 신고해주시길 바랍니다(공개해도 되는 내용이 아니라면 말이죠). 여러분의 공헌은 같은 문제를 가진 미래의 누군가를 도울 수 있을 것입니다.
최근 정비된 Bug Reporter 웹 앱이 사용하기 꽤 편해졌다고 해도 네이티브 앱을 대체할 수는 없습니다.
Keith Smiley의 Brisk는 애플의 Bug Reporter를 이용해서 Radar에 신고할 수 있는 macOS 앱입니다. 이 앱은 이중 인증, radar 임시 저장, rdar:// URL을 열 수 있게 자동으로 바꿔치기 하는 등 필요한 모든 기능을 제공합니다. 하지만 그 중에서도 가장 멋진 기능은 Open Radar에도 동시에 올릴 수 있게 해주는 cross-post 입니다.
{% asset brisk-app.png %}
시작하기 위해선 최신 버전을 GitHub에서 받거나 Homebrew에서 다음 커맨드를 통해 설치하면 됩니다.
$ brew cask install Brisk
이제 버그 리포트를 작성하는 법은 아셨을테니 좋은 버그 리포트를 작성하는 방법에 대해 얘기해봅시다.
하나의 버그 리포트에 여러개의 버그를 적는 것은 전혀 도움이 안됩니다. 추가로 우려 사항을 제기하는 것은 할당된 엔지니어의 이해를 어렵고 힘들게 해서 실용적이지 않은 결과를 초래합니다.
대신에 여러 개의 Radar를 신고하고 관련된 문제를 요약에 ID로 알려주면 됩니다.
문제가 더 빨리 잘 해결되기 위한 가장 좋은 방법은 딱 맞는 엔지니어에게 할당되는 것입니다. 그러기 위해서는 중요한 정보를 제목에 보여주는 것이 좋습니다.
-
API에 대한 문제라면 심볼을 모두 제목에 넣는 것이 좋습니다. (예:
URLSession.dataTaskWithRequest(_:)) -
문서에 관련된 문제라면 네비게이션의 모든 목록을 제목에 포함해주세요. (예: "Foundation > URL Loading System > URLSession > dataTaskWithRequest:")
-
특정 앱에 대한 문제일 경우엔 앱 이름, 버전 그리고 빌드 번호를 참조해주세요. 이 정보는 "About" 정보 창에서 찾을 수 있습니다. (예: "Xcode 10.0 beta (10L176w)")
아마도 여러분이 버그 리포트를 작성할 때는 기분이 그렇게 좋진 않을 것입니다.
예상한 대로 작동하지 않는 것은 수용 할 수 없어. 난 이 문제를 디버깅하기 위해 시간을 버렸어. 애플은 소프트웨어 퀄리티에 대해 신경쓰지 않아.
짜증나죠. 모두 이해합니다.
하지만 그 중에 어떤 것도 문제가 더 빨리 해결되는데에 도움이 되지 않습니다. 무엇보다 적대적인 태도는 엔지니어가 여러분의 문제를 찾을 확률이 더 낮아질 뿐입니다.
버그 리포트를 받는 것도 우리와 같은 사람이라는 사실을 기억하세요. 공감 능력을 익히세요.
Peter Steinberger의 좋은 버그 리포트를 작성하는 방법을 기록한 훌륭한 조언을 그의 블로그에서 확인할 수 있습니다.
외부 개발자들은 종종 Radar에 신고하는 것이 블랙 홀에 메시지를 보내는 것같은 느낌을 받은 경험이 있을 것입니다. 매 시간 수 천 개의 새로운 Radar가 생기기 때문에 담당자가 여러분의 버그 리포트를 자세히 읽어보는 것은 거의 불가능에 가깝기 때문에 어쩔 수 없습니다.
다행스럽게도 여러분의 버그 리포트가 잘 받아들여지게 도와주는 방법이 있습니다.
애플의 버그 분류 작업 흐름에선 각 문제는 하나의 Radar로 추적됩니다. 만약 여러 개의 Radar가 같은 문제를 리포트하고 있다면 가장 오래되거나 제일 구체적인 것만 남고 나머지는 모두 중복으로 닫힐 것입니다. 이 해결책은 외부 개발자에게 실망스러울 수 있습니다. 특히 Radar가 보이지 않는 사람들에겐 마지막 단어가 그들이 들었던 말일 것이기 때문입니다.
그래도 그 말은 여러분의 버그가 중복으로 닫히는 것은 항상 나쁜 것만은 아니라는 점입니다. 여러분은 의도적으로 기존의 Radar 복사본을 신고하면서 "저도 이런 문제를 가지고 있어요" 나 "이것 먼저 수정해주세요" 라고 할 수 있습니다. 이것이 애플 엔지니어들을 귀찮게 하는 일이라 해도 우리는 소프트웨어 품질이라는 이름 하에 버그 리포트를 할 용기를 가져야 합니다.
Semper fidelis, buggos.
애플의 몇몇 팀은 트위터의 피드백에 반응을 잘 해주는 편입니다. 루프 안에 있을 때는 루프에 있는 것을 유지하기 힘들기 때문에 엔지니어와 윗사람 모두 vox popili (사람들의 목소리) 에 채널을 맞춰둡니다.
애플의 차가운 소셜 미디어 정책으로 인해 여러분은 모든 것에 대한 답변을 듣기는 힘들 수 있습니다. 하지만 여러분의 트윗은 쿠퍼티노에 있는 누군가의 검색 결과에는 나올 것입니다.
애플 엔지니어들은 여러분과 같은 개발자입니다. 그리고 대부분은 우리가 작성하는 것에 관심을 가지고 있습니다. 게다가 블로그에 글을 쓰는 것은 동료 개발자들에게도 도움되는 일입니다
애플에서 일했던 제 개인적인 경험을 기반으로 말하자면 Radar는 제가 사용해본 가장 좋은 버그 추적 시스템입니다. 그래서 외부 개발자로써 놓치고 있는 것을 잘 알고 있는 상태로 바깥에서 안쪽을 보는 것은 좌절감을 주기도 합니다.
오픈 소스 소프트웨어는 버그를 마주치는 사람이 고칠 수 있도록 권한을 제공하는 것과는 대조적으로 애플 소프트웨어의 대부분은 소유권이 있습니다. 우리가 할 수 있는 일이 그렇게 많지 않다는 뜻이죠. 우리가 할 수 있는 단 하나의 선택지는 버그를 제보하고 이게 최선이길 바라는 것 뿐입니다.
다행히도 상황은 꽤 나아졌습니다. 새로운 Bug Reporter 사이트는 훌륭하고 과정 자체의 투명성도 점점 나아지고 있습니다.
@apple 버그 제보기의 변화를 응원합니다! 이제 단순히 "닫힘" 알림을 받는 것이 아닌 "검사 대기중"처럼 변경된 알림을 받았다는 얘기를 많이 들었습니다. Dave DeLong (@davedelong) Twitter
이 변화가 지속되기 위해서는 우리가 꾸준한 소통을 해야합니다. 다음부턴 잘못된 것이 있을 때 이렇게 말해주세요, "Radar에 신고해!"