산업자동화 예지보전, 엣지와 클라우드를 고르는 순서

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

모터 진동이 기준치를 넘었는데 클라우드 연결이 끊겼다면 설비를 멈출 수 있을까요? 반대로 공장 안에서만 데이터를 처리한다면 여러 생산라인에서 반복되는 고장 패턴을 제대로 발견할 수 있을까요? 산업자동화 예지보전을 설계할 때는 분석 기술보다 먼저 엣지와 클라우드 중 어디에서 판단할지 결정해야 합니다.

두 방식은 우열이 분명한 경쟁 제품이 아닙니다. 응답 시간, 데이터 규모, 보안 정책, 운영 인력에 따라 적합한 위치가 달라집니다. 이 글에서는 현장의 요구사항을 분리하고 비용과 장애 시나리오를 검토한 뒤, 실제 제어시스템에 적용하는 순서로 두 선택지를 맞붙여 보겠습니다.

첫째, 멈추면 안 되는 판단과 모아야 하는 분석을 나눕니다

엣지는 설비 가까이에서 즉시 판단합니다

엣지 분석은 산업용 PC, 지능형 게이트웨이 또는 설비 근처의 컨트롤러에서 데이터를 처리합니다. 진동, 전류, 압력처럼 짧은 시간에 크게 변하는 계측값을 현장에서 곧바로 분석하므로 네트워크 왕복 지연을 줄일 수 있습니다. 베어링 충격파가 급증하거나 모터 전류가 비정상적으로 흔들릴 때 즉시 경고를 내야 한다면 엣지가 유리합니다.

다만 엣지 장치는 연산 능력과 저장 공간이 제한적이고, 여러 현장에 배포한 분석 모델을 각각 관리해야 합니다. 장치 3대일 때는 간단하지만 게이트웨이가 100대로 늘어나면 펌웨어, 인증서, 모델 버전까지 관리 대상이 됩니다. 빠른 판단을 얻는 대신 분산 운영의 부담을 떠안는 구조입니다.

클라우드는 공장과 시간을 가로질러 패턴을 찾습니다

클라우드 분석은 여러 설비와 사업장의 데이터를 한곳에 축적해 장기 추세와 공통 고장 패턴을 탐색하는 데 강합니다. 동일한 펌프가 계절이나 원료 배치에 따라 어떻게 달라지는지 비교하고, 수개월의 이력으로 잔여 수명을 추정하려면 넓은 저장 공간과 탄력적인 연산 자원이 도움이 됩니다. 제어시스템의 기본 개념은 제어시스템 용어 설명에서도 확인할 수 있지만, 예지보전 분석 결과와 실시간 제어 명령은 역할을 명확히 구분해야 합니다.

• 엣지 우세: 수십 밀리초에서 수초 안에 경보가 필요하고 통신 단절 중에도 판단해야 하는 경우
• 클라우드 우세: 여러 라인, 공장, 계절의 데이터를 비교하고 분석 모델을 자주 개선하는 경우
• 분리 원칙: 설비 보호에 직접 관여하는 기능은 현장에 남기고 장기 최적화는 상위 분석 계층으로 보냅니다.
• 첫 질문: 이 분석이 늦어졌을 때 생산 손실이 생기는지, 단지 보고서 생성이 늦어지는지 구분합니다.

둘째, 계측 데이터의 속도와 의미를 기준으로 승부를 가릅니다

고속 파형은 엣지에서 줄여 보내는 편이 낫습니다

가속도 센서의 고속 진동 파형은 초당 수천 개 이상의 샘플을 만들 수 있습니다. 이런 원시 데이터를 모든 설비에서 계속 전송하면 네트워크와 저장 비용이 빠르게 커집니다. 엣지에서 RMS, 피크, 첨도, 주파수 대역별 에너지 같은 특징값을 계산한 뒤 필요한 결과만 보내면 데이터양을 크게 줄일 수 있습니다.

그렇다고 원시 파형을 모두 폐기하면 안 됩니다. 새로운 고장 유형이 나타났을 때 기존 특징값만으로는 원인을 다시 분석하기 어렵기 때문입니다. 정상 상태에서는 요약값을 전송하고, 임계치 초과 전후의 파형을 일정 시간 저장했다가 선택적으로 올리는 이벤트 기반 업로드가 현실적인 절충안입니다.

느린 공정값은 클라우드에서 관계를 찾기 좋습니다

온도, 유량, 탱크 레벨, 에너지 사용량처럼 초 또는 분 단위로도 의미가 유지되는 계측 데이터는 클라우드 집계에 잘 맞습니다. 생산량, 품질 검사 결과, 정비 이력과 결합하면 단일 센서만 볼 때 놓쳤던 관계를 발견할 수 있습니다. 예를 들어 펌프 진동은 정상이어도 토출 압력 대비 소비전력이 서서히 증가한다면 임펠러 오염이나 배관 저항 변화를 의심할 수 있습니다.

1. 센서별 샘플링 주기와 하루 데이터 발생량을 계산합니다.
2. 원시 데이터가 필요한 보존 기간과 특징값만 필요한 기간을 나눕니다.
3. 경보 전후 파형을 몇 초간 저장할지 정하고 장치 저장 용량을 산정합니다.
4. 시간 동기화 오차가 분석 결과에 미치는 영향을 시험합니다.

분석 위치를 고르기 전에 ‘모든 데이터를 모으자’는 요구부터 의심해야 합니다. 활용 목적과 보존 기간이 없는 데이터는 자산보다 운영 부채가 되기 쉽습니다.

셋째, 제어권과 보안 경계를 그은 뒤 연결 방식을 정합니다

클라우드 장애가 인터록을 흔들어서는 안 됩니다

예지보전 점수가 높아졌다는 이유만으로 클라우드가 PLC 출력이나 안전 계장 기능을 직접 바꾸게 설계하는 것은 신중해야 합니다. 네트워크 지연, 계정 오류, 모델 오판이 공정 정지로 이어질 수 있기 때문입니다. 안전 인터록과 필수 운전 로직은 독립된 현장 제어 계층에 두고, 분석 시스템은 권고값이나 정비 알림을 전달하는 역할부터 맡기는 편이 안전합니다.

자동 조치가 꼭 필요하다면 한 번에 전권을 넘기지 말아야 합니다. 첫 운영 기간에는 분석 결과를 표시만 하고, 다음에는 작업자 승인 후 조치하며, 충분한 검증을 거친 항목만 제한된 범위에서 자동 실행하는 순서가 적절합니다. 자동 감속이 허용되더라도 최저 운전 속도, 최대 변경 폭, 적용 가능 운전 모드를 PLC에서 다시 검사하도록 구성합니다.

보안은 엣지 대 클라우드가 아니라 전체 경로의 문제입니다

엣지라고 자동으로 안전한 것도 아니고 클라우드라고 항상 위험한 것도 아닙니다. 사용하지 않는 포트, 공유 계정, 장기간 갱신되지 않은 운영체제, 평문 프로토콜은 어느 위치에서나 취약점이 됩니다. 특히 정보유출과 침해 사고가 다양한 업종으로 확산되는 양상은 정보유출 관련 보도에서도 드러나므로, 생산망은 외부에 직접 노출하지 않고 구간별 보안 통제를 적용해야 합니다.

• 망 분리: 제어망, 현장 수집망, 업무망, 외부 서비스 구간 사이의 통신 방향과 허용 포트를 문서화합니다.
• 최소 권한: 분석 계정에는 필요한 태그의 읽기 권한만 부여하고 제어 쓰기 권한은 기본적으로 차단합니다.
• 암호화: 전송 구간 암호화와 장치 인증을 함께 적용하고 인증서 만료를 모니터링합니다.
• 감사 기록: 누가 모델을 바꾸고 임계치를 수정했는지 변경 이력을 남깁니다.
• 복구 시험: 게이트웨이 초기화, 계정 잠김, 인증서 만료 상황을 가정해 복구 시간을 측정합니다.

현장에서 자주 놓치는 항목은 시간 동기화입니다. 보안 로그와 계측 데이터의 시간이 다르면 사고 원인과 설비 이상 순서를 재구성하기 어렵습니다. NTP 또는 정밀 시각 동기화 체계를 선택하고, 연결이 끊겼을 때 장치 시계가 얼마나 틀어지는지도 점검해야 합니다.

넷째, 장비 가격보다 5년 운영비로 엣지와 클라우드를 겨룹니다

엣지 비용은 구매 뒤에 더 잘 보입니다

엣지 방식은 산업용 PC나 게이트웨이를 구매하면 끝나는 것처럼 보이지만 실제 비용은 설치 이후에 나타납니다. 패널 공간, 전원 장치, 통신 모듈, 예비품, 현장 방문, 운영체제 패치와 모델 배포가 모두 필요합니다. 팬리스 장비라도 주변 온도와 분진 조건에 따라 수명이 달라지므로 일반 사무용 PC 가격과 단순 비교해서는 안 됩니다.

예산을 잡을 때는 장치 한 대의 가격보다 설비 한 점을 5년간 분석하는 총비용을 계산해야 합니다. 국내외 공급사, 연산 성능, 방진·방수 등급, 이중 전원 여부에 따라 가격 차이가 커서 일률적인 금액을 제시하기 어렵습니다. 견적서에는 하드웨어뿐 아니라 초기 프로그램 작성, 현장 시운전, 연간 유지보수, 예비품 보유량을 분리해 적는 것이 좋습니다.

클라우드 비용은 사용량과 데이터 이동에서 갈립니다

클라우드는 초기 서버 구매 부담이 낮지만 수집 메시지 수, 저장 용량, 분석 연산 시간, 외부 반출 트래픽에 따라 비용이 누적됩니다. 데이터가 적은 실증 단계에서는 저렴해 보여도 센서 수와 보존 기간이 늘면 예상보다 빠르게 증가할 수 있습니다. 반면 여러 공장이 같은 분석 플랫폼을 공유한다면 중앙 운영 인력을 줄이고 모델 개선 결과를 빠르게 확산하는 효과가 있습니다.

1. 1단계: 센서 수, 샘플링 속도, 압축률로 월간 데이터양을 추정합니다.
2. 2단계: 정상 데이터, 이벤트 파형, 정비 기록의 보존 기간을 각각 정합니다.
3. 3단계: 엣지 장치 교체 주기와 현장 출동 비용을 포함합니다.
4. 4단계: 클라우드 저장, 연산, 전송, 백업, 기술지원 비용을 나눠 계산합니다.
5. 5단계: 생산 중단 1시간의 손실액을 산정해 장애 예방 편익과 비교합니다.

가령 소수의 핵심 설비에서 고속 진동을 분석한다면 엣지 장비 구매가 경제적일 수 있습니다. 반대로 전국 사업장의 저속 에너지 데이터를 모아 수요를 예측한다면 클라우드가 운영 효율을 높일 가능성이 큽니다. 독자님의 현장은 센서 수가 늘어날수록 장치가 더 많이 필요한 구조인지, 데이터만 늘어나는 구조인지부터 확인해 보십시오.

도입비가 가장 싼 구성을 찾기보다 고장 한 번을 놓쳤을 때의 손실과 오경보 한 번을 처리하는 비용을 함께 계산해야 예지보전의 투자 가치가 선명해집니다.

다섯째, 한 설비에서 검증한 뒤 하이브리드 구조로 넓힙니다

작은 실증도 성공 기준은 숫자로 정합니다

처음부터 전 공장을 연결하면 센서 문제, 통신 문제, 모델 문제가 한꺼번에 드러나 원인을 구분하기 어렵습니다. 고장 이력이 있고 생산 영향이 큰 설비 한 종류를 선정한 뒤 정상, 주의, 이상 상태를 구분할 수 있는 데이터를 확보하는 것이 먼저입니다. 펌프라면 진동만 달지 말고 전류, 흡입·토출 압력, 운전 속도와 정비 이력까지 함께 연결해야 설명 가능한 판단이 가능합니다.

실증의 성공 기준도 ‘대시보드가 잘 보인다’가 되어서는 안 됩니다. 탐지 가능한 고장 유형, 허용 오경보 횟수, 경보 선행 시간, 데이터 누락률, 장애 복구 시간을 수치로 정해야 합니다. 생산자동화 분야가 기계·전기·제어를 함께 다룬다는 점은 생산자동화산업기사 관련 설명에서도 살펴볼 수 있으며, 실제 프로젝트 역시 설비 담당자와 계측·제어 담당자의 협업이 필수입니다.

현장 판단과 중앙 학습을 연결합니다

실무에서는 어느 한쪽을 완전히 선택하기보다 엣지 추론 대 클라우드 학습으로 역할을 나누는 하이브리드 구조가 효과적입니다. 엣지는 센서 신호를 정제하고 즉시 경보를 발생시키며, 클라우드는 여러 설비의 이력으로 모델을 재학습합니다. 검증된 새 모델은 승인 절차를 거쳐 엣지 장치에 배포합니다.

중요한 것은 배포보다 되돌리기입니다. 새 모델이 특정 운전 조건에서 오경보를 늘리면 이전 버전으로 즉시 복귀할 수 있어야 합니다. 모델 파일, 학습 데이터 범위, 임계치, 승인자, 적용 장치 목록을 버전별로 남기면 ‘지난주부터 경보가 달라진 이유’를 추적할 수 있습니다.

• 대상 설비의 고장 모드와 감지 가능한 계측 변수를 연결합니다.
• 센서 설치 방향, 체결 토크, 측정 위치를 표준 작업서에 기록합니다.
• 네트워크 단절 중 엣지 경보와 로컬 저장이 유지되는지 시험합니다.
• 클라우드 재연결 후 중복 데이터와 누락 데이터가 어떻게 처리되는지 확인합니다.
• 기존 모델과 신규 모델을 같은 데이터로 비교한 뒤 승인된 버전만 배포합니다.
• 정비 완료 후 실제 고장 원인을 입력해 분석 결과의 정확도를 다시 평가합니다.

확장 순서는 같은 종류의 설비, 같은 라인, 다른 라인, 다른 사업장 순이 안정적입니다. 같은 모델명의 모터라도 부하와 설치 기반이 다르면 정상 진동 범위가 달라질 수 있으므로 임계치를 무조건 복제하지 않습니다. 공통 모델을 기본값으로 쓰되 현장별 기준선을 보정하는 방식이 관리성과 정확도의 균형을 잡아 줍니다.

여섯째, 모델과 통신 조건이 바뀌는 순간까지 운영 절차에 넣습니다

정확도는 시간이 지나면 자연스럽게 흔들립니다

예지보전 모델은 설치한 날의 정확도를 영구히 유지하지 않습니다. 원료, 생산 품목, 운전 속도, 윤활유, 부품 공급사, 주변 온도가 바뀌면 정상 데이터의 분포도 달라집니다. 이를 모델 드리프트 관점에서 감시하지 않으면 정상 설비를 이상으로 판단하거나 실제 이상을 놓칠 수 있습니다.

따라서 월별 정확도만 볼 것이 아니라 경보 후 실제 정비 결과가 무엇이었는지 연결해야 합니다. 작업자가 ‘이상 없음’만 선택하도록 하면 학습 자료가 빈약해지므로 베어링 손상, 축 정렬 불량, 센서 체결 문제, 공정 조건 변화처럼 원인을 세분화합니다. 모델의 재학습 주기는 달력으로 고정하기보다 오경보율이나 데이터 분포 변화가 기준을 넘을 때 검토하도록 설계하는 편이 효율적입니다.

기술과 요금제 변화에 대응할 출구를 남깁니다

클라우드 서비스의 기능과 요금 체계, 엣지 장치의 지원 기간, 산업용 통신 규격과 보안 요구사항은 시간이 지나며 달라질 수 있습니다. 2026년 현재 적절한 구성이 몇 년 뒤에도 최선이라는 보장은 없습니다. 특정 서비스만 이해할 수 있는 형식에 모든 데이터를 묶어 두면 플랫폼 이전 비용이 커지므로 원시 데이터와 주요 특징값을 표준적인 형식으로 내보낼 수 있는지 계약 전에 확인해야 합니다.

장치 공급 종료도 현실적인 변수입니다. 동일 모델을 구하지 못할 때 대체 하드웨어에 분석 프로그램을 옮길 수 있는지, 라이선스가 장치에 귀속되는지, 운영체제 보안 업데이트가 언제까지 제공되는지 문서로 받아 두십시오. 클라우드에서는 서비스 중단 시 로컬 운전이 유지되는 시간과 데이터를 다른 저장소로 반출하는 절차를 시험해야 합니다.

• 분기별: 오경보율, 미탐지 사례, 데이터 누락률과 통신비 변화를 검토합니다.
• 변경 발생 시: 모터·베어링·센서 교체 또는 운전 레시피 변경 후 기준선을 다시 수집합니다.
• 연 1회 이상: 네트워크 단절, 인증서 만료, 엣지 장치 고장, 클라우드 접근 불가를 가정한 복구 훈련을 수행합니다.
• 계약 갱신 전: 저장·연산 단가와 데이터 반출 조건, 기술지원 종료 일정을 다시 확인합니다.
• 확장 전: 신규 라인의 정상 범위가 기존 모델과 통계적으로 같은지 검증합니다.

결국 선택 순서는 고정되어 있지 않습니다. 지금은 짧은 응답 시간이 중요해 엣지가 앞서더라도, 데이터가 충분히 쌓이면 중앙 학습의 가치가 커질 수 있습니다. 반대로 통신 요금이나 보안 정책이 바뀌면 클라우드로 보내던 원시 데이터를 현장에서 요약해야 할 수도 있습니다. 분석 위치를 다시 바꿀 수 있는 데이터 구조와 운영 기록을 남겨 두는 것이 변화하는 산업자동화 환경에서 가장 오래가는 설계입니다.