Error messages는 여전히 developers를 위해 작성되고 users를 위한 것이 아니다. 왜?

배경 및 소개

최근 디지털 서비스 곳곳에서 "An unexpected error has occurred. Please try again." 같은 무의미한 에러 문구가 여전히 보이는데요. 사용자 입장에서는 무엇이 잘못됐는지, 내 탓인지 시스템 탓인지, 지금 무엇을 해야 하는지 전혀 알 수 없다는 문제가 제기됩니다. 원글은 에러 메시지가 종종 정보를 과소 제공하거나, 기술적으로는 정확하지만 사람에게는 쓸모없고, 심지어 사용자를 탓하면서도 구체적 다음 조치를 안내하지 않는다고 비판합니다. 좋은 에러는 무엇이 일어났는지, 책임의 귀속, 그리고 다음 단계까지 알려줘야 하는데 대부분 세 축 모두에 실패한다는 지적입니다. 커뮤니티에서는 운영 현실상 원인 파악이 즉시 불가능한 경우가 많다는 의견도 나왔는데요. 그럴수록 재시도 안내나 부분 실패 내역처럼 지금 당장 실행 가능한 정보를 주자는 제안이 이어졌습니다.

주요 내용

원글의 핵심은 에러 메시지의 삼박자를 분명히 하자는 것입니다. 첫째, 무엇이 실패했는지 사용자가 이해할 언어로 구체화할 것. 둘째, 사용자 과실인지 시스템 문제인지 귀속을 명확히 할 것. 셋째, 사용자가 지금 바로 취할 수 있는 다음 행동을 제시할 것인데요. "unexpected error" 같은 포괄적 표현은 이 세 가지를 모두 놓치며, UX 관점에서 사용자의 정신적 모델을 붕괴시키고 문제 해결 비용을 사용자에게 전가한다는 점에서 주목할 만합니다.

상위 댓글은 현실적인 제약을 짚습니다. 많은 경우 추가 조사 없이는 원인이 불명확해 사용자에게 정확한 처방을 제시하기 어렵다는 것인데요. 이때 취할 수 있는 실용적 해법으로 두 가지가 제안됩니다. 첫째, 재시도를 요청하되 빈말로 끝내지 않고 재시도 조건을 최소화해 안내하는 것입니다(예: 네트워크 확인 후 즉시 재시도, 일정 시간 뒤 자동 재시도 등). 둘째, 액션의 일부만 실패했다면 그 범위를 가시화하는 것입니다. 예컨대 bulk import로 30개 중 5개가 실패했다면 실패한 5개의 식별자와 가능한 이유를 목록으로 제공해 사용자가 전체 작업을 되돌리지 않고 필요한 부분만 수정·재시도할 수 있게 하는 방식입니다. 이는 실패를 국소화하고 사용자의 통제감을 회복시킨다는 점에서 의미가 있습니다.

개인적으로는 불확실성을 숨기지 말고 관리하는 전략이 핵심이라고 보는데요. 원인을 모를 때는 그 사실을 명시하고, 사용자가 선택할 수 있는 가장 낮은 비용의 다음 단계를 함께 제시하는 것이 바람직합니다. 또한 시스템은 가능한 범위 내에서 실패 단위를 쪼개고, 항목별 상태와 참조용 식별자(correlation ID)를 남겨 사용자 화면에 요약 노출할 수 있어야 합니다. 결국 에러 메시지는 기술 로그의 축약본이 아니라 사용자의 의사결정을 돕는 인터페이스라고 볼 수 있습니다.

결론 및 시사점

정리하면, 무책임한 포괄 메시지에서 벗어나 "무엇이 일어났는지·누구의 문제인지·지금 무엇을 할지"를 담는 에러 설계가 필요하다는 문제의식인데요. 동시에 운영 환경에서는 즉시 원인 규명이 어려운 한계가 존재합니다. 따라서 좋은 패턴은 확실한 사실부터 전달하고, 불확실성은 투명하게 명시하며, 사용자가 바로 취할 수 있는 행동과 부분 실패 정보를 제공하는 방향으로 수렴합니다. 이는 blame을 줄이고 사용자 agency를 높이는 UX 원칙과 맞닿아 있다는 점에서 의미가 있습니다. 다만 이를 실현하려면 백엔드가 실패 단위를 식별·반환하고, 항목별 결과와 메타데이터를 남기며, 프런트엔드가 이를 사람 친화적 문구로 매핑하는 설계와 telemetry가 필요합니다. 이런 토대 없이 메시지만 바꾸면 결국 다시 "Please try again"에 머물 수밖에 없다는 한계도 분명합니다.