이제 에이전트를 만드는 건 어렵지 않다. 프롬프트를 쓰고, 도구를 붙이고, 데모를 돌리면 그럴듯하게 작동한다. 진짜 어려운 건 그다음이다. 프롬프트를 고치고, 모델을 새 버전으로 올리고, 도구 하나를 바꿨을 때 — 방금 그 변경이 제품을 좋게 만들었는지, 조용히 나쁘게 만들었는지 아는 것. 대부분의 팀은 이걸 눈으로 몇 번 돌려보고 “잘 되네” 하고 배포한다. 감(vibes)으로 운전하는 것이다.
문제는 감이 규모를 못 버틴다는 데 있다. 프롬프트 하나에 수십 개의 사용 사례가 물려 있고, 그중 다섯 개가 미묘하게 망가진 걸 사람 눈으로 잡을 방법은 없다.
데모는 통과하고, 프로덕션은 샌다
에이전트가 실전에서 무너지는 방식은 최종 답만 봐서는 안 보인다. 한 현장 분석에서 에이전트 실패의 약 17%는 같은 단계를 무의미하게 반복하는 것이었고, 약 14%는 추론과 실제 행동이 어긋나는 것이었다. 둘 다 마지막 출력만 검사하면 그대로 통과한다. 답은 그럴싸한데 과정이 썩은 것이다.
그래서 "출력이 맞나"만 보는 테스트는 데모용이다. 데모의 골든 케이스는 항상 통과하고, 프로덕션의 진짜 실패는 데이터셋에 없으니 잡히지 않는다. 평가가 실패를 담지 못하면, 통과는 아무 의미가 없다.
LLM 심판을 맹신하면, 심판이 거짓말한다
여기서 많은 팀이 지름길을 택한다. “채점을 LLM한테 시키자.” LLM-as-judge는 유용하지만, 검증 없이 쓰면 흔들리는 자를 대고 재는 것과 같다.
같은 답을 두 번 채점시켰을 때 판정이 일치하는 비율은 temperature를 0으로 고정하면 95%를 넘지만, 1로 올리면 70%까지 떨어진다. 자가 채점기가 같은 입력에 다른 점수를 준다는 뜻이다. 게다가 알려진 편향이 줄줄이 있다 — 긴 답을 무조건 좋게 보는 장황함 편향, 먼저 제시된 쪽을 선호하는 위치 편향, 자기 계열 모델의 출력을 후하게 주는 자기 강화 편향. 프런티어 모델조차 고급 편향 테스트에서 절반 넘게 틀린다는 보고가 있다.
교훈은 "LLM 심판을 쓰지 마라"가 아니다. 심판도 평가 대상이다. 사람이 라벨링한 소규모 정답 세트로 심판의 판정을 먼저 검증하고, 그 일치율을 알고 나서 심판에게 나머지를 맡겨야 한다. 검증되지 않은 심판은 자동화된 자기기만이다.
평가 루프가 진짜 레버리지다
제대로 된 팀이 하는 건 화려하지 않다. 세 조각이면 된다.
- 얼려둔 골든 세트. 반드시 맞아야 하는 핵심 케이스를 고정한다. 이건 회귀 기준선이다. 여기서 점수가 떨어지면 그 변경은 배포하지 않는다.
- 자라나는 실패 세트. 프로덕션에서 터진 케이스를 매번 테스트로 편입한다. 에이전트가 실패할 때마다 데이터셋이 커진다. 두 번 같은 방식으로 당하지 않는다.
- 배포 게이트. 골든 세트 점수가 임계값 아래로 내려가면 릴리스를 자동으로 막는다. 사람의 감은 이 임계값을 통과한 뒤에야 개입한다. 기준선 위에서의 감은 판단이지만, 기준선 없는 감은 도박이다.
이 루프의 진짜 가치는 규모에서 드러난다. 혼자 혹은 소수가 대규모 제품을 굴리려면, 매 배포마다 손으로 QA하는 건 불가능하다. 그 QA를 대신하는 게 평가 루프다. 사람 열 명이 눈으로 하던 검수를, 얼려둔 케이스와 게이트가 자동으로 한다. 1인 유니콘의 방어선이 온톨로지라면, 그 방어선이 무너지지 않았는지 확인하는 센서가 평가 루프다.
하루면 바꾸고, 하루엔 못 만든다
모델을 새 버전으로 올리는 데는 한 줄이면 된다. 프롬프트를 고치는 것도 몇 분이다. 정작 어려운 건 그게 아니라, 바꾼 뒤가 더 나쁜지 즉시 판별하는 능력이다. 이 능력은 하루에 생기지 않는다. 케이스를 쌓고, 심판을 검증하고, 게이트를 세우는 시간이 쌓여야 생긴다.
그래서 평가 루프는 귀찮은 잡일이 아니라 해자다. 경쟁자가 모델을 열 번 바꾸는 동안, 당신은 그 열 번이 각각 나아졌는지 안다. 감으로 배포하는 쪽은 언젠가 조용히 무너지고, 이유도 모른다. 남은 질문은 하나다. 당신의 다음 배포는 무엇 위에서 결정되는가 — 감인가, 기준선인가.