AI 평가가능성 격차

배포 가능 기준은 두 줄로 나뉜다. OpenAI의 o1 시스템 카드에는 사후 완화 점수가 “medium” 이하면 배포할 수 있고, “high” 이하면 추가 개발을 이어갈 수 있다고 적혀 있다. NIST는 AI 리스크 관리를 Govern, Map, Measure, Manage의 4개 기능으로 나눈다. 숫자와 단계는 분명하다. 더 큰 문제는 그 이전 단계다. 조직이 그 판단을 뒷받침할 평가 증거를 처음부터 충분히 갖고 있느냐다.

세 줄 요약

이 글의 핵심은 모델 성능이 아니라, 위험과 가치를 판단할 만큼 충분한 평가 증거가 없는 상태를 가리키는 ‘AI 평가가능성 격차’다.
이 격차가 크면 레드팀, 벤치마크, 감사 보고서가 있어도 경영진·감사인·정책 담당자가 배포 판단을 높은 확신으로 내리기 어렵다.
독자는 평가 결과 자체만 보지 말고, 무엇을 어떻게 측정했고 어떤 문서와 게이트로 남겼는지를 오늘 점검해야 한다.

현황

arXiv에 올라온 “The AI Evaluability Gap: The Missing Layer for Managing Risk and Sustaining Value”의 발췌에 따르면, AI를 배포하는 조직은 두 가지 거버넌스 과제에 동시에 직면한다. 하나는 AI 리스크 관리이고, 다른 하나는 AI 가치의 지속이다. 논문의 발췌는 이 둘이 모두 “충분하다고 가정할 수 없는 증거”에 의존한다고 짚는다. 즉, 모델이 좋으냐 나쁘냐보다 먼저 그 판단을 뒷받침할 증거가 있느냐가 문제다.

이 문제의식은 기존 평가 체계를 부정하기보다, 그 전제를 다시 묻는다. 지금 업계는 레드팀, 자동 평가, 인간 평가, 감사 프레임워크를 폭넓게 언급한다. OpenAI는 frontier risk와 preparedness 프레임워크에서 모니터링, 평가, 예측, 보호를 함께 다룬다. Safety Evaluations Hub에서는 평가 과학 자체가 계속 바뀌고 있다고 설명한다. o1 시스템 카드도 위험 범주별 실험 결과를 “indicators”에 연결해 Low, Medium, High, Critical로 위험 수준을 나눈다.

그런데 여기서 더 눈에 띄는 것은 프레임워크의 유무보다 문서와 증거의 연결성이다. 검색된 자료에는 문서화가 파편화돼 있고, 정책 담당자·감사인·사용자가 안전 주장을 신뢰성 있게 평가하기 어렵다는 취지의 표현이 확인된다. 여기서 AI 평가가능성 격차라는 개념은 “평가를 했다”와 “그 평가가 거버넌스 의사결정에 충분한 증거가 된다” 사이의 빈칸을 가리킨다. 벤치마크 점수 하나나 레드팀 보고서 하나만으로는 메워지지 않는 층위다.

분석

왜 이게 중요한가. 기업 AI 도입의 병목이 모델 정확도에서만 생기지 않기 때문이다. 실제 조직은 “성능이 괜찮다”보다 “누가 어떤 근거로 배포를 승인했는가”를 더 오래 따진다. NIST가 Govern, Map, Measure, Manage라는 4개 기능으로 AI RMF를 구성한 이유도 여기에 있다. 측정은 한 단계일 뿐이다. 그 앞뒤로 책임 구조, 위험 맥락화, 운영 통제가 붙어야 한다. 평가가능성 격차는 이 연결 고리가 빠진 상태를 설명한다.

이 개념의 장점은 안전과 사업 가치를 한 프레임으로 다룬다는 점이다. 위험 통제 실패와 가치 유지 실패를 별개로만 보지 않고, 둘 다 증거 부족에서 출발할 수 있다고 보기 때문이다. 예를 들어 어떤 모델이 데모에서는 잘 작동해도, 어떤 데이터에서 실패하는지, 완화 조치 뒤에 위험 수준이 어떻게 달라졌는지, 사고가 났을 때 어떤 경로로 기록·보고되는지가 없으면 사업 가치를 안정적으로 유지하기 어렵다. 반대로 안전 평가가 있어도 문서가 흩어져 있거나 실험을 반복하기 어려우면 감사와 이사회 보고에서 설득력이 약해진다.

한계도 있다. “평가가능성”이라는 말은 범위가 넓다. 자칫 모든 거버넌스 문제를 한 바구니에 담는 개념이 될 수 있다. 또 평가 증거를 늘린다고 리스크가 자동으로 줄어드는 것도 아니다. 문서를 두껍게 쌓는 일과 실제 통제를 강화하는 일은 다르다. 업계가 이 개념을 실무에 쓰려면, 어떤 증거가 배포 결정에 충분한지, 어떤 실험이 반복 가능해야 하는지, 어떤 사고 기록이 경영 판단으로 이어지는지를 더 분명히 정의할 필요가 있다.

실전 적용

기업이 지금 당장 할 수 있는 접근은 비교적 분명하다. NIST는 AI RMF를 Govern, Map, Measure, Manage로 구조화하고, 반복 가능하고 확장 가능한 TEVV, 즉 test, evaluation, verification, validation 절차를 강조한다. 여기에 시스템 카드, 위험 문서화, 사고 보고 체계를 붙이면 “모델이 얼마나 좋다”가 아니라 “우리가 무엇을 알고 무엇을 아직 모르는가”를 남길 수 있다. Anthropic은 시스템 카드에서 모델의 능력, 안전 평가, 책임 있는 배포 판단을 문서화한다고 설명한다. OECD는 공통 사고 보고 프레임워크와 AI Incidents Monitor를 운영한다.

핵심은 평가를 이벤트가 아니라 파이프라인으로 바꾸는 일이다. 배포 직전 한 번 테스트하는 방식으로는 평가가능성 격차를 줄이기 어렵다. o1 시스템 카드처럼 사후 완화 기준을 명시적 게이트로 두는 접근은 실무에서 참고할 만하다. “점수가 낮으면 배포, 높으면 중단” 같은 통제는 단순해 보일 수 있다. 하지만 그 뒤에 실험 설계와 문서화가 붙어야 의미가 생긴다.

오늘 바로 할 일 체크리스트

현재 운영 중인 AI 기능마다 누가 승인했고 어떤 평가 문서가 근거였는지 한 장으로 정리하라.
성능 테스트, 안전 테스트, 사용자 영향 검토가 각각 어떤 주기로 반복되는지 적고 빈칸을 찾으라.
배포 보류 기준과 사고 보고 경로를 문서에 명시하고, 제품팀과 리스크팀이 같은 버전을 보게 하라.

FAQ

Q. AI 평가가능성 격차는 그냥 평가가 부족하다는 말과 다른가?
그렇습니다. 단순히 테스트 수가 적다는 뜻보다 범위가 넓습니다. 어떤 평가를 했는지, 그 결과가 반복 가능한지, 문서가 연결돼 있는지, 감사나 배포 결정에 쓸 만큼 충분한지까지 포함하는 개념입니다.

Q. 기존 레드팀이나 벤치마크가 있으면 이 문제는 해결된 것 아닌가?
아닙니다. 레드팀과 벤치마크는 중요한 입력이지만, 그것만으로 거버넌스 판단이 끝나지는 않습니다. 실험 조건, 적용 범위, 한계, 완화 조치, 승인 기준이 함께 문서화돼야 의사결정에 쓰기 쉬워집니다.

Q. 작은 조직도 이 프레임을 써야 하나요?
그렇습니다. 다만 규모는 줄일 수 있습니다. 복잡한 위원회보다 먼저, 평가 항목·배포 게이트·사고 기록을 한 문서로 묶고 반복 가능한 점검 루틴을 만드는 편이 현실적입니다.

결론

AI 평가가능성 격차는 모델이 강하냐 약하냐보다, 조직이 그 모델을 판단할 증거를 충분히 갖고 있느냐를 묻는다. 앞으로 볼 포인트는 새 모델의 성능표만이 아니다. 그 성능과 위험을 어떤 평가 파이프라인과 문서 체계로 입증하느냐다.

Aionda

AI 평가가능성 격차

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기