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

무중단 스키마 마이그레이션은 Expand-Contract(Parallel Change) 패턴을 따릅니다. 먼저 새로운 테이블(주문 헤더, 주문 상세)을 생성하고 기존 테이블과 병행 운영하며, 애플리케이션 레이어에서 Dual Write를 구현하여 양쪽에 동시 기록합니다. TypeScript에서는 Union 타입과 타입 가드를 활용해 구 스키마와 신 스키마를 모두 처리할 수 있는 Repository 패턴을 구현하고, Feature Flag로 읽기 소스를 점진적으로 전환합니다. 데이터 동기화는 별도의 백그라운드 작업으로 수행하며, 체크섬 검증으로 정합성을 보장합니다. 모든 데이터가 마이그레이션되고 신규 스키마로 완전히 전환된 후, 구 테이블과 Dual Write 로직을 제거하는 Contract 단계를 진행합니다. 각 단계마다 롤백 계획을 수립하고, TypeScript의 Discriminated Union을 활용해 컴파일 타임에 스키마 버전 불일치를 감지할 수 있도록 설계합니다.

다중 테넌트 환경에서는 tenant_id를 복합 인덱스의 선두 컬럼으로 배치하여 테넌트별 데이터 격리를 효율화합니다. 복합 검색 쿼리의 경우 실제 쿼리 패턴을 분석하여 (tenant_id, created_at, status) 또는 (tenant_id, category, status)처럼 자주 사용되는 조합별로 인덱스를 생성합니다. Covering Index를 활용하면 SELECT 절의 컬럼까지 인덱스에 포함시켜 테이블 액세스를 제거할 수 있습니다. Partial Index는 특정 상태(예: active)만 자주 조회되는 경우 WHERE status = 'active' 조건으로 인덱스 크기를 줄이고 성능을 향상시킵니다. TypeScript에서는 Repository 패턴에 쿼리 빌더를 추상화하고, 각 메서드에 JSDoc으로 사용되는 인덱스를 명시하여 개발자가 인덱스를 인지하도록 합니다. 또한 타입 레벨에서 필수 필터(tenant_id)를 강제하는 인터페이스를 설계하여 인덱스를 활용하지 못하는 쿼리를 컴파일 타임에 방지합니다.

재고 초과 판매는 Read Committed 격리 수준에서 SELECT-UPDATE 사이의 Lost Update 문제입니다. Serializable 격리 수준으로 변경하면 완벽한 격리를 보장하지만 동시성이 크게 저하되고 직렬화 오류가 빈번합니다. 비관적 락(SELECT FOR UPDATE)은 재고 조회 시점에 행 잠금을 획득하여 다른 트랜잭션을 대기시키므로 데이터 정합성을 보장하지만, 락 경합으로 인한 대기 시간과 데드락 위험이 있습니다. 낙관적 락(version 컬럼)은 충돌 시 재시도가 필요하며 충돌률이 높은 재고 시스템에서는 비효율적입니다. Redis 등 외부 저장소를 활용한 분산 락은 데이터베이스 부하를 분산하지만 복잡도가 증가합니다. 재고 시스템에서는 SELECT FOR UPDATE를 사용한 비관적 락이 가장 적합하며, TypeScript에서는 트랜잭션 범위를 최소화하고 락 획득 타임아웃을 설정하여 데드락을 방지합니다. 또한 재고 차감을 원자적 UPDATE(SET quantity = quantity - 1 WHERE quantity >= 1)로 변경하여 SELECT를 제거하는 방법도 효과적입니다.