Django(Python)와 Node.js/NestJS, 뭐가 다를까 — 스택 전환을 고민하다 미룬 이유

두 줄 요약

사내 협업 도구를 다른 개발자와 통합하는 문제로 "지금 만들고 있는 프로젝트를 Node.js/NestJS로 통째로 리팩토링할까?"를 고민했다. 결론은 "지금은 완성이 먼저, 스택 통일은 나중에"였고, 그 판단 근거가 됐던 두 스택의 차이를 정리해둔다.

배경

혼자서 Django + MariaDB로 개발해온 사내용 프로그램이 있다. 그런데 다른 개발자가 별도 서버에서 Node.js/NestJS + PostgreSQL 기반의 사내 협업 플랫폼을 만들고 있고, 언젠가 두 시스템을 합치게 될 가능성이 있다. 그렇다면 "나중에 다시 짤 바엔 지금부터 NestJS로 맞춰서 가는 게 낫지 않나?" 하는 생각이 자연스럽게 들었다.

하지만 지금 당장 다른 언어·프레임워크로 갈아타기보다는, 진행 중인 프로젝트를 Django로 완성하는 쪽을 택했다. 그 판단에 깔린 두 스택의 차이를 짚어본다.

언어와 타입 시스템

• Django: Python. 동적 타입, 문법이 익숙하면 바로 로직에 집중할 수 있다.
• NestJS: TypeScript. 정적 타입 덕분에 대규모 협업에서 실수를 컴파일 단계에서 잡아주지만, 처음 접하면 타입 정의 자체가 진입장벽이 된다.

이미 Python 문법에 익숙한 상태에서 Django로 계속 개발하면 "웹 프레임워크"만 새로 익히면 되지만, NestJS로 넘어가면 언어(TypeScript)와 프레임워크(NestJS)와 ORM(TypeORM/Prisma)을 동시에 배우면서 실무 기능까지 구현해야 한다. 학습 곡선의 기울기 자체가 다르다.

프레임워크 철학

• Django: "배터리 포함(batteries included)" 철학. ORM, 어드민, 인증, 폼 처리가 기본 내장돼 있어 빠르게 뼈대를 세울 수 있다.
• NestJS: Angular에서 영향을 받은 구조로, 모듈·컨트롤러·프로바이더 단위로 강제되는 아키텍처가 있다. 처음엔 보일러플레이트가 많게 느껴지지만, 팀 규모가 커질수록 구조의 일관성이 유지된다는 장점이 있다.

즉 혼자 빠르게 기능을 완성해야 하는 상황에는 Django 쪽이 유리하고, 여러 명이 같은 코드베이스를 오래 유지보수해야 하는 상황에는 NestJS의 강제된 구조가 유리해지는 쪽이다.

ORM과 데이터베이스

• Django ORM + MariaDB: 이미 스키마 설계와 마이그레이션 이력이 전부 이 조합으로 쌓여 있다. 지금 와서 PostgreSQL + TypeORM/Prisma로 옮기면 스키마 자체는 재사용 가능해도, 마이그레이션 이력과 쿼리 최적화 경험(select_related/prefetch_related 같은 것)은 처음부터 다시 쌓아야 한다.
• NestJS + TypeORM/Prisma + PostgreSQL: 협업 중인 다른 시스템이 이미 이 조합을 쓰고 있어서, 나중에 통합할 때는 언어 장벽이 사라진다는 이점이 있다.

지금 상황에 대입해보면

몇 가지 현실적인 변수를 같이 놓고 봤다.

1. 진행 상황: DB 설계나 데이터 이관 같은 초기 단계가 아니라, 이미 v2.1까지 배포해서 실무에서 쓰고 있는 상태였고 지금은 v3.0을 설계·구축하는 단계였다. 언어를 바꾸면 스키마 설계 같은 일부 자산은 재사용해도, 이미 돌아가고 있는 시스템 전체를 처음부터 다시 짜야 한다.
2. 일정 리스크: "완성해서 인수인계하고 다음 단계로 넘어가자"가 목표인데, 처음 써보는 스택으로 가면 완성 시점을 예측하기 어려워진다. 급한 실무 기능이 학습 곡선 때문에 밀릴 위험이 있다.
3. 협업 이점: 스택을 맞추면 나중에 통합할 때 언어 장벽이 없어지고, NestJS 학습 자체가 커리어에도 도움이 된다.
4. 범위: 지금 다루는 화면 수가 크지 않아서, 배우면서 만들어도 감당 못 할 규모는 아니다.

3, 4번은 지금 당장 전환해도 되는 이유였지만, 1, 2번이 더 크게 다가왔다. 결국 지금 진행 중인 부분은 Django로 완성하고, 스택 전환은 나중에 통합 시점에 한 번에 판단하는 쪽으로 정리했다. 두 마리 토끼(완성 + 새 스택 학습)를 한 번에 잡으려다 둘 다 시간에 쫓기는 상황을 피하고 싶었다.

그 외에 고려할 수 있는 다른 언어/프레임워크

사내 B2B 관리 도구 같은 걸 만들 때 후보가 Django/NestJS만 있는 건 아니다. 참고로 짚어본 다른 선택지들.

• Ruby on Rails: Django처럼 "배터리 포함" 철학이 강하고, 컨벤션이 더 강제적이다. CRUD 중심 사내 도구에는 잘 맞지만 국내 채용 시장이 상대적으로 작다.
• Laravel (PHP): ORM·인증·큐가 기본 내장돼 있고 한국어 학습 자료가 많다. 국내 SI/사내 시스템 쪽에 여전히 수요가 있다.
• Spring Boot (Java/Kotlin): 타입 안정성과 구조 강제력이 가장 강해 대규모 팀 협업에 최적화돼 있다. 반대로 보일러플레이트가 커서 혼자 빠르게 MVP를 만들기엔 부적합하다.
• FastAPI (Python): Django와 같은 언어라 학습 곡선은 낮지만, ORM/인증/어드민을 직접 조합해야 한다. API 서버 중심이라 NestJS와 비슷한 포지션.
• Go (Gin/Echo 등): 성능과 단일 바이너리 배포가 강점이지만, 웹 프레임워크 생태계가 Django/Rails만큼 다 갖춰져 있지 않다.

1인 개발 + 사내 인프라 + 커리어 전환이라는 지금 조건에 대입하면, 실질적인 후보는 이미 다룬 Django/NestJS와 FastAPI 정도이고 나머지는 "이 상황"보다 "이 분야 채용 시장에서 얼마나 쓰이는가"로 우선순위가 갈리는 선택지에 가깝다.

정리

기준 Django (Python) NestJS (TypeScript)

학습 곡선	완만 (기존 Python 지식 재사용)	가파름 (언어+프레임워크+ORM 동시 학습)
개발 속도 (혼자, 단기)	빠름	상대적으로 느림
구조 강제성	약함 (자유도 높음)	강함 (모듈 구조 강제)
협업/유지보수 (팀, 장기)	컨벤션에 의존	타입+구조로 일관성 확보
지금 상황과의 궁합	이미 쌓인 자산 재사용 가능	동료 스택과 통일, 향후 통합 용이

지금은 Django로 마무리하고, 실제로 통합 논의가 구체화되면 그때 NestJS 학습을 겸해 리팩토링하는 방향으로 갈 계획이다. 그 시점에 마이그레이션 자체를 별도 글로 남겨두면 두 스택을 실제로 비교한 기록이 될 것 같다.