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

단일 테이블은 구조가 단순하지만 인덱스 크기 증가로 쓰기 성능이 저하되고 풀스캔 시 비효율적입니다. 파티셔닝(날짜 기준)은 최근 데이터 조회가 빠르고 오래된 파티션 삭제가 용이하지만 파티션 간 조인이 비효율적이고 파티션 키 선택이 중요합니다. 아카이빙은 운영 DB 크기를 최소화하고 성능을 최적화하지만 별도 스토리지 비용과 과거 데이터 조회 시 복잡도가 증가합니다. 결정 기준은 최근 3개월 데이터의 조회 비율이 90% 이상이면 아카이빙, 전체 기간 분석 쿼리가 빈번하면 파티셔닝, 데이터 증가율이 낮으면 단일 테이블을 선택합니다. CI/CD 파이프라인에서는 파티셔닝 전략 변경 시 무중단 마이그레이션 스크립트와 롤백 계획이 필수입니다.

복합 인덱스 컬럼 순서는 첫째로 WHERE 절의 등호(=) 조건 컬럼을 우선하고, 둘째로 높은 카디널리티 컬럼을 앞에 배치하며, 셋째로 범위 조건(<, >) 컬럼을 마지막에 둡니다. 실제 환경에서는 슬로우 쿼리 로그와 실행 계획(EXPLAIN)을 분석하여 인덱스 스캔 범위가 넓거나 Using filesort가 발생하는지 확인합니다. 인덱스 사용 통계(sys.schema_unused_indexes)로 미사용 인덱스를 파악하고, 쿼리 패턴 변화에 따라 인덱스를 재설계합니다. 개선 시에는 새 인덱스를 먼저 생성하고 충분한 모니터링 후 기존 인덱스를 삭제하며, 인덱스 생성 시 ONLINE DDL을 사용하여 서비스 중단을 방지합니다. CI/CD 파이프라인에 인덱스 변경 스크립트를 포함하고 카나리 배포로 성능 영향을 검증합니다.

서비스별로 다른 격리 수준을 사용하면 한 서비스는 READ COMMITTED로 커밋되지 않은 데이터를 보지 않지만, 다른 서비스는 READ UNCOMMITTED로 더티 리드를 허용하여 데이터 일관성 문제가 발생합니다. REPEATABLE READ 서비스는 팬텀 리드를 방지하지만 SERIALIZABLE 서비스와 락 경합이 발생하여 데드락 가능성이 높아집니다. 관리 방법으로는 첫째, 조직 전체에 표준 격리 수준(일반적으로 READ COMMITTED)을 정의하고 예외는 아키텍처 리뷰를 거칩니다. 둘째, DB 공유 대신 Database per Service 패턴으로 전환하고 Saga 패턴으로 분산 트랜잭션을 관리합니다. 셋째, 공유가 불가피하면 스키마 레벨로 분리하고 서비스 간 직접 테이블 접근을 금지하며 API를 통해서만 통신하도록 강제합니다.

데드락 원인 파악은 SHOW ENGINE INNODB STATUS로 최근 데드락 로그를 확인하고, 어떤 트랜잭션들이 어떤 순서로 락을 획득하려 했는지 분석합니다. 일반적으로 서로 다른 순서로 여러 테이블이나 로우를 락하려 할 때 발생합니다. 해결 방안으로 첫째, 모든 트랜잭션이 동일한 순서로 테이블과 로우에 접근하도록 코드를 표준화합니다. 둘째, 트랜잭션 범위를 최소화하고 긴 트랜잭션을 여러 작은 트랜잭션으로 분리합니다. 셋째, 비관적 락(SELECT FOR UPDATE) 대신 버전 컬럼을 사용한 낙관적 락으로 전환하여 락 경합을 줄입니다. 넷째, 재고 차감 같은 경합이 심한 작업은 Redis나 메시지 큐로 직렬화합니다. 다섯째, 데드락 재시도 로직을 애플리케이션에 구현하되 최대 재시도 횟수를 제한합니다.

N+1 문제 식별은 APM 도구나 ORM 쿼리 로깅을 활성화하여 동일한 패턴의 쿼리가 반복 실행되는지 확인하고, 특정 API 응답 시간이 데이터 건수에 비례하여 증가하는지 모니터링합니다. 즉시 해결책으로는 ORM의 Eager Loading(JPA의 fetch join, N+1 방지 어노테이션)을 사용하거나 배치 쿼리로 변환합니다. 쿼리 결과를 애플리케이션에서 조인하는 방법도 고려합니다. 장기적으로는 CQRS 패턴을 도입하여 조회용 비정규화 테이블이나 Read Model을 별도로 구성하고, 복잡한 조인이 필요한 데이터는 Materialized View나 캐시 레이어에 저장합니다. GraphQL DataLoader 같은 배치 로딩 패턴을 적용하거나, 마이크로서비스 환경에서는 BFF(Backend for Frontend)에서 데이터를 조합하여 제공합니다.

정규화는 데이터 중복을 제거하여 일관성을 보장하고 갱신 이상을 방지하지만, 조인이 많아져 읽기 성능이 저하됩니다. 비정규화는 조인을 줄여 읽기 성능을 향상시키지만 데이터 중복으로 스토리지 비용이 증가하고 갱신 시 일관성 유지가 어렵습니다. 적용 기준으로 OLTP 시스템에서 쓰기가 빈번하고 데이터 일관성이 중요하면 정규화를 우선하고, OLAP이나 분석 시스템처럼 읽기 중심이고 복잡한 조인이 필요하면 비정규화합니다. 실시간 대시보드나 검색 기능처럼 응답 속도가 중요한 경우 비정규화하되, 원본 데이터는 정규화 상태로 유지하고 비정규화 데이터는 캐시나 Materialized View로 구성합니다. 마이크로서비스에서는 서비스 내부는 정규화하고 서비스 간 데이터 공유는 비정규화된 이벤트나 API 응답으로 처리합니다.

커버링 인덱스는 쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 있어 테이블 접근 없이 인덱스만으로 결과를 반환할 수 있는 인덱스입니다. SELECT와 WHERE 절의 모든 컬럼이 인덱스에 있으면 실행 계획에서 Using index가 표시되며 성능이 크게 향상됩니다. 주의점으로 첫째, 인덱스에 컬럼을 추가하면 인덱스 크기가 증가하여 메모리 사용량이 늘어나고 쓰기 성능이 저하됩니다. 둘째, 자주 변경되는 컬럼을 인덱스에 포함하면 인덱스 갱신 비용이 증가합니다. 셋째, VARCHAR나 TEXT 같은 큰 컬럼은 인덱스 크기를 급격히 증가시키므로 신중히 판단합니다. 넷째, 쿼리 패턴이 변경되면 커버링 인덱스가 불필요해질 수 있으므로 주기적으로 사용 통계를 모니터링하고 정리합니다.

2PC는 준비 단계와 커밋 단계로 나뉘어 원자성을 보장하지만, 코디네이터 장애 시 참여자들이 무한정 대기하는 블로킹 문제가 있고 성능이 저하되며 가용성이 낮아집니다. Saga 패턴은 각 서비스가 로컬 트랜잭션을 실행하고 실패 시 보상 트랜잭션으로 롤백하며, 이벤트 기반으로 느슨한 결합을 유지하지만 일시적 불일치 상태를 허용해야 합니다. 주문-결제-배송 같은 비즈니스 프로세스에 적합합니다. TCC(Try-Confirm-Cancel)는 리소스를 예약하고 확정하거나 취소하는 방식으로 일관성을 높이지만 비즈니스 로직이 복잡해지며, 좌석 예약이나 재고 예약에 적합합니다. Event Sourcing은 상태 변경을 이벤트로 저장하여 완전한 이력 추적이 가능하지만 쿼리 복잡도가 증가하며, 감사 로그가 중요한 금융 시스템에 적합합니다.

실행 계획에서 첫째, 스캔 방식(type)을 확인하여 ALL(풀 테이블 스캔)이나 index(인덱스 풀 스캔)는 개선 대상이고, ref나 range는 적절하며, const나 eq_ref가 이상적입니다. 둘째, rows(예상 스캔 행 수)가 실제 결과보다 훨씬 크면 불필요한 데이터를 읽는 것이므로 인덱스 추가나 쿼리 재작성이 필요합니다. 셋째, Extra 필드에서 Using filesort나 Using temporary는 디스크 I/O를 유발하므로 인덱스로 정렬을 처리하도록 개선합니다. 넷째, 조인 순서와 조인 타입을 확인하여 작은 테이블을 먼저 읽고 Nested Loop보다 Hash Join이 효율적인지 판단합니다. 튜닝 우선순위는 실행 빈도가 높고 응답 시간이 긴 쿼리를 먼저 개선하며, 스캔 행 수가 많은 순서대로 처리하고, 비즈니스 임팩트가 큰 API부터 최적화합니다.

MySQL 5.6 이상의 Online DDL을 사용하면 대부분의 스키마 변경을 잠금 없이 수행할 수 있지만, 테이블 크기가 크면 복제 지연이 발생할 수 있습니다. Percona의 pt-online-schema-change나 gh-ost 같은 도구는 새 테이블을 생성하고 트리거로 변경사항을 복제한 후 원자적으로 테이블을 교체하여 안전합니다. 전략으로 첫째, 변경 전 충분한 테스트 환경에서 실행 시간과 복제 지연을 측정합니다. 둘째, 피크 시간을 피해 트래픽이 낮은 시간대에 실행하고 모니터링을 강화합니다. 셋째, 컬럼 추가 시 NOT NULL 제약은 나중에 추가하고, 처음엔 NULL 허용으로 생성 후 데이터 마이그레이션 후 제약을 추가합니다. CI/CD 통합은 스키마 변경을 별도 마이그레이션 스크립트로 관리하고, Flyway나 Liquibase로 버전 관리하며, 배포 파이프라인에서 Blue-Green 배포나 카나리 배포와 함께 단계적으로 적용합니다. 롤백 스크립트를 항상 준비하고 변경 전후 데이터 정합성을 검증합니다.