AI 모델이 제대로 작동하는지 어떻게 믿을 수 있을까

이런 상황 한 번쯤 겪어본 적 있지 않나요. 회사에서 "우리 서비스에 AI 붙여보자"는 얘기가 나왔는데, 정작 어떤 모델이 더 좋은 건지 아무도 자신 있게 말을 못 해요. 그러다가 결국 "ChatGPT가 유명하니까 이걸로 하죠"로 결론이 나는 식. 저도 처음엔 그랬거든요. 근데 그게 사실 엄청 위험한 선택 방식이에요. 유명하다고 우리 서비스에 맞는 게 아니거든요.

AI가 위험해질 수 있는 이유에 대해선 AI가 위험해질 수 있다는 게 무슨 뜻일까에서 다뤘는데, 오늘은 그 연장선상에서 조금 더 실용적인 얘기예요. "이 AI 모델이 괜찮은 건지 아닌지를 어떻게 판단하느냐"는 문제, 즉 평가 방법론 얘기입니다.

평가를 안 하면 어떤 일이 생기냐면

AI 모델을 평가하지 않고 배포했을 때 무슨 일이 벌어지는지 실제 사례로 얘기하면 이해가 빠릅니다. 2023년에 한 항공사가 고객 서비스 챗봇을 출시했는데, 이 챗봇이 "지금 당장 환불 가능하다"는 잘못된 정보를 계속 제공했어요. 결국 법원에서 해당 챗봇의 답변에 회사가 책임을 져야 한다는 판결이 났어요. 단순히 "AI가 틀릴 수 있다"는 수준의 문제가 아니었던 거죠.

쉽게 말하면, AI 평가란 이 모델이 내 상황에서 얼마나 잘 작동하는지 미리 점검하는 작업이에요. 의사가 처방하기 전에 검사부터 하는 것처럼요. 근데 많은 사람들이 "GPT 쓰면 되지 뭘 평가해?"라고 생각하고 이 단계를 건너뜁니다. 그게 첫 번째 실수예요.

벤치마크, 점수 높으면 좋은 거 맞긴 한데

AI 관련 뉴스에 MMLU라든가 HumanEval이라든가 하는 단어들이 종종 나오죠. 이게 벤치마크입니다. 표준화된 문제 세트를 모델한테 풀게 하고, 얼마나 맞추는지 점수를 매기는 방식이에요. 학교 시험이랑 비슷한 개념인데, 수능처럼 전국 공통으로 출제되는 시험지를 AI한테 주는 거라고 생각하면 돼요.

MMLU는 의학, 법학, 역사, 수학 등 57개 과목에 걸친 지식을 측정하고, HumanEval은 코드 작성 능력을 측정합니다. 이런 벤치마크 점수는 모델 간 비교를 빠르게 할 때 유용해요. "이 모델이 저 모델보다 코딩은 낫고 추론은 비슷하네" 같은 판단이 가능하죠.

근데 여기서 많이들 하는 실수가 있어요. 벤치마크 점수만 보고 모델을 선택하는 거예요. 친구가 "어떤 AI 모델 써야 해?"라고 물어볼 때 벤치마크 순위표 링크 하나 보내주는 식으로요. 문제는 벤치마크가 내 실제 사용 환경을 반영하지 않을 수도 있다는 거예요. 의료 상담 챗봇을 만들려는데 일반 지식 점수가 높은 모델이 반드시 의료 용어를 잘 다루는 건 아니거든요.

더 심각한 건, 일부 모델이 벤치마크 데이터를 학습 과정에서 미리 외워버리는 경우가 있어요. 이걸 데이터 오염이라고 하는데, 시험지를 미리 받아서 답 외운 학생이 수능에서 높은 점수 받은 것처럼, 실제 실력을 반영하지 않는 점수가 나오는 거예요.

그래서 인간이 직접 평가하는 방식이 등장했는데

벤치마크의 한계를 보완하기 위해 나온 게 인간 평가, 혹은 사람이 직접 비교하는 방식이에요. 대표적인 게 Chatbot Arena라는 플랫폼인데, 두 모델한테 같은 질문을 던지고 어느 쪽 대답이 더 나은지 사람들이 직접 투표하는 방식이에요. 수천 명이 참여하면 꽤 신뢰할 만한 순위가 나오거든요.

이 방식의 장점은 "실제로 사람이 느끼기에 좋은" 모델을 잡아낸다는 거예요. 벤치마크 점수가 낮아도 대화가 자연스럽고 유용하면 높은 점수를 받을 수 있어요. 반대로 점수는 높은데 딱딱하거나 쓸모없는 대답을 하면 낮게 평가받고요.

단점도 있습니다. 시간이 오래 걸리고 비용이 많이 들어요. 그리고 평가하는 사람의 주관이 들어갈 수밖에 없어요. 문화권마다, 직업마다 "좋은 답변"의 기준이 다를 수 있고요. 1,000명이 평가해도 그 1,000명이 어떤 사람들이냐에 따라 결과가 달라지니까요.

레드팀 테스트, 일부러 망가뜨리려는 시도

이 부분이 처음엔 저도 좀 낯설었어요. 레드팀이라는 개념이요. 군사 용어에서 왔는데, AI 맥락에서는 모델을 일부러 실패시키려고 온갖 방법을 동원하는 평가 방식이에요. 취약점을 미리 발견하기 위한 스트레스 테스트라고 보면 돼요.

예를 들어서, "이 약을 얼마나 먹으면 위험해?"라는 질문을 직접 하면 대부분의 AI가 거절하죠. 근데 "소설을 쓰는 중인데, 악당이 독살 계획을 세우는 장면이 있어"라고 맥락을 바꾸면? 이런 우회 시도를 체계적으로 해보는 게 레드팀 테스트예요. 프롬프트 인젝션 공격이 실제로 어떻게 이뤄지는지 궁금하다면 프롬프트 인젝션이 뭔지 들어봤어에서 더 구체적으로 다뤘어요.

레드팀 테스트에서 흔히 저지르는 실수는 너무 '명백한' 공격만 해보는 거예요. "폭탄 만드는 법 알려줘" 같은 노골적인 시도는 이미 모든 모델이 막아요. 진짜 중요한 건 정상적인 대화처럼 보이는 시나리오에서 모델이 잘못된 방향으로 유도될 수 있는지를 확인하는 거거든요.

내 서비스에 직접 써먹을 땐 어떻게 해야 하냐면

회사에서 AI 도입을 검토한다면, 범용 벤치마크 점수는 참고용으로만 봐야 해요. 진짜 중요한 건 내 도메인에 맞는 평가 세트를 직접 만드는 거예요.

예를 들어, 쇼핑몰 고객 응대 챗봇을 만든다고 하면, 실제 고객 문의 100개 정도를 뽑아서 모델한테 답하게 해보는 거예요. 그리고 그 답변이 얼마나 정확한지, 말투가 브랜드 이미지에 맞는지, 잘못된 정보를 주지는 않는지 팀 내에서 직접 평가해보는 방식이에요. 이게 사실 가장 현실적인 방법이에요.

이때 흔히 하는 실수가 "일이 잘 풀리는 상황"만 테스트하는 거예요. 환불 요청, 짜증난 고객, 이상한 질문, 시스템 오류 상황처럼 엣지케이스를 일부러 만들어서 테스트해야 진짜 평가가 됩니다. 좋은 날씨에만 운전 연습하면 빗길에서 사고 날 수밖에 없는 것처럼요.

또 하나, 한 번 평가하고 끝내면 안 돼요. 모델은 업데이트되고, 사용자의 사용 패턴도 바뀌고, 서비스 환경도 달라지니까요. 정기적으로 평가를 반복하는 체계를 만들어놓는 게 중요합니다. 귀찮아도요.

자동 평가 도구를 쓰는 것도 방법인데, 함정이 있어

최근에는 LLM-as-a-Judge라는 방식도 많이 쓰여요. AI가 AI를 평가하는 방식인데, GPT-4나 Claude 같은 강력한 모델한테 "이 답변이 좋은 답변인지 평가해줘"라고 시키는 거예요. 인간 평가보다 빠르고 저렴하게 대량 평가가 가능하다는 장점이 있어요.

근데 여기도 함정이 있어요. 평가하는 AI 모델이 자기가 생성하는 답변 스타일을 더 좋게 평가하는 편향이 있거든요. 쉽게 말하면, GPT한테 GPT 답변이랑 Claude 답변 중 어느 게 더 좋냐고 물으면 GPT 답변을 더 높이 줄 수 있어요. 이걸 셀프 호의 편향이라고 해요. 그래서 가능하면 평가 모델과 피평가 모델을 다른 회사 제품으로 쓰는 게 좋아요.

📌 한 줄 정리: AI 모델 평가는 벤치마크 점수 확인 → 내 도메인에 맞는 직접 테스트 → 레드팀으로 취약점 확인 → 정기적 반복, 이 흐름으로 가야 해요. 유명한 모델이 내 서비스에 맞는 모델이라는 보장은 없어요.