버그는 개발 과정에서 피할 수 없는 부분입니다. 버그가 발생하는 것은 당황스럽지만, 직면한 문제를 식별, 재현하고 Apple 피드백 지원을 통해 버그 리포트를 제출함으로써 이러한 문제를 빠르게 해결하는 데 도움을 줄 수 있습니다.

Learn more about bug reporting

Learn more about our privacy policy when filing bugs with Feedback Assistant

Apple 플랫폼용으로 개발하는 동안 버그를 발견한다면 언제든 피드백을 보내주시기 바랍니다. 저희도 미처 모르고 있었던 문제는 수정할 수 없으니까요. 하지만 여러분이 제공하는 정보가 막다른 길로 이끄는 것이 아니라, 이슈를 분류하는 데 도움이 되도록 하려면 어떻게 해야 할까요? 명확하고 실행 가능하며, 무엇보다 수정 가능한 버그 리포트를 위한 유용한 팁을 확인해 보세요.

명확하고, 직접적이면서도, 상세하게 설명

새로운 버그 리포트를 로깅할 때는 먼저 이슈와 원인이 되는 요소를 모두 명시하는 제목으로 시작하여 최대한 자세히 설명합니다. ‘캘린더 이벤트 누락’과 같은 제목은 육하원칙 중에서 어떻게, 왜와 같은 중요한 정보가 빠져 있지만, ‘macOS 12.4에서 빠른 이벤트 생성 후 캘린더 이벤트 누락’이라는 제목은 저희가 조치하기 쉬운 설명을 제공합니다.

팁: 버그를 검토하는 담당자가 해당 이슈가 어떻게 앱 개발에 영향을 미치는지 이해할 수 있으면 도움이 되는 경우가 많습니다. 앱을 개발하는 동안 문제를 발견한 경우, 독립적인 샘플 프로젝트에서 문제를 재현할 수 있더라도 제목과 설명 필드에 앱의 이름과 버전을 포함하고 App Store 기록이나 TestFlight 빌드로 연결되는 링크를 추가해 주시기 바랍니다.

문제를 작성할 때는 각 단계를 자세하게 설명해 주세요. 신고를 읽는 사람이 해당 앱이나 시스템을 한 번도 본 적이 없다고 가정하고 작성하는 것이 도움이 되는 경우가 많습니다. 예를 들어 “캘린더에서 이벤트를 생성할 때 갑자기 사라집니다”라는 설명에는 이슈를 재현하는 데 필요한 여러 가지 상세 정보가 누락되어 있습니다. Quick Event(빠른 이벤트) 버튼, Siri 또는 드래그해서 새로운 이벤트를 추가하는 것 중 어떤 방법을 통해 캘린더 이벤트를 생성하나요? ‘갑자기’는 얼마의 시간을 의미하나요? 멀티태스킹 이후에 이벤트가 사라졌나요? 아니면 앱을 실행하는 중에 이벤트가 사라졌나요?

버그를 검토하는 사람이 작업을 잠시 멈추고 이런 종류의 질문을 고민할 때마다 문제가 빠르게 해결될 가능성이 줄어듭니다. 대신 버그를 어떻게 하면 자세히 설명할 수 있을지 생각해 보세요. 예를 들어 다음과 같이 작성할 수 있습니다.

1. Calendar(캘린더) 앱에서 Quick Event(빠른 이벤트) 버튼을 클릭합니다. 
2. 임의의 제목으로 이벤트를 만듭니다. 
3. Enter를 누릅니다.

실제 결과: 이벤트가 캘린더 오른쪽에 나타났다가 사라집니다.

원하는 결과: 캘린더 이벤트가 캘린더에 표시된 채로 유지되어야 합니다.

재현 단계와 원하는 결과를 작성한 후에는 문제에 영향을 미칠 만한 추가적인 요소를 고려합니다. iCloud에 로그인했나요? 접근성 설정을 켰나요? 운영 체제의 다른 곳에서 이슈를 재현할 수 있나요? 최초 리포트에서 자세한 정보를 제공할수록, 검토하는 담당자가 효과적으로 분류하고 적절한 팀이 수정할 수 있도록 배정이 가능합니다.

몇 가지 시각적 자료 추가

재현한 버그의 스크린샷이나 화면 레코딩을 제공하면 귀중한 실마리가 됩니다. 또한 설명 필드를 작성할 때 미처 생각하지 못했던 디테일이 포함될 수도 있습니다. UI에 이슈가 있는 경우에는 항상 시각적 자료를 포함해야 합니다.

충돌 로깅

안타깝게도 어떤 버그는 재현할 수 없거나 쉽게 따라하기 어려울 수 있습니다. 이렇게 까다로운 사례인 경우, sysdiagnose와 같은 로깅 정보를 제공하는 것이 나을 수도 있습니다. iPhone이나 iPad에서 버그를 신고할 경우, 피드백 지원 앱을 사용하여 자동으로 캡처할 수 있습니다. Apple의 웹 포털을 통해 제출할 경우, sysdiagnose를 수동으로 수집할 수 있도록 프로파일을 설치하셔도 됩니다.

이슈와 관련된 추가 로깅을 제공할 수도 있습니다. 예를 들어, 충돌을 경험했다면 앱의 충돌 로그를 포함하세요. 성능 저하 이슈를 신고하는 경우 iOS 또는 iPadOS의 Instruments Trace나 macOS의 Sample을 포함하세요.

샘플 프로젝트 만들기

앱을 개발하는 동안 이슈가 발생했나요? 문제를 작은 샘플 프로젝트나 컴파일이 되는 Swift Playgrounds 프로젝트로 분리하는 것이 좋습니다. 이렇게 하면 해당 버그로 범위를 좁힐 수 있을 뿐만 아니라 버그를 검토하는 담당자와 엔지니어가 문제를 가장 쉽게 분류할 수 있습니다. 전체 샘플 프로젝트를 생성할 수 없다면 샘플 코드도 도움이 됩니다. 이슈의 범위를 좁힐 수 있는 모든 추가 정보는 도움이 됩니다.

리포트 에스컬레이션

Apple Developer Program, Enterprise Program 또는 MFi Program의 유료 회원이 프로덕션 릴리스의 Apple 플랫폼 중 하나에서 기술 이슈를 경험한 경우, Technical Support Incident(기술 지원 인시던트)를 제출하는 것이 좋습니다. 이는 버그를 수정할 수 없거나, 특정 기술을 구현하는 데 문제가 있거나, 코드에 대해 일반적인 문의 사항이 있을 때 Apple 프레임워크, API 및 도구에 대해 코드 수준의 지원을 요청하는 것입니다.

Request technical support