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

나와 Cory의 배경 비교

Cory의 블로그를 많이 읽어 왔습니다. 우리 둘 다 Python 개발자지만, Cory는 Django를 주로 다루고 저는 줄곧 Flask 같은 더 얇은 프레임워크를 사용해 왔습니다. Django를 사용해 본 경험은 전혀 없지만 Python에는 익숙합니다.

개발 환경

• 운영체제: Ubuntu
  • Cory는 macOS 사용자일 거라고 생각했습니다.
• 브라우저: 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는 현지화를 고려해 앱을 설계하는 것 같습니다. 저는 이런 생각을 한 지가 15년쯤 됐습니다.
• 국제화할 수 있는 문자열의 문법은 꽤 간단해 보입니다.
  • {% translate "Manage your chats here." %}
  • 다른 언어로 번역한 내용은 어딘가에 따로 제공해야 할 텐데, 그 부분이 어떻게 동작하는지 궁금합니다.

Django의 제어 흐름

• Django는 이상합니다! 그냥 get_object_or_404를 호출하면 객체를 찾지 못했을 때 함수가 종료되고 HTTP 404 오류가 반환되는 것 같습니다.
  • Python Flask나 Go에서 넘어온 제게는 상당히 낯선 방식입니다. 두 환경에서는 개발자가 HTTP 오류를 반환하는 과정을 더 명시적으로 처리해야 하기 때문입니다. 물론 처리되지 않은 예외는 HTTP 500 오류가 됩니다.

git GUI

• Cory가 제가 한 번도 본 적 없는 git GUI를 사용합니다.
  • git g를 호출해 실행하는데, Cory만 사용하는 git 별칭인 것 같습니다.
• Cory는 변경 내용을 검토하면서 파일을 하나씩 커밋에 추가합니다.
• Cory는 포맷이 올바르지 않으면 커밋을 거부하고 원하는 스타일로 다시 포맷하는 pre-commit 훅을 사용합니다.
  • 자동화 도구가 제 코드를 바꾸는 것을 믿지 못해서 저는 늘 이런 방식을 두려워해 왔습니다.
  • Cory의 방식에서는 자동화 도구가 코드를 바꾸지만, 커밋하기 전에 Cory가 그 변경 사항을 다시 검토합니다.

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

• Cory는 제가 어려움을 겪고 있는 문제, 즉 클라이언트 사이드 렌더링과 서버 사이드 렌더링 사이에서 코드를 중복하지 않는 방법을 htmx로 해결하는 것 같습니다.

  • 웹 앱을 만들다 보면 페이지를 완전히 새로고침하지 않고 페이지에 콘텐츠를 추가하고 싶은 상황을 자주 만납니다.
  • 사용자가 페이지를 새로고침하면 콘텐츠를 동적으로 추가했을 때 보았던 것과 같은 콘텐츠가 보여야 합니다.
  • 저는 다음과 같은 좋지 않은 선택지 세 가지 사이에서 자주 막힙니다.
    1. 항상 콘텐츠를 클라이언트 사이드에서 렌더링하기. 구현이 복잡하고 브라우저에서 더 느리게 렌더링됩니다.
    2. 항상 콘텐츠를 서버 사이드에서 렌더링하기. 변경 사항을 표시하려면 대체로 페이지 전체를 새로고침해야 합니다.
    3. 렌더링 로직을 두 번 구현하기. 한 번은 클라이언트 사이드 렌더링용으로, 한 번은 서버 사이드 렌더링용으로 구현합니다.

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

ChatGPT API

• ChatGPT API는 놀라울 정도로 사용하기 쉽습니다.
  • API에는 모델 이름과 대화에 포함된 메시지 목록만 전달하면 됩니다.
  • API를 호출할 때마다 ChatGPT에 전체 메시지 내역을 전달해 대화 상태를 유지합니다.

마무리하며

Django가 무거운 프레임워크일 거라고 예상했지만, 실제로는 예상보다 더 무겁습니다. Django에는 Python의 리스트, 딕셔너리, 열거형을 위한 자체 래퍼가 있습니다. Django와 순수 Python 사이의 간극은 React와 바닐라 JavaScript 사이의 차이처럼 느껴집니다.

Cory가 하는 일의 상당 부분이 Django에 특화되어 있어서, 그 내용을 제 작업에 적용하는 데 어려움이 있었습니다. 어쩌면 영상을 잘못 골랐기 때문일 수도 있습니다. 이 영상에서 Cory가 하던 작업은 대체로 Django의 여러 요소를 서로 연결하는 일이었기 때문입니다.

그래도 모든 것을 더 높은 추상화 계층에서 설계하는 스택에서 개발자 경험이 어떤지 볼 수 있어 흥미로웠습니다.