웹 프레임워크란 무엇인가 — Django로 이해하는 3가지 핵심 구조

웹 프레임워크는 웹 서비스를 만들 때 반복되는 구조와 규칙을 미리 만들어둔 뼈대다. 매번 바닥부터 짓지 않아도 되는 이유가 여기 있다. Django는 그 웹 프레임워크 중에서도 가장 직관적으로 개념을 드러내는 도구다. 이 글에서는 웹 프레임워크가 왜 필요한지, Django가 그 개념을 어떻게 구현하는지를 3가지 구조로 풀어본다.

웹 프레임워크를 처음 접하는 사람이라면 “그냥 코드 모음 아닌가?”라고 생각하기 쉽다. 하지만 프레임워크는 단순한 코드 모음이 아니다. 규칙이 있고, 흐름이 있고, 내 코드가 어디에 들어가야 하는지 이미 정해져 있다. Django를 통해 그 구조를 직접 확인해보자.

웹 프레임워크란 무엇인가 — 뼈대가 있어야 집을 짓는다

집을 지을 때 콘크리트 배합법부터 직접 연구하는 사람은 없다. 골조가 먼저 세워지고, 그 안에서 방을 배치하고 마감재를 고른다. 웹 프레임워크도 같은 원리다.

웹 서비스를 만들려면 공통으로 필요한 것들이 있다. 브라우저 요청을 받아서 처리하는 구조, 데이터베이스와 연결하는 방법, 화면을 만들어 돌려보내는 흐름. 이걸 매번 처음부터 만들면 시간이 너무 오래 걸린다. 웹 프레임워크는 이 반복 작업을 미리 구조화해둔 것이다.

웹 프레임워크를 쓴다는 건, 검증된 골조 위에서 작업한다는 뜻이다. 보안, 성능, 구조 설계의 기본은 이미 해결되어 있다.

라이브러리와 웹 프레임워크는 뭐가 다른가

웹 프레임워크를 처음 배울 때 가장 많이 헷갈리는 지점이 여기다. 라이브러리도 코드를 가져다 쓰는 건데, 뭐가 다른가.

핵심 차이는 주도권이다.

라이브러리는 내가 필요할 때 꺼내 쓴다. NumPy로 배열 계산이 필요할 때 import numpy를 쓰고, 필요 없으면 안 쓴다. 내가 언제 어디서 쓸지 결정한다.

웹 프레임워크는 반대다. 프레임워크가 흐름을 잡고, 내 코드를 적절한 시점에 호출한다. Django를 예로 들면, 브라우저 요청이 들어왔을 때 urls.py → views.py → template 순서로 흐름이 이미 정해져 있다. 내가 그 흐름을 바꿀 수 없다. 정해진 자리에 내 코드를 채워 넣는 방식이다.

이걸 IoC(제어의 역전, Inversion of Control) 라고 부른다. 제어권이 나에게 있지 않고, 프레임워크에 있다는 뜻이다.

웹 프레임워크를 쓴다는 건 그 규칙에 동의한다는 뜻이다. 규칙이 답답하게 느껴질 수 있지만, 그 규칙 덕분에 팀원이 바뀌어도 코드 구조가 일관하게 유지된다.

Django가 웹 프레임워크를 설명하기 좋은 3가지 이유

웹 프레임워크는 Django 말고도 많다. FastAPI, Flask, Spring, Rails. 그런데 웹 프레임워크의 개념을 처음 이해하는 데는 Django가 특히 유리하다. 이유가 3가지 있다.

첫째, 구조가 명시적이다. Django는 파일과 역할이 명확하게 나뉜다. urls.py는 요청을 받고, views.py는 처리하고, templates는 화면을 만든다. 어디에 무엇을 써야 하는지 헷갈릴 여지가 적다.

둘째, 기능이 내장되어 있다. Django는 “배터리 포함(Batteries Included)” 철학으로 설계됐다. DB 연결, 관리자 페이지, 인증, 폼 처리가 기본으로 들어있다. 웹 서비스에 필요한 것들이 뭔지 Django 구조를 보면 한눈에 파악된다.

셋째, 패턴이 표준화되어 있다. Django는 MTV 패턴이라는 명확한 설계 원칙을 따른다. 이 패턴을 이해하면 다른 웹 프레임워크의 구조도 같은 눈으로 읽을 수 있게 된다.

Django의 구조 — MTV 패턴으로 보는 웹 프레임워크의 실체

Django의 핵심은 MTV 패턴이다. Model, Template, View — 세 가지 역할이 명확하게 분리되어 있다.

일반적으로 알려진 MVC 패턴(Model-View-Controller)과 이름만 다르고 역할은 같다. Django가 View 대신 Template, Controller 대신 View라는 이름을 쓸 뿐이다.

브라우저에서 요청이 들어오면 Django는 이 순서로 처리한다.

1. urls.py — 요청 URL을 보고 어떤 View로 보낼지 결정한다
2. views.py — 비즈니스 로직을 실행하고, 필요하면 Model에서 데이터를 꺼낸다
3. Model — DB와 연결해서 데이터를 가져오거나 저장한다
4. Template — 데이터를 HTML에 담아 브라우저로 돌려보낸다

이 흐름이 웹 프레임워크가 하는 일의 전부다. 요청을 받고 → 처리하고 → 응답을 돌려보낸다. Django는 이 흐름을 파일 단위로 명확하게 구분해두었다.

가상환경 설정부터 시작해서 Django를 직접 설치해보면, 이 파일 구조가 자동으로 생성되는 것을 확인할 수 있다.

Django의 또 다른 강점은 ORM(Object Relational Mapping) 이다. SQL을 직접 쓰지 않고 Python 코드로 DB를 다룰 수 있다.

# SQL 대신 이렇게
Post.objects.filter(category="AI").order_by("-created_at")

웹 프레임워크가 DB 연결까지 추상화해준다는 게 이 코드 한 줄에 담겨 있다. 이미 ORM의 핵심 원리를 다룬 포스팅이 있으니 참고해도 좋다.

웹 프레임워크를 고르는 3가지 기준

웹 프레임워크는 Django만 있는 게 아니다. 상황에 따라 다른 선택이 맞을 수 있다. 고르는 기준 3가지를 정리했다.

첫째, 무엇을 만드는가. API만 필요하다면 FastAPI가 더 가볍고 빠르다. 관리자 페이지, 인증, DB 연동이 모두 필요한 완성형 서비스라면 Django가 유리하다.

둘째, 규칙을 얼마나 따를 수 있는가. Django는 규칙이 많다. 파일 이름, 폴더 구조, 코드 위치가 정해져 있다. 이 규칙이 불편하면 Flask나 FastAPI처럼 자유도가 높은 마이크로 프레임워크가 맞다.

셋째, 팀의 유지보수 환경. 규칙이 많다는 건 팀원이 바뀌어도 코드 구조가 일관하다는 뜻이기도 하다. 장기 운영 서비스나 팀 협업 환경에서는 Django의 표준화된 구조가 장점이 된다.

웹 프레임워크는 도구다. 어떤 게 더 좋은지보다, 지금 만드는 것에 무엇이 더 맞는지가 기준이 되어야 한다.

핵심 요약

• 웹 프레임워크는 웹 서비스 개발에 필요한 공통 구조를 미리 만들어둔 뼈대다
• 라이브러리와의 차이는 주도권 — 프레임워크가 흐름을 잡고 내 코드를 호출한다 (IoC)
• Django는 MTV 패턴으로 역할을 명확히 분리해 웹 프레임워크의 구조를 직관적으로 보여준다
• 웹 프레임워크 선택 기준은 만드는 것, 규칙 수용도, 유지보수 환경 3가지다

[링크 제안]

Django의 URL 처리 구조가 궁금하다면 다음 글이 이어진다.

• Django URL 라우팅 완전 이해 — urls.py 역할을 3가지 비유로 잡는 법

웹 프레임워크와 함께 자주 등장하는 Docker의 개념이 궁금하다면 이 글을 참고해도 좋다.

• Docker 가상환경 차이부터 잡아라 — 컨테이너 입문 3가지 핵심 개념

Django 공식 문서는 Django 공식 사이트에서 확인할 수 있다.

FAQ