백엔드 렌더링으로 돌아간 개발자가 Django에서 발견한 실용성과 함정

프런트엔드 프레임워크가 웹 개발의 기본값처럼 여겨지는 시대에, 오히려 반대 방향으로 걸어간 개발 경험담이 눈길을 끈다. 한 개발자는 자바스크립트를 최소화하고 SQL 데이터베이스에 백엔드에서 HTML을 렌더링하는, 이른바 '2010년대 스타일'의 웹사이트를 다시 배우는 과정을 기록했다. 흥미로운 점은 이 방식이 그에게 결코 쉽지 않았다는 고백이다. 2000년대나 2010년대에 이 방식을 정식으로 익히지 않았기 때문에 배울 것이 많았고, 과거 Go 표준 라이브러리나 Flask로 시도했다가 좌절했던 경험도 있었다. 그런 그가 Django에서는 '해볼 만하다'는 감각을 얻었다는 것이다.

그는 프런트엔드에 로직을 몰아넣는 단일 페이지 방식과 백엔드에 몰아넣는 방식이 겉보기에 정반대처럼 보이지만, 본질적으로는 '가능한 한 로직을 한곳에 모은다'는 같은 목표를 공유한다고 본다. 페이지가 하나뿐인 단순한 앱을 넘어 여러 페이지를 가진 사이트를 만들려 하자, 프런트엔드 코드가 많아지는 선택지들이 더는 매력적으로 느껴지지 않았고 그래서 백엔드로 방향을 틀었다는 설명이다.

쿼리셋과 템플릿 필터가 주는 실용성

그가 특히 유용하게 여긴 기능은 Django의 쿼리셋(QuerySet) 클래스다. 다양한 WHERE 조건을 각각의 메서드로 정의해 두면, 실제 뷰 코드에서는 그 메서드들을 조합해 쿼리를 구성한다. 필터를 정의하는 문법 자체는 그의 취향이 아니지만, 정작 시간을 쓰는 것은 정의해 둔 메서드를 호출하는 부분이고 이 코드는 읽기 쉽고 쓰기에 편안하다고 평가한다. 'SQL을 아는데 쿼리 빌더가 왜 필요하냐'고 생각했던 과거와 달리, 이런 구조가 코드 가독성을 크게 높인다는 점을 인정하게 됐고 다른 쿼리 빌더 라이브러리에도 관심이 생겼다고 한다.

HTML 생성을 돕는 템플릿 필터들도 개별적으로는 사소하지만 모여서 큰 차이를 만든다고 봤다. 그가 가장 아끼는 필터는 querystring이다. 예컨대 ?date=2026-06-01 같은 파라미터로 화면 표시 내용을 바꾸는 사이트에서, 이 필터는 하나의 값만 바꾼 동일 쿼리스트링 링크를 손쉽게 생성해 준다. 이전 날짜로 이동하는 링크를 만드는 식의 작업이 간단해진다는 것이다. 또한 그는 모델을 수정하면 Django가 마이그레이션을 자동 생성해 주는 시스템을 여전히 높이 평가한다. 이미 19번의 마이그레이션을 진행했고, 문제에 대한 이해가 바뀔 때마다 데이터베이스를 부담 없이 변경할 수 있다는 점이 실질적인 도움이 됐다고 말한다.

상속보다 함수, 그리고 설정 파일의 함정

코드 구조에 대해서는 뚜렷한 취향을 드러낸다. Django 문서는 공통 코드를 공유하는 여러 뷰를 클래스 기반 뷰와 상속으로 정리하는 방식을 제시하지만, 그는 상속으로 코드를 공유하는 경험이 즐겁지 않았다고 밝힌다. 많은 코드를 공유하는 네 개의 뷰를 부모 클래스 상속으로 묶어 봤다가, 결국 함수 기반 뷰로 전환했고 그 편이 훨씬 명료했다는 것이다. 다만 EventQuerySet(SearchableQuerySetMixin, models.QuerySet)처럼 Django가 제공하는 인터페이스를 쓰기 위한 상속은 깊이 고민하지 않고 그대로 사용한다. 그는 자신의 의견을 '이것이 옳다'가 아니라 '나는 이쪽이 더 편하다'는 식으로 표현하려 한다고 덧붙였다.

성능 문제는 예상치 못한 지점에서 드러났다. 어느 시점부터 LLM 스크레이퍼들이 초당 10건가량 요청을 보내기 시작해 이를 차단했는데, 이 일이 사이트의 처리 용량을 돌아보게 만들었다. ab -n 1000 -c 1로 가벼운 부하 테스트를 해 보니 월 10달러짜리 VM에서 초당 2~3건 정도를 처리하는 수준이었다. 대개 '충분히 빠른' Go 백엔드에 익숙했던 그에게 Django의 성능 감각은 낯설었다.

원인은 뜻밖에도 설정 실수였다. Django 성능 문서에서 캐시 템플릿 로더를 켜면 매번 템플릿을 컴파일하지 않아 성능이 크게 개선된다는 언급을 봤고, CPU 프로파일링에서 실제로 템플릿 렌더링에 시간이 많이 쓰이고 있었다. 확인해 보니 기본값으로 켜져 있어야 할 이 로더를 그가 다른 작업을 하다 실수로 꺼 둔 상태였다. 이를 다시 켜자 사이트는 CPU를 다 쓰지 않고도 초당 12건 정도를 무난히 처리하게 됐다. 그는 이 사례를 두고 프레임워크이기 때문에 오히려 무심코 잘못 설정하기 쉽다고, 그리고 Django 설정 파일이 여전히 혼란스럽다고 짚었다.

프로파일링이 준 교훈

마지막으로 그는 성능에 대한 통념을 뒤집는 관찰을 남긴다. 흔히 '성능 문제가 생기면 데이터베이스 쿼리를 확인하고 인덱스를 추가하라'고들 하지만, 그가 겪은 문제들은 느린 쿼리가 아니라 템플릿 캐싱처럼 다른 원인에서 비롯됐다. 그래서 그에게는 쿼리부터 의심하기보다 CPU 프로파일을 먼저 돌려 보는 편이 더 유용했다. 게다가 SQLite를 쓰고 있어 느린 쿼리가 있더라도 어차피 CPU 프로파일에 드러난다. py-spy로 프로파일링에 빠져드는 것은 재미있는 일이지만, 그는 자신이 이미 프로파일링을 잘 알고 있으며 지금 가장 중요하게 배워야 할 주제는 아니라고 선을 그었다. 백엔드 렌더링으로의 회귀라는 개인적 실험이지만, 프레임워크의 편의와 그 이면의 설정 리스크를 함께 보여 준다는 점에서 실무자에게도 참고할 지점이 있다.