자동 수집 시스템을 납품할 때 가장 무거운 질문은 "이 숫자, 믿어도 되나요"입니다. 코드가 돌아간다는 것과 숫자가 맞는다는 것은 다른 문제입니다. 파싱이 엉뚱한 열을 읽어도, 동명이인의 기록을 가져와도 시스템은 멀쩡히 돌아갑니다. 야구 데이터 수집기를 만들며 우리는 이 질문에 절차로 답했습니다. 리포트에 표시되는 수치를 원본과 전수 대조하는 검증입니다. 그 방법과 배운 것을 정리합니다.
수집 데이터의 오류는 세 층에서 온다
검증을 설계하려면 무엇이 틀릴 수 있는지부터 나눠야 합니다.
| 오류 층 | 예 | 특징 |
|---|---|---|
| 수집 실패 | 페이지 로드 실패, 셀렉터 어긋남 | 시끄럽게 드러남(빈 값·에러) |
| 대상 오인 | 동명이인, 엉뚱한 행·열 파싱 | 그럴듯한 숫자라 조용함 |
| 전달 왜곡 | 단위 혼동, 매핑 뒤바뀜, 반올림 | 리포트 단계에서 발생 |
위험한 것은 두 번째와 세 번째입니다. 수집 실패는 로그로 잡히지만 대상 오인과 전달 왜곡은 "정확하게 틀린" 숫자를 만듭니다. 이 유형은 코드 리뷰나 단위 테스트만으로는 부족하고 최종 산출물과 원본의 대조로만 확실히 잡힙니다.
방법: 표시 수치 전수 대조
우리가 실행한 검증은 단순하고 무식하고 확실합니다. 표본 경기를 골라 완성된 리포트에 표시되는 모든 수치에 번호를 붙이고 각 수치를 원본 사이트 화면에서 직접 찾아 대조하는 것입니다.
실제로 두 경기 표본에서 각각 이백여 개씩, 도합 사백 개가 넘는 표시 수치를 대조해 불일치 없음을 확인했습니다. 핵심은 "전수"입니다. 눈에 띄는 몇 개만 확인하는 표본 검증은 특정 지표 전체가 밀려 있는 계통 오류를 놓칠 수 있습니다. 리포트 한 장 분량이라면 전수 대조는 하루가 안 걸리는 투자이고 그 대가로 "모든 표시 수치가 원본과 일치함을 확인했다"는 문장을 얻습니다.
전수 대조가 잡아 주는 대표 사례가 대상 오인입니다. 동명이인 선수의 기록을 가져오는 오류는 숫자 자체가 그럴듯해 다른 방법으로는 발견이 어렵지만 원본 화면과 나란히 놓고 대조하면 즉시 드러납니다. 우리 수집기가 선수를 팀 대조로 판별하게 된 것도 이런 검증 과정의 산물입니다.
검증은 실행이 아니라 절차로 남긴다
한 번의 검증은 그 시점의 코드에 대한 증명일 뿐입니다. 수집 로직이 바뀌면, 사이트가 개편되면 증명은 낡습니다. 그래서 우리는 검증을 문서로 남겼습니다. 어떤 경기를 표본으로, 어떤 수치를 몇 개 대조했고 결과가 어땠는지를 기록한 검증 보고서입니다.
문서화의 효용은 재검증에서 나옵니다. 다음 변경 때 같은 절차를 반복하면 되므로 검증 비용이 떨어지고 "지난번엔 확인했었나"라는 논쟁이 사라집니다. 발주자 입장에서도 검증 보고서는 산출물의 일부로 받을 가치가 있는 문서입니다.
데이터 검증 체크리스트
- 표본 단위(리포트 한 장, 정산서 한 건)의 전수 대조를 수행했는가
- 검증 표본·항목 수·결과가 문서로 남았는가
- 수치의 계보(단계별 중간 산출물)가 추적 가능한가
- 재검증 트리거(수집 로직 변경, 대상 사이트 개편)가 정해져 있는가
검증을 돕는 구조: 산출물 계보
전수 대조를 쉽게 하려면 수치의 출처가 추적돼야 합니다. 우리 수집기는 단계별 중간 산출물을 실행 식별자 아래 저장해 리포트의 수치가 어느 단계의 어떤 데이터에서 왔는지 거슬러 올라갈 수 있게 했습니다. 대조 중 불일치가 나오면 수집·조립·렌더 중 어느 층의 문제인지 바로 좁혀집니다.
검증 가능한 산출물이라는 관점은 다른 프로젝트에서도 반복됩니다. 정산 자동화에서 가공 결과와 나란히 원본 행을 보존해 대조 경로를 남긴 것(광고비 정산 자동화)도 같은 원리입니다. 수집기 자체의 안정 장치는 셀렉터 안정화 설계에서, 이 검증이 수행된 시스템의 전체 그림은 야구 데이터 수집 자동화 사례에서 볼 수 있습니다.
자주 묻는 질문
수집 데이터 검증은 어떻게 하는 게 좋나요?
최종 산출물에 표시되는 수치를 원본과 직접 대조하는 것이 가장 확실합니다. 표본 몇 개가 아니라 표본 단위(리포트 한 장, 정산서 한 건)의 전수 대조를 권합니다. 계통 오류(특정 지표 전체가 밀리는 유형)는 부분 표본으로 놓치기 쉽기 때문입니다.
단위 테스트가 있으면 대조 검증은 필요 없지 않나요?
역할이 다릅니다. 단위 테스트는 "코드가 의도대로 동작하는가"를, 대조 검증은 "의도 자체가 원본과 맞는가"를 확인합니다. 엉뚱한 열을 읽도록 잘못 의도된 파서는 테스트를 통과하면서 틀린 데이터를 만듭니다. 두 검증은 보완 관계입니다.
검증은 한 번 하면 끝인가요?
아닙니다. 검증은 그 시점 코드에 대한 증명이라, 수집 로직 변경이나 대상 사이트 개편 후에는 재검증이 필요합니다. 절차를 문서로 남겨 두면 재검증 비용이 크게 줄고 검증 보고서 자체가 납품물의 신뢰 근거가 됩니다.
수치가 틀렸을 때 원인은 어떻게 찾나요?
단계별 중간 산출물을 남겨 계보를 추적합니다. 수집 원본, 조립된 데이터셋, 최종 렌더 값을 실행 단위로 보관하면, 불일치가 수집·조립·표시 중 어느 층에서 생겼는지 바로 좁혀집니다. 계보가 없으면 모든 원인을 처음부터 의심해야 합니다.