[ API ] Django 비동기 ADRF 적용하기!

---

 

지난번 큐를 도입한 API 처리에서도 한계점이 명확했다.
큐를 이용하면 처리 지연을 줄이긴 했지만, 결국 API는 동기로 동작하고 있었고, 큐 작업을 넘기기까지의 지연도 무시할 수 없었다.

그래서 이번엔 동기로 동작하는 API를 비동기로 전환해 보기로 결정했다.

 

---

Django에서 비동기? sync_to_async vs ADRF

 

Django에서도 sync_to_async 같은 유틸을 통해 비동기 처리를 시도할 수 있지만, 한계가 명확하다.
찾아보니까 ADRF라는 비동기 View를 위한 라이브러리가 있길래 도입해보았다.

ADRF는 기존 DRF 문법을 그대로 활용할 수 있으면서도, async def 기반으로 View를 작성할 수 있도록 도와준다.

 

########## app.py ##########
from adrf.views import APIView
from rest_framework.response import Response
import asyncio

class MyAsyncView(APIView):
    async def get(self, request):
        await asyncio.sleep(1)
        return Response({"message": "Hello from async view!"})
        
        
        
########## urls.py ##########
from django.urls import path
from .views import MyAsyncView

urlpatterns = [
    path("async-hello/", MyAsyncView.as_view()),
    ]

---

ADRF 와 큐로 성능 향상 시키기

 

ADRF를 도입하고 나서, 기존에 큐만 사용했을 때보다 약 30~50% 정도의 처리 시간이 단축되었다.

예를 들어,

 

큐만 사용했을 때 OCR 평균 처리 시간: 약 25초

 

ADRF + 큐 사용 후 OCR 평균 처리 시간: 약 9~12초

 

단순한 구조였지만, 비동기로 바꾸는 것만으로도 이렇게 체감할 수 있는 변화가 있는 건 꽤 인상적이었다.

 

---

그런데... 굳이?? 이렇게까지??

 

ADRF도 좋은 도구였지만, 결국 이렇게까지 할 바엔 FastAPI로 옮기는 게 더 낫지 않을까? 하는 생각이 들었다.
FastAPI는 처음부터 비동기를 고려한 구조이기도 하고,
라우팅이나 문서화, 성능 측면에서도 꽤 매력적인 선택지였다.

게다가, 이번 경험을 통해
굳이 모든 걸 Django에서 처리하려는 집착이 꼭 좋은 건 아니었다는 걸 느꼈다.

 

---

MSA 관점에서 프레임워크 혼용

 

이번 프로젝트를 진행하면서 "처음부터 MSA를 고려해서 각 역할에 맞는 프레임워크를 선택했으면 어땠을까?"라는 생각이 들었다.

 

관리 UI, 인증, 어드민 등은 Django, 데이터 병렬 처리, 고성능 API는 FastAPI로 

 

프레임워크를 상황에 맞게 적절히 혼용하는 전략이 오히려 더 유지보수성과 성능을 챙기는 방법이었을지도 모르겠다.

 

---

 

늘 “다양한 관점에서 생각하자”라고 말은 했지만,
프로젝트에 깊이 들어가다 보면 어느새 기존 선택에 매몰되어 시야가 좁아지곤 한다.

 

이번 경험은 한발 물러나서 전체 구조를 보고
기술을 ‘도구’로 유연하게 선택하는 사고 방식을 다시 생각하게 만들어주었다.

 

앞으로는 다음과 같은 기준을 세워볼 생각이다:

 

비동기 처리와 성능이 핵심일 경우 → FastAPI 고려

관리 도구 및 ORM, 인증 등이 중요할 경우 → Django 유지

 

전체 아키텍처는 MSA로 유연하게 분리

 

---

마무리

각 기술의 장단점을 명확히 이해하고 유연하게 적용하는 태도가 훨씬 중요하다는 걸 다시 한 번 느낀 경험이었다.

하지만 굳이 비동기를 저렇게 라이브러리를 도입해서 할 바엔, Fastapi를 도입해서 진행하는게 더 효율적으로 보였다.

---