투명성과 설명가능성
"설명은 모델의 속성이 아니라, 특정 수신자가 특정 목적을 달성하게 하는 관계다"
🎯 이 단계의 학습 목적
- 왜 배우는가: "블랙박스라서 문제다"는 진단은 정확하지 않습니다. 문제는 불투명성 자체가 아니라 이의제기·감사·개선에 필요한 정보가 없다는 것입니다. 이 구분을 못 하면 쓸모없는 설명을 대량 생산하게 됩니다.
- 배워서 얻는 것: ① 투명성·해석가능성·설명가능성·추적가능성의 정확한 구분 ② LIME·SHAP·반사실적 설명의 원리와 구체적 실패 모드 ③ 모델 카드/데이터시트 작성 실무 ④ GDPR 22조와 EU AI Act의 실제 요구 수준 ⑤ LLM 사고사슬이 왜 설명으로 신뢰되기 어려운가
1. 핵심 학습 주제 (심화 강의)
| 핵심 주제 | 구체적으로 묻는 질문 | 이 Phase에서 얻는 핵심 답 |
|---|---|---|
| 개념 구분 | 투명성, 해석가능성, 설명가능성, 추적가능성은 같은 말인가? | 투명성은 시스템 정보를 공개하는 범위, 해석가능성은 작동 원리를 사람이 이해하는 정도, 설명가능성은 특정 결과의 이유를 전달하는 능력, 추적가능성은 결정의 기록을 재구성하는 능력입니다. 수신자와 목적에 따라 필요한 조합이 달라집니다. |
| XAI 기법 | LIME·SHAP·반사실 설명은 실제 모델의 이유를 보여주는가? | 대부분은 모델 내부를 그대로 읽는 것이 아니라 입력 변화와 출력의 관계를 근사합니다. 설명의 보기 좋은 정도가 아니라 충실성·안정성·범위·행동 가능성을 검증해야 합니다. |
| 문서화 | 개별 예측 설명만으로 조직의 책임을 검증할 수 있는가? | 모델 카드·데이터시트·시스템 카드는 용도, 데이터 출처, 집단별 성능, 한계, 금지 용도, 담당자를 남깁니다. 문서화는 한 번의 설명보다 생애주기 전체의 책임 추적에 강합니다. |
| 법적 설명 의무 | 자동화된 결정을 받은 사람에게 항상 설명받을 권리가 있는가? | 관할과 결정의 중대성에 따라 다르며, 단일한 보편적 "설명권"으로 단순화하면 안 됩니다. 실무에서는 법적 최소선보다 넓게 결정 통지·주요 요인·이의제기·인간 재검토를 함께 설계합니다. |
| LLM 투명성 | 모델이 말한 사고과정은 믿을 만한 설명인가? | 자연어 사고과정은 그럴듯한 사후 합리화일 수 있으며 내부 계산의 충실한 기록으로 보장되지 않습니다. 출처, 도구 호출, 검색 문서, 버전, 프롬프트, 평가 결과처럼 검증 가능한 시스템 증거가 더 중요합니다. |
📕 3-1. 개념 정리 — 네 단어를 구분하지 못하면 논의가 무너진다
| 용어 | 정의 | 대상 | 확인 방법 |
|---|---|---|---|
| 투명성 Transparency | 시스템의 존재·목적·데이터·성능·한계가 공개되어 있는가 | 시스템 전체(조직 행위) | 문서 존재 여부, 공개 범위 |
| 해석가능성 Interpretability | 모델의 내부 작동을 인간이 직접 이해할 수 있는가 | 모델 구조 | 선형회귀·짧은 결정트리 = 높음, 심층망 = 낮음 |
| 설명가능성 Explainability | 특정 출력이 왜 나왔는지 사후에 근거를 제시할 수 있는가 | 개별 결정 | LIME/SHAP/반사실 등 사후 기법 |
| 추적가능성 Traceability | 어떤 데이터·코드·버전·승인으로 이 결정이 만들어졌는지 재구성할 수 있는가 | 운영 기록 | 로그, 모델 레지스트리, 감사 추적 |
실무에서 가장 저평가된 항목은 추적가능성입니다. 사고 조사에서 실제로 필요한 것은 "이 신경망이 어떻게 생각했나"가 아니라 "2월 3일 14시에 어떤 모델 버전이 어떤 입력에 어떤 출력을 냈고 누가 승인했나"입니다. EU AI Act가 고위험 시스템에 자동 로그 기록을 요구하는 이유가 여기 있습니다.
① 설명의 수신자별 요구 — 하나의 설명은 존재하지 않는다
| 수신자 | 목적 | 필요한 설명 형태 | 실패 사례 |
|---|---|---|---|
| 영향받는 개인 | 이의제기, 행동 변경 | 반사실적 — "소득이 300만원 더 높았다면 승인되었습니다" | SHAP 값 막대그래프 제공 (해석 불가) |
| 현장 운영자 | 이 건을 신뢰할지 판단 | 불확실성 + 유사 사례 + 주요 근거 요약 | 단일 점수만 표시 → 자동화 편향 |
| 개발자 | 디버깅, 성능 개선 | 특징 기여도, 오류 사례 군집, 데이터 슬라이스 성능 | 전역 평균 중요도만 확인 |
| 감사인·규제기관 | 준수 여부 검증 | 문서·로그·평가 프로토콜·재현 가능성 | 사후 설명 시각화 제출 (검증 불가) |
| 경영진 | 위험 판단 | 실패 모드, 최악의 경우, 잔여 위험 | 정확도 단일 숫자 |
핵심 명제: 설명의 품질은 수신자가 그 설명으로 목적을 달성했는지로만 평가할 수 있습니다. 따라서 XAI 평가에는 사람 대상 실험이 필요하며, "그럴듯해 보임"은 평가가 아닙니다.
② 설명이 해로운 경우 — 세 가지
- 과잉 신뢰 유발: 설명이 붙으면 사람은 틀린 예측도 더 잘 받아들입니다. 여러 실험에서 설명의 존재 자체가 신뢰를 높이되 정확도 판별 능력은 높이지 않는 결과가 보고되었습니다. 경험적 연구
- 게이밍 경로 제공: 대출 심사·부정 탐지에서 상세 설명은 조작 방법을 알려줍니다. 반사실적 설명이 특히 취약합니다.
- 정당화 도구화: 설명이 결정을 개선하는 대신 방어하는 데 쓰이면 책임성을 오히려 약화시킵니다 — "설명했으니 됐다"는 형식적 준수.
📗 3-2. XAI 기법 지도와 각각의 실패 모드
① 큰 분기: 내재적 해석가능 모델 vs 사후 설명
선형/로지스틱 회귀, 짧은 결정트리, GAM(일반화 가법 모델), 규칙 리스트, 점수표(scorecard). 모델 자체가 설명이므로 설명과 실제 계산이 일치합니다.
복잡한 모델을 학습한 뒤 별도 기법으로 근사 설명 생성. LIME, SHAP, 그래디언트 기반 saliency, 반사실 생성. 설명이 실제 계산과 다를 수 있습니다.
진행 중 논쟁 Rudin(2019)은 고위험 결정에는 사후 설명을 쓰지 말고 처음부터 해석가능한 모델을 쓰라고 주장합니다. 근거: ㉠ 정형 데이터에서 성능 차이가 작은 경우가 많고 ㉡ 사후 설명은 정의상 근사이므로 틀릴 수 있는데 검증할 방법이 없다는 것. 반론은 이미지·언어·유전체처럼 성능 격차가 큰 영역이 존재한다는 점입니다. 시험에서는 영역 의존적이라는 조건부 답이 정답입니다.
② 주요 기법 정밀 비교
| 기법 | 작동 원리(한 문장) | 산출물 | 대표적 실패 모드 |
|---|---|---|---|
| LIME | 설명할 지점 주변에 교란된 샘플을 만들어 국소 선형 모델을 적합 | 국소 특징 가중치 | 교란 분포·커널 폭에 따라 결과가 크게 흔들림(불안정성). 같은 입력에 두 번 돌리면 다른 설명이 나올 수 있음 |
| SHAP | 협력게임의 섀플리 값으로 각 특징의 기여를 공리적으로 배분 | 전역·국소 기여도 | ㉠ 특징 간 상관이 강하면 비현실적 조합을 평가해 기여도가 왜곡 ㉡ 계산 비용 ㉢ 기여도는 인과가 아니라 연관 |
| Saliency / Grad-CAM | 출력에 대한 입력의 기울기로 중요 영역 시각화 | 히트맵 | 일부 기법은 모델 가중치를 무작위화해도 비슷한 히트맵을 냄(위생 검사 실패) |
| 반사실적 설명 Counterfactual | 결정이 뒤집히는 가장 가까운 입력을 탐색 | "X를 Y로 바꾸면 결과가 달라짐" | ㉠ 실행 불가능한 제안(나이를 낮춰라) ㉡ 다중 반사실 중 무엇을 보여줄지의 자의성 ㉢ 게이밍 유도 |
| 개념 기반(TCAV 등) | 사람이 정의한 개념이 예측에 미치는 영향 측정 | 개념 민감도 점수 | 개념 예시 집합의 품질에 전적으로 의존 |
| 예시 기반 (영향 함수, 프로토타입) | 이 예측에 가장 영향을 준 학습 데이터를 제시 | 유사·영향 사례 | 대규모 모델에서 근사 오차 큼, 프라이버시 노출 위험 |
③ 설명의 품질을 판단하는 4가지 축
- 충실성(Faithfulness): 설명이 모델의 실제 계산을 반영하는가. 검증법 — 설명이 지목한 특징을 제거했을 때 예측이 실제로 변하는지 측정
- 안정성(Stability): 유사 입력에 유사 설명이 나오는가. 검증법 — 미세 교란 후 설명 거리 측정
- 이해가능성(Comprehensibility): 대상 수신자가 실제로 이해하는가. 검증법 — 사람 대상 과제 성공률
- 실행가능성(Actionability): 수신자가 그 설명으로 할 수 있는 행동이 있는가. 반사실적 설명이 강한 축
실무 권장 조합: 영향받는 개인에게는 실행 가능한 반사실(변경 가능한 특징만 사용, 실현 가능성 제약 부여) + 이의제기 경로. 개발·감사용으로는 SHAP 전역 분석 + 데이터 슬라이스별 성능표. 두 용도를 하나의 산출물로 합치려는 시도가 대부분 실패의 원인입니다.
📘 3-3. 문서화 산출물 — 설명보다 강력한 투명성 도구
실무에서 책임성을 실제로 높인 것은 정교한 XAI 시각화가 아니라 표준화된 문서였습니다. 문서는 감사 가능하고, 비교 가능하며, 조직의 기억이 됩니다.
① 모델 카드 (Model Cards, Mitchell et al. 2019)
- 모델 세부: 개발 주체, 버전, 날짜, 아키텍처, 라이선스
- 의도된 용도: 주 사용처, 주 사용자, 범위 밖 사용(out-of-scope) — 이 항목이 가장 중요합니다
- 요인(Factors): 인구집단·환경·기기 등 성능에 영향을 주는 조건
- 지표: 사용한 지표와 선택 이유, 결정 임계값
- 평가 데이터: 출처·구성·전처리 — 학습 데이터와 분리 기재
- 분해 성능: 위 요인별 세분화된 성능과 불확실성 (핵심 항목)
- 윤리적 고려·한계·권고: 알려진 실패 모드와 완화 조치
② 데이터시트 (Datasheets for Datasets, Gebru et al. 2018)
데이터셋의 생애주기 질문지입니다: 동기(왜 만들었나) → 구성(무엇이 들어있나, 결측·민감정보) → 수집 과정(누가, 어떻게, 동의는) → 전처리·정제 → 사용(기존 사용처, 부적절한 사용) → 배포 → 유지관리.
왜 강력한가: "수집 과정" 항목을 정직하게 채우려면 동의·보상·라벨러 근로조건을 기록해야 합니다. 많은 조직이 이 문항에서 처음으로 자기 데이터의 출처를 모른다는 사실을 발견합니다. 문서화는 그 자체로 진단 도구입니다.
③ 시스템 카드 · 투명성 노트 · 사용 정책
- 시스템 카드: 모델 하나가 아니라 여러 모델·규칙·인간 절차가 결합된 제품 전체를 기술. 실제 위험은 결합 지점에서 발생하므로 실무 가치가 큽니다.
- 기반모델 투명성: 학습 데이터 출처, 컴퓨트, 노동 조건, 다운스트림 정책까지 포괄하는 평가 프레임이 등장했습니다(Foundation Model Transparency Index).
- EU AI Act 연계: 고위험 시스템의 기술 문서(Annex IV)와 GPAI 모델의 학습 데이터 요약 공개 의무가 이 계보의 법제화입니다 → Phase 6.
④ 좋은 문서와 나쁜 문서 구별법
| 항목 | 나쁜 문서 | 좋은 문서 |
|---|---|---|
| 성능 | "정확도 94%" | 집단·환경별 분해 성능 + 신뢰구간 + 평가 데이터 구성 |
| 용도 | "다양한 용도에 활용 가능" | 범위 밖 사용을 명시적으로 열거하고 이유 기술 |
| 한계 | "완벽하지 않을 수 있음" | 재현 가능한 실패 사례와 발생 조건 기술 |
| 데이터 | "공개 데이터 사용" | 출처·라이선스·수집 시점·동의 근거·정제 규칙 |
| 갱신 | 날짜 없음 | 버전·변경 이력·재평가 주기·폐기 조건 |
📙 3-4. 법적 요구 — '설명 요구권'은 존재하는가
① GDPR의 구조
| 조항 | 내용 | 실무적 의미 |
|---|---|---|
| 제22조 | 법적 효과 또는 이에 준하는 중대한 영향을 미치는 전적으로 자동화된 결정에 종속되지 않을 권리 | 원칙적 금지 + 예외(계약 이행, 명시적 동의, 법률 근거). 예외 시에도 인간 개입 요구·의견 표명·이의제기 권리 보장 |
| 제13~15조 | 자동화된 결정이 있을 경우 관련 논리(logic involved) 및 중요성·예상 결과에 관한 의미 있는 정보 제공 | 알고리즘 전체 공개가 아니라 이해 가능한 논리 설명 |
| 전문(Recital) 71 | 결정에 대한 설명을 받을 권리 언급 | 전문은 법적 구속력이 없음 — 이 지점이 논쟁의 핵심 |
진행 중 논쟁 Wachter et al.(2017)은 GDPR 본문이 보장하는 것은 사전적 시스템 설명일 뿐 개별 결정에 대한 사후 설명 요구권은 아니라고 주장했습니다. Selbst & Powles는 13~15조의 "의미 있는 정보"를 목적론적으로 해석하면 실질적 설명 의무가 도출된다고 반박했습니다. 이후 EU 사법재판소는 자동화 결정 관련 사건에서 절차와 원리를 이해할 수 있는 수준의 설명이 필요하다는 취지의 판단을 내려 왔습니다. 실무 결론: 영업비밀을 이유로 아무 설명도 하지 않는 것은 방어되지 않는다.
② 위험 비례 설명 의무 (risk-proportionate explanation)
모든 시스템에 같은 설명을 요구하는 것은 비효율적이고 실현 불가능합니다. 성숙한 접근은 위험 수준에 따라 설명의 깊이를 차등화하는 것입니다.
| 위험 수준 | 예시 | 최소 요구 |
|---|---|---|
| 낮음 | 상품 추천, 자동 완성 | AI 사용 사실 고지, 끄기 옵션 |
| 중간 | 스팸 분류, 콘텐츠 순위 | + 일반 논리 설명, 신고·정정 경로 |
| 높음 | 대출·채용·보험·교육 배정 | + 개별 반사실적 설명, 인간 재심사, 로그 보존 |
| 매우 높음 | 의료 진단, 형사사법, 아동보호 | + 내재적 해석가능 모델 우선 검토, 외부 감사, 사전 승인, 사후 성능 모니터링 공개 |
③ EU AI Act의 투명성 3층
- 고위험 시스템: 기술 문서, 자동 로그 기록, 배포자용 사용 지침, 인간 감독 설계 (제9~15조 계열)
- 특정 시스템의 고지 의무: 사람과 상호작용하는 AI, 감정 인식, 생체 분류, 딥페이크 콘텐츠는 사용 사실·인공 생성 사실을 알려야 함
- 범용 AI(GPAI): 기술 문서, 저작권 정책, 학습 데이터 충분히 상세한 요약 공개. 시스템적 위험 모델은 추가 평가·사고 보고 의무
한국: 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(AI 기본법)이 고영향 AI에 대한 고지·설명·이용자 보호 의무를 규정하고 있으며, 개인정보보호법 제37조의2는 자동화된 결정에 대한 거부·설명 요구권을 명문화했습니다. 시행 시기와 하위 고시는 반드시 원문으로 확인하세요 → Phase 6.
📕 3-5. LLM 시대의 설명 — 사고사슬은 설명이 아니다
① 그럴듯함과 충실함의 분리
언어모델은 요청하면 언제나 유창한 이유를 생성합니다. 문제는 그 이유가 실제 계산 경로를 반영한다는 보장이 없다는 것입니다. 이를 불충실한 설명(unfaithful explanation)이라 합니다.
경험적 연구 여러 연구에서 프롬프트에 편향 신호를 주입하면(예: 정답 위치를 특정 보기로 편중) 모델의 답이 바뀌지만, 생성된 사고사슬은 그 편향을 전혀 언급하지 않고 다른 이유를 만들어 냅니다. 즉 사고사슬은 결정의 사후 합리화일 수 있습니다.
실무 함의: "모델이 이유를 설명하니 투명하다"는 주장은 성립하지 않습니다. 사고사슬은 ㉠ 성능 향상 기법으로는 유효하고 ㉡ 사용자 이해를 돕는 인터페이스로는 가치가 있으나 ㉢ 감사 증거로 쓰기에는 부적합합니다.
② LLM 시스템에서 실제로 가능한 투명성
RAG에서 인용된 원문 구절을 함께 제시. 검증 가능한 근거이므로 사고사슬보다 훨씬 강한 투명성입니다.
보정된 신뢰도, 거절(abstention) 옵션, "확인 필요" 표시. 과잉 신뢰를 직접 줄입니다.
시스템 프롬프트 정책, 안전 필터의 존재, 데이터 보존 정책, 사용 제한. 모델 내부보다 운영 규칙의 공개가 실질적입니다.
희소 오토인코더 등으로 내부 특징을 식별하려는 연구. 유망하지만 아직 운영 감사 도구로는 미성숙합니다. 진행 중 연구
③ 생성 AI의 투명성 체크리스트 (실무)
- 사용자가 AI와 대화 중임을 명확히 알 수 있는가 (인간 사칭 금지)
- 모델·버전·지식 시점이 공개되는가
- 사실 주장에 출처가 붙는가, 출처 없는 주장은 표시되는가
- 거절·불확실 응답이 가능하며 그 조건이 문서화되었는가
- 입력이 학습에 사용되는지, 보존 기간은 얼마인지 고지되는가
- 생성물에 출처 메타데이터/워터마크가 부착되는가 (Phase 6의 C2PA)
- 오류 신고와 정정 반영 경로가 있는가
2. 필독 문헌
- 📖 Interpretable Machine Learning — Molnar (온라인 무료). 기법별 원리와 한계의 표준 참고서
- 📄 Model Cards (2019) · Datasheets (2018) — 직접 하나씩 작성해 보는 것이 학습 효과가 가장 큼
- 📄 Rudin (2019) — 고위험 영역에서 사후 설명을 쓰지 말라는 강한 주장. 반론과 함께 읽을 것
- 📄 Wachter et al. (2018), Counterfactual Explanations without Opening the Black Box — 반사실적 설명의 법적·기술적 정식화
3. 추천 영상
내재적 해석가능 모델 진영의 대표 강연. 이 단계 필수 시청
협력게임 이론에서 특징 기여도로 이어지는 논리를 그림으로 이해
"인간의 개념으로 모델을 심문한다"는 접근
LLM 내부 특징을 식별하려는 최신 연구 흐름
법률 실무자 관점의 정리
4. 주차별 실행 계획
- ✅ 1~2일차: 네 용어(투명성·해석가능성·설명가능성·추적가능성)를 사례와 함께 구분해 정리. 수신자별 설명 요구 표를 스스로 재작성
- ✅ 3일차: 공개 데이터셋으로 SHAP·LIME을 직접 실행하고, 같은 입력에 두 번 실행해 설명이 얼마나 흔들리는지 확인
- ✅ 4일차: 본인이 아는 모델 하나로 모델 카드 전체를 작성. "범위 밖 사용"과 "분해 성능"을 반드시 채울 것
- ✅ 5일차: GDPR 22·15조와 EU AI Act 투명성 조항 원문 대조 → 위험 비례 설명 표를 본인 도메인에 맞게 수정
- ✅ 6~7일차: 서술형 과제 → 퀴즈 응시
5. 실전 과제: 모델 카드 + 설명 설계서
[모델 카드] 보험 청구 자동심사 v1.4 (2026-03 릴리스)
1. 모델 세부 XGBoost 분류기 / 학습 2025-01~2025-12 / 담당 리스크모델링팀 / 내부 전용
2. 의도된 용도 소액 청구(300만원 이하)의 '즉시승인 후보' 선별
범위 밖 사용 ✗ 최종 거절 결정 ✗ 300만원 초과 청구 ✗ 사기 조사 근거
✗ 타 보험사 데이터로의 이식 → 각 항목의 금지 사유를 1줄씩 기재
3. 요인 연령대, 지역, 가입 경로(설계사/온라인), 청구 유형
4. 지표 주지표: 집단별 TPR(승인 누락률) / 임계값 0.62 / 선택 근거: 정당한 청구의
부당 지연이 회복 불가능한 피해 → 분리 계열 채택. 보정은 모니터링만.
5. 평가 데이터 2025-10~12 홀드아웃 18,300건 (학습과 시간 분리) / 라벨: 최종 심사 결과
6. 분해 성능 전체 AUC 0.89
온라인 가입 60대 이상: TPR 0.71 [0.66,0.76] ← 최저 구간, 경고
설계사 가입 30대 : TPR 0.93 [0.92,0.94]
7. 한계 · 신규 상품(2026-01 출시) 데이터 없음 → 해당 상품 자동심사 제외
· 재해 급증기 분포 이동에 취약(2025-07 폭우 시 오류율 2.1배)
8. 윤리적 고려 자동화 편향 우려 → 심사자 UI에 '불확실 구간' 표시 및 뒤집기 사유 필수 입력
[설명 설계서] 수신자별 산출물
· 청구인 : 반사실 1개(변경 가능 항목 한정) + 이의제기 링크 + 담당자 연락처
예) "진단서에 상병코드가 기재되면 즉시 승인 대상이 됩니다"
· 심사자 : 상위 근거 3개 + 신뢰도 구간 + 유사 과거 사례 5건 + 뒤집기 버튼
· 감사인 : 월간 분해 성능표, 임계값 변경 이력, 뒤집기 비율/사유 집계, 재현 스크립트
· 규제기관 : 기술문서(Annex IV 대응), 자동 로그 12개월 보존, 사고 보고 절차
[검증 계획]
충실성 : 상위 근거 3개 제거 시 예측 변화량 측정(목표 ΔP ≥ 0.15)
안정성 : 입력 1% 교란 100회 반복, 상위 근거 집합 일치율 ≥ 80%
이해도 : 심사자 20명 대상 과제 실험 — 설명 유무에 따른 '오류 예측 판별 정확도' 비교
(설명이 신뢰만 높이고 판별력을 못 높이면 설계 실패로 간주)
6. 서술형 과제
Q1. (600자 이상) "우리 시스템은 SHAP 값을 제공하므로 GDPR의 설명 요구를 충족합니다"라는 주장을 평가하시오. 기술적 한계와 법적 요구 수준을 모두 다룰 것.
모범 답안 개요 보기
기술적 문제: ㉠ SHAP 기여도는 연관이지 인과가 아니며, 특징 간 상관이 강하면 비현실적 조합을 평가해 값이 왜곡된다. ㉡ 기여도 막대그래프는 정보주체가 무엇을 해야 하는지 알려주지 않는다(실행가능성 부재). ㉢ 사후 설명은 근사이며 충실성이 별도 검증되지 않으면 모델의 실제 계산과 다를 수 있다.
법적 문제: GDPR 13~15조는 "관련 논리에 관한 의미 있는 정보"를 요구한다. '의미 있는'의 판단 기준은 정보주체가 이해하고 제22조가 보장하는 이의제기·의견 표명 권리를 실질적으로 행사할 수 있는지다. 전문가용 수치는 이 기준을 충족하기 어렵다. 또 제22조는 설명만이 아니라 인간 개입 요구권을 포함하므로, 설명 제공만으로는 준수가 완결되지 않는다.
대안 제시(가점): 정보주체에게는 실행 가능한 반사실적 설명 + 이의제기 절차 + 인간 재심사 경로를, 감사인에게는 SHAP 전역 분석과 분해 성능표를, 개발자에게는 슬라이스 성능을 각각 제공하는 수신자 분리 설계. 아울러 고위험이라면 내재적 해석가능 모델 검토가 선행되어야 한다는 Rudin의 논변을 언급.
Q2. (400자 이상) LLM이 생성한 사고사슬(chain-of-thought)을 규제 감사 증거로 제출하는 것이 왜 부적절한지 설명하고, 대신 무엇을 제출해야 하는지 3가지를 제시하시오.
모범 답안 개요 보기
부적절한 이유: 사고사슬은 충실성이 보장되지 않는다. 프롬프트에 주입된 편향이 답을 바꿔도 설명에는 그 편향이 등장하지 않는다는 실험 결과가 있으며, 이는 설명이 사후 합리화일 수 있음을 뜻한다. 또한 동일 입력에도 샘플링에 따라 다른 설명이 생성되어 재현성이 없고, 사슬 자체를 조작·유도할 수 있어 증거로서 무결성이 약하다.
대신 제출할 것: ① 추적 로그 — 모델 버전, 시스템 프롬프트 버전, 입력·출력 해시, 타임스탬프, 승인자 ② 검증된 근거 — RAG 인용 원문과 문서 ID(사실 주장의 출처 확인 가능) ③ 평가 프로토콜과 결과 — 사전 등록된 테스트 세트, 레드팀 결과, 거절률·오류율 및 그 재현 스크립트. 여기에 시스템 카드와 운영 정책 문서를 더하면 완결됩니다.
📌 Phase 3 핵심 정리
- ✅ 네 용어 구분: 투명성(공개) · 해석가능성(내부 이해) · 설명가능성(개별 근거) · 추적가능성(재구성). 사고 조사에서 실제로 쓰이는 건 추적가능성이다.
- ✅ 설명은 관계다: 수신자와 목적이 정해져야 설명의 형태가 정해진다. 정보주체에겐 반사실, 감사인에겐 문서·로그.
- ✅ 사후 설명의 한계: LIME은 불안정, SHAP은 상관 특징에서 왜곡, saliency는 위생 검사 실패 사례 존재. 충실성·안정성을 측정하라.
- ✅ 문서가 더 강력하다: 모델 카드의 '범위 밖 사용'과 '분해 성능', 데이터시트의 '수집 과정'이 실제 책임성을 만든다.
- ✅ 법: GDPR 22조는 설명만이 아니라 인간 개입·이의제기를 요구. 사후 설명 요구권의 존재 여부는 논쟁이나, 아무 설명도 안 하는 것은 방어되지 않는다.
- ✅ LLM: 사고사슬은 유창하지만 불충실할 수 있다. 감사 증거는 로그·인용 출처·평가 프로토콜이다.