사례
도구 사슬로 SDM 주제를 훑어 본 예비 탐색
이 코스의 도구 셋을 공유의사결정 교육이라는 주제에 돌려 본 기록입니다. 방향을 잡는 데는 쓸모가 있었고, 실제 검토의 방법이 되지는 못했습니다.
이 코스에서 소개하는 도구들을 제 주제에 직접 돌려 본 기록입니다. 남의 이야기가 아니라 제가 화면을 눌러 본 기록이라서, 쓸모 있었던 자리와 그렇지 않았던 자리를 함께 적을 수 있습니다. 2026년 7월 뇌신경마취과학회 워크숍에서 이 화면들을 따라가며 설명했습니다.
무엇을 해 보려 했는가
관심 주제는 이것이었습니다.
AI가 보건의료 전문직 학습자와 임상의의 공유의사결정(shared decision-making, SDM)을 가르치고, 훈련하고, 평가하고, 학습을 지원하는 데 어떻게 쓰이는가.
"A와 B 중 어느 쪽이 낫다"를 묻는 효과 질문이 아니라, 비교가 아직 서지 않는 주제에서 무엇이 어떻게 쓰이고 있는지 지도를 그리는 종류의 질문입니다. 그래서 질문의 틀도 PICO가 아니라 PCC로 잡았습니다.
| 칸 | 예비 탐색에서 채운 값 |
|---|---|
| P 대상·문제 | 보건의료 전문직 학습자, 임상의, 교육자 |
| C 개념 | AI 기반 교육, 시뮬레이션, 코칭, 평가, 피드백 |
| C 맥락 | SDM 교육, 의사소통 훈련, 환자중심 결정대화 |
세 칸을 먼저 고정하고 시작한 것은 예비 탐색에서도 그대로 이득이었습니다. 다만 이 세 줄은 예비 탐색의 범위이지 논문의 선정 기준이 아닙니다. 실제 검토의 기준은 이후 별도로 다시 세웠습니다.
어떻게 해 봤는가
1. 근거 모으기 — medical-deep-research
New Research 화면에서 질문 유형을 PICO·PCC·Free-form 중에 고르게 되어 있고, PCC를 골라 위의 세 칸을 그대로 채웠습니다. 같은 화면에서 provider와 model, lookback 기간을 지정하는데, 이 세 값은 성능 설정이라기보다 어떤 검색 환경에서 모았는지를 남기는 기록입니다. 반년 뒤에 결과가 달라 보일 때 무엇이 달라졌는지 짚을 수 있는 자리가 여기입니다.
실행 버튼을 누르면 실행 기록(trace)이 한 줄씩 쌓입니다. 이 기록이 실제로는 감사 추적입니다. 남는 단계 이름을 그대로 옮기면 이렇습니다.
fetch_fulltext→parse_pdf— 원문을 받아 와 본문을 읽을 수 있게 풉니다.screen_studies— 화이트리스트 방식으로 1차 선별을 합니다.appraise_evidence— 선별과 평가를 한 덩어리로 처리하지 않고 체크포인트로 나눕니다.- citation snowballing — Europe PMC의 참고문헌과 OpenAlex를 타고 후보를 넓힌 뒤 다시 선별을 겁니다.
verify_studies— 판정이 아니라 사람이 다시 확인해야 할 목록을 뽑아 줍니다.
기록에는 포함된 논문만 남는 것이 아닙니다. 제외한 논문과 원문을 받아 오지 못한 실패까지 남습니다. 처음에는 실패 기록이 지저분해 보였는데, 검색 비뚤림을 나중에 따질 수 있는 것은 정확히 그 지저분한 줄들 덕분이었습니다.
산출물은 인용이 달린 합성 보고서 한 편입니다. 문장마다 [n] 형태로 출처가 걸리고, Markdown으로 내보내면 인용이 그대로 보존됩니다. 이 보고서를 "논문 목록"이 아니라 주제의 윤곽을 잡는 글감으로 받는 것이 이 단계의 목적이었습니다.
2. 개념으로 세우기 — ResearchWiki
내보낸 Markdown을 ResearchWiki의 corpus로 넘겼습니다. 여기서 처음 만드는 것이 Input Set인데, 이름과 달리 파일을 넣는 화면이 아니라 경계를 정하는 화면입니다. 세 가지를 적습니다.
- 주 질문과 주제 설명 — corpus의 경계
- 관점 메모 — 나중에 모델이 읽는 연구자의 해석 방향. 키워드 목록이 아닙니다.
- seed concept — 그래프가 자라기 시작하는 첫 지점
수집이 시작되면 대시보드가 Total·이번 주·평가완료·평가대기 네 수치와 일별 수집 그래프, 최근 문헌 목록을 보여 줍니다. 저는 이 화면을 진척 표시가 아니라 corpus가 충분한지 확인하는 감사 화면으로 썼습니다.
그다음 나오는 것이 개념 그래프와 개념별 위키입니다. 공유의사결정, decision coaching, OPTION 평가척도 같은 개념이 노드로 뜨고, 개념마다 corpus 전체의 언급을 모은 문서 한 장이 합성됩니다. 그래프에서 실제로 쓸모 있었던 것은 노드가 아니라 연결의 굵기였습니다. 굵은 연결은 이미 함께 다뤄져 온 개념이고, 가는 연결은 아직 덜 엮인 개념입니다. 이 주제를 어느 방향에서 볼 것인지가 이 그림에서 잡혔습니다.
3. 방법과 원고 — ResearchDesk
마지막 단계는 방법과 원고입니다. Methods Workbench는 자격·중재·결과·분석 단계를 결정 카드로 하나씩 채우게 되어 있고, 카드가 채워지는 만큼 Protocol과 SAP, data dictionary, 체크리스트가 컴파일되는 구조입니다. My Articles로 넘기면 컴파일된 방법 산출물이 부록으로 붙고, Readiness는 원고를 원래 프로토콜과 대조해 어긋난 자리를 짚어 줍니다.
무엇이 쓸모 있었는가
질문의 틀을 먼저 고정한 것. PCC 세 칸을 적어 두고 시작하니 탐색 도중에 범위가 흔들리지 않았습니다. 예비 탐색에서도 이 효과는 분명했습니다.
기록이 남은 것. 챗봇에 같은 질문을 했다면 링크와 요약은 받았겠지만, 어디를 어떻게 돌았고 무엇을 왜 뺐는지는 남지 않습니다. 여기서는 제외 사유와 실패한 원문 수집까지 파일로 남았습니다.
개념별 한 장. 논문별 요약을 스무 개 쌓아 두면 주제의 윤곽이 잡히지 않습니다. 같은 개념에 대한 여러 논문의 설명이 한 장으로 모이자 그제야 무엇이 이미 다뤄졌고 무엇이 비어 있는지 보였습니다.
단계마다 사람이 서는 자리가 분명해진 것. 근거를 믿을 만한가, 개념 연결이 맞는가, 방법을 지켰는가. 이 자리들에서 저는 도구의 출력을 받는 사람이 아니라 판정하는 사람이었습니다.
무엇이 안 됐는가
가장 중요한 것부터 적습니다 — 이 탐색의 산출물은 논문의 방법이 되지 못했습니다. 예비 탐색은 주제의 지형을 보는 데는 쓸모가 있었지만, 학술지에 낼 주제범위 문헌고찰의 검색 전략으로 그대로 쓸 수는 없었습니다. 실제 검토의 검색은 별도로 다시 설계했습니다. 도구가 낸 첫 결과를 방법으로 승격시키지 않은 것이 이 사례에서 가장 중요한 결정이었고, 이 코스가 내내 말하는 원칙 그대로입니다 — 도구는 기록을 남기고, 판정은 사람이 합니다.
결과 수치를 내놓지 않습니다. 이 글은 절차 기록입니다. 예비 탐색의 중간 건수를 성과처럼 적는 편이 훨씬 그럴듯해 보였겠지만, 그건 이 코스가 하지 말라고 가르치는 일입니다. 실제 검토의 건수와 결과는 논문에 있습니다.
실행이 느려 강의에서 실시간으로 보여 주지 못했습니다. 검색과 원문 수집, 합성까지 한 번 도는 데 시간이 걸립니다. 워크숍에서는 사전에 찍어 둔 화면으로 대체했습니다. "요청 한 줄이면 끝난다"는 인상을 주는 자리가 있다면 정정해 두겠습니다. 끝나기를 기다려야 하는 도구입니다.
원문을 받아 오지 못한 논문이 있었습니다. 실행 기록에 실패한 수집이 남습니다. 구독 접근이 걸린 논문, PDF 구조가 특이한 논문에서 생깁니다. 이 실패를 확인하지 않고 넘어가면 "다 돌았다"고 착각하게 됩니다. 실제로는 접근할 수 있었던 문헌으로 범위가 조용히 좁혀진 상태입니다.
초안 단계가 가장 덜 여물었습니다. ResearchDesk는 셋 중 가장 나중에 만든 도구라 화면 구성이 계속 바뀌고 있습니다. 워크숍에서도 이 부분만은 실제 화면 대신 자리를 비워 둔 상태로 발표했습니다. 이 사슬을 따라 해 보실 분은 앞의 두 단계에 기대를 걸고 마지막 단계는 여유를 두시는 편이 정확합니다.
다시 한다면
예비 탐색과 본 검토를 처음부터 다른 작업으로 두겠습니다. 이번에도 실제로 그렇게 했지만, 두 작업의 파일과 기록을 처음부터 분리해 두었다면 나중에 "이 숫자가 어느 쪽에서 나온 것인지"를 따지는 일이 없었을 것입니다. 탐색은 방향을 잡는 일이고, 검토는 방법을 지키는 일입니다.
관점 메모는 문장으로 적겠습니다. 키워드가 아니라 "이 주제를 교육 설계의 관점에서 보고, 임상 성과보다 학습자 평가에 무게를 둔다"처럼 방향을 문장으로 적어야 모델이 그 방향으로 읽습니다.
원문 수집 실패 목록을 확인하는 일정을 따로 잡겠습니다. 실행이 끝난 날이 아니라 그다음 날 한 시간을 잡아 두는 편이 낫습니다. 실패 목록과 verify_studies 목록을 같은 시간에 처리하면 확인이 밀리지 않습니다.
도구를 셋 다 쓰지는 않겠습니다. 예비 탐색이 목적이라면 근거 모으기와 개념 세우기까지로 충분했습니다. 초안 단계까지 한 번에 붙이려다 사슬만 길어졌습니다. 처음 시도하시는 분이라면 앞의 두 단계만 돌려 보고, 그 산출물이 실제로 쓸모 있는지 확인한 다음에 다음 단계를 붙이시길 권합니다.
2026-08-18 확인