MAS 평가 체계 — 5분 발표 최종 대본

스토리라인: 최적화에는 심판이 필요하다 → 우리가 구축·운영해 온 측정 체계 → 업계 표준(ADK)을 구현 코드까지 확인해 대조 → 하이브리드 채택 결정 → 앞 발표들의 최적화 루프가 이 위에서 돈다.

타임라인 한눈에

대본

시간	화면	내용
0:00–0:30	타이틀	훅 — "더 좋다"를 판정하는 심판
0:30–1:45	eval_ph1 요약 1장	우리가 구축·운영한 것 (6차원 · pass^k · 대시보드)
1:45–3:30	plain.html 요약표	ADK 11종 — 두 갈래, 가져올 노하우 3, 제약
3:30–4:30	요약표 유지	하이브리드 결정 — "설계·데이터 유지, 엔진만 교체"
4:30–5:00	—	클로징 — 최적화 루프가 이 위에서 돈다

0:00–0:30 화면: 타이틀

앞서 보신 발표들이 GEPA와 ProTeGi로 프롬프트를 "더 좋게" 만드는 방법이었다면, 제 파트는 그 "더 좋다"를 판정하는 심판 얘기입니다. 최적화 루프는 결국 평가 점수를 연료로 돕니다. 채점이 흔들리면 개선도 흔들립니다. 그래서 저는, 방금 보신 그 AutoGen 팀들을 채점해 온 평가 체계를 말씀드리겠습니다.

0:30–1:45 화면: eval_ph1 6차원 요약 1장

단일 프롬프트는 "정답과 비교" 하나로 충분하지만, 멀티에이전트는 실패 지점이 다층적입니다. 최종 답이 틀리는 경우. 답은 맞는데 도구를 엉뚱하게 쓴 경우. 에이전트끼리 역할이 꼬인 경우. 답은 맞는데 토큰을 세 배 태운 경우. 그리고 근거 없는 말을 지어내는 환각까지.

그래서 저희는 작업 성공·협업·도구·효율·안전, 여러 차원으로 나눠 채점하고, 같은 작업을 다섯 번 반복해서 "매번 성공하는가"를 보는 방식으로 — 대시보드와 실험 원장까지 — 운영해 왔습니다. 여기까지가 1단계였습니다.

1:45–3:30 화면: plain.html 요약표로 전환

다음 질문은 이것이었습니다. "우리 채점 기준이 업계 기준으로 봐도 맞는가?" 그래서 Google의 에이전트 프레임워크 ADK에 내장된 평가 메트릭 11종을 확인했습니다. 공식 문서는 각 메트릭이 무엇을 측정하는지만 알려주는데, 저희는 어떻게 점수를 내는지까지 보려고 구현 코드를 직접 열어봤습니다. 지금 보시는 표가 그 결과물입니다.

(요약표 '채점' 열 가리키며) 핵심은 두 갈래입니다. 코드로 비교하는 결정론 방식 2종 — 빠르고 비용이 없지만, 표현이 조금만 달라도 놓칩니다. 나머지 9종은 LLM이 심판을 보는 방식 — 의미를 이해하니 유연하지만, 호출 비용이 들고 결과가 매번 흔들릴 수 있습니다.

(상세 섹션으로 천천히 스크롤) 이 확인 과정에서 그대로 가져올 노하우 세 가지를 건졌습니다. 첫째, 심판 LLM을 한 번만 부르지 않고 다섯 번 불러 다수결로 판정하고, 동점이면 불합격 처리하는 보수적 설계 — 이 "다섯 번"이라는 숫자는 문서가 아니라 코드의 기본값에만 있는 사실입니다. 둘째, 환각 검증을 응답 전체 뭉텅이가 아니라 문장 단위로 쪼개서 "이 문장이 근거 자료에 있는가"를 하나씩 따지는 2단계 파이프라인. 셋째, 심판 하나가 실패해도 전체 평가가 죽지 않게 격리하는 운영 설계입니다.

(유의점 섹션) 반대로 제약도 확인했습니다. 11종 중 4종은 사실상 구글 클라우드 유료 서비스로 넘기는 래퍼라 저희 환경에서는 쓸 수 없고, 문자열 비교 메트릭 하나는 영어를 전제로 설계돼 한국어에는 부적합합니다.

3:30–4:30 화면: 요약표로 복귀

그래서 결론은 "전면 채택"도 "무시"도 아닌 하이브리드입니다. 구글이 이미 검증해 놓은 골격 — LLM 심판 인프라와 환각 검증 — 은 채택합니다. 대신 ADK에 없는 저희 고유 차원, 즉 에이전트 간 협업, 비용 효율, 한국어 도메인 채점은 커스텀 메트릭으로 그 골격 위에 얹습니다.

중요한 것은, 저희가 운영하며 검증한 차원 설계와 축적된 평가 데이터는 그대로 유지되고, 채점 엔진만 표준 골격으로 교체된다는 점입니다. ADK가 아직 실험 단계 API라는 리스크는 변환 어댑터 한 파일로 격리하는 설계를 마쳤고, 이식 작업은 나흘 내외로 계획되어 있습니다.

4:30–5:00 화면: 그대로

이게 완성되면, 앞서 보신 GEPA·ProTeGi 최적화 루프가 바로 이 측정 체계 위에서 돌게 됩니다. "프롬프트를 바꿨더니 점수가 올랐다"가 아니라, "업계 표준 수준의 심판이 여러 차원에서 반복 검증한 점수가 올랐다"고 보고드릴 수 있게 되는 것입니다. 다음 보고에서는 이식 완료 후 실제 수치로 찾아뵙겠습니다. 감사합니다.

질문	답변
비용은 얼마나 드나?	LLM 심판 호출은 정액제 플랜 내에서 소화 가능. 결정론 메트릭이 무료 1차 필터 역할을 하므로 전수 호출이 아님.
왜 구글 걸 전부 안 쓰나?	4종은 GCP 유료 종속, 1종은 한국어 부적합, 그리고 협업·효율 차원은 ADK에 아예 없음.
기존에 만든 건 버려지나?	아니요. 차원 설계·평가셋·대시보드·축적 데이터는 유지, 채점 엔진만 교체. 운영 경험이 있었기에 표준을 평가할 기준도 있었던 것.
언제 완료되나?	이식 계획 수립 완료, 작업 나흘 내외. 다음 보고 전 수치 확보 목표.
소스를 봤다는 게 무슨 의미인가?	공식 문서에는 "무엇을 측정하는지"만 있고, 심판 5회 다수결·동점 불합격·Vertex 위임 같은 "어떻게"는 구현 코드에만 있음. 그 수준까지 확인했다는 뜻.
이 11개는 어떻게 정해진 건가?	저희 선별이 아니라 구글이 ADK 공식 지원 기준으로 선언한 전수(공식 Criteria 문서·소스 enum·레지스트리 3중 일치). 저희가 한 일은 그 전수를 기존 지표에 매핑해 채택 5·배제 5·보류 1로 판정한 것. → 선정 근거·매핑 문서
채택 기준은 무엇이었나?	기존 운영 지표(pass@1·grounded%·loop_rate 등)에 1:1 매핑해 상위 호환이면 채택, GCP 종속·한국어 부적합이면 배제. 탈락분의 역할은 전부 대체 경로 존재 — 최종선정표 참조.
왜 최종 형태가 ADK 중심인가?	프레임 정정부터: 중심은 우리 6차원 설계·데이터이고 ADK는 판정기 엔진 부품. 엔진으로 ADK인 이유 — ① AutoGen 진영엔 메트릭 체계가 없음(AutoGenBench는 실행 하네스), ② 대안들은 RAG 출발인 반면 ADK만 멀티에이전트 궤적이 1급 설계, ③ 소스 실사로 종속 없음 확인(심판 자유·커스텀 등록·로컬), ④ 어댑터 격리로 가역적 결정. → §4 대안 비교

MAS 성능, 정확히 측정하기 — 5분 발표 최종 대본

타임라인 한눈에

대본

발표 팁

예상 Q&A