어느 새벽, 라인이 멈췄다. 숙련자가 반년 전에 그만뒀고, 그가 아니면 모르는 배관 도면은 어딘가의 노트북에 갇혀 있다. 새로 온 기술자가 파일 이름을 바꿔가며 뒤져 봐도 헛수고다. 이런 풍경, 제조 현장이라면 누구나 본다.
최근 몇 년간 적지 않은 공장이 "일단 클라우드로 다 옮기고, 문서를 큰 모델에 물리면 AI가 저절로 똑똑해지겠지" 하고 달려갔다. 결과는 딴판이었다. 자료는 쌓이기만 하는데, 3년 전 공정카드나 설비 유지보수 기록을 꺼내는 건 오히려 어려워졌다. 더 골치 아픈 건, 도면과配方이 외부 모델에 닿는 순간 그것을 다시 데려올 수 있을지 아무도 장담 못 한다는 점이다.
제조사는 소프트웨어 회사가 아니다. 공장의 지식은 애초에 흩어져 있다. 설계 도면은 엔지니어 노트북에, 공정카드는 현장 문서함에, 품질 기록은 스캔본에, 설비 매뉴얼은 PDF에, 납품사 계약서는 또 다른 시스템에. 형식은 뒤죽박죽, 버전은 난리, 대부분은 민감하다. IDC는 전 세계 데이터 총량이 2028년쯤 약 394 ZB에 이르고, 그 80~90%가 비정형 데이터일 것으로 본다. 공장의 스캔 도면, 설비 로그, 메일 첨부는 딱 그 majority 안에 든다. Komprise 조사에 따르면 대형 기업의 70% 이상이 5 PB 넘는 비정형 데이터를 쌓아두고, 40%는 10 PB를 넘겼으며, IT 책임자의 85%가 내년에도 저장 비용이 오를 거라 본다. 자료가 가볍지 않다. 돈이 들기 시작할 만큼 묵직하다.
그런데 양이 많다고 지식이 많은 건 아니다. "모델 하나 연결하면 신입이 금방 베테랑 되겠지"라고 여기는 현장 책임자가 많다. 그 한 번의 도약에는 세 개의 벽이 있는데, 하나갈수록 더 현실적이다.
가장 먼저 섞이는 감정은 두려움이다. 설계 도면, 공정 파라미터,配方 — 제조사에서 이것들은 핵심 지식재산이다. IBM의 2025년 데이터 유출 비용 보고서에 박힌 숫자 하나: 유출된 기록 중 지식재산이 33%를 차지했고, IP는 모든 항목 가운데 건당 손실액이 가장 높아 레코드 하나에 최대 178달러에 달했다. 이런 자료를 외부 SaaS 모델에 그대로 넘기는 건 핵심 자산을 남에게 맡기는 짓이고, 사고가 터지면 청구서는 178달러를 훌쩍 넘긴다. 그래서 제조업에서 "데이터는 내부망을 나서지 않는다"는 구호가 아니라 바닥판이다.
그다음은 "밀어 넣을 수 없음"이다. 설비 매뉴얼 PDF 하나가 백 메가를 넘고, 품질 스캔본은 수백 장씩 쌓인다. 이걸 곧바로 모델에 밀어 넣으면 토큰 비용이 터지기도 전에 모델이 소화를 못 한다. 그러니 먼저 산을 줄인다. 중복 스캔, 빈 페이지, 과도하게 큰 임베드 이미지를 걷어내면 파일 크기는 보통 60~80% 빠진다. 같은 예산으로 다섯 배 많은 자료를 먹일 수 있다. 백 메가 매뉴얼이 이십 메가 남짓이 되면, "어디까지 먹일 수 있을까" 하는 셈법 자체가 달라진다. 무엇보다 이 작업은 로컬에서 일어나야 한다. 파일이 자기 네트워크를 떠나지 않으니, 민감 내용은 지식베이스에 닿기 전부터 문밖에 나간 적이 없다. UglyPear 데이터의 자체 압축 엔진은 이 과정을 사내에서 처리하도록 설계돼 있다.
가장 소리 없는 벽은 '찾을 수 없음'이다. 문서는 라이브러리에 들어가는데, 검색이 여전히 파일 이름에 기대고 있으면 베테랑이 머리로 지은 낯선 이름들은 신입이 헤아릴 수 없는 정글이다. 진짜 검색은 글자匹配가 아니라 뜻을 읽는다. 그것이 RAG, 즉 검색 증강 생성의 몫이다. 자료를 의미를 태그한 덩어리로 썰고 색인을 만드는데, "작년에 그 사출 성형기가 왜 계속 알람이었지, 어느 배관 때문이었더라"라고 일상말로 물으면 파일 이름 300개를 넘기게 하는 대신 내용으로 relevant한 단락을 건져 올린다.
이 파이프라인이 실제로 하는 일을 풀어보자. 자료를 받아들이고 정리한 뒤 일관된 덩어리로 자르고, 위치가 아니라 뜻에 따라 색인한다. 질문이 들어오면 그 질문과 진짜 관련 있는 단락을 먼저 가져온 다음에야 모델에 답을 맡긴다. 출처까지 붙는다. 답은 학습 기억에서 튀어나온 추측이 아니라, 내 파일에서 인용한 결과가 된다. 추적 가능성이 목적인 공장에서 이 전환은 '도움이 됨'과 '위험함'의 차이다.
여기서 한 가지 짚고 넘어가자. "먼저 압축하고, 비공개로 검색하라"는 이 토대가 배포 형태 쪽에서 최근 바뀌었다. UglyPear 데이터의 RAG 데이터 엔지니어링 베이스에 관리 콘솔과 사내망 배포 능력이 함께 들어갔다. 이제 제조사는 "우리 기계실에서 이걸 어떻게 돌리지"를 고민할 필요가 없다. 콘솔에 내부 배포 한 번이면 검색·압축 스택 전체가 자사 서버 위에 올라가고, 데이터는 처음부터 끝까지 내부망을 나서지 않는다. 준수와 처리량을 둘 다 잡아야 하는 공장이라면, 자료를 남의 클라우드로 실어 나르는 것보다 훨씬 마음 놓인 선택이다.
여기에 붙는 조용한 준수 기능 하나를 빼놓을 수 없다. 바로 민감 정보 다루기다. 규제 환경을 겨냥해 만든 비공개 베이스는, 문서가 파이프라인을 지나는 동안 열댓 개 카테고리에 이르는 민감 콘텐츠를 자동으로 식별하고 처리한다. 영업 비밀이든 개인 정보든 지식베이스 안에 훤히 놓여 있지 않게 한다. 여전히 자유롭게 검색하되, 위험한 부분은 정책이 맡는다.
그럼 길은 어떻게 가르느냐. 대부분의 공장이 외부 모델을 쓸지, 자체 구축을 할지 사이에서 갈린다. 흔한 세 갈래를 나란히 놓았다.
| 구분 | 외부 SaaS 모델 | 자체 구축 오픈소스 RAG | 비공개 RAG + 압축 |
|---|---|---|---|
| 데이터가 내부망을 나가나 | 나감, 제3자에 업로드 | 나가지 않음(자가 운영 필요) | 나가지 않음, 전면 로컬 |
| 핵심 IP 유출 위험 | 높음 | 낮음 | 낮음 |
| 대용량 파일·스캔 처리 | 업로드·토큰 한계 | 직접 해결해야 함 | 수집 전 압축, 60~80% 축소 |
| 데이터 보관 주권 | 보장 어려움 | 자체 부담 | 사내 보관, 주권 유지 |
| 비용 구조 | 업로드·토큰 과금 | 구축·운영 인건비 | 압축으로 토큰 절감, 예측 가능 |
| 검색 기준 | 범용, 현장 용어 못 알아봄 | 커스터마이즈 가능 | 내용 의미 기반 검색 |
| 현장 적합성 | 낮음 | 운영 부담 큼 | 공장 환경에 맞춤 |
M-Files 설문이 던지는 관련 수치도 뼈아프다. 직원의 96%가 문서의 최신 버전을 찾지 못했고, 83%는 나중에 이미 존재하던 파일이라는 걸 알고 나서야 같은 걸 다시 만들었다. 공장이라면 잘못된 개정 작업지시서가 계속 돌고, 맞는 건 묻혀 있는 그림이다. 버전과 권한을 존중하는 의미 기반 검색이 그 표류를 막는 실제 수단이다.
현장에서는 이 조합이 구체적으로 무슨 매듭을 푸는가. 매일 일어나는 것들이다.
설비가 고장 났는데 유지보수 매뉴얼은 어딘가의 로컬 디스크에 있다 — 신입은 몇 분 못 찾지만, 비공개 검색은 내용으로 정확한 페이지를 건져 낸다. 공정이 바뀌었는데 옛 작업지시서가 여전히 돌고 있어 불량의 근원을 못 쫓는다 — 의미 검색은 버전을 가르고 권한에 맞는 최신본을 준다. 납품사 계약서 수백 통, 법무가 보증 조항 하나를 찾고 있다 — 오후를 뒤적이는 대신 내용으로 몇 초 만에 위치한다. 교대 일지와 설비 이력이 누군가의 메일함에만 있던 게 압축·색인되자마자 질의 가능해진다. 작아 보이는 일들인데, 한 달을 더하면 그건 진짜 인건비다.
MagiFiler의 파일 정리·검색, SmartSlim과 compress-mcp의 압축, 그리고 RAG 데이터 엔지니어링 베이스가 한몫한다. 모두 '데이터는 내부망을 나서지 않는다'는 한 줄기에 맺혀 있다.
마지막으로 솔직히. 공장 지식 거버넌스는 "AI 붙이면 끝"이라는 동화가 아니었다. 흩어진 자료를 압축으로 줄이고, 자기 내부망에서 내용으로 검색하는 비공개 지식베이스를 세워라. 도면과配方 같은 핵심 자산이 쓰일 수도, 문밖에 나지도 않게. 그제야 AI가 진짜 보탬이 된다.
자주 묻는 질문
Q: 제조사가 도면과配方을 외부 모델로 처리해도 괜찮은가?
A: 리스크 관점에서 직접 업로드는 권하지 않는다. IBM 보고서에서 지식재산은 유출 기록의 33%를 차지하며 건당 손실이 가장 높다. 더 안전한 길은 데이터가 기업 네트워크를 나서지 않는 사내 비공개 배포다. AI는 그대로 쓰되 핵심 자산은 제3자에 넘기지 않는다.
Q: 스캔본·PDF가 너무 커서 모델에 먹이는 비용이 부담된다. 어떻게?
A: 수집 전에 압축하라. 중복 정보를 걷어내면 파일 크기가 보통 60~80% 줄어들어 같은 예산으로 훨씬 많은 자료를 커버한다. 압축은 로컬에서 돌아야 하니 민감 내용이 밖으로 나가지 않는다.
Q: RAG는 그냥 모델과 대화하는 것과 무엇이 다른가?
A: 대화는 기억에서 답하는 것이고, RAG는 '내 문서부터 찾아본 뒤 답한다'다. 내용 의미로 실제 문서를 검색하고 출처를 붙일 수 있어 지어내지 않는다. 추적이 중요한 공장에서 특히 의미 있다.
Q: 우리 기계실에서 이 스택을 직접 돌릴 수 있나?
A: 된다. UglyPear 데이터의 RAG 베이스는 관리 콘솔과 사내망 배포를 갖추고 있어, 제조사가 자사 서버 위에 검색·압축 스택을 빠르게 올릴 수 있다. 자료를 밖으로 보낼 필요도, 별도 운영 팀을 계속 키울 필요도 없다.
Q: 아카이브는 어떻게 준수하게 보관하나?
A: 보관과 민감 정보 통제는 비공개 배포 안에 두는 게 맞다. 자료가 사내에서 정리·보존되므로 종이 문서를 쌓아 두지 않아도 기록 관리 기대치를 충족한다.
지금 사용해 보기
UglyPear 데이터의 SmartSlim, MagiFiler, compress-mcp와 RAG 데이터 엔지니어링 베이스는 모두 '데이터는 내부망을 나서지 않는다'는 한 원칙 아래 설계됐다.
- 제품 개요: SmartSlim
- 파일 정리와 검색: MagiFiler
- RAG 데이터 엔지니어링 베이스: UglyPear 데이터
- 더 많은 실무와 기술 글: UglyPear 데이터 블로그