Validate: 정의, 입력 필드 검증 및 Android 구현

Android에서 필드 검증이란?

필드 검증은 지정된 규칙에 따라 사용자가 입력한 단일 값을 확인하는 것입니다. 각 필드에는 고유한 데이터 유형(이메일, 숫자, 전화, 비밀번호, 텍스트)이 있습니다. 각 유형에는 고유한 기준(형식, 길이, 값 범위, 필수 여부)이 있습니다. 필드 검증은 “이 필드의 입력이 올바른가?”라는 질문에 답합니다.

필드 검증과 양식 검증의 차이점은 필드가 다른 필드와 독립적으로 확인된다는 것입니다. 이메일은 이메일 패턴에 대해 검증되고, 전화는 전화 패턴에 대해 검증됩니다. 필드가 유효하지 않은 경우 사용자는 해당 특정 필드에 대한 오류를 확인합니다. 하나의 필드가 검증에 실패해도 양식은 제출되지 않은 상태로 남을 수 있습니다. 필드 검증은 완전한 양식 검증의 구성 요소입니다.

UX 연구에 따르면 사용자는 입력 완료 후 1-2초 이내에 검증 오류를 확인할 것으로 기대합니다. 3초 이상의 지연은 애플리케이션 문제로 인식됩니다. 따라서 TextWatcher를 통한 실시간 검증이 제출 버튼을 누를 때만 확인하는 것보다 더 바람직합니다.

필드 검증의 주요 방법

Android에서 필드 검증에는 세 가지 주요 접근 방식이 있습니다. 첫 번째는 조건 연산자(if, when)를 통한 수동 확인입니다. 개발자는 문자열을 받아 Boolean 또는 오류 메시지를 반환하는 함수를 작성합니다. 이 접근 방식은 로직을 완전히 제어할 수 있지만 각 필드와 각 조건에 대한 코드를 작성해야 합니다.

두 번째 접근 방식은 Android 내장 클래스 사용입니다. 예를 들어, Patterns.EMAIL_ADDRESS.matcher(email).matches()는 표준 패턴에 대해 이메일을 검증합니다. Patterns.PHONE.matcher(phone).matches()는 전화번호를 검증합니다. TextUtils.isEmpty()는 비어 있는지 확인합니다. 이러한 메서드는 외부 종속성 없이 기본 시나리오를 처리합니다.

세 번째 접근 방식은 검증 라이브러리입니다. InputValidator, AndroidValidator 또는 Commons Validator와 같은 라이브러리는 미리 만들어진 어노테이션과 검증 체인을 제공합니다. 개발자는 규칙을 선언적으로 설명합니다: @Email, @NotEmpty, @MinLength(6). 라이브러리 자체가 검증을 수행하고 오류 목록을 반환합니다. 이는 개발 속도를 높이지만 종속성을 추가합니다.

이메일, 전화, 비밀번호 검증

이메일의 표준 검증에는 @ 기호, 도메인 부분의 존재, 공백 및 키릴 문자가 없는지 확인이 포함됩니다. Android는 대부분의 합법적인 이메일 주소를 처리하는 Patterns.EMAIL_ADDRESS를 제공합니다. 그러나 특정 검증(예: 회사 도메인만)이 필요한 경우 사용자 정의 정규식을 작성해야 합니다. 이메일은 각 문자 후가 아닌 입력 완료 후에 검증됩니다.

전화번호는 국가 또는 지역 마스크에 대해 검증됩니다. 국제 전화번호의 경우 E.164 형식(+국가 코드, 통신사 코드, 번호)이 사용됩니다. Google의 libphonenumber 라이브러리는 전화 검증의 업계 표준입니다. 코드로 국가를 확인하고 번호의 길이와 형식을 검증합니다. Android에서는 기본 검증을 위해 PhoneNumberUtils.isGlobalPhoneNumber를 사용할 수 있습니다.

비밀번호에는 여러 복잡성 기준(최소 길이, 대문자 및 소문자, 숫자, 특수 문자 존재)이 있습니다. Android에는 비밀번호 검증을 위한 내장 클래스가 없습니다 — 각 프로젝트가 자체 요구사항을 정의합니다. 일반적으로 비밀번호는 정규식 또는 조건 집합을 통해 검증됩니다. 오류 메시지에 정확한 요구사항을 노출하지 않는 것이 중요합니다: “비밀번호가 너무 간단합니다”가 “대문자와 숫자가 필요합니다”보다 좋습니다.

data class ValidationResult(
    val isValid: Boolean,
    val errorMessage: String? = null
)

fun validatePassword(password: String): ValidationResult {
    if (password.length < 6)
        return ValidationResult(false, "Minimum 6 characters")
    if (!password.any { it.isUpperCase() })
        return ValidationResult(false, "Uppercase letter required")
    return ValidationResult(true)
}

예제에서 validatePassword는 isValid 필드와 선택적 오류 메시지가 있는 ValidationResult를 반환합니다. 이 접근 방식은 구성에 편리합니다: 여러 검증이 순차적으로 수행되고 첫 번째 발견된 오류가 반환됩니다. 이메일 및 전화 검증도 동일한 원칙을 따릅니다 — 각각 메시지 또는 성공과 함께 결과를 반환합니다.

언제 검증을 수행해야 하나요?

검증 시점은 UX에 큰 영향을 미칩니다. 세 가지 전략이 있습니다: 각 문자 후 검증(즉시), 포커스 손실 후(onFocusLost), 양식 제출 시(onSubmit). 각 전략은 다른 시나리오에 적합합니다. 즉시 검증은 엄격한 제약이 있는 필드(전화번호, PIN 코드)에 좋습니다. OnFocusLost는 이메일과 이름에 적합합니다. OnSubmit은 필수 필드에 적합합니다.

Material Design Guidelines에 따르면 전략을 결합하는 것이 좋습니다: 필드는 포커스 손실 시와 양식 제출 시 모두 검증되어야 합니다. 즉시 검증은 제약이 명확한 경우(예: 최대 필드 길이)에 적합합니다. 이메일에 대해 각 문자 후 오류를 표시하면 사용자가 입력을 마치기 전에 메시지를 보게 됩니다. 이는 짜증나게 하고 전환율을 낮춥니다.

첫 번째 오류 규칙: 양식 제출 시 첫 번째 유효하지 않은 필드에 대해서만 오류를 표시합니다. 10개의 오류 목록으로 사용자를 압도하지 마십시오. 첫 번째 오류를 수정한 후 다음 오류를 표시할 수 있습니다. 이 단계별 안내는 인지 부하를 줄이고 사용자가 양식을 더 빨리 작성하는 데 도움이 됩니다.

검증을 위한 도구 및 라이브러리

Android SDK는 Validate를 위한 기본 도구를 제공합니다: 이메일 및 전화용 Patterns, 비어 있음 확인용 TextUtils, 임의 패턴용 정규식. 1-3개 필드가 있는 프로젝트의 경우 이것으로 충분합니다. 그러나 10+개 필드가 있는 양식에서는 수동 검증 유지보수가 어려워집니다 — 새 필드마다 별도의 함수와 업데이트된 제출 로직이 필요합니다.

인기 있는 검증 라이브러리: Android Saripaar(@Email, @NotEmpty, @Password 어노테이션), Apache Commons Validator(이메일, URL, 신용카드 번호 검증), 반응형 검증을 위한 RxBinding + RxJava. Saripaar를 사용하면 입력 필드에 직접 어노테이션을 배치하고 한 줄로 검증을 호출할 수 있습니다: validator.validate(). 라이브러리는 setError를 통해 자동으로 오류를 표시합니다.

Google은 TextInputLayout과 함께 Material Design Components를 사용할 것을 권장합니다. setError, setHelperText 및 setCounterEnabled를 통한 내장 검증은 타사 라이브러리 없이 기본 시나리오를 처리합니다. 복잡한 프로젝트(핀테크, 헬스케어)의 경우 Material Components + Clean Architecture의 도메인 계층 패턴을 사용한 사용자 정의 검증 조합을 사용하는 것이 좋습니다.

필드 검증 시 흔한 오류

첫 번째 오류는 입력 시작 전에 오류를 표시하는 것입니다. 필드가 필수이지만 사용자가 입력을 시작하지 않은 경우 “필드는 필수입니다”를 표시하지 마십시오. 이는 잘못된 문제 인식을 만듭니다. 오류는 사용자가 필드와 상호작용한 후(입력 시작, 필드 이탈, 양식 제출 시도)에만 표시되어야 합니다.

두 번째 오류는 불명확한 오류 메시지입니다. 메시지는 구체적이어야 하며 문제 해결 방법을 제시해야 합니다. “유효하지 않은 이메일”은 나쁩니다. “이메일에는 @와 도메인이 포함되어야 합니다(예: user@example.com)”이 좋습니다. 사용자는 문서를 참조하지 않고도 무엇이 잘못되었고 어떻게 수정하는지 이해할 수 있어야 합니다.

세 번째 오류는 설명 없이 제출 차단입니다. 검증 오류로 인해 제출 버튼이 비활성화된 경우 사용자는 어떤 필드가 유효하지 않은지 확인할 수 있어야 합니다. 메시지 없는 회색 버튼은 사용자에게 막다른 골목입니다. 항상 오류가 있는 필드를 강조 표시하고 각 유효하지 않은 필드 옆에 오류 텍스트를 표시하십시오.