문제는 테스트가 없는 게 아니다
AI 코딩 어시스턴트를 도입한 팀이 가장 먼저 마주치는 유혹은 테스트 생성 속도다. Cursor에 한 줄 지시하면 테스트 파일이 뚝딱 생긴다. 하지만 그 테스트가 실제로 팀의 의사결정을 바꾸는지는 전혀 다른 이야기다. 테스트 자동화를 도입한 팀 대부분이 겪는 진짜 문제는 테스트 부족이 아니라 테스트에 대한 신뢰 부족이다. 파이프라인이 빨간불을 켜도 누군가 '그냥 재실행해봐'를 외친다면, 그 팀의 테스트 스위트는 비용만 먹는 배경 소음에 불과하다.
Cursor + DeepEval: 프롬프트 회귀 테스트의 실전 루프
dev.to에 올라온 한 실무 사례는 이 문제를 정확히 짚는다. 가상의 화물 추적 회사 고객 지원 트리아지 앱을 만든 개발자는, 앱이 "대체로 잘 동작한다"는 것이 오히려 문제였다고 말한다. '지금 당장 키 로테이션 필요, 긴급'이라는 티켓을 보안 사고로 분류해 인간 에스컬레이션을 트리거한 것이다. JSON은 유효했고, 필드값은 허용 범위 안이었다. 출력은 정상이었는데 동작은 틀렸다.
그가 선택한 해법은 Cursor에 DeepEval 에이전트 스킬을 추가하고, 기존 티켓과 정책 문서를 바탕으로 골든 데이터셋을 자동 생성하는 것이었다. 핵심은 이 데이터셋이 앱을 학습시키는 게 아니라 체크리스트라는 점이다. 프롬프트를 수정할 때마다 '실제 장애는 여전히 에스컬레이션되는가', '일반 How-to 질문은 정상 큐에 남는가'를 반복 검증하는 루프가 생긴다. 수정 후 재실행, 통과 여부 확인, 다시 수정—이 워크플로우가 있어야 비로소 프롬프트 변경이 '희망'이 아닌 '근거' 위에 서게 된다.
통과율 96%가 말해주지 않는 것들
그런데 이 루프를 돌린다고 해서 팀의 신뢰 문제가 자동으로 해결되지는 않는다. dev.to의 또 다른 글은 테스트 스위트가 신뢰를 잃는 구조적 이유를 분석한다. 통과율 96%는 그럴싸해 보이지만, 그 4% 실패가 실제 제품 결함을 잡았는지, 통과한 96%가 위험한 배포 경로를 커버했는지는 말해주지 않는다. 세 번 재시도 끝에 겨우 통과한 테스트가 몇 개인지도 모른다.
더 심각한 문제는 유지보수 비용이다. AI로 10분 만에 생성한 테스트가 이후 매달 3시간씩 수정을 요구한다면, 그건 10분짜리 테스트가 아니다. AI 생성 테스트의 경제성을 평가할 때 생성 속도만 보는 팀은 이 함정에 빠진다. 실패 메시지가 얼마나 명확한지, 제품 변경에 얼마나 민감하게 반응하는지, 수정에 얼마나 많은 컨텍스트가 필요한지—이 지표들이 진짜 유지보수 비용을 결정한다.
AI 에이전트 테스트: 최종 답변이 맞아도 프로세스는 망가진 경우
LLM 기반 앱을 테스트할 때 또 하나의 함정이 있다. AI 에이전트는 도구를 선택하고, 결과를 해석하고, 다음 행동을 결정하는 과정 자체가 제품이다. 엉뚱한 도구를 골랐다가 에러를 받고, 두 번째 도구로 재시도해 부분적으로 레코드를 변경한 뒤 '성공'을 보고하는 에이전트를 최종 응답만 체크하는 테스트는 통과시킨다. 정답에 도달했지만 과정이 완전히 망가진 케이스를 잡지 못하는 것이다.
DeepEval의 두 가지 메트릭—라우팅 필드가 예상값과 일치하는지, 그 결정이 정책 문서의 에스컬레이션 규칙을 따랐는지—을 분리해서 체크하는 방식이 의미 있는 이유가 여기 있다. 출력 검증과 정책 준수 검증을 독립적으로 돌려야 에이전트의 결정 과정을 제품의 일부로 다룰 수 있다.
주의력은 자동화하고, 판단은 사람이 한다
세 번째 관점은 자동화 루틴 설계 철학에서 온다. 플랫폼 팀 테크 리드가 공유한 사례에서 그는 지원 채널 트렌드 수집, ADR 상태 추적, 자신의 커뮤니케이션 습관 점검 등 세 가지 자동화 루틴을 만들었다. 공통 구조는 하나다. 주의력(attention)을 자동화하고, 판단(judgment)은 인간이 내린다.
이 원칙은 AI 테스트 자동화에도 그대로 적용된다. Cursor가 골든 데이터셋을 만들고 DeepEval이 실패를 잡아주는 것은 '주의력의 자동화'다. 그 실패를 보고 프롬프트를 어떻게 수정할지, 어떤 엣지 케이스를 추가할지, 이 테스트 결과가 배포 결정을 바꿔야 하는지는 여전히 인간의 판단 영역이다. 그는 한마디로 정리한다. "효율은 진짜다. 하지만 그건 부수 효과다. 효율을 직접 최적화 목표로 삼으면 할 필요 없는 일을 더 빠르게 하게 된다."
팀이 실제로 설계해야 할 것
세 사례를 엮으면 AI-First 팀이 테스트 자동화에서 진짜 설계해야 할 것이 보인다.
첫째, 회귀 체크리스트를 먼저 정의하라. 프롬프트나 모델을 바꾸기 전에 '반드시 유지되어야 할 동작'의 목록이 있어야 한다. DeepEval의 골든 데이터셋이 그 역할을 한다.
둘째, 통과율이 아니라 판단 유용성으로 메트릭을 바꿔라. 실패가 실제 결함을 잡았는지, 그 실패를 진단하는 데 시간이 얼마나 걸렸는지를 추적해야 팀이 테스트를 믿기 시작한다.
셋째, 에이전트 테스트는 최종 출력이 아니라 결정 과정을 커버하라. 도구 선택, 메모리 업데이트, 복구 경로, 부분 사이드이펙트—이 레이어를 테스트하지 않으면 데모에서만 신뢰할 수 있는 에이전트가 된다.
넷째, 유지보수를 설계에 포함시켜라. AI가 테스트를 생성한 속도는 장기 비용과 무관하다. 생성 이후 누가 소유하고, 어떤 주기로 검토하고, 불안정한 테스트를 어떻게 처리할지를 처음부터 설계해야 한다.
전망: 신뢰는 실패 하나씩 쌓인다
AI가 테스트를 짜는 속도는 앞으로 더 빨라질 것이다. Cursor 같은 코딩 에이전트에 DeepEval 같은 평가 프레임워크가 통합되면, 기능 개발과 동시에 회귀 테스트 스위트가 자동으로 확장되는 워크플로우가 현실화된다. 하지만 속도가 빨라질수록 팀이 그 결과를 실제로 신뢰하는지 여부가 더 중요해진다.
테스트 스위트는 유용한 실패 하나씩 신뢰를 쌓는다. 한번 신뢰를 잃으면, 테스트를 더 추가하는 것이 오히려 문제를 키운다. AI가 테스트 생성 속도를 올릴수록, 그 테스트가 팀의 판단을 실제로 바꾸는 구조를 설계하는 일은 테크 리드의 몫으로 남는다.