Edge 02. 도입 이유

개요

Edge Computing을 이해할 때 중요한 질문은 “무엇인가?”에서 끝나지 않는다. 실제 시스템 설계에서는 **왜 Edge Computing이 필요한가?**를 따져야 한다.

기존 cloud 중심 구조는 여전히 강력하다. 중앙 cloud는 대규모 compute, storage, global management, elasticity를 제공한다. 하지만 IoT device, camera, sensor, autonomous system, smart factory, retail store, telco network처럼 물리 세계와 직접 연결된 시스템에서는 모든 데이터를 중앙 cloud로 보내는 방식이 한계를 드러낸다.

Edge Computing이 필요한 핵심 이유는 다음 네 가지로 정리할 수 있다.

이유	의미
Data Control	데이터를 어디에서 처리하고, 어떤 형태로 중앙에 보낼지 통제
Cost Reduction	raw data 전체 전송, 저장, 처리 비용을 줄임
Faster Insights and Actions	데이터가 생긴 현장에서 빠르게 판단하고 action 수행
Continuous Operations	cloud 연결이 불안정해도 현장 시스템이 계속 동작

즉 Edge Computing은 단순한 성능 최적화가 아니라, 현장 데이터와 현장 action을 중심으로 시스템을 다시 설계하는 운영 전략이다.

---

Cloud-Only 구조의 한계

Cloud 중심 구조에서는 보통 다음 흐름을 가정한다.

Device / Sensor / Camera
        ↓
Network
        ↓
Cloud / Central Data Center
        ↓
Processing / Analytics / AI
        ↓
Decision
        ↓
Network
        ↓
Action

이 구조는 다음과 같은 workload에 적합하다.

• 일반적인 backend API
• batch analytics
• 장기 데이터 저장
• 대규모 model training
• centralized dashboard
• global policy management

하지만 모든 데이터와 모든 판단을 중앙 cloud에 의존하면 다음 문제가 생길 수 있다.

데이터 양 증가
→ network bandwidth 사용량 증가
→ cloud storage 비용 증가
→ cloud processing 비용 증가
→ latency 증가
→ 현장 action 지연
→ 연결 장애 시 운영 중단 위험 증가

특히 다음 데이터는 중앙으로 모두 보내기 어렵다.

• CCTV video stream
• LiDAR point cloud
• industrial sensor telemetry
• robot arm status
• vibration sensor data
• temperature / pressure / humidity data
• smart meter reading
• patient monitoring signal
• mobile network telemetry
• POS / inventory data
• autonomous vehicle sensor data

이런 데이터는 양이 많고, 현장성이 강하며, 빠른 판단이 필요한 경우가 많다. 따라서 다음 질문이 중요해진다.

이 데이터를 꼭 중앙 cloud까지 보내야 하는가?
현장에서 먼저 처리해도 되는가?
현장에서 바로 action해야 하는가?
중앙에는 raw data가 아니라 event나 summary만 보내도 되는가?

Edge Computing은 이 질문에 대한 구조적 답변이다.

---

첫 번째 이유: Data Control

Data Control은 Edge Computing을 도입하는 중요한 이유 중 하나다.

여기서 data control은 단순히 “보안이 좋아진다”는 뜻이 아니다. 더 정확히는 다음을 통제할 수 있다는 의미다.

• 데이터가 어디에서 처리되는가?
• raw data가 현장 밖으로 나가는가?
• 중앙 cloud에는 어떤 형태의 데이터가 올라가는가?
• 민감 데이터는 local에 남겨둘 수 있는가?
• 지역, 국가, 산업 규정에 맞게 data residency를 지킬 수 있는가?
• 현장별로 다른 보안 정책을 적용할 수 있는가?

Raw Data와 Derived Data 구분

Edge Computing에서 중요한 설계 기준은 raw data와 derived data를 구분하는 것이다.

구분	예시
Raw Data	원본 영상, 원본 음성, 전체 sensor stream, 상세 위치 정보, 개인 식별 가능 데이터
Derived Data	이상 감지 여부, 불량품 개수, 평균 온도, 혼잡도 수치, event timestamp, anonymized metadata

Edge에서는 raw data를 local에서 처리하고, 중앙에는 derived data만 보낼 수 있다.

예를 들어 retail 매장에서 camera를 사용하는 상황을 생각할 수 있다.

매장 camera
→ edge에서 사람 수 계산
→ "현재 매장 혼잡도: 높음"만 중앙 전송

이 구조에서는 원본 영상 전체가 중앙으로 이동하지 않는다. Cloud에는 운영에 필요한 결과만 올라간다.

의료 데이터 예시

의료 데이터는 민감도가 높다. 모든 환자 데이터를 중앙 cloud로 보내는 구조는 법적, 보안적, 운영적 부담이 크다.

Cloud 중심 구조는 다음과 같다.

환자 데이터
→ Cloud 전송
→ 분석
→ 결과 반환

Edge 구조에서는 다음처럼 바꿀 수 있다.

환자 데이터
→ 병원 내부 edge server에서 local analysis
→ 이상 징후 event만 중앙 시스템으로 전송

이 방식에서는 raw data를 병원 내부에 남겨두고, 중앙에는 필요한 event만 전송할 수 있다.

제조 데이터 예시

제조업에서도 data control은 중요하다.

다음 데이터는 기업의 핵심 기밀일 수 있다.

• 생산라인 영상
• 장비 vibration pattern
• 품질 검사 이미지
• 설비 이상 패턴
• 공정 조건
• 불량 발생 조건

이 데이터를 전부 외부 cloud로 보내지 않고 공장 내부 edge에서 먼저 처리하면 data leakage 위험을 줄일 수 있다.

Data Control은 운영 정책 문제이기도 하다

Data Control은 security만의 문제가 아니다. 운영 정책과도 연결된다.

예를 들어 여러 국가에 매장이 있는 기업이라면 국가별로 data 처리 정책이 다를 수 있다.

한국 매장:
  - raw video local retention 7일
  - 중앙에는 metadata만 전송

유럽 매장:
  - 개인정보 관련 데이터 local 처리
  - anonymized aggregate만 전송

미국 매장:
  - 특정 event clip만 central archive

이런 식으로 site별 data policy를 다르게 가져가려면 Edge Computing이 유리하다.

---

두 번째 이유: Cost Reduction

Edge Computing의 두 번째 이유는 Cost Reduction이다.

여기서 비용은 단순히 server 구매 비용만 의미하지 않는다. 실제 비용은 여러 계층에서 발생한다.

비용 항목	설명
Network cost	대량 데이터를 중앙으로 전송하는 비용
Cloud storage cost	raw data를 장기간 저장하는 비용
Cloud compute cost	모든 데이터를 중앙에서 처리하는 비용
Data egress cost	cloud에서 데이터를 다시 외부로 내보낼 때 발생할 수 있는 비용
Operational cost	장애 대응, 중앙 병목 처리, 대규모 pipeline 유지 비용
Latency cost	느린 의사결정으로 인해 발생하는 비즈니스 손실

모든 데이터의 가치는 같지 않다

현장에서 발생하는 데이터는 많지만, 모든 데이터가 같은 가치를 갖는 것은 아니다.

예를 들어 CCTV가 24시간 영상을 생성한다고 하자.

24시간 전체 영상 중
- 대부분은 아무 사건이 없는 정상 상태
- 일부만 사람이 지나감
- 아주 일부만 보안 이벤트
- 더 적은 일부만 장기 보관 가치가 있음

이때 모든 영상을 cloud로 보내고 저장하는 것은 비효율적이다.

Edge에서 먼저 다음을 수행할 수 있다.

전체 영상 수집
→ 움직임 감지
→ 사람 또는 차량 감지
→ 이상 이벤트 판별
→ 필요한 clip만 저장 또는 전송

이 방식은 network traffic, cloud storage, cloud analytics 비용을 모두 줄일 수 있다.

Data Reduction Layer로서의 Edge

Edge Computing의 비용 절감은 주로 data reduction에서 나온다.

Before Edge:
Raw Data 100%
→ Cloud 전송
→ Cloud 저장
→ Cloud 처리

After Edge:
Raw Data 100%
→ Edge local processing
→ Event / Summary / Metadata만 Cloud 전송

정확한 감소 비율은 workload마다 다르므로 확인 필요하다. 하지만 원리는 같다.

Edge는 모든 raw data를 중앙으로 보내기 전에, 현장에서 의미 있는 정보로 압축하는 계층이다.

Smart Factory 예시

공장에 vibration sensor가 1,000개 있다고 가정할 수 있다. 각 sensor가 초당 데이터를 계속 만든다면 중앙 cloud에는 많은 time-series data가 들어간다.

하지만 실제로 중요한 것은 대부분 다음 event다.

• 정상 범위 이탈
• 특정 주파수 이상 진동
• bearing failure pattern
• motor overheating
• cycle time anomaly
• 설비 정지 전조

Edge에서는 raw vibration stream을 local에서 분석하고, 이상 징후가 있을 때만 event를 중앙으로 보낼 수 있다.

vibration stream
→ edge feature extraction
→ anomaly detection
→ event only upload

이 구조는 network와 cloud 비용을 줄이고, 동시에 더 빠른 설비 대응을 가능하게 한다.

비용 절감은 확장성 문제이기도 하다

Cloud 중심 구조에서 device 수와 data volume이 증가하면 중앙 pipeline을 계속 키워야 한다.

더 많은 device
→ 더 많은 network traffic
→ 더 큰 ingestion pipeline
→ 더 큰 storage
→ 더 큰 analytics cluster
→ 더 복잡한 운영

Edge 구조에서는 일부 처리량을 site 단위로 분산시킬 수 있다.

각 site에서 local preprocessing
→ 중앙에는 정제된 데이터만 수집
→ 중앙 pipeline 부하 감소

따라서 Edge는 단순 비용 절감 도구가 아니라, 중앙 시스템의 scale pressure를 줄이는 architecture pattern이다.

---

세 번째 이유: Faster Insights and Actions

Edge Computing의 세 번째 이유는 Faster Insights and Actions다.

여기서 중요한 것은 insight만이 아니라 action까지 포함된다는 점이다.

Cloud analytics는 다음 흐름에 강하다.

데이터 수집
→ 장기 저장
→ 분석
→ dashboard
→ report
→ business decision

반면 Edge Computing은 다음 흐름에 강하다.

데이터 발생
→ 즉시 분석
→ 즉시 판단
→ 즉시 action

Insight와 Action의 차이

Insight는 “무슨 일이 일어나고 있는지 아는 것”이다.

예시는 다음과 같다.

• 이 장비는 진동이 증가하고 있다.
• 이 매장은 현재 혼잡도가 높다.
• 이 환자의 심박 패턴이 비정상이다.
• 이 차량 주변에 장애물이 있다.
• 이 network cell의 latency가 증가하고 있다.

Action은 그 insight를 바탕으로 실제 조치를 취하는 것이다.

• 장비 속도를 낮춘다.
• 작업자를 호출한다.
• 알림을 보낸다.
• 차량이 감속한다.
• network traffic을 우회시킨다.
• digital signage를 변경한다.
• robot arm을 정지시킨다.

Edge Computing의 가치는 insight를 빠르게 얻는 것에서 끝나지 않는다. 그 insight를 현장에서 바로 action으로 연결하는 데 있다.

Latency가 Architecture를 결정하는 경우

어떤 workload에서는 latency가 단순 성능 지표가 아니라 architecture 결정 요소다.

예를 들어 robot arm이 사람과 가까운 공간에서 움직이는 상황을 생각할 수 있다.

Camera detects human proximity
→ system decides whether to slow down or stop robot

이 판단을 cloud 왕복으로 처리하면 늦을 수 있다.

Camera
→ Cloud
→ AI inference
→ Cloud response
→ Robot stop

반면 edge에서 처리하면 control loop가 짧아진다.

Camera
→ Local edge inference
→ Robot stop

이런 경우 Edge Computing은 단순 최적화가 아니라 safety requirement를 만족하기 위한 architecture가 된다.

AI Inference와 Edge

현대 Edge Computing에서 중요한 workload 중 하나는 AI inference다.

AI lifecycle을 나누면 다음과 같다.

Training:
  - 대규모 데이터
  - 많은 GPU
  - 장시간 계산
  - Cloud 또는 중앙 cluster에 적합

Inference:
  - 현장 데이터 입력
  - 빠른 판단
  - 낮은 latency 필요
  - Edge에 적합한 경우 많음

즉 model training은 cloud에서 수행하고, 학습된 model을 edge에 배포해 현장에서 inference하는 구조가 자연스럽다.

Cloud:
  - model training
  - model registry
  - version management

Edge:
  - model inference
  - local decision
  - event upload

이 구조에서 중요한 운영 문제는 model version 관리다.

어떤 edge site에 어떤 model version이 배포되어 있는가?
특정 site에서 model 성능이 떨어지는가?
rollback은 가능한가?
offline site는 reconnect 후 어떻게 update되는가?
model drift는 어떻게 감지하는가?

따라서 Edge AI는 단순히 model을 작게 만드는 문제가 아니라, model lifecycle을 분산 환경에서 운영하는 문제이기도 하다.

---

네 번째 이유: Continuous Operations

Edge Computing의 네 번째 이유는 Continuous Operations다.

Cloud 중심 구조에서는 중앙과의 연결이 끊기면 현장 시스템이 멈출 수 있다.

현장 device
→ Cloud 연결 실패
→ 처리 불가
→ action 불가
→ 운영 중단

Edge 구조에서는 local node가 최소 기능을 계속 수행할 수 있다.

현장 device
→ local edge processing
→ local decision
→ local action
→ cloud reconnect 후 sync

핵심은 Local Autonomy

Continuous Operations의 핵심은 Local Autonomy다.

즉 중앙 cloud가 잠시 보이지 않아도 edge site가 스스로 계속 동작해야 한다.

Retail 예시

Retail 매장에서 WAN 장애가 발생할 수 있다.

WAN 장애 발생
→ 중앙 Cloud API 접근 불가
→ 매장 POS, inventory, queue management 중단 위험

Edge 구조에서는 매장 내부 edge node가 local cache와 local service를 제공할 수 있다.

WAN 장애 발생
→ local edge service 계속 동작
→ transaction/event local buffer 저장
→ 연결 복구 후 중앙 sync

Smart Factory 예시

Smart Factory에서 cloud 연결 장애가 발생하면 monitoring이나 safety response가 늦어질 수 있다.

Cloud 연결 장애
→ 설비 monitoring 중단
→ safety system 지연

Edge 구조에서는 공장 내부 edge server가 계속 sensor data를 분석하고, 위험 상황에서 local action을 수행할 수 있다.

Remote Site 예시

선박, 광산, 농장, 항공, 재난 현장처럼 연결이 불안정한 곳에서는 중앙 cloud 의존도가 높으면 시스템 안정성이 떨어진다.

이런 환경에서는 edge가 local operation을 유지하는 역할을 한다.

---

Local-First와 Eventual Sync

Continuous Operations를 제대로 구현하려면 local-first 구조와 eventual sync가 필요하다.

정상 상태:
  Edge → Cloud 실시간 또는 준실시간 sync

연결 장애:
  Edge local operation 유지
  local buffer에 event 저장
  critical action은 local에서 수행

연결 복구:
  buffered event upload
  state reconciliation
  policy / model / config update

이 구조는 edge server를 배치한다고 자동으로 만들어지지 않는다. Application이 offline tolerance를 고려해 설계되어야 한다.

필요한 요소는 다음과 같다.

• local database
• durable queue
• retry mechanism
• idempotent event processing
• conflict resolution
• timestamp ordering
• local policy cache
• reconnect 후 reconciliation
• partial failure handling

따라서 Continuous Operations는 infrastructure 문제이면서 동시에 application architecture 문제다.

---

왜 지금 Edge Computing이 중요해졌는가?

Edge Computing 자체가 완전히 새로운 개념은 아니다. CDN, branch server, industrial control system, embedded system은 오래전부터 존재했다.

그럼에도 최근 Edge Computing이 더 중요해진 이유는 여러 흐름이 동시에 겹쳤기 때문이다.

IoT Device 증가

IoT device와 connected system이 늘어나면서 데이터 생성 지점이 폭발적으로 많아졌다.

예전에는 사용자가 직접 만든 request가 중심이었다면, 지금은 기계와 sensor가 자동으로 데이터를 계속 만든다.

사람 중심 request
→ device 중심 continuous data stream

이 변화는 architecture를 바꾼다.

AI/ML Workload 증가

현장 data를 단순 저장하는 것에서 끝나지 않고, AI로 실시간 분석하려는 요구가 커졌다.

예시는 다음과 같다.

• defect detection
• object detection
• predictive maintenance
• anomaly detection
• fraud detection
• patient risk detection
• traffic flow optimization

AI inference는 빠른 data access와 local decision이 중요하기 때문에 edge와 잘 맞는다.

5G와 MEC

5G는 edge 확산의 중요한 배경이다.

5G가 무선 구간의 bandwidth와 latency를 개선하더라도, application server가 멀리 있으면 end-to-end latency는 여전히 커질 수 있다.

그래서 telco 환경에서는 compute를 사용자와 가까운 위치, 예를 들어 기지국 근처나 regional office에 배치하는 MEC(Multi-access Edge Computing)가 중요해진다.

Hybrid Cloud 확산

대부분의 기업은 단일 cloud만 쓰지 않는다. on-premise, public cloud, private cloud, SaaS, branch site, edge site가 섞인다.

이런 환경에서는 workload를 어디에 배치할지 결정하는 것이 중요하다.

central cloud
private data center
regional site
branch office
factory edge
device edge

Edge Computing은 hybrid cloud architecture의 가장 바깥쪽 계층이라고 볼 수 있다.

---

Business 관점의 도입 이유

“왜 Edge Computing인가?”라는 질문은 기술적으로는 latency, bandwidth, data control의 문제다. 하지만 business 관점에서는 다음 질문에 가깝다.

왜 기업은 데이터를 현장 가까이에서 처리해야 하는가?
왜 중앙 Cloud만으로는 충분하지 않은가?
왜 edge에 투자할 가치가 있는가?

그 답은 보통 다음 네 가지로 정리된다.

더 빠른 현장 대응

Retail에서는 고객 대기열, 재고 부족, 매장 혼잡도에 빠르게 대응할 수 있다.

Manufacturing에서는 설비 이상, 불량품 발생, 안전 위험에 빠르게 대응할 수 있다.

Healthcare에서는 환자 상태 변화에 빠르게 대응할 수 있다.

더 낮은 운영 비용

모든 raw data를 중앙으로 보내지 않고 edge에서 정제하면 network, storage, processing 비용을 줄일 수 있다.

더 강한 데이터 통제

민감한 데이터를 local에서 처리하고, 필요한 결과만 중앙으로 보내면 보안과 compliance 측면에서 유리하다.

더 높은 운영 연속성

Cloud 연결이 끊겨도 현장 기능이 유지된다.

이 네 가지가 합쳐지면 Edge Computing은 단순 infrastructure 최적화가 아니라 운영 모델의 변화가 된다.

---

DevOps 관점에서의 해석

DevOps 관점에서 Edge Computing이 필요한 이유는 workload 실행 위치가 business requirement에 직접 영향을 주기 때문이다.

일반적인 cloud-native 환경에서는 다음을 주로 고민한다.

어떤 cluster에 배포할 것인가?
어떤 namespace를 쓸 것인가?
replica 수는 몇 개인가?
service routing은 어떻게 할 것인가?
observability는 어떻게 할 것인가?

Edge 환경에서는 질문이 더 복잡해진다.

어떤 site에 배포할 것인가?
그 site의 network는 안정적인가?
그 site의 hardware는 충분한가?
그 site에서 data를 외부로 보낼 수 있는가?
offline 상태에서도 동작해야 하는가?
local action이 필요한가?
model version은 site별로 달라야 하는가?
중앙 registry에 접근할 수 없는 경우 어떻게 할 것인가?

즉 Edge DevOps는 단순 배포 자동화가 아니라 site-aware workload management다.

Edge 배포에서 고려할 항목

항목	질문
Site	어느 위치에 workload를 둘 것인가?
Latency	현장 action까지 허용 가능한 지연은 얼마인가?
Bandwidth	raw data를 중앙으로 보낼 수 있는가?
Storage	local에 얼마나 저장해야 하는가?
Offline	중앙 연결 없이 얼마나 버텨야 하는가?
Security	device identity와 인증서는 어떻게 관리하는가?
Update	offline site의 update는 어떻게 처리하는가?
Rollback	edge 배포 실패 시 현장에서 어떻게 복구하는가?
Observability	log와 metric을 언제, 얼마나 중앙으로 보낼 것인가?

Edge 환경의 배포 전략

Edge에서는 일반적인 rolling update만으로 충분하지 않을 수 있다.

site별로 다음 전략이 필요할 수 있다.

1. small canary site에 먼저 배포
2. 정상 동작 확인
3. 동일 hardware group으로 확대
4. region 단위 확산
5. 실패 site 자동 제외
6. local rollback 수행
7. 중앙 control plane과 상태 동기화

특히 AI model을 edge에 배포할 때는 application version과 model version을 분리해서 관리하는 것이 좋다.

application version: v1.8.2
model version: defect-detector-2026.06.01
site group: factory-a-line-3
hardware profile: gpu-edge-small

이런 metadata가 없으면 edge fleet이 커질수록 운영이 어려워진다.

---

Edge Computing 도입 판단 기준

모든 시스템에 Edge Computing이 필요한 것은 아니다.

Edge를 도입해야 하는지 판단하려면 다음 질문을 던져야 한다.

Edge가 유리한 경우

질문	Edge가 유리한 상황
latency가 중요한가?	real-time control, safety, AR/VR, robot, vehicle
데이터 양이 큰가?	video, sensor stream, LiDAR, telemetry
local action이 필요한가?	설비 제어, 현장 알림, 자동 정지
network가 불안정한가?	원격지, 이동체, 지하, 해상, 재난 현장
민감 데이터인가?	의료, 금융, 공공, 제조 기밀
중앙 전송 비용이 큰가?	continuous high-volume stream
site가 많은가?	매장, 공장, 기지국, 물류센터
offline operation이 필요한가?	cloud 연결 없이도 local service 유지 필요

Edge가 필요하지 않을 수 있는 경우

다음 경우에는 cloud 중심 구조가 더 단순하고 적합할 수 있다.

• latency 요구사항이 낮다.
• 데이터 양이 작다.
• local action이 필요 없다.
• 모든 데이터를 중앙에서 통합 분석해야 한다.
• 현장에 server를 둘 운영 능력이 없다.
• 보안상 현장 장비 노출이 더 위험하다.
• offline operation 요구가 없다.
• workload가 batch 중심이다.

즉 Edge는 “무조건 좋은 구조”가 아니라 요구사항이 맞을 때 강력한 구조다.

---

흔한 오해

오해 1. Edge는 Cloud를 대체한다

Edge는 cloud를 대체하기보다 보완한다.

Cloud:
  - global intelligence
  - model training
  - long-term storage
  - centralized policy
  - fleet management

Edge:
  - local decision
  - real-time inference
  - event filtering
  - local action
  - offline continuity

오해 2. Edge는 latency만을 위한 기술이다

Latency는 중요하지만 전부가 아니다.

Edge의 이유는 다음 요소가 함께 작동한다.

latency
+ bandwidth
+ data control
+ cost
+ reliability
+ compliance
+ continuous operations

오해 3. Edge는 장비만 사면 된다

Edge Computing은 hardware 구매 문제가 아니다.

진짜 어려운 부분은 다음이다.

• fleet management
• remote deployment
• security patch
• certificate rotation
• monitoring
• rollback
• offline sync
• model lifecycle
• site별 policy 관리

오해 4. 모든 데이터를 Edge에만 두면 된다

Edge에만 데이터를 두면 global analytics가 어려워질 수 있다.

따라서 보통은 다음 균형이 필요하다.

local raw data
+ central metadata
+ selected event upload
+ periodic aggregate sync

---

Architecture Pattern

Cloud-Only 구조

Camera / Sensor
      ↓
Cloud Ingestion
      ↓
Cloud Storage
      ↓
Cloud Analytics
      ↓
Dashboard / Alert
      ↓
Action

이 구조는 중앙 관리가 쉽다. 그러나 latency, bandwidth, privacy, offline operation 문제가 생길 수 있다.

Edge + Cloud 구조

Camera / Sensor
      ↓
Edge Gateway
      ↓
Local Edge Inference
      ↓
Local Action
      ↓
Filtered Event Upload
      ↓
Cloud Analytics / Long-term Storage

이 구조에서는 현장 판단은 edge가 담당하고, 장기 분석과 전체 관리는 cloud가 담당한다.

Edge-Native 운영 구조

Cloud Control Plane
      ↓
Policy / Model / App Deployment
      ↓
Edge Sites
      ↓
Local Execution
      ↓
Event / Metric / Log Sync
      ↓
Central Observability

이 구조에서 중요한 것은 중앙 control plane이 일시적으로 보이지 않아도 edge site가 local desired state를 유지하는 것이다.

---

검증 포인트

Edge Computing을 도입할 때는 개념적으로 유리하다는 이유만으로 결정하면 안 된다. 다음 항목을 검증해야 한다.

검증 항목	확인할 내용
Latency	cloud 왕복과 edge local 처리의 end-to-end latency 차이
Data Volume	raw data와 derived data의 전송량 차이
Local Storage	offline 기간 동안 저장 가능한 event와 log 용량
Failure Mode	WAN 장애, cloud API 장애, registry 장애 시 동작
Rollback	edge 배포 실패 시 local rollback 가능 여부
Security	device identity, 인증서, image signing, local encryption
Observability	offline 상태에서 metric과 log를 어떻게 보존하고 전송할지
Cost	network, storage, compute, 운영 비용의 전체 변화
Compliance	raw data local 처리와 중앙 전송 데이터의 정책 적합성

---

요약

Edge Computing이 필요한 이유는 모든 데이터를 중앙 cloud로 보내는 방식이 현실적인 한계를 갖기 때문이다.

핵심 이유는 다음 네 가지다.

Data Control
Reduced Costs
Faster Insights and Actions
Continuous Operations

Edge는 데이터를 생성 지점 가까이에서 처리해 다음 효과를 만든다.

• 민감 데이터의 이동을 줄이고 data control을 강화한다.
• raw data 전체 전송, 저장, 처리 비용을 줄인다.
• insight를 현장에서 빠르게 action으로 연결한다.
• cloud 연결 장애 상황에서도 local operation을 유지한다.
• 중앙 cloud pipeline의 scale pressure를 줄인다.
• site-aware workload management를 가능하게 한다.

결국 Edge Computing은 단순한 인프라 배치 방식이 아니다. 데이터가 생성되는 현장, 판단이 필요한 위치, 실제 action이 수행되는 위치를 중심으로 workload를 재배치하는 architecture strategy다.