이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 모델링에서 저는 비즈니스 엔티티 간 관계를 ERD로 먼저 시각화하는 방식을 선호합니다. 정규화 수준은 읽기와 쓰기 비율을 고려해 결정하는데, 읽기가 많은 경우 일부 컬럼을 비정규화해 조인을 줄이는 쪽을 선택했습니다.
쿼리 최적화는 EXPLAIN ANALYZE로 실행 계획을 먼저 확인하는 것에서 시작합니다. 순차 스캔이 발생하는 컬럼에 인덱스를 추가하고, 복합 인덱스 순서를 선택도 높은 컬럼 기준으로 조정했습니다. 인턴 때 한 쿼리에서 전체 스캔이 발생해 응답 시간이 2초를 넘겼는데, 인덱스 하나 추가로 120ms 이하로 줄어든 경험이 있습니다.
N+1 문제는 ORM 사용 시 자주 마주쳤습니다. 관계 데이터를 루프에서 개별 조회하는 패턴을 발견하면 JOIN이나 IN 절로 변환했고, 쿼리 수를 줄이는 것이 인덱스 최적화만큼 효과적이라는 것을 직접 확인했습니다.
데이터 모델링과 쿼리 최적화에서 검증 결이 명확해진 경험은 실행 계획 분석 전후를 비교해서 인덱스 효과를 수치로 확인한 케이스였습니다. 쿼리가 느리다고 느꼈을 때 EXPLAIN ANALYZE를 실행하기 전에는 어느 단계가 느린지 추측으로만 접근했습니다.
실행 계획을 보고 나서 어느 단계에서 어느 만큼의 시간이 걸리는지가 명확해졌고, 인덱스를 추가한 뒤 동일하게 실행 계획을 비교하자 효과도 수치로 확인됐습니다. 쿼리 최적화에서 실행 전 가정보다 실행 계획 분석이 실제 병목을 정확하게 보여준다는 결이 생겼습니다.
데이터 모델링과 쿼리 최적화에서 본인 사례로 닫힌 경험은 ORM을 사용할 때 N+1 문제가 발생하는 것을 발견하고 쿼리를 개선한 케이스였습니다. 관계 데이터를 조회하는 기능을 만들 때 코드는 단순해 보였는데, 실제로 실행되는 쿼리 수를 로그로 확인하니 조회 건수에 비례해서 쿼리가 늘어나고 있었습니다.
JOIN으로 한 번에 가져오도록 변경하자 쿼리 수가 크게 줄었습니다. ORM이 어떤 쿼리를 실행하는지 확인하지 않으면 성능 문제를 뒤늦게 발견하게 된다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.