"비슷한 문제가 예전에도 있었던 것 같은데요."
개발 회의에서 이 말이 나오면 바로 PLM 시스템을 엽니다. 당시 프로젝트 폴더를 찾습니다. 파일은 분명히 있습니다.
그런데 파일명에는 프로젝트 이름만 있습니다.
변경 이유는 첨부 문서 중간 어딘가에 적혀 있습니다. 어느 조건에서 생긴 문제였는지 확인하려고 문서를 대여섯 개 열다 보면, 회의는 이미 다음 안건으로 넘어가 있습니다.
저희 팀리부뜨는 AI로 제조 기업의 문서와 개발 이력을 실제 업무에 연결하는 일을 하고 있습니다.
PLM은 제품 개발 과정의 문서와 이력을 관리합니다. 언제 어떤 문서가 등록됐고 개정번호가 몇 번까지 올라갔는지는 정확하게 남습니다.
PLM은 제 할 일을 했습니다. 문제는 그다음입니다. 설계변경 기록을 찾았다고 해도 어떤 문제가 원인이었는지, 언제 발견했는지, 어떤 검토를 거쳐 결론을 내렸는지까지 알아야 다음 개발에 참고할 수 있습니다.
그 내용은 대부분 자유서술로 적혀 있습니다. 검토 쟁점은 회의록 PPT 안에, 판정 근거는 첨부파일 안에 있습니다. 검색으로는 안 걸립니다.
키워드 검색을 돌리면 비슷한 파일이 수십 개 나옵니다. 그중 어느 것이 이번 건과 정말 관련 있는지는 결국 열어봐야 압니다.
형상은 비슷한데 재질과 공법이 다르면 같은 해결책을 그대로 적용할 수 없습니다. 검색은 그 차이를 알려주지 않습니다. 비슷한 자료를 많이 보여주는 것과, 이번 검토에 쓸 수 있는 자료를 골라주는 것은 다른 일입니다.
그렇다고 입력 양식을 새로 만드는 방법도 잘 안 됩니다. 필드를 열 개 늘리면 현업의 입력 부담이 같이 늘고, 결국 빈칸으로 남거나 형식적으로 채워집니다.
팀리부뜨는 기업용 AI 에이전트를 구축하고 있습니다. 회사의 업무 맥락을 학습한 에이전트 하나가 사람이 하던 반복 작업을 대신 처리하는 방식입니다.
개발 조직에서는 이 에이전트가 문서를 다음 설계의 판단 재료로 바꾸는 일을 맡습니다. 국내 자동차부품 제조기업과 PLM AI 과제를 추진하며 만들고 있는 구조입니다.
[팀리부뜨 AI 에이전트의 개발 문서 처리 과정]
입구는 새 시스템이 아닙니다. 담당자가 이미 작성하고 있는 엑셀과 PPT, 검토 문서가 그대로 입구가 됩니다. 새로 적을 것을 늘리지 않는 것이 원칙입니다.
에이전트는 그 문서를 처리하는 과정에서 품목과 개정 정보, 검토 내용, 변경 사유의 후보를 뽑아 원문과 함께 남깁니다. 담당자는 뽑혀 나온 항목을 확인하거나 고치면 됩니다.
가장 중요한 것은 검토한 내용과 공식 확정된 내용을 구분하는 일입니다. 문서에 제안만 되어 있던 조치를 실제 시행한 결과처럼 기록해버리면, 이후 검색에서도 잘못된 경험을 그대로 전달하게 됩니다. 그래서 출처와 상태를 같이 보관합니다.
현재는 AI 워크스페이스와 PLM 조회 도구를 연결한 개발을 바탕으로 데이터 자산화와 과거 사례 활용을 구체화하는 단계입니다. 반복 문제를 얼마나 줄일 수 있는지는 실제 개발 업무에서 확인해나갈 부분입니다.
PLM은 그대로 씁니다. 그 안에 들어 있는 문서를 읽어 검색할 수 있는 항목으로 바꾸고, 부품과 프로젝트, 개정 이력에 연결합니다.
| 이미 남기는 자료 | 구조화할 정보 | 목표로 하는 활용 |
|---|---|---|
| 설계변경 문서 | 변경 사유, 발견 시점, 개정 | 과거 문제 이력 조회 |
| 구조검토, 시험 결과 | 검토 쟁점, 조치, 판정 상태 | 유사 사례의 조건 비교 |
| 개발 일정, 투자 계획 | 계획과 실적, 변경 이유 | 프로젝트 편차 분석 |
| 회의, 검토 기록 | 결정 사항, 근거, 후속 조치 | 인수인계와 다음 검토 |
설계 검토 시점의 선례 제시
유사 부품의 과거 문제와 조치 이력을 검토 회의 전에 미리 추려줍니다. 중요한 것은 비슷한 자료를 몇 개 보여주느냐가 아닙니다. 왜 이번 건과 관련 있는지, 어느 조건이 다른지를 같이 적어주는 것입니다.
설계변경 사유 정리
자유서술로 적힌 변경 사유에서 원인과 조치, 판정을 분리해 항목으로 남깁니다. 문서 한 건을 다시 읽고 요약하던 일이 에이전트가 뽑아둔 대여섯 개 항목을 확인하는 일로 바뀝니다.
개발 단계별 점검
게이트 리뷰에서 필요한 문서가 다 등록됐는지 확인하는 데서 끝내지 않고, 과거 유사 프로젝트에서 어떤 쟁점이 나왔는지를 같이 꺼냅니다. 체크리스트를 채우는 점검이 아니라 놓친 것을 찾는 점검이 됩니다.
인수인계와 담당자 변경
담당자가 바뀔 때 전달되는 것은 보통 폴더와 파일 목록뿐입니다. 변경 사유와 검토 쟁점이 항목으로 남아 있으면 후임자가 직접 조회해 배경을 파악하고, 정말 애매한 것만 골라 물어볼 수 있습니다.
개발팀 밖의 업무까지
같은 에이전트가 서류 업무에도 붙습니다. 무역 서류 자동화를 도입한 한 기업의 담당자는 원래 불편했던 지점을 이렇게 말했습니다. "문서는 많은데, 이 오더 자체가 한눈에 안보였어요." 개발 문서에서 겪는 답답함과 같은 이야기입니다.
오래된 문서를 전부 정리한 뒤에 시작할 필요는 없습니다. 내용을 확인해줄 담당자가 아직 있는 최근 프로젝트 하나로 먼저 검증하는 방법이 훨씬 빠릅니다. AI가 찾아낸 문제와 조치, 판정이 원문과 맞는지만 보면 됩니다.
지난 개발에서 다시 찾고 싶은 자료가 있다면, 어디까지 자동화가 가능한지 팀리부뜨의 산업 AI 자동화 전문가와 함께 정리해보세요. 현재 쓰는 PLM과 개발 문서 양식을 같이 공유해주시면 범위를 더 빨리 잡을 수 있습니다.
상담문의 시 "PLM 시스템 글을 보고 문의했다"고 남겨주시면 보다 원활한 상담이 가능합니다.
이 글은 국내 자동차부품 제조기업과 추진 중인 PLM AI 과제의 개발 방향을 소개합니다. 과거 사례 추천과 효과 검증은 단계적으로 추진하는 범위입니다.
%202.png){kind=logo}
