생산 이력, BOM, 작업 지시, 검사 성적서, 부적합 보고서가 하나의 시스템에 쌓이기 시작하면 ERP 선택은 회계 소프트웨어 구매를 넘어선다. 특히 방산, 항공우주, 규제 산업의 제조 조직은 클라우드 ERP를 계속 쓸지, 오픈소스 기반 온프레미스 또는 에어갭 ERP/MES/QMS를 운영할지 결정해야 한다.
핵심은 데이터가 사내에 있느냐만이 아니다. 온프레미스 시스템을 선택하는 순간 조직은 서버, 계정, 백업, 취약점 대응, 장애 복구, 감사 증적을 함께 맡는다. 반대로 클라우드는 운영 부담을 줄일 수 있지만, 데이터 경계와 공급업체 의존성, 네트워크 단절 상황에서의 현장 운영을 따져야 한다.
제조 조직이 온프레미스·에어갭 ERP/MES/QMS를 선택할 만한 조건은 분명하다. 규제 대상 정보가 정해진 보안 경계 안에 머물러야 하고, 생산 현장이 외부 네트워크에 의존하지 않고 돌아가야 하며, 그 책임을 맡을 운영 역량과 예산이 있어야 한다.
먼저 비교할 대상은 배포 방식이 아니라 책임의 위치다
클라우드 ERP와 온프레미스 ERP를 비교할 때 흔히 “누가 데이터를 보관하는가”부터 묻는다. 그러나 CTO와 개발 리더가 더 먼저 확인할 질문은 “장애, 보안 사고, 감사 요청이 생겼을 때 누가 무엇을 증명하고 복구하는가”다.
| 비교 축 | 클라우드 ERP/MES/QMS | 온프레미스·에어갭 ERP/MES/QMS |
|---|---|---|
| 인프라 운영 | 공급업체가 플랫폼 운영을 맡는 범위가 넓다 | 제조 조직 또는 운영 파트너가 서버와 네트워크를 관리한다 |
| 데이터 경계 | 계약, 리전, 접근 통제 설정을 검토해야 한다 | 네트워크와 저장소를 조직이 직접 통제할 수 있다 |
| 현장 연결성 | 인터넷 또는 전용 연결 상태가 중요하다 | 내부망만으로 운영하도록 설계할 수 있다 |
| 업데이트 | 공급업체 일정과 정책의 영향을 받는다 | 조직이 검증 시점과 배포 순서를 정할 수 있다 |
| 장애 복구 | 서비스 계약 범위와 공급업체 복구 절차에 의존한다 | 백업, 복제, 복구 훈련을 조직이 설계하고 실행해야 한다 |
| 기능 확장 | 제공된 설정 범위 안에서 빠르게 시작하기 쉽다 | 코드, API, 데이터 모델을 더 깊게 검토하고 변경할 수 있다 |
| 비용 구조 | 구독료와 사용량, 연동 비용을 중심으로 본다 | 인프라·운영 인력·지원 계약·업그레이드 비용까지 포함해 본다 |
온프레미스는 통제권을 늘려 주지만 책임도 이전한다. 서버를 사내에 둔다는 사실만으로 보안이 강화되는 것은 아니다. 패치가 늦고, 관리자 계정이 공유되고, 백업 복구를 시험하지 않는다면 클라우드보다 더 취약한 운영이 될 수 있다.
에어갭 환경은 이 책임을 더 무겁게 만든다. 외부 연결이 차단된 환경에서는 긴급 패치, 컨테이너 이미지 반입, 라이선스 검증, 인증서 갱신, 시간 동기화, 원격 지원 절차까지 사전에 정해야 한다. “인터넷에 연결하지 않는다”는 요구사항은 출발점이지 운영 계획이 아니다.
규제 대응은 제품 기능과 조직의 증빙 체계를 나눠 봐야 한다
CMMC나 NIST SP 800-171 같은 요구사항을 검토하는 제조 조직이라면, 시스템이 규제에 “준수한다”는 표현을 그대로 구매 기준으로 쓰기 어렵다. 규제 적합성은 특정 제품의 기능만으로 완성되지 않기 때문이다.
예를 들어 CUI를 다루는 조직은 정보가 어디에 저장되고, 누가 접근하며, 변경과 접근을 어떻게 기록하고, 사고가 났을 때 어떤 절차로 대응하는지를 설명할 수 있어야 한다. ERP/MES/QMS는 이 과정에서 중요한 시스템이지만, 조직의 전체 보안 경계를 대신하지는 않는다.
온프레미스 제품을 검토할 때는 다음을 분리해서 확인하는 편이 안전하다.
- 제품 기능: 역할 기반 권한, 세분화된 접근 통제, 감사 로그, 전자 승인, 데이터 보존, 첨부 파일 접근 통제가 필요한 수준으로 제공되는가.
- 배포 설계: 데이터베이스, 파일 저장소, 백업 저장소, 운영자 접속 경로가 같은 보안 경계 안에 있는가.
- 운영 증빙: 계정 검토, 변경 승인, 취약점 조치, 백업 복구 시험, 접근 로그 검토를 누가 어떤 주기로 남기는가.
- 공급업체 산출물: 시스템 보안 계획서 작성에 쓸 배포 문서, 책임 분담표, 통제 항목 매핑 자료를 제공하는가.
일부 제조 ERP 제품은 고객이 운영하는 PostgreSQL 데이터베이스, 자체 VPC, 온프레미스 또는 완전한 에어갭 배포를 지원한다고 제시한다. CMMC 관련 문서나 SSP, POA&M 작성에 쓸 입력 자료를 제공하는 상용 지원 모델도 있다. 다만 해당 자료는 감사 통과를 보장하는 증서가 아니라, 조직이 자신의 환경과 통제를 설명하는 데 쓰는 입력값으로 봐야 한다.
ERP, MES, QMS가 한 데이터 모델을 공유할 때 얻는 것과 잃는 것
제조 실행과 품질 관리가 ERP와 분리되어 있으면 연동 비용이 늘어난다. 주문에서 생산 지시가 생성되고, 작업자가 공정을 수행하며, 검사 결과와 부적합 조치가 남고, 완성품의 로트 또는 시리얼 이력이 이어지는 흐름이 여러 시스템에 나뉘기 때문이다.
통합형 ERP/MES/QMS는 이 흐름을 하나의 데이터 모델에서 다룰 수 있다는 점이 장점이다. BOM과 라우팅 변경, 자재 로트, 작업자 기록, 측정값, NCR, CAPA, 교정 이력, 출하 성적서를 같은 제품 및 생산 이력에 연결할 수 있다. 추적성 조회나 품질 문제 조사에서 별도 동기화 작업을 줄일 여지가 생긴다.
그러나 “한 데이터베이스”가 곧 “좋은 통합”을 뜻하지는 않는다. 다음 조건을 확인해야 한다.
-
마스터 데이터의 책임자가 정해져 있는가
품목, BOM, 공정, 검사 기준, 공급업체, 고객 코드가 바뀔 때 누가 승인하는지 정하지 않으면 통합 시스템도 빠르게 신뢰를 잃는다. -
현장 작업 흐름을 강제로 왜곡하지 않는가
디지털 작업 지시와 바코드 추적이 있어도, 작업자가 예외 상황을 기록할 수 없거나 승인 대기 때문에 생산이 멈춘다면 우회용 스프레드시트가 다시 생긴다. -
회계와 제조의 마감 규칙이 충돌하지 않는가
생산 현장은 재작업, 대체 자재, 부분 완료를 즉시 기록해야 한다. 회계는 비용과 재고를 일정한 기준으로 마감해야 한다. 제품 데모에서는 보이지 않는 충돌이므로 시나리오 테스트가 필요하다.
통합 제품은 데이터 복제를 줄일 수 있지만, 장애 범위도 넓어진다. 따라서 생산 현장 단말, 데이터베이스, 파일 저장소, 라벨 프린터, 바코드 장비가 어느 부분에서 끊겨도 어떤 업무를 계속할지 정해야 한다.
오픈소스는 소유권이 아니라 검증과 변경의 선택지다
오픈소스 기반 제조 시스템의 강점은 코드와 데이터 구조를 검토하고, 조직의 공정에 맞게 확장할 수 있다는 데 있다. TypeScript, React, PostgreSQL, Docker처럼 널리 쓰이는 구성이라면 내부 개발팀이 기술 검토와 운영 인수에 참여하기도 수월할 수 있다.
그렇다고 “소스가 공개되어 있으니 공급업체 종속이 없다”고 판단하면 곤란하다. 특정 제품의 설치 문서, 데이터 마이그레이션 도구, 업그레이드 경로, 현장 교육 자료, 도메인 지식은 여전히 공급업체나 구현 파트너에게 집중될 수 있다. 공개 저장소를 내려받아 실행하는 것과 생산 시스템을 운영하는 것은 다른 일이다.
라이선스도 초기에 확인해야 한다. 예를 들어 AGPL-3.0 기반 코어는 수정한 시스템을 네트워크로 사용자에게 제공할 때 소스 제공 의무가 문제 될 수 있다. 일부 제품은 API, SSO, 에어갭 라이선스, 상용 지원을 별도 상업 라이선스로 제공한다. 법률 해석은 조직의 법무 및 라이선스 담당자와 검토해야 하지만, 기술팀은 적어도 다음 질문을 계약 전 목록에 넣어야 한다.
- 내부 수정분을 비공개로 유지하려면 어떤 상용 조건이 필요한가.
- 에어갭 환경에서 라이선스 활성화와 갱신은 어떻게 처리하는가.
- 커뮤니티 버전과 상용 버전의 기능 차이는 무엇인가.
- 커스터마이징 후 업그레이드할 때 충돌을 누가 해결하는가.
- 공급업체 지원이 중단되어도 데이터베이스와 첨부 파일을 독립적으로 읽고 이전할 수 있는가.
총비용은 구독료와 서버 가격 사이에 있지 않다
클라우드 구독료와 온프레미스 서버 구매 비용만 비교하면 결론이 왜곡된다. 제조 시스템의 총비용은 소프트웨어 가격보다 운영 체계의 빈틈에서 커지는 경우가 많다.
온프레미스 또는 에어갭 환경에서는 최소한 다음 항목을 비용표에 넣어야 한다.
- 데이터베이스 운영, 모니터링, 용량 관리, 성능 튜닝
- 백업 보관, 복구 절차, 복구 시험과 책임자
- 운영체제와 컨테이너 이미지의 취약점 관리
- SSO, MFA, 계정 수명주기, 권한 검토
- 현장 단말과 바코드 스캐너, 프린터, 라벨 시스템 연동
- 버전 업그레이드 전 검증 환경과 회귀 테스트
- 긴급 장애 시 공급업체 또는 구현 파트너의 지원 조건
- 데이터 마이그레이션과 기존 종이·스프레드시트 절차 전환 교육
반대로 클라우드도 비용이 예측 가능하다고만 볼 수 없다. 사용자 수, 거래량, 저장 공간, API 호출, 외부 시스템 연동, 고급 보안 기능, 데이터 반출 조건이 계약에 어떻게 반영되는지 확인해야 한다. 특히 생산 데이터와 품질 문서를 장기간 보관해야 하는 조직이라면, 저장과 추출 비용을 별도로 검토할 이유가 있다.
공급업체 선정 전에 해 볼 검증 시나리오
제품 기능 목록보다 유용한 것은 실제 생산 흐름을 따라가는 검증이다. 데모에서는 정상적인 주문과 완성 처리만 보지 말고, 품질과 운영이 흔들리는 상황을 넣어야 한다.
첫 번째 시나리오는 자재 로트 문제의 역추적이다. 특정 자재 인증서나 입고 로트에 문제가 생겼을 때, 영향을 받은 재공품과 출하품을 어디까지 찾을 수 있는지 확인한다. 조회 결과뿐 아니라 담당자가 어떤 기록을 수정할 수 있는지도 봐야 한다.
두 번째는 공정 중 부적합과 재작업이다. 작업자가 부적합을 등록하고, 승인자가 처분을 결정하며, CAPA와 교정 조치가 이어지고, 원가와 일정에 어떤 영향이 남는지 테스트한다. 이때 현장 작업자가 입력하기 어려운 화면이라면 기능이 있어도 운영되지 않는다.
세 번째는 네트워크 또는 외부 서비스 단절이다. 에어갭을 요구하는 조직이라면 더 중요하다. 라이선스 확인, 시간 동기화, 로그 수집, 원격 지원, 업데이트가 외부 연결 없이 가능한지 문서와 실제 환경에서 확인해야 한다.
네 번째는 복구 훈련이다. 백업 파일이 있다는 사실로는 부족하다. 별도 환경에 복원한 뒤, ERP 거래 기록, MES 작업 지시, QMS 첨부 문서, 권한 설정이 필요한 시점까지 돌아오는지 검증해야 한다.
온프레미스·에어갭 ERP/MES/QMS는 “클라우드를 쓰지 않는 선택”이 아니다. 생산과 품질 데이터의 경계, 현장 시스템의 연속성, 보안 통제의 증빙, 운영팀의 책임 범위를 조직이 직접 설계하는 선택이다. 제품 비교표를 만들기 전에, 보안 책임자·제조 책임자·품질 책임자·개발 운영팀이 함께 복구 목표와 변경 승인 절차를 먼저 합의해 두는 편이 낫다. 그 합의가 없다면 어떤 배포 방식도 오래 버티기 어렵다.
