“안전 데이터는 Edge에 두고 탄소 데이터는 Cloud에 둔다”는 문장은 이해하기 쉽습니다. 가스 위험 경보는 즉시 반응해야 하고, 장기간 탄소 분석은 많은 저장공간과 계산 자원이 필요하기 때문입니다. 그러나 실제 시스템을 이 두 칸으로만 나누면 중요한 질문이 빠집니다. 안전 사건의 이력을 클라우드에 보존하지 않아도 되는가, 탄소 원자료는 인터넷이 끊기면 버려도 되는가, 현장 보정과 품질검사는 어디에서 실행할 것인가입니다.
데이터 배치는 데이터 이름이 아니라 결정의 시간, 연결 단절 허용도, 원자료 보존, 계산량, 기밀성, 현장 복구 능력으로 정해야 합니다. 하나의 메탄 관측도 로컬 경보에는 즉시 쓰이고, 일간 품질검사와 월간 탄소 집계에는 나중에 다시 쓰일 수 있습니다. 따라서 현실적인 구조는 Edge와 Cloud 중 하나를 고르는 것이 아니라 기능과 복제본의 역할을 나누는 것입니다.
오해 교정: 위치보다 책임을 먼저 정한다
Edge는 센서 내부, 게이트웨이, 농장 서버처럼 데이터 발생원 가까운 계산·저장 영역을 뜻할 수 있습니다. Cloud는 원격의 확장 가능한 저장·분석 서비스를 가리킵니다. NIST SP 500-325는 대규모·이종 IoT와 높은 지연이 전통적인 클라우드 중심 구조의 과제가 될 수 있으며, 네트워크 가까이 계산·관리·분석을 분산하는 포그 모델을 설명합니다.
하지만 Edge라고 항상 빠르고 안전한 것도, Cloud라고 항상 느리고 불안한 것도 아닙니다. 전원이 불안정한 현장 게이트웨이는 클라우드보다 자주 멈출 수 있고, 관리되지 않는 로컬 장치는 패치와 백업이 어려울 수 있습니다. 반대로 클라우드는 장기 보존, 버전 관리, 여러 농장 비교와 접근 감사를 체계화하기 좋지만 외부망 단절 때 현장 조치를 보장할 수 없습니다.
따라서 먼저 기능의 책임을 정합니다. 위험 임계값 판단과 경광등 구동, 안전 환기 인터록은 어떤 장애에도 현장에서 지속돼야 하는가? 원자료 수집과 버퍼링은 몇 시간 또는 며칠을 견뎌야 하는가? 탄소 계산은 재현성과 승인 절차를 위해 어느 버전의 코드로 어디서 실행할 것인가? 이 질문의 답이 위치를 결정합니다.
첫 번째 원칙: 생명·설비 보호의 제어 루프는 현장에서 닫는다
사람이나 동물, 설비의 안전에 직접 연결된 기능은 인터넷 왕복을 전제로 해서는 안 됩니다. 가스 농도가 위험 기준을 넘었을 때 경보를 울리거나 환기 설비를 안전 상태로 전환하는 판단은 로컬에서 계속 동작해야 합니다. 클라우드는 상태를 모니터링하고 정책을 배포할 수 있지만, 연결이 끊겨도 마지막으로 검증된 안전 규칙과 로컬 센서 입력으로 보호 기능이 유지되어야 합니다.
여기서 탄소용 메탄 분석과 안전용 가스 감지를 같은 것으로 혼동하면 안 됩니다. 측정 범위, 응답시간, 설치 위치, 인증과 고장 안전 요구가 다를 수 있습니다. 한 센서 값을 두 용도에 사용할 수 있는지는 장치 사양과 위험성 평가로 확인해야 합니다. 탄소 모델의 보정이나 AI 이상탐지가 법정 또는 현장 안전장치를 대체한다고 가정해서는 안 됩니다.
NIST SP 800-82는 OT가 물리 환경을 감지하거나 직접 변화를 일으키며, 보안 대책도 성능·신뢰성·안전 요구를 고려해야 한다고 설명합니다. 안전 제어 경로에는 최소 기능, 우선순위, 수동 전환, 고장 시 상태와 정기 시험이 필요합니다. 클라우드 명령이 로컬 보호장치를 우회하지 못하도록 권한 경계를 둡니다.
두 번째 원칙: 탄소 원자료도 Edge에서 살아남아야 한다
탄소 데이터가 월말에 집계된다고 해서 현장 저장이 불필요한 것은 아닙니다. 농촌 통신은 끊길 수 있고 게이트웨이와 클라우드 사이에는 지연과 재전송이 생깁니다. Edge는 원자료를 순서대로 버퍼링하고 무결성 정보를 붙인 뒤 연결 복구 시 재전송해야 합니다. 저장 용량은 평균 발생량이 아니라 예상 최대 단절시간, 재전송 여유와 안전 로그 우선순위로 정합니다.
버퍼는 단순 파일 폴더보다 명확한 큐 정책이 필요합니다. 각 레코드에 장치 ID, 관측시각, 수신시각, 순번, 단위, 품질 상태와 해시 또는 서명을 붙입니다. 업로드 확인을 받은 뒤에만 로컬 보존 정책에 따라 삭제하고, 중복 전송은 고유 키로 안전하게 처리합니다. 저장공간이 부족할 때 무엇을 먼저 보존할지도 정해야 합니다. 안전 사건 원문과 교정·설정 변경 로그는 평시 고빈도 환경값보다 긴 보존이 필요할 수 있습니다.
로컬 집계는 전송량을 줄이지만 원자료를 너무 일찍 버릴 위험이 있습니다. 1초 값을 10분 평균으로만 보내면 피크와 장치 이상을 나중에 재검토하기 어렵습니다. 탄소 MRV에 필요한 시간해상도와 감사 가능성을 정한 뒤, 원자료·요약·이벤트의 보존기간을 다르게 설계합니다.
세 번째 원칙: Cloud는 장기 계보와 교차 농장 분석을 맡는다
클라우드의 강점은 많은 농장의 데이터를 같은 규칙으로 저장하고, 장기간 비교하며, 계산 버전과 승인 이력을 관리하는 데 있습니다. 메탄 원자료, 교정기록, 사육두수, 급여, 환기와 기상 데이터를 연결해 기준선과 감축량을 계산하고, 방법론·배출계수·코드가 바뀌었을 때 이전 결과를 재현할 수 있어야 합니다.
이때 클라우드 저장값을 진실의 유일한 원본이라고 부르기보다 데이터 단계별 권위를 정하는 편이 정확합니다. 장치 원시신호, 게이트웨이 수신기록, 보정 데이터, 분석용 정제 데이터와 승인된 보고 결과는 서로 다른 목적의 기록입니다. 원자료를 덮어쓰지 않고 파생 단계와 계산 계보를 연결합니다. OGC SensorThings 같은 표준 모델은 이종 센서의 관측과 메타데이터를 일관되게 교환하는 참고가 될 수 있습니다.
클라우드에서는 여러 농장에 무거운 모델을 실행하고 플릿 전체의 드리프트를 탐지할 수 있습니다. 그러나 학습된 모델이나 임계값을 Edge로 보낼 때는 버전, 서명, 승인자, 적용 대상과 롤백을 관리해야 합니다. 모델 배포도 펌웨어와 마찬가지로 원격 코드를 현장 의사결정에 넣는 변화이기 때문입니다.
현장 시나리오: 36시간 통신 장애
태풍으로 한 농장의 외부망이 36시간 끊겼다고 가정해 보겠습니다. 좋은 구조에서는 로컬 안전 경보와 환기 보호가 계속 동작합니다. 게이트웨이는 센서 관측과 팬·경보 사건을 UTC 시각과 순번으로 저장하고, 화면에는 클라우드 연결 이상과 남은 버퍼 시간을 보여 줍니다. 현장 담당자는 로컬 상태를 확인하고 수동 절차를 수행할 수 있습니다.
연결이 복구되면 게이트웨이는 오래된 관측부터 재전송합니다. 클라우드는 수신시각이 아니라 원 관측시각에 배치하고, 중복을 제거하되 원본 순번의 누락을 검사합니다. 36시간 동안 실행하지 못한 중앙 품질검사와 집계를 다시 수행하고, 지연 업로드 구간을 플래그합니다. 월간 탄소 보고는 완전성 확인 뒤에만 갱신됩니다.
나쁜 구조에서는 안전 경보가 클라우드 API 응답을 기다리거나, 탄소 원자료가 버퍼 없이 사라지거나, 복구 뒤 모든 값이 현재 시각으로 저장됩니다. 문제는 Edge냐 Cloud냐가 아니라 장애 중 각 기능의 책임과 복구 순서를 설계하지 않은 데 있습니다.
데이터 배치 결정을 위한 다섯 질문
첫째, 몇 초 안에 결정해야 하는가? 둘째, 연결이 몇 시간 끊겨도 기능이 유지돼야 하는가? 셋째, 잘못된 결정의 피해가 안전·생산·보고 중 어디에 나타나는가? 넷째, 원자료를 얼마나 오래 보존해야 재현과 검증이 가능한가? 다섯째, 장치와 클라우드 중 어디에서 보안 패치·접근통제·감사를 더 안정적으로 운영할 수 있는가?
이 질문에 따라 데이터를 분류합니다. P0 안전 제어는 로컬 판단과 로컬 출력, P1 안전·운영 사건은 로컬 즉시 보존과 클라우드 복제, P2 탄소 원자료는 로컬 버퍼와 신뢰 가능한 재전송, P3 장기 분석·보고는 클라우드 계산과 승인, P4 모델·설정은 중앙 관리와 서명된 현장 배포처럼 역할을 나눌 수 있습니다. 구체적인 등급명은 조직에 맞게 바꿔도 원칙은 유지됩니다.
실행 체크리스트
데이터가 아니라 데이터로 내리는 결정과 최대 허용 지연을 목록화합니다.
안전 제어가 인터넷과 클라우드 없이 계속 동작하는지 시험합니다.
탄소 원자료 버퍼를 최대 단절시간과 발생량 기준으로 산정합니다.
관측시각, 순번, 장치 ID와 품질 플래그를 재전송에도 보존합니다.
중복 제거, 누락 탐지, 업로드 확인과 재시도 규칙을 정합니다.
원자료, 요약, 사건과 감사로그의 보존기간을 다르게 정합니다.
Edge·Cloud 각각의 접근권한, 키, 패치, 백업과 복구 책임자를 둡니다.
모델·설정 배포에는 서명, 카나리, 승인과 롤백을 적용합니다.
지연 업로드와 모델 대체 구간이 탄소 결과에 미친 영향을 표시합니다.
정기적으로 통신 단절, 저장공간 부족과 클라우드 장애 훈련을 합니다.
결론
안전 데이터는 Edge, 탄소 데이터는 Cloud라는 구분은 유용한 출발점이지만 완성된 설계는 아닙니다. 안전 판단은 현장에서 닫혀야 하고, 탄소 원자료도 연결 단절 동안 현장에서 살아남아야 합니다. 클라우드는 장기 계보, 여러 농장 비교, 무거운 분석과 승인된 보고에 강점을 가집니다.
좋은 데이터 배치 전략은 Edge와 Cloud를 경쟁시키지 않습니다. 현장에는 즉시성과 복원력을, 중앙에는 확장성과 재현성을 맡기고, 같은 기록이 손실 없이 이동하도록 책임을 연결합니다. 가장 중요한 검증은 정상 상태의 대시보드가 아니라 인터넷을 끊었을 때입니다. 그때 안전 기능이 유지되고 탄소 원자료가 보존되며 복구 뒤 동일한 시간축으로 돌아온다면 배치 전략은 실제 현장을 견딜 준비가 된 것입니다.