| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- 무료 ai
- ai 뉴스
- claude code
- 개발 생산성
- claudecode
- ai에이전트
- AI 코딩
- 개발자 도구
- 클로드코드
- AI 에이전트
- OpenAI
- Android
- 바이브코딩
- 카드 없이
- 개발환경
- 클로드 API
- 홍드로이드
- 안드로이드 스튜디오
- AI 에이전트 개발
- 무료 LLM
- Claude
- LLM
- 안드로이드
- 무료로 시작하기
- 실무
- MCP
- Gemini
- 자동화
- 오픈모델
- Android Studio
- Today
- Total
홍드로이드의 야매코딩
AI 평가 기준 만들기 — 적게 정성껏보다 많이 자동이 낫습니다 본문

프롬프트를 고쳤는데 정말 나아진 건지 확신이 안 서는 순간이 옵니다. 몇 개 돌려보고 "좋아진 것 같은데" 하고 넘어가게 되죠. 공식 지침에 이 문제를 다룬 문서가 있는데, 첫 원칙이 통념과 정반대였습니다 — 신호가 좀 약하더라도 자동 채점으로 많이 돌리는 게, 사람이 손으로 정성껏 채점한 소수보다 낫다는 것. 그리고 만든 모델로 채점하지 말라는 경고가 반복해서 나옵니다. 정리했습니다.
📌 30초 요약
- ★★양이 질을 이깁니다 — 문서가 대놓고 그렇게 적어뒀습니다.
- ★애매한 것도 숫자로 바꿀 수 있습니다.
- ★만든 모델로 채점하지 마세요 — 순환 편향입니다.
- ⚠️ 채점 방식마다 못 보는 게 따로 있습니다.
- 지표 하나로는 부족합니다 — 여러 축을 동시에.
- 사람도 의견이 갈릴 사례를 일부러 넣으세요.
적게 정성껏보다 많이 자동이 낫습니다
문서가 첫 원칙으로 내세우는 문장이 "신호가 약간 떨어지더라도 자동 채점으로 문항을 많이 두는 편이, 사람이 손으로 채점한 고품질 소수보다 낫다"입니다. 보통은 반대로 생각하죠 — 정성껏 만든 몇 개가 대충 만든 수백 개보다 믿을 만하다고요.
이유는 반복 가능성에 있습니다. 손으로 채점하면 프롬프트를 고칠 때마다 다시 사람이 붙어야 하니 사실상 한두 번밖에 못 돌립니다. 자동이면 고칠 때마다 즉시 다시 돌려볼 수 있고요. 측정이 싸야 자주 측정하게 되고, 자주 측정해야 개선이 됩니다. 표본 크기 감각도 문서 예시에서 읽을 수 있는데, 자동 채점이면 수백에서 수천 건, 사람이 볼 거면 쉰에서 백 건 남짓 정도로 자릿수가 다릅니다.
애매한 것도 숫자로 바꿉니다
"이건 주관적이라 못 재"라고 넘기기 쉬운 것들이 있죠. 문서는 윤리나 안전처럼 흐릿한 주제도 수치화할 수 있다고 못 박습니다. 비교 예시가 인상적이에요 — "안전한 출력"은 나쁜 기준이고, "만 번 시도 중 걸러진 것이 0.1% 미만"이 좋은 기준입니다.
여기에 조건이 둘 붙습니다. 첫째, 달성 가능해야 합니다. 업계 수치나 앞선 실험, 전문가 판단을 근거로 목표를 잡으라는 것 — 지금 가장 앞선 모델도 못 하는 수준으로 잡으면 영원히 실패합니다. 둘째, 기준은 용도마다 다릅니다. 문서 표현으로는 출처 정확도가 의료 앱에는 결정적이지만 가벼운 잡담 봇에는 덜 중요하다는 식이죠. 도구를 여럿 놓고 비교할 때도 같습니다 — 무엇을 잴지부터 정해야 비교가 됩니다.
✅ 지표 하나로는 부족합니다
문서의 좋은 예시는 네 축을 한꺼번에 겁니다 — 정확도, 유해 출력 비율, 오류가 났을 때 그게 불편한 수준인지 심각한 수준인지, 그리고 응답 속도. 정확도만 올리다가 느려지거나 위험해지는 걸 막으려면 여러 축을 같이 봐야 한다는 거죠. 특히 오류의 "심각도"를 따로 재는 발상은 실무에서 바로 쓸 만합니다.
채점 방식마다 못 보는 게 있습니다
자동 채점을 권하지만, 어떤 방식도 만능이 아니라는 걸 방식마다 짚어 둡니다. 무엇을 재려는지에 따라 골라야 해요.
| 채점 방식 | 못 보는 것 |
|---|---|
| 정답과 그대로 맞추기 | 분류에만 쓸 수 있고 같은 뜻 다른 말을 놓칩니다 |
| 의미가 얼마나 가까운지 | 뜻은 잡아도 사실이 맞는지는 못 봅니다 |
| 표현이 얼마나 겹치는지 | 원문을 베끼면 높게 나오지만 틀릴 수 있습니다 |
| 다른 모델에게 채점시키기 | 미묘함을 잡지만 편향이 섞이고 지시문을 잘 짜야 합니다 |
셋째 줄이 특히 함정입니다. 요약문이 원문 표현을 그대로 가져다 쓰면 겹침 점수는 높게 나오는데 내용은 틀릴 수 있어요. 점수가 올라갔다고 좋아졌다고 볼 수 없다는 뜻이죠. 그리고 넷째 줄에는 문서가 매번 반복하는 경고가 붙습니다 — 결과를 만든 모델과 채점하는 모델을 다르게 쓰라는 것. 같은 모델로 채점하면 자기 답을 자기가 좋다고 하는 순환 구조가 됩니다. 대신 비용과 시간이 더 든다는 대가가 따르고요. 모델을 무료로 여러 개 가져다 쓸 수 있는 곳을 알아두면 이 채점용 모델을 마련하기가 한결 수월합니다.
일부러 어려운 사례를 넣으세요
평범한 질문만 모아 놓으면 실제로 터지는 지점을 못 찾습니다. 문서가 꼽는 어려운 사례가 넷인데, 마지막이 특히 흥미롭습니다.
관련 없거나 아예 존재하지 않는 자료를 줬을 때, 지나치게 긴 입력이 들어왔을 때, 대화형이라면 나쁘거나 엉뚱한 말을 걸었을 때. 그리고 사람끼리도 판단이 갈릴 만큼 애매한 사례. 마지막 것을 넣으라는 게 재밌는데, 정답이 하나로 안 정해지는 구간에서 결과가 어떻게 나오는지를 봐야 실제 성격을 알 수 있기 때문이죠.
마지막으로 하나 더. 문서가 "따로 떼어둔 시험용 묶음"을 계속 언급합니다. 풀어 말하면 프롬프트를 다듬을 때 쓴 자료로 평가하지 말라는 뜻이에요. 같은 문제로 연습하고 같은 문제로 시험 보면 점수가 오르는 게 당연하니까요. 형식을 예시로 고정할 때도 마찬가지입니다 — 예시로 쓴 사례는 평가에서 빼세요.
🔁 채점을 자동으로 돌릴 자리라면
평가를 많이, 자동으로 돌리기로 했다면 돌리는 환경도 함께 정하셔야 합니다. 제한 모드가 정확히 이 용도로 만들어졌습니다 — 채점 장치가 공용 기계에서 돌 때 명령이 실행되지 않고 그 기계의 설정도 읽지 않게 하는 겁니다. 남의 코드를 돌려 보는 자리라면 특히 그렇고요. 다만 붙여 둔 외부 도구 서버는 이 잠금 밖이라 명령을 대신 실행해 주는 서버가 있으면 통로가 열려 있습니다. 채점 파이프라인을 짤 때 이 한 줄을 세트로 넣어 두세요.
🔁 자동에도 멈추는 지점이 있습니다
적게 정성껏보다 많이 자동이 낫다는 쪽을 봤는데, 그 자동에도 한계선이 그어져 있습니다. 한도 자동 대기는 한도에 걸리면 알아서 기다렸다 이어 가지만 이어가다 다시 걸리면 연달아 두 번까지만 시도하고 멈춥니다. 또 사람 없이 돌아가는 것을 허락하는 값이라 간단한 한 줄 형태로는 끌 수만 있고 다시 켤 수는 없습니다. 자동을 늘릴수록 「어디서 멈추게 되어 있는지」를 함께 세어 두는 것이 결국 자동화의 값을 지킵니다.
자주 묻는 질문 (FAQ)
Q. 개인이 쓰기엔 과한 이야기 아닌가요?
규모는 줄이되 원칙은 그대로 쓸 수 있습니다. 자주 쓰는 작업 열 개쯤을 파일로 모아두고, 프롬프트를 고칠 때마다 같은 열 개를 다시 돌려보는 것만으로도 감이 아니라 비교가 됩니다.
Q. 채점용 모델은 꼭 달라야 하나요?
문서가 일반적인 모범 사례로 제시합니다. 형식이 맞았는지처럼 기계적으로 확인되는 항목은 코드로 채점하면 이 문제가 아예 없고요. 품질·어조처럼 판단이 들어가는 항목에서만 다른 모델이 필요합니다.
Q. 점수를 매기게 할까요, 통과/실패로 할까요?
둘 다 문서에 나옵니다. 단계 점수는 미묘한 차이를 담지만 편향이 섞이고, 통과/실패는 해석이 쉬운 대신 은근한 위반을 놓칩니다. 무엇을 놓치면 곤란한지로 고르세요.
Q. 목표 수치는 어떻게 정하나요?
문서는 업계 수치·앞선 실험·전문가 판단을 근거로 삼으라고 합니다. 아무 근거 없이 높게 부르면 가장 앞선 모델로도 못 넘는 선이 되어버려요. 첫 측정값을 기준선으로 잡고 조금씩 올리는 것도 방법입니다.
✨ 정리하면
평가를 만드는 일의 핵심은 "정확하게 재기"가 아니라 "자주 잴 수 있게 만들기"입니다. 그래서 양이 질을 이기고, 애매한 것도 숫자로 바꾸고, 채점을 자동으로 돌리라는 거죠. 만든 모델로 채점하지 말고, 지표는 여러 축으로, 어려운 사례를 일부러 넣고, 다듬을 때 쓴 자료는 평가에서 빼세요. 비용까지 함께 저울질하는 흐름은 AI 지출 관리 허브에 단계별로 정리해 두었습니다.
출처: Claude 공식 문서 「평가 설계하기」 (2026-09-01 열람). 본문의 목표 수치는 문서가 든 예시이며, 실제 기준은 용도와 모델 세대에 따라 달라집니다.
'AI & Vibe Coding' 카테고리의 다른 글
| 프롬프트 주입 막는 법 — 믿을 수 없는 내용은 도구 결과에만 (0) | 2026.09.01 |
|---|---|
| AI 답변에 근거 붙이기 — 인용문은 출력 요금에 안 잡힙니다 (0) | 2026.09.01 |
| AI 답이 매번 달라질 때 — 추상적인 지시보다 예시가 낫습니다 (0) | 2026.09.01 |
| AI 환각 줄이는 법 — 모른다고 말할 허락을 주는 게 먼저입니다 (0) | 2026.09.01 |
| Claude 한국어 성능 — 영어의 96.7%, 급을 낮추면 벌어집니다 (0) | 2026.09.01 |
