파이썬 웹 프레임워크 완전 비교 — FastAPI · Django · Flask 선택 기준 3가지

서비스를 만들겠다고 마음먹은 순간, 가장 먼저 막히는 질문이 있다.

“파이썬 웹 프레임워크, 뭘 써야 하지?”

FastAPI, Django, Flask. 셋 다 파이썬으로 서버를 만드는 도구다. 그런데 검색해보면 “FastAPI가 빠르다”, “Django는 강력하다”, “Flask는 가볍다”는 말만 나오고, 정작 내 상황에서 뭘 써야 하는지는 아무도 말해주지 않는다.

이 글에서는 파이썬 웹 프레임워크 3가지의 구조적 차이와 선택 기준을 정리한다. 거기에 프론트엔드 기술 흐름, 한국 개발 생태계의 특수성, 그리고 서비스를 만드는 사람이 가져야 할 가장 본질적인 태도까지 함께 다룬다.

파이썬 웹 프레임워크란 무엇인가

서버는 단순하다. 요청을 받아서 함수를 돌리고 응답을 돌려준다. 이게 전부다.

문제는 그 과정에서 처리해야 할 것들이 많다는 것이다. URL 라우팅, 요청 파싱, 응답 직렬화, 에러 핸들링, 데이터베이스 연결… 이런 것들을 매번 처음부터 짜면 시간이 너무 많이 걸린다. 파이썬 웹 프레임워크는 이 반복 작업을 자동화해주는 도구다. 개발자는 비즈니스 로직, 즉 “어떤 함수를 어떤 조건에서 실행할 것인가”에만 집중할 수 있게 된다.

세 프레임워크 모두 같은 역할을 한다. 차이는 그 역할을 어떤 방식으로, 어느 수준까지 자동화하느냐에 있다.

FastAPI · Django · Flask — 3가지 차이를 한 번에 잡는 법

웹 프레임워크를 고를 때 기준이 되는 3가지는 성능, 자유도, 구조다.

FastAPI — 빠르게 만들고 싶을 때

FastAPI는 기본 설정 기준으로 셋 중 가장 빠른 웹 프레임워크다. 파이썬 파일 하나에 서버 전체를 자유롭게 구성할 수 있다. 빠르게 API 서버를 만들어야 할 때, 구조보다 속도가 우선일 때 선택하면 된다.

단점도 있다. 네트워크 관련 설정을 내가 직접 건드릴 수 없다. FastAPI 개발자가 정해놓은 기본값을 그대로 따라야 한다. 자유도가 낮은 만큼, 특정 상황에서는 최적화에 한계가 생긴다.

Django — 구조가 필요한 서비스에

Django는 코드 작성 규칙이 가장 엄격한 웹 프레임워크다. 어느 파일에 무엇을 써야 하는지 다 정해져 있다. 뷰는 views.py, URL은 urls.py, 데이터 모델은 models.py. 규칙에서 벗어나는 순간 Django가 정해놓은 구조가 깨진다.

대신 네트워크 설정까지 직접 건드릴 수 있다. 고수가 다루면 FastAPI보다 더 빠질 수 있다. 팀이 크고 유지보수가 길게 이어지는 서비스라면 Django의 엄격한 구조가 오히려 자산이 된다.

웹 프레임워크의 본질이 궁금하다면, Django의 IoC 구조와 MTV 패턴을 정리한 글을 먼저 읽어두면 이 비교가 더 선명하게 들어온다.

Flask — 단순하게 띄우고 싶을 때

Flask는 셋 중 가장 오래된 웹 프레임워크다. 2005년 전후 등장한 Django보다도 레거시 코드베이스가 넓게 퍼져 있다. 기본 성능은 가장 느리지만, 가볍고 진입 장벽이 낮다. 이미 Flask로 만들어진 서버가 있는 환경에서는 유지보수 관점에서 Flask를 계속 쓰는 게 자연스럽다.

파이썬만으로 앱을 만들 때 — Streamlit의 자리

파이썬 웹 프레임워크와 함께 알아두면 유용한 도구가 있다. Streamlit이다.

HTML, CSS, JavaScript를 모르는 상태에서 파이썬 코드만으로 화면이 있는 애플리케이션을 만들고 싶을 때 쓴다. 엑셀 매크로로 돌리던 계산 로직을 웹 화면에 올려야 할 때, 측정 데이터를 정리해서 그래프로 바로 보여줘야 할 때 빠르게 쓸 수 있다.

단, Streamlit으로 만든 앱은 디자인 자유도가 낮다. 색깔, 레이아웃, 스타일을 내 마음대로 바꾸는 데 한계가 있다. 그게 문제 되지 않는 상황, 즉 로직이 정확하면 되고 디자인 요구사항이 없는 내부 도구라면 웹 프레임워크보다 Streamlit이 훨씬 빠르다.

바이브 코딩과 Streamlit을 조합하면 엔지니어 혼자서도 실무 도구를 빠르게 만들어낼 수 있다.

한국에서 Java/Spring이 표준인 이유

이 세 프레임워크를 공부하다 보면 자연스럽게 다른 언어 생태계도 눈에 들어온다.

전 세계 웹 개발 표준은 JavaScript다. 그런데 한국만 유독 Java + Spring이 사실상 표준처럼 통용된다. 이유가 있다.

전자정부 프레임워크. 2000년대 초반, 정부는 모든 공공기관과 정부 납품 업체가 반드시 Java를 써야 한다고 시행령으로 못 박았다. 은행, 공공기관, 정부 연관 사업 모두 포함이다. 당시 Java는 가장 최신의, 가장 검증된 언어였다. 그 선택이 20년이 지난 지금도 바뀌지 않았다. 레거시 코드가 이미 방대하게 쌓였기 때문이다.

결과적으로 한국 개발자 시장에서는 Java + Spring을 모르면 선택지가 좁아진다. 전문 개발자로 이직을 고려하고 있다면 Java와 Spring은 결국 한 번은 마주하게 된다.

파이썬이 데이터 사이언스의 표준이라면, Java는 한국 공공·금융 서비스의 표준이다. 둘은 서로를 대체하지 않는다. 용도가 다르다.

프론트엔드 기술 흐름 — 브라우저가 이해하는 언어는 3가지뿐

서버(백엔드)를 파이썬으로 만든다면, 화면(프론트엔드)은 어떻게 만드는가?

브라우저가 이해하는 언어는 3가지뿐이다. HTML, CSS, JavaScript. 파이썬은 브라우저가 직접 읽지 못한다. Streamlit이나 FastAPI 같은 도구도 내부적으로는 파이썬 코드를 이 3가지로 번역해서 브라우저에 전달하고 있다.

전통적인 프론트엔드 개발은 이 3가지를 각각 다뤄야 했다. HTML로 구조를 잡고, CSS로 스타일을 입히고, JavaScript로 동작을 추가하는 방식이다. 2010년 Facebook이 React를 발표하면서 흐름이 달라졌다.

React의 핵심 아이디어는 단순하다. JavaScript 하나로 HTML과 CSS의 역할까지 통합하자는 것이다. 빈 HTML 파일 하나를 두고, JavaScript가 화면의 모든 요소를 동적으로 구성하고 제어한다. 언어를 하나로 통일하면 개발자가 여러 언어를 오가지 않아도 된다는 장점이 있다.

현재 프론트엔드 개발자의 80~90%가 React를 채택하고 있다. 웹 개발 생태계에서 JavaScript 기반 튜토리얼이 압도적으로 많은 이유가 여기 있다.

파이썬 엔지니어 입장에서 현실적인 조언을 하자면, 화면이 필요한 내부 도구는 Streamlit으로 빠르게 해결하고, 본격적인 프론트엔드가 필요한 상황이 생기면 그때 HTML·CSS·JavaScript 순서로 진입하는 게 자연스럽다.

서비스를 만든다는 것 — 수집 · 가공 · 제공

여러 프로젝트에서 웹 프레임워크를 바꿔가며 서비스를 만들어보면, 결국 기술보다 먼저 남는 사고 틀이 하나 있다. 이걸 배우는 목적은 결국 하나다. 누군가에게 쓸모 있는 무언가를 만드는 것.

그 과정을 내가 실제로 쓰는 방식으로 단순하게 정리하면 3가지다.

수집 → 가공 → 제공

어떤 서비스를 만들어달라는 요청이 들어왔을 때, 머릿속에 바로 이 3가지가 떠올라야 한다.

• 데이터를 어디서 어떻게 가져올 것인가 (수집)
• 가져온 데이터를 어떻게 처리하고 정리할 것인가 (가공)
• 처리된 결과를 어떤 형태로 전달할 것인가 (제공)

기술 스택을 늘리고 싶다면 이 3가지 각각을 확장해 나가면 된다. 수집의 방법을 다양화하고, 제공의 방식을 넓히고, 가공의 정확도를 높이는 것이다. 가공은 사실 짬밥이다. 경험이 쌓일수록 정교해진다.

고객을 중심에 두는 피드백 루프

기술보다 더 중요한 게 있다. 만든 것을 받는 사람이 누구인가를 정확히 이해하는 것이다.

고객은 상사일 수도 있고, 동료일 수도 있고, 후배일 수도 있고, 현장 오퍼레이터일 수도 있다. 직책이나 역할보다 중요한 건, 그 사람이 지금 어떤 문제를 안고 있는가다.

문제를 정확히 이해했다 해도 완벽하게 구현하기는 어렵다. 말을 전달하는 과정에서 오해가 생기고, 내가 받아들인 것과 상대가 의도한 것 사이에 언제나 간격이 있다.

그래서 유효한 방법은 하나다. 빠르게 만들어서, 빠르게 전달하고, 빠르게 피드백을 받는 것. 한 번에 완벽하게 만들려는 것보다, 짧은 사이클로 여러 번 수정하는 쪽이 결과적으로 더 정확한 결과물을 만들어낸다.

API 설계를 이 관점에서 보면, URL 구조 하나, 응답 형식 하나도 결국 고객이 어떻게 사용할지를 기준으로 결정되어야 한다는 게 자연스럽게 이해된다.

마무리 — 파이썬 웹 프레임워크, 어떻게 선택할 것인가

웹 프레임워크의 선택 기준은 결국 3가지로 요약된다.

화면이 필요한 내부 도구라면, 웹 프레임워크 이전에 Streamlit을 먼저 검토하는 것이 더 현실적인 선택일 수 있다.

기술 스택을 쌓는 것보다 더 앞에 있는 것은, 지금 만들려는 것이 누구의 문제를 해결하는가를 묻는 것이다. 그 질문이 명확할 때, 웹 프레임워크 선택도 자연스럽게 따라온다. 각 프레임워크의 공식 문서와 생태계는 Python.org에서 확인할 수 있다.

함께 읽으면 좋은 글

프레임워크를 골랐다면, 다음 질문은 “그 서버를 어디에, 어떻게 올릴 것인가”다.

• 가상환경 설정이 웹서비스 개발 첫날에 필요한 3가지 이유 — venv + Django 입문 가이드

웹 서비스를 만드는 목적이 내부 데이터 처리라면, 이 글도 이어서 읽어보길 권한다.

• 재귀적 분석이란 — AI가 내 코드를 읽을 때 실제로 벌어지는 3가지 일

FAQ