Node.js 리드·아키텍트 데이터베이스 면접

파티셔닝은 단일 DB 내에서 테이블을 논리적으로 분할하는 방식으로, 주로 시계열 데이터(월별/연도별)나 지역별 분할에 적합하며 애플리케이션 코드 변경이 거의 없습니다. 샤딩은 데이터를 여러 DB 인스턴스로 물리적으로 분산하는 방식으로, 단일 DB 성능 한계를 넘어서거나 지리적 분산이 필요할 때 사용하며, Node.js에서는 샤드 키 기반 라우팅 로직과 분산 트랜잭션 처리를 구현해야 합니다. 아카이빙은 오래된 데이터를 별도 스토리지로 이관하는 방식으로, 최근 3-6개월 데이터만 주로 조회되는 패턴에 적합하며, 통합 조회가 필요한 경우 CQRS 패턴이나 데이터 레이크를 함께 고려해야 합니다. Node.js 레벨에서는 커넥션 풀 관리, 쿼리 라우팅 미들웨어, 읽기 전용 레플리카 활용, 그리고 Sequelize나 TypeORM 같은 ORM의 파티션/샤드 지원 여부를 검토해야 합니다. 비용 측면에서는 파티셔닝이 가장 경제적이고, 샤딩은 인프라 비용과 운영 복잡도가 높으며, 아카이빙은 스토리지 비용 최적화에 유리합니다.

먼저 실제 쿼리 로그를 분석하여 가장 빈번하게 사용되는 필터 조합 상위 5-10개를 파악하고, 카디널리티가 높고 선택도가 좋은 컬럼(카테고리, 브랜드 등)을 우선순위로 복합 인덱스를 생성합니다. 복합 인덱스 컬럼 순서는 등호 조건, 범위 조건, 정렬 조건 순으로 배치하며, 가격 범위 같은 범위 조건은 인덱스 마지막에 위치시킵니다. 자주 조회되는 컬럼들을 포함한 커버링 인덱스를 생성하여 테이블 액세스를 최소화하고, 단일 컬럼 인덱스들이 인덱스 머지로 활용될 수 있도록 구성합니다. Node.js 레벨에서는 쿼리 빌더 패턴을 활용해 조건 유무에 따라 동적으로 최적 쿼리를 생성하고, 복잡한 조합 검색은 Elasticsearch 같은 검색 엔진으로 오프로드하는 하이브리드 아키텍처를 고려합니다. 또한 Redis를 활용한 결과 캐싱과 쿼리 실행 계획 모니터링을 통해 지속적으로 인덱스 효율성을 검증하고, Slow Query Log 분석을 자동화하여 인덱스 전략을 개선합니다.

Read Committed에서는 같은 트랜잭션 내에서 같은 데이터를 두 번 읽을 때 다른 값이 나올 수 있는 Non-repeatable read와, 범위 쿼리 시 새로운 행이 추가되는 Phantom read가 발생할 수 있으며, Repeatable Read는 Phantom read만, Serializable은 모든 문제를 방지하지만 락 경합으로 처리량이 크게 감소합니다. 비관적 락은 SELECT FOR UPDATE를 사용하여 트랜잭션 시작 시 행을 잠그는 방식으로, Sequelize에서는 transaction.LOCK 옵션으로 구현하며, 충돌이 빈번한 경우 적합하지만 데드락 위험이 있습니다. 낙관적 락은 version 컬럼을 활용해 UPDATE 시 version을 비교하여 충돌을 감지하는 방식으로, 충돌이 드문 경우 높은 동시성을 제공하지만 재시도 로직이 필요합니다. 금융 이체처럼 정합성이 중요한 경우 Repeatable Read + 비관적 락을 사용하고, 재고 차감처럼 충돌이 적은 경우 Read Committed + 낙관적 락을 사용하며, 극도로 높은 동시성이 필요한 경우 Redis 분산 락이나 메시지 큐를 활용한 순차 처리를 고려합니다. Node.js에서는 트랜잭션 타임아웃 설정, 데드락 감지 및 재시도 로직, 그리고 APM 도구를 통한 락 대기 시간 모니터링이 필수적입니다.

첫 번째로 EXPLAIN ANALYZE로 실행 계획을 분석하여 Full Table Scan 발생 원인을 파악하고, JOIN 조건과 WHERE 절에 적절한 인덱스를 추가하며, JOIN 순서를 작은 테이블부터 시작하도록 최적화합니다. Using filesort를 해결하기 위해 ORDER BY 컬럼에 인덱스를 생성하고, GROUP BY 컬럼 순서를 인덱스 컬럼 순서와 일치시키며, 필요시 커버링 인덱스를 구성합니다. 쿼리 자체를 여러 개의 작은 쿼리로 분할하거나, 서브쿼리를 JOIN으로 변경하고, 불필요한 컬럼 조회를 제거하여 결과셋 크기를 줄입니다. 아키텍처 레벨에서는 집계 결과를 Materialized View나 별도 집계 테이블로 미리 계산하여 저장하고, Node.js에서 node-cron으로 주기적으로 업데이트하는 방식을 고려합니다. CQRS 패턴을 적용하여 읽기 전용 복제본이나 Redis, MongoDB 같은 읽기 최적화 스토어로 데이터를 동기화하거나, 실시간성이 중요하지 않다면 비동기 처리 후 결과를 캐싱하는 전략을 사용합니다. 마지막으로 ClickHouse나 BigQuery 같은 분석 전용 DB로 데이터를 ETL하여 대시보드 쿼리를 오프로드하는 방안도 검토합니다.

데이터베이스 행 락(SELECT FOR UPDATE)은 트랜잭션 범위 내에서 자동으로 관리되고 ACID를 보장하지만, 트랜잭션이 길어지면 락 대기 시간이 증가하고 데드락 위험이 있으며, 커넥션을 점유하여 커넥션 풀 고갈 문제가 발생할 수 있습니다. 갭 락은 Repeatable Read 이상에서 범위 조건 시 자동 적용되어 Phantom read를 방지하지만, 의도치 않은 넓은 범위 잠금으로 동시성이 크게 저하될 수 있습니다. Redis 분산 락(Redlock 알고리즘)은 DB 커넥션과 독립적으로 동작하여 타임아웃 제어가 명확하고, Node.js 멀티 인스턴스 환경에서도 일관된 락을 제공하지만, Redis 장애 시 락이 해제되지 않거나 중복 획득되는 문제가 있어 TTL 설정이 중요합니다. DB named lock(GET_LOCK)은 트랜잭션과 독립적이고 명시적 제어가 가능하지만, 커넥션을 별도로 사용해야 하고 애플리케이션에서 락 해제를 보장해야 합니다. 예약 시스템처럼 짧은 트랜잭션에서는 SELECT FOR UPDATE + Repeatable Read가 적합하고, 외부 API 호출이 포함된 긴 작업에서는 Redis 분산 락을 사용하며, Node.js에서는 ioredis의 Redlock 라이브러리나 node-redlock을 활용하고, 락 획득 실패 시 재시도 로직과 최대 대기 시간을 설정해야 합니다. 모니터링 측면에서는 락 대기 시간, 데드락 발생 빈도, Redis 락 TTL 만료 현황을 추적하고, Circuit Breaker 패턴으로 락 획득 실패 시 빠르게 실패 처리하는 것이 중요합니다.