성능과 책임은 같은 문제가 아니다 → Accountability / 거버넌스
모델 정확도가 95%라면, 그 시스템은 안전한가?
파일럿 테스트에서 오류가 거의 없었다면, 도입해도 되는가?
성능 지표가 높으면 책임 구조도 함께 설계된 것인가?
이 질문은 비슷해 보이지만 전혀 다른 층위에 있다.
우리는 여전히 성능과 책임을 같은 문제처럼 다룬다.
AI 도입 회의에서 가장 많이 나오는 문장은 이것이다.
“정확도는 충분합니다.”
그 다음 질문은 잘 나오지 않는다.
“문제가 생기면 누가 판단하고, 누가 멈추는가?”
성능은 수치다.
책임은 구조다.
이 둘은 닮지 않았다.
한 중견 제조 유통 기업 사례를 보자.
한 중견 제조 유통 기업 사례를 보자.
연 매출 800억 원, 직원 120명.
이 회사는 수요 예측 AI를 도입했다.
초기 성능은 나쁘지 않았다.
예측 오차율은 기존 엑셀 기반 방식보다 18% 개선됐다.
현장 반응도 괜찮았다.
문제는 4개월 후에 발생했다.
특정 제품군의 예측이 반복적으로 빗나갔다.
재고는 과잉, 일부는 품절.
영업팀은 “AI가 이렇게 말한다”고 주장했고,
구매팀은 “그래도 이상하다”고 말했다.
여기서 드러난 것은 모델 성능 문제가 아니었다.
누가 최종 판단권자인지 정의되지 않았다는 점이었다.
AI 권고를 따르지 않으면 책임이 개인에게 돌아오는 구조였고,
따랐다가 실패해도 명확한 책임 경로가 없었다.
결국 사람은 AI를 따를 수밖에 없었다.
성능이 아니라 구조의 문제였다.
우리가 흔히 하는 착각은 이것이다.
“성능이 높으면 리스크는 줄어든다.”
성능은 평균적 상황에서의 확률이다.
책임은 예외 상황에서의 결정 구조다.
평균은 숫자로 관리할 수 있다.
예외는 권한과 역할로만 관리된다.
정확도 95%는 5%의 실패를 전제로 한다.
그 5%를 누가 감당하는지 설계하지 않으면,
그 시스템은 완성되지 않은 것이다.
거버넌스는 규정집이 아니다.
현장에서의 흐름 설계다.
최소한 다음 네 가지가 정의되어야 한다.
- 의사결정 단계 구분
- AI 권고
- 인간 검토
- 최종 승인
이 세 단계가 명확히 나뉘어 있는가?
- 이탈 허용 구조
- AI 판단을 거부할 수 있는가?
- 거부 시 근거 기록 방식은 있는가?
- 책임 귀속 경로
- 오류 발생 시 검토 대상은 모델인가, 운영 프로세스인가?
- 개인 평가와 시스템 평가를 분리했는가?
- 중단 권한 정의
- 누구에게 시스템 중단 권한이 있는가?
- 긴급 상황에서 승인 체계는 단순한가?
이 네 가지가 없으면,
AI는 성능이 아니라 압력으로 작동한다.
성능 최적화는 모델 팀의 과제다.
책임 설계는 경영 구조의 문제다.
이 둘을 같은 테이블에서 다루지 않으면,
결국 AI는 “도입은 했지만 불편한 도구”가 된다.
현장에서 보이는 징후는 단순하다.
사람들이 AI 결과를 의심하면서도 그대로 따른다.
결과가 좋으면 “AI 덕분”이고,
나쁘면 “현장이 잘못했다”고 말한다.
이건 기술 문제가 아니다.
책임이 비가시화된 상태다.
당장 점검해야 할 질문은 세 가지다.
- AI 판단을 거부해도 인사상 불이익이 없는가?
- 실패 사례가 모델 개선으로 연결되는 경로가 있는가?
- 시스템을 멈출 권한이 개인이 아니라 구조에 있는가?
이 질문에 답하지 못하면,
성능 개선 논의는 반복될 뿐이다.
성능은 숫자로 증명된다.
책임은 설계로만 증명된다.
두 문제를 분리하지 않으면,
우리는 계속 같은 회의를 반복하게 된다.
AI는 똑똑해질 수 있다.
하지만 책임은 자동으로 생기지 않는다.
AI현장감독 이동주는 AI 도입 과정에서 반복되는 구조 문제를 연구한다.
AI adoption failure를 기술 문제가 아닌 설계와 흐름의 문제로 바라본다.
Fieldbly에서 현장 사례를 기반으로 정리하고 있다.
(homepage) http://www.fieldbly.com