Ruby on Rails 리드·아키텍트 데이터베이스 면접

파티셔닝과 아카이빙 전략을 복합적으로 적용하겠습니다. 먼저 PostgreSQL의 테이블 파티셔닝(Range Partitioning)을 월 단위로 적용해 최근 데이터의 조회 성능을 개선합니다. Rails에서는 abstract class와 connection switching을 활용해 파티션을 투명하게 처리합니다. 1년 이상 된 데이터는 별도 아카이브 DB로 이동하고, read-only 복제본을 구성합니다. Rails 모델에서는 STI나 Delegated Types를 활용해 ActiveOrder와 ArchivedOrder를 분리하고, 통합 조회가 필요한 경우 Union 쿼리나 Elasticsearch 같은 검색 엔진을 활용합니다. 마이그레이션 시에는 zero-downtime 전략으로 dual-write 기간을 두고 점진적으로 전환하며, 데이터 정합성 검증 프로세스를 병행합니다.

먼저 각 필터 컬럼의 카디널리티와 사용 빈도를 분석해 우선순위를 정합니다. 가장 선택성이 높고 자주 사용되는 조건(예: category_id)에는 단일 인덱스를, 자주 함께 사용되는 2-3개 조합(예: category_id, price_range)에는 복합 인덱스를 생성합니다. PostgreSQL의 경우 부분 인덱스(Partial Index)를 활용해 특정 조건의 데이터만 인덱싱하고, BRIN 인덱스를 가격 같은 범위 검색에 활용합니다. Rails에서는 Arel이나 scope를 활용해 쿼리를 구조화하되, EXPLAIN ANALYZE를 CI 파이프라인에 통합해 인덱스 사용 여부를 자동 검증합니다. 복잡한 다중 조건은 Elasticsearch나 Algolia 같은 전문 검색 엔진으로 오프로드하는 것도 고려하며, 인덱스 유지보수 비용과 쿼리 성능의 트레이드오프를 지속적으로 모니터링합니다.

PostgreSQL의 READ COMMITTED 격리 수준을 기본으로 사용하되, 재고 감소 부분에만 SELECT FOR UPDATE를 적용한 비관적 락을 사용합니다. Rails에서는 ActiveRecord의 lock 메서드로 구현하며, 재고 테이블을 먼저 락하고 포인트, 주문 순으로 일관된 락 순서를 유지해 데드락을 방지합니다. 재고 확인과 감소를 원자적으로 처리하기 위해 UPDATE stock SET quantity = quantity - 1 WHERE id = ? AND quantity >= ? 형태의 조건부 업데이트를 사용합니다. 트랜잭션 실패 시 재시도 로직을 구현하되, 최대 3회로 제한하고 exponential backoff를 적용합니다. 대규모 동시 접근이 예상되면 Redis의 분산 락이나 비동기 큐로 요청을 직렬화하는 것도 고려합니다. 모든 트랜잭션은 짧게 유지하고, 외부 API 호출은 트랜잭션 밖으로 분리합니다.

첫 번째로 Rails의 includes를 사용한 eager loading으로 연관 데이터를 미리 로드합니다. 단순 조회는 includes, 조건이 있으면 joins와 preload를 조합합니다. 두 번째로 집계 데이터는 counter_cache나 별도 집계 테이블을 활용해 미리 계산된 값을 저장합니다. 세 번째로 복잡한 통계는 Materialized View를 생성하고 주기적으로 REFRESH하거나, Scenic gem을 활용해 Rails에서 뷰를 관리합니다. 네 번째로 실시간성이 중요하지 않은 데이터는 Redis나 Rails.cache로 캐싱하며, 캐시 무효화 전략을 명확히 정의합니다. 마지막으로 Bullet gem을 개발 환경에 통합해 N+1 문제를 자동 감지하고, APM 도구로 프로덕션 쿼리 패턴을 지속적으로 모니터링합니다.

먼저 Blue-Green 배포 전략으로 PostgreSQL 환경을 병렬 구축하고, AWS DMS나 pgloader로 초기 데이터를 복제합니다. 이후 dual-write 기간을 두어 양쪽 DB에 동시 쓰기하며 데이터 정합성을 검증합니다. MySQL 특화 기능(예: 특정 함수, AUTO_INCREMENT 동작)을 식별해 Rails 코드 레벨에서 추상화하고, 테스트 커버리지를 강화합니다. 스테이징 환경에서 프로덕션 데이터 복사본으로 전체 프로세스를 3회 이상 리허설하며, 각 단계별 소요 시간을 측정합니다. 실제 전환 시에는 read-only 모드로 전환 후 최종 델타 동기화를 수행하고, PostgreSQL로 트래픽을 전환합니다. 롤백 계획으로는 4시간 내 문제 발견 시 즉시 MySQL로 복귀할 수 있도록 DNS와 connection pool 설정을 준비하고, 전환 후 24시간은 MySQL 데이터를 유지합니다. 모니터링 대시보드로 쿼리 성능, 에러율, 응답시간을 실시간 추적하며, 팀 간 커뮤니케이션 채널과 에스컬레이션 프로세스를 명확히 정의합니다.