AI 프롬프트 평가 만들기 — 정성껏 100개보다 대충 1,000개

프롬프트를 다듬고 나면 늘 같은 지점에서 막힙니다. "그래서 좋아진 게 맞나?" 답 몇 개 눈으로 보고 "이게 더 나은 것 같은데" 하고 넘어가죠. 그런데 다음 주에 다시 고칠 때는 지난번이 얼마나 좋았는지 기억이 안 납니다. 공식 문서에 평가를 만드는 법이 정리돼 있는데, 세 가지 원칙 중 하나가 직관과 정면으로 어긋납니다 — 사람이 공들여 채점한 적은 문항보다, 신호가 좀 흐려도 자동으로 채점한 많은 문항이 낫다는 겁니다.

📌 30초 요약

• 양이 질을 이깁니다. 손으로 채점한 100개보다 자동 채점한 1,000개.
• "좋은 답"은 기준이 아닙니다. 숫자로 바꿔야 기준이 됩니다.
• 한 가지 지표로는 부족합니다. 대부분 여러 축을 같이 봐야 합니다.
• 채점 방법마다 필요한 문항 수가 다릅니다. 50개부터 500개까지.
• 채점하는 모델은 답을 만든 모델과 달라야 합니다.

1. 고치려면 먼저 재야 합니다

문서가 제시하는 설계 원칙은 셋입니다. 첫째 실제 쓰임새를 닮게 만들 것. 시험 문항이 우리 서비스에 실제로 들어오는 요청 분포를 반영해야 한다는 뜻입니다. 그러면서 엣지 케이스를 잊지 말라고 덧붙입니다.

문서가 든 엣지 케이스 목록이 실용적입니다 — 관련 없거나 아예 존재하지 않는 자료가 들어올 때, 입력이 터무니없이 길 때, 사용자가 험하거나 엉뚱한 말을 할 때, 그리고 마지막 하나가 특히 눈에 띕니다: 사람끼리도 판단이 갈릴 만큼 애매한 경우. 이걸 시험에 넣어 두라는 겁니다. 실제 서비스에서 사고는 늘 이런 데서 터지니까요.

둘째는 가능하면 자동으로 채점되게 문제를 설계하라는 것입니다. 객관식으로 만들거나, 문자열이 맞는지 비교하거나, 코드로 검사하거나, AI에게 채점을 맡기거나. 그리고 셋째가 이 글의 주인공입니다.

2. 정성껏 100개보다 대충 1,000개

문서의 표현을 그대로 옮기면 이렇습니다 — "신호가 조금 약한 자동 채점이라도 문항이 많은 쪽이, 사람이 손으로 정성껏 채점한 적은 문항보다 낫다." 품질 관리라고 하면 보통 꼼꼼함을 떠올리는데 정반대를 권하는 셈이죠.

이유는 통계입니다. 문항이 100개면 한두 개 결과가 뒤집히는 것만으로도 점수가 출렁입니다. 그래서 프롬프트를 고쳤을 때 나온 1~2%의 변화가 진짜 개선인지 우연인지 구분이 안 됩니다. 반면 1,000개면 채점이 좀 거칠어도 평균이 안정돼서 작은 차이도 신호로 잡힙니다. 개별 판정의 정확도를 조금 잃고 전체의 신뢰도를 크게 버는 거래죠.

현실적인 조언으로 바꾸면 — 완벽한 정답지를 만들려다 시작을 미루지 마세요. 거칠어도 자동으로 돌아가는 평가를 먼저 세우고, 문항을 늘리는 데 힘을 쓰는 편이 낫습니다. 이 블로그에서 한국어 토큰이 정말 몇 배나 더 드는지 직접 재봤을 때도 결론은 같았습니다 — 떠도는 숫자보다 내가 돌려 본 표본이 정확합니다.

3. "좋은 답"은 기준이 아닙니다

평가를 만들기 전에 무엇을 성공이라 부를지부터 정해야 합니다. 문서는 이걸 구체적·측정 가능·달성 가능·목적에 맞을 것으로 정리합니다. 핵심은 측정 가능입니다.

윤리나 안전처럼 흐릿해 보이는 것도 숫자로 바꿀 수 있다며 문서가 예를 듭니다. "안전한 출력"은 나쁜 기준이고, "1만 번 시도 중 유해 판정이 0.1% 미만"이 좋은 기준입니다. 전자는 회의실에서 끝나고, 후자는 이번 주에 좋아졌는지 알려 줍니다.

그리고 지표 하나로는 대개 부족합니다. 문서가 든 예를 보면 한 기능에 네 축이 동시에 붙습니다 — 정확도 지표가 일정 수준 이상, 출력의 99.5%가 무해, 오류가 나더라도 90%는 치명적이지 않고 불편한 수준, 응답의 95%가 0.2초 안에. 정확도만 올리다 응답이 느려지거나, 빠르게 만들다 품질이 무너지는 걸 막으려면 애초에 여러 축을 함께 걸어 두는 수밖에 없습니다.

4. 채점 방법 다섯과 필요한 문항 수

채점 방법이 여럿이고, 방법마다 의미 있는 결과를 내려면 필요한 문항 수가 다릅니다. 이 대응표가 실무에서 가장 쓸모 있습니다.

채점 방법	언제 쓰나	권장 문항
정확히 일치	답이 딱 떨어질 때(분류·판정)	제한 없음
뜻이 얼마나 가까운지	표현이 달라도 같은 답이어야 할 때	50개 이상
정답 요약본과 겹침 정도	요약 품질을 볼 때	200개 이상
AI가 1~5점 매기기	말투·공감처럼 주관적인 것	100개 이상
AI가 예/아니오 판정	미묘하거나 암시적인 위반 잡기	500개 이상

⚠️ 자기 답을 자기가 채점하게 두지 마세요

AI에게 채점을 맡기는 세 방법 모두에 문서가 같은 단서를 붙였습니다 — 채점하는 모델은 답을 만든 모델과 다른 것을 쓰라는 것입니다. 같은 모델에게 맡기면 자기 문체와 판단 습관을 후하게 볼 여지가 생기니까요. 편하다고 한 모델로 생성과 채점을 돌리면 점수는 잘 나오는데 사용자 반응은 그대로인 상황이 만들어집니다.

같은 이유로 남이 만든 비교표도 그대로 믿기 어렵습니다. 어떤 문항으로 어떻게 채점했는지가 결과를 좌우하니까요. 도구 비교글을 믿기 전에 직접 확인해 본 적이 있는데, 결론은 늘 같습니다 — 내 작업으로 내가 돌려 봐야 내 답이 나옵니다.

5. 자주 묻는 질문 (FAQ)

Q. 1인 개발인데 1,000개를 어떻게 만드나요?

직접 쓰지 마세요. 실제로 들어온 요청 기록이 가장 좋은 재료입니다. 로그에서 뽑아 개인정보만 지우면 곧바로 문항이 됩니다. 아직 서비스 전이라면 AI에게 다양한 변형을 만들게 하고, 엣지 케이스만 손으로 몇 개 끼워 넣으세요.

Q. 채점까지 AI에게 맡기면 돈이 많이 들지 않나요?

채점은 대개 짧은 판정 하나라 생성보다 훨씬 쌉니다. 그리고 채점에는 가벼운 모델을 써도 되는 경우가 많습니다. 정 부담되면 매번 전부 돌리지 말고 프롬프트를 고친 날에만 전체를 돌리는 식으로 주기를 나누세요.

Q. 목표 점수는 몇 점으로 잡아야 하나요?

문서는 업계 수치나 앞선 실험, 전문가 판단에 근거해 잡으라고 합니다. 중요한 단서가 하나 붙는데 — 지금 최고 성능 모델도 못 하는 수준을 목표로 잡지 말라는 것입니다. 첫 목표는 현재 값보다 조금 높게 잡고 올려 가는 편이 현실적입니다.

Q. 사람이 보는 건 아예 필요 없나요?

그런 뜻은 아닙니다. 문서도 정성적 척도를 정량 지표와 "함께" 쓰라고 합니다. 다만 사람의 시간은 채점이 아니라 설계에 쓰는 게 낫습니다 — 어떤 엣지 케이스를 넣을지, 어떤 축으로 성공을 정의할지 같은 데요. 채점 자체는 기계에 맡기세요.

✨ 정리하면

프롬프트를 고쳤는데 좋아졌는지 모르겠다면 평가가 없는 것입니다. 셋만 기억하세요 — 완벽한 100개보다 거친 1,000개, "좋은 답" 대신 숫자로 된 기준, 채점 모델은 생성 모델과 다른 것. 그리고 사람의 시간은 채점이 아니라 설계에 쓰세요. AI에 드는 돈이 새는 자리를 순서대로 훑고 싶다면 AI 지출 관리 허브에, 국내 AI 서비스 흐름은 전 국민 무료 AI 사업 정리에 담아 뒀습니다.

※ 2026년 9월 기준 공식 문서(평가 설계·성공 기준 안내)를 바탕으로 정리했습니다. 채점 방법별 권장 문항 수는 문서가 제시한 기준이며 작업 성격에 따라 달라질 수 있습니다. FAQ의 "로그에서 문항을 뽑는다", "채점은 가벼운 모델로도 된다"는 부분은 동작 원리에 근거한 권고입니다.