[번역] accept 속성이 파일 업로드 UX를 저하시키는 이유
Adam Silver - 2026년 5월 31일
지난주에 저는 파일 입력(input)의
accept 속성이 왜 나쁜 UX인지에 대해 글을 올렸습니다.accept 속성을 사용하면 입력창에서 허용할 파일 형식을 지정할 수 있습니다. 예를 들어, 사용자가 영수증을 업로드해야 한다면 다음과 같이 작성할 수 있습니다.<input type="file" accept="image/jpeg,image/png">이렇게 하면 사용자는 해당 파일 형식만 선택할 수 있습니다. 그 외의 모든 파일은 비활성화됩니다.
제출 전에 사용자가 잘못된 형식을 선택하는 것을 방지하여 에러 발생을 막아주기 때문에, 언뜻 보기에는 좋아 보입니다.
하지만 지난 포스트에서 언급했듯이, 이는 다음과 같은 이유로 나쁜 UX입니다.
- 비활성화된 파일은 회색으로 흐릿하게 표시되어 읽기 어렵습니다.
- 일부 사용자는 미묘하게 회색으로 변한 스타일을 알아차리지 못하고, 잘못된 파일을 계속 클릭하려고 시도할 것입니다.
이러한 사용자들에게 이 인터페이스는 고장 났거나 혼란스러운 것으로 느껴집니다.
하지만 Russell이라는 분이 제 의견에 반대하며 다음과 같은 답변을 주셨습니다.
"부적절한 옵션을 비활성화하는 것은 좋은 UX이며, WCAG(웹 콘텐츠 접근성 지침)에서도 권장하는 사항입니다. 사용자는 업로드 과정을 여러 번 반복하면서도 왜 작동하지 않는지 이해하지 못할 수도 있습니다. 또한 당신은 제이콥의 법칙(Jakob’s Law)을 어기고 있습니다. 업로드 시 파일을 비활성화하는 것은 사용자들에게 익숙한 방식입니다. 이를 무시하면 사용자가 자신의 방식을 조정해야 하므로 마찰이 생기고 인지 부하(Cognitive load)가 증가합니다."
문제는
accept 속성이 우리 두 사람 모두가 해결하려고 노력하는 바로 그 문제를 야기한다는 점입니다.구체적으로 말하자면, 사용자가 인터페이스가 왜 작동하지 않는지 이해하지 못하게 된다는 것입니다.
그리고 이것은 이론적인 이야기가 아닙니다.
저는 사용자 조사(User research) 과정에서 이런 현상을 반복적으로 목격했습니다.
Russell은 또한 힌트 텍스트(Hint text)를 통해 사용자에게 허용되는 형식을 알려주어야 한다고 말했습니다.
이렇게 하면 사용자가 파일 대화 상자를 열기 전에 무엇을 해야 할지 알 수 있습니다.
전적으로 동의합니다.
하지만 모든 사용자가 힌트 텍스트를 읽을 것이라고 기대해서는 안 됩니다. 연구 결과에 따르면 많은 사용자가 이를 발견하지 못하거나 읽지 않는다는 사실이 반복적으로 증명되었습니다.
이런 상황이 발생하면 사용자는 컴퓨터가 왜 반응하지 않는지 이해하지 못해 분노의 클릭(Rage clicking)을 하게 됩니다.
그것은 좋지 않습니다.
설령 사용자가 힌트 텍스트를 읽었다 하더라도, 그 내용을 기억한다는 보장은 없습니다. 아마도 사용자는 다음과 같은 상황일 수 있습니다.
- 스트레스를 받고 있거나 서두르는 중임
- 전화 통화로 인해 방해를 받음
- 인지 장애나 기억력 문제가 있음
따라서
accept 속성은 보호 계층이 아닙니다.오히려 문제의 원인입니다.
대신
accept 속성을 버리고 에러를 표시한다면, 사용자는 다음과 같이 문제를 즉시 해결하는 데 도움이 되는 피드백을 받게 됩니다.
이것만으로 충분히 설득되지 않는다면(충분해야 마땅하지만),
accept 속성에는 세 가지 문제가 더 있습니다.- 파일 형식만 처리할 뿐, 파일 크기는 처리하지 못합니다.
- 파일을 드래그 앤 드롭(Drag and drop) 방식으로 끌어다 놓으면 속성을 우회할 수 있습니다.
- 안드로이드용 Firefox와 같은 일부 브라우저에서는 이를 지원하지 않습니다.
따라서 이 방식은 취약할 뿐만 아니라, 어차피 에러 처리를 별도로 해야만 합니다.
저는 Russell에게 WCAG 어디에서
accept 속성을 권장하는지 인용해 달라고 요청했습니다. 그는 성공 기준 3.3.2와 관련된 권고 지침(Advisory guidance)을 보내주었습니다."사용자가 실수할 가능성을 줄이는 디자인을 선택하십시오. 여기에는 다음이 포함됩니다. [...] 유효한 입력만 선택할 수 있는 인터페이스 사용 [...]"
분명히 말씀드리자면:
이것은 '성공 기준(Success criteria)'이 아닙니다. '권고 지침'일 뿐입니다.
그리고 이 지침은 거의 확실히 제이콥 닐슨(Jakob Nielsen)의 5번째 사용성 휴리스틱(Usability heuristic)인 '에러 방지'에서 기인한 것입니다.
휴리스틱 자체는 훌륭하지만, 디자이너들은 이를 사용자로부터 에러를 숨겨도 된다는 승인으로 끊임없이 오해하곤 합니다.
마치 에러를 보여주고 사용자가 수정하게 하는 것보다, 에러를 숨기고 존재하지 않는 척하는 것이 더 나은 것처럼 말이죠.
요약하자면:
에러를 숨기는 것은 에러 방지가 아닙니다.
이것이 바로
accept 속성이 나쁜 이유입니다.에러를 숨기는 대신, 적절하게 에러를 방지하는 다양하고 정당하며 사용자 친화적인 방법들을 알고 싶으시다면, 저의 강의인 'Form Design Mastery'가 도움이 될 것입니다.
0
1
댓글
?
아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!
Inkyu Oh님의 다른 글
더보기번역
tsgo는 왜 그렇게 많은 메모리를 사용하나요?
Inkyu Oh • Front-End
0
0
1
번역
최고의 로딩 상태는 로딩 상태가 없는 것입니다
Inkyu Oh • Front-End
0
0
3
