서론
데이터분석을 시작하면 코딩을 하면서 짜라란 결과물을 내는 과정보다, 데이터를 뜯어보면서 전처리 및 정합성을 훑어보는 시간이 훨씬 길어서 ‘이게 맞나?’란 생각이 들 때가 있다. 같은 데이터 화면이 변화 없이 30분 지속되면 ‘쟤는 대체 뭘할까라고 생각하겠지?’라는 생각이 들 때도 있다.
데이터의 정확도에는 변수가 너무 많았다고 느껴서, 2023년 하반기 동안 마주했던 정확도를 방해하는 예시들을 정리해보았다. 크게 ‘회사의 환경적 이유’, ‘데이터가 입력될 때’, ‘보고자료를 준비하는 사람의 관점이 데이터에 반영될 때’로 나눠보았다.
*모든 사례는 각색 되었습니다.
정확도에 영향을 미쳤던 경우 1. 회사의 환경적 이유
환경적 요인으로 회사의 분석 기준이 정확하게 수립되어 있지 않은 경우가 많다. 그렇다면, 분석가가 기준을 협업 부서들과 토의해나가며 잡아야 하는 경우도 있을 텐데, 고민이 된다.
- 회사의 조직도를 기준으로 분류를 했는데, 조직도가 한 달 만에 바뀐 경우
생산부서 별 생산량을 보고 싶다는 요청이 들어왔다. 그렇다면 조직도를 기준으로 생산부서를 분류해야겠다고 생각을 했다. 그렇게 보고를 마무리 했는데, 한 달 뒤 다시 정기보고를 하게 되었을 때 보니 조직도가 바뀌었다.
⇒ 그렇다면, 이전 조직도 기준으로 계속 가야할까? 바뀐 조직도를 적용해야 할까? - 구매 기준 정보가 명확히 수립되어 있지 않은 경우
부서마다 보고 기준이 다르고, 100%의 구매 품목을 알 수 없다. 매입부서에서는 주요 원재료를 5개로, 지원부서에서는 15개 세분화로, 제조사에서는 7개로 보고한다고 한다. 지원부서의 15개 세분화도 전체 기준을 포함하는 세분화는 아니라고 한다.
⇒ 그렇다면, 구매 기준 정보부터 만들어나가야 하는걸까? - 전산의 A화면과 B화면에 같은 값이 다르게 출력이 되고 있다.
2개가 세트인 상품이, A화면에서는 1개로, B화면에서는 2개로 출력이 된다.
⇒ 빠르게 로직 수정이 안된다면, 매번 전처리를 해줘야 하는걸까? - 전산의 한 카테고리에 묶인 값들이, 하나는 ‘재료’이고, 하나는 ‘제품’ 단위 기준
비슷한 예로, A와 B라는 큰 카테고리의 제품을 판매하는데 c라는 반제품이 전산 상 같은 버튼에 묶여 있다.
⇒ 실무자들은 이에 대해 어떻게 생각할까? 분류된 이유가 있을까?
정확도에 영향을 미쳤던 경우 2. 데이터가 입력될 때
수기로 입력되는 데이터가 있을 때, 모든 사람이 같은 기준을 보고도 같은 값을 입력하기란 쉽지 않았다.
- 동일한 제품에 코드는 두 개
A는 0000코드로, 담당자가 바뀌며 B는 0001코드로 입력하였다.
⇒ 이 경우, 코드로 불러오게 되면 둘 중 하나는 누락되었고, 제품명으로 데이터값들을 불러와야 전체 데이터가 불러와야 했다. - 10월에 잘못 등록한 금액, 11월에 차액만큼만 수정해서 반영
등록자가 9월 매출 발생건 1개 금액을 ERP에 잘못 등록하였다. 9월 발생건을 고치기 보다, 그 차액만큼 10월에 수정 등록하였다.
⇒ 이 경우, 히스토리를 모르거나, 원본 OEM 데이터가 없는 사람의 경우, 9월과 10월의 정확한 매출 수치를 모른 채 ERP에 등록되어 있는 값이 해당 월의 매출이라고 이해하게 된다. - 엑셀 파일을 만들면서, 복사붙여넣기 실수 발생
10월보다 11월의 데이터 건수가 작다. 10월 형식에 11월 데이터를 붙여넣기 후, 남은 10월 데이터행은 지웠어야 했는데, 그 부분을 놓쳐서 11월 데이터와 10월 데이터가 섞였다!
⇒ 더블체크가 되지 않는 경우, 정확하지 않은 수치가 보고될 수 있다. - 하나의 회사, 명칭은 여러 개
(주)분석회사라는 하나의 회사를 사람에 따라 (주)분석회사, (주)분석, 분석회사, 분석 등으로 다양하게 입력하는 경우
⇒ 발견해서 전처리를 하게 되면 다행이다. 전처리 방식도 고민을 하게 되는데, 파이썬이 나을까, 원본 엑셀을 수정할까 고민하지만 실무에서는 원본 엑셀 수정 비율이 높다고 느껴진다.
⇒ 발견하지 못하면 1개의 회사건이 아니라 4개의 회사건으로 분류된 채로 놓쳐지는 데이터가 된다.
정확도에 영향을 미쳤던 경우 3. 보고자료를 준비하는 사람의 관점이 데이터에 반영될 때
- 똑같은 매출건이 중복 책정 보고
매출 중 전산에 등록 안되던 OO 케이스가 있다. 전산에 OO 케이스가 등록되기 시작했지만, 원본 엑셀 계약 데이터의 값과 전산의 값이 일치하지 않아 보고담당자는 동일하지 않은 별개의 OO 케이스 건으로 간주하였다. 담당자는 전산의 OO 케이스 값과 엑셀 계약 데이터의 값을 더하여 보고하였다.
⇒ 이런 경우는 ‘전산 개선 + 보고 수치를 뽑는 룰 확정 + 정확한 값이 전산에 등록되도록 등록자 교육’이 모두 이뤄질 수 있을까 - 100%가 아닌 데이터들
변수1의 4번 사례처럼 재료 기준, 제품 기준이 섞여 있을 때, 엑셀에 제품 기준만 수작업으로 수식을 걸어서 ‘제품 기준’ 매출을 추출해 보고를 한다. 그런데, 10월에서는 발생하지 않았던 제품이 있어 11월에 추가 수식을 걸어줬다. 그렇다면, 10월 이전에 보고되었던 ‘제품’ 기준도 11월에 수식이 추가된 버전으로 돌린다면 값이 변경이 될 가능성이 존재한다.
⇒ 누락 또는 온전히 분류가 되지 않더라도 비중이 크지 않다면 괜찮은걸까 - 기타 또는 삭제 되는 데이터들
‘매출에 XX 항목은 뭐야? 비중이 크지 않으니 빼고 보자’라는 요청이 들어온다. 그렇게 빼거나 기타로 뭉쳐지는 값들이 기록이 되지 않기 때문에, 그 데이터를 다루던 사람이 변경되면 ‘기타’에 해당되는 항목은 무엇이었는지 찾는데만 며칠이 소모된다.
⇒ 그런 요청이 있다면 주석으로 변경 내역을 기록으로 남기도록 권고하고 있다. - 등록이 누락된 건
10월에 전산에 등록이 누락된 데이터 값이 있다. 등록자가 아차!싶어서 11월에 넣었다고 연락이 왔다. 이걸 계산서 기준으로 10월값으로 봐야할 지, 전산에 등록된 기준으로 11월에 넣어야 할 지에도 판단이 들어간다.
⇒ 이런 경우에도 어떻게 구분했는지 기록으로 남기도록 권고하고 있다. - 제각각의 보고 기준
똑같은 매출 보고를 해도, A부서와 B부서의 매출 기준이 다르니 값도 다르다. C레벨은 이 보고를 받고, 같은 매출인데 왜 값이 다르냐고 의심을 한다.- A부서
매출 = (a1+a2+a3 , A) + (b1+b2 , B) - B부서
매출 = (a1+a2+a3+a4+a5, A) + (b1+b2+b3+b4+b5, B) + (c1+c2, C)
⇒ ‘PM을 위한 데이터 리터러시(프로덕트 데이터 분석)’이란 강의를 듣고 있는데, MECE(Mutually Exclusive Coleectively Exhaustive : 중복과 누락이 없고 각 요소를 모두 합하면 전체가 되는 것)라는 문제정의 방법을 들었다. 매출 기준을 수립할 부서에서 MECE하게 분류를 각자 해보고, 의사소통을 하며 모두가 납득할 만한 기준을 찾아나가보는 것은 어떨까 생각을 했다.
- A부서
마치며
수많은 전처리 경우가 존재한다거나, 데이터를 다루는 사람의 판단이 들어가는 일은 늘 발생한다고 생각한다. 유관 부서들과 합의를 해서 기준을 세운다거나, 판단이 들어가는 경우는 세밀하게 기록을 남기는 등으로 차근차근 잡아나가고 싶다. 이렇게 해서 개선한 사례가 존재하게 된다면 공유할 수 있게 되는 그날까지 또 데이터를 하염없이 바라보게 될 것 같다.
댓글