이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
SQL 사용 경험은 수업 데이터베이스 과목에서 설비 유지보수 이력 데이터베이스를 설계하고 쿼리를 작성한 것입니다. 장비 ID, 점검 일자, 고장 유형, 조치 내역을 테이블로 설계하고 JOIN으로 장비별 이력을 조회하는 쿼리를 구현했습니다. 특정 기간 내 특정 부품의 교체 빈도를 GROUP BY와 HAVING으로 집계해 고장 빈도 상위 부품을 파악하는 분석도 했습니다. PL/SQL은 Oracle DB 실습에서 커서와 예외 처리를 활용한 배치 데이터 처리 프로시저를 작성했습니다.
인덱스가 없는 컬럼으로 대용량 테이블을 조회하면 Full Table Scan이 발생하는 것을 실습에서 확인했습니다. SQL은 데이터를 질문할 수 있는 언어라고 생각합니다.
쿼리를 최적화 없이 작성했다가 데이터가 많아지면서 조회가 느려진 경험이 있습니다. 수업 프로젝트에서 JOIN을 여러 개 중첩해 결과를 뽑았는데, 데이터 건수가 늘어나자 응답이 수 초 이상 걸리는 상황이 됐습니다. SQL은 결과가 맞아도 성능이 나쁘면 운영 환경에서 쓸 수 없다는 걸 그때 배웠습니다. 이후로는 쿼리 작성 후 실행 계획(EXPLAIN)을 확인하는 습관이 생겼습니다.
SQL 역량은 결과를 내는 것이 아니라 효율적으로 내는 것이라는 원칙이 생겼습니다. 쿼리 정확성과 쿼리 성능은 별개의 역량이라는 걸 경험으로 확인했습니다. 이후 같은 쿼리를 인덱스 힌트와 서브쿼리 분리로 재작성하니 응답 시간이 10분의 1로 줄었습니다.
SQL 최적화는 데이터가 늘기 전에는 보이지 않는 기술이라는 원칙이 생겼습니다.
데이터베이스 관리자 입장에서 다른 팀의 쿼리를 검토해본 경험이 SQL 작성 기준을 바꿔줬습니다. 수업에서 DBA 역할을 맡아 팀원들의 쿼리를 리뷰했는데, 결과는 같아도 실행 계획이 전혀 다른 쿼리들이 많았습니다. 결과 중심으로만 쿼리를 검증하면 성능 문제는 운영 후에야 드러난다는 걸 그때 이해했습니다.
인덱스 사용 여부와 조인 순서가 쿼리 성능을 결정하는 핵심 변수라는 원칙이 생겼습니다. SQL은 언어를 아는 것이 아니라 DB가 어떻게 처리하는지를 이해하는 것이라는 걸 그 경험에서 배웠습니다. 그 뒤로 쿼리를 작성하면 실행 계획을 함께 확인하는 습관이 자리잡았습니다.
같은 결과를 내는 쿼리도 실행 계획이 다르면 완전히 다른 코드라는 걸 그 뒤 여러 번 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신세계아이앤씨 임베디드·펌웨어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.