[CS300 #280] AI 안전과 평가 — 잘 되는지보다 어떻게 실패하는지를 잰다
컴퓨터공학 300 주제 시리즈의 280번째 글이다. 전체 지도는 여기.
한 줄 요약
AI 안전은 시스템이 의도하지 않은 해를 끼치지 않게 설계·검증·운영하는 일이고, 그 출발점은 믿을 수 있는 평가다. 벤치마크 점수 하나가 아니라 불확실성, 오염, 악의적 입력, 실제 사용 맥락까지 재야 한다.
왜 필요한가
AI 시스템의 실패는 일반 소프트웨어와 다르다. 버그는 대개 재현되고 코드에서 원인을 찾을 수 있다. 모델의 실패는 확률적이고, 학습 데이터에서 온 편향이 숨어 있고, 사람이 예상하지 못한 입력에서 터진다. 그리고 모델이 에이전트로 도구를 쓰기 시작하면 실패가 텍스트에서 행동으로 번진다.
엔지니어 입장의 안전은 철학적 논쟁보다 구체적이다. “이 기능을 출시해도 되는가”에 답할 근거를 만드는 일이다. 그 근거가 평가다. 평가가 허술하면 좋아 보이는 숫자로 위험한 시스템을 내보내게 된다.
핵심 개념
무엇이 잘못될 수 있나
Amodei 외(2016)의 “Concrete Problems in AI Safety” 는 기계학습 시스템의 사고를 구체적인 연구 문제로 나눴다.
| 문제 | 뜻 | 예 |
|---|---|---|
| 부작용 회피 | 목표를 이루며 주변을 망가뜨림 | 청소하려고 물건을 치워 버림 |
| 보상 해킹 | 목표 지표의 허점을 파고듦 | 테스트를 고치는 대신 테스트를 지움 |
| 확장 가능한 감독 | 사람이 매번 확인하기 비싼 목표 | 긴 문서 요약의 정확성 |
| 안전한 탐험 | 시행착오 자체가 위험 | 실제 장비에서의 무작위 행동 |
| 분포 이동에 대한 강건성 | 학습과 다른 상황에서의 오작동 | 다른 병원 장비의 의료 영상 |
LLM 이 널리 쓰이면서 여기에 환각(그럴듯한 거짓), 프롬프트 인젝션, 유해 정보 제공, 개인정보 유출, 과도한 권한을 가진 에이전트 같은 위험이 더해졌다. OWASP 의 LLM 애플리케이션 상위 10 위험 목록이 실무 점검표로 쓰기 좋다.
위험 관리 체계
NIST 의 AI 위험 관리 프레임워크(AI RMF 1.0, 2023)는 조직이 AI 위험을 다루는 활동을 네 기능으로 정리한다.
GOVERN (거버넌스: 책임, 정책, 문화) — 나머지 셋을 감싼다
MAP (맥락 파악: 누가, 어디서, 어떤 영향을)
MEASURE (측정: 평가, 시험, 모니터링)
MANAGE (관리: 우선순위, 대응, 잔여 위험 수용 여부)
유럽연합의 AI 법(Regulation (EU) 2024/1689)처럼 위험 수준에 따라 의무를 달리하는 규제도 생겼다. 엔지니어에게 중요한 것은 “어떤 용도로 쓰이느냐에 따라 같은 모델의 위험이 다르다”는 관점이다.
좋은 평가의 조건
1) 과제에 맞는 측정. 범용 벤치마크(지식 문항인 MMLU, 코드 생성 문항인 HumanEval 등)는 모델 간 대략의 비교에 쓰인다. 하지만 내 서비스의 성능은 내 데이터로 만든 평가 세트로만 알 수 있다. HELM(Liang 외, 2022)은 정확도 하나가 아니라 보정, 강건성, 공정성, 효율 등 여러 지표를 여러 시나리오에서 함께 보고하자고 제안했다.
2) 불확실성 표시. 문항 200개에서 72% 와 75% 는 같은 수준일 수 있다. 신뢰구간 없이 순위를 매기면 잡음을 실력으로 착각한다.
3) 오염 점검. 평가 문항이 학습 데이터에 들어갔으면 모델은 푸는 게 아니라 기억한다. 공개 벤치마크는 시간이 지날수록 웹에 퍼져 오염 위험이 커진다. 문항과 학습 텍스트의 n-gram 겹침 검사, 공개되지 않은 자체 문항, 주기적인 새 문항 추가로 대응한다.
4) 적대적 평가(레드팀). 정상 사용자만 가정한 평가는 악의적 사용을 못 잡는다. 탈옥 시도, 인젝션, 경계 사례를 일부러 찾는 팀을 둔다.
5) 지표가 목표가 되면 망가진다. 특정 벤치마크 점수를 올리는 데 최적화하면 점수는 오르고 실제 능력은 그만큼 오르지 않는다. 보상 해킹의 평가판이다.
운영에서의 안전 장치
- 심층 방어: 입력 필터, 모델 자체의 안전 학습, 출력 검증, 권한 제한, 사람 검토를 겹친다. 하나가 뚫려도 다음이 막는다.
- 최소 권한: 에이전트에게 필요한 도구와 범위만 준다.
- 로그와 사후 분석: 문제가 된 입출력을 기록하고, 평가 세트에 회귀 사례로 추가한다.
직접 해 보기
두 모델의 평가 결과에 부트스트랩 신뢰구간을 붙이고, 간단한 8-gram 오염 검사를 해 본다.
import random
random.seed(42)
# 가상의 평가 결과: 문항 200개에 대한 정답 여부(1/0)
model_a = [1 if random.random() < 0.72 else 0 for _ in range(200)]
model_b = [1 if random.random() < 0.75 else 0 for _ in range(200)]
def bootstrap_ci(xs, n=2000, alpha=0.05):
means = sorted(sum(random.choice(xs) for _ in xs) / len(xs) for _ in range(n))
return means[int(n * alpha / 2)], means[int(n * (1 - alpha / 2)) - 1]
for name, r in (("A", model_a), ("B", model_b)):
lo, hi = bootstrap_ci(r)
print(f"모델 {name}: 정확도 {sum(r)/len(r):.3f}, 95% CI [{lo:.3f}, {hi:.3f}]")
# 오염 점검: 평가 문항과 학습 텍스트의 8-gram 겹침
def ngrams(s, n=8):
w = s.split(); return {" ".join(w[i:i+n]) for i in range(len(w) - n + 1)}
train_text = "the quick brown fox jumps over the lazy dog and then runs into the forest at night"
items = ["the quick brown fox jumps over the lazy dog and then sleeps",
"a slow green turtle walks under the bright sun in the morning light"]
for it in items:
print("오염 의심" if ngrams(it) & ngrams(train_text) else "겹침 없음", "|", it[:40])
실행 결과:
모델 A: 정확도 0.730, 95% CI [0.665, 0.790]
모델 B: 정확도 0.710, 95% CI [0.645, 0.770]
오염 의심 | the quick brown fox jumps over the lazy
겹침 없음 | a slow green turtle walks under the brig
흥미로운 결과가 나왔다. 모의 실험에서 모델 B 의 실제 정답 확률(0.75)을 A(0.72)보다 높게 설정했는데, 문항 200개로 잰 점수는 A 가 0.730, B 가 0.710 으로 순서가 뒤집혔다. 두 신뢰구간은 크게 겹친다. 이 정도 문항 수로는 3%p 차이를 가려낼 수 없다는 뜻이다. “A 가 B 보다 낫다”고 보고했다면 잡음을 결론으로 내놓은 셈이다. 차이를 확인하려면 문항을 늘리거나, 같은 문항에 대한 두 모델의 정오를 짝지어 비교하는 검정(쌍체 부트스트랩, 맥니마 검정 등)을 써야 한다.
오염 검사에서는 첫 문항이 학습 텍스트와 8단어 연속으로 겹쳐 걸렸다. 실제 연구에서도 이런 n-gram 겹침을 오염 지표로 쓰지만, 바꿔 쓴 문항은 못 잡는 한계가 있다.
현업에서는
- 출시 기준을 미리 적는다. “평가 세트 정확도 X 이상, 유해 응답 비율 Y 이하, 레드팀 치명 사례 0건” 같은 기준을 개발 전에 정하고, 결과를 보고 기준을 바꾸지 않는다.
- 자체 평가 세트가 자산이다. 실제 사용 로그에서 뽑은 사례, 과거 사고 사례, 레드팀 사례를 계속 쌓는다. 모델·프롬프트를 바꿀 때마다 돌린다.
- 사람 평가도 측정 도구다. 평가자 간 일치도를 재고, 기준표(루브릭)를 주고, 모델 이름을 가리고 비교한다. LLM 을 채점자로 쓸 때는 사람 평가와의 일치도를 먼저 확인한다.
- 작은 시스템도 마찬가지다. 홈랩에서 운영 보조 봇을 돌린다면, 봇이 실행할 수 있는 명령의 범위를 제한하고, 실행 기록을 남기고, 사고가 나면 그 사례를 다음 검증 항목에 추가하는 것이 같은 원리의 축소판이다.
확인 문제
- 보상 해킹의 예를 하나 들고, 평가에서 같은 현상이 어떻게 나타나는지 설명하라.
- 문항 200개 평가에서 두 모델이 72%, 75% 를 받았다. “B 가 더 낫다”고 결론 내기 전에 무엇을 확인해야 하는가?
- 벤치마크 오염이란 무엇이며 어떻게 점검하는가?
- NIST AI RMF 의 네 기능은?
- 심층 방어가 LLM 시스템에서 특히 중요한 이유는?
풀이
- 코딩 에이전트가 테스트를 통과시키려고 테스트 코드를 지우는 것. 평가에서는 특정 벤치마크 점수만 최적화해 점수는 오르지만 실제 능력은 오르지 않는 현상으로 나타난다.
- 신뢰구간 또는 쌍체 검정으로 차이가 통계적으로 의미 있는지, 그리고 그 평가 세트가 실제 사용 사례를 대표하는지 확인한다.
- 평가 문항이 학습 데이터에 포함되어 모델이 풀이가 아니라 기억으로 맞히는 것. n-gram 겹침 검사, 비공개 문항, 학습 데이터 수집 시점 이후에 만든 새 문항으로 점검한다.
- GOVERN, MAP, MEASURE, MANAGE.
- 모델의 행동은 확률적이고 프롬프트 인젝션 같은 공격을 완벽히 막는 단일 수단이 없으므로, 여러 겹의 독립된 장치로 한 겹이 뚫려도 피해를 막아야 하기 때문이다.
더 읽을거리 (References)
- NIST, AI Risk Management Framework, AI RMF 1.0 (NIST AI 100-1) PDF
- D. Amodei 외, “Concrete Problems in AI Safety”, 2016. arXiv:1606.06565
- P. Liang 외, “Holistic Evaluation of Language Models”, 2022. arXiv:2211.09110
- OWASP, Top 10 for Large Language Model Applications