WCS 데이터 보존: 장비 로그와 경보 기록을 얼마나 보관할까

결론부터. WCS 데이터 보존은 세 문장으로 끝난다. 하나. 초 단위 원시 데이터는 30~90일, 분 단위 집계는 1년, 일일 요약과 중요 이벤트는 영원히 보관한다. 둘. 세 계층에 저장한다 — 현장 산업용 PC는 핫 데이터만, 엣지 서버는 집계와 1년 윈도우, 클라우드는 콜드 아카이브 전용이다. 셋. 경보 기록과 작업 감사 로그는 따로 빼서 법령과 계약 요구에 따라 보관한다 — 장비 로그와는 완전히 다른 보존 정책이다. 아래는 왜 이렇게 돼 있는지와, 본 가동 전에 착지시키는 단계별 절차다.

WCS 데이터 보존이 이렇게 나뉘는 이유: 찾는 사람부터 시작해라

WCS 데이터를 조회하는 사람은 딱 세 종류다. 첫째, 사고 조사관. 뭔가 부서졌다, 화물이 손상됐다, 라인이 멈췄다, "정확히 무슨 일이 있었나"를 재구성해야 한다. 초 단위 원시 데이터가 필요하다 — 집계로는 현장을 재현할 수 없다. 둘째, OEE와 효율 분석가. 설비 종합 효율, 다운타임 분포다. 집계를 원한다. 초 단위 포인트로 월간 OEE를 계산하는 사람은 없다, 자해야. 셋째, 감사와 컴플라이언스. "이 경보를 누가 언제 확인했나", "어느 파라미터를 누가 바꿨나"를 원한다. 작업 기록, 전건이다.

보존 정책은 이 세 사람에게서 역산해서 만든다. 누가, 어느 세기로, 얼마나 거슬러 조회하는지 정하면, 매트릭스는 거의 자동으로 그려진다. 반대로 "다 보관해라, 언젠가 쓸모 있다"고 하는 사람은 현장을 돌려본 적이 없다. 아무도 조회하지 않는 데이터는 저장한 적 없는 데이터다.

앞에 역설적인 판단을 말해둔다. 영원히 보관할 가치가 가장 높은 건 장비 로그가 아니다 — 구성 변경 기록과 경보 확인 기록이다. 장비 로그는 "무슨 일이 있었나"에 답한다. 구성 변경은 "왜 일어났나"에 답한다. 내가 돌린 사고 리뷰 10번 중 9번은 "어느 파라미터를 누가 바꿨나"에서 끝났다. 이 함정을 세 번 봤다. 데이터는 다 있었는데, 광전 센서의 딜레이를 200ms에서 800ms로 바꾼 게 누군지 못 찾았고, 리뷰 회의가 범인 찾기가 됐다.

이제 계산이다. 계산식은 이거 — 자기 창고 숫자를 넣어라.

1일 데이터량 ≈ 포인트 수 × 86,400(초/일) × 레코드당 바이트 수

계산 예. 2,000포인트, 1초 샘플링, 레코드당 50바이트 — 하루 약 8.6GB, 90일에 약 780GB다. 그래서 원시 데이터를 영원히 보관할 수 없다. 스토리지가 비싸서가 아니라, 아무도 조회하지 않기 때문이다. 보관하는 건 SSD 무덤을 파는 것과 같다. 현장 산업용 PC에 780GB의 핫 데이터는 느린 쿼리와 고통스러운 백업을 뜻한다 — 그리고 언젠가 디스크가 가득 차고, 그게 아래 함정 1번이다.

WCS 데이터 보존, 단계별로: 본 가동 전 5가지

데이터 유형을 재고조사해라. WCS 데이터는 딱 다섯 버킷에 떨어진다 — 버킷당 한 행, 빠짐없이. PLC 포인트 로그, 경보 기록, 태스크 궤적, 작업 감사 로그, 구성·프로그램 변경이다. 재고조사할 때 각 버킷의 출처(어느 PLC, 어느 서비스가 쓰나)를 메모해라. 나중에 깨지면, 당황하지 말고 먼저 표를 읽는다.
데이터 보존 매트릭스를 그려라. 이 형식을 쓰고, 자기 사이트 숫자를 넣어라.

두 가지 주의. 경보 기록의 원시 보존에 고정 일수는 쓰지 마라 — "법령/계약에 따름"이라고 써라. 업계와 고객 계약은 다르고, 고정 숫자는 계약이 바뀌면 부채가 된다. 작업 감사와 구성 변경은 영구지만 양은 아주 작으니, 안심하고 보관해라 — 이게 위 섹션의 "영원히 보관할 가치가 가장 높은" 것이다.

스토리지 계층을 정해라. 현장 산업용 PC의 SSD는 7~30일분의 핫 데이터만 갖는다. 네트워크 장애 때도 쿼리가 돌게 하기 위해서다. 엣지 서버는 집계와 1년 윈도우를 갖는다. 클라우드는 콜드 아카이브 전용이다. 규칙 하나. 핫 데이터를 클라우드에 두지 마라 — 전송과 쿼리 요금이 가르쳐준다. 망설이면 먼저 데이터량 계산식을 돌리고, 엣지 서버 일회성 투자와 비교해, 감이 아니라 계산으로 정해라.

콜드 아카이브의 또 다른 숨은 비용. 복구다. 콜드 아카이브는 싸지만, 데이터를 되찾는 데 몇 시간~하루가 걸린다 — 긴급한 사고 조사에서는 영원이다. 그래서 "영원히 보관"은 "언제든 온라인"이 아니다. 데이터 보존 정책을 정할 때, 감사인과 고객과 먼저 복구 SLA를 확인해라. 다음 날 복구로 버틸 수 있는 건 콜드 아카이브로, 못 버티는 건 엣지 서버에 둔다. 이 트레이드오프는 본 가동 전에 정해라 — 나중에 아카이브 데이터를 옮기는 건 생각보다 훨씬 힘들다.

정리와 아카이브를 자동화해라. 정기 작업 + 디스크 수위 알림. 80%에서 경고, 90%에서 오래된 데이터부터 자동 아카이브다. 수위 알림은 사람이 진짜 읽는 곳으로 보내라 — 당번 채팅 그룹, 당번 전화다. 아무도 안 여는 공개 메일함이 아니다. 아카이브 실행마다 로그를 쓴다. 얼마나 아카이브하고, 얼마나 삭제했나. 장부는 맞춰라.
인수인계 문서다. 운영팀으로의 산출물 3개, 전부 필수. 보존 매트릭스(스테이크홀더 서명 — 서명은 "이 정책은 합의됨"의 의미), 정리·아카이브 작업 목록(스케줄, 책임자, 장애 시 절차서), 아카이브 복원 드릴 기록 1건(아카이브한 데이터가 정말 읽혀 돌아오는 것의 증거 — 해본 적 없는 드릴은, 종이 위에만 존재하는 아카이브다).

제어 캐비닛이 있는 WCS 컨베이어 라인

흔한 실패 모드: 네 가지 다 봤다

첫째. 본 가동 때 보존 정책이 없음. 2024년 10월, 중국 동부의 대형 이커머스 창고. 광군제 피크 2주 전, WCS 산업용 PC의 로컬 디스크가 로그로 가득 차 시스템이 멈췄다. 복구. 4시간의 다운타임, 긴급 익스포트와 아카이브, 정기 정리 추가, 수위 알림 후장착이다. 이 함정을 세 번 봤다. 갈수록 비싸졌다 — 1번은 테스트 환경, 2번은 비수기, 3번은 피크 직전이다. 한 문장의 교훈. 보존 정책은 본 가동 체크리스트에 올려라. 운영의 "나중에 생각하자" 리스트가 아니다.

둘째. 집계 로직이 코드에 굳고, 원시 데이터가 삭제됨. 어느 사이트는 90일 뒤 초 단위 데이터를 삭제했다. 6개월 뒤 경영진이 다른 OEE 계산식을 원했고, 원재료는 사라졌다. 옛 집계에서 역산하는 수밖에 없었다 — 전 방향으로 틀렸다. 교훈. 원시 데이터를 삭제하기 전에, 집계 정의가 동결됐는지 확인해라. 망설이면 원시 보존을 180일로 늘려라. 스토리지 비용 2배로 후회 보험을 산다. 싼 보험이다.

셋째. 경보 기록이 작업 로그와 섞임. 어느 3PL은 경보 기록을 30일만 보관했다. 4개월 뒤 고객이 화물 손상을 주장하며 그날의 경보 기록과 태스크 궤적을 요구했다 — 없어서, 고객이 말하는 대로 물었다. 경보 기록 보존은 고객 계약을 맺기 전에 정하고, 계약에 첨부해라. 나중에 고치는 건, 미리 계획하는 것의 10배가 든다.

넷째. 아무도 안 보는 정리 작업이다. 수위 알림은 3년 전에 퇴사한 사람의 메일함으로 갔다. 아무도 눈치채기 전에 디스크가 가득 찼고, 아카이브 작업은 3개월째 에러인데 아무도 몰랐다. 인수인계 목록에는 알림 수신자를 지명하고, 퇴사 시 후임을 지명하고, 후임의 서명을 받아라. 구식이다. 먹힌다.

본 가동 밤의 체크리스트 — 끝에 이 세 줄을 더해라. 스테이크홀더 승인된 보존 매트릭스, 정리 작업을 수동으로 1회 실행하고, 아카이브와 삭제의 로그를 확인, 3개월 전 아카이브를 무작위로 1건 뽑아 읽어 돌리는 아카이브 복원 드릴 1건이다. 이 세 줄이 끝나면, 데이터는 클로즈드루프라고 말할 수 있다. 안 끝났으면, 지금 해라.

Lin Xiao, WMS 도입 컨설턴트 지음

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.