Next.js 리드·아키텍트 데이터베이스 면접

EAV 모델은 스키마 유연성이 높지만 JOIN 연산이 과도하게 발생하고 타입 안정성이 떨어지며, 복합 조건 검색 시 성능이 급격히 저하됩니다. PostgreSQL의 JSONB 컬럼은 GIN 인덱스를 통해 특정 속성 검색이 가능하지만, 부분 업데이트 시 전체 JSON을 다시 쓰는 오버헤드가 있고 트랜잭션 격리 수준에서 행 단위 잠금만 가능해 속성별 동시성 제어가 어렵습니다. 정규화된 관계형 모델은 쿼리 성능과 데이터 무결성이 우수하나 스키마 변경 비용이 높습니다. 실무에서는 핵심 속성(가격, 재고)은 정규화된 컬럼으로, 가변 속성은 JSONB로 관리하는 하이브리드 방식을 선택하며, 재고 차감은 SELECT FOR UPDATE로 행 잠금을 확보한 후 원자적 업데이트를 수행합니다. 검색 성능이 중요한 속성은 Generated Column으로 추출해 인덱스를 생성하는 전략을 병행합니다.

인덱스가 있어도 사용되지 않는 주요 원인은 첫째, WHERE 조건에 함수나 타입 변환이 적용되어 인덱스 컬럼이 변형된 경우, 둘째, 조건의 Selectivity가 낮아 옵티마이저가 전체 행의 상당 부분을 읽어야 한다고 판단한 경우(일반적으로 15-20% 이상), 셋째, 통계 정보가 오래되어 실제 데이터 분포를 반영하지 못하는 경우입니다. Cardinality는 고유 값의 수로 인덱스 효율성을 결정하며, Selectivity는 조건을 만족하는 행의 비율로 옵티마이저가 인덱스 스캔과 시퀀셜 스캔 중 선택하는 기준이 됩니다. Covering Index는 쿼리에 필요한 모든 컬럼을 인덱스에 포함시켜 테이블 접근을 제거하며, PostgreSQL의 INCLUDE 절로 구현 가능합니다. 실무에서는 ANALYZE 명령으로 통계를 갱신하고, 복합 인덱스의 컬럼 순서를 Selectivity 높은 순으로 배치하며, 날짜 범위와 같이 자주 변경되는 조건은 파티셔닝과 병행하는 전략을 사용합니다.

Read Committed에서는 트랜잭션이 잔여 좌석을 읽고(10석), 예약 가능 판단 후 업데이트하는 사이 다른 트랜잭션이 먼저 커밋하면 Lost Update가 발생합니다. Repeatable Read는 첫 읽기 시점의 스냅샷을 유지하지만 PostgreSQL에서는 쓰기 충돌 시 먼저 커밋한 트랜잭션만 성공하고 나머지는 롤백되며, Serializable은 SSI를 통해 직렬화 가능성을 검증해 이상 현상을 완전히 차단하지만 재시도 로직이 필요합니다. MySQL의 Gap Lock은 범위 내 존재하지 않는 레코드까지 잠그고, Next-Key Lock은 레코드와 그 앞 갭을 함께 잠가 Phantom Read를 방지하지만 동시성이 저하됩니다. PostgreSQL의 SSI는 잠금 없이 충돌을 감지해 동시성이 높지만 재시도 오버헤드가 있습니다. 예약 시스템에서는 충돌 빈도가 높으면 SELECT FOR UPDATE로 비관적 잠금을 사용하고, 충돌이 드물면 버전 컬럼 기반 낙관적 잠금으로 동시성을 높이며, 대기열 시스템과 결합해 피크 시간대 부하를 분산하는 전략을 병행합니다.

Serverless 환경에서는 각 Lambda 인스턴스가 독립적으로 커넥션 풀을 생성하므로, 동시 실행 수가 100개면 connection_limit이 5일 때 최대 500개 커넥션이 생성되어 DB 한계를 초과할 수 있습니다. Cold Start 시 풀 초기화로 첫 요청 지연이 발생하며, 사용 후 유휴 커넥션이 Lambda 수명 동안 유지되어 비효율적입니다. PgBouncer의 Transaction 모드는 트랜잭션 단위로 커넥션을 반환해 풀 효율이 높지만 Prepared Statement와 Session 변수 사용이 제한되며, Session 모드는 클라이언트 세션 동안 커넥션을 유지해 호환성은 높지만 동시성이 낮습니다. Serverless에서는 connection_limit을 1-2로 최소화하고 PgBouncer를 Transaction 모드로 운영하며, Container 환경에서는 인스턴스 수 × connection_limit가 DB max_connections의 70%를 넘지 않도록 설정합니다. pool_timeout은 애플리케이션 응답 시간보다 짧게 설정해 빠른 실패를 유도하고, RDS Proxy는 IAM 인증과 자동 페일오버를 제공해 보안과 가용성을 강화합니다.

Range Partitioning은 날짜나 숫자 범위로 분할해 시계열 데이터에 최적이며 파티션 프루닝 효과가 크고, List Partitioning은 카테고리별 분할에 적합하지만 분포 불균형 위험이 있으며, Hash Partitioning은 균등 분산이 가능하지만 범위 쿼리에서 모든 파티션을 스캔해야 합니다. 시계열 데이터는 월 단위 Range Partitioning을 사용하며, WHERE 절에 파티션 키가 포함되면 옵티마이저가 해당 파티션만 스캔하는 Partition Pruning으로 I/O를 획기적으로 줄입니다. 파티션 자동 생성은 pg_cron이나 애플리케이션 레벨에서 구현하며, 오래된 데이터 삭제 시 DROP PARTITION은 메타데이터만 제거해 즉각적이고 WAL 생성이 없어 가장 빠르며, TRUNCATE는 테이블 구조 유지하며 빠르고, DELETE는 행 단위 삭제로 WAL과 VACUUM 부담이 큽니다. 파티션 키는 쿼리의 WHERE 절에 자주 등장하고 Cardinality가 적절해야 하며(너무 높으면 파티션 과다, 너무 낮으면 불균형), 복합 파티셔닝(날짜+지역)으로 쿼리 패턴에 맞춰 최적화합니다.