이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 PostgreSQL로 데이터 모델링을 처음 직접 했습니다. 초기엔 정규화에만 집중해서 쿼리가 여러 테이블을 조인하는 구조가 됐고, 데이터가 쌓이면서 복잡한 조인 쿼리의 응답 시간이 늘어나는 문제가 생겼습니다. EXPLAIN ANALYZE로 실행 계획을 분석해서 인덱스가 없는 조인 컬럼을 찾아 인덱스를 추가했습니다. 날짜 범위 조회가 많은 테이블에는 파티셔닝을 적용해서 조회 범위를 좁히는 방식을 써봤습니다. 통계 쪽에서는 VACUUM ANALYZE를 주기적으로 실행해서 플래너가 최신 통계를 사용하도록 유지했습니다. 정규화와 성능은 트레이드오프가 있어서, 조회 빈도가 높은 집계 데이터는 읽기 전용 집계 테이블을 별도로 두는 방식을 선택했습니다.
PostgreSQL 최적화에서 가장 직접적으로 효과를 확인한 것은 EXPLAIN ANALYZE 출력을 전후로 비교했을 때였습니다. 처음 쿼리는 10만 건 테이블에 대해 Sequential Scan으로 실행되고 있었고, 응답 시간이 평균 1.2초였습니다.
선택도가 높은 컬럼에 B-Tree 인덱스를 추가한 뒤 같은 쿼리의 실행 계획이 Index Scan으로 바뀌었고, 응답 시간이 0.08초로 줄었습니다. 수치로 나타나기 전까지는 인덱스가 얼마나 차이를 만드는지 직관적으로 가늠하기 어려웠는데, 이 경험 이후 최적화 전후를 반드시 측정 결과로 비교하는 습관이 생겼습니다.
단, 인덱스를 추가할수록 쓰기 작업 시간이 늘어나는 것도 같은 실험에서 확인했습니다. INSERT가 많은 테이블에 인덱스를 과도하게 추가했을 때 벌크 적재 시간이 두 배 가까이 늘어났고, 인덱스가 읽기를 위한 선택이지 만능이 아니라는 것을 수치로 확인했습니다.
PostgreSQL에서 전문 검색 기능을 구현할 때 GIN 인덱스를 처음 사용해봤습니다. tsvector로 문서를 변환하고 GIN 인덱스를 붙이니 텍스트 검색 속도가 크게 개선됐는데, 같은 테이블에 대한 INSERT 속도가 눈에 띄게 느려지는 것을 발견했습니다.
GIN 인덱스는 역색인 구조를 유지하기 때문에 새 데이터가 들어올 때 인덱스를 갱신하는 비용이 B-Tree보다 크다는 것을 그때 배웠습니다. 결국 데이터의 변경 빈도와 검색 요청 빈도를 비교해서 읽기가 훨씬 많은 경우에만 GIN을 유지하고, 자주 갱신되는 테이블에는 별도 검색 테이블로 분리하는 방향을 선택했습니다.
파티셔닝에서도 비슷한 경험이 있었습니다. 월별 파티셔닝을 적용하니 특정 월 데이터 조회는 빨라졌지만, 여러 월에 걸친 범위 쿼리에서 플래너가 처리해야 하는 작업이 늘어나는 케이스가 있었습니다. 최적화는 항상 어떤 쿼리 패턴을 우선할지 결정하는 것을 전제로 한다는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.