Evals Are Not Unit Tests - Ido Pesok, Vercel v0

영상 링크: Evals Are Not Unit Tests — Ido Pesok, Vercel v0
채널명: AI Engineer

Evals는 단위 테스트가 아니다 — Ido Pesok, Vercel v0 핵심 요약

• 영상 제목: Evals는 단위 테스트가 아니다 — Ido Pesok, Vercel v0
• Vercel의 엔지니어 Ido Pesok이 Vercel v0의 AI 기반 개발 플랫폼과 신규 기능(GitHub 연동, 1억 메시지 돌파 등)을 간략히 소개함.
• 발표의 주된 목표는 AI 앱 개발에서의 ‘Eval’(모델 평가)의 실제적 의미와 적용법을 현업 개발자 시각에서 설명하는 것임.
• 연구실‧모델 배포 측면의 “eval”이 아니라, 앱 사용자·프로덕션 데이터 관점에서 eval의 필요성과 설계 방법을 중점적으로 다룸.
• “Fruit Letter Counter”라는 엉뚱한 예시 앱을 만들어, LLM의 출력 일관성 실패(예: ‘strawberry’ ‘R’ 개수 오답) 경험담을 공유함.
• LLM은 데모 시에는 잘 동작해도 실제 배포 환경에선 다양한 예외 입력에 취약해, 전통적 유닛 테스트로는 한계가 드러남을 강조.
• 개선 시도(프롬프트 엔지니어링, 반복 테스트 등)로도 예외 케이스가 계속 발생함을 예시로 설명.
• ‘농구 코트’ 시각화로 데이터와 평가의 구조(데이터=코트 내 점, 평가=슛, 성공/실패=점수)를 설명하며, “코트의 경계와 범위” 파악의 중요성 강조.
• Eval 작성을 위한 데이터 수집, 케이스 선정, 점수화 및 실무 적용법에 대한 구체적 방법을 안내함.
• 실제 개발에서 evals를 CI에 통합하여, 팀 내 개선점 확인·회귀 방지·품질 향상 등에 필수 도구로 삼을 것을 결론으로 제시함.

세부 요약 - 주제별 정리

Vercel v0와 프로젝트 소개, 그리고 신규 GitHub 연동 기능 발표

• 발표자 Ido Pesok은 Vercel에서 v0라는 풀스택 AI 기반 개발 플랫폼을 만들고 있음.
• V0는 웹 프로토타이핑, 아이디어 실험, 빌드가 매우 쉽고 빠른 플랫폼임을 강조.
• 트위터에서 공유된 v0로 만든 다양한 쿨한 프로젝트 예시들을 소개함.
• 최근 v0의 GitHub 싱크 기능이 추가되어, 생성된 코드를 v0에서 GitHub으로 바로 푸시 가능해짐.
• GitHub 변경사항을 v0 채팅창에서 바로 불러올 수 있고, 브랜치 변경, PR 생성 등 협업 플로우도 지원함.
• v0를 통한 메시지 전송 횟수가 1억 건을 돌파했다는 성과도 공유함.

발표 의도: 응용단에서의 Eval 개념을 체계적으로 소개함

• 본 발표의 초점은 “Application layer에서의 Eval(모델 평가)” 방식에 있음.
• 모델 배포 및 연구실에서의 eval(모델 정확도, 벤치마크)이 아닌, 실제 사용자와 앱, 실데이터 환경에서 eval이 어떻게 작동하고, 왜 중요한지를 설명함.
• LLM이 실제 응용 환경에 배포될 때 필연적으로 발생할 수 있는 불확실성과 취약점 해결에 중점을 둠.

‘Fruit Letter Counter’ 앱 예시로 LLM 불확실성 이슈를 재치 있게 시연함

• “Fruit Letter Counter”라는 앱을 예시로 듦. (이름처럼, 과일명에 들어간 알파벳의 개수를 세는 앱)
• Chachi BT(=ChatGPT)로 로고를 만들고, v0로 UI와 백엔드를 제작, AI SDK를 이용해 스트림 텍스트 호출까지 간단히 구현함.
• 초기 테스트(‘How many Rs in strawberry?’ 등)에서는 GPT-4.1이 예상대로 ‘3’이라는 정답을 반환.
• 문제 없이 배포하고 트위터에 공유했으나, 바로 한 유저(John)가 “딸기에 포함된 R 개수를 물었더니 2라 답했다”며 오류를 제보함.
• 단순 앱에서도 LLM 출력이 예측 불가하고, 전형적 QA 혹은 유닛테스트(몇 번만 잘 동작하면 문제 없음)로는 문제를 발견하지 못함을 시사.

LLM 기반 앱의 불안정성과 데모/실배포 간 차이의 실전 사례 공유

• LLM 기반 앱은 ‘테스트/데모 환경’에서는 신뢰도 높아 보이지만, 실사용에선 예외적 상황·입력이 곧잘 발생.
• 특히 앱이 확장될수록(실제 유저들이 의도치 않은 입력, 엉뚱한 질문 가능성) LLM 성능의 불일치가 빈번해짐.
• “데모 세상에서는 완벽하지만 프로덕션에서는 환각(hallucination)이 찾아온다”는 농담 삽입.
• 모든 기능(예: 인증, 로그인, 로그아웃 등)을 유닛 테스트로 100% 검증해도, APP 본질의 5% 부분(LLM 핵심 질의 등)이 실패할 수 있음을 강조.

프롬프트 엔지니어링과 반복 테스트도 완전한 해결책이 아님을 강조

• 문제 해결을 위해 기존 프롬프트에서 체인 오브 쏘트 등의 기법을 도입하고 프롬프트를 세밀하게 조정함.
• 훨씬 창의적이고 설명적인 프롬프트(“너는 모험에 나선 과일사랑 AI다” 등)를 고안해 밤새 실험.
• ChatGPT에서 10회 연속 테스트를 통과했음에도, 실제 유저가 한 번 더 엉뚱한 묶음 입력을 하자 오답이 다시 발생함.
• 기존 및 새롭게 시도한 접근 모두 실전 입력을 100% 포괄하지 못함이 드러남.

‘농구 코트’ 비유로 eval 구조와 데이터 범위 파악의 필요성을 시각적으로 설명함

• 데이터=농구 코트 내 점, 평가(Task)=슛, 성공/실패=파란색(성공)/빨간색(실패)
• 쉬운 케이스(‘딸기에 R이 몇 개?’)는 쉬운 슛(바스켓 가까운 파란 점), 복잡한 예외(다수 과일명, 변형된 조건)는 난이도 높은 슛(먼 곳 빨간 점)으로 표기.
• ‘코트 밖(Out of bounds)’의 예: “당근(Carrot)에 음절이 몇 개?” 등 아예 앱 논리와 무관한 질의.
• 좋은 eval 작성은 내 앱 코트의 경계와 핵심적 영역을 파악하는 데서 시작된다고 설명함.
• eval을 쓸데없는 범위(코트 밖, 혹은 의미없는 케이스)에 적용하면 오히려 비효율적임을 지적.

실제 eval 셋을 구축할 땐, 주요 사용자 질의 및 다양한 도메인 공간을 포괄하도록 해야 함

• Eval 데이터 확보 방법:
  • 유저 피드백(thumbs up/down) 수집 — 노이즈는 있지만 오류 포착에 유용한 신호임.
  • 로그 샘플링: 무작위로 100개 정도 로그를 주기적으로 리뷰하면 실제 사용 패턴·문제 구간 파악에 효과.
  • 커뮤니티 포럼, 소셜 미디어(트위터/X 등)를 통한 문제 사례 파악 등.
• 데이터 분포가 특정 영역에 치우치지 않도록, 앱의 실제 ‘사용자 탐색 공간’ 전체를 커버할 수 있게 설계.
• 코트 시각화로 경계와 취약(실패 다발) 구간을 파악, 우선순위 개선 타겟 설정 가능.

eval 구성 시 ‘상수는 데이터, 변수는 Task(슈팅)에’ 원칙을 적용해 재사용성과 효율성 높임

• 테스트 환경 설계 시, 수식·코드 구조처럼 상수(예: 자주 활용되는 대표 질의)는 데이터에, 변수(시스템 프롬프트, 프리프로세싱/RAG 등)는 Task(슈팅)에 분리해서 설계 권고.
• 이러한 설계는 평가환경 재사용, 확장성, 명확성을 보장해줌.
• AI SDK의 미들웨어 활용: 사전처리, RAG, 프롬프트 수정 등의 로직을 미들웨어로 관리하여 API와 eval에 공유 적용 가능.
• 실전과 연습(평가코드)의 일치도가 높아야 현실적인 품질 검증·개선이 이루어진다는 점 재차 강조.

점수화(Scoring) 기준은 단순·결정론적 패스/페일에 최대한 가깝게 설계해야 디버깅 및 협업이 용이함

• 평가 스코어링은 도메인 특성에 따라 다를 수 있으나, ‘문자 개수처럼 명확한 케이스’처럼 가급적 결정적(Deterministic) 평가 방식을 택할 것 권고.
• 복잡한 텍스트 생성 등에서는 기준 만들기 어려워도, 심플하고 명료하게 점수를 메기기(예: 패스/페일)로 협업과 디버깅 효율성 확보.
• 평가 로직이 과도하게 복잡하면 팀원 간 소통과 분산 작업에 장애가 생김.
• 구조적으로 처리 어려운 경우에는 실제로 ‘휴먼 리뷰’를 포함해 신호(signal) 확보 방법을 다각적으로 적용해도 무방함.

평가 편의성을 높이기 위한 프롬프트 구조 통제, production과 eval 프롬프트 가이드

• 프롬프트에 일부 ‘답을 태그로 감싸서 출력하라’는 식의 구조화 규칙을 추가하면, 평가 자동화를 단순화할 수 있음(문자열 매칭 등).
• 단, 프러덕션 프로덕트에서는 이런 포맷을 쓰지 않도록 하고, 오직 평가용(code/test) 환경에서만 활용 권고.

평가 자동화와 CI(지속적 통합)에 evals를 포함하여 PR 시 실질적 개선점/회귀를 즉시 파악 가능함

• Brain Trust 같은 도구로 eval 리포트를 CI(테스트 자동화)에 연동하면, 코드/프롬프트 수정 시 자동으로 평가 리포트가 생성되어 개선·회귀 상황을 명확히 확인 가능.
• 예를 들어, 프롬프트 일부 변동 후, 농구코트(데이터스페이스) 전체에서 파란 점이 얼마나 늘었는지 등 시각적으로 확인 가능.
• 전체 시스템에서 어느 파트(데이터 영역)에 개선·악화가 있었는지 팀 전체 공유 가능, 실질적인 품질 지표로 삼을 수 있음.

지속적 연습(평가) 실행이 성능 관찰, 문제 탐지, 장기 품질 개선의 핵심임

• 농구 연습 비유: 선수는 90% 성공한다고 해도 어떤 영역에서 더 실패를 많이 하는지 반복적 관찰이 필수.
• 실제 서비스에서는 조기·정기적으로 반복평가(e.g. 매일)하여 성능 저하나 새로운 취약점이 생겼는지 확인해야 함.
• 동일 질문을 여러 번 번갈아 테스트해(예: 5회 중 4회 성공률), 확률적 오류도 파악 가능.

eval을 핵심 프로세스로 삼아야 LLM 앱 신뢰성·품질·운영 효율성을 끌어올릴 수 있음을 강조하며 마무리함

• 평가(evals)는 LLM 기반 앱의 ‘연습장’, 데이터의 중심, 개선을 측정하는 유일한 지표이므로 필수적임을 재확인.
• 모델 교체, 시스템 프롬프트·RAG 변경 등에도 ‘연습(평가) 데이터셋’을 일관적으로 적용해 변화폭을 정량적으로 파악 가능.
• 측정 없는 개선은 불충분하며, eval이 개선 효과 측정의 ‘명확성’을 제공함.
• 향상된 eval 관리가 곧 더 높은 신뢰성, 전환율/재방문율, 개발‧운영 효율성이라는 실질적 가치로 이어짐.
• 농구코트 시각화 앱 자체도 v0로 작성했음을 덧붙이며 발표를 종료함.

Q&A 세션에서 eval의 반복실행/성능관찰 방법에 대한 실무 팁 공유

• 실무에서는 평가를 매일(혹은 정기적으로) 반복 실행해 최근 성능, 회귀/개선 여부를 빠르게 파악.
• 동일 질문을 여러 번 실행(5회 등)해 변동폭, 성공률을 포착해 확률적 취약점도 함께 진단 가능.
• 끊임없는 반복과 데이터 모니터링이 LLM 기반 시스템 품질관리의 핵심임을 재강조.