PLM과 MES가 십오 년째 돌고 있습니다.
화면은 낡았지만 업무는 전부 그 안에 있습니다. 조회 한 번에 메뉴를 네 번 들어가야 하고, 등록할 때는 같은 값을 세 화면에 나눠 넣습니다.
AI 이야기가 나오자 IT팀이 먼저 말합니다. "두 시스템 다 외부 연동 기능이 없습니다. 만든 회사도 지금은 유지보수만 합니다."
그러면 시스템을 새로 만들 때까지 기다려야 할까요.
레거시 시스템 AI 연동을 알아보는 분들이 가장 먼저 부딪히는 질문입니다.
저희 팀리부뜨(team reboott)는 PLM과 MES에 쌓인 데이터를 온톨로지로 정리해, AI 에이전트가 쉽게 처리할 수 있게 만드는 일을 하고 있습니다.
요약
레거시 시스템 AI 연동은 시스템을 새로 만들지 않아도 됩니다.
팀리부뜨는 PLM과 MES 앞에 계정 보관, 허용 기능, 실행 기록, 중복 방지를 맡는 관문을 세워 데이터를 안전하게 꺼내고, 꺼낸 데이터를 부품, 개정, 공정, 설비, 지표의 온톨로지로 정리합니다.
AI 에이전트는 이 관계를 따라 두 시스템을 건너는 질문과 What-if 분석에 답합니다.
시스템 등록은 조회, 초안, 테스트, 승인 순서로 한 단계씩 맡깁니다.
레거시 시스템 AI 연동은 외부 연동 기능이 없는 오래된 사내 시스템에 AI 에이전트를 연결하는 일입니다. 오래된 시스템이 AI와 잇기 어려운 이유는 사람이 화면으로 쓰는 것을 전제로 만들어졌기 때문입니다.
요즘 서비스는 외부 프로그램과 데이터를 주고받는 통로를 기본으로 갖추고 있습니다. 오래된 사내 시스템은 그 통로가 없거나, 있어도 설명 문서가 남아 있지 않습니다.
그래서 선택지가 두 가지로 좁혀지곤 합니다. 시스템을 새로 만들거나, 화면 클릭을 흉내 내는 RPA를 붙이거나.
새로 만드는 데는 몇 년과 큰 비용이 듭니다. 옮기는 과정에서 코드 안에만 있던 업무 규칙이 빠질 위험도 있습니다.
RPA는 빨리 붙지만 화면이 조금만 바뀌어도 멈추고, 무엇을 판단해서 눌렀는지 기록이 남지 않습니다. 두 방식의 차이는 RPA vs AI 자동화 글에서 비교했습니다.
담당자 계정을 AI에게 그대로 넘기면 안전하지 않습니다. 연결 방법보다 현업이 더 걱정하는 것이 있습니다. AI가 잘못된 값을 시스템에 넣으면 누가 책임지느냐는 문제입니다.
AI에게 담당자 계정을 그대로 주면, 그 계정으로 할 수 있는 모든 일을 AI도 할 수 있게 됩니다. 조회만 시키려 했는데 삭제 버튼까지 손이 닿아 있는 셈입니다. 나중에 어떤 작업을 사람이 했고 어떤 작업을 AI가 했는지 구분하기도 어렵습니다.
보안팀이 AI 도입에 반대하는 이유도 대개 여기 있습니다. 문제는 AI가 아니라, AI가 쓸 권한의 범위를 정해두지 않은 것입니다.
팀리부뜨는 기업용 AI 에이전트를 구축하고 있습니다. 회사의 업무 맥락을 학습한 에이전트 하나가 사람이 하던 반복 조회와 입력을 대신 처리하는 방식입니다.
오래된 시스템과 이 에이전트를 연결할 때 팀리부뜨는 시스템 코드를 고치지 않습니다. 대신 에이전트와 시스템 사이에 정해진 규칙만 통과시키는 관문을 하나 세웁니다.
[관문이 맡는 네 가지]
계정 정보는 관문만 갖고 있습니다. 에이전트는 비밀번호를 모릅니다. "이 조건으로 조회해달라"고 관문에 요청할 뿐입니다.
허용된 기능만 엽니다. 처음에는 조회 기능만 열고, 등록 기능은 별도 승인을 받은 뒤 하나씩 엽니다. 목록에 없는 기능은 요청이 와도 거부합니다.
모든 실행을 기록합니다. 누가 어떤 질문을 했고, 에이전트가 어떤 기능을 어떤 값으로 불렀는지 남깁니다. 문제가 생기면 이 기록을 따라 거슬러 올라갑니다.
같은 요청이 두 번 처리되지 않게 막습니다. 네트워크가 끊겨 에이전트가 다시 시도하더라도 같은 등록이 두 건 생기지 않습니다.
관문은 사람이 화면에서 보내던 요청을 같은 방식으로 보내고, 응답을 에이전트가 읽기 좋은 형태로 바꿔 돌려줍니다. 기존 시스템은 바꿀 필요 없이 그대로 둡니다.
꺼낸 PLM, MES 데이터는 부품, 개정, 공정, 설비, 지표를 객체로 세운 온톨로지로 정리해야 AI 에이전트가 쉽게 처리합니다. 관문으로 데이터를 꺼낼 수 있게 됐다고 끝나지 않습니다.
PLM과 MES의 데이터는 각 시스템이 쓰기 좋은 표 모양으로 쌓여 있습니다. 부품표는 부품표대로, 설비 태그는 태그대로 있습니다. 이 부품이 어느 공정에 들어가고 그 공정을 어느 설비가 맡는지는 두 시스템 어디에도 한 줄로 적혀 있지 않습니다.
PLM AI, MES AI 연동을 각각 따로 붙이면 에이전트는 표 안의 질문에만 답합니다. "이 부품 설계변경 뒤에 불량률이 달라졌나요" 같은 질문은 PLM과 MES를 건너야 해서 막힙니다.
그래서 꺼낸 데이터를 온톨로지로 정리합니다. 부품, 개정, 변경 사유, 공정, 설비, 지표를 객체로 세우고 그 사이를 관계로 잇습니다. 부품 번호와 설비 코드처럼 시스템이 이미 갖고 있는 키로 잇기 때문에, 언제든 원본 기록으로 되돌아갈 수 있습니다.
이렇게 해두면 에이전트의 일이 단순해집니다. 질문을 받으면 부품에서 개정과 변경 사유로, 다시 공정과 설비로 관계를 따라가고, 변경 전후의 실적을 MES에서 꺼내 비교합니다. 사람이 두 시스템 화면을 번갈아 열며 하던 일을 에이전트가 관계를 따라 대신 합니다.
| 시스템 | 쌓여 있는 것 | 온톨로지에서 세우는 객체 | 에이전트가 쉬워지는 일 |
|---|---|---|---|
| PLM | 부품표, 도면, 설계변경, 시험 결과 | 부품, 개정, 변경 사유, 판정 | 같은 부품의 과거 변경과 문제 찾기 |
| MES | 설비 태그, 생산 실적, 작업 조건 | 공정, 설비, 지표, 측정 기간 | 이상이 생긴 설비와 지표 좁히기 |
| 문서 | 기준서, 회의록, 검토 자료 | 기준, 근거 위치 | 답변에 근거와 확인 상태 붙이기 |
이 온톨로지 위에 숙련자의 판단 기준까지 얹으면 암묵지가 회사 자산이 됩니다. 그 방법은 암묵지 자산화 글에서 다뤘습니다.
맡길 수 있지만, 한 단계씩 넓혀야 합니다. 처음부터 등록을 맡기지 않고 조회로 시작해서, 에이전트가 입력할 내용을 초안으로 만들어 사람에게 보여주는 단계로 갑니다. 그다음 실제와 분리된 테스트 환경에서 등록을 검증하고, 마지막에 담당자 승인을 거쳐 실제 시스템에 반영합니다.
단계를 올릴 때마다 직접 확인할 것이 있습니다. 테스트 환경이 정말 실제 데이터와 분리돼 있는지는 시스템마다 다릅니다.
메뉴 이름에만 '테스트'가 붙어 있고 저장은 같은 곳에 되는 경우도 있습니다. 그래서 등록 기능을 열기 전에 반드시 한 건을 직접 넣어보고 어디에 저장되는지 확인합니다.
| 단계 | 에이전트가 하는 일 | 사람이 하는 일 |
|---|---|---|
| 조회 | 조건에 맞는 자료를 찾아 정리 | 결과를 보고 판단 |
| 초안 | 입력할 값을 만들어 제시 | 고치거나 그대로 입력 |
| 테스트 등록 | 분리된 환경에 실제로 등록 | 등록 결과를 원본과 대조 |
| 승인 후 반영 | 승인된 건만 실제 시스템에 등록 | 승인 버튼으로 최종 확인 |
설계변경이 생산에 미친 영향 확인
PLM의 변경 이력과 MES의 해당 공정 실적을 같은 부품 기준으로 이어서, 변경 전후 불량률과 작업 시간을 나란히 보여줍니다. 두 시스템 담당자에게 따로 자료를 요청하던 일이 질문 하나로 끝납니다.
정비 일정을 옮기기 전에 What-if 확인
"조립 2라인을 다음 주 3일 세우면?"처럼 가정을 물으면, 에이전트가 온톨로지의 관계를 따라 영향 받는 공정과 부품, 생산 계획을 찾고 같은 공정을 할 수 있는 대체 설비까지 함께 보여줍니다. 숫자 예측은 연결한 시뮬레이션 모델의 정밀도에 따라 다르기 때문에, 최종 선택은 담당자가 합니다.
메뉴 네 번 들어가던 조회를 질문 하나로
"지난달 등록된 변경 건 중 아직 승인 안 된 것"처럼 말로 물으면, 에이전트가 필요한 조회를 여러 번 불러 결과를 한 표로 모아줍니다. 담당자는 메뉴를 네 번씩 들어가는 대신 정리된 표만 확인합니다.
거래처 서류를 오래된 ERP에 옮겨 적는 일
레거시 시스템은 공장에만 있지 않습니다. 무역팀과 경영지원팀에서는 거래처가 보낸 발주서와 인보이스를 오래된 ERP 등록 화면 세 곳에 나눠 옮겨 적는 일이 흔합니다. 에이전트가 서류를 읽어 화면별로 들어갈 값을 초안으로 만들고, 담당자는 초안 하나만 확인해 승인합니다.
메신저에서 바로 조회
사내 메신저에서 에이전트를 부르면 관문을 거쳐 시스템을 조회합니다. 출장 중에도 PC 앞에 앉을 필요가 없고, 이때도 메신저 사용자와 시스템 권한이 같은 사람으로 이어지는지를 관문이 확인합니다.
차세대 시스템 준비 자료
관문에 쌓인 실행 기록을 보면 현업이 어떤 기능을 얼마나 자주 쓰는지가 드러납니다. 몇 년 뒤 새 시스템을 설계할 때 무엇부터 옮길지 정하는 근거가 됩니다.
연결할 수 있습니다. 팀리부뜨의 관문은 사람이 화면에서 보내던 요청을 같은 방식으로 보내고 응답을 에이전트가 읽기 좋은 형태로 바꿉니다. 그래서 시스템 쪽 코드를 고치거나 새 연동 기능을 만들지 않아도 됩니다.
처음에는 조회만 맡기고, 등록은 초안 작성, 테스트 환경 등록, 담당자 승인 후 반영 순서로 넓힙니다. 모든 실행은 관문에 기록되어 누가 어떤 값으로 무엇을 했는지 거슬러 확인할 수 있습니다.
PLM과 MES는 각자 표로 데이터를 쌓기 때문에 "이 부품이 어느 설비에서 만들어지는지" 같은 관계가 어디에도 한 줄로 적혀 있지 않습니다. 온톨로지로 부품, 공정, 설비, 지표를 잇고 나면 AI 에이전트가 두 시스템을 건너는 질문과 What-if 분석에 관계를 따라 답할 수 있습니다.
가장 자주 쓰는 조회 기능 두세 개를 고르는 것이 시작입니다. 조회는 데이터를 바꾸지 않아서 보안 검토도 상대적으로 가볍고, 효과는 첫 주부터 보입니다.
오래된 시스템 때문에 AI 도입을 미루고 계신다면, 쓰고 계신 PLM, MES와 자주 반복하는 조회, 입력 업무를 알려주세요. 팀리부뜨의 AI 에이전트 구축 전문가가 연결 방식과 단계를 함께 정리해드립니다.
상담문의 시 "레거시 시스템 AI 연동 글을 보고 문의했다"고 남겨주시면 보다 원활한 상담이 가능합니다.
%202.png){kind=logo}
