우리가 가장 많이 하는 실수는 사내 시스템이던 사외 시스템이던 Database는 맞다고 가정하는 것이다.
당연히 맞아야 하는 것이지만, 또 당연하지도 않다.
- 데이터에 오류가 발생하는 경우는 아래와 같다.
- 시스템에 누군가가 숫자를 잘못 입력하거나 (담당자가 실수)
- 시스템과 시스템 사이의 데이터 인터페이스 중에 문제가 생기거나 (여기서 데이터 누락이 발생)
- 마스터 매핑이 잘못되는 일이 생기거나 (마스터를 사람이 수작업으로 관리한다면)
- 타이밍상 오류 (실물과 전산이 다르게 움직인다던지 등)
보고를 다 마치고 왔는데, 알고 보니 원본 데이터가 잘못되었고, 이로 인해 엉뚱한 분석 결과가 보고된 것이라면 정말 난처한 일이다.
오랜 경험이 있거나, 매의 눈을 가진 사람이라면 그나마 문제가 되는 숫자를 쉽게 찾아낼 수 있겠지만, 그렇지 않다면 엑셀이 아무리 좋아도, 결국 엉뚱한 보고와 그에 따른 경영 의사결정의 오류, 회사의 손실로 이어지게 될 수도 있다.
그래서 엑셀의 달인이 되려면, 먼저 가장 근본적인 Database의 검증 작업부터 명확한 기준을 세팅해서 Data의 Quality를 확보해야 한다.
위의 Case 들을 기반으로 몇 가지 적용할 수 있는 포인트를 정리해 보면 이렇다.
1. 담당자를 명확히 해둔다. (특히 사외 시스템과 연계된다면 이슈 발생 시 해결할 수 있는 사람이 누구인지 담당자를 파악해야 한다.)
아무리 잘 세팅해도 시스템은 언제든지 바뀐다. 특히 보안 취약점 개선 등 다양한 사유로 시스템은 항상 업그레이드될 수 있다는 점을 잊지 말아야 한다. 이슈가 발생하지 않으면 다행이지만, 시스템 변경 사항에 대한 사전 공유, UAT, 이슈 발생 시 즉시 해결할 수 있는 시나리오별 대응 방법 및 책임자를 알아야 문제를 해결할 수 있다.
2. 마스터의 오류는 상시 점검하여 Zero화 한다.
마스터 오류가 발생하는 이유는 대부분 일부 프로세스를 사람이 담당하기 때문이다. 정기적으로 마스터와 매핑 등을 점검할 수 있도록 해두어야 누락 등 큰 사고를 피할 수 있다.
3. 숫자가 튀는 현상을 기준에 의해 자동으로 센싱하고 Risk를 자동 메일링으로 전달하도록 하고, 데이터 오류시 1번의 담당자와 즉시 확인 및 조치토록 세팅한다.
숫자가 튄다는 건 뭔가 이슈가 있다는 말이다. 이를 체크하는 기준 로직을 반영해서 데이터의 Outlier를 파악하고 조치하도록 한다. 특히 Fraud (고의로 데이터를 조작하는 행위) Case에 대한 체크 로직을 반영해줘야 한다.
4. 숫자의 감각을 익혀라.
아무런 문제가 없어 보여도, 숫자의 감각이 있는 사람은 금세 이슈를 발견할 수 있다. 특히 해당 분야의 숫자를 오랜 시간 바라본 경영진들은 동물적인 감각으로 숫자의 오류를 바로 알아차리기도 한다. 정상 범위가 머릿속에 있어야 Outlier 기준을 세팅할 수 있다. 이를 눈으로 보면서 감각을 키우는 것을 추천한다. 혹시 누가 알까? 나중에 본인이 경영진이 될 수 있을지...
처음부터 완벽을 기할 수는 없겠지만, 이 노하우가 쌓이면 점점 완벽한 Database 가 될 것이다.
Data Quality에 집착하는 것이 가장 기본이다. Data가 틀리면 결과는 무조건 틀리다. 꼭 이 부분을 고려해서 시간이 걸리고 돈이 든다고 해도 충분히 투자할 가치가 있음을 기억해 주길 바란다.