CX 데이터 분석 입문: 데이터 품질·SQL 결합·포트폴리오 예시

CX 데이터 분석은 고객의 의견과 이용 기록을 살펴 서비스 경험을 이해하고 개선할 판단을 돕는 일입니다. 데이터가 많거나 대시보드가 정교하다고 해서 고객의 생각과 이탈 원인을 정확히 알게 되는 것은 아닙니다. 어떤 자료를 누구의 어떤 경험과 연결했는지, 계산이 올바른지부터 확인해야 합니다.

이 글은 자료 범위와 품질 점검, 주문·문의 데이터를 결합할 때의 중복 집계, 결과를 보고서와 포트폴리오로 정리하는 방법을 다룹니다. 주문 5건·문의 4건과 아래 SQL은 설명을 위해 별도로 구성한 가상 예시이며 실제 고객 데이터나 기업의 개선 성과가 아닙니다.

목차

1. CX 데이터의 범위와 해석 한계
2. 분석 전에 확인할 데이터 품질
3. 가상 주문·문의 결합에서 생기는 중복
4. SQL로 주문 단위를 유지하는 예시
5. 보고서와 개선 확인 계획
6. 관련 업무와 취업 준비 방법
7. 자주 묻는 질문

고객 의견과 이용 기록은 각 자료의 범위를 확인한 뒤 함께 해석합니다.

CX 데이터의 범위와 해석 한계

CX는 Customer Experience, 고객 경험을 뜻합니다. 분석에 쓰는 자료는 설문·고객 의견뿐 아니라 주문·배송·상담·서비스 사용 기록까지 포함할 수 있습니다. 모든 회사가 같은 데이터 구조나 “CX 데이터 분석가”라는 직함을 사용하는 것은 아니므로 목적과 업무 범위를 먼저 확인하세요.

Qualtrics의 경험 데이터와 운영 데이터 설명은 사람의 인식·태도에 관한 자료와 운영 시스템의 기록을 구분해 함께 살피는 관점을 제시합니다. 이 글에서는 고객이 전한 배송 경험과 주문·문의 기록의 관계를 생각해 볼 수 있습니다. 이를 연결해도 응답하지 않은 고객의 감정이나 모든 문제의 원인이 자동으로 밝혀지지는 않습니다.

자료마다 담는 내용과 확인할 한계

자료 예시	살펴볼 내용	주의할 해석
주문·배송 기록	주문 상태, 처리 시점, 배송 흐름	기록 지연이나 상태 정의 차이 확인. 고객의 만족도를 직접 측정한 자료는 아님
웹·앱 행동 기록	기록된 화면 방문과 행동 경로	수집 누락·기기 식별·이벤트 중복 확인. 반복 조회만으로 가격 불만을 확정하지 않음
고객센터 문의	도움을 요청한 내용과 응대 과정	문의를 남긴 사람과 전체 고객 구분. 문의 건수와 고객 수 구분
설문·리뷰	응답자가 표현한 의견과 평가	질문·척도·응답 시점·선정 편향 확인. 답하지 않은 사람의 의견을 채우지 않음

직원 퇴사율이나 근무 만족도는 직원 경험을 다루는 자료입니다. 회사에 관한 수치라는 이유만으로 고객 경험의 성과로 대신 사용할 수 없습니다. 마찬가지로 CX 분석은 작은 표본·업무 기록에서도 시작할 수 있으므로 반드시 대규모 빅데이터 분석의 한 분야로만 정의할 필요는 없습니다.

분석 전에 확인할 데이터 품질

“데이터는 거짓말하지 않는다”는 말보다 수집·가공·해석에서 생길 오류를 점검하는 태도가 필요합니다. 영국 정부 데이터 품질 체계는 사용 목적에 맞는 품질을 강조하고 완전성·유일성·일관성·적시성·유효성·정확성 등의 관점을 설명합니다. 이는 모든 조직에 동일한 합격 점수를 부여하는 기준은 아닙니다.

주문·문의 분석에 적용해 보는 품질 질문

관점	이 글의 점검 예시
완전성	분석할 기간의 주문이 빠지지 않았는가, 필요한 주문 번호가 비어 있지는 않은가
유일성	주문 표에 주문 하나가 여러 행으로 중복 적재되지 않았는가
일관성	주문 표와 상담 표에서 같은 주문의 상태·식별 규칙이 충돌하지 않는가
적시성	주문 기록과 상담 기록이 언제까지 갱신됐는가, 비교할 만큼 같은 시점을 담는가
유효성	날짜·금액·상태가 정한 형식과 허용 범위에 맞는가
정확성	기록된 주문 금액이나 상태가 확인 가능한 원천 기록과 맞는가

빈칸이 없다는 사실이 값의 정확성을 보장하지는 않습니다. 형식이 맞는 날짜도 잘못 입력된 날짜일 수 있습니다. 품질 보고서에는 검사 항목·대상 행 수·문제 건수·미확인 범위를 적고, 서로 다른 문제를 근거 없이 하나의 “품질 점수”로 합치지 마세요.

데이터 결합 전에는 표의 한 행이 무엇을 뜻하는지 적어 두세요. 주문 한 행, 상품 한 행, 상담 메시지 한 행을 섞으면 같은 고객이나 주문이 반복됩니다. 이름·이메일 같은 식별 정보로 임의 연결하지 말고, 허용된 자료와 정의된 연결 키를 사용하며 연결할 수 없는 기록도 별도 확인합니다.

가상 주문·문의 결합에서 생기는 중복

아래 O1~O5와 T1~T4는 모두 가상 데이터입니다. 주문 표에는 주문당 한 행이 있고, 취소·환불·세금·배송비 조정은 없는 단순한 주문 금액으로 가정합니다. 문의 표에는 서로 다른 티켓당 한 행이 있으며 네 티켓 모두 표 안의 주문에 연결된다고 가정합니다.

가상 주문 5건과 연결된 문의

주문	주문 금액	연결된 문의 티켓
O1	10,000원	T1, T2
O2	20,000원	없음
O3	30,000원	T3
O4	40,000원	없음
O5	50,000원	T4

주문 금액의 원래 합계는 150,000원입니다. 그런데 주문과 문의를 주문 번호로 바로 LEFT JOIN하면, O1은 T1과 T2에 각각 연결되어 두 행이 됩니다. 문의가 없는 O2·O4도 남으므로 결합 결과는 6행입니다. 이 결과에서 주문 금액을 그대로 더하면 O1의 10,000원이 두 번 들어가 160,000원으로 부풀려집니다.

이는 데이터가 새로 생긴 것이 아니라 표를 결합하면서 원래 값이 반복된 것입니다. PostgreSQL의 JOIN 설명에서도 조건에 맞는 오른쪽 행마다 결합 행이 생기고, LEFT JOIN은 연결되지 않는 왼쪽 행도 남긴다는 동작을 확인할 수 있습니다. 여기의 주문 예시와 금액은 공식 문서 사례를 복사한 것이 아니라 별도로 구성했습니다.

주문 수만 COUNT(DISTINCT order_id)로 고쳐도 금액 합계는 여전히 중복될 수 있습니다. SUM(DISTINCT amount) 역시 일반적인 해결책이 아닙니다. 서로 다른 주문의 금액이 같다면 필요한 금액까지 한 번만 더하기 때문입니다. 원하는 집계 단위에 맞게 먼저 요약하거나 주문 합계와 문의 합계를 따로 계산해야 합니다.

• 문의 티켓 수: T1~T4의 4건입니다.
• 문의가 연결된 주문 수: O1·O3·O5의 3건입니다.
• 문의가 연결된 주문 비율: 3÷5×100=60%입니다.
• 주문 100건당 문의 티켓: 4÷5×100=80건입니다. 이는 80%의 고객이 문의했다는 뜻이 아닙니다.

작은 가상 표의 숫자는 계산 과정을 확인하기 위한 값이며 서비스의 실제 기준치나 목표가 아닙니다. 문의가 없다는 사실만으로 만족했다고 판단할 수도 없습니다.

SQL로 주문 단위를 유지하는 예시

아래 SQL은 앞의 가상 자료를 그대로 포함합니다. 먼저 문의를 주문별로 집계해 주문당 최대 한 행으로 만든 뒤, 주문 표와 결합하는 연습입니다. 실제 업무 데이터베이스에 접속할 필요 없이 자료와 계산 구조를 읽을 수 있습니다.

WITH
orders(order_id, amount) AS (
  VALUES ('O1', 10000), ('O2', 20000),
         ('O3', 30000), ('O4', 40000), ('O5', 50000)
),
tickets(ticket_id, order_id) AS (
  VALUES ('T1', 'O1'), ('T2', 'O1'),
         ('T3', 'O3'), ('T4', 'O5')
),
ticket_counts AS (
  SELECT order_id, COUNT(*) AS ticket_count
  FROM tickets
  GROUP BY order_id
),
order_level AS (
  SELECT o.order_id, o.amount,
         COALESCE(t.ticket_count, 0) AS ticket_count
  FROM orders o
  LEFT JOIN ticket_counts t ON o.order_id = t.order_id
)
SELECT COUNT(*) AS orders,
       SUM(amount) AS order_amount,
       SUM(ticket_count) AS tickets,
       SUM(CASE WHEN ticket_count > 0 THEN 1 ELSE 0 END)
         AS orders_with_tickets
FROM order_level;

이 예시의 결과는 orders=5, order_amount=150000, tickets=4, orders_with_tickets=3입니다. SQL을 사용하지 않는 연습이라면 주문별로 문의 수를 묶은 표를 만든 뒤 주문 표와 연결해도 같은 집계 구조를 확인할 수 있습니다.

실제 자료에 적용할 때는 다음 조건을 추가로 확인하세요. 주문 표의 주문 번호가 유일한지, 티켓 표에 중복 적재가 없는지, 주문 번호가 비어 있거나 주문 표에 없는 티켓이 있는지 점검해야 합니다. 위 코드의 COUNT(*)는 티켓 표 한 행이 중복 없는 티켓 하나라는 가정에 의존합니다. 문의 이력 변경마다 행이 생기는 표라면 먼저 티켓의 정의와 중복 처리를 검토하세요.

기간도 맞춰야 합니다. 이번 달에 만들어진 주문을 분석하는지, 이번 달에 들어온 모든 문의를 분석하는지에 따라 포함할 대상이 달라집니다. 이전 달 주문의 이번 달 문의를 어떻게 다룰지, 취소·환불을 금액에 언제 반영할지 정한 뒤 결합하세요. 연결되지 않은 문의를 숨겨 놓고 전체 문의가 집계됐다고 쓰지 않습니다.

분석 도구와 함께 집계 기준과 데이터 품질을 점검하는 연습이 필요합니다.

보고서와 개선 확인 계획

데이터를 결합해 숫자를 얻은 뒤에는 확인한 사실과 앞으로 확인할 질문을 분리합니다. 앞의 가상 자료로는 문의가 발생한 주문 수를 셀 수 있지만 문의 원인·만족도·재구매 영향은 알 수 없습니다. 추가 자료가 필요한 지점을 드러내는 것이 보고서의 일부입니다.

1. 분석 목적: 어떤 경험을 살피고 누구의 어떤 판단을 돕는지 한 문장으로 적습니다.
2. 자료와 집계: 기간, 표별 한 행의 의미, 연결 키, 포함·제외·미연결 건수를 적습니다.
3. 품질 확인: 중복·누락·갱신 시점 점검과 아직 확인하지 못한 항목을 남깁니다.
4. 관찰 결과: 건수·금액·비율의 분자와 분모를 함께 보여 줍니다. 이 글의 경우 가상 주문5건, 문의4건, 문의 연결 주문3건입니다.
5. 해석과 제안: 문의 내용이나 서비스 흐름을 추가로 살필 필요가 있다는 수준으로 제안합니다. 문의가 존재한다는 이유만으로 제품 결함·고객 이탈을 확정하지 않습니다.
6. 후속 검증: 담당자, 필요한 자료, 검토할 대안, 반영 여부와 비교 기준을 기록합니다. 계획·실행·효과 측정을 구분합니다.

고객의 서술을 분류하는 과정은 VOC 분석의 분류·지표 계산 예시에서 이어 볼 수 있습니다. 행동의 이유를 더 알아봐야 한다면 UX 리서치의 질문·관찰·해석 구분을 참고해 추가 조사를 설계할 수 있습니다.

전후 수치가 달라졌다고 개선안의 효과가 확정되는 것은 아닙니다. 이용 규모·고객 구성·시즌·수집 방식이 함께 바뀌었는지 검토하세요. 공개할 수 있는 성과가 없다면 분석 결과와 제안 범위를 제시하면 됩니다. 이탈률10% 감소나 전환율5% 상승 같은 숫자를 근거 없이 채우지 않습니다.

관련 업무와 취업 준비 방법

CX 관련 공고를 볼 때는 직함보다 맡을 일을 읽으세요. 데이터 추출·품질 점검·보고서 작성이 중심인지, 상담 운영과 문제 전달이 중심인지, 고객의 제품 활용 지원이나 개선 프로젝트 조율이 중심인지에 따라 준비가 달라집니다. 한 사람이 여러 업무를 함께 맡을 수도 있습니다.

공고의 업무를 준비 자료로 연결하는 예시

요구 업무	보여 줄 수 있는 자료
데이터 추출·정리	한 행의 의미, 결합 조건, 중복·누락 점검과 재현 가능한 계산
대시보드·보고	지표 정의, 기간·분모, 차트에서 답하려는 질문과 해석 한계
고객 문제 파악	문의 분류 기준, 원인 확인에 필요한 자료, 직접 담당한 범위
개선 협업	제안·팀 결정·실제 반영·후속 확인을 구분한 기록

SQL·Python·R·시각화 도구를 모두 익혀야 모든 CX 직무에 지원할 수 있는 것은 아닙니다. 공고의 필수 조건과 우대 조건을 나누고, 그 도구로 무엇을 해야 하는지 확인하세요. 먼저 작은 자료에서 잘못된 집계를 발견하고 설명할 수 있는지 점검한 뒤 필요한 분석·통계·도구 학습을 늘려 갈 수 있습니다.

포트폴리오에는 자료 출처·이용 범위, 문제 정의, 정리 과정, 계산, 결론과 한계, 직접 수행한 범위를 남기세요. 이 글의 SQL을 연습했다면 “가상 주문·문의 결합에서 금액 중복을 확인하고 주문별 집계로 바로잡았다”라고 설명할 수 있습니다. 실제 회사의 고객 문제를 해결하거나 매출을 개선했다고 쓰면 안 됩니다.

AI가 만든 분류·요약·예측은 결과를 원자료와 대조하고 검증할 필요가 있습니다. 고객 감정을 확실히 읽거나 미래 행동을 보장하는 도구로 보지 마세요. 실제 예측 과제에서는 학습에 쓰지 않은 자료의 평가, 예측 시점에 알 수 없는 정보가 들어갔는지 등을 검토해야 합니다. 개인 학습에서 생성한 고객 답변도 가상 자료로 표시합니다.

고객 자료를 활용할 때는 조직의 접근 권한·처리 목적·보관·공개 기준을 확인하세요. 원문의 개인 정보를 임의로 외부 도구나 공개 저장소에 올리지 않습니다. 법적 요건은 적용되는 상황에 따라 확인해야 하며, 특정 해외 법률 이름을 나열했다고 모든 요건이 충족되는 것은 아닙니다.

연봉·학위·자격증·근무 조건·채용 여부는 현재 공식 공고의 기준으로 비교하세요. 확인되지 않은 기업 사례나 교육 홍보를 근거로 고용 수요가 계속 늘거나 특정 성별에게 기회가 많다고 단정하지 않습니다. 퇴사·재직·이직은 생활 여건과 목표에 맞춰 판단할 선택이며, 데이터 학습의 성과와 구분할 필요가 있습니다.

자주 묻는 질문

CX 데이터 분석은 반드시 빅데이터를 다뤄야 하나요?

그렇지 않습니다. 고객 경험에 관한 질문에 답할 수 있는 자료가 중요합니다. 작은 표에서도 집계 단위·품질·해석 한계를 설명하는 분석을 연습할 수 있습니다.

왜 주문과 문의를 연결하면 금액이 늘어나나요?

한 주문에 여러 문의가 연결되면 주문 금액이 여러 행에 반복될 수 있기 때문입니다. 주문 기준 합계가 필요하다면 주문 단위를 유지하도록 집계 구조를 정하고 원래 합계와 대조하세요.

문의가 없는 고객은 만족한 고객인가요?

문의 기록이 없다는 것과 만족도를 확인했다는 것은 다릅니다. 채널 누락이나 문의하지 않은 경험도 있을 수 있습니다. 고객의 의견을 알 수 없는 부분은 미확인으로 남깁니다.

SQL이나 특정 전공이 모든 관련 직무에 필수인가요?

지원 공고별로 확인해야 합니다. 분석·운영·고객 활용 지원·프로젝트 조율 등 업무 범위가 다르므로 필수 자격과 실제로 맡는 작업을 기준으로 준비하세요.

데이터로 개선안을 제시하면 성과로 써도 되나요?

분석과 제안의 성과를 설명할 수 있지만, 실제 반영·고객 경험 변화·매출 효과를 측정했다는 뜻은 아닙니다. 수행한 범위에 맞는 동사를 사용하고 확인하지 않은 개선 수치를 만들지 마세요.

자료 확인: 2026-09-08. 본문의 주문·문의·금액과 SQL은 별도로 구성한 교육용 예시입니다. 실제 기업 자료를 분석하거나 고객 경험의 개선 효과를 측정한 결과가 아닙니다.