데이터 검증 경험, 결과값이 달랐던 3가지 이유

안녕하세요!  2년차 데이터사이언티스트 먼지입니다.

 

올해 3월, 새로운 회사에 입사하였습니다.

작은 회사임에도 대기업들 상대로 컨설팅 업무라 정말 타이트하게 일이 진행되더라고요. 바쁘고 성장할 수 있는 회사를 원했는데 이 정도로 바쁠줄은 몰랐습니다.. 3개월 동안 7시 전 퇴근 한적이 10번이 안되는 것 같네요.

 

바쁜 이유는 매주 결과물을 내야하기 때문입니다.

매주 팀내에서 목표를 정하고, 결과를 대표님께 컨펌받고, 대표님이 고객사에게 전달하는 방식으로 진행되기 때문에 프로젝트 기간엔 바쁠 수 밖에 없는 것 같습니다.

 

그래서 왜 뜬금없이 바쁜 걸 이야기하지..? 라고 생각하실 것 같은데요. 프로젝트 마지막 주, 시간에 쫓기느라 데이터 검증을 제대로 하지 못했었습니다. 3시간이면 해결할 문제를 시간에 쫓기고, 당황해 6시간이 넘게 걸렸죠. 

 

지금 생각하면 왜 그랬지 싶지만, 너무 바쁜 상황에 데이터도 많고 로직도 워낙 복잡하다 보니 머릿속이 하얘졌던 것 같습니다. 다음부턴 이런 실수를 방지하고자 데이터 검증 경험을 남겨보려 합니다.

 

1. 어떤 프로젝트 였나요?

제가 참여한 프로젝트는 리포트 자동화에 관련된 업무였습니다.

고객사의 엑셀 데이터(raw data)를 넣었을때 쿼리를 통해 자동적으로 리포트가 산출될 수 있도록 하는 프로젝트입니다.

 

그전까진 완벽한 리포트가 계산되는 것에 집중했습니다. 잘 마무리가 되었고, 대표님께서 프로젝트 기간 1주를 남기고 고객사 앞에서 직접 리포트가 산출되는 것을 보여주자고 하셨습니다.

   

그래서 마지막 1주일, 인풋데이터 자동화 작업에 착수했습니다. 

이전까지는 현업 엑셀파일에서 시트마다 CSV를 손수 뽑아 DB에 직접 넣어주었었다면, 이제는 엑셀파일을 넣어주기만 하면 필요한 모든 데이터가 추출되고, DB에 자동으로 업로드까지 되는 작업을 진행해야 했죠.

 

2. 왜 결과값이 다르지?

이미 리포트 산출 로직은 동일하게 구현되어 있고, 파이썬으로 데이터 수집 작업도 완료되었으니 다 끝났다고 생각했지만.. 전혀 아니었습니다. 분명 같은 엑셀 파일의 데이터를 사용했는데, 산출된 리포트 값이 다른 겁니다.

 

리포트의 경우, 고객사 임원진분들께서 의사결정을 하시는데 사용하시는 리포트라 팀에서 숫자 10 단위까지 관리하는데, 한개도 아닌 여러 항목이 달라지니 당황스러웠습니다.

 

리포트 항목은 수많은 input 데이터들이 합쳐져서 나온 결과 값이기 때문에 '어느 부분에서 잘못되었다'를 바로 판단하기 어려웠고, 다른 팀원이 작성한 2천줄의 쿼리를 파악해야 했습니다.

 

한때 정말 패닉이 오기도 했지만 시간을 가지고 천천히 해결해 나갔습니다. 프로젝트를 잘 마무리 지을 수 있었고 그 동안 어떤 문제점, 어떤 해결방안이 있었는지 적어보려 합니다.

3. 결과값이 달랐던 이유 3가지

산출물의 결과값이 달랐기에 여러방면으로 이유를 찾으려 했고, 다음 3가지에서 문제가 생겼었습니다.

(1) DB 업로드 시 중복(데이터 소수점 차이)

매달 DB에 새로운 데이터를 업데이트를 해줘야 하는 작업이었기 때문에, 기존데이터와 같은 데이터가 DB에 업로드 되지 않도록 하는 작업이 중요했습니다. 그래서 primary key 설정을 해주었고 코드 파일을 돌렸을 때, 중복데이터가 걸러지고 새로운 데이터만 업로드 되는 걸 확인했습니다. 

 

문제는 자동화 테스트를 할때 생겼습니다. 자동화 테스트 단계는 아래와 같습니다. 

 

(1) 자동화 전 사용하던 DB에서 전월까지의 데이터 미리 업로드.(전월 데이터는 채워져 있다고 가정)

(2) 자동화 코드를 통해 자동화DB에 새로운 월 데이터를 잘 넣어주는지 확인하기

 

단계별 생성되는 테이블 데이터를 확인하던 중, 560개의 데이터가 들어가야 하는데 570개의 데이터가 들어가고 있는 상황을 발견하였습니다. 단 10개의 데이터가, 데이터 소수점 자리 값이 달라 다른 데이터로 인식되어 DB에 업로드가 되고 있었습니다.

 

새로 수집하는 데이터의 형식을 정수형으로 바꿔 중복되는 문제를 해결하였습니다.

 

경우에 따라 3000이란 숫자가 2999.9999로 업로드 될때가 있었습니다. (이해를 위해 만든 예시 데이터입니다.)

 

(2) Join 시 중복

조인에서 문제가 생겼을 거라는 건 당연히 예상했었습니다.

다만, 문제는 제가 작성하지 않은 몇천줄 짜리 쿼리에서 문제가 생겼다는 점이었죠.

 

쿼리는 너무 길고, 해당 내용은 모르고, 팀원은 다른 일 하느라 바쁘고, 시간은 촉박하고...

 

해결한 방법은 한가지였습니다. 마음을 다 잡고 CTE 하나 하나 count(*)로 데이터 개수를 다 확인해봤습니다.

쿼리가 cte 방식으로 관리되고 있었기에 생각보다 수월하게 확인할 수 있었고 직접 찍어보니, 어떤 곳에서 데이터가 늘어났는지 확인할 수 있었습니다. 

 

모르는 쿼리에서 어떻게 찾아내지..? 라고 생각하고 당황했었는데 막상 해보니 해볼만 했습니다. 두려움이 사라지는 계기가 되었던 것 같습니다. 

하나 하나 데이터 개수를 찍어봤습니다.(이해를 위해 만든 쿼리 예시입니다)

(3) Input data 문제(다른데이터&중복)

(1) 원천데이터의 문제

기존 리포트를 산출했을 때, 고객사에서 잘못된 데이터를 전달해줬었고, 팀원분께서 새롭게 데이터를 받았었는데 이 부분이 저에게 공유가 안되었습니다. 

 

엑셀에 기존 데이터와 새롭게 수집된 데이터를 하나하나 비교하다보니 데이터의 차이점을 발견하게 되어 해결할 수 있었습니다. 

데이터를 일일이 비교하는 작업은 꼭 필요하단 생각이 들어, 나중에 한번 정리해서 포스팅해보겠습니다 :) 

 

 

(2) 데이터 중복 업로드

 급하게 여러 테스트를 진행하다보니, 넣으면 안되는 스키마에 데이터를 넣어버렸던 걸 확인했습니다.

같은 데이터가 2번씩 들어가 숫자가 2배가 되어있던 것이죠.

 

동시다발적으로 문제가 생기니 기초적인 문제에 신경쓰지 못했고 애초에 DB 테이블 생성시 primary key를 설정해 놓지 않은 부분이 컸던 것 같습니다.

 

중복되었던 input 데이터

 

4. 결론 및 느낀점

이번 프로젝트를 통해 데이터 검증은 모든 단계마다 숫자로 이야기하고 판단해야 된다는 것을 깨닫게 되었습니다. 

 

* input 데이터 개수엔 차이가 없는지

* join을 하고 난 뒤 데이터 개수 차이가 없는지

* 업로드 되야 하는 데이터 개수와 실제 업로드 되는 데이터 수가 같은지 등등 

 

차분하게 꼼꼼히 확인하는 것이 가장 빠른 길이었고, '이 정도면 괜찮겠지', '빨리 끝내야지'라는 생각이 더 어렵고 복잡하게 만들었던 것 같습니다. (+ 추가로 테이블 생성시 DB primary key 설정은 꼭 해야겠습니다..)

 

이번 촉박한 타임라인에서의 작업이 당시엔 큰 스트레스였지만, 데이터과학자로 성장하는 계기가 되었던 것 같습니다. 비슷한 일이 생긴다면, 이젠 당황하지 않을 것 같네요.

 

다음 포스팅엔 데이터 개수가 같고 데이터 자체의 문제가 있는 경우, 데이터를 하나하나 직접 비교하는 방법들에 대해 알아보도록 하겠습니다.

 

읽어주셔서 감사합니다 :)