# 데이터 검증

## 개

**데이터 검증**(Data)은 데이터의 정확, 일관성, 완전성 및 신뢰성을 보장하기 위해 수행되는 일련의 절차와 기법을 의미합니다. 데이터 과학 및 정보 시스템 분야에서 데이터 검증은 데이터 분석, 모델링, 의사결정 과정의 신뢰도를 확보하는 핵심 단계로, 오류가 포함된 데이터가 후속 프로세스에 영향을 미치는 것을 방지하는 데 목적이 있습니다.

특히 대량의 데이터를 다루는 빅데이터 환경이나 머신러닝 모델 개발 과정에서는 초기 데이터 품질이 결과의 정확성에 직접적인 영향을 미치기 때문에, 데이터 검증은 전처리 과정에서 필수적인 요소로 간주됩니다. 이 문서에서는 데이터 검증의 목적, 주요 방법, 도구, 그리고 실무 적용 사례를 중심으로 설명합니다.

---

## 데이터 검증의 목적

데이터 검증은 단순히 오류를 찾는 것을 넘어서, 다음과 같은 전략적 목적을 가지고 있습니다:

- **정확성 확보**: 데이터가 현실 세계의 사실과 일치하는지 확인합니다. 예: 고객 연락처 정보가 유효한 형식인지 검사.
- **일관성 유지**: 데이터 간의 논리적 관계가 유지되는지 확인합니다. 예: "출생일"이 "입사일"보다 이후일 수 없음.
- **완전성 보장**: 필요한 모든 데이터가 누락 없이 존재하는지 확인합니다. 예: 필수 입력 필드가 비어 있는지 점검.
- **무결성 유지**: 데이터베이스의 참조 무결성(예: 외래 키)을 준수하는지 확인합니다.
- **보안 및 규정 준수**: 개인정보보호법(GDPR, PIPA 등)에 따라 민감 정보가 적절히 처리되었는지 검증.

이러한 목적은 데이터 기반 의사결정의 신뢰성을 높이고, 잘못된 인사이트 도출을 방지합니다.

---

## 데이터 검증의 주요 방법

데이터 검증은 수동 또는 자동화된 방식으로 수행되며, 일반적으로 다음과 같은 방법들이 활용됩니다.

### 1. 형식 검증 (Format Validation)
데이터가 정해진 형식을 따르는지 확인합니다.
- 예: 이메일 주소는 `user@domain.com` 형식을 가져야 함
- 전화번호는 특정 국가의 규칙(예: 한국은 010-XXXX-XXXX)을 준수해야 함
- 날짜 형식이 ISO 8601(YYYY-MM-DD) 기준인지 확인

### 2. 범위 검증 (Range Validation)
수치 데이터가 허용 가능한 범위 내에 있는지 확인합니다.
- 예: 나이가 0~150 사이인지
- 성적이 0~100점 사이인지

### 3. 유형 검증 (Type Validation)
데이터의 자료형이 적절한지 확인합니다.
- 예: 숫자 필드에 문자열이 포함되지 않도록 함
- 불리언 값은 `true`/`false`만 허용

### 4. 필수 값 검증 (Mandatory Field Validation)
필수 입력 항목이 누락되었는지 확인합니다.
- 예: 회원가입 시 이름, 이메일은 필수 입력

### 5. 논리적 일관성 검증 (Logical Consistency)
다수의 필드 간의 관계가 타당한지 확인합니다.
- 예: "결혼 여부"가 "기혼"인데 배우자 이름이 없으면 오류
- "출생일"이 "고용일"보다 이후일 수 없음

### 6. 중복 데이터 검증
중복된 레코드가 존재하는지 확인합니다.
- 예: 동일한 고객 ID로 두 개의 레코드 존재

### 7. 참조 무결성 검증 (Referential Integrity)
데이터베이스에서 외래 키가 참조하는 기본 키가 존재하는지 확인합니다.
- 예: 주문 테이블의 `고객ID`가 고객 테이블에 실제로 존재하는지

---

## 데이터 검증 도구 및 프레임워크

자동화된 데이터 검증을 위해 다양한 도구와 라이브러리가 사용됩니다.

| 도구 | 설명 |
|------|------|
| **Great Expectations** | 파이썬 기반 오픈소스 라이브러리. 데이터의 기대 조건(Expectations)을 정의하고 검증 가능. |
| **Pandas + Custom Scripts** | 파이썬의 Pandas를 활용해 수동으로 검증 로직 구현. 유연하지만 유지보수 어려움. |
| **Deequ (by AWS)** | Apache Spark 기반의 데이터 품질 검증 도구. 대규모 데이터셋에 적합. |
| **Talend** | ETL 도구 내장 검증 기능. 비개발자도 사용 가능. |
| **dbt (data build tool)** | 데이터 변환 과정에서 검증 단계를 통합. SQL 기반 검증 가능. |

예시: Great Expectations를 사용한 검증 코드
```python
import great_expectations as gx

context = gx.get_context()
validator = context.sources.pandas_default.read_csv("data.csv")

# 이메일 형식 검증
validator.expect_column_values_to_match_regex("email", r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")

# 나이 범위 검증
validator.expect_column_values_to_be_between("age", min_value=0, max_value=120)

# 검증 결과 저장
results = validator.validate()
print(results.success)
```

---

## 실무 적용 사례

### 1. 금융 데이터 처리
은행에서 고객 대출 정보를 처리할 때, 신용 점수는 반드시 300~850 범위 내에 있어야 하며, 소득 정보는 음수가 될 수 없습니다. 이와 같은 제약 조건을 검증 규칙으로 설정하여 자동 검사합니다.

### 2. 의료 데이터 통합
병원 정보 시스템에서 환자 데이터를 통합할 때, 생년월일과 진료일의 일관성, 진단 코드의 표준 형식(CPT, ICD-10) 준수 여부를 검증합니다.

### 3. 전자상거래 로그 분석
사용자 행동 로그에서 세션 ID, 타임스탬프, 이벤트 유형의 형식이 올바른지 확인하고, 비정상적인 접근 패턴(예: 미래 시간대 로그)을 필터링합니다.

---

## 참고 자료 및 관련 문서

- [Great Expectations 공식 문서](https://docs.greatexpectations.io/)
- [Deequ GitHub 저장소](https://github.com/awslabs/deequ)
- Kimball, R., & Ross, M. (2013). *The Data Warehouse Toolkit*. Wiley.
- GDPR 및 개인정보보호법(PIPA) 관련 데이터 처리 가이드라인

데이터 검증은 데이터 과학의 기초이자 핵심이며, 지속적인 모니터링과 개선이 필요합니다. 체계적인 검증 프로세스를 도입함으로써 데이터 기반 조직의 신뢰성과 효율성을 극대화할 수 있습니다.

## 입력 단계의 데이터 검증 전략

데이터가 시스템에 진입하는 시점에 따라 검증 전략을 다르게 설정해야 합니다. 일반적으로 클라이언트 측 검증과 서버 측 검증을 모두 수행하는 '이중 검증' 전략이 권장됩니다.

| 구분 | 클라이언트 측 검증 (Client-side) | 서버 측 검증 (Server-side) |
| :--- | :--- | :--- |
| **수행 위치** | 브라우저, 모바일 앱 (Frontend) | API 서버, DB 서버 (Backend) |
| **주요 목적** | 사용자 경험(UX) 향상, 즉각적인 피드백 | 데이터 무결성 보장, 보안 강화 |
| **검증 시점** | 데이터 전송 전 (실시간/제출 시) | 데이터 수신 후, DB 저장 전 |
| **신뢰도** | 낮음 (사용자가 우회 가능) | 높음 (시스템 제어 가능) |
| **장점** | 서버 부하 감소, 빠른 응답 속도 | 보안 사고 방지, 최종 데이터 정확성 보장 |

## 입력 값 검증 기법

데이터의 오염을 막기 위해 다음과 같은 구체적인 제어 기법을 사용합니다.

- **화이트리스트(Whitelist) 필터링**: 허용된 값의 목록을 정의하고, 그 외의 모든 입력을 거부하는 방식입니다. 가장 안전한 방법으로, 예상 가능한 입력 값의 집합이 명확할 때 사용합니다.
- **블랙리스트(Blacklist) 필터링**: 금지된 특정 문자나 패턴(예: `<script>`, `DROP TABLE`)을 정의하고 이를 차단하는 방식입니다. 새로운 공격 패턴이 계속 등장하므로 화이트리스트보다 보안성이 낮습니다.
- **정규 표현식(Regular Expression) 패턴 매칭**: 특정 규칙(예: 전화번호, 우편번호, 비밀번호 복잡도)을 정의하여 입력 값이 해당 패턴과 일치하는지 검사합니다.
- **입력 값 정규화(Normalization)**: 데이터 검증 전, 입력 값을 일관된 형식으로 변환하는 과정입니다. (예: 공백 제거, 대소문자 통일, 유니코드 정규화 등)

## 실시간 및 비동기 검증

정적인 검증 외에 사용자 인터랙션에 따라 다음과 같은 동적 검증 방식을 도입하여 편의성을 높입니다.

- **실시간 검증 (Real-time Validation)**: 사용자가 입력 필드에서 포커스를 옮기거나 타이핑하는 즉시 검증을 수행합니다. (예: 비밀번호 입력 시 '8자 이상' 조건 충족 여부를 즉시 표시)
- **비동기 검증 (Asynchronous Validation)**: 서버의 데이터베이스 조회가 필요한 경우, 페이지 새로고침 없이 API 통신을 통해 검증합니다. (예: 회원가입 시 '아이디 중복 확인' 버튼 클릭 또는 입력 후 자동 체크)

## 입력 검증 특화 라이브러리

최근에는 스키마 정의를 통해 타입 체크와 값 검증을 동시에 수행하는 라이브러리가 널리 사용됩니다.

### Python: Pydantic
타입 힌트를 기반으로 데이터 유효성을 검사하며, FastAPI 등 현대적인 프레임워크의 표준으로 사용됩니다.

```python
from pydantic import BaseModel, EmailStr, Field, ValidationError

class UserSchema(BaseModel):
    username: str = Field(..., min_length=3, max_length=20)
    email: EmailStr
    age: int = Field(..., ge=0, le=120)

try:
    user = UserSchema(username="kd", email="invalid-email", age=150)
except ValidationError as e:
    print(e.json()) # 길이 부족, 이메일 형식 오류, 범위 초과 출력
```

### JavaScript/TypeScript: Zod
TypeScript 우선(TypeScript-first) 스키마 선언 및 검증 라이브러리로, 런타임 타입 안전성을 보장합니다.

```typescript
import { z } from "zod";

const UserSchema = z.object({
  username: z.string().min(3).max(20),
  email: z.string().email(),
  age: z.number().int().min(0).max(120),
});

const result = UserSchema.safeParse({
  username: "kd",
  email: "invalid-email",
  age: 150,
});

if (!result.success) {
  console.log(result.error.format()); // 상세 검증 오류 출력
}
```

## 보안 사고 예방 사례: SQL 인젝션 방지

입력 값 검증과 매개변수화 쿼리(Parameterized Query)를 사용하지 않을 경우, 공격자가 악의적인 SQL 구문을 삽입하여 데이터베이스를 조작할 수 있습니다.

### ❌ 취약한 코드 (검증 없음)
사용자 입력값을 문자열에 직접 결합하여 쿼리를 생성하는 경우입니다.
```python
# 사용자 입력: 'admin' OR '1'='1'
user_id = "admin' OR '1'='1"
query = f"SELECT * FROM users WHERE id = '{user_id}'"
# 실행 결과: SELECT * FROM users WHERE id = 'admin' OR '1'='1' 
# -> 모든 사용자 정보가 유출됨
```

### ✅ 안전한 코드 (입력 검증 및 매개변수화)
입력 값의 형식을 검증하고, 쿼리 파라미터를 분리하여 처리합니다.
```python
# 1. 입력 값 검증 (정규식 또는 라이브러리 사용)
if not user_id.isalnum(): # 영문/숫자만 허용
    raise ValueError("Invalid Input")

# 2. 매개변수화 쿼리 사용 (Prepared Statement)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
# 실행 결과: 입력값이 단순 문자열로 처리되어 SQL 구문으로 해석되지 않음
```

## 거래 생성 과정의 데이터 검증 절차

거래(Transaction) 발생 시 데이터의 원자성(Atomicity)과 일관성(Consistency)을 보장하기 위해 검증은 단일 시점이 아닌, 거래의 생명주기에 따라 단계별로 수행됩니다.

### 1. 단계별 검증 흐름
1. **사전 검증 (Pre-Validation)**: 거래 요청이 접수된 즉시 수행하며, 요청 데이터의 형식, 필수 값 누락 여부, 기본적인 비즈니스 제약 조건(예: 송금액이 0보다 큰지)을 확인합니다.
2. **실행 중 검증 (In-Flight Validation)**: 실제 데이터베이스 업데이트 직전에 수행합니다. 현재 시점의 잔액 확인, 계좌 상태(정지 여부), 한도 초과 여부 등 실시간 상태를 검증합니다.
3. **사후 검증 (Post-Validation)**: 거래 완료 후, 결과 데이터가 논리적으로 타당한지 확인합니다. (예: A계좌 감소액과 B계좌 증가액의 합계가 일치하는지 검증)

### 2. 검증 시퀀스 다이어그램
```mermaid
sequenceDiagram
    participant Client as 클라이언트
    participant API as API 서버
    participant DB as 데이터베이스
    participant Val as 검증 엔진

    Client->>API: 거래 요청 (송금 요청)
    API->>Val: 사전 검증 요청 (형식, 필수값)
    Val-->>API: 검증 통과
    API->>DB: 현재 상태 조회 (잔액, 계좌상태)
    DB-->>API: 상태 데이터 반환
    API->>Val: 실행 중 검증 요청 (잔액/한도 체크)
    Val-->>API: 검증 통과
    API->>DB: 거래 실행 (Update/Insert)
    DB-->>API: 실행 완료
    API->>Val: 사후 검증 요청 (합계 일치 여부)
    Val-->>API: 최종 무결성 확인 완료
    API-->>Client: 거래 성공 응답
```

---

## 거래 무결성을 위한 특수 검증 기법

금융 및 상거래 시스템에서는 단순한 타입 체크를 넘어, 데이터의 절대적 무결성을 보장하기 위한 특수 기법을 적용합니다.

### 1. 멱등성(Idempotency) 검증
동일한 요청이 여러 번 전달되어도 결과가 단 한 번만 반영되도록 보장하는 기법입니다. 네트워크 오류로 인한 재시도(Retry) 시 중복 결제나 중복 송금을 방지하는 데 필수적입니다.

**구현 예시 (Idempotency Key 방식):**
- 클라이언트가 요청 시 고유한 `Idempotency-Key`(UUID 등)를 헤더에 포함하여 전송합니다.
- 서버는 해당 키를 저장소(Redis 등)에 기록하고, 동일한 키로 요청이 오면 실제 로직을 수행하지 않고 이전의 성공 응답을 그대로 반환합니다.

```python
# 멱등성 검증 의사코드
def process_payment(request):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # 1. 이미 처리된 키인지 확인
    if cache.exists(idempotency_key):
        return cache.get(idempotency_key) # 기존 응답 반환
    
    # 2. 실제 결제 로직 수행
    result = execute_payment_logic(request.data)
    
    # 3. 결과 저장 후 반환
    cache.set(idempotency_key, result, expire=86400) # 24시간 보관
    return result
```

### 2. 이중 기입(Double-entry) 검증
모든 거래를 '차변(Debit)'과 '대변(Credit)'으로 나누어 기록하고, 두 합계의 차이가 항상 0이 되는지 검증하는 방식입니다. 이는 데이터 누락이나 임의 조작을 즉시 발견할 수 있게 합니다.

### 3. 잔액 및 한도 체크
단순 수치 검증이 아닌, 거래 시점의 스냅샷을 기반으로 한 논리적 검증입니다.
- **잔액 검증**: `현재 잔액 - 출금 요청액 $\ge$ 최소 유지 잔액`
- **한도 검증**: `금일 누적 거래액 + 현재 요청액 $\le$ 일일 이체 한도`

---

## 거래 데이터 무결성 보강

### 1. 원자성과 일관성 관점의 무결성
데이터 검증의 목적 중 '무결성 유지'는 거래 시스템에서 다음과 같은 관점으로 확장됩니다.
- **원자성(Atomicity) 보장**: "전부 성공하거나 전부 실패해야 한다." 송금 시 A의 계좌에서 돈이 빠져나갔다면, 반드시 B의 계좌에 입금되어야 합니다. 검증 실패 시 전체 프로세스를 롤백(Rollback)하여 불완전한 상태를 방지합니다.
- **일관성(Consistency) 보장**: 거래 전후의 시스템 상태가 정의된 비즈니스 규칙을 준수해야 합니다. 예를 들어, 전체 계좌의 총합 금액은 송금 전후로 변함이 없어야 한다는 규칙을 검증합니다.

### 2. 비즈니스 로직 기반 일관성 검증 사례
논리적 일관성 검증 단계에서 다음과 같은 비즈니스 체크리스트를 적용합니다.
- **총량 보존 법칙**: $\sum(\text{출금액}) = \sum(\text{입금액}) + \sum(\text{수수료})$
- **상태 전이 유효성**: '결제 대기' 상태의 주문만 '결제 완료' 상태로 변경될 수 있으며, '배송 완료' 상태에서 다시 '결제 대기'로 돌아갈 수 없음.

---

## 금융 송금 프로세스 실무 적용 사례

실제 송금 시스템에서 이루어지는 단계별 검증 시나리오와 상태 변화는 다음과 같습니다.

### 1. 송금 프로세스 상태 변화 표

| 단계 | 상태 (Status) | 주요 검증 항목 | 실패 시 조치 |
| :--- | :--- | :--- | :--- |
| **요청** | `REQUESTED` | 계좌번호 형식, 송금액 양수 여부, 인증 토큰 유효성 | 400 Bad Request 반환 |
| **검증** | `VALIDATING` | 출금 계좌 잔액, 일일 이체 한도, 수취 계좌 유효성 | 거래 거절 및 오류 메시지 전송 |
| **처리** | `PROCESSING` | DB 락(Lock) 획득 여부, 원자적 업데이트 가능 여부 | 롤백 및 재시도 유도 |
| **완료** | `COMPLETED` | 최종 잔액 업데이트 확인, 거래 로그 기록 일치 여부 | 관리자 알림 및 수동 조정 |
| **실패** | `FAILED` | 실패 사유 분류 (잔액부족, 시스템오류 등) | 사용자에게 실패 사유 고지 |