문제가 발생하면 소프트웨어와 상호 작용하는 사용자의 여정에서 중요한 부분입니다. 그것은 종종 그들의 시간이 낭비되고 있는지 아닌지에 대한 그들의 인식에 깊은 영향을 미치는 변곡점입니다. 모든 실패를 예상할 수 있는 것은 아닙니다. 시스템에서 인터페이스에 이르기까지 애플리케이션을 설계하는 방법은 이러한 사실을 반영해야 합니다. 우리는 예상 여부에 관계없이 발생하는 문제를 처리할 때 사용자에게 가능한 최고의 경험을 제공하기 위해 최선을 다할 책임이 있습니다. 오류 처리는 빠르게 복잡해지는 것들 중 하나이며 복원력 있는 애플리케이션을 구축하려면 체계적인 접근 방식이 중요합니다. 실패 모드에 대한 작업을 미루면서 Happy Path 의 우선 순위를 정하고 싶지만 시간과 예산이 제한되어 있으면 오류를 부정확하게 처리하고 사용자를 소외시키며 고객 지원 및 엔지니어를 좌절시키는 응용 프로그램으로 끝날 위험이 있습니다. 오류 처리의 우선 순위를 적절하게 지정하려면 여러 분야에 걸쳐 프로젝트 팀 구성원의 동의가 필요합니다. 디자인 및 UX 전문가는 일이 계획대로 진행되지 않는 경우에도 사용자에게 최상의 경험을 제공하는 전체적인 오류 처리 접근 방식을 지원하기 위해 애플리케이션의 오류 모드를 설명해야 합니다. 다음은 오류를 정상적으로 처리하도록 애플리케이션을 설계할 때 염두에 두려고 하는 몇 가지 사항입니다. 모든 오류에는 2개의 측면이 있습니다. 애플리케이션의 UI와 상호작용하는 사용자 경험 고장을 관찰하고 조사하고 이해하려는 엔지니어의 경험 우리 모두는 "죄송합니다, 고장났습니다!" 페이지, 어쩌면 하나 또는 두 개를 만들 수도 있습니다. 완전히 예상치 못한 일이 발생하지 않는 한(예: HTTP 500) 이러한 종류의 결과는 정확하지 않고 실망스럽습니다. 우리가 사용자와 사용자의 시간 및 제품 사용에 대한 선택을 존중한다고 가정할 때 사용자에게 빚진 "이유"와 "다음 단계"를 전달하는 데 실패합니다. 반면에 엔지니어는 문제를 해결하기 위해 문제가 발생한 원인과 문제를 재현하는 방법을 이해하기 위해 충분한 정보가 필요합니다. 관찰 가능성이 낮으면 적용 범위의 격차가 발생하여 애플리케이션의 오류 모드를 이해하는 능력이 손상됩니다. 불충분한 메타데이터 또는 재현성은 문제를 완화하기 위해 취해야 할 적절한 단계를 결정하는 능력을 약화시킵니다. 모든 오류를 예상할 수 있는 것은 아닙니다. 오류는 두 가지 유형 중 하나로 나타납니다. 인증/권한 부여 오류, 유효성 검사 오류와 같은 예상 오류 (복구 가능한) 렌더링 오류 또는 서비스 가용성 오류와 같은 예기치 않은 오류 (복구할 수 없음) 복구 가능한 오류 의 경우 사용자에게 무엇이 잘못되었는지 알려주고 진행 방법에 대한 옵션을 제공해야 합니다. 사용자가 수행하려는 작업이 실패한 이유와 추가 실패를 피하기 위해 취해야 하는 단계를 이해하도록 돕습니다. 사용자가 실패 상태에서 복구하기 위해 취할 수 있는 상황별 작업이 있는 경우 이상적으로는 사용자에게 제공해야 합니다(예: 구성 요소가 데이터 로드에 실패한 경우 "다시 시도" 버튼을 제공하거나 사용자에게 지시 응용 프로그램을 다시 로드하려고 함) 그렇지 않은 경우 문제를 해결하거나(예: 자동으로 재시도) 손상된 상태의 구성 요소를 숨기기 위한 대체 전략이 있어야 합니다. 예: 양식 저장 시 유효성 검사 오류 또는 데이터 로드에 실패한 캘린더 또는 지도 위젯 복구할 수 없는 오류 의 경우 사과하고 문제가 발생했음을 설명해야 하며 이상적으로는 사용자에게 오류를 인식하고 문제를 해결하기 위해 적절한 조치를 취하고 있다는 확신을 제공해야 합니다. 예상치 못한 문제가 있음을 공개하고 사용자에게 진행 방법에 대한 몇 가지 옵션을 제공하는 것은 우리의 책임입니다(예: 기다렸다가 나중에 다시 시도, 버그 보고서 제출 또는 지원팀에 직접 문의). 특성으로 인해 알려진 작동 상태로 돌아갈 수 있는 명확한 경로가 없는 경우가 많습니다. 적절한 경우 사용자에게 시스템 상태 및 분류 상태( https://status.io/ 또는 자체 호스팅 버전 여부)에 대한 가시성을 제공하고 우리가 어떻게 적응하고 있는지 설명하는 사후 분석을 제공해야 합니다. 시간이 지남에 따라 더 탄력적이 되도록 소프트웨어를 발전시킵니다. 예: 중요한 서비스와 통신할 수 없기 때문에 서버는 500 내부 서버 오류를 반환합니다. 대부분의 응용 프로그램은 알려진 공통 오류 모드와 유사한 세트를 공유합니다. 모든 소프트웨어가 이러한 모든 것을 설명할 필요는 없으며 일부 소프트웨어에는 고려해야 할 추가 오류 모드가 있습니다. 그러나 이러한 문제를 해결하기 위해 잘 정립된 모범 사례를 활용할 수 있을 만큼 충분히 일반적입니다. 입증 ???? 사용자가 조치를 취하거나 페이지에 액세스하려고 시도하고 응답하기 위해 사용자를 식별해야 하지만 로그인되지 않았습니다. 이러한 종류의 실패는 충분히 이해되고 있으며 대부분의 응용 프로그램은 HTTP 401 Unauthenticated 응답을 반환하고 로그인 페이지로 리디렉션하는 표준 접근 방식을 취합니다. 이상적으로는 로그인 후 사용자가 가려고 했던 장소로 돌아가거나 작업이 다시 시도됩니다. 권한 부여 ???? 사용자가 자신에게 없는 권한이 필요한 작업을 수행하거나 페이지를 방문하려고 합니다. 많은 시스템에는 제한된 권한을 가진 여러 사용자 유형이 있습니다. 적절하게 설계되면 이러한 종류의 실패가 자주 발생하지 않으며 표준 접근 방식으로 충분합니다. 우리의 애플리케이션은 인증된 사용자가 상호 작용할 권한이 없다는 것을 알고 있는 UI가 표시되는 것을 방지하기에 충분한 컨텍스트를 가지고 있습니다. 표준 접근 방식에는 HTTP 403 Forbidden 응답 반환 및/또는 "액세스 거부" 페이지 표시가 포함됩니다. 일부 응용 프로그램의 경우 사용자가 관리자에게 추가 권한을 요청하도록 돕는 것이 더 나은 솔루션일 수 있습니다. 애플리케이션이 403 응답을 자주 발생시키는 사용자에게 UI를 노출하는 경우 이러한 시나리오가 처음부터 발생하지 않도록 보다 세분화된 역할 또는 권한 검사를 사용하는 것이 좋습니다. 확인 ???? 불완전하거나 잘못된 사용자 제공 데이터(종종 양식과 상호 작용할 때). 신뢰할 수 있고 탄력적인 애플리케이션을 구축하려면 데이터 무결성을 유지 관리해야 하므로 레코드를 생성하거나 업데이트하기 전에 사용자 입력을 검증해야 합니다. 유효성 검사 오류는 매우 일반적이며 이를 적절하게 처리하는 것은 잘 알려져 있습니다. 이상적으로는 사용자의 요청이 성공하기 위해 수행해야 하는 변경 사항에 대한 직접적이고 실행 가능한 지침을 제공할 수 있습니다. WebAIM은 접근성 고려 사항에 대한 몇 가지 조언을 제공합니다. WCAG에는 다음과 같은 몇 가지 유용한 제안이 포함된 양식의 사용자 입력 처리에 대한 몇 가지 지침이 있습니다 . 다양한 입력 형식을 허용하십시오 . 전화번호, 날짜 또는 시간과 같은 필드에 대해 여러 공통 형식을 허용합니다. number지나치게 제한적인 양식 필드 유형(예: 우편번호 입력)을 사용하지 마십시오 . 되돌릴 수 없는 작업에 대해 사용자 확인이 필요합니다. 예를 들어, 사용자가 무언가를 삭제하도록 요청하면 영구적인 부작용을 커밋하기 전에 해당 작업을 확인하도록 요구합니다. 실행 취소 기능을 제공합니다. 레코드를 즉시 삭제하는 대신 레코드가 삭제된 것으로 표시되지만 필요한 경우 나중에 복구할 수 있는 일시 삭제를 고려하십시오. 표현 ???? 요청에 대한 응답을 준비하는 동안 애플리케이션이 응답을 렌더링하지 못합니다. 이러한 (종종 치명적인) 버그는 데이터 형태에 대한 잘못된 가정, 데이터 로드 실패 또는 렌더링 코드의 오타로 인해 발생할 수 있습니다. 이러한 종류의 문제가 발생할 위험을 완화하는 데 도움이 될 수 있는 여러 가지 결정이 있습니다. 강력한 형식의 프로그래밍 언어 는 데이터에 액세스할 때 어떤 계약도 위반하지 않았지만 정적 분석이 허용하는 만큼만 똑똑하다는 컴파일 타임 검증을 제공합니다. 외부 시스템과 인터페이스할 때 정의한 유형이 올바르지 않거나 향후 변경으로 인해 무효화될 위험이 여전히 있습니다. 방어적 프로그래밍 기술 은 복잡성을 대가로 예상치 못한 변경을 처리하는 데 있어 렌더링 코드에 약간의 유연성을 제공할 수 있습니다. 조건부 속성 액세스, 존재 여부 또는 빈 확인 및 대체 또는 기본값은 오류를 방지하는 데 도움이 될 수 있지만 데이터가 누락된 경우 수행할 작업은 덜 명확할 수 있습니다. 사용자에게 오류를 표시하는 것보다 누락되거나 자리 표시자 데이터가 있는 UI를 표시하는 것이 더 낫습니까? 이 질문에 대한 답변은 귀하의 애플리케이션 및 도메인에 따라 다를 수 있습니다. 프레임워크 지원 기능 은 렌더링과 관련된 예상치 못한 문제를 설명할 수 있는 강력한 대체 방법을 제공할 수 있습니다. 이에 대한 좋은 예는 React, Vue 또는 SolidJS의 오류 경계 입니다. 이러한 종류의 기능을 사용하면 예외와 같은 방식으로 구성 요소 계층 구조의 오류를 처리하고 프레임워크에서 렌더링 오류가 발생하는 경우 표시할 대체 UI를 선언할 수 있습니다. 서비스 가용성 ???? 당사 소프트웨어가 의존하는 서비스를 일시적으로 사용할 수 없습니다. 특히 웹에 있는 많은 종류의 소프트웨어는 인증, 데이터 지속성, 백그라운드 처리, 이메일 전송, 푸시 알림 및 기타 여러 기능과 같은 다른 서비스에 의존합니다. 인증과 같이 이러한 서비스가 중요한 경우 서비스 중단은 애플리케이션을 일시적으로 사용할 수 없음을 의미할 수 있습니다. 이메일 전송과 같은 다른 작업의 경우 서비스 중단이 반드시 애플리케이션을 사용할 수 없다는 의미는 아닙니다. 이와 같은 시나리오에서는 나중에 다시 시도하도록 전자 메일을 대기열에 추가하고 지연을 사용자에게 알릴 수 있습니다. 관찰 가능성은 문제를 분류하고 수정하는 데 중요합니다. 문제를 모니터링하고 캡처하는 도구가 없으면 문제를 조사하고 수정하는 것이 어렵거나 불가능합니다. 특히 분산 시스템(예: 마이크로서비스 지향 아키텍처)에서 그렇습니다. 오류 모니터링: 문제 해결은 문제가 언제 발생하는지 아는 것으로 시작되며 Sentry 와 같은 서비스 는 탄력적인 시스템 구축의 핵심 구성 요소입니다. 엔지니어가 오류가 발생한 컨텍스트를 더 잘 이해할 수 있도록 오류 모니터링 서비스에 오류를 보낼 때 오류와 함께 충분한 메타데이터를 포함하는 것이 중요합니다. 오류 발생 시 애플리케이션 상태를 캡처하는 것은 분산 시스템 또는 마이크로서비스 지향 아키텍처에서 어려울 수 있으므로 세션 정보를 로깅하고 연결하는 보다 정교한 방법이 필요합니다(트랜잭션 ID로 태그가 지정된 이벤트는 다른 시스템의 상태를 연결하는 데 도움이 될 수 있음) 사용자 세션 재생: LogRocket 또는 Datadog 과 같은 서비스는 사용자 세션을 재생하고 문제가 발생했을 때 응용 프로그램의 동작을 직접 경험할 수 있는 기능을 제공합니다. 공감을 형성하는 데 도움이 될 뿐만 아니라 문제가 발생한 이유를 이해하기 위해 인과 관계를 분석하는 데 중요한 도구가 될 수 있습니다. 회귀 방지: 버그가 발견되고 수정되면 가능한 경우 해당 특정 시나리오를 다루는 테스트를 추가하는 것이 중요합니다. 해당 테스트를 보고된 버그와 연결하면(예: 티켓 번호에 연결하여) 테스트의 목적과 중요성을 미래의 엔지니어에게 전달하는 데 도움이 됩니다. 마지막 생각들 오류를 정상적으로 처리하는 애플리케이션을 제공하는 능력에 영향을 미치는 많은 고려 사항이 있습니다. 이러한 실패 시나리오를 설명할 책임은 프로젝트 팀과 제품 소유자에게 분산되어 있습니다. 엔지니어는 이러한 시나리오 중 일부가 발생할 위험 수준에 영향을 미치는 기술적 결정을 탐색하고 시스템 수준에서 디버깅을 용이하게 하는 기술을 사용할 수 있는 좋은 위치에 있습니다. 디자인, UX 및 제품은 사용자가 투명하고 정중하게 의사 소통하면서 쉽게 수정하거나 에스컬레이션할 수 있는 장애 시나리오에서 도메인별 워크플로를 제공하여 사용자 경험을 설명할 수 있는 좋은 위치에 있습니다. 궁극적으로, 애플리케이션이 진정으로 훌륭한 사용자 경험을 제공하려면 이러한 모든 것이 결합되어야 하며, 이는 종종 사용자 여정의 중요한 변곡점인 상황이 무너지는 경우에도 마찬가지입니다. 이러한 상황을 처리하는 방법은 제대로 수행되지 않으면 사용자를 소외시키고 좌절시킬 수 있으며, 잘 수행되면 충성도와 존경심을 구축할 수 있습니다.