채팅에 상주하며 일상 업무를 대행하는 AI 에이전트는 운영하면서 반드시 프롬프트나 툴 정의를 수정하고 싶어집니다. '이 표현 방식으로는 오해받을 수 있다', '새로운 툴을 추가했더니 기존 판단이 바뀌었다'와 같은 개선은 피할 수 없지만, LLM의 출력은 결정적이지 않기 때문에 수정했다고 생각한 부분과 관계없는 곳에서 자신도 모르게 성능이 저하되는 경우가 빈번하게 발생합니다. 본 글에서는 상주 에이전트의 프롬프트 변경을 안전하게 수행하기 위한 평가 설계 방안을 정리합니다.

일반적인 소프트웨어 테스트가 효과적이지 않은 이유

일반적인 코드라면 입력에 대한 출력은 결정적이므로 단위 테스트(Unit Test)가 작동합니다. 그러나 LLM을 거치는 처리는 같은 입력이라도 실행할 때마다 표현이 흔들리며, '엄격 일치(Strict Match)' 기반의 테스트는 거의 성립하기 어렵습니다. 그렇다고 테스트를 포기하고 사람의 육안 확인에만 의존한다면, 프롬프트를 변경할 때마다 모든 기능을 수동으로 만져보고 확인하는 비용이 발생하여 상주 에이전트의 개선 속도 자체가 떨어지게 됩니다.

즉 과제는 'LLM 출력을 어떻게 엄격하게 테스트할 것인가'가 아니라, 엄격 일치에 의존하지 않고 성능 저하를 감지할 수 있는 평가 메커니즘을 어떻게 만들 것인가입니다.

평가 세트는 '실제 운영 로그'에서 구축한다

재현성이 가장 높았던 방법은 제로(0)부터 평가 데이터를 구상하는 것이 아니라, 실제로 에이전트가 겪었던 입력을 평가 세트의 모집단으로 삼는 것이었습니다.

• 일상적인 대화 중 판단이 모호했던 사례, 과거에 잘못된 출력을 했던 사례, 기밀 마스킹(Confidential Masking)과 관련된 사례 등을 지속적으로 샘플링하여 평가 세트 후보로 축적합니다.
• 후보에는 '입력(대화/트리거)', '기대되는 동작 요건', '실제 과거 출력'을 세트로 보관합니다.
• 기대값은 문장 그대로의 텍스트가 아니라, 만족해야 할 조건들의 체크리스트로 작성하는 것이 좋습니다. (예:

Slack/Teams/Chatwork에 상주하며 이용자의 판단 기준을 학습하며 성장해 나가는 HACH와 같은 에이전트에게는, 이러한 "변경 후에도 망가지지 않았음을 기계적으로 확인할 수 있는" 평가 기반이 개선 속도와 안전성을 양립시키는 토대가 됩니다. 동일한 과제에 도전하고 계신 분들께 참고가 되기를 바랍니다.

Discussion