모호한 구두 협의와 요약형 계약서로 인해 발생하는 과업 범위(SOW) 분쟁의 근본 원인을 분석하고, 데이터 입출력과 설비 연동 경계를 명확히 규정하는 기능 명세서 첨부 기술을 통해 저렴한 초기 도입비로 안전하게 제조 시스템을 안착시키는 가이드를 제시합니다.
1. 도장 찍은 날부터 시작되는 제조 현장의 동상이몽
제조 기업의 대표이사나 공장장, 그리고 전산 담당자가 스마트 공장 도입을 결심하고 공급 기업과 마주 앉는 순간은 늘 부푼 기대로 가득 차 있습니다. 수많은 회의를 거치고, 제안서를 검토하며, 화면 예시를 보면서 “이제 우리 공장도 주먹구구식 엑셀 작업에서 벗어나 데이터 기반으로 굴러가겠구나” 하는 확신을 갖게 됩니다. 그리고 수십 장에 달하는 표준 용역 계약서의 마지막 장에 날인을 마칩니다.
그런데 참으로 이상한 일은, 바로 그 계약서에 도장을 찍은 직후부터 양측의 시선이 완전히 엇갈리기 시작한다는 점입니다.
프로젝트 중반을 넘어서며 화면 개발이 본격화되면 현장에서는 탄식이 터져 나옵니다.
“부장님, 개발사가 가져온 화면을 보니까 우리 현장에서 쓰는 특수 바코드 재발행 기능이 아예 없는데요?”
“이게 무슨 소리야? 당연히 바코드로 입출고를 관리한다고 계약서에 써놨는데 그게 왜 빠져?”
개발사에 따져 물으면 돌아오는 대답은 차갑고 단호합니다.
“고객사님, 계약서 첨부 과업 범위(SOW)에는 ‘표준 자재 바코드 스캔 및 입고 처리’라고만 명시되어 있습니다. 현장 불량 시 재발행하거나 임의 로트를 분할해 재발행하는 기능은 기본 범위에 없는 추가 커스터마이징 항목입니다. 개발을 원하시면 추가 변경 계약(Change Order)과 추가 공수 비용을 책정해 주셔야 합니다.”
순식간에 회의실은 고성과 불신으로 얼룩집니다. 공장 측에서는 “기본적인 상식조차 안 갖춰진 반쪽짜리 프로그램을 만들어 놓고 돈을 더 내놓으라는 거냐”며 분통을 터뜨리고, 개발사는 “애초에 제시된 예산과 기간 내에서 합의된 규격대로 만들었을 뿐인데 무리한 추가 요구를 한다”며 개발을 중단하겠다고 맞섭니다. 결국 프로젝트 완료 예정일은 하염없이 밀리고, 잔금 지급을 둘러싼 내용증명이 오가며 법적 분쟁의 문턱까지 치닫게 됩니다.
도대체 어디서부터 잘못된 것일까요? 왜 수많은 제조 기업들이 철저한 MES 구축 계약서 점검 과정 없이 일을 시작했다가 이와 같은 뼈아픈 수업료를 치르는 것일까요?
2. 당연하다는 착각을 깰 때 비로소 드러나는 소프트웨어의 실체
우리가 기계 설비를 살 때는 이런 분쟁이 거의 일어나지 않습니다. 선반이나 밀링기, 사출기를 발주할 때는 설비의 가로·세로 규격, 최대 분당 회전수(RPM), 가압 톤수, 사용 전력, 모터 제조사까지 밀리미터 단위로 적힌 사양서가 계약서 뒤에 한 묶음으로 붙습니다. 설비가 공장 바닥에 안착했을 때 사양서와 단 1cm만 달라도 납품 거부 사유가 명확합니다. 실체가 눈에 보이는 물리적 장비이기 때문입니다.
하지만 소프트웨어는 눈에 보이지 않습니다. 코드가 완성되어 화면에 뜨기 전까지는 양쪽 모두 머릿속에 각자의 그림을 그리고 있을 뿐입니다.
여기서 치명적인 비극이 발생합니다. 고객사는 ‘MES(제조실행시스템)’라는 단어 안에 자신의 공장에서 일어나는 모든 일상적인 예외 상황—자재가 잘못 들어왔을 때의 반품 흐름, 작업자가 실수로 잘못 찍었을 때의 취소 절차, 야간 작업 시의 긴급 대체 투입—이 마법처럼 전부 포함되어 있을 것이라고 지레짐작합니다. 반면 공급 개발사는 계약서에 적힌 ‘재고 관리’, ‘생산 실적 등록’이라는 몇 줄의 활자를 자신들이 보유한 가장 단순한 기본 패키지 기능으로 해석합니다.
근본적으로 파고들어가 보면 소프트웨어란 복잡한 마술이 아닙니다. 소프트웨어의 본질은 지극히 단순한 세 가지 요소의 결합입니다.
- 입력(Input): 어떤 데이터를, 어떤 장치를 통해, 어느 타이밍에 집어넣는가?
- 연산 및 처리(Process): 시스템이 그 데이터를 어떤 규칙과 조건식으로 가공하고 검증하는가?
- 출력(Output): 그 결과로 화면에 무엇을 보여주고, 어떤 데이터베이스 테이블에 저장하며, 다른 장비에 어떤 신호를 쏘아주는가?
소프트웨어 개발에서 ‘당연한 것’이란 세상에 존재하지 않습니다. 시스템에 규칙을 하나하나 가르쳐주지 않으면 컴퓨터는 아무것도 판단하지 못합니다.
결국 과업 범위(Scope of Work, SOW) 분쟁이란 대단히 고차원적인 철학적 갈등이 아닙니다. ‘입력과 처리와 출력의 규칙’을 사전에 활자화하여 못 박아두지 않은 채, 서로가 상대방의 머릿속 생각을 읽고 있을 것이라 믿어버린 게으름이 만들어낸 필연적인 사고입니다.
3. 모호한 계약서의 세 가지 함정과 분쟁의 메커니즘
수많은 실패 사례를 들여다보면 계약서와 첨부 문서에서 공통적으로 발견되는 대표적인 독소 조항과 모호한 표현들이 있습니다. 성공적인 프로젝트를 이끌기 위해서는 전문적인 MES 구축 계약서 점검 단계에서 이러한 문장들을 찾아내 완전히 해체해야 합니다.
첫 번째 함정: “기타 상호 협의에 따른다”는 백지위임
계약서 특약이나 과업 지시서 말미에 단골로 등장하는 문구입니다. 겉으로 보기에는 양사 간의 원만한 협력을 유도하는 아름다운 배려처럼 보이지만, 실제로는 분쟁의 뇌관입니다. ‘상호 협의’란 어느 한쪽이 거부하면 아무것도 진행할 수 없다는 뜻과 같습니다. 고객사는 “협의해 주기로 했으니 당연히 해줘야 한다”고 압박하고, 공급사는 “우리는 동의한 적 없으니 못 한다”고 버팁니다. 결국 힘의 논리에 의해 을이 마지못해 날림으로 기능을 때워 넣거나, 갑이 소송을 불사하는 파국으로 이어집니다.
두 번째 함정: 추상적인 서술형 기능 정의
“현장의 원활한 생산을 위한 실시간 모니터링 기능 제공”, “직관적인 재고 이력 추적 체계 구축” 같은 문장들입니다. ‘원활한’의 기준은 초당 몇 건의 데이터를 랙 없이 처리하는 것입니까? ‘직관적인’의 기준은 마우스 클릭 몇 번 안에 원하는 데이터가 조회되는 것을 의미합니까? 수치와 조건이 빠진 수식어는 개발자에게 아무런 기술적 지침을 주지 못하며, 훗날 검수 단계에서 “우리가 생각한 원활한 수준이 아니다”라는 주관적 불만의 빌미가 됩니다.
세 번째 함정: 시스템 간 연동의 책임 경계 부재
MES는 홀로 떠 있는 외딴섬이 아닙니다. 위로는 기존 ERP 및 회계 프로그램과 손을 잡아야 하고, 아래로는 현장 생산 설비의 PLC, 온도 컨트롤러, 비전 검사기, 바코드 리더기, 전자저울과 신호를 주고받아야 합니다.
그런데 계약서에 단순하게 “설비 인터페이스 구축 1식”이라고 적어두면 반드시 싸움이 납니다. 설비 PLC에서 데이터를 올려주는 통신 모듈 비용은 누가 부담하는가? PLC 프로그램 수정(래더 수정)은 설비 제조사가 하는가, MES 개발사가 하는가? 통신 패킷이 깨졌을 때 재전송 로직은 누가 책임지는가?
세계적인 프로젝트 관리 연구 기관인 프로젝트 관리 협회(PMI, Project Management Institute)의 글로벌 표준 지침서에서도 프로젝트 실패의 가장 큰 단일 원인으로 ‘모호한 범위 정의(Scope Creep)와 문서화되지 않은 인터페이스 경계’를 꼽고 있습니다. 경계선이 명확하지 않은 작업은 반드시 작업 지연과 비용 전가 분쟁을 불러일으킵니다.
도입 전 단계에서 이러한 잠재적 위험을 철저히 걷어내고, 공장의 언어와 개발의 언어를 완벽하게 일치시키는 작업이 선행되어야만 안심하고 현장을 혁신할 수 있습니다.
👉 엠이에스코리아 전문 컨설턴트에게 시스템 구축 범위 무료 상담받기
4. 분쟁을 원천 봉쇄하는 기능 명세서(Functional Spec) 첨부 4대 원칙
그렇다면 어떻게 해야 계약서라는 활자 뭉치를 공장을 지키는 강력한 방패로 만들 수 있을까요?
해답은 단순한 2~3장짜리 견적서나 과업 요약서 대신, 시스템의 물리적 동작을 규정한 ‘상세 기능 명세서’를 계약서의 쪼갤 수 없는 필수 부속 합의서로 묶어버리는 것입니다.
공장의 업종이 금속을 깎는 정밀 가공이든, 플라스틱을 찍어내는 사출 성형이든, 케미컬 배합이든, 다단계 전자 부품 조립이든 상관없습니다. 모든 제조 공정에 범용적으로 적용되는 기능 명세서 작성의 본질적 4대 원칙을 정리해 드립니다.
[ 과업 범위(SOW) 분쟁을 차단하는 기능 명세서 핵심 구조 ]
+-----------------------------------------------------------+
| 1. UI 와이어프레임 & 데이터 필드 정의 |
| - 화면 구성 요소, 필수 입력값, 버튼별 동작 정의 |
+-----------------------------------------------------------+
│
▼
+-----------------------------------------------------------+
| 2. 인터페이스 책임 경계선 분할 (API / 통신 프로토콜) |
| - PLC, ERP, 계측기 연동 시 물리적 데이터 인계점 확정 |
+-----------------------------------------------------------+
│
▼
+-----------------------------------------------------------+
| 3. 비즈니스 로직 및 예외 상황(Exception) 처리 규칙 |
| - 작업자 오입력, 통신 단절 시 데이터 보존 및 롤백 |
+-----------------------------------------------------------+
│
▼
+-----------------------------------------------------------+
| 4. 수치화된 완료 판정 기준 (Acceptance Criteria) |
| - 시나리오 기반 검수 조건, 동시 접속 응답 속도 규정 |
+-----------------------------------------------------------+
원칙 1: 화면(UI) 와이어프레임과 필드 속성을 1:1로 매핑하라
메뉴 목록에 ‘작업 지시 등록 화면’이라고 한 줄 적는 것으로 끝내서는 안 됩니다.
투박한 손그림이라도 좋으니画面에 어떤 항목들이 배치되는지 와이어프레임을 첨부해야 합니다.
- 이 화면에서 보여줄 품목 코드, 품명, 지시 수량, 납기일 필드는 필수 입력 항목인가, 선택 항목인가?
- 품목 코드를 직접 키보드로 치는가, 팝업 창을 띄워 검색하는가, 바코드를 찍어 자동 완성하는가?
- 지시 수량에 음수(-)나 문자가 들어갔을 때 시스템은 어떤 경고 메시지를 띄우며 차단할 것인가?이처럼 화면 단위로 입출력 규칙을 못 박아두면, 나중에 “이 버튼이 왜 여기에 있냐”, “왜 이 데이터가 한눈에 안 보이냐”는 식의 소모적인 감정싸움이 일어날 틈이 사라집니다.
원칙 2: 인터페이스 연동의 물리적 분계점을 도표화하라
설비나 기존 프로그램과의 연동에서는 ‘우편함’의 비유를 기억하셔야 합니다.
MES 개발사가 공장 설비의 내부 배선을 일일이 따서 신호를 분석해 줄 수는 없습니다. 마찬가지로 설비 제작사가 MES의 데이터베이스 구조를 알 수도 없습니다.
따라서 기능 명세서에는 두 주체가 만나는 명확한 데이터 우편함을 정의해야 합니다.
- “공급사는 지정된 IP와 포트로 TCP/IP 소켓 서버를 열어둔다.”
- “설비 측(고객사 측) 엔지니어는 완제품 1개 생산 완료 시마다 [시리얼번호, 합불판정, 측정값]을 쉼표로 구분한 문자열 규격에 맞춰 해당 포트로 전송한다.”
- “데이터가 정상 수신되면 MES는 ‘ACK’ 신호를 설비로 되돌려주고, 설비는 이 신호를 받은 후에만 다음 제품을 컨베이어로 이송한다.”이와 같이 데이터의 인계점(Hand-shake)을 규정해 두면, 통신이 안 될 때 설비 문제인지 소프트웨어 문제인지 테스터기 하나로 10초 만에 책임 소재를 가려낼 수 있습니다.
원칙 3: 정상 흐름보다 ‘예외 상황(Exception Handling)’을 더 꼼꼼히 적어라
개발자가 만든 데모 프로그램은 언제나 완벽하게 돌아갑니다. 이상적인 조건에서 이상적인 순서로만 버튼을 누르기 때문입니다. 하지만 실제 공장은 먼지와 소음, 그리고 작업자의 실수로 가득 찬 거친 세계입니다.
- 작업자가 바코드를 두 번 연속으로 중복 스캔했을 때 시스템은 어떻게 튕겨낼 것인가?
- 네트워크가 일시적으로 끊겼을 때 현장 키오스크는 작업을 중단할 것인가, 로컬 메모리에 데이터를 임시 저장했다가 재접속 시 일괄 업로드할 것인가?
- 이전 공정 검사가 ‘불합격’ 처리된 로트 번호가 후공정 설비에 물렸을 때 설비 가동 인터록을 어떻게 발생시킬 것인가?훌륭한 기능 명세서는 행복한 성공 시나리오보다 비정상적인 돌발 상황에 대한 처리 규칙을 기술하는 데 70%의 지면을 할애합니다.
원칙 4: 주관적 형용사를 배제하고 ‘수치화된 인수 검수 조건’을 걸어라
프로젝트의 종료는 개발사의 “다 만들었습니다”라는 선언으로 끝나는 것이 아니라, 고객사의 ‘검수 확인서 서명’으로 완성됩니다. 검수 기준이 모호하면 양사 모두 고통에 빠집니다.
- 나쁜 예: “시스템은 안정적인 성능을 보장하며, 현장 업무에 무리가 없어야 한다.”
- 좋은 예: “단말기 30대에서 동시에 생산 실적 등록 버튼을 눌렀을 때 응답 시간은 1.5초 이내여야 한다. 시나리오 테스트 케이스 50개 항목 중 치명적 결함(시스템 다운, 데이터 유실)이 0건이고, 경미한 결함(오탈자, 정렬 불량)이 3건 이하일 때 최종 검수를 승인한다.”
국내에서도 소프트웨어 거래의 공정성을 확보하기 위해 공정거래위원회 등 유관 기관에서 표준 소프트웨어 구축 도급계약서 양식을 보급하고 있으며, 핵심 과업 범위의 구체적 기술을 분쟁 예방의 제1원칙으로 명시하고 있습니다.
5. 실무자를 위한 계약 전 최종 체크리스트
계약서 날인 직전, 실무자가 직접 챙겨야 할 MES 구축 계약서 점검 체크리스트는 다음과 같습니다. 이 질문들에 명확한 ‘예’라는 답이 나오지 않는다면 펜을 내려놓고 명세서부터 보완해야 합니다.
| 점검 영역 | 핵심 검토 질문 | 확인 여부 |
| 화면 및 기능 | 도입될 모든 단위 화면의 목록과 각 화면별 와이어프레임이 첨부되었는가? | [ ] |
| 데이터 정의 | 화면 내 주요 입력 필드의 데이터 타입(숫자, 문자, 날짜)과 필수 여부가 적혀 있는가? | [ ] |
| 설비 인터페이스 | 설비 신호를 받아올 프로토콜(RS-232, TCP/IP, OPC UA 등)과 패킷 구조가 정의되었는가? | [ ] |
| 외부 연동 | ERP 등 타 시스템과의 연동 방식(DB to DB, API, 엑셀 업로드)과 주기가 명시되었는가? | [ ] |
| 예외 및 제약 | 현장 오작동, 통신 단절, 중복 작업 시의 시스템 방어 로직이 포함되었는가? | [ ] |
| 인수 검수 기준 | 주관적 판단이 아닌 정량적 수치와 시나리오 기반의 합불 판정 기준이 있는가? | [ ] |
| 과업 변경 절차 | 개발 중 요구사항 변경 시 추가 비용 산정 기준(M/D 공수 단가표)이 합의되었는가? | [ ] |
이 체크리스트를 통과한 계약서는 단순한 법적 서류가 아닙니다. 프로젝트를 이끌어가는 개발자와 현장 관리자가 하나의 목적지를 향해 흔들림 없이 나아가도록 돕는 가장 완벽한 설계도가 됩니다.
6. 군더더기 없는 투명한 명세가 ‘저렴한 초기 도입비’를 만든다: 엠이에스코리아의 신념
많은 기업들이 기능 명세서를 꼼꼼하게 작성하자고 하면 “그렇게 세세하게 따지면 개발사가 골치 아파서 견적을 훨씬 높게 부르는 것 아니냐”고 지레 겁을 먹습니다.
하지만 소프트웨어 산업의 생리를 들여다보면 정반대입니다.
개발사들이 견적을 높게 부르는 진짜 이유는 해야 할 일이 명확해서가 아니라, ‘고객이 나중에 무슨 말을 더 꺼낼지 몰라 위험 비용(Risk Buffer)을 듬뿍 얹어두기 때문’입니다. 고객이 무엇을 원하는지 불확실할수록 개발사는 인건비와 기간을 넉넉하게 잡을 수밖에 없고, 그 거품은 고스란히 고객사의 도입 비용으로 전가됩니다.
저희 엠이에스코리아는 바로 이 비효율의 거품을 걷어내는 것에서 출발합니다.
- 범용적 코어 아키텍처 기반의 신속한 명세화우리는 특정 업종의 틀에 갇히지 않고 금형 관리, 설비 보전, 조립 공정, 물류 추적 등 다양한 제조 현장의 핵심 데이터 흐름을 수용하는 표준화된 코어 아키텍처를 보유하고 있습니다. 따라서 백지상태에서 비싼 공수를 들여 명세를 짜는 것이 아니라, 이미 검증된 공정 블록을 조립하듯 명확하고 빠른 기능 정의를 제시합니다.
- 저렴한 초기 도입비의 실현과업 범위(SOW)가 유리알처럼 투명해지면 개발사 입장에서도 쓸데없는 방어 비용을 얹을 이유가 전혀 없습니다. 프로젝트 중반에 발생하는 재작업과 헛걸음 공수가 원천 차단되므로, 엠이에스코리아는 고객사에게 저렴한 초기 도입비로도 대기업 못지않은 견고하고 완성도 높은 시스템을 제공할 수 있습니다.
- 현장과 개발자를 잇는 실무 언어의 일치우리는 탁상공론식 법률 용어로 계약서를 채우지 않습니다. 현장 작업자가 장갑을 벗지 않고도 터치할 수 있는 UI 흐름, 엔지니어가 단번에 알아듣는 PLC 인터페이스 분계점을 명세서에 직접 녹여냅니다. 불확실성이 사라진 프로젝트는 빠르고, 정확하며, 뒤탈이 없습니다.
비용을 아끼는 가장 현명한 방법은 기능을 깎아내는 것이 아니라, 요구사항의 경계를 선명하게 긋는 것입니다.
👉 과업 분쟁 걱정 없는 엠이에스코리아 맞춤 견적 및 상세 상담 신청하기
7. 선명한 약속 위에 세워지는 성공적인 스마트 공장
소프트웨어 도입 프로젝트에서 계약서는 서랍 속에 고이 모셔두는 종이 쪼가리가 되어서는 안 됩니다. 개발팀과 현장팀이 매일 아침 화면을 열어보며 “우리가 오늘 구현해야 할 모습이 이 약속과 정확히 일치하는가?”를 대조해 보는 살아있는 나침반이어야 합니다.
“알아서 잘해주겠지”라는 안일한 믿음은 현장의 오랜 땀방울을 한순간에 분쟁과 상처로 바꿉니다. 반면, “우리의 요구를 가장 작은 데이터 단위까지 쪼개어 종이 위에 선명하게 드러내겠다”는 단호한 원칙은 그 어떤 외풍에도 흔들리지 않는 튼튼한 시스템의 주춧돌이 됩니다.
다양한 제조 현장의 특성을 깊이 이해하고, 불필요한 과업 부풀리기 없이 본질에 집중하는 파트너를 만나십시오. 성공적인 디지털 전환을 이끄는 첫 단추는 바로 꼼꼼한 MES 구축 계약서 점검입니다.
화려한 말잔치 대신 투명한 기능 명세서 한 장으로 진검승부하는 엠이에스코리아가 여러분 공장의 소중한 투자와 시간을 가장 정직하게 지켜드리겠습니다.
