AI의 PoC(Proof of Concept, 개념 증명)가 실패할 때, 그 원인이 모델의 정확도 부족 그 자체인 경우는 의외로 적다. 더 많은 이유는, 정확도라는 숫자가 나온 뒤에 그것을 어떻게 해석하고, 어떻게 사업적 판단으로 연결할지가 불분명하기 때문이다. 이 기사에서는 검색 증강 생성(RAG)을 주요 소재로 하여, AI 시스템의 평가를 「지표의 정의」, 「계측」, 「해석」이라는 세 가지 과제로 분해하고, 각각에 대한 실무적인 대처를 논한다. 아울러, 동작하는 소프트웨어를 조기에 제공하는 인크리멘털(Incremental) 개발이 개발 방법론으로서뿐만 아니라 평가의 장치로서 기능함을 보여준다.

참고로, 이 기사의 논의는 특정 도구나 제품에 의존하지 않는다. RAG 애플리케이션의 프로토타입을 단기간에 구동하는 수단은 주요 클라우드의 매니지드 서비스(Managed Service), OSS 프레임워크, 사내 인프라 중 어느 것이든 실현 가능하며, 이하의 논의는 그 모두에 적용될 수 있다.

평가를 가로막는 세 가지 과제

1. 지표의 정의: 단일 축으로 환원할 수 없는 업무

평가 기준은 관계자 전원이 이해할 수 있는 단순한 지표인 것이 이상적이다. 하지만 지금까지 인간이 수행해 온 업무를 AI로 대체할 경우, 그 업무의 품질은 왕왕 복합적인 축으로 이루어져 있다. 문서 검색을 동반하는 문의 대응이라면, 답변의 정확성, 근거 제시, 망라성, 톤의 적절성은 독립적으로 좋고 나쁨이 갈릴 수 있다. 업무의 본질을 포착하려 할수록 지표는 복잡해지며, 복잡해질수록 관계자의 공통 이해로부터 멀어진다. 여기에는 본질적인 트레이드오프(Trade-off)가 존재한다.

2. 계측: 정답 데이터가 존재하지 않음

지표를 정의할 수 있어도, 계측에는 리퍼런스, 즉 Golden Data(평가용 정답 포함 데이터셋)가 필요하다. RAG라면 "이 질문에는 이 문서의 이 부분을 근거로 이렇게 답해야 한다"라는 어노테이션(Annotation)이다. 실무에서는 이 데이터가 갖춰져 있지 않은 것이 오히려 일반적이며, 정비에는 전문 인력의 시간이라는 높은 비용이 든다. 계측할 수 없는 것은 개선할 수 없다는 원칙이 프로젝트 첫날부터 무너져 있는 것이다.

3. 해석: 숫자가 나와도 판단할 수 없음

세 가지 중 가장 간과되기 쉽고, 또한 가장 심각한 것이 이 과제이다. precision이나 recall 같은 지표의 정의는 어렵지 않다. 어려운 것은, 계측 결과로서 정확도 95%, 혹은 70%라는 숫자가 나왔을 때, 그것이 사업적 이용에 가치가 있는지를 판단하는 것이다. 100%는 통상 달성되지 않는다. 그렇다면 몇 %라면 좋은 것인가? 이 질문에 책상 위에서 답할 수 있는 관계자는 대부분 존재하지 않는다. 지표의 산출과 지표의 해석은 별개의 작업이며, 후자를 위한 구조를 갖추지 못한 PoC는 좋은 숫자가 나오든 나쁜 숫자가 나오든 앞으로 나아가지 못한다.

전제의 정리: 무엇을 평가하고 있는지를 분리하기

세 가지 과제에 임하기 전에, RAG 평가에서 가장 빈번하게 발생하는 혼동을 제거해 둘 필요가 있다. 그것은 검색(Retrieval)의 평가와 시스템 전체(End-to-End) 평가의 혼동이다.

precision@k나 recall은 검색 컴포넌트가 적절한 문서를 취득했는지를 측정하는 지표이다. 반면, "챗봇의 답변이 허용 가능한가"는 검색 결과를 받은 생성을 포함한 시스템 전체의 출력 품질 문제이며, 충실성(Faithfulness: 답변이 취득한 문서에 근거하고 있는가)이나 답변의 적절성과 같은 별도의 계통 지표로 측정해야 할 대상이다. 검색 정확도가 높더라도 생성이 근거를 무시하면 답변은 나빠지며, 검색이 불완전하더라도 생성이 적절하게 "모른다"라고 답하면 피해는 한정된다.

이 분리는 단순한 용어 정리가 아니다. 어느 계층에서 실패했느냐에 따라 대처 방법이 완전히 다르기 때문에 (검색의 실패라면 청킹(Chunking)이나 임베딩 모델의 변경, 생성의 실패라면 프롬프트나 모델의 변경), 혼동한 채로 "정확도"를 하나의 숫자로 이야기하면 개선 루프 자체가 돌아가지 않게 된다. 이후 이 기사에서 "평가"라고 말할 때는, 이 두 계층을 의식적으로 구별한 상태에서의 논의로 한다.

Golden Data 부재 시의 평가 아키텍처

계측의 과제(과제 2)에 대해 "데이터가 갖춰질 때까지 기다린다" 이외의 선택지를 갖는 것이 PoC의 속도를 결정한다. 실무상 유효한 것은 정답 데이터에 대한 의존도가 다른 여러 평가 수단을 단계적으로 조합하는 것이다.

제1단계는 소수 정예의 테스트 세트이다. 망라적인 Golden Data 정비를 기다리는 것이 아니라, 도메인 전문가에게 "이것에 답하지 못하면 말이 안 된다"라는 질문을 20~50건 정도 뽑아달라고 요청하고, 정답의 요점만을 기입한다. 통계적인 대표성은 없지만, 치명적인 결함을 검출하기에는 충분하며 정비 비용은 몇 시간 내로 끝난다.

제2단계는 생성에 대한 루브릭(Rubric, 평가 기준표) 평가이다. 검색은 precision@k나 recall로 기계적으로 평가할 수 있으므로, 사람이나 LLM의 판단을 요하는 루브릭은 검색과 독립적인 생성 품질에 집중하여 사용하는 것이 합리적이다. 전체를 하나의 척도로 밀어 넣는 것이 아니라, 생성 품질을 여러 축—예를 들어 충실성(취득한 문서에 근거하고 있는가), 내용의 정확성, 망라성, 톤의 적절성—으로 나누고, 각 축에 대해 각각 순서가 정해진 단계를 정의한다. 이는 과제 1(복합적인 평가 축) 및 앞 절에서 언급한 검색·생성의 분리에 대한 응답이기도 하다. 복잡한 단일 지표에 업무의 본질을 억지로 끼워 맞추는 것이 아니라, 단순한 축을 여러 개 가지고 각 축을 단계별로 파악하는 것이 관계자의 이해와 개선 지침 모두에 도움이 된다.

제3단계로서 LLM을 평가자로 사용하는 경우(LLM-as-a-judge), 교정(Calibration)을 전제 조건으로 한다. LLM을 통한 자동 평가는 확장성(Scale)이 있지만, 그 판정이 인간 전문가의 판정과 어느 정도 일치하는지를 소수의 샘플로 반드시 검증한 뒤에 사용해야 한다. 교정 없는 자동 평가는 측정의 과제를 해결한 것처럼 보이지만, 실제로는 해석 불가능한 숫자만을 양산할 뿐이다.

이 3단계 구성의 핵심은 평가의 정밀도와 비용 사이의 트레이드오프(Trade-off)를 프로젝트 단계에 따라 의식적으로 선택하는 것에 있다. PoC 초기 단계에 필요한 것은 통계적으로 엄격한 측정이 아니라, 개선 방향을 결정할 수 있을 정도의 해상도이다.

움직이는 소프트웨어는 평가 장치이다

지금까지의 논의는 지표 설계에 관한 것이지만, 과제 3(해석)은 지표 설계만으로는 해결되지 않는다. 70%라는 숫자의 의미는 그 70%에 포함된 성공과 실패의 내용을 보지 않고서는 판단할 수 없기 때문이다.

인크리멘털(Incremental) 개발—최소한의 기능을 가진 움직이는 애플리케이션을 조기에 제공하고, 그곳에 검증을 쌓아가는 방식—이 평가에서 수행하는 역할은 바로 여기에 있다. 보고서의 숫자만 받는 경우와 달리, 관계자가 실제로 입력과 출력을 조작할 수 있는 환경이 있으면 다음과 같은 메커니즘이 작동한다.

첫째, 정성적인 경험이 정량 지표의 해석을 교정한다. "recall 70%"라는 추상적인 숫자는 실제 실패 사례를 10건 확인한 관계자에게는 구체적인 의미를 갖는다. 실패 사례 안에도 "전혀 허용할 수 없는 오류", "일부는 허용 가능한 불완전함", "운영 프로세스를 정비하면 흡수할 수 있는 결락"이라는 색채의 차이가 있다는 점은 출력을 직접 접해봐야만 판별할 수 있다. 지표가 복잡할수록 이러한 경험을 통한 교정의 가치는 커진다. 즉, 체험 환경의 존재는 과제 1에서 언급한 트레이드오프(정확하지만 복잡한 지표는 이해되지 않는다)를 완화하고 지표 선택의 자유도를 높인다.

둘째, 도메인 특유의 실패 모드(Failure mode)가 조기에 노출된다. AI 개발자가 상정하는 에러 분류와 도메인 전문가가 업무상 중대하다고 간주하는 에러 분류는 많은 경우 일치하지 않는다. 전문가가 실제로 접하는 환경은 개발자가 특정할 수 없는 과제를 평가 데이터를 정비하기 전이라도 찾아낸다. 이는 과제 2에 대한 시간적 헤지(Hedge)로 작용한다. 즉, Golden Data를 수집하는 기간을 과제 발견에 활용할 수 있다.

셋째, Go/No-Go 판단의 재료가 숫자에서 구조로 바뀐다. 사업적 판단에 필요한 것은 "정확도가 몇 %인가"가 아니라, "어떤 종류의 오류가 어떤 빈도로 발생하며, 각각의 업무상 비용은 얼마이고, 어디까지가 운영으로 흡수 가능한가"이다. 오류의 비대칭성—예를 들어 "답변하지 않는" 오류와 "틀린 내용을 자신 있게 답변하는" 오류의 비용 차이—은 체험을 통해서만 관계자 간에 합의될 수 있다. 이 구조가 갖춰졌을 때, 70%라는 숫자는 비로소 판단 가능한 정보가 된다.

요약

AI PoC에서의 평가 난제를 지표의 정의·측정·해석 세 가지로 분해했다. 정의의 과제에는 단순한 축의 병용으로, 측정의 과제에는 정답 데이터에 대한 의존도를 단계화한 평가 아키텍처로, 그리고 가장 심각한 해석의 과제에는 움직이는 소프트웨어를 통한 관계자의 교정으로 대응할 수 있다.

인크리멘털 개발을 "빨리 만들기 위한 수법"이 아니라, "판단 가능한 평가를 성립시키기 위한 장치"로 위치시킨다. 검색과 생성을 분리하여 측정하고, 단계화된 평가 수단으로 숫자를 도출하며, 실제 출력과의 접촉을 통해 그 숫자의 의미를 관계자 간에 교정한다. 이 구조를 첫 PoC 설계에 포함하는 것이 이후 본 프로덕션 개발의 성패를 크게 좌우한다.

참고 문헌

[1] D. Sculley et al. Hidden Technical Debt in Machine Learning Systems. NIPS, pp. 2503–2511, 2015.

l. Hidden Technical Debt in Machine Learning Systems. NIPS, pp. 2503–2511, 2015.

[2] C. Larman and V. R. Basili. Iterative and Incremental Developments: A Brief History. Computer, vol. 36, no. 6, pp. 47–56, 2003.

[3] Beck, K. et al. Principles behind the Agile Manifesto. https://agilemanifesto.org/principles.html, 2001.

논의 (Discussion)