본문 바로가기
REVIVELAB — AI Engineering for Manufacturing.
작업자가 생산 설비를 조작하는 모습

생산관리시스템 기능 추가 개발 비용

생산관리시스템 기능 추가 개발 비용은 어디를 건드리는지로 갈립니다

생산관리시스템 기능 추가 개발 비용은 기능 개수보다 그 요청이 조회 화면에서 끝나는지, 품목·재고 기준과 설비 연동까지 닿는지에 따라 갈립니다. 계층별로 따라오는 작업과 견적서에서 확인할 항목을 표로 정리했습니다.

발행 2026-10-07

생산관리시스템에 기능을 추가할 때 개발 비용이 갈리는 지점은 기능의 개수가 아니라 그 기능이 기존 데이터 구조와 설비 신호를 어디까지 건드리는가입니다. 화면 하나를 더 붙이는 일과 품목·재고 기준을 고쳐 과거 데이터까지 맞추는 일은 요청서에 같은 한 줄로 적히지만, 산정에 들어가는 작업이 다릅니다. 아래에 요청 유형별로 따라오는 작업과, 받은 견적서를 비교 가능한 형태로 만드는 확인 항목을 표로 정리했습니다.

같은 '기능 하나'가 세 갈래로 나뉩니다

기능 추가 요청을 모아 놓고 보면 대개 세 계층 중 하나에 닿습니다. 첫째는 조회·출력 계층입니다. 이미 쌓고 있는 데이터를 다른 조건으로 뽑거나 양식을 바꿔 출력하는 일로, 저장 구조를 건드리지 않으므로 영향 범위가 화면 단위에서 끝나는 편입니다.

둘째는 마스터·로직 계층입니다. 품목이나 공정 등록 항목을 늘리고, 재고가 깎이는 시점이나 실적이 집계되는 기준을 바꾸는 일입니다. 여기부터는 그 기준을 함께 쓰는 다른 화면이 같이 흔들립니다. 신규 입력은 맞게 들어가는데 과거 데이터가 새 기준에 맞지 않아 집계가 어긋나는 상황이 이 구간에서 자주 생깁니다.

셋째는 설비·외부 연동 계층입니다. 설비에서 신호를 받아 실적을 자동으로 올리거나, 납품처·회계 쪽 양식에 맞춰 자료를 내보내는 일입니다. 상대가 우리 통제 밖에 있어서 규격 확인과 예외 처리 규칙이 함께 붙습니다.

요청이 닿는 계층요청 예함께 따라오는 작업견적 단계에서 물을 것
조회·출력 계층조회 조건 추가, 보고 양식·라벨 변경, 내보내기 항목 추가기존 화면 영향 확인, 출력 서식 검증이 요청이 월 유지보수 범위인지 별도 산정인지
마스터 계층품목·공정·거래처 등록 항목 추가, 코드 체계 변경해당 항목을 쓰는 화면 일괄 수정, 기존 등록 데이터 보정과거 등록 데이터를 새 항목에 맞추는 작업이 범위에 들어가는지
로직 계층재고 차감 시점 변경, 실적·불량 집계 기준 변경, 원가 배부 기준 추가영향받는 집계 화면 재검증, 마감된 기간 처리 방침 결정기준 변경 전 데이터를 어떻게 처리하기로 했는지
설비 연동 계층설비 신호로 실적 자동 수집, 계측값 수집 주기 변경설비 쪽 통신 규격 확인, 신호 끊김 시 처리 규칙, 현장 시험설비 쪽 확인이 늦을 때 일정과 범위를 어떻게 적는지
외부 연동 계층납품처 요구 양식 반영, 회계·그룹웨어 자료 연계상대 규격 확인, 예외 건 처리 규칙, 재전송 수단상대 규격이 바뀔 때 재작업을 어느 쪽이 맡는지
권한·이력 계층사용자별 열람 범위 분리, 변경 이력 남기기기존 계정 재정리, 이력 저장량 증가 대비운영 중인 계정 구조를 바꾸는 일이 포함되는지
표 1.기능 추가 요청이 닿는 계층별로 함께 따라오는 작업과 견적 단계에서 물을 것

표의 마지막 칸이 견적 단계에서 물을 질문이 됩니다. '얼마입니까'보다 '이 요청은 어느 계층에 들어갑니까'를 먼저 물으면, 금액 차이의 이유가 설명으로 돌아옵니다.

견적이 늦거나 흔들리는 이유는 대개 자료 상태입니다

같은 요청을 받아도 어떤 공장에서는 범위가 금방 정해지고 어떤 공장에서는 계속 바뀝니다. 차이는 요청의 난이도보다 지금 쓰는 시스템의 상태를 설명할 수 있는지에서 나옵니다.

확인이 안 되면 산정이 추정으로 바뀌는 항목은 대체로 네 가지입니다. 지금 실제로 쓰는 화면과 쓰지 않는 화면의 구분, 품목·공정 등록 규칙과 예외 처리 관행, 가동 이후 손댄 커스터마이징 이력, 그리고 그 변경을 적어 둔 자료가 남아 있는지입니다. 특히 커스터마이징 이력이 문서로 남아 있지 않으면 코드를 열어 확인하는 시간이 먼저 들어가고, 그 시간이 견적에 들어갑니다.

여기서 흔히 어긋나는 것이 유지보수와 추가 개발의 경계입니다. 공장에서는 '화면 하나 고치는 일'로 보고, 업체는 '집계 기준을 바꾸는 일'로 보는 경우가 있습니다. 계약서에 경계가 예시로 적혀 있지 않으면 요청마다 협의가 반복됩니다.

견적서는 금액 칸보다 범위 칸을 비교합니다

여러 곳에서 받은 견적서를 나란히 놓으면 금액은 비교되지만 범위는 비교되지 않는 경우가 많습니다. 범위가 한 줄로 적혀 있으면 서로 다른 일을 같은 값으로 견주게 됩니다.

견적서에서 볼 항목모호하게 적히는 방식분명하게 적힌 방식왜 비교가 어긋나는가
작업 범위'생산실적 화면 개선' 같은 한 줄바뀌는 화면 이름과 추가되는 입력 항목까지 나열한 줄 범위는 서로 다른 작업량을 같은 칸에 넣게 만든다
기존 데이터 처리언급 없음과거 데이터 보정 포함 여부와 대상 기간 명시보정을 뺀 쪽이 낮아 보이지만 가동 후 다시 요청된다
검증 방식'테스트 후 적용'시험 항목과 합격 기준, 누가 확인하는지현장 시험을 누가 몇 번 도는지에 따라 작업량이 달라진다
유지보수 경계'기능 추가 포함'추가된 기능의 이후 변경이 월 범위인지 건당인지경계가 없으면 같은 요청이 매번 협의로 돌아온다
변경 요청 처리'협의'착수 후 요구가 바뀔 때의 처리 절차중간 변경을 어디까지 흡수하는지가 이미 값에 들어 있다
산출물'개발 완료'변경 화면 설명서, 설정값 기록, 인계 자료 목록기록을 남기는 작업이 빠지면 다음 변경에서 다시 시간이 든다
표 2.기능 추가 견적서를 비교 가능한 형태로 만드는 확인 항목

이 표를 그대로 양식으로 써서 후보마다 같은 칸을 채우게 하면, 어느 쪽이 넓은 범위를 적었는지가 드러납니다. 곳 수를 늘리는 것보다 같은 질문을 똑같이 던지는 쪽이 비교에 유리합니다.

견적을 받기 전에 한 장으로 정리할 것

요청서를 길게 쓸 필요는 없습니다. 네 가지만 적혀 있으면 산정이 추정에서 벗어납니다. 첫째 그 기능으로 무엇을 보고 판단하려는지, 둘째 누가 언제 어느 화면에서 입력하는지, 셋째 기존 어느 화면·어느 자료와 이어지는지, 넷째 무엇이 되면 완료로 볼 것인지입니다.

특히 네 번째가 빠지면 가동 후에 '이건 아직 안 된 것 아닌가'가 남습니다. 완료 기준을 숫자로 적기 어렵다면 확인할 화면과 대조할 자료를 적어 두는 방식도 됩니다. 실제 범위와 규모는 현재 자료 상태와 연동 구간을 현장에서 확인한 뒤 산출해 드립니다.

태블릿으로 품목을 스캔해 재고를 맞추는 창고 작업자
그림 1.재고가 깎이는 시점을 바꾸는 요청은 입력 화면 하나로 끝나지 않고 과거 데이터와 집계 기준까지 함께 확인하게 됩니다.
주물 공장에서 붉게 달궈진 용탕이 주형으로 흘러드는 주입 순간
그림 2.설비에서 신호를 받아 실적을 자동으로 올리는 구간은 설비 쪽 통신 규격과 신호 끊김 처리 규칙을 먼저 확인해야 범위가 정해집니다.

FAQ

자주 묻는 질문

Q01
기능 하나 추가하는 건데 왜 업체마다 견적 차이가 크게 납니까?
대부분은 같은 요청 문장을 서로 다른 범위로 읽었기 때문입니다. '실적 입력에 항목 하나 추가'라는 한 줄을 어떤 곳은 입력 화면 수정까지로 보고, 어떤 곳은 그 항목이 집계·보고 화면에 반영되는 것과 과거 데이터 처리까지로 봅니다. 뒤쪽이 범위가 넓으니 값도 올라가지만, 가동 후에 다시 요청하게 되는 일은 줄어듭니다. 그래서 비교하실 때는 금액 칸을 먼저 보지 않고 범위 칸을 같은 양식에 올려 보시는 편이 정확합니다. 바뀌는 화면 이름, 과거 데이터 보정 포함 여부, 검증 방식, 산출물 네 칸만 채워도 어느 쪽이 무엇을 빼고 적었는지가 드러납니다. 차이가 설명되지 않는 견적은 금액이 낮아도 착수 후에 협의가 반복될 수 있습니다.
Q02
유지보수 계약을 하고 있는데 기능 추가도 그 안에 포함되는 건가요?
계약서에 경계가 어떻게 적혀 있는지에 따라 달라지고, 적혀 있지 않은 경우가 많습니다. 일반적으로 조회 조건 추가나 출력 양식 변경처럼 저장 구조를 건드리지 않는 요청은 월 범위로 보는 곳이 많고, 품목·공정 등록 구조나 집계 기준을 바꾸는 요청은 별도 산정으로 넘어가는 편입니다. 다만 이 선은 업체마다 다르게 그어져 있어서 미리 맞춰 두지 않으면 요청마다 협의가 생깁니다. 권해 드리는 방법은 지난 1년간 보낸 요청 가운데 자주 나오는 것 세 개를 적어 두고 '이건 어느 쪽에 들어갑니까'를 그대로 물어보시는 것입니다. 추상적인 기준보다 실제 요청으로 물을 때 답이 분명해집니다. 결과는 계약서나 합의 문서에 예시 형태로 남겨 두시는 편이 좋습니다.
Q03
견적을 받으려면 우리 쪽에서 무엇을 먼저 정리해 가야 하나요?
길게 쓰실 필요는 없고 네 가지면 충분합니다. 그 기능으로 무엇을 보고 판단하려는지, 누가 언제 어느 화면에서 입력하는지, 기존 어느 화면이나 자료와 이어지는지, 무엇이 되면 완료로 볼 것인지입니다. 여기에 지금 쓰는 시스템 쪽 정보로 가동 이후 손댄 변경 이력과 그 기록이 남아 있는지를 더하시면 좋습니다. 이력이 문서로 없으면 업체가 코드를 열어 확인하는 시간이 먼저 들어가고, 그 시간도 산정에 포함됩니다. 반대로 지금 실제로 쓰는 화면과 쓰지 않는 화면만 구분해 드려도 확인 범위가 줄어듭니다. 완료 기준을 숫자로 적기 어려우면 확인할 화면과 대조할 자료를 적어 두는 방식으로 대신하셔도 됩니다.
Q04
지금 쓰는 시스템을 만든 곳이 아닌 다른 업체에 기능 추가를 맡길 수 있나요?
가능한 경우와 어려운 경우가 갈리고, 기준은 업체의 역량보다 자료 상태입니다. 데이터베이스 구조와 소스에 접근할 수 있고 그동안의 변경이 어느 정도 기록돼 있으면 다른 곳에서도 손댈 수 있습니다. 반대로 소스 제공 범위가 계약으로 제한돼 있거나, 가동 이후 변경이 기록 없이 누적돼 있으면 구조를 읽는 시간이 먼저 들어갑니다. 그래서 먼저 확인하실 것은 소스와 설계 자료의 보유·제공 조건입니다. 함께 보실 것은 그 이후의 책임 경계입니다. 한 시스템을 두 곳이 손대기 시작하면 문제가 생겼을 때 원인 구분이 어려워지므로, 어느 구간을 누가 맡는지와 변경 기록을 어디에 남길지를 미리 정해 두시는 편이 낫습니다.
Q05
기능을 추가하면 나중에 버전 업그레이드나 유지보수에 문제가 생기지 않나요?
어디에 붙이는지에 따라 달라지는 편입니다. 표준 기능을 직접 고치는 방식은 이후 표준 버전이 올라갈 때 고친 부분이 덮일 수 있고, 별도 화면이나 확장 지점에 붙이는 방식은 영향이 작은 쪽입니다. 그래서 견적 단계에서 '표준을 수정하는 방식입니까, 분리해서 붙이는 방식입니까'를 물어보시면 이후 부담까지 함께 비교할 수 있습니다. 또 하나 중요한 것은 기록입니다. 무엇을 왜 어떻게 바꿨는지가 남아 있지 않으면 다음 변경에서 같은 확인 작업을 다시 하게 됩니다. 변경 화면 설명서와 설정값 기록을 산출물에 넣어 달라고 요청하시는 편이 좋습니다. 우리 환경에서 어느 방식이 맞는지는 현재 구성을 확인한 뒤 정리해 드립니다.

근거·참고

제도와 기준의 원본

현장에 맞는 답이 필요하시면

이 글은 일반적인 기준을 정리한 것입니다. 공정과 설비를 직접 보고 해당 현장의 조건에 맞춰 범위를 잡아 드립니다.

MORE

함께 보면 좋은 글