AI를 써먹기 위한 최소 지식 7편: Eval과 검증
AI 출력과 에이전트 작업 결과를 검증하기 위한 Eval 개념, 테스트 케이스, 체크리스트, 회귀 방지 흐름을 정리합니다.
목차
지난 글에서는 AI가 tool을 호출하고 Agent처럼 작업하는 흐름을 정리했습니다.
그럼 이제 가장 중요한 질문이 남습니다.
"AI가 한 작업을 어떻게 믿을 수 있을까?"
여기서 필요한 게 Eval과 검증입니다.
AI 결과물을 그냥 읽고 "괜찮아 보이네"로 끝내면 위험합니다. 특히 코드 수정, 배포, 공개 발행처럼 실제 결과가 남는 작업은 더 그렇습니다.
검증은 AI 답변 이후에 시작된다
AI가 답을 줬다고 일이 끝난 건 아닙니다.
개발 작업에서는 보통 그 다음이 진짜입니다.
AI 제안
-> diff 확인
-> 테스트 실행
-> 로컬/프리뷰 확인
-> 운영 영향 확인
-> 결과 기록이 과정이 있어야 AI를 개발 흐름에 넣을 수 있습니다.
AI를 믿는다는 건 아무 검증 없이 맡긴다는 뜻이 아닙니다.
검증 가능한 작업 단위로 나누고, 결과를 확인할 수 있게 만든다는 뜻에 가깝습니다.
Eval은 반복 작업에서 특히 중요하다
한 번 쓰고 끝나는 작업은 사람이 직접 보면 됩니다.
하지만 반복되는 작업은 기준이 필요합니다.
예를 들어 반복적으로 콘텐츠 초안을 만든다면, 매번 이런 질문을 해야 합니다.
| 항목 | 확인 질문 |
|---|---|
| 중복 | 기존 글과 주제가 겹치지 않는가 |
| 상태 | status가 draft인가 |
| 언어 | KO/EN 같은 slug로 생성됐는가 |
| 공개 노출 | 초안이 공개 목록이나 검색 색인에 들어가지 않았는가 |
| 품질 | 글이 너무 일반론으로 흐르지 않았는가 |
| 보고 | 프리뷰 URL과 검증 결과가 전달됐는가 |
이걸 매번 눈으로만 보면 놓칩니다.
그래서 자동 검사와 사람 검토를 나눠야 합니다.
자동으로 볼 수 있는 것과 사람이 봐야 하는 것
모든 검증을 자동화할 수는 없습니다.
하지만 자동화할 수 있는 건 꽤 많습니다.
| 자동 검증 가능 | 사람 검토 필요 |
|---|---|
| 파일 존재 여부 | 글의 재미와 설득력 |
| frontmatter 형식 | 어투가 자연스러운지 |
| slug 중복 | 공개해도 민감하지 않은지 |
| 테스트 통과 | 결론이 납득되는지 |
| 공개 노출 여부 | 예시가 적절한지 |
| 링크 200/404 | 시리즈 흐름이 좋은지 |
AI 작업을 안정화하려면 자동 검증 가능한 부분은 최대한 기계에게 맡기고, 사람은 판단이 필요한 부분에 집중하는 게 좋습니다.
작은 Eval 세트부터 만든다
처음부터 거대한 평가 시스템이 필요하지는 않습니다.
작은 체크리스트도 Eval입니다.
예를 들어 AI 기초 연재 글을 검토한다면:
1. 이전 편과 자연스럽게 이어지는가
2. 이번 편의 핵심 개념이 하나로 명확한가
3. 코드/표/예시 중 최소 하나가 있는가
4. 다음 편 예고가 실제 다음 글과 맞는가
5. 공개 글에 내부 작업 흔적이 없는가이 기준을 매번 적용하면 글 품질이 일정해집니다.
코드 작업도 마찬가지입니다.
1. 요청한 파일만 수정했는가
2. unrelated change를 건드리지 않았는가
3. 테스트가 통과했는가
4. 실패 케이스를 설명했는가
5. 남은 위험을 보고했는가이런 기준이 쌓이면 AI 작업을 훨씬 안정적으로 운영할 수 있습니다.
좋은 Eval은 실패 조건도 같이 정한다
Eval을 만들 때 성공 조건만 적으면 반쪽짜리가 됩니다.
예를 들어 "링크가 정상이어야 한다"는 기준은 좋습니다. 하지만 더 중요한 건 실패했을 때 어떻게 할지도 정해두는 것입니다.
링크 200 확인 성공 -> PASS
링크 404 발견 -> FIX
민감한 정보나 의도하지 않은 공개 노출 발견 -> STOP이렇게 나눠두면 AI가 결과를 보고 다음 행동을 고르기 쉬워집니다.
저는 검증 결과를 보통 세 가지로 나누는 편이 좋다고 봅니다.
| 결과 | 의미 | 다음 행동 |
|---|---|---|
| PASS | 기준을 통과함 | 다음 단계로 진행 |
| FIX | 수정하면 해결 가능함 | 수정 후 다시 검증 |
| STOP | 사람이 봐야 할 위험이 있음 | 중단하고 보고 |
중요한 건 STOP 조건입니다.
테스트 실패처럼 고치면 되는 문제는 FIX로 충분합니다. 하지만 공개되면 안 되는 정보, 의도하지 않은 삭제, 운영 데이터 영향처럼 되돌리기 어려운 건 자동으로 밀어붙이면 안 됩니다.
회귀 방지가 중요하다
AI는 빠르게 수정안을 만들 수 있습니다.
그런데 빠르게 바꾼다는 건 빠르게 깨뜨릴 수도 있다는 뜻입니다.
그래서 회귀 방지가 중요합니다.
예를 들어 정적 콘텐츠 생성 흐름을 고쳤다면 최소한 이런 검사를 해야 합니다.
1. 정적 페이지 생성 명령이 성공하는가
2. 공개 산출물에 초안 식별자가 없는가
3. 공개 글 URL은 정상 응답하는가
4. 초안 글 URL은 외부에서 열리지 않는가여기서 기대는 명확합니다.
published 글: 200
draft 글: 404
RSS/sitemap/공개 데이터: draft slug 없음이처럼 기대 결과가 명확한 검사는 자동화하기 좋습니다.
검증 명령은 거창할 필요가 없습니다.
처음에는 아래처럼 단순해도 됩니다.
생성 명령 성공 여부 확인
공개 HTML에서 특정 slug 확인
sitemap에 공개 글만 있는지 확인
공개 URL이 200인지 확인
노출되면 안 되는 키워드가 없는지 검색이런 검사가 쌓이면 나중에는 "AI가 잘했는지"를 감으로만 보지 않아도 됩니다. 최소한 깨지면 안 되는 기준은 기계적으로 잡을 수 있습니다.
AI 평가도 버전 관리가 필요하다
Eval 기준도 바뀝니다.
처음에는 "파일이 생겼는가"만 봐도 충분할 수 있습니다.
나중에는 이런 기준이 추가될 수 있습니다.
- 글이 너무 짧지 않은가
- 시리즈 번호가 연속적인가
- 한국어/영어 제목이 같은 의미인가
- 외부 최신 사실은 공식 출처로 확인했는가
- 보안/비용 관련 표현이 과장되지 않았는가이 기준은 문서나 스크립트로 남겨야 합니다.
그래야 나중에 AI에게도 같은 기준으로 작업을 시킬 수 있습니다.
정리하면
AI를 실무에 붙이려면 검증 기준이 필요합니다.
Eval은 거창한 연구용 평가만 뜻하지 않습니다.
반복 작업의 품질을 지키기 위한 기준과 절차입니다.
1. AI 답변 이후에 검증이 시작된다.
2. 반복 작업에는 Eval 기준이 필요하다.
3. 자동 검증과 사람 검토를 나눠야 한다.
4. 작은 체크리스트도 Eval이다.
5. 회귀 방지 검사는 명령어로 고정하는 편이 좋다.다음 글에서는 마지막으로, AI에게 tool과 agent 권한을 줄 때 어디까지 허용해야 하는지 권한 경계와 보안 관점에서 정리해보겠습니다.
댓글
0