AI 제품의 진짜 해자는 모델이 아니라 평가자와 검증 게이트다

AI 제품의 품질과 자기개선 능력이 생성 모델보다 평가자, hard verifier, 배포 전 replay simulation에 의해 좌우된다는 관점을 정리합니다.

AI 제품을 만들 때 사람들은 먼저 더 좋은 모델을 찾는다. 물론 모델은 중요하다. 하지만 제품이 반복해서 좋아지려면 더 중요한 축이 있다. 바로 평가자와 검증 게이트다. 생성자가 아무리 강해도, 무엇이 좋은 결과인지 판단하는 장치가 약하면 제품은 개선되는 척하면서 망가진다.

TL;DR

AI 제품의 품질은 생성 모델만으로 결정되지 않는다. 평가자와 검증 게이트가 같이 있어야 한다.
자기개선 루프의 기본식은 mutate → evaluate → gate다. 여기서 약한 고리는 대부분 evaluate다.
judge가 약하면 시스템은 좋아지는 것이 아니라 judge를 속이는 방향으로 최적화될 수 있다.
hard verifier는 테스트, 타입 체크, 정책 체크, 정답 비교, 실행 가능성처럼 기계적으로 확인 가능한 신호다.
초기 AI 서비스도 출시 전 replay simulation과 사용자 시나리오 테스트를 작게라도 가져가야 한다.

왜 지금 중요한가

AI 제품을 만드는 팀은 보통 모델 선택부터 고민한다.

GPT를 쓸까, Claude를 쓸까?
오픈소스 모델을 붙일까?
더 긴 컨텍스트가 필요할까?
비용이 싼 모델로 바꿀 수 있을까?

이 질문들은 중요하다. 하지만 모델만 바꿔서는 제품 품질이 안정되지 않는다.

진짜 문제는 이런 곳에서 터진다.

답변이 그럴듯하지만 틀렸다.
테스트하지 않고 성공했다고 말한다.
예외 케이스에서 위험한 출력을 한다.
프롬프트를 고쳤더니 기존에 되던 케이스가 깨진다.
A/B 후보 중 무엇이 더 좋은지 판단 기준이 없다.

이 문제는 모델 성능 문제가 아니라 평가 시스템 문제다.

최근 수집한 자료들은 이 방향을 분명히 보여준다.

RSI Book은 자기개선 시스템의 핵심을 mutate → evaluate → gate로 설명한다.
OpenAI Deployment Simulation은 배포 전 실제 대화 분포에 가까운 시뮬레이션으로 후보 모델의 행동을 검토한다.
NAVER D2의 자동화 파이프라인은 스펙 변경, 결함 탐지, 프롬프트 최적화, 검증을 분리한다.
Devin Productivity 자료는 에이전트 생산성을 사람 시간 환산과 세션 단위로 측정하려는 흐름을 보여준다.

한 줄로 말하면 이렇다.

AI 제품의 해자는 생성 능력이 아니라 평가 능력에서 생긴다.

핵심 흐름

1. 생성자는 점점 흔해진다

모델 성능은 빠르게 상향 평준화되고 있다. 오늘 가장 좋은 모델도 몇 달 뒤에는 가격이 내려가거나, 비슷한 성능의 대안이 나온다.

그래서 모델 자체만으로 오래 가는 해자를 만들기는 어렵다. 특히 작은 AI 유틸이나 SaaS는 대부분 범용 모델 API 위에서 출발한다.

그렇다면 차이는 어디서 생길까?

어떤 입력을 받는가
어떤 맥락을 넣는가
어떤 출력 형식을 요구하는가
어떤 실패를 감지하는가
어떤 결과를 사용자에게 보여주고 숨기는가
어떤 로그를 다음 개선에 쓰는가

여기서 평가와 검증이 핵심이 된다.

2. 자기개선 루프는 judge만큼만 믿을 수 있다

Recursive Self-Improvement 관점에서 자기개선은 단순한 식으로 볼 수 있다.

candidate = mutate(best)
score = evaluate(candidate)
if score > best.score:
    best = candidate

이 구조에서 사람들은 mutate에 관심을 많이 둔다. 더 다양한 후보를 만들고, 더 창의적인 답변을 생성하고, 더 큰 모델을 쓰려고 한다.

하지만 실제 병목은 evaluate다.

평가자가 약하면 어떤 일이 생길까?

후보가 실제로 좋아지지 않았는데 점수만 높아진다.
평가 기준의 빈틈을 이용하는 결과가 나온다.
사용자에게 중요한 품질이 아니라 측정하기 쉬운 지표만 오른다.
안전성이나 신뢰성 문제가 누적된다.

학교 시험에서 문제은행만 외운 학생이 점수는 높지만 실제 실력은 부족한 것과 비슷하다. AI 제품도 judge가 약하면 그렇게 된다.

3. hard verifier는 AI 제품의 안전벨트다

LLM judge는 유용하다. 하지만 모든 것을 LLM judge에게 맡기면 위험하다.

가능하면 기계적으로 확인할 수 있는 신호를 먼저 써야 한다. 이것이 hard verifier다.

예시는 많다.

제품 유형	hard verifier 예시
코드 생성	테스트 통과, 타입 체크, 린트, 빌드 성공
SQL 생성	파서 통과, 샘플 DB에서 실행, 금지 쿼리 차단
ERD 생성	Mermaid 문법 검증, 테이블/관계 일관성 체크
문서 요약	필수 항목 포함, 출처 링크 보존, 숫자/고유명사 비교
번역/윤문	금지어 보존, 숫자 보존, 용어집 일치
고객 응대	정책 위반 탐지, 개인정보 노출 차단, escalation 조건

AI가 판단해야 하는 영역과 기계가 검증할 수 있는 영역을 섞으면 안 된다.

기계가 확인할 수 있는 것은 기계가 확인해야 한다. LLM judge는 그 다음이다.

실제 사례 / 원문에서 본 신호

RSI Book: 루프의 신뢰도는 평가자의 신뢰도다

RSI Book의 중요한 메시지는 단순하다.

자기개선 시스템은 후보를 만들고, 평가하고, 통과시키는 구조다. 그런데 평가자가 약하면 루프 전체가 약해진다.

이건 AI 제품에도 그대로 적용된다.

예를 들어 AI가 랜딩페이지 카피를 개선한다고 하자. 평가 기준이 “더 설득력 있어 보이는가?”뿐이면 모델은 과장된 문장을 만들기 쉽다.

반대로 평가 기준이 이렇게 되어 있으면 결과가 달라진다.

첫 문장에서 대상 사용자가 명확한가?
과장 표현이 없는가?
기능과 효용이 구분되어 있는가?
모바일 첫 화면에서 CTA가 보이는가?
사용자가 입력 없이 예시 결과를 볼 수 있는가?

평가 기준이 구체적일수록 자기개선 루프는 덜 흔들린다.

OpenAI Deployment Simulation: 배포 전 실제 대화를 재현한다

OpenAI Deployment Simulation의 핵심은 배포 전 후보 모델의 행동을 실제 대화 분포에 가깝게 재현해보는 것이다.

이 접근이 중요한 이유는 간단하다.

테스트셋은 보통 깔끔하다. 실제 사용자는 그렇지 않다.

질문이 모호하다.
중간에 말을 바꾼다.
금지된 요청을 우회해서 묻는다.
제품이 의도하지 않은 방식으로 사용한다.
긴 대화 끝에 문제가 발생한다.

그래서 AI 제품은 “좋은 예시 10개에서 잘 된다”만으로는 부족하다. 출시 전에는 실제 사용자 패턴을 흉내 낸 시나리오가 필요하다.

작은 스타트업도 거창한 시뮬레이션 시스템부터 만들 필요는 없다. 최소 버전은 가능하다.

1. 대표 사용자 질문 30개를 모은다.
2. 성공/실패 기준을 붙인다.
3. 새 프롬프트나 모델 후보를 돌린다.
4. 실패 유형을 태깅한다.
5. 치명 실패가 있으면 배포하지 않는다.

이 정도만 해도 “느낌상 괜찮다”보다 훨씬 낫다.

NAVER D2: 스펙과 결함 탐지를 분리한다

NAVER D2 발표는 실무적으로 좋은 힌트를 준다.

쇼핑 에이전트의 답변 스펙은 계속 바뀐다. 기존 방식에서는 사람이 프롬프트를 고치고, 문제를 찾고, 다시 테스트해야 했다.

발표에서 인상적인 구조는 다음이다.

Markdown 기반 스펙
→ 결함 탐지 체크리스트
→ 결함 결과를 reward signal로 사용
→ prompt optimization
→ 검증과 승인

여기서 중요한 것은 스펙, 생성, 결함 탐지, 최적화가 분리되어 있다는 점이다.

많은 작은 AI 제품은 이 네 가지가 한 프롬프트 안에 섞여 있다.

너는 좋은 답변을 해야 해.
정확하고 친절하게 답해.
규칙을 지켜.

이런 프롬프트는 처음에는 빨라 보이지만, 제품이 커지면 관리가 어렵다.

스펙은 문서로, 결함 유형은 체크리스트로, 프롬프트는 실행 로직으로, 검증은 별도 게이트로 둬야 한다.

Devin Productivity: 생산성도 측정 설계가 필요하다

Devin Productivity 자료는 에이전트의 생산성을 사람 시간으로 환산하거나 세션 단위로 측정하려는 흐름을 보여준다.

여기서 얻을 수 있는 교훈은 하나다.

AI가 일을 했다는 사실보다, 그 일이 실제로 어떤 가치를 만들었는지 측정해야 한다.

에이전트가 5시간 돌았고 파일 30개를 바꿨다고 해서 생산성이 높은 것은 아니다. 사용자가 겪던 문제가 줄었는지, 배포 가능한 산출물이 생겼는지, 다음 작업의 비용이 낮아졌는지를 봐야 한다.

작은 팀 사업에 주는 힌트

글로벌 유틸/AI 서비스 전략은 빠른 출시가 중요하다. 하지만 빠른 출시와 검증 부재는 다르다.

특히 AI 기능이 들어가는 순간, 최소 검증 게이트가 필요하다.

AI ERD Generator에 적용하면

첫 타깃인 AI ERD Generator를 예로 들어보자.

사용자는 자연어로 이렇게 입력할 수 있다.

온라인 강의 플랫폼 DB를 만들어줘.
학생, 강사, 강의, 결제, 수강 이력이 필요해.

AI는 ERD와 SQL을 만들어준다. 여기서 모델이 그럴듯한 답을 내는 것은 어렵지 않다. 진짜 문제는 검증이다.

최소 verifier는 이렇게 잡을 수 있다.

검증 항목	방법
Mermaid ERD 문법	Mermaid parser/render 테스트
SQL DDL 문법	SQLite/Postgres parser 또는 dry run
관계 일관성	FK가 존재하는 테이블/컬럼을 참조하는지 검사
필수 엔티티 포함	입력에서 추출한 핵심 명사와 결과 테이블 비교
위험 출력 차단	실제 개인정보/보안정보 요청 시 안내
사용자 수정 루프	“이 관계를 1:N으로 바꿔줘” 같은 follow-up 테스트

이 정도만 있어도 단순 AI 데모에서 제품으로 한 단계 올라간다.

작은 AI 유틸의 공통 검증 게이트

앞으로 여러 유틸을 만들면 공통 게이트를 템플릿화할 수 있다.

# AI Utility Verification Gate

## Input cases
- 정상 케이스 5개
- 애매한 케이스 3개
- 악성/오류 케이스 3개

## Output checks
- 필수 필드 포함
- 문법/스키마 검증
- 금지 내용 없음
- 출처/면책 문구 필요 시 포함

## UX checks
- 실패 시 사용자가 다음 행동을 알 수 있음
- 예시 입력 제공
- 복사/다운로드 동작 확인

## Release gate
- 치명 실패 0개
- 일반 실패는 known issue로 기록
- 배포 후 로그 수집 위치 명시

이 템플릿은 한 번 만들면 여러 AI 유틸에 반복 적용할 수 있다. 이것이 운영 해자다.

바로 해볼 실험

실험 1. 프롬프트 수정 전후 replay set을 만든다

프롬프트를 고칠 때마다 감으로 배포하지 않는다.

최소 20~30개의 입력 케이스를 모아두고, 변경 전후 결과를 비교한다.

cases/
  normal-01.txt
  normal-02.txt
  ambiguous-01.txt
  edge-01.txt
  malicious-01.txt

각 케이스에는 기대 조건을 붙인다.

must_include:
  - users
  - courses
  - enrollments
must_not_include:
  - 실제 개인정보 요청
syntax:
  mermaid: valid
  sql: valid

이 정도만 있어도 제품 품질이 크게 안정된다.

실험 2. LLM judge보다 hard verifier를 먼저 붙인다

AI가 AI를 평가하게 하는 것은 유용하지만, 첫 단계가 되어서는 안 된다.

순서는 이렇게 가는 것이 좋다.

1. 문법/스키마/테스트 같은 hard verifier
2. 규칙 기반 체크
3. LLM judge
4. 사람 승인

기계가 볼 수 있는 것은 기계가 보고, 애매한 품질 판단만 LLM이나 사람이 본다.

실험 3. 실패 유형을 제품 자산으로 저장한다

실패는 버그가 아니라 자산이다. 단, 기록할 때만 자산이 된다.

## Failure log

### 2026-06-20
- 입력: “마켓플레이스 DB 만들어줘”
- 실패: seller/buyer를 같은 users로 합쳤지만 role 관계가 불명확
- 원인: role modeling 기준 없음
- 수정: role/table 분리 선택지를 사용자에게 물어보는 follow-up 추가
- verifier: role ambiguity case 추가

이런 로그가 쌓이면 제품은 시간이 지날수록 똑똑해진다. 그냥 프롬프트만 고치면 다음 달에 같은 실수를 반복한다.

리스크 / 반론

반론 1. 초기 MVP에 eval까지 붙이면 너무 느리지 않나?

거대한 eval 시스템은 필요 없다. 하지만 최소 검증은 필요하다.

초기 MVP의 검증은 작아야 한다.

대표 입력 10개
오류 입력 3개
문법 체크 1개
수동 시나리오 3개

이 정도는 속도를 크게 늦추지 않는다. 오히려 출시 후 망신과 재작업을 줄인다.

반론 2. LLM judge도 틀릴 수 있지 않나?

맞다. 그래서 LLM judge만 믿으면 안 된다.

LLM judge는 유용한 보조 평가자다. 하지만 중요한 게이트에는 hard signal이 필요하다.

실행되는가?
파싱되는가?
테스트를 통과하는가?
금지 규칙을 위반하지 않는가?
이전 성공 케이스를 깨지 않았는가?

이런 질문은 가능한 한 기계적으로 확인해야 한다.

반론 3. 사용자 반응이 최종 평가 아닌가?

맞다. 최종 평가는 사용자다.

하지만 사용자에게 검증되지 않은 위험한 결과를 그대로 던지면 안 된다. 출시 전 검증은 사용자를 대체하는 것이 아니라, 기본 품질선을 지키는 장치다.

출시 후에는 실제 로그와 사용자 행동이 가장 중요한 평가 데이터가 된다. 그래서 eval과 analytics는 연결되어야 한다.

결론

AI 제품의 첫 번째 차별점은 모델일 수 있다. 하지만 오래 가는 차별점은 평가 시스템에서 나온다.

생성 모델은 점점 좋아지고, 점점 싸지고, 점점 비슷해진다. 반면 좋은 평가자, 좋은 실패 로그, 좋은 replay set, 좋은 검증 게이트는 제품 안에 쌓인다.

AI 제품을 만들 때 질문을 바꿔야 한다.

어떤 모델을 쓸까?

에서 멈추지 말고,

무엇을 좋은 결과로 볼 것인가?
실패를 어떻게 감지할 것인가?
배포 전에 무엇을 replay할 것인가?
어떤 실패는 자동 차단할 것인가?
사용자 로그를 다음 eval로 어떻게 되돌릴 것인가?

까지 가야 한다.

AI 유틸 실험도 이 원칙으로 가는 편이 좋다. 빠르게 만들되, 최소 검증 게이트를 제품 템플릿으로 만든다.

그 순간 단순한 AI 데모가 아니라, 반복해서 좋아지는 AI 서비스가 된다.

Sources

The State of Recursive Self-Improvement · The RSI Book
OpenAI Deployment Simulation
NAVER D2 — 답변 생성 모델 자동화 파이프라인
Cognition Devin Productivity
Image: <chatgpt image 2>

Source links

The State of Recursive Self-Improvement · The RSI Book
OpenAI Deployment Simulation
NAVER D2 — 답변 생성 모델 자동화 파이프라인
Cognition Devin Productivity