안녕하세요, 약토피아입니다☺️
"이 적응증에 지금 임상 3상이 몇 개나 진행 됐거나 진행 되고있지?”
”어떤 약물들이 경쟁하고 있지?"
한 번쯤 확인해보고 싶은 질문인데요.
막상 ClinicalTrials.gov에 들어가보면
임상시험 한 건만 해도 페이지가 여러 장이라,
스무 건이 넘어가면 엑셀에 옮겨 적다가 하루가 갑니다.
그리고 다 옮기고 나서
"이 칸, 내가 어디서 보고 적었더라?"
"이 내용은 다시 확인해봐야겠는데?"라는
의문이 남기 쉬워요.
그래서 오늘은 Claude로 근거를 추적할 수 있고,
필터를 적용해 interactive하게 사용할 수 있는
경쟁 임상 비교표를 만들어보겠습니다.
오늘 예시로 보여드릴 질환 영역은 EGFR 변이 비소세포폐암입니다.
준비물 먼저!
오늘의 준비물은 Clinical Trials 커넥터 연결하기입니다.
커넥터를 연결하면 클로드가 ClinicalTrials.gov를 직접 조회합니다.
기억으로 답하는 게 아니라 등록 원본을 가져오기 때문에,
없는 NCT 번호를 적을 위험이 크게 줄어요.
👉 커넥터 연결하는 법은 지난 칼럼 — <Claude Cowork로 출처 추적되는 임상시험 비교표 만들기>에서 자세히 다뤘으니 참고해주세요! ☺️
Step 1. 프로젝트 만들기
💡 Claude 프로젝트가 뭔가요?
같은 규칙을 공유하는 대화들을 묶어두는 작업 공간이에요.
프로젝트에 지침을 한 번 저장해두면,
그 안에서 새로 여는 모든 대화에 자동으로 적용됩니다.
매번 "이렇게 저렇게 해줘"를 다시 칠 필요가 없어요.
오늘처럼 단계가 여러 개인 작업에 특히 유용합니다.
(Claude 유료 플랜에서 제공됩니다.)
1️⃣ [프로젝트] → [새 프로젝트]를 누르고 프로젝트 이름을 입력한 뒤 [프로젝트 만들기]를 클릭합니다.
2️⃣ 프로젝트 [지침]란에 아래 프롬프트를 입력하고 [지침 저장]을 클릭합니다.
[프로젝트 지침 프롬프트]
# Project 지침 — 임상시험 비교표 파이프라인
당신은 임상시험 데이터를 비교 가능한 표로 정리한다.
지시받은 단계만 수행하고, 단계를 건너뛰거나 합치지 않는다.
## 절대 규칙 3개
1. 원문에 없는 정보는 null. 추측·상식으로 채우지 않는다.
2. evidence 는 원문을 한 글자도 바꾸지 않고 복사한다.
두 문장을 이어붙이지 마라. 근거가 여러 군데면 더 짧고 결정적인 것 하나만.
3. 값이 없거나 도구가 막히면 그 사실을 보고하고 그대로 진행한다.
멈춰 서서 되묻지 마라. 단, 무엇을 못 했는지는 반드시 보고한다.
## 1. 모을 때
- 도구 응답을 요약·정리·해석하지 않는다. 받은 그대로 저장한다.
- 여러 페이지면 다 받을 때까지 반복하고, 총 건수와 실제 저장 건수를 대조해 보고한다.
- "가져왔습니다"라고만 하지 말고 식별자 목록 전체를 나열한다.
## 2. 뽑을 때 — 값을 두 종류로 구분한다
- **그대로 옮길 값** — 원본에 그 항목이 그대로 있는 값(식별자·이름·수치·원문 문구).
evidence 를 달지 않는다.
- **네가 판단할 값** — 원본에 그 항목이 없어서 네가 본문을 읽고 정한 값(분류·환산·판정).
반드시 evidence 에 그렇게 판단한 근거가 된 원문 문장을 한 글자도 바꾸지 않고 복사해 남긴다.
어느 값이 어느 쪽인지는 실행 프롬프트가 지정한다.
## 3. 표 만들 때
- HTML을 손으로 쓰지 않는다. 데이터를 읽어 HTML을 뱉는 스크립트를 짜서 실행한다.
값을 눈으로 옮겨 적는 순간 조용한 오류가 들어간다.
- 네가 판단한 칸은 마우스를 올리면 evidence 가 툴팁으로 보이게 한다.
- 빈 칸은 —. 문서 상단에 "— 는 해당 없음이 아니라 원본에 없음"을 한 줄 명시한다.
- 본표에서 뺀 행은 조용히 빼지 말고 별도 목록에 사유와 함께 전부 남긴다.
- 단일 HTML. CSS·JS 인라인. 외부 요청 0건.
## 4. 검증기 만들 때
- 판정은 AI가 아니라 코드가 한다. 문자열이 원본에 있는지 없는지만 본다.
- raw 를 JSON.parse 해서 그 안의 모든 문자열 값을 모아 대조한다.
파일 텍스트를 그대로 검색하지 마라 — 줄바꿈이 이스케이프돼 있어 안 맞는다.
- 숫자도 문자열로 바꿔 대조 대상에 포함한다. 비교는 부분문자열 포함으로.
- 만든 뒤 스스로 한 번 돌려보고, 실패가 진짜 오류인지 대조 버그인지 구분해 보고한다.
- 실패가 나오면 고칠 것은 검증기가 아니라 뽑아낸 evidence 다.프로젝트를 만들고 나면, 다음 자료 수집 단계로 넘어갑니다.
Step 2. 자료 수집
첫 프롬프트가 하는 일은 원본을 손대지 않고 받아두는 것입니다.
[프롬프트 1]
Clinical Trials 도구로 다음 조건의 시험을 검색해줘.
- condition: EGFR mutated non-small cell lung cancer
- phase: 3
- status: RECRUITING, ACTIVE_NOT_RECRUITING, COMPLETED, ENROLLING_BY_INVITATION
- lead sponsor class: INDUSTRY
- start date: 2024년 이후
받은 응답을 요약하지 말고 그대로 raw.json 에 저장해줘.
각 시험은 get_trial_details 로 상세도 받아서 같이 저장해줘.
locations 배열은 건수만 기록하고 본문은 빼줘.
마지막에 총 건수와 NCT ID 목록을 보고해줘.💡 자료 수집 단계에서 왜 "원본 그대로"를 강조하나요?
마지막 검증 단계에서"이 문장이 원본에 있나?"를 대조하는데요,
원본이 이미 클로드가 요약한 문장이면 대조할 기준이 사라져요.
그래서 첫 단계에서는 아무 판단도 시키지 않습니다.locations(참여 기관 목록)만 건수로 줄였어요.
(시험 하나에 기관이 수백 개씩 달리기 때문)
자료 수집 단계에서는 AI에게 어떠한 판단도 시키지 않고,
원본 그대로를 저장하도록 했습니다.
💡용어 이해하기: JSON이란?
JSON은 데이터를 ‘이름표 : 값’ 쌍으로 적어 둔 텍스트입니다.
예시)
{
"sponsor": "argenx",
"phase": "PHASE3"
}특별한 프로그램이 아니라 그냥 텍스트라서 메모장으로도 열립니다.
오늘은 각 임상시험 정보를 JSON으로 저장할 거에요.
그러면 모든 값 옆에 ‘무엇을 뜻하는지’ 이름표가 항상 붙어 있어서
클로드도, 검증기도 값을 정확히 찾아 대조할 수 있습니다.
위에서 만든 raw.json처럼 이름이 ‘.json’으로 끝나는 결과물이 바로 이 형식입니다.
Step 3. 데이터 추출하기
Step 2에서 받은 원본은 시험 하나당 항목이 수십 개씩 딸린 데이터 묶음입니다.
여기서 표에 넣을 값만 골라 추출하는 단계를 거칠 거에요.
[프롬프트 2] 마지막 문장을 보면 3건만 먼저 진행하도록 설계했어요.
3건을 먼저 처리하면서, 내가 추가로 정해야 하는 기준에 대한 답변을 합니다.
[프롬프트 2]
raw.json 의 각 시험을 아래 스키마로 뽑아 extracted.json 으로 만들어줘.
■ 원본에서 그대로 옮길 값 — 근거를 달지 마라
nct_id · sponsor · drug(시험약) · comparator(대조군, 원문 표기 그대로)
· enrollment · phase_label · primary_measure
■ 네가 판단할 값 — 판정 근거가 된 원문 문장을 evidence 에 함께 남겨라
line : 1차 | TKI 진행 후 | 수술 전후 | 기타
comparator_type : EGFR TKI | 화학요법 | 표준치료(미지정)
target : EGFR | 그 외
■ 판정 규칙
[line] 시험약을 어느 시점에 투여하는지로 분류한다.
- 이전 항암치료를 받지 않은 환자에게 투여하면 → "1차"
(근거 표현: first-line / treatment-naive / previously untreated)
- EGFR TKI 치료 중 병이 진행한 환자에게 투여하면 → "TKI 진행 후"
(근거 표현: after progression on ... TKI / failed EGFR TKI)
- 수술 전후에 투여하면 → "수술 전후"
(근거 표현: perioperative / neoadjuvant / adjuvant / resectable)
- 위 표현이 원문에 하나도 없으면 → "기타"
[comparator_type] 대조군에 배정된 약이 무엇인지로 분류한다. 시험약은 보지 마라.
- 대조군이 EGFR 표적 경구제이면 → "EGFR TKI"
(osimertinib, aumolertinib, afatinib 등)
- 대조군이 백금 기반 항암화학요법 또는 docetaxel 이면 → "화학요법"
- 원문이 대조군을 "standard of care" 라고만 쓰고 약 이름을 밝히지 않았으면
→ "표준치료(미지정)"
단, 괄호 등으로 약 이름을 밝혔다면 그 약을 기준으로 분류한다
- 원문에 대조군이 아예 없으면 → null. 셋 중 하나로 억지로 분류하지 마라.
[target] 이 시험이 실제로 모집하는 환자의 유전자 변이로 분류한다.
- 적격기준이 EGFR 변이를 요구하면 → "EGFR"
- 적격기준이 다른 변이(예: HER2)를 요구하면 → "그 외"
검색어가 EGFR 이었더라도 마찬가지다
먼저 3건만 하고 멈춰줘. 확인 후 나머지 진행.이제 남은 시험들도 마찬가지로 데이터를 추출합니다.
[프롬프트 3]
나머지 전부 같은 방식으로 extracted.json 에 채워줘.
다 되면 건수와 판단이 갈렸던 지점을 보고해줘."판단이 갈렸던 지점을 보고해줘"라고 요청하는 이유는
클로드가 애매하다고 느낀 지점을 우리가 검토할 수 있게하기 위함이에요.
💡 왜 ‘그대로 옮길 값’과 ‘판단할 값’을 나눠서 지시하나요?
추출하는 값의 성격이 다르기 때문이에요.
예시 | 등록 원문에 | |
|---|---|---|
① 그대로 옮길 값 | 등록번호 · 등록 인원 · 스폰서 | 그 항목이 그대로 있음 |
② 판단할 값 | 치료 라인 · 대조군 유형 | 원하는 형태로는 없음 |
②를 구체적으로 보면 이렇습니다.
- 치료 라인 — ClinicalTrials.gov 등록 양식에는 치료 라인 항목 자체가 없습니다.
하지만 1차 치료인지 TKI 실패 후인지는 제목·요약·적격기준을 읽어야 알 수 있어요. - 대조군 유형 — 등록 양식에
활성대조 / 위약대조구분은 있습니다.
하지만 "EGFR TKI냐 화학요법이냐"는 없어요.
게다가 커넥터가 돌려주는 항목에는 이 구분조차 들어오지 않습니다.
즉 ②는 클로드가 본문을 읽고 스스로 분류한 값입니다.
그래서 ②에 해당되는 항목들은 그렇게 판단한 근거가 된 원본 문장을 함께 저장하게 시킵니다.
실제로 이렇게 나옵니다. (NCT06350097)
항목 | 뽑힌 값 | 함께 저장된 근거 |
|---|---|---|
스폰서 | AstraZeneca | — (원본에 그대로 있음) |
등록 인원 | 582명 | — (원본에 그대로 있음) |
치료 라인 | 1차 |
|
대조군 유형 | EGFR TKI |
|
1차, EGFR TKI 라는 표현은 원본에 없습니다.
하지만 왜 그렇게 판단했는지가 원문 문장으로 남아 있어요.
이 문장이 진짜 원본에 있는 문장인지는 Step 5에서 검증기가 확인합니다.
💡 "그대로 옮길 값"에는 왜 근거를 안 붙이나요?
틀릴 수가 없는 값이기 때문입니다.
스폰서: AstraZeneca는 원본에서 그대로 옮겨 적은 것뿐이에요.
여기에 "왜 그렇게 적었는지 근거를 대"라고 시키면
클로드가 없는 이유를 만들어 낼 확률이 증가합니다.
확인할 게 늘어나는 게 아니라, 지어낼 거리가 늘어나요.
Step 4. 인터렉티브 HTML 표 만들기
이제 뽑아낸 데이터를 필터되고 정렬되는 HTML 표로 만듭니다.
[프롬프트 4]
extracted.json 으로 landscape.html 을 만들어줘.
- 열: NCT · 시험약 · 치료 라인 · 무엇과 비교 · 대조군 유형 · 1차 평가변수 · 등록수 · phase · 스폰서
- 필터: 치료 라인 · 대조군 유형 · target
- 열 클릭하면 정렬. NCT 는 clinicaltrials.gov 링크
- 네가 판단한 칸(치료 라인·대조군 유형·target)은 마우스를 올리면
evidence 의 근거 문구가 툴팁으로 보이게 할 것
- target 이 "그 외"인 행은 본표에서 빼고 아래 별도 목록으로.
뺀 이유를 행마다 한 줄로 적을 것< Claude가 만들어 준 landscape.html >
판단한 칸에 마우스를 올리면 근거 원문이 그대로 뜹니다.
의문이 드는 내용이 있을 때,
파일을 일일이 찾지 않고 바로 확인할 수 있어요.
필터를 걸면 내가 원하는 범위 안에서 검색할 수 있어요.
⚠️ 주의할 점
- 이 표는 '비교 가능 여부를 확정한 표'이지, '효과 비교표'가 아닙니다.
head-to-head 시험 없이 서로 다른 시험 간 효과 크기를 비교하면 안 됩니다. - ClinicalTrials.gov는 설계(프로토콜)의 진실이지 결과의 진실이 아니에요.
"이렇게 하겠다고 등록했다"까지가 이 데이터의 범위입니다.
표 상단에도 명시해놨어요:—는 "해당 없음"이 아니라 "원본에 없음"입니다.
Step 5. 근거 문장 검증하기
Step 3에서 판단한 값마다 근거 문장을 함께 저장해뒀죠.
마지막으로 그 문장들이 정말 등록 원문에 있는 문장인지 확인합니다.
이걸 클로드에게 "이거 맞아?"라고 물어보지 않고,
대신 문장을 한 글자씩 대조하는 검증기를 만들어 돌릴 거에요.
검증기는 "이 문장이 원본 파일 안에 있다 / 없다"만 판단하도록 설계합니다.
[프롬프트 5]
extracted.json 의 값이 raw.json 안에 그대로 있는지 확인하는
검증기를 verifier.html 로 만들어줘.
- 붙여넣기 칸 두 개: raw.json / extracted.json
- 검사 대상은 두 종류 다:
① 판단 칸의 evidence 문구
② 그대로 옮겼다고 한 칸(drug · comparator · primary_measure · sponsor · phase_label)
- 통과율 %, 실패 목록(NCT · 필드 · 문구 · 사유) 표시
- 서버 전송 없음, 외부 라이브러리 없음
대조 방법을 이렇게 못박아줘. 검증기 자신이 틀리면 안 되니까:
- 원본을 파일 텍스트로 훑지 마. JSON 으로 파싱한 뒤 값만 꺼내서 비교해
(원본 파일 안의 줄바꿈은 \n 으로 이스케이프돼 있어서 텍스트로 훑으면 헛다리를 짚는다)
- 숫자도 문자열로 바꿔서 비교해
- 완전일치 말고 부분문자열로 봐
- 값이 리스트면 이어붙이지 말고 원소 하나씩 비교해
- 그 NCT 자기 원문 안에 있는지를 봐. 다른 시험 원문에 있는 건 통과가 아니다다른 질환에도 적용하고 싶다면?
프로젝트 지침을 새로 쓸 필요 없이, 아래 두 값을 바꾸면 돼요.
어디서 | 무엇을 |
|---|---|
[프롬프트 1] |
|
[프롬프트 2] |
|
판단할 값을 정할 때 아래 질문을 생각해보면 좋아요.
"이 질환에서 시험 설계가 갈리는 지점이 무엇인가?"
EGFR 변이 비소세포폐암은 치료 라인과 대조군에서 갈렸어요.
질환이 다르면 갈리는 지점도 다릅니다.
예를 들어 ATTR 아밀로이드증의 경우, 판단할 값을 이렇게 정해볼 수 있어요.
■ 네가 판단할 값
manifestation : 심근병증 | 다발신경병증 | 둘 다
comparator_type : 위약 | 활성대조 | 표준치료(미지정)
study_role : 본시험 | 연장연구 | 진단영상하지만 처음부터 정하지 못해도 괜찮아요.
[프롬프트 2]에서 시험 3건만 먼저 돌려보게 설계한 이유가
바로 이 판단할 값을 알기 위함이니까요!
오늘은 근거를 검증할 수 있는
경쟁 임상 인터랙티브 HTML 비교표 만드는 방법을 알아봤어요! 🙂
내용이 도움 되셨다면, 주변 동료분들께 많이 공유해주세요💚
약사 제약인을 위한 AI 커뮤니티
<약토피아> 3기 멤버를 모집합니다 (~9/4 마감)🔥
🩷 AI-driven 퍼스널 브랜딩 트랙
내 경험과 전문성을 콘텐츠 자산으로 쌓아,
약국·병원·회사·창업 어디에 있든 나만의 자리를 만듭니다.
소개글 둘러보기 →

🩵 바이브코딩 기초 트랙
클로드도 바이브코딩도 전혀 몰라도 괜찮습니다.
4주 만에 약학 뉴스 자동 큐레이션 앱을 만들며
탄탄한 바이브코딩 기본기를 갖춥니다.
소개글 둘러보기 →
💛 빌더 심화 트랙
클로드 코드에게 '만들어줘'를 반복하던 사람에서,
에이전트를 지휘하는 사람으로.
각자 만들고 싶은 앱·서비스를 정하고,
실제 배포까지 마치는 에이전틱 코딩 심화 트랙입니다.
각 트랙 페이지에서 2기 참여자분들의 생생한 후기와 멤버 성장 사례를 보실 수 있습니다.
하나씩 둘러보는 재미가 있으실 거예요!
