01 · eval은 다시 실행할 수 있는 평가다
AI가 코드를 잘 쓴다는 인상만으로 도입 효과를 판단하기는 어렵습니다. 같은 과제에 다른 실행 결과가 나올 수 있고, 쉬운 예시만 고르면 실패가 숨겨집니다. eval은 입력 과제, 실행 조건, 채점 규칙과 결과 기록을 묶어 변경 전후를 비교하는 평가 절차입니다.
Anthropic의 2026년 평가 가이드는 과제, 반복 실행, 평가기, 실행 기록과 최종 결과를 구분하며 여러 평가 방식을 조합할 것을 설명합니다. 모델의 응답만 읽는 것보다 실제 환경의 결과를 살펴야 한다는 것이 핵심입니다. 아래는 교육용 코드 수정 평가의 구체적인 설계 예시입니다.
02 · 작은 실패 모음부터 시작한다
처음에는 실제로 겪은 문제 다섯 개를 모아 봅니다. 공백 처리, 날짜 경계, 권한 없는 접근, 데이터 없는 화면, 저장 실패처럼 유형을 나눕니다. 각 과제에는 시작 코드, 재현 입력, 기대 결과, 허용 변경 범위를 준비합니다. 정상 예시도 넣어 기존 기능을 망가뜨리는지 확인합니다.
학습용 과제와 최종 확인용 과제를 구분하세요. 프롬프트를 수정할 때마다 정답까지 본 동일 사례만 반복하면 그 예시에 맞춘 개선일 수 있습니다. 보지 않은 변형 입력으로 마지막 검사를 하면 일반화 여부를 조금 더 분명히 볼 수 있습니다. 적은 사례의 결과를 전체 개발 능력으로 확대 해석하지 않습니다.
03 · 기계 검증과 사람 검토의 역할
반환 값, HTTP 상태, 저장 결과, 파싱 성공 여부는 자동 검사에 잘 맞습니다. 유지보수성이나 화면의 읽기 순서는 기준을 적은 리뷰가 필요합니다. AI 리뷰를 보조로 쓰더라도 근거 파일과 재현 경로를 요청하고 실제 실행으로 확인하세요. 보안 문제를 없다고 말한 것만으로 안전을 증명할 수는 없습니다.
평가기에 주는 기준도 검토 대상입니다. 테스트를 삭제해 실패가 사라졌거나 특정 입력만 하드코딩했다면 의도한 해결이 아닙니다. 기능 결과와 변경 적절성을 별도로 봅니다. 리뷰 의견은 중요도, 근거, 사용자 영향, 재현 방법을 갖추게 하면 사람이 우선순위를 결정하기 쉽습니다.
04 · 반복 실행을 공정하게 만들기
매 실행은 같은 시작 코드와 격리된 테스트 데이터로 시작합니다. 이전 실행의 수정 파일이나 저장 상태가 다음 실행을 돕지 않게 정리합니다. 모델과 도구 버전, 시간 한도, 제공 문서, 실행 횟수를 함께 기록합니다. 조건이 다르면 별도 실험으로 표시합니다.
이 학습 과제에서는 각 문제를 세 번 실행해 성공 횟수와 실패 종류를 남겨 봅니다. 세 번이라는 수는 통계적 보증이 아니라 반복 변동을 관찰하기 위한 작은 시작점입니다. 평균 점수 외에도 항상 실패하는 문제와 가끔 실패하는 문제를 나누어 보면 다음 개선 대상을 고르기 쉽습니다.
05 · 실패를 다음 개발 입력으로 바꾸기
실패 원인을 요구 해석, 파일 탐색, 구현, 도구 실행, 검증 누락으로 분류해 봅니다. 테스트 서버가 뜨지 않은 실행을 모델의 코드 오류와 같은 칸에 넣으면 원인을 잘못 판단할 수 있습니다. 평가 환경 장애는 따로 기록하고, 재실행했다면 그 사실도 남깁니다.
최종 보고서에는 성공률 하나 대신 과제 수, 실행 조건, 실패 사례, 사람이 수정한 부분을 넣어 보세요. 학생은 이런 기록으로 문제 해결 과정을 보여 줄 수 있고, 주니어 개발자는 팀의 AI 리뷰 도입을 작은 실험으로 제안할 수 있습니다. 모델을 교체하거나 프롬프트를 바꾸면 같은 평가를 다시 실행해 개선과 퇴행을 함께 살핍니다.