SQL 인터뷰에서 점수를 잃는 순간

SQL 인터뷰에서 가장 흔한 착각이 있다. "쿼리가 맞으면 통과한다." 아니다. 쿼리가 맞아도 탈락하는 경우가 생각보다 많다. 그리고 대부분의 면접관은 그 이유를 정확히 설명하지 않는다. "더 좋은 후보가 있었습니다"라는 피드백 뒤에 숨은 진짜 이유를 이 글에서 다룬다.

면접관이 SQL 인터뷰에서 실제로 보는 것은 쿼리의 정답 여부만이 아니다. 문제를 어떻게 이해하고, 어떤 순서로 접근하며, 막혔을 때 어떻게 대처하는지를 본다. 이것이 실무와 연결되기 때문이다.

나는 지난 몇 년간 채용 면접에 참여하고 멘티들의 인터뷰를 수십 차례 준비시키며 반복적으로 확인한 패턴이 있다. 정답을 맞히고도 점수를 잃는 순간은 특정한 행동과 연결된다.

문제를 받고 화면을 응시하며 10분간 침묵하는 것 — 이것이 내가 본 가장 자주 발생하는 실수다. "생각 중이에요"는 한 번은 괜찮지만, 그 이후가 없으면 면접관은 당신이 무엇을 생각하는지 전혀 알 수 없다.

실무에서 분석가가 혼자 일하는 경우는 드물다. 팀원과 공유하고, 질문하고, 방향을 조율하는 것이 일의 본질이다. 면접에서 침묵은 "나는 혼자 일합니다"라는 신호로 읽힌다.

대안은 간단하다. 생각하는 과정을 말로 하라. "일단 필요한 테이블이 무엇인지 확인하겠습니다. users 테이블과 events 테이블이 필요할 것 같고, 조인 조건을 먼저 생각해보겠습니다." 이런 식의 구두 사고(verbal thinking)가 면접관에게 보여주어야 하는 것이다.

면접에서 "월별 활성 사용자 수를 구하는 쿼리를 작성해보세요"라는 질문을 받았을 때, 바로 쿼리를 시작하는 사람과 먼저 질문을 하는 사람이 있다. 후자가 더 좋은 분석가다.

'활성 사용자'의 정의는 회사마다 다르다. 로그인한 사람인가, 특정 행동을 한 사람인가, 7일 기준인가 30일 기준인가? 이를 먼저 확인하는 것이 실무에서는 당연한 행동이고, 면접에서도 마찬가지다.

면접관은 이 질문에 단 하나의 정답을 원하지 않는다. 당신이 어떤 가정을 세우고 일하는지를 보고 싶은 것이다. "활성 사용자를 지난 30일 내 로그인으로 정의하겠습니다. 다른 기준이 있으시면 말씀해 주세요"라는 한 문장이 면접 점수를 크게 올린다.

쿼리가 '대부분의 경우'에는 맞지만 특정 상황에서 깨지는 것을 작성하는 경우가 많다. NULL 처리, 중복 레코드, 날짜 경계값, 빈 테이블 — 이것들이 엣지 케이스다.

예를 들어, 사용자별 최근 주문을 구하는 쿼리를 짤 때 ROW_NUMBER()를 사용했다면, "주문이 없는 사용자는 어떻게 처리되나요?"라는 질문에 답할 수 있어야 한다. NULL이 들어오면 어떻게 되는지, 동점 처리(tie-breaking)는 어떻게 할 것인지도 함께 고민하라.

쿼리를 완성한 후 스스로에게 묻는 습관을 들여라. "이 쿼리가 깨지는 경우는 무엇인가?" 면접에서 이 질문을 면접관이 하기 전에 당신이 먼저 한다면, 그것 자체가 강력한 인상을 남긴다.

코딩 테스트에서 정답을 맞히면 되지 않냐고 생각할 수 있다. 하지만 실무 SQL 인터뷰에서 면접관은 종종 "이 쿼리가 실제로 100만 행짜리 테이블에서 실행된다면 어떻게 될까요?"를 묻는다.

기초적인 성능 감각을 드러내는 방법은 복잡하지 않다. SELECT *를 피하고 필요한 컬럼만 선택하는 이유를 설명할 수 있어야 하고, 서브쿼리 대신 CTE를 선택한 이유, WHERE 절에서 인덱스를 활용하려는 의도 등을 언급하면 충분하다.

성능에 관한 모든 것을 알 필요는 없다. 다만 "빠르게 실행되어야 하는 쿼리라면, 저는 이 부분을 먼저 최적화할 것입니다"라는 식으로 사고 방향을 보여주는 것이 포인트다.

지금까지 점수를 잃는 패턴을 살펴봤다면, 이제 반대로 점수를 올리는 신호를 알아보자. 내가 면접관으로서 가장 좋은 인상을 받았던 5가지 행동이다.

첫째, 가정을 명확히 한다. 둘째, 중간 결과를 확인하면서 진행한다("여기서 행 수를 먼저 확인해보겠습니다"). 셋째, 스스로 엣지 케이스를 언급한다. 넷째, 쿼리가 틀렸을 때 당황하지 않고 어디서 틀렸는지를 찾는 과정을 보여준다. 다섯째, 완성 후 "더 나은 방법이 있을까요?"를 스스로 묻는다.

이 5가지 신호가 공통적으로 드러내는 것은 하나다. 당신이 팀에서 함께 일하기 좋은 사람이라는 것. SQL 인터뷰는 결국 기술 테스트이기도 하지만, 동시에 같이 일할 사람인지를 확인하는 자리이기도 하다.