데이터 이해와 활용
실제 사례는 공개 기록을 바탕으로, 가상 사례는 개념을 설명하기 위한 설정으로 작성했습니다.
매출 그래프만 보고 도시락을 더 주문했다
데이터웨어하우스와 분석 목적 — 어떤 결정을 도울지 정한다
본사는 판매량만으로 수요를 단정하지 않도록 판매·품절·입고 기록을 같은 상품과 날짜로 모아 발주에 사용했습니다.
이야기 읽기 →두 부서의 매출이 모두 맞았다
데이터 표준화 — 데이터의 이름·형식·계산 기준을 맞춘다
영업팀의 주문액과 재무팀의 취소를 뺀 정산액을 구분했습니다. 지표 옆에 기준일과 취소 반영 여부를 표시했습니다.
이야기 읽기 →이름으로 합치고 전화번호로 나누자 고객 수가 바뀌었다
키와 식별 — 표의 한 행이 나타내는 대상을 구별한다
동명이인과 번호 변경을 이름·전화번호로 억지 연결하지 않고 고객 번호로 확인한 기록만 결합했습니다.
이야기 읽기 →빈 날짜를 오늘 날짜로 채웠다
품질 — 용도에 맞게 믿을 수 있는지 확인한다
입고일이 비어 있다는 이유로 오늘 날짜를 넣지 않았습니다. 확인 가능한 값만 보완하고 미확인 자료의 비율을 표시했습니다.
이야기 읽기 →고객 주소를 고치니 과거 배송지도 바뀌었다
데이터 모델 — 업무 대상과 관계를 저장 구조로 표현한다
고객이 이사해도 과거 배송지를 확인할 수 있도록 주문 당시 주소를 주문에 저장했습니다. 현재 연락 주소와 구분해 관리했습니다.
이야기 읽기 →주문은 확정됐지만 마지막 재고는 그대로였다
트랜잭션의 ACID — 함께 바뀔 데이터를 묶는다
같은 데이터베이스의 재고 확보와 주문 저장을 함께 처리하고, 외부 결제의 확인·취소는 별도 절차로 관리했습니다.
이야기 읽기 →보고서에서 사라진 반품
ETL — 원본 자료를 가져와 변환·저장한 과정을 남긴다
음수 매출은 오류가 아니라 반품 기록이었습니다. 원본에서 보고서까지의 변환을 확인하고 반품을 포함하도록 규칙을 고쳤습니다.
이야기 읽기 →광고를 본 고객이 많이 샀다는 이유
서술·예측 분석 — 패턴과 원인을 구분한다
광고를 본 고객은 원래 구매가 잦았습니다. 분석가는 기존 구매 성향을 살펴 비교 집단의 조건 차이를 확인했습니다.
이야기 읽기 →분석용 파일이 계속 쌓였다
접근과 보관 — 필요한 데이터만 필요한 사람에게 준다
개인 폴더에 고객 원본이 계속 쌓이지 않도록 공용 분석 환경을 마련했습니다. 보관할 결과와 삭제할 사본을 구분했습니다.
이야기 읽기 →매일 갱신되는 줄 알았던 표
운영 책임 — 데이터 갱신과 오류 수정 담당자를 정한다
사흘 전 재고로 주문받는 일을 줄이기 위해 갱신 담당자와 알림 수신자를 정했습니다. 화면에는 마지막 갱신 시각을 표시했습니다.
이야기 읽기 →같은 상품이 서로 다른 이름으로 팔렸다
기준정보 — 여러 업무가 같은 대상을 가리키게 한다
용량이 다른 상품을 이름만으로 합치지 않도록 상품 기준표와 코드 대응표를 만들었습니다. 신규 코드 등록 책임도 정했습니다.
이야기 읽기 →자정 주문이 다른 날 매출에 잡혔다
시간 기준 — 언제의 데이터인지 함께 저장한다
해외 주문의 협정 세계시와 한국 시간을 구분했습니다. 자정 전후 주문으로 날짜 변환을 시험했습니다.
이야기 읽기 →실패한 작업을 다시 돌리니 판매가 두 배가 됐다
재처리와 중복 — 다시 실행해도 거래가 중복되지 않게 한다
거래 번호와 처리 이력을 확인해 판매 파일 재실행 시 같은 거래를 다시 더하지 않았습니다. 중간 실패 후 다시 실행하는 시험도 추가했습니다.
이야기 읽기 →금액 열의 형식이 바뀐 날
스키마 변경 — 자료 형식의 변화를 관리한다
금액에 통화 문자가 붙은 파일을 빈칸으로 바꾸지 않고 오류로 분리했습니다. 공급업체와 변경 안내 및 시험 파일 제공을 합의했습니다.
이야기 읽기 →합계는 맞는데 수량이 뒤집혔다
무결성 — 값과 업무 규칙을 검사한다
반품인지 출고인지에 따라 수량의 부호를 검사했습니다. 모든 음수를 허용하던 입력 규칙을 거래 종류별로 고쳤습니다.
이야기 읽기 →응답한 고객만 본 만족도
데이터의 유용성 — 수집한 자료가 누구를 포함하는지 확인한다
앱 설문에 적게 참여한 전화 상담 고객의 경험도 들었습니다. 설문 점수가 설명하는 고객의 범위를 명확히 했습니다.
이야기 읽기 →전사 보고서가 주문 처리를 느리게 했다
질의 최적화 — 필요한 결과를 적은 비용으로 얻는다
운영 DB의 긴 조회가 주문 처리와 같은 자원을 사용했습니다. 조회 범위를 줄이고 반복 집계는 별도 분석 자료로 옮겼습니다.
이야기 읽기 →수정된 재고의 이유를 찾을 수 없었다
이력과 감사 가능성 — 누가 언제 왜 값을 바꿨는지 남긴다
재고 변경 전후 값과 이유를 기록했습니다. 잘못된 보정도 지우지 않고 추가 보정으로 남겨 변경 과정을 확인할 수 있게 했습니다.
이야기 읽기 →같은 재고표로 판매 확정과 다음 날 발주를 판단했다
데이터 서비스 수준 — 제공 조건을 합의한다
전날 재고표는 발주 분석에 쓰고 당일 판매 확정은 별도 재고 확보 경로로 처리하도록 제공 조건을 나눴습니다.
이야기 읽기 →버튼 색을 바꾼 주의 매출 증가는 누구의 성과일까
AB 테스팅 — 비교 전에 성공 기준을 정한다
팀은 같은 기간 고객을 두 버튼 화면에 무작위 배정하고 완료 주문과 취소를 함께 비교하도록 실험을 설계했습니다.
이야기 읽기 →