🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

monday Service는 LangSmith와 Vitest를 결합해 오프라인·온라인 평가를 개발 초기부터 코드와 CI/CD 안에 넣고, 서비스 에이전트 품질을 빠르게 검증·모니터링하는 전략을 구축했다.

📌 핵심 요약

• monday Service는 고객-facing AI 서비스 에이전트를 만들면서 평가를 출시 직전 검사가 아니라 Day 0 요구사항으로 삼았고, 알파 사용자보다 먼저 품질 문제를 찾는 evals-driven development framework를 만들었다.
• LangGraph 기반 ReAct 에이전트는 IT, HR, Legal 같은 서비스 부서에서 KB article과 도구를 사용해 문의를 해결할 수 있지만, reasoning chain의 작은 편차가 전체 결과로 cascade될 수 있어 체계적인 평가가 필요했다.
• 오프라인 평가는 sanitized IT ticket 기반 golden dataset에서 runtime health, output shape, persistence, tool sanity, correctness를 확인하는 안전망으로 시작했고, 이후 grounding, conflict handling, guardrail, trajectory 평가로 확장됐다.
• LangSmith Vitest integration을 통해 CI 실행을 LangSmith experiment로 기록하고, Vitest parallelism과 ls.describe.concurrent를 조합해 20개 티켓 기준 sequential 162.35초를 18.60초로 줄이며 8.7배 빠른 feedback loop를 만들었다.
• 온라인에서는 LangSmith Multi-Turn Evaluator로 production trace의 전체 conversation trajectory를 평가했고, judge prompt와 rule은 TypeScript 코드로 repository에 두어 version control, peer review, CI/CD 배포 흐름 안에서 관리했다.

🧩 주요 포인트

1. monday Service는 고객-facing AI 서비스 에이전트를 만들면서 평가를 출시 직전 검사가 아니라 Day 0 요구사항으로 삼았고, 알파 사용자보다 먼저 품질 문제를 찾는 evals-driven development framework를 만들었다.
2. LangGraph 기반 ReAct 에이전트는 IT, HR, Legal 같은 서비스 부서에서 KB article과 도구를 사용해 문의를 해결할 수 있지만, reasoning chain의 작은 편차가 전체 결과로 cascade될 수 있어 체계적인 평가가 필요했다.
3. 오프라인 평가는 sanitized IT ticket 기반 golden dataset에서 runtime health, output shape, persistence, tool sanity, correctness를 확인하는 안전망으로 시작했고, 이후 grounding, conflict handling, guardrail, trajectory 평가로 확장됐다.
4. LangSmith Vitest integration을 통해 CI 실행을 LangSmith experiment로 기록하고, Vitest parallelism과 ls.describe.concurrent를 조합해 20개 티켓 기준 sequential 162.35초를 18.60초로 줄이며 8.7배 빠른 feedback loop를 만들었다.
5. 온라인에서는 LangSmith Multi-Turn Evaluator로 production trace의 전체 conversation trajectory를 평가했고, judge prompt와 rule은 TypeScript 코드로 repository에 두어 version control, peer review, CI/CD 배포 흐름 안에서 관리했다.

🧠 상세 정리

1. 평가를 Day 0 요구사항으로 둔 배경

본문은 monday Service가 고객-facing AI 서비스 에이전트를 만들면서 평가를 출시 직전 점검이 아니라 Day 0 요구사항으로 둔 과정을 설명한다. monday Service는 여러 서비스 부서의 문의를 자동화하고 해결하기 위한 AI Native Enterprise Service Management 플랫폼이며, 새 AI service workforce는 인간 상담원의 티켓 부담을 줄이는 맞춤형 역할 기반 에이전트로 소개된다. 팀은 알파 사용자가 문제를 발견할 때까지 기다리지 않고, 개발 사이클 안에 평가를 먼저 심어 품질 결함을 조기에 잡으려 했다. 그 결과로 피드백 루프 단축, 수백 개 예제에 대한 빠른 커버리지, 운영 trace 기반 관찰성, 버전 관리되는 평가 로직이라는 네 가지 성과를 제시한다.

2. ReAct 기반 서비스 에이전트의 품질 리스크

AI service workforce는 LangGraph 기반 ReAct 에이전트로, IT·HR·Legal 같은 enterprise service management use case에서 고객의 KB article과 도구를 활용해 문의를 처리하도록 설계됐다. 이 구조의 장점은 서비스 부서별 실행 흐름을 자동화할 수 있는 자율성이지만, 같은 자율성이 평가 난도를 높인다. ReAct 방식에서는 reasoning chain의 각 단계가 이전 단계에 의존하므로, 프롬프트의 작은 변화나 도구 호출 결과의 작은 편차가 이후 판단 전체로 전파될 수 있다. 원문은 이런 작은 deviation이 크게 다른, 때로는 잘못된 결과로 이어질 수 있다고 보고, 그래서 개발 초기부터 체계적인 평가가 필요하다고 설명한다.

3. 두 축의 평가 전략: 오프라인 안전망과 온라인 모니터

팀은 agent evaluation best practice를 조사하며 단일 평가층만으로는 충분하지 않다고 결론냈고, 오프라인 평가와 온라인 평가라는 두 축을 세웠다. 오프라인 평가는 curated golden dataset에 대해 에이전트를 실행하는 안전망으로, groundedness, retrieval accuracy, tool-calling 같은 core logic과 KB article conflict나 priority resolution 같은 edge case를 함께 본다. 목표는 단순한 prompt tweak이 다른 과제 처리 능력을 뜻하지 않게 망가뜨리는 일을 막는 것이다. 온라인 평가는 production 환경에서 end-to-end business 관점의 성능을 계속 수집·분석·개선하는 monitor이며, Automated Resolution과 Containment rate 같은 business signal을 실시간으로 추적한다.

4. 오프라인 평가의 출발점과 초기 커버리지

오프라인 평가를 실제로 시작할 때 팀이 먼저 던진 질문은 완벽한 coverage를 설계하는 것이 아니라, 무엇을 평가할지에 대한 실용적인 출발점을 고르는 것이었다. 그래서 내부 IT help desk에서 이미 해결된 실제 티켓을 sanitization한 약 30개 데이터셋을 만들고, Access & Identity, VPN과 연결 문제, Device/OS 지원처럼 흔한 요청 범주를 포함했다. 첫 suite의 검사는 의도적으로 단순했다. 에이전트가 crash나 timeout 없이 end-to-end로 성공하는지, 응답이 기대 schema와 format을 따르는지, thread와 session이 생성되어 application database에 persistence되는지, 필요한 tool이 올바른 input으로 호출되고 오류 없이 실행됐는지를 확인했다.

5. 점수 하나에서 행동별 평가로 확장

초기에는 OpenEvals의 Correctness evaluator를 사용해 에이전트 응답을 같은 resolved-ticket dataset의 reference output과 비교하는 LLM-as-judge 방식으로 baseline을 만들었다. baseline이 생긴 뒤에는 session memory, KB retrieval, grounding, conflict resolution, guardrail처럼 특정 행동을 겨냥한 더 작은 use-case-specific dataset으로 확장했다. 평가가 미묘해질수록 하나의 correctness score만으로는 부족했기 때문에, factual claim이 제공된 KB content로 trace되는지, region이나 time에 따라 정책이 다를 때 clarifying question을 하는지, 필요한 경우 refusal을 하는지 등을 나누어 보았다. KB를 너무 이르거나 너무 늦지 않은 시점에 가져오는지, safety나 policy guardrail이 final answer 전에 실행되는지도 AgentEvals의 trajectory LLM-as-judge 같은 방식으로 검사했다.

6. LangSmith Vitest로 CI 평가를 실험화한 방식

이 오프라인 계층을 구현하는 핵심 프레임워크로는 LangSmith Vitest integration이 사용됐다. Vitest의 검증 구조를 쓰면서도 LangSmith ecosystem과 연결되어, CI가 실행될 때마다 distinct experiment로 자동 기록되고 각 test suite는 dataset처럼 다뤄진다. 이 덕분에 팀은 특정 run으로 내려가 agent가 ground truth와 어디에서 diverge했는지 확인하고, 코드 변경이 production에 도달하기 전에 실제 영향을 검증할 수 있었다. 그러나 처음에는 평가가 serial로 실행되어 eval fail, fix, re-eval pass의 반복이 병목이 되었고, 느린 feedback loop가 testing depth나 development pace 중 하나를 희생하게 만든다는 교훈을 얻었다.

7. 병렬화와 동시 실행으로 줄인 피드백 시간

병목을 줄이기 위해 팀은 Vitest와 LangSmith integration을 최적화해 local worker와 remote API call에 부하를 나누는 hybrid approach를 택했다. CPU-bound 작업에는 Vitest의 pool:'forks'를 사용하고 Dataset Shard를 separate test file에 배정해 여러 worker process가 병렬로 실행되도록 했다. I/O-bound 특성이 강한 LLM evaluation에는 각 test file 내부에서 ls.describe.concurrent를 사용해 높은 latency를 겹쳐 처리했고, runner가 idle 상태로 기다리지 않게 만들었다. eval function은 한 번의 pass에서 response schema와 state persistence를 확인하는 deterministic baseline, 그리고 OpenEvals와 AgentEvals를 이용한 correctness와 groundedness semantic grading을 함께 수행했다. 20개의 sanitized IT ticket benchmark에서는 sequential 162.35초에서 parallel plus concurrent 18.60초로 줄어 8.7배 빠른 결과를 제시했다.

8. 운영 환경에서의 온라인 멀티턴 평가

온라인 평가에서는 offline evaluation이 controlled sandbox에서 regression을 잡는 데 유용하지만 synthetic 또는 sanitized example의 static snapshot이라는 한계가 있다고 본다. production의 예측 불가능성을 포착하기 위해 실제 production trace 위에서 real-time으로 평가를 돌리고, 특히 multi-turn dialogue에서는 한 번의 답변보다 entire conversation trajectory를 봐야 한다고 설명한다. LangSmith의 Multi-Turn Evaluator는 LLM-as-a-judge로 end-to-end thread를 채점하며, custom prompt를 통해 user satisfaction, tone, goal resolution 같은 high-level outcome을 평가할 수 있게 한다. 또한 custom inactivity window로 session이 complete되는 시점을 지정하고 sampling rate로 데이터량과 LLM cost의 균형을 맞출 수 있었기 때문에, online multi-turn setup을 빠르게 production에 적용할 수 있었다.

9. 평가자와 배포 흐름까지 코드로 관리

프로토타입에서 production으로 이동하면서 팀은 judge prompt와 rule도 일반 production code와 같은 기준으로 관리하려 했다. 그래서 source of truth를 repository로 옮기고, MultiSignalEvaluationPrompt와 ExtractionField 같은 structured TypeScript object로 conversation-analysis judge를 정의했다. 이 방식은 version control, peer review, automated CI/CD pipeline을 가능하게 했고, Cursor와 Claude Code 같은 AI IDE 안에서 complex prompt를 바로 다듬거나 judge 자체에 대한 offline evaluation을 작성하는 흐름도 자연스럽게 만들었다. 제공된 원문 범위에서 deployment는 yarn eval deploy라는 custom CLI command를 CI/CD에 넣고, PR merge 시 TypeScript definition을 LangSmith Prompt Registry로 push하는 Sync Prompts와 local evaluation rule을 production definition과 비교해 갱신 또는 생성하는 Reconcile Rules 단계까지 설명한다.

🧾 핵심 주장 / 시사점

• 서비스 에이전트 품질 관리는 단일 응답의 정확도만 보아서는 부족하며, 도구 호출 순서, KB 사용 타이밍, guardrail 실행 위치, multi-turn conversation outcome까지 함께 평가해야 한다.
• 평가 체계가 개발 속도를 늦추면 결국 테스트 깊이와 배포 속도 중 하나가 희생되므로, 평가 품질만큼 feedback loop의 속도와 DevEx도 핵심 설계 요소가 된다.
• judge prompt와 evaluation rule을 코드로 관리하면 평가 인프라도 review, versioning, CI/CD, offline validation의 대상이 되어 production 품질 관리 흐름에 더 자연스럽게 편입된다.

✅ 액션 아이템

• 평가를 출시 직전 점검이 아니라 Day 0 요구사항으로 명시해 알파 사용자 이전에 품질 결함을 선제적으로 찾아낸다.
• 오프라인 평가는 sanitized IT 티켓 기반 golden dataset으로 시작해 runtime health, output shape, persistence, tool sanity를 점검한 뒤 correctness로 확장한다.
• LangSmith와 Vitest를 CI에서 결합해 실험을 기록하고 ls.describe.concurrent로 20개 티켓 실행을 162.35초에서 18.60초, 8.7배 속도로 줄인다.

❓ 열린 질문

• LangGraph ReAct에서 reasoning chain의 작은 편차가 cascade되는 구간은 어디인가?
• sanitized IT 티켓 기반 golden dataset은 production Multi-Turn 실패를 얼마나 잘 포착할 수 있는가?
• TypeScript로 관리되는 judge prompt와 rule의 변경 시 어느 품질 기준과 임계값을 적용할 것인가?