임상시험 등록기록에 결과와 날짜가 있다고 해서, 그 결과가 언제부터 공개돼 있었는지까지 한 번에 알 수 있는 것은 아니다. 결과 제출을 시도한 이력과 결과표가 실제로 나타난 상태를 구분해야 하고, 변화를 어느 날짜에 놓을지도 정해야 한다. 기록을 비교하기 전에 먼저 풀어야 할 문제였다.
나는 ClinicalTrials.gov의 변경 이력을 읽는 틀을 상태·시간·기준점으로 나누어 설계했다. 같은 기록을 보더라도 무엇을 하나의 상태로 읽고, 어떤 날짜를 사건의 시점으로 쓰며, 어디를 비교의 기준으로 잡느냐가 다를 수 있기 때문이다. 이 선택을 드러내 놓고 검토하는 상태–시간–기준점, 곧 state–clock–anchor 감사 방식으로 원고와 근거 자료를 준비했다.
세 가지 선택을 따로 둔다
상태는 그 시점의 등록기록에 무엇이 나타나 있는지를 뜻한다. 이 작업에서는 결과 제출을 시도한 이력과 결과 내용이 실제로 실린 상태를 나누어 읽었다. ‘결과가 있다’는 표시 하나에 기대기보다, 해당 버전의 결과 영역에 내용이 있는지를 확인하는 방식으로 공개된 상태를 정의했다.
시간은 변화를 어느 날짜에 놓을지 정하는 규칙이다. 이를 clock이라고 불렀다. 기준점인 anchor는 그 날짜를 무엇에 비추어 비교할지 정하는 선택이다. 처음 결과가 공개될 때의 기록을 기준으로 삼는 것과 나중의 기록을 기준으로 삼는 것을 구분해, 시간 규칙과 기준점 선택을 교차하여 비교하도록 구성했다. 둘을 함께 바꾸어 놓고 차이가 어느 한쪽에서만 왔다고 읽지 않기 위해서다.
이렇게 나누는 목적은 등록기록으로 실제로 무엇을 측정하고 있는지 살피는 데 있다. 기록의 변화는 관찰할 수 있지만, 그 변화만으로 법적 의무 위반이나 연구자의 의도를 판단하는 것은 다른 문제다. 이 감사 방식은 기록을 표현하고 비교하는 선택을 검토하는 방법으로 범위를 잡았다.
재현 자료를 따로 공개했다
2026년 8월 29일 재현 자료 v1.0.0을 Zenodo에 공개했다. 수집·재구성·분석 코드, 파생 데이터, 그림의 입력 자료, 테스트와 실행 안내를 함께 묶었다. 어떤 자료를 사용했는지 되짚을 수 있도록 수집 목록과 파일 해시도 남겼다. 해시는 파일 내용이 달라졌는지 비교하는 데 쓰는 값이다.
다만 원시 변경 이력 응답을 한꺼번에 모은 파일은 이 공개 묶음에 재배포하지 않았다. 테스트와 그림 생성은 배포한 자료에서 실행할 수 있지만, 전체 변경 이력을 같은 입력으로 다시 구성하려면 기록된 해시와 일치하는 원시 자료도 필요하다. 나중에 사이트에서 다시 받은 자료가 보존된 입력과 같다는 보장은 없으므로, 공개 코드의 존재와 동일 입력 재현의 조건을 구분해 적었다.
TrialTrace: 변경 이력을 직접 살펴보는 도구
이 재현 자료를 바탕으로 임상시험 기록의 변화를 찾아볼 수 있는 TrialTrace를 만들어 2026년 9월 14일 코드를 공개했다. 이번 공개판은 임상시험 400개의 기록에서 재구성한 5,629건의 버전 간 변화를 다룬다. 이는 공개판에 포함한 자료의 규모이며, ClinicalTrials.gov 전체나 현재의 등록 상태를 뜻하지 않는다.
임상시험 식별번호인 NCT 번호를 넣으면 버전별 날짜와 변경된 항목을 시간순으로 살펴보고, 공식 변경 이력 페이지로 돌아가 확인할 수 있다. 나는 비교에 쓴 자료와 출처를 함께 확인할 수 있도록 수집 목록과 파일 해시를 연결했다. 원시 응답 파일 전체를 재배포하지 않고, 공개 가능한 파생 표와 필요한 출처 정보를 도구에 포함했다.
코드를 내려받아 Python 환경에서 실행하면 검색 화면과 API를 사용할 수 있다. 데이터베이스를 만들 때는 파일 해시와 자료 수를 검사하며, 테스트와 자동 검사 절차도 저장소에 함께 공개했다. 현재 공개판은 보존된 자료를 읽는 도구로, 최신 기록을 실시간으로 감시하거나 변경 이유를 판정하는 서비스는 아니다.
처음 실행한다면 Python 3.11 이상 환경에서 저장소의 설치·실행 안내를 따른 뒤, 로컬 주소 http://127.0.0.1:8000를 열면 된다. 사용 안내의 예제 번호 NCT04153409로 검색해 날짜와 변경 항목을 살펴보고, 결과에 연결된 공식 이력과 대조해 볼 수 있다.
실행이나 기록 비교 중 막힌 곳이 있다면 어느 단계에서 무엇을 확인하려 했는지 알려주시면 좋겠다. 오류 내용과 환경 정보는 공개해도 되는 범위만 보내주시면 된다.
같은 날 OpenSSF Best Practices의 Passing 기준을 충족했다. 개발·테스트·보안 관행에 관한 항목에 근거를 연결해 제출하는 프로젝트 자기인증이며, 독립적인 보안감사나 취약점이 없다는 보증을 뜻하지 않는다.
자료 공개와 원고의 진행
2026년 8월 30일에는 원고를 저널에 제출했고 접수 기록을 받았다. 연구 구성과 다음 경로도 계속 검토하고 있다. 재현 자료의 DOI는 공개된 데이터 묶음을 가리키며, 논문의 게재 수락이나 온라인 최종판을 뜻하지 않는다.
상세한 연구 결과는 논문의 온라인 최종판과 활성 DOI가 확인된 뒤 설명할 범위로 남겨 두었다. 이 글에서는 미출판 집계와 결론, 심사 서신과 원고 식별정보를 공개하지 않는다.
결국 붙잡고 있는 질문은 기록을 비교하기 전에 비교의 조건을 얼마나 분명하게 적을 수 있는가다. 상태와 날짜, 기준점을 따로 놓아야 같은 등록기록을 읽은 다른 사람이 그 선택부터 다시 살펴볼 수 있다.