언제 쓰나
수집 → 병합 → 정규화 → 분석 파이프라인을 여러 번 다시 돌릴 때. 규칙을 고칠 때마다 예전에 고쳤던 버그가 되살아나는지 확인해야 한다.
정본 코드
~/Documents/혜연/BTC_KOL_PoC/
validate.py 167줄 파이프라인 전체 무결성
verify_merges.py 316줄 추론 병합 전수 재판정핵심 1 — 터졌던 버그를 회귀 테스트로 박아라
건수·중복·커버리지에 더해, 지금까지 실제로 터졌던 버그의 회귀 테스트를 포함한다.
일반 검증(건수가 맞나, 중복이 없나)만으로는 한 번 고친 버그가 되살아나는 걸 못 잡는다. 정본에 박혀 있는 두 개:
# 회귀: 4글자 이하 실명을 이니셜로 쪼개던 버그 (Hwang Shin → HWANG S H I N)
check("회귀 · 실명을 이니셜로 오인하지 않음", not split_bug, ...)
# 회귀: 강창무 ← 김성현 오병합
check("회귀 · KANG CHANG MOO ≠ KIM SUNG HYUN", ...)구체적인 사례를 이름째로 박는다. "이니셜 처리가 잘 되나" 같은 추상적 검사는 무엇이 깨졌는지 안 알려준다. 실제로 틀렸던 그 사람의 이름을 넣으면 깨지는 순간 원인이 바로 보인다.
버그를 고칠 때마다 그 케이스를 여기 한 줄 추가하는 습관을 들인다.
핵심 2 — 추론으로 합친 건은 전수로 본다
verify_merges.py 의 판단 기준이 정확하다.
병합은 네 규칙으로 일어난다. ① 은 ORCID 라는 식별자를 쓰므로 검증 대상이 아니다. ②③④ 는 표기·기관·공저자를 근거로 한 추론이라 틀릴 수 있고, 틀리면 두 사람의 실적이 한 사람에게 합쳐진다. KOL 순위를 직접 흔들기 때문에 전수로 본다.
식별자 조인과 추론을 나누고, 추론만 검증한다. ORCID 로 합친 건 검증할 게 없다. 표본이 아니라 전수로 보는 이유는 오류 하나가 순위를 바꾸기 때문이다 — 영향이 큰 판정은 표본으로 넘기지 않는다.
검증은 2단계다: 식별자 판정(ORCID·PMID 로 확인 가능한 것) → GPT 판정(남은 것). 여기서도 싼 근거를 먼저 쓴다.
python3 verify_merges.py --list # 검증 대상 목록
python3 verify_merges.py --run # 식별자 판정 + GPT 판정
python3 verify_merges.py --report # 결과 요약검사 결과는 한 줄씩 PASS/FAIL 로
check(name, ok, detail) 형태로 항목마다 이름·통과여부·상세를 낸다. 실패한 항목만이 아니라 통과한 항목도 함께 출력한다 — 무엇을 검사했는지가 보여야 검증의 범위를 신뢰할 수 있다.
함정
- 검증은 read-only. 검증 스크립트가 데이터를 고치면 검증의 의미가 없다.
--selfcheck를 검증 스크립트 자체에도 둔다. 검증기가 틀리면 아무것도 못 믿는다.- 기대값을 숫자로 박되 그 근거를 주석에 남긴다 —
excel-case-validator참조.
연관 skill
excel-case-validator(엑셀 대조 검증), author-disambiguate(검증 대상), paper-merge-provenance, wos-export-check(입력 단계 검수)