두숟갈 스터디 16회

이번 시간에는 Two Scoops of Django 24장 **‘장고 성능 향상시키기’**와 25장 **‘Asynchronous Task Queues’**를 공부했다. 24장은 성능 최적화의 관점을, 25장은 비동기 작업 큐를 언제 써야 하는지와 어떤 점을 조심해야 하는지를 중심으로 다뤘다.

성능 향상은 여러 계층에서 접근해야 한다. Query에서는 중복 쿼리를 줄이고 인덱스를 활용해 느린 쿼리를 제거하며, Database에서는 로그나 일시적 데이터를 무작정 쌓지 않고 각 DB 환경 설정을 주의 깊게 봐야 한다.

그 밖에도 Cache를 어디에 둘지와 cache invalidation 시점을 고민해야 하고, HTML/CSS/JavaScript 같은 static file은 압축과 최소화가 중요하다. 필요에 따라 업스트림 캐시나 CDN도 활용할 수 있다.

다만 핵심 메시지는 서툰 최적화는 해가 될 수 있다는 점이다. 규모가 작은 서비스나 초기 제품 단계에서는 최적화보다 먼저 실제로 동작하는 기능을 만드는 것이 더 중요하며, 사용자가 거의 없는 상태에서 성능 문제를 미리 걱정하다가 개발 자체를 멈추는 실수를 피해야 한다.

비동기 작업 큐는 결과 처리에 시간이 오래 걸리는 작업에 적합하다. 반대로 사용자가 즉시 결과를 확인하거나 바로 써야 하는 작업에는 맞지 않으며, 작업 성격을 보고 신중하게 선택해야 한다.

비동기 task를 쓸 때는 몇 가지 원칙이 중요하다.

• 멱등성을 유지할 수 있게 작성해야 한다. 재시도 가능성이 항상 있기 때문이다.
• 중요한 데이터를 큐 안에만 보관하지 말아야 한다. 실패와 재시도를 고려하면 데이터는 별도 저장소에 두고, 큐는 이를 꺼내 실행하는 용도로 쓰는 편이 안전하다.
• 큐는 공짜가 아니다. 보이지 않게 돌아가더라도 결국 컴퓨팅 자원을 쓰므로, 비효율적으로 설계하면 병목이 된다.

심화에서는 추가 자료도 함께 소개했다. Postgres Performance 번역 글을 통해 캐시와 히트율, 인덱스 사용법 같은 실무 팁을 살폈고, 실제 DB에 직접 조회해보며 이해를 넓혔다.

또한 Celery 관련 글들에서는 중요한 데이터를 큐에 넣지 않는 방식, 이메일 발송 task에서 중복 발송을 막는 설계, Celery - Best Practices를 다뤘다. 마지막으로 AMQP 글을 통해 메시지 큐의 용어와 내부 동작 배경을 정리했다.

전체적으로 이번 스터디는 Django 성능 튜닝의 기본 원칙과 비동기 작업의 올바른 사용 기준을 함께 정리한 시간이었다. 특히 개인 서비스에 Celery나 PostgreSQL 최적화를 적용해볼 실질적인 힌트를 얻었다는 점이 인상적이었다.