Django가 해결하는 웹 개발 문제

웹 애플리케이션에서 반복되는 일

웹 애플리케이션은 겉으로는 다양해 보이지만, 내부에서 반복되는 일은 비슷합니다. 사용자가 주소를 입력하면 서버는 그 주소가 어떤 기능을 의미하는지 찾아야 합니다. 필요한 데이터를 데이터베이스에서 읽고, 사용자가 볼 HTML을 만들고, 로그인한 사용자인지 확인한 뒤, 최종 응답을 브라우저로 돌려보내야 합니다.

예를 들어 게시글 상세 페이지를 만든다고 생각해 봅시다.

1. /posts/3/ 주소가 들어온다.

2. 이 주소가 "3번 게시글 상세 보기"라는 기능과 연결된다.

3. 데이터베이스에서 3번 게시글을 찾는다.

4. 게시글 데이터를 HTML 화면에 끼워 넣는다.

5. 완성된 HTML을 응답으로 보낸다.

댓글 작성, 회원가입, 상품 목록, 관리자 화면도 큰 흐름은 다르지 않습니다. 문제는 이 반복 작업을 매번 직접 만들면 시간이 많이 들고, 프로젝트마다 구조가 달라져 유지보수가 어려워진다는 점입니다.

Django는 이 반복을 줄이기 위해 만들어진 웹 프레임워크입니다. 프레임워크는 개발자가 자주 마주치는 문제를 미리 정리해 둔 뼈대라고 볼 수 있습니다. Django는 단순히 몇 가지 도구만 제공하는 것이 아니라, 웹 애플리케이션을 만드는 데 필요한 주요 구성요소를 함께 제공합니다. 공식 문서에서도 Django의 핵심 구성으로 모델, 뷰, 템플릿, 관리자 인터페이스 등을 설명합니다.¹

AI 생성 이미지

Django가 미리 준비해 주는 것들

Django를 쓰면 다음 기능을 처음부터 직접 설계하지 않아도 됩니다.

라우팅: 주소를 기능에 연결하기

라우팅은 사용자가 요청한 URL을 어떤 코드가 처리할지 정하는 일입니다. Django에서는 보통 urls.py 파일에 URL 규칙을 적습니다.

path("posts/<int:pk>/", views.post_detail)

이 코드는 /posts/3/ 같은 주소가 들어왔을 때 post_detail이라는 View 함수가 처리하도록 연결합니다. URL 규칙이 한곳에 정리되므로, 프로젝트가 커져도 "어떤 주소가 어떤 기능으로 이어지는지" 추적하기 쉽습니다.

템플릿: 데이터를 HTML로 보여 주기

웹 서버가 데이터만 갖고 있어서는 사용자가 볼 수 없습니다. 데이터를 HTML에 넣어 화면으로 만들어야 합니다. Django의 Template은 이 작업을 담당합니다.

<h2>{{ post.title }}</h2>
<p>{{ post.content }}</p>

Template은 Python 코드와 HTML을 무리하게 섞지 않도록 도와줍니다. View는 데이터를 준비하고, Template은 그 데이터를 화면에 배치합니다. 역할이 나뉘면 디자이너와 백엔드 개발자가 작업을 나누기도 쉬워집니다.

ORM: SQL을 직접 쓰지 않고 데이터 다루기

웹 애플리케이션은 대부분 데이터베이스를 사용합니다. 게시글, 댓글, 사용자, 주문 같은 정보는 모두 데이터베이스에 저장됩니다. Django의 ORM은 Python 클래스로 데이터 구조를 정의하고, Python 코드로 데이터를 조회하거나 저장하게 해 줍니다.

post = Post.objects.get(pk=3)

이 한 줄은 데이터베이스에서 기본 키가 3인 게시글을 가져오는 동작입니다. 실제로는 SQL이 실행되지만, 개발자는 Python 객체를 다루듯 코드를 작성합니다. SQL을 몰라도 된다는 뜻은 아닙니다. 다만 일상적인 CRUD 작업, 즉 생성·조회·수정·삭제 코드를 더 일관된 방식으로 작성할 수 있습니다.

관리자 페이지: 내부 관리 기능 빠르게 만들기

서비스를 만들다 보면 운영자가 데이터를 확인하고 수정할 화면이 필요합니다. 게시글을 삭제하거나, 사용자를 비활성화하거나, 상품 정보를 고치는 화면입니다. Django는 모델을 등록하는 것만으로 기본 관리자 페이지를 제공합니다.

이 기능은 Django의 큰 장점입니다. 아직 별도의 운영 도구를 만들기 전에도 데이터를 확인하고 수정할 수 있습니다. 초기 개발 단계에서는 특히 유용합니다. 물론 최종 사용자에게 보여 줄 화면은 따로 만들어야 하지만, 내부 관리 기능을 빠르게 확보할 수 있다는 점은 개발 속도에 큰 영향을 줍니다.

인증과 권한: 로그인과 접근 제어

로그인 기능도 거의 모든 웹 서비스에서 반복됩니다. 사용자를 만들고, 비밀번호를 안전하게 저장하고, 로그인 상태를 유지하고, 특정 사용자만 접근할 수 있는 페이지를 구분해야 합니다.

Django는 기본 인증 시스템을 제공합니다. 사용자 계정, 그룹, 권한, 세션, 비밀번호 해싱, 로그인 관련 도구가 포함되어 있습니다.² 여기서 인증은 "이 사용자가 누구인지 확인하는 일"이고, 권한은 "확인된 사용자가 무엇을 할 수 있는지 판단하는 일"입니다.

이 기능을 직접 구현하는 것은 위험합니다. 특히 비밀번호 저장 방식이나 세션 관리는 보안과 직접 연결됩니다. Django의 기본 기능을 사용하면 흔한 실수를 줄이고, 필요한 부분만 프로젝트에 맞게 확장할 수 있습니다.

Batteries-included 방식의 장단점

Django를 설명할 때 자주 나오는 표현이 "batteries-included"입니다. 필요한 건전지가 이미 들어 있다는 뜻입니다. 웹 개발에 자주 필요한 기능이 프레임워크 안에 함께 들어 있다는 의미로 이해하면 됩니다.

반대로 Flask 같은 마이크로프레임워크는 더 작은 출발점을 제공합니다. 기본 구조는 가볍고, 필요한 기능은 확장 패키지를 골라 붙이는 방식입니다. 이 차이는 좋고 나쁨의 문제가 아니라 선택의 문제입니다.

Django의 장점은 분명합니다.

• 프로젝트 구조가 비교적 일관됩니다.

• ORM, 관리자, 인증, 폼, 템플릿 등 주요 기능을 한 흐름에서 배울 수 있습니다.

• 팀원이 바뀌어도 파일 위치와 역할을 예측하기 쉽습니다.

• 데이터 중심 웹 애플리케이션을 빠르게 만들 수 있습니다.

하지만 단점도 있습니다.

• 처음에는 배워야 할 개념이 많아 보입니다.

• 작은 API 서버에는 구조가 무겁게 느껴질 수 있습니다.

• Django의 관례를 이해하지 못하면 설정 파일과 앱 구조가 복잡해 보입니다.

• 자유롭게 모든 것을 직접 고르는 방식에 익숙한 개발자에게는 제약처럼 느껴질 수 있습니다.

따라서 아주 작은 실험용 서버나 단일 기능 API라면 Flask 같은 선택이 더 단순할 수 있습니다. 반면 사용자, 관리자, 데이터 모델, 폼, 권한, 화면 렌더링이 함께 필요한 서비스라면 Django의 기본 구성이 큰 도움이 됩니다.

이 책은 Django의 선택을 무조건 정답으로 말하지 않습니다. 대신 Django가 어떤 문제를 해결하려고 이런 구조를 갖게 되었는지 설명합니다. 구조의 이유를 알면 settings.py, urls.py, models.py, views.py 같은 파일이 암기 대상이 아니라 역할이 분명한 도구로 보입니다.

Django의 MVT 패턴 이해하기

Django는 MVT 패턴으로 동작한다고 설명합니다. MVT는 Model, View, Template의 약자입니다.

Model: 데이터의 구조와 규칙

Model은 데이터의 형태를 정의합니다. 예를 들어 게시글에는 제목, 내용, 작성일이 있을 수 있습니다.

class Post(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

이 클래스는 단순한 Python 코드처럼 보이지만, Django는 이를 바탕으로 데이터베이스 테이블 구조를 만들 수 있습니다. Model은 "우리 서비스가 어떤 데이터를 다루는가"를 표현하는 중심입니다.

View: 요청을 처리하고 응답을 결정

Django에서 View는 화면 자체가 아닙니다. 이름 때문에 헷갈리기 쉽습니다. Django의 View는 요청을 받아 필요한 작업을 하고, 어떤 응답을 돌려줄지 결정하는 코드입니다.

def post_detail(request, pk):
    post = Post.objects.get(pk=pk)
    return render(request, "posts/detail.html", {"post": post})

이 View는 게시글을 조회하고, Template에 데이터를 넘긴 뒤, HTML 응답을 만듭니다. 즉 View는 URL, Model, Template 사이를 연결하는 처리 담당자입니다.

Template: 사용자에게 보여 줄 표현

Template은 사용자가 실제로 보게 될 HTML의 틀입니다.

<h2>{{ post.title }}</h2>
<div>{{ post.content }}</div>

Template은 데이터의 저장 방식이나 요청 처리 과정을 몰라도 됩니다. 전달받은 데이터를 어떻게 보여 줄지만 담당합니다.

하나의 요청이 응답이 되기까지

Django의 전체 흐름은 다음처럼 볼 수 있습니다.

브라우저 요청
   ↓
URLconf(urls.py)
   ↓
View(views.py)
   ↓
Model / ORM(models.py) ↔ 데이터베이스
   ↓
Template(.html)
   ↓
HTTP 응답
   ↓
브라우저 화면

조금 더 구체적으로 따라가 보겠습니다.

사용자가 브라우저에서 /posts/3/으로 접속합니다. Django는 먼저 URLconf에서 이 주소와 일치하는 규칙을 찾습니다. 규칙이 발견되면 연결된 View가 실행됩니다.

View는 요청 객체를 받습니다. 요청 객체에는 사용자가 어떤 주소로 접근했는지, 어떤 방식으로 요청했는지, 로그인한 사용자인지 같은 정보가 들어 있습니다. View는 필요한 경우 Model을 통해 데이터베이스에 접근합니다. 게시글 상세 페이지라면 Post 모델에서 3번 게시글을 조회합니다.

데이터를 준비한 View는 Template을 선택하고, Template에 넘길 값을 정리합니다. 이 값을 보통 context라고 부릅니다. Template은 context에 담긴 데이터를 HTML에 채워 넣습니다. 마지막으로 Django는 완성된 HTML을 HTTP 응답으로 만들어 브라우저에 돌려줍니다.

모든 요청이 반드시 Template을 거치는 것은 아닙니다. API를 만들 때는 HTML 대신 JSON을 응답할 수 있습니다. 하지만 기본적인 웹 페이지를 만들 때는 URLconf, View, Model, Template의 흐름을 이해하는 것이 가장 중요합니다.

앞으로 배울 구조를 한눈에 보기

이 책의 이어지는 실습 장들에서는 이 흐름을 실제 코드로 하나씩 확인합니다.

먼저 프로젝트와 앱의 차이를 이해합니다. URL과 View로 요청을 처리하고, Template으로 화면을 만듭니다. Model과 ORM으로 데이터 구조를 정의한 뒤, 관리자 페이지에서 데이터를 다룹니다.

이후에는 사용자의 입력을 처리하는 Form, 게시판 CRUD, 클래스 기반 View, 로그인과 권한 관리, 정적 파일과 미디어 파일을 다룹니다. 프로젝트가 커졌을 때 필요한 데이터베이스 관계, 쿼리 최적화, 테스트, REST API, 배포와 운영 준비까지 이어집니다.

중요한 것은 순서입니다. Django는 여러 기능이 따로 떨어져 있는 도구 모음이 아닙니다. URL은 View로 이어지고, View는 Model과 Template을 사용하며, Model은 관리자와 인증, 권한, 폼과도 연결됩니다. 하나를 배우면 다음 기능의 이유가 조금씩 보입니다.

Django를 잘 쓰는 첫걸음은 많은 코드를 외우는 것이 아닙니다. 요청이 어디에서 시작해 어디를 거쳐 응답이 되는지 이해하는 것입니다. 이 흐름을 알고 있으면 새 파일을 만들 때도, 설정을 바꿀 때도, 오류를 추적할 때도 현재 자신이 어느 지점을 다루고 있는지 판단할 수 있습니다.

참고

¹Django documentation

²User authentication in Django