AI 제품을 만드는 Product Manager 관점의 글

AI 제품에서는 테스트 방식 자체가 달라진다.
 

기존 제품에서는 기능이 명확하게 정의되어 있고 그 기능이 의도대로 동작하는지를 확인하면 된다.

예를 들어 로그인 기능을 만든다고 가정해보자.

• 올바른 아이디와 비밀번호 입력 → 로그인 성공
• 잘못된 비밀번호 입력 → 로그인 실패
• 비로그인 상태에서 접근 → 로그인 페이지 이동

이처럼 입력과 결과가 명확하다. 그래서 테스트는 비교적 단순하다. 정답이 있기 때문이다.

하지만 생성형 AI 제품에서는 이 방식이 어려워진다.

예를 들어 AI가 [회의 요약]을 한다고 할 때,
같은 회의 내용을 입력해도 응답은 매번 달라질 수 있다.
어떤 요약은 결론 중심으로 요약했고, 어떤 요약은 간단한 맥락까지 포함했을 수 있다.

이럴 때는 둘 중 어느 것이 하나의 <정답>인지 정의하기 어렵다는 점이다.

그래서 AI 제품에서는 테스트(Test)보다 평가(Evaluation)가 중요해진다.

기존 제품 테스트는 보통 이렇게 정의된다.

• 기대 결과(Expected result)가 존재한다
• 결과가 일치하면 pass, 다르면 fail
   

그런데 AI 결과는 pass / fail 로 나누기보다 
좋다 / 보통이다 / 나쁘다 처럼 품질의 수준으로 평가해야 하기 때문이다.

예를 들어 [AI 요약 기능]이라면 다음과 같은 기준으로 평가하게 된다.

• 핵심 내용이 포함되어 있는가
• 불필요한 내용이 줄어들었는가
• 문장이 자연스러운가
• 사실 관계가 유지되는가
• 사용자 의도와 맞는가
   

이건 기능이 된다/안된다의 테스트라기 보다는 판단 품질을 평가하는 기준이다.

기존 제품에서는 테스트 케이스가 명확하다. (입력 A → 결과 B)
생성형 AI 제품에서는 하나의 입력에 대해 다양한 결과가 가능하다.

그래서 테스트 케이스 대신 평가 세트(Evaluation set)를 사용하게 된다.
다양한 입력 데이터를 준비하고, 여러 결과를 비교하고, 평균적인 품질을 평가한다.
즉, 단일 테스트가 아니라 전체 분포를 보는 방식으로 바뀐다.

또 하나의 차이는 품질 기준이 고정되지 않는다는 점이다.

기존 제품에서는 기능이 동작하면 테스트는 완료된다.

하지만 AI 제품에서는 출시 이후에도 평가 기준이 계속 바뀐다.
사용자 피드백이 쌓이고 실제 사용 데이터가 늘어나면서 더 좋은 판단 기준이 발견되기 때문이다.

그래서 AI 제품에서는 테스트가 한 번으로 끝나지 않는다. 지속적인 평가와 개선이 필요하다.

이 변화는 PM 역할에도 영향을 준다.

기존 제품에서는 PM이 기능 요구사항을 정의하고 QA 팀이 테스트를 수행했다면,
AI 제품에서는 PM이 평가 기준 자체를 정의해야 한다.

✔️ 무엇이 좋은 결과인가
✔️ 어떤 수준이면 충분한가
✔️ 언제 fallback 해야 하는가
✔️ 어떤 데이터를 수집할 것인가

이 기준이 없으면 AI 품질을 판단할 수 없기 때문이다.

AI 제품에서의 테스트는 기능 동작 여부가 아니라, AI의 판단 품질을 정의하고 개선하는 과정이다.

AI 제품에서는 단 하나의 정답이 없다. 더 나은 판단이 있을 뿐이다.
그래서 AI PM의 역할도 이러한 판단의 기준을 설계하는 것이 중요해지고 있다.

*더 많은 글은 브런치에서 보실 수 있습니다.