입력 오류 문구, ‘다시 확인해 주세요’보다 필요한 5가지

입력 오류 문구는 사용자를 탓하는 경고가 아니라, 문제가 생긴 항목과 고치는 방법을 알려 주는 안내입니다. “다시 확인해 주세요”만 쓰면 무엇을 다시 봐야 하는지 알기 어렵습니다. 오류 항목, 문제 설명, 허용 형식, 수정 행동, 색 외의 단서까지 다섯 가지를 갖추면 사용자는 시행착오를 줄이고 입력을 이어갈 수 있습니다.

 

출처: Polina Tankilevitch, Pexels - 입력 오류 문구가 필요한 온라인 입력 상황을 설명하는 자료사진 - 확인일 2026년 9월 15일

 

왜 ‘다시 확인해 주세요’만으로는 부족할까요?

 

회원가입이나 결제 폼을 제출했는데 화면 위에 “입력값을 다시 확인해 주세요”라고만 뜨는 경우가 있습니다. 사용자는 어느 칸이 틀렸는지 찾기 위해 이름, 이메일, 전화번호, 비밀번호를 다시 훑어야 합니다. 빨간 테두리만 추가됐다면 색을 구분하기 어렵거나 화면을 확대해 쓰는 사람은 오류 위치를 더 늦게 발견할 수 있습니다.

 

WCAG 2.2의 오류 식별 기준은 자동으로 감지된 입력 오류가 있다면 오류가 난 항목을 식별하고, 오류 내용을 텍스트로 설명하도록 안내합니다. 핵심은 경고를 보여 주는 데서 끝나는 것이 아니라 사용자가 문제를 찾을 수 있게 만드는 것입니다.

 

좋은 문구는 짧더라도 구체적입니다. “이메일 주소에 @가 없습니다”는 문제를 알려 주고, “name@example.com 형식으로 입력해 주세요”는 다음 행동을 제시합니다. 두 문장을 합치면 사용자는 다른 입력칸을 뒤질 필요 없이 바로 고칠 수 있습니다.

 

1) 어느 항목에서 오류가 났는지 적습니다

 

첫 번째 정보는 오류 항목입니다. “필수 항목입니다”만 여러 곳에 반복되면 사용자는 문구와 입력칸의 관계를 다시 추측해야 합니다. “휴대전화 번호를 입력해 주세요”, “배송지 우편번호를 입력해 주세요”처럼 항목 이름을 문장에 포함하면 오류 요약 영역에서도 뜻이 유지됩니다.

 

문구는 가능하면 해당 입력칸 가까이에 둡니다. 화면 위에 오류 목록을 함께 제공한다면 각 문구를 해당 입력칸과 연결하는 방법도 고려해야 합니다. 시각적 위치만으로 관계를 전달하기보다 프로그램이 읽을 수 있는 이름과 설명을 함께 제공하면 보조 기술을 쓰는 사용자도 같은 정보를 얻을 수 있습니다.

 

2) 무엇이 잘못됐는지 텍스트로 설명합니다

 

두 번째 정보는 문제의 내용입니다. “유효하지 않습니다”는 실패했다는 사실만 알려 줄 뿐, 빠진 값인지 형식이 다른지 범위를 벗어났는지 구분하지 못합니다. 자동으로 원인을 알 수 있다면 “비밀번호가 8자보다 짧습니다”, “예약 날짜가 오늘보다 이전입니다”처럼 확인된 문제를 설명합니다.

 

색은 보조 단서로 쓸 수 있지만 유일한 단서가 되어서는 안 됩니다. 빨간색 테두리와 함께 오류 아이콘, 텍스트 설명을 제공하면 색을 구분하기 어려운 상황에서도 상태를 이해할 수 있습니다. 아이콘만 놓을 때도 의미가 화면 낭독기에 전달되는지 별도로 확인해야 합니다.

 

오류 문구는 공격적이거나 모호한 표현을 피합니다. “잘못 입력하셨습니다”보다 “카드 번호는 숫자 16자리로 입력해 주세요”가 문제 해결에 직접 도움이 됩니다. 시스템 내부 용어와 오류 코드는 사용자에게 필요한 설명으로 바꿔야 합니다.

 

자체 제작 · W3C 오류 식별과 오류 제안 기준을 바탕으로 모호한 문구와 구체적인 수정 안내를 비교한 예시 도해 · 확인일 2026년 9월 15일

 

3) 허용되는 형식이나 조건을 알려 줍니다

 

세 번째 정보는 정답의 범위입니다. W3C의 오류 제안 기준은 입력 오류가 자동으로 감지되고 올바른 수정 방법을 알 수 있다면, 보안이나 콘텐츠 목적을 해치지 않는 범위에서 수정 제안을 제공하도록 안내합니다.

 

날짜라면 YYYY-MM-DD, 이메일이라면 name@example.com, 비밀번호라면 “영문과 숫자를 포함한 8자 이상”처럼 사용자가 맞춰야 할 조건을 구체적으로 씁니다. 예시는 실제 허용 규칙과 일치해야 합니다. 화면의 도움말에는 8자 이상이라고 적혀 있는데 검증기는 10자를 요구하면, 좋은 문구처럼 보여도 사용자는 계속 실패합니다.

 

조건은 가능하면 입력하기 전에 안내하고, 오류가 생기면 필요한 조건을 다시 보여 줍니다. 모든 규칙을 오류 뒤에 처음 공개하면 사용자는 숨겨진 규칙을 맞히는 상황에 놓입니다. 다만 주민등록번호나 계정 존재 여부처럼 상세한 힌트가 보안 위험을 키울 수 있는 정보는 공개 범위를 따로 판단해야 합니다.

 

4) 사용자가 바로 할 수 있는 수정 행동을 씁니다

 

네 번째 정보는 다음 행동입니다. “오류가 발생했습니다”보다 “공백을 제거하고 숫자만 입력해 주세요”, “종료일을 시작일 이후로 선택해 주세요”가 훨씬 실용적입니다. 문구를 읽는 즉시 무엇을 바꿀지 알 수 있어야 합니다.

 

여러 해결 방법이 있다면 가장 안전하고 가까운 행동부터 제안합니다. 인증번호가 만료된 경우 “다시 시도해 주세요”보다 “인증번호를 새로 받아 입력해 주세요”가 명확합니다. 결제 승인 실패처럼 시스템이 정확한 원인을 알 수 없는 경우에는 원인을 지어내지 말고, 다시 시도할 시점이나 다른 결제수단, 문의 경로처럼 확인된 선택지만 제공합니다.

 

자동 수정 버튼을 제공할 때는 적용 결과가 예측 가능해야 합니다. 사용자가 입력한 값을 몰래 바꾸기보다 어떤 값으로 바뀌는지 보여 주고 선택하게 하는 편이 안전합니다. 특히 금액, 날짜, 주소처럼 결과에 영향을 주는 값은 더 신중해야 합니다.

 

5) 색만이 아닌 단서로 오류 상태를 전달합니다

 

다섯 번째 정보는 중복된 상태 단서입니다. 오류 입력칸을 빨간색으로 바꾸는 것에 더해 오류 아이콘, 텍스트, 입력칸과의 연결을 함께 사용합니다. 키보드로 제출한 뒤 오류가 난 첫 항목이나 오류 요약으로 이동시키는 방식도 검토할 수 있습니다.

 

문구가 화면에 나타났더라도 보조 기술이 변화를 알아차리지 못하면 사용자는 결과를 놓칠 수 있습니다. 오류가 생긴 시점, 포커스 이동, 오류 요약과 입력칸의 연결을 실제 키보드와 화면 낭독 환경에서 확인해야 합니다. 이 글의 다섯 항목은 문구 설계의 출발점이고, 전체 접근성 적합성을 대신하는 체크는 아닙니다.

 

자체 제작 · W3C 오류 식별과 오류 제안 기준을 바탕으로 입력 오류 문구에 필요한 다섯 가지 정보를 정리한 체크리스트 · 확인일 2026년 9월 15일

 

오류 문구 작성 전 체크리스트

 

확인 항목	문구에 담을 내용	예시
오류 항목	문제가 생긴 입력칸 이름	이메일 주소
문제 설명	빠진 값이나 잘못된 조건	@가 없습니다
허용 형식	조건 또는 짧은 예시	name@example.com
수정 행동	사용자가 바로 할 일	@를 포함해 다시 입력
색 외 단서	텍스트·아이콘·연결	오류 아이콘과 설명

 

아래 순서로 소리 내어 읽어 보면 문구의 빈칸을 찾기 쉽습니다.

 

• 어느 입력칸에서 문제가 생겼는지 바로 알 수 있나요?
• 무엇이 빠졌거나 허용되지 않는지 설명했나요?
• 올바른 형식이나 조건이 실제 검증 규칙과 일치하나요?
• 사용자가 바로 실행할 수정 행동이 있나요?
• 색을 보지 못해도 오류 상태와 위치를 알 수 있나요?

 

문구를 짧게 줄일 때 남겨야 할 것

 

모바일 화면에서는 문구가 길어지기 쉽습니다. 이때 사과, 장식적인 표현, 같은 뜻의 반복부터 줄이고 항목과 해결 방법은 남깁니다. 예를 들어 “죄송합니다. 입력하신 이메일 주소가 올바르지 않은 것 같습니다. 다시 한번 확인해 주시기 바랍니다”는 “이메일 주소에 @가 없습니다. name@example.com 형식으로 입력해 주세요”로 바꿀 수 있습니다.

 

한 문구에 서로 다른 오류를 모두 넣지 않는 것도 중요합니다. 비밀번호가 짧은 경우와 확인값이 다른 경우는 해결 방법이 다르므로 각각의 원인에 맞는 문구를 보여 줍니다. 시스템이 원인을 구분할 수 없다면 확인하지 못한 원인을 단정하지 않고, 허용 조건을 다시 안내합니다.

 

자주 묻는 질문

 

오류 문구는 무조건 입력칸 바로 아래에 있어야 하나요?

 

입력칸 가까이에 두면 관계를 이해하기 쉽습니다. 화면 위의 오류 요약을 함께 쓸 수도 있지만, 각 문구가 해당 입력칸과 시각적·프로그램적으로 연결되는지 확인해야 합니다.

 

빨간 테두리와 아이콘이 있으면 텍스트는 없어도 되나요?

 

권장하기 어렵습니다. WCAG 2.2 오류 식별 기준은 오류 항목과 내용을 텍스트로 설명하도록 안내합니다. 색과 아이콘은 텍스트를 보완하는 단서로 사용하세요.

 

사용자가 틀린 값을 자동으로 고쳐 줘도 되나요?

 

예측 가능한 단순 형식은 제안할 수 있지만, 중요한 값은 변경 결과를 보여 주고 선택하게 하는 편이 안전합니다. 시스템이 원인을 확실히 알지 못하면 임의로 수정하지 마세요.

 

보안을 위해 자세한 오류 원인을 숨겨야 할 때는 어떻게 하나요?

 

계정 존재 여부나 민감정보가 드러날 수 있다면 상세 원인을 공개하지 않을 수 있습니다. 그 경우에도 사용자가 취할 수 있는 안전한 다음 행동과 공식 문의 경로를 제공하세요.

 

공식 출처

 

- W3C - Understanding SC 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification

 

- W3C - Understanding SC 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html

 

- W3C - Technique G177, Providing suggested correction text: https://www.w3.org/WAI/WCAG22/Techniques/general/G177

 

공식 자료 확인일: 2026년 9월 15일. 실제 서비스에서는 입력 규칙, 보안 범위, 키보드와 보조 기술 동작을 함께 확인해야 합니다.