PostHog의 알렉스 레베데프(Alex Lebedev)는 실제 코드 변경과 사고 사례, 데이터 환경을 활용해 AI 에이전트를 평가하는 방법을 소개했다. 핵심은 업무에 맞는 채점 기준을 만들고, 에이전트끼리 정보를 공유하지 못하게 하며, 반복 실행에서도 같은 조건을 유지하는 것이다.
레베데프는 PostHog가 매달 2조 개가 넘는 LLM 토큰을 사용하며, 상당 부분이 에이전트 실행에 쓰인다고 밝혔다. 이처럼 비용이 큰 상황에서 결과를 느낌만으로 판단하지 않도록 벤치마크를 활용한다. 다만 에이전트는 흔적, 메모리, 데이터베이스 쿼리 기록 등을 찾아 시험을 쉽게 통과하려 할 수 있어 평가 설계에 주의해야 한다.
업무에 맞는 채점 기준 만들기
코드 리뷰 에이전트 ReviewHog를 평가할 때 PostHog는 먼저 대형 PR 하나를 복사해 고정하고, 사람이 검토해 찾은 잠재적 버그 목록을 정답 기준으로 삼았다. 각 에이전트가 찾아낸 문제 수와 실행 시간, 비용을 비교할 수 있었지만, 한 PR의 한 변경만 다룬다는 한계가 있었다.
이후 실제 사고 33건과 사고를 일으킨 PR, 문제 설명, 문제를 수정한 PR을 모아 골든 세트를 만들었다. ReviewHog는 사고 원인이 된 버그를 62%의 사례에서 찾았다. 47%에서는 다른 봇이 놓친 버그를 ReviewHog만 발견했다. 9%에서는 다른 봇이 먼저 문제를 제기해 ReviewHog가 이미 알려진 문제로 표시했고, 6%에서는 다른 봇만 버그를 찾았다. 당시 가장 좋은 조합은 버그 탐색에 GPT Sol 5.6의 xhigh, 검증에 Claude Opus 5의 xhigh를 쓰고 두 단계 모두 pi를 하네스로 사용하는 것이었다. 실험 결과는 공개돼 있다.
이 결과는 PostHog의 코드와 업무에 맞춘 것이므로 다른 작업이나 코드베이스에서도 같은 조합이 최선이라는 뜻은 아니다. 또한 공개 저장소에서는 에이전트가 웹을 통해 병합된 PR을 찾아 답을 알아낼 수 있다. 사고가 난 PR을 다시 구성하는 과정에서 GitHub 봇이 오작동할 수도 있어, 에이전트가 작업하는 브랜치를 격리했다.
개방형 작업에는 정답 목록 대신 평가 기준표를 썼다. 예를 들어 특정 영역을 조사하는 Scouts 에이전트는 발견 내용을 보고했는지, 결과가 실행 가능한지, 다음 단계가 제시됐는지처럼 공통 기준과 해당 에이전트의 맥락에 맞춘 기준으로 평가한다. Session Replay 플레이어의 안정성을 조사한다면 실제 재생 실패 징후를 찾았는지, 데이터를 올바르게 조회했는지, 발견한 버그가 실제 사용자에게 영향을 미쳤는지도 살핀다. PostHog는 이 방식으로 모델, 추론 노력 수준, 프롬프트 변경에 따른 결과를 비교한다. 평가가 완전히 결정적이지는 않지만, 단순히 모델의 답변이 그럴듯한지를 보는 것보다 유용하다는 설명이다. 평가 기준 생성기 코드도 공개했다.
실행 간 정보 공유 차단하기
실제 데이터를 대상으로 여러 에이전트를 평가하면 먼저 실행된 에이전트의 메모리나 쿼리 기록이 다음 실행에 노출될 수 있다. PostHog의 한 사례에서는 B4 실행이 이상 징후를 조사해 메모리를 저장했고, 뒤이어 실행된 B12가 그 메모리를 읽어 직접 조사하지 않았다. 이런 정보 유출은 에이전트의 실제 성능을 왜곡한다. 반대로 다른 에이전트가 이미 처리한 일을 보고 건너뛰면, 성능이 좋은 에이전트가 낮은 점수를 받을 수도 있다.
간단한 방법은 실행을 순차적으로 진행하고 매번 데이터베이스와 로그를 정리하는 것이다. 하지만 실행 시간이 길고 정리 작업이 필요하다. 병렬 실행을 하려면 모든 실행에 같은 시작 맥락을 제공하고, 메모리·데이터베이스 등 쓰기 가능한 상태와 평가 과정을 각각 분리해야 한다. ClickHouse나 로그 같은 관측 도구의 기록도 정보 유출 경로가 될 수 있다.
격리를 지나치게 하면 실제 에이전트가 사용하는 도구나 작업 단계를 평가 환경에서 빼게 될 수 있다. Scouts의 시험 실행에서는 실제 실행처럼 보고서를 만들거나 데이터를 수정하지 않아 일부 동작을 평가하지 못했다. PostHog 사례에서는 정보 검색이 저장보다 중요해 이를 받아들였지만, 평가 대상에 따라 실제 도구를 모두 쓸 수 있는 격리 환경이 필요할 수 있다.
고정된 데이터 환경에서 반복 평가하기
실제 데이터베이스에 에이전트를 실행하면 데이터가 계속 바뀌어 모델 간 점수를 공정하게 비교하기 어렵다. PostHog는 앱과 데이터를 복제해 시작 상태를 고정하는 오프라인 벤치마크를 만들고 있다. 각 실행 뒤 가상 머신(VM)을 삭제하고 새로 만들어 상태를 초기화한다. 에이전트가 데이터를 만들거나 수정·삭제하는 작업도 시험할 수 있고, 데이터가 고정돼 있어 지난달의 모델 결과와 오늘의 결과를 비교하기 쉽다. 여기서 ‘오프라인’은 AI 서비스 연결까지 끊는다는 뜻이 아니라, 평가 데이터의 상태를 고정한다는 뜻이다.
처음에는 모델 컨텍스트 프로토콜(MCP) 호출에 저장된 응답을 돌려주는 방식을 썼다. 간단한 시연에는 쓸 수 있었지만 에이전트가 매번 다른 쿼리를 실행할 수 있어 실제 업무와 비슷한 평가에는 잘 맞지 않았다. 여러 실행 경로를 바탕으로 응답을 모의하는 방식도 시도했으나, 실행 중 작은 차이가 생기면 예상 밖 쿼리에 응답하지 못해 평가가 실패할 수 있었다.
대신 PostHog는 실제 데이터 일부를 복원한 격리된 샌드박스를 만들었다. PostgreSQL과 ClickHouse의 테이블 일부를 Parquet 파일로 저장해 VM의 로컬 PostHog 인스턴스에 복원한다. 데이터는 PostHog 인프라 밖으로 나가지 않는다. 정적 데이터에 현재 시각을 기준으로 한 쿼리를 실행하면 날짜가 맞지 않는 문제가 생기므로, 데이터를 주입할 때 고정된 시간대에 맞춰 타임스탬프를 이동한다.
데이터를 너무 적게 복제하면 에이전트가 빠진 테이블을 조회하고 환경이 이상하다고 의심할 수 있다. 예를 들어 개인정보(PII)가 포함된 사용자 테이블은 복제하지 않기로 했지만, 에이전트가 관련 없는 작업 중에도 해당 테이블을 찾는 경우가 있었다. 반대로 데이터가 실제 환경의 규모와 맞지 않아도 에이전트가 데이터가 합성됐다고 의심할 수 있다. 시험이라고 판단한 에이전트는 추가 확인을 멈추거나 데이터의 불일치 조사에 예산을 쓰고, 평소보다 추측성 결과를 내놓을 수 있다. 이를 막을 단일 해법은 없으며, 데이터 구성을 반복 조정해야 한다는 것이 PostHog의 설명이다.
PostHog는 채점 기준과 실행 격리 방식을 내부 테스트에 적용하고 있으며, 환경 고정 작업은 계속 진행 중이라고 밝혔다. 레베데프는 모델의 버그 탐색과 검증에 서로 다른 모델 계열을 쓰는 것도 중요하다고 덧붙였다. OpenAI 또는 Anthropic 모델만으로 두 단계를 모두 처리했을 때 결과가 좋지 않았다고 설명했다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요