KBI 금융 AI 리터러시 (K-ALFA) common mistakes
KBI 금융 AI 리터러시 (K-ALFA) · Understand the traps and how to avoid them.
설명가능성(explainability)과 성능(accuracy)을 맞교환 관계로 단정하거나, 반대로 '설명만 붙이면 규제·소비자보호 요건이 충족된다'고 서술하는 답안을 쓴다. 예를 들어 '딥러닝은 설명이 어려우므로 금융에서 무조건 금지된다'거나 'SHAP 값을 제시하면 신용 거절 사유 설명 의무가 끝난다'고 결론 내린다.
AI 기본 개념 단원에서 모델 성능 지표(정확도, AUC)와 해석 도구를 같은 층위의 개념으로 섞어 암기하기 때문이다. 특히 '블랙박스 모델 = 규제 위반'이라는 단순 공식이 시험 직전 요약노트에 자주 등장해, 사후 설명기법의 한계(근사치, 국소 설명의 불안정성)와 법적 설명 의무의 요건을 구분하지 못한다.
What to do instead
성능과 설명가능성은 별개의 축이며, 규제상 요구되는 것은 '모델 종류'가 아니라 '의사결정 근거의 제시 가능성'이라는 점을 기준으로 정리한다. 사후 설명기법이 제공하는 것(변수 기여도 근사)과 제공하지 못하는 것(인과관계, 개별 고객에 대한 확정적 사유)을 표로 구분하고, 신용 거절 사유 설명은 모델 해석 도구가 아니라 별도의 사유 코드·정책 규칙과 함께 설계된다는 점을 사례 단위로 익힌다.
생성형 AI의 '환각(hallucination)'과 '학습 데이터 편향'을 같은 현상으로 취급하거나, 환각을 '모델이 거짓말을 하도록 학습된 문제'로 설명한다. 또한 RAG(검색증강생성)를 도입하면 환각이 완전히 제거된다고 단정한다.
생성형 AI 원리 단원에서 확률적 다음 토큰 예측이라는 기본 메커니즘을 건너뛰고 서비스 용어(RAG, 파인튜닝, 프롬프트 엔지니어링)만 외우기 때문이다. RAG가 '근거 문서를 프롬프트에 넣는 방식'일 뿐 사실 검증 장치가 아니라는 점, 검색된 문서 자체가 틀리면 오류가 그대로 재생산된다는 점이 요약본에서 빠진다.
What to do instead
환각의 발생 원인을 '확률적 생성 + 근거 부재 + 확신도와 정확도의 불일치'로 구조화하고, RAG·도구 호출·출처 인용·사람 검토가 각각 어떤 오류 유형을 줄이는지(그리고 줄이지 못하는지) 매핑한다. 편향은 학습 데이터 분포에서 오는 체계적 오차, 환각은 생성 메커니즘에서 오는 사실 오류로 원인을 분리해 서술 연습을 한다.
금융 AI 관련 규제를 '특정 법률 하나'로 답하거나, AI 기본법·개인정보보호법·신용정보법·금융소비자보호법의 역할을 뒤섞어 'AI법이 신용평가를 직접 규율한다'고 쓴다. 또한 고위험 AI 분류 기준을 산업(금융=무조건 고위험)으로만 판단한다.
규제 단원은 여러 법령이 중첩되는 구조라, 수험생이 'AI 규제 = AI 기본법'이라는 단일 프레임을 만들고 세부 조항을 암기하려 한다. 실제로는 자동화된 결정에 대한 설명 요구, 신용정보 활용 동의, 취급 자격 등이 서로 다른 법령에 흩어져 있어 어느 법이 무엇을 규율하는지 층위를 구분하지 못한다.
What to do instead
규제 지형을 'AI 일반 규율(AI 기본법상 고위험 분류·투명성 의무) / 개인정보·자동화 결정(개인정보보호법) / 신용정보·평가(신용정보법) / 판매·설명·불공정행위(금융소비자보호법)'의 4층 표로 직접 작성한다. 고위험 판단은 산업이 아니라 '용도·영향(권리·의무에 중대한 영향, 취약 소비자 대상 여부)' 기준으로 서술하는 연습을 한다.
AI 리스크 관리 답안에서 '리스크 = 모델 성능 저하'로 축소해 쓰고, 모델 리스크 관리의 3대 축(개발·검증·모니터링)이나 데이터 드리프트, 개념 드리프트, 데이터 계보(lineage)를 구체적으로 언급하지 않는다. 데이터 거버넌스 질문에도 '개인정보를 암호화한다' 수준의 답만 쓴다.
리스크 관리 단원을 일반 IT 보안 상식으로 대체해 암기하기 때문이다. 금융 AI 리스크는 모델 오류, 데이터 품질, 편향, 제3자(외부 모델·API) 의존, 규제 변화 등 다층 구조인데, 수험생은 익숙한 '보안=암호화·접근통제' 프레임으로 답을 채운다.
What to do instead
리스크 유형을 모델·데이터·운영·제3자·규제·평판으로 나눈 체크리스트를 만들고, 각 유형마다 통제 수단(독립 검증, 백테스트·스트레스 테스트, 성능·드리프트 모니터링 임계치, 재학습 주기, 벤더 평가·계약 조항, 감사 로그)을 짝지어 서술한다. 데이터 거버넌스는 '수집-품질-계보-접근-보존-파기'의 생애주기로 답하는 틀을 고정한다.
업무별 활용 사례 문항에서 'AI가 하면 좋은 일'과 'AI에 맡기면 안 되는 판단'을 구분하지 않고, 모든 업무에 생성형 AI를 만능 해법으로 제시한다. 예를 들어 신용 심사·보험 인수·이상거래 탐지·상담 요약에 동일한 접근을 적용하고, 최종 판단 주체를 모호하게 쓴다.
사례 단원이 가장 방대해 키워드 암기로 대응하기 때문이다. 각 업무의 규제 강도(설명 의무, 금지 행위, 감독 보고), 오류 비용의 비대칭성, 데이터 특성(정형 vs 비정형)이 다르다는 점을 고려하지 않고 '자동화=효율' 프레임만 적용한다.
What to do instead
업무별로 '목표 / 사용 데이터 / AI 역할(보조·추천·자동화) / 오류 시 소비자 영향 / 필수 통제(사람 검토, 설명 제공, 이의제기 경로)' 5칸 표를 만들어 사례를 정리한다. 특히 소비자 권리에 직접 영향을 주는 결정은 AI가 '판단'이 아니라 '보조'로 위치하고 최종 결정과 책임은 사람·기관에 남는다는 원칙을 모든 사례에 일관되게 적용한다.
AI 산출물 검증 문항에서 '사실관계 확인'만 쓰고, 출처 검증·수치 재계산·최신성 확인·프롬프트/모델 버전 기록·재현성 확보를 빠뜨린다. 또한 검증 책임을 'AI 제공사'에게 있다고 서술하거나, 검증을 '개발자 업무'로 한정한다.
검증을 '읽어보고 틀린 곳 고치기'라는 상식적 교정으로 이해하기 때문이다. 금융 문서·보고서·고객 응대 초안에서 요구되는 검증은 수치의 원장 대조, 인용의 원문 확인, 적용 규정의 시점 확인, 산출물 이력 관리까지 포함하며, 책임은 이를 업무에 사용한 조직과 담당자에게 귀속된다.
What to do instead
검증 절차를 '① 입력(프롬프트·데이터 출처) ② 처리(모델·버전·설정 기록) ③ 출력(사실·수치·인용·규정 시점) ④ 승인(사람 검토자·승인 기록)'의 4단계로 외우고, 각 단계에서 남겨야 할 증적을 함께 서술한다. 책임 소재는 '사용한 조직의 검토 의무'로 명확히 쓰는 연습을 한다.
AI 기본 개념 문항에서 머신러닝·딥러닝·생성형 AI·LLM을 포함관계가 아닌 병렬 개념으로 나열하거나, '학습'과 '추론', '파인튜닝'과 '프롬프트 엔지니어링'을 같은 것으로 설명한다.
용어가 비슷하고 마케팅 문구에서 혼용되기 때문에, 정의를 외우지 않고 예시만 기억해 계층 구조를 뒤섞는다. 특히 파인튜닝(가중치 조정)과 RAG·프롬프트(입력 조정)의 차이는 실제 운영 비용·통제 방식과 연결되므로 시험에서 자주 변별점이 된다.
What to do instead
개념 지도를 직접 그려 'AI ⊃ 머신러닝 ⊃ 딥러닝 ⊃ 생성형 AI(LLM 포함)'의 포함관계를 고정하고, 학습/추론, 파인튜닝/프롬프트·RAG를 '무엇이 바뀌는가(가중치 vs 입력)' 기준으로 대비표를 만든다. 각 개념마다 금융 현장 예시를 하나씩 붙여 정의와 사례를 함께 회상한다.
규제·윤리 문항에서 '설명의무'와 '동의'를 같은 것으로 취급하거나, 자동화된 결정에 대한 고지·설명 요구를 '개인정보 수집 동의'로 충족된다고 쓴다. 또한 차별 금지와 공정성 검증을 '민감정보를 입력하지 않으면 해결된다'고 단정한다.
개인정보 동의 절차가 익숙해 모든 규제 요건을 '동의 받기'로 환원하는 습관이 생기기 때문이다. 설명 요구는 결과 통지와 근거 제시에 관한 것이고, 공정성은 민감변수를 제거해도 대리변수(우편번호, 직업, 거래 패턴)로 편향이 남을 수 있다는 점이 간과된다.
What to do instead
동의(수집·이용의 적법 근거)와 설명(결정 이후의 통지·이의제기)을 시점과 목적 기준으로 분리해 서술한다. 공정성은 '민감변수 제외 → 대리변수 점검 → 그룹별 성능·승인율 비교 → 임계치·보정 조치'의 절차로 답하고, 민감정보 미입력이 공정성 보장이 아님을 명시적으로 쓰는 연습을 한다.
리스크 관리 문항에서 '사람이 최종 검토하면 리스크가 해소된다'는 human-in-the-loop 문구만 반복하고, 자동화 편향(automation bias), 검토자의 과부하, 검토 품질 측정 방법을 제시하지 않는다. 모니터링도 '주기적으로 점검한다'는 서술에 그친다.
정답처럼 들리는 안전한 문구를 재사용하는 전략 때문이다. 그러나 형식적 사람 검토는 승인 도장이 되기 쉬워 실질 통제가 되지 못하며, 시험은 검토의 실효성(표본 설계, 검토 시간, 불일치율 측정, 이의제기 처리)을 구체적으로 요구한다.
What to do instead
사람 검토를 통제로 인정받기 위한 조건(권한, 정보 제공, 시간, 판단 기록, 이견 제기 가능성)을 명시하고, 자동화 편향 완화책(무작위 표본 재검토, AI 판단 가림 검토, 불일치율·재검토율 지표)을 함께 서술한다. 모니터링은 지표·임계치·경보·조치·기록의 5요소로 구체화한다.
사례 판단 문항에서 규제 샌드박스·혁신금융서비스 같은 예외 제도나 망분리·클라우드 이용 관련 조건을 무시하고, '규제 때문에 불가능하다' 또는 '샌드박스면 모두 가능하다'로 양극단 답안을 쓴다. 외부 생성형 AI API 사용 시 데이터 반출·학습 재사용 이슈도 빠뜨린다.
제도 이름만 기억하고 적용 조건(대상 업무, 기간, 이용자 보호 조치, 사후 평가, 데이터 국외 이전 요건)을 정리하지 않았기 때문이다. 또한 클라우드·외부 API 사용을 단순 기술 선택으로 보고 데이터 거버넌스·제3자 리스크와 연결하지 못한다.
What to do instead
예외·혁신 제도를 '가능하게 하는 조건 + 지켜야 하는 조건'의 쌍으로 정리한다(예: 실증 특례의 기간·범위, 소비자 보호 장치, 결과 보고). 외부 AI 서비스 이용은 데이터 반출 범위, 학습 재사용 금지 약정, 국외 이전 근거, 로그·감사 가능성의 4항목 체크로 답하는 틀을 만든다.