골든 데이터셋과 평가 전략 — 안정적인 AI 에이전트를 위한 마지막 퍼즐
AI 에이전트를 만들고 나면 한 가지 질문이 남는다. "이거 잘 되고 있는 거 맞아?" 프롬프트 바꿨더니 이전보다 나아진 건지, 모델 버전 올렸더니 오히려 퇴보한 건 아닌지. 솔직히 나도 처음엔 수동으로 몇 개 질문 던져보고 "음, 괜찮은데?" 하고 넘겼다. 그러다 프로덕션에서 터지면 그때서야 허둥지둥하게 된다.
이 글에서는 골든 데이터셋이라는 개념에서 출발해, 오프라인과 온라인 평가를 어떻게 엮는지, LangSmith로 실제 에이전트를 평가하는 흐름, 그리고 이 분야가 어디로 향하고 있는지까지 정리해봤다. 전부 다루려는 건 아니고, 내가 실제로 고민했던 부분들 위주로 썼다.
골든 데이터셋이라고 해서 거창한 게 아니다
골든 데이터셋(Golden Dataset)은 "정답이 달린 테스트 세트"다. 입력과 기대 출력이 쌍으로 있고, 사람이 직접 검증한 데이터. 이게 전부다. 거창하게 들리지만 실은 꽤 단순한 개념이다.
예를 들어 RAG 기반 고객 응대 봇을 만들었다면, "환불 정책이 뭐야?"라는 질문에 대해 기대하는 정답을 미리 적어두는 것이다. 이런 쌍을 50개, 100개 모아두면 그게 골든 데이터셋이 된다.
근데 막상 만들어 보면 생각보다 까다롭다. 몇 가지 삽질 끝에 알게 된 것들이 있다.
대표성이 핵심이다. 쉬운 질문만 모아두면 벤치마크 점수는 좋은데 실전에서 터진다. Microsoft의 RAG 평가 가이드에서도 강조하는 건데, 단순 질문, 복합 질문, 오타가 섞인 질문, 악의적 질문까지 골고루 담아야 한다. 내 경험상 "이건 잘 되겠지" 하고 넘긴 유형에서 사고가 난다.
골든 데이터셋의 구조는 보통 이런 식이다:
- 입력(Input): 사용자 질문이나 요청
- 기대 출력(Expected Output): 정답 또는 정답의 핵심 요소
- 컨텍스트(Context): RAG라면 참조해야 할 문서 조각
- 메타데이터: 난이도, 카테고리, 엣지 케이스 여부 등
여기서 한 가지 함정이 있는데, 기대 출력을 너무 엄격하게 잡으면 안 된다는 거다. LLM은 같은 의미를 다른 문장으로 표현할 수 있으니까. "정확히 이 문장이어야 한다"보다 "이 핵심 정보가 포함되어야 한다" 식으로 정의하는 게 실용적이다.
구축할 때 실질적으로 도움이 되는 팁
처음부터 완벽한 데이터셋을 만들려고 하면 영원히 시작을 못 한다. 20~30개로 시작해서 점진적으로 늘려가는 게 현실적이다.
가장 좋은 소스는 실제 프로덕션 로그다. 사용자가 실제로 하는 질문은 내가 예상한 것과 꽤 다르다. 처음에 내가 머리 싸매고 만든 테스트 케이스보다, 프로덕션에서 수집한 실패 사례 10개가 훨씬 값지다.
그리고 데이터셋을 "살아 있는 문서"로 취급해야 한다. 새로운 실패 패턴이 발견되면 추가하고, 도메인이 바뀌면 업데이트하고, 주기적으로 리뷰한다. 버전 관리도 필수다. 어느 시점의 데이터셋으로 평가한 건지 추적이 안 되면 비교 자체가 무의미해진다.
합성 데이터(Synthetic Data)로 초기 데이터셋을 부트스트래핑하는 방법도 있다. LLM에게 "이 문서를 기반으로 사용자가 할 법한 질문 20개를 만들어줘"라고 하면 꽤 괜찮은 초안이 나온다. 다만 이건 반드시 사람이 검수해야 한다. LLM이 만든 질문은 실제 사용자 패턴과 다를 수 있으니까.
오프라인 평가 vs 온라인 평가 — 둘 다 필요하다
평가 전략을 크게 나누면 오프라인과 온라인 두 갈래다. 어느 쪽이 더 낫다가 아니라, 각각 잡아내는 게 다르다.
오프라인 평가: 배포 전에 잡을 수 있는 것들
오프라인 평가는 배포 전에 골든 데이터셋이나 자동화된 테스트 스위트를 돌려보는 것이다. CI/CD 파이프라인에 넣으면 프롬프트 수정할 때마다 자동으로 회귀 테스트가 돌아간다.
장점은 명확하다. 재현 가능하고, 빠르게 반복할 수 있고, 프로덕션에 올리기 전에 잡을 수 있다. 프롬프트 하나 바꿨는데 기존에 잘 되던 케이스가 깨지는지 바로 확인 가능하다.
주요 메트릭으로는 정확도(Correctness), 충실도(Faithfulness), 관련성(Relevance) 같은 것들이 있고, RAG 시스템이면 여기에 검색 정밀도(Precision@k), 재현율(Recall@k), 문맥 충분성(Context Sufficiency) 같은 검색 품질 지표가 추가된다.
LLM-as-a-Judge도 오프라인 평가에서 많이 쓴다. 사람 평가는 비용이 크니까, GPT-4나 Claude 같은 모델에게 "이 응답이 기대 출력과 의미적으로 일치하는지 1-5점으로 평가해줘"라고 하는 방식이다. 완벽하진 않지만, 규모 있는 평가를 자동화할 수 있다는 점에서 실용적이다.
온라인 평가: 실전에서만 보이는 것들
여기가 좀 다르다. 온라인 평가는 실제 프로덕션 트래픽을 대상으로 한다. A/B 테스트, 사용자 피드백(좋아요/싫어요 버튼), 실시간 모니터링이 여기에 해당한다.
오프라인에서 아무리 점수가 좋아도, 실제 사용자가 예상 못한 방식으로 질문하거나, 데이터가 바뀌었거나, 트래픽 패턴이 달라지면 성능이 떨어질 수 있다. 이런 드리프트(drift)는 온라인 모니터링으로만 잡힌다.
실시간으로 추적하면 좋은 것들:
- 응답 레이턴시(P50, P99)
- 토큰 사용량과 비용
- 에러율
- 사용자 만족도 점수
- 환각(hallucination) 발생 빈도
하이브리드가 현실적이다
결론적으로 둘 다 해야 한다. 오프라인 평가로 기본 품질을 보장하고, 온라인 평가로 실전 상황을 모니터링하는 구조. Webflow 같은 회사는 일상적으로 자동화된 평가를 돌리고, 주간 단위로 사람이 직접 리뷰하는 하이브리드 접근을 쓴다고 한다.
이상적인 흐름은 이렇다: 프로덕션 로그에서 흥미로운 케이스를 골라내고 → 골든 데이터셋에 추가하고 → 오프라인 테스트를 강화하고 → 다시 배포 후 온라인으로 검증. 이 순환이 계속 돌아야 평가 품질이 올라간다.
RAG 시스템이라면 평가가 더 복잡해진다. 검색이 잘 됐는지(retrieval quality)와 생성이 잘 됐는지(generation quality)를 분리해서 봐야 하기 때문이다. 검색은 잘 됐는데 생성에서 환각이 생길 수 있고, 반대로 검색이 엉뚱한 문서를 가져와서 아무리 생성을 잘 해도 답이 틀릴 수 있다. 이 두 축을 독립적으로 평가하는 게 핵심이다.
LangSmith로 에이전트 평가하기
LangSmith는 LangChain 팀에서 만든 관측성(Observability) + 평가 플랫폼이다. LangChain으로 만든 에이전트만 되는 게 아니라 OpenAI SDK, Anthropic SDK, LlamaIndex 등 어떤 프레임워크로 만든 LLM 앱이든 트레이싱과 평가가 가능하다.
데이터셋과 실험
LangSmith에서 골든 데이터셋을 관리하는 방식이 꽤 직관적이다. 데이터셋을 만들고, 각 예시(Example)에 입력과 기대 출력을 넣고, 에이전트를 해당 데이터셋 위에서 실행하면 하나의 "실험(Experiment)"이 생긴다. 실험은 데이터셋의 각 예시에 대한 실행 결과와 평가 점수의 모음이다.
이게 편리한 이유는 프로덕션에서 디버깅하다가 발견한 문제 트레이스를 바로 데이터셋에 저장할 수 있다는 점이다. "이 케이스 실패했네" → 클릭 몇 번으로 골든 데이터셋에 추가 → 다음 실험에서 자동으로 테스트. 이 워크플로가 자연스럽게 연결된다.
평가자(Evaluator) 설정
평가자는 크게 세 종류다:
- 코드 기반: 정확히 일치하는지, 특정 키워드가 포함됐는지 같은 결정론적 검증
- LLM-as-a-Judge: 의미적 정확성, 환각 여부, 간결성 등을 LLM이 판정
- 커스텀 로직: 비즈니스 규칙에 맞는 자체 평가 함수
2025년에 추가된 기능 중에 UI에서 코드 없이 평가자를 정의할 수 있게 된 게 있다. 미리 만들어진 Hallucination, Correctness, Conciseness 같은 평가자를 데이터셋에 붙이기만 하면 된다. Few-shot 예시를 넣어서 평가자의 판단 정확도를 높이는 것도 가능하다.
에이전트 트레이싱의 진짜 가치
에이전트 평가에서 LangSmith의 트레이싱이 특히 유용한 건, 에이전트가 여러 스텝을 거치기 때문이다. 도구를 호출하고, 결과를 해석하고, 다음 행동을 결정하는 전체 체인을 시각적으로 볼 수 있다. 어디서 잘못된 판단을 했는지, 도구 호출이 실패했는지, 프롬프트의 어느 부분이 문제인지 정확히 짚어낼 수 있다.
최근에 나온 Multi-turn Evals 기능은 멀티턴 대화에서 에이전트가 사용자 목표를 달성했는지를 평가할 수 있게 해준다. 단일 질문-응답이 아니라 여러 턴에 걸친 대화 전체를 평가하는 건 에이전트 시대에 점점 더 중요해지고 있다.
온라인 평가 쪽도 지원한다. 프로덕션 트래픽에 대해 실시간으로 평가자를 돌릴 수 있고, 커스텀 대시보드에서 토큰 사용량, 레이턴시(P50, P99), 에러율, 피드백 점수를 모니터링할 수 있다.
실용적인 시작점
처음부터 복잡한 평가 파이프라인을 구축하려 하지 말고, 프로덕션에서 실패한 케이스 10개를 골든 데이터셋으로 만드는 것부터 시작하자. 그 10개에 대해 자동 평가를 돌리는 것만으로도 회귀 방지 효과가 크다.
앞으로 나아갈 방향 — 솔직히 불확실한 것들이 많다
솔직히 이 분야는 너무 빠르게 변하고 있어서, 6개월 뒤를 예측하는 것도 조심스럽다. 그래도 몇 가지 방향은 보인다.
에이전트가 점점 더 똑똑해진다
Gartner에 따르면 2026년 말까지 엔터프라이즈 앱의 40%가 AI 에이전트를 내장할 거라고 한다. 2025년에 5% 미만이었으니 어마어마한 성장률이다. 단순히 질문에 답하는 수준을 넘어서, 스스로 계획하고, 도구를 선택하고, 결과를 검증하고, 필요하면 재시도하는 자율적 에이전트가 표준이 되어가고 있다.
이게 평가에 어떤 의미인가 하면, 단일 입력-출력 쌍으로는 에이전트의 품질을 제대로 측정할 수 없게 된다는 거다. 에이전트가 목표에 도달하기까지의 "경로"가 중요하고, 중간 판단의 질도 평가해야 한다. 평가 방법론 자체가 진화해야 하는 상황이다.
멀티에이전트의 시대
2026년은 멀티에이전트 시스템이 실험실에서 나와 프로덕션에 투입되는 해가 될 거라는 전망이 많다. Gartner는 멀티에이전트 시스템 관련 문의가 2024년 Q1 대비 2025년 Q2에 1,445% 급증했다고 발표했다. 하나의 만능 에이전트보다, 검색 전문 에이전트, 분석 전문 에이전트, 코딩 전문 에이전트가 협업하는 구조가 마이크로서비스 아키텍처와 비슷하게 자리 잡고 있다.
이건 평가를 더 어렵게 만든다. 개별 에이전트의 성능뿐 아니라 에이전트 간 협업이 제대로 되는지, 오케스트레이션이 적절한지까지 봐야 한다. 아직 이 부분에 대한 확립된 평가 방법론은 솔직히 부족하다. 내가 아는 한, 대부분의 팀이 end-to-end 테스트와 컴포넌트별 테스트를 조합해서 쓰고 있는데, 더 나은 방법이 필요하다.
비즈니스 적용의 현실
80%의 조직이 AI 에이전트에서 측정 가능한 경제적 효과를 보고하고 있다는 통계도 있지만, 동시에 보안 취약점(56%), 높은 비용(37%), 시스템 통합 어려움(35%)이 주요 장애물로 꼽힌다. 기술적으로 되는 것과 비즈니스에서 쓸 수 있는 것 사이에는 여전히 간극이 있다.
특히 거버넌스 문제가 커지고 있다. AI 에이전트가 자율적으로 결정을 내리는데, 그 결정에 대한 책임은 누가 지는가? 2028년에는 조직의 38%가 AI 에이전트를 인간 팀원과 동등하게 팀에 배치할 거라는 예측도 있는데, 그때가 되면 평가는 단순한 기술적 메트릭을 넘어 비즈니스 KPI와 직결되어야 할 것이다.
내가 아직 고민하고 있는 것들
평가를 하면 할수록 드는 생각인데, "좋은 응답"의 기준 자체가 모호하다. 정확하지만 딱딱한 응답과 약간 부정확하지만 사용자 경험이 좋은 응답 중 어느 게 더 나은가? 이건 비즈니스 맥락에 따라 다르고, 골든 데이터셋만으로는 답이 안 나오는 영역이다.
그리고 평가 비용도 무시 못 한다. LLM-as-a-Judge를 매번 돌리면 그 자체로 API 비용이 꽤 나온다. 평가를 위한 평가가 되어버리는 아이러니한 상황을 어떻게 피할 것인가.
결국 "완벽한 평가 시스템"이란 없는 것 같다. 있는 건 "지금 우리 팀에 맞는 적절한 수준의 평가"뿐이다. 작게 시작하고, 실패에서 배우고, 점진적으로 강화해나가는 수밖에 없다. 이 글이 그 시작점을 잡는 데 조금이라도 도움이 되면 좋겠다.