1인 개발자의 NestJS vs FastAPI 선택 기준, 분기선 3개

두 프레임워크를 같이 쓴다고 하면 "하나로 통일하지 왜"라는 말을 자주 들어요. 저도 처음엔 그러려고 했어요. 그런데 직접 만들어 보니 통일이 오히려 비용이었어요. 지금은 질문 3개로 분기선을 긋고, 나머지는 고민하지 않아요.

질문 1. 핵심 의존성이 어느 생태계에 있나

가장 먼저 보는 건 프레임워크가 아니라 라이브러리예요. AI 모델 호출, 임베딩, 데이터 전처리가 중심이면 파이썬 생태계를 벗어나기 어렵더라고요. 플랜티처럼 AI 모델을 붙이는 쪽은 그래서 FastAPI로 기울어요. 반대로 멤버·회비·출전 로테이션처럼 CRUD와 실시간 갱신이 대부분인 플랜비 같은 성격은 NestJS가 편해요. WebSocket 게이트웨이가 프레임워크 안에 있고, 프론트가 Next.js라 타입 정의를 그대로 나눠 쓸 수 있거든요.

CRUD·실시간(WebSocket) 중심 vs AI·데이터 처리 중심 — 핵심 의존성이 있는 생태계로 프레임워크를 고른다

질문 2. 타입 계약을 어디서 검증하나

NestJS는 DTO 클래스에 class-validator 데코레이터를 붙이면 요청 검증과 타입이 한 곳에 모여요. 프론트와 같은 TypeScript라 계약이 어긋나면 컴파일 단계에서 잡히고요. FastAPI는 Pydantic 모델이 OpenAPI 스키마를 만들어 주는데, 프론트가 TypeScript면 그 스키마를 zod로 다시 옮기는 단계가 하나 더 생겨요. 적용해 봤더니 이 왕복이 생각보다 자주 어긋났어요. 그래서 FastAPI 쪽은 응답 스키마를 바꿀 때 왕복 테스트를 같이 돌리는 걸 규칙으로 뒀어요.

질문 3. 동시성 모델이 워크로드와 맞나

Node는 이벤트 루프 하나로 I/O를 처리해요. DB 쿼리와 외부 API 대기가 대부분인 API 서버엔 잘 맞아요. 파이썬은 기본 빌드에서 GIL 때문에 CPU를 쓰는 작업을 한 프로세스 안에서 병렬로 못 돌려요. 그래서 FastAPI 쪽은 uvicorn 워커 수를 코어에 맞춰 띄우고, 무거운 계산은 요청 경로 밖으로 뺐어요. 테스트해 보면 이 차이는 단일 요청보다 부하 상황에서 크게 벌어져요.

둘 다 같은 걸 쓰는 부분

인증은 두 쪽 다 Supabase JWT를 서버에서 검증해요. NestJS는 Guard, FastAPI는 Depends로 붙여 보니 위치만 다르고 검증 로직은 같아요. DB도 Postgres 하나를 공유하고, 배포는 둘 다 Docker 이미지로 Railway에 올려요. 로컬에서 돌려 보니 기본 포트만 다른데, NestJS 스캐폴드는 3000번, uvicorn은 8000번이에요. 이 정도면 인프라 스크립트는 거의 공유돼요.

• ✓핵심 의존성 생태계
• ✓타입 계약 검증 위치
• ✓동시성 모델과 워크로드
• ✓인증
• ✓DB
• ✓배포는 공유

통일하지 않은 이유

뼈대 잡는 시간은 비슷했어요. nest new는 src 아래 파일 5개를 만들어 주고, FastAPI는 파일 1개로 시작해요. 둘 다 첫 엔드포인트까지 10분이면 충분했어요. 문제는 그 다음이에요. 파이썬 AI 라이브러리를 Node에서 흉내 내거나, TypeScript 타입 공유를 파이썬에서 흉내 내는 순간 유지비가 올라가요. 같은 회사 안에서도 플랜엘처럼 법령·판례 데이터를 월 3건 무료로 검색하게 열어 둔 서비스는 요청 수보다 데이터 적재 방식이 먼저 보여서 기준이 또 달라지고요.

결국 1인 개발에서 프레임워크 선택은 취향이 아니라 유지비 계산이에요. 질문 3개에 답이 나오면 그대로 가고, 답이 안 나오면 이미 굴리고 있는 쪽을 고르는 게 제 기준이에요.