우리는 ‘신뢰’를 올리는 방법만 고민했고, ‘신뢰가 정당해지도록’ 설계하지 않았다.
Thank you for reading this post, don't forget to subscribe!
한눈에 보기
AI 기반 의사결정지원 시스템(의사결정 지원 시스템, DSS)은 종종 “아직, 현장에서 작동하지 않는다”고 평가된다. 하지만 이 실패의 상당 부분은 모델 성능이 아니라 신뢰 보정(trust calibration) 문제다. 즉, 사용자가 믿는 것(trust)과 시스템이 실제로 해낼 수 있는 것(trustworthiness)이 어긋난다.
이 글의 요지는 단순하다.
- 신뢰는 감정이 아니라 리스크(취약성) 상황에서 예측을 가능하게 하는 장치다.
- 신뢰는 항상 “무엇을 믿는가?”라는 계약(contract)이라는 속성을 숨기고 있다.
- 목표는 “신뢰 증가”가 아니라 정당한 신뢰(warranted trust)와 정당한 불신(warranted distrust)이다.
등장하는 주요 용어
- AI 의사결정지원 / 의사결정 지원 시스템 / DSS(Decision Support System) / AI-DSS
- 계약(contract) / 계약적 신뢰(contractual trust)
- 신뢰(trust) / 신뢰할 만함(trustworthiness)
- 정당한 신뢰(warranted trust) / 부당한 신뢰(unwarranted trust)
- 신뢰 보정(trust calibration) / 미사용(disuse) / 오남용(misuse) / 남용·악용(abuse)
1) “실패”는 어떤 모습으로 나타나는가
현장에서 “AI가 안 된다”는 말은 대개 아래 중 하나다.
- 미사용(disuse): 시스템이 괜찮아도 안 쓴다(무시, 우회, 비활성화).
- 오남용(misuse): 과신해서 따라가다 사고가 난다(자동화 편향, 과잉 의존).
- 남용/악용(abuse): “모델이 그랬다”로 책임 전가, 통제 도구화.
핵심은 이것이다.
이 세 가지는 모두 “모델이 틀렸다, 성능이 모자르다”만으로 설명되지 않는다.
실패의 근원에는 사람과 AI 시스템이 형상하는 관계가 무너진 결과이며, 신뢰 보정 실패가 그 시작점이다.
2) 신뢰는 감정이 아니라 ‘리스크 기반 예측 장치’다
인간에게 신뢰(trust)는 위험이 있을 때만 의미가 있다.
사용자가 AI-DSS를 신뢰한다는 말은 보통 다음 두 조건이 있을 때 성립한다.
- 취약성(vulnerability): 시스템의 결정으로 인해 나쁜 결과가 “가능”하고, 그것이 “바람직하지 않다”.
- 예측(anticipation): 사용자의 목표가 불확실성 속에서 “이 시스템이 의도대로 작동할지”를 예측하는 데 있다.
실무 판별 질문: 사용자가 모델을 무시해도 별 비용이 없다면, 우리는 ‘신뢰’를 평가하는 게 아니라 ‘선호/호감’을 평가하고 있을 가능성이 크다.
3) 모든 신뢰는 ‘계약적’이다: 무엇을 믿는가를 먼저 적어라
사람들은 AI를 막연히 신뢰하지 않는다. 항상 특정한 기대를 신뢰한다.
이 기대를 계약(contract)이라고 부르자.
결정 지원에서 자주 등장하는 계약들
- 정확성 계약: “맥락 X에서 추천이 충분히 맞다.”
- 강건성 계약: “엣지케이스/교란/드리프트에서 무너지지 않는다.”
- 공정성 계약: “집단 Y에게 체계적으로 불리하지 않다.”
- 투명성 계약: “사용자 수준에서 설명 가능하다.”
- 프라이버시 계약: “민감 속성이 노출/역추정되지 않는다.”
- 책임성 계약: “감사·이의제기·구제가 가능하다.”
가장 흔한 실패 메커니즘
사용자는 개발자가 말하지 않은 계약을 암묵적으로 가정한다. 그래서 첫 번째 처방은 단순하지만 강력하다.
지킬 계약을 명시하고, 지키지 못하는 경계(조건/예외)를 동시에 명시하라.
4) 신뢰(trust)와 신뢰할 만함(trustworthiness)을 분리하라
두 개는 다르다.
- 신뢰(trust): 사용자 태도(취약성 수용)
- 신뢰할 만함(trustworthiness): 시스템이 특정 계약을 실제로 지킬 수 있는 능력
세련된 UI는 신뢰를 올릴 수 있지만 능력을 보장하지 않는다.
반대로 좋은 모델도 신뢰를 못 얻으면 미사용이 된다.
AI-DSS가 실패하는 이유는 이 둘을 섞어 “신뢰를 올리자”만 남기는 순간부터 시작된다.
5) 정당한 신뢰 vs 부당한 신뢰
‘신뢰가 높다’는 말이 곧 좋은 게 아니다.
- 정당한 신뢰(warranted): 신뢰가 ‘능력(신뢰할 만함)’에서 인과적으로 발생
- 부당한 신뢰(unwarranted): UI/권위/설명 톤 등 능력과 비인과적 요인에서 발생
부당한 신뢰는 특히 오남용(misuse)를 키운다.
가장 간단한 진단(개입 테스트)
모델의 실제 능력을 낮췄는데도 사용자 신뢰가 거의 그대로라면, 우리는 신뢰를 설계한 게 아니라 “연출”했을 가능성이 크다.
6) 미니 사례로 보는 ‘계약·취약성·오남용’
사례 A — 대출 심사 추천(신용 리스크)
- 사용자: 심사역
- 취약성: 연체·규제 위반·차별 이슈·평판 손실
- 오남용 시나리오: “기업용 UI” + “확신형 문구”가 능력과 무관하게 신뢰를 올려 OOD(낯선 분포) 신청자에서 사고
설계 포인트: 정확성 계약만이 아니라 공정성·드리프트 탐지·유보(abstain)·인간 개입 정책까지 계약으로 명시.
사례 B — 임상 트리아지 제안
- 사용자: 의료진
- 취약성: 환자 피해·법적 책임
- 오남용 시나리오: 그럴듯한 설명이 “충실한 설명”이 아니어도 설득력으로 신뢰를 올려 과신
설계 포인트: 설명은 “신뢰 증폭기”가 아니라 “보정기(언제 의존/언제 의심)”로 설계.
7) 정당한 신뢰는 어떻게 만들어지는가: 내재 vs 외재 경로
정당한 신뢰는 보통 두 경로 중 하나(혹은 둘 다)를 통해 생긴다.
7.1 내재적 신뢰(intrinsic)
사용자가 모델의 추론 과정(또는 그에 충실한 신호)을 이해하고, 그 과정이 사용자의 priors(전문 규범/지식/기대)와 정합할 때 생긴다.
- 제약: 사용자가 ‘좋은 priors’를 갖고 있지 않으면, 설명을 많이 줘도 내재적 신뢰는 잘 생기지 않는다.
7.2 외재적 신뢰(extrinsic)
사용자가 추론을 이해하지 못해도, 평가 체계(검증/감사/운영 실적)가 믿을 만하면 생긴다.
- 주의: 외재 신뢰는 결국 “평가를 믿는다”이므로, 평가가 운영 분포를 대표하지 못하면 신뢰는 잘못 보정된다.
8) 무엇을 할 것인가: 신뢰를 ‘기능’으로 다시 설계하기(실행 순서)
여기서부터가 핵심이다. “신뢰 증가”가 아니라 “정당한 신뢰/불신 보정”을 설계한다.
Step 1 — 계약을 문장으로 작성(5–10줄)
템플릿:
“맥락 [C]에서, 이 시스템은 이해관계자 [S]에게 [계약]을 [경계/허용오차] 내에서 유지한다.”
예:
- “운영 분포가 훈련 분포와 유사할 때만 추천을 제공하고, 유사도 임계치 미만이면 유보한다.”
- “집단 간 오류율 차이가 기준치를 넘으면 경고하고, 특정 결정은 인간 승인으로 게이트한다.”
Step 2 — 취약성 시트 작성(5줄)
- 이해관계자
- 손해 사건(undesirable events)
- 의존 지점(어디서 DSS에 기대는가)
- 되돌림(이의제기/롤백/대체 경로)
- 책임 경로(누가 무엇을 책임지는가)
Step 3 — 신뢰/능력 분리표 작성
- 계약별 “능력 증거(평가/감사/모니터링)” vs “알려진 한계(비목표/취약 구간)”를 분리 기록
Step 4 — 부당한 신뢰를 줄이는 UX 원칙
- 확신형 표현(“확실합니다”) 최소화
- “경계/제약/유보 조건”을 UI의 1급 정보로 승격
- 설명은 설득이 아니라 “의존/의심” 판단을 돕는 형식으로
Step 5 — 보정 장치 3종(의존/의심/폴백)
- 언제 의존할지: 분포 적합, 계약 지표 충족, 근거 충분
- 언제 의심할지: 드리프트 신호, 입력 결손, 하위집단 불명, 유사도 낮음
- 폴백: 인간 개입, 2차 모델, 정책 기반 유보/에스컬레이션
9) 신뢰를 어떻게 평가할 것인가(사용성 말고 정당성)
혹시 말해 붙이지만, 단순히 설문(“AI 신뢰합니까?”)만으로는 정당성을 알 수 없다.
최소 프로토콜(개입 기반 정당성 테스트)
- 신뢰 행동을 측정(의존률/오버라이드율/결정시간/회복 행동 등)
- 실제 신뢰할 만함을 조작(성능 저하/개선/오라클 대체)
- 조작 후 신뢰를 재측정
- 능력 변화에 따라 신뢰도 변하면: 보정이 존재(정당성 가능성↑)
- 변하지 않으면: UI/권위 기반 신뢰 위험(부당 신뢰 가능성↑)
10) XAI의 위치: 신뢰 “증가”가 아니라 신뢰 “보정”
설명가능성(XAI)을 “신뢰를 올리는 기술”로 두면 위험하다.
XAI의 역할은 계약에 대해:
- 신뢰할 만한 시스템에는 정당한 신뢰를,
- 신뢰할 만하지 않은 시스템에는 정당한 불신을
형성하도록 돕는 것이다.
그리고 계약마다 필요한 설명은 다르다(정확성/공정성/프라이버시/책임성은 같은 설명으로 해결되지 않는다).
툴킷(복붙용)
A) 계약 목록(최소 5개)
- 정확성 / 강건성 / 공정성 / 투명성 / 책임성
B) 취약성 시트(5줄)
- 이해관계자 / 손해 사건 / 의존 지점 / 되돌림 / 책임 경로
C) 정당성 테스트(3단계)
- 측정 → 능력 조작 → 재측정
D) 의존/의심 체크리스트
- 의존: 분포 적합 + 계약 지표 충족 + 근거 충분
- 의심: 드리프트/결손/하위집단 불명/유사도 낮음
- 폴백: 인간 개입/2차 확인/유보-에스컬레이션
FAQ(묻고 답하기)
Q1. 정확도가 높은데도 DSS가 실패하는 이유는?
정확성 계약만 충족해도 사용자가 가정한 다른 계약(공정성/책임/강건성)이 깨지거나, 신뢰가 부당하게 형성되어 오남용·미사용이 발생할 수 있다.
Q2. 정당한 신뢰란?
신뢰가 시스템의 실제 능력(신뢰할 만함)에서 인과적으로 발생한 상태다.
Q3. UI 과신(부당한 신뢰)을 줄이려면?
UI/설명은 설득이 아니라 “경계·제약·유보 조건”과 “의존/의심 판단”을 돕도록 설계하고, 개입 기반 테스트로 검증한다.
Q4. 신뢰 보정이란?
사용자 신뢰 행동이 시스템 능력과 정렬되는 상태(과신도 불신도 아닌 적정 상태)다.
용어집
- 의사결정 지원 시스템(DSS): 인간 의사결정을 돕는 추천/정보 제공 시스템
- AI 의사결정지원(AI-DSS): 추천이 ML/AI 모델에서 나오는 DSS
- 계약적 신뢰(contractual trust): 특정 계약을 지킬 것이라는 신뢰
- 취약성(vulnerability): 시스템 결정에 의해 손해를 볼 수 있는 리스크 노출
- 신뢰할 만함(trustworthiness): 계약을 유지할 수 있는 실제 능력
- 정당한 신뢰(warranted trust): 신뢰가 능력에서 인과적으로 발생한 상태
- 부당한 신뢰(unwarranted trust): UI/권위 등 비인과 신호로 생긴 신뢰
- 신뢰 보정(trust calibration): 신뢰와 능력의 정렬
마무리
AI 의사결정지원이 실패하는 이유는 “모델이 나빠서”만이 아니다.
우리가 신뢰를 설계하지 않았기 때문이다.
이제 질문을 바꿔야 한다.
- “신뢰를 어떻게 올릴까?”가 아니라,
- “어떤 계약이 중요한가, 취약성은 무엇인가, 신뢰를 어떻게 정당하게 만들고 유지할 것인가?”
이 전환이 채택과 안전을 동시에 가능하게 한다.
(이 글은 한국어 버전 발행 글이며, 영문 버전은 이곳에 발행 되었습니다: augmentedtechnology.substack.com)
이 글은 아래 의사결정 연구 논문을 기반으로 작성 되었으며 ,
”Formalizing Trust in Artificial Intelligence: Prerequisites, Causes and Goals of Human Trust in AI“
이 글을 작성하는 과정에는 LLM 기반 업무도구인 VibeWorkPlace(LLM Applications) 활용 했습니다.
해경에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.