Django 리드·아키텍트 데이터베이스 면접

PostgreSQL 기본값인 READ COMMITTED는 커밋된 데이터만 읽지만 같은 트랜잭션 내에서도 다른 결과를 반환할 수 있습니다. REPEATABLE READ는 트랜잭션 시작 시점의 스냅샷을 보장하며, SERIALIZABLE은 완전한 직렬화를 보장하지만 성능 오버헤드가 큽니다. Django에서는 select_for_update()로 행 단위 비관적 락을 걸어 재고 조회 시점부터 업데이트까지 다른 트랜잭션의 접근을 막을 수 있습니다. select_for_update(nowait=True)를 사용하면 락 대기 없이 즉시 예외를 발생시켜 사용자에게 품절 안내가 가능하고, skip_locked=True는 락 걸린 행을 건너뛰어 대기열 처리에 유용합니다. 또는 F() 표현식으로 UPDATE stock = stock - 1 WHERE stock > 0 같은 원자적 연산을 수행하거나, version 필드를 추가해 낙관적 락을 구현할 수 있습니다. 데드락 방지를 위해 항상 같은 순서로 테이블에 접근하고, 트랜잭션을 최대한 짧게 유지하며, 락 타임아웃을 설정해야 합니다.

Range 파티셔닝은 날짜나 ID 범위로 분할하여 시계열 데이터에 적합하고, List는 지역이나 카테고리 같은 명시적 값으로, Hash는 고른 분산이 필요할 때 사용합니다. 주문 데이터는 created_at 기준 월별 Range 파티셔닝이 적합하며, 오래된 파티션은 별도 테이블스페이스로 이동하거나 압축 저장할 수 있습니다. Django에서는 파티션 테이블을 직접 모델로 정의하지 않고 부모 테이블만 모델로 관리하며, 파티션 생성은 마이그레이션의 RunSQL이나 별도 스크립트로 처리합니다. 파티션 프루닝이 작동하려면 WHERE 절에 파티션 키가 반드시 포함되어야 하므로, 쿼리 작성 시 날짜 범위를 명시하고 함수나 연산을 파티션 키에 직접 적용하지 않아야 합니다. 기존 데이터 마이그레이션은 다운타임 없이 진행하기 위해 새 파티션 테이블을 먼저 생성하고, 배치로 데이터를 복사한 후 트리거로 동기화하며, 최종적으로 테이블명을 교체하는 전략을 사용합니다. 파티션별 인덱스 관리와 통계 정보 업데이트도 자동화해야 합니다.

복합 인덱스는 여러 컬럼을 하나의 인덱스로 묶어 특정 쿼리 패턴에 최적화되며, 컬럼 순서는 카디널리티가 높고 등호 조건이 먼저, 범위 조건은 나중에 배치하는 것이 일반적입니다. 예를 들어 WHERE user_id = X AND created_at > Y 쿼리에는 (user_id, created_at) 순서가 적합하며, 첫 번째 컬럼만으로도 인덱스를 활용할 수 있지만 두 번째 컬럼부터 시작하는 쿼리는 인덱스를 사용하지 못합니다. Partial Index는 WHERE status = 'active' 같은 조건을 인덱스에 포함시켜 특정 부분집합만 인덱싱하여 크기를 줄이고, Covering Index는 SELECT 절의 모든 컬럼을 인덱스에 포함시켜 테이블 접근 없이 인덱스만으로 쿼리를 처리합니다. Expression Index는 LOWER(email)이나 DATE(created_at) 같은 함수 결과에 인덱스를 생성하며, Django에서는 Meta.indexes에 Index 클래스로 정의할 수 있습니다. 인덱스는 INSERT, UPDATE, DELETE 시 추가 오버헤드가 발생하고 저장 공간을 차지하므로, 실제 쿼리 로그를 분석하여 빈도가 높고 성능 영향이 큰 쿼리에만 선택적으로 적용하며, EXPLAIN ANALYZE로 실행 계획을 검증해야 합니다.