Chapter 2. 무엇을 만들까?

 

공정 엔지니어가 현장에서 다루는 데이터는 크게 두 가지입니다. MES에서 집계된 집계 데이터와 설비가 직접 생성하는 설비 Log 데이터. 이 두 가지를 어떻게 활용할 수 있는지, 그리고 이 강의에서 무엇을 언제 만들어볼 것인지를 이번 챕터에서 정리하겠습니다.

 

---

 

2-1. OEE (Overall Equipment Effectiveness, 설비종합효율)

집계 데이터로 산출하는 지표 중 가장 대표적이고 포괄적인 것이 바로 OEE입니다. 간혹 직행률을 OEE와 동일시하는 경우가 있는데, 직행률은 투입 대비 양품 비율로 시간 개념이 없기 때문에 별개의 지표로 봐야 합니다. 직행률 저하의 영향은 OEE의 시간가동률 항목에 흡수되어 계산됩니다.

OEE는 다음 세 가지 요소의 곱으로 계산됩니다.

 

OEE = 시간가동률 × 성능가동률 × 양품률

 

시간가동률 : '주어진 시간에 얼마나 많은 제품을 생산했는가'를 의미합니다. 일반적으로 (생산수 × 이론 C/T) ÷ 배치시간으로 계산합니다. 배치시간이란 근무시간에서 식사, 체조와 같이 사전에 약속된 제외시간을 뺀 실제 조업시간입니다. 여기서 중요한 점은 C/T를 반드시 이론값으로 사용해야 한다는 것입니다. 실측 C/T의 변화는 성능가동률에서 반영하기 때문입니다.

 

성능가동률 : '설계된 이론 C/T 기준으로 실제 어느 속도로 생산했는가'를 의미합니다. 이론 C/T ÷ 실측 C/T로 계산하며, 설비 노후화나 조건 변경 등에 의한 C/T 저하가 이 항목에 반영됩니다. 개인적으로는 실시간 C/T 계측 및 반영을 통해 가능하면 성능가동률을 100%로 유지하기를 권장합니다. 변수가 많아지면 시간가동률의 비가동 요인을 추정하기가 극도로 어려워지기 때문입니다.

 

양품률 : '투입수 대비 양품이 몇 개 생산됐는가'를 의미합니다. 비교적 단순한 개념이지만, 재작업품을 양품으로 볼 것인지에 대한 기준을 사전에 명확히 정의해두는 것이 중요합니다.

 

이렇게만 보면 간단해 보입니다. 그런데 실제 현장에서 정확하게 산출하려면 이야기가 달라집니다. 예를 들어, 컨베이어로 연결된 6개 공정이 있을 때 한 공정에서 발생한 비가동이 전체 OEE에 주는 영향을 계산한다고 가정해봅시다. 공정별 버퍼 수량, 비가동 발생 시점의 각 공정별 버퍼 재고, 병목 공정 여부, LOB(Line of Balance), 비가동 시간과 제외시간의 겹침 여부 등 무수한 요소를 고려해야 정확한 산출이 가능합니다. 이를 수기로 계산하는 것은 사실상 불가능하기 때문에, 지금까지는 어쩔 수 없이 시간 단위로 뭉뚱그려 계산해왔습니다.

 

이제는 다릅니다. Claude Code로 이 모든 변수를 반영한 계산 로직을 구현하고, 비가동 요인별 OEE 영향도를 자동으로 시각화할 수 있습니다. 성능가동률과 양품률도 마찬가지입니다. 지금까지의 방식이 최선이었을 뿐, 최고의 방식은 아니었습니다. Chapter 3에서 OEE 자동 산출, 추이 분석, 시각화 대시보드를 직접 만들어보겠습니다.

 

---

 

 

2-2. 공정 데이터와 통계적 분석

설비 Log 데이터는 집계 데이터보다 훨씬 풍부하고, 활용 가치도 높습니다. 그만큼 다루기도 어렵습니다.

설비 Log에는 일반적으로 생산 시각, 바코드, 라인, 제품군 등의 식별 정보와 함께 해당 설비가 수행한 모든 동작의 측정값이 기록됩니다. 토크, 압력, 온도, 위치값 등 설비에 따라 수십~수백 개의 변수가 하나의 파일에 담기기도 합니다. 파일 형태는 보통 CSV나 TXT로, 날짜·라인·설비번호 기준으로 정규화된 폴더 트리에 쌓입니다.

 

문제는 파일의 수입니다. 설비 한 대가 하루에 수천 개의 로그 파일을 생성하는 것은 드문 일이 아닙니다. 한 달치 데이터를 모으면 순식간에 수백만 행을 넘어섭니다. 분석하고 싶어도 데이터를 꺼내오는 것 자체가 벽이 되는 구조입니다.

 

설비 Log 분석의 경험이 아직 없으신 분들께는 6-Sigma 교육을 먼저 받으실 것을 강력히 권장합니다. 대량생산 체제에서 방대한 데이터를 기반으로 공정을 유지관리하려면 기초 통계 지식과 함께 DOE(실험계획법), MSA(측정시스템 분석), DMAIC 등 기본적인 기법에 대한 이해가 반드시 필요합니다. 코딩 에이전트는 코드를 대신 써줄 수 있지만, 무엇을 분석할지는 엔지니어가 판단해야 하기 때문입니다.

 

DMAIC

 

지금까지 Log 분석의 전형적인 흐름은 이랬습니다. 폴더 트리를 수작업으로 뒤져 파일을 복사하고, Excel로 열어보다 100만 행 제한에 막히고, 어떻게든 Minitab까지 끌고 가도 친절하지 않은 UI와 씨름하다 결국 분석을 포기하는 것. 이 전 과정을 Claude Code로 만든 Python 기반 프로그램으로 자동화할 수 있습니다. Chapter 4에서 설비 Log 자동 수집부터 SPC(Statistical Process Control) 관리도, Cpk 분석까지 한 번에 처리하는 분석 시스템을 직접 만들어보겠습니다.

 

---

 

 

2-3. AI를 활용한 검사와 자동 분석

3년 전까지만 해도 AI는 데이터 사이언스를 전공한 엔지니어들의 전유물이었습니다. 딥러닝 기반 비전 검사가 산업계에 가장 먼저 도입됐고, 이어서 머신러닝을 활용한 설비 데이터 이상 감지, SPC 예측 등이 등장했습니다. 이 모든 것을 도입하려면 개발사에 수억을 주고 수개월을 기다리는 것이 당연한 과정이었습니다.

지금은 다릅니다. 기본적인 이론만 이해하고 있으면 코딩 자체는 Claude Code가 충분히 해냅니다. 더불어 LLM의 등장으로 이전에는 꿈도 꾸지 못했던 자동 분석과 개선 제안까지 가능해졌습니다.

특히 주목할 것은 RAG(Retrieval-Augmented Generation) 기반의 AI 에이전트입니다. 사내 작업표준, 불량 이력, 설비 매뉴얼 등을 지식 허브에 구축하고 MCP 기반 검색 도구를 연결하면, "이 불량의 원인과 대응책을 찾아줘"라는 질문에 현장 맥락에 맞는 답을 돌려주는 에이전트를 만들 수 있습니다. Chapter 5에서 이 시스템을 직접 구현해보겠습니다.

여기까지 읽으셨다면 이제 그림이 그려지셨을 겁니다. 우리가 다루는 데이터가 무엇인지, 그리고 그것으로 무엇을 만들 수 있는지. 다음 Chapter부터 본격적으로 손을 움직여보겠습니다.

RAG, MCP, LLM