AI 제품 품질을 출시하기 전에 증명하는 평가 주도 개발

AI 제품 품질을 출시하기 전에 증명하는 평가 주도 개발

AI 뉴스 썸네일

생성형 AI 제품은 같은 입력에도 답이 달라질 수 있어요. 정답의 경계도 모호해서 기존 단위 테스트만으로 품질을 설명하기 어려워요. Airbnb Engineering은 실제 오류를 평가 기준으로 바꾸고, 출시 전부터 운영 단계까지 계속 확인하는 평가 주도 개발을 제안했어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
시작점	약 100개 사례의 출력과 실행 과정을 사람이 직접 읽어요	실제 사용자가 만날 실패 유형부터 평가 기준으로 만들 수 있어요
평가 구조	프로그램 검사, LLM 심판, 인간 평가를 순서대로 조합해요	비용을 줄이면서도 주관적 품질과 고위험 판단을 놓치지 않아요
보정 기준	실패 사례를 포함한 50~100개 골든 데이터셋으로 LLM 심판을 맞춰요	자동 점수가 인간 판단과 얼마나 일치하는지 확인할 수 있어요
에이전트 평가	최종 답뿐 아니라 도구 선택, 인자, 중간 상태와 실행 경로를 살펴요	우연히 맞은 답 뒤에 숨은 잘못된 과정을 찾을 수 있어요
운영 연결	비식별화한 실사용 사례를 표본으로 뽑아 새 실패를 평가에 추가해요	출시 뒤 품질 변화를 지속해서 추적할 수 있어요

1. AI 제품은 평가 기준부터 개발해야 해요

전통적인 테스트는 입력과 예상 결과를 비교하기 좋아요. 생성형 AI는 출력이 매번 달라질 수 있고, 유용성이나 말투처럼 하나의 정답으로 고정하기 어려운 항목도 많아요. 검색, 추론, 도구 호출, 답변 생성이 이어지는 시스템에서는 각 단계가 따로 실패할 수도 있어요. 최종 답변만 보면 어느 단계에서 문제가 생겼는지 놓치기 쉬워요. 2

Airbnb가 설명한 평가 주도 개발은 제품에서 발견한 오류를 명확한 평가 항목으로 바꾸는 방식이에요. 팀은 무엇을 개선할지와 출시 전에 넘겨야 할 기준을 먼저 정해요. 모든 상황을 예상하려 하기보다 실제 사례를 읽고, 반복해서 나타나는 실패를 평가 목록에 추가해요. 여러 품질을 한 번에 판단하는 거대한 평가기보다 정확성, 충실성, 간결성처럼 한 가지 기준을 맡는 평가기 3~5개를 잘 보정하는 쪽을 권해요.

728x90

출력 100개를 직접 읽는 일부터 시작해요

초기 단계에서는 합성 사례를 포함한 입력 약 100개를 실행하고 결과를 직접 살펴봐요. 답변에 없는 정책을 만들어 냈는지, 지나치게 길지는 않은지, 유효한 질문을 거부하지는 않았는지, 구조화된 데이터가 깨지지 않았는지를 기록해요. 이렇게 모은 오류 유형이 평가 항목과 출시 기준의 재료가 돼요.

평가 숫자를 먼저 만들면 제품과 동떨어진 점수를 최적화할 수 있어요. 일반적인 유용성 점수가 높아도 실제 고객이 자주 겪는 오류를 잡지 못하면 출시 판단에 도움이 되지 않아요. 제품 담당자와 도메인 전문가가 좋은 답과 나쁜 답을 함께 정의해야 하는 이유예요.

세 단계 평가가 서로의 빈틈을 메워요

JSON 형식, 필수 필드, 길이 제한처럼 코드로 판단할 수 있는 항목은 프로그램 검사로 처리해요. 빠르고 결과가 일정해서 명백한 오류를 가장 먼저 걸러내기 좋아요. 구조화된 출력은 지시문에만 의존하지 않고 스키마 검사까지 붙여야 뒤쪽 데이터 처리가 깨지는 일을 줄일 수 있어요.

말투, 관련성, 충실성처럼 규칙만으로 판단하기 어려운 항목에는 LLM 심판을 쓸 수 있어요. 평가 기준은 사람이 같은 결과에 비슷한 판단을 내릴 정도로 구체적이어야 해요. 실패 사례가 포함된 50~100개 골든 데이터셋에서 인간 레이블과 비교하고, 일치도가 80% 후반에서 90%대에 이르도록 기준과 예시를 조정해요. 자동 심판이 자신 있게 틀릴 수 있으므로 이 보정 단계를 건너뛰면 안 돼요. 1

인간 평가는 정답 데이터 작성, 고위험 판단, 자동 평가기 사이의 의견 충돌을 해결할 때 남겨 둬요. 도메인 전문가끼리도 기준에 합의하지 못한다면 자동화를 늘리기 전에 그 차이부터 정리해야 해요. 최종 출시 판단을 맡을 사람도 명확히 정해 두는 편이 좋아요.

AI 에이전트는 실행 경로까지 확인해요

AI 에이전트가 올바른 답을 냈더라도 잘못된 도구를 호출했거나 불필요하게 긴 경로를 거쳤을 수 있어요. 잘못된 인자를 넘겼는데 우연히 결과가 맞았을 가능성도 있어요. 그래서 에이전트 유형, 도구 호출, 입출력, 중간 상태를 실행 추적으로 남기고 전체 경로를 재구성해요.

이 기록이 있으면 필요한 시점에 올바른 도구를 썼는지, 하위 작업이 적절한 순서로 실행됐는지 확인할 수 있어요. 평가는 시스템 전체뿐 아니라 특정 단계로 좁힐 수도 있어요. 운영 장애가 생겼을 때 어느 구성 요소를 고쳐야 하는지도 더 빨리 찾을 수 있어요.

출시 뒤 새 오류도 평가 목록에 넣어요

평가는 출시 승인으로 끝나지 않아요. Airbnb의 예시는 비식별화한 실사용 트래픽 일부를 매일 표본으로 뽑아 프로그램 검사와 LLM 심판을 실행하고, 문제가 표시된 결과를 사람이 검토하는 흐름을 설명해요. 새 실패 유형이 발견되면 평가 항목과 제품 수정 작업으로 연결해요. 개인정보는 검토 전에 강하게 비식별화하고, 데이터 사용 목적도 안전과 품질 확인으로 제한해요. 2

왜 중요한가요

AI 기능을 출시할 때 모델 성능표 하나만으로 제품 품질을 판단하기 어려워요. 제품이 자주 받는 질문과 실제 오류를 바탕으로 출시 기준을 정해야 해요. 코드로 확인할 수 있는 항목은 자동 검사에 맡기고, 주관적인 품질은 보정된 LLM 심판으로 좁힌 뒤 고위험 사례를 사람이 결정하면 비용과 신뢰성을 함께 관리할 수 있어요. 1

개발팀은 새 기능을 붙이기 전에 실패 사례 50~100개부터 모아 볼 수 있어요. 각 사례에 기대 행동과 실패 원인을 적고, 검색·도구 호출·최종 답변을 따로 평가해요. 변경할 때는 모델, 지시문, 서빙 설정 가운데 하나씩만 바꿔야 품질 변화의 원인을 찾기 쉬워요.

자동 평가기의 점수도 검증 대상이에요. 인간과의 일치율, 평가자끼리의 불일치, 새 유형의 오류를 정기적으로 확인해야 해요. 제품 기준이 바뀌면 골든 데이터셋과 평가 기준도 함께 고쳐야 점수가 현실을 따라갈 수 있어요.

참고 자료

1. 평가 주도 개발 — GeekNews
2. Eval-Driven Development: Lessons from Evaluating GenAI at Scale — Airbnb Engineering