제조 공정 데이터 온톨로지 구축, 로트 추적으로 품질 문제 원인 찾기

1. 도입 이유

고객사는 품질 문제가 생기면 정해진 기한 안에 원인 보고서를 요구했습니다. 데이터를 모으는 데 시간을 다 쓰면 원인을 따질 시간이 모자랐고, 데이터 통합도 몇 번 시도해 보았지만 공정이 바뀔 때마다 오래가지 못했습니다.

2. 현장 조건

원료가 여러 공정을 차례로 지나 완제품으로 만들어지는 공장이었습니다. 공정 조건은 MES와 공정 데이터 서버에, 검사 결과는 품질 시스템에 기록됐고, 원자재 성적서는 PDF로만 남아 있었습니다.

공정 중간에 제품을 자르거나 합치는 일이 생겨, 최종 제품 번호와 앞 공정 로트 번호가 하나씩 맞지 않는 일이 생겼습니다. 중간에 바뀐 번호를 이어 붙여야 앞 공정까지 추적할 수 있었습니다.

정보시스템팀은 공정 데이터를 한곳에 모으는 작업을 몇 번 시도했지만, 공정이 바뀔 때마다 다시 맞춰야 해서 오래가지 못했습니다.

고객사는 품질 문제가 생기면 정해진 기한 안에 원인과 대책을 담은 보고서를 요구했습니다. 어떤 데이터를 먼저 확인할지는 담당자의 경험에 달려 있었습니다.

공장 데이터는 외부로 나갈 수 없어, 새로 도입하는 서버와 접속 권한도 공장 보안 절차에 따라 하나씩 승인을 받았습니다.

기존 방식의 한계

• 품질 문제 한 건마다 담당자가 로트 번호로 시스템을 하나씩 열어 조회했습니다.
• 원자재 성적서는 PDF를 열어 눈으로 확인했습니다.
• 공정 항목 이름이 시스템마다 달라 같은 값을 다른 말로 부르는 경우가 많았습니다.

3. 해결 방법

테이블 구조 분석으로 만든 초안

MES, 공정 데이터 서버, 품질 시스템의 테이블 구조와 조회 기록을 분석해 공정, 로트, 조건, 검사의 관계 초안을 자동으로 뽑았습니다. 항목 이름은 현장에 파견된 엔지니어(FDE)가 생산기술팀과 함께 논의하여 정리했습니다.

바뀐 번호를 이어 두기

제품을 자르고 합칠 때 생기는 번호 변화를 관계로 남겨, 제품 번호 하나로 앞 공정까지 추적할 수 있게 했습니다. 성적서 PDF의 수치도 추출해 원자재 데이터와 연결했습니다.

기준에서 벗어난 값 표시

품질 문제가 접수되면 Agent가 해당 로트의 공정 조건 중 기준을 벗어난 항목과 비슷한 지난 사례를 같이 보여 줍니다. 원인 판단은 품질 담당자가 맡습니다.

검토했다가 뺀 방법

• 데이터 레이크로 전부 옮기기: 예전에 시도했다가 공정 변경을 따라가지 못했던 방식입니다. 원래 시스템은 두고 관계만 정의했습니다.

4. 진행 과정

1. 인사이트 세미나: 품질보증팀, 생산기술팀과 품질 문제 대응에서 시간이 드는 구간을 정리했습니다.
2. 대상 업무 · KPI 설정: 원인 분석 자료를 준비하는 시간을 KPI로 정했습니다.
3. 현장 파견 · OS 설계: FDE가 공장에 머물며 로트 체계와 공정 항목을 정리해 온톨로지 설계안을 만들었습니다.
4. PoC AI OS 구축: 제품군 하나로 역추적과 기준 이탈 표시를 먼저 만들고, 지난 품질 문제 사례에 적용해 원인을 제대로 찾는지 검증했습니다.
5. 시범 운영 · 확산: 제품군을 확대하고, 정보시스템팀이 새 공정을 등록하는 절차를 만들었습니다.

5. 도입 후 달라진 점

프로젝트를 함께 진행해 보니 어땠나요?

현장에 파견된 엔지니어가 공장에 머물며 로트 체계와 공정 항목을 직접 정리해 주셨습니다. 제품군 하나로 먼저 만들어 지난 품질 문제 사례로 검증했기 때문에, 다른 제품군으로 확대하기 전에 실제 대응에 쓸 수 있는지 미리 확인할 수 있었습니다.

도입하고 나서 무엇이 달라졌나요?

품질 문제를 추적하는 방식이 달라졌습니다. 예전에는 로트 번호로 시스템을 하나씩 열어 조회해야 했는데, 이제는 제품 번호 하나로 공정 조건과 원자재까지 한 화면에서 확인할 수 있게 됐습니다.

운영하면서 특히 나아진 점이 있다면 무엇인가요?

시스템마다 다르게 부르던 공정 항목 이름이 정리됐다는 점입니다. 같은 값을 두고 헷갈리는 일이 줄었습니다. 공정이 바뀌어도 온톨로지에 항목만 추가하면 되기 때문에, 예전처럼 데이터를 처음부터 다시 정리할 필요가 없어졌습니다.

— 품질보증팀 담당자