Pydantic

FastAPI에서 Data Model 클래스로 사용하고 있는 Pydantic 사용법에 대해 알아보자.

 

1 . Pydantic이란?

FastAPI에서 Class 사용 시 보이던 것이다.

Data Validation 혹은 Settings Management 라이브러리라고 보면 된다.

Type Hint를 런타임 시점에 강제하여 안전하게 데이터를 핸들링 할 수 있다.

 

파이썬 기본 타입인 String, int, 혹은 List, Dic, Tuple에 대한 Validation을 지원한다.

기존 Validation 라이브러리보다는 빠르다.

머신러닝 Feature Data Validation으로도 활용이 가능하다.

 

예를 들어 Feature A는 Int타입에 0 ~ 100 사이라고 지정했다고 가정하자.

만약 데이터가 들어오고 실행될 때, 데이터가 이 범위를 벗어나는 값이면 에러를 반환하게 된다.

즉, 잘못된 데이터가 들어왔을 때 체크할 수 있다는 장점이 있다.

 

 

2. Validation

'Machine Learning'이나 'Deep Learning', LLM 이나 모두 Data Validation을 체크하는게 필요할 때가 있다.

 

Machine Learning Model Input Validation의 예시를 보자면

Online Serving에서 FastAPI 통해서 요청하는데, 우리가 필요없는 데이터를 제공할 수 있고, 우리가 사람 연령을 Input Feature로 넣는다고 할 때, 나이가 7000살 1만살 이런 식으로 들어오는 것은 이상한 데이터다.

 

Validation Check Logic

(1) 올바른 URL을 입력받았는지 

(2) 1~10 사이의 정수 입력받았는지

(3) 올바른 폴더 이름을 입력받았는지

 

 

Validation을 할 때 사용할 수 있는 방법들은 다양하다.

그들 중 크게 3가지를 알아보자.

 

(1) 일반 Python Class를 활용

Python Class 사용하므로 input을 정의하고 Validation 로직을 추가해야 하므로 의미 없는 코드가 많아진다.

복잡한 검증 로직에는 Class Method가 복잡해지기 쉬울거다.

Exception Handling을 어떻게 할지, 어떻게 커스텀을 어떻게 할지가 어려워진다.

Input을 받아서 Inference를 수행하는 로직에 집중하기 어려워지고, 체크하는데 코드량이 더 늘어날 수 있다.

(2) Dataclass 를 활용 (python 3.7 이상 필요)

데코레이터를 사용하니 init method를 따로 작성할 필요가 없어진다.

그리고 post init 매직 메서드를 사용할 수 있다.

하지만 여전히 길어지는 검증 로직을 분리하기 위해 Validate method를 따로 만들어야 한다.

 

* Dataclass 활용 특징

인스턴스를 생성하는 시점에서 Validation을 수행하기 쉽다.

하지만 여전히 Validation 로직들을 직접 작성해야 한다.

Validation 로직을 따로 작성하지 않으면, 런타임에서 type checking을 지원하지 않는다.

 

 

(3) Pydantic 활용

훨씬 간결해진 코드

주로 사용하는 타입들(http url, db url, enum 등)에 대한 Validation이 만들어져 있다.

런타임에서 Type Hint 에 따라서 Validation Error 발생하기도 하고, Custom Type에 대한 Validation 도 쉽게 가능하다.

try except를 통해 에러가 발생하면 바로 나오도록 설정이 되어있다.

 

 

 

 

3. Config

기본 환경 설정이나 서버키를 저장하고 불러오기 할 때 사용 가능하다.

앱을 기동하기 위해 사용자가 설정해야 하는 config 정보가 있을 거다. DB정보 같은

보통 이런 Config들은 하나의 모듈이나 클래스로 관리해서, 사용자가 보기 쉽게 저장한다.

 

 

(1) Config 관리

Config 를 관리할 때 자주 사용하는 방법은 다음과 같다.

 

 

코드 내 상수로 관리

코드 내에서 아래처럼 상수로 관리하는 방법이다.

가장 간단하지만 보안(Secret)들이 그대로 노출되는 이슈가 있을 수 있다.

배포 환경(보통 개발과 운영을 분리)에 따라 값을 다르게 줄 수 없다.

- 환경에 따라 DB 주소가 다른데 배포할 때 코드를 자주 변경할 수 없어서 정보 변경에 어려움이 있다.

- 때문에 코드랑 config 정리를 분리해서 관리하는 것이 필요하다. 

- 보안 정보가 아닌 값들을 다루거나 테스트 같이 임시 환경에서만 적합하다.

 

yaml 등과 같은 파일로 관리

별도의 파일에서 관리 후, 실행할 때 파일을 지정해서 Config 클래스에 주입하는 방법

- 배포 환경 별로 다른 yaml 파일을 생성할 수 있다.

- 하지만 보안 정보가 여전히 파일에 노출되므로, 배포 환경 별로 파일이 노출되지 않게 관리가 필요하다.

 

yaml 같은 걸 만들더라도 깃허브에 올리지 않고 클라우드 서비스에서 주입이 되도록 설정하고는 한다.

 

 

환경 변수 (Pydantic.BaseSettings)로 관리

환경 변수에 설정 값을 저장한 뒤, 코드에서는 그 환경 변수를 읽어오는 방법을 많이 쓴다.

 

Validation처럼 Pydantic은 BaseSettings를 상속한 클래스에서 Type Hint로 주입된 설정 데이터를 검증할 수 있다.

 

Field 클래스의 env 인자 : 환경변수를 해당 필드로 오버라이딩 하겠다는 의미다.

yaml이나 ini 파일들을 추가적으로 만들지 않고, '.env'파일들을 환경별로 만들어두거나, 실행환경에서 유연하게 오버라이딩 할 수 있다.

 

따라서 '.env_example' 과 같은 파일들을 깃허브에 많이 올린다.

 

환경 변수는 배포할 때 주입하고, 파일에는 보안 정보가 노출되지 않도록 한다.