Spring 리드·아키텍트 데이터베이스 기술면접

주문 데이터는 시간 기반 조회가 주를 이루므로 Range 파티셔닝(월별 또는 분기별)을 우선 적용하고, 1년 이상 경과한 데이터는 별도 아카이브 테이블로 이관하는 하이브리드 전략을 추천합니다. 파티셔닝은 테이블 구조 변경 없이 투명하게 적용 가능하며, 파티션 프루닝으로 쿼리 성능을 개선할 수 있습니다. 샤딩은 단일 DB 한계를 넘는 경우에만 고려하되, 애플리케이션 레벨에서 샤드 키 관리와 크로스 샤드 쿼리 처리가 필요해 복잡도가 높습니다. 통계 집계를 위해서는 별도의 OLAP용 데이터 마트를 구축하고, CDC(Change Data Capture)를 통해 실시간 동기화하는 방식으로 OLTP와 OLAP를 분리합니다. Spring Batch를 활용해 주기적으로 오래된 데이터를 아카이빙하고, JPA의 @Where 애노테이션이나 Hibernate Filter로 활성 데이터만 조회하도록 애플리케이션 레벨에서 제어합니다.

다중 테넌트 환경에서는 tenant_id를 복합 인덱스의 선두 컬럼으로 배치하여 테넌트별 데이터 격리와 빠른 필터링을 보장합니다. 이후 컬럼은 쿼리 패턴에 따라 선택도가 높은 순서로 배치하며, WHERE 절에 자주 사용되는 컬럼들을 모두 포함한 커버링 인덱스를 구성해 테이블 액세스를 최소화합니다. MySQL의 InnoDB는 클러스터드 인덱스를 사용하므로 세컨더리 인덱스가 PK를 포함하는 구조이며, PostgreSQL은 힙 테이블 구조로 INCLUDE 절을 활용한 커버링 인덱스 구성이 효과적입니다. 대형 테넌트의 데이터 편중 문제는 파티셔닝으로 물리적 분리를 고려하거나, 대형 테넌트 전용 읽기 복제본을 구성하는 방식으로 해결합니다. 인덱스 크기 모니터링을 위해 pg_stat_user_indexes나 INFORMATION_SCHEMA를 주기적으로 확인하고, 사용되지 않는 인덱스는 제거하여 메모리 효율성을 유지합니다.

재고 차감과 같은 높은 동시성 시나리오에서는 Optimistic Lock을 우선 고려하되, 충돌률이 높으면 Pessimistic Lock이나 분산 락을 적용합니다. Optimistic Lock은 @Version을 사용해 UPDATE 시점에 버전 체크로 충돌을 감지하며, 충돌 시 ObjectOptimisticLockingFailureException을 발생시켜 재시도 로직이 필요하지만 락 대기가 없어 처리량이 높습니다. Pessimistic Lock은 SELECT FOR UPDATE로 명시적 락을 획득하여 충돌을 원천 차단하지만, 락 대기 시간이 길어지고 데드락 가능성이 있으며, 락 타임아웃 설정이 필수입니다. 분산 락은 Redis의 Redisson이나 Zookeeper를 활용해 멀티 DB 환경에서도 일관성을 보장하지만, 외부 시스템 의존성과 네트워크 레이턴시가 추가됩니다. Serializable 격리 수준은 가장 강력한 일관성을 제공하지만 성능 저하가 크므로 일반적으로 권장하지 않습니다. 실무에서는 충돌률이 낮으면 Optimistic Lock + 재고 부족 시 즉시 실패 처리, 충돌률이 높으면 Redis 분산 락 + 재고 캐싱 전략을 조합합니다.

N+1 문제 해결의 기본은 Fetch Join으로, JPQL에서 'JOIN FETCH'를 사용해 한 번의 쿼리로 연관 엔티티를 로딩합니다. 하지만 페이징과 함께 사용 시 메모리 페이징이 발생하므로, 이 경우 @BatchSize나 hibernate.default_batch_fetch_size로 IN 절 배치 로딩을 적용합니다. ToOne 관계는 Fetch Join, ToMany 관계는 Batch Size 조합이 효과적이며, 복수의 컬렉션 Fetch Join 시 MultipleBagFetchException 발생을 주의해야 합니다. 읽기 전용 화면은 DTO Projection으로 필요한 컬럼만 조회하여 메모리 사용량을 줄이고, @Transactional(readOnly=true)로 flush 모드를 MANUAL로 설정해 변경 감지 오버헤드를 제거합니다. OSIV는 뷰 렌더링까지 영속성 컨텍스트를 유지해 Lazy Loading이 가능하지만, 커넥션 점유 시간이 길어지므로 트래픽이 높은 시스템에서는 비활성화하고 명시적 Fetch 전략을 사용합니다. 복잡한 집계나 동적 쿼리는 QueryDSL로, DB 특화 기능이 필요하면 Native Query를 사용하되 결과를 DTO로 매핑합니다.

대용량 테이블의 무중단 스키마 변경은 Expand-Contract 패턴을 따릅니다. NOT NULL 컬럼 추가는 1단계로 NULL 허용 컬럼 추가 및 기본값 설정, 2단계로 애플리케이션에서 해당 컬럼 사용, 3단계로 기존 데이터 마이그레이션, 4단계로 NOT NULL 제약 추가 순으로 진행합니다. 인덱스 생성은 CONCURRENTLY 옵션(PostgreSQL) 또는 ALGORITHM=INPLACE(MySQL)를 사용해 락을 최소화하며, 대용량 테이블은 피크 시간을 피해 야간에 실행합니다. 컬럼 타입 변경은 새 컬럼 추가 후 데이터 복사, 애플리케이션 전환, 구 컬럼 삭제 순서로 점진적 전환하며, 테이블 분리는 듀얼 라이트 패턴으로 양쪽 테이블에 동시 쓰기 후 점진적으로 읽기를 전환합니다. Flyway는 버전 기반 마이그레이션 스크립트를 관리하며, 각 스크립트는 멱등성을 보장하고 롤백 스크립트를 함께 작성합니다. 배포 순서는 하위 호환 스키마 먼저 배포 후 애플리케이션 배포, 마지막으로 구 스키마 제거 순으로 진행하며, 마이그레이션 실패 시 트랜잭션 롤백과 버전 테이블 상태 확인으로 정합성을 보장합니다.