Chapter 10

코파일럿에서 에이전트로

대화창에 질문하고 답을 복사해 붙이던 단계에서, AI가 직접 시스템을 조회하고 초안을 만들고 승인을 요청하는 단계로 넘어가고 있다. 그만큼 할 수 있는 일이 늘지만 틀릴 수 있는 지점도 늘어난다. 이 장에서는 에이전트가 어떻게 움직이는지, 어디에 사람의 승인 지점을 두어야 하는지, 여러 단계에서 작은 오류가 어떻게 쌓이는지를 제조 현장의 장면으로 살펴본다.

LLM은 무엇을 하는가: 컨텍스트가 전부다

대규모 언어 모델(LLM, Large Language Model)은 주어진 글 다음에 올 토큰(단어 조각)을 확률적으로 예측하는 모델이다. 엄청난 양의 텍스트로 학습해 문법·상식·전문 지식의 패턴을 익혔기 때문에 요약, 번역, 초안 작성, 분류, 추론을 꽤 잘한다. 실무자에게 중요한 사실은 세 가지다.

  1. 모델은 우리 회사를 모른다. 어제 발생한 클레임, 우리 라인의 설비 코드, 사내 8D 양식은 학습 데이터에 없다. 이런 정보는 매번 컨텍스트(context, 모델에 입력으로 넣는 글)에 넣어 줘야 한다. 6장의 RAG가 바로 그 역할을 한다.
  2. 모델은 그럴듯하게 틀린다. 근거가 없을 때도 유창한 문장을 만들어 낸다(환각, hallucination). 그래서 출처 표시와 검증 단계가 필요하다.
  3. 같은 모델도 입력에 따라 결과가 크게 달라진다. 무엇을, 어떤 순서로, 어떤 형식으로 넣느냐가 성능을 좌우한다.
컨텍스트 창 (한 번의 호출에 들어가는 입력 전체) 시스템 지시: 역할 · 규칙 · 출력 형식 사용자 요청: "CVD-03 알람 원인 정리" 검색된 문서: 매뉴얼 4.3절, 정비 이력 도구 결과: 센서 트렌드, WIP 현황 대화·작업 이력 (이전 단계) LLM 답변 또는 도구 호출 모델 가중치는 바뀌지 않는다
그림 10-1. 한 번의 모델 호출에 들어가는 컨텍스트. 사내 지식은 모델 안이 아니라 컨텍스트로 들어간다. 초록 칸(검색 문서·도구 결과)을 무엇으로 채우느냐가 사내 AI의 품질을 결정한다.

프롬프트(prompt)는 이 컨텍스트 중 사람이 설계하는 부분이다. 좋은 업무용 프롬프트는 역할("당신은 B사 품질보증팀의 8D 작성 보조자다"), 규칙("근거 문서에 없는 수치는 쓰지 말고 '확인 필요'로 표시"), 출력 형식(사내 8D 양식의 항목과 순서), 예시(잘 쓴 D2 문단 하나)를 담는다. 이는 3장의 표준 산출물 템플릿과 같은 이야기다. 양식이 표준화되어 있지 않으면 프롬프트도 표준화할 수 없다.

챗봇·코파일럿·워크플로·에이전트

"에이전트"라는 말이 넓게 쓰이면서 같은 단어로 전혀 다른 것을 가리키는 일이 많다. 이 책에서는 누가 다음 행동을 결정하는가를 기준으로 네 가지를 구분한다.

형태다음 행동을 정하는 주체제조 현장의 예장점주의점
챗봇사람(매 질문)사내 규정·규격 질의 응답도입 쉬움, 위험 낮음복사·붙여넣기가 남음
코파일럿사람(작업 안에서 제안을 수락)8D 양식 안에서 문단 제안, 메일 회신 초안기존 도구 안에서 작동제안을 그대로 수락하는 습관
워크플로사람이 미리 설계한 경로견적 메일 수신 → 추출 → 비교표 → 검토 요청예측 가능, 테스트 쉬움예외 경로를 미리 정의해야 함
에이전트모델이 상황을 보고 동적으로알람 원인 조사: 어떤 데이터를 볼지 스스로 선택예상 못 한 상황에 유연경로·비용·오류가 가변적

여기서 실무적으로 중요한 구분이 워크플로 vs 에이전트다. 워크플로는 단계가 고정되어 있고 각 단계 안에서만 LLM이 일한다. 에이전트는 목표만 받고, 어떤 도구를 어떤 순서로 몇 번 쓸지 모델이 결정한다. 에이전트가 더 "똑똑해" 보이지만 제조 업무 대부분은 절차가 정해져 있으므로 워크플로로 시작하고, 정말 경로를 예측할 수 없는 부분(원인 조사, 탐색)에만 에이전트형 자율성을 준다는 것이 이 책의 권고다.

"에이전트 도입"이 아니라 "어느 단계에 자율성을 줄 것인가"

현장에서 쓸 만한 시스템은 대개 혼합형이다. 설비 알람 대응을 예로 들면, 알람 수신·이슈 카드 생성·인계 메모 작성은 워크플로로, 원인 조사 부분만 에이전트로, 설비에 영향을 주는 조치는 사람 승인으로 묶는다.

도구 사용과 표준 연결(MCP)

LLM 자체는 글만 만든다. MES를 조회하거나 작업지시를 생성하려면 도구 사용(tool use, function calling)이 필요하다. 원리는 단순하다. 개발자가 쓸 수 있는 도구의 이름·설명·입력 형식을 컨텍스트에 알려 주면, 모델은 답변 대신 "이 도구를 이 인자로 불러 달라"는 구조화된 요청을 출력한다. 실제 실행은 모델이 아니라 그 바깥의 애플리케이션이 하고, 결과를 다시 컨텍스트에 넣어 모델이 다음 행동을 정한다.

모델 출력 (도구 호출 요청) → 애플리케이션이 실행 → 결과를 컨텍스트에 추가
search_maintenance_log(equipment_id="CVD-03", keyword="배기", days=180)
→ [{"date": "47일 전", "symptom": "챔버 압력 상승", "action": "배기 라인 파우더 세정", "wo": "WO-예시-0412"}]
query_sensor_trend(equipment_id="CVD-03", tags=["chamber_pressure"], hours=24)
→ {"trend": "6시간 동안 단조 증가", "last": "상한의 104%"}

문제는 연결의 수다. 사내에 MES, ERP, PLM, QMS, CMMS, 문서 저장소가 있고, AI 애플리케이션도 여러 개라면 각각을 일일이 연결하는 코드가 늘어난다. 4장에서 본 점대점 매핑 문제와 같은 구조다. 이를 줄이기 위해 등장한 것이 MCP(Model Context Protocol) 같은 표준이다. MCP는 AI 애플리케이션을 외부 도구·데이터 원천에 연결하는 방식을 규정한 개방형 표준으로, 2024년 말 공개된 뒤 여러 AI 도구와 플랫폼이 지원하고 있다. 데이터·도구를 제공하는 쪽이 MCP 서버로 도구(tools)·리소스(resources)·프롬프트 템플릿(prompts)을 노출하면, MCP 클라이언트(AI 애플리케이션)가 이를 발견하고 호출한다. 한 번 만든 "CMMS용 MCP 서버"를 여러 AI 애플리케이션이 재사용할 수 있다는 점이 핵심이다. 에이전트끼리 작업을 주고받는 방식을 표준화하려는 프로토콜들도 논의되고 있다.

① 계획 ② 도구 호출 ③ 관찰(결과) ④ 판단 ⑤ 승인 요청 에이전트 루프 목표까지 반복 표준 연결 MES · WIP CMMS · 정비 이력 센서 이력 DB 문서 검색(RAG) PLM · BOM 쓰기: 작업지시 읽기 먼저 · 쓰기는 승인 후
그림 10-2. 에이전트 루프. 모델은 계획 → 도구 호출 → 관찰 → 판단을 반복하고, 쓰기 작업 앞에서는 사람에게 승인을 요청한다. 표준 연결(예: MCP)은 사내 시스템을 도구로 노출하는 방식을 통일해 연결 비용을 줄인다.
표준 연결은 권한 문제를 대신 풀어 주지 않는다

연결이 쉬워진다는 것은 위험한 연결도 쉬워진다는 뜻이다. MES 쓰기 권한을 가진 도구를 노출하면 모델이 잘못 판단했을 때 실제로 LOT가 홀드되거나 레시피가 바뀔 수 있다. 도구별로 읽기/쓰기를 나누고, 호출자(사용자)의 권한을 그대로 따르게 하고, 모든 호출을 로그로 남겨야 한다. 문서 안에 숨겨진 지시문으로 모델을 조종하는 프롬프트 주입(prompt injection)도 도구 권한과 결합하면 실제 피해가 된다(12장).

자율성 단계와 사람의 승인 지점

자율주행의 자동화 단계 구분(SAE J3016)처럼, 업무 AI에도 자율성의 단계를 나눠 두면 "어디까지 맡길까"를 구체적으로 토론할 수 있다. 아래는 이 책에서 쓰는 구분이다(표준 규격이 아니라 설명용 구분이다).

  1. L0 수동사람이 모든 작업을 한다. AI는 쓰이지 않는다.
  2. L1 제안AI가 검색 결과·문장을 제안하고, 사람이 직접 작성한다(코파일럿).
  3. L2 초안 + 사람 승인AI가 산출물 초안이나 실행 계획을 만들고, 사람이 검토·수정해 승인해야 반영된다. human-in-the-loop
  4. L3 조건부 실행정해진 범위·조건 안에서 AI가 실행하고, 사람은 모니터링하다 예외에 개입한다. human-on-the-loop
  5. L4 범위 내 자율정의된 업무 범위 안에서 AI가 끝까지 수행하고, 사람은 로그를 주기적으로 사후 감사한다.

human-in-the-loop(HITL)은 사람이 매 건 승인해야 진행되는 구조이고, human-on-the-loop(HOTL)은 시스템이 진행하되 사람이 감시하며 멈출 수 있는 구조다. 같은 업무 안에서도 단계마다 적절한 수준이 다르다. 8D를 예로 들면 이슈 카드 생성은 L4도 괜찮지만, 근본원인 확정(D4)은 데이터가 아무리 좋아도 L1~L2를 넘기 어렵다. 원인을 "확정"하는 행위는 책임과 고객 신뢰가 걸린 판단이기 때문이다.

INTERACTIVE

자율성 단계 슬라이더 — 8D 업무에서 AI와 사람의 역할

단계별 상한은 "그 단계의 판단에 걸린 책임과 오류 비용"을 반영한 예시 기준이다. 상한을 끄면 모든 단계가 목표 단계로 올라간다.

AI가 실행까지—
사람 승인 지점—
상한에 걸린 단계—
예상 리드타임—
리드타임은 레거시(L0) 기준 각 단계 소요 시간에 단계별 계수(L1 0.85, L2 0.6, L3 0.35, L4 0.25)를 곱한 예시 모델이다. 해볼 것: 상한을 끄고 L4로 올리면 리드타임은 줄지만, D4 근본원인과 D5 대책을 AI가 단독으로 확정하게 된다. 그 대가를 누가 지는지 생각해 보자.

다단계 오류 누적: pn의 함정

데모에서 한 단계 작업의 정확도가 95%라면 꽤 좋아 보인다. 하지만 에이전트는 여러 단계를 이어서 수행한다. 각 단계가 독립적으로 확률 \(p\)로 성공한다고 하면, \(n\)단계 작업이 끝까지 맞을 확률은 다음과 같다.

$$ P_{\text{성공}} = p^{\,n} \qquad \text{예: } 0.95^{10} \approx 0.60, \quad 0.99^{10} \approx 0.90, \quad 0.95^{20} \approx 0.36 $$
단계별 정확도가 95%여도 10단계를 거치면 열 번 중 네 번은 어딘가 틀린다. 단계가 길수록 단계별 정확도의 작은 차이가 크게 벌어진다.

해법은 두 가지다. 하나는 단계 수를 줄이는 것(업무를 좁게 정의), 다른 하나는 중간에 검증 체크포인트를 넣는 것이다. \(n\)단계를 \(k\)개의 구간으로 나누고 각 구간 끝에서 오류를 검출률 \(d\)로 잡아 바로잡는다고 하면(사람의 검토, 규칙 검사, 원본 대조 등), 구간 \(j\)의 길이를 \(m_j\)라 할 때 전체 성공률은 다음과 같다.

$$ P_{\text{성공}} = \prod_{j=1}^{k} \Big[\, q_j + (1-q_j)\,d \,\Big], \qquad q_j = p^{\,m_j}, \quad \sum_j m_j = n $$
예: \(n=10,\ p=0.95\), 체크포인트 2개(5단계마다), \(d=0.9\)이면 \(q = 0.95^5 \approx 0.774\), 구간 성공률 \(0.774 + 0.226 \times 0.9 \approx 0.977\), 전체 \(0.977^2 \approx 0.955\). 검증 없이 60%이던 것이 95% 수준으로 오른다. 검출된 오류는 바로잡힌다고 단순화한 모델이다.
INTERACTIVE

오류 누적 계산기 — 단계 수, 정확도, 체크포인트

검증 없음 pⁿ—
체크포인트 포함—
100건 중 오류 도달—
pⁿ ≥ 90%가 되려면 p—
곡선은 단계 수에 따른 최종 성공률(가로축 n). 점선은 검증 없음, 실선은 같은 k개의 체크포인트를 균등 배치한 경우다. 해볼 것: p를 99%로 올리는 것(모델 개선)과 체크포인트를 2개 넣는 것(프로세스 개선) 중 어느 쪽이 더 싼지 비교해 보자. 체크포인트마다 사람 시간이 든다는 점도 잊지 말자.
현실의 오류는 독립적이지 않다

\(p^n\)은 단계별 오류가 서로 독립이라는 가정 위에 있다. 실제로는 앞 단계의 오류가 뒤 단계로 전파되어 더 큰 오류를 만들기도 하고(잘못 조회한 LOT 번호로 이후 모든 분석이 어긋남), 반대로 뒤 단계에서 앞의 이상을 알아채기도 한다. 그래서 체크포인트는 오류가 전파되기 쉬운 지점 바로 뒤(식별자 조회, 수치 추출 직후)에 두는 것이 효과적이다.

제조 시나리오 네 가지

다음 네 시나리오는 가상 회사들의 예다. 각 시나리오에서 무엇을 자동화하고 어디서 멈추는지를 보자.

시나리오트리거주요 도구AI가 하는 일사람의 승인 지점평가 지표
8D 보고서 초안고객 클레임 메일 접수QMS 8D 이력, LOT 추적, 검사 DB클레임 요약, 유사 8D 검색, D2·D3 초안, 봉쇄 범위 계산봉쇄 실행, D4 원인 확정, 고객 송부초안 수정량, D3 기한 준수율
설비 알람 트리아지설비 알람 발생알람 로그, 센서 이력, CMMS, 매뉴얼중복·잡음 알람 묶기, 우선순위 판정, 원인 후보와 근거 제시LOT 홀드, 작업지시 생성우선순위 일치율, 대응 착수 시간
구매 견적 비교협력사 견적 회신 수신메일·첨부 파서, 품목 마스터, 단가 이력단가·납기·MOQ·조건 추출, 단위·통화 정규화, 비교표와 이상치 표시협력사 선정, 품의 상신추출 정확도, 비교표 작성 시간
ECN 영향 분석설계 변경 요청 등록PLM BOM, 라우팅, 검사 기준서, 고객 승인 이력영향 받는 상위 조립품·공정·문서·고객 목록 작성영향 범위 확정, 고객 변경 승인 신청누락된 영향 항목 수(재현율)

구매 견적 비교: 정규화가 절반이다

가상의 C사(정밀화학) 구매팀은 협력사 다섯 곳에서 견적을 받는다. 한 곳은 엑셀, 한 곳은 PDF, 한 곳은 메일 본문에 "kg당 USD, FOB 기준", 다른 곳은 "톤당 원화, 착지 인도"로 보낸다. 사람이 비교표를 만들 때 시간 대부분은 단위·통화·인도 조건을 맞추는 데 쓴다. 이 작업은 LLM의 추출 능력과 규칙 기반 환산(환율, 단위 변환)을 섞은 워크플로가 잘한다. 다만 "가장 싼 곳"을 고르는 것과 "가장 좋은 협력사"를 고르는 것은 다르므로, 품질 이력·공급 리스크 판단과 선정은 사람이 한다. 비교표에는 반드시 원본 문서의 위치를 링크해, 검토자가 숫자를 원본과 대조할 수 있게 한다.

ECN 영향 분석: 그래프가 있어야 에이전트가 걷는다

설계 변경의 영향 분석은 "이 부품을 쓰는 상위 조립품은? 그 조립품의 공정 라우팅은? 그 공정의 검사 기준서와 관리계획서는? 고객 변경 승인이 필요한 품목은?"을 따라가는 탐색이다. 에이전트가 이 탐색을 하려면 BOM·라우팅·문서·고객 승인 이력이 서로 연결되어 있어야 한다. 연결이 메일과 엑셀에만 있다면 에이전트도 길을 잃는다. 4장의 온톨로지와 6장의 지식 그래프가 여기서 실제 가치로 바뀐다.

ECN-예시 부품 P-1102 재질 변경 조립품 A-20 조립품 A-35 공정: 용접 OP30 검사 기준서 개정 관리계획서 개정 고객 변경 승인 필요 변경 사용처 사용처 화살표 하나 = 도구 호출 한 번 (BOM 역전개 · 라우팅 · 문서 조회)
그림 10-3. ECN 영향 분석은 연결된 데이터 위의 탐색이다. 각 엣지는 에이전트의 도구 호출 하나에 해당하고, 마지막 노드(고객 변경 승인)는 반드시 사람이 확정한다. 연결이 끊긴 곳(메일로만 관리되는 고객 승인 이력 등)에서 누락이 생긴다.

설비 알람 트리아지: 한 번 따라가 보기

가상의 A사 반도체 후공정 라인에서 새벽 2시에 CVD 설비 알람이 울렸다. 아래 트레이스는 알람 트리아지 에이전트가 무엇을 생각하고, 어떤 도구를 부르고, 어디서 사람에게 넘기는지를 단계별로 보여 준다.

INTERACTIVE

에이전트 실행 트레이스 재생 — 새벽 2시의 설비 알람

색 구분: 이벤트·승인, 생각, 도구 호출, 결과, 산출물. 승인 요청에서는 직접 승인 또는 반려를 골라야 진행된다.

진행—
도구 호출 (읽기/쓰기)—
가상 경과 시간—
상태—
모든 도구 이름·코드·수치는 가상이다. 관찰할 것: 읽기 도구는 에이전트가 스스로 부르지만, LOT 홀드와 작업지시 같은 쓰기 도구는 승인 뒤에만 호출된다. 반려를 고르면 에이전트가 반려 사유를 기록하고 사람에게 넘긴다. 이것이 감사 가능한 에이전트의 최소 조건이다.

에이전트 설계 원칙과 평가

파일럿에서 잘 돌던 에이전트가 운영에서 문제를 일으키는 이유는 대개 비슷하다. 범위가 넓고, 권한이 크고, 무엇을 했는지 기록이 없고, 좋아졌는지 나빠졌는지 잴 방법이 없다. 이를 뒤집은 것이 설계 원칙이다.

흔한 첫 시도

  • "품질 업무 전체를 돕는 에이전트"
  • 개발 편의를 위해 관리자 계정으로 시스템 연결
  • 결과만 저장, 중간 도구 호출은 기록 없음
  • 데모 질문 몇 개로 "잘 된다" 판단
  • 실패하면 모델 탓, 프롬프트만 계속 수정

운영 가능한 설계

  • "클레임 접수 → D3 초안"처럼 좁고 끝이 분명한 범위
  • 사용자 권한 그대로, 읽기 도구부터, 쓰기는 승인 뒤
  • 모든 생각·도구 호출·결과·승인을 감사 로그로 저장
  • 과거 실제 사례로 만든 평가 세트로 변경마다 회귀 시험
  • 실패 사례를 분류해 데이터·도구·프롬프트·프로세스 중 원인 수정

평가는 최종 결과와 과정을 함께 본다. 최종 답이 맞아도 엉뚱한 근거에서 나왔다면 다음에는 틀린다.

평가 대상지표측정 방법
최종 결과작업 성공률(정답과 일치), 사람 수정량평가 세트 정답 대조, 수정 전후 비교
과정올바른 도구 선택률, 불필요한 호출 수, 단계별 정확도트레이스 검토, 단계별 정답 라벨
근거성주장마다 출처가 있는 비율, 출처와 내용 일치율표본 검토(사람) 또는 별도 평가 모델 + 표본 검증
안전승인 없이 쓰기 시도 0건, 권한 밖 데이터 접근 0건감사 로그 자동 점검
운영응답 시간, 건당 비용, 승인 반려율 추이모니터링 대시보드
승인 반려율은 최고의 학습 데이터다

사람이 반려한 제안과 반려 사유를 모으면, 에이전트가 무엇을 모르는지가 드러난다. 반려율이 계속 낮게 유지되는 단계는 자율성 단계를 한 칸 올릴 후보이고, 반려율이 높은 단계는 데이터나 도구부터 다시 봐야 한다. 자율성은 선언이 아니라 이렇게 데이터로 획득하는 것이다.

핵심 정리

  1. LLM은 우리 회사를 모른다. 사내 지식은 컨텍스트(검색 문서·도구 결과)로 넣어 주며, 그 품질이 사내 AI의 품질을 결정한다.
  2. 챗봇·코파일럿·워크플로·에이전트는 "누가 다음 행동을 정하는가"로 구분한다. 제조 업무는 워크플로로 시작하고 탐색이 필요한 구간에만 에이전트형 자율성을 준다.
  3. 도구 사용은 모델이 호출을 요청하고 애플리케이션이 실행하는 구조다. MCP 같은 개방형 표준은 연결 비용을 줄이지만 권한·감사 문제는 따로 설계해야 한다.
  4. 자율성은 업무 단계별로 정한다. 책임이 걸린 판단(원인 확정, 고객 송부, 설비 조치)에는 사람의 승인 지점을 둔다.
  5. \(n\)단계 작업의 성공률은 \(p^n\)으로 빠르게 떨어진다. 범위를 좁히고, 오류가 전파되기 쉬운 지점 뒤에 검증 체크포인트를 둔다.
  6. 좁은 범위, 최소 권한, 감사 로그, 실제 사례 기반 평가 세트, 반려율 추적이 운영 가능한 에이전트의 조건이다.

확인 퀴즈

Q1. 사내 LLM이 어제 접수된 클레임 내용을 정확히 요약하려면 무엇이 필요한가?

모델 가중치에는 어제의 사내 정보가 없다. 검색(RAG)이나 도구 호출로 컨텍스트에 넣어 주는 것이 기본 방법이다.

Q2. 워크플로와 에이전트의 가장 본질적인 차이는?

둘 다 LLM을 쓸 수 있다. 차이는 다음 행동을 누가 정하느냐다. 에이전트에도 승인 지점은 필요하다.

Q3. MCP(Model Context Protocol)에 대한 설명으로 가장 적절한 것은?

MCP는 도구·리소스를 서버로 노출하고 AI 애플리케이션이 클라이언트로 호출하는 방식의 표준이다. 권한 설계는 여전히 별도로 해야 한다. 설비 통신은 OPC UA 같은 다른 표준의 영역이다.

Q4. 단계별 정확도 0.9인 작업 5단계를 검증 없이 수행할 때 최종 성공률에 가장 가까운 것은?

\(0.9^5 \approx 0.590\). 단계가 늘수록 성공률이 기하급수적으로 떨어진다.

Q5. 8D 업무에서 상한을 L1~L2로 낮게 두는 것이 가장 적절한 단계는?

근본원인 확정은 책임과 고객 신뢰가 걸린 판단이다. AI는 가설과 근거를 제시하고 사람이 확정한다.

Q6. 운영 중인 에이전트의 특정 단계에서 승인 반려율이 몇 달째 매우 낮게 유지된다. 합리적인 다음 행동은?

낮은 반려율은 자율성 확대의 근거가 될 수 있다. 다만 검토가 형식적으로 변한 것은 아닌지 표본 점검도 함께 하는 것이 좋다.