LLM 기반 시스템을 평가하는 방법은 크게 온라인 평가와 오프라인 평가로 나눌 수 있습니다. 각 방식은 서로 다른 장단점을 가지고 있으며, 시스템의 개발 단계와 목적에 따라 적절히 선택하거나 조합해 사용해야 합니다.
| 측면 | 오프라인 평가 | 온라인 평가 |
|---|---|---|
| 데이터 소스 | 사전 구축된 데이터셋 | 실제 사용자 상호작용 |
| 비용 | 상대적으로 저렴 | 상대적으로 비쌈 |
| 시간 | 빠른 결과 | 데이터 수집에 시간 소요 |
| 위험 | 낮음(실제 사용자 노출 없음) | 높음(사용자 경험에 직접 영향) |
| 통제 | 높음(환경 통제 가능) | 낮음(다양한 외부 요인 존재) |
| 현실성 | 제한적(실제 상황 완벽 반영 어려움) | 높음(실제 사용 환경) |
| 반복성 | 높음(동일 조건 반복 가능) | 낮음(동일 조건 재현 어려움) |
| 피드백 루프 | 없음 | 있음(사용자 반응에 따른 상호작용) |
| 유용성 | 개발 초기, 세부 기능 평가, 회귀 테스트 | 실제 환경 성능, 사용자 경험, 장기적 효과 |
20.1 오프라인 평가
19장의 골든 데이터셋을 활용한 평가가 대표적인 오프라인 평가 방식입니다.
마치 자동차를 출시하기 전에 테스트 트랙에서 충돌 테스트와 성능 테스트를 반복하는 것처럼, 오프라인 평가는 실제 사용자에게 노출되기 전에 시스템의 기본적인 성능과 안전성을 검증하는 역할을 합니다.
장점
- 통제된 환경: 고정된 데이터셋을 쓰므로 동일한 조건에서 여러 시스템이나 구성을 비교할 수 있다. 실제 사용자 환경에서는 불가능한 수준의 통제를 제공한다.
- 반복 가능성: 프롬프트의 한 단어만 수정하더라도 그 효과를 즉시 확인할 수 있고, 이러한 빠른 피드백 루프가 효율적인 개발을 가능하게 한다.
- 효율성: 실제 사용자와의 상호작용 없이 대량의 테스트를 수행할 수 있어 수백 개의 질문을 몇 분 만에 처리한다.
- 비용 효율성: 실제 사용자를 모집하거나 실시간 서비스를 운영할 필요가 없어 스타트업이나 초기 개발 단계에서 제한된 예산으로도 충분한 평가가 가능하다.
- 세부 지표 분석: 검색 정확도, 응답 품질 등 특정 측면에 집중해 강점과 약점을 명확히 파악할 수 있다.
방법론도 다양합니다. 시뮬레이션 기반 평가로 사용자 시나리오를 시뮬레이션해 견고성을 테스트하고, 교차 검증(cross validation) 으로 데이터셋을 여러 부분으로 나눠 일반화 성능을 평가하며, 오류 분석(error analysis) 으로 어떤 유형의 질문에서 실패하는지 체계적으로 분석해 개선 우선순위를 결정합니다. CI/CD 파이프라인에 평가를 통합하면 성능 저하를 유발할 수 있는 변경이 실수로 적용되는 것을 방지하는 안전망이 됩니다.
한계 네 가지
| 한계 | 내용 |
|---|---|
| 실제 사용자 행동 반영의 한계 | 가장 큰 약점. 실제 사용자들은 종종 모호하거나 불완전한 질문을 하며, 맥락이 부족한 상황에서 시스템을 사용한다. 또한 사용자마다 배경지식과 기대치가 달라 동일한 응답이라도 만족도가 크게 달라질 수 있다 |
| 동적 상호작용의 부재 | 실제 대화에서는 사용자가 응답을 보고 추가 질문을 하거나 질문을 수정하는 경우가 많다. 이러한 다단계 상호작용은 단일 질문-답변 쌍으로는 평가하기 어렵다 |
| 시간 경과에 따른 변화 반영 어려움 | 사용자의 관심사와 질문 유형은 변하지만 고정된 데이터셋은 이를 반영하기 어렵다. 세법처럼 정기적으로 개정되는 도메인에서는 데이터셋의 시의성이 매우 중요하다 |
| 편향된 데이터셋의 위험 | 데이터셋 구축자의 관점이나 경험이 반영되면서 특정 유형의 질문에 편향될 수 있다 |
20.2 온라인 평가
온라인 평가는 실제 사용자와의 상호작용을 바탕으로 시스템 성능을 실시간으로 측정하는 방법입니다.
A/B 테스트로 객관적인 성능 차이를 확인하고, 사용자 피드백으로 그 원인과 맥락을 파악하며, 행동 지표로 장기적인 트렌드와 실제 사용 패턴을 모니터링하는 삼각 검증(triangulation) 방식이 바람직합니다.
비즈니스 관점에서 온라인 평가는 실제 ROI와 사용자 만족도를 측정하는 핵심 도구입니다. 기술적으로 우수한 시스템이라도 사용자가 실제로 사용하지 않거나 만족하지 않으면 비즈니스 성공으로 이어지기 어렵기 때문입니다.
주요 가치
- 실제 사용 환경에서의 검증: 사용자는 디바이스, 네트워크 상황, 시간대, 심리적 상태 등 다양한 조건에서 시스템을 쓴다. 예상치 못한 입력, 방해 요소, 멀티태스킹 상황은 통제된 오프라인 환경에서 재현하기 어렵다.
- 동적 피드백의 실시간 수집: 특정 기능에 대한 반응이 부정적이라면 즉시 개선에 착수할 수 있다.
- 예측 불가능한 상호작용 패턴의 발견: 실제 사용자들은 종종 시스템을 의도하지 않은 방식으로 사용하거나 창의적인 질문을 던진다. 이런 상황에서의 반응을 관찰해 견고성을 높이고 엣지 케이스를 개선한다.
- 다차원적 사용자 경험 측정과 시간에 따른 변화 추적.
한계 다섯 가지
높은 비용과 자원 소모(인프라·리크루팅·고객 지원·분석 시스템 운영), 시간적 제약(저빈도 시나리오나 장기 효과는 수개월~수년), 통제의 어려움(경쟁사 움직임·경제 상황·사회적 이슈), 위험 부담(특히 세무·법률 분야는 금전적 손실과 법적 책임까지), 반복 실험의 어려움(사용자는 이전 경험에 영향을 받으므로 완전히 동일한 조건의 반복은 실질적으로 불가능).
① A/B 테스트 — 6단계 절차
| 단계 | 핵심 |
|---|---|
| 1. 테스트 목표와 가설 수립 | 한 번에 하나의 변수만 변경한다. ‘새로운 검색 알고리즘이 사용자 만족도를 15% 향상시킬 것이다’ 같은 정량적 가설이 바람직하다 |
| 2. 평가 지표 설계와 우선순위 | 주요 지표(응답 만족도·검색 클릭률·문제 해결 완료율)와 보조 지표(응답 시간·세션 길이·재방문율)를 구분하고, 최소 감지 가능한 효과 크기(MDE) 와 방향성을 사전에 정의한다 |
| 3. 통계적 설계와 표본 크기 계산 | 검정력 분석으로 계산하며 보통 검정력 80%, 유의수준 5% 를 쓴다. 표본이 작으면 제2종 오류가, 지나치게 크면 실무적으로 의미 없는 작은 차이도 통계적으로 유의하게 만들 수 있다 |
| 4. 무작위 할당과 그룹 균형 | 성별·연령·사용 경험·지역 등 공변량이 균등한지 확인하고, 동일 사용자는 테스트 기간 내내 같은 그룹에 속하도록 사용자 ID나 쿠키로 할당한다 |
| 5. 실험 기간 설정과 데이터 수집 | 요일별·시간대별 변동을 고려해 최소 1~2주, 계절성이 중요한 서비스는 몇 달이 필요하다 |
| 6. 통계적 분석과 결과 해석 | t-검정, 카이제곱 검정, 비모수 검정 등을 데이터 유형에 맞게 고른다. 통계적으로 유의해도 실무적으로 의미 없는 차이일 수 있고, 유의하지 않아도 비즈니스적으로 중요한 인사이트일 수 있다 |
A/B 테스트의 가장 큰 장점은 직접적인 인과관계를 파악할 수 있다는 것입니다. 다른 조건을 동일하게 유지한 채 특정 변수만 바꾸므로 상관관계와 인과관계를 명확히 구분할 수 있습니다. 조직 내 의사결정 과정을 개선하는 효과도 있어, 직관이나 권위에 의존한 의사결정을 줄이고 실험 문화를 조성합니다.
한계는 충분한 표본 크기가 필요하다는 점입니다. 트래픽이 적은 서비스나 니치 마켓 대상 서비스에는 큰 장벽이 됩니다. 그리고 책이 각주로 정리한 세 가지 통계적 함정이 특히 값집니다.
다중 비교 문제(multiple comparisons problem): 동시에 너무 많은 변수를 테스트할 때 발생하는 오류다. p-값을 5%로 설정했더라도 20개의 버튼 색상을 동시에 테스트한다면 통계적으로 한 개 정도는 우연히 ‘성공’으로 판별될 수 있다.
피킹 문제(peeking problem): 정해진 표본 크기를 채우기 전에 결과를 미리 확인하고 조기에 실험을 중단하는 실수다. 실험 초기에는 데이터가 적어 결과의 변동 폭이 매우 크다. 이때 우연히 p-값이 유의미하게 나왔다고 실험을 멈추고 ‘성공’을 선언하면 실제로는 효과가 없는 기능을 도입하게 된다.
심슨의 역설(Simpson’s paradox): 데이터를 세부 그룹별로 나누어 봤을 때와 전체를 합쳐서 봤을 때의 결과가 정반대로 나타나는 현상이다. 모바일과 데스크톱 각각의 환경에서는 B안의 전환율이 높았더라도, 전환율이 원래 높은 ‘데스크톱 사용자’가 A안에 몰렸다면 전체 합계에서는 A안이 더 높게 나타날 수 있다.
그 밖에 일시적 외부 요인(계절성·경쟁사 캠페인), 학습 효과(새 기능에 적응하는 과정)와 참신함 효과(일시적 관심 증가), 장기 효과 측정의 어려움, 네트워크 효과가 있는 서비스에서의 독립성 가정 위배도 고려해야 합니다.
② 사용자 피드백 수집
| 방법 | 특징 |
|---|---|
| 즉시적 피드백 메커니즘 | 별점(1~5), 좋아요/싫어요 버튼. 다만 피드백 인터페이스는 사용자 경험을 방해하지 않도록 직관적이고 빠르게 조작할 수 있어야 하며, 선택적으로 제공해 부담을 주지 않아야 한다 |
| 주기적 심층 설문조사 | 월간 또는 분기별. 리커트 척도와 개방형 질문을 적절히 조합하고 사용자 세그먼트별 맞춤 질문을 구성한다 |
| 자유 형식 피드백 채널 | NLP로 주요 테마·감정·개선 요청을 자동 추출하고 분류한다 |
| 사용자 인터뷰와 포커스 그룹 | 파워 유저나 장기 사용자와의 일대일 인터뷰. 포커스 그룹은 집단 역학을 활용해 더 깊은 인사이트를 얻는다 |
장점은 정량적 지표로는 ‘무엇이’ 일어나는지 파악할 수 있지만, 질적 피드백으로는 ‘왜’ 그런 일이 일어나는지 이해할 수 있다는 점입니다. 개발팀이 예상치 못한 개선 아이디어를 발견하고, 피드백을 반영하는 과정에서 브랜드 로열티도 높아집니다.
한계는 응답 편향입니다. 불만족한 사용자가 만족한 사용자보다 더 적극적으로 피드백을 제공하는 경향이 있어 전체를 대표하지 못할 수 있습니다. 참여율이 낮다는 문제, 주관적 평가 의존, 그리고 사회적 바람직성 편향(실제 생각보다 사회적으로 바람직해 보일 답변을 하려는 경향)도 있습니다.
③ 행동 지표 분석
행동 지표 분석은 사용자가 의식적으로 표현하지 않는 진짜 행동 패턴을 기반으로 시스템의 실제 가치와 효과를 평가하는 강력한 방법입니다. 사용자의 실제 행동이 그들의 진정한 선호와 만족도를 가장 정확하게 반영한다는 전제에 근거합니다.
- 참여도와 몰입도: 세션 길이, 페이지 뷰. 다만 해석에 주의가 필요합니다. 세무 상담은 문제를 빠르게 해결해 세션이 짧으면 오히려 긍정적일 수 있습니다.
- 재사용률과 리텐션: DAU·WAU·MAU, 코호트 분석.
- 상호작용 품질과 깊이: 대화 깊이, 질문 개선율(사용자가 초기 질문을 수정하거나 구체화하는 빈도).
- 기능 사용 패턴 분석: 고급 기능의 채택률.
- 문제 해결 효율성과 성공률: 문제 해결 완료율, 외부 자원 참조 빈도(낮을수록 시스템이 충분한 정보를 제공하고 있다는 뜻).
- 오류 발생률과 복구 패턴, 학습과 적응 패턴.
장점은 자연스럽고 편향되지 않은 행동을 관찰할 수 있다는 것입니다. 사용자가 말하는 것과 실제로 하는 것 사이의 차이를 발견하는 데 특히 유용하고, 대규모 집단을 동시에 분석해 통계적 신뢰성이 높습니다.
반면 가장 큰 한계는 행동의 근본적인 원인을 파악하기 어렵다는 것입니다. 세션 시간이 짧은 것이 빠른 문제 해결 때문인지 불만족으로 인한 조기 이탈 때문인지 구분하기 어려울 수 있습니다. 또한 행동 지표는 실제 만족도의 대리 지표일 뿐이며, 때로는 실제 목표와 다른 방향으로 최적화될 수 있습니다. 개인정보 보호와 데이터 윤리에 대한 주의도 필요합니다.
20.3 하이브리드 접근법
하이브리드 접근법은 단순히 두 평가 방법을 병행하는 것이 아니라 각 방법의 고유한 강점을 극대화하고 한계를 상호 보완하는 체계적인 평가 프레임워크입니다.
개발 단계별 평가 전략
| 단계 | 목표와 활동 |
|---|---|
| ① 초기 개발 — 기술적 가능성 검증 | 오프라인 평가로 기본 성능 검증. 임베딩 모델·청킹 전략·검색 알고리즘·LLM 모델의 다양한 조합을 빠르고 저렴하게 테스트한다. 사용자 경험보다 기술적 성능에 집중 |
| ② 베타 테스트 — 실제 환경의 초기 검증 | 사내 직원·파트너사·선별된 외부 사용자 대상. 이들은 관대하고 피드백에 적극적이며 문제 발생 시 이해도가 높다. 오프라인에서는 발견할 수 없던 사용성 문제와 실제 업무 맥락의 제약을 파악하고, 네트워크 지연·동시 사용자 처리 등 실제 운영 조건 성능을 측정 |
| ③ 출시 — 시장 검증과 최적화 | A/B 테스트로 최종 구성 선택, 폭넓은 행동 데이터 수집. 평가의 중심을 기술적 성능에서 사용자 경험 지표로 전환(만족도·업무 효율성 향상·재사용 의향) |
| ④ 유지 보수 — 지속적 개선과 안정성 | 오프라인 회귀 테스트로 업데이트 영향을 사전 검증하고, 온라인 모니터링으로 성능 저하와 불만 증가를 조기 감지 |
온라인-오프라인 피드백 루프
1. 실제 사용자 데이터 수집 (온라인 평가)
2. 골든 데이터셋 개선 (수집된 데이터로 확장)
3. 오프라인 테스트 (개선된 데이터셋으로 여러 변형 테스트)
4. 온라인 검증 (가장 성능 좋은 변형을 A/B 테스트로)
5. 반복
이 루프는 시스템이 실제 사용 패턴에 적응하면서도 변경 사항의 효과를 안전하게 검증하도록 합니다.
카나리 배포
카나리 배포(canary deployment) 는 새 버전을 일부 사용자에게 점진적으로 노출해 리스크를 최소화하는 전략입니다.
- 오프라인 평가로 검증 — 새 버전을 먼저 철저히 검증
- 소규모 출시 — 검증된 버전을 매우 작은 비율(예: 1%) 의 사용자에게만 제공
- 모니터링 및 평가 — 실시간으로 성능 지표와 오류를 모니터링
- 점진적 확대 — 문제가 없으면 더 많은 사용자에게
- 회귀 옵션 — 문제 발생 시 즉시 이전 버전으로 롤백
오프라인 평가의 안전성과 온라인 평가의 현실성을 결합하는 방식입니다.
20.4 RAG 시스템을 위한 평가 전략
RAG는 검색과 생성이 결합된 시스템이라 한 컴포넌트의 오류가 다음 단계로 전파되어 최종 결과를 크게 왜곡할 수 있습니다. 게다가 검색 실패, 정보 누락, 환각 생성, 맥락 왜곡, 일관성 부족 등 실패 모드가 다양해 각각을 별도로 감지하고 측정하는 방법을 마련해야 합니다.
컴포넌트별 오프라인 평가
검색 컴포넌트는 검색 정확도와 재현율을 도메인별로 세분화해 측정하고, MRR로 랭킹 품질을 보며, 청킹 전략의 효과를 분석합니다. 너무 작은 청크는 맥락 손실을, 너무 큰 청크는 노이즈 증가를 야기합니다. 여러 임베딩 모델을 비교해 일반 모델과 도메인 특화 모델의 성능 차이를 분석해 투자 대비 효과를 평가합니다.
생성 컴포넌트는 사실적 정확성(특히 수치 정보·법령 인용·계산 과정), 응답 완전성, 근거성, 그리고 프롬프트 템플릿 비교로 평가합니다.
전체 시스템 온라인 평가
사용자 만족도(응답 후 만족도, 유용성 피드백, 응답 후 추가 질문 빈도), 행동 지표(동일 주제에 대한 반복 질문 빈도, 대화 포기율, 대화 깊이, 서비스 재사용률), 그리고 A/B 테스트(검색 알고리즘 변형 비교, top-k 최적화, LLM 모델 크기와 응답 품질의 상관관계 분석, 프롬프트 전략 비교)로 평가합니다.
여기서도 단서가 붙습니다. “더 큰 모델이 항상 더 나은 사용자 경험을 보장하는 것은 아니다.”
지속적 모니터링 및 개선
실시간 성능 모니터링은 응답 시간(컴포넌트별로 세분화), 검색 실패율 추적(검색 실패는 전체 시스템 실패로 이어지므로), 환각 발생 빈도 감지(응답과 검색 문서 간 일치도를 실시간 분석)로 구성합니다.
피드백 기반 개선은 부정적 케이스를 수집·분석해 공통 실패 패턴을 파악하고, 자주 실패하는 질문 유형을 식별하며, 발견된 실패 사례를 골든 데이터셋에 추가하고, 개선 후 동일 케이스를 재평가해 부작용이 없는지 확인합니다.
20.5 정리 — 무엇을 언제 쓰나
궁극적으로 어떤 평가 방식을 선택할지는 시스템의 개발 단계, 목적, 가용 자원, 허용 가능한 리스크 수준에 따라 달라져야 합니다. 개발 초기에는 오프라인 평가를 중심으로 하고, 출시 준비 단계에서는 온라인 평가를 강화하는 전략이 효과적입니다.
- 오프라인은 통제·반복·저비용, 온라인은 현실성·사용자 경험·ROI 입증이다.
- 오프라인의 한계는 모호한 질문과 다단계 대화를 못 담는다는 것이고, 온라인의 한계는 비싸고 위험하며 반복할 수 없다는 것이다.
- A/B 테스트는 한 번에 한 변수, 표본 크기는 사전 계산, 그리고 다중 비교·피킹·심슨의 역설을 조심한다.
- 행동 지표는 말이 아닌 행동을 본다. 단 짧은 세션이 만족인지 이탈인지 구분하려면 다른 지표와 함께 봐야 한다.
- 단계별로 무게중심을 옮긴다. 초기 오프라인 → 베타 → 출시 A/B → 유지 보수 회귀 테스트.
- 위험을 줄이려면 카나리 배포로 1%부터 시작한다.
- RAG는 컴포넌트별로 먼저, 그다음 전체 시스템을 본다. 실패 사례는 골든 데이터셋에 되먹임한다.