데이터 직무 SQL 테스트가 중요한 이유(조회, 조인, 집계)

데이터 분석이나 데이터 사이언스 직무를 준비하는 취업 준비생의 프로젝트를 점검하다 보면 Python과 Tableau, 머신러닝까지 경험했는데 SQL 테스트에서는 생각보다 시간이 오래 걸리는 경우가 있습니다. SELECT와 WHERE, GROUP BY 같은 문법은 알고 있지만 실제 문제에서 최근 30일 동안 구매한 사용자 가운데 두 번 이상 주문한 고객을 구하라는 조건이 나오면 어느 테이블을 기준으로 시작해야 하는지, 날짜 조건을 어디에 적용해야 하는지, 고객 수를 COUNT해야 하는지 주문 수를 COUNT해야 하는지에서 혼란이 생기는 식입니다. 더 어려운 문제는 쿼리가 실행됐는데 결과가 틀리는 경우입니다. 고객 테이블과 주문 테이블을 JOIN한 뒤 고객 수가 갑자기 늘어났는데도 그대로 집계하거나, LEFT JOIN과 INNER JOIN의 차이를 충분히 확인하지 않아 원래 포함되어야 할 사용자가 빠지기도 합니다. SQL 테스트가 까다로운 이유는 문법 오류보다 이런 데이터 구조와 업무 조건의 해석 오류를 확인하기 좋기 때문입니다. 현재 공개된 데이터 직무 채용에서도 이 점을 확인할 수 있습니다. 토스플레이스 Data Analyst 공고는 복잡한 비즈니스 로직을 정합성 있는 SQL로 구현할 수 있는 역량을 요구하며 직무 인터뷰에서 라이브 쿼리 테스트를 진행한다고 명시하고 있습니다. 토스뱅크 Data Analyst와 일부 Data Scientist 직무도 사전 쿼리 테스트를 전형에 포함하고 있습니다. 모든 데이터 직무가 SQL 테스트를 실시하는 것은 아니지만, SQL이 단순 우대 기술이 아니라 실제 문제 해결 능력을 확인하는 평가 수단으로 활용되는 사례는 분명히 존재합니다.
2026년 정부 AI 연구인력 선발에서도 SQL 코드 작성이 코딩 테스트 항목에 포함됐고, 기본 단계에서는 JOIN과 UNION 등의 활용 능력, 심화 단계에서는 다양한 함수를 이용한 정교한 SQL 작성 능력을 평가했습니다. SQL을 데이터 관련 기술의 기본 활용 능력으로 직접 검증하는 사례라고 볼 수 있습니다. 따라서 SQL 테스트를 준비할 때는 문제 사이트에서 많은 문법을 외우는 것만으로 충분하지 않습니다. 조회에서는 필요한 데이터를 정확히 골라내고, 조인에서는 서로 다른 테이블의 관계와 데이터 증가 원인을 이해하며, 집계에서는 업무 질문을 정확한 숫자로 바꿀 수 있어야 합니다.
이번 글에서는 데이터 직무 채용에서 SQL 테스트가 중요한 이유를 조회, 조인, 집계 세 가지 기준으로 나누어 정리하겠습니다.

조회는 문제의 조건을 데이터 필터로 정확하게 바꾸는 기본 역량입니다

1. SELECT보다 먼저 어떤 데이터가 필요한지를 해석할 수 있어야 합니다

SQL 문제를 보면 바로 SELECT 문부터 작성하는 경우가 많습니다. 하지만 실제 테스트에서는 문법 자체보다 문제 문장에서 분석 대상과 기간, 조건, 제외 대상이 무엇인지 정확하게 읽는 과정이 더 중요할 수 있습니다.
조회 문제에서는 다음 내용을 먼저 구분할 수 있습니다.

• 어떤 테이블이 분석의 출발점인지 확인합니다.
• 결과에 필요한 컬럼과 불필요한 컬럼을 나눕니다.
• 날짜와 상태, 사용자 조건을 정확하게 해석합니다.
• NULL이 포함되어도 되는 항목인지 확인합니다.
• 중복 행을 허용할지 제거해야 할지 구분합니다.
• 정렬이나 상위 N개 조건이 실제 문제에 필요한지 판단합니다.

예를 들어 2026년 9월에 첫 구매한 고객이라는 문제는 단순히 9월 주문만 조회하는 것과 다릅니다. 고객의 모든 주문 가운데 최초 주문일을 구한 뒤 그 최초 주문일이 9월인 사용자를 찾아야 할 수도 있습니다. SQL 테스트에서 이런 차이를 놓치면 문법적으로 완벽한 쿼리를 작성해도 정답과 다른 결과가 나올 수 있습니다. 따라서 조회 역량은 SELECT 문을 얼마나 빨리 입력하는가보다 자연어로 주어진 업무 조건을 정확한 데이터 조건으로 변환할 수 있는가에서 먼저 드러납니다.

2. 단순 조회와 분석용 조회는 조건을 해석하는 깊이에서 차이가 있습니다

기초 SQL에서는 특정 컬럼을 선택하고 WHERE 조건을 적용하는 문제부터 시작합니다. 데이터 직무 테스트에서는 같은 문법을 사용하더라도 조건을 여러 단계로 해석해야 하는 문제가 나올 수 있습니다.

• 단순 조회: 특정 지역에 거주하는 사용자를 가져옵니다.
• 기간 조건 조회: 특정 기간에 실제 활동한 사용자만 가져옵니다.
• 상태 조건 조회: 취소나 테스트 데이터를 제외하고 유효한 거래만 남깁니다.
• 복합 조건 조회: 기간과 사용자 속성, 거래 상태를 동시에 적용합니다.
• 업무 기준 조회: 활성 사용자, 신규 고객, 재구매 고객처럼 문장으로 정의된 기준을 SQL 조건으로 변환합니다.

이 차이를 이해하면 WHERE 문법을 아는 것과 데이터를 조회할 수 있다는 말의 의미도 달라집니다. 실제 데이터 직무에서는 신규 고객이라는 표현이 가입일을 의미하는지 첫 구매일을 의미하는지부터 정의해야 할 수 있습니다. 토스플레이스의 현재 Data Analyst 공고에서도 단순 데이터 추출을 넘어 비즈니스 문제를 정의하고, 복잡한 비즈니스 로직을 SQL로 구조화할 수 있는 역량을 요구하고 있습니다. SQL이 기술 문법이면서 동시에 업무 정의를 구현하는 언어라는 점을 보여주는 부분입니다.

3. 조회 문제에서는 NULL과 날짜 조건이 자주 결과를 흔드는 부분입니다

SQL 테스트에서 어려운 문법보다 기본 조건 처리 때문에 결과가 달라지는 경우가 많습니다. 특히 날짜와 NULL은 문제의 조건을 잘못 읽으면 예상과 다른 데이터가 포함되거나 제외되기 쉽습니다.
조회 연습에서는 다음 내용을 확인할 수 있습니다.

• NULL과 빈 문자열을 같은 상태로 보지 않습니다.
• =와 IS NULL의 차이를 이해합니다.
• 날짜와 시간까지 포함된 컬럼의 범위를 확인합니다.
• 시작일과 종료일이 포함되는 조건인지 구분합니다.
• 문자열 날짜와 날짜형 데이터의 차이를 확인합니다.
• 시간대가 포함되는 데이터에서는 기준 시간을 확인합니다.

예를 들어 10월 1일부터 10월 31일까지의 데이터를 조회할 때 날짜 컬럼에 시간이 포함되어 있다면 종료 조건을 어떻게 설정하느냐에 따라 31일 일부 데이터가 빠질 수 있습니다. 테스트에서는 이런 기본 조건을 통해 지원자가 문법보다 데이터의 실제 형태를 고려하는지를 확인할 수 있습니다.

4. 조회 결과는 출력되었다는 사실보다 문제 조건을 모두 반영했는지 다시 확인해야 합니다

SQL을 실행해 결과가 나오면 문제를 해결했다고 생각하기 쉽습니다. 하지만 테스트에서는 조건 하나를 빠뜨려도 자연스러운 결과가 나올 수 있기 때문에 결과 자체를 검증하는 습관이 중요합니다.

• 전체 건수 확인: 필터 적용 전후 행 수가 예상 범위인지 확인합니다.
• 최솟값·최댓값 확인: 날짜와 수치 범위가 문제 조건에 맞는지 확인합니다.
• 일부 표본 확인: 결과에서 몇 개의 행을 선택해 원본 조건과 비교합니다.
• 제외 조건 확인: 취소 데이터나 테스트 계정 등이 실제로 빠졌는지 확인합니다.
• 중복 확인: 동일한 사용자가 여러 번 포함되어도 되는 문제인지 구분합니다.

SQL 테스트에서 높은 난도의 함수를 알고 있어도 기본 조회 결과를 검증하지 않으면 작은 조건 오류로 전체 답이 달라질 수 있습니다. 조회 문제의 완성도는 쿼리가 실행되는가보다 문제의 대상과 범위가 정확하게 남았는가에서 결정됩니다.

조인은 여러 테이블의 관계와 분석 단위를 이해하는 능력을 확인하기 좋은 영역입니다

1. JOIN에서는 테이블을 붙이는 것보다 한 행이 무엇을 의미하는지 먼저 이해해야 합니다

SQL 테스트에서 JOIN 문제가 어렵게 느껴지는 이유는 문법보다 테이블의 관계를 이해해야 하기 때문입니다. 고객 테이블에서는 한 행이 고객 한 명일 수 있지만 주문 테이블에서는 한 고객이 여러 행을 가질 수 있습니다.
조인 문제에서는 다음 내용을 확인할 수 있습니다.

• 각 테이블에서 한 행이 무엇을 의미하는지 구분합니다.
• 기본키와 외래키의 관계를 확인합니다.
• 1:1, 1:N 관계인지 이해합니다.
• JOIN 이후 행 수가 증가할 가능성을 예상합니다.
• 분석에 필요한 테이블만 연결합니다.
• 조인 이후 중복과 누락을 확인합니다.

예를 들어 고객 100명과 주문 1,000건을 고객 ID로 조인하면 결과가 100행으로 유지될 것이라고 생각하면 안 됩니다. 한 고객이 여러 주문을 가지고 있기 때문에 주문 기준으로 1,000행 또는 그에 가까운 결과가 만들어질 수 있습니다. 이런 구조를 이해하지 못하면 이후 COUNT와 SUM도 모두 잘못될 가능성이 높습니다. 그래서 JOIN은 데이터 직무 SQL 테스트에서 테이블 관계를 실제로 이해하는지 확인하기 좋은 문제가 됩니다.

2. INNER JOIN과 LEFT JOIN은 문법보다 분석 대상이 달라지는 차이가 중요합니다

JOIN 종류를 외우는 것은 어렵지 않습니다. 하지만 어떤 JOIN을 선택하느냐에 따라 분석 대상 자체가 바뀐다는 점을 이해하는 것이 중요합니다.

• INNER JOIN을 사용한 경우: 양쪽 테이블에 연결되는 데이터만 결과에 남습니다.
• LEFT JOIN을 사용한 경우: 기준 테이블의 대상은 유지하고 연결되는 데이터가 없는 경우에도 행을 남길 수 있습니다.
• 잘못된 INNER JOIN을 사용한 경우: 거래가 없는 고객처럼 분석에 필요한 대상이 사라질 수 있습니다.
• 잘못된 LEFT JOIN을 사용한 경우: 필요 없는 대상까지 남으면서 이후 집계 기준이 달라질 수 있습니다.
• JOIN 이후 WHERE 조건을 적용한 경우: 조건 위치에 따라 LEFT JOIN이 의도와 다르게 작동할 수도 있습니다.

예를 들어 구매하지 않은 사용자 수를 구하는 문제에서 주문 테이블과 INNER JOIN을 하면 구매 기록이 없는 사용자가 처음부터 사라집니다. 이 문제에서는 LEFT JOIN으로 전체 사용자를 유지한 뒤 주문이 연결되지 않은 사용자를 확인하는 방식이 필요할 수 있습니다. 즉 JOIN 문제는 문법 암기가 아니라 문제에서 유지해야 할 분석 대상이 누구인지 판단하는 능력을 평가합니다.

3. 여러 테이블을 조인할수록 중복과 데이터 증가를 확인하는 습관이 중요합니다

데이터 직무에서는 한두 개의 테이블만 사용하는 경우보다 사용자와 주문, 상품, 이벤트처럼 여러 테이블을 함께 보는 경우가 많습니다. 이때 각 테이블이 모두 1:N 관계를 가지고 있다면 JOIN 이후 데이터가 예상보다 크게 증가할 수 있습니다.
조인 연습에서는 다음 내용을 확인할 수 있습니다.

• JOIN 전 각 테이블의 행 수를 확인합니다.
• 키 값의 중복 여부를 확인합니다.
• JOIN 후 전체 행 수가 어떻게 변했는지 비교합니다.
• 특정 사용자의 행이 몇 개로 증가했는지 살펴봅니다.
• 집계 전에 필요한 단위로 데이터를 먼저 줄일지 판단합니다.
• DISTINCT가 원인을 해결하는 것인지 단순히 숨기는 것인지 구분합니다.

예를 들어 사용자 한 명에게 주문 3건과 상담 기록 4건이 있는데 두 테이블을 그대로 함께 조인하면 조합에 따라 행이 12개로 늘어날 수 있습니다. 이 상태에서 주문금액을 SUM하면 같은 주문이 여러 번 계산될 가능성이 있습니다. 따라서 SQL 테스트에서도 DISTINCT를 습관적으로 넣는 것보다 왜 중복이 발생했는지와 어느 단계에서 데이터 단위를 맞춰야 하는지를 이해하는 편이 중요합니다.

4. 좋은 JOIN 문제 해결은 최종 쿼리보다 데이터 관계를 설명하는 과정이 명확합니다

실제 직무 인터뷰에서 라이브 쿼리 테스트가 이루어지는 경우라면 최종 답만 보는 것이 아니라 문제를 어떻게 접근하는지도 드러날 수 있습니다. 현재 토스플레이스 Data Analyst 공고는 직무 인터뷰에서 라이브 쿼리 테스트를 명시하고 있고, 토스뱅크 Data Analyst 공고 역시 사전 쿼리 테스트를 전형에 포함하고 있습니다.

• 테이블 구조 확인: 각각의 테이블이 어떤 데이터를 나타내는지 파악합니다.
• 기준 테이블 선택: 최종 결과에서 반드시 유지해야 하는 대상이 무엇인지 정합니다.
• 관계 확인: 한 키에 여러 행이 존재할 가능성을 확인합니다.
• JOIN 방식 선택: 분석 대상에 맞게 INNER와 LEFT 등을 결정합니다.
• 결과 검증: JOIN 이후 행 수와 일부 표본을 비교합니다.

이 흐름이 익숙하면 처음 보는 데이터셋에서도 문법부터 작성하기보다 데이터의 관계부터 파악할 수 있습니다. SQL 테스트 준비에서도 JOIN 문제의 개수를 많이 푸는 것만큼 조인 전후 행이 왜 달라졌는지를 설명하는 연습이 중요합니다.

집계는 업무 질문을 정확한 지표와 숫자로 변환할 수 있는지를 확인하는 영역입니다

1. 집계에서는 함수보다 무엇을 한 건으로 볼 것인지 정의하는 과정이 먼저입니다

COUNT와 SUM, AVG, GROUP BY의 문법 자체는 SQL 초기에 학습하는 내용입니다. 하지만 데이터 직무 테스트에서는 어떤 값을 세고 어느 단위로 묶어야 하는지가 더 어려운 경우가 많습니다.
집계 문제에서는 다음 내용을 먼저 확인할 수 있습니다.

• 사용자 수와 거래 건수를 구분합니다.
• 전체 주문금액과 결제 완료 금액을 나눕니다.
• 일별과 월별처럼 시간 단위를 정확하게 설정합니다.
• 중복 사용자를 한 번만 계산해야 하는지 확인합니다.
• 취소와 환불을 지표에 포함할지 구분합니다.
• 분자와 분모가 같은 데이터 범위를 사용하고 있는지 확인합니다.

예를 들어 구매 고객 수는 주문 건수를 COUNT하는 문제와 다릅니다.동일한 고객이 다섯 번 구매했더라도 고객 수에서는 한 명으로 계산해야 할 수 있기 때문에 DISTINCT 또는 사전 집계가 필요할 수 있습니다. 따라서 집계 SQL에서 중요한 것은 함수 사용 능력보다 업무 문장을 정확한 데이터 단위와 계산 기준으로 바꾸는 능력입니다.

2. 단순 집계와 비즈니스 지표 계산은 숫자의 정의에서 차이가 있습니다

실무 데이터 분석에서는 매출과 전환율, 재방문율, 리텐션처럼 업무에서 사용하는 지표를 SQL로 계산하는 경우가 많습니다. 이러한 지표는 GROUP BY만 작성한다고 자동으로 결정되지 않습니다.

• 단순 COUNT: 조건에 해당하는 데이터 행의 수를 계산합니다.
• 사용자 수: 동일 사용자의 여러 행동을 어떻게 처리할지 기준이 필요합니다.
• 매출: 주문금액과 실제 결제금액, 취소와 환불 가운데 무엇을 포함할지 결정합니다.
• 전환율: 분자에 포함된 대상이 분모 집단 안에 존재하는지 확인합니다.
• 리텐션: 최초 방문이나 가입 시점을 어떤 기준으로 잡고 이후 행동을 어느 기간에 확인할지 정의합니다.

현재 토스의 Data Analytics Engineer 공고에서도 전사가 동일한 정의와 숫자를 사용할 수 있도록 데이터 모델과 지표 정의, 집계 로직을 설계하고 관리하는 업무를 강조하고 있습니다. 집계가 단순 함수 활용을 넘어 데이터 조직의 신뢰도와 연결된다는 사례입니다. 이런 관점으로 준비하면 SQL 테스트의 집계 문제도 숫자를 만들어내는 문제보다 지표 정의를 구현하는 문제로 이해할 수 있습니다.

3. GROUP BY 이후에는 숫자가 그럴듯해 보여도 반드시 검증이 필요합니다

집계 결과는 대부분 깔끔한 숫자로 출력되기 때문에 오류를 발견하기 더 어려울 수 있습니다. 잘못된 JOIN이나 조건이 들어가도 매출 1억 원, 사용자 2만 명처럼 자연스러운 결과가 나올 수 있습니다.
집계 검증에서는 다음 내용을 확인할 수 있습니다.

• 전체 합계와 그룹별 합계가 논리적으로 맞는지 비교합니다.
• JOIN 이전과 이후 금액 합계가 달라지지 않았는지 확인합니다.
• 사용자 수가 전체 가입자 수보다 커지지 않았는지 살펴봅니다.
• 특정 날짜나 그룹을 선택해 직접 계산합니다.
• COUNT(*)와 COUNT(column), COUNT(DISTINCT)의 결과 차이를 확인합니다.
• NULL이 평균과 개수 계산에 어떻게 반영되는지 확인합니다.

예를 들어 지역별 매출을 계산했는데 그룹별 합계를 다시 더한 값이 원본 전체 매출보다 크다면 JOIN이나 데이터 중복부터 의심할 수 있습니다. 이러한 검증 습관이 있어야 SQL 테스트뿐 아니라 실제 분석에서도 결과를 자신 있게 설명할 수 있습니다.

4. SQL 테스트에서 집계 역량을 보는 이유는 숫자를 의사결정에 사용할 수 있어야 하기 때문입니다

데이터 직무에서는 쿼리를 작성하는 것 자체가 최종 업무인 경우보다 그 결과를 이용해 제품과 사업의 상태를 판단하는 경우가 많습니다. 따라서 SQL 테스트도 복잡한 문법 하나보다 비즈니스 질문을 정확한 수치로 바꾸는 능력을 확인하는 방향으로 이해할 수 있습니다.

• 질문 해석 단계: 무엇을 알고 싶은 문제인지 먼저 파악합니다.
• 분석 단위 단계: 사용자와 주문, 이벤트 가운데 계산 기준을 정합니다.
• 조건 정의 단계: 기간과 상태, 제외 대상을 명확하게 만듭니다.
• 집계 단계: 문제에 적합한 COUNT와 SUM, AVG 등을 적용합니다.
• 검증 단계: 표본과 전체값을 이용해 계산 결과를 다시 확인합니다.

토스플레이스의 데이터 분석 역할 역시 단순 데이터 추출보다 팀 목표를 지표로 정량화하고 새로운 지표와 분석 프레임을 설계하는 일을 강조하고 있습니다. SQL 테스트가 중요한 이유도 결국 이런 업무를 수행할 수 있는 기본적인 데이터 사고를 직접 확인하기 쉽기 때문이라고 볼 수 있습니다. SQL 테스트 준비에서도 어려운 윈도우 함수를 많이 아는 것만큼 문제의 지표를 어떤 단위와 조건으로 계산해야 하는지 정확하게 정의하는 연습이 중요합니다.

• conclusion

데이터 직무 채용에서 SQL 테스트가 중요해지는 이유를 단순히 기업들이 SQL을 많이 사용하기 때문이라고만 설명하기에는 부족합니다. SQL은 데이터베이스에서 값을 가져오는 언어이면서 동시에 지원자가 데이터를 어떤 구조로 이해하고, 여러 테이블의 관계를 어떻게 해석하며, 모호한 업무 질문을 어떤 숫자로 바꾸는지를 직접 확인하기 좋은 도구이기 때문입니다. 현재 공개된 일부 데이터 분석·데이터 사이언스 채용에서도 사전 쿼리 테스트나 라이브 쿼리 테스트가 실제 전형에 포함되어 있습니다. 다만 모든 기업과 모든 데이터 직무가 동일한 SQL 테스트를 실시한다고 일반화할 필요는 없습니다. 중요한 것은 SQL 활용 역량 자체가 다양한 데이터 직무에서 계속 요구되고 있다는 점입니다. 조회에서는 필요한 데이터를 정확하게 남기는 능력이 중요합니다. 문제의 기간과 사용자, 상태 조건을 데이터 필터로 바꾸고 NULL이나 중복, 날짜 범위를 확인할 수 있어야 합니다. 조인에서는 여러 테이블을 연결했다는 사실보다 연결 이후 데이터 단위가 어떻게 변하는지를 이해해야 합니다. 1:N 관계와 JOIN 종류를 제대로 이해하지 못하면 이후 모든 집계 결과가 잘못될 수 있기 때문에 테이블의 관계를 읽는 능력이 중요합니다. 집계에서는 COUNT와 SUM 문법보다 지표의 정의가 먼저입니다. 사용자 수와 주문 수, 주문금액과 실제 매출처럼 비슷해 보이지만 서로 다른 숫자를 구분하고 분자와 분모, 기간과 제외 조건을 정확하게 만들 수 있어야 합니다.
최종적으로 확인할 항목은 다음과 같습니다.

• 문제의 자연어 조건을 WHERE 절로 정확하게 변환할 수 있는지 확인합니다.
• 날짜와 NULL, 중복 조건을 구분해서 처리할 수 있는지 살펴봅니다.
• 테이블의 기본키와 관계를 이해하고 JOIN할 수 있는지 확인합니다.
• JOIN 이후 행 수가 증가한 이유를 설명할 수 있는지 점검합니다.
• 사용자 수와 거래 건수처럼 서로 다른 집계 단위를 구분할 수 있는지 살펴봅니다.
• 최종 숫자를 원본 데이터와 일부 표본으로 다시 검증할 수 있는지 확인합니다.

SQL 테스트 준비 흐름은 다음과 같이 연결할 수 있습니다.

• SELECT·WHERE 기초 → 날짜와 NULL 처리 → ORDER BY·CASE → 테이블 관계 이해 → INNER·LEFT JOIN → JOIN 전후 행 수 검증 → GROUP BY → COUNT·SUM·AVG → DISTINCT와 중복 이해 → 서브쿼리·CTE → 윈도우 함수 → 실제 업무형 문제 해석 → 지표 정의 → 쿼리 작성 → 결과 검증 → 시간 제한 문제풀이 → 라이브 쿼리 설명 → 포트폴리오와 면접 연결

결국 SQL 테스트에서 중요한 것은 복잡한 쿼리를 가장 짧게 작성하는 능력이 아닙니다. 조회에서는 필요한 데이터를 정확하게 찾고, 조인에서는 여러 테이블의 관계와 데이터 단위를 이해하며, 집계에서는 업무 질문을 신뢰할 수 있는 숫자로 바꿀 수 있어야 합니다.
이 세 가지가 연결되어 있다면 SQL 테스트를 위한 문제풀이 능력을 넘어 실제 데이터 직무에서 필요한 데이터 해석과 검증 능력까지 함께 준비할 수 있습니다.