brunch

AI 제품의 QA는 무엇이 달라져야 할까?

Part 8. 체크리스트를 넘어선 실험 기반 QA 구조

by Alicia in Beta
Part 8. 핵심 요약

1. 기존 QA 방식으로는 생성형 AI 제품의 품질을 충분히 담보할 수 없다.
2. 기능 명세 기반의 테스트는 LLM 기반 응답의 불확실성과 다양성을 다룰 수 없다.
3. PM은 QA 담당자와 함께 실험 중심의 품질 판단 체계를 설계하고, LLM을 붙이기 전후로 완전히 다른 제품 흐름이 된다는 점을 고려한 테스트 설계를 리드해야 한다.






기존 디지털 제품의 QA는 명확한 기능 명세와 그에 따른 시나리오를 기준으로 이루어졌다. 버튼을 누르면 어떤 화면이 나오는지, 어떤 조건에서 어떤 결과가 출력되는지—정확한 정의와 시나리오가 있었고, 테스트 케이스는 이를 검증하는 방식으로 설계되었다.


AI 제품에서는 QA가 가장 어렵고도 모호한 영역이다. 그 이유는 단 하나—예측이 안 되기 때문이다.


명세서가 있어도 모델이 정확히 따르지 않는다. 테스트 케이스를 정의해도, 같은 입력에 매번 같은 응답이 나오지 않는다. 그렇다고 QA를 포기할 수도 없다. 그렇다면, 우리는 QA를 어떻게 다시 바라봐야 할까?




1. 사라지는 명세서: 기능이 아닌 흐름을 테스트


기존 QA의 기본 단위는 '기능 명세'였다. 하지만 LLM이 붙는 순간, 이 명세는 추상화된다. 동일한 입력에도 매번 다른 결과를 내는 AI의 응답을 어떻게 하나의 기준으로 테스트할 수 있을까?


예를 들어, 챗봇 응답의 품질을 QA하려 한다고 해보자. 기존 방식처럼 "이 질문에 이 답이 나와야 한다"고 정의하는 것이 무의미해진다. 테스트는 단지 "응답했는가"만 검증할 수 있고, 그 안의 내용은 QA 범주에서 벗어나버린다. 하지만 우리는 알고 있다. 이 '내용'이야말로 사용자 경험의 전부이며, 제품의 성공을 좌우하는 핵심이라는 것을.


그래서 QA는 이제 '기능 중심'에서 '흐름과 응답 경험 중심'으로 재설계되어야 한다. 그 흐름 속에서 AI가 언제 등장하고, 그 응답이 어떤 역할을 하며, 사용자의 목적 달성에 어떤 영향을 미치는지를 중심으로 테스트 항목을 구성해야 한다.




2. LLM 이후, 테스트는 새로 시작된다


내가 경험한 가장 실무적인 깨달음은 이거였다:

LLM을 붙이는 순간, 지금까지 만든 모든 기획/설계/디자인은 현실에서 무력해질 수 있다.


기존처럼 기획자가 수십 가지 시나리오를 고민하고, 디자이너가 UX와 화면을 구성하고, 개발자가 구현한 최고의 기능일지라도—실제 모델이 어떻게 응답하느냐에 따라 제품 경험이 완전히 달라질 수 있다. 이건 단지 QA의 문제가 아니라, 제품 전체의 완성도와 직결된다.


그래서 나는 팀에서 항상 강조했다. "모든 기능은 LLM을 붙인 뒤에야 진짜 테스트가 가능하다."

아이디어 단계든, 디자인이 완료된 상태든, 상관없다. 일단 LLM API를 붙여보고, 사용자의 입력과 응답 흐름을 확인하면서 그 뒤를 논의해야 한다. 이 원칙은 초기 스타트업이든, 스케일업 단계이든 모두에게 적용된다고 생각한다.




3. 예측 대신 실험


QA의 방식이 바뀌면, 역할도 달라진다. 좋은 QA는 이제 기능 구현 여부를 검수하는 것에서 더 나아가, 제품 전체 흐름 속에서 사용자 경험의 적절성과 신뢰성을 검토하고, 반복 실험으로 문제를 구체화하는 파트너다.


PM은 QA 팀을 체크리스트 수행자가 아닌 실험 설계의 동료로 인식해야 한다. 실제 기능 QA 뿐만 아니라, 전체적으로 사용자 관점에서 미묘한 응답의 어색함이나 반복성, 흐름 속 단절 등을 발견하고, 이를 기준으로 LLM 프롬프트나 설계를 개선하는 데 큰 역할을 할 수 있다.


나는 제품팀과 다음과 같은 실험적 테스트 방식을 최대한 활용했다. 이 중 상황에 따라 선택적으로 적용하면 좋다:

프롬프트 단위 A/B 테스트로 응답 품질 비교

유사 입력군에 대한 응답 일관성 및 유용성 측정

사용자 피드백을 QA 지표로 반영하는 항목 설계

내부 툴/Test 환경에서 실제 사용자 조건과 유사한 QA 테스트 실행

제한된 사용자 비율로 테스터 모집하여 정성 피드백 수집

LLM 기반 자동 평가 모델을 활용한 반복 테스트 자동화 시도 등


이처럼 QA는 실험의 언어로 재구성되어야 한다. 예측이 아니라 관찰과 측정을 통해 품질을 찾아가는 구조, 반복할 수 있는 작은 단위의 실험을 쌓아가는 구조가 되어야 한다.


한 가지 덧붙이자면, 여기서 말하는 QA는 어디까지나 ‘제품 흐름’ 기준의 테스트를 의미한다. 실제로는 QA와 병렬로, LLM 자체의 성능 평가 체계도 별도로 설계되어야 한다. 프롬프트별 응답 품질, 맥락 이해 수준, 응답 속도, 비용 효율성, 사용자 피드백 등을 포괄하는 정량/정성 평가 체계가 바로 그것이다. Part 3에서 다뤘던 품질 관리 및 LLM 평가(Evaluation)와 연계해, QA와 LLM 평가가 함께 제품의 완성도를 높이는 방향으로 구성되어야 한다.







우리는 이제 QA를 더 이상 '검증 체크리스트'로만 다룰 수 없다.

특히 AI 제품에서의 QA는, 기능 구현의 완료 여부보다도 실제로 유저에게 '가치 있는 경험이 전달되는가'를 확인하는 과정이다.


기능 QA도 물론 여전히 중요하다. 하지만 그 이상으로, 우리는 사용자의 여정과 AI의 응답을 연결하는 흐름을 테스트해야 하고, 명세가 없는 영역에서 실험으로 품질을 측정해야 하며, 팀 전체가 이 실험을 반복할 수 있는 구조를 만들어야 한다.


QA는 더 이상 끝단의 검증이 아니다. AI 제품에서는 오히려 시작점이 될 수 있다.



변수를 통제하려면 결국 빠르고, 작게, 사용자와. (image generated by GPT-4o)



다음 글에서는 AI 제품의 운영과 개선에 대해 이야기해보려 한다. 제품은 릴리즈 이후에도 계속 학습하고 변화해야 한다. 특히 생성형 AI가 포함된 제품은 사용자 피드백 시스템의 재설계 없이는 진화할 수 없다.





▶️ 다음 글: AI 제품, 출시 이후가 진짜 시작이다

◀️ 이전 글: AI 제품의 모델 선택과 운영 전략


*본 글의 전체 시리즈는 여기에서 확인할 수 있습니다.




keyword
이전 09화AI 제품의 모델 선택과 운영 전략