Django를 처음부터 다시 배운다면: HTTP에서 시작하는 학습 로드맵
연말이 되면 자연스럽게 지난 1년을 돌아보게 된다. 나에게는 매년 빠지지 않고 떠오르는 주제가 하나 있다. 바로 “Django를 나는 제대로 배우고 있었나?” 하는 질문이다.
Django와 Django REST Framework(DRF)를 사용한 지 여러 해가 지났다. 크고 작은 프로젝트를 거치며 이제는 적어도 이렇게 말할 수 있다.
“어디가 어떻게 동작하는지, 예전보다는 확실히 감이 잡힌다.”
물론 여전히 모르는 것투성이다. 그래도 이제는 과거의 나에게, 그리고 막 Django를 시작하는 개발자에게 “이 순서로 배우면 훨씬 덜 헤맬 거야” 라고 말해줄 수 있을 만큼은 정리가 되었다.
이 글은 그런 맥락에서 쓴, Django를 처음부터 다시 배운다면 어떻게 시작할지에 대한 개인적인 가이드다. 연말 회고처럼 읽히면서도, 언제 읽어도 유효한 Django 학습의 기준점이 되었으면 한다.
1. Django는 결국 HTTP를 다루는 프레임워크다
아주 당연한 말 같지만, 처음 Django를 배울 때는 이 사실을 자꾸 잊게 된다.
Django는 UI를 렌더링하든, JSON API만 반환하든, 본질은 HTTP 요청을 받아 HTTP 응답을 돌려주는 것이다.
- 클라이언트(브라우저, 앱, 다른 서버)가 HTTP 요청을 보낸다.
- Django가 그 요청을 받아서 적절한 처리를 한다.
- 그리고 HTTP 응답(HTML, JSON, 파일, 에러 등)을 되돌려준다.
우리가 흔히 떠올리는 Django의 요소들:
- URLConf
- View (FBV/CBV)
- Template
- ORM
- Middleware
- Authentication / Permission
- DRF의 Serializer, ViewSet, Router…
이 모든 것은 사실 “HTTP 요청 하나를 잘 받고, 잘 처리해서, 잘 돌려주기 위한 도구”일 뿐이다.
처음 Django를 접할 때 이 관점을 놓치면, 프레임워크가 금방 “마법 상자”처럼 느껴진다.
“일단 이렇게 쓰면 된다고 하니까… 쓰긴 쓰는데, 왜 이렇게 동작하는지는 잘 모르겠다.”
이 상태가 오래 가면, 어느 순간 프레임워크에 끌려다니기 시작한다.
2. 화려한 기능보다 먼저, “왜 그렇게 하는지”를 이해하라
Django를 처음 배우면 대개 이런 기능이 눈에 들어온다.
- 로그인/회원가입, 소셜 로그인
- 권한/인가 처리
- 캐시 설정
- 비동기 작업(Celery 등)
- 각종 미들웨어와 설정값들
이것들은 분명 나중에 필요해지는 기능들이다. 문제는, 이걸 너무 일찍 파고들 때 생긴다.
어느 순간 이런 질문이 따라온다.
“근데 왜 이렇게 해야 하지?”
이 질문에 답할 수 없는 상태에서 코드를 쌓아 올리면:
- 에러를 고쳐도 찜찜함이 남고
- 구조를 바꾸려 할 때마다 프레임워크에 발목이 잡힌다
- 구글링 답을 그대로 붙여두고 “일단 되니까 넘어가자” 모드가 된다
그래서 과거의 나에게, 그리고 지금 막 Django를 시작하는 개발자에게 가장 먼저 해주고 싶은 말은 이거다.
“기능보다 먼저, 웹의 동작 원리와 HTTP의 흐름을 이해하자.”
3. HTTP 흐름을 이해하면 Django의 바깥까지 보인다
Django를 “투명하게” 다루고 싶다면, HTTP 프로토콜의 기본 흐름을 피해갈 수 없다.
최소한 이런 것들을 직접 만져보며 이해하면 좋다.
- 요청은 어떤 구조를 가지는가
- URL, 메서드(GET/POST/PUT/DELETE…), 헤더, 쿼리스트링, 바디
- 응답은 무엇을 기준으로 결정되는가
- 상태 코드(200/400/404/500…), 헤더, 바디(JSON/HTML 등)
- 브라우저는 무엇을 캐시하고, 서버는 무엇을 신경 써야 하는가
간단한 예를 들어보자. 터미널에서 이런 요청을 한 번 직접 보내보는 것이다.
curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"
이 요청 하나에도 HTTP의 핵심이 다 들어 있다.
- 어떤 URL로 (
/articles/1/) - 어떤 메서드로 (
GET) - 어떤 헤더를 포함해 (
Accept: application/json) - 무엇을 돌려받고 싶은지 (JSON)
이 흐름이 머릿속에 그려지기 시작하면, Django의 바깥도 함께 보이기 시작한다.
- 왜 nginx에서 특정 경로를 Django로 프록시하는지
- gunicorn/uWSGI 같은 WSGI 서버가 어떤 역할을 하는지
- Django는 어디까지 책임지고, 어디부터는 다른 계층의 일인지
이 지점에 도달하면 Django는 더 이상 “알 수 없는 마법”이 아니다. “HTTP 요청을 처리하기 위해 이 정도 구조는 필요하겠구나” 하는 그림이 자연스럽게 그려진다.
그리고 그때 깨닫게 된다.
Django의 각종 편의 기능들은 본질이 아니라 곁가지다. 본질(HTTP와 웹의 동작 원리)을 이해하면, 곁가지는 자연스럽게 따라온다.
4. 첫 프로젝트는 단순하게, 그리고 FBV로 시작하라
Django 입문 시, 나는 이제 이런 방식을 가장 추천한다.
첫 번째 프로젝트는 의도적으로 단순하게, Function-Based View(FBV)로.
가능하면 이런 조건을 맞춰보자.
- 인증/권한 을 최소한으로 구현하는 앱
- 관리 페이지나 설정이 복잡하지 않은 구조
- 관계가 단순한 모델들 (예: 게시글, 댓글 정도)
- “멋진 구조”보다 “동작 흐름”을 느낄 수 있는 기능 위주
예를 들어, 아주 간단한 게시글 목록/상세를 FBV로 구현해본다고 해보자.
# views.py
from django.http import JsonResponse
from .models import Article
def article_detail(request, pk):
article = Article.objects.get(pk=pk)
data = {
"id": article.id,
"title": article.title,
"content": article.content,
}
return JsonResponse(data)
이 한 뷰 안에 Django의 핵심 흐름이 다 들어 있다.
request객체를 인자로 받는다.- URL에서 넘어온
pk로 ORM을 통해 데이터를 조회한다. - 파이썬 딕셔너리를 만들고
- 그것을 HTTP 응답(JSON)으로 감싼다.
이 과정을 한 줄 한 줄 따라가며 디버깅해 보면:
- URLConf가 어떻게 view에 연결되는지
request객체에 어떤 정보가 담겨 있는지- ORM이 실제로 어떤 SQL을 날리는지
- 응답이 어떻게 JSON으로 변환되는지
모든 과정이 눈에 들어오기 시작한다.
특히 이 단계에서 Django ORM을 차분히 익혀두면, 이후 어떤 규모의 프로젝트를 하더라도 엄청난 자산이 된다.
5. 그 다음은 빠르게 CBV와 DRF로 넘어가라
여기까지 FBV로 “HTTP–View–ORM–Response” 흐름을 몸으로 익혔다면, 이제 두 번째 프로젝트에서는 망설이지 말고 CBV와 DRF를 적극적으로 사용하는 단계로 넘어가길 추천한다.
Django의 진짜 힘, DRF의 진짜 편리함은 이때부터 체감된다.
CBV와 DRF는 이런 가치를 준다.
- 반복되는 패턴을 줄여주는 재사용 가능한 구조
- 프로젝트 전반을 관통하는 일관된 패턴
- 역할이 분리된 명확한 책임
- URL/Serializer/ViewSet/Permission이 맞물리는 확장 가능한 설계
예를 들어, 같은 기능을 DRF로 옮겨보면 이렇게 될 수 있다.
# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer
class ArticleViewSet(ReadOnlyModelViewSet):
queryset = Article.objects.all()
serializer_class = ArticleSerializer
그리고 라우터만 등록하면:
# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet
router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')
urlpatterns = router.urls
이제:
/articles//articles/{id}/
와 같은 엔드포인트가 자동으로 동작한다.
FBV로 HTTP 흐름을 충분히 이해한 상태라면, CBV/DRF의 이런 마법 같은 동작도 결국 이렇게 보인다.
“아, 결국 저 안에서도 같은 HTTP 요청/응답 흐름이 돌아가는 거구나. 다만 공통 패턴을 클래스로 잘 추상화해놓은 거네.”
이 인식 차이가 중요하다. CBV/DRF를 “암기해야 할 문법”으로 대하면 끝없이 헷갈리지만, “이미 알던 HTTP 처리 과정을 잘 추상화한 도구”로 보면 훨씬 빨리 흡수된다.
그리고 기억이 안나거나 이해가 안되는 부분이 있다면 때로는 Django의 소스 내부로 들어가서 그 구조를 들여다보자.
6. Django 학습 순서를 다시 정리해보면
과거의 나에게, 그리고 지금 Django를 시작하는 개발자에게 나는 아마 이렇게 학습 순서를 추천할 것 같다.
- 웹과 HTTP 기본 이해
- 브라우저–서버 간 요청/응답 흐름
- HTTP 메서드, 상태 코드, 헤더, 쿠키, 세션 개념
- 간단한
curl또는 Postman으로 요청 보내보기 - Django 기초: FBV로 한 바퀴 돌기 - URLConf–View–Template–ORM 기본 흐름 익히기 - 인증/권한 없이 동작하는 작은 프로젝트 하나 완주 - ORM으로 CRUD 직접 구현해보기
- Django ORM, Admin 조금 더 파보기 - 모델 설계, 관계(ManyToOne, ManyToMany 등), 쿼리 최적화 맛보기 - Admin으로 데이터 관리하며 모델 구조에 익숙해지기
- CBV로 전환하기 - Generic View로 CRUD 다시 구현해보기 - Mixin, 상속 구조를 보면서 “패턴 추상화” 감 익히기
- DRF로 API 프로젝트 만들기 - Serializer, ViewSet, Router, Permission, Authentication 기본 - FBV/CBV로 만들었던 기능을 DRF로 다시 설계해보기
- 그 다음에야 “화려한 기능”으로 - 인증/인가, throttling, pagination, filter - 캐시, 비동기 작업, 배포, 스케일링 등
중요한 건, 단계별로 “왜 이렇게 하는지”를 스스로 설명할 수 있어야 한다는 것이다. “이렇게 해야 한다고 해서”가 아니라, “HTTP와 웹의 구조 때문에 이렇게 하는 게 자연스럽다”는 감각까지 가는 것이 목표다.
7. 마무리: 프레임워크를 외우지 말고, 웹을 이해하라
마지막으로, 과거의 나에게 그리고 지금 Django를 시작하는 개발자에게 이 문장을 꼭 남기고 싶다.
프레임워크를 외우지 말고, 웹이 어떻게 동작하는지를 이해하라.
Django는 그 이해를 돕기 위한 훌륭한 도구일 뿐이다.
이 관점을 잃지 않는다면:
- Django의 버전이 바뀌어도
- 다른 웹 프레임워크(Flask, FastAPI, Node, Spring…)를 만나더라도
- 새로운 아키텍처나 클라우드 환경을 접하더라도
항상 동일한 기준으로 질문할 수 있다.
- “이 시스템은 HTTP를 어떻게 다루고 있지?”
- “어디서 어떤 책임을 지고 있지?”
- “이 추상화는 결국 어떤 요청/응답 패턴을 감추고 있지?”
그 기준이 있다면, 특정 프레임워크에 갇히지 않고 어느 환경에서도 흔들리지 않는 웹 개발자로 성장할 수 있다고 믿는다.
댓글이 없습니다.