최근 개발자 커뮤니티 지커뉴스(GeekNews)에는 LLM Evals에 대해 알아야 할 모든 것이라는 글이 올라와 눈길을 끌었습니다. 원문은 AI 제품의 응답 품질을 평가하는 방법을 700명 넘는 엔지니어와 PM에게 가르쳐 온 Hamel Husain과 Shreya Shankar가 강의에서 받은 질문을 모아 정리한 FAQ 문서입니다.
단순히 “새 AI 도구가 나왔다”는 소식이었다면 이렇게 오래 눈에 밟히지 않았을 겁니다. 이 글이 다루는 질문은 “내가 만든 AI 기능이 실제로 잘 작동하는지 어떻게 확인하느냐”인데, 이건 결국 개발자의 일상 업무 방식과 채용 기준까지 건드리는 질문이거든요.
LLM Evals란 무엇인가: 코드 리뷰처럼 자연스러운 습관
Evals(평가)는 벤치마크 점수를 재는 일이 아닙니다. 내 제품이 실제로 어디서, 왜 실패하는지 찾아내는 과정입니다. 저자들은 이 과정의 핵심을 “에러 분석(error analysis)”이라고 부릅니다. 사용자와 AI가 나눈 대화 기록, 즉 트레이스(trace)를 사람이 직접 읽고 실패 유형을 분류하는 작업입니다.
트레이스와 에러 분석
트레이스는 사용자의 첫 질문부터 AI의 최종 응답까지, 그 사이의 모든 도구 호출과 중간 메시지를 포함한 전체 기록을 말합니다. 저자들은 자동화된 평가 지표를 만들기 전에 최소 100개의 실제 트레이스를 사람이 먼저 읽어보라고 권합니다. 20개 정도를 봤을 때 새로운 실패 유형이 더 안 나오면 그때 멈춰도 된다는 게 이들의 경험적 기준입니다.
개발 시간의 60~80%가 여기로 이동하고 있다
Hamel Husain과 Shreya Shankar의 발표에 따르면, 우리가 작업한 프로젝트들에서는 개발 시간의 60~80%를 에러 분석과 평가에 썼습니다.
Hamel Husain, Shreya Shankar — LLM Evals FAQ
이 수치는 Hamel Husain과 Shreya Shankar가 LLM Evals: Everything You Need to Know 문서에서 직접 밝힌 내용입니다. 기능을 새로 만드는 시간보다 “이게 왜 실패했는가”를 들여다보는 시간이 훨씬 많다는 뜻이죠. 코드를 쓰는 시간보다 리뷰하고 디버깅하는 시간이 긴 것과 비슷한 흐름이라고 보면 이해가 빠릅니다.
평가를 한 사람이 책임진다: ‘선한 독재자’ 모델과 팀 구조 변화
흥미로운 부분은 조직 구조 얘기입니다. 저자들은 대부분의 중소규모 팀에는 품질 기준을 정하는 “선한 독재자(benevolent dictator)” 한 명을 세우라고 권합니다. 법률 문서를 다루면 변호사, 헬스케어 챗봇이면 임상 전문가처럼, 도메인을 가장 잘 아는 한 사람이 최종 판단자가 되는 구조입니다.
전문가 다섯 명이 매번 합의해야 판단이 나온다면, 그건 제품 범위가 너무 넓다는 신호라고 이들은 말합니다. 이 구조는 팀에 새로운 역할, 즉 “이 AI가 제대로 일했는지 최종적으로 판단하는 사람”을 만들어낸다는 점에서 커리어 관점에서도 지켜볼 만합니다.
PM과 엔지니어 경계가 흐려질 때 생기는 일 (제 경험담)
후배님도 이런 경험 있으신가요? 저는 몇 년 전 RAG 챗봇을 붙이는 프로젝트에서, 프롬프트만 손보고 대화 몇 개만 눈으로 확인한 채 배포했다가 곤란했던 적이 있어요. 엔지니어 입장에서는 “도구 호출이 성공했다”로 보였지만, 실제로는 사용자가 원한 답이 아니었던 케이스가 여럿이었거든요.
Hamel Husain과 Shreya Shankar는 이 문제를 정확히 짚습니다. 엔지니어는 검색 오류나 도구 호출 실패 같은 기술적 문제를 잡아내는 데 강하고, PM은 “사용자가 기대한 결과가 실제로 나왔는가” 같은 제품 관점의 실패를 더 잘 잡아냅니다. 그래서 질문 자체를 “도구 호출이 성공했는가”가 아니라 “예약이 실제로 됐는가”로 바꾸라고 이들은 조언합니다.
결국 평가를 잘하려면 기술 이해와 제품 감각을 동시에 갖춰야 한다는 뜻이고, 저는 이게 시니어 개발자에게는 새로운 기회로 보여요. 두 역할 사이에 서 있을 수 있는 사람이 흔치 않으니까요.
한국 채용시장에서 지금 준비할 수 있는 것
아직 국내에 “Evals 엔지니어”라는 직군이 따로 자리 잡았다고 말하기는 어렵습니다 — 이 부분은 제 관찰이고, 통계로 확인된 사실은 아니에요. 다만 원문에서 소개하는 AI Evals 강의가 4,500명 넘는 수강생과 500개 넘는 기업 소속 참가자를 모았다는 점은, 이 역량을 배우려는 수요가 실제로 존재한다는 신호로 읽을 수 있습니다.
지금 당장 할 수 있는 준비는 거창하지 않아요. 담당 중인 AI 기능의 실패 사례 20~50개를 직접 눈으로 읽어보는 것부터 시작하면 됩니다. 이 습관 자체가, 다음 이력서나 면접에서 “AI 제품 품질을 직접 들여다본 경험”이라는 한 줄을 채워줄 수 있어요.
이 스킬, 지금 배워야 할까 — 판단 체크리스트
모든 개발자가 당장 Evals 전문가가 될 필요는 없습니다. 아래 체크리스트로 지금 우선순위를 가늠해 보세요.
- 담당 서비스에 LLM 응답을 다루는 기능이 있다 → 지금 에러 분석을 시작하는 게 낫습니다.
- 실패 사례가 쌓이는데 아직 아무도 정기적으로 들여다보지 않는다 → 우선순위 1순위입니다.
- 이미 QA·PM 역할이 뚜렷하게 나뉘어 있다 → “선한 독재자” 역할을 누가 맡을지부터 팀에서 정하세요.
- 트래픽이 적고 아직 실험 단계다 → 자동화 평가 도구보다 수동 리뷰가 먼저입니다.
이 글만으로 Evals를 전부 이해하긴 어렵습니다. 원문이 다루는 질문이 40개가 넘거든요. 다만 “평가는 벤치마크가 아니라 조직의 습관”이라는 핵심만 기억해도, 다음에 관련 채용 공고나 프로젝트 요구사항을 봤을 때 낯설지 않을 거예요.
관련 글
- AI가 코드를 얼마나 잘 짜는지보다 “개발자 실력을 어떻게 재는가”라는 기준 자체가 바뀌고 있다는 이야기는 개발자 실력을 재는 기준, AI 시대에 완전히 달라졌다에서 더 다뤘습니다.
- LLM을 어떻게 학습하고 활용하는지가 시니어와 주니어를 가르는 지점이라는 분석은 LLM 학습법, 시니어 개발자가 남들과 다르게 쓰는 이유에서 확인할 수 있습니다.
- AI 도구 선택이 실무 효율에 미치는 영향이 궁금하다면 AI 코딩 에이전트 언어 선택, ‘동적 언어가 유리하다’는 통념이 깨졌습니다도 참고해 보세요.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요