웹 접근성 미드레벨 데이터베이스 기술면접

웹 접근성 준수 추적 시스템은 크게 세 가지 테이블로 설계할 수 있습니다. 첫째, wcag_criteria 마스터 테이블에 WCAG 체크리스트 항목을 관리하고(기준 코드, 설명, 레벨 등), 둘째, page_compliance 테이블에 페이지별 현재 준수 상태를 저장합니다(페이지 ID, 기준 ID, 준수 여부, 최종 수정일). 셋째, compliance_history 테이블에 모든 변경 이력을 시간순으로 기록합니다(이력 ID, 페이지 ID, 기준 ID, 이전 상태, 새 상태, 수정자, 수정 시각). 정규화는 3NF까지 적용하되, 조회 성능을 위해 page_compliance에는 최신 상태만 유지하고 이력은 별도 테이블로 분리합니다. 대량의 이력 데이터 조회를 위해 파티셔닝(날짜 기준)을 고려할 수 있으며, 페이지별 전체 준수율 같은 집계 데이터는 materialized view나 summary 테이블로 관리하는 것이 효율적입니다.

이 쿼리는 ARIA role로 필터링하고 사용자별로 그룹화하여 집계하므로, 복합 인덱스 설계가 핵심입니다. 인덱스 컬럼 순서는 일반적으로 WHERE 절의 동등 조건, WHERE 절의 범위 조건, GROUP BY/ORDER BY 절 순서로 결정합니다. 이 경우 (aria_role, user_id, timestamp) 순서의 복합 인덱스가 효과적인데, aria_role로 먼저 필터링하고 user_id로 그룹화하며 timestamp는 범위 계산에 사용되기 때문입니다. 다만 aria_role의 카디널리티가 낮다면(종류가 적다면) 인덱스 효율이 떨어질 수 있으므로, 실제 데이터 분포를 분석해야 합니다. 대안으로 특정 role에 대한 쿼리가 빈번하다면 필터링된 인덱스(partial index)를 고려하거나, 시간 범위 조건이 항상 포함된다면 (timestamp, aria_role, user_id) 순서로 파티셔닝과 결합하는 전략도 유효합니다. 또한 집계 쿼리의 특성상 커버링 인덱스를 구성하여 테이블 접근을 완전히 제거하는 것이 성능 향상에 큰 도움이 됩니다.

이 시나리오는 전형적인 Lost Update 문제로, 두 크롤러가 동시에 같은 점수를 읽고 각자 계산한 결과로 업데이트하면 한 쪽의 변경사항이 손실됩니다. 비관적 락 방식으로는 SELECT FOR UPDATE를 사용해 행 수준 배타적 락을 획득한 후 업데이트하면 다른 트랜잭션이 대기하게 되어 안전하게 처리할 수 있습니다. 낙관적 락 방식으로는 버전 컬럼을 추가하고, UPDATE 시 WHERE 절에 읽었던 버전을 포함시켜 버전이 변경되었으면 재시도하는 방식으로 구현합니다. 격리 수준은 최소한 READ COMMITTED 이상이어야 하며, REPEATABLE READ나 SERIALIZABLE을 사용하면 더 강력한 보장을 받지만 성능과 데드락 가능성을 고려해야 합니다. 실무에서는 업데이트 빈도와 충돌 가능성을 고려하여, 충돌이 드물다면 낙관적 락으로 성능을 높이고, 충돌이 빈번하다면 비관적 락이나 큐 기반 순차 처리를 선택하는 것이 효과적입니다.