모바일 앱의 입력 검증 — 기본, 검사 방법 및 구현

입력 검증이란 무엇인가?

입력 검증은 사용자, 외부 서비스 또는 다른 구성 요소로부터 애플리케이션에 들어오는 데이터가 예상되는 기준을 충족하는지 확인하는 것입니다. 이 기준에는 데이터 유형(문자열, 숫자, 날짜), 형식(이메일, URL, 전화), 값 범위(나이 18~120), 길이(비밀번호 8~128자) 및 허용되는 문자(라틴 문자, 숫자, 하이픈만)가 포함됩니다. 검증이 없으면 애플리케이션이 런타임 오류, 데이터 손상 또는 보안 취약점을 유발하는 데이터를 처리할 수 있습니다.

검증이 중요한 보안 요소인 이유

입력 검증의 부재는 SQL Injection, XSS, Command Injection, Path Traversal, Buffer Overflow와 같은 취약점의 근본 원인입니다.MITRE CWE (2025)에 따르면 CWE-20(Improper Input Validation)은 가장 위험한 소프트웨어 오류 순위에서 2위를 차지합니다. 검증은 Defense in Depth 보안 모델의 첫 번째 방어선입니다. 잘못된 데이터가 시스템의 다른 구성 요소에 도달하기 전에 차단합니다.

검증 vs 살균

검증은 기준을 충족하지 않는 데이터를 거부합니다. 살균(정리)은 위험한 부분을 제거하거나 이스케이프하여 데이터를 수정합니다. 예를 들어 HTML 콘텐츠를 입력할 때 검증은 텍스트 길이를 확인하고 살균은 HTML Purifier 또는 DOMPurify 라이브러리로 script 태그를 제거합니다. 살균은 검증을 대체하지 않습니다. 둘은 함께 작동합니다. 검증은 "허용/금지" 정책이고 살균은 "사용 전 정리"입니다.

입력 검증의 유형

검증은 검사 깊이에 따라 분류됩니다. 형식 검증은 가장 간단하고 빠르며, 비즈니스 검증은 가장 복잡하고 상황에 따라 달라집니다. 세 가지 수준을 모두 순서대로 적용해야 합니다. 먼저 형식, 그다음 의미, 그다음 비즈니스 로직입니다. 어느 한 수준을 건너뛰면 시스템 오작동이나 취약점이 발생할 수 있습니다.

형식 검증

데이터 유형, 크기, 형식 및 허용 문자 확인.정규식, 언어의 내장 유형 및 검증 라이브러리를 통해 구현됩니다. 예: UUID 확인(8-4-4-4-12 16진수 형식), 전화번호 확인(숫자만, 시작 부분 +, 7~15자), 정수 확인(값이 Integer.MIN_VALUE — Integer.MAX_VALUE 범위 내). 형식 검증은 모든 입력 필드의 최소 필수 수준입니다.

의미 검증

도메인 맥락에서 데이터의 논리적 정확성을 확인합니다. 예: 시작 날짜가 종료 날짜보다 늦지 않음, 나이가 시스템에 합리적인 범위 내, 좌표가 서비스 영역 내. 의미 검증에는 비즈니스 맥락 이해가 필요하며 형식만으로는 수행할 수 없습니다. 예: "티켓 수" 필드는 형식 검증(정수, > 0)을 통과할 수 있지만 의미적으로는 사용 가능한 좌석 수를 초과할 수 없습니다.

비즈니스 검증

가장 복잡한 수준 — 애플리케이션의 비즈니스 규칙에 대한 데이터 준수를 확인합니다. 예: 사용자는 유일한 관리자를 삭제할 수 없음, 주문 금액이 신용 한도를 초과하지 않음, 상품은 재고가 있을 때만 주문할 수 있음. 비즈니스 검증에는 종종 데이터베이스 쿼리 또는 외부 서비스가 필요하며 형식 및 의미 검사 후에 수행됩니다. 비즈니스 검증 오류는 사용자 불만의 가장 흔한 원인입니다.

클라이언트 측 및 서버 측 검증

클라이언트 측 검증(브라우저 또는 모바일 앱)은 사용자 편의를 위해 필요합니다. 데이터를 서버로 보내지 않고 즉각적인 피드백을 제공합니다. 그러나 서버 측 검증만이 유일하게 신뢰할 수 있습니다. 클라이언트 코드는 항상 우회할 수 있기 때문입니다. 개발자 도구, Postman 또는 프록시(Burp Suite)를 통해 요청을 보내면 클라이언트 측 검증은 존재하지 않게 됩니다.PortSwigger Research (2025)에 따르면 테스트된 웹 애플리케이션의 90% 이상이 하나 이상의 필드에서 클라이언트 측 검증에만 의존합니다.

규칙: 클라이언트는 UX용, 서버는 보안용

클라이언트 측 검증은 제출 버튼을 비활성화하고, 오류를 강조하고, 힌트를 표시할 수 있습니다. 서버 측 검증은 클라이언트가 이미 확인했더라도 모든 매개변수의 필수 검사입니다. 두 수준 모두에서 검증을 중복하는 것은 표준 관행입니다. 서버는 클라이언트가 존재하지 않는 것처럼 데이터를 검사해야 합니다. 이는 변조된 요청, 자동화된 공격 및 악의적인 클라이언트로부터의 보호를 보장합니다.

클라이언트 측 검증 구현

웹에서는 — HTML5 속성(required, pattern, min/max, type="email") 및 JavaScript. 모바일 앱에서는 — 네이티브 텍스트 필드 검증기(Android의 InputFilter, iOS의 textField(:shouldChangeCharactersIn:)). React용 React Hook Form 및 Formik, Vue용 Vuelidate, Angular Reactive Forms — 클라이언트 측 검증을 위한 인기 있는 라이브러리입니다. 모두 사용자 지정 규칙과 비동기 검증(서버에서 로그인 고유성 확인)을 지원합니다.

// Express 및 Joi를 사용한 서버 측 검증의 예
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — 이미 검증되었고 안전한 데이터
    const user = await User.create(value);
    res.status(201).json(user);
});

모바일 앱에서의 검증

모바일 앱은 데이터 검증에 특별한 요구 사항을 부과합니다. 화면이 작아서 오류는 간결해야 하고, 키보드는 상황에 맞아야 하며(숫자 입력 시 숫자 키패드), UI를 차단하지 않도록 검사는 비동기여야 합니다. 네이티브 플랫폼은 기본적으로 사용해야 하는 내장 검증 메커니즘을 제공합니다. Android용 Material Design Guidelines와 iOS용 Human Interface Guidelines에는 검증 오류 표시에 대한 자세한 권장 사항이 포함되어 있습니다.

Android에서의 검증 (Jetpack Compose)

Jetpack Compose는 상태 관리를 통해 선언적인 검증 접근 방식을 제공합니다. 각 입력 필드는 상태(MutableState)에 바인딩되고 오류는 현재 값을 기반으로 계산됩니다.Compose Validator 라이브러리는 required, email, min/max length, pattern과 같은 규칙 생성을 단순화합니다. 검증은 텍스트 변경(onValueChange) 또는 양식 제출 시도 시 트리거됩니다. 첫 제출 후 또는 사용자가 입력을 마친 후에만 오류를 표시하는 것이 좋습니다(디바운스 300-500ms).

iOS에서의 검증 (SwiftUI)

SwiftUI에는 내장 양식 검증 메커니즘이 없지만 Combine 및 프로퍼티 래퍼를 통해 쉽게 구현할 수 있습니다. 필드 값에 @State를 사용하고 오류에 계산된 속성을 사용하세요.ValidatedPropertyKit 프레임워크는 @Validated().email(), @Validated().range(18...120) 같은 준비된 데코레이터를 제공합니다. iOS 권장 사항 — 입력 수준에서 오류 수를 줄이기 위해 키보드 유형(UIKeyboardType.emailAddress, .numberPad)과 자동 대문자화를 사용하세요.

Flutter에서의 검증

Flutter는 검증기 콜백으로 내장 검증이 있는 Form 및 TextFormField 클래스를 제공합니다. 각 필드는 데이터가 올바르면 오류를 문자열로, 올바르지 않으면 null을 반환합니다. FormState.validate()는 양식의 모든 필드 검사를 실행합니다. 복잡한 경우를 위한 reactive_forms 패키지: 사용자 지정 검증기, 비동기 검사, 동적 규칙. Flutter Web과 모바일 버전은 동일한 API를 사용하므로 유지 관리가 쉽습니다.

// Flutter의 양식 검증 예시
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // 유효한 데이터 처리
                    }
                },
                child: Text('제출'),
            ),
        ],
    ),
)

검증 기술 및 도구

최신 프레임워크는 요구 사항의 80%를 충족하는 내장 검증기를 제공합니다. 나머지 20%는 사용자 지정 규칙, 정규식 또는 기존 규칙의 조합이 필요합니다. 핵심 원칙은 검증이 선언적이어서 쉽게 읽고, 테스트하고, 유지 관리할 수 있어야 한다는 것입니다. 컨트롤러와 화면에 분산된 검증 로직을 피하고 별도의 클래스나 스키마로 옮기세요.

화이트리스트 vs 블랙리스트 접근 방식

화이트리스트 — 허용되는 데이터를 정의하고 나머지는 모두 거부합니다. 블랙리스트 — 금지되는 데이터를 정의하고 나머지는 모두 통과시킵니다. 화이트리스트가 항상 더 신뢰할 수 있습니다: 어떤 데이터가 통과할지 정확히 알 수 있습니다. 블랙리스트는 가능한 모든 공격을 예측해야 하는데 이는 불가능합니다. 예: 나이를 확인할 때 블랙리스트("0", "-1", "999999" 금지)가 아닌 화이트리스트(18~120 숫자만)를 사용하세요.

정규식 — 강력함과 위험

정규식은 형식 검증을 위한 효과적인 도구이지만 ReDoS 공격(Regular Expression Denial of Service)의 원인이 될 수 있습니다. 일부 패턴(예: (a+)+b)은 긴 문자열에서 치명적인 백트래킹을 유발하여 서버 CPU를 완전히 점유합니다. 검증된 regex 라이브러리를 사용하고 정규식을 적용하기 전에 문자열 길이를 제한하세요. 복잡한 경우(이메일, URL)에는 자체 제작 정규식 대신 언어의 내장 파서를 사용하세요.

검증 시 흔한 실수

경험 많은 개발자도 검증 구현 시 실수를 합니다. 가장 흔한 것: 클라이언트에서만 검증, 너무 엄격한 규칙(비밀번호 "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), 정보가 없는 오류 메시지("Error: invalid input") 및 엣지 케이스 무시(처음/끝 공백, Unicode 문자, 빈 문자열). 이러한 각 실수는 UX를 악화시키고 양식 전환율을 낮출 수 있습니다.

• 클라이언트에서만 검증 — 가장 위험한 실수: 모든 요청은 Postman 또는 cURL로 위조할 수 있음
• 너무 엄격한 규칙 — 사용자를 쫓아냄: OWASP는 등록 시 최소 요구 사항을 권장함
• Unicode 무시 — 문자(문자 단위)가 아닌 바이트로 문자열 길이를 확인하면 러시아어, 중국어, 이모지가 깨짐
• 정보 없는 오류 — "Email must contain @ symbol after local part" 대신 "Invalid format"
• 빈 필드 확인 — if (value)는 빈 문자열과 0, false, "0"을 구분하지 않음

모범 사례는 단위 테스트로 커버되는 중앙 집중식 검증 시스템입니다. 각 규칙은 경계 값, 올바른 데이터, 일반적인 공격(SQLi 시도, XSS 페이로드, 매우 긴 문자열)을 별도로 테스트해야 합니다. 검증에 대한 회귀 테스트는 리팩토링 중 규칙이 우발적으로 약해지는 것을 방지합니다. 속성 기반 테스트(QuickCheck, fast-check)를 사용하여 무작위 데이터를 생성하고 검증이 예외로 실패하지 않는지 확인하세요.