React 주니어 데이터베이스 기술면접

트랜잭션은 여러 작업을 하나의 논리적 단위로 묶어 모두 성공하거나 모두 실패하도록 보장합니다. 결제 시나리오에서 주문은 생성되었지만 재고 차감이 실패하면 실제 재고보다 많은 주문이 발생하는 데이터 불일치 문제가 생깁니다. ACID 속성 중 원자성(Atomicity)이 가장 중요한데, 이는 트랜잭션 내 모든 작업이 완전히 수행되거나 전혀 수행되지 않음을 보장합니다. 일관성(Consistency)도 중요하며, 데이터베이스가 트랜잭션 전후로 유효한 상태를 유지하도록 합니다. 트랜잭션 실패 시 롤백을 통해 이전 상태로 되돌릴 수 있습니다.

Race Condition은 여러 요청이 동시에 쿠폰 잔여 수량을 조회하고 차감할 때, 실제보다 많은 쿠폰이 발급되는 문제입니다. 예를 들어 잔여 1개일 때 10명이 동시에 조회하면 모두 발급 가능하다고 판단해 10개가 발급될 수 있습니다. 이를 해결하기 위해 비관적 락(Pessimistic Lock)을 사용하면 SELECT FOR UPDATE 구문으로 데이터를 읽는 동안 다른 트랜잭션의 접근을 차단합니다. 낙관적 락(Optimistic Lock)은 버전 컬럼을 두고 수정 시 버전을 확인해 충돌을 감지합니다. 선착순 이벤트처럼 충돌이 빈번한 경우 비관적 락이 더 적합하며, Redis 같은 인메모리 DB의 원자적 연산도 대안이 될 수 있습니다.

먼저 날짜 컬럼에 인덱스가 있는지 확인해야 합니다. 인덱스가 없으면 Full Table Scan이 발생해 모든 데이터를 검색하므로 느립니다. 날짜 범위 검색에는 B-Tree 인덱스를 생성하면 효과적입니다. EXPLAIN 명령어로 실행 계획을 분석해 인덱스가 실제로 사용되는지 확인해야 합니다. WHERE 절에서 날짜 컬럼에 함수를 적용하면 인덱스를 타지 않으므로 피해야 합니다. 필요한 컬럼만 SELECT하고 불필요한 JOIN을 제거하며, 결과가 많다면 페이지네이션을 적용해 한 번에 가져오는 데이터 양을 줄여야 합니다. 복합 인덱스가 필요한 경우 WHERE 절의 조건 순서를 고려해 생성합니다.

다대다 관계는 중간 테이블(Junction Table 또는 Bridge Table)을 사용해 두 개의 일대다 관계로 분해합니다. Order와 Product 사이에 OrderItem이라는 중간 테이블을 생성합니다. OrderItem 테이블은 order_id와 product_id를 외래키로 가지며, 두 컬럼을 조합해 복합 기본키로 설정하거나 별도의 id를 기본키로 둡니다. 중간 테이블에는 수량(quantity), 가격(price) 같은 관계에 대한 추가 속성도 저장할 수 있습니다. 이렇게 설계하면 한 주문에 여러 상품을, 한 상품이 여러 주문에 포함되는 것을 표현할 수 있으며 데이터 중복도 방지됩니다.

인덱스는 추가 저장 공간을 차지하며, 테이블 크기의 10-20% 정도를 사용합니다. INSERT, UPDATE, DELETE 작업 시 인덱스도 함께 수정해야 하므로 쓰기 성능이 저하됩니다. 특히 인덱스가 많을수록 쓰기 작업이 느려집니다. 카디널리티가 낮은 컬럼(성별, boolean 같이 값의 종류가 적은 경우)은 인덱스 효과가 미미합니다. 테이블 크기가 작거나(수천 건 이하) 조회보다 쓰기가 빈번한 경우 인덱스가 오히려 성능을 저하시킬 수 있습니다. 따라서 조회가 빈번하고, 카디널리티가 높으며, 테이블 크기가 충분히 큰 컬럼에만 선택적으로 인덱스를 생성해야 합니다.