친구인 Cory Zue가 라이브 코딩 세션을 꾸준히 공개하고 있어서, 하나를 시청하며 메모를 남겨 보기로 했다.

나와 Cory의 배경 비교

Cory의 블로그를 많이 읽었다. 우리는 둘 다 Python 개발자이지만, 그는 Django를 전문으로 하고 나는 Flask 같은 가벼운 프레임워크 위주로 작업해 왔다. Django 경험은 없지만 Python 자체에는 익숙하다.

개발 환경

• OS: Ubuntu
  • Cory는 OS X를 쓸 줄 알았다.
• 브라우저: Firefox
• IDE: PyCharm(으로 보인다)
  • PyCharm은 써본 적이 없고 VS Code에 더 익숙하다.

모델

• Django 관련 내용에서 길을 잃을까 봐 슬슬 걱정되기 시작했다.
• Cory가 ChatMessage 모델을 보여주는데, 이는 프레임워크에 해당 객체를 데이터베이스에 어떻게 저장하고 불러올지 알려주는 ORM 객체인 것 같다.
  • ORM을 다뤄본 적이 없어서 이 모든 게 낯설다.

마이그레이션

• Cory가 ./manage.py makemigrations chat 명령을 실행하는데, 이는 방금 정의한 두 모델을 데이터베이스가 지원할 수 있도록 데이터베이스 마이그레이션을 생성하는 것 같다.
• 이어서 방금 생성한 마이그레이션을 적용하기 위해 ./manage.py migrate를 실행한다.
• Django는 확실히 내가 익숙한 방식보다 훨씬 더 “매직”이 많다. 나는 지금까지 데이터베이스 마이그레이션을 직접 손으로 만들어 왔기 때문이다.
  • Cory가 하는 방식은 새로운 객체를 정의할 때마다 SQL 보일러플레이트를 잔뜩 작성하던 내 경험보다 훨씬 덜 지루하지만, 동시에 개발자와 데이터베이스 사이에 추상화 계층을 많이 추가하기도 한다.

어드민 UI 만들기

• Cory는 추가한 모델을 기반으로 어드민 페이지의 보일러플레이트 정의를 만들기 위해 ChatGPT를 사용한다.
  • ChatGPT가 제대로 만들어 주긴 했지만, Cory는 자신이 선호하는 Django 문법에 맞게 약간 손봐야 했다.

• Django는 이 정의를 이용해 데이터베이스에서 새 모델을 추가/편집할 수 있는 어드민 UI를 자동으로 생성하는 것으로 보인다.
  • 꽤 괜찮다. 나는 보통 이런 경우 데이터베이스에 직접 쿼리를 날리는데, 이 방식이 확실히 더 쉽다.

번역

• Cory는 이 앱을 현지화(localizability)를 염두에 두고 설계하는 것 같다. 나는 15년 정도 이런 걸 생각해 본 적이 없다.
• 국제화 가능한 문자열을 위한 문법은 꽤 직관적으로 보인다.
  • {% translate "Manage your chats here." %}
  • 다른 언어에 대한 번역은 다른 곳에서 제공해야 할 텐데, 그 과정이 어떻게 이뤄지는지 궁금하다.

Django 제어 흐름

• Django는 참 특이하다! 그냥 get_object_or_404를 호출하면 객체를 찾지 못했을 때 함수가 종료되면서 HTTP 404 에러를 반환하는 것 같다.
  • Python Flask나 Go에 익숙한 내게는 꽤 낯설다. 그 두 환경은 (처리되지 않은 예외가 HTTP 500 에러가 되는 경우를 제외하고는) HTTP 에러를 반환할 때 개발자가 훨씬 더 명시적으로 처리하도록 강제하기 때문이다.

git GUI

• Cory는 내가 한 번도 본 적 없는 git용 GUI를 사용한다.
  • git g라는 명령으로 실행하는데, Cory만의 git alias인 것 같다.
• Cory는 파일을 검토하면서 하나씩 커밋에 추가한다.
• Cory는 포매팅이 잘못되면 커밋을 거부하고 원하는 스타일로 다시 포매팅해 주는 pre-commit 훅을 가지고 있다.
  • 나는 자동화된 도구가 내 코드를 고치는 걸 신뢰하지 못해서 이런 방식을 늘 꺼려 왔다.
  • Cory 방식대로라면 자동화 도구가 코드를 수정하긴 하지만, 커밋하기 전에 그 변경 사항을 직접 검토한다.

클라이언트 사이드 렌더링과 서버 사이드 렌더링 간 코드 공유

• Cory는 내가 늘 고민하던 문제, 즉 클라이언트 사이드 렌더링과 서버 사이드 렌더링 사이에서 코드 중복을 어떻게 피할지를 htmx로 해결하는 것 같다.

  • 웹 앱에서는 페이지에 콘텐츠를 추가하고 싶지만 페이지 전체를 새로고침하고 싶지 않은 상황을 자주 마주한다.
  • 사용자가 새로고침을 해도 동적으로 추가했을 때 봤던 것과 동일한 콘텐츠를 봐야 한다.
  • 그럴 때 나는 종종 세 가지 별로인 선택지 사이에서 막히곤 한다:
    1. 항상 클라이언트 사이드에서 콘텐츠를 렌더링한다 — 복잡하고 브라우저에서 렌더링이 더 느리다.
    2. 항상 서버 사이드에서 콘텐츠를 렌더링한다 — 변경 사항을 보여주려면 보통 페이지 전체를 새로고침해야 한다.
    3. 렌더링 로직을 두 번 구현한다: 한 번은 클라이언트 사이드 렌더링용으로, 한 번은 서버 사이드 렌더링용으로.

• 영상에서는 자세히 볼 수 없었지만, htmx를 사용하면 Cory가 HTML을 서버 사이드에서 정의하고, htmx 속성을 통해 특정 요소들이 전체 새로고침 없이, 또 렌더링 로직을 다시 구현할 필요 없이 스스로 다시 렌더링되도록 할 수 있는 것 같다.

ChatGPT API

• ChatGPT API는 놀랍게도 사용하기 쉽다.
  • API는 모델 이름과 대화에 포함된 메시지 목록이 전부다.
  • 매 API 호출마다 전체 메시지 히스토리를 ChatGPT에 전달함으로써 대화 상태를 유지한다.

마무리 생각

Django가 무거운 프레임워크일 거라고 예상은 했지만, 생각보다 더 무거웠다. Django는 Python의 리스트, 딕셔너리, enum에 대해서도 자체 래퍼를 가지고 있다. Django와 순수 Python 사이의 간극은 React와 바닐라 JavaScript 사이의 간극처럼 느껴진다.

내 작업에 교훈을 적용하는 데 어려움을 겪었다. Cory가 한 작업 중 상당수가 Django에 특화된 것이었기 때문이다. 운이 없게 영상을 잘못 고른 것일 수도 있다. 이 영상에서 Cory가 한 작업은 대부분 Django의 여러 요소들을 서로 붙이는 것이었기 때문이다.

그래도 더 높은 추상화 계층에서 모든 것을 설계하는 스택에서의 개발자 경험을 보는 건 흥미로웠다.