Julia Evans가 Django로 ‘2010년식 웹사이트’를 만들며 좋았던 것들

왜 갑자기 ‘2010년식 웹사이트’인가

• Julia Evans는 요즘 SQL 데이터베이스를 두고, 서버에서 HTML을 렌더링하는 방식으로 웹사이트를 만드는 중임

  • 본인은 2000년대나 2010년대에 이런 방식의 웹 개발을 제대로 배운 적이 없어서, 생각보다 쉽지는 않다고 함
  • 이전에는 정적 사이트 생성기, 약간의 JavaScript가 있는 정적 사이트, Vue.js 단일 페이지 앱, Lambda나 Go 백엔드 조합에 익숙했음

• 프론트엔드 중심 접근이 싫어진 게 아니라, 페이지가 많은 사이트에서는 로직을 한곳에 두고 싶어진 쪽에 가까움

  • 단일 페이지 앱에서는 가능한 한 백엔드를 얇게 만들고 프론트엔드에 로직을 모으는 게 편했음
  • 반대로 Django식 서버 렌더링에서는 JavaScript를 최소화하고 백엔드에 로직을 모으는 식임
  • 겉보기엔 정반대지만, 글쓴이 입장에선 “복잡도를 한곳에 둔다”는 점에서 비슷한 선택임

QuerySet 메서드 체이닝이 생각보다 좋았다

• Django QuerySet에 도메인별 필터 메서드를 붙여두면 뷰 코드가 꽤 읽기 좋아짐

  • 예시는 Events.objects.approved().for_tab(tab).with_festivals(...).is_free(...).is_outdoors(...) 같은 형태임
  • 각각의 메서드는 내부적으로 WHERE 조건을 추가하지만, 사용하는 쪽에서는 “승인된 이벤트 중 탭과 축제, 무료 여부, 야외 여부로 필터링”처럼 읽힘

• 글쓴이는 원래 “SQL을 아는데 query builder가 왜 필요하지?” 쪽에 가까웠음

  • 그런데 복잡한 조건을 직접 매번 늘어놓는 대신 의미 있는 메서드로 감싸니 구조가 훨씬 좋게 느껴졌다고 함
  • 필터 정의 문법 자체가 취향은 아니지만, 대부분의 시간은 정의가 아니라 사용 쪽에서 보내기 때문에 만족도가 높았음

• Django 템플릿 필터도 잔일을 많이 줄여줌

  • urlize는 일반 텍스트 URL을 링크로 바꿔줌
  • linebreaksbr는 줄바꿈을 <br>로 바꿔줌
  • date는 날짜 표시를 포맷해줌
  • json_script는 Python dictionary를 안전하게 JSON으로 바꿔 <script> 태그에 넣어줌

• 특히 querystring 템플릿 태그를 마음에 들어 함

  • ?date=2026-06-01 같은 필터가 있는 페이지에서 기존 query string을 유지한 채 특정 값만 바꾸는 링크를 만들 수 있음
  • 예를 들어 이전 날짜 링크를 만들거나, outdoors 파라미터만 제거하는 식의 UI가 깔끔해짐

자동 마이그레이션은 여전히 강력하다

• Django의 자동 데이터베이스 마이그레이션은 글쓴이가 계속 좋아하는 기능임

  • 모델에 필드를 추가하거나 구조를 바꾸면 Django가 migration을 생성해줌
  • 지금까지 이미 19개의 데이터베이스 migration을 만들었고, 앞으로도 더 생길 것 같다고 함

• 이게 중요한 이유는 문제 이해가 개발 중에 계속 바뀌기 때문임

  • 처음부터 완벽한 스키마를 설계하기 어렵고, 실제 데이터를 보면서 모델을 바꾸게 됨
  • 그때 migration이 자연스럽게 따라와주면 데이터 구조 변경이 덜 무서워짐

상속 기반 뷰는 취향이 아니었다

• Django 문서는 class-based view와 상속으로 뷰 코드를 조직하는 선택지를 자주 제시함

  • 글쓴이도 공통 코드가 많은 4개 뷰를 상속 구조로 묶어보려 했음
  • 결과적으로는 경험이 별로였고, 공통 로직을 함수로 빼는 방식으로 바꿨다고 함

• 다만 Django가 제공하는 인터페이스를 쓰기 위한 상속은 괜찮게 받아들임

  • 예를 들어 class EventQuerySet(SearchableQuerySetMixin, models.QuerySet) 같은 형태는 그냥 필요한 인터페이스를 구현하는 느낌으로 사용함
  • 싫은 건 “내 애플리케이션 로직을 상속 계층으로 공유하는 방식”에 더 가까움

성능은 아직 감이 잘 안 잡힌다

• LLM 스크래퍼가 사이트를 발견하면서 초당 약 10 요청을 보내기 시작했고, 그때부터 처리 용량을 고민하게 됨

  • 일단 차단은 했지만, 사이트가 어느 정도 버틸 수 있어야 하는지 감이 필요해짐
  • Go 백엔드에 익숙할 때는 보통 그냥 충분히 빠른 경우가 많았는데, Django는 느낌이 다르다고 함

• 가벼운 부하 테스트 결과는 처음엔 꽤 낮았음

  • ab -n 1000 -c 1 기준, 월 약 10달러짜리 가상머신에서 초당 2-3 요청 정도였음
  • profiling을 파고들고 싶은 유혹이 있었지만, 지금 가장 배워야 할 게 profiling은 아니라고 선을 그음

• 성능 고민 포인트도 여러 개 남아 있음

  • 트래픽이 가끔 몰리는 사이트라면 scale up을 염두에 둬야 하는지
  • 캐시하기 쉬운 구조로 설계해야 하는지
  • Django 문서에서 Jinja가 더 빠르다고 하는데 템플릿 엔진을 바꿀 가치가 있는지
  • {% block %}이 {% include %}보다 빠르다는 말이 실제로 얼마나 중요한지

• 실제로 가장 큰 힌트는 데이터베이스가 아니라 템플릿 렌더링에서 나왔음

  • CPU profiling을 보니 템플릿 렌더링에 시간이 많이 쓰이고 있었음
  • Django 성능 문서에서 cached template loader가 템플릿을 매번 컴파일하지 않게 해 성능을 크게 올릴 수 있다는 설명을 봄
  • 알고 보니 기본으로 켜져 있어야 할 cached template loader를 다른 설정을 만지다 실수로 꺼둔 상태였음

• 캐시를 다시 켠 뒤에는 처리량이 대략 초당 12 요청까지 올라감

  • 엄밀한 전후 벤치마크는 아니지만, CPU를 다 쓰지 않고도 꽤 쉽게 처리하는 수준이 됨
  • 흔히 “성능 문제면 DB 쿼리부터 봐라, 인덱스 봐라”라고 하지만, 이번에는 템플릿 설정이 더 중요했음
  • SQLite를 쓰고 있어서 느린 DB 쿼리도 CPU profile에 드러날 거라, 지금은 CPU profile부터 보는 게 더 유용했다고 함

---

기술 맥락

• 이 글의 큰 선택은 서버 사이드 렌더링으로 로직을 백엔드에 모으는 거예요. 페이지가 많아질수록 프론트엔드 상태와 라우팅, API 조합이 복잡해질 수 있어서, Django처럼 HTML을 서버에서 만들어주는 방식이 오히려 단순해질 때가 있거든요.

• QuerySet 메서드를 쓰는 이유는 SQL을 몰라서가 아니에요. approved, future, with_tags 같은 이름으로 조건을 감싸두면 뷰 코드가 데이터베이스 문법보다 제품의 의미에 가깝게 읽혀요. 유지보수할 때 이 차이가 꽤 커요.

• 자동 마이그레이션이 편한 이유는 초기 스키마가 거의 항상 틀리기 때문이에요. 실제 서비스를 만들다 보면 필드가 추가되고 의미가 바뀌는데, Django는 모델 변경과 DB 변경을 연결해줘서 실험 비용을 낮춰줘요.

• 성능 쪽에서는 템플릿 캐시 사례가 중요해요. 병목이 항상 DB에 있는 건 아니고, 프레임워크 설정 하나 때문에 매 요청마다 템플릿을 다시 컴파일하는 식의 낭비가 생길 수 있어요. 그래서 Django에서는 쿼리 확인과 함께 CPU profiling도 꽤 실용적인 출발점이에요.