쌓인 개선 사례, 생성 AI로 다시 꺼내 쓰기
개선 사례가 쌓일수록 오히려 찾기 어려워지는 이유
개선활동을 오래 해 온 공장일수록 비슷한 고민을 안고 있습니다. 개선 기록이 계속 쌓이면, 정작 지금 문제와 닮은 사례를 찾아내는 일이 새로운 부담이 됩니다. 기록은 엑셀과 종이, 담당자 개인 폴더에 흩어져 있고, 검색어가 조금만 달라도 원하는 사례가 걸리지 않습니다.
생성 AI가 현장에서 주목받는 지점이 바로 여기입니다. 평소 쓰는 말 그대로 질문하면, 축적된 사례 가운데 관련 있는 것을 찾아 정리해 주는 역할입니다. 아이디어를 대신 내주는 도구라기보다 "이미 가진 노하우를 다시 꺼내 쓰는 속도"를 높이는 도구에 가깝습니다.
이 글에서는 일본 제조 현장의 공개 사례와 공장 사용자 연구를 근거로 다섯 가지를 차례로 살펴봅니다. 생성 AI를 개선활동에 연결하는 방식, 비용이 생기는 지점, 보안·안전 기준, 도입이 멈추는 패턴, 그리고 운영 방식의 선택지입니다.
범용 챗봇과 사내 지식 검색형은 출발점이 다르다
"챗GPT를 개선활동에 쓴다"는 말에는 서로 다른 두 가지 방식이 섞여 있습니다. 하나는 범용 챗봇에 일반적인 개선 아이디어를 묻는 방식이고, 다른 하나는 회사가 가진 문서와 사례를 AI가 먼저 찾아본 뒤 그 내용을 근거로 답하게 하는 방식입니다. 후자를 검색 증강 생성, 흔히 "RAG"라고 부릅니다.
현장 개선에 실질적으로 쓸모가 있는 쪽은 대부분 후자입니다. 범용 모델은 우리 공장의 설비명과 품번, 과거에 시도한 대책을 모르기 때문에 그럴듯하지만 일반론에 머무는 답을 내놓기 쉽습니다.
| 구분 | 범용 챗봇 질의 | 사내 지식 검색형(RAG) |
|---|---|---|
| 답변 근거 | 모델이 학습한 일반 지식 | 사내 매뉴얼·개선 기록에서 찾은 문서 조각 |
| 현장 고유 정보 반영 | 어려움 | 등록된 범위 안에서 가능 |
| 근거 확인 | 출처 확인이 어려움 | 참고한 문서 조각을 함께 표시 가능 |
| 사전 준비 | 거의 없음 | 사례 정리·문서 등록·검수 체계 필요 |
| 적합한 용도 | 발상 보조, 일반 원리 학습 | 유사 사례 검색, 표준 절차 확인 |
개선 사례를 목록으로 정리한 뒤 AI에 묻는 접근
일본에서는 한 부품 제조사의 대표가 2023년 경제산업성 심의회에서 생성 AI를 개선활동에 붙인 경험을 공개한 바 있습니다. 라인별 개선 사례를 정해진 양식의 목록으로 정리해 사내에 공유해 왔는데, 사례가 너무 많이 쌓이면서 필요한 것을 찾기 어려워졌고, 이 목록을 생성 AI에 넣어 자연어로 질문하는 방식을 택했다는 내용입니다.
이 사례에서 눈여겨볼 점은 AI보다 그 이전 단계입니다. 개선 기록이 이미 같은 양식으로 정리돼 있었기 때문에 AI를 붙이는 작업이 비교적 단순했습니다. 발표의 결론도 기술보다 조직 쪽에 무게를 두어, 기존 방식을 바꾸려는 경영자의 태도가 변화의 출발점이라는 메시지를 담고 있습니다.
실제 공장 사용자 연구가 보여 준 효과와 한계
생성 AI 기반 지식 검색이 현장에서 어떻게 받아들여지는지는 2024년 학술지 Frontiers in Artificial Intelligence에 실린 연구에서 구체적으로 확인할 수 있습니다. 연구팀은 공장 매뉴얼과 작업자들이 작성한 문제 분석 보고서를 근거로 답하는 RAG 시스템을 만들었습니다. 그리고 세제 공장의 관리자 4명과 작업자 5명에게 실제 업무에서 나올 법한 질문을 던지게 했습니다.
시스템 구조는 개선 사례 관리에도 그대로 참고할 만합니다.
- 긴 문서는 약 400토큰 단위 조각으로 나눠 색인하고, 질문과 비슷한 조각을 찾아 답변에 사용합니다.
- 답변 화면에 근거 문서 조각을 함께 보여 줘 사용자가 직접 확인할 수 있게 했습니다.
- 작업자가 "왜"를 반복하는 근본원인 분석 보고서를 입력하면 AI가 논리 점검을 하고, 숙련자 검수를 거친 뒤에만 지식 베이스에 추가합니다.
참여자들은 정보에 바로 접근할 수 있다는 점과 작은 업무의 처리 속도를 장점으로 꼽았습니다. 반대로 시스템에 기록이 없는 문제를 물으면 오히려 시간을 낭비하게 된다는 지적과, 가까운 숙련 동료에게 묻는 편이 빠르다는 의견도 나왔습니다. 연구팀은 숙련자가 곁에 없는 야간 단독 근무처럼 물어볼 사람이 없는 상황에서 쓰임새가 크다고 해석했습니다.
다만 연구팀 스스로 밝힌 한계도 있습니다. 실제 라인을 가동하는 중에 시험하는 것은 위험하다는 판단으로 제외했고, 벤치마크는 20개 문항을 한 명이 채점했습니다. 결과를 일반화하기보다 도입 전 검토의 출발점으로 삼는 것이 맞습니다.
같은 연구는 공장 문서 기반 20개 문항으로 여러 언어모델을 비교했습니다. 점수는 100점 만점이며, GPT 계열은 2023년 7월 버전 기준입니다.
| 모델 | 사실성 | 완전성 | 환각(낮을수록 좋음) |
|---|---|---|---|
| GPT-4 | 97.5 | 95 | 0 |
| StableBeluga2(오픈소스) | 95 | 92.5 | 7.5 |
| Mixtral 8x7B(오픈소스) | 92.5 | 92.5 | 2.5 |
| GPT-3.5 | 90 | 90 | 5 |
| Llama 2(오픈소스) | 77.5 | 82.5 | 13 |
모델 세대가 바뀌면 점수도 달라지므로, 이 표를 특정 모델을 고르는 근거로 쓰기는 어렵습니다. 사내 문서를 근거로 붙였을 때 오픈소스 모델도 상용 모델에 근접할 수 있다는 방향을 읽는 정도가 적절합니다.
오답을 줄이기 위한 설계 장치
같은 연구에서 시스템에 넣은 장치들은 대부분 오답을 줄이는 쪽에 맞춰져 있습니다. 연구팀은 범용 모델이 별도의 맞춤 작업 없이는 공장 현장에서 쓰임새가 제한적이고, 그럴듯하지만 근거 없는 답변인 "환각"이 가장 큰 걱정거리라고 봤습니다.
- 근거가 없으면 답하지 않기: 질문 템플릿에 제공된 문서에 관련 정보가 없으면 답하지 말라는 지시를 넣었습니다.
- 출처 성격별 분리: 공장 매뉴얼과 작업자가 공유한 현장 지식을 서로 다른 질의로 나눠, 두 출처가 섞여 생기는 혼란을 막았습니다.
- 오답 중심 채점: 벤치마크에서 완전히 맞으면 1점, 일부만 맞으면 0.5점, 그 외는 0점을 줘 틀린 답을 크게 감점했습니다.
과거에는 작업자가 쓴 문제 보고서가 구조가 엉성하고 용어가 제각각이라 AI가 활용하기 어려운 자료로 여겨졌습니다. 연구팀은 언어모델의 이해력이 이런 한계를 넘을 수 있다고 봤습니다. 정리가 덜 된 현장 기록도 자산이 될 수 있다는 뜻이지만, 그만큼 숙련자 검수가 중요해집니다.
비용은 라이선스보다 데이터 정리에서 더 든다
생성 AI 도입 비용을 떠올리면 보통 구독료나 사용량 요금이 먼저 생각납니다. 실제 부담은 세 갈래로 나뉩니다.
- 사용료: 상용 API는 처리한 토큰 양에 비례해 과금됩니다. 위 연구는 상위 모델의 토큰당 단가가 더 높지만, 답이 간결해 일부 상쇄된다고 봤습니다.
- 인프라: 모델을 사내에서 직접 돌리려면 GPU 서버가 필요합니다. 연구팀은 오픈소스 모델 시험에 메모리 합계 96GB인 GPU 2장을 사용했습니다.
- 숨은 비용: 흩어진 개선 기록을 같은 양식으로 정리하는 작업, 새 사례를 검수하는 숙련자의 시간, 작업자 교육이 여기에 해당합니다.
세 번째 항목이 가장 자주 과소평가됩니다. 앞의 일본 사례가 AI를 붙이기 전에 정형 양식의 개선 목록부터 갖췄다는 점은 비용 측면에서도 시사점이 큽니다. 양식 없이 시작하면 AI가 읽을 수 있는 데이터를 만드는 인건비가 라이선스 비용보다 커지기 쉽습니다.
정보보안과 현장 안전, 두 가지 기준을 먼저 세운다
개선 사례에는 설비 조건, 품번, 거래처 요구사항 같은 민감 정보가 섞여 있습니다. 외부 생성 AI 서비스에 이 내용을 그대로 입력하면 영업비밀 관리나 거래처와의 비밀유지 약정 범위를 벗어날 수 있습니다. 사내 기준 없이 개인 판단에 맡기는 운영은 피해야 합니다.
- 입력 금지 정보 정의: 거래처명, 도면 수치, 개인정보처럼 외부 서비스에 넣지 않을 항목을 문서로 정합니다.
- 서비스 등급 구분: 입력 내용이 학습에 쓰이지 않는 기업용 계약인지, 사내 서버 구동형인지에 따라 넣을 수 있는 정보 범위를 다르게 둡니다.
- 답변 검증 책임: AI 답변을 설비 조작이나 안전 판단에 바로 쓰지 않고, 사람이 근거 문서를 확인하는 절차를 둡니다.
마지막 항목은 보안보다 안전의 문제입니다. 앞의 연구에서도 한 관리자가 답변이 부정확하면 안전이 위협받을 수 있다고 우려했습니다. 연구팀 역시 화학물질을 다루는 공장에서 그럴듯한 오답이 위험한 상황으로 이어질 수 있다고 짚었습니다.
도입이 멈추는 네 가지 지점
생성 AI 개선 도구가 시범 단계에서 멈추는 원인은 기술보다 운영에 있는 경우가 많습니다.
첫째는 데이터 부족입니다. 등록된 사례가 적으면 AI는 관련 없는 사례를 끌어오거나 답을 하지 못합니다. 사용자는 몇 번 헛걸음을 한 뒤 다시 찾지 않게 됩니다.
둘째는 질문 품질에 대한 의존입니다. 위 연구 참여자 중에는 질문이 아주 구체적이어야 믿을 만한 답이 나온다고 느낀 사람도 있었습니다. 어떤 정보를 담아 물어야 하는지 질문 예시를 함께 제공해야 하는 이유입니다.
셋째는 사람과 도구의 경쟁 구도입니다. 숙련자에게 묻는 문화가 강한 현장에서는 AI가 경쟁 상대로 비치기 쉽습니다. 숙련자를 검수자로 참여시키면 대체가 아니라 숙련자의 지식을 더 넓게 퍼뜨리는 구조가 됩니다.
넷째는 교육과 세대 차이입니다. 연구 참여자들은 작업자 교육, 전 직원의 수용, 고령 작업자의 실제 사용 여부를 도입 장벽으로 꼽았습니다.
범용 서비스·사내 구축·로컬 모델을 나눠 쓰는 방식
한 가지 방식만 고집할 필요는 없습니다. 정보 민감도와 용도에 따라 나눠 쓰면 비용과 보안 사이의 균형을 잡기 쉽습니다.
- 범용 서비스: 개선 기법 학습, 회의록 정리처럼 민감 정보가 없는 일에 씁니다.
- 기업용 클라우드 기반 사내 검색: 사내 개선 기록 검색처럼 답변 품질이 중요하고 민감도가 중간인 영역에 씁니다.
- 사내 서버 구동 오픈소스 모델: 도면이나 거래처 정보가 얽혀 외부 반출이 어려운 문서에 씁니다.
위 연구도 오픈소스 모델이 최상위 상용 모델보다 점수는 다소 낮지만, 사내에서 운영하면 데이터 보안과 맞춤화에서 이점이 있다고 평가했습니다. 민감 데이터를 다루는 기업에는 유력한 선택지라는 판단입니다.
생성 AI는 개선 노하우를 "찾는 비용"을 줄이는 도구다
생성 AI가 개선 아이디어를 대신 만들어 주지는 않습니다. 일본 제조 현장의 공개 사례와 공장 사용자 연구가 공통으로 보여 주는 것은, 이미 쌓인 노하우를 필요한 순간에 꺼내 쓰는 시간을 줄이는 데 효과가 있다는 점입니다. 그 효과는 사례를 정형 양식으로 정리해 둔 회사에서 먼저 나타납니다.
처음 시작하는 공장이라면 AI 도구를 고르기 전에 개선 기록 양식을 하나로 통일하는 일부터 권합니다. 작업 구분, 개선 관점, 효과, 적용 라인 정도의 열만 맞춰도 나중에 어떤 AI를 붙이든 바로 쓸 수 있는 자산이 됩니다. 그 위에 외부 입력 금지 정보와 숙련자 검수 절차를 정해 두면, 작은 범위의 시범 운영을 안전하게 시작할 수 있습니다.
참고문헌
- Kernan Freire, S., Wang, C., Foosherian, M., Wellsandt, S., Ruiz-Arenas, S., Niforatos, E. "Knowledge sharing in manufacturing using LLM-powered tools: user study and model benchmarking." Frontiers in Artificial Intelligence, Vol. 7, 1293084. 2024.03.27. CC BY. https://doi.org/10.3389/frai.2024.1293084
본 게시물은 AI 어시스턴트를 활용하여 초안을 작성하고 편집자의 검수를 거쳤습니다. 타 기업명 및 영업 기밀 보호를 위해 본문 중 일부 고유명사는 익명화(A/B) 처리되었습니다.