초짜 파이썬 개발자가 서비스 만든 썰 푼다 -06-

외부 모듈(라이브러리)를 쓴다는 것의 의미

0. 이번 이야기를 풀기 전에 이 글을 시작하면서 올린 코드 구조를 다시 한번 소환해 보려한다.

거듭 말씀드리지만, 뭔가 기시감이 느껴진다면 정상입니다.

실질적인 API URL을 제공하는 부분인 Controllers와 비즈니스 로직을 담고 있는 Service로직은 각자 DTO라는 패키지를 갖고 있다.

애초 시스템 구조를 구상할때, Controller가 외부와 데이터를 교환할때는 Controller에 있는 DTO를 사용하고, 검증이후 Service와 데이터를 교환할때는 Service에 있는 DTO를 사용하게 하자 는것이 기본 구상이었다.

...그리고 이것이 또다른 삽질의 시작이었다.

1. 그럼 DTO는 어떻게 구현할것인가? 파이썬의 클래스를 잘 이해하지 못하던 시절, 그냥 다른 코드에서 하던대로 파이썬 안에 클래스를 선언해서 그걸 DTO로 삼기 시작했다.

하지만 이렇게 만들자니, Controller에서는 웹을 통해 받은 데이터 검증 코드가 산더미같이 늘어나기 시작했고 Controller와 Service간의 데이터 교환을 위한 복제 코드가 DTO 클래스 하나 추가될때마다 늘어나기 시작했다.

물론, 그러한 불편을 해소하기 위해 클래스의 멤버를 읽어들여 복제하는 코드를 만들었으나 이번엔 Controller DTO-> Service DTO -> ORM Model 로 갈때와 그 반대로 ORM Model -> Service DTO -> Controller DTO로 갈때의 복잡한 경우의 수가 지저분한 코드를 만들어 내기 시작했다.

뭔가 쎄하지 않은가. 

2. 사실, 애초부터 저런 코드들은 필요하지 않았다. FastAPI는 Pydantic을 지원한다. 그리고 Pydantic은 위의 고민들을 깔끔하게 해결해줄수 있는 라이브러리들을 이미 가지고 있었다. DTO <-> ORM Model 간 변환에쓸수 있는 model_validator가 있고, 클래스 인스턴스 생성이후 추가적인 필드를 만들기 위한 @computed_field 어노테이션이 있으며 데이터 검증을 위한 @field_validator가 있다.

한마디로, 잘 알고 썼으면 안했을 삽질에 또 시간을 낭비한 것이다.

그러게요.

3. 그래서, 결국 지금 모든 DTO는 Pydantic의 BaseModel을 상속시켜 만들고 있다. 직접 만들었던 매핑라이브러리는 볼때마다 이불킥을 부르는 추억의 파편으로 남아있긴 하지만.

그럼 이쯤 했음 어느정도 파이썬을 잘 쓰는 개발자가 되었을까? 그랬음 이 시리즈는 애초에 빛도 못봤을거여...