에이전트가 스스로 나아질 때, 그걸 믿어도 되는지 판정할 계층이 없다

어떤 문제인가

에이전트가 스스로 프롬프트를 다시 쓰고, 새 도구를 붙이고, 성공했던 궤적을 메모리에 넣어 다음 판단에 반영한다. 여기까지는 이미 현실이다. 문제는 그다음이다. 그 ‘개선’이 정말 개선인지 누가 판정하나. 새 버전이 결제 문의 처리 정확도를 올렸다 쳐도, 그 대가로 환불 예외 처리를 조용히 망가뜨렸을 수 있다. 더 고약한 경우는 에이전트가 자기 자신을 채점할 때다. 스스로 “통과”를 주는데, 그게 능력이 늘어난 건지 채점 기준을 외운 건지, 즉 보상 해킹인지 구별이 안 된다. 지금 팀들이 쓰는 건 사후 로그를 보여주는 관측 도구뿐이다. 무언가 망가진 뒤에야 대시보드에서 발견한다. 배포하기 전에 “이 자기개선을 프로덕션에 올려도 되는가”를 자동으로 막아설 관문이 없다.

왜 지금인가

자기개선 자체가 갑자기 흔해졌다. 프로덕션 트레이스에서 실패 사례를 뽑아 프롬프트를 자동 갱신하는 파이프라인, 성공 궤적을 메모리에 축적하는 에이전트 프레임워크, 강화학습으로 도구 사용을 다듬는 루프가 오픈소스로 쏟아진다. 만드는 쪽은 폭발했는데 그걸 통제하는 쪽은 그대로다. DevOps에는 카나리 배포와 자동 롤백이 표준으로 자리 잡았지만, 에이전트에는 대응물이 없다. 코드 회귀는 테스트로 잡지만, “말투가 미묘하게 공격적으로 변했다”거나 “특정 고객 유형에서만 판단이 나빠졌다” 같은 능력 회귀는 단위 테스트로 안 잡힌다. 게다가 EU AI Act처럼 고위험 시스템에 로깅·사람 감독·변경 이력을 요구하는 규제가 발효되면서, 에이전트가 스스로 바뀔 때마다 “무엇이 왜 바뀌었고 검증은 어떻게 했나”를 증명해야 하는 압력이 커진다. 만들기 쉬워지는 속도와 검증하는 속도의 간극, 그 사이가 곧 시장이다.

어떻게 만들 수 있나

핵심은 자기개선을 코드 배포처럼 다루는 것이다. 에이전트가 새 버전을 제안하면, 그걸 바로 프로덕션에 올리지 않고 세 관문을 통과시킨다. 첫째, held-out 게이팅. 에이전트가 절대 학습·자기평가에 쓸 수 없는 별도 평가셋을 격리해 둔다. 자기가 채점 기준을 못 보게 막아야 보상 해킹을 걸러낸다. 둘째, 회귀 감지. 새 버전을 옛 버전과 나란히 돌려(shadow 또는 A/B) 작업 유형별로 점수 변화를 통계적 유의성까지 따진다. 전체 평균은 올라도 특정 구간이 떨어졌으면 잡아낸다. 셋째, eval-as-CI. 이 평가를 개발자의 파이프라인 안에 게이트로 박아, 통과 못 한 자기개선은 프로덕션 승격을 자동으로 막고 직전 버전으로 롤백한다. 관측 도구(Langfuse·Arize) 위에 얹히는 ‘판정·승격·롤백’ 레이어로 포지셔닝하면, 이미 트레이스를 쌓고 있는 팀에 자연스럽게 파고든다.

flowchart LR
  A[배포된 에이전트] --> B[자기개선 버전 제안]
  B --> C{held-out 평가 게이트}
  C -->|통과| D{회귀 감지}
  C -->|실패| E[자동 롤백]
  D -->|이상 없음| F[프로덕션 승격]
  D -->|회귀 발견| E

성공 조건

이건 ‘또 하나의 평가 도구’가 되면 죽는다. 오프라인 벤치마크를 돌려주는 회사는 이미 많다. 살아남으려면 ‘프로덕션에서 스스로 바뀌는 에이전트’라는 좁고 뜨거운 문제 하나에 못 박아야 한다. 차별점은 사전 게이팅과 자동 롤백이다, 사후 대시보드가 아니라 배포를 막아서는 관문. 신뢰의 핵심은 held-out셋의 무결성이므로, 평가셋이 에이전트에게 유출되지 않았음을 증명하는 장치가 제품의 심장이 된다. 위험도 분명하다. 랭체인·랭퓨즈 같은 관측 플랫폼이 이 기능을 자체 흡수하면 시장이 좁아진다. 그러니 특정 프레임워크에 종속되지 않는 횡단 표준, 그리고 규제 대응 증거(무엇이 왜 바뀌었고 어떻게 검증했나)를 자동으로 남기는 컴플라이언스 각도로 방어선을 먼저 세워야 한다. 오탐이 잦아 멀쩡한 개선까지 막으면 팀은 게이트를 꺼 버린다. 통계적 엄밀함과 낮은 오탐률이 생존선이다.