바이어별 납품사양서 버전 관리와 ERP·MES BOM-Variant 연동 — 같은 제품을 다르게 납품할 때

같은 반제품을 쓴다고 같은 제품으로 관리할 수 있는 것은 아니다.

공장에서 생산하는 내용물은 동일해도 대형마트 PB에는 600g, 편의점에는 120g, 프랜차이즈에는 1kg 벌크로 공급할 수 있다. 포장재가 다르고 바코드가 다르며 표시사항·박스입수·소비기한 인쇄위치·출하검사 기준도 달라질 수 있다. 수출제품이라면 언어와 표시형식, 포장규격이 다시 달라진다.

이 상태에서 생산팀이 “내용물은 같으니까 같은 제품”이라고 판단하면 Master Data와 현장의 기준이 갈라지기 시작한다.

식품 제조에서 바이어별 납품사양서는 단순한 영업문서가 아니다. 무엇을 어떤 조건으로 생산하고, 어떤 자재로 포장하며, 어떤 기준으로 검사해 어느 고객에게 납품할 것인지를 정의하는 Manufacturing Specification에 가깝다.

같은 반제품에서 여러 개의 ’판매 가능한 제품’이 만들어진다

반제품 A를 하나 생산한다고 하자. 바이어 X는 500g, 바이어 Y는 600g, 바이어 Z는 동일한 500g이지만 자체 PB 필름과 별도의 물류 바코드를 쓴다. 내용물 Recipe는 같을 수 있다. 그러나 완제품 관점에서는 서로 다른 Specification이다.

• 포장 중량이 다르다
• 포장재 품목이 다르다
• 입수가 다르다
• Customer Part Number가 다르다
• Label Version이 다르다
• 검사기준도 다를 수 있다

따라서 이를 하나의 완제품코드와 하나의 BOM으로 관리하면서 작업지시서 비고란에 대형마트용 편의점용 수출용이라고 적는 방식은 생산량이 늘어날수록 위험해진다. 사람이 비고란을 읽고 차이를 기억해야 하기 때문이다.

납품사양서는 계약과 생산 사이에 존재한다

바이어가 보내는 제품규격서에는 제품명과 중량만 들어 있는 게 아니다. 다음이 포함될 수 있다.

• 원재료 또는 주요 성분조건 / 제품규격
• 포장단위 / 포장재 Specification / 바코드 / Box 입수
• 보관조건 / 소비기한 / 표시방법
• 검사기준 / 납품조건

문제는 이 문서가 계속 개정된다는 것이다. 처음 계약했을 때 Rev.01이었는데 포장재 변경으로 Rev.02가 되고, 이후 바코드 변경으로 Rev.03이 될 수 있다. 그런데 영업팀에는 Rev.03, 품질팀 서버에는 Rev.02, 생산현장 파일철에는 Rev.01이 남아 있으면 공장은 세 가지 기준으로 같은 제품을 관리하고 있는 셈이다.

이 상태에서는 작업자가 실수한 게 아니라 시스템이 서로 다른 정답을 동시에 허용한 것이다.

Revision Control의 핵심은 최신 파일을 찾는 게 아니다

버전 관리를 단순히 파일명 뒤에 날짜를 붙이는 것으로 생각해서는 안 된다. 제품규격서_최종.pdf → 제품규격서_최종수정.pdf → 제품규격서_최종수정2.pdf 같은 방식은 Revision Control이 아니다.

실제 관리에서는 각 개정본이 어느 시점부터 유효한지를 알아야 한다. Rev.03이 9월 1일 승인됐다고 해서 8월 30일 생산분까지 Rev.03 기준으로 평가하면 안 된다. 따라서 Specification Master에는 최소한 Revision No., 승인상태, Effective Date, 개정사유와 고객 승인 여부가 연결돼야 한다.

여기에서 중요한 개념이 Effective Revision이다. 가장 최근에 만들어진 Version과 현재 생산에 적용해야 하는 Version은 항상 같지 않다. Rev.04가 이미 작성됐더라도 바이어 승인을 기다리고 있다면, 현재 생산은 여전히 승인된 Rev.03으로 진행해야 할 수 있다. 그래서 시스템은 Latest Version보다 Effective Approved Version을 찾아야 한다.

바이어 요구사항이 법적 Product Master를 덮어쓰면 안 된다

바이어가 요구한다고 모든 Specification을 그대로 적용할 수 있는 게 아니다. 식품의 표시사항에는 법령과 식약처 고시에 따라 관리해야 하는 내용이 존재한다. 현행 표시기준은 식품유형별로 제품명·식품유형·소비기한·내용량·원재료명·품목보고번호와 알레르기 유발물질 등 필요한 표시사항을 규정한다.

따라서 데이터 구조에는 우선순위가 필요하다. 가장 아래에 법적으로 승인·관리되는 Regulatory Product Master가 있고, 그 위에 제조 Recipe와 BOM이 있으며, 그 위에 고객사별 Specification과 Packaging Variant가 연결된다. 즉 바이어 Specification은 독립된 제품 정의가 아니라 법적·제조상 허용범위 안에서 고객별 차이를 정의하는 Layer로 보는 편이 적절하다.

바이어 요청 때문에 원재료나 표시내용이 달라진다면, 단순 고객사양 변경으로 끝내지 않고 품목제조보고·표시사항·알레르기·영양정보 등에 미치는 영향을 다시 검토해야 한다.

무엇을 Variant로 만들 것인지 먼저 구분해야 한다

고객사별 차이라고 해서 모든 항목을 BOM Variant에 넣을 필요는 없다. 내용물 Recipe가 달라지는 경우와 포장만 달라지는 경우를 구분하는 게 좋다.

동일한 떡 반제품을 만든 뒤 고객 A에는 500g, 고객 B에는 600g으로 포장한다면, 제조 Recipe는 공통으로 유지하고 Packaging BOM을 Variant로 나눌 수 있다. 반면 고객 B만 설탕 함량이나 특정 원료가 실제로 달라진다면 단순 포장 Variant가 아니라 별도의 Formula 또는 Recipe Version으로 관리해야 할 수 있다.

이 구분이 중요하다. 같은 반제품 + 다른 포장과 다른 배합 + 비슷한 외형을 같은 종류의 Variant로 취급하면 제조와 표시 데이터가 뒤섞인다.

Customer Part Number는 내부 품목코드와 분리해서 연결할 수 있다

바이어가 자신의 품목코드를 쓰는 경우가 많다. 우리 ERP에서는 FG-00127인데 대형마트에서는 PB-783421, 다른 거래처에서는 A004517이라고 부를 수 있다. 이때 내부 품목코드를 거래처 코드에 맞춰 계속 새로 만드는 방식보다 Internal Item Code ↔ Customer ↔ Customer Part Number의 매핑관계를 가지는 편이 관리하기 쉽다.

하나의 내부 제품이 여러 고객코드와 연결될 수도 있고, 반대로 고객사양 차이가 크다면 별도의 내부 완제품코드로 분리할 수도 있다. 중요한 것은 코드 개수를 줄이는 게 아니라 어떤 생산사양을 선택해야 하는지가 코드로 명확하게 결정되는 것이다.

BOM-Variant는 작업자가 선택하는 옵션이 되어서는 안 된다

생산지시를 발행하면서 작업자에게 “오늘은 어느 거래처용인가 확인해서 BOM을 선택하세요”라고 하면 통제력이 약해진다.

ERP에서 Sales Order 또는 Production Plan이 만들어질 때 이미 고객과 Customer Part Number가 결정돼 있다. 그 정보를 바탕으로 시스템이 해당 고객에게 유효한 Specification Revision과 BOM-Variant를 선택하는 게 좋다. 예를 들어 생산지시 WO-260905-021이 고객 A용이라면 MES는 자동으로 제품코드 · Customer Part Number · Specification Rev.03 · Recipe Rev.07 · Packaging BOM Variant A · Label Version L05를 작업지시에 Binding한다.

작업자는 무엇을 선택할지 판단하는 게 아니라 지정된 자재와 지시가 일치하는지를 확인하는 역할을 하게 된다.

구버전 포장재 투입은 현장에서 가장 현실적인 오류다

포장재가 Rev.02에서 Rev.03으로 변경됐다고 하자. 창고에는 Rev.02 필름이 12롤 남아 있고 신규 Rev.03도 입고됐다. 문서상 Rev.03으로 변경했다고 해서 현장의 Rev.02가 사라지는 건 아니다.

그래서 Specification 변경에는 기존 포장재의 처리방침까지 포함돼야 한다. 소진 가능한가 / 특정 생산일까지 쓸 수 있는가 / 사용금지인가 / 폐기할 것인가 / Return할 것인가 — 이 상태가 ERP 재고에도 반영돼야 한다.

MES에서 포장재를 Scan했을 때 해당 Work Order가 요구하는 Packaging BOM과 다른 Revision이면 경고 또는 투입차단을 수행할 수 있다. 이것이 포장공정의 Poka-Yoke다. 문서교육으로 “구형 필름 쓰지 마세요”라고 전달하는 것보다 시스템적으로 사용가능 Version을 제한하는 편이 통제력이 높다.

라벨은 같은 디자인처럼 보여도 데이터는 다를 수 있다

고객별 특수라벨에서는 육안으로 발견하기 어려운 차이가 생긴다. GS1 또는 고객 전용 바코드, 상품코드, 소비기한 표시위치, 로트 인쇄위치, 상품명, 고객 물류코드, 박스라벨 — 이 중 하나만 달라도 해당 거래처에서 입고거부가 발생할 수 있다.

더 중요한 것은 법정 표시사항이다. 현행 표시광고법 시행규칙은 소비자가 알아보기 쉽고 명확하도록 표시하도록 규정하며, 표시사항과 구체적인 표시방법은 법령과 식약처 고시에 따라 관리된다. 따라서 Label Version은 그래픽 파일명 하나로 관리할 게 아니라 제품규격서 Revision 및 실제 생산 LOT와 연결하는 게 좋다. 이 부분은 포장재 가변정보 인쇄와 오기 방지로 이어진다.

품질팀도 구버전을 보면 정상제품을 부적합으로 만들 수 있다

Version 오류는 생산에서만 발생하지 않는다. 고객 A가 허용 중량범위를 개정했다고 하자. 생산팀은 최신 Rev.04로 생산했는데 QC가 Rev.03 규격서로 검사하면 정상제품을 부적합으로 판정할 수 있다. 반대라면 더 위험하다. 생산이 구버전으로 이뤄졌는데 QC까지 같은 구버전을 가지고 있으면 제품이 정상으로 승인될 수 있다.

따라서 Production과 Quality가 별도의 Specification 파일을 가지고 있으면 안 된다. 생산지시와 출하검사 모두 동일한 Effective Specification Revision을 참조해야 한다.

수기 사양서와 ERP·MES Version Control의 차이는 파일 개수가 아니다

구분	수기·파일 중심 관리	ERP·MES Version Control
최신 사양 확인	담당자가 파일 검색	Effective Revision 자동 선택
바이어 코드	비고·파일명 관리	Customer Part No. 매핑
BOM 선택	작업자 판단	Customer/BOM-Variant 자동 Binding
포장재	육안 확인	자재 LOT·Version Scan
구버전 사용	교육·표찰 통제	유효 Version Interlock 가능
라벨	별도 파일관리	Label Version과 Work Order 연결
QC 검사기준	별도 문서 확인	동일 Specification Revision 호출
변경이력	수정파일 비교	Revision·사유·승인·Effective Date
과거 생산추적	당시 파일 재검색	LOT별 적용 Revision 조회
감사대응	이메일·파일 취합	Audit Trail 즉시 조회

ERP·MES를 도입한다고 문서가 없어지는 게 아니다. 차이는 문서가 생산 Transaction의 조건으로 작동하느냐에 있다.

변경관리에서 가장 중요한 것은 영향분석이다

바이어가 포장 중량을 500g에서 520g으로 변경해 달라고 요청했다고 하자. 단순 숫자 하나의 변경처럼 보인다. 그러나 실제로는 여러 곳에 영향을 준다.

• BOM 사용량이 바뀔 수 있다
• 박스 입수가 달라질 수 있다
• 영양정보의 표시단위가 영향을 받을 수 있다
• 포장재 디자인이 변경될 수 있다
• 제품단가와 물류단가가 달라진다
• 설비 세팅값도 수정될 수 있다

따라서 Specification Revision을 승인할 때는 단순히 문서를 승인하는 게 아니라 Change Impact를 승인하는 구조가 필요하다. 변경 대상이 Recipe라면 Regulatory Review가, 포장재라면 Label Review가, 생산조건이라면 공정·설비 영향검토가 필요하다.

생산 당시의 사양은 생산 이후에도 고정돼야 한다

Rev.05가 오늘 발효됐다고 해서 과거에 Rev.04로 생산한 LOT가 Rev.05 제품으로 바뀌는 건 아니다. 따라서 MES에는 Finished LOT가 생산될 때 적용했던 Specification Revision을 Snapshot 또는 Reference 형태로 보존해야 한다.

나중에 고객 클레임이 발생해 다음과 같은 질문을 받았을 때,

2026년 7월 12일 납품한 제품의 규격은 무엇이었습니까?

현재의 최신 규격을 보여주는 게 아니라 그 생산 당시 유효했던 규격을 보여줘야 한다. 이것이 Specification 관리의 Audit Trail이다.

사양서 개정은 승인에서 끝나지 않고 현장 전환까지 끝나야 한다

Revision Control에서 흔히 놓치는 부분이다. Rev.04가 승인됐다. 하지만 생산현장 게시판에는 Rev.03 작업표준이 남아 있고, 창고에는 Rev.03 포장재가 있고, 라벨 프린터에는 이전 Template가 남아 있고, QC 검사 Sheet도 Rev.03이다. 이 상태에서는 문서시스템만 개정됐을 뿐 공장은 아직 전환되지 않았다.

따라서 Revision의 상태를 Draft → Customer Review → Approved → Effective → Obsolete 정도로 구분하고, Effective로 전환하기 전에 관련 Master와 현장자료의 준비상태를 확인하는 구조가 유용하다.

MES 작업지시서는 사양서를 다시 쓰는 문서가 아니다

MES Work Instruction에 납품사양서 전체를 복사해 넣는 방식은 장기적으로 다시 중복관리 문제를 만든다. 작업지시서는 승인된 Master를 호출해야 한다. 작업자가 오늘 생산할 제품을 열면 고객명 · 제품 · 생산수량 · 적용 Specification Revision · 실제 Recipe · 포장중량 · 승인 포장재 · Label Version · 검사항목이 자동으로 나타난다.

Revision이 변경되면 작업지시 템플릿을 일일이 고치는 게 아니라 Master가 바뀌어야 한다. ERP Master Data와 MES Transaction의 역할을 분리하는 이유다.

출하승인은 마지막 Version Check가 되어야 한다

제품을 제대로 생산했더라도 잘못된 거래처로 보내면 같은 문제가 발생한다. 따라서 출하단계에서는 완제품 LOT에 기록된 Customer Specification과 주문의 Customer Part Number가 맞는지 확인할 수 있다. 고객 A 전용 PB 제품을 고객 B 주문에 할당하지 못하도록 하는 것이다.

여기에 제품의 Quality Status, 소비기한 잔여조건과 거래처별 출하요건까지 함께 적용하면 출하검사와 물류통제가 같은 Master Data를 보게 된다. 이 구조는 유통사 품질실사 대응에서도 강한 증빙이 된다. 감사관이 특정 바이어 제품을 지정하면, 해당 제품이 어느 Specification Revision으로 생산됐고 어떤 자재와 Label Version이 쓰였는지 LOT 단위로 설명할 수 있기 때문이다.

결국 필요한 것은 ’제품 하나’가 아니라 Specification Matrix다

고객별 제품이 늘어날수록 품목코드를 무작정 늘리는 방식에도 한계가 있다. 반대로 모든 것을 하나의 품목코드에 넣고 비고란으로 관리하는 방식은 더 위험하다. 따라서 식품 ERP의 Master Data에서는 제품을 여러 Layer로 보는 게 유용하다.

• 법적 제품정보를 관리하는 Regulatory Master
• 실제 배합을 관리하는 Recipe 또는 Formula
• 포장자재를 관리하는 Packaging BOM
• 고객별 차이를 정의하는 Customer Specification과 BOM-Variant

MES는 Production Order가 발행될 때 이 관계에서 해당 고객·해당 생산일에 유효한 조합만 선택한다.

결국 바이어별 납품사양서 버전 관리의 목적은 최신 PDF를 잘 보관하는 게 아니다. 고객 주문이 생산지시로 바뀌는 순간, 사용할 Recipe·포장재·라벨·검사기준이 하나의 승인된 Version으로 자동 결정되게 만드는 것이다.

표시(Labeling)는 그 Version이 실제 포장에 정확히 표현되는지를 통제하고, ERP Master Data는 Customer Part Number와 BOM-Variant의 관계를 관리하며, 감사 대응은 과거 생산 LOT에 어떤 사양이 적용됐는지를 증명한다. 이 세 영역을 MES Work Instruction과 연결하면 작업자는 수십 장의 고객사양서를 외울 필요가 없다. 시스템이 현재 작업에 허용된 자재와 기준만 보여주고, 다른 자재가 투입될 때 차단하면 된다.

좋은 Specification Management는 작업자에게 최신 사양서를 잘 읽도록 요구하는 체계가 아니라, 구버전 사양으로 생산하기 어려운 구조를 만드는 것이다.