AI 시스템은 같은 입력에도 매번 다른 답을 낼 수 있고, 서비스 제공자가 모델을 바꾸면 애플리케이션 코드가 그대로여도 결과가 달라질 수 있다. deepsense.ai의 AI 엔지니어링 매니저 피오트르 리셰프스키(Piotr Ryszewski)는 이런 시스템을 평가하려면 기존 소프트웨어 테스트를 활용하되, 기대한 행동이 얼마나 자주 나타나는지와 그 조건을 반복 측정하고 출시 뒤에도 변화를 감시해야 한다고 설명한다.
전통적인 테스트 피라미드는 AI 시스템에도 유용하다. 단위 테스트에서는 데이터 처리, 청킹, 응답 파싱, 오류 처리처럼 결정적인 코드와 함께, 선별한 입력·기대 출력으로 구성한 골든 세트의 일부 모델 평가를 수행할 수 있다. 통합 테스트에서는 검색 증강 생성(RAG)의 검색과 생성 전체 흐름을 평가하고, 에이전트라면 모델과 도구, 작업의 연속 과정을 함께 확인한다. 인수 테스트에서는 고객과 합의한 시나리오를 성공적으로 처리하는지가 기준이 된다.
출시 후 모니터링은 테스트 피라미드 바깥에서 계속돼야 한다. 출력 분포나 사용자 질문이 달라지거나 기반 모델이 바뀌면, 테스트를 만들 때의 가정이 실제 사용 환경과 어긋날 수 있기 때문이다.
평가할 때는 환각뿐 아니라 프롬프트 변경이나 제공자의 모델 업데이트로 이전에 잘 처리하던 답변의 품질이 떨어지는 회귀도 살펴야 한다. 형식과 응답 시간만 재고 답변의 유용성을 놓치면 안전하다는 잘못된 인상을 줄 수 있다. 비교 기준이 되는 골든 세트가 없으면 새 모델이나 프롬프트가 개선됐는지도 판단하기 어렵다.
리셰프스키는 사업 담당자와 합의한 골든 세트에서 시작해 프롬프트, 모델 등 주요 요소가 바뀔 때 자동 평가를 실행하는 방식을 제안한다. 평가는 결정론적 규칙, 모델 평가 기준, 사람의 검토를 함께 활용하고, 근거 확인을 통해 답변이 검색된 출처에 기반하는지도 살펴야 한다. 결과가 합의한 기준 아래로 떨어졌을 때 배포를 막을지, 변경을 되돌릴지, 문제를 상향 보고할지 미리 정해야 한다. 담당자와 대응 계획이 없는 기준값만으로는 시스템을 보호하기 어렵다.
시스템 구조에 따라 실패 양상과 평가 방법도 달라진다. RAG에서는 생성이 빠진 문서나 부적절한 문맥을 보완할 수 없으므로 검색된 문서가 적절한지 먼저 측정한다. 에이전트는 최종 답변만으로 신뢰성을 판단하지 않고 의사결정, 도구 호출, 중간 상태가 담긴 실행 기록을 살핀다. 외부 서비스 연동에서는 인터페이스가 제대로 작동하는지뿐 아니라 도구 설명을 모델이 이해해 적절한 때 호출하는지도 확인해야 한다.
고객 검증도 테스트의 일부다. 요구사항 문서만으로는 팀과 고객이 같은 말을 서로 다르게 해석할 수 있으므로, 구체적인 사례를 놓고 프로젝트 전반에 걸쳐 검토하는 편이 낫다고 리셰프스키는 말한다. 기술 검토에서는 명확한 기준에 따라 시스템을 측정하고, 사업 검토에서는 실제 고객 업무 흐름을 지원하는지 확인해야 한다. 고객이 방향을 바꾸면 그 변경을 분류하고 기록해 결정하는 절차도 필요하다.
리셰프스키는 배포가 품질 관리의 끝이 아니라 새로운 단계의 시작이라고 강조한다. 모델 변경, 입력 변화, 오래된 검색 데이터는 시간이 지나며 시스템의 행동을 바꿀 수 있다. 따라서 지속적인 모니터링과 책임 주체, 시간이 지나도 유지되는 허용 기준을 함께 마련해야 한다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요