업무 시스템 기초 4/4 · 시제가 공급망 소프트웨어를 하나로 만든 이유: 벤더와 공장이 같은 오더 기록을 쓰는 구조
핵심 요약
3편에서 본 문제의 뿌리는 회사마다 쓰는 시스템이 다르다는 점보다, 회사와 회사를 이어 주는 공통의 기록이 없다는 점이었어요. 시제는 시스템과 시스템을 하나씩 연결하는 대신, 벤더 본사와 제조 공장이 오더 하나를 같은 기록으로 관리하는 쪽을 택했어요. Monolis는 수주부터 원가, 자재, 생산 계획, 생산 실적, 선적, 정산까지 공급망 전반을 하나의 오더 기록 위에서 통합하는 클라우드 솔루션이에요. 1편에서 본 ERP, APS, MES, WMS의 기능을 벤더와 공장이 함께 쓰고, 바이어의 P/O는 PDF를 올리면 오더 정보로 바뀌어요. 공장 라인의 실적은 Monolog가 계측해 같은 오더 번호 아래로 보내요.
1편에서는 PLM, ERP, APS, MES, WMS가 각각 무엇을 관리하는지를, 2편에서는 이 시스템들이 제조산업에서 왜 따로 자랐는지를, 3편에서는 의류 오더가 바이어, 벤더, 제조 공장의 시스템을 지나며 어디서 사람이 다시 입력하게 되는지를 정리했어요.
3편의 결론은 이랬어요. 회사마다 다른 시스템을 쓰는 것 자체보다, 회사 사이를 이어 주는 공통의 기록이 없다는 점이 더 근본적인 원인이에요. 이번 마지막 글에서는 시제가 이 문제를 어떻게 풀었는지를 정리할게요.
시스템을 잇기 전에 기록을 하나로
3편에서 본 것처럼 거래처끼리 시스템을 하나씩 직접 연결하면, 거래처가 늘어날수록 연결 수가 훨씬 빠르게 늘어나요. 시제는 연결을 늘리는 대신 기록을 하나로 모으는 쪽을 택했어요. 이런 기록을 단일 기준 기록(SSOT, Single Source of Truth)이라고 불러요. 같은 정보를 여러 곳에 따로 저장하지 않고 한 곳에만 두고, 필요한 사람이 모두 그 한 곳을 보고 고치는 방식이에요.
병원의 전자 차트를 떠올리면 쉬워요. 접수 직원은 인적 사항을, 간호사는 혈압과 체온을, 의사는 진단과 처방을, 약사는 조제 내역을 같은 차트에 적어요. 각자 자기 메모장에 적고 다음 사람에게 사진을 찍어 보내는 병원은 없어요. 누가 언제 무엇을 적었는지도 차트에 남아요.
의류 오더에서 이 차트에 해당하는 것이 오더 기록이에요. 오더번호, 스타일, 컬러와 사이즈별 수량, 납기가 한 번 등록되면, 원가와 자재 발주, 라인 배정, 생산 실적, 선적, 정산이 모두 그 오더 아래에 쌓여요. 벤더 본사와 제조 공장은 같은 오더를 열고 각자 맡은 부분을 입력해요.
Monolis가 맡는 구간
Monolis는 벤더 본사와 해외 제조 공장이 수주부터 정산까지 하나의 오더 기록 위에서 공급망 전반을 통합해 관리하는 클라우드 솔루션이에요. 확정된 소개 문구로는 “주문·원가·자재·생산·선적·정산이 한 시스템에서 이어집니다. 본사와 해외 공장이 같은 화면을 봅니다.”1
메뉴는 기준정보(Master), 라이브러리(Library), 오더(Order), 자재(Material), 생산(Production), 재무(Finance), 결재(Approval), 대시보드(Dashboard)로 나뉘어 있어요.1 1편에서 정리한 다섯 시스템에 대응시키면 다음과 같아요.
| 1편의 시스템 | Monolis에서 다루는 기록 | 주로 입력하는 곳 |
|---|---|---|
| ERP | 오더 등록, 원가(CBD), 원단·부자재·외주 발주, 대금 지급, 매출·매입, 결재 | 벤더 본사 영업·자재·재무 |
| APS | 라인 사전 예약(Pre-book), 라인 배정(Assign Line), 라인별 일정 | 제조 공장 |
| MES | 일별 생산 실적(Daily Output), Monolog의 라인 실시간 실적 | 제조 공장 |
| WMS | 원부자재 선적과 입고 상태, 완제품 적재(Loading)와 선적 서류 | 벤더 본사, 제조 공장 |
| PLM | 범위 밖. 바이어 PLM의 문서를 받아 오더 기록으로 옮기는 쪽을 맡아요 | 바이어 |
1편의 다섯 시스템과 Monolis가 다루는 기록의 대응 (입력 주체는 기획 명세 기준)1
표의 마지막 줄이 중요해요. PLM은 바이어가 상품을 기획하고 사양을 관리하는 시스템이라서, Monolis는 그 역할을 대신하지 않아요. 대신 바이어가 보내는 문서를 받아서 오더 기록으로 바꾸는 입구를 맡아요.
한 오더 기록 위에서 일이 이어지는 순서
오더 하나가 Monolis 안에서 흐르는 순서를 따라가 보면 다음과 같아요.1
1. 벤더 본사 영업 담당이 오더를 등록해요. 오더 정보, 컬러와 사이즈별 수량(ASST), 자재 목록이 오더 아래에 들어가요.
2. 자재 목록과 소요량으로 원가(CBD)를 계산하고, 결재를 거쳐 원단과 부자재, 외주 가공을 발주해요.
3. 원부자재는 선적 준비, 운송 중, 입고 완료 순서로 상태가 바뀌고, 대금 지급은 매입으로 이어져요.
4. 제조 공장은 오더를 라인에 사전 예약하고 배정한 뒤, 매일 봉제와 포장 실적을 입력해요.
5. 봉제 실적은 완제품 적재 수량으로 이어지고, 선적 서류와 인보이스를 거쳐 매출로 기록돼요.
6. 선적과 정산이 끝나면 최종 원가가 확정돼요.
3편에서 본 여섯 구간과 비교하면 차이가 보여요. 작업 지시를 엑셀로 정리해 메일로 보내고, 공장이 그 파일을 다시 입력하던 구간이 없어요. 벤더가 오더와 자재 정보를 등록한 바로 그 기록을 공장이 열어 라인을 배정하고, 공장이 입력한 실적을 벤더가 같은 기록에서 확인해요.
3편의 네 가지 이유에 대한 답
3편에서 회사 사이의 연결이 어려운 이유를 네 가지로 정리했어요. Monolis가 각각을 어떻게 다루는지 정리하면 다음과 같아요.
| 3편의 이유 | Monolis에서의 처리 |
|---|---|
| 같은 오더를 부르는 번호가 회사마다 달라요 | 벤더 본사와 공장이 같은 오더 문서번호를 써요. Monolog도 라인에 배정된 오더 문서번호로 실적을 묶어요2 |
| 연결할 상대가 오더마다 바뀌어요 | 공장은 기준정보에 한 번 등록하고, 오더마다 라인 배정으로 연결해요. 거래 상대마다 새 연결을 만들지 않아요1 |
| 바이어가 형식을 정해요 | 바이어 P/O PDF를 올리면 오더 정보와 수량이 자동으로 입력돼요. 엑셀 P/O는 바이어별 형식을 정의해 받아요3 |
| 보여 줄 수 있는 범위가 달라요 | 메뉴마다 권한을 접근 불가, 조회, 편집, 편집과 승인으로 나눠 사람마다 볼 수 있는 범위를 정해요1 |
3편에서 정리한 네 가지 이유와 Monolis의 처리 방식
바이어 P/O PDF 자동 입력은 2025년 4월 베타 버전으로 배포됐어요.3 바이어 P/O 양식을 사내 형식으로 옮기는 일이 왜 어려운지는 PO 매핑, AI의 가능성과 코딩의 현실 사이에 정리해 두었어요.
현장 실적이 오더 기록으로 들어오는 길: Monolog
오더 기록이 하나여도, 공장 라인의 실적을 사람이 종이에 적어 입력한다면 3편에서 본 재입력 구간이 공장 안에 그대로 남아요. 이 구간을 맡는 것이 Monolog예요. Monolog는 공장용 스마트팩토리 솔루션으로, 봉제기 위에 올려두면 기계의 움직임과 사람의 손동작을 함께 읽어요.4
1세대 장치는 페달을 밟는 순간과 바늘이 진동하는 순간을 감지해서, 기계가 움직인 시간과 손으로 원단을 다룬 시간을 나눠 기록해요.4 2세대 장치는 태블릿 카메라로 손가락과 관절의 좌표를 읽어요. 이때 카메라는 얼굴을 촬영 범위에서 제외하고, 원본 영상은 0.5초 안에 파기해서 저장하지 않아요. 좌표 데이터만 남고, 작업자는 가명 ID로 관리되며, 휴게시간에는 수집을 멈춰요.5 Monolog의 목적은 작업자를 감시하는 것이 아니라, 라인에서 실제로 걸린 시간을 증명하는 것이에요.
이렇게 계측한 실적은 라인에 배정된 오더의 문서번호 아래로 모여요.2 표본으로 적은 숫자와 연속으로 계측한 숫자가 어떻게 다르게 쓰이는지는 현장에서 측정한 생산 정보가 사라지는 이유에서 다뤘어요. 공정별로 계측한 실측 시간(AMV)이 다음 오더의 견적 기준인 SMV 학습에 반영되면, 공정분석으로 만드는 원가의 정확도도 점점 좋아질 수 있어요.6
아직 사람이 맡는 일
모든 구간이 끝난 것은 아니에요. 바이어 PLM은 여전히 바이어의 시스템이고, TechPack PDF를 올리면 자재 목록의 원단과 부자재 항목이 자동으로 채워지는 기능은 준비 중이에요.3 선적 단계에서 바이어가 요구하는 EDI나 포털 형식에 맞추는 일도 바이어마다 달라요.
그래서 시제가 정한 순서는 이래요. 먼저 벤더와 공장 사이, 곧 사람이 가장 많이 다시 입력하던 구간을 하나의 기록으로 묶고, 바이어 쪽 문서는 그 기록으로 들어오는 입구를 하나씩 넓혀 가는 것이에요.
마무리하며
네 편에 걸쳐 ERP, MES, PLM, WMS, APS라는 이름이 무엇을 가리키는지, 제조산업에서 왜 다섯 갈래로 나뉘어 자랐는지, 의류 오더에서는 이 시스템들이 세 회사에 흩어져 어디서 끊기는지, 그리고 시제가 그 끊긴 자리를 어떻게 하나의 오더 기록으로 묶었는지를 정리했어요.
시스템의 이름보다 먼저 볼 것은 오더 하나의 정보가 몇 번 다시 입력되는지예요. 우리 회사에서 같은 오더번호와 수량을 몇 곳에 적고 있는지 세어 보면, 어디부터 하나로 묶어야 할지가 보여요.
함께 읽으면 좋은 글
- ERP, MES, PLM, WMS, APS의 차이: 의류 오더 한 건으로 정리한 다섯 가지 업무 시스템
- 제조산업 소프트웨어의 역사: MRP에서 ERP, PLM, APS, MES, WMS로 나뉜 과정
- 의류 오더가 세 회사의 시스템을 지나는 길: 기계가 읽는 구간과 사람이 읽는 구간
- 오더번호를 끝날 때까지 반복적으로 입력하는 이유
참고 자료
- 시제 내부 자료, Monolis 기획 명세(메뉴 구성, 모듈별 기능, 입력 주체, 권한 체계)와 확정 소개 문구. 2026년 9월 기준. ↩
- 시제 내부 자료, Monolog API 명세. 라인 배정 단위와 실적 집계 기준(오더 문서번호). ↩
- 시제 내부 자료, Monolis 배포 기록과 기능 정의. P/O PDF 자동 입력 베타 배포(2025년 4월), 엑셀 P/O 바이어별 형식 정의, TechPack 기반 자재 목록 자동 입력(준비 중). ↩
- 시제 내부 자료, Monolog 제품 소개 확정 문구. 1세대 장치의 계측 방식. ↩
- 시제 내부 자료, Monolog 2세대 공개 사양과 개인정보 보호 설계. ↩
- 시제 내부 자료, 실측 시간(AMV)과 표준시간(SMV)의 관계에 대한 확정 문구. ↩
