개발시에 발생하는 DRF의 몇몇 문제점들

1. 서론

학교를 다니면서 Python으로 서버를 개발하면서 프로젝트를 적지만 몇 번 진행한 경험이 있다. 그때마다 난 DRF를 사용해 왔다.

사실 클라이언트와 서버를 동시에 개발하지 않는 이상 Django를 쓴다고 하면 보통 DRF를 사용한다는 걸 말하는 것 같다.

진행한 프로젝트들은 보통은 간단한 프로젝트이거나 MSA에선 Python이 사용되는 도메인의 크기가 크지 않아서 장고 프로젝트가 부담스럽게 커지진 않는 것 같다.

하지만 큰 프로젝트를 DRF로 개발하게 되면 몇 가지 문제가 생기는 것 같다.

 

2. DRF 프로젝트

Django 프로젝트는 App이라는 단위로 나누어진다. 

개인적으로 App으로 프로젝트가 구성되는 건 좋게 느껴진다. 기능별로 직관적으로 나눌 수 있고, 새로운 도메인이 추가되며 확장하는 경우엔 보통 App을 한 개 더 만들면 된다.

하지만 각각의 App을 유지보수하는 건 힘든 일인 것 같다. 물론 다른 프레임워크들을 DRF만큼의 숙련도? 를 갖고 있지 않아서 정확히 비교할 순 없지만 DRF 구조 자체에서 오는 불편함이 있는 걸 느낄 순 있다.

 

3. DRF로 개발 시에 생기는 문제점들

물론 내가 DRF를 평가할 건 안되지만 개발하면서 힘들었던 점들을 간단하게 정리해 보았다.

3-1. Django ORM

Django는 자체 ORM인 Django ORM을 사용한다. DRF도 그에 따라서 Django ORM을 사용한다.

Django ORM은 그냥 모델 클래스를 가져와서 쓸 수 있다. view, serializer 등 어디서든 그냥 쓸 수 있다.

어느 파일이든, 코드든 아무 곳에서나 ORM으로 쿼리를 날리니 복잡해질 수밖에 없는 것 같다. 

3-2. 비즈니스 로직

DRF는 view, serializer, model로 구성되어 있다. 명시적으로 나눠진 service 계층이 없다.

service 계층이 나누어져있지 않으니 비즈니스 로직이 담겨있을 자리는 크게 정해져 있지 않다. 이 때문에 사람마다 비즈니스 로직이 담겨있는 곳은 다 다르고 이 때문에 사람마다 프로젝트의 구조가 조금씩 다르다. 같은 프로젝트를 여러 명이 개발하게 되면 각각 App마다의 비즈니스 로직의 위치가 다를 때도 있다.

나는 그저 간단한 서비스로직을 보고 싶은데 view부터 model까지 숨겨져 있는 비즈니스 로직을 찾으러 다녀야 하는 문제가 발생한다.

3-4. 다른 아키텍처 적용의 어려움

DRF의 구조를 바꾸기 힘든 상태에선 당연히 다른 아키텍처 적용도 어려워진다. layered architecture를 적용하려고 해도 Django의 간극을 줄이기 위해서 고민을 해야 하고 심지어 이런 간극에 대한 블로그들도 많이 있다. 

DRF의 디자인을 지키면 필요 없긴 하지만 DI도 제대로 지원하지 않는다. 사실 DRF CBV는 둔갑한 함수형 프로그래밍인 것 같은 느낌도 든다.

3-5. 단일 책임 원칙 - 하나의 객체는 하나의 동작을 갖는다.

당장 serializer만 봐도 단일 책임 원칙이 지켜지지 않는다. OOP를 지켜 코드를 짠다면 serializer는 이름 그대로 직렬화의 역할만 해야 한다. 그런데도 DRF 공식 문서에서도 serializer에 비즈니스 로직을 넣게 코드가 작성되어 있다..

당연히 SRP가 지켜지지 않으니 유지보수는 어려워진다.

3-6. 개방 폐쇄 원칙 - 기존 코드를 변경하지 않으면서 기능확장이 가능해야한다.

view를 사용하게 되면 여러 기능 개발을 위해서 mixin이나 메서드들을 사용하게 되면서 상속에 의존하면서 서비스가 작동한다.

확장을 하려면 클래스 자체를 수정해야 하는 문제가 생길 수도 있다.

 

이런 문제들은 전체적으로 사이드이펙트가 예측이 힘들어진다. 즉 하나를 고쳤는데 다른 기능들이 멈추기 시작할 수도 있다.

 

이런 코드들은 차갑고 단단하게 식은 스파게티 뭉티기들을 접시 위에 모아둔 느낌을 들게 한다.

 

3. Django-Ninja

https://django-ninja.dev/

FastAPI를 닮으면서 Django ORM을 사용할 수 있는 프레임워크이다.

속도가 빠른 걸로 유명한 프레임워크이다.

serializer를 사용하지 않고 schema를 사용한다. 

타입힌트를 사용해서 안정적으로 프로그래밍할 수 있고, DRF에서 사용하기 힘든 swagger 문서도 자동으로 완성해 준다.

프레임워크도 자유로워서 여러 아키텍처도 적용할 수 있으며 django-ninja-extra를 사용하면 controller class와 di를 사용해서 프로그래밍을 할 수 있다.

개인적으로 공부하면서 현재 진행하는 프로젝트에 적용해볼 예정이다.

https://github.com/Jueuunn7/ninjango-board 

 

물론 Ninja가 무조건 좋은건 아니다. 레딧같은 커뮤니티만 가도 Ninja를 비선호 하시는 분들이 꽤 많이 계신다.

갠취향인것 같다. DRF물론 강력한 프레임워크인데 DRF에 회의감?이 느껴지시는 분들은 Ninja를 많이 좋아하실것 같다.