Django 리드·아키텍트 성능 최적화 기술면접

먼저 Django Debug Toolbar와 django-silk를 활용해 애플리케이션 레벨에서 쿼리 수행 시간과 N+1 문제를 확인합니다. APM 도구(New Relic, Datadog)로 트랜잭션 트레이스를 분석하여 느린 엔드포인트와 외부 API 호출 지연을 파악합니다. 데이터베이스 레벨에서는 pg_stat_statements나 slow query log로 실행 계획과 인덱스 활용도를 점검하며, 락 대기 상황을 확인합니다. 인프라 레벨에서는 CPU, 메모리, 디스크 I/O 메트릭을 모니터링하고, 네트워크 레이턴시와 로드밸런서 상태를 체크합니다. 캐시 히트율과 커넥션 풀 사용률도 중요한 지표이며, 최근 배포나 데이터 증가 같은 변경 사항과의 상관관계를 분석합니다.

select_related는 ForeignKey나 OneToOne 관계에서 JOIN을 통해 한 번의 쿼리로 관련 객체를 가져오며, prefetch_related는 ManyToMany나 역참조 관계에서 별도 쿼리로 데이터를 가져온 후 Python에서 조인합니다. only는 필요한 필드만 SELECT하여 데이터 전송량을 줄이고, defer는 특정 필드를 나중에 로드합니다. 이들을 조합해도 개선되지 않으면 iterator()로 메모리 사용을 줄이고, values()나 values_list()로 딕셔너리나 튜플로 받아 객체 생성 오버헤드를 제거합니다. 더 나아가 raw SQL이나 extra()를 활용하거나, 복잡한 집계는 DB 뷰나 materialized view로 사전 계산하며, 읽기 전용 replica를 활용한 read/write 분리도 고려합니다.

per-site 캐시는 전체 응답을 캐싱하여 정적 사이트에 적합하고, per-view 캐시는 cache_page 데코레이터로 뷰 단위 캐싱을 하며 인증 정보에 따라 다른 캐시 키를 사용합니다. template fragment 캐시는 템플릿 일부만 캐싱하여 동적 부분과 정적 부분을 분리하고, low-level 캐시는 cache.set/get으로 쿼리 결과나 연산 결과를 세밀하게 제어합니다. Redis 분산 환경에서는 cache key에 버전이나 태그를 포함시켜 관련 키를 그룹화하고, 데이터 변경 시 Django signals(post_save, post_delete)를 활용해 해당 그룹의 캐시를 일괄 삭제합니다. cache stampede 방지를 위해 probabilistic early expiration이나 lock 메커니즘을 적용하며, 캐시 워밍 전략으로 주요 데이터를 사전 로드합니다.

N+1 문제는 ORM의 lazy loading으로 인해 관계된 객체에 접근할 때마다 추가 쿼리가 발생하는 것이 원인입니다. 코드 레벨에서는 select_related와 prefetch_related를 적절히 사용하고, Prefetch 객체로 복잡한 관계를 최적화하며, 코드 리뷰 시 관계 접근 패턴을 점검합니다. 개발 환경에서는 django-debug-toolbar로 쿼리 수를 시각화하고, nplusone 라이브러리로 자동 감지하며, 테스트에서 assertNumQueries로 쿼리 수를 검증합니다. 아키텍처 레벨에서는 GraphQL의 dataloader 패턴이나 Django의 Prefetch 객체로 배치 로딩을 구현합니다. 프로덕션에서는 APM의 쿼리 카운트 메트릭에 임계값 알림을 설정하고, slow query log에서 반복 패턴을 분석하며, 주기적인 성능 테스트를 자동화합니다.

수직 스케일링은 단일 서버의 리소스를 증가시켜 구현이 간단하지만 물리적 한계가 있고 단일 장애점이 존재합니다. 수평 스케일링은 서버를 추가하여 이론상 무한 확장이 가능하고 고가용성을 제공하지만 복잡도가 증가합니다. Django는 stateless하므로 로드밸런서 뒤에 여러 인스턴스를 배치하기 적합하며, 세션은 Redis나 DB 기반 세션으로 중앙화하고, 파일 업로드는 S3 같은 객체 스토리지를 사용합니다. Celery beat는 단일 인스턴스에서만 실행되도록 구성하거나 분산 락을 사용하며, DB 커넥션 풀은 인스턴스 수를 고려해 적절히 설정합니다. 오토스케일링 정책은 CPU, 메모리, 요청 큐 길이 등의 메트릭 기반으로 설정하고, health check 엔드포인트로 트래픽 라우팅을 제어합니다.

Celery 도입 시 작업 특성에 따라 큐를 분리하여 중요도가 높은 작업이 블로킹되지 않도록 하고, priority queue로 긴급 작업을 우선 처리합니다. Task는 idempotent하게 설계하여 재시도 시 부작용이 없도록 하며, exponential backoff와 max_retries를 설정합니다. 작업 타임아웃을 설정하여 무한 대기를 방지하고, acks_late 옵션으로 worker 장애 시 작업 손실을 막습니다. 실패한 작업은 DLQ(Dead Letter Queue)로 라우팅하여 별도 분석하고, Flower나 Celery beat를 통해 작업 상태를 모니터링하며, Sentry로 에러를 추적합니다. 중요 작업은 DB에 상태를 기록하여 사용자에게 진행 상황을 알리고, webhook이나 polling으로 결과를 전달합니다.

템플릿 캐싱은 cached template loader를 활성화하여 템플릿 파싱 오버헤드를 제거하고, fragment 캐싱으로 부분적으로 동적인 페이지를 최적화합니다. 컨텍스트 프로세서는 필요한 것만 등록하고 무거운 연산은 lazy evaluation으로 처리하며, 템플릿에서 복잡한 로직은 template tag로 분리합니다. 정적 파일은 WhiteNoise나 django-compressor로 압축하고, collectstatic으로 빌드 타임에 처리하며, 파일명에 해시를 포함시켜 캐시 무효화를 관리합니다. CDN을 통해 정적 파일을 엣지 로케이션에서 제공하고, Cache-Control 헤더로 브라우저 캐싱 정책을 설정합니다. 이미지는 적절한 포맷과 크기로 최적화하고, lazy loading을 적용하며, HTTP/2를 활성화하여 다중 리소스를 효율적으로 전송합니다.