모두의포트폴리오
PE · FDE 직군을 위한 포트폴리오 밀키트
예전 판입니다 (1판)이 문서는 2026-08-02 에 새 판으로 개정됐습니다. JD 에 외부 고객사 구축이 없고 협업 상대가 전부 자사 조직이라, 사용자를 자사 품질보증 담당자로 되돌리고 대조 방향을 고객사에서 회신받은 수입검사 결과와 자사 출하 성적서 사이로 뒤집었습니다.최신 판 보기 →
경력코오롱인더스트리

생산·품질 담당자가 채팅으로 '○○라인 불량 원인 확인해줘'라고 하면 어느 조회·등록 도구를 어떤 값으로 부를지 계획하고, 대상 설비·과제가 대장에 없거나 요청이 모호하면 실행을 멈추고 되묻거나 담당자에게 넘기는 제조 운영 AI Agent 콘솔

코오롱인더스트리 공고에서 뽑은 세 가지 시그널.

코오롱인더스트리 제조 DX 담당은 AX 전략 기반 AI Agent 서비스를 기획·프로토타이핑하고, 운영관리·과제관리 같은 제조 도메인 관리시스템을 그 Agent 에 도구로 연동하며, Agent Harness 로 계획·실행·검증 루프를 구성합니다. 현업 요청을 대장 매핑과 허용 규칙으로 검사해 도구를 부르거나 되묻거나 막는 이 콘솔은 그 핵심(요건도출·프로토타이핑·관리시스템 연동·Agent Harness)을 정면으로 입증합니다. 제조 라인·설비·과제라는 대상이 대장에 정의돼 있어야 요청이 허용 작업으로 매핑되는 이 사슬은, 대장 없이 일반 챗봇으로는 그대로 만들 수 없습니다. 실제 제조 설비 코드 체계나 사내 MES 연동 같은 실무 깊이는 포트폴리오로 증명되지 않으므로 합성 대장으로 라우팅 구조만 보이고, 그 깊이는 면접에서 솔직히 다룹니다.

01

AI Agent 서비스 기획 및 프로토타이핑

AX 전략을 기반으로 제조 현업이 쓸 AI Agent 서비스를 기획하고 요건을 도출해 프로토타이핑하고 검증합니다. 요청 라우팅 콘솔이 그 프로토타입으로 정렬됩니다.

AX 전략 기반 AI Agent 서비스 기획 및 제품화FDE: AI Agent 요건도출 및 프로토타이핑, 검증사용자 중심 요구사항 정의 및 서비스 시나리오 설계
02

제조 관리시스템·과제관리 연동

운영관리·과제관리 같은 제조 도메인 관리시스템을 기획하고 AI Agent 가 그 데이터를 도구로 조회·등록하게 잇습니다. 운영 대장 라우팅이 정렬됩니다.

다양한 도메인의 관리시스템(운영관리, 과제관리 등) 기획 경험제조 AI 기획 및 PI/컨설팅 지원현업부서(제조/생산 등) 및 경영진 대상 보고·커뮤니케이션 경험
03

Agent Harness 기반 도구 실행

Agent Harness 로 도구를 정의하고 계획·실행·검증 루프를 구성해 요청을 안전하게 도구 호출로 바꿉니다. 권한 밖 차단과 미매핑 되묻기가 정렬됩니다.

Agent Harness 기반 프로젝트 진행 경험AI Agent 개발 PO/PM 및 고도화 로드맵 수립S/W 아키텍처 이해 및 사용자 요구사항 정의, SW 개발 경험

포트폴리오 요약

제조 현업의 자연어 요청을 받아 Claude 가 요청 의도를 분류하고 어떤 도구(품질조회·설비이력조회·과제등록·상태변경·담당자알림)를 어떤 값으로 부를지 계획하되, 요청이 가리키는 라인·설비·과제가 운영 대장에 매핑되는지, 요청한 작업이 그 대상의 허용 목록 안인지, 요청이 한 대상으로 특정되는지 규칙으로 검사해 실행할지·되물을지·막을지 정합니다. 무엇을 실행할지는 대장 매핑과 허용 규칙이 결정하고, LLM 은 의도 분류와 도구 계획 초안만 맡습니다. 지식 판정이 아니라 요청과 대장의 정합성 게이트입니다.

고객 정의

코오롱인더스트리 제조 DX 담당자(AI Agent 서비스 기획 겸 FDE). 생산·품질 현업이 채팅으로 던지는 요청을 AI Agent 가 알아서 도구로 처리하게 만들 때, 대장에 없는 설비를 지어내 조회하거나 권한 밖 작업을 실행하지 않는지 요청마다 일일이 확인하던 일을, 한 콘솔에서 계획·실행·되묻기·차단 결과를 함께 보고 싶은 사람입니다.

고민 지점

현업 요청과 운영 대장을 한 스키마로 묶고 매핑·허용 규칙을 붙이면, (a) 대장에 없는 대상·권한 밖 작업·모호한 요청을 규칙으로 걸러 되묻거나 막고, (b) 왜 그 도구를 그 값으로 부르는지 대장 레코드 인용으로 풀며, (c) 여러 요청 유형을 끊김 없이 도구 계획으로 잇습니다.

주차별 일정

1주차여기까지로 완성

요청 분류 + 도구 계획 + 대장 검사로 실행·되묻기·차단

현업 자연어 요청을 받아 Claude 가 의도를 분류하고 도구 호출 계획을 세우되, 대상이 운영 대장에 없거나 요청이 모호하거나 작업이 권한 밖이면 멈추고 되묻거나 담당자에게 넘기는 동작하는 채팅 콘솔입니다. 운영 대장과 요청은 합성 더미로 시작하고 도구는 조회 결과를 흉내내는 모의 함수로 로컬 구동합니다.

  1. 1일 · 요청·대장·계획 스키마를 정의현업 요청·운영 대장(라인·설비·과제·허용작업)·도구 계획·매핑 검사 스키마 + 되묻기·차단 규칙 정의
  2. 2-3일 · 도구 정의와 Agent Harness 계획 루프품질조회·설비이력·과제등록·상태변경·담당자알림을 함수 스키마로 정의하고 계획·실행·검증 루프를 구성합니다
  3. 4-5일 · 의도 분류 + 도구 계획 + 매핑 검사 게이트Claude 의도 분류·도구 계획 생성 + 대상 대장 매핑·허용 작업·요청 특정성 규칙으로 실행/되묻기/차단 결정
  4. 6일 · 제조 운영 AI Agent 콘솔 화면요청 입력 + 세운 계획(도구·값)과 인용한 대장 레코드 + 되묻기·차단 사유 카드
  5. 7일 · 7일치 시연 영상 + 심은 정답과 비교한 기준선여기까지가 1주차 완성품입니다
2주차선택 성장

계획이 맞았는지 확인

라우팅 판정을 심은 정답 결정·검수자 2명 라벨과 비교해 라우팅 정확도, 되묻기·차단 정밀도와 재현율, 일치도를 보여주는 화면입니다.

  1. 8-10일 · 검수자 2명이 라우팅 라벨링심은 정답 결정 대비 라우팅 정확도·되묻기·차단 정밀도·재현율 + 검수 가이드
  2. 11-12일 · 판정 신뢰도 보강일치도 측정(Cohen's κ: 두 사람 판정이 우연 이상으로 일치하는 정도, 0~1) + 오라우팅 사례 정리 + 5% 사람 점검
3주차선택 성장

실제 도구 실행 연동과 감사 로그

과제 등록·상태 변경 도구를 실제로 실행해 대장에 반영하고, 두 번째 도메인(설비 이력 조회)을 붙이며, 누가 언제 어떤 요청으로 무엇을 실행했는지 감사 로그로 남기는 화면입니다.

  1. 15-18일 · 과제 등록·상태 변경 도구 실제 실행 연동실행 결과를 대장에 반영하고 설비 이력 조회 도메인을 붙이며 감사 로그를 남깁니다
  2. 19-21일 · 두 번째 요청 유형 추가 + 통합 시연 영상실제 도입 계획(실 MES 연동·실 검수자 교체)을 포함합니다

데모 · 측정 지표

01

요청 시나리오 14종(정상 조회·과제 등록·모호 요청·미등록 설비·권한 밖 작업)을 넣으면, 세운 도구 계획과 인용한 대장 레코드, 실행/되묻기/차단 결과가 몇 초 안에 나오는 걸 시연합니다

02

일부러 만든 악성·결측 입력 30종(대장에 없는 설비 코드·표기 흔들린 라인명·담당자 없는 과제·빈 요청문)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다

03

더미에 심은 정답 결정 45건 중 라우팅 판정(실행/되묻기/차단)이 일치한 게 39건(약 87%)이고 부른 도구·값이 규칙과 맞는 걸 보여줍니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다

정직 경계선

진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 라우팅 정확도와 되묻기·차단 정밀도는 코오롱인더스트리 실 운영 대장과 실 현업 요청, 실 검수자가 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다

미리 알아둬야 할 것들

이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다

이 포트폴리오가 입증하는 것은 AI Agent 요건도출·프로토타이핑, Agent Harness 계획·실행·검증 루프, 관리시스템 연동 라우팅 게이트 기술입니다. 실제 제조 설비 코드 체계·사내 MES 연동·현장 안전 규정 같은 실무 깊이는 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 부분은 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 합성 운영 대장으로 라우팅 구조만 입증합니다

정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 대장에 없는 설비 코드·표기 흔들린 라인명·권한 밖 작업·복수 후보로 모호한 요청 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 요청만 통과시키는 게 아님을 보여줍니다

LLM 이 세운 계획은 그럴듯해도 대장에 없는 대상을 조회하려 하거나 권한 밖 작업을 부를 수 있습니다. 대상이 대장에 매핑되는지·작업이 허용 목록 안인지 규칙으로 검사하고, 매핑이 안 되면 실행하지 않고 되묻거나 차단합니다

라인·설비 표기가 제각각입니다. 정규화로 같은 대상으로 묶고, 못 묶은 건 추측하지 말고 미매핑으로 알립니다. 실제 도입 시 사내 코드 체계·요청 분포가 더미와 다르므로 매핑 규칙과 허용 목록을 다시 맞춰야 합니다(도입 단계 과제로 분리)

더미 데이터

① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.

ops_registryTABLE· 12 rows

라인·설비·과제 운영 대장. AI Agent 가 요청 대상을 조회하고 허용 작업을 확인하는 마스터입니다. 같은 대상의 표기 별칭·담당자 결측·허용 작업 빈 값을 일부러 섞어, 대장에 없거나 권한 밖인 요청을 실행하지 않는지 자가채점합니다.

② ops_registry.seed.json 다운로드
① 인라인 샘플 (프리뷰 5 / 12)
entity_identity_typename_rawname_idownerstatusallowed_actions
line_A1lineA1 생산라인line_a1김생산가동["query_quality","query_equipment_history","notify_owner"]
line_A2lineA2라인line_a2박라인가동["query_quality","notify_owner"]
eq_press_07equipment프레스 7호기eq_press_07이설비가동["query_equipment_history","notify_owner"]
eq_dryer_03equipment건조기 3호eq_dryer_03—점검중["query_equipment_history"]
task_1042taskA1라인 불량률 개선 과제task_1042김생산진행중["update_task_status","notify_owner"]
③ 증강 프롬프트 (본인 LLM 에 붙여서 N 배 늘리기)
아래 JSON Schema 에 맞는 라인·설비·과제 운영 대장 30건을 JSON 배열로 생성합니다. line·equipment·task 를 고르게 섞고 allowed_actions 는 entity_type 에 맞게 둡니다.

{"type":"object","properties":{"entity_id":{"type":"string"},"entity_type":{"type":"string","enum":["line","equipment","task"]},"name_raw":{"type":"string"},"name_id":{"type":["string","null"]},"owner":{"type":["string","null"]},"status":{"type":"string"},"allowed_actions":{"type":"array","items":{"type":"string","enum":["query_quality","query_equipment_history","create_task","update_task_status","notify_owner"]}}},"required":["entity_id","entity_type","name_raw","status","allowed_actions"]}

쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(대장에 없거나 권한 밖인 요청을 실행하는 함정 회피): (1) 같은 대상의 표기 별칭(같은 name_id 를 가리키는 'A1 생산라인'/'에이원 라인'처럼 정규화돼야 함) 2건 이상, (2) 결측: owner 가 null 이거나 name_id 가 null 인 미매핑 레코드 2건, (3) 경계값: allowed_actions 가 빈 배열(허용 작업 없음)이거나 status='정지'/'점검중'인 극단 1~2건, (4) 도메인 혼동을 부르는 유사 명칭(프레스 7호기/프레스 8호기) 2건. JSON 배열만.
schema (3 층의 단일 출처)
{"type":"object","properties":{"entity_id":{"type":"string"},"entity_type":{"type":"string","enum":["line","equipment","task"]},"name_raw":{"type":"string"},"name_id":{"type":["string","null"]},"owner":{"type":["string","null"]},"status":{"type":"string"},"allowed_actions":{"type":"array","items":{"type":"string","enum":["query_quality","query_equipment_history","create_task","update_task_status","notify_owner"]}}},"required":["entity_id","entity_type","name_raw","status","allowed_actions"]}
agent_requestsTABLE· 14 rows

현업 자연어 요청 로그. AI Agent 가 가장 먼저 받는 입력입니다. 대장에 없는 대상·권한 밖 작업·복수 후보로 모호한 요청을 일부러 섞고, gold_decision 과 gold_tool 로 정답을 심어 자가채점합니다.

② agent_requests.seed.json 다운로드
① 인라인 샘플 (프리뷰 5 / 14)
req_idutterancetarget_rawtarget_idrequested_actiongold_decisiongold_tool
r_001A1 생산라인 최근 불량률 좀 보여줘A1 생산라인line_a1query_qualityroutequery_quality
r_002프레스 7호기 지난달 설비 이력 조회해줘프레스 7호기eq_press_07query_equipment_historyroutequery_equipment_history
r_003에이원 라인 품질 데이터 확인 부탁해에이원 라인line_a1query_qualityroutequery_quality
r_0049호기 설비 이력 좀 봐줘9호기—query_equipment_historyblock—
r_005그 라인 상태 알려줘그 라인—query_qualityclarify—
③ 증강 프롬프트 (본인 LLM 에 붙여서 N 배 늘리기)
아래 JSON Schema 에 맞는 현업 자연어 요청 로그 60행을 JSON 배열로 생성합니다. route 위주에 clarify·block 을 섞습니다.

{"type":"object","properties":{"req_id":{"type":"string"},"utterance":{"type":"string"},"target_raw":{"type":"string"},"target_id":{"type":["string","null"]},"requested_action":{"type":["string","null"],"enum":["query_quality","query_equipment_history","create_task","update_task_status","notify_owner",null]},"gold_decision":{"type":"string","enum":["route","clarify","block"]},"gold_tool":{"type":["string","null"]}},"required":["req_id","utterance","target_raw","gold_decision"]}

gold_decision 규칙: target_id 가 null 이고 대상 표기가 특정 불가·복수 후보(예: '그 라인', '프레스')면 clarify, target_id 가 null 이고 대장에 아예 없는 대상(예: '9호기')이면 block, target_id 는 매핑됐지만 requested_action 이 그 대상의 allowed_actions 밖(ops_registry 참조)이면 block, utterance 가 비었으면 clarify, 그 외(대상 매핑됨·작업 허용됨)면 route 이고 gold_tool=requested_action. route 가 아니면 gold_tool=null.

쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 요청만 통과시키는 함정 회피): (1) 표기 별칭('A1 생산라인'/'에이원 라인'처럼 같은 target_id 로 정규화돼야 함) 3건 이상, (2) 대장에 없는 대상(target_id=null, block) 2건, (3) 모호한 지시대명사·복수 후보(target_id=null, clarify) 2건, (4) 결측: utterance 가 빈 문자열 1건, (5) 권한 밖 작업(대상은 매핑됐지만 requested_action 이 allowed_actions 밖, block) 3건. gold_decision 은 위 규칙대로 정직하게. JSON 배열만.
schema (3 층의 단일 출처)
{"type":"object","properties":{"req_id":{"type":"string"},"utterance":{"type":"string"},"target_raw":{"type":"string"},"target_id":{"type":["string","null"]},"requested_action":{"type":["string","null"],"enum":["query_quality","query_equipment_history","create_task","update_task_status","notify_owner",null]},"gold_decision":{"type":"string","enum":["route","clarify","block"]},"gold_tool":{"type":["string","null"]}},"required":["req_id","utterance","target_raw","gold_decision"]}

기술 상세 · 아키텍처·운영·출력 스키마

기술 스택 매핑
Python요청 분류·도구 계획·대장 검사 규칙·FastAPI 백엔드를 구현하는 언어입니다
LLM현업 자연어 요청의 의도를 분류하고 도구 호출 계획 초안을 만드는 생성 엔진입니다
Claude요청 의도 분류와 도구·파라미터 계획을 담당하는 구체 모델입니다
Agent Harness도구를 정의하고 계획을 세워 실행하고 결과를 검증하는 계획·실행·검증 루프의 골조입니다
Tool calling품질조회·설비이력·과제등록 같은 도구를 스키마로 정의해 LLM 이 구조화된 호출로 부르게 하는 방식입니다
FastAPI요청 분류·계획·대장 검사 게이트를 묶는 백엔드 API 입니다
PostgreSQL라인·설비·과제 운영 대장과 허용 작업 목록을 담는 저장소입니다
Next.js현업 요청 입력과 계획·실행·되묻기·차단 결과를 보여주는 채팅 콘솔 화면입니다
LLM 선택
model
Claude Sonnet (의도 분류·도구 계획 생성) + GPT-4o-mini (LLM-as-judge 계획이 대장 매핑·허용 규칙과 일치하는지 검사)
prompt
few-shot 4 예시 + 도구를 함수 스키마로 정의한 tool calling 강제 + 대상이 대장에 없으면 되묻기·차단 가드 + 작업이 허용 목록 밖이면 차단 가드 + 후행 judge
rationale
실행할지 되물을지 막을지는 대상의 대장 매핑·허용 작업 규칙이 결정하므로 LLM 이 도구를 잘못 불러도 게이트에서 막힙니다. 의도 분류·계획 품질에 Sonnet 을, 계획 대 규칙 일치 judge 는 비용·속도 우선으로 mini 를 씁니다. 요청 대상은 정형 대장에서 키로 조회되므로 벡터 검색(RAG)이 아니라 구조화된 tool calling 과 대장 매핑이 제품의 골조입니다.
결정 게이트
1주차 끝콘솔이 현업 요청을 의도 분류해 도구 계획을 세우고, 대상이 대장에 없거나 모호하거나 권한 밖이면 멈추고 되묻거나 담당자에게 넘기는가. 여기까지가 그 자체로 제출 가능한 완성품입니다.

✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(계획이 맞았는지 확인)로 진행합니다.

2주차 끝라우팅 판정이 심은 정답 결정·검수자 라벨로 맞다고 확인되고 라우팅 정확도와 되묻기·차단 정밀도·재현율이 붙는가.

✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(실제 도구 실행 연동과 감사 로그)로 진행합니다.

재사용 레이어 · 코어 70% / 도메인 30%
core (재사용 가능)
  • Agent Harness: 도구 스키마 정의 + 계획·실행·검증 루프
  • 매핑 게이트: 요청 대상이 대장에 있는지·작업이 허용 목록 안인지 규칙 검사
  • 모호 요청 되묻기 가드 + 권한 밖 작업 차단 가드
  • 라우팅 평가 도구(라우팅 정확도·되묻기·차단 정밀도·재현율)
  • 차단·미매핑 알림 리포트 봇
  • 5% 사람 spot-check 샘플러
domain (교체 대상)
  • 라인·설비·과제 운영 대장과 도메인별 엔티티 코드 체계
  • 검수자 페르소나와 도메인 요청 라벨 가이드
  • 도구 목록과 factors enum(미매핑·모호·권한밖·담당자없음)은 도메인별로 갈아끼웁니다
출력 스키마 · agent_decision

요청 1건에 대한 AI Agent 결정 카드. 세운 도구 계획·실행 여부·되묻기·차단 사유를 한 스키마로 담아 콘솔 카드에 씁니다. 지식 판정이 아니라 요청과 대장의 정합성 게이트입니다.

schema (JSON Schema)
{"type":"object","properties":{"req_id":{"type":"string"},"decision":{"type":"string","enum":["route","clarify","block"]},"tool":{"type":["string","null"],"enum":["query_quality","query_equipment_history","create_task","update_task_status","notify_owner",null]},"params":{"type":"object","properties":{"target_id":{"type":["string","null"]}},"required":["target_id"]},"factors":{"type":"array","items":{"type":"string","enum":["ok","unmapped_target","ambiguous_target","action_not_allowed","missing_owner","empty_request"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["req_id","decision","tool","params","factors","reason","evidence"]}
모범 출력 (4)
[
  {
    "input_ref": "r_001 (정상 조회)",
    "output": {
      "req_id": "r_001",
      "decision": "route",
      "tool": "query_quality",
      "params": {
        "target_id": "line_a1"
      },
      "factors": [
        "ok"
      ],
      "reason": "A1 생산라인이 대장의 line_a1 로 매핑되고 query_quality 가 그 라인의 허용 작업 목록 안이라 품질조회 도구를 호출합니다.",
      "evidence": "target_id=line_a1, allowed_actions 에 query_quality 포함",
      "hedge": null
    }
  },
  {
    "input_ref": "r_004 (대장에 없는 설비)",
    "output": {
      "req_id": "r_004",
      "decision": "block",
      "tool": null,
      "params": {
        "target_id": null
      },
      "factors": [
        "unmapped_target"
      ],
      "reason": "요청이 가리키는 9호기가 운영 대장에 없어 어떤 설비인지 확인할 수 없습니다. 지어내 조회하지 않고 실행을 막습니다.",
      "evidence": "target_raw=9호기, 대장 매핑 없음(target_id=null)",
      "hedge": "대장에 없는 설비라 조회하지 않고 담당자 확인이 필요합니다"
    }
  },
  {
    "input_ref": "r_005 (모호한 요청)",
    "output": {
      "req_id": "r_005",
      "decision": "clarify",
      "tool": null,
      "params": {
        "target_id": null
      },
      "factors": [
        "ambiguous_target"
      ],
      "reason": "그 라인이라는 표현만으로는 어느 라인인지 특정되지 않아 후보가 여럿입니다. 실행 전에 어느 라인인지 되묻습니다.",
      "evidence": "target_raw=그 라인, 특정 불가(복수 후보)",
      "hedge": "대상 라인이 특정되지 않아 되묻습니다"
    }
  },
  {
    "input_ref": "r_006 (권한 밖 작업)",
    "output": {
      "req_id": "r_006",
      "decision": "block",
      "tool": null,
      "params": {
        "target_id": "line_a2"
      },
      "factors": [
        "action_not_allowed"
      ],
      "reason": "A2라인은 line_a2 로 매핑되지만 create_task 가 그 라인의 허용 작업 목록에 없어 과제 등록 권한이 없습니다. 실행을 막습니다.",
      "evidence": "target_id=line_a2, allowed_actions 에 create_task 없음",
      "hedge": "허용되지 않은 작업이라 실행하지 않습니다"
    }
  }
]
검증 노트 (자동 vs 수동)

[자동 검증] 1. JSON Schema 로 출력 형식(필드·enum)이 통과하는지 확인해 필드 누락·잘못된 decision·tool 값을 거릅니다. 2. decision 이 매핑·허용 규칙(대장에 없음→block, 특정 불가·빈 요청→clarify, 허용 목록 밖→block, 통과→route)과 일치하는지 봅니다. 3. decision=route 면 tool 이 그 target_id 의 allowed_actions 에 실제로 들어 있는지(대장 대조) 확인하고, 허용 목록 밖이면 route 가 되지 않게 강제합니다. 4. decision 과 tool 을 심은 정답 gold_decision·gold_tool 과 비교해 라우팅 정확도와 되묻기·차단 정밀도·재현율을 계산합니다. [수동 검증] 1. 검수자 2명이 비동기로 실행/되묻기/차단을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 판정 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.