LLM 애플리케이션 테스트가 어려운 이유로 비결정성이 자주 언급된다. 하지만 엔터프라이즈 에이전트의 중요한 보장 중 상당수는 모델을 호출하지 않고도 검증할 수 있다. tenant 조건이 모든 쿼리에 들어가는지, 전문 에이전트가 허용된 도구만 받는지, 같은 쓰기가 두 번 생기지 않는지, 검색 장애 때 근거를 꾸며내지 않는지는 일반적인 코드 테스트의 영역이다.

enterprise-agent-reference의 단위 테스트는 실제 LLM credential이나 실행 중인 Docker stack을 요구하지 않는다. 첫 커밋 기준 21개 테스트가 서비스와 계약의 경계를 검증한다.

모델 대신 조립 결과를 검사한다

에이전트 런타임 테스트는 MCP client와 모델 factory를 mock으로 바꾼다. 그 뒤 create_deep_agent에 전달된 인자를 확인한다. 계정 분석가에는 고객 관련 도구 세 개만, 정책 조사자에는 검색 도구 두 개만 들어가는지 검사하고 create_followup_task가 interrupt 대상으로 설정됐는지 확인한다.

이 테스트는 모델이 매번 올바른 도구를 고른다고 증명하지 않는다. 대신 잘못 고르더라도 전문 에이전트가 보유하지 않은 능력은 사용할 수 없다는 구조적 보장을 확인한다.

서비스 테스트는 공격자의 관점도 포함한다

Records 테스트는 정상 고객 조회와 함께 cross-tenant case 조회가 not found인지 확인한다. 후속 작업 생성은 같은 idempotency key로 두 번 호출해 task row가 하나인지 검사한다. 키가 없는 쓰기는 실패해야 한다.

Knowledge 테스트에는 더 노골적인 실패 조건이 있다.

  • 검색 query에 인증 tenant filter가 들어간다.
  • 호출자가 unknown filter로 tenant를 바꾸려 하면 거절한다.
  • 검색 backend가 다른 tenant hit를 반환해도 제거한다.
  • 문서 안의 injection 문장은 untrusted content로 남는다.
  • OpenSearch timeout 때 가짜 검색 결과를 만들지 않는다.

API 계약과 repository 상태를 따로 검증한다

thread repository 테스트는 사용자와 tenant 소유권, 승인 상태 전환, 메시지와 citation 저장을 다룬다. API 계약 테스트는 SSE 응답과 승인 endpoint가 예상 형식을 지키는지 확인한다. SQLite는 빠른 repository test double로만 사용하고 production 경로가 PostgreSQL이라는 사실을 문서에 명시한다.

테스트 double을 사용할 때 중요한 것은 차이를 숨기지 않는 것이다. PostgreSQL 고유 동작, 실제 MCP transport와 checkpoint adapter는 별도 integration 검증이 필요하다.

평가 데이터셋은 다른 질문에 답한다

단위 테스트가 시스템 경계를 검증한다면 evaluation dataset은 에이전트 행동을 검토한다. 현재 다섯 개 사례에는 고객·정책 조사, citation 요구, 승인 전 중단, cross-tenant 거절과 prompt injection containment가 포함된다. 기본 runner는 데이터셋 형식을 검증하고, 실행 중인 stack을 대상으로 하는 live mode는 실제 행동을 확인한다.

평가 사례에는 최소한 다음 정보가 있어야 한다.

  • 사용자 요청과 인증 tenant
  • 반드시 사용해야 하거나 사용하면 안 되는 도구
  • 기대하는 citation
  • approval 발생 여부
  • 금지된 데이터와 실패 조건

아직 남은 테스트 공백

현재 suite가 production 준비를 의미하지는 않는다. 실제 PostgreSQL·OpenSearch를 사용한 integration test, 프로세스 재시작 후 checkpoint 재개, 동시에 들어온 승인, SSE 연결 취소, 부하와 timeout budget, migration 호환성은 더 검증해야 한다. 모델 provider별 tool calling 차이도 live evaluation이 필요하다.

에이전트 품질을 답변 점수 하나로 줄이면 보안과 운영 실패가 평균 속에 묻힌다. 먼저 절대 깨지면 안 되는 경계를 결정적 테스트로 고정하고, 그 위에서 모델 행동을 반복 평가하는 것이 더 설명 가능한 순서다.