데이터 직무를 준비하는 분의 SQL 프로젝트를 검토하면서 온라인 쇼핑몰의 재구매율을 분석한 자료를 본 적이 있습니다. 준비생은 고객, 주문, 상품 테이블을 조인하고 고객별 구매 횟수를 계산한 뒤 재구매율이 약 18퍼센트라는 결과를 제시했습니다. 쿼리에는 서브쿼리와 그룹 함수가 사용되어 있었고 실행 결과도 보기 좋게 정리되어 있었습니다. 그러나 재구매 고객과 전체 고객을 어떤 기준으로 구분했는지 묻자 답변이 막혔습니다. 회원가입만 하고 구매하지 않은 사람을 분모에 포함했는지, 첫 구매 후 며칠이 지나야 재구매 가능성이 있다고 판단했는지, 취소된 주문을 구매 횟수에 넣었는지가 정리되지 않았기 때문입니다.
원본 데이터를 다시 확인하니 한 주문에 여러 상품이 포함되면서 주문 테이블과 상품 상세 테이블을 조인할 때 같은 주문이 여러 행으로 늘어나고 있었습니다. 이 상태에서 행의 개수를 구매 횟수로 계산해 일부 고객이 실제보다 많이 구매한 것으로 나타났습니다. 여기에 취소 주문과 분석 종료일 직전에 첫 구매한 고객까지 포함되면서 재구매율도 왜곡되었습니다. 준비생은 주문번호를 기준으로 중복을 제거하고 정상 결제 건만 남긴 뒤, 첫 구매 후 90일 이상 관찰할 수 있는 고객을 대상으로 다시 계산했습니다. 수정된 결과는 처음보다 낮았지만 특정 상품군에서 두 번째 구매가 빠르게 발생한다는 새로운 특징을 발견할 수 있었습니다.
이 경험은 SQL 실습의 가치가 복잡한 문법을 많이 사용하는 데 있지 않다는 점을 보여줍니다. 데이터 직무에서는 무엇을 계산하려 했는지, 필요한 행을 어떤 조건으로 선택했는지, 결과가 이상할 때 원본 데이터를 어떻게 확인했는지가 중요합니다. 간단한 조회 쿼리로 시작한 프로젝트라도 쿼리작성, 데이터정제, 분석결과가 하나의 흐름으로 연결되면 지원자의 논리적인 사고와 검증 태도를 보여주는 취업 자료가 될 수 있습니다.
업무 질문을 데이터 구조로 바꾸는 쿼리작성 과정이 필요합니다
- 문법보다 먼저 해결할 질문을 좁혀야 합니다
SQL을 연습할 때 SELECT, JOIN, GROUP BY, 윈도 함수처럼 문법 단위로 문제를 푸는 경우가 많습니다. 문법 학습은 필요하지만 포트폴리오에서는 어떤 질문을 해결하기 위해 해당 기능을 사용했는지가 보여야 합니다. 월별 매출을 조회했다는 설명보다 최근 6개월 동안 신규 고객 매출이 감소한 시점을 찾기 위해 주문일과 첫 구매일을 기준으로 고객을 구분했다는 설명이 직무와 더 가깝습니다.
분석 질문이 분명하면 필요한 테이블과 칼럼도 자연스럽게 정리됩니다. 고객별 재구매 간격을 확인하려면 고객 ID, 주문번호, 주문일, 결제 상태가 필요합니다. 상품군별 차이까지 비교한다면 상품 정보와 주문 상세 데이터도 연결해야 합니다. 반대로 질문을 정하지 않은 채 모든 테이블을 조인하면 사용하지 않는 칼럼이 늘어나고 중복 행이 발생하는 원인을 찾기도 어려워집니다.
- 먼저 결과를 한 문장으로 예상해 보는 것이 좋습니다. 신규 고객의 두 번째 구매까지 걸리는 기간을 상품군별로 비교한다는 식으로 목적을 정하면 어떤 데이터를 가져와야 하는지 판단하기 쉬워집니다. 쿼리를 작성한 뒤에도 결과가 처음 질문에 답하고 있는지 확인할 수 있습니다.
- 테이블 관계는 그림이나 짧은 문장으로 정리해야 합니다. 고객 한 명이 여러 주문을 만들고 주문 하나에 여러 상품이 포함되는 구조를 이해해야 조인으로 행이 늘어나는 이유를 설명할 수 있습니다. 기본키와 외래키를 확인하는 과정도 분석의 일부입니다.
- 조인 결과가 늘어난 이유를 확인해야 합니다
한 준비생은 카페 주문 데이터를 활용해 회원별 방문 횟수와 구매 금액을 분석했습니다. 고객 테이블과 주문 테이블을 연결했을 때까지는 결과가 정상이었지만 주문 상세 테이블을 추가하자 전체 매출이 실제 집계값보다 크게 나타났습니다. 처음에는 SUM 함수의 사용법이 잘못되었다고 생각했지만, 주문 한 건에 메뉴가 여러 개 포함되면서 같은 주문 금액이 메뉴 개수만큼 반복된 것이 원인이었습니다.
그는 조인 전후의 행 수와 주문번호 개수를 비교하고, 특정 주문 한 건을 조건으로 조회해 데이터가 늘어나는 모습을 직접 확인했습니다. 이후 주문 단위 금액을 사용할 때는 주문 테이블에서 먼저 집계하고, 메뉴별 판매량을 볼 때만 상세 테이블을 연결하도록 쿼리를 분리했습니다. 이 과정을 통해 조인이 정상적으로 실행되었다고 해서 계산 결과까지 올바른 것은 아니라는 점을 이해할 수 있었습니다.
- 실행 여부만 말한 설명: 고객과 주문 테이블을 조인해 구매 내역을 조회했습니다.
- 과정이 보이는 설명: 고객 ID를 기준으로 주문 데이터를 연결하고 조인 전후의 행 수와 주문번호 개수를 비교했습니다.
- 판단과 검증이 담긴 설명: 주문 상세 테이블을 추가한 뒤 전체 매출이 원본 집계보다 커지는 현상을 발견했습니다. 특정 주문을 조회해 하나의 주문 금액이 상품 수만큼 반복된다는 점을 확인했고, 주문 단위 매출과 상품별 판매량을 서로 다른 단계에서 집계하도록 수정했습니다. 변경 후 전체 주문 금액과 SQL 결과를 다시 대조했습니다.
- 결과를 확인할 수 있는 작은 검증 쿼리가 필요합니다
긴 쿼리를 한 번에 완성하면 어느 단계에서 데이터가 달라졌는지 확인하기 어렵습니다. 원본 테이블의 행 수, 고유 주문번호 개수, 결측값 수, 상태별 건수를 먼저 조회한 뒤 조건과 조인을 단계적으로 추가하는 것이 좋습니다. 최종 결과와 함께 이러한 검증 쿼리를 남기면 단순히 실행에 성공한 것이 아니라 데이터 변화를 확인하면서 작성했다는 점을 보여줄 수 있습니다.
예를 들어 월별 매출을 계산했다면 특정 월의 주문 몇 건을 직접 조회해 합계를 비교할 수 있습니다. 고객별 구매 횟수를 구했다면 구매가 한 번인 고객과 여러 번인 고객을 각각 표본으로 선택해 주문 내역을 확인해야 합니다. 모든 행을 수작업으로 검토할 필요는 없지만 경곗값과 예상 밖의 결과는 원본 데이터로 돌아가 확인하는 습관이 필요합니다.
면접에서는 완성된 SQL문 전체를 외울 필요가 없습니다. 어떤 질문에서 시작했고, 처음 작성한 결과에서 무엇이 이상했으며, 어느 조건을 확인해 수정했는지를 설명하면 됩니다. 복잡한 문법보다 데이터가 변하는 지점을 이해하고 있다는 사실이 더 분명하게 전달됩니다.
중복과 결측값의 처리 기준이 보이는 데이터정제가 중요합니다
- 삭제하기 전에 발생 원인을 확인해야 합니다
데이터를 정리할 때 중복 행을 모두 제거하거나 결측값을 0으로 채우는 방식은 간단하지만, 실제 의미를 확인하지 않으면 결과가 왜곡될 수 있습니다. 같은 고객과 같은 주문 시간이 반복되어 있어도 하나는 결제 기록이고 다른 하나는 상품 상세 기록일 수 있습니다. 결측값도 정보가 누락된 것인지, 해당 항목 자체가 존재하지 않는 것인지에 따라 처리 방법이 달라집니다.
한 배달 주문 프로젝트에서는 할인 금액이 비어 있는 행을 모두 오류 데이터로 판단해 제거했습니다. 하지만 원본 구조를 확인해 보니 쿠폰을 사용하지 않은 주문은 할인 금액이 비어 있도록 저장되어 있었습니다. 해당 행을 삭제하면 정상 주문 상당수가 분석에서 빠지는 문제가 발생했습니다. 준비생은 결측값의 의미를 확인한 뒤 쿠폰 미사용 주문의 할인 금액만 0으로 처리하고, 주문 금액이나 고객 ID가 없는 행은 별도로 분류했습니다.
- 결측값은 칼럼별 의미를 먼저 확인해야 합니다. 할인 금액의 빈 값은 쿠폰을 사용하지 않았다는 뜻일 수 있지만 고객 ID의 빈 값은 비회원 주문일 가능성이 있습니다. 같은 처리 방법을 모든 칼럼에 적용하면 중요한 차이를 놓칠 수 있습니다.
- 중복 여부는 고유 기준을 정한 뒤 판단해야 합니다. 행 전체가 같다는 이유만으로 지우기보다 주문번호, 고객 ID, 주문 시각, 상품 ID 중 어떤 조합이 한 건을 의미하는지 확인해야 합니다. 데이터 구조상 정상적으로 반복되는 행과 실제 중복 입력을 구분할 필요가 있습니다.
- 취소와 환불을 구분하면 매출 해석이 달라집니다
쇼핑몰 데이터를 분석한 준비생이 특정 월의 매출이 전월보다 크게 증가했다는 결과를 제시한 적이 있습니다. 그러나 결제 상태를 나누어보니 대규모 주문이 발생한 뒤 같은 달에 취소된 사례가 포함되어 있었습니다. 주문 금액만 합산했기 때문에 실제로 확보한 매출보다 높은 수치가 나온 것입니다.
준비생은 주문 완료, 취소, 부분 환불을 구분하고 분석 목적에 따라 계산 기준을 다시 세웠습니다. 주문 발생 규모를 확인할 때는 최초 결제 금액을 사용했고, 실제 매출을 비교할 때는 취소와 환불 금액을 반영했습니다. 그 결과 주문 수요 자체는 늘었지만 취소율도 함께 상승했다는 새로운 문제를 발견했습니다. 단순한 성장 결론이 결제 이후 이탈 원인을 확인해야 한다는 분석으로 바뀐 것입니다.
- 일괄 처리한 설명: 분석 전에 중복값과 결측값을 제거했습니다.
- 기준이 포함된 설명: 주문번호를 기준으로 중복 데이터를 확인하고 취소 주문을 정상 매출에서 제외했습니다.
- 업무 의미가 드러나는 설명: 주문 상세를 연결하면서 같은 주문번호가 여러 행으로 늘어난 것은 정상 구조로 판단해 삭제하지 않았습니다. 대신 주문 단위 매출을 별도로 집계했고, 결제 상태를 완료, 취소, 부분 환불로 구분했습니다. 수정 전후 결과를 비교하니 매출 증가와 함께 취소율도 높아졌다는 점을 발견해 결제 이후 과정의 점검이 필요하다고 해석했습니다.
- 정제 기준은 다른 사람이 재현할 수 있어야 합니다
포트폴리오에서 전처리를 완료했다고만 적으면 어떤 데이터가 제외되었는지 알기 어렵습니다. 분석 기간, 제외한 상태값, 중복 판단 기준, 결측값 처리 방법을 짧게라도 기록해야 합니다. SQL 파일에는 주석을 남기고 README에는 업무적인 이유를 설명하면 코드와 분석 목적을 함께 이해할 수 있습니다.
실제로 한 구독 서비스 프로젝트에서는 해지일이 없는 고객을 모두 결측 데이터로 분류했습니다. 하지만 해지일이 비어 있다는 것은 현재도 이용 중인 고객이라는 의미였습니다. 이를 삭제하면 활성 사용자 대부분이 분석에서 빠지게 됩니다. 준비생은 해지일의 빈 값을 오류가 아닌 상태 정보로 다시 해석하고, 분석 기준일을 사용해 이용 기간을 계산했습니다. 이 수정으로 장기 이용 고객과 조기 해지 고객의 차이를 비교할 수 있었습니다.
정제 과정은 데이터를 깨끗하게 만드는 작업이 아니라 분석 목적에 맞게 의미를 구분하는 과정입니다. 면접에서는 몇 건을 삭제했는지보다 왜 제외하거나 유지했는지를 설명해야 합니다. 처음 적용한 기준에서 문제가 발견되었다면 수정 전후의 결과까지 남기는 것이 좋습니다.
계산값을 업무 질문에 연결한 분석결과가 역량을 보여줍니다
- 숫자를 제시한 뒤 왜 그런지 한 번 더 물어야 합니다
SQL로 월별 매출이나 고객 수를 계산했다고 해서 분석이 끝나는 것은 아닙니다. 숫자의 변화가 어떤 고객군이나 상품에서 발생했는지 확인해야 실제 활용 가능한 정보가 됩니다. 전체 매출이 줄었다면 주문 고객 수가 감소한 것인지, 고객당 구매 금액이 낮아진 것인지, 취소율이 높아진 것인지 나누어 볼 수 있습니다.
한 온라인 교육 서비스 프로젝트에서는 월별 결제 고객 수가 증가했지만 전체 매출은 거의 변하지 않았습니다. 처음에는 신규 회원 확보가 성과라고 정리했지만, 상품별 결제 금액과 할인 사용 여부를 추가로 확인하니 저가 입문 강의와 신규 가입 쿠폰의 비중이 크게 늘어난 상태였습니다. 고객 수는 증가했지만 평균 결제 금액이 낮아져 전체 매출이 유지된 것입니다.
준비생은 이를 매출 정체로만 표현하지 않고 신규 고객 유입은 늘었지만 고가 과정으로 이어지는 비율을 추가로 확인해야 한다고 해석했습니다. 이후 첫 구매 상품별로 두 번째 구매 전환율을 계산해 입문 강의 구매 고객이 어떤 과정으로 이동하는지 살펴봤습니다. 하나의 집계 결과가 다음 분석 질문으로 이어진 사례입니다.
- 전체 수치를 세부 집단으로 나누어야 합니다. 신규와 기존 고객, 상품군, 유입 경로, 가입 시기처럼 문제와 관련된 기준을 선택하면 평균값에 가려진 차이를 찾을 수 있습니다. 다만 구분 기준을 무작정 늘리기보다 처음 세운 질문과 연결되는 항목을 선택해야 합니다.
- 예상과 다른 결과는 오류로 단정하지 않아야 합니다. 먼저 조인과 필터 조건을 다시 확인하고, 계산이 맞다면 데이터에서 나타난 현상으로 받아들여야 합니다. 가설이 틀렸다는 사실도 새로운 분석 방향을 만드는 근거가 될 수 있습니다.
- 재구매율은 관찰 기간에 따라 달라질 수 있습니다
재구매율을 계산할 때 전체 고객 중 두 번 이상 구매한 사람의 비율만 구하면 최근에 처음 구매한 고객이 불리하게 포함될 수 있습니다. 어제 첫 구매한 고객과 6개월 전에 첫 구매한 고객은 다시 구매할 수 있었던 기간이 다르기 때문입니다. 따라서 분석 목적에 따라 첫 구매 후 일정 기간이 지난 고객만 대상으로 정하거나 30일, 60일, 90일 재구매율을 구분해야 합니다.
실제로 한 준비생은 최근 1년간 고객을 모두 포함해 상품군별 재구매율을 계산했습니다. 신규 출시 상품은 최근 구매자가 많아 기존 상품보다 재구매율이 낮게 나타났습니다. 처음에는 상품 만족도가 낮다고 해석했지만 첫 구매 시점을 확인한 뒤 비교 조건이 공정하지 않다는 사실을 발견했습니다. 첫 구매 후 90일 이상 지난 고객만 남겨 다시 계산하자 상품군 간 차이가 줄었고, 특정 유입 채널에서 들어온 고객의 재구매가 낮다는 새로운 특징이 나타났습니다.
- 결과만 강조한 설명: SQL로 고객별 재구매율을 계산했습니다.
- 분석 기준이 보이는 설명: 첫 구매 후 90일 이상 관찰할 수 있는 고객만 대상으로 재구매 여부를 계산했습니다.
- 의사결정까지 이어진 설명: 전체 고객을 분모로 사용했을 때 최근 유입된 고객이 많은 상품의 재구매율이 낮게 나타나는 문제를 발견했습니다. 고객별 첫 구매일과 두 번째 구매일을 구한 뒤 90일의 관찰 기간을 적용했고, 상품군과 유입 채널별 차이를 다시 비교했습니다. 특정 광고 채널의 고객이 첫 구매 이후 이탈하는 경향을 확인해 유입 메시지와 후속 상품의 연결을 점검해야 한다고 제안했습니다.
- 결과를 표와 문장으로 함께 정리해야 합니다
면접관이 SQL 실행 화면만 보고 분석 내용을 이해하기는 어렵습니다. 최종 테이블에는 핵심 수치와 비교 기준을 담고, 그 아래에 관찰한 사실과 가능한 원인, 추가로 확인할 항목을 문장으로 정리하는 것이 좋습니다. 차트를 추가하더라도 무엇을 보여주는지 제목과 해석을 함께 적어야 합니다.
포트폴리오에서는 문제 배경, 데이터 구조, 정제 기준, 핵심 쿼리, 검증 과정, 발견 내용, 제안 순서로 구성하면 흐름을 이해하기 쉽습니다. 전체 코드를 본문에 붙이기보다 결과가 달라진 조건이나 판단이 필요했던 부분을 선별해 보여주는 편이 효과적입니다. 상세 SQL 파일은 GitHub에 연결하고 본문에는 쿼리를 작성한 이유와 결과를 중심으로 설명할 수 있습니다.
같은 프로젝트라도 데이터 분석가는 지표 기준과 해석을 더 강조할 수 있고, 데이터 엔지니어 지원자는 테이블 구조와 처리 흐름, 재현 가능성을 더 구체적으로 보여줄 수 있습니다. 서비스 기획이나 마케팅 데이터 직무라면 수치를 실제 업무 제안으로 연결하는 부분이 중요합니다. 지원 직무에 따라 같은 경험에서 앞에 배치할 내용을 조정해야 프로젝트가 직무 자료로 보입니다.
- conclusion
SQL 실습을 데이터 직무 역량으로 보여주는 핵심은 복잡한 문법을 많이 사용했다는 사실에 있지 않습니다. 해결할 질문을 정하고 필요한 테이블을 선택한 과정, 중복과 결측값의 의미를 확인한 기준, 계산 결과가 예상과 다를 때 원본 행으로 돌아가 검증한 경험이 보여야 합니다. 여기에 분석한 수치를 업무에서 활용할 수 있는 제안으로 연결하면 간단한 실습도 충분한 취업 자료가 됩니다.
지금 자신의 SQL 프로젝트를 다시 열어본다면 가장 긴 쿼리보다 결과가 달라졌던 지점을 먼저 확인해 보는 것이 좋습니다. 조인 이후 행이 늘어난 이유를 설명할 수 있는지, 취소와 환불을 어떤 기준으로 처리했는지, 지표의 분자와 분모를 다른 사람도 이해할 수 있는지 살펴봐야 합니다. 이러한 기준이 없다면 새로운 프로젝트를 시작하기 전에 기존 결과를 다시 검증하는 편이 더 효과적일 수 있습니다.
- 작성 과정을 점검할 때는 분석 질문과 테이블 관계가 연결되어 있는지 확인해야 합니다. 사용한 문법을 나열하기보다 어떤 정보를 얻기 위해 해당 조인과 집계를 선택했는지 설명할 수 있어야 합니다.
- 정제 단계에서는 중복과 결측값을 무조건 제거하지 않았는지 살펴봐야 합니다. 데이터가 생성된 이유와 업무 의미를 확인하고 유지, 제외, 대체 기준을 기록하면 면접에서도 근거 있는 답변을 할 수 있습니다.
- 최종 결과에서는 수치 하나로 결론을 내리지 않았는지 점검해야 합니다. 고객군과 기간을 나누어 차이를 비교하고, 예상과 다른 결과를 다시 검증한 뒤 추가 분석이나 업무 제안으로 연결해야 합니다.
실제 프로젝트를 검토하면 SQL문은 길지만 분석 대상과 제외 조건을 설명하지 못하는 경우가 많습니다. 이런 자료는 문법을 연습했다는 사실은 보여주지만 데이터 직무에서 필요한 판단 능력까지 전달하기는 어렵습니다. 반대로 단순한 집계라도 처음 결과의 오류를 발견하고 조인 기준과 관찰 기간을 수정한 과정이 있다면 문제해결 경험으로 발전합니다.
쿼리를 완성한 뒤에는 데이터 질문, 사용한 테이블, 정제 조건, 검증 방법, 핵심 결과, 제안을 한 페이지에 정리해 보세요. 이 기록은 이력서에서 프로젝트 성과로 압축할 수 있고, 포트폴리오에서는 분석 흐름을 보여주며, 면접에서는 데이터 기준과 문제해결 과정을 묻는 질문의 근거가 됩니다. 결국 SQL 실습이 취업 자료로 바뀌는 순간은 쿼리가 오류 없이 실행되었을 때가 아니라, 그 결과가 왜 나왔는지를 검증하고 업무적인 의미까지 설명할 수 있게 되었을 때입니다.
