6. 에이전트 검증용 데이터셋을 어떻게 만들지?
에이전트 서비스 품질 검증
에이전트의 품질을 검증하려면 Golden set, Golden sample이라고 부르는 답지가 필요하다. 머신러닝을 해본 사람이라면 훈련(Train), 검증(Validation), 평가(Test) 데이터셋을 떠올릴 수 있다. 에이전트 검증용 데이터셋도 비슷하다. 질의와 기대 결과가 한 세트로 묶여 있고, 그 세트로 제품이 잘 동작하는지 평가한다.
다만 에이전트 제품에서 이 데이터셋은 학습용이라기보다 평가용에 가깝다. 우리 조직에서 만든 에이전트 제품도 지금 중요한 것은 “얼마나 학습시켰는가”보다 “내가 기획한 시나리오를 실제로 만족하는가”이기 때문이다. 그래서 데이터셋을 만들 때도 모델을 훈련시키기 위한 재료가 아니라, 제품 품질을 검증하기 위한 기준으로 설계했다.
나처럼 보편적인 서비스 기획을 하다 에이전트 제품 기획을 시작한 사람들은 이 데이터셋을 어떻게 설계해야 할지 막막할 것이다. 그래서 이번 글은 에이전트를 사용한 제품을 만든 후, 이를 검증하기 위한 질의 데이터셋을 만든 노하우를 풀어볼 예정이다.
이런 글이 유용한 사람
에이전트 제품을 만들고 있는데, 품질 검증 기준을 어떻게 세워야 할지 막막한 사람
에이전트 검증 데이터셋을 실무 기준으로 이해하고 싶은 사람
기획자가 에이전트 평가셋을 어떻게 설계해야 하는지 감을 잡고 싶은 사람
데이터셋은 누가 만드는가
데이터셋은 에이전트를 기획한 사람이 설계하게 된다. 이유는 단순하다. 제품이 어떤 상황에서 어떻게 동작해야 하는지를 가장 구체적으로 알고 있는 사람이 대개 기획자이기 때문이다.
많이 듣는 질문이 있다. 이런 질의셋도 LLM에게 맡겨서 한 번에 만들면 되는 것 아니냐는 것. 일부 초안은 그렇게 만들 수 있다. 하지만 최초에 사용할 데이터셋과 기준은 결국 사람이 잡아야 한다. 어떤 사용자가 어떤 문장으로 요청할지, 그 요청에서 어떤 도구를 사용해야 하는지, 어디까지를 성공으로 볼지 같은 기준이 먼저 있어야 에이전트가 제대로 동작한다고 볼 수 있다.
실무에서는 역할의 무게중심도 조금 다른 것 같다. 개발자는 자신이 만든 에이전트 인터페이스와 도구 연결, API 호출, 기능 동작 여부를 더 집중해서 본다. 반면 기획자는 사용자의 요구를 얼마나 만족했는지, 단일 턴 질의응답은 물론이고 조건이 많아졌을 때도 답변 품질이 유지되는지를 본다. 그래서 질의 데이터셋 설계는 자연스럽게 기획자의 영역이 되는 경우가 많다.
제품 평가용 데이터셋 만들기
내가 만들었던 검증용 질의 데이터셋도 철저히 제품 품질 평가를 위한 것이었다. 예를 들어 이런 사용자 시나리오를 가정해 보자.
하반기 공개채용을 설계해줘. 영업 담당자, 마케터를 채용할 예정이고, 모집 공고는 1개월 정도 오픈할 예정이야. 그 뒤의 전형은 역량검사 -> 서류 -> 면접 1차 -> 면접 2차로 설계했으면 좋겠어. 총 리드타임은 3개월이고, 기간 초안은 너가 알아서 분배해봐. 채용명, 공고명, 전형명도 너가 함께 제안해줘.
일반적인 LLM 서비스와 달리 에이전트 서비스인 만큼, 에이전트는 질의를 잘 분해하고 적절한 API를 호출해서 정보를 수집하고 기능을 제공해야 한다. 위 질문을 예로 들면, 각 공고와 전형을 구성하는 데이터를 조회해야 하고, 이미 제품 안에 있는 설정값을 참고해야 하며, 사용자가 준 조건을 모두 반영한 채용 계획을 설계해서 화면의 데이터를 채워넣거나 데이터를 즉시 생성해야 한다. 즉, 이 질의의 평가는 "대답이 그럴듯한가"가 아니라 "요구한 조건을 만족하는 계획을 실제 제품 맥락 안에서 만들었는가"에 가깝다.
내가 만든 데이터셋은 이런 시나리오를 하나씩 쪼개서 담는 작업이었다. 어떤 요청이 들어오면 어떤 데이터를 조회해야 하는지, 어떤 도구를 써야 하는지, 최종 응답에는 어떤 값이 포함돼야 하는지까지 정의하는 식이다.
평가 질의 제작 노하우
질의 데이터셋을 만들다 보면 기능 단위로 자르고 싶은 유혹이 크다. 하지만 실제 사용자는 기능 이름으로 말하지 않는다. 자기 상황을 말한다. 그래서 데이터셋도 기능 목록보다 사용자 시나리오 단위로 설계하는 편이 훨씬 낫다.
예를 들어 사용자가 "채용 설정 시 사용할 대표 메시지 템플릿을 설정하고 싶다"라고 입력했다고 해보자. 이 요청은 한 번의 답변으로 끝나지 않을 수 있다.
첫 번째 턴에서는 메시지 템플릿 리스트를 조회하는 도구를 호출해 현재 테넌트에 어떤 템플릿이 있는지 먼저 확인해야 한다. 그런데 사용자는 템플릿 이름을 말하지 않았으니, 에이전트는 바로 설정을 진행하는 대신 어떤 템플릿을 대표로 둘지 되물어야 한다.
두 번째 턴에서 사용자가 "2026년 하반기 공채용 메시지 템플릿"이라고 답하면, 아까 조회한 리스트에 그 템플릿이 실제로 있는지 확인한다. 있다면 해당 템플릿의 Datakey와 대표 템플릿 설정 도구를 사용해 값을 저장한다. 마지막으로는 설정이 완료됐다는 안내와 함께, 사용자가 바로 확인할 수 있는 버튼이나 후속 액션을 제공해야 한다.
질의와 기대 결과를 쓸 때는 이 흐름이 머릿속에 있어야 한다. 기대 결과에는 "좋은 답변" 같은 추상적인 문장이 아니라, 어떤 도구가 올바르게 사용됐는지, 어떤 값이 저장됐는지, 사용자에게 어떤 후속 안내가 나가야 하는지가 들어가야 한다.
데이터셋 관리 방법
나는 데이터셋을 관리할 때 주로 두 가지 방법을 사용한다.
1. LLM Ops 서비스의 데이터셋 기능을 쓰거나,
2. 엑셀 같은 내부 문서로 관리하는 방법이다.
나는 아직 외부 서비스보다는 엑셀로 관리하는 편이다. 초기에 구조를 잡거나 소통할 때 훨씬 편하기 때문이다. (우리 회사는 LLM Ops로 데이터독을 사용하는데, 데이터셋 기능이 에이전트가 사용된 제품에 맞춰져있다기 보단 ML 검증처럼 학습-검증-평가 구조에 조금 더 가까운 것 같다.)
나는 주로 아래 컬럼으로 구성한다.
- 에이전트 모드: 어떤 에이전트의 품질을 측정하는 질의인지 구분한다. 예를 들어 "채용 운영용 에이전트", "통계 분석용 에이전트"처럼 분리한다.
- 질의명: 사용자가 실제로 할 법한 요청 문장을 적는다. 기능명보다 사용자 언어에 가깝게 쓴다.
- 기대 결과: 답변이 의도를 충족했는지, 정확한 값이 들어갔는지 판단할 수 있도록 기준을 적는다.
- 사용 여부: 더 이상 쓰지 않는 질의셋은 제외한다. 자동 검증 시에도 이 값을 기준으로 돌린다.
이중 기대 결과와 질의가 가장 중요하다. 기대 결과를 구성할 때는 아래 두 가지를 가장 중요하게 본다.
1. 의도 충족: 사용자의 질의와 에이전트의 답변을 비교해 요청을 제대로 이해했는지 본다.
2. 정확성: 응답에 반드시 포함돼야 할 키와 밸류를 적어두고, 그 값이 실제로 맞는지 확인한다.
데이터셋 설계 흐름
내가 질의 데이터셋을 만들 때 밟았던 순서는 대체로 이렇다.
1. 평가 목적을 정한다.
먼저 이 데이터셋이 무엇을 검증하기 위한 것인지 정한다. 단순 조회 기능의 정확성을 볼 것인지, 여러 조건이 섞인 계획 수립을 볼 것인지, 멀티턴 대화에서 맥락에 맞춰 잘 동작하는 것을 볼 것인지부터 정해야 한다. 목적이 흐리면 질의도 흐려진다.
2. 사용자 시나리오를 뽑는다.
기능 목록에서 출발하지 않고, 사용자가 실제로 어떤 장면에서 이 에이전트를 쓰는지 정리한다. 채용 공고 설계, 메시지 템플릿 설정, 운영 현황 조회처럼 시나리오를 잡고, 그 안에서 필요한 질의를 뽑는다.
3. 기대 결과를 구조화한다.
여기서부터는 "무슨 답이 나와야 하나"를 쓰는 단계다. 필요한 도구 호출, 응답에 포함돼야 할 값, 저장돼야 할 상태, 후속 안내까지 적는다. 이 단계에서 질의가 지나치게 복합적이면 다시 쪼갠다.
4. 실제 서비스에서 검증하고 개선한다.
문서에 적었다고 끝나지 않는다. 실제 서비스에서 그 질의를 넣어보고, 데이터독 로그 같은 운영 로그를 확인하면서 응답값이 내가 적어둔 기준과 맞는지 본다. 이때 질의셋이 잘못 설계된 경우도 생각보다 자주 나온다. 결국 데이터셋도 한 번에 완성되지 않고, 검증하면서 계속 다듬게 된다.
이 과정이 생각보다 시간이 많이 든다. 나도 원래 하던 기획 업무와 병행하면서 데이터셋을 준비했고, 틈틈이 실제 검증을 돌렸다. 몸으로 익히는 데만 거의 30일이 걸린 것 같다. 특히 데이터셋을 구현한 뒤, 실제 서비스에서 답변이 나오는지 보고 운영 로그로 응답값을 하나씩 확인하는 과정이 오래 걸렸다.
질의는 최대한 분해하기
질의가 복잡할수록 더 현실적이라고 생각하기 쉽다. 나는 오히려 가능한 만큼 분해하는 편을 선호한다.
예를 들어 "채용 설정 > 채용 분야"를 조회하는 도구와 생성하는 도구가 있다고 해보자. 그러면 "현재 등록된 채용 분야 목록을 알려주고, 기획과 영업 항목을 추가해줘"라고 한 번에 묶기보다, "현재 등록된 채용 분야 목록을 알려줘"와 "채용 분야로 기획, 영업 항목을 추가해줘"를 별도 질의로 나눠 검증한다.
이렇게 해야 품질 측정 시 노이즈가 덜하다. 어떤 도구를 못 쓴 건지, 조회는 됐는데 생성이 실패한 건지, 아니면 모델이 멀티 액션 조합에서 흔들린 건지 더 선명하게 보인다.
단일 동작이 잘 검증되어 있다면, 이후에는 모델이 그 동작들을 조합해서 복합 질의도 처리할 가능성이 높다. 그래서 나는 질의의 의도를 분해하고, 서로 중복되지 않게 배치하는 편이다.
품질 벤치마킹
여기까지 정리하면 에이전트의 품질을 검증할 수 있는 최소한의 환경이 만들어진다. 정확히 말하면 외부 홍보용 성능 수치라기보다, 우리 팀 내부에서 공통으로 보는 벤치마크가 생기는 것이다.
벤치마크 평가를 할 수 있는 데이터셋이 생길 때 장점은 점수화를 할 수 있고, 이를 바탕으로 어디를 개선해야 하는지도 판단한다. 이 흐름을 바탕으로 "에이전트 개선 라이프사이클"을 돌린다. 어떤 질의에서 자주 실패하는지 보고, 프롬프트를 손볼지, 도구 설계를 바꿀지, 사용자 확인 턴을 추가할지 같은 판단이 쉬워진다.
지금 내가 세팅한 질의셋은 5개 에이전트 모드를 검증하기 위한 질의가 총 1000개 정도 된다. 모든 제품이 이 정도 규모로 갈 필요는 없을 것이다. 다만 우리 제품은 에이전트를 활용한 기능이 꽤 깊게 들어가 있어서, 이 정도의 평가가 필요했다. 세팅하는데 시간이 많이 들긴 했지만, 제품과 에이전트를 사용한 제품을 훨씬 더 깊게 이해하게 된 것도 사실이다.
다음 글에서는 이렇게 질의와 기대 결과를 마련한 뒤, 검증 자동화를 어떻게 붙였는지 정리할 계획이다.
ⓒ 327roy All rights reserved.