최신 트렌드와 활용법을 공유하세요
구조화 출력 모델을 운영하다 보면 이상한 실패가 반복됩니다. JSON이 깨지는 정도가 아니라 같은 문장을 계속 반복하거나, OCR 결과가 루프에 빠지거나, 특정 필드를 끝없이 복사하는 식입니다. temperature를 낮추고 repetition penalty를 넣어도 완전히 사라지지 않습니다. Hugging Face에 공개된 Dharma AI의 글은 이 문제를 Direct Preference Optimization, 즉 DPO로 다루는 실전 사례를 보여줍니다. 핵심은 실패 출력을 버리지 않고 rejected example로 사용했다는 점입니다. DharmaOCR 사례에서 SFT 이후 DPO를 추가하자 text degeneration이 모든 모델 패밀리에서 줄었습니다. 평균 감소율은 59.4%, 가장 큰 케이스는 87.6%였다고 설명합니다. 이 숫자보다 중요한 것은 방법론입니다. DPO는 챗봇의 선호도 정렬에만 쓰는 도구가 아니라, OCR이나 structured generation처럼 정답 기준이 명확한 작업의 실패 모드를 직접 겨냥할 수 있습니다. ## 왜 SFT만으로는 반복 루프가 남을까 Supervised Fine-Tuning은 정답 출력을 더 잘 따라 하게 만듭니다. 문서 OCR이라면 올바른 전사 결과, JSON 추출이라면 맞는 필드 구조를 학습합니다. 문제는 SFT의 목표가 토큰 단위 likelihood를 높이는 데 있다는 점입니다. 모델이 반복 루프에 빠졌을 때 그 전체 completion이 실패라는 신호를 직접 받지 못합니다. 반복 루프는 단순한 decoding 설정 문제가 아닐 수 있습니다. 특정 토큰이나 패턴이 자기 자신을 강화하는 분포 영역에 들어가면, 다음 토큰 예측이 계속 같은 방향으로 쏠립니다. temperature, top-p, repetition penalty는 증상을 줄일 수 있지만, 모델이 그 실패 출력을 나쁜 completion으로 학습한 것은 아닙니다. DPO는 여기서 다른 신호를 줍니다. 같은 입력에 대해 chosen output과 rejected output을 만들고, 모델이 chosen을 선호하도록 학습합니다. 구조화 작업에서는 사람 취향이 아니라 명확한 품질 기준이 있습니다. 올바른 OCR은 chosen, 반복 루프는 rejected입니다. ## 실패 출력을 버리지 않는다는 발상 많은 데이터 정제 파이프라인은 모델이 만든 이상한 출력을 제거합니다. 깨끗한 데이터셋을 만들기 위해서입니다. 하지만 반복 루프를 줄이는 목적이라면 이 출력은 노이즈가 아니라 가장 중요한 학습 신호입니다. DharmaOCR 접근은 SFT 모델이 실제로 만들어낸 degenerate output을 rejected example로 보존했습니다. 이 방식의 장점은 실패가 모델 자신의 분포에서 나온다는 점입니다. 사람이 상상한 나쁜 예시보다 실제 모델이 빠지는 함정이 더 정확한 negative signal입니다. 운영 중인 모델이 특정 영수증 양식에서 금액 필드를 반복한다면, 그 실패 출력을 모아 rejected set으로 쓰는 편이 일반적인 오류 예시를 만드는 것보다 낫습니다. ## 어떤 작업에 적용할 수 있나 첫 번째 후보는 OCR과 문서 추출입니다. 계약서, 세금계산서, 영수증, 의료 문서처럼 출력 구조가 명확하고 정답 비교가 가능한 영역입니다. 반복 루프, 필드 누락, 잘못된 복사, 포맷 붕괴를 rejected output으로 만들 수 있습니다. 두 번째는 코드 생성의 특정 하위 작업입니다. 예를 들어 TypeScript type 생성, SQL migration 생성, OpenAPI schema 변환처럼 정답 구조가 비교적 명확한 작업입니다. 모델이 같은 필드를 반복하거나, import를 무한히 추가하거나, JSON schema nesting을 망치는 경우를 negative pair로 만들 수 있습니다. 세 번째는 RAG 답변의 근거 일치 검증입니다. 정답 문서에 없는 내용을 섞은 답변, 같은 문장을 반복한 답변, 출처 ID를 잘못 붙인 답변을 rejected output으로 구성할 수 있습니다. 단, 이 경우 chosen과 rejected의 품질 차이를 자동으로 안정적으로 판정할 수 있어야 합니다. ## DPO 데이터셋을 만드는 절차 절차는 단순하게 시작할 수 있습니다. 먼저 SFT 또는 현재 운영 모델로 같은 입력에 대해 여러 후보 출력을 생성합니다. 다음으로 자동 judge나 규칙 기반 검사로 출력 품질을 분류합니다. 반복 루프는 n-gram repetition, 특정 토큰 비율, 최대 길이 도달 여부, schema validation 실패로 잡을 수 있습니다. 그다음 같은 입력에 대해 좋은 출력과 나쁜 출력을 묶어 preference pair를 만듭니다. 여기서 주의할 점은 rejected output을 너무 다양하게 섞지 않는 것입니다. 반복 루프를 줄이려는 DPO라면 반복 루프 중심으로 negative set을 구성해야 합니다. 필드 누락, 오탈자, hallucination까지 한 번에 다 잡으려 하면 학습 신호가 흐려질 수 있습니다. 실패 모드별로 데이터셋을 나누고, 가장 비용이 큰 실패부터 줄이는 편이 낫습니다. ## 운영 파이프라인에서의 안전장치 DPO는 모델을 개선하는 방법이지 런타임 검증을 대체하지 않습니다. 구조화 출력 서비스에는 여전히 schema validation, retry, fallback, human review가 필요합니다. 특히 문서 추출 결과가 결제, 보험, 세무, 의료 판단에 연결된다면 모델 출력만 믿으면 안 됩니다. 추천 구조는 세 단계입니다. 첫째, 런타임에서 반복 루프와 schema 오류를 탐지합니다. 둘째, 실패 샘플을 로그로 모아 재현 가능한 데이터셋을 만듭니다. 셋째, 일정량이 쌓이면 DPO 또는 다른 preference optimization으로 실패 모드를 학습시킵니다. 이렇게 하면 운영 로그가 단순 장애 기록이 아니라 모델 개선 재료가 됩니다. ## 실행 체크리스트 DPO의 실전 가치는 “좋은 답변을 더 좋게”보다 “반복되는 나쁜 실패를 명시적으로 피하게” 만드는 데 있습니다. 구조화 출력, OCR, 코드 변환, RAG 검증처럼 품질 기준이 명확한 작업이라면 실패 출력을 버리지 말고 학습 신호로 바꿔볼 만합니다. - 운영 로그에서 반복 루프, 포맷 붕괴, schema validation 실패를 분리해 수집합니다. - 같은 입력에 대해 chosen output과 rejected output을 묶을 수 있는 기준을 정의합니다. - rejected set은 하나의 실패 모드 중심으로 좁게 구성합니다. - 자동 judge를 쓰더라도 일부 샘플은 사람이 검수해 라벨 품질을 확인합니다. - DPO 전후로 degeneration rate, schema success rate, exact match, downstream task success를 따로 측정합니다. - 런타임에서는 schema validation과 fallback을 계속 유지합니다. - 실패 출력은 삭제 대상이 아니라 다음 학습 라운드의 가장 구체적인 negative signal로 다룹니다.
AI 시스템을 만들 때 모든 요청을 가장 큰 모델로 보내는 방식은 단순합니다. 하지만 운영비와 지연 시간이 빠르게 커집니다. 특히 IDE 기능, RAG 후처리, 요청 라우팅, 도구 선택, 요약, 검증처럼 자주 호출되는 단계는 큰 모델이 항상 정답이 아닙니다. JetBrains가 공개한 Mellum2는 이 지점을 겨냥한 모델입니다. 12B Mixture-of-Experts 구조이지만 토큰당 활성 파라미터는 2.5B이고, 텍스트와 코드 워크로드에 맞춰 공개됐습니다. Mellum2 발표에서 중요한 문장은 “frontier model 대체”가 아니라 “larger AI system 안의 focal model”이라는 설명입니다. Apache 2.0 라이선스, 코드와 자연어 작업, 라우팅·RAG·서브에이전트·프라이빗 배포에 적합하다는 포지션이 명확합니다. 실무 개발자에게는 모델 성능표보다 “어떤 단계에 작은 모델을 넣어 비용을 줄일 수 있나”가 더 중요합니다. ## 작은 모델이 필요한 위치부터 찾기 운영 중인 AI 서비스 로그를 보면 모든 요청이 같은 난이도가 아닙니다. 사용자의 질문 의도 분류, 검색 쿼리 재작성, 문서 조각 압축, 코드 파일 요약, 도구 선택, 최종 답변 검수 같은 중간 단계가 많습니다. 이 단계들은 대형 추론 모델을 호출하면 품질은 괜찮지만 비용과 지연 시간이 과합니다. 작은 코드 모델은 이런 high-frequency, low-to-medium complexity 작업에 맞습니다. 예를 들어 “이 요청은 결제 문의인가, 기술 문의인가”, “이 코드 변경은 테스트 파일을 함께 봐야 하는가”, “이 검색 결과 20개 중 답변에 넣을 5개는 무엇인가” 같은 작업입니다. 정답이 비교적 구조화되어 있고, 긴 추론보다 빠른 분류와 변환이 필요한 곳이 후보입니다. ## Mellum2의 MoE 구조가 주는 운영상 의미 Mellum2는 총 12B 파라미터지만 토큰당 2.5B만 활성화하는 Mixture-of-Experts 모델입니다. 이 구조는 같은 총 용량 대비 inference 효율을 높이는 데 유리합니다. 발표에서는 비슷한 크기의 모델 대비 경쟁력 있는 벤치마크와 2배 이상 빠른 inference를 강조합니다. 실무에서는 “벤치마크가 좋다”보다 “동시 요청을 얼마나 버티는가”가 더 중요합니다. RAG 파이프라인에서 문서 10개를 각각 요약하거나, 에이전트가 매 단계 tool selection을 할 때 모델 호출 수는 쉽게 늘어납니다. 이때 토큰당 활성 파라미터가 작은 모델은 처리량과 비용 측면에서 유리할 수 있습니다. ## 라우팅 모델로 쓰는 방법 가장 쉬운 적용은 라우팅입니다. 사용자 요청을 몇 개의 경로로 나누고, 각 경로마다 다른 모델이나 도구를 호출합니다. 예를 들어 개발자 지원 챗봇이라면 요청을 `bug_analysis`, `code_generation`, `docs_search`, `billing`, `unsafe_or_unknown`으로 분류할 수 있습니다. 여기서 중요한 것은 라우팅 모델에게 긴 답변을 쓰게 하지 않는 것입니다. 출력은 JSON 하나로 제한합니다. `route`, `confidence`, `required_tools`, `reason` 정도면 충분합니다. confidence가 낮으면 큰 모델로 보내거나 사람에게 넘깁니다. 이렇게 하면 작은 모델이 잘하는 빠른 분류만 맡고, 어려운 판단은 더 강한 모델이 처리합니다. ## RAG 파이프라인에 넣는 방법 RAG에서 작은 모델을 넣을 수 있는 위치는 많습니다. 첫째, 사용자 질문을 검색 쿼리로 바꾸는 query rewriting입니다. 둘째, 검색 결과를 압축하는 context compression입니다. 셋째, 답변에 쓸 근거와 버릴 근거를 고르는 reranking 보조 단계입니다. 넷째, 최종 답변이 근거 문서와 어긋나는지 확인하는 lightweight verifier입니다. 큰 모델 하나가 검색부터 답변까지 모두 처리하면 구현은 쉽습니다. 하지만 문서가 많아질수록 context 비용이 늘고, latency가 길어집니다. 작은 모델로 검색 전후를 정리하면 큰 모델에는 더 적은 문맥과 더 명확한 질문을 보낼 수 있습니다. 특히 내부 코드베이스 RAG에서는 파일 요약, 심볼 설명, 변경 영향 범위 추정에 작은 코드 모델이 유용합니다. ## 서브에이전트에 넣을 때의 기준 에이전트 시스템에서는 하나의 모델이 모든 일을 하는 구조보다 역할을 나누는 구조가 안정적입니다. Mellum2 같은 모델은 planner, validator, transformer, context preparer 같은 서브에이전트 후보입니다. 예를 들어 메인 에이전트가 “결제 API 오류를 분석하라”는 작업을 받으면, 작은 모델이 관련 로그를 요약하고, 변경 파일을 분류하고, 테스트 후보를 추천할 수 있습니다. 다만 작은 모델에게 장기 계획 전체를 맡기면 위험합니다. 작은 모델은 빠른 반복 작업과 명확한 스키마 출력에 적합합니다. 요구사항이 모호하거나 여러 이해관계가 엮인 판단은 큰 모델이나 사람 검토로 넘겨야 합니다. 모델 크기 선택은 비용 문제가 아니라 실패 비용 문제입니다. ## 배포 전 평가 방법 작은 모델 도입은 A/B로 봐야 합니다. “큰 모델 대비 얼마나 싸다”만 보면 안 됩니다. 라우팅 오분류율, 검색 누락률, 압축 후 답변 정확도, verifier false positive를 측정해야 합니다. 특히 라우팅 모델이 낮은 confidence를 제대로 표시하는지가 중요합니다. 모르는 것을 모른다고 못 하면 전체 시스템 품질을 떨어뜨립니다. 운영 로그에서 200~500개 샘플을 뽑아 사람 기준 라벨을 만들고, 작은 모델과 기존 큰 모델의 결과를 비교합니다. 정확도가 조금 낮아도 비용 절감이 크고, 낮은 confidence를 안전하게 fallback할 수 있으면 도입 가치가 있습니다. 반대로 오분류가 사용자 데이터 변경이나 결제 처리로 이어지는 영역에는 쓰면 안 됩니다. ## 실행 체크리스트 Mellum2 같은 작은 코드 모델의 핵심은 대형 모델을 이기는 것이 아니라 대형 모델을 덜 부르게 만드는 것입니다. AI 시스템이 커질수록 라우터, 요약기, 검증기, 서브에이전트가 늘어납니다. 이 고빈도 단계에 맞는 모델을 고르는 것이 비용과 속도를 좌우합니다. - 운영 로그에서 반복 호출이 많은 중간 단계를 찾습니다. - 라우팅, query rewriting, context compression, validation부터 작은 모델 후보로 분리합니다. - 출력은 자유문이 아니라 JSON schema로 제한합니다. - confidence가 낮으면 큰 모델 또는 사람 검토로 fallback합니다. - 200개 이상 실제 샘플로 오분류율과 지연 시간을 측정합니다. - write action이나 결제 같은 고위험 판단에는 작은 모델 단독 결정을 쓰지 않습니다. - 비용 절감률만 보지 말고 실패 비용과 재시도 비용을 함께 계산합니다.
웹앱을 AI 에이전트가 조작하게 만들 때 가장 흔한 접근은 화면을 보고 클릭하게 하는 방식입니다. 데모는 빨리 나옵니다. 하지만 실무에서는 버튼 위치가 바뀌거나, 문구가 바뀌거나, 모달이 하나 끼면 실패합니다. Google I/O 2026 Developer Keynote에서 소개된 WebMCP는 이 문제를 다른 방향에서 풀려는 제안입니다. 브라우저 기반 AI 에이전트가 JavaScript 함수, HTML form 같은 구조화된 도구를 사용할 수 있도록 웹 표준 형태로 노출하자는 접근입니다. 핵심 검색 의도는 분명합니다. “AI agent가 웹사이트를 안정적으로 조작하려면 무엇을 준비해야 하나?”입니다. 답은 단순히 모델을 키우는 것이 아닙니다. 웹앱 쪽에서 에이전트가 사용할 수 있는 안전한 tool surface를 설계해야 합니다. WebMCP는 아직 제안 단계이고 Chrome 149 origin trial로 실험이 예고된 영역이지만, 지금부터 설계 원칙을 바꿔야 할 이유는 충분합니다. ## 화면 자동화와 구조화 도구의 차이 화면 자동화는 사람이 보는 인터페이스를 모델이 해석해서 행동합니다. “저 파란 버튼을 눌러”, “이 입력칸에 이메일을 넣어” 같은 방식입니다. 장점은 기존 웹앱을 거의 수정하지 않아도 된다는 점입니다. 단점은 불안정성입니다. UI가 바뀌면 에이전트가 같은 의도를 다른 요소에 연결할 수 있습니다. 구조화 도구 방식은 웹앱이 에이전트에게 명시적 기능을 제공합니다. 예를 들어 `searchOrders`, `createTicket`, `applyCoupon`, `submitReturnRequest` 같은 작업 단위를 노출합니다. 에이전트는 화면 픽셀을 추측하지 않고 정의된 입력 스키마와 권한 범위 안에서 작업합니다. 이 방식은 API와 비슷하지만, 브라우저 문맥에서 사용자 세션, 페이지 상태, 폼, 권한과 연결될 수 있다는 점이 다릅니다. ## WebMCP가 필요한 실제 상황 첫 번째는 복잡한 폼입니다. 보험 청구, 환불 신청, B2B 견적 요청, 관리자 설정처럼 입력칸이 많고 조건부 필드가 있는 화면은 visual agent만으로 안정화하기 어렵습니다. 모델은 보이는 필드명을 잘 읽어도 숨겨진 validation rule이나 required condition을 모를 수 있습니다. 두 번째는 장바구니나 결제 직전 플로우입니다. 사용자가 “이 쿠폰 적용해줘”라고 했을 때 에이전트가 화면을 클릭해 처리할 수는 있지만, 잘못된 쿠폰을 적용하거나 결제 버튼을 눌러버리면 사고가 됩니다. 구조화 도구는 `applyCoupon`은 허용하되 `placeOrder`는 사용자 승인이 필요하게 나눌 수 있습니다. 세 번째는 SaaS 관리자 화면입니다. 계정 권한 변경, 팀원 초대, API key 재발급, 과금 플랜 변경은 에이전트 자동화 수요가 큽니다. 동시에 위험도도 큽니다. 이런 영역은 화면 클릭이 아니라 명시적 tool contract와 감사 로그가 필요합니다. ## 웹앱 개발자가 지금 설계해야 할 것 먼저 액션을 읽기, 제안, 쓰기로 나눠야 합니다. 읽기 액션은 비교적 자유롭게 허용할 수 있습니다. 예를 들어 주문 상태 조회, 문서 검색, 설정값 확인입니다. 제안 액션은 변경 전 미리보기입니다. “이 설정을 바꾸면 이렇게 된다”를 계산해 보여줍니다. 쓰기 액션은 실제 상태 변경입니다. 여기에는 승인, 롤백, 로그가 붙어야 합니다. 다음은 입력 스키마입니다. 에이전트에게 자유 텍스트만 받으면 검증이 어렵습니다. 가능한 enum, date format, amount range, user id, resource id를 명확히 해야 합니다. 예를 들어 환불 처리 tool은 `orderId`, `refundItems`, `reasonCode`, `notifyCustomer`를 분리해야 합니다. “환불해줘”라는 문장을 그대로 받으면 위험합니다. 세 번째는 권한 모델입니다. 사용자에게 권한이 있어도 에이전트에게 모든 권한을 주면 안 됩니다. 에이전트 사용 시 권한을 한 단계 더 좁히는 방식이 필요합니다. 읽기는 허용, 쓰기는 승인, 외부 발송은 금지처럼 정책을 나눕니다. ## SEO와 제품 문서 관점의 기회 WebMCP 같은 흐름은 기술 문서와 제품 SEO에도 영향을 줍니다. 앞으로 사용자는 “이 서비스는 AI agent friendly 한가?”를 볼 가능성이 큽니다. API 문서만 있는 서비스보다 agent action 문서, tool schema, 안전한 자동화 가이드가 있는 서비스가 선택될 수 있습니다. 개발자 대상 SaaS라면 문서에 “AI agent integration”, “browser agent support”, “MCP tool surface”, “automation-safe actions” 같은 검색 의도를 반영할 수 있습니다. 단, 키워드를 억지로 반복하면 안 됩니다. 실제로 어떤 작업을 에이전트에게 맡길 수 있고, 어떤 작업은 승인 단계가 필요한지 예시 중심으로 써야 합니다. ## 구현 전에 정해야 할 안전 기준 WebMCP 자체를 기다리지 않아도 지금 적용할 수 있는 기준이 있습니다. 웹앱 내부 액션을 사람이 보는 UI와 에이전트가 쓰는 tool contract로 분리하는 것입니다. 그리고 각 tool에 위험 등급을 붙입니다. 예를 들어 `readInvoice`는 low risk, `draftRefund`는 medium risk, `executeRefund`는 high risk입니다. low risk는 자동 실행, medium risk는 미리보기 후 승인, high risk는 2단계 확인과 감사 로그를 요구합니다. 이렇게 해두면 WebMCP가 본격화됐을 때도 구조를 옮기기 쉽습니다. ## 실행 체크리스트 WebMCP 도입의 본질은 “에이전트가 웹앱을 더 똑똑하게 보게 하자”가 아닙니다. 웹앱이 에이전트에게 안전하고 검증 가능한 작업 단위를 제공하자는 것입니다. 실무 개발자는 지금부터 화면 자동화 중심 사고를 줄이고 tool contract 중심 설계로 이동해야 합니다. - 웹앱의 주요 사용자 작업을 읽기, 제안, 쓰기 액션으로 분류합니다. - 각 액션에 입력 스키마, 권한, 실패 응답, 감사 로그 필요 여부를 정의합니다. - 결제, 삭제, 권한 변경, 외부 발송은 자동 실행하지 않고 승인 단계로 둡니다. - 에이전트용 tool 이름은 UI 문구가 아니라 업무 의미 기준으로 정합니다. - 화면 클릭 테스트와 별도로 tool contract 테스트를 만듭니다. - 제품 문서에는 에이전트가 할 수 있는 작업과 금지된 작업을 예시로 씁니다. - WebMCP origin trial이 열리면 기존 액션 설계를 표준 인터페이스에 매핑합니다.
Computer Use Agent는 화면을 보고 클릭하고 입력하는 에이전트입니다. 브라우저 자동화만 생각하면 Playwright나 Selenium과 비슷해 보이지만, 실제 방향은 더 넓습니다. 웹, 데스크톱 앱, 모바일 화면, 사내 도구까지 사람이 눈으로 보고 조작하던 GUI를 모델이 처리하는 쪽으로 가고 있습니다. H Company가 공개한 Holo3.1은 이 흐름에서 중요한 포인트를 보여줍니다. 성능 경쟁만이 아니라 로컬 실행, 모바일 지원, 다양한 agent harness 호환성이 전면에 나왔습니다. Holo3.1은 0.8B, 4B, 9B, 35B-A3B 네 가지 크기로 공개됐고, 35B-A3B에는 FP8, Q4 GGUF, NVFP4 같은 양자화 체크포인트가 제공됩니다. 발표 내용에서 가장 실무적인 숫자는 AndroidWorld 성능 개선입니다. 35B-A3B 모델은 67%에서 79.3%로, 4B와 9B 변형은 58%에서 72%로 개선됐다고 설명합니다. 또 DGX Spark 기준 NVFP4 W4A16은 FP8 대비 1.41배, BF16 대비 1.74배 토큰 처리량을 보였고, agent harness 최적화와 결합했을 때 평균 step time이 6.8초에서 3.3초로 줄었다고 합니다. ## 왜 로컬 Computer Use Agent가 중요해졌나 GUI 자동화는 개인정보와 사내 데이터에 바로 닿습니다. 브라우저에 로그인된 관리자 콘솔, CRM, 회계 시스템, 고객 지원 도구를 에이전트가 조작한다면 화면 스크린샷과 입력값이 외부 API로 나가는 구조는 부담이 큽니다. 클라우드 모델을 쓰더라도 마스킹, 프록시, 감사 로그, 권한 분리가 필요합니다. 로컬 실행은 이 문제를 줄이는 선택지입니다. 모델과 agent harness가 같은 네트워크 또는 같은 장비에서 돌면 화면 데이터가 외부로 나가지 않습니다. 물론 로컬이라고 자동으로 안전해지는 것은 아닙니다. 권한 분리와 로그, 사용자 승인 단계는 여전히 필요합니다. 하지만 개인정보가 많은 업무에서는 “성능이 조금 낮아도 내부에서만 실행”이 더 합리적인 요구가 됩니다. ## Holo3.1 발표에서 볼 세 가지 기술 변화 첫째, 환경 범위가 넓어졌습니다. 기존 computer-use 모델은 웹 벤치마크에서 강해도 모바일이나 데스크톱 앱에서는 흔들리는 경우가 많았습니다. Holo3.1은 웹, 데스크톱, 모바일 환경을 명시적으로 다룹니다. 이는 배포팀 입장에서 중요합니다. 실제 업무 자동화는 브라우저 하나로 끝나지 않습니다. Slack, ERP, 내부 Electron 앱, 모바일 관리자 앱이 섞이는 경우가 많습니다. 둘째, agent harness 호환성을 봅니다. 모델이 JSON을 잘 내는 것만으로는 충분하지 않습니다. 어떤 프레임워크에서는 function calling이 표준이고, 어떤 프레임워크는 별도 action schema를 씁니다. Holo3.1은 function-calling protocol 지원을 추가했고, OSWorld와 내부 벤치마크에서 native execution과 function calling이 near-parity에 가까워졌다고 설명합니다. 실무에서는 이게 도입 비용을 줄입니다. 셋째, 작은 모델과 양자화가 제품 요구사항이 됐습니다. 0.8B, 4B, 9B 모델은 최고 성능용이 아니라 비용과 지연 시간을 맞추기 위한 선택지입니다. 자주 호출되는 화면 인식, 단순 클릭 판단, 폼 입력 같은 단계는 거대한 모델보다 작은 모델이 더 맞을 수 있습니다. ## 어디에 바로 적용할 수 있을까 가장 먼저 떠오르는 영역은 반복적인 백오피스 작업입니다. 예를 들어 고객 정보 조회, 티켓 분류, CRM 필드 업데이트, 정산 화면 대조, 관리자 콘솔 설정 변경입니다. API가 잘 정리된 조직이라면 API 자동화가 먼저입니다. 하지만 현실에서는 API가 없거나, 권한이 제한되거나, 오래된 웹 관리자 화면만 있는 경우가 많습니다. 이때 GUI agent가 임시 다리 역할을 할 수 있습니다. 두 번째는 QA 자동화입니다. 기존 E2E 테스트는 selector가 조금만 바뀌어도 깨집니다. Computer Use Agent는 화면 의미를 보고 작업하므로 selector 의존도를 낮출 수 있습니다. 다만 테스트 자동화에 쓰려면 결과 판정은 별도 deterministic check로 해야 합니다. 에이전트가 “성공한 것 같다”고 말하는 것을 테스트 통과로 보면 안 됩니다. 세 번째는 개인 로컬 워크플로우입니다. 개발자 PC에서 브라우저, 터미널, 문서, 이슈 트래커를 오가며 반복 작업을 처리하는 agent가 여기에 해당합니다. 이 경우 로컬 실행은 지연 시간과 프라이버시 측면에서 장점이 큽니다. ## 위험한 도입 방식 가장 위험한 방식은 관리자 권한이 있는 브라우저를 에이전트에게 그대로 맡기는 것입니다. 화면 조작 agent는 실수했을 때 write action을 수행합니다. 잘못된 버튼 클릭, 잘못된 고객 선택, 잘못된 저장은 단순 답변 오류보다 복구 비용이 큽니다. 또 하나는 관측 없이 자동화를 돌리는 방식입니다. Computer Use Agent는 반드시 action log, screenshot diff, tool call trace, 사용자 승인 지점을 남겨야 합니다. Holo3.1 같은 모델 성능이 좋아져도 제품 설계에서는 “어디서 멈출 것인가”가 더 중요합니다. 결제, 삭제, 권한 변경, 고객 통지처럼 되돌리기 어려운 액션은 자동 실행이 아니라 승인 대기 단계로 남기는 편이 안전합니다. ## 개발팀용 도입 체크리스트 Holo3.1의 의미는 특정 모델 하나가 아니라 computer-use agent가 로컬과 실무 배포 조건을 갖추기 시작했다는 데 있습니다. 이제 개발팀은 “화면을 조작할 수 있나”보다 “어떤 권한과 검증 아래 조작하게 할 것인가”를 설계해야 합니다. 실행 체크리스트입니다. - API로 해결 가능한 업무와 GUI 조작이 필요한 업무를 먼저 분리합니다. - GUI agent에는 최소 권한 계정과 별도 브라우저 프로필을 사용합니다. - 클릭, 입력, 제출, 저장 액션을 단계별로 로그로 남깁니다. - 삭제, 결제, 권한 변경, 외부 발송은 사용자 승인 없이는 실행하지 않게 합니다. - selector 기반 E2E와 화면 의미 기반 agent 테스트를 함께 운영합니다. - 로컬 실행이 필요한 데이터 범위를 정의하고, 외부 API로 나가면 안 되는 화면을 목록화합니다. - 작은 모델은 라우팅과 단순 조작, 큰 모델은 복잡한 판단에 쓰는 다층 구조를 검토합니다.
보이스 에이전트는 데모에서는 자주 그럴듯해 보입니다. 문제는 실제 업무 전화로 들어가면 실패 지점이 갑자기 늘어난다는 데 있습니다. 예약번호 한 글자를 잘못 듣거나, 인증 절차를 건너뛰거나, 정책상 불가능한 요청을 가능하다고 말하면 사용자는 바로 신뢰를 잃습니다. ServiceNow AI가 Hugging Face에 공개한 EVA-Bench Data 2.0은 이 문제를 정면으로 다룹니다. 핵심은 “대화를 잘한다”가 아니라 “업무 상태를 정확히 바꾼다”를 평가한다는 점입니다. 이번 공개에서 눈에 띄는 숫자는 3개 도메인, 121개 도구, 213개 시나리오입니다. 기존 항공 고객 서비스 중심 평가에서 Enterprise IT Service Management, Healthcare HR Service Delivery까지 확장됐고, 시나리오 커버리지는 약 4배 늘었습니다. 각 데이터셋은 Hugging Face datasets로 바로 불러올 수 있고, MIT 라이선스로 공개됐습니다. 개발팀 입장에서는 벤치마크 논문을 읽는 데서 끝나는 자료가 아니라, 실제 평가 파이프라인에 넣어볼 수 있는 샘플이라는 점이 중요합니다. ## 왜 보이스 에이전트 평가는 일반 챗봇 평가와 다를까 텍스트 챗봇 평가는 답변의 정확성, 유해성, 문체, 도구 호출 성공률을 주로 봅니다. 보이스 에이전트는 여기에 음성 인식 오류, 턴테이킹, 인증, 사용자 재확인, 최종 업무 처리까지 얹힙니다. 사용자가 “비행편을 바꿔줘”라고 말했을 때 좋은 답변을 생성하는 것과 실제 예약 상태를 올바르게 변경하는 것은 다른 문제입니다. EVA-Bench 2.0이 강조하는 부분도 여기에 있습니다. 각 시나리오는 사용자 목표, 초기 데이터베이스 상태, 기대 최종 데이터베이스 상태를 포함합니다. 즉 평가 기준이 “친절하게 말했는가”가 아니라 “정해진 정책과 권한 안에서 올바른 write action을 수행했는가”로 내려옵니다. 실무에서는 이 차이가 큽니다. 콜센터 자동화, 사내 IT 헬프데스크, HR 상담처럼 데이터 변경이 들어가는 업무는 말솜씨보다 상태 전이가 중요합니다. ## 213개 시나리오가 주는 실무 신호 이번 버전은 Airline CSM 50개, Enterprise ITSM 80개, Healthcare HRSD 83개 시나리오로 구성됩니다. 단순 문의만 있는 것도 아닙니다. 단일 의도, 최대 4개 의도가 섞인 다중 의도, 사용자가 정책을 우회하려는 adversarial call, 목표 자체가 충족 불가능한 케이스까지 포함합니다. 실무 개발자에게 유용한 부분은 “불가능한 요청”을 평가한다는 점입니다. 많은 에이전트는 가능한 업무보다 불가능한 업무에서 더 위험해집니다. 사용자가 권한이 없는 기록을 보려고 하거나, 긴급도를 부풀리거나, 인증을 회피하면 모델은 대화를 매끄럽게 이어가기 위해 정책을 어길 수 있습니다. 그래서 보이스 에이전트 QA에서는 happy path만 돌리면 안 됩니다. 실패해야 하는 요청을 제대로 실패시키는지 확인해야 합니다. ## 인증과 재현성이 핵심 평가 축이 된 이유 EVA-Bench는 인증을 중요한 실패 지점으로 봅니다. 실제 전화 업무에서는 고객명, 이메일, 직원 ID, OTP, 보험 정보, 예약번호처럼 구조화된 값을 음성으로 주고받습니다. 모델이 숫자 하나를 놓치면 다음 도구 호출이 틀어지고, 사용자는 그 사실을 뒤늦게 발견합니다. 또 하나의 핵심은 재현성입니다. 같은 시나리오를 돌릴 때마다 사용자가 임의로 다르게 행동하면 평가 점수는 흔들립니다. EVA-Bench는 사용자 목표를 decision tree처럼 구성해 사용자가 언제 밀어붙이고, 언제 대안을 받아들이고, 어떤 증거가 있어야 통화를 끝내는지 명시합니다. 이 방식은 내부 QA에도 그대로 적용할 수 있습니다. “비밀번호 초기화 테스트”처럼 이름만 적지 말고, 사용자 발화 조건, 허용 정책, 도구 상태, 성공 증거를 분리해서 작성해야 합니다. ## 개발팀은 EVA-Bench를 어떻게 활용할 수 있나 첫 번째 용도는 회귀 테스트입니다. 보이스 에이전트 프롬프트, ASR 모델, 도구 스키마, 정책 문구를 바꿀 때마다 같은 시나리오를 반복 실행하면 변경의 부작용을 잡을 수 있습니다. 특히 인증 실패율, 불가능한 목표 처리율, write tool 정확도를 따로 기록해야 합니다. 두 번째 용도는 자체 데이터셋 설계 참고입니다. ServiceNow 팀은 시나리오 데이터베이스와 사용자 목표, 기대 최종 상태를 함께 생성하고 검증합니다. 이 구조를 따라가면 “테스트 대화 로그 몇 개”보다 훨씬 견고한 평가셋을 만들 수 있습니다. 고객센터, 예약, 정산, 내부 승인처럼 상태 변경이 있는 업무라면 대화 품질 점수보다 최종 상태 검증을 먼저 넣는 편이 낫습니다. 세 번째 용도는 다국어 출시 전 점검입니다. EVA-Bench는 영어 외 언어 확장도 예고했습니다. 한국어 보이스 에이전트라면 단순 번역으로 충분하지 않습니다. 전화번호 형식, 이름 발음, 기관명, 지역명, 존댓말, 사용자의 우회 표현까지 현지화해야 합니다. ## 도입 전에 볼 체크포인트 EVA-Bench 2.0은 보이스 에이전트 시장이 “말을 잘하는 모델”에서 “업무를 안전하게 끝내는 시스템”으로 이동하고 있다는 신호입니다. 개발팀은 모델 이름보다 평가 설계를 먼저 봐야 합니다. 특히 음성 기반 업무 자동화는 프롬프트만 좋아져서 해결되지 않습니다. 도구 스키마, 인증 절차, 정책 표현, 상태 검증, 실패 케이스가 함께 있어야 합니다. 실행 체크리스트입니다. - 현재 보이스 에이전트의 성공 기준을 답변 점수가 아니라 최종 DB 상태로 정의합니다. - happy path와 함께 인증 실패, 권한 없음, 정책상 불가, 다중 의도 시나리오를 만듭니다. - 사용자 목표, 초기 상태, 기대 최종 상태를 한 세트로 관리합니다. - 모델 변경, 프롬프트 변경, 도구 스키마 변경마다 같은 시나리오를 재실행합니다. - 한국어 서비스라면 이름, 번호, 기관명, 존댓말, 지역 표현을 현지화한 별도 평가셋을 만듭니다. - 보이스 에이전트 출시 전에는 “잘 답했는가”보다 “잘 거절했는가”를 반드시 확인합니다.
