정부 스마트공장 지원사업은 제조 솔루션 구축 사업 기간의 상한을 6~9개월(연장 최대 3개월)로 둡니다. 민간 단일 공장용 제조 솔루션 계약을 찾아보면 검수와 안정화까지 포함한 계약 기간이 8~16개월인 사례가 나옵니다. AI 코딩 도구가 나온 뒤로 「이제 개발은 몇 배 빨라진다」는 말이 흔한데, 제조 솔루션 구축 기간이 그만큼 줄었다는 이야기는 잘 들리지 않습니다.

제조 AI 운영체제 VEXPLOR를 만드는 웨이스가 제조 솔루션을 구축하면서 본 것은 기간의 대부분이 코딩 밖에 있다는 점입니다. 이 글에서는 공개된 기준으로 제조 솔루션 구축 기간이 어디에 쓰이는지 나눠 보고, AI가 줄이는 기간과 줄이지 못하는 기간을 정리합니다.

화면 100개 안팎의 제조 솔루션은 정부 기준 산식의 중간값으로 따지면 개발 인력 5~8명이 9개월 넘게 걸립니다

비교 대상은 관리 화면과 현장 키오스크 화면, 설비·저울 연동을 합쳐 화면이 58~102개인 단일 공장용 제조 솔루션입니다.

이 규모를 정부 기준으로 환산해 봤습니다. 공공 소프트웨어 사업은 화면이나 코드 줄 수가 아니라 「기능 점수」로 규모를 계산합니다. 데이터를 저장하는 단위, 데이터를 입력·조회·출력하는 기능을 하나씩 세어 점수를 매기는 방식입니다. 화면 하나에 등록, 수정, 조회, 엑셀 출력이 모두 있으면 기능을 4개로 세고, 확인 버튼만 있는 화면은 0개로 셉니다. 한국소프트웨어산업협회의 「SW사업 대가산정 가이드」(2025 개정판)로 기능 점수를 매기고, 과학기술정보통신부 고시 「소프트웨어사업 계약 및 관리감독에 관한 지침」이 정한 1인 생산성(한 달에 19~24점)으로 나눴습니다.

· 기능 점수(중간 가정) — 화면 58개: 약 1,640점 · 화면 102개: 약 2,360점
· 필요 공수 — 화면 58개: 약 74 M/M · 화면 102개: 약 98 M/M
· 개발 인력 8명이면 — 화면 58개: 약 9개월 · 화면 102개: 약 12개월
· 개발 인력 5명이면 — 화면 58개: 약 15개월 · 화면 102개: 약 20개월

M/M은 한 사람이 한 달 동안 하는 일의 양입니다. 화면 한 장에 등록·조회·출력 기능이 몇 개 있는지를 가정해 기능 점수를 거꾸로 추정한 값이라 오차가 큽니다(±50% 안팎). 모든 화면을 처음부터 새로 개발한다고 가정한 값이고, 설비 통신 공사, 키오스크 설치, 현장 시운전도 들어 있지 않습니다. 공개 자료의 기간(정부 사업 상한 6~9개월, 민간 계약 사례 8~16개월)과 자릿수는 같습니다. 다만 세 값은 각각 개발 공수, 사업 기간 상한, 계약 기간이라 서로를 검증하지는 못합니다.

개발 기간 가운데 코딩은 3분의 1입니다

같은 가이드는 소프트웨어 개발을 분석, 설계, 구현, 시험 4단계로 나누고 단계마다 비중을 매깁니다.

· 분석 — 비중: 19% · 하는 일: 요구 듣고 정리
· 설계 — 비중: 24% · 하는 일: 화면·데이터 구조 결정
· 구현 — 비중: 32% · 하는 일: 코드 작성
· 시험 — 비중: 25% · 하는 일: 확인·수정 반복

AI 코딩 도구가 가장 크게 줄이는 것은 구현입니다. 구현이 32%이므로 코드 작성 시간이 0이 되어도 전체는 3분의 1 정도만 줄어듭니다. 이 비중은 가이드가 대가를 나누는 기준이라 실제 시간 비중과 똑같지는 않습니다. 그래도 방향은 분명합니다. 코딩만 빨라져서는 개발 9개월이 6개월이 될 뿐, 1개월이 되지는 않습니다.

역할이 나뉘면 일을 넘길 때마다 기다리는 시간이 생깁니다

기간을 늘리는 요인이 하나 더 있습니다. 정부 스마트공장 사업계획서 양식은 「추진조직 및 업무분장」 칸에 총괄 PM, 개발 PM, 품질관리 담당, 교육훈련 담당을 따로 적게 합니다. 공공 제조 솔루션 발주서도 과업 총괄책임자(PM)를 요구하고, 현장 인력 모집 글에는 「담당 PL의 주도하에 진행」이라고 적혀 있습니다.

역할을 나누는 데는 이유가 있습니다. 누가 무엇을 책임지는지가 분명해지고, 만든 사람이 아닌 사람이 품질을 확인하며, 정부 사업의 정산과 감리에서 투입 인력을 증빙할 수 있습니다. 다만 그 대가로 일이 한 사람에게서 다음 사람에게 넘어갈 때마다 시간이 듭니다.

역할이 나뉘면 일이 이렇게 흘러갑니다.

· 현장 → PM — 작업자와 관리자가 말한 요구를 PM이 문서로 옮깁니다.
· PM → 설계 — 문서를 받은 설계자가 화면과 데이터 구조를 정합니다.
· 설계 → 개발 — 개발자가 설계서대로 만들고, 모르는 것은 다시 PM에게 묻습니다.
· 개발 → 시험 → 현장 — 시험 담당이 확인하고, 현장에서 「이게 아니다」가 나오면 처음으로 돌아갑니다.

예를 들어 칭량 화면에 「저울 값이 허용 범위를 벗어나면 다음 공정으로 못 넘어가게 해 달라」는 요구가 나왔다고 해 보겠습니다. 허용 범위를 품목마다 다르게 둘지, 벗어났을 때 누가 풀어 줄 수 있는지는 요구를 말한 작업자와 관리자만 압니다. 그런데 이 질문은 대개 개발자가 코드를 짜다가 떠올립니다. 개발자는 PM에게 묻고, PM은 공장에 묻고, 답이 돌아오는 동안 그 화면은 멈춥니다.

넘길 때마다 문서를 쓰고 읽는 시간, 답을 기다리는 시간이 붙습니다. 이 대기 시간이 몇 퍼센트인지 공개된 수치는 찾지 못했습니다. 다만 AI가 코드 작성을 몇 분으로 줄여도, 개발자가 PM의 답을 사흘 기다리면 그 사흘은 그대로 남습니다.

구축 기간을 크게 줄이려면 코딩 밖의 3가지를 바꿔야 합니다

첫째, 처음부터 만들지 않습니다. 공장마다 다른 것은 생각보다 적습니다. 품목, 공정, 작업 지시, 실적, 재고 같은 기본 구조는 비슷하고, 공장마다 다른 것은 그 위의 규칙과 화면 일부입니다. 표준 화면과 데이터 구조 위에서 시작하면 분석과 설계의 상당 부분이 「무엇을 새로 만들까」가 아니라 「표준과 무엇이 다른가」로 바뀝니다.

둘째, 요구를 듣는 사람과 만드는 사람을 한 사람으로 합칩니다. 현장에서 요구를 들은 사람이 그 자리에서 AI와 함께 화면을 만들어 보여 주면 중간에 일을 넘길 필요가 없어집니다. 「이게 아니다」가 나와도 다음 날이 아니라 그 자리에서 고칩니다. 이런 역할을 현장 배치 엔지니어(FDE, Forward Deployed Engineer)라고 부릅니다.

셋째, 시험과 오픈 뒤 수정은 AI가 먼저 하고 사람은 확인합니다. 시험 비중이 25%이고, 오픈 뒤에는 수정 요청이 계속 들어옵니다. 「표시 순서를 바꿔 달라」, 「엑셀로 받게 해 달라」 같은 작은 요청도 기존 방식에서는 PM 접수, 개발 배정, 수정, 배포를 거칩니다. 시험을 코드로 만들어 자동으로 실행하고, 오픈 뒤 들어오는 수정 요청도 AI가 먼저 코드로 반영하게 하면 사람은 결과만 확인하면 됩니다.

웨이스가 앞의 두 가지를 적용한 한 식품 공장에서는 엔지니어 1명이 VEXPLOR 표준 화면 58개에서 시작해, 개발 7주 만에 화면을 102개까지 키웠습니다. 이 공장은 아직 구축 중이고 표준 화면 58개를 만든 공수도 7주에 들어 있지 않아, 위 산식과 바로 비교할 수 있는 값은 아닙니다.

구축 기간이 줄면 공장이 얻는 것은 가격 인하가 아니라 먼저 가동되는 기간입니다

구축이 빨라지면 사는 쪽에서 먼저 나오는 질문은 「그럼 값도 내려가느냐」입니다. 견적서가 「인력 5명 × 12개월」로 적혀 있으면 기간이 줄 때 값도 같이 줄어야 맞습니다. 하지만 값을 만드는 범위로 정한 견적이라면 기간이 줄어도 값은 그대로이고, 줄어든 기간은 다른 곳으로 돌아갑니다.

먼저 가동되는 기간이 공장의 수익 구간이 됩니다. 제조 솔루션이 6개월 먼저 가동되면, 그 6개월 동안 생기는 효과가 공장의 몫입니다. 무엇을 효과로 셀지는 공장마다 다르지만, 보통 이런 항목입니다.

· 불량 — 무엇이 바뀌나: 덜 버리는 자재 · 어디서 확인하나: 불량 집계
· 재고 — 무엇이 바뀌나: 덜 묶이는 현금 · 어디서 확인하나: 재고 회전
· 납기 — 무엇이 바뀌나: 안 내는 지연금 · 어디서 확인하나: 지연 이력
· 집계 시간 — 무엇이 바뀌나: 수기 입력·보고 · 어디서 확인하나: 담당자 근무 기록

먼저 얻는 수익은 「먼저 가동되는 개월 수 × 월 효과」로 계산합니다. 이 계산은 사는 쪽이 자기 숫자로 해야 합니다. 파는 쪽이 금액을 말하면 그것은 약속이 되고, 사는 쪽이 계산하면 내부 품의의 근거가 됩니다.

구축 뒤 수정이 빨라지는 것도 공장의 몫입니다. 현장에서 「이 항목 하나만 바꿔 달라」는 요청이 나온 날 바로 반영되면, 시스템이 공장의 변화를 늦게 따라가며 생기던 수기 우회 작업이 줄어듭니다.

다만 이 계산에는 조건이 있습니다. 먼저 가동해도 그 기간에 벌 것이 있어야 합니다. 앞 공정이 먼저 끝나야 하는 라인, 다음 회계연도까지 가동 계획이 없는 현장, 예산 집행 기간이 고정된 사업에서는 먼저 끝나도 그 시간이 수익으로 바뀌지 않습니다. 구축 속도를 따지기 전에 「먼저 가동되면 그 기간에 무엇이 달라지는가」부터 묻는 것이 순서입니다.

AI가 줄이지 못하는 기간도 있습니다

· 요구를 확정하는 시간 — 무엇을 만들지는 공장이 정합니다. 경영진과 현장의 의견이 다르면 그 조율은 AI가 대신하지 못합니다. 그래서 컨설팅 기간은 공장마다 다르고, 구축 기간과 따로 봐야 합니다.
· 현장에 설치하고 맞추는 시간 — 설비 통신 연결, 키오스크 설치, 실제 설비와의 시운전은 공장에 사람이 가야 하는 일입니다. 기능 점수로도 잡히지 않습니다.
· 기준정보를 정리하고 옮기는 시간 — 품목, 공정, BOM 같은 기준정보를 새 시스템에 맞게 정리하고 기존 자료를 옮기는 일은 공장 사람이 함께 확인해야 끝납니다.
· 인수시험과 병행 운영 — 공장이 직접 시험해 받아들이고, 한동안 기존 방식과 함께 운영하며 결과를 맞춰 보는 기간이 필요합니다.
· 교육과 익숙해지는 시간 — 작업자가 새 화면으로 실적을 입력하는 데 익숙해지는 기간은 개발 속도와 상관없습니다.

AI로 제조 솔루션 구축 기간을 크게 줄이는 회사는 코딩을 빠르게 한 회사가 아니라, 처음부터 만들지 않고 중간에 일을 넘기는 단계를 없앤 회사입니다.

WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.

(이 글은 웨이스 기술블로그에 먼저 실린 글입니다. 원문: https://blog.vexplor.com/post/why-faster-coding-does-not-shorten-factory-system-builds)