그누보드5 리드·아키텍트 데이터베이스 기술면접

게시판별 테이블 분리 방식은 테이블 수가 수백 개 이상 증가하면 스키마 관리, 백업/복구, 통계 쿼리 작성이 복잡해지고 메타데이터 오버헤드가 발생합니다. 통합 테이블로 전환 시 board_id 컬럼으로 구분하고 (board_id, wr_num) 복합 인덱스를 설계하며, 파티셔닝(RANGE 또는 HASH)을 적용해 성능을 유지할 수 있습니다. 마이그레이션은 읽기는 기존 구조 유지, 쓰기는 dual write로 양쪽에 기록하는 단계적 전환이 필요하며, 데이터 정합성 검증과 롤백 계획이 필수입니다. 통합 테이블은 관리 편의성과 크로스 게시판 쿼리에 유리하지만, 단일 테이블 크기 증가와 핫스팟 이슈를 관리해야 하는 트레이드오프가 있습니다. 서비스 규모, 게시판 생성 빈도, 운영 인력을 고려해 아키텍처를 선택해야 합니다.

복합 인덱스 컬럼 순서는 WHERE 절의 등호 조건을 먼저, 범위 조건을 나중에 배치하고, 카디널리티가 높은 컬럼을 앞에 두는 것이 원칙이지만 실제 쿼리 패턴 분석이 우선입니다. mb_level(등호) + mb_datetime(범위) 조합이 많다면 (mb_level, mb_datetime, mb_point) 순서로 구성하고, SELECT 절에 자주 사용되는 컬럼을 마지막에 추가해 커버링 인덱스로 만들면 테이블 액세스를 제거할 수 있습니다. 인덱스 효과 측정은 EXPLAIN ANALYZE로 실행 계획의 rows examined, filtered 비율을 확인하고, slow query log에서 Query_time과 Rows_examined 비교로 정량화합니다. 인덱스 비용은 INSERT/UPDATE 성능 저하와 디스크 용량을 모니터링하며, 실제 쿼리 응답시간 개선이 30% 이상일 때 추가를 권장합니다. pt-index-usage 같은 도구로 미사용 인덱스를 주기적으로 제거하는 것도 중요합니다.

포인트 업데이트는 Lost Update 문제를 방지하기 위해 최소 READ COMMITTED 이상이 필요하며, SELECT FOR UPDATE로 비관적 락을 사용하거나 버전 컬럼 기반 낙관적 락을 적용할 수 있습니다. 데드락 방지를 위해 항상 회원 테이블 → 포인트 내역 테이블 순으로 일관된 락 획득 순서를 유지하고, 트랜잭션 범위를 최소화해 락 보유 시간을 줄여야 합니다. 대규모 동시 접속 환경에서는 Redis 같은 인메모리 저장소에서 포인트를 먼저 증감하고 비동기로 DB에 반영하는 eventual consistency 패턴을 고려할 수 있습니다. 또는 포인트 증감 이벤트를 큐에 적재하고 워커가 배치 처리하는 방식으로 락 경합을 근본적으로 회피할 수 있습니다. 비즈니스 요구사항상 강한 일관성이 필요한지, 최종 일관성으로 충분한지에 따라 아키텍처를 선택해야 합니다.

EXPLAIN을 실행해 각 서브쿼리가 인덱스를 활용하는지 확인하고, Using temporary와 Using filesort 발생 여부를 체크합니다. 각 게시판 테이블에 wr_datetime 인덱스가 있더라도 UNION ALL 후 정렬은 임시 테이블을 생성하므로, 각 서브쿼리에서 ORDER BY + LIMIT을 먼저 적용해 결과 수를 줄인 후 UNION하는 것이 효과적입니다. 또는 애플리케이션 레벨에서 각 게시판의 최신글 N개를 병렬로 조회한 후 머지 소트하는 방식으로 변경할 수 있습니다. 근본적으로는 통합 게시글 뷰 테이블이나 Elasticsearch 같은 검색 엔진을 도입해 크로스 게시판 조회를 최적화하는 것이 장기적 해결책입니다. 캐싱 레이어(Redis)를 추가해 최근 게시글 목록을 5분 단위로 갱신하는 것도 실용적인 방안입니다.

InnoDB는 인덱스를 통해 접근한 행에 Row Lock을 걸고, 범위 조건이나 인덱스가 없으면 Gap Lock으로 범위를 잠가 Phantom Read를 방지합니다. 조회수 업데이트는 PRIMARY KEY로 접근하므로 Row Lock만 발생하지만, 초당 수백 건의 UPDATE가 동일 행에 집중되면 락 대기 큐가 길어집니다. 이를 해결하기 위해 Redis 카운터로 조회수를 실시간 증가시키고, 1분마다 배치로 DB에 동기화하는 방식으로 DB 락 경합을 99% 이상 줄일 수 있습니다. 또는 조회수 증가 이벤트를 Kafka 같은 메시지 큐에 적재하고 컨슈머가 집계 후 벌크 업데이트하는 방식도 효과적입니다. 실시간성이 중요하지 않은 통계성 데이터는 eventual consistency를 허용하는 것이 락 경합 해결의 핵심입니다. 트랜잭션 격리 수준을 READ COMMITTED로 낮춰 Gap Lock을 제거하는 것도 고려할 수 있습니다.

읽기 비중이 80% 이상이고 쓰기가 적다면 Read Replica 도입이 가장 간단하며, 애플리케이션에서 읽기 전용 커넥션을 분리하고 replication lag만 모니터링하면 됩니다. 데이터가 수십억 건 이상 증가하고 단일 DB 용량 한계에 도달하면 샤딩이 필요하며, 그누보드의 경우 사이트 ID나 게시판 ID 기반 샤딩이 자연스럽지만 크로스 샤드 조인이 불가능해 애플리케이션 복잡도가 크게 증가합니다. CQRS는 쓰기는 정규화된 DB에, 읽기는 비정규화된 별도 저장소(Elasticsearch 등)에 저장해 각각 최적화할 수 있지만, 이벤트 소싱과 동기화 인프라 구축이 필요해 구현 비용이 가장 높습니다. 대부분의 경우 Read Replica로 시작해 용량 문제가 발생하면 테이블별 샤딩을 단계적으로 적용하고, 검색이나 분석 워크로드만 별도 저장소로 분리하는 하이브리드 접근이 현실적입니다. 팀의 기술 역량과 운영 인력을 고려한 점진적 전환이 리스크 관리의 핵심입니다.

먼저 slow query log를 pt-query-digest로 분석해 가장 빈번하거나 누적 시간이 긴 쿼리를 식별하고, 해당 쿼리의 EXPLAIN 결과를 시간대별로 비교해 실행 계획 변화를 확인합니다. 테이블 통계 정보가 오래되어 옵티마이저가 잘못된 실행 계획을 선택할 수 있으므로 ANALYZE TABLE로 통계를 갱신하고, 인덱스 힌트 적용 여부를 판단합니다. Performance Schema나 sys 스키마를 활성화해 락 대기, 임시 테이블 생성, 풀 스캔 발생 쿼리를 실시간 모니터링합니다. 특정 시간대 급증은 배치 작업이나 크롤러 접근일 수 있으므로 애플리케이션 로그와 상관 분석이 필요합니다. 재발 방지를 위해 Datadog이나 PMM 같은 APM 도구로 쿼리 성능을 지속 모니터링하고, slow query 임계값을 점진적으로 낮춰가며 경보 설정을 정교화합니다. 주기적인 쿼리 리뷰 문화와 배포 전 쿼리 성능 테스트를 프로세스화하는 것이 중요합니다.