방대한 내용이네요.
쉬운 설명
AI 서비스를 만들다 보면 "이 답변이 잘 나온 건지 아닌지"를 판단하기가 생각보다 어려운데요, 이걸 확인하는 과정을 '평가(Evals)'라고 불러요. 쉽게 말하면 AI가 뱉어낸 결과물을 사람이 직접 눈으로 살펴보면서 "어? 이건 틀렸네", "이건 이상한 답이네" 하고 하나씩 찾아내는 작업이에요. 시험 채점하듯 자동으로 점수만 매기는 게 아니라, 먼저 사람이 답안지를 꼼꼼히 읽어보고 어떤 문제가 자주 생기는지 파악한 다음에, 그중 반복되는 문제만 나중에 자동으로 걸러내는 장치를 만드는 거라고 생각하면 됩니다.
요약
이 글은 AI 엔지니어와 PM 700명 이상을 대상으로 진행한 'AI Evals' 강의에서 실제로 가장 많이 나온 질문들을 정리한 자료를 바탕으로 하고 있어요. 핵심 주장은 명확합니다. 평가 시스템을 만들 때 값비싼 도구나 인프라부터 구축하지 말고, 먼저 사람이 직접 20~50개 정도의 AI 출력 결과를 30분만 훑어보는 '오류 분석(error analysis)'부터 시작하라는 거예요. 이 과정에서 사용자를 잘 이해하는 한 명의 전문가가 품질을 판단하는 최종 결정권자, 이른바 '선의의 독재자' 역할을 맡는 게 효율적이라고 설명합니다.
특히 눈에 띄는 대목은 실제 프로젝트에서 개발 시간의 60~80%를 오류 분석과 평가에 쓴다는 부분이에요. 이 말은 자동화된 검사 도구를 만드는 것보다, 데이터를 직접 들여다보고 무엇이 왜 잘못됐는지 이해하는 데 훨씬 더 많은 시간이 들어간다는 뜻입니다. 또 하나 흥미로운 관점은 평가 통과율이 100%에 가깝다면 오히려 위험 신호라는 거예요. 너무 쉬운 기준으로 테스트하고 있다는 뜻일 수 있고, 차라리 70% 정도의 통과율이 시스템을 제대로 압박하며 테스트하고 있다는 신호일 수 있다는 겁니다.
활용 포인트
실무에 적용할 때는 이렇게 시작해보면 좋아요. 먼저 노션이나 구글 시트, 혹은 주피터 노트북 같은 익숙한 도구에 최근 AI가 생성한 응답 20~50개를 모아놓고, 팀 안에서 사용자를 가장 잘 아는 한 사람이 하나씩 읽으면서 "이건 왜 이상한가"를 메모하는 시간을 정기적으로 가져보세요. 코드를 다룰 줄 안다면 Claude나 Codex 같은 AI 코딩 도구를 활용해서 직접 나만의 간단한 리뷰용 인터페이스(예: 응답과 원본 질문을 나란히 보여주고 좋음/나쁨을 체크하는 화면)를 빠르게 만들어보는 것도 방법입니다. 이렇게 찾은 문제 중에 정규식이나 간단한 조건문으로 바로 잡아낼 수 있는 건 그 자리에서 코드로 고치고, LLM을 판정자로 세워야 할 만큼 복잡한 문제만 별도로 자동 평가 장치를 만드는 식으로 투자 우선순위를 나눠보세요.
기획자나 학습자 입장에서는 이 접근을 프로젝트 회의에 그대로 적용할 수 있어요. 매번 큰 기능을 배포하기 전에 "AI 출력물 30분 리뷰" 세션을 캘린더에 고정으로 넣고, 발견된 문제를 표로 정리해서 우선순위를 매기는 습관을 들이면 됩니다. 이건 특별한 툴이나 예산 없이도 오늘 당장 팀 회의에서 시도해볼 수 있는 방법이라는 점이 큰 장점이에요.
주의 사항
이 글에서 소개하는 방법론은 특정 강의(AI Evals 코스)와 저자들의 실무 경험에 기반한 의견으로, 저자 스스로도 "보편적 진리가 아니라 대부분의 경우에 통하는 견해"라고 밝히고 있어요. 원문에 언급된 25% 할인 코드나 강의 일정 같은 프로모션 정보는 시간이 지나면 만료되거나 바뀔 수 있으니 실제로 확인하려면 원문 링크를 직접 방문하는 게 안전합니다. 또한 관측(observability) 도구마다 '트레이스(trace)'와 '스팬(span)'이라는 용어를 다르게 정의하고 있다는 점도 언급되니, 다른 자료를 참고할 때 용어 혼동에 주의하세요.
자체 검증
원문을 다시 확인해보면, 700명 이상의 엔지니어와 PM을 대상으로 진행한 강의에서 나온 질문을 정리했다는 점, 개발 시간의 60~80%를 오류 분석과 평가에 썼다는 점, 20~50개 출력물을 30분간 리뷰하라는 권장 사항, 100% 평가 통과율을 경계해야 한다는 주장, 그리고 '선의의 독재자' 역할의 도메인 전문가를 두라는 조언까지 모두 원문 내용과 일치합니다. 다만 원문은 트레이스와 스팬의 정의가 관측 도구 벤더마다 다르다는 점을 짧게 언급만 하고 상세 비교표는 스크린샷으로 대체하고 있어서, 이 부분의 구체적 차이는 본문에서 다루지 않았다는 점을 밝혀둡니다.
태그
#AI #LLM평가 #AI개발 #제품기획 #머신러닝
원문
https://hamel.dev/blog/posts/evals-faq
참고자료
A Field Guide to Rapidly Improving AI Products