이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 커뮤니티 앱의 DB 스키마를 처음 설계했을 때, 인덱스는 생각조차 안 하고 정규화에만 집중했다가 조회 쿼리가 느려지는 문제를 겪었습니다. 그 뒤로 테이블을 설계할 때 세 가지를 함께 보게 됐습니다. 첫째, 어떤 쿼리가 가장 자주 실행되는가를 먼저 파악해 인덱스 전략을 잡고, 둘째 NULL 허용 여부와 기본값을 데이터 의미에 맞게 정의하며, 셋째 나중에 컬럼을 추가할 때 기존 레코드에 미치는 영향을 미리 계산합니다. 특히 외래 키 관계가 복잡해지면 JOIN 비용이 기대보다 클 수 있어서, 읽기가 잦은 테이블은 약간의 비정규화를 허용한 적도 있습니다. 이 경험들이 지금도 설계 첫날에 쿼리 패턴을 먼저 적어두는 버릇으로 이어졌습니다.
RDB 설계에서 인덱스를 많이 추가할수록 조회가 빨라진다고 생각했다가 예상치 못한 결을 경험했습니다. 조회 최적화를 위해 여러 컬럼에 인덱스를 추가했더니, INSERT가 빈번한 테이블에서 쓰기 작업이 눈에 띄게 느려졌습니다. EXPLAIN ANALYZE로 확인하니 인덱스 갱신이 쓰기마다 추가적으로 발생하는 것이 원인이었습니다.
읽기 최적화와 쓰기 성능은 상충하는 결이 있어서, 인덱스는 실제 쿼리 패턴에서 자주 쓰이는 것만 선택적으로 추가하는 방향으로 정리했습니다. 인덱스를 제거한 뒤 쓰기 성능이 회복됐고, 조회 쿼리 분석을 통해 꼭 필요한 인덱스만 남겼습니다. RDB 설계에서 인덱스는 공짜가 아니라는 것을 이 경험에서 처음으로 체감했습니다. 지금은 인덱스를 추가하기 전에 해당 테이블의 읽기·쓰기 비율을 먼저 확인하는 결이 생겼습니다.
RDB 설계에서 읽기 성능을 위해 역정규화를 적용했다가 나중에 데이터 불일치 문제를 겪었습니다. 사용자 이름을 자주 조회하는 여러 테이블에 중복으로 저장하는 방식을 택했는데, 사용자 이름이 변경됐을 때 모든 테이블을 업데이트하는 것을 빠뜨리는 케이스가 생겼습니다.
UPDATE 트리거를 추가했지만 트리거가 중첩되면 디버깅이 어려워지는 구조가 됐습니다. 결국 이름처럼 자주 변하는 데이터는 역정규화 대상에서 제외하고, 변경이 거의 없는 정적 데이터만 역정규화하는 기준을 세웠습니다. 역정규화는 성능을 얻지만 일관성 보장 비용을 치르는 결이 있다는 것을 직접 확인했습니다. 지금은 역정규화 여부를 결정할 때 그 데이터가 얼마나 자주 변경되는가를 반드시 먼저 확인하는 결이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.