제지 구매 업무 자동화 : 자재 마스터에서 시작된 AX 확산

한솔제지의 구매 업무 자동화 프로젝트는 지급보증보험·자재 마스터·영세율 마감·선적 모니터링 네 가지 업무를 대상으로 추진되었습니다. 공통된 개선 방향은 분명합니다. 반복된 작업은 시스템이 맡고, 사람의 판단이 필요한 지점에는 AI를 연결해 업무를 다시 설계하는 것입니다.

그중에서도 이번에 주목할 사례는 자재 마스터입니다. 자재는 수천 건에 이르고, 공장마다 같은 자재를 서로 다른 이름으로 부르는 경우도 적지 않습니다. 사람이 일일이 조회하고 대조하는 방식만으로는 중복과 오류를 막기 어려웠고, 그 부담은 결국 현업과 자재팀 모두에게 누적돼 왔습니다.

이번 프로젝트는 이 문제를 단순히 "더 꼼꼼히 확인하자"는 방식으로 접근하지 않았습니다. AI가 대신 수천 건의 자재 마스터를 전수로 대조하고, 유사 자재를 찾아내며, 신청 단계와 승인 단계에서 각각 검증하도록 프로세스 자체를 다시 설계했습니다.

기존에는 신규 자재를 등록하려면 공장 담당자가 SAP에서 자재를 일일이 조회한 뒤 엑셀 요청서를 작성해 메일로 보내야 했습니다. 이후 자재팀은 요청마다 가이드 준수 여부를 확인하고, 기존 자재와의 중복 여부를 다시 검토해야 했습니다.

문제는 이 과정이 단순히 번거로운 데 그치지 않았다는 점입니다. 조회와 검색이 불편하다 보니 기존 자재가 있음에도 신규 등록 요청이 반복됐고, 공장마다 다른 명칭을 사용하면서 동일 자재가 중복 생성되는 일도 이어졌습니다.

결국 사람의 수기 확인에 의존하는 구조에서는 검증 부담이 커질수록 오류 가능성도 함께 높아질 수밖에 없었습니다.

[ 기존 자재 등록 프로세스 ]

이번 프로젝트는 자재 조회부터 신청, 처리까지의 전 과정을 다시 설계했습니다. 핵심은 각 단계에 AI 검증을 넣어 자재 등록의 정확도와 속도를 함께 높인 점입니다. 프로세스는 크게 다섯 단계로 구성됩니다.

이 구조의 의미는 단순히 AI 기능이 추가됐다는 데 있지 않습니다. 공장 담당자의 조회 방식, 자재팀의 검증 방식, 시스템의 처리 방식이 하나의 흐름 안에서 다시 정렬됐다는 점이 더 중요합니다.

현업에서 체감하는 변화는 조회 단계에서 가장 먼저 나타납니다. 담당자가 자재명·사진·견적서를 올리고 'AI 검증'을 누르면, AI Atlas가 SAP 자재 마스터를 전수 분석해 유사도 순으로 후보를 제시합니다. 그 결과는 세 가지로 자동 분류됩니다.

[ AI가 유사도 기반으로 기존 자재를 조회·판정하는 실제 화면 ]

이전에는 무엇으로 검색해야 할지부터 고민해야 했다면, 이제는 현업이 가진 자료를 그대로 올리고 AI의 검증 결과를 바탕으로 다음 단계를 진행할 수 있게 됐습니다. 검색의 출발점이 사람의 기억과 경험에서 데이터 기반 검색으로 옮겨간 셈입니다.

이는 공장 담당자의 역할도 바꿉니다. 직접 자재를 찾아내고 요청서를 작성하는 데 시간을 쓰기보다, AI가 제시한 결과를 바탕으로 더 정확한 요청을 만드는 쪽으로 역할의 중심이 이동하고 있습니다.

자재 담당자 단계에서는 AI가 한 번 더 재검증을 수행합니다. 공장 담당자가 등록을 요청하면, 자재 담당자는 AI의 검토 결과를 바탕으로 승인 또는 반려를 결정합니다. 승인된 건은 SAP에 자동 등록되고, 결과는 메신저와 메일로 요청자에게 실시간 전달됩니다.

이 과정의 가장 큰 의미는 중복을 사후 정리가 아니라 사전 차단의 문제로 바꿨다는 데 있습니다. 공장마다 다른 이름으로 불리던 동일 자재를 등록 전에 걸러내면서, 자재 마스터의 신뢰성과 일관성을 높일 수 있게 됐습니다.

자재 담당자의 역할 역시 달라집니다. 모든 요청을 처음부터 끝까지 수기로 확인하는 것이 아니라, AI가 걸러낸 결과를 바탕으로 예외를 판단하고 최종 승인에 집중하는 구조로 바뀌고 있습니다. 이는 단순한 업무 경감이 아니라, 검증 업무의 성격 자체가 바뀌고 있다는 의미이기도 합니다.

[ 자재 담당자 : AI 재검증 → 승인 시 SAP 자동 등록·실시간 알림 → 명칭이 달라 생기던 중복을 원천 차단 ]

오픈 이후 5개 공장 현업이 직접 사용하며 자재 마스터 관리 방식이 정착되고 있습니다.

※ 오픈 이후 누적 · 8/24 10시 기준 (요청 339건 = 승인 269 · 반려 24 · 처리중 46)

특히 반려율 9.2%는 부정적 지표로만 볼 필요가 없습니다. 상당수는 가이드 미준수나 기존 중복 신청에 해당하며, 오히려 AI가 중복과 오류 가능성을 사전에 걸러낸 결과이기 때문입니다. 다시 말해, 이 데이터는 단순한 처리 실적이 아니라 자재 마스터 품질이 높아지고 있다는 신호이기도 합니다.

오픈 이후 현업은 다음과 같은 변화를 직접 체감하고 있습니다.

이번 사례가 보여준 것은, AI 효과가 가장 큰 곳이 데이터가 방대하고 정형화돼 있지만, 사람이 다 대조하기에는 너무 많은 반복 업무라는 점입니다. 자재 마스터는 바로 그런 영역이었습니다. 같은 방식으로 다음과 같은 영역에 확장될 수 있습니다.

• • 마스터 데이터 표준화
  

  거래처·고객·품목 코드처럼 중복·오류가 쌓이기 쉬운 정형 데이터의 정합성 점검

• • 타 계열사 구매·자재·물류
  

  같은 성격의 대량·반복·대조 업무가 여러 계열사에 이미 존재

• • 문서·요청 자동 처리
  

  견적서·주문서 등에서 정보를 추출하고 검증하는 반복 업무

다만 이번 사례의 의미는 "AI를 어디에 붙일 수 있는가"에만 있지 않습니다. 더 중요한 것은 AI가 개입할 수 있도록 업무를 표준화하고, 검증 기준을 정리하며, 사람과 시스템의 역할을 다시 나눴다는 점입니다. 공장 담당자는 검색과 입력의 반복에서 벗어나 더 정확한 요청에 집중하게 됐고, 자재 담당자는 건건이 수기 확인하던 역할에서 예외 판단과 승인에 집중하는 역할로 이동하고 있습니다.

즉, AI 도입은 기능 추가가 아니라 역할과 프로세스의 재설계를 동반합니다. 결국 AX는 "조직을 바꿔야 한다"는 선언만으로 이루어지지 않습니다. 어떤 업무 단위에 AI를 연결할지, 그에 맞춰 검증과 승인 흐름을 어떻게 다시 설계할지, 사람의 역할을 어디에 집중시킬지를 구체적으로 정할 때 비로소 실행 가능한 변화가 됩니다.

이번 자재 마스터 사례는 그 점에서 분명한 힌트를 줍니다. Agent의 성능만 높인다고 AX가 완성되는 것이 아니라, Agent가 작동할 수 있도록 데이터와 프로세스를 정비하고, 그에 맞춰 조직의 역할까지 함께 조정할 때 비로소 변화는 확산됩니다.

같은 말, 다른 뜻 — 온톨로지로 AI에 업무의 맥락을 더하다

지난 8월호에서 우리는 AI 활용을 넓혀갈수록 판단 기준을 규칙으로 정리하는 일이 중요하다고 말씀드렸습니다. 이번 호는 그 다음 이야기입니다.

규칙이 제대로 작동하려면, 규칙이 쓰는 말의 뜻부터 같아야 합니다.

이번 호에서는 AI에 업무의 뜻과 관계를 알려주는 방법, '온톨로지(Ontology)'를 소개합니다.

같은 '납기'라는 말이라도 영업에서는 고객에게 약속한 날짜를, 생산에서는 제품을 완성할 예정일을, 물류에서는 출하 예정일을 떠올릴 수 있습니다. 서로 연결된 일정이지만 같은 날짜는 아닙니다. AI에게 "납기가 늦어질 주문을 찾아줘"라고 요청한다면, 어떤 날짜를 기준으로 판단해야 할까요?

[ 같은 '납기', 세 개의 날짜 (가상 예시) ]

AI도 용어와 기준이 명확하지 않으면, 서로 다른 의미의 데이터를 혼동할 수 있습니다. 날짜마다 무슨 뜻인지 정해져 있지 않으면, AI는 그럴듯하지만 기준이 다른 답을 내놓을 수 있습니다.

[ 뜻이 여러 개인 용어 수에 따른 해석 조합 (산술 계산) ]

AI가 문맥으로 일부를 걸러내더라도, 뜻이 정의돼 있지 않으면 어느 조합이 맞는지 확인할 근거가 없습니다. 가상의 이야기만은 아닙니다. 장항공장의 공정 데이터를 정리하면서도 생산계획·지폭조합·작업지시처럼 이름은 비슷하지만 서로 다른 것들이 확인됐습니다.

온톨로지는 업무에 등장하는 대상의 의미와 관계를 정리한 모델입니다. '고객 주문'이 무엇이고, 어떤 '제품'을 필요로 하며, 그 제품이 어떤 '자재'와 '설비'로 만들어지는지 연결합니다. 회사에서 쓰는 말을 시스템도 일관되게 해석하도록 준비하는 일입니다.

기존 데이터 모델에도 의미와 관계가 있습니다. 온톨로지는 이를 명시하고 여러 업무에서 일관되게 활용하도록 돕습니다.

[ 온톨로지 한눈에 보기 : 업무 데이터 → 대상·속성·관계 → AI의 업무 활용 ]

온톨로지는 데이터 분야에서 20년 넘게 발전해 온 개념이지만(부록 참고), 지금 다시 살펴볼 이유는 만드는 방법과 쓰는 주체가 함께 바뀌었기 때문입니다.

▲ LLM 등장을 기점으로 달라진 온톨로지의 제작 방식과 활용 주체

국내에서도 특정 업무의 경험을 그룹으로 넓히는 흐름이 보입니다. HD현대는 2026년 1월 팔란티어와의 협력을 그룹 전반으로 확대한다고 발표했고,¹ LG CNS도 2026년 3월 LG 계열사의 품질관리 적용을 바탕으로 협력 확대와 전담 조직 구성을 추진한다고 밝혔습니다.²

다만 플랫폼 도입이나 협력 확대가 모든 업무의 검증 완료를 뜻하지는 않습니다. AI가 활용할 용어와 관계를 정확히 정의하고, 데이터의 품질·갱신 기준·실행 권한을 업무별로 검증해야 합니다.

제지 장항공장에서는 AX 추진 T/F가 현장과 함께 품질 클레임 대응을 개선하고 있습니다. 여러 시스템에 데이터와 연결 정보가 있었지만 원인 추적에 필요한 관계와 예외를 한눈에 확인하기 어려워, 21개 공정 단계의 데이터·설비·제어시스템, 현장 용어와 전산 코드, 점보롤·롤·제조번호의 연결을 항목별 근거·검증 상태와 함께 정리한 '공정별 데이터 레이어 맵'을 만들었습니다.

뜻과 관계가 정리되면 AI가 할 수 있는 일이 달라집니다. 품질 클레임을 받으면 제조번호에서 생산 LOT·롤·점보롤의 이력을 찾고, 해당 호기의 생산 시간대와 검사 결과를 맞춰 확인해야 합니다(그림). AI는 확인된 연결을 따라 근거를 모으고, 원인 판단은 담당자가 합니다.

[ 품질 클레임 역추적 경로 (장항공장 사례 기반 개념도 - 일반 경로를 단순화) ]

레이어 맵에서 온톨로지까지

온톨로지는 보통 여섯 단계를 거쳐 만들어집니다. 레이어 맵은 그중 조사·정리 단계의 산출물이며, 항목마다 근거와 검증 상태가 붙어 있어 다음 단계로 바로 이어집니다.

[ 온톨로지 구축 6단계와 레이어 맵의 위치 ]

레이어 맵이 ①~③ 단계를 맡고, 대표 클레임 하나로 ④ 개념 모델과 ⑤ 데이터 검증을 시작하는 것이 다음 순서입니다. 조사 결과마다 근거와 검증 상태를 붙여 둔 덕분에, 어디서부터 이어 가야 할지가 이미 드러나 있습니다.

8월호에서 판단 기준을 규칙으로 정리하는 일을 AX의 기초 공사라고 말씀드렸습니다. 온톨로지는 그 규칙이 쓰는 말의 뜻과 관계를 정리하는 일입니다. 규칙이 "고객 약속일 3일 전까지 지연 가능성을 알린다"라면, 온톨로지는 '고객 약속일'이 무엇이고 어떤 주문·작업지시와 이어지는지를 정의합니다.

출발점은 이미 관리하는 기준정보와 업무 규칙입니다. 그룹 데이터 플랫폼과 ATLAS가 여러 시스템의 데이터를 연결하고 있고, 안전관리 TBM AI Agent는 작업·위험요인·대책의 관계를 다루고 있습니다. 장항공장 사례처럼 대표 질문 하나에서 시작해 검증한 뒤 범위를 넓히는 것이 좋겠습니다.

현업은 용어의 뜻과 예외를 설명하고, IT는 이를 데이터와 연결해 검증하며, 경영진은 해결할 문제의 우선순위와 부서 간 합의를 지원합니다.

각 사에서 AX 과제를 발굴하실 때, 8월호에서 부탁드린 "이 업무의 판단 기준이 정리되어 있는가"와 함께 "이 업무의 핵심 용어가 부서마다 같은 뜻인가"도 봐 주시기 바랍니다.

진행 중인 'AI Festival 2026'에서 AI 코딩 도구로 업무 도구를 만들어 보는 경험은 현장의 아이디어를 구현하는 기회입니다. 이 도구들이 여러 부서의 데이터를 활용하려면, 우리가 쓰는 말과 업무의 관계도 명확해야 합니다.

▶ 주요 근거
¹ HD현대·팔란티어 공동 발표 (2026. 1. 20.)  ² LG CNS·팔란티어 공동 발표 (2026. 3. 11.)
W3C OWL · Palantir Ontology 공식 문서 · AI 활용 온톨로지 연구 (2026. 4.)
내부 사례 : 장항공장 AX 추진 T/F 공정별 데이터 레이어 맵 (2026년 9월 기준, 작성 중)

W3C 표준 : 2004 OWL 1 → 2009 OWL 2(2012 개정 2판) → 2014 RDF 1.1 · JSON-LD

전사 전체를 한 번에 정의하기보다, 실제 업무에서 필요한 범위부터 검증하며 확장하는 접근이 중요합니다.

대표 활용을 구분한 참고 자료이며, 서로 배타적인 발전 단계나 각 기술의 시작 시점을 뜻하지 않습니다.
출처 | W3C 권고안(OWL·RDF), schema.org, 각 표준기구 공개 자료