🚀 [Project] AI 내 직원 만들기: Django와 FastAPI의 하이브리드 동거

🏗️ 왜 'Django + FastAPI' 하이브리드인가?

TradeNPU는 이미 15개가 넘는 앱이 돌아가는 거대한 Django 성곽입니다. 여기에 실시간 LLM 통신이 빈번한 AI 직원(MCP 서버) 기능을 그대로 얹기에는 몇 가지 우려가 있었습니다.

• 동기(Sync) vs 비동기(Async): Django는 기본적으로 동기 방식입니다. 관리자 전용 API라면 문제가 없지만, 다수의 사용자가 동시에 AI를 호출하면 I/O 병목현상이 발생할 수 있습니다.

• 서버 혹사 방지: 무거운 Django 서버가 LLM의 긴 응답 시간을 기다리느라 리소스를 점유하게 두는 것보다, 비동기에 최적화된 FastAPI에게 이 역할을 맡기는 것이 훨씬 경제적입니다.

처음에는 새로운 프레임워크가 낯설었지만, "Django를 안다면 FastAPI는 식은 죽 먹기"라는 조언대로 단 30분 만에 기본 세팅을 마칠 수 있었습니다. 파이썬 생태계의 유사성 덕분에 비동기 서버의 세계로 빠르게 발을 들였죠.

---

 

🛠️ 트러블슈팅: Django의 유산을 FastAPI로 가져오기

FastAPI에서 기존 Django의 모델(DB)을 그대로 쓰려니 예상치 못한 에러들이 터져 나왔습니다. 이를 해결하기 위해 적용한 두 가지 핵심 팁을 공유합니다.

1. 전용 settings_fastapi.py 생성: FastAPI가 Django의 settings.py를 통째로 로드하면 불필요한 앱과 미들웨어까지 모두 불러오려다 에러가 발생합니다. 필요한 앱(INSTALLED_APPS)만 남긴 경량화된 설정 파일을 별도로 만들어 연결하는 것이 포인트입니다.

2. 정확한 경로 지정: FastAPI가 Django 모델에 접근할 수 있도록 apps.py의 name을 프로젝트명까지 포함한 전체 경로(예: MyProject.CS)로 수정해야 모듈 인식 오류를 피할 수 있습니다.

---

 

⚠️ 현실적인 벽: ASGI 배포와 WSGI의 생존 전략

개발 서버에서는 완벽했던 비동기 환경이 라이브 서버 배포 단계에서 제동이 걸렸습니다. 현재 호스팅사가 ASGI를 '실험적'으로만 지원하고 있었기 때문입니다. 트래픽 신기록을 경신 중인 TradeNPU에게 서버 셧다운은 있을 수 없는 일이었죠.

여기서 찾은 우회 전략은 다음과 같습니다.

• WSGI에서 스트리밍 구현: Django의 StreamingHttpResponse를 활용하되, 서버 측 버퍼링 설정을 코드 단에서 제어하여 비동기식 표현(Streaming)을 성공시켰습니다.

• DRF를 이용한 데이터 가교: FastAPI 서버가 외부 호스팅에 위치할 경우 DB 직접 연결은 보안 및 스키마 관리에 리스크가 있습니다. 대신 Django 쪽에서 DRF(Django REST Framework)로 CRUD API를 열어주고, FastAPI(MCP 서버)가 이를 호출하는 방식을 선택했습니다.

---

 

🧭 마치며: 다시 MCP의 궤도로

아키텍처 고민 때문에 잠시 샛길로 샜지만, 결과적으로 '안전한 데이터 접근(DRF)'과 '유연한 비동기 처리(FastAPI)'라는 두 마리 토끼를 잡을 준비를 마쳤습니다.

이제 인프라 고민은 뒤로하고, 본격적으로 AI 직원에게 일을 시키기 위한 MCP 코딩에 들어갑니다. 과연 이 하이브리드 구조 위에서 AI 직원이 얼마나 기민하게 움직여줄지, 다음 기록에서 계속하겠습니다.

 

---

💡 안내: 이 포스팅은 기존 네이버 블로그의 5, 6회차 연재분을 통합하여 재구성했습니다. 거대해진 레거시 서버(Django)와 유연한 비동기 서버(FastAPI)를 어떻게 연결하고, 배포 환경의 제약을 어떻게 극복했는지에 대한 기록입니다.

---

---

---