왜 우리의 AI 앱은 데모에서만 완벽할까?

멋진 AI 데모를 보고 감탄한 경험, 다들 한 번쯤 있죠. 하지만 막상 우리가 만든 AI 제품을 출시하면, 예상치 못한 곳에서 문제가 터지곤 합니다. 분명히 테스트할 땐 완벽했는데, 왜 이런 일이 생길까요? 이 글은 AI 앱의 품질을 ‘진짜로’ 측정하고 개선하는 법에 대한 이야기입니다.

 

테스트를 통과한 ‘과일 글자 수 세기’ 앱

여기 ‘과일 글자 수 세기’라는 간단한 앱이 있습니다. 말 그대로 과일 이름의 글자 수를 세어주는 AI 앱입니다. ‘apple’을 입력하니 ‘5’이라고 정확히 답했습니다. 두 번이나 테스트에 성공했고, 저희는 자신 있게 제품을 출시했습니다.

 

“딸기에 R이 2개라는데요?”

하지만 출시 직후, ‘존’이라는 이름의 사용자에게서 트윗이 날아왔습니다. “딸기(Strawberry)에 R이 몇 개냐고 물었더니 2개라고 답했어요.” AI 모델은 본질적으로 신뢰하기 어렵습니다. 데모에서는 멋져 보이지만, 실제 운영 환경에서는 환각(Hallucination)이 우리를 기다립니다.

 

프롬프트 엔지니어링, 10번의 성공, 그리고 또다시 실패

우리는 포기하지 않고 프롬프트를 개선하기 위해 밤을 새웠습니다. “활기 넘치는 과일 애호가 AI…”로 시작하는 멋진 프롬프트를 만들었습니다. 이번엔 같은 질문으로 10번 연속 테스트했고, 10번 모두 성공했습니다.

하지만 존은 다시 나타났습니다. 그는 이번에 “딸기, 바나나, 파인애플, 망고…” 등 긴 과일 목록을 한꺼번에 질문했습니다. 사용자는 우리가 상상하지 못한 방식으로 앱을 사용합니다. 앱의 로그인, UI 등 95%가 완벽해도, 가장 치명적인 5%의 AI 로직이 실패할 수 있습니다.

 

해답은 ‘농구 코트’에 있습니다

여기서 바로 ‘이밸(Eval)’, 즉 AI 평가의 개념이 등장합니다. 이를 설명하기 위해 농구 코트 비유를 들어보겠습니다. 골대는 ‘정답’, 농구공을 던지는 행위는 ‘사용자 질문(Task)’입니다. 슛이 성공하면 ‘파란색 점(성공)’, 실패하면 ‘빨간색 점(실패)’입니다.

 

우리 앱의 ‘코트’는 어떻게 생겼을까?

좋은 이밸을 만들려면, 먼저 우리 앱의 ‘코트’를 이해해야 합니다. “딸기에 R이 몇 개?”처럼 쉬운 질문은 골대와 가까운 ‘파란 점’일 것입니다. 존의 긴 과일 목록 질문은 골대에서 아주 먼 ‘빨간 점’이겠죠.

이 ‘코트’를 그릴 때 흔히 빠지는 함정이 있습니다. 첫째, ‘코트 밖(out-of-bounds)’ 질문에 시간을 낭비하는 것입니다. ‘당근의 음절은 몇 개?’ 같은 질문은 우리 앱의 영역이 아니죠. 둘째, 골대 앞 쉬운 질문만 테스트하는 것입니다. 코트의 경계를 명확히 알고, 구석구석 모든 영역을 테스트해야 합니다.

 

사용자 데이터 수집, 지름길은 없습니다

이 빨간 점과 파란 점들은 어떻게 수집할까요? 사용자의 ‘좋아요/싫어요’ 피드백은 훌륭한 신호가 될 수 있습니다. 꾸준히 로그를 살피며 무작위 샘플을 확인하는 것도 좋은 방법입니다.

커뮤니티 포럼이나 트위터에서 사용자의 실제 불만을 직접 파악할 수도 있습니다. 안타깝게도 이 ‘코트’를 이해하는 작업에는 지름길이 없습니다. 제대로 된 데이터셋을 구축하면, 우리 시스템이 코트의 ‘우측 하단’에서 유독 약하다는 식의 명확한 진단을 내릴 수 있습니다.

 

이밸은 유닛 테스트가 아닙니다

이밸은 유닛 테스트와 근본적으로 다릅니다. 이밸은 ‘실전 연습’에 가깝습니다. “딸기에 R이 몇 개?” 같은 ‘데이터(질문)’는 상수로 고정합니다.

우리가 실제로 바꾸며 테스트할 것은 ‘태스크(변수)’입니다. 예를 들어, 새로운 시스템 프롬프트나 RAG 설정을 이 변수에 넣고 테스트합니다. 이렇게 하면, 연습(이밸)이 실전(운영)과 거의 동일한 코드를 공유하게 되어 매우 효율적입니다.

 

점수 매기기, 단순할수록 좋습니다

마지막 단계는 이 슛이 성공했는지 ‘점수’를 매기는 것입니다. 이 점수 시스템은 가능한 한 ‘결정론적(deterministic)’이고 ‘성공/실패’로 명확해야 합니다. 점수판이 복잡하면 무엇이 잘못됐는지 디버깅하기가 극도로 어려워집니다.

스스로에게 “이 테스트가 실패했다는 것을 알려면 무엇을 확인해야 하지?”라고 질문해 보세요. 때로는 이밸 전용 프롬프트에 <answer> 같은 태그를 추가해, 점수 매기기(스트링 매칭)를 더 쉽게 만드는 트릭을 쓸 수도 있습니다. 정 코드로 만들기 어렵다면, 사람이 직접 리뷰하는 것도 괜찮습니다.

 

측정이 없으면, 개선도 없습니다

이밸 시스템을 CI(지속적 통합)에 연결하는 것을 적극 권장합니다. 동료가 프롬프트를 수정한 PR을 올렸을 때, 이 변경이 코트의 한쪽을 고쳤지만 다른 쪽을 망가뜨렸는지 바로 알 수 있습니다. “측정 없는 개선은 제한적이고 부정확합니다.”

이밸은 우리에게 시스템을 체계적으로 개선할 수 있는 ‘명확성’을 줍니다. 이는 더 높은 신뢰도, 더 높은 품질로 이어집니다. 결국 고객 지원에 쏟는 시간을 줄이고, 더 나은 사용자 경험을 만드는 선순환을 만들게 될 것입니다.

출처: AI Engineer 유튜브