클라우드 SCADA와 온프레미스, 요구사항부터 전환까지

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

여러 공장의 생산 현황을 한 화면에서 보고 싶지만, 설비 데이터를 외부망으로 보내도 되는지 걱정되시나요? 이때 가장 먼저 부딪히는 선택이 클라우드 SCADA 대 온프레미스 SCADA입니다. 클라우드는 확장과 원격 접근에 강하고, 온프레미스는 현장 통제력과 독립 운전에 유리합니다.

문제는 어느 한쪽이 항상 우월하지 않다는 점입니다. 요구사항을 수집하기도 전에 제품부터 정하면 통신 지연, 구독료 증가, 보안 심사 지연 같은 비용이 뒤늦게 드러납니다. SDEC와 같은 기술 컨설팅 관점에서는 제품명이 아니라 운영 조건과 장애 시나리오부터 비교해야 합니다.

1. 제품보다 먼저 멈추면 안 되는 업무를 찾습니다

실시간 제어와 경영 모니터링을 분리합니다

SCADA 도입 목적이 무엇인지 한 문장으로 답할 수 있어야 합니다. 운전원이 밸브와 모터를 직접 조작할 화면이 필요한지, 본사에서 생산량과 에너지 사용량을 조회할 대시보드가 필요한지에 따라 구조가 완전히 달라집니다. 전자는 수백 밀리초 수준의 반응과 현장 독립성이 중요하지만, 후자는 여러 거점의 데이터 통합과 접근 편의성이 더 중요합니다.

온프레미스 SCADA는 공장 내부 서버와 네트워크에서 동작하므로 인터넷이 끊겨도 제어 화면을 유지하기 쉽습니다. 반면 클라우드 SCADA는 사업장 추가, 외부 전문가 접속, 장기 데이터 분석에 유리합니다. 클라우드 화면을 PLC의 직접 제어 루프에 연결하는 설계는 회선 장애와 지연을 제어 위험으로 바꿀 수 있으므로 신중해야 합니다.

• 즉시 멈추면 손실이 큰 업무: 운전 조작, 인터록 확인, 긴급 알람 인지
• 수분 지연을 허용할 수 있는 업무: 생산 실적 집계, 설비 효율 비교, 관리자 보고
• 수시간 후 처리해도 되는 업무: 장기 추세 분석, 월간 에너지 보고, 품질 상관관계 분석
• 첫 질문: 인터넷과 클라우드가 4시간 중단돼도 생산을 안전하게 계속할 수 있는가?

제어는 현장에 남기고, 관찰과 분석부터 클라우드로 확장하면 두 방식의 장점을 가장 안전하게 시험할 수 있습니다.

2. 요구사항을 지연·보존·접속 숫자로 바꿉니다

‘빠르게’와 ‘오래’를 측정 가능한 조건으로 씁니다

“실시간으로 보여야 한다”는 문장은 견적과 설계에 도움이 되지 않습니다. 화면 갱신 주기, 알람 전달 허용 시간, 태그 수, 동시 사용자 수, 데이터 보존 기간을 숫자로 바꿔야 합니다. 예를 들어 핵심 운전 화면은 1초 이내 갱신, 관리자 대시보드는 10초 주기, 원시 데이터는 3개월, 1분 집계 데이터는 3년처럼 등급을 나눌 수 있습니다.

온프레미스는 서버 성능과 저장장치를 초기에 넉넉히 구매하면 비용 예측이 쉽지만, 사용량이 예상보다 적어도 투자비를 되돌리기 어렵습니다. 클라우드는 작은 규모로 시작할 수 있으나 태그 수, 데이터 수집 빈도, 저장량, 외부 전송량, 사용자 라이선스가 늘면서 월 비용이 커질 수 있습니다. 기술의 개념과 적용 맥락을 살펴보면 기술 선택은 도구 자체보다 목적과 활용 조건에 연결되어야 한다는 점을 확인할 수 있습니다.

1. 설비와 PLC별로 수집할 태그를 목록화합니다.
2. 태그마다 수집 주기와 변화 시 기록 여부를 정합니다.
3. 알람은 위험도에 따라 전달 목표 시간을 구분합니다.
4. 원시값과 집계값의 보존 기간을 따로 결정합니다.
5. 현장 운전원, 본사 관리자, 외부 협력사의 동시 접속 수를 계산합니다.

가령 태그 2만 개를 모두 1초마다 저장하는 방식과 값이 변할 때만 저장하는 방식은 스토리지와 네트워크 부하가 크게 다릅니다. 따라서 클라우드냐 온프레미스냐를 묻기 전에 어떤 데이터를 어느 해상도로 남길지 결정하는 것이 정확한 엔지니어링 순서입니다.

3. 보안 통제권과 운영 책임을 맞붙여 봅니다

내부 설치가 곧 안전을 뜻하지는 않습니다

온프레미스는 데이터와 서버를 공장 안에 둘 수 있어 망 분리 정책이나 고객사의 반출 제한을 충족하기 쉽습니다. 그러나 패치, 백업, 계정 관리, 인증서 갱신, 장애 감시를 모두 내부 인력이 맡아야 합니다. 인터넷과 분리된 서버라도 공용 관리자 계정, 오래된 운영체제, 검증되지 않은 USB 사용이 남아 있다면 안전하다고 보기 어렵습니다.

클라우드는 다중 인증, 중앙 로그, 관리형 백업, 지역별 이중화 같은 기능을 빠르게 적용할 수 있습니다. 대신 계정 탈취, 잘못 공개된 저장소, 과도한 외부 접속 권한처럼 설정 오류가 큰 위험이 됩니다. 공급자가 인프라를 보호하더라도 고객은 사용자 권한과 데이터 분류, 현장 게이트웨이 보안을 책임져야 한다는 공동 책임 구조를 계약과 운영 절차에 반영해야 합니다.

• 온프레미스 우세 조건: 데이터 외부 반출 금지, 폐쇄망 의무, 인터넷 없는 장시간 독립 운전
• 클라우드 우세 조건: 여러 사업장의 중앙 관제, 잦은 사용자 증감, 원격 협업과 분석
• 공통 필수 통제: 개인별 계정, 최소 권한, 다중 인증, 변경 기록, 복구 훈련
• 피해야 할 구성: PLC를 인터넷에 직접 노출하거나 업무망에서 제어망으로 무제한 접속 허용

원격 접속은 상시 개방보다 승인된 시간에만 열고, 접속 목적과 작업 내역을 기록하는 편이 안전합니다. 읽기 전용 조회와 제어 명령 권한도 분리해야 합니다. 누가 언제 설정값을 바꿨는지 추적되지 않는다면 플랫폼의 위치와 관계없이 운영 리스크가 커집니다.

4. 초기 구축비와 5년 운영비를 같은 표에 놓습니다

구매비 대 구독료만 비교하면 비용이 왜곡됩니다

온프레미스는 서버, 이중화 장비, 운영체제, 데이터베이스, 백업 장치, 항온·전원 설비와 구축 인건비가 초기에 집중됩니다. 클라우드는 초기 장비 부담이 낮지만 사용량 기반 요금, 전용 회선, 데이터 전송, 관리 서비스와 구독 라이선스가 반복됩니다. 어느 쪽이 저렴한지는 태그 규모와 보존 정책, 내부 운영 인력의 보유 여부에 따라 달라집니다.

소규모 단일 공장에서 태그와 사용자가 거의 늘지 않고 이미 서버실과 운영 인력이 있다면 온프레미스가 경제적일 수 있습니다. 반대로 여러 공장을 순차 연결하거나 프로젝트마다 데이터량이 크게 변하면 클라우드의 탄력성이 유리합니다. 견적은 부가세 포함 여부, 환율, 기술지원 등급에 따라 달라지므로 특정 금액 하나보다 5년 총소유비용의 구성 항목을 비교해야 합니다.

1. 초기 구축비와 연간 반복비를 분리합니다.
2. 데이터가 매년 20%, 50% 늘어나는 경우를 각각 계산합니다.
3. 내부 담당자의 운영 시간도 인건비로 반영합니다.
4. 장애 1시간당 생산 손실과 복구 목표를 비용에 포함합니다.
5. 계약 종료 시 데이터 추출·변환·삭제 확인 비용까지 넣습니다.

5. 작은 파일럿에서 장애 복구 능력을 겨룹니다

정상 화면보다 실패 상황을 먼저 시험합니다

두 선택지를 공정 전체에 곧바로 적용하기보다 대표 설비 한 개 라인으로 검증하는 편이 좋습니다. 다만 파일럿을 단순히 “데이터가 보인다”에서 끝내면 실전 적합성을 판단할 수 없습니다. 회선을 끊고, 게이트웨이를 재부팅하고, 센서값을 급격히 바꾸며 누락과 중복, 시간 순서가 어떻게 처리되는지 확인해야 합니다.

온프레미스 파일럿에서는 서버 한 대가 멈췄을 때 예비 서버 전환 시간과 백업 복원 성공 여부를 봅니다. 클라우드 파일럿에서는 인터넷 단절 중 데이터를 로컬에 얼마나 저장하는지, 재연결 후 어떤 속도로 동기화하는지 확인해야 합니다. 국내 기술의 해외 실증 성과를 다룬 K-디지털 글로벌 실증 사례처럼, 문서상 기능보다 실제 환경에서 검증된 결과가 도입 판단에 더 강한 근거가 됩니다.

• 회선을 30분, 4시간, 24시간 차단하고 로컬 버퍼 한계를 확인합니다.
• 서버 또는 수집기를 강제 종료한 뒤 자동 재기동 여부를 봅니다.
• 잘못된 시간대와 시계 오차가 데이터 순서에 미치는 영향을 검사합니다.
• 알람 폭주 상황에서 중요한 경보가 묻히지 않는지 측정합니다.
• 백업본으로 새 환경을 복원하고 실제 소요 시간을 기록합니다.

성공적인 데모는 기능을 보여주지만, 좋은 파일럿은 실패했을 때 생산이 어떻게 살아남는지를 보여줍니다.

평가표에는 화면 속도뿐 아니라 데이터 누락률, 장애 감지 시간, 복구 시간, 운영자 개입 횟수를 넣으세요. 공급사 설명 대신 같은 시험 조건과 동일한 점수 체계를 적용하면 클라우드 대 온프레미스의 장단점이 현장 언어로 드러납니다.

6. 전면 교체와 하이브리드 전환의 경계를 정합니다

현장 제어는 남기고 분석 계층부터 이동할 수 있습니다

오래된 SCADA가 불편하다고 해서 모든 PLC, HMI, 서버를 한 번에 바꿀 필요는 없습니다. 가동 중단이 어려운 공장은 기존 제어 화면과 인터록을 온프레미스에 유지하고, 복제된 데이터를 클라우드로 전달하는 하이브리드 구조가 현실적입니다. 이 방식은 생산 제어와 데이터 활용을 분리해 전환 위험을 낮춥니다.

반면 하이브리드는 시스템이 두 개가 되므로 태그 이름, 시간 동기화, 알람 기준, 사용자 권한을 이중으로 관리할 수 있습니다. 임시 구조를 장기간 방치하면 인터페이스가 누적되고 장애 책임도 불분명해집니다. 따라서 어떤 기능을 현장에 남기고 무엇을 이전할지, 임시 연계는 언제 제거할지를 목표 아키텍처와 전환 일정에 명시해야 합니다.

1. 첫 번째 순서: 기존 PLC와 SCADA에서 읽기 전용 데이터를 수집합니다.
2. 두 번째 순서: 클라우드에 생산·에너지 대시보드를 만들고 수치 일치 여부를 검증합니다.
3. 세 번째 순서: 장기 이력, 보고서, 예측 분석을 순차적으로 이전합니다.
4. 네 번째 순서: 운영자가 새 화면에 익숙해진 뒤 중복 기능을 제거합니다.
5. 다섯 번째 순서: 원격 제어가 꼭 필요할 때만 별도 위험 평가와 승인 절차를 거칩니다.

프로토콜도 특정 공급사 전용 방식에만 의존하지 않는 편이 좋습니다. OPC UA, MQTT 등 목적에 맞는 표준 인터페이스를 검토하고, 태그 사전과 단위 체계를 별도 문서로 관리하면 향후 플랫폼 변경 비용을 낮출 수 있습니다. 단, 표준을 쓴다는 사실만으로 상호운용성이 자동 보장되지는 않으므로 실제 장비 조합으로 연결 시험을 해야 합니다.

7. 생산 연속성부터 우선순위를 다시 세웁니다

최종 선택은 네 가지 질문의 순서로 좁힙니다

첫 번째 우선순위는 생산 연속성과 안전입니다. 인터넷이나 중앙 서버가 중단됐을 때도 현장 운전과 보호 기능이 유지되어야 한다면 로컬 제어 계층을 남겨야 합니다. 이 조건은 비용이나 화면 편의보다 먼저 판단해야 하며, 클라우드를 선택하더라도 엣지 게이트웨이의 저장과 독립 운전 기능을 요구사항에 넣어야 합니다.

두 번째는 보안·규제, 세 번째는 확장 속도, 네 번째는 총소유비용입니다. 외부 반출이 금지된 데이터가 많다면 온프레미스 또는 선별 전송형 하이브리드가 앞섭니다. 여러 사업장을 빠르게 연결하고 분석 기능을 자주 추가해야 한다면 클라우드의 이점이 커집니다. 마지막으로 동일한 5년 기간과 동일한 장애 조건을 적용해 비용을 비교해야 숫자가 공정해집니다.

• 1순위 생산 연속성: 외부 연결 없이 필수 조작과 알람이 유지되는가?
• 2순위 보안·규제: 어떤 데이터가 현장 밖으로 나갈 수 있으며 누가 승인하는가?
• 3순위 확장성: 향후 연결할 공장, 태그, 사용자 수가 얼마나 늘어나는가?
• 4순위 경제성: 구축비·구독료·인력·회선·장애 손실을 모두 계산했는가?
• 5순위 이탈 가능성: 계약 종료 시 데이터와 설정을 표준 형식으로 가져올 수 있는가?

선택이 여전히 어렵다면 핵심 제어는 온프레미스, 통합 조회와 분석은 클라우드로 두는 구성이 출발점이 될 수 있습니다. 이후 파일럿 결과에서 회선 복구, 데이터 정합성, 운영 부담이 검증되면 이전 범위를 넓히세요. 좋은 SCADA 엔지니어링은 최신 플랫폼을 고르는 일이 아니라, 장애가 발생해도 현장이 감당할 수 있는 구조를 순서대로 만드는 일입니다.