특정 약물에 대해 알려진 안전 신호(safety signals)가 무엇인지 Claude에게 물어보면, Claude는 자신의 학습 데이터로부터 답변할 것입니다. 이는 과거의 어느 시점에 고정된, 보고 ID(report IDs)가 뒷받침되지 않은 그럴듯한 요약일 뿐입니다. 가벼운 질문이라면 괜찮습니다. 하지만 실제 보고서에서 실제 신호를 포착하는 것이 업무인 약물감시(pharmacovigilance) 작업에서 "그럴듯한 요약"은 당신이 필요로 하는 것과 정반대되는 것입니다. 당신에게는 근거가 되는 사례들이 필요합니다: 누가 영향을 받았는지, 어떤 반응이 기록되었는지, 얼마나 심각했는지, 그리고 보고자가 실제로 지목한 약물이 무엇인지 말입니다.

이 가이드에서는 Claude를 공식 Apify MCP 서버에 연결하고, FDA 이상사례 보고 시스템(FAERS)을 읽는 단일 Actor를 노출합니다. 이 가이드를 마치면 Claude, Cursor 또는 모든 MCP 클라이언트가 대화 도중에 호출하여 약물에 대한 실제 이상사례 보고서를 가져올 수 있는 작동 가능한 도구를 갖게 됩니다. 여기에는 환자 세부 정보, 반응, 심각성, 그리고 실제 안전 검토(safety review)의 근거가 되는 의심 약물 대 병용 약물(suspect-versus-concomitant) 분석 내용이 포함됩니다.

아래의 모든 내용은 실제 설정과 실제 출력 결과입니다. 가짜 응답(mocked responses)은 없습니다.

Apify MCP 서버란 무엇인가?

Model Context Protocol (MCP)는 AI 클라이언트가 외부 도구를 호출할 수 있게 해주는 개방형 표준입니다. Apify MCP 서버(https://mcp.apify.com)는 Apify 플랫폼 상에서 해당 표준을 구현하며, 이는 Apify Store에 있는 수천 개의 Actor 각각이 에이전트가 호출할 수 있는 도구가 된다는 것을 의미합니다.

왜 API 호출을 직접 하드코딩하는 대신 MCP를 통해 Actor를 라우팅할까요?

• 에이전트가 가져올 시점을 결정합니다. Claude는 대화를 읽고 자신이 가지고 있지 않은 최신 보고 데이터가 필요함을 인지하여 스스로 도구를 호출합니다. 모든 질문에 대해 일일이 연결 코드 (glue code)를 작성할 필요가 없습니다.
• 구조화된 입력 및 출력. MCP 서버가 Claude에게 Actor의 입력 스키마 (input schema)를 전달하므로, 모델은 매개변수를 정확하게 채우고 추론 가능한 깔끔한 데이터셋을 반환합니다.
• 하나의 연결로 여러 도구 사용. 동일한 MCP 엔드포인트가 search-actors, fetch-actor-details, call-actor를 노출하므로, 에이전트는 새로운 설정 없이도 어떤 Actor든 발견하고 실행할 수 있습니다.
• 인프라 구축 불필요. 서버는 호스팅되어 있습니다. 설정 파일에 몇 줄만 추가하면 끝납니다.

사용할 Actor

우리는 openFDA Drug Adverse Events & Recalls Scraper를 노출할 것입니다. 약물 이름을 입력하면, 이 Actor는 FAERS 안전 보고서를 다음과 같은 구조화된 레코드로 반환합니다: 안전 보고서 ID, 환자의 성별 및 연령, 보고된 반응, 심각성 플래그 및 그 이유 (입원, 생명 위협, 사망), 보고 유형 및 날짜, 보고 국가, 그리고 보고서에 포함된 전체 약물 목록이며, 각 약물은 적응증 (indication) 및 투여 경로 (route)와 함께 의심 (suspect) 또는 **병용 (concomitant)**으로 표시됩니다. 동일한 Actor를 사용하여 데이터셋 입력을 전환하면 약물 회수 (recall) 조치 정보도 가져올 수 있습니다.

이러한 필드 세트는 약물 감시 (pharmacovigilance) 및 약물 안전 검토에 필요한 것입니다. 단일 숫자가 아니라 보고서 전체가 필요하며, 이를 통해 분석가는 환자의 맥락을 확인하고 어떤 약물이 연루되었는지 판단할 수 있습니다. FAERS는 공개되어 있고 권위 있는 자료이므로, 에이전트에 연결하기 위한 깨끗한 첫 번째 소스로 적합합니다.

1단계: Apify API 토큰 가져오기

Apify Console에 로그인한 후, Settings → Integrations를 열고 개인 API 토큰을 복사합니다. MCP 서버는 인증을 수행하고 Actor 실행 비용을 귀하의 계정으로 청구하는 데 이 토큰을 사용합니다.

📌 참고: 토큰은 비밀 정보입니다. 클라이언트 설정(config)에만 보관하고, 프롬프트에 입력하거나 커밋된 파일에 절대 포함하지 마세요.

2단계: Claude Desktop을 Apify MCP 서버로 지정하기

Claude Desktop의 설정 파일(Settings → Developer → Edit Config, 또는 macOS의 경우 ~/Library/Application Support/Claude/claude_desktop_config.json)을 열고 Apify 서버를 추가합니다. tools 쿼리 파라미터가 중요한 부분입니다. 이 파라미터는 서버에 어떤 Actor를 노출할지 알려주어, Claude가 전체 Store 대신 하나의 집중된 도구만 가져올 수 있게 합니다.

{
  "mcpServers": {
    "apify": {
...

Cursor는 .cursor/mcp.json에서 동일한 JSON을 사용합니다. 호스팅된 엔드포인트 대신 stdio를 통해 로컬에서 실행하는 것을 선호한다면 다음과 같이 설정합니다:

{
  "mcpServers": {
    "apify": {
...

Claude Desktop을 재시작하여 새로운 서버를 인식하도록 합니다.

3단계: 도구가 로드되었는지 확인하기

재시작 후, Actor가 호출 가능한 도구로 나타납니다. Apify 서버가 노출하는 도구 목록을 확인하면 스토리지 헬퍼(storage helpers)와 함께 Store 핸들 이름으로 지정된 Actor 자체를 볼 수 있습니다:

get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--openfda-drug-events-scraper

마지막 항목인 scrapers_lat--openfda-drug-events-scraper가 바로 우리의 약물감시 (pharmacovigilance) 도구입니다. 이제 Claude는 이 도구가 존재한다는 것과, 무엇을 하는지 (Actor의 README로부터), 그리고 어떤 입력값을 받는지 (서버가 전달하는 입력 스키마로부터) 알고 있습니다. 입력값으로는 약물 이름을 나타내는 searchQuery, 이벤트 또는 리콜(recalls)을 선택하는 dataset 셀렉터, 선택 사항인 날짜 범위, 그리고 maxRecords 제한이 있습니다.

4단계: Claude에게 이상사례 보고서를 가져오도록 요청하기

이제 결과물을 확인할 차례입니다. 일반적인 채팅에서 실제 보고서가 필요한 질문을 던져보세요:

"아스피린이 언급된 최근 FDA 이상사례 보고서(FAERS)를 가져와 줘. 환자, 반응, 그리고 어떤 약물이 의심 약물(suspect)로 표시되었는지 포함하여 심각한 사례 하나를 전체 내용으로 보여줘."

Claude는 자신이 기억만으로는 이에 답할 수 없음을 인지하고, FAERS 도구를 선택한 뒤 사용자의 질문으로부터 입력값을 채웁니다. 내부적으로 클라이언트는 Actor의 파라미터가 포함된 tools/call을 전송합니다:

{
  "name": "scrapers_lat--openfda-drug-events-scraper",
  "arguments": {
...

Apify MCP 서버는 Actor를 실행하고, 실행이 완료될 때까지 기다린 후 데이터셋을 반환합니다. 다음은 생성된 실제 실행 메타데이터(run metadata)입니다:

{
  "runId": "DzlAwbvYGb0ojGgBt",
  "actorName": "scrapers_lat/openfda-drug-events-scraper",
...

5초도 채 되지 않아 25개의 실시간 FAERS 보고서가 추출되었습니다.

5단계: 실제 출력 결과 읽기

도구가 반환하는 데이터셋은 구조화된 안전 보고 데이터(safety-report data)입니다. 다음은 실행 결과에서 추출한 실제 기록입니다 (안전 검토에 중요한 필드만 포함):

{
  "safetyReportId": "10003432",
  "reportType": "Spontaneous",
...

Claude는 이를 읽고 평이한 언어로 답변합니다: 이것은 심각한 (serious) 보고서이며, 안전 보고서 번호 10003432로, 말초 부종(peripheral oedema) 및 체액 저류(fluid retention)로 인해 **입원(hospitalized)**한 84세 여성에 관한 것입니다. 아스피린은 그녀의 복용 약물 목록에 있지만, 보고자는 이를 병용 (concomitant) 약물로 표시했습니다. 표시된 의심 (suspect) 약물은 폐동맥 고혈압 치료를 위해 복용 중인 Letairis (ambrisentan)이며, 체액 저류는 이 약물 계열의 알려진 신호(class signal)입니다. 이 모든 사실은 모델의 기억이 아니라 공식 FAERS 기록을 통해 추적할 수 있습니다.

의심 약물(suspect)과 병용 약물(concomitant)의 구분은 이 작업의 핵심입니다. "aspirin"에 대한 단순한 키워드 검색은 이 보고서를 찾아내지만, 보고서 작성자는 aspirin을 원인으로 지목하지 않았습니다. 분석가는 이러한 차이를 파악해야 하며, 모델은 aspirin이 부종(oedema)을 유발했다고 암시하는 대신 이를 정직하게 전달할 수 있도록 구조화된 characterization 필드가 필요합니다. 도구는 이를 드러내 주지만, 기억에 의존한 요약은 이러한 차이를 뭉뚱그려 버릴 것입니다.

실제 사용 사례: 시그널 분류(signal-triage) 어시스턴트

맥락을 살펴보겠습니다. 제품을 모니터링하는 약물 안전 분석가(drug-safety analyst)는 유입되는 FAERS 보고서를 검토하여 노이즈(noise)와 시그널(signal)을 구분해야 합니다. 관심 있는 각 약물에 대해 분석가는 다음 사항을 신속하게 파악해야 합니다: 최근 보고서 중 심각한(serious) 사례가 몇 건인지, 어떤 반응이 반복되는지, 그리고 해당 약물이 단순히 환자의 복용 목록에 포함된 것인지 아니면 실제 의심 약물(suspect)로 분류되었는지 여부입니다.

도구가 없다면 분석가는 FAERS 프런트엔드에 쿼리를 날리고, 보고서를 하나씩 열어 필드 내용을 스프레드시트에 복사해야 합니다. 하지만 Claude에 이 도구가 연결되어 있다면, 분석가는 약물 이름을 말하고 에이전트에게 최근 보고서를 가져와 심각한 사례의 수를 세고, 주요 반응을 집계하며, 해당 약물이 의심 약물로 표시된 사례와 기록된 심각성 사유를 나열하라고 요청할 수 있습니다. Claude는 Actor를 호출하고, 반환된 데이터셋을 바탕으로 추론하며, 보고서 ID를 증거로 포함한 짧은 분류(triage) 노트를 생성합니다. 분석가는 복사 및 붙여넣기가 아닌, 판단을 내리는 데 시간을 집중할 수 있습니다.

그러한 요청을 구체적인 브리프(brief) 형태로 나타내면 다음과 같습니다: "이 약물에 대한 마지막 보고서 배치를 가져와서, 반응(reaction)별로 그룹화하고, 어떤 반응이 심각한 보고서(serious reports)에 나타나는지 알려주세요. 그리고 약물이 의심 약물(suspect drug)이면서 심각성 사유가 사망 또는 생명을 위협하는 경우를 표시해 주세요." Claude는 입력을 채우고, Actor를 한 번 실행한 뒤, 한 줄씩 근거를 제시할 수 있는 표 형태로 답변합니다. 왜냐하면 모든 행이 FAERS 기록에서 열어볼 수 있는 safetyReportId를 가리키고 있기 때문입니다. 동일한 프롬프트에서 단어 하나만 바꾸면 다음 약물에도 똑같이 적용됩니다. 이것이 바로 에이전트 도구(agent tool)가 저장된 대시보드보다 뛰어난 이유입니다. 질문이 바뀌면 도구도 그에 맞춰 움직일 수 있기 때문입니다.

이것이 모든 훌륭한 에이전트 도구의 형태입니다. 즉, 의사결정을 제거하는 것이 아니라 기계적인 데이터 호출(mechanical fetch)을 제거하는 것입니다. 그리고 각 기록은 고유한 safetyReportId를 가지고 있기 때문에, 에이전트 요약에 포함된 모든 주장은 원본 보고서까지 추적 및 감사(auditable)가 가능합니다.

더 나아가기: 두 번째 도구 체이닝(chaining)

이상사례 분류(triage)는 단순히 보고서 자체에서 끝나지 않는 경우가 많습니다. 의심 약물을 확인했다면, 다음 질문은 해당 약물의 승인된 라벨(label)에 무엇이라고 적혀 있는가입니다. 즉, 적응증(indications), 경고(warnings), 박스 경고(boxed warnings), 그리고 제조사가 이미 나열한 이상반응(adverse reactions) 등이 대상입니다. 동일한 MCP 연결을 통해 tools 파라미터를 확장함으로써 더 많은 Actor를 노출할 수 있습니다:

이제 에이전트는 동일한 대화 내에서 특정 약물에 대한 FAERS 보고서를 가져오는 동시에 공식 FDA 라벨을 가져올 수 있으며, 보고서에서 반복되는 반응이 라벨에 이미 문서화된 경고인지 아니면 새로운 현상처럼 보이는지를 알려줄 수 있습니다. 각 Actor는 별개의 도구이므로, 에이전트는 각 단계에 맞는 적절한 도구를 스스로 선택합니다. 즉, 현장 신호(field signal)에는 이벤트(events) 도구를, 승인된 참조(approved reference)에는 라벨(labels) 도구를 사용하는 식입니다.

🏹 문제 해결(Troubleshooting): 만약 Claude에 도구가 나타나지 않는다면, 일반적인 두 가지 원인은 tools 파라미터에 Actor 핸들(handle)이 누락되었거나 잘못 입력된 경우(Store URL에 있는 정확한 username/actor-name이어야 함), 그리고 Claude가 실행 중인 동안 설정(config)을 수정한 경우입니다. 핸들을 수정하고 저장한 뒤, 클라이언트를 완전히 재시작하십시오.

📌 참고: 각 도구 호출(tool call)은 귀하의 Apify 계정으로 비용이 청구되는 실제 Actor 실행입니다 (이 Actor는 결과당 과금 방식입니다). 대화형 분류(triage)의 경우 쿼리당 비용은 1센트의 아주 작은 일부에 불과합니다. 만약 수천 개의 약물을 일정에 따라 전수 조사할 계획이라면, 채팅 메시지당 한 번씩 호출하는 대신 Apify API 또는 예약된 작업(scheduled task)을 통해 Actor를 직접 실행하십시오.

해석에 관한 주의사항

FAERS는 자발적 보고 시스템(spontaneous-reporting system)입니다. 보고가 되었다는 것은 누군가가 이를 제출했다는 의미이지, 해당 약물이 사건을 유발했다는 것을 의미하지는 않습니다. 또한 많은 보고가 임상의가 아닌 소비자로부터 옵니다. 보고서에 기재된 반응은 어떤 결과로든 나타날 수 있으며, 동일한 사례에 수십 개의 약물이 나열될 수 있고, 중복 보고도 존재합니다. FAERS를 에이전트에 연결하는 가치는 자동화된 인과관계 파악이 아닙니다. 숙련된 검토자가 해석을 수행할 수 있도록 가공되지 않은 보고서에 빠르고 감사 가능한(auditable) 방식으로 접근할 수 있게 하는 데 있습니다. 이러한 관점을 유지한다면, 이 도구는 진지한 워크플로우에서 제 역할을 다할 것입니다.

마무리

이제 귀하는 대화 도중 환자 맥락, 심각도, 의심 약물 상세 정보 등 실제 안전성 검토에 필요한 정보를 포함하여, 요청 시 실시간으로 실제 FDA 이상사례 보고를 가져올 수 있는 AI 에이전트를 보유하게 되었습니다. 이 패턴은 재사용 가능합니다. 권위 있는 구조화된 데이터(structured data)를 반환하는 Actor를 선택하고, tools 파라미터를 통해 Apify MCP 서버로 이를 노출한 뒤, 에이전트가 언제 호출할지 결정하게 하십시오.

더 나아가려면: