이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대용량 트래픽 환경의 DB 설계에서 가장 중점을 두는 것은 파티셔닝 전략입니다. 시간 기반 데이터는 날짜 범위 파티션을 사용하면 쿼리 시 스캔 범위를 줄일 수 있고, 오래된 데이터를 아카이빙하는 작업도 파티션 단위로 처리할 수 있습니다.
인덱스 설계는 읽기 패턴을 먼저 파악하는 것에서 시작합니다. 자주 쓰이는 필터·정렬 조건을 분석해 복합 인덱스를 구성하되, 인덱스가 많아질수록 쓰기 성능이 저하되기 때문에 필요한 것만 선택적으로 추가했습니다.
읽기/쓰기 부하가 함께 높은 경우에는 DB 복제 구조를 적용했습니다. 레플리카로 읽기 트래픽을 분산하고 메인 DB는 쓰기에 집중하도록 구성하니 피크 시간대 응답 지연이 눈에 띄게 줄었고 처리량도 늘었습니다.
서비스 출시 후 사용자가 늘면서 특정 목록 조회 API가 느려지는 문제가 생겼습니다. 처음에는 인덱스가 이미 있으니 괜찮다고 생각했는데, 슬로우 쿼리 로그를 켜고 보니 N+1 패턴으로 ORM이 쿼리를 수백 번 날리고 있었습니다. EXPLAIN ANALYZE로 실행 계획을 확인했더니 Nested Loop 방식으로 순차 스캔이 반복되는 것이 보였습니다. Eager Loading으로 관계를 미리 조인하도록 바꿨고, 복합 인덱스를 추가하면서 카디널리티가 높은 컬럼을 앞에 배치했습니다.
변경 전후를 같은 데이터셋으로 반복 측정해 응답 시간이 1.8초에서 120ms로 줄었음을 로그로 확인했습니다. 직관으로 빠를 것 같다는 추측만으로는 튜닝 결과를 신뢰할 수 없다는 것을 배웠고, 측정 변경 재측정의 루프를 기록으로 남기는 것이 DB 성능 작업의 기본이라는 생각이 자리 잡혔습니다.
개인 프로젝트에서 이벤트 로그 테이블이 한 달 만에 수천만 건을 넘었을 때, 테이블을 그냥 두면 인덱스 리빌드 시간도 늘고 정기 백업에 걸리는 시간도 지수적으로 증가한다는 것을 확인했습니다. 대용량 DB 설계에서 제가 중점을 두는 것은 샤딩이나 파티셔닝을 언제 시작해야 하는가의 판단 타이밍입니다. 데이터가 충분히 쌓인 후 마이그레이션하면 다운타임이 커지기 때문에, 조기에 범위 파티셔닝을 설계해두면 나중에 구조를 뜯지 않아도 됩니다. 이 경험에서 날짜 기반 범위 파티션을 미리 설계해두고, 오래된 파티션은 아카이브 테이블로 분리하는 방식을 택했습니다. 결과적으로 월별 파티션 추가에 소요되는 시간은 5초 미만이었고, 전체 스캔이 필요한 쿼리도 파티션 프루닝으로 대상 범위가 1/12로 줄었습니다.
설계 타이밍을 늦추는 것이 가장 비싼 기술 부채라는 점이 대용량 DB 설계의 핵심이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.