제조 AI Agent는 어떻게 협업하고 실행해야 하는가?

기존의 제조 AI는 주어진 데이터를 받아 하나의 결과를 예측하는 방식으로 활용됐다.

• 제품이 정상인지 불량인지 판정한다.
• 설비가 언제 고장 날지 예측한다.
• 다음 달의 수요를 전망한다.
• 공정조건과 품질의 관계를 분석한다.
• 에너지 사용량을 예측한다.

모델의 입력과 출력은 비교적 명확했다.

그러나 AI Agent는 다르다.

Agent는 목표를 전달받고 필요한 데이터를 찾는다. 문제를 여러 단계로 나누고 적절한 도구를 선택하며 다른 시스템이나 Agent에 작업을 요청한다. 결과를 확인한 뒤 계획을 수정하거나 다음 행동을 결정하기도 한다.

예를 들어 생산관리자가 다음과 같이 요청할 수 있다.

“오늘 긴급주문을 반영하되 납기를 지키고, 설비 과부하와 품질위험을 최소화하는 생산계획을 다시 만들어라.”

이 요청을 수행하려면 하나의 모델만으로는 부족하다.

• 주문과 납기를 확인해야 한다.
• 재고와 자재 입고일을 조회해야 한다.
• 설비능력과 현재 상태를 확인해야 한다.
• 품질위험을 평가해야 한다.
• 작업자와 금형, 공구의 가용성을 확인해야 한다.
• 에너지 피크와 물류동선을 고려해야 한다.
• 기존 계획과 변경계획을 비교해야 한다.
• 필요하면 담당자의 승인을 받아 MES에 반영해야 한다.

이 과정에는 여러 데이터와 모델, 시스템과 사람이 참여한다.

따라서 제조 AI Agent의 핵심은 말을 잘하는 챗봇을 만드는 데 있지 않다.

서로 다른 역할을 가진 Agent가 동일한 제조상황을 이해하고, 충돌하는 목표를 조정하며, 허용된 범위 안에서 안전하게 실행하도록 만드는 것이다.

---

1. 제조 AI Agent란 무엇인가

AI Agent는 주어진 목표를 달성하기 위해 상황을 인식하고 계획을 세우며 도구와 데이터를 사용해 행동하는 AI 시스템이다.

일반적인 AI 모델이 입력에 대해 하나의 출력을 제공한다면 Agent는 여러 단계의 업무를 연결한다.

일반적인 AI 모델

데이터 입력

↓

모델 추론

↓

예측 또는 분류 결과

AI Agent

목표 수신

↓

상황과 제약조건 파악

↓

작업계획 수립

↓

데이터·모델·도구 선택

↓

다른 Agent 및 시스템과 협업

↓

실행 또는 승인 요청

↓

결과 확인

↓

재계획 또는 종료

Agent는 대규모 언어모델만을 의미하지 않는다.

언어모델은 자연어로 목표를 이해하고 계획을 세우는 데 사용될 수 있지만, 실제 제조업무를 수행하려면 다음 요소가 함께 필요하다.

• 설비와 공정에 대한 데이터
• 예측과 최적화를 수행하는 전문모델
• 업무규칙과 품질기준
• 온톨로지와 지식그래프
• MES·QMS·ERP·WMS와의 인터페이스
• 설비와 Edge 시스템의 상태정보
• 사용자와 Agent의 권한
• 승인과 실행절차
• 결과를 확인하는 모니터링 기능

NIST는 2026년 AI Agent Standards Initiative를 시작하면서 자율적으로 행동하는 Agent가 안전하게 상호운용될 수 있도록 기술표준과 개방형 프로토콜이 필요하다고 설명했다. 제조현장에서도 Agent의 성능뿐 아니라 신뢰성과 보안, 상호운용성과 권한통제가 함께 고려돼야 한다.

제조 AI Agent는 독립적으로 생각하는 가상의 직원이 아니다.

제조목표와 규칙, 데이터와 실행도구를 연결해 제한된 업무를 수행하는 소프트웨어 실행주체다.

---

2. 제조 Agent는 어떤 역할로 구분해야 하는가

하나의 Agent에 모든 제조업무를 맡기면 구조는 단순해 보인다.

그러나 생산과 품질, 설비와 물류의 목표가 서로 다르기 때문에 판단근거와 책임이 불명확해질 수 있다.

역할을 구분하면 전문성과 권한, 성능과 책임을 별도로 관리할 수 있다.

① 생산계획 Agent

수요와 주문, 재고와 설비능력을 이용해 생산계획을 수립한다.

• 주문 우선순위 분석
• 일·주·월 생산계획 작성
• 설비와 작업자 배정
• 긴급주문 반영
• 계획변경의 영향분석
• 납기위험 예측
• 대안계획 비교

② 공정운영 Agent

계획을 실제 공정조건과 작업순서로 변환한다.

• 작업지시 확인
• 공정조건 추천
• 제품 전환과 셋업 순서 결정
• 병목공정 탐지
• 사이클타임 분석
• 이상조건 발생 시 대안 제시

③ 품질 Agent

제품과 공정의 품질위험을 분석한다.

• 검사결과 판정
• 불량 가능성 예측
• 검사수준 조정
• 원인 후보 분석
• 제품과 LOT 격리 요청
• 재검사와 재작업 추천
• 고객불량과 내부데이터 연결

④ 설비·정비 Agent

설비상태와 고장위험을 관리한다.

• 이상징후 탐지
• 고장 가능성과 잔여수명 예측
• 정비시점 추천
• 작업과 부품 준비
• 생산계획과 정비계획 조정
• 정비 후 상태검증

⑤ 물류 Agent

원재료와 재공품, 완제품의 이동을 관리한다.

• 자재 가용성 확인
• 창고와 공정 간 이동계획
• AGV·AMR 작업배정
• 적치위치 추천
• 병목과 대기시간 분석
• 출하 우선순위 조정

⑥ 에너지 Agent

생산목표를 유지하면서 에너지 사용을 최적화한다.

• 피크전력 예측
• 설비운전 시간 조정
• 에너지 원단위 분석
• 비효율 설비 탐지
• 생산계획별 에너지 비용 비교

⑦ 안전 Agent

작업자와 설비, 환경의 안전조건을 확인한다.

• 작업허가 조건 확인
• 위험구역 접근 감시
• 안전규칙 위반 탐지
• 설비 인터록 상태 확인
• 위험한 작업계획 차단
• 비상정지와 대피정보 지원

⑧ 지식 Agent

문서와 표준, 경험지식을 제공한다.

• 작업표준 검색
• 설비 매뉴얼 확인
• 과거 장애사례 검색
• 품질규격과 고객요구 확인
• 온톨로지와 지식그래프 조회
• 답변의 출처와 유효기간 표시

⑨ 조정 Agent

여러 Agent의 제안을 종합하고 충돌을 조정한다.

• 전체 목표와 우선순위 확인
• 업무를 전문 Agent에 배분
• 결과의 일관성 점검
• 대안별 영향 비교
• 승인 필요 여부 판단
• 최종 실행계획 작성

역할을 나눈다고 모든 Agent를 별도의 언어모델로 만들 필요는 없다.

하나의 기반모델에 서로 다른 역할과 도구를 부여할 수도 있고, 전문 알고리즘과 규칙엔진을 Agent 형태로 연결할 수도 있다.

중요한 것은 Agent의 수가 아니다.

각 Agent가 어떤 판단을 담당하고, 어떤 데이터와 도구를 사용하며, 어디까지 실행할 수 있는지 구분하는 것이다.

---

3. Agent는 제조현장의 상황을 어떻게 공유해야 하는가

여러 Agent가 협업하려면 동일한 제조상황을 이해해야 한다.

생산계획 Agent가 설비 A를 가동 가능한 상태로 인식하고 정비 Agent가 정지 대상으로 인식한다면 올바른 계획을 만들 수 없다.

공유해야 할 상황정보에는 다음이 포함된다.

① 주문과 생산계획

• 주문번호
• 제품과 수량
• 납기
• 고객 우선순위
• 현재 계획과 진행률
• 계획변경 이력

② 제품과 공정

• 제품사양
• BOM과 공정경로
• 작업표준
• 품질기준
• 허용 공정조건
• 사용 가능한 설비와 금형

③ 설비상태

• 운전·대기·고장·정비 상태
• 현재 작업
• 생산능력
• 이상징후
• 정비예정
• 공구와 소모품 상태

④ 자재와 물류

• 원재료와 재공품 재고
• 자재 LOT
• 입고예정
• 창고위치
• 운반장비 상태
• 이동과 대기시간

⑤ 품질상태

• 검사결과
• 불량유형
• 품질경보
• 격리제품
• 재검사와 재작업
• 고객불량 정보

⑥ 인력과 작업조건

• 작업자와 자격
• 교대조
• 작업가능 시간
• 교육과 숙련도
• 안전작업 조건

Agent들이 각자 다른 데이터베이스에서 정보를 조회하면 시점과 단위, 코드가 달라질 수 있다.

따라서 공통된 상황모델이 필요하다.

온톨로지와 지식그래프는 제품과 설비, 공정과 품질, 주문과 작업지시의 관계를 공통된 의미로 연결하는 데 사용할 수 있다.

예를 들어 다음 관계가 명확해야 한다.

주문 A

→ 제품 P를 요구한다.

→ 제품 P는 공정 R1과 R2를 거친다.

→ 공정 R1은 설비 M1 또는 M2에서 수행할 수 있다.

→ 설비 M1은 현재 이상징후가 있다.

→ 설비 M2는 금형 T가 필요하다.

→ 금형 T는 다른 작업에서 사용 중이다.

→ 대체계획은 납기를 3시간 지연시킨다.

Agent는 이 관계를 이용해 단순히 빈 설비를 찾는 것이 아니라 실행 가능한 계획을 만들어야 한다.

공통 상황정보에는 반드시 다음이 포함돼야 한다.

• 데이터의 기준시각
• 데이터 출처
• 단위
• 최신성
• 품질상태
• 신뢰수준
• 승인상태
• 사용 가능한 범위

같은 데이터라고 해도 5분 전 정보와 현재 정보는 다르다.

Agent 협업의 첫 번째 조건은 더 많은 데이터를 연결하는 것이 아니라, 같은 시점의 현실을 같은 의미로 이해하는 것이다.

---

4. Agent 간 업무는 어떻게 배분해야 하는가

조정 Agent가 목표를 받으면 먼저 목표를 실행 가능한 작업으로 분해해야 한다.

예를 들어 다음과 같은 요청이 있다고 하자.

“오늘 오후까지 긴급주문 500개를 추가 생산할 수 있는지 확인하고 가능한 계획을 제시하라.”

이를 다음과 같이 나눌 수 있다.

생산계획 Agent

• 기존 주문과 납기 확인
• 추가 생산가능 시간 계산
• 대체 생산순서 작성

자재 Agent

• 원재료와 부품 재고 확인
• 부족자재와 입고 가능시간 확인

설비 Agent

• 사용 가능한 설비 확인
• 설비능력과 고장위험 분석
• 계획된 정비와의 충돌 확인

품질 Agent

• 생산속도 증가에 따른 품질위험 분석
• 추가검사 필요 여부 판단

인력 Agent

• 작업 가능한 인원과 자격 확인
• 연장근무와 교대조건 검토

물류 Agent

• 자재와 재공품 이동시간 분석
• 출하 가능시간 확인

에너지 Agent

• 피크전력과 추가 에너지 비용 계산

각 Agent의 결과를 받은 조정 Agent는 대안을 구성한다.

조정 Agent는 단순히 가장 비용이 낮은 C안을 선택해서는 안 된다.

안전과 품질, 납기와 비용의 우선순위에 따라 허용 가능한 대안만 남겨야 한다.

업무를 배분할 때에는 다음을 명확히 해야 한다.

• 전체 목표
• 하위 작업
• 담당 Agent
• 입력데이터
• 필요한 도구
• 완료조건
• 제한시간
• 결과형식
• 실패 시 처리
• 승인 필요 여부

Agent에게 모호한 작업을 주면 결과를 확인하기 어렵다.

**“최적의 생산계획을 만들어라”**보다 다음과 같이 요청해야 한다.

“고객 A의 납기를 지키고 중요 품질기준과 설비 안전한계를 위반하지 않으며, 기존 주문의 지연을 2시간 이내로 제한한 생산계획 대안 세 개를 작성하라.”

좋은 업무분해는 일을 잘게 나누는 것이 아니다.

각 작업의 책임과 완료조건을 확인할 수 있도록 나누는 것이다.

---

5. Agent들의 목표가 충돌하면 어떻게 조정해야 하는가

제조현장의 목표는 하나가 아니다.

생산량을 늘리면 설비부하와 품질위험이 증가할 수 있다. 재고를 줄이면 자재부족 위험이 커질 수 있다. 예방정비를 수행하면 고장위험은 낮아지지만 납기가 지연될 수 있다.

따라서 Agent들이 서로 다른 결론을 내리는 것은 비정상적인 일이 아니다.

문제는 충돌 자체가 아니라 충돌을 해결하는 기준이 없는 것이다.

① 절대 위반할 수 없는 조건

• 작업자 안전
• 법규
• 설비의 안전한계
• 고객의 핵심 품질요구
• 환경배출 기준
• 승인되지 않은 데이터와 시스템 접근

이 조건은 비용과 생산량으로 교환할 수 없다.

② 허용범위 안에서 조정할 조건

• 납기지연
• 생산량
• 재고
• 에너지 비용
• 셋업시간
• 설비 가동률
• 작업자 연장근무
• 물류거리

이 조건은 조직이 정한 가중치와 허용범위 안에서 비교할 수 있다.

③ 사람이 결정해야 하는 조건

• 주요 고객의 납기변경
• 안전여유의 축소
• 검사수준의 완화
• 정비연기
• 대규모 재작업
• 외주생산 전환
• 승인되지 않은 원재료의 사용
• 생산중단과 출하보류

충돌조정에는 다음과 같은 방법을 사용할 수 있다.

규칙 기반 조정

사전에 정의된 우선순위와 제한조건을 적용한다.

점수 기반 조정

납기와 품질, 비용과 설비위험을 점수화해 대안을 비교한다.

시뮬레이션 기반 조정

Digital Twin에서 여러 대안의 결과를 시험한다.

협상 기반 조정

각 Agent가 요구조건과 양보 가능한 범위를 제시하고 공통 대안을 찾는다.

사람의 결정

허용범위를 벗어나거나 중요한 이해관계가 충돌하면 책임자가 선택한다.

충돌조정 결과에는 결론만 표시해서는 안 된다.

• 어떤 목표가 충돌했는가
• 어떤 조건을 우선했는가
• 제외된 대안은 무엇인가
• 예상되는 손실과 위험은 무엇인가
• 누가 최종 결정했는가

를 함께 기록해야 한다.

다중 Agent 시스템에서 가장 위험한 상태는 Agent들이 서로 다른 의견을 내는 것이 아니다.

충돌을 숨긴 채 하나의 확정된 답처럼 실행하는 것이다.

---

6. Agent의 계획은 어떻게 검증해야 하는가

Agent가 계획을 만들었다고 곧바로 실행해서는 안 된다.

계획에는 존재하지 않는 설비나 자재가 포함될 수 있다. 서로 양립할 수 없는 작업이 동시에 배정되거나 작업표준을 위반할 수도 있다.

따라서 계획과 실행 사이에 검증계층이 필요하다.

① 형식 검증

• 필수정보가 모두 있는가
• 설비와 제품 코드가 유효한가
• 시간과 단위가 올바른가
• 명령형식이 시스템 규격에 맞는가

② 자원 검증

• 설비가 실제로 사용 가능한가
• 자재와 공구가 준비돼 있는가
• 필요한 자격의 작업자가 있는가
• 물류와 저장공간이 확보됐는가

③ 순서 검증

• 선행작업이 완료됐는가
• 공정순서가 맞는가
• 동시에 수행할 수 없는 작업이 겹치지 않는가

④ 품질 검증

• 공정조건이 승인범위 안에 있는가
• 검사와 샘플링 계획이 포함됐는가
• 변경된 계획이 품질위험을 높이지 않는가

⑤ 설비 검증

• 설비의 운전한계를 넘지 않는가
• 정비와 교정상태가 유효한가
• 이상징후가 있는 설비를 사용하지 않는가

⑥ 안전 검증

• 안전인터록을 우회하지 않는가
• 위험작업의 허가가 있는가
• 작업자와 이동장비의 경로가 충돌하지 않는가
• 비상대응이 가능한가

⑦ 사업 검증

• 고객 납기와 계약조건을 위반하지 않는가
• 과도한 비용이 발생하지 않는가
• 기존 주문에 미치는 영향이 허용범위 안인가

⑧ 권한 검증

• 해당 Agent가 이 계획을 제안할 권한이 있는가
• 실행명령까지 전달할 수 있는가
• 사람의 승인이 필요한가

검증은 가능하면 생성과 분리해야 한다.

계획을 만든 Agent가 자신의 결과를 다시 승인하면 오류를 발견하지 못할 수 있다.

따라서 다음과 같은 구조가 필요하다.

계획 Agent

→ 계획 작성

검증 Agent 또는 규칙엔진

→ 제약조건 확인

Digital Twin

→ 예상결과 시험

담당자

→ 필요 시 승인

실행 Adapter

→ 허용된 명령으로 변환

현장시스템

→ 실행과 결과회신

Agent의 자연어 답변을 설비명령으로 직접 사용해서는 안 된다.

자연어로 생성된 계획을 검증 가능한 구조화 데이터와 허용된 명령으로 변환해야 한다.

---

7. Digital Twin은 Agent 협업에서 어떤 역할을 하는가

Agent가 제안한 계획은 논리적으로 타당해도 실제 공장에서는 예상과 다르게 작동할 수 있다.

설비의 미세한 속도차이와 작업자 동선, 물류대기와 품질변동이 계획에 반영되지 않을 수 있기 때문이다.

Digital Twin은 Agent가 현실을 변경하기 전에 결과를 시험하는 공간으로 사용할 수 있다.

① 생산계획 검증

• 계획별 생산량
• 예상 완료시간
• 병목공정
• 재공품 증가
• 납기지연

② 설비영향 검증

• 설비부하
• 고장위험
• 정비시점
• 공구와 금형의 사용량

③ 품질영향 검증

• 공정조건 변화
• 불량 가능성
• 검사대기
• 재작업량

④ 물류영향 검증

• 이동거리
• AGV·AMR 충돌
• 자재대기
• 창고혼잡

⑤ 에너지영향 검증

• 시간대별 전력
• 피크전력
• 설비별 에너지 원단위
• 생산계획별 비용

Agent는 Digital Twin의 결과를 이용해 계획을 수정할 수 있다.

초기계획 작성

↓

Digital Twin 실행

↓

병목과 위험 확인

↓

Agent 간 재협의

↓

수정계획 작성

↓

재시뮬레이션

↓

허용기준 충족

↓

승인과 실행

그러나 Digital Twin의 결과를 절대적인 정답으로 사용해서는 안 된다.

Twin에는 모델의 단순화와 가정, 보정오차가 존재한다.

따라서 다음을 함께 표시해야 한다.

• 실제설비와 동기화된 시각
• 모델의 유효범위
• 주요 가정
• 예상오차
• 보정이력
• 반영하지 못한 조건
• 결과의 신뢰수준

잘못된 Digital Twin은 Agent의 계획을 안전하게 만드는 것이 아니라 잘못된 확신을 줄 수 있다.

Agent의 실행을 Twin에서 먼저 시험하되, Twin 자체의 정확성과 적용한계도 지속해서 검증해야 한다.

---

8. Agent는 어떤 도구와 시스템에 접근할 수 있어야 하는가

Agent가 제조업무를 수행하려면 외부도구와 시스템을 호출해야 한다.

• 데이터베이스 조회
• MES 작업지시 확인
• QMS 검사결과 조회
• ERP 주문과 재고 확인
• WMS 이동작업 생성
• CMMS 정비작업 요청
• Digital Twin 시뮬레이션
• 보고서 작성
• 담당자에게 승인 요청
• 제한된 설비명령 전달

Model Context Protocol과 같은 개방형 프로토콜은 언어모델 기반 응용프로그램이 외부 데이터와 도구를 표준화된 방식으로 연결할 수 있도록 한다. MCP 도구는 데이터베이스 조회와 API 호출, 계산과 같은 외부 작업을 모델이 요청할 수 있게 한다.

그러나 도구를 연결할 수 있다는 사실과 연결해도 된다는 판단은 다르다.

각 도구에는 다음의 정책이 필요하다.

① 읽기와 쓰기 구분

조회권한과 변경권한을 분리한다.

② 대상범위 제한

전체 공장이 아니라 담당 설비와 제품에만 접근하도록 한다.

③ 작업별 권한

조회, 생성, 변경, 승인, 삭제 권한을 구분한다.

④ 조건부 실행

특정 시간과 상태, 승인조건을 만족할 때만 실행한다.

⑤ 사용량 제한

반복호출과 대량실행을 제한한다.

⑥ 자격증명 분리

모든 Agent가 하나의 관리자 계정을 공유하지 않도록 한다.

⑦ 결과검증

도구호출이 성공했다는 응답만 믿지 않고 실제 시스템 상태를 다시 확인한다.

⑧ 감사기록

누가 어떤 Agent를 통해 어떤 도구를 호출했는지 남긴다.

MCP의 공식 보안 지침도 민감한 데이터와 관리작업에 접근하거나 사용자별 감사가 필요한 경우 권한부여를 적용할 것을 권고하며, HTTP 기반 접근통제에는 표준화된 인증·인가 흐름을 사용한다.

생산계획 Agent가 계획을 조회하는 권한은 필요할 수 있다.

그러나 다음 권한까지 자동으로 필요한 것은 아니다.

• 확정된 계획의 삭제
• 품질판정 기준의 변경
• 안전한계의 수정
• PLC 프로그램 변경
• 사용자 계정 생성
• 로그 삭제

Agent에는 업무를 수행하는 데 필요한 최소한의 권한만 부여해야 한다.

Agent의 능력은 연결된 모델의 지능보다 사용할 수 있는 도구와 권한에 의해 더 크게 결정된다.

---

9. 다중 Agent 시스템에는 어떤 위험이 있는가

여러 Agent가 협업하면 복잡한 업무를 자동화할 수 있다.

그러나 Agent 수와 연결도구가 늘어날수록 새로운 위험도 증가한다.

① 잘못된 목표해석

생산량을 높이라는 목표를 품질과 안전보다 우선할 수 있다.

② 역할과 권한의 중첩

여러 Agent가 같은 작업을 수정하거나 서로의 결과를 덮어쓸 수 있다.

③ 순환호출

Agent A가 B를 호출하고 B가 다시 A를 호출하면서 작업이 끝나지 않을 수 있다.

④ 오류의 연쇄확산

한 Agent의 잘못된 결과를 다른 Agent들이 사실로 사용해 오류가 확대될 수 있다.

⑤ 정보의 불일치

Agent마다 다른 시점과 버전의 데이터를 사용할 수 있다.

⑥ 도구 오용

정상적인 도구를 잘못된 순서나 목적으로 사용할 수 있다.

⑦ 권한 확대

하위 Agent가 상위 Agent의 권한을 이용하거나 불필요한 시스템에 접근할 수 있다.

⑧ 간접 프롬프트 주입

문서와 데이터, 외부 메시지에 포함된 악의적 지시를 Agent가 정상적인 작업지시로 오인할 수 있다.

⑨ 메모리 오염

잘못되거나 조작된 내용을 장기기억에 저장해 이후 판단에 반복적으로 사용할 수 있다.

⑩ 책임의 분산

어떤 Agent의 판단이 최종결과를 만들었는지 확인하기 어려울 수 있다.

NIST는 AI Agent 시스템의 고유한 보안위험으로 간접 프롬프트 주입과 데이터 오염, 안전하지 않은 모델, 명세를 형식적으로만 만족시키는 행동, 정렬되지 않은 목표에 따른 실행 등을 제시하고 있다.

OWASP의 Agentic AI 보안자료도 Agent 행동 탈취, 도구 오용, 신원·권한 남용과 같은 위험을 주요하게 다룬다. 다중 Agent 환경에서는 Agent 간 신뢰관계와 메시지 전달경로가 추가적인 공격표면이 된다.

따라서 다음과 같은 보호조치가 필요하다.

• Agent별 고유한 신원
• 최소권한
• 입력데이터의 출처검증
• Agent 간 메시지의 무결성 확인
• 외부문서와 명령의 분리
• 중요도구의 사람 승인
• 호출횟수와 비용 제한
• 반복과 종료조건
• 독립된 정책검증
• 실행 전 시뮬레이션
• 실시간 이상행동 감시
• 즉시 권한회수와 격리

Agent의 실패는 틀린 문장 하나를 만드는 데서 끝나지 않는다.

잘못된 계획이 다른 Agent와 시스템을 거쳐 실제 제조실행으로 확대될 수 있다는 점이 가장 큰 위험이다.

---

10. Agent의 성능은 어떻게 평가해야 하는가

Agent의 성능을 답변의 정확도만으로 평가해서는 안 된다.

Agent는 여러 단계를 계획하고 도구를 호출하며 다른 Agent와 협업하기 때문이다.

① 목표달성 성능

• 요청한 목표를 달성했는가
• 완료조건을 충족했는가
• 부분적으로 완료된 작업은 무엇인가
• 불가능한 목표를 정확히 보고했는가

② 계획 성능

• 필요한 작업을 빠짐없이 분해했는가
• 작업의 순서가 적절한가
• 자원과 시간을 현실적으로 반영했는가
• 예외와 대안을 고려했는가

③ 도구사용 성능

• 올바른 도구를 선택했는가
• 입력값이 정확했는가
• 불필요한 호출은 없었는가
• 도구의 실패를 적절히 처리했는가
• 호출결과를 다시 확인했는가

④ 협업 성능

• 적절한 Agent에 업무를 요청했는가
• 중복작업이 발생하지 않았는가
• 충돌하는 결과를 식별했는가
• 공통 상황정보를 일관되게 사용했는가

⑤ 제조성과

• 납기준수율
• 생산량
• 불량률
• 재작업
• 설비정지
• 재고
• 에너지
• 작업시간
• 의사결정시간

⑥ 위험과 안전

• 금지된 행동의 시도
• 권한초과
• 안전조건 접근
• 잘못된 자동실행
• 작업자의 거부
• 롤백과 비상정지
• Near-miss

⑦ 운영성능

• 전체 처리시간
• Agent 간 통신지연
• 도구호출 실패율
• 반복횟수
• 처리비용
• 서비스 가용성
• 복구시간

⑧ 설명과 추적성

• 판단근거를 확인할 수 있는가
• 사용한 데이터와 도구를 추적할 수 있는가
• 최종결론이 만들어진 과정을 재현할 수 있는가

Agent 평가에는 정상적인 업무만 사용해서는 안 된다.

• 데이터 누락
• 설비고장
• 긴급주문
• 품질기준 변경
• 서로 충돌하는 지시
• 권한이 없는 요청
• 악의적인 외부문서
• 도구와 네트워크 장애
• Digital Twin과 실제설비의 불일치

와 같은 조건도 시험해야 한다.

좋은 Agent는 항상 답을 만들어내는 Agent가 아니다.

정보와 권한이 부족할 때 실행을 멈추고 사람에게 판단을 요청할 수 있는 Agent다.

---

11. Agent를 현장에 어떻게 단계적으로 배포해야 하는가

Agent가 시험환경에서 업무를 성공적으로 수행했다고 전체 공장에 바로 연결해서는 안 된다.

Agent는 운영환경에서 예상하지 못한 데이터와 예외, 사람과 시스템을 만나기 때문이다.

① 지식지원 단계

Agent가 문서와 데이터를 검색하고 설명한다.

시스템 변경권한은 없다.

② 분석지원 단계

현황을 분석하고 위험과 대안을 제시한다.

실행은 사람이 수행한다.

③ Shadow Agent 단계

실제 업무데이터로 계획을 작성하지만 현장에는 반영하지 않는다.

기존 계획과 작업자의 판단을 비교한다.

④ 승인형 실행 단계

Agent가 작업계획이나 시스템 변경을 준비하고 담당자가 승인하면 실행한다.

⑤ 제한적 자동실행 단계

특정 설비와 제품, 시간대에서만 자동으로 실행한다.

⑥ 다중 Agent 협업 단계

여러 전문 Agent가 계획과 품질, 설비와 물류를 함께 조정한다.

⑦ 자율운영 단계

검증된 조건에서 Agent가 계획·실행·확인·재계획을 반복한다.

사람은 정책과 예외, 중대한 위험을 감독한다.

단계별로 다음 조건을 확인해야 한다.

Agent의 적용범위는 성능이 확인될 때마다 조금씩 넓혀야 한다.

• 한 개 설비
• 한 개 제품
• 한 개 교대조
• 하나의 작업유형
• 제한된 생산조건
• 낮은 위험의 명령

부터 시작하는 것이 좋다.

성공한 사례 수뿐 아니라 실패와 거부, 중단과 복구가 제대로 작동했는지도 확인해야 한다.

Agent 배포의 목표는 자동화 비율을 빠르게 높이는 것이 아니다.

조직이 Agent의 행동을 이해하고 통제할 수 있는 범위 안에서 실행권한을 확대하는 것이다.

---

12. 운영 중 무엇을 지속해서 감시해야 하는가

다중 Agent 시스템은 각 Agent가 정상이라고 해서 전체가 정상인 것은 아니다.

개별 판단은 타당하지만 협업과정에서 충돌과 지연, 반복이 발생할 수 있다.

따라서 다음 계층을 함께 감시해야 한다.

① 목표와 작업

• 어떤 목표가 요청됐는가
• 누가 요청했는가
• 어떤 하위 작업으로 분해됐는가
• 완료와 실패조건은 무엇인가

② Agent 상태

• 실행 중인 Agent
• 사용한 모델과 버전
• 작업진행률
• 반복횟수
• 대기와 실패
• 중단된 이유

③ Agent 간 상호작용

• 어떤 Agent가 누구에게 무엇을 요청했는가
• 같은 작업이 중복되지 않았는가
• 충돌하는 결과가 있는가
• 응답이 지연되거나 누락되지 않았는가

④ 도구와 시스템

• 호출한 도구
• 사용한 계정과 권한
• 입력과 출력
• 성공과 실패
• 실제 시스템 변경결과

⑤ 제조상황

• 생산계획과 실적
• 설비상태
• 품질결과
• 자재와 물류
• 에너지
• 안전경보

⑥ 사람의 개입

• 승인과 거부
• 수정내용
• 수동전환
• Agent 중단
• 이의제기와 피드백

⑦ 위험지표

• 권한초과 시도
• 금지된 도구호출
• 반복실행
• 목표의 임의확장
• 설명할 수 없는 판단
• 안전조건 접근
• 결과의 불일치
• 비정상적인 비용과 처리시간

모니터링 화면에는 전체 흐름이 보여야 한다.

요청된 목표

→ 참여한 Agent

→ 사용한 데이터와 도구

→ Agent별 판단

→ 발생한 충돌

→ 선택한 대안

→ 사람의 승인

→ 실제 실행

→ 제조결과

각 지표에는 다음이 정의돼야 한다.

• 정상범위
• 경고기준
• 자동중단 기준
• 담당자
• 대응시간
• 복구방법
• 재개조건

Agent가 정해진 업무를 완료했는지만 확인해서는 부족하다.

어떤 과정과 권한을 이용해 완료했으며 그 결과가 실제 제조성과와 안전에 어떤 영향을 주었는지 확인해야 한다.

---

13. 경영진은 Agent 도입 전에 무엇을 확인해야 하는가

Agent 기반 자율제조를 보고받을 때 경영진은 Agent의 수와 시연화면, 자동화율에 관심을 갖기 쉽다.

그러나 실제 운영을 위해서는 다른 질문이 필요하다.

첫째, Agent를 사용해야 하는 제조문제가 명확한가.

일반적인 자동화와 규칙기반 시스템으로 해결할 수 있는 문제에 복잡한 Agent를 적용할 필요는 없다.

둘째, 각 Agent의 역할과 소유부서가 정해져 있는가.

생산과 품질, 설비와 물류의 책임을 Agent라는 이름 아래 섞어서는 안 된다.

셋째, Agent가 공유하는 제조상황이 일관되고 최신인가.

서로 다른 데이터와 코드, 시간을 사용하면 협업할 수 없다.

넷째, 안전과 품질, 납기와 비용이 충돌할 때 적용할 우선순위가 있는가.

목표의 충돌을 Agent가 임의로 해결하게 해서는 안 된다.

다섯째, Agent가 사용할 수 있는 데이터와 도구, 실행권한이 제한돼 있는가.

모든 Agent에 관리자 권한을 주는 방식은 운영할 수 없다.

여섯째, Agent가 만든 계획을 독립적으로 검증하는가.

규칙과 제약조건, Digital Twin과 사람의 검토가 필요하다.

일곱째, 자연어 응답과 실제 설비명령 사이에 통제계층이 있는가.

Agent의 문장이 곧바로 PLC와 로봇의 명령이 되어서는 안 된다.

여덟째, Agent 간 충돌과 오류의 연쇄확산을 감지할 수 있는가.

개별 Agent뿐 아니라 전체 협업흐름을 감시해야 한다.

아홉째, 모든 판단과 도구호출, 승인과 실행을 추적할 수 있는가.

문제가 발생했을 때 원인을 재현할 수 있어야 한다.

열째, Agent와 외부도구를 즉시 격리하고 권한을 회수할 수 있는가.

중단과 복구는 운영을 시작하기 전에 시험해야 한다.

열한째, Agent의 성과를 제조 KPI로 측정하고 있는가.

응답의 자연스러움보다 불량과 납기, 정지시간과 비용의 개선을 확인해야 한다.

열두째, Agent가 실패했을 때 기존 업무로 돌아갈 수 있는가.

작업자가 Agent 없이도 핵심 공정을 운영할 수 있어야 한다.

Agent 도입의 타당성은 시연의 화려함으로 판단할 수 없다.

현장의 데이터를 정확하게 이해하고 제한된 권한으로 검증 가능한 행동을 수행하며, 실패했을 때 안전하게 멈출 수 있는가를 확인해야 한다.

---

마치며

제조 AI Agent는 기존 시스템 위에 대화창 하나를 추가하는 기술이 아니다.

생산과 품질, 설비와 물류의 데이터를 이해하고 여러 전문모델과 업무시스템을 연결해 실제 작업을 수행하는 새로운 실행구조다.

Agent는 사람보다 빠르게 많은 정보를 분석할 수 있다.

여러 대안을 만들고 Digital Twin에서 결과를 시험하며 변화된 상황에 맞춰 계획을 다시 만들 수도 있다.

하지만 Agent의 판단과 실행이 연결될수록 작은 오류의 영향도 커진다.

잘못된 데이터 하나가 잘못된 계획으로 이어지고, 그 계획이 다른 Agent에 전달되어 실제 설비와 생산에 반영될 수 있다.

따라서 제조 AI Agent는 다음의 흐름으로 설계하고 운영해야 한다.

해결할 제조문제와 목표를 정의한다.

생산·품질·설비·물류 등 Agent의 역할을 구분한다.

공통된 제조상황과 의미체계를 구축한다.

전체 목표를 검증 가능한 하위 작업으로 분해한다.

Agent별 데이터와 도구, 실행권한을 제한한다.

안전·품질·납기·원가의 우선순위를 정한다.

Agent들의 판단이 충돌하면 근거와 영향을 비교한다.

계획을 규칙과 제약조건으로 독립 검증한다.

Digital Twin에서 실행결과를 먼저 시험한다.

필요한 경우 사람이 승인한다.

자연어 계획을 허용된 제어명령으로 변환한다.

실행결과를 확인하고 예상과 다르면 중단한다.

모든 판단과 협업, 도구호출과 결과를 기록한다.

문제가 발생하면 Agent를 격리하고 기존 업무로 복구한다.

이 흐름이 연결될 때 Agent는 단순한 대화형 도구에서 제조운영의 구성요소로 발전할 수 있다.

중요한 것은 Agent가 스스로 많은 일을 하게 만드는 것이 아니다.

각 Agent가 맡은 역할을 정확히 수행하고, 다른 Agent와의 경계를 지키며, 조직이 정한 조건 안에서만 행동하도록 만드는 것이다.

여러 Agent가 협업한다고 책임까지 분산돼서는 안 된다.

목표를 정하고 권한을 부여하며 결과를 승인하는 책임은 여전히 조직과 사람에게 있다.

Agent의 자율성은 통제의 부재가 아니다.

명확한 목표와 역할, 제한조건과 검증, 중단과 복구가 준비된 상태에서 허용되는 제한된 자율성이다.

바로 이것이 제조 AI Agent가 실제 현장에서 협업하고 실행하기 위해 필요한 기본구조이며, 개별 AI 활용을 자율제조 운영체계로 발전시키는 다음 단계다.

다음 글에서는 Digital Twin이 단순한 3D 시각화와 모니터링 도구를 넘어 AI Agent의 판단을 시험하고 미래의 제조상황을 예측하는 운영환경으로 발전하는 과정을 살펴보고자 한다.

현실의 공장과 가상공장은 어떻게 동기화해야 하며, 시뮬레이션 결과를 실제 의사결정에 사용하려면 무엇을 검증해야 할까.

[자율제조 시리즈 ⑬] Digital Twin은 AI Agent의 판단을 어떻게 검증하는가?

---

참고자료

• NIST — AI Agent Standards Initiative
• NIST — Securing AI Agent Systems RFI
• NIST — Artificial Intelligence Risk Management Framework
• NIST — Trustworthy AI in Critical Infrastructure Profile Concept Note
• NIST NCCoE — Software and AI Agent Identity and Authorization
• ISO — ISO/IEC 42001:2023, AI Management Systems
• ISO — Artificial Intelligence Standards
• OWASP — Agentic AI: Threats and Mitigations
• OWASP — Top 10 for Agentic Applications 2026
• OWASP — Multi-Agentic System Threat Modeling Guide
• OWASP — Securing Agentic Applications Guide 1.0
• Model Context Protocol — Specification
• Model Context Protocol — Tools
• Model Context Protocol — Authorization
• Model Context Protocol — Security Best Practices