운영체제 리드·아키텍트 데이터베이스 기술면접

READ COMMITTED는 각 쿼리마다 새로운 스냅샷을 생성하여 커밋된 데이터만 읽지만 Non-Repeatable Read와 Phantom Read가 발생할 수 있습니다. REPEATABLE READ는 트랜잭션 시작 시점의 스냅샷을 유지하여 Non-Repeatable Read를 방지하지만, MySQL InnoDB는 Next-Key Lock으로 Phantom Read도 방지합니다. MVCC 구현에서 READ COMMITTED는 Undo 로그를 짧게 유지할 수 있어 메모리 효율적이지만, REPEATABLE READ는 장기 트랜잭션 시 Undo 로그가 누적되어 퍼지(Purge) 지연을 유발할 수 있습니다. 금융 시스템에서는 일반적으로 데이터 일관성이 중요하므로 REPEATABLE READ를 선택하되, 대량 조회나 분석 쿼리는 별도 읽기 전용 복제본에서 READ COMMITTED로 처리하는 하이브리드 전략을 권장합니다. 격리 수준이 높을수록 Lock 경합과 Rollback Segment 크기가 증가하므로, 트랜잭션 지속 시간을 최소화하는 것이 핵심입니다.

데드락은 두 개 이상의 트랜잭션이 서로가 보유한 Lock을 기다리며 무한 대기 상태에 빠지는 현상으로, Mutual Exclusion(배타적 Lock), Hold and Wait(보유 및 대기), No Preemption(선점 불가), Circular Wait(순환 대기)의 4가지 조건이 모두 충족될 때 발생합니다. Wait-for Graph는 트랜잭션을 노드로, 대기 관계를 간선으로 표현하여 사이클을 탐지하며, 사이클 발견 시 희생자를 선택해 롤백합니다. 애플리케이션 레벨에서는 모든 트랜잭션이 동일한 순서로 테이블/행을 접근하도록 강제하고, 트랜잭션 범위를 최소화하며, SELECT ... FOR UPDATE 사용 시 NOWAIT 또는 SKIP LOCKED 옵션을 활용합니다. 데이터베이스 레벨에서는 innodb_lock_wait_timeout을 적절히 설정하고, 인덱스 최적화로 Lock 범위를 줄이며, 필요시 낙관적 Lock(버전 관리)으로 전환합니다. 모니터링 측면에서는 information_schema.innodb_trx와 innodb_locks를 주기적으로 분석하여 데드락 패턴을 식별하고 쿼리를 개선해야 합니다.

B-Tree는 정렬된 트리 구조로 제자리 업데이트(in-place update)를 수행하며 읽기에 최적화되어 있지만, 랜덤 쓰기 시 디스크 I/O가 많고 Write Amplification이 높습니다. LSM-Tree는 메모리의 MemTable에 쓰기를 버퍼링한 후 SSTable로 순차 플러시하여 쓰기 성능이 우수하지만, 읽기 시 여러 레벨을 검색해야 하므로 Read Amplification이 발생합니다. 로그 수집 시스템처럼 쓰기가 많고 최신 데이터 조회가 주된 경우 LSM-Tree(RocksDB, Cassandra)가 적합하며, OLTP 시스템처럼 포인트 쿼리와 트랜잭션 일관성이 중요한 경우 B-Tree(MySQL, PostgreSQL)가 유리합니다. LSM-Tree의 Compaction은 레벨 간 SSTable을 병합하여 읽기 성능을 개선하지만, Major Compaction 시 CPU와 I/O 부하가 급증하므로 Leveled, Tiered, Hybrid 전략 중 워크로드에 맞는 선택이 필요합니다. 실무에서는 쓰기 처리량과 읽기 지연시간, 공간 증폭률(Space Amplification)을 모니터링하며 Compaction 스케줄을 조정해야 합니다.

Nested Loop Join은 외부 테이블의 각 행마다 내부 테이블을 스캔하며 O(N*M) 복잡도를 가지지만, 내부 테이블에 인덱스가 있으면 O(N*logM)으로 개선되어 소규모 결과셋에 효율적입니다. Hash Join은 작은 테이블로 해시 테이블을 생성한 후 큰 테이블을 스캔하며 O(N+M) 복잡도로 대용량 테이블 간 등가 조인에 유리하지만, 메모리 부족 시 디스크 스필이 발생합니다. Sort Merge Join은 양쪽 테이블을 정렬 후 병합하며 O(NlogN + MlogM) 복잡도로 비등가 조인이나 이미 정렬된 데이터에 적합합니다. 옵티마이저는 테이블 통계(카디널리티, 히스토그램), 인덱스 존재 여부, 조인 조건의 선택도, 사용 가능한 메모리를 기반으로 비용 기반 선택을 수행합니다. 성능 개선 시에는 EXPLAIN ANALYZE로 실제 실행 통계를 확인하고, 카디널리티 추정 오류는 통계 갱신으로, 인덱스 미사용은 적절한 인덱스 추가로, 조인 순서 오류는 힌트나 쿼리 재작성으로 해결하며, 필요시 서브쿼리를 CTE나 임시 테이블로 분리하여 중간 결과를 구체화합니다.

수평 파티셔닝은 단일 데이터베이스 내에서 테이블을 논리적으로 분할하는 것이며, 샤딩은 여러 물리적 서버에 데이터를 분산하는 것으로 확장성과 가용성 목표가 다릅니다. Range 파티셔닝은 날짜나 ID 범위로 분할하여 시계열 데이터에 적합하지만 데이터 쏠림이 발생할 수 있고, Hash 파티셔닝은 균등 분산이 가능하나 범위 쿼리 시 모든 파티션을 스캔해야 하며, List 파티셔닝은 지역이나 카테고리 같은 명시적 값으로 분할하여 비즈니스 로직에 부합하지만 관리 복잡도가 높습니다. Partition Pruning은 WHERE 절의 파티션 키 조건을 분석하여 불필요한 파티션 스캔을 제거함으로써 쿼리 성능을 향상시킵니다. 파티션 키는 쿼리의 주요 필터 조건이면서 데이터가 균등하게 분포되고, 파티션 개수는 관리 가능한 수준으로 유지되어야 하며, 복합 키 사용 시 첫 번째 컬럼이 가장 선택적이어야 합니다. 파티션 재구성 시에는 Lock으로 인한 서비스 중단, 대량 데이터 이동에 따른 I/O 부하, 인덱스 재생성 시간을 고려하여 온라인 DDL이나 파티션 교환(EXCHANGE PARTITION) 기법을 활용해야 합니다.

동기 복제는 마스터가 모든 복제본의 쓰기 확인을 받은 후 커밋하여 강한 일관성(CP)을 보장하지만 네트워크 지연이나 복제본 장애 시 가용성이 저하됩니다. 비동기 복제는 마스터가 즉시 커밋하고 백그라운드로 복제하여 높은 가용성(AP)과 성능을 제공하지만 복제 지연 동안 데이터 손실 위험과 읽기 불일치가 발생할 수 있습니다. 준동기 복제는 최소 하나의 복제본 확인 후 커밋하여 절충안을 제공하며, MySQL의 rpl_semi_sync_master_wait_for_slave_count로 제어합니다. 복제 지연은 대량 쓰기, 복제본의 낮은 하드웨어 성능, 네트워크 대역폭 부족, 단일 스레드 복제로 인해 발생하며, Seconds_Behind_Master 메트릭과 GTID 기반 포지션 차이를 모니터링하고, 병렬 복제(slave_parallel_workers) 활성화와 복제본 스케일업으로 개선합니다. 읽기 복제본 사용 시에는 세션 내 쓰기 후 읽기(Read-Your-Writes) 일관성을 보장하기 위해 마스터에서 읽거나, GTID 기반으로 복제 완료를 확인한 후 읽기를 수행하거나, 애플리케이션 레벨에서 타임스탬프 기반 라우팅을 구현해야 합니다.

1NF는 각 속성이 원자값을 가져야 하며 반복 그룹을 제거하여 다중값 이상을 방지하고, 2NF는 부분 함수 종속을 제거하여 기본키의 일부에만 종속된 속성을 분리함으로써 삽입/삭제 이상을 해결하며, 3NF는 이행 함수 종속을 제거하여 비키 속성 간 종속성을 분리함으로써 갱신 이상을 방지합니다. 반정규화는 빈번한 조인으로 인한 성능 저하를 개선하기 위해 선택하며, 대표적으로 읽기 중심 시스템의 집계 테이블 추가, 자주 조회되는 참조 데이터의 중복 저장, 계산 컬럼의 사전 저장 등이 있습니다. 반정규화 시 데이터 중복으로 인한 불일치 위험이 있으므로, 트리거나 애플리케이션 로직으로 동기화를 보장하거나, 배치 작업으로 주기적 정합성 검증을 수행하며, 쓰기가 적고 읽기가 많은 데이터에만 제한적으로 적용해야 합니다. 현대적 접근으로는 CQRS 패턴을 활용하여 명령(쓰기)용 정규화 모델과 조회(읽기)용 반정규화 모델을 분리 운영하는 방법도 있습니다.

커버링 인덱스는 쿼리가 필요로 하는 모든 컬럼을 인덱스가 포함하여, 인덱스만 스캔하고 테이블 접근(Table Lookup)을 생략함으로써 랜덤 I/O를 제거하고 성능을 크게 향상시킵니다. 복합 인덱스 컬럼 순서는 등호 조건을 우선 배치하고, 카디널리티가 높은(고유값이 많은) 컬럼을 앞에 두며, 범위 조건이나 정렬 조건을 마지막에 배치하는 것이 원칙이지만, 실제 쿼리 패턴과 선택도를 분석하여 결정해야 합니다. 인덱스 카디널리티가 낮으면(예: 성별, Boolean) 인덱스 스캔 후 대량의 행을 필터링해야 하므로 풀 테이블 스캔보다 비효율적일 수 있습니다. 인덱스가 성능을 저하시키는 경우는 쓰기 작업 시 인덱스 갱신 오버헤드, 인덱스가 너무 많아 옵티마이저 혼란 유발, 인덱스 크기가 커서 버퍼 풀 효율 저하, 낮은 선택도로 인한 비효율적 스캔 등이 있으며, 주기적으로 사용되지 않는 인덱스를 식별하여 제거하고(sys.schema_unused_indexes), 쓰기 중심 테이블은 최소한의 인덱스만 유지해야 합니다.

WAL 프로토콜은 데이터 페이지를 디스크에 쓰기 전에 변경 내역을 트랜잭션 로그에 먼저 기록하여, 커밋 시점에 로그만 디스크에 동기화하면 트랜잭션을 완료할 수 있게 합니다. 원자성은 트랜잭션 시작/커밋/롤백 정보를 로그에 기록하여 장애 시 Undo를 통해 미완료 트랜잭션을 취소하고, 지속성은 커밋된 트랜잭션의 로그를 디스크에 강제 기록(fsync)하여 장애 후 Redo를 통해 복구함으로써 보장됩니다. 체크포인트는 주기적으로 메모리의 더티 페이지를 디스크에 플러시하여 로그에서 재수행해야 할 범위를 줄이고 복구 시간을 단축하며, 체크포인트 LSN 이전의 로그는 복구에 불필요하므로 재사용 가능합니다. 트랜잭션 로그가 증가하는 원인은 장기 실행 트랜잭션, 복제 지연으로 인한 로그 보관, 체크포인트 빈도 부족, 로그 백업 미실행 등이며, 장기 트랜잭션 종료, 복제 지연 해소, 체크포인트 간격 조정, 정기적인 로그 백업으로 해결합니다. SQL Server의 경우 트랜잭션 로그 백업이 필수이며, PostgreSQL은 WAL 아카이빙과 max_wal_size 설정을 관리해야 합니다.

간헐적 성능 저하의 원인으로는 통계 정보가 오래되어 옵티마이저가 잘못된 실행 계획을 선택하는 경우, 파라미터 스니핑으로 첫 실행 시 캐싱된 계획이 다른 파라미터에 부적합한 경우, 버퍼 풀에서 페이지가 제거되어 디스크 I/O가 발생하는 경우, 다른 트랜잭션의 Lock으로 인한 대기 등이 있습니다. Performance Schema의 events_statements_history와 events_waits_history_long을 활성화하여 쿼리별 대기 이벤트를 분석하고, SHOW PROFILE을 통해 쿼리 실행 단계별 시간 소요를 확인하며, sys.statements_with_runtimes_in_95th_percentile 뷰로 이상치를 식별합니다. 평균 응답 시간은 소수의 느린 쿼리가 숨겨질 수 있으므로, P95와 P99 백분위수를 모니터링하여 대부분 사용자가 경험하는 실제 성능과 최악의 경우를 파악해야 하며, 이는 SLA 정의와 성능 개선 우선순위 결정에 필수적입니다. 해결 방법으로는 통계 정보 자동 갱신 설정, 쿼리 힌트나 OPTIMIZE TABLE 실행, 적절한 인덱스 추가, 트랜잭션 범위 축소, 커넥션 풀 크기 조정 등이 있으며, APM 도구를 통한 지속적 모니터링이 중요합니다.