컴퓨터공학 300 주제 시리즈의 293번째 글이다. 전체 지도는 여기.

한 줄 요약

AI 윤리는 “AI 가 사람에게 해를 끼치지 않게 하라”는 막연한 구호가 아니다. 투명성, 공정성, 안전, 책임성 같은 원칙을 측정 가능한 요구사항, 문서, 검토 절차, 사람의 개입 지점으로 바꾸는 엔지니어링 작업이다.

왜 필요한가

AI 시스템은 일반 소프트웨어와 다른 위험을 가진다.

  • 규칙을 사람이 쓰지 않고 데이터에서 배운다. 데이터의 왜곡을 그대로 배운다.
  • 결과를 설명하기 어렵다. 왜 대출이 거절됐는지 말하지 못할 수 있다.
  • 확률적으로 틀린다. 틀리는 비율이 낮아도 대상이 수백만 명이면 많은 사람이 피해를 본다.
  • 학습 때와 다른 데이터가 들어오면 조용히 성능이 떨어진다.
  • 생성형 모델은 그럴듯한 거짓을 만들거나 저작권·개인정보가 섞인 내용을 출력할 수 있다.

그래서 각국 정부와 국제기구가 원칙과 규제를 만들고 있다. 개발자 입장에서는 “누군가 정할 문제”가 아니라, 설계·평가·배포 과정에 들어가야 할 체크리스트다.

핵심 개념

주요 원칙 프레임워크

문서 성격 핵심
OECD AI 원칙 정부 간 권고 포용적 성장, 인권·민주적 가치, 투명성·설명가능성, 견고성·안전, 책임성
UNESCO AI 윤리 권고 회원국 권고 인권, 다양성, 환경, 영향 평가
NIST AI RMF 1.0 자발적 위험관리 프레임워크 신뢰할 수 있는 AI 의 특성, GOVERN-MAP-MEASURE-MANAGE
EU AI Act (규정 2024/1689) 법적 구속력 있는 규정 위험 기반 차등 규제

문서마다 표현은 다르지만 반복되는 주제가 있다. 사람의 권리 존중, 공정성, 투명성과 설명가능성, 안전과 보안, 프라이버시, 책임성이다.

NIST AI RMF: 원칙을 활동으로

미국 NIST 의 AI 위험관리 프레임워크(AI RMF 1.0)는 신뢰할 수 있는 AI 의 특성으로 다음을 든다.

  • 타당하고 신뢰할 수 있음(valid and reliable)
  • 안전함(safe)
  • 보안과 회복력(secure and resilient)
  • 책임성과 투명성(accountable and transparent)
  • 설명가능성과 해석가능성(explainable and interpretable)
  • 프라이버시 강화(privacy-enhanced)
  • 공정성, 해로운 편향 관리(fair with harmful bias managed)

그리고 이를 관리하는 네 기능을 둔다.

GOVERN  : 조직의 정책·역할·책임을 정한다            (전체를 감싼다)
MAP     : 맥락을 파악하고 위험을 식별한다            "누가 어떤 피해를 입을 수 있나"
MEASURE : 위험을 측정·평가·추적한다                 "얼마나 자주, 누구에게"
MANAGE  : 우선순위를 정해 대응하고 모니터링한다       "줄이거나, 받아들이거나, 멈춘다"

EU AI Act: 위험 기반 규제

EU AI Act 는 용도에 따라 의무를 다르게 둔다.

위험 수준 예 의무
금지 사회적 점수 매기기 등 규정이 열거한 관행 사용 금지
고위험 채용, 신용평가, 교육, 핵심 인프라 등 규정이 열거한 영역 위험관리, 데이터 거버넌스, 기술 문서, 기록, 사람의 감독, 정확성·견고성
투명성 의무 챗봇, 딥페이크 등 AI 와 상호작용함을, 생성물임을 알림
그 외 스팸 필터 등 별도 의무 최소

같은 이미지 분류 모델이라도 사진 앱 필터에 쓰면 낮은 위험이고, 채용 면접 평가에 쓰면 고위험이다. 기술보다 용도가 위험을 정한다는 것이 핵심이다.

원칙을 요구사항으로 바꾸기

원칙 엔지니어링 산출물
투명성 모델 카드, 데이터시트, AI 사용 고지
설명가능성 결정 사유 제공, 특성 중요도 분석, 이의 제기 경로
공정성 집단별 성능 평가, 편향 측정(다음 글)
안전·견고성 분포 이탈 감지, 적대적 입력 시험, 레드팀
프라이버시 학습 데이터 최소화, 개인정보 필터링, 기억 유출 시험
책임성 승인 절차, 변경 기록, 사고 대응 절차, 책임자 지정
사람의 감독 사람 검토 경로, 중단 스위치, 자동화 범위 제한

모델 카드(Mitchell 외, 2019)는 모델의 용도, 사용하면 안 되는 용도, 평가 데이터, 집단별 성능, 한계를 짧게 정리한 문서다. 코드에 README 가 있듯 모델에도 설명서가 있어야 한다는 발상이다.

사람의 개입(human-in-the-loop)

모든 결정을 자동화할 필요는 없다. 모델이 확신이 낮은 경우나 결과의 영향이 큰 경우는 사람에게 넘긴다. 이때 두 가지 함정이 있다.

  • 자동화 편향: 사람이 모델 출력을 그냥 승인하는 습관이 생긴다. 사람 검토가 형식적이 된다.
  • 책임 공백: “모델이 그랬다”와 “사람이 승인했다”가 서로를 탓한다. 누가 최종 책임자인지 정해야 한다.

직접 해 보기

모델의 확신도 임계값에 따라 자동 처리 범위와 사람 검토 부담이 어떻게 바뀌는지 본다. 합성 데이터다.

import random

random.seed(7)
# 가상의 분류 모델 출력: (모델 확신도, 예측이 맞았는가)
cases = []
for _ in range(2000):
    conf = random.uniform(0.5, 1.0)
    correct = random.random() < conf      # 확신도가 높을수록 맞을 확률이 높다고 가정
    cases.append((conf, correct))

print("임계값  자동처리율  자동처리 오류율  사람 검토 건수")
for thr in (0.5, 0.7, 0.8, 0.9, 0.95):
    auto = [c for c in cases if c[0] >= thr]
    human = len(cases) - len(auto)
    err = sum(1 for _, ok in auto if not ok) / len(auto)
    print(f"{thr:5.2f}   {len(auto) / len(cases):8.1%}   {err:12.1%}   {human:10d}")

실행 결과다.

임계값  자동처리율  자동처리 오류율  사람 검토 건수
 0.50     100.0%          25.9%            0
 0.70      58.1%          16.8%          837
 0.80      39.1%          11.5%         1218
 0.90      19.7%           5.9%         1607
 0.95       9.2%           2.7%         1815

임계값을 올리면 자동 처리 오류율은 내려가지만 사람이 볼 건수가 늘어난다. 어디에 선을 그을지는 기술 문제가 아니라 가치 판단이다. 오류 한 건이 스팸 메일 하나를 놓치는 것이면 낮은 임계값도 괜찮다. 오류 한 건이 대출 거절이나 의료 판단이면 높은 임계값과 충분한 검토 인력이 필요하다.

또 하나. 이 예제는 확신도가 실제 정답률과 잘 맞는다고(보정이 잘 됐다고) 가정했다. 실제 모델은 과신하는 경우가 많다. 확신도를 정책에 쓰기 전에 보정 상태를 측정해야 한다. 그리고 이 표를 집단별로 다시 그려 보면, 어떤 집단은 사람 검토로 더 많이 넘어가거나 더 많이 틀릴 수 있다. 그 문제는 다음 글에서 다룬다.

현업에서는

  • 사내에 LLM 기반 기능을 넣을 때 사용 정책(입력하면 안 되는 데이터), 출력 검증(사실 확인, 금칙 내용 필터), 로그 보존과 개인정보 처리 방침을 함께 정한다.
  • 모델 배포 파이프라인에 “모델 카드 갱신”과 “평가 리포트 첨부”를 필수 단계로 넣는다. 코드 리뷰 없이 머지하지 않듯 평가 없이 모델을 교체하지 않는다.
  • 운영 중에는 입력 분포와 성능을 모니터링하고, 문제가 생기면 이전 모델로 되돌리거나 기능을 끌 수 있게 해 둔다. 홈랩 k3s 에서 모델 서빙 파드를 운영해도 버전 고정과 롤백 경로는 같은 원리다.
  • 사용자에게 AI 가 만든 결과임을 알리고, 이의 제기나 사람 상담으로 가는 경로를 둔다.

확인 문제

  1. NIST AI RMF 의 네 기능을 적고, 각각 한 줄로 설명하라.
  2. EU AI Act 에서 같은 기술이 서로 다른 위험 수준이 될 수 있는 이유는?
  3. 모델 카드에 들어가야 할 항목 세 가지를 들어라.
  4. 사람 검토 단계를 두었는데도 실질적 감독이 안 되는 이유 두 가지는?

풀이

  1. GOVERN(정책·역할·책임 수립), MAP(맥락 파악과 위험 식별), MEASURE(위험 측정·추적), MANAGE(우선순위에 따른 대응과 모니터링).
  2. 위험은 기술이 아니라 용도와 영향 대상에 따라 정해지기 때문이다.
  3. 의도된 용도와 사용하면 안 되는 용도, 평가 데이터와 지표, 집단별 성능, 알려진 한계 중 셋.
  4. 자동화 편향(모델 출력을 그대로 승인), 검토 인력·시간 부족, 책임자 불명확, 검토자에게 판단 근거가 제공되지 않음 등.

더 읽을거리 (References)