AI 기능을 만들다 보면 결과물이 괜찮은지 판단하는 순간이 옵니다. 대개는 다 만든 다음입니다. 몇 번 돌려 보고, 그럴듯하면 넘어갑니다. 채점 기준은 그때 가서 정해도 된다고 생각하죠. 저도 그랬습니다.
이번에는 순서를 바꿔 봤습니다. 제가 만들던 것은 아이디어 한 단락을 넣으면 기획 문서 초안을 만들어 주는 AI 기능이었습니다. 기획서와 요구사항, 인수기준(이 기능이 완료됐다고 볼 조건)까지는 문서로 적혀 있었고 구현은 아직 시작하기 전이었습니다. 그 상태에서 평가셋(결과물을 채점할 문항 모음)부터 만들기로 했습니다.
평가셋을 설계하는 AI에게는 기획 문서만 읽게 했습니다. 나중에 코드가 생기더라도 채점 기준은 코드가 아니라 문서에서 나와야 합니다. 채점 기준이 구현에서 나오면 구현이 틀린 곳을 채점도 같이 틀리기 때문입니다. 결과는 예상과 달랐습니다. 평가 문항은 9개가 나왔는데, 기획서에 되물어야 할 질문도 9개가 나왔습니다.
성공 기준을 먼저 정하라는 말은 오래전부터 있었습니다
시스템 공학 표준인 ISO/IEC/IEEE 15288은 검증을 이렇게 정의합니다. 적어 둔 요구사항이 충족됐다는 것을 객관적 증거로 확인하는 일. 이와 짝을 이루는 활동을 흔히 이렇게 구분합니다. 검증은 문제를 제대로 풀었는지를 보고, 밸리데이션(타당성 확인)은 애초에 제대로 된 문제를 풀고 있는지를 봅니다. 뒤에서 이 구분이 다시 나옵니다.
LLM 기능에도 같은 순서가 요구됩니다. Anthropic의 개발 문서는 LLM 기반 애플리케이션을 만드는 일이 성공 기준을 분명히 정의하는 데서 시작하고, 그다음 그 기준을 잴 평가를 설계한다고 적어 둡니다. 평가를 오래 다뤄 온 Hamel Husain은 실패한 AI 제품들이 거의 언제나 같은 원인을 공유한다고 말합니다. 튼튼한 평가 체계를 만들지 못했다는 것입니다.
사람이 만들 때는 이 순서가 조금 느슨해도 티가 덜 났습니다. 기준이 비어 있으면 개발자가 물어봤으니까요. “1문장만 넣으면 만들어요, 말아요.” 이런 질문이 회의에서 오가면서 빈칸이 메워졌습니다. AI는 되묻지 않습니다. 빈칸을 자기 판단으로 채우고 끝까지 갑니다.
저는 이것을 한 번 겪었습니다. 지난 글에서 다른 서비스의 기획서 하나로 AI에게 네 번 구현을 시켰더니, 적힌 곳은 네 번 모두 같았고 안 적힌 곳은 네 번 모두 달랐습니다. 그때는 다 만든 뒤에야 빈칸을 찾았습니다. 이번에는 만들기 전에 찾을 수 있는지 보고 싶었습니다.
성공 판정 기준이라는 절은 있었는데 목표치가 비어 있었습니다
기획서에는 성공 판정 기준이라는 절이 따로 있었습니다. 기준 세 개와 측정 방법, 측정 시점까지 표로 정리돼 있었습니다. 그런데 기준 두 개의 목표치 칸에는 미확정 표시가 붙어 있었습니다. 첫 시범 운영을 언제까지 끝낼지, 판정 결과를 표본으로 뽑아 다시 볼 때 몇 건을 볼지가 비어 있었습니다.
더 큰 빈칸은 따로 있었습니다. 이 기능이 만든 기획 문서가 좋은 문서인지 판단할 내용 기준이 어디에도 없었습니다. 절을 어떻게 구성해야 하는지, 요구 문장은 어떤 형식이어야 하는지, 아이디어를 얼마나 충실히 옮겨야 하는지가 문서 세트 전체에 적혀 있지 않았습니다. 앞에서 말한 구분으로 보면, 문서를 요구대로 만들었는지 검증할 기준은 조금 있었지만 쓸 만한 기획 문서인지 밸리데이션할 기준은 없었던 셈입니다.
막힌 곳: 기준이 없으니 평가셋을 만들 수 없다고 멈추는 것도 정직한 답입니다. 하지만 그러면 인수기준에 이미 적힌 것까지 버리게 됩니다. 평가셋 설계 절차에는 이런 경우에 어떻게 할지가 정해져 있지 않았습니다.
바꾼 방법: 전부 멈추는 대신 적힌 만큼만 문항으로 만들었습니다
설계를 맡은 AI는 전부 멈추지 않았습니다. 인수기준에 적힌 것은 문항으로 만들고, 적히지 않은 것은 문항 대신 질문으로 남겼습니다. 빈칸을 지어낸 문항으로 메우지 않은 것이 핵심입니다. 저는 이 판단을 보고, 기준이 일부만 있을 때는 이렇게 한다는 규칙을 평가셋 설계 절차에 새로 넣었습니다.
문항 하나는 입력, 기대 결과, 판정 방법으로 이뤄집니다. 예를 들면 이렇습니다. 입력은 “좌석예약”이라는 한 단어입니다. 기대 결과는 문서를 한 건도 만들지 않고 “아이디어를 1문단 이상 입력해 주세요”라는 안내를 띄우는 것입니다. 판정은 만들어진 문서 수와 안내 문구를 코드로 셉니다.
9개 문항은 네 종류로 나눴고, 종류마다 넣은 이유가 다릅니다. 잘 만들어야 하는 정상 입력 3개는 기본 동작을 봅니다. 빈 입력이나 한 단어처럼 만들지 말아야 하는 입력 2개는 기능이 억지로 무언가를 내놓지 않는지 봅니다. 문서를 만드는 도중에 서버 오류를 일부러 일으키는 경우와 아이디어 안에 지시문을 섞어 넣은 경우 2개는 막아야 할 것을 막는지 봅니다. 앞의 것은 반쯤 만든 문서가 남지 않아야 하고, 뒤의 것은 섞여 든 지시를 따르지 않아야 합니다. 마지막으로 두 결과를 나란히 놓는 비교 쌍 2개는 원문에 있는 값은 그대로 옮기고 없는 값은 지어내지 않는지 봅니다.
질문 9개는 성격이 달랐습니다. 몇 개만 옮겨 보겠습니다.
인수기준에는 1문장 미만이면 만들지 않는다고 적혀 있는데, 화면 안내 문구는 1문단 이상 입력하라고 합니다. 정확히 1문장을 넣으면 만드는지 마는지가 정해져 있지 않습니다. 요구사항은 입력을 1~3단락으로 적었는데, 4단락을 넣으면 거절할지 잘라 낼지 그냥 만들지도 비어 있었습니다. 지시문이 섞인 입력은 다른 요구사항에서 끌어와 문항으로 만들었지만, 그걸 막으라는 정책이 따로 적혀 있지는 않아서 확인 질문으로도 올렸습니다.
셋 다 사람 개발자라면 구현하다가 물어봤을 질문입니다. AI에게 구현을 맡겼다면 아무도 묻지 않은 채 어느 한쪽으로 정해졌을 겁니다. 채점표를 먼저 짜니 그 질문들이 구현 전에 나왔습니다.
AI에게 채점을 맡기는 문항에는 비용이 따로 붙었습니다
문항마다 채점 방법도 정해야 했습니다. 순서는 이렇게 잡았습니다. 코드로 판정할 수 있으면 코드로, 안 되는 것만 AI 심판(결과물을 읽고 합격인지 판정하는 별도의 AI)에게, 그래도 안 되는 것은 사람에게 넘겼습니다. 9개 중 6개는 코드로 판정할 수 있었고, 2개는 AI 심판, 1개는 사람 몫이었습니다.
AI 심판이 필요한 문항은 이런 것입니다. 목표치나 출시 기한이 없는 아이디어를 넣었을 때, 결과 문서에 “목표 이용자 1,000명” 같은 값이 슬쩍 들어갔는지 봐야 합니다. 어떤 숫자를 지어낼지 미리 알 수 없으니 금지할 문자열 목록을 만들 수 없고, 원문과 대조해 읽어야 합니다.
그런데 AI 심판은 그 자체를 먼저 맞춰야 씁니다. Hamel Husain은 모델 기반 평가와 사람 평가가 얼마나 일치하는지 추적해야 자동 평가를 얼마나 믿을지 정할 수 있다고 말합니다. 사람이 같은 결과물에 먼저 합격과 불합격을 매긴 라벨이 있어야 한다는 뜻입니다. 저는 결과물 한 건씩 20건을 라벨 기준으로 잡았고, 한 건에 12분쯤 걸린다고 치면 심판 하나를 맞추는 데 4시간쯤 듭니다. 이 12분은 재 본 값이 아니라 추정입니다.
AI 심판 문항 2개는 지어낸 값이 들어갔는지를 보는 심판 하나를 같이 씁니다. 사람 몫으로 남긴 비교 쌍 하나는 사정이 달랐습니다. 두 결과가 같은 주제를 빈칸으로 남겼는지를 봐야 해서 두 번째 심판이 필요했는데, 그런 문항은 1개뿐이었습니다. 문항 1개를 위해 라벨 20건을 만드는 것은 앞뒤가 바뀐 일이라 사람에게 남겼습니다.
이 판단을 보고 규칙을 하나 정했습니다. 새 심판을 만들려면 그 심판이 볼 같은 성격의 문항이 3개 이상 쌓여야 합니다. 다만 이 규칙은 첫 심판을 이미 만든 뒤에 정했습니다. 그 심판이 보는 문항은 2개라 규칙대로라면 문턱 아래입니다. 되돌려 없애지는 않았고, 다시 볼 대상으로 남겨 두었습니다.
아직 남은 문제: 채점표는 있는데 한 번도 채점하지 않았습니다
정직하게 적어 둘 것이 셋 있습니다.
첫째, 평가셋은 설계만 했고 문항을 실제 기능에 돌려 본 적은 0회입니다. 문항이 좋은 결과물과 나쁜 결과물을 가려내는지는 아직 모릅니다.
둘째, AI 심판은 채점 기준 문서 하나를 초안으로 써 둔 상태입니다. 한 번도 돌리지 않았고, 맞춰 볼 사람 라벨도 0건입니다. 돌린다 해도 라벨이 쌓이기 전까지 그 판정은 참고값입니다.
셋째, 가장 큰 질문인 내용 품질 기준이 아직 비어 있습니다. 기획 문서 양식을 따로 갖고 있어서 그걸 이 기능의 산출물 기준으로 채택할지 정하면 되는데, 그 결정은 제 몫으로 남아 있습니다. 채점표를 먼저 짜서 얻은 가장 큰 결과가 결국 제가 정할 일 목록이었던 셈입니다.
마치며: ‘다 만든 뒤의 채점표’가 아니라 ‘만들기 전의 질문지’
평가셋을 먼저 만들면 품질을 미리 잴 수 있을 거라고 기대했습니다. 실제로 얻은 것은 품질 점수가 아니라 기획서의 빈칸 목록이었습니다. AI에게 구현을 넘기는 순간 그 빈칸은 아무도 묻지 않는 자리가 됩니다. 그러니 채점표를 먼저 짜는 일의 값은 채점보다 질문에 있습니다.
AI에게 구현을 넘기는 순간 그 빈칸은 아무도 묻지 않는 자리가 됩니다.
지금 AI에게 맡기려는 기능이 있다면, 구현을 시작하기 전에 합격 조건을 문항 세 개로 적어 보시길 권합니다. 위의 예처럼 입력 하나, 기대 결과 하나, 그걸 어떻게 셀지 한 줄이면 충분합니다. 적다가 막히는 자리가 AI가 혼자 정하게 될 자리입니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- Anthropic, Define your success criteria, platform.claude.com/docs/en/test-and-evaluate/define-success (2026-09-28 확인)
- SEBoK, System Verification, sebokwiki.org/wiki/System_Verification (ISO/IEC/IEEE 15288:2015 정의와 Martin 1997 인용, 2026-09-28 확인)
- Hamel Husain, Your AI Product Needs Evals, hamel.dev/blog/posts/evals (2024-03-29, 2026-09-28 확인)