검토를 돕는 도구는 판정하지 않는다

에이전트와 일하는 프런트엔드 #4 — 검토를 돕는 도구가 판정까지 하면 왜 사람이 같이 틀리는지, 측정된 숫자 두 개로 이야기해 보려고 해요.

3편은 이렇게 끝냈어요. 에이전트에게 구현은 맡길 수 있어도 판정 기준은 맡길 수 없다.

그 글은 에이전트를 쓰는 쪽에서 쓴 거였는데요. 요즘 제가 하는 일은 반대쪽이에요. 사람이 문서를 검토하는 걸 도와주는 시스템을 만들고 있거든요. 그러니까 질문이 이렇게 바뀝니다.

판정을 사람이 해야 한다면, 도구는 도대체 뭘 해야 하나?

답이 "도구가 1차로 판정하고 사람이 확인한다"인 것 같지만, 이 답에는 측정된 반박이 두 개 있어요. 이 글에서는 그 두 결과를 먼저 보고, 거기서 나오는 프런트엔드 설계 원칙 다섯 개를 정리해 볼게요.

AI 교육 20시간으로도 자동화 편향은 안 막혀요

올해 NEJM AI에 실린 무작위 시험이에요. 의사 44명, 전원 AI 리터러시 교육을 20시간 이수한 사람들이었어요. 임상 사례 여섯 개를 진단하게 하면서 한 그룹에는 정상적인 LLM 조언을, 다른 그룹에는 절반의 사례에서 일부러 틀린 조언을 줬습니다.

결과부터 표로 볼게요.

	정상 조언	틀린 조언
진단 추론 점수	84.9%	73.3% (조정 −14.0p)
1순위 진단 정확도	90.5%	76.1% (−18.3%p)

틀린 조언을 받은 쪽이 1순위 진단에서 열 명 중 한 명 넘게 더 틀렸어요. 20시간 교육을 받고도요.

저자들의 결론이 뼈아픕니다. AI 리터러시 교육만으로는 자동화 편향을 막지 못한다. (Qazi et al., NEJM AI 2026)

이게 왜 도구 설계자에게 중요하냐면, 우리가 기본값으로 삼는 안전장치가 보통 이거라서예요. "사람이 최종 확인합니다." "사용자 교육을 하겠습니다." 20시간 교육받은 의사가 저 정도면, 반나절 온보딩 받은 사용자에게 기대할 수 있는 건 없다고 봐야 하죠.

그렇다고 경보를 촘촘히 띄우면 90%가 무시돼요

그럼 경고를 촘촘히 띄우면 되지 않나 싶은데요. 이것도 이미 해봤어요. 처방 시스템의 약물 상호작용(DDI, Drug-Drug Interaction) 경보를 모은 메타분석에서, 처방 57만 건·연구 11편 기준 경보 무시율이 90%였어요. (95% CI 85.6–95.0, Felisberto et al., 2024)

임계값을 조정해도 잘 안 내려갑니다. 사람이 게을러서가 아니라, 하루에 수십 번 울리는 신호는 정보가 아니라 소음이 되기 때문이에요.

두 결과를 겹치면 설계 딜레마가 됩니다

• 도구가 조용히 판정하면 → 자동화 편향. 틀렸을 때 사람이 같이 틀려요.
• 도구가 시끄럽게 판정하면 → 경보 피로. 맞았을 때도 사람이 안 봐요.

중간값을 잘 잡으면 되는 문제처럼 보이는데, 아니에요. 두 실패 모두 "도구가 판정한다"는 전제에서 나옵니다. 전제를 안 건드리면 둘 사이를 오갈 뿐이죠.

그래서 도구의 일은 판정이 아니라 증거예요

여기부터는 규정이 아니라 제 정리입니다.

사람이 검토를 못 하는 이유는 판단력이 부족해서가 아니에요. 판단에 필요한 걸 모으는 비용이 너무 커서죠. 프로토콜 검토를 예로 들면, 판정 자체는 5초면 끝나요. 그 5초에 도달하기까지가 오래 걸립니다 — 이 문장이 어느 버전에서 바뀌었는지, 원 규정 문구가 뭔지, 다른 섹션과 충돌하는지, 지난번엔 어떻게 처리했는지.

도구가 이걸 없애주면 사람의 판정은 빨라지면서 사람의 것으로 남아요. 도구가 대신 판정하면 빨라지지만 위의 두 숫자가 따라오고요.

도구는 "이건 틀렸습니다"라고 말하지 않아요. "여기가 기준 문서의 이 부분과 다릅니다"라고 말하고, 원문을 옆에 띄웁니다. 다른 게 틀린 건지는 사람이 정해요.

프런트엔드에서 이건 이렇게 생겼어요

1. 핵심 화면은 목록이 아니라 대조 화면이에요.
검토 지원 도구를 만들면 십중팔구 "발견 사항 목록"부터 만들게 되는데요. 그게 만들기 쉬우니까요. 그런데 목록은 판정의 결과물이에요. 실제로 사람이 오래 머무는 화면은 좌우 대조입니다. 여기 붙은 문장과 저기 있는 원문. 목록은 대조 화면으로 가는 색인일 뿐이에요.

2. 신뢰도 점수를 숫자로 주지 않아요.
"이 지적의 확신도 87%" 같은 표시는 도움이 될 것 같지만, 자동화 편향을 강화합니다. 숫자가 판정을 대신해버리거든요. 87%를 보고 사람이 할 수 있는 건 믿거나 안 믿거나 둘 중 하나고, 대개 믿죠. 같은 자리에 근거 출처를 넣으면 사람이 할 일이 생겨요 — 열어보는 것.

3. 미리 채워주지 않아요.
자동화 편향의 UI판이 기본값이에요. 폼에 AI가 값을 채워두면 그 값은 검토되지 않습니다. 빈칸으로 두고 옆에 후보를 제시하면, 채우는 행위가 사람의 것이 돼요. 클릭 한 번 차이인데 책임 주체가 바뀝니다.

4. AI가 만든 것과 사람이 만든 것을 끝까지 구분해서 저장해요.
화면에서만 구분하는 걸로는 부족해요. 데이터에 남아야 합니다. 이 값의 출처가 제안인지 입력인지, 사람이 그대로 받았는지 고쳤는지. 2편에서 쓴 감사 추적이 여기서 실물이 돼요. 나중에 "이 판정 누가 했나"를 물었을 때 대답할 수 있는 유일한 방법이거든요.

5. 경보를 줄이는 법은 임계값 조정이 아니에요.
90%가 무시당하는 이유는 경보가 많아서고, 경보가 많은 이유는 도구가 판정을 많이 해서예요. 판정을 안 하면 무시당할 경보도 없죠. 차이를 보여주는 것과 경고하는 것은 다릅니다. 전자는 쌓여도 참고 자료지만 후자는 쌓이면 소음이에요.

물론 이 다섯 개가 모든 경우의 정답은 아닙니다. 사용자가 하루에 수백 건을 처리해야 하는 화면이라면 "전부 사람이 판정한다"는 원칙이 그대로 처리량 문제가 되거든요. 저도 아직 이 지점은 못 풀었어요. 지금은 판정이 아니라 정렬로 버티고 있습니다. 무엇이 틀렸는지는 말하지 않고, 무엇부터 볼지만 순서를 매기는 식으로요.

규제 쪽에서 봐도 같은 결론이 나와요

2편에서 정리한 방향 — 위험에 비례해서, 사람이 책임지는 구조로 — 을 도구 설계 언어로 옮기면 그냥 이거예요. 도구는 중요 판정을 하지 않는다. 판정을 하지 않으면 그 도구는 애초에 높은 위험 등급을 받지 않고, 검증 부담도 그만큼 줄어듭니다.

재밌는 건 이게 규제 회피가 아니라는 점이에요. 판정하지 않는 도구가 실제로 더 낫습니다. 위의 두 결과가 그 얘기를 하고 있어요.

적용해보기

검토를 돕는 화면을 만들고 계신다면, 이런 질문을 던져보면 좋겠어요.

• 이 화면에서 사용자가 가장 오래 머무는 곳이 목록인가요, 대조 화면인가요?
• 우리가 띄우는 경고 중에, 사용자가 실제로 열어보는 비율을 세어본 적이 있나요?
• AI가 채워 넣은 값과 사람이 입력한 값이 데이터에서 구분되나요? 화면에서만 구분되는 건 아닌가요?
• "사람이 최종 확인합니다"를 안전장치로 쓰고 있다면, 그 사람이 틀린 조언을 받았을 때 걸러낸다는 근거가 있나요?

네 편을 관통하는 한 문장

1편은 에이전트가 읽을 저장소를 만드는 얘기였고, 2편은 그렇게 만든 코드의 책임이 누구에게 있는지, 3편은 맞고 틀림의 기준이 어디서 오는지였어요. 4편은 그 기준을 지키는 도구를 어떻게 만드는지였고요.

네 편이 결국 같은 말을 네 번 했습니다.

기계는 자료를 옮기고, 사람은 판정한다. 이 경계를 코드와 화면과 기록에 명시적으로 새겨넣은 만큼만, 에이전트를 안전하게 쓸 수 있어요.

규제 산업이 20년간 문서로 해온 게 이 경계를 적어두는 일이었어요. 지금은 모든 산업이 같은 걸 코드로 적어야 하는 시기가 됐고요. 양식을 이미 갖고 있는 쪽이 유리하다고, 저는 생각합니다.

이 글을 읽으면서 "나라면 이렇게 했을 텐데" 싶은 지점이 있었다면, 그 얘기를 듣고 싶어요. 읽어주셔서 감사합니다.

---

참고 — Qazi IA, Ali A, Khawaja AU, et al., Automation Bias in Large Language Model–Assisted Diagnostic Reasoning among Physicians Trained in AI Literacy: A Randomized Clinical Trial, NEJM AI 2026 (NCT06963957) · Felisberto M, et al., Override rate of drug-drug interaction alerts in clinical decision support systems: a brief systematic review and meta-analysis, Health Informatics Journal, 2024