Django를 처음 접했을 때 이런 생각을 했다. “왜 굳이 Django를 써야 하지? FastAPI도 있고, Flask도 있는데.” 답은 생각보다 단순했다. Django를 쓰는 가장 큰 이유는 Django 모델 하나로 할 수 있는 일이 너무 많기 때문이다.
데이터 구조 정의부터 DB 조작, 자동 검증, 관리 화면 생성까지 — 모두 Django 모델을 중심으로 돌아간다. 이번 포스팅에서는 Django 모델이 무엇인지, 그리고 왜 이것이 Django를 선택하는 핵심 이유가 되는지를 현장 엔지니어 시각으로 풀어본다.
Django 모델이란 — 데이터 구조를 Python으로 정의한다
Django 모델은 “이 데이터를 어떤 형태로 저장하고 다룰 것인가”를 Python 클래스로 선언한 것이다.
class Part(models.Model):
part_name = models.CharField(max_length=100)
quantity = models.IntegerField()
created_at = models.DateTimeField(auto_now_add=True)
이 코드 한 블록이 Django 모델이다. “파트라는 데이터는 이름, 수량, 생성일시를 가진다”고 구조를 선언한 것이다.
현장에 비유하면 장비 스펙 시트와 같다. 어떤 항목을 측정하고, 어떤 타입으로 기록할지 미리 정해두는 것. 그 규격대로 실제 저장 공간(DB 테이블)을 만드는 작업이 바로 다음에 설명할 Migration이다.
Django 모델이 핵심인 3가지 이유
이유 1 — ORM으로 SQL 없이 DB를 다룬다
ORM(Object-Relational Mapping)은 Python 코드로 DB를 조작할 수 있게 해주는 기능이다. SQL을 직접 쓰지 않아도 된다.
# SQL 없이 데이터 전체 조회
parts = Part.objects.all()
# 조건 검색
low_stock = Part.objects.filter(quantity__lt=10)
엔지니어 입장에서 보면, 데이터베이스 문법을 따로 익히지 않아도 Python 문법 안에서 모든 데이터 조작이 가능하다는 뜻이다. Django 모델이 이 진입 장벽을 확 낮춰준다.
이유 2 — 데이터 검증을 Django 모델이 자동으로 처리한다
FastAPI나 Flask를 사용하면 데이터 유효성 검증 로직을 개발자가 직접 모두 작성해야 한다. 이메일 형식이 맞는지, 숫자 컬럼에 문자가 들어오진 않는지 — 하나하나 방어 코드를 짜야 한다.
Django 모델은 이 검증을 자동으로 위임받는다.
email = models.EmailField() # 이메일 형식 자동 검증
quantity = models.IntegerField() # 정수 외 입력 차단
모델에 한 번 정의해두면, 잘못된 데이터는 DB에 들어오기 전에 차단된다. 실서비스에서 데이터가 오염되면 되돌리는 비용이 어마어마하다. 현장에서 한 번이라도 경험해봤다면 이 기능의 가치를 바로 알 수 있다.
이유 3 — Migration으로 Django 모델 변경을 DB에 안전하게 반영한다
Django 모델(코드)을 수정했다고 해서 DB 테이블이 자동으로 바뀌지 않는다. 이 간극을 채워주는 게 Migration이다.
python manage.py makemigrations # 변경 감지 → 이력 파일 생성
python manage.py migrate # 이력 파일 → DB에 실제 반영
Migration이 중요한 이유는 단순히 “DB에 반영”하는 것 이상이다. 변경 이력이 파일로 남는다. 어떤 시점에 어떤 컬럼이 추가되고 삭제됐는지 기록이 쌓인다. 팀 개발 환경에서는 이 이력이 곧 롤백의 근거가 된다.
Django 모델을 만들었다면 Migration은 반드시 실행해야 한다. 코드에만 존재하고 DB에 없는 테이블에 데이터를 넣으려 하면 바로 오류가 난다.
모델 하나로 관리 화면까지 자동 생성된다
Django의 또 다른 강점은 Admin 기능이다. Django 모델을 등록하면 별도 개발 없이 관리 화면이 자동으로 생성된다.
# admin.py
from django.contrib import admin
from .models import Part
admin.site.register(Part)
이 네 줄이면 Part 데이터를 조회하고 추가하고 수정하고 삭제하는 관리 페이지가 완성된다. 프로토타입 단계에서 빠르게 데이터를 확인하고 운영할 때 실질적인 시간 절약이 된다.
View, URL, Template — Django 모델 다음에 오는 것들
Django는 MTV(Model-Template-View) 구조로 역할이 명확하게 분리되어 있다.
| 구성요소 | 역할 |
|---|---|
| Model | 데이터 구조 정의 + DB 관리 |
| View | 요청 처리 + 비즈니스 로직 |
| Template | 화면 출력 (HTML) |
| URL | 요청 경로 연결 |
Django 모델이 기반을 잡으면, View는 모델에서 데이터를 가져와 Template에 전달하는 중간 조율자 역할을 한다. View, URL, Template 각각의 역할은 별도 포스팅에서 다룰 예정이다. 지금은 “모델이 탄탄하면 나머지는 그 위에 쌓아올리는 것”이라는 흐름만 기억해두면 된다.
핵심 요약
- Django모델은 데이터 구조를 Python 클래스로 선언하는 설계도다
- ORM으로 SQL 없이 DB를 조작할 수 있어 진입 장벽이 낮아진다
- 데이터 검증을 모델이 자동으로 처리해 잘못된 데이터가 DB에 들어오는 것을 막는다
- Migration으로 모델 변경 이력을 관리하고 DB에 안전하게 반영한다
- Admin 등록 4줄이면 관리 화면이 자동 생성된다 — FastAPI·Flask 대비 압도적인 자동화 생태계
[링크 제안]
Django모델의 ORM 동작 방식을 더 깊이 이해하고 싶다면 이 글이 다음 단계다.
Django를 시작하기 전에 개발환경부터 제대로 잡아야 한다.
아이언맨으로 Agentic Engineering을 이해하다
