평가 없는 에이전트는 배포하지 마라

프롬프트 한 줄을 고쳤다. "Output strictly valid JSON"을 "Always respond using clean, parseable JSON"으로, 더 친절해 보이는 문구로 바꿨을 뿐이다. 그러자 다운스트림 파싱이 조용히 깨졌다. 예외도 에러도 없이 요청은 정상 응답했고, 로그엔 이상 징후가 없었다. 이것이 에이전트 시대 코드가 실패하는 방식이다 — 크래시하지 않고, 조용히 틀린다.

그래서 나는 이렇게 주장한다. 에이전트 시대의 코드리뷰는 평가(eval)다. 평가 없이 프롬프트나 에이전트를 고쳐 내보내는 것은, 감에 의존한 배포다. 취향이 아니라, 비결정적 시스템을 다루는 이가 감당할 최소한의 규율이다.

이 주장은 이번 호가 다루는 '루프 엔지니어링' — 사람이 매번 프롬프트하는 대신 AI 에이전트가 목표 달성까지 실행-검증-수정 루프를 스스로 돌도록 시스템을 설계하는 패러다임 — 의 한복판을 겨눈다. 그 자율 루프를 멈춰 세우는 명령 /goal은 "모든 테스트 통과, 린트 클린"처럼 기계가 판별 가능한 종료조건을 요구하는데, 그 종료조건의 실체가 무엇이냐 물으면 답은 결국 평가 게이트다. 루프를 멈추는 그 선(線)이 곧 이 글이 말하는 평가다.

단위 테스트가 멈추는 곳

우리가 아는 단위 테스트(unit test)는 안정된 명세와 결정적(deterministic) 결과를 가정한다. LLM은 그 가정을 깬다. 같은 프롬프트를 두 번 샘플링하면 다른 텍스트가 나오고, 한 번 통과한 테스트가 코드 한 줄 안 바꿔도 다음번엔 실패한다. 단일 실행은 신뢰할 판정 근거가 못 된다.

문제는 배포 전에서 끝나지 않는다. 에이전트 거동은 배포 뒤에도 진화한다. 프롬프트는 그대로인데 입력 분포가 이동하고(distribution shift), 제공사가 API를 그대로 둔 채 모델 가중치·서빙 인프라를 갱신하면 출력 포맷과 도구 호출 순서가 달라진다. 그래서 최근 논의는 배포 전 검증에 그치는 TDD를 넘어 '평가 주도 개발·운영(EDDOps)'을 별도 규율로 세우자고 말한다(arXiv:2411.13768).

프롬프트 자체도 놀랄 만큼 취약하다. 동의어 하나, 형용사 하나를 바꾸는 작은 어휘 변화조차 크고 종종 파괴적인 거동 변화를 부른다. 앞의 JSON 사례가 그것이다. 게다가 이런 실패는 예외를 던지지 않는 조용한 실패(silent failure)라, 프롬프트만 손보며 개선하려 들면 "한 실패 모드를 고치면 다른 실패가 튀어나오는 두더지 잡기(whack-a-mole)"에 빠진다고 실무자 하멜 후사인(Hamel Husain)은 말한다.

더 깊은 함정도 있다. 무엇이 '좋은 출력'인지 정하는 기준 자체가 고정돼 있지 않다. 출력을 채점하려면 기준이 필요하지만, 정작 그 기준은 출력을 하나씩 채점하는 과정에서 정의된다 — 학계가 기준 표류(criteria drift)라 부르는 현상이다(Shankar et al., UIST 2024). 좋음의 정의가 데이터를 보는 과정에서 만들어지는 이상, 감으로 프롬프트만 매만져서는 그 과정을 붙잡을 수 없다.

평가 루프의 최소 구성

그럼 무엇으로 대체하나. 평가다. 평가는 output == expected를 단언하는 대신, 대표 입력 집합에서 모델이 옳은 일을 하는 빈도가 배포해도 될 만큼 충분한지를 묻는다. 버전 관리되는 채점 스위트가 모든 변경마다 돌며 무엇을 내보낼지 게이트한다.

후사인은 이를 세 층위로 정리한다. ① 빠르고 값싼 어서션·단위 테스트, ② 사람과 모델이 함께 하는 평가(트레이스를 로깅해 "데이터를 보는 과정의 모든 마찰을 제거"하는 단계), ③ 성숙 단계의 A/B 테스트. 한 부동산 AI 제품(Rechat)은 새 실패가 나올 때마다 갱신하는 수백 개의 단위 테스트를 쌓았다. OpenAI 공식 쿡북도 평가를 프로덕션 배포 전에 회귀를 잡는 반복 가능한 테스트로 다룬다.

벤더의 조언은 더 구체적이다. Anthropic 공식 문서는 대부분의 실사용이 다차원 평가를 요구한다며 과업 특화·자동 채점·"질보다 양"(정교한 소수보다 자동 채점 문항을 많이)을 원칙으로 든다. "안전한 출력" 같은 모호한 기준조차 "1만 회 중 0.1% 미만이 필터에 걸림"처럼 정량화하라고 권한다.

사람 채점이 비싸면 모델을 심판(LLM-as-a-judge)으로 쓸 수 있다. MT-Bench·Chatbot Arena에서 GPT-4급 강한 심판은 사람 선호와 80%를 넘는 일치도를 보였고, 이는 사람들 사이의 일치 수준과 같다(Zheng et al., NeurIPS 2023). 다만 같은 논문이 그 심판의 위치 편향(제시 순서에 민감)·장황함 편향(긴 답 선호)·자기 강화 편향(자기 출력 선호)도 함께 밝혔다. 그래서 심판은 그냥 붙이는 게 아니라, 라벨링된 홀드아웃셋에서 높은 참-양성률(TPR)·참-음성률(TNR)을 목표로 사람 판단에 정렬해야 한다.

"비싸고 게이밍된다"

두 가지 반론이 예상된다. 둘 다 부분적으로 옳다.

먼저 "비싸다". 평가는 값싸지 않다. 후사인과 슈레야 샹카르(Shreya Shankar)는 개발 시간의 60~80%를 에러 분석과 평가에 쓴다고 조언한다. 비용에는 위계가 있다 — 단순 어서션은 구축·유지가 싸지만, LLM 심판 평가자는 100개 넘는 라벨 예시와 매주 유지보수를 요구하니 그 실패 모드가 투자를 정당화할 때만 붙일 일이다. 다만 그 비용의 큰 부분은 도구값이 아니라 사람이 데이터를 읽는 시간이고, 그 시간이 곧 제품 이해다. 평가를 건너뛴다고 그 이해가 공짜로 생기지는 않는다 — 대안은 감이지, 절약이 아니다.

다음은 "게이밍된다". 이것도 실재한다. "측정값이 목표가 되면 더 이상 좋은 측정값이 아니다"라는 굿하트의 법칙(Goodhart's Law) 그대로다. 강화학습의 보상 해킹이 그 전형이고, 공개 벤치마크도 예외가 아니다. 「The Leaderboard Illusion」(NeurIPS 2025)은 약 200만 건의 대결·243개 모델·42개 제공사(2024년 1월~2025년 4월)를 분석해, 일부 제공사가 여러 비공개 변형을 미리 돌려 가장 좋은 점수만 골라 공개할 수 있음을 보였다 — 한 곳은 공개 전 27개 변형을 시험했다.

그러나 여기서 결론이 갈린다. 게이밍에 취약한 것은 남이 만든 외부 리더보드이지, 내 프로덕션에서 뽑은 평가셋이 아니다. 두 종류의 게이밍을 섞으면 안 된다 — 공개 벤치마크 조작과, 내부 평가셋에 대한 과적합·심판 편향은 원인도 완화책도 다르다. 후자는 심판을 사람 라벨에 정렬하고, 생성에 쓴 모델과 다른 모델로 채점하며, 위치 편향에는 후보 순서를 뒤집고, 자주 도는 CI에서는 LLM 심판보다 값싼 결정적 체크를 선호하는 것으로 상당 부분 줄어든다. "게이밍된다"의 답은 "평가하지 말자"가 아니라 "남의 리더보드가 아니라 내 실패에 근거한 평가를 하자"다.

그래서, 월요일 아침에 무엇을 하나

시작점은 인프라가 아니라 에러 분석이다. 순서는 이렇다. 실제 사용자 트레이스를 모아 한 건씩 읽으며 무엇이 잘못됐는지 자유서술로 적는다(오픈 코딩) — 도메인 지식이 필요해 모델에 위임할 수 없고, 처음엔 트레이스마다 '첫 번째 실패'만 기록해도 된다. 그 노트를 5~10개 실패 모드로 묶고(축 코딩), 피벗 테이블로 빈도를 세어 무엇부터 고칠지 정한다. 이렇게 해야 평가 지표가 상용 대시보드의 일반 지표가 아니라 내 앱의 실제 거동에 뿌리내린다.

규모는 부담스럽지 않다. 실무자들은 시작 시 최소 100개 트레이스 검토를 권하되, 20개쯤 봐도 새 실패 범주가 안 나오는 '이론적 포화'에 이르면 멈춰도 된다고 본다. 가장 작은 실행안은 20~50개 출력을 30분 손으로 훑는 것이다. 운영에 들어가면 주당 10~20개(이상치 위주)를 계속 모니터링하도록 권한다.

도구는 나중이다. 화려한 평가 플랫폼을 사기 전에 노트북과 스프레드시트로 시작하라. 세분화된 점수 대신 좋음/나쁨 이진 라벨을 써라 — "3점이냐 4점이냐"를 다툴 시간이 없다. 단일 스킬이라면 10~20개 프롬프트만으로도 회귀를 드러내기 충분하다고 OpenAI는 조언한다. 작은 CSV로 시작해 실제 실패를 만날 때마다 키우면 된다. 이렇게 모은 평가 데이터는 품질을 재는 자이자, 나중에 파인튜닝에 쓸 데이터셋으로 이중으로 쓰인다.

이 규율은 루프 엔지니어링이 자율 루프에 '검증자 서브에이전트'를 따로 세우라고 요구하는 이유와 정확히 같은 자리에 있다. 개념을 명명한 애디 오스마니가 그 분리를 든 근거는 "코드를 작성한 모델이 자기 숙제를 채점하면 너무 후하다"는 것이었다 — 작성과 채점을 갈라놓아야 한다는 그 원칙의 실체가, 앞서 말한 "생성에 쓴 모델과 다른 모델로 채점하라"는 평가의 처방이다. 서브에이전트가 무엇으로 채점하느냐는 물음의 답이 곧 평가셋이다.

정리하자. 개발자라면 프롬프트 diff를 감으로 머지하지 말고 회귀 평가를 CI 게이트로 걸어라. 기획자라면 제품 스펙의 성공 기준을 다차원 평가 항목으로 명문화하라 — 무엇을 성공으로 볼지, 어디서 회귀를 막을지가 이제 요구사항의 일부다. 에이전트 시대에 코드리뷰가 사라진 것이 아니다 — 그 이름이 평가로 바뀌었을 뿐이다.