핵심노트 · 주제 02

데이터 이해와 활용

이게 뭔가요?

업무에서 생기는 사실을 어떤 형태로 기록하고, 서로 연결하고, 찾아서 활용할지 배웁니다. 식당 예약 앱에서는 누가 어느 시간에 예약했는지, 취소했는지, 자리가 몇 개 남았는지를 일관되게 저장하고 확인하는 일입니다.

왜 배우나요?

고객 화면에는 예약 완료인데 식당 명단에는 없다면 현장에서 자리를 배정하지 못할 수 있습니다. 취소된 단체 예약까지 세면 준비할 음식 수량도 잘못 판단할 수 있습니다. 여러 사람이 같은 자료를 사용해도 내용이 어긋나지 않게 관리하고, 믿을 수 있는 자료를 바탕으로 판단하기 위해 배웁니다.

데이터를 많이 모으는 것보다, 같은 의미로 해석하고 믿을 수 있는 판단에 사용하는 것이 먼저입니다.

교재 개념의 뜻을 설명하고, 가상 업무에서 언제 왜 쓰는지 풀어 쓴 자체 해설입니다. 먼저 설명과 예시를 읽고, 확인 질문에 자신의 말로 답해 보세요. 각 항목의 관련 교재 내용에서 단원과 교재 페이지를 확인할 수 있습니다. 20개 노트는 교재 전체 요약이나 시험 중요도 순위가 아니며, 주제 끝의 추가 학습 내용도 함께 확인하세요.

1. 데이터웨어하우스와 분석 목적 — 어떤 결정을 도울지 정한다

데이터웨어하우스(DW)는 여러 업무 시스템의 자료를 모아 비교와 분석에 쓰는 저장소입니다. 주문을 처리하는 시스템과 달리, 기간이나 지점별 변화를 살펴보고 판단하는 데 초점을 둡니다.

점장이 다음 주에 주문할 물량을 정하려면 누적 매출만으로는 부족합니다. 최근 상품별 판매량, 남은 재고, 입고 예정일을 함께 알아야 합니다. 따라서 먼저 ‘누가 어떤 결정을 할 것인가’를 정하고 그 결정에 필요한 자료를 모아야 합니다.

가상 업무 예시

편의점 본사는 다음 주 도시락 발주량을 매장별로 정하려 합니다. 판매 시스템의 주간 판매량만 보면 매진으로 못 판 수요를 놓치고, 창고 재고만 보면 어느 지점에서 부족했는지 모릅니다. 분석 담당자는 매장·날짜·상품 기준을 맞춰 판매, 품절, 입고 기록을 분석 저장소에 모읍니다. 본사는 같은 요일의 흐름을 비교해 발주량을 조정하며, 오늘 주문 접수는 기존 판매 시스템이 계속 처리합니다.

생각해 볼 질문
이 분석 결과는 누가 어떤 결정을 할 때 사용하나요? 발주량을 정하는 데 필요한 판매량과 재고가 포함됐나요?

2. 데이터 표준화 — 데이터의 이름·형식·계산 기준을 맞춘다

데이터 표준화는 자료의 이름·의미·형식·작성 규칙을 조직에서 함께 정하는 일입니다. 같은 단어를 써도 뜻이 다르면 자료를 합쳤을 때 잘못된 결과가 나올 수 있습니다.

영업팀은 주문된 금액을, 회계팀은 반품을 뺀 확정 금액을 ‘매출’이라고 부를 수 있습니다. 두 숫자를 비교하려면 어떤 거래를 포함하는지와 어느 날짜를 기준으로 계산하는지부터 맞춰야 합니다. 표의 제목만 같게 바꾸는 것으로는 해결되지 않습니다.

가상 업무 예시

영업 보고서는 주문액 100만 원을 매출로 표시하고, 회계 보고서는 그중 취소된 20만 원을 빼 80만 원을 표시했습니다. 담당자는 한쪽을 오류로 고치기 전에 두 값의 정의를 확인합니다. 보고서에 ‘주문액’과 ‘취소 차감액’을 구분하고, 같은 실적을 비교할 때는 기간과 취소 반영 기준을 맞춥니다.

생각해 볼 질문
매출에 포함할 거래와 제외할 거래, 집계 날짜를 정했나요? 부서가 달라도 같은 기준으로 계산하나요?

3. 키와 식별 — 표의 한 행이 나타내는 대상을 구별한다

기본키는 표에서 각 행을 구별하는 값입니다. 다른 행과 중복되지 않고 값이 비어 있지 않아야 합니다. 고객 이름은 동명이인이 있을 수 있으므로 보통 별도의 고객 번호로 구별합니다.

자료를 합칠 때는 한 행이 무엇을 뜻하는지도 확인해야 합니다. 주문 한 건에 상품 세 개가 있으면 상품별 자료에 주문 총액이 세 번 나타날 수 있습니다. 이 금액을 그대로 더하면 매출이 세 배가 되므로 주문 단위와 상품 단위를 구분해서 계산해야 합니다.

가상 업무 예시

주문 501번의 총액은 3만 원이고 상품은 세 종류입니다. 주문 표는 501번으로 한 건을 구별하지만 주문상품 표는 ‘501번+상품 행 번호’로 세 행을 구별합니다. 두 표를 연결하면 3만 원이 세 행에 반복되므로 그대로 더한 9만 원은 잘못된 매출입니다. 주문 번호별로 한 번만 합산하거나 상품별 금액을 더하도록 계산 단위를 정합니다.

생각해 볼 질문
표의 한 행은 주문 한 건인가요, 주문에 담긴 상품 한 개인가요? 표를 연결한 뒤 주문 금액이 중복 합산되지는 않나요?

4. 품질 — 용도에 맞게 믿을 수 있는지 확인한다

데이터 품질은 자료가 정확하고 서로 일치하는지, 필요한 시점에 목적에 맞게 쓸 수 있는지를 살피는 것입니다. 자료를 열어 볼 수 있는지와 안전하게 보호하는지도 포함합니다.

전화번호가 정해진 자릿수를 지켜도 고객이 번호를 바꿨다면 연락에 쓸 수 없습니다. 형식 검사뿐 아니라 최신 정보인지도 확인해야 하는 이유입니다. 배송 안내가 목적이라면 실제 연락 실패율을 살피고 고객이 번호를 고칠 방법을 마련할 수 있습니다.

가상 업무 예시

배송용 전화번호의 자릿수가 맞아도 고객이 번호를 바꿨다면 연락할 수 없습니다. 담당자는 연락 실패가 접수되면 고객에게 새 번호를 확인하고, 확인한 번호로 기록을 수정하는 절차를 마련합니다.

생각해 볼 질문
잘못된 전화번호나 주소처럼 업무 실패를 일으킬 데이터는 무엇인가요? 오류를 누가 발견하고 수정하나요?

5. 데이터 모델 — 업무 대상과 관계를 저장 구조로 표현한다

데이터 모델링은 실제 업무에서 관리할 대상, 대상의 특징, 대상 사이의 관계를 정리하는 작업입니다. 예를 들어 고객은 주문을 하고 주문에는 여러 상품이 포함됩니다. 이런 관계를 정리한 뒤 저장할 표와 연결 방법을 설계합니다.

상품의 현재 가격만 저장하면 가격이 바뀐 뒤 과거 주문 금액을 다시 계산하기 어렵습니다. 주문 당시의 판매 가격도 보관해야 합니다. 무엇을 저장할지는 현재 화면뿐 아니라 나중에 어떤 사실을 확인해야 하는지를 생각하며 결정합니다.

가상 업무 예시

상품의 현재 가격만 저장하면 가격 변경 후 옛 주문의 결제 금액을 재현하기 어렵습니다. 주문 당시 적용한 가격을 거래 기록에 남겨 현재 판매 가격과 구분합니다.

생각해 볼 질문
상품 가격이 바뀐 뒤에도 과거 주문 당시의 가격과 결제 금액을 확인할 수 있나요?

6. 트랜잭션의 ACID — 함께 바뀔 데이터를 묶는다

트랜잭션은 하나의 작업으로 묶어 처리할 데이터 연산입니다. ACID는 그 작업이 지켜야 할 네 성질입니다. 원자성은 전부 성공하거나 전부 취소되는 것, 일관성은 정해진 데이터 규칙을 지키는 것, 고립성은 동시에 진행되는 작업이 서로 잘못된 영향을 주지 않도록 제어하는 것, 영속성은 확정한 결과가 장애 후에도 유지되는 것입니다.

주문 저장과 재고 차감을 한 트랜잭션으로 묶으면 재고 차감 실패 시 주문 저장도 취소할 수 있습니다. 다만 외부 결제 업체의 처리까지 같은 범위로 묶이는 것은 아닙니다. 어느 데이터베이스의 어떤 작업을 함께 처리하는지 범위를 확인해야 합니다.

가상 업무 예시

마지막 재고 한 개를 주문하면서 주문 행은 저장됐지만 재고 변경에서 오류가 났습니다. 둘을 따로 확정하면 다음 고객도 남은 한 개를 살 수 있다고 보게 됩니다. 같은 데이터베이스의 주문 저장과 재고 차감을 한 트랜잭션으로 묶으면 오류 때 둘 다 취소할 수 있습니다. 재시도한 주문은 다시 재고를 확인해야 하며, 외부 결제 취소는 별도로 처리합니다.

생각해 볼 질문
주문 등록과 재고 차감 중 하나만 성공하면 어떤 문제가 생기나요? 두 결과가 어긋났는지 확인하고 바로잡을 방법이 있나요?

7. ETL — 원본 자료를 가져와 변환·저장한 과정을 남긴다

ETL은 자료를 가져오고(Extract), 분석에 맞게 바꾸고(Transform), 저장소에 넣는(Load) 과정입니다. 서로 다른 시스템의 자료를 모을 때 날짜 형식이나 단위를 맞추고 중복을 처리하는 작업이 포함됩니다.

원본 주문 자료가 정확해도 변환 과정에서 취소 주문을 잘못 포함하면 매출이 틀립니다. 가져온 건수, 제외한 건수와 이유, 저장한 건수를 남기면 어느 단계에서 결과가 달라졌는지 찾기 쉽습니다. 최종 숫자만 확인하지 말고 그 숫자가 만들어진 과정도 확인합니다.

가상 업무 예시

본사 집계에서 신규 매장의 매출이 0원으로 나왔습니다. 담당자가 원본 100건, 변환 통과 80건, 저장 80건을 대조하니 새 지점 코드의 20건이 변환 단계에서 제외돼 있었습니다. 지점 코드 변환표를 고친 뒤 해당 거래만 다시 반영합니다. 원본을 가져오는 일과 변환하는 일, 저장하는 일을 나눠 기록했기에 실제 매출 부진으로 오해하지 않았습니다.

생각해 볼 질문
보고서의 숫자가 어떤 원본 자료에서 왔나요? 제외 조건·환산·집계 과정을 거슬러 확인할 수 있나요?

8. 서술·예측 분석 — 패턴과 원인을 구분한다

서술적 분석은 자료에서 현재와 과거의 특징을 찾는 것이고, 예측적 분석은 자료를 바탕으로 앞으로의 결과를 추정하는 것입니다. ‘지난달 주말 판매량이 높았다’는 관찰과 ‘다음 주말에도 많이 팔릴 것이다’라는 예상은 구분해야 합니다.

할인 쿠폰을 보낸 뒤 매출이 늘었어도 쿠폰 때문이라고 바로 결론 낼 수는 없습니다. 같은 기간의 연휴나 광고도 영향을 줬을 수 있습니다. 이처럼 원인을 따질 때 다른 영향을 살피는 것은 분석 결과를 업무에 적용할 때 필요한 추가 판단입니다.

가상 업무 예시

마트 분석가는 ‘지난 네 번의 주말에 우유가 평일보다 많이 팔렸다’는 관찰로 다음 주말 발주량을 늘리자고 제안합니다. 하지만 지난 주말에는 할인 행사도 있었고 다음 주에는 끝납니다. 점장은 판매 기록과 예측을 구분하고 행사 여부를 반영해 발주량을 정합니다. 반복된 패턴이 다음 주 수요를 보장하지는 않습니다.

생각해 볼 질문
매출 증가에 쿠폰 외의 요인도 영향을 줬을 수 있나요? 관찰한 증가와 원인에 대한 추측을 구분해 설명했나요?

9. 접근과 보관 — 필요한 데이터만 필요한 사람에게 준다

개인정보를 사용할 때는 먼저 어떤 목적에 필요한지와 누가 볼 수 있어야 하는지를 정합니다. 목적에 필요하지 않은 정보를 함께 모으면 관리할 자료와 유출 시 피해가 커질 수 있습니다.

지점별 판매량을 비교하는 보고서에는 고객의 이름과 집 주소가 필요하지 않을 수 있습니다. 분석에 필요한 항목만 제공하고 열람 권한과 보관 기준을 정합니다. 실제 수집·이용·삭제 조건은 적용되는 규정과 계약을 확인해서 결정해야 합니다.

가상 업무 예시

지점별 판매 분석에 고객 이름과 상세 주소가 필요하지 않다면 분석 자료에서 제외합니다. 원본에 접근할 수 있는 사람과 집계 결과를 보는 사람도 구분합니다.

생각해 볼 질문
분석에 고객 이름과 상세 주소가 꼭 필요한가요? 필요한 항목의 보관 기간과 접근할 담당자를 정했나요?

10. 운영 책임 — 데이터 갱신과 오류 수정 담당자를 정한다

데이터를 운영한다는 것은 저장한 자료가 계속 믿을 만한 상태로 쓰이도록 관리하는 것입니다. 갱신이 멈추거나 잘못된 값이 들어왔을 때 확인하고 고칠 담당자도 필요합니다.

매일 아침 갱신하던 재고표가 사흘 전 자료를 보여 주면 점장은 없는 상품을 판매할 수 있습니다. 화면에 마지막 갱신 시간을 표시하고 갱신 실패를 담당자에게 알리면 오래된 자료를 최신 자료로 오해하는 일을 줄일 수 있습니다.

가상 업무 예시

매일 아침 발주에 쓰는 화면이라면 밤사이 수집 실패를 알려야 합니다. 마지막 갱신 시각을 표시하고, 최신 자료가 없을 때 전날 수치를 새 자료처럼 보여 주지 않도록 합니다.

생각해 볼 질문
갱신이 실패하면 누가 언제 알게 되고, 사용자에게 어떤 상태를 보여 줍니까?

11. 기준정보 — 여러 업무가 같은 대상을 가리키게 한다

기준정보는 상품·고객·지점처럼 여러 업무에서 공통으로 사용하는 대상을 구별하고 설명하는 자료입니다. 같은 대상을 시스템마다 다르게 적으면 합계가 나뉘거나 중복될 수 있습니다.

‘강남점’과 ‘강남 1호점’이 같은 매장이라면 공통 지점 번호로 연결해야 합니다. 이름이 바뀌어도 같은 매장임을 알 수 있도록 번호와 변경 이력을 관리합니다. 번호를 정하는 데서 끝내지 말고 새 지점을 등록하고 오류를 고칠 담당자도 정합니다.

가상 업무 예시

같은 지점을 판매 시스템은 강남점, 물류 시스템은 강남1로 부르면 자료 결합이 누락될 수 있습니다. 안정된 지점 코드로 연결하고 명칭은 별도로 관리합니다.

생각해 볼 질문
지점 이름이 바뀌거나 겹쳐도 같은 지점인지 구별할 수 있나요? 판매·물류 시스템이 같은 지점 코드를 사용하나요?

12. 시간 기준 — 언제의 데이터인지 함께 저장한다

자료의 시간에는 일이 실제로 일어난 시간과 시스템에 수집된 시간이 있습니다. 두 시간을 혼동하면 같은 거래가 보고서에서 다른 날의 실적으로 잡힐 수 있습니다.

밤 11시 59분에 결제한 주문을 다음 날 0시 5분에 모았다고 해서 다음 날 매출로 계산할지는 업무 기준에 따라 정해야 합니다. 날짜별 매출을 만들 때 사용할 시간과 시간대를 정하고, 늦게 도착한 자료를 반영하는 방법도 마련합니다.

가상 업무 예시

9월 30일 23시 59분 결제가 통신 지연으로 10월 1일 0시 5분에 수집됐습니다. 수집일로 월 매출을 계산하면 9월 거래가 10월로 넘어갑니다. 담당자는 결제 시각과 수집 시각을 따로 저장하고, 결제월 보고서에는 정한 시간대의 결제 시각을 사용합니다. 이미 만든 9월 보고서에는 늦게 도착한 거래를 반영해 수정 표시를 남깁니다.

생각해 볼 질문
발생 시간과 수집 시간을 혼동하지 않으며 시간대가 명확합니까?

13. 재처리와 중복 — 다시 실행해도 거래가 중복되지 않게 한다

멱등성은 같은 요청을 여러 번 처리해도 한 번 처리한 것과 같은 결과가 되도록 하는 성질입니다. 통신이 끊겨 작업을 다시 시도할 때 특히 필요합니다.

주문 100건을 저장하다가 70건에서 멈췄다면 전체를 다시 실행할 수 있습니다. 각 주문을 구분할 번호와 처리 기록을 확인해 이미 저장된 주문을 다시 만들지 않아야 합니다. 번호가 있다는 것만으로 충분하지는 않고 중복 요청을 어떻게 처리할지까지 구현해야 합니다.

가상 업무 예시

매출 수집이 중간에 끊겨 하루치를 다시 실행하면 일부 주문이 두 번 들어갈 수 있습니다. 원본 주문 ID를 기준으로 중복을 막고 누락 여부를 대조합니다.

생각해 볼 질문
중단된 매출 수집을 다시 실행해도 같은 주문이 두 번 집계되지 않나요? 누락된 주문도 찾을 수 있나요?

14. 스키마 변경 — 자료 형식의 변화를 관리한다

스키마는 데이터가 어떤 항목과 자료형으로 구성되는지 정한 구조입니다. 자료를 주고받는 시스템은 이 구조뿐 아니라 값의 의미와 단위도 같게 이해해야 합니다.

배송 시스템이 무게를 그램으로 읽는데 보내는 쪽에서 킬로그램으로 바꾸면, 둘 다 숫자라서 형식 검사는 통과해도 배송비가 틀릴 수 있습니다. 변경 전에 영향을 받는 시스템을 찾고 단위·적용 시점·이전 자료 처리 방법을 함께 전달해야 합니다.

가상 업무 예시

물류 업체가 상품 무게를 2,000그램 대신 2킬로그램으로 보내면서 항목 이름을 그대로 뒀습니다. 받는 프로그램은 숫자 2를 2그램으로 읽어 배송비를 적게 청구했습니다. 양쪽 담당자는 단위를 이름이나 명세에 표시하고, 같은 물건의 구·신 자료로 요금이 같은지 확인한 뒤 전환합니다. 숫자 형식 검사만으로는 잡을 수 없는 오류입니다.

생각해 볼 질문
무게 단위나 필드 형식을 바꾸면 어떤 보고서와 계산이 영향을 받나요? 사용 부서에 전환 날짜를 알렸나요?

15. 무결성 — 값과 업무 규칙을 검사한다

무결성은 데이터가 정해진 규칙을 어기지 않도록 유지하는 것입니다. 예를 들어 주문 번호는 중복되지 않고, 주문에 적힌 고객 번호는 실제 고객 자료에 존재해야 한다는 규칙을 둘 수 있습니다.

배송일이 주문일보다 빠르면 안 된다는 업무 규칙도 검사할 수 있습니다. 화면 입력만 검사하면 파일 가져오기나 다른 프로그램을 통한 입력에서 빠질 수 있으므로 필요한 경로에 규칙을 적용합니다. 규칙을 통과했다고 실제 사실까지 모두 정확하다고 보장되는 것은 아닙니다.

가상 업무 예시

주문 화면에서는 수량 0을 막았지만 거래처가 올린 CSV에는 0개 주문이 들어왔습니다. 출고 목록에 포장할 수 없는 주문이 남았습니다. 팀은 이 업무의 ‘수량은 1 이상’ 규칙을 서버와 저장 단계에도 적용하고, 파일 업로드는 잘못된 행과 이유를 알려 수정하게 합니다. 화면에서 막았다는 사실만으로 모든 데이터의 무결성이 보장되지는 않습니다.

생각해 볼 질문
날짜 역전이나 중복 ID 중 자동으로 찾을 오류는 무엇인가요? 예외가 맞는지 판단하고 수정할 담당자는 누구인가요?

16. 데이터의 유용성 — 수집한 자료가 누구를 포함하는지 확인한다

분석에 쓰는 자료가 판단하려는 사람이나 상황을 제대로 포함하는지 확인해야 합니다. 일부 집단만 모은 자료로 전체의 의견을 설명하면 결론이 치우칠 수 있습니다.

택배 앱 사용자에게만 만족도를 물으면 로그인에 실패해 상담 전화로 돌아간 고객의 불편은 빠집니다. 전체 고객의 이용 경험을 알고 싶다면 조사에 응답할 수 없었던 집단도 확인해야 합니다. 이는 교재의 데이터 품질 개념을 조사와 분석에 적용한 예입니다.

가상 업무 예시

앱 설문만 보면 앱 사용이 어려워 탈락한 고객의 불편은 드러나지 않습니다. 상담과 이탈 과정의 자료도 함께 확인해 조사 대상을 넓힙니다.

생각해 볼 질문
분석 자료에 들어오지 못한 대상은 누구이며 왜 빠졌습니까?

17. 질의 최적화 — 필요한 결과를 적은 비용으로 얻는다

질의 최적화는 같은 조회 결과를 더 적은 비용으로 얻을 실행 방법을 찾는 것입니다. 데이터베이스는 여러 방법의 예상 비용을 비교하고, 인덱스 같은 탐색 수단을 활용합니다.

인덱스는 책의 색인처럼 필요한 자료를 빨리 찾도록 돕는 별도 구조입니다. 고객 번호와 날짜로 주문을 자주 찾는다면 그 조건에 맞는 인덱스가 도움이 될 수 있습니다. 하지만 저장 공간을 쓰고 자료 수정 시 함께 갱신해야 하므로 실제 조회 조건과 실행 결과를 보고 선택합니다.

가상 업무 예시

고객 한 명의 최근 주문을 찾을 때마다 전체 주문을 읽으면 주문이 늘수록 조회가 느려질 수 있습니다. 담당자는 고객 번호와 주문 날짜로 찾는 인덱스를 검토합니다. 적용 전후 조회 시간과 새 주문 저장에 드는 시간을 함께 비교합니다.

생각해 볼 질문
고객 한 명의 최근 주문을 찾기 위해 전체 주문을 읽고 있지는 않나요? 실행 계획에서 읽는 자료의 범위를 확인했나요?

18. 이력과 감사 가능성 — 누가 언제 왜 값을 바꿨는지 남긴다

감사 기록은 누가 언제 어떤 자료를 바꿨는지 나중에 확인할 수 있도록 남기는 기록입니다. 문제가 생겼을 때 원인을 찾고 처리 과정이 적절했는지 살피는 데 사용합니다.

환불받을 계좌가 바뀌어 돈이 잘못 송금됐다면 현재 계좌만 봐서는 변경 과정을 알 수 없습니다. 필요한 범위에서 변경 전후 값, 작업자, 시각과 승인 기록을 연결해야 합니다. 기록 자체도 함부로 바꾸거나 불필요하게 열람하지 못하도록 보호합니다.

가상 업무 예시

거래처 정산 계좌가 바뀌었다면 승인과 변경 이력을 남깁니다. 잘못된 지급이 발견됐을 때 현재 값뿐 아니라 지급 당시 값과 승인 경로를 확인합니다.

생각해 볼 질문
과거 지급 당시의 계좌와 승인자를 확인할 수 있나요? 이후 누가 왜 계좌를 바꿨는지도 기록돼 있나요?

19. 데이터 서비스 수준 — 제공 조건을 합의한다

SLA는 서비스를 제공하는 쪽과 이용하는 쪽이 품질 기준을 합의한 약속입니다. 데이터를 제공하는 서비스라면 갱신 시각, 허용 지연, 문제가 생겼을 때의 연락과 복구 기준을 정할 수 있습니다.

판매팀은 매시간 갱신된다고 생각하지만 담당자는 하루 한 번 갱신하면 된다고 생각할 수 있습니다. 이 차이를 줄이려면 ‘오전 9시까지 전날 확정 거래를 반영한다’처럼 확인 가능한 기준을 합의하고 실제로 지켰는지 살펴야 합니다.

가상 업무 예시

마케팅팀은 어제 구매한 고객을 제외하고 쿠폰을 보내려는데, 고객 집계는 일주일 전 자료였습니다. 구매자에게도 쿠폰이 발송될 수 있습니다. 두 팀은 ‘매일 오전 9시까지 전날 24시까지의 구매 반영’과 실패 시 알림·발송 보류를 합의합니다. ‘매일 갱신’보다 기준 시각과 실패 때의 행동까지 정해야 같은 기대를 가집니다.

생각해 볼 질문
자료를 받는 팀이 갱신 주기와 지연 시 대응 방법을 알고 있나요? 제공 조건이 바뀌면 누가 알려 주나요?

20. AB 테스팅 — 비교 전에 성공 기준을 정한다

A/B 테스트는 두 가지 안을 서로 다른 집단에 적용하고 결과를 비교하는 방법입니다. 어떤 안이 목표 달성에 도움이 되는지 살펴보려면 비교 기준과 측정 방법을 먼저 정해야 합니다.

주문 버튼의 문구를 바꾼 뒤 클릭이 늘어도 완료 주문이 늘지 않았다면 판매 개선이라고 단정하기 어렵습니다. 비교 집단의 조건을 맞추고 주문 완료율과 취소 같은 부작용을 함께 살핍니다. 결과를 본 뒤 유리한 지표만 고르면 판단이 왜곡될 수 있습니다.

가상 업무 예시

쇼핑몰이 추천 화면 A와 B에 고객을 무작위로 나눠 배정합니다. 시작 전에 완료 주문 비율을 주지표로, 취소 비율을 함께 볼 지표로 정합니다. B의 클릭은 늘었지만 완료 주문은 비슷하고 취소는 늘었다면 클릭만으로 B를 채택하지 않습니다. 관찰 기간과 두 집단의 조건도 확인한 뒤 판단합니다.

생각해 볼 질문
비교를 시작하기 전에 성공 기준과 기간을 정했나요? 클릭 증가뿐 아니라 주문 취소 같은 불리한 결과도 함께 확인했나요?

교재에서 함께 확인할 내용

위 20개 노트는 교재 개념을 업무에 적용하는 길잡이입니다. 다음 이론과 기법은 별도로 읽고 직접 설명하거나 계산해 보세요. 이 목록도 교재 전체를 대신하지는 않습니다.

1. 함수 종속과 정규화

함수 종속은 어떤 값을 알면 다른 값이 하나로 정해지는 관계입니다. 상품 번호를 알면 상품명이 정해지는 경우가 예입니다. 정규화는 이런 관계를 바탕으로 표를 나눠 중복 때문에 생기는 수정 오류를 줄이는 과정입니다. 주문 번호와 상품 번호를 합친 키에서 상품명은 상품 번호만으로 정해집니다. 이런 부분 종속을 없애는 것이 제2정규형의 조건이고, 제3정규형은 다른 일반 속성을 거쳐 값이 정해지는 이행 종속도 없앱니다.

확인해 보기: 주문번호와 상품번호가 복합키일 때 상품명은 키 전체에 종속하나요, 일부에 종속하나요?

데이터 이해와 활용 · 72쪽 →

2. SQL의 조회 조건과 그룹 조건

SELECT는 보여 줄 열을, WHERE는 계산에 사용할 행을 고릅니다. GROUP BY는 고객별·날짜별처럼 행을 묶고, HAVING은 묶어서 계산한 결과에 조건을 적용합니다. 예를 들어 1만 원 이상 주문만 남기는 조건은 WHERE에, 고객별 합계가 10만 원 이상인 조건은 HAVING에 둡니다.

확인해 보기: 개별 주문 금액이 1만 원 이상인 행을 고르는 조건과 고객별 주문 합계가 10만 원 이상인 그룹을 고르는 조건은 어디에 둘까요?

데이터 이해와 활용 · 107쪽 →

3. 동시성 제어와 직렬 가능성

동시성 제어는 여러 거래가 같은 자료를 읽고 바꿀 때 서로의 작업을 망가뜨리지 않도록 조절하는 것입니다. 잔액 100을 읽은 두 거래가 각각 10과 20을 더한 뒤 110과 120을 따로 저장하면 한쪽 증가가 사라질 수 있습니다. 직렬 가능성은 함께 실행하더라도 하나씩 순서대로 실행한 어떤 결과와 같도록 하는 성질입니다.

확인해 보기: 두 거래가 같은 잔액을 읽고 각각 덮어쓸 때 어떤 갱신이 사라질 수 있나요?

데이터 이해와 활용 · 122쪽 →

4. ETL과 OLAP

ETL은 자료를 가져오고, 형식과 의미를 맞추고, 분석 저장소에 넣는 과정입니다. OLAP은 그 자료를 여러 기준과 상세 수준으로 살펴보는 분석 방식입니다. 전국 월매출에서 지역별 월매출로 나누거나 일별 기록으로 내려가 보는 것이 예입니다. 요약에서 더 자세한 내용으로 내려가는 기능을 드릴다운이라고 합니다.

확인해 보기: 월별 매출을 일별로 나누어 보면 집계의 상세 수준은 어떻게 달라지나요? 이렇게 더 자세히 내려가 보는 OLAP 기능은 무엇인가요?

데이터 이해와 활용 · 138쪽 →

5. 지도·비지도·강화 학습

지도 학습은 사진에 불량·정상이라는 정답을 붙여 학습시키는 것처럼 입력과 정답을 함께 사용합니다. 비지도 학습은 정답 없이 비슷한 구매 패턴끼리 고객을 묶는 것처럼 자료의 구조를 찾습니다. 강화 학습은 행동 뒤 얻는 보상을 바탕으로 어떤 상황에서 어떤 행동을 할지 배우는 방식입니다.

확인해 보기: 정답이 있는 불량품 분류와 구매 패턴에 따른 고객 군집화는 각각 어떤 학습에 해당하나요?

데이터 이해와 활용 · 153쪽 →