탄소 데이터 플랫폼은 인터넷이 연결된 화면에서 가장 안정적으로 보입니다. 센서값이 연속 곡선을 만들고, 농장별 지표가 갱신되며, 보고서 버튼이 동작합니다. 하지만 농장에서는 이동통신 음영, 공유기 장애, 전원 품질, 장비 점검 때문에 연결이 끊깁니다. 이때 화면이 잠시 멈추는 것보다 더 큰 문제는 나중에 무엇이 실제로 측정되었는지 설명할 증거가 사라지는 것입니다.

Carbon Data는 일반적인 앱 로그와 성격이 다릅니다. 적용 전후 비교, 외부 검토, 공급망 보고에 쓰일 수 있으므로 값뿐 아니라 측정 시각, 장치, 교정 상태, 품질 플래그, 변환 이력이 함께 살아 있어야 합니다. 단절 구간을 편의상 직선으로 채우거나 재연결 뒤 같은 데이터를 두 번 합산하면 감축 추정 자체가 흔들립니다. Edge–Cloud 설계는 연결 기술의 문제가 아니라 증거 연속성의 문제입니다.

오해부터 바로잡기: 클라우드 백업이 있으면 데이터는 안전한가

클라우드에 이미 올라간 데이터는 보호할 수 있지만, 단절 중 생성된 데이터는 아직 클라우드에 존재하지 않습니다. 현장 장치의 임시 메모리만 믿으면 재부팅이나 저장공간 부족으로 사라질 수 있습니다. 반대로 로컬 디스크에 파일을 남겼다고 끝나는 것도 아닙니다. 파일이 손상되거나 시각이 틀리고, 전송 완료 여부를 알 수 없거나, 누가 수정했는지 확인할 수 없다면 검증 가능한 기록이 아닙니다.

또한 ‘인터넷이 끊겼다’와 ‘센서가 멈췄다’는 구분해야 합니다. 센서는 정상 수집했지만 업링크만 끊겼을 수 있고, 게이트웨이 전원 장애로 수집 자체가 중단됐을 수도 있습니다. 두 상황을 모두 빈칸으로 표시하면 데이터 이용자는 원인을 알 수 없습니다. 수집 상태, 로컬 저장 상태, 클라우드 수신 상태를 분리해 관찰해야 합니다.

세 개의 시간과 하나의 식별자가 필요하다

현장 데이터 한 건에는 최소한 세 종류의 시간이 유용합니다. observed_at은 센서가 관측한 시각, received_at_edge는 게이트웨이가 받은 시각, ingested_at_cloud는 클라우드가 수신한 시각입니다. 정상 연결에서는 거의 비슷하지만 단절과 재전송이 발생하면 차이가 커집니다. 이 차이를 보존해야 측정 지연과 전송 지연을 구분할 수 있습니다.

시간은 UTC 기준의 명확한 오프셋을 포함한 형식으로 교환하고, 화면에서 현지시각으로 변환하는 편이 안전합니다. RFC 3339(이후 RFC 9557로 업데이트됨)는 인터넷 프로토콜에서 일관된 타임스탬프 표현을 정의합니다. 장치 시계가 동기화되지 않은 기간에는 값을 버리기보다 clock_status, 예상 오차, 교정 이벤트를 함께 기록합니다. 잘못된 시각을 조용히 덮어쓰면 급이·환기 사건과 메탄 변화를 잘못 연결할 수 있습니다.

각 관측에는 전역적으로 충돌하지 않는 event_id가 필요합니다. 재전송할 때 같은 관측을 새 데이터처럼 만들지 않고 동일한 ID를 유지합니다. 서버는 이미 처리한 ID를 다시 받아도 감축 집계가 늘어나지 않도록 멱등성을 보장해야 합니다. HTTP 표준도 PUT 같은 멱등 메서드는 동일 요청을 반복해도 의도한 효과가 같아 자동 재시도에 적합하다고 설명합니다. POST를 쓰더라도 별도의 멱등 키와 중복 판정 규칙을 정할 수 있습니다.

현장 시나리오: 17시간 단절 뒤 생기는 네 가지 오류

한 농장이 오후 3시부터 다음 날 오전 8시까지 인터넷이 끊겼다고 가정해 보겠습니다. 센서와 게이트웨이는 계속 작동했고 10초 주기의 데이터를 로컬에 저장했습니다. 연결이 복구되면 첫 번째 위험은 전송 폭주입니다. 최신 실시간 값과 17시간의 적체 데이터가 경쟁하면서 일부 메시지가 만료되거나 순서가 뒤섞일 수 있습니다.

두 번째는 중복입니다. 게이트웨이가 전송했지만 응답을 받기 전에 연결이 다시 끊기면 성공 여부를 알 수 없습니다. 복구 뒤 같은 묶음을 다시 보내는 것은 올바른 행동이지만, 서버가 같은 이벤트를 두 번 집계하면 배출량도 두 배가 됩니다. 세 번째는 시각 오류입니다. 단절 중 장치가 재부팅되어 시계가 초기화되면 관측 순서가 뒤집힐 수 있습니다. 네 번째는 저장공간 초과입니다. 사전에 용량을 계산하지 않았다면 가장 오래된 원자료가 조용히 덮어써질 수 있습니다.

이 네 오류를 막으려면 게이트웨이는 내구성 있는 큐에 데이터를 먼저 확정하고, 이벤트 ID와 순번을 부여한 뒤 전송해야 합니다. 클라우드가 수신과 영구 저장을 확인한 데이터만 로컬 보존정책에 따라 정리합니다. 최신 알림과 과거 적체를 서로 다른 우선순위로 전송하고, 서버는 농장·장치·시퀀스별 누락 범위를 계산합니다. 복구 완료는 ‘연결됨’ 표시가 아니라 예상 이벤트 수, 수신 수, 중복 수, 손상 수가 맞는지 대조한 뒤 선언해야 합니다.

Edge–Cloud 역할을 어떻게 나눌 것인가

엣지는 측정과 가장 가까운 증거 보존소입니다. 원자료 수신, 스키마 기본검사, 장치 상태 결합, 로컬 암호화 저장, 순번 부여, 전송 큐, 최소 현장 알림을 담당합니다. 단절 중에도 운영자가 최근 상태와 저장 여유를 볼 수 있어야 합니다. 중요한 설정의 로컬 변경도 감사 로그에 남깁니다.

클라우드는 여러 장치와 기간을 통합하는 계층입니다. 중복 제거, 장기 보존, 버전 관리, 농장 간 권한 분리, 분석, 보고서, 외부 API를 담당합니다. 엣지가 계산한 집계를 그대로 진실로 취급하지 않고 원자료와 계산 버전을 연결합니다. 클라우드에서 재계산한 결과와 현장에서 당시 생성한 결과가 다르면 두 값을 덮어쓰지 말고 차이와 이유를 기록합니다.

두 계층 사이의 계약은 메시지 스키마로 명시합니다. 필수 필드는 농장·축사·장치·센서 식별자, 이벤트 ID, 순번, 관측·수신 시각, 측정값과 단위, 품질 상태, 교정·설정 버전입니다. 스키마 버전이 바뀌면 이전 장치가 갑자기 거부되지 않도록 호환 규칙과 마이그레이션 기간을 둡니다. 알 수 없는 필드를 무시할지, 필수 필드가 빠진 데이터를 격리할지도 정해야 합니다.

저장 용량과 보존 기간은 숫자로 설계한다

‘충분히 큰 디스크’는 요구사항이 아닙니다. 센서 수 × 샘플 빈도 × 메시지 크기 × 최대 단절기간에 인덱스·로그·암호화 오버헤드와 안전여유를 더해 최소 용량을 계산해야 합니다. 예를 들어 센서가 늘거나 고해상도 모드가 켜졌을 때도 최대 단절기간을 버틸 수 있는지 시험합니다. 디스크 사용률이 경고와 위험 임계값을 넘으면 운영자에게 알려야 합니다.

모든 데이터를 영구 보존할 필요는 없지만 삭제 순서는 증거 가치에 따라야 합니다. 안전 사건과 탄소 주장에 연결된 원자료, 교정·설정 변경, 품질 판정 로그는 우선순위가 높습니다. 디버그 로그와 재생성 가능한 캐시는 낮을 수 있습니다. 압축과 집계는 허용하되 원본 삭제 시점, 재현 가능한 변환식, 보존 책임자를 정책으로 남깁니다.

백업도 ‘복사본 존재’가 아니라 복구 가능성으로 평가합니다. NIST SP 1339는 OT 백업을 변경관리와 통합하고, 정기 생성·시험하며, 복구 훈련에서 검토할 것을 강조합니다. 게이트웨이 설정, 인증서, 메시지 스키마, 모델·규칙, 장치 목록을 복원할 수 있어야 하며 운영 데이터와 비밀키의 백업 방식은 분리할 필요가 있습니다. 복구 시험은 원본 시스템을 위험하게 하지 않는 격리 환경에서 수행합니다.

신뢰성을 보안과 분리하지 말아야 하는 이유

공격자는 인터넷을 끊지 않고도 단절처럼 보이게 할 수 있습니다. 전송 큐를 삭제하고 시계를 바꾸거나, 오래된 데이터를 재생하고, 게이트웨이 설정을 조작할 수 있습니다. 따라서 데이터 전송 암호화만으로는 부족합니다. 장치 고유 신원, 인증서 회전, 서명된 업데이트, 저장 데이터 보호, 최소 권한, 변경 불가능하거나 외부로 복제되는 감사 로그가 필요합니다.

무결성 검사를 위해 메시지 묶음의 해시와 이전 묶음과의 연결을 남길 수 있습니다. 다만 해시가 있다고 센서값이 현실을 정확히 반영한다는 뜻은 아닙니다. 해시는 기록 이후의 변경을 탐지할 뿐, 조작된 설정으로 처음부터 잘못 측정한 값까지 고치지 못합니다. 교정, 물리적 봉인, 현장 점검과 데이터 무결성 통제를 함께 운영해야 합니다.

실행 체크리스트

  • 농장별 최대 예상 단절시간과 그 근거를 정했는가.

  • 센서 수·주기·메시지 크기로 로컬 저장용량을 계산했는가.

  • 관측 시각, 엣지 수신 시각, 클라우드 적재 시각을 구분하는가.

  • 이벤트 ID와 장치별 순번으로 중복·누락·순서 역전을 찾을 수 있는가.

  • 재전송이 반복되어도 집계 결과가 늘어나지 않는가.

  • 전송 완료 확인 전 원자료를 삭제하지 않는가.

  • 디스크 부족 시 삭제 우선순위와 현장 경고가 작동하는가.

  • 시계 동기화 실패와 재부팅 구간을 품질 상태로 남기는가.

  • 설정·인증서·스키마·데이터의 백업과 복구를 실제 시험했는가.

  • 단절 중 설정 변경과 수동 조치도 감사 로그에 기록되는가.

  • 복구 후 예상 건수와 수신·중복·손상 건수를 대조하는가.

  • 클라우드 미수신을 센서 미측정으로 오해하지 않게 표시하는가.

결론: 연결 복구가 아니라 증거 복구를 완료해야 한다

인터넷 단절은 예외가 아니라 농장 시스템의 정상적인 운영조건 중 하나입니다. 좋은 Edge–Cloud 구조는 끊기지 않는 네트워크를 가정하지 않습니다. 끊겨도 수집하고, 로컬에 안전하게 확정하며, 동일한 식별자로 다시 보내고, 서버에서 중복 없이 합치고, 누락과 시각 오류를 품질 상태로 남깁니다.

연결 아이콘이 초록색으로 돌아온 순간에 복구가 끝나는 것도 아닙니다. 단절 전후의 사건 순서, 데이터 수량, 장치 시각, 설정 버전과 무결성을 대조해야 Carbon Data의 Evidence Chain이 이어집니다. 탄소 데이터가 ‘살아 있다’는 말은 값이 어딘가 남아 있다는 뜻이 아니라, 나중에 누가 보더라도 무엇이 관측되고 어떻게 전달됐는지 설명할 수 있다는 뜻입니다.

출처