Compal Electronics의 Compal-MVP: 에이전트 4개가 노트북 R&D 시험을 나눠 맡아 검증 주기 47% 단축
대만 Compal Electronics가 R&D 검증을 계획·실행·원인 추정·준수 확인의 에이전트 4개(Compal-MVP)로 나눠 검증 주기를 47% 줄였다고 보고한 사례입니다. 화면과 로그를 함께 읽는 실행 방식, 확정된 실패만 쌓는 지식베이스, 12주 파일럿과 판정 기준을 정리했습니다.
Compal Electronics는 노트북 R&D 검증을 에이전트 넷에게 나눠 맡겼습니다. 계획을 짜는 Orchestrator, 화면과 로그를 보며 시험을 돌리는 Operator, 고장 원인을 미리 짚는 Reasoner, 준수를 확인하고 실패에서 배우는 Guardian입니다. 회사 보고로는 검증 주기가 47% 줄었습니다. 우리 시험실에 옮기려면 시험 한 계열에서 에이전트 판정을 사람 판정과 맞춰 보는 일, 선임 엔지니어의 고장 분석을 확정된 사례 기록으로 쌓는 일부터 시작해야 합니다.
요약
Compal Electronics는 대만 타이베이에 본사를 둔 노트북·전자제품 위탁 설계·생산 기업입니다. 2026 Gartner Eye on Innovation Awards 첨단 제조 부문에 제출·소개된 이 사례는 R&D 검증(신제품이 사양대로 동작하는지 출시 전에 시험하는 일)을 다룹니다. 사례집에 따르면 검증에는 세 가지 병목이 있었습니다. 복잡한 시험의 81%를 사람이 손으로 돌렸습니다. 시험을 정해진 순서대로 하나씩 이어 붙이는 선형 스케줄링 탓에 장비와 사람이 놀거나 한쪽으로 몰렸습니다. 고장 진단은 선임 엔지니어의 머릿속 경험(암묵지)에 기댔습니다. 제품 종류가 많고 물량도 큰 시장이라 출시가 늦어지고 인력을 유연하게 돌리기 어려웠으며 선임이 떠나면 진단 지식도 함께 사라질 위험이 있었습니다. 회사는 이 일을 Compal-MVP라는 검증 플랫폼에서 에이전트 4개가 나눠 맡게 했습니다.
회사가 보고한 성과는 네 가지 비율과 시험실 운영 방식 하나입니다. 검증 주기가 47% 줄었고 반복 시험에 쓰던 엔지니어 공수의 68%를 더 가치 있는 일로 돌렸습니다. 선임 엔지니어의 문제 해결 지식 가운데 62%를 다시 쓸 수 있는 검증 지식베이스로 옮겼고 복잡한 검증 워크플로의 81%를 자동화하거나 AI 지원으로 바꿨습니다. 여러 제품군의 시험실은 24시간 돌아가게 됐습니다. 기준선, 측정 기간, 각 비율의 분모는 사례집에 나오지 않습니다. 사례집 설명을 따라가면 효과의 출처는 둘입니다. 사람이 화면을 보고 내리던 판단을 VLM(vision language model, 이미지를 읽는 언어 모델)과 시스템 로그를 겹쳐 대신했습니다. 그리고 계획을 한 번 짜고 끝내지 않고 결과에 따라 다시 짜는 폐쇄 루프와 agent memory(에이전트가 과거 결과를 기억하는 저장소)를 붙였습니다. 아래에서 네 에이전트와 루프, 공개 자료로 확인한 관련 사례, 한국 제조사 시험실에 옮길 때의 설계와 일정을 봅니다.
핵심 메커니즘
Orchestrator: 선임의 시험 계획 노하우를 옮겨 담은 계획 에이전트
Orchestrator는 무엇을 어떤 순서로, 어느 시험대에서 시험할지 정하는 에이전트입니다. 사례집은 이 에이전트가 전문가의 노하우를 디지털화해 실행 계획을 스스로 짠다고 설명합니다. 입력은 고객 시험 사양과 제품 구성, 시험 장비 목록, 그리고 선임이 계획을 짤 때 쓰던 규칙입니다. 처리 단계에서는 시험을 잘게 나누고 선후 관계와 장비를 배정합니다. 출력은 시험대별 일정과 우선순위 큐입니다. 선형 스케줄링과 다른 점은 순서가 고정되지 않는다는 것입니다. 앞 시험이 실패하거나 장비가 비면 일정을 다시 짭니다. 사례집에 실린 경영진 발언이 꼽은 동적 스케줄링이 이 부분입니다.
구성이 자주 바뀌고 시험 항목이 많은 곳에 맞고 순서가 늘 같은 소규모 시험이면 고정 스크립트가 낫습니다. 작은 예시(가상 예시)로, 같은 메인보드에 CPU 두 종과 패널 세 종이 붙는 노트북이라면 조합이 여섯 개입니다. Orchestrator는 조합마다 공통 시험은 한 번만 돌리고 패널에 따라 달라지는 디스플레이 시험만 따로 배정해 시험대 대기 시간을 줄입니다.
Operator: 화면(VLM)과 로그를 함께 읽고 사람처럼 조작하는 실행 에이전트
Operator는 시험을 실제로 돌리는 에이전트입니다. 사례집은 VLM 기반 화면 분석과 시스템 로그를 결합해 사람 전문가처럼 움직인다고 적었습니다. 시험 중 장치 화면을 캡처하면 VLM이 창, 버튼, 오류 표시를 읽고 같은 시각의 시스템 로그와 맞춰 봅니다. 화면에는 정상으로 보이는데 로그에 드라이버 오류가 찍혔거나, 로그는 깨끗한데 화면이 멈춰 있으면 사람이 알아채던 이상입니다. Operator는 둘을 겹쳐 보고 다음 조작(클릭, 키 입력, 재부팅)을 실행하거나 판정을 내립니다. 경영진 발언이 말한 인터페이스 자동 조작에 해당합니다.
화면 조작이 많은 시험, 이를테면 OS 설정이나 BIOS 메뉴, 드라이버 설치, 사용자 시나리오 시험에 맞습니다. 전압이나 온도처럼 계측기 숫자만 보면 되는 시험은 VLM 없이 기존 계측 자동화가 더 싸고 정확합니다. 작은 예시(가상 예시)로, 절전 모드 복귀 시험에서 화면은 바탕화면으로 돌아왔지만 로그에 무선랜 장치 재초기화 실패가 남았다면 Operator는 통과가 아니라 uncertain으로 판정해 다시 돌리거나 사람에게 넘깁니다.
Reasoner: 시험 데이터를 예측적 디버깅으로 바꾸는 원인 추정 에이전트
Reasoner는 시험 데이터에서 고장 원인을 추정하는 에이전트입니다. 사례집 표현으로는 시험 데이터를 예측적 디버깅으로 바꿉니다. 실패가 나면 증상과 로그, 제품 구성과 펌웨어 버전을 받아 과거 실패 사례에서 비슷한 것을 찾고 원인 후보에 순위를 매깁니다. 예측적이라는 말은 실패 뒤에 원인을 찾는 데서 끝나지 않는다는 뜻으로 읽힙니다. 비슷한 구성에서 자주 깨지던 시험을 미리 표시해 Orchestrator가 그 시험을 앞쪽에 배치하게 만드는 방식입니다.
과거 실패 기록이 수백 건 이상 쌓여 있고 증상과 원인이 함께 적혀 있을 때 쓸 만합니다. 신규 플랫폼 첫 세대처럼 비슷한 과거 사례가 없으면 후보의 근거가 약하므로 사람 진단을 앞에 둡니다. 작은 예시(가상 예시)로, 특정 SSD 펌웨어 버전에서 최대 절전 복귀 실패가 반복됐다면, 같은 펌웨어가 들어간 새 구성의 최대 절전 시험을 첫날 일정으로 당깁니다.
Guardian: 준수를 지키고 실패에서 배우는 감시 에이전트
Guardian은 두 가지 일을 합니다. 하나는 준수 확인입니다. 고객 사양이 요구한 시험이 빠지지 않았는지, 판정마다 증거(화면 캡처, 로그)가 붙었는지, 정해진 규칙을 어긴 조작이 없는지 봅니다. 다른 하나는 실패 학습으로, 실패 사례를 기록해 다음 계획과 원인 추정에 쓰게 합니다. 경영진 발언이 말한 AI 거버넌스가 이 역할입니다. 사람 없이 밤새 시험을 돌리려면 판정 근거를 지키는 역할이 따로 있어야 합니다.
고객사 인증이나 규제 시험처럼 증거 보관이 필요한 곳에서는 꼭 둬야 합니다. 내부 탐색용 시험이라면 규칙 검사를 가볍게 두고 학습 기능만 써도 됩니다. 작은 예시(가상 예시)로, 고객 사양에 “충전 시험은 주변 온도 기록 첨부”가 있는데 온도 로그가 비어 있으면 Guardian은 그 판정을 무효로 돌리고 시험을 다시 큐에 넣습니다.
Closed-loop feedback과 agent memory: 결과가 다음 계획으로 돌아가는 고리
네 에이전트를 하나로 묶는 것은 폐쇄 루프입니다. Operator의 결과가 Reasoner로 가고 Reasoner의 추정과 Guardian이 확정한 실패가 memory에 쌓이며 Orchestrator는 그 memory를 보고 다음 계획을 짭니다. 사례집은 이 구조가 수작업을 줄이고 지식을 보존하는 적응형 플랫폼을 만든다고 설명합니다. 지식베이스로 옮긴 선임 지식 62%라는 숫자가 이 고리에서 나옵니다. 고리가 한 번 돌 때마다 확정된 사례가 늘고 사례가 늘수록 계획과 원인 추정이 사람에게 덜 기댑니다. 사례집에 실린 경영진 발언도 플랫폼의 목표를 네 기능을 한데 묶는 것으로 설명합니다. 원문 표현은 “integrate dynamic scheduling, automated interface operation, failure analysis, and AI governance”입니다.
사례 재구성
Compal-MVP: 노트북 R&D 검증을 에이전트 4개로 나눈 사례
| 항목 | 내용 |
|---|---|
| 상황 | 복잡한 시험의 81%가 수작업이었고 선형 스케줄링으로 장비와 인력이 비효율적으로 쓰였으며 고장 진단이 선임의 암묵지에 의존했습니다. 출시 지연, 인력 운용 제약, 지식 유실 위험이 함께 있었습니다. |
| 한 일 | Compal-MVP를 만들어 계획(Orchestrator), 실행(Operator), 원인 추정(Reasoner), 준수와 학습(Guardian)을 나눠 맡겼습니다. 폐쇄 루프 피드백과 agent memory를 붙였습니다. 사례집이 든 기술 분류는 AI 에이전트, 자동화, 도메인 특화 언어 모델, 의사결정 인텔리전스 플랫폼, 생성형 AI입니다. |
| 결과(회사 보고) | 검증 주기 47% 감소, 반복 시험 공수 68%를 고부가 업무로 전환, 선임 문제 해결 지식 62%를 지식베이스로 전환, 복잡한 검증 워크플로 81% 자동화 또는 AI 지원, 여러 제품군 시험실 24시간 가동. 기준선과 기간은 사례집에서 밝히지 않음. |
| 연결 | 네 메커니즘과 폐쇄 루프 전체의 사례입니다. 24시간 가동은 Operator와 Guardian이 사람 없이 판정과 증거 관리를 맡을 수 있어야 가능합니다. |
공개 자료로 확인한 관련 사례: AI Agent for PC Test Automation
| 항목 | 내용 |
|---|---|
| 상황 | 언론 보도(旺得富理財網, 2026.04.29)에 따르면 기존 PC 시험은 수작업 비중이 크고 자동화 스크립트는 유지보수가 어렵고 확장이 안 됐습니다. |
| 한 일 | Compal 공통 소프트웨어 R&D 본부 AI 팀이 Think(계획), Act(자율 실행), Verify(검증)를 도는 자체 에이전트 구조를 만들고 주요 지점에 사람 확인(HITL)을 뒀습니다. 工商時報(2026.08.04) 보도로는 양산 전 신제품 도입(NPI) 단계에서 엔지니어가 고객 시험 사양, 장치 사양, OS 설정(PDF, Excel)을 올리면 LLM이 해석해 시험을 계획·실행하고 고객 기준과 비교해 로그를 남깁니다. 실패하면 재시도와 문제 해결을 먼저 하고 풀지 못할 때만 사람이 들어갑니다. |
| 결과 | 대만 경제부 제2회 智慧創新大賞(스마트 혁신 대상) 은상(2026.04 보도). 회사 내부 추산으로 수동 모니터링 시간이 약 150시간에서 약 1시간으로 줄었고 올해 InnoVEX에서 50곳이 넘는 기업이 문의했다고 보도됐습니다. 게이밍 노트북, AI PC, 엣지 장치에서도 돌고 온프레미스·클라우드·하이브리드 배치를 지원한다고 소개됐습니다. |
| 연결 | Orchestrator(사양 해석과 계획), Operator(실행과 비교), Guardian(사람 확인 지점)과 같은 방향입니다. 다만 Compal-MVP와 같은 시스템인지는 공개 자료로 확인하지 못했으므로 별도 사례로 둡니다. |
기술 디테일: 우리 시험실에 네 에이전트를 세우려면
아래는 사례집과 공개 보도에 없는, 실제로 돌릴 때 필요한 설계입니다. 필드명과 수치는 모두 가상 예시입니다.
Orchestrator를 만들려면 LLM은 사양 해석에, 일정은 최적화 도구에 맡깁니다. 고객 시험 사양(PDF, Excel)을 LLM이 읽어 시험 항목을 아래 같은 구조화 출력으로 뽑게 합니다. 일정 배정 자체는 LLM에게 맡기지 않고 OR-Tools CP-SAT 같은 제약 최적화 도구로 풉니다. 시험대 수, 장치 수, 선후 관계가 제약이고 전체 소요 시간이 목표입니다. LLM 출력은 temperature 0으로 두고 사양서의 시험 항목 번호 목록과 대조해 빠지거나 지어낸 항목이 있으면 사람 확인으로 돌립니다. 실패나 장비 고장이 나면 남은 시험만 다시 최적화합니다.
{
"test_id": "PWR-S4-012",
"spec_ref": "고객사양 v3.2 §5.4",
"config": {"cpu": "A", "panel": "16in-OLED", "bios": "1.07"},
"rig_type": "power-cycler",
"depends_on": ["PWR-S4-001"],
"est_minutes": 95,
"priority": 2,
"evidence_required": ["screen", "event_log", "ambient_temp"]
}
Operator를 돌리려면 판정을 넷으로 나누고 애매하면 재실행합니다. 단계마다 화면 캡처 한 장과 그 앞뒤 30초 로그를 함께 넘기고 VLM에는 화면에서 본 것만 screen_state로, 로그 해석은 별도 규칙과 LLM이 log_signals로 내게 합니다. 최종 판정은 둘을 합친 verdict(pass, fail, uncertain)와 confidence입니다. uncertain이면 같은 단계를 3회 다시 돌려 다수결을 보고 그래도 어긋나면 엔지니어 대기열로 보냅니다. 가장 위험한 실패는 거짓 통과입니다. 초기 4주는 모든 pass 판정의 10%를 무작위로 사람이 다시 보고 거짓 통과가 한 건이라도 나오면 그 시험 계열의 자동 통과를 멈춥니다. 화면 해상도와 OS 언어가 바뀌면 VLM 정확도가 흔들리므로 구성별로 기준 캡처 20장씩을 평가 세트로 둡니다.
Reasoner와 memory를 쓰려면 사람이 확정한 실패만 지식으로 넣습니다. 실패 사례 기록은 symptom, error_codes, config(제품 구성·펌웨어·OS 빌드), root_cause, fix, confirmed_by, confirmed_at, source_run_id 필드로 둡니다. 검색은 증상 문장 임베딩과 오류 코드 일치를 함께 써서 상위 5건을 가져오고 Reasoner는 원인 후보 3개와 근거 사례 ID를 냅니다. 근거 사례 ID가 없는 후보는 화면에 보여 주지 않습니다. 에이전트가 추정만 하고 사람이 확정하지 않은 원인이 지식베이스에 들어가면 다음 추정이 그 추정을 근거로 삼는 오염이 생깁니다. 선임 지식을 옮기는 비율(Compal은 62%로 보고)을 우리도 재려면, 시작 전에 선임 인터뷰로 고장 유형 목록을 만들어 분모로 쓰고 지식베이스가 덮는 유형 수를 분자로 셉니다.
Guardian을 세우려면 규칙 검사는 코드로, 기록은 바꿀 수 없게 둡니다. 고객 사양의 필수 시험 목록, 증거 요건, 금지 조작(예: 시험 중 BIOS 설정 임의 변경)은 LLM 판단이 아니라 규칙 코드로 검사합니다. 판정과 증거, 에이전트가 실행한 조작은 실행 ID별로 추가만 되는 로그에 남깁니다. 고객사 감사에서 “이 판정은 누가 무엇을 보고 내렸나”에 답하려면 run_id, agent, model_version, prompt_version, evidence_uri, human_override가 한 줄에 있어야 합니다. 모델이나 프롬프트를 바꾼 날에는 과거 평가 세트를 다시 돌려 판정 일치율이 떨어지지 않았는지 보고 나서 배포합니다.
24시간 가동을 하려면 사람 없는 시간의 멈춤 규칙을 먼저 정합니다. 야간에 escalate가 쌓이면 시험대가 놀게 되므로, Orchestrator가 escalate된 시험을 건너뛰고 다른 시험을 당겨 오게 합니다. 같은 시험대에서 연속 3회 장비 오류가 나면 그 시험대를 일정에서 빼고 아침 담당자에게 알립니다. 검증 데이터는 미출시 정보이므로 모델은 사내(온프레미스·엣지) 배치를 기본값으로 둡니다.
현업 실행 디테일: 누가, 언제, 무엇을
역할(가상 예시)
| 역할 | 맡는 일 | 투입 |
|---|---|---|
| 검증 팀장(오너) | 대상 시험 계열 선정, 주간 판정, 현업 스폰서 보고 | 주 4시간 |
| 선임 시험 엔지니어 2명 | 계획 규칙과 고장 진단 지식 인터뷰, 실패 사례 확정 | 주 6시간 |
| 시험 자동화 엔지니어 2명 | 시험대 연결, 화면 캡처·로그 수집, 조작 도구 | 전담 |
| ML 엔지니어 1~2명 | VLM·LLM 프롬프트, 평가 세트, 지식베이스 검색 | 전담 |
| 품질·고객 대응 담당 | 고객 사양 필수 시험과 증거 요건 정리, Guardian 규칙 검토 | 주 3시간 |
| 시험실 운영 담당 | 시험대 가동 기록, 야간 멈춤 규칙 운영 | 주 4시간 |
시작 전 준비물. 최근 12개월의 시험 계획서와 결과 로그, 실패 분석 보고서(원인과 조치가 적힌 것), 시험대·장비 목록과 가동 기록, 주요 고객 2~3곳의 시험 사양서, 기준선 숫자(시험 계열별 검증 소요 일수, 사람이 지켜본 시간, 시험대 가동률)입니다. 기준선이 없으면 나중에 47% 같은 숫자를 우리 것으로 말할 수 없으므로 1~2주차에 반드시 잽니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 시험 계열 하나(예: 전원·절전 시험) 고르기, 기준선 측정, 선임 인터뷰 4회 | 기준선 표, 고장 유형 목록(분모) |
| 3~5주 | Operator를 그 계열에 붙여 사람과 나란히 실행(shadow mode) | 판정 일치율, 거짓 통과 건수 |
| 6~8주 | 과거 실패 보고서로 지식베이스를 채우고 Reasoner 시험 | 원인 후보 적중률, 지식베이스 커버리지 |
| 9~10주 | Orchestrator로 동적 일정 적용, 시험대 2~3대 | 시험대 가동률, 소요 일수 변화 |
| 11~12주 | Guardian 규칙 적용, 야간 무인 운영 2주 | 감사 로그, 야간 멈춤 기록, 확대 여부 판정 |
선임 인터뷰 질문. 이 증상을 보면 가장 먼저 무엇을 확인합니까? 같은 증상인데 원인이 달랐던 경우는 무엇이 달랐습니까? 시험 순서를 바꿔서 시간을 줄인 경험이 있습니까, 어떤 기준으로 바꿨습니까? 신입이 가장 자주 놓치는 로그는 무엇입니까? 고객이 증거로 꼭 요구하는 것은 무엇입니까?
진행 판정 기준(가상 예시). 3~5주차 shadow mode 200회 이상에서 Operator 판정이 사람과 95% 이상 일치하고 거짓 통과가 0건이면 자동 통과를 엽니다. 6~8주차에 Reasoner 상위 3개 후보 안에 실제 원인이 들어간 비율이 60% 이상이면 엔지니어 화면에 노출합니다. 12주차에 대상 계열의 검증 소요 일수가 기준선보다 20% 이상 줄고 감사 로그 누락이 0건이면 두 번째 시험 계열로 넓힙니다. 하나라도 못 미치면 그 단계를 2주 더 돌리고 원인을 적습니다.
어디에 먼저 쓸까. 한국 대기업 제조사라면 노트북·스마트폰·가전·전장 부품의 신뢰성 시험과 고객 인증 시험이 1순위입니다. 화면 조작이 많고 시험 사양이 고객마다 다르며 선임 엔지니어 은퇴로 진단 지식이 빠져나가는 곳이기 때문입니다. 순서는 Compal-MVP의 네 역할을 한꺼번에 만들지 말고 Operator로 사람 판정과 맞추는 일부터, 다음으로 지식베이스, 그다음 계획과 감시 순입니다. 실행을 믿을 수 있어야 계획과 학습도 쓸모가 생깁니다. 현업 스폰서는 R&D 검증 조직장이 맡고 지표는 Compal처럼 검증 주기, 반복 공수 전환, 지식 전환율, 시험실 가동 시간 넷으로 잡되 분모를 1주차에 문서로 정합니다. Guardian의 감사 로그는 파일럿 첫날부터 켭니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 회사 | Compal Electronics, Inc. (대만 타이베이) |
| 출처 | Gartner 2026 Eye on Innovation Awards for Advanced Manufacturing, Greater China 사례집 슬라이드 6 |
| 사례명 | Multi-Agent R&D Validation Platform (Compal-MVP) |
| 문제 | 복잡한 시험 81% 수작업, 선형 스케줄링, 고장 진단의 선임 암묵지 의존. 출시 지연, 인력 운용 제약, 지식 유실 위험 |
| 구성 | Orchestrator(계획), Operator(VLM·로그 기반 실행), Reasoner(예측적 디버깅), Guardian(준수·실패 학습), 폐쇄 루프 피드백, agent memory |
| 기술 분류 | AI Agents, Automation, Domain-Specific Language Models, AI, Decision Intelligence Platforms, GenAI |
| 성과(회사 보고) | 검증 주기 47% 감소 · 반복 시험 공수 68% 고부가 업무로 전환 · 선임 문제 해결 지식 62% 지식베이스화 · 복잡한 검증 워크플로 81% 자동화 또는 AI 지원 · 여러 제품군 시험실 24시간 가동 |
| 경영진 언급 | 동적 스케줄링, 인터페이스 자동 조작, 고장 분석, AI 거버넌스를 하나의 검증 플랫폼으로 묶음 (Senior Executive) |
| 관련 공개 자료 | AI Agent for PC Test Automation: 대만 경제부 스마트 혁신 대상 은상(2026.04 보도), Think·Act·Verify 루프와 HITL, 수동 모니터링 약 150시간에서 약 1시간(회사 내부 추산, 2026.08 보도). 2026.10 Compal 발표: 제6회 디지털 전환 딩거상에서 AI 비전 검사 플랫폼 ‘Eye of Smart Manufacturing’ 1등상, ‘AI Agents Empowering Employees’ 우수상 |
핵심 개념
- R&D validation(R&D 검증)
- 신제품이 설계 사양과 고객 요구대로 동작하는지 양산 전에 시험하는 일. 전원, 절전, 무선, 디스플레이, OS 호환 시험 등이 들어간다.
- VLM(vision language model)
- 이미지를 입력으로 받아 그 내용을 글로 설명하거나 질문에 답하는 언어 모델. 여기서는 시험 중 장치 화면을 읽는 데 쓴다.
- NPI(New Product Introduction)
- 신제품을 설계에서 양산으로 넘기는 단계. 검증 시험이 가장 몰리는 구간이다.
- HITL(Human-in-the-Loop)
- 자동화 흐름의 정해진 지점에서 사람이 확인하거나 판정하게 두는 설계.
- shadow mode
- 에이전트가 사람과 같은 일을 나란히 하되 결과는 쓰지 않고 비교만 하는 시험 운영 방식.
내 메모
TODO: 내 생각 추가
근거: 사용자가 제공한 Gartner 2026 Eye on Innovation Awards Greater China 사례집의 Compal Electronics 사례(슬라이드 6, Multi-Agent R&D Validation Platform). 이 사례는 2026 Gartner Eye on Innovation Awards 첨단 제조 부문에 제출·소개된 사례이며 수상 여부는 공개 자료로 확인하지 못했습니다. 확인한 공개 자료: 旺得富理財網 보도(2026.04.28, https://wantrich.chinatimes.com/news/20260428900648-420501 · 2026.04.29, https://wantrich.chinatimes.com/news/20260429900141-420101), 工商時報 보도(2026.08.04, https://www.ctee.com.tw/news/20260804701569-431202), Compal 발표(I-Connect007, 2026.10.06, https://iconnect007.com/article/151874/compal-earns-two-honors-for-ai-transformation-at-digital-transformation-awards/151871/aep). 공개 자료의 AI Agent for PC Test Automation이 Compal-MVP와 같은 시스템인지는 확인하지 못했습니다. 요약·메커니즘·사례 재구성·원문 사례 표는 위 자료를 AX Review가 다시 정리했고 기술·현업 디테일, JSON 예시, 판정 기준, 일정, 인포그래픽과 표는 새로 작성했으며 그 안의 숫자는 가상 예시입니다.