AI 결과물을 믿게 만드는 검증 3종 — 이진·정량·정성, 그리고 운영 중 검증

AI에게 코드를 짜게 하고, 문서를 쓰게 하고, 설계를 맡긴다. 그런데 막상 결과물을 받아 들면 "이걸 믿어도 되나" 하는 멈칫이 온다. 사람이 짠 코드라면 리뷰하고 테스트를 돌려 믿음을 만든다. AI 결과물도 똑같이, 믿음은 검증에서 나온다. 다만 무엇을 어떻게 검증하느냐가 조금 다르다.

개인 작업에 AI를 깊게 끼워 넣을수록(흔히 AX, AI Transformation이라 부르는 그 변화 말이다) 이 질문이 매일 돌아온다. 검증 없이 받아들이면 어느 순간 잘못된 결과가 조용히 쌓인다. 그래서 검증을 하나의 막연한 작업이 아니라 세 종류의 레이어로 나눠 보면 훨씬 다루기 쉬워진다.

## 검증은 한 덩어리가 아니라 세 레이어다

다이어그램 설명. 하나의 "AI 결과물"을 세 갈래 검증으로 동시에 거는 구조를 보여준다. "되는가 / 안 되는가"를 묻는 검증은 참·거짓이 분명한 자리에, "숫자로 측정"하는 검증은 양으로 잴 수 있는 자리에, "전문가 눈으로 평가"하는 검증은 숫자로 표현하기 어려운 자리에 각각 붙는다. 셋은 경쟁 관계가 아니라 서로 다른 빈틈을 메우는 보완 관계라, 하나만 쓰면 나머지 두 종류의 결함이 그대로 빠져나간다는 점이 핵심이다.

## 1. 이진 검증 — 되는가, 안 되는가

가장 익숙한 검증이다. 기능이 동작하면 참이고, 아니면 거짓이다. 우리가 흔히 말하는 테스트 케이스가 바로 이것이다. "로그인하면 토큰이 돌아온다", "빈 입력에는 에러를 던진다"처럼 답이 둘 중 하나로 떨어진다.

이 검증은 만들기가 가장 쉽고, 그래서 가장 많아진다. 입력과 기대 출력만 정해 두면 기계가 영원히 같은 판정을 반복한다. 비용이 거의 들지 않으니 수백 개를 쌓아도 부담이 적다. AI가 짜 준 함수가 의도대로 도는지 가장 먼저, 가장 촘촘히 걸어 두는 그물이 이 이진 검증이다.

다만 한계가 분명하다. "되긴 되는데 얼마나 빠른가", "되긴 되는데 설계가 깔끔한가" 같은 질문에는 참·거짓 하나로 답할 수가 없다. 그래서 나머지 두 레이어가 필요해진다.

## 2. 정량 지표 — 숫자로 재는 검증

두 번째 레이어는 결과물을 숫자로 측정한다. 대표적으로 처리량(throughput, 단위 시간에 처리한 작업 수), 지연시간(latency, 요청을 보내고 응답을 받기까지 걸린 시간), 오류율(전체 시도 중 실패한 비율) 같은 값이다. 참·거짓이 아니라 "얼마나"를 잰다.

숫자로 재면 좋은 점은 기준선을 그어 둘 수 있다는 것이다. 예를 들어 "p99 지연시간이 200ms를 넘으면 실패"처럼 선을 정해 두면, 기능은 되는데 느려지는 회귀를 자동으로 잡는다. 이진 검증이 "되는가"를 본다면, 정량 지표는 "쓸 만한 수준으로 되는가"를 본다. AI가 만든 결과물이 어제보다 느려졌는지, 오류율이 올라갔는지는 숫자를 봐야만 보인다.

## 3. 정성 루브릭 — 숫자로 못 재는 것을 평가한다

세 번째 레이어가 가장 까다롭다. "아키텍처가 과도하게 추상화되지는 않았나", "디자인에 색이 너무 많지는 않나", "화면 동선이 직관적인가" 같은 기준은 참·거짓으로도, 숫자로도 깔끔하게 떨어지지 않는다. 이런 품질은 사람이 보고 "음, 이건 좀 과하다" 하고 판단하던 영역이다.

여기서 요즘 널리 쓰는 방법이 LLM-as-a-judge(LLM을 심판으로 세우는 평가 방식)다. AI에게 "네가 그 분야 전문가라고 생각하고 이 결과물을 1~5점 척도로 평가하라"고 시킨다. 사람이 매기던 정성 평가를 모델에게 위임하는 것이다. 평가 기준(루브릭, 점수 단계별로 무엇이 좋고 나쁜지 적은 채점표)을 함께 주면 판단이 한결 안정된다.

# 정성 루브릭을 LLM 심판에게 맡기는 평가 함수
import re

JUDGE_PROMPT = """당신은 시니어 소프트웨어 아키텍트다. 아래 설계를 평가하라.
기준 — 추상화 정도: 불필요하게 과하면 1점, 군더더기 없이 적절하면 5점.
정수 점수(1~5)와 한 줄 근거만 출력하라.

[설계]
{design}
"""

def judge_design(design: str) -> int:
    # 1단: 평가 대상을 프롬프트에 끼워 넣는다
    answer = call_llm(JUDGE_PROMPT.format(design=design))
    # 2단: 심판 답변에서 첫 정수만 파싱 — 장황한 설명이 섞여도 점수만 취한다
    score = int(re.search(r"[1-5]", answer).group())
    # 3단: 3점 미만이면 검증 실패로 간주해 빌드를 멈춘다
    return score

코드 설명. 정성 기준 하나(추상화가 과한가)를 LLM 심판에게 1~5점으로 채점시키는 최소 코드다. 점수 단계의 의미를 프롬프트에 명시해 판단의 기준선을 고정하고, 답변에서 첫 정수만 뽑아 통과 여부로 쓴다. 주의할 점은 두 가지다. 첫째, 척도는 필요 이상으로 잘게 나누지 않는 편이 낫다. 1~10처럼 너무 세분하면 심판이 방어하기 어려운 구분을 지어내 점수에 노이즈가 끼기 때문이다. 둘째, 심판도 결국 모델이라 사람이 주기적으로 채점 결과를 감사해 줘야 신뢰가 유지된다.

## 만들 때만이 아니라, 운영 중에도 검증해야 한다

지금까지의 세 레이어는 주로 만들 때(build-time, 빌드·배포 직전) 거는 검증이다. 그런데 만든 제품 자체가 AI 에이전트라면 이야기가 달라진다. AI 에이전트는 비결정적(non-deterministic, 같은 입력을 줘도 출력이 매번 달라질 수 있는 성질)이라, 같은 요청에도 다른 도구를 고르고 다른 답을 낸다. 빌드 시점에 한 번 통과했다고 운영 중 매 응답이 안전하다는 보장이 없다.

다이어그램 설명. 검증이 배포 전에서 끝나지 않고 운영 중까지 이어지는 흐름을 보여준다. 만들 때 거는 세 레이어를 통과해 배포에 이르지만, 비결정적 에이전트는 그 뒤로도 매번 새로운 출력을 내므로 "상시 가드레일"이 한 겹 더 붙는다. 여기서 가드레일(guardrail)은 운영 중 입력과 출력을 상시 검사해, 응답을 실제 행동으로 옮기기 전에 위험한 출력을 걸러 내는 안전장치를 뜻한다. 놓치기 쉬운 부분은 이 가드레일이 매 요청마다 비용을 치른다는 점이라, 보통 한 검사를 수십 밀리초 안에 끝내도록 지연 예산을 빠듯하게 잡는다.

운영 중 검증을 설계할 때 한 가지 발상이 특히 인상적이다. 위험한 행동을 런타임에 "하지 마라"고 막는 대신, 애초에 그 행동을 할 수단 자체를 에이전트에게 주지 않는 방식이다. 예를 들어 삭제·쓰기 도구를 에이전트가 볼 수 있는 도구 목록에서 빼 버리면, 에이전트는 그 행동을 시도할 길조차 찾지 못한다. 막는 것보다 구조적으로 불가능하게 만드는 편이 더 단단하다.

## 정리 — 세 레이어를 겹쳐야 믿음이 선다

이진 검증은 "되는가"를, 정량 지표는 "쓸 만한 수준인가"를, 정성 루브릭은 "잘 만들었는가"를 본다. 세 질문은 서로를 대신하지 못한다. 셋을 겹쳐 걸어야 AI 결과물에 대한 믿음이 빈틈없이 선다. 그리고 제품이 매번 다르게 반응하는 AI 에이전트라면, 만들 때의 검증에 더해 운영 중 상시 가드레일까지 한 겹을 더 둬야 안심하고 맡길 수 있다.

개인 작업에 AI를 들일 때도 마찬가지다. 결과물을 그냥 받아들이는 대신, 이 세 가지 중 어떤 검증을 걸 수 있는지 한 번 물어보는 습관만으로도 잘못된 결과가 조용히 쌓이는 일을 크게 줄인다.

---

참고한 공개 자료:

• https://towardsdatascience.com/llm-as-a-judge-a-practical-guide/
• https://www.confident-ai.com/blog/why-llm-as-a-judge-is-the-best-llm-evaluation-method
• https://www.sitepoint.com/testing-ai-agents-deterministic-evaluation-in-a-non-deterministic-world/
• https://datanorth.ai/blog/evals-openais-framework-for-evaluating-llms
• https://www.promptfoo.dev/docs/configuration/expected-outputs/model-graded/
• https://www.kalviumlabs.ai/blog/guardrails-for-llm-applications/
• https://www.anthropic.com/research/building-effective-agents

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.