Schema는 어떤 형식의 데이터를 받거나 돌려줄 것인지에 대한 계층이고 사용자 요청과 응답 형태에 대해 정의한다.
Schema 레이어에서는 사용자 요청 데이터에 대해 검증을 수행하는데 데이터 검증은 Schema 레이어에서만 수행하지 않는다.
데이터 검증은 Service 레이어에서도 수행하는데 두 계층에서 수행하는 검증은 무엇이 다른지 궁금했다.
결론부터 말하면 두 검증은 목적이 완전히 다르다.
Schema 검증 = 데이터 형식 검증 (Data Validation)
Service 검증 = 비즈니스 규칙 검증 (Business Validation)
Plain Text
복사
Schema 검증
Schema는 요청 데이터의 형식과 타입을 검증하는 역할을 한다. FastAPI에서는 Pydantic을 사용하여 schema를 정의한다.
예를 들어 다음과 같은 사용자 생성 요청 schema가 있다고 가정해보자.
class UserCreate(BaseModel):
name: str
email: EmailStr
age: int
Python
복사
그리고 클라이언트가 다음과 같은 요청을 보낸다.
{
"name": "James",
"email": "example@test.com",
"age": 20
}
JSON
복사
FastAPI는 이를 자동으로 검증한다.
위는 정상적인 데이터 형식의 요청이지만 만약 다음과 같은 요청이 들어온다면 FastAPI는 자동으로 에러를 반환한다.
{
"name": "James",
"email": "not-email",
"age": "twenty"
}
JSON
복사
이처럼 Schema는 데이터의 구조와 타입을 검증하는 역할을 한다. Schema에서 검증하는 대표적인 항목은 다음과 같다.
•
데이터 타입 검증
•
필수 필드 여부
•
이메일 형식
•
문자열 길이
•
숫자 범위
다시 말해 Schema는 요청 데이터가 올바른 형태인지 확인하는 역할을 한다.
Service 검증
Service는 비즈니스 규칙을 검증하는 역할을 한다.
예를 들어 사용자 생성 로직을 생각해 보자. 사용자를 생성할 때 다음과 같은 규칙이 있을 수 있다.
•
이메일은 중복될 수 없다.
•
나이는 18세 이상이어야 한다.
•
특정 도메인의 이메일만 허용한다.
이런 규칙은 데이터 형식 검증이 아니라 비즈니스 규칙 검증이다.
def create_user(db: Session, payload: UserCreate):
existing_user = repository.get_user_by_email(db, payload.email)
if existing_user:
raise HTTPException(status_code=400, detail="이미 존재하는 이메일입니다.")
if payload.age < 18:
raise HTTPException(status_code=400, detail="18세 이상만 가입 가능합니다.")
return repository.create_user(db, payload)
Python
복사
이처럼 Service에서는 도메인 규칙을 검증한다. Service에서 검증하는 대표적인 항목은 다음과 같다.
•
이메일 중복 검사
•
권한 검사
•
상태 변경 규칙
•
비즈니스 정책
즉, Service는 업무 규칙을 검증하는 역할을 한다.
차이점
구분 | Schema 검증 | Service 검증 |
목적 | 데이터 형식 검증 | 비즈니스 규칙 검증 |
위치 | API 계층 | 도메인 계층 |
사용 도구 | Pydantic | 커스텀 로직 |
예시 | 이메일 형식 검증 | 이메일 중복 검사 |
좀 더 자세하게 각 계층에서 검증하는 예시는 다음과 같다.
•
Schema 계층에서의 검증
◦
Email이 이메일 형식인가?
◦
Age가 숫자인가?
◦
Name이 존재하는가?
•
Service 계층에서의 검증
◦
이미 가입된 이메일인가?
◦
나이가 18세 이상인가?
◦
가입 가능한 사용자 상태인가?
검증을 두 단계로 나누는 이유
검증을 두 단계로 나누는 이유는 책임 분리(Separation of Concerns) 때문이다.
Schema는 데이터 형식에만 집중하고 Service는 비즈니스 규칙에 집중한다. 이렇게 역할을 분리하면 코드 가독성 향상, 유지보수 용이, 테스트 용이 등의 장점이 존재한다.
정리
FastAPI에서 Schema와 Service는 모두 데이터를 검증하지만 목적이 다르다.
Schema는 API 입력 데이터를 안전하게 만드는 역할을 하고, Service는 도메인 규칙을 적용하는 역할을 한다.
이 두 역할을 명확하게 분리하면 확장성과 유지보수성이 좋은 API 구조를 만들 수 있다.