53 KiB
53 KiB
A2A-gRPC 이중 계층 엣지 AIoT 멀티 에이전트 통신 프레임워크
시스템 설계 명세 (System Design Specification)
버전: 1.0.0
작성일: 2026-06-07
대상 독자: 분산 시스템 설계자, 엣지 AIoT 아키텍트, AI 에이전트 개발자
목차
- 설계 원칙
- 시스템 아키텍처 개요
- 계층별 설계 명세
- T2 엣지 게이트웨이 상세 설계
- 에이전트 상호작용 프로토콜
- 데이터 흐름 설계
- 장애 내성 설계
- 멀티테넌시 설계
- 관측성 설계
- 사례별 설계 적용
1. 설계 원칙 (Design Principles)
본 시스템의 모든 아키텍처 결정은 다음 7가지 guiding principle에 근거한다. 각 원칙은 엣지 AIoT의 물리적 이질성과 다중 에이전트 협업의 복잡성에서 도출되었다.
P1. Tier-Appropriate Protocol (계층 적합 프로토콜)
각 tier는 자신의 자원·연결성·전력 제약에 최적화된 프로토콜을 사용한다. T1 클라우드에는 gRPC/HTTP-2, T2 엣지에는 gRPC over QUIC, T3 현장 디바이스에는 MQTT/CoAP/BLE를 적용한다. 단일 프로토콜로 3-tier 전체를 포괄하려는 설계는 거부한다. 이는 임베디드 디바이스에 gRPC 풀스택을 강제할 때 발생하는 RAM·Flash 초과 문제와, 클라우드 서버에 MQTT를 사용할 때 발생하는 스키마 안전성 부재 문제를 동시에 해결하는 근거다.
P2. Semantic-Transport Separation (시맨틱-전송 분리)
에이전트 간 "무엇을 할 것인가(Task 위임·역량 광고)"와 "어떻게 전달할 것인가(Byte 전송)"를 명확히 분리한다. A2A/MCP는 시맨틱 계층에서 동작하고, gRPC/MQTT/CoAP는 전송 계층에서 동작한다. 이 분리는 전송 프로토콜을 교체해도 에이전트 협업 로직이 영향받지 않도록 보장한다.
P3. Hardware-Rooted Identity (하드웨어 기반 신원)
네트워크 주소(IP, MAC)나 소프트웨어 토큰만으로는 물리적 디바이스의 신원을 보장할 수 없다. 모든 신원 클레임은 TPM/Secure Element의 하드웨어 attestation 또는 Kubernetes Service Account 바인딩에 뿌리를 두어야 한다. SPIFFE/SPIRE가 이 하드웨어 신원을 동적 SVID로 추상화하여 상위 계층에 전달한다.
P4. Fail-Locally, Resume-Globally (국소 실패, 전역 재개)
T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정상 운영 조건이다. 단절 발생 시 T3 디바이스는 로컬 큐에 데이터를 보존하고, 재접속 시 Resume Token으로 마지막 위치부터 이어받는다. 이 원칙은 단절을 "복구해야 할 장애"가 아닌 "흡수해야 할 물리적 현실"로 취급한다.
P5. Defense in Depth (다층 보안)
보안 통제는 인프라 계층(Envoy Service Mesh, mTLS)과 애플리케이션 계층(gRPC Interceptor, RBAC)에 중복 배치한다. 어느 한 계층이 우회되더라도 다른 계층이 보호를 지속한다. T3 디바이스의 물리적 접근 가능성을 고려하여, 디바이스 변조 시 즉시 SVID를 폐기할 수 있는 동적 인증서 회전 메커니즘을 포함한다.
P6. Observable by Default (기본 관측성)
관측성(Tracing, Metrics, Logging)은 사후에 추가하는 기능이 아니라 프레임워크의 기본 구성 요소다. W3C traceparent는 T1→T2→T3 전 경로에 걸쳐 gRPC Metadata로 전파되며, T2 게이트웨이는 trace context의 fan-out 지점으로 작동한다. 관측성 없는 배포는 설계상 불가능하다.
P7. Schema-First Interoperability (스키마 우선 상호운용)
다수의 디바이스 클래스, 언어, 런타임이 공존하는 환경에서 상호운용성은 Protocol Buffers .proto 파일을 단일 진실 원천(Single Source of Truth)으로 삼는 Contract-First 접근으로만 보장된다. Buf Schema Registry(BSR)와 buf breaking CI 검증이 OTA 업데이트 중에도 하위 호환성을 자동으로 강제한다.
2. 시스템 아키텍처 개요
2.1 3-Tier 전체 조감도
╔══════════════════════════════════════════════════════════════════════════════╗
║ T1: CLOUD TIER (k8s / GPU 서버 / 데이터센터) ║
║ ║
║ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ ┌──────────────────┐ ║
║ │ LLM Agent │ │ PM / Planner│ │ Analytics │ │ A2A Orchestrator │ ║
║ │ (GPT/Claude│ │ Agent │ │ Agent │ │ (Task Registry) │ ║
║ │ /Gemini) │ │ │ │ │ │ │ ║
║ └──────┬──────┘ └──────┬──────┘ └──────┬───────┘ └────────┬─────────┘ ║
║ └────────────────┴─────────────────┴──────────────────┘ ║
║ │ A2A Protocol (Agent Cards / Tasks) ║
║ ┌──────────────────────────────────────────────────────────────────────┐ ║
║ │ Istio Service Mesh + Envoy Proxy + OTel Collector + SPIRE Server │ ║
║ │ OAuth2 + JWKS mTLS (k8s SA SPIFFE ID) Prometheus + Jaeger │ ║
║ └──────────────────────────────────────────────────────────────────────┘ ║
╚══════════════════════════════════════════╦═══════════════════════════════════╝
║
gRPC over QUIC (HTTP/3) / gRPC over HTTP/2
W3C traceparent in gRPC Metadata
mTLS + SPIFFE SVID
║
╔══════════════════════════════════════════╩═══════════════════════════════════╗
║ T2: EDGE TIER (Jetson / RK3588 / 산업용 PC / 5G MEC) ║
║ ║
║ ┌──────────────────────────────────────────────────────────────────────┐ ║
║ │ T2 EDGE GATEWAY (핵심 컴포넌트) │ ║
║ │ │ ║
║ │ ┌────────────┐ ┌─────────────┐ ┌──────────┐ ┌────────────────┐ │ ║
║ │ │ Protocol │ │ Message │ │ Buffer / │ │ Resume Token │ │ ║
║ │ │ Translator │ │ Normalizer │ │ Batcher │ │ Manager │ │ ║
║ │ │ MQTT↔gRPC │ │ JSON↔Protob │ │ Fan-in │ │ (disconnect) │ │ ║
║ │ └────────────┘ └─────────────┘ └──────────┘ └────────────────┘ │ ║
║ │ ┌────────────┐ ┌─────────────┐ │ ║
║ │ │ Device │ │ Metrics │ A2A Endpoint (SSE / Webhook) │ ║
║ │ │ Auth Relay │ │ Collector │ gRPC Interceptor (Trace Inject) │ ║
║ │ │ SVID Verify│ │ Prom→OTel │ │ ║
║ │ └────────────┘ └─────────────┘ │ ║
║ └──────────────────────────────────────────────────────────────────────┘ ║
║ ║
║ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────────────┐ ║
║ │ Edge Infer. │ │ Local LLM │ │ Envoy Edge Proxy (xDS Light) │ ║
║ │ Agent │ │ Agent │ │ SPIRE Agent + mTLS │ ║
║ └──────────────┘ └──────────────┘ └──────────────────────────────────┘ ║
╚══════════════════════════════════════════╦═══════════════════════════════════╝
║
MQTT 5.0 / CoAP (Confirmable) ║ gRPC-Lite / nanopb
BLE / Wi-Fi / LoRa / 5G NR ║ (고성능 임베디드)
TPM/SE X.509 SVID ║
║
╔══════════════════════════════════════════╩═══════════════════════════════════╗
║ T3: FIELD TIER (MCU / 임베디드 Linux / 로봇 / 센서 / AGV) ║
║ ║
║ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐ ║
║ │ Cortex-M │ │ AGV / │ │ CCTV / │ │ Smart │ │ Wearable / │ ║
║ │ Sensor │ │ Robot │ │ Vision │ │ Meter │ │ Vital Mon. │ ║
║ │ MQTT Pub │ │ gRPC-Lite│ │ gRPC │ │ MQTT │ │ BLE/MQTT │ ║
║ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └─────────────┘ ║
║ ║
║ [TPM/SE attestation] [X.509 SVID] [Offline Queue] [nanopb Protobuf] ║
╚══════════════════════════════════════════════════════════════════════════════╝
2.2 3계층 프로토콜 스택
┌─────────────────────────────────────────────────────────────┐
│ Layer 3: Semantic Layer (시맨틱 계층) │
│ - A2A Protocol: Agent Card 광고, Task 위임·탐색 │
│ - MCP (Model Context Protocol): 도구/데이터 바인딩 │
│ - SSE / Webhook: 비동기 Task 상태 업데이트 │
├─────────────────────────────────────────────────────────────┤
│ Layer 2: Transport Layer (전송 계층) │
│ - T1↔T2: gRPC over QUIC (HTTP/3) + Bidi Streaming │
│ - T2↔T2: gRPC Bidi Streaming (엣지 합의) │
│ - T2↔T3: MQTT 5.0 / CoAP Confirmable / gRPC-Lite │
│ - Retry Policy: Exponential Backoff + Jitter │
├─────────────────────────────────────────────────────────────┤
│ Layer 1: Security / Identity Layer (보안/신원 계층) │
│ - T1: OAuth2 + mTLS (k8s SA 기반 SPIFFE ID) │
│ - T2: SPIFFE SVID + 하드웨어 시리얼 기반 identity │
│ - T3: TPM/SE attestation + X.509 SVID │
│ - 2계층 거버넌스: Envoy Service Mesh + gRPC Interceptor │
└─────────────────────────────────────────────────────────────┘
2.3 Tier 간 연결 특성 요약
| 구간 | 전송 프로토콜 | 보안 | 지연 목표 | 단절 내성 |
|---|---|---|---|---|
| T1 ↔ T2 | gRPC over HTTP/2 or QUIC | mTLS + SPIFFE SVID | < 100ms | Resume Token + QUIC conn-migration |
| T2 ↔ T2 | gRPC Bidi Streaming | mTLS + SPIFFE SVID | < 10ms | 로컬 재연결 + Bidi 재확립 |
| T2 ↔ T3 (임베디드) | MQTT 5.0 / CoAP | X.509 SVID + TLS-PSK | < 1s | MQTT Last Will + QoS 1/2 |
| T2 ↔ T3 (고성능) | gRPC-Lite / nanopb | mTLS Lite | < 50ms | Resume Token |
| T3 ↔ T3 | MQTT / C-V2X / BLE Mesh | 디바이스 pairwise key | < 10ms | 로컬 큐 |
3. 계층별 설계 명세
3.1 시맨틱 계층 (A2A / MCP)
3.1.1 A2A Protocol 통합
A2A(Agent-to-Agent) Protocol은 에이전트가 서로의 역량을 발견하고 Task를 위임하는 표준 시맨틱 계층이다. 본 프레임워크에서 A2A는 다음과 같이 통합된다.
Agent Card 구조 (JSON)
{
"agent_id": "edge-inference-agent-t2-site-a",
"tier": "T2",
"capabilities": [
{"name": "visual_inspection", "modality": "vision", "latency_ms": 50},
{"name": "anomaly_detection", "modality": "timeseries", "latency_ms": 200}
],
"endpoint": {
"grpc": "grpcs://edge-site-a.internal:50051",
"a2a_sse": "https://edge-site-a.internal:8443/a2a/events",
"a2a_webhook": "https://edge-site-a.internal:8443/a2a/webhook"
},
"device_class": "edge-gateway",
"spiffe_id": "spiffe://edge/org/site-a/gateway/uuid-1234",
"schema_version": "v1.2.0"
}
Task 위임 흐름
- T1 Orchestrator가 Agent Card Registry를 조회하여 대상 T2 에이전트 선택
POST /a2a/tasks로 Task 객체 전송 (submitted 상태)- T2 에이전트가 Task 수신 후 processing 상태로 전환
- SSE 또는 Webhook으로 상태 변화(submitted → working → completed/failed) 비동기 전달
- T2는 하위 T3 디바이스에 대해 동일한 A2A 엔드포인트를 노출하여, T3 디바이스도 A2A Task로 모델링 가능
Rationale: A2A가 직접 gRPC 메소드가 아닌 HTTP(S)/SSE 기반으로 설계된 이유는, 방화벽 통과 용이성과 브라우저 호환성을 확보하기 위함이다. 반면 실제 데이터 전송(모델 업데이트, 센서 스트리밍)은 gRPC를 통해 이루어져 성능을 보장한다.
3.1.2 MCP (Model Context Protocol) 통합
MCP는 LLM 에이전트가 외부 도구(Tool)와 데이터 소스에 바인딩되는 표준 인터페이스를 제공한다.
T1 LLM Agent
│
├── MCP Tool: "query_sensor_data"
│ └── gRPC call → T2 Gateway → T3 Sensor
│
├── MCP Tool: "send_ota_command"
│ └── gRPC Unary → T2 Gateway → T3 Device
│
└── MCP Resource: "device_telemetry_stream"
└── gRPC Server Streaming → T2 Gateway fan-out
MCP 도구 호출은 T2 게이트웨이의 gRPC 인터셉터를 통해 traceparent가 자동 주입되어, LLM 추론 요청부터 T3 센서 응답까지의 전체 경로가 단일 trace로 연결된다.
3.2 전송 계층 (gRPC / QUIC / MQTT)
3.2.1 gRPC 4대 RPC 모드 매핑
| RPC 모드 | 사용 시나리오 | Proto 예시 |
|---|---|---|
| Unary | OTA 명령, 상태 조회, 설정 변경, A2A Task 결과 조회 | rpc SendOTA(OTARequest) returns (OTAResponse) |
| Server Streaming | T1→T2 모델 업데이트, T1→T2 LLM 토큰 스트리밍, T2→T3 펌웨어 청크 | rpc StreamModel(ModelRequest) returns (stream ModelChunk) |
| Client Streaming | T3→T2 센서 배치 업로드, OTA 청크 전송, 비디오 프레임 업로드 | rpc UploadTelemetry(stream SensorData) returns (UploadResult) |
| Bidi Streaming | T2↔T2 엣지 합의, AGV 충돌 회피, V2V 안전 메시지 | rpc Negotiate(stream ConsensusMsg) returns (stream ConsensusMsg) |
Rationale: Bidi Streaming을 T2↔T2 엣지 합의에 사용하는 이유는, 다수 엣지 노드가 단일 소켓을 통해 ms 단위의 상호 메시지 교환을 진행할 수 있어 소켓 수를 O(n²)에서 O(n)으로 줄이기 때문이다.
3.2.2 gRPC over QUIC (T1↔T2)
T1↔T2 광역 무선 구간에서는 gRPC를 QUIC(HTTP/3) 위에 실어 다음 이점을 얻는다.
- Connection Migration: 모바일 IP 변경 시(5G→Wi-Fi) TCP 연결 단절 없이 마이그레이션
- 0-RTT Handshake: 재연결 시 0-RTT로 즉시 재개 (Resume Token과 시너지)
- HOLB-Free Multiplexing: 여러 gRPC 스트림이 패킷 손실 시 상호 blocking 없이 독립적으로 재전송
gRPC Frame
└── HTTP/3 Frame
└── QUIC Packet
└── UDP Datagram
└── 5G NR / LTE / Wi-Fi Physical
3.2.3 T2↔T3 프로토콜 선택 기준
T3 디바이스 특성 분류:
RAM > 2MB?
/ \
YES NO (MCU/LoRa)
│ │
gRPC-Lite? MQTT 5.0 or CoAP
(nanopb) │
/ \ QoS 요구도 높음?
YES NO / \
│ │ YES NO
gRPC-Lite MQTT 5.0 CoAP MQTT QoS 0
(고성능 임베디드) (일반 IoT) (Confirmable) (저전력 센서)
3.3 보안/신원 계층 (SPIFFE/SPIRE)
3.3.1 SPIFFE ID 체계
각 tier의 SPIFFE ID는 계층적 네임스페이스로 설계하여, 정책 적용 시 와일드카드 매칭이 가능하도록 한다.
T1 클라우드 에이전트:
spiffe://cluster.local/ns/<namespace>/sa/<service-account>/agent/<agent-id>
예: spiffe://cluster.local/ns/ai-agents/sa/pm-agent/agent/pm-001
T2 엣지 게이트웨이:
spiffe://edge/<org>/<site>/gateway/<hardware-uuid>
예: spiffe://edge/acme/factory-line-a/gateway/550e8400-e29b
T3 현장 디바이스:
spiffe://iot/<org>/<site>/device/<serial-number>
예: spiffe://iot/acme/factory-line-a/device/agv-motor-ctrl-0042
3.3.2 Attestation 메커니즘
T1: Kubernetes Service Account Token 검증
→ SPIRE Server가 k8s API 통해 SA 존재 확인
→ SVID 발급 (단기 X.509, TTL: 1시간)
T2: 하드웨어 시리얼 + TPM PCR 측정값 attestation
→ SPIRE Agent가 TPM Quote 생성 후 SPIRE Server에 전송
→ Server가 제조사 TPM EK Certificate Chain 검증
→ SVID 발급 (TTL: 4시간, 자동 갱신)
T3: TPM 2.0 / Secure Element attestation
→ Device가 SE에서 서명된 Device Certificate 생성
→ T2 SPIRE Agent가 중계하여 SPIRE Server에 전송
→ SVID 발급 (TTL: 24시간, 오프라인 시 Local CA 위임 가능)
3.3.3 2계층 통신 거버넌스
┌──────────────────────────────────────────────────────┐
│ Layer 1: Infrastructure (Envoy / Service Mesh) │
│ - mTLS 종단(SPIFFE SVID 기반 인증서 자동 교체) │
│ - 카나리 라우팅, 글로벌 Rate Limiting │
│ - xDS Light로 T2 게이트웨이에 정책 push │
│ - Circuit Breaker, Health Check │
├──────────────────────────────────────────────────────┤
│ Layer 2: Application (gRPC Interceptor) │
│ - 디바이스 클래스별 페이로드 크기·빈도 검증 │
│ - 디바이스 컨텍스트 전파 (battery_level, link_rssi) │
│ - 단절 시 Resume Token 발급·검증 │
│ - W3C traceparent 주입·추출 │
│ - Deadline 강제 주입 (디바이스 클래스별 정책) │
└──────────────────────────────────────────────────────┘
Rationale: 2계층 분리의 핵심 이점은 관심사 분리다. Service Mesh는 인프라 팀이 제어하여 앱 변경 없이 네트워크 정책을 배포할 수 있고, gRPC Interceptor는 개발팀이 비즈니스 로직 수준에서 디바이스 컨텍스트를 활용할 수 있게 한다. T2 엣지 노드는 전체 Istio 대신 Envoy Mobile(xDS Light)로 경량화하여 제한된 자원 안에서 메쉬 기능을 구현한다.
4. T2 엣지 게이트웨이 상세 설계
T2 엣지 게이트웨이는 본 아키텍처의 핵심 허브다. 이 컴포넌트 하나가 3-tier 전체의 프로토콜 이질성, 보안 경계, 단절 복구, 관측성 집약을 담당한다.
4.1 컴포넌트 다이어그램
T1 방향 (gRPC over QUIC / HTTP-2)
│
┌───────────────▼───────────────────────────────┐
│ gRPC Server (T1 facing) │
│ Unary / Server-Streaming / Client-Streaming │
└───────────────┬───────────────────────────────┘
│
┌───────────────▼───────────────────────────────┐
│ Interceptor Chain (공통) │
│ [Auth] → [Trace Inject] → [Deadline] → │
│ [Rate Limit] → [Resume Token] → [Metrics] │
└───────────────┬───────────────────────────────┘
│
┌──────────┬───────────┼───────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│Protocol│ │Message │ │ Buffer │ │ Resume │ │ Device │
│Transltr│ │Normalzr│ │Batcher │ │ Token │ │ Auth │
│ │ │ │ │ │ │ Manager │ │ Relay │
│MQTT │ │JSON │ │T3 fan-in│ │Offset │ │SVID │
│topic → │ │↕ │ │N msgs → │ │store │ │verify │
│gRPC │ │Protobuf│ │1 Stream │ │(Redis) │ │→ T1 mTLS │
│method │ │ │ │ │ │ │ │ │
└────┬───┘ └────────┘ └────┬────┘ └─────────┘ └──────────┘
│ │
└──────────┬───────────┘
▼
┌───────────────────────┐ ┌───────────────────────┐
│ MQTT Broker (Mosq.) │ │ CoAP Server │
│ T3 Pub/Sub 처리 │ │ Confirmable/Observe │
└───────────┬───────────┘ └───────────┬───────────┘
│ │
└──────────┬─────────────────┘
▼
T3 방향 (MQTT / CoAP / BLE)
┌──────────────────────────────────────────────────┐
│ A2A Endpoint Server (HTTP/S) │
│ GET /a2a/agents → Agent Card 응답 │
│ POST /a2a/tasks → Task 위임 수신 │
│ GET /a2a/events (SSE) → Task 상태 스트리밍 │
│ POST /a2a/webhook → Task 상태 콜백 수신 │
└──────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────┐
│ Metrics Collector │
│ Prometheus Exporter → OTel Collector → Jaeger │
│ Custom Metrics: resume_token_count, │
│ protocol_translation_latency_ms, │
│ t3_connection_drops_total │
└──────────────────────────────────────────────────┘
4.2 6대 모듈별 책임 명세
Module 1: Protocol Translator (프로토콜 변환기)
책임: T3 디바이스의 MQTT publish 메시지를 T1 방향 gRPC 메소드 호출로 변환, 반대 방향도 지원.
변환 규칙 예시:
MQTT topic: iot/{org}/{site}/{device_serial}/telemetry
↓ 매핑 테이블 조회
gRPC method: SensorService.UploadTelemetry (Client Streaming)
MQTT topic: iot/{org}/{site}/{device_serial}/command/ota
↓
gRPC method: DeviceService.SendOTA (Unary)
구현: Buf transcoding filter (google.api.http annotation 기반)를 사용하여 MQTT JSON 페이로드를 gRPC Protobuf로 자동 변환. 매핑 규칙은 YAML 설정 파일로 외부화하여 재배포 없이 업데이트 가능.
Module 2: Message Normalizer (메시지 정규화기)
책임: T3 디바이스의 JSON 페이로드와 T1/T2의 Protobuf 메시지 간 양방향 변환. 스키마 버전 불일치 처리.
스키마 진화 처리:
디바이스 펌웨어 v1.0 (구버전 JSON 스키마)
↓
Message Normalizer
- BSR에서 현재 .proto 스키마 로드
- JSON 필드를 proto 필드에 매핑
- 신규 필드: proto default 값 채움
- 구버전 필드: Protobuf Any + schema descriptor로 보존
↓
T1 에이전트 (최신 Protobuf)
Module 3: Buffer / Batcher (버퍼·배치 처리기)
책임: T3 다수 노드의 fan-in 메시지를 집계하여 T1으로의 gRPC Streaming 효율을 최대화.
배치 정책:
max_batch_size: 기본 100개 메시지 (디바이스 클래스별 재정의 가능)max_wait_ms: 기본 50ms (지연 민감도 기준)- 배치 조건:
max_batch_size도달 ORmax_wait_ms경과 중 먼저 발생하는 조건
T3 센서 x 10,000개 (각 1Hz)
→ Buffer: 50ms 수집
→ 배치 = 최대 500개 메시지
→ 단일 gRPC Client Streaming으로 T1 전달
(소켓 수: 10,000개 → 1개)
Module 4: Resume Token Manager (재개 토큰 관리자)
책임: T3↔T2 또는 T2↔T1 단절 발생 시 스트리밍 위치를 저장하고, 재접속 시 이어받기를 지원.
Resume Token 구조:
{
"stream_id": "telemetry-stream-agv-0042-20260607T120000Z",
"last_offset": 8192,
"last_sequence": 1024,
"traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
"device_id": "spiffe://iot/acme/line-a/device/agv-0042",
"issued_at": "2026-06-07T12:00:00Z",
"ttl_seconds": 300
}
Resume Token은 Redis(T2 로컬)에 저장되어 게이트웨이 재시작 후에도 유효하다. TTL 초과 시 클라이언트는 전체 재동기화(full resync)를 수행한다.
Module 5: Device Auth Relay (디바이스 인증 중계기)
책임: T3 디바이스의 X.509 SVID를 T2에서 검증하고, T1에는 T2 자체 SVID로 mTLS 재인증을 수행.
T3 Device (X.509 SVID) → TLS 핸드셰이크
│
T2 Auth Relay
1. T3 SVID 인증서 Chain 검증 (SPIRE CA 루트)
2. SPIFFE ID SAN 추출 및 권한 확인
3. 디바이스 클래스 / 테넌트 매핑
4. gRPC Metadata에 X-Device-SPIFFE-ID 주입
│
T1 방향 gRPC (T2 SVID로 mTLS)
Rationale: T3 디바이스가 T1까지 직접 mTLS 연결을 맺을 경우, 클라우드 SPIRE Server가 수만 개 T3 디바이스의 SVID를 직접 관리해야 한다. T2가 인증 중계를 담당함으로써 T1은 T2 수준의 소수 연결만 관리하고, T3의 신원 폭발적 증가를 T2에서 흡수한다.
Module 6: Metrics Collector (메트릭 수집기)
책임: T2 게이트웨이의 운영 메트릭을 수집하여 T1 OTel Collector로 전송.
수집 메트릭 목록:
# Gateway 운영 메트릭
grpc_requests_total{method, status, device_class}
grpc_request_duration_seconds{method, p50, p95, p99}
protocol_translation_latency_ms{from_protocol, to_protocol}
buffer_queue_depth{device_class}
resume_token_issued_total
resume_token_consumed_total
t3_connection_active{protocol}
t3_connection_drops_total{reason}
# 디바이스 상태 메트릭 (T3 telemetry 집계)
device_battery_level{device_id, class}
device_link_rssi{device_id, interface}
device_message_rate_hz{device_id}
5. 에이전트 상호작용 프로토콜
5.1 A2A Task 생명주기
상태 전이:
submitted → working → completed
→ failed
→ cancelled (T1 요청 또는 타임아웃)
5.2 T1 Orchestrator → T2 Edge Agent Task 위임 시퀀스
T1 Orchestrator T2 Edge Gateway T3 AGV Agent
│ │ │
│ 1. GET /a2a/agents │ │
│ ───────────────────> │ │
│ <─ Agent Card (JSON) ──│ │
│ │ │
│ 2. POST /a2a/tasks │ │
│ {task: "visual_inspection", │
│ input: {zone: "line-a"}, │
│ deadline: "2026-06-07T12:00:30Z"} │
│ ───────────────────> │ │
│ <─ {task_id, status: "submitted"} ── │
│ │ │
│ 3. GET /a2a/events │ │
│ (SSE connection) │ │
│ ───────────────────> │ │
│ │ 4. gRPC Unary │
│ │ SendCommand │
│ │ (start_inspection) │
│ │ ──────────────────────> │
│ │ <── (ack) ─────────────-│
│ │ │
│ 5. SSE event: │ │
│ {status: "working"} │ │
│ <─────────────────── event stream ── │
│ │ │
│ │ │ (검사 수행)
│ │ │
│ │ 6. gRPC Client Stream │
│ │ UploadInspectionData │
│ │ <────────────────────── │
│ │ (프레임 x N chunks) │
│ │ │
│ 7. SSE event: │ │
│ {status:"completed",│ │
│ result: {defects: │ │
│ [{zone: "A2", ...}]│ │
│ <─────────────────── event stream ── │
│ │ │
│ 8. POST /a2a/tasks │ │
│ /{task_id}/ack │ │
│ ───────────────────> │ │
5.3 T2↔T2 엣지 합의 시퀀스 (AGV 충돌 회피)
T2 Gateway A T2 Gateway B
(AGV 라인 A 담당) (AGV 라인 B 담당)
│ │
│ gRPC Bidi Streaming: Negotiate() │
│ ─────────────────────────────────────> │
│ <──────────────── (stream established) ─ │
│ │
│ ConsensusMsg { │
│ type: POSITION_CLAIM, │
│ zone: "intersection-01", │
│ agv_id: "agv-0042", │
│ priority: EMERGENCY │
│ } │
│ ─────────────────────────────────────> │
│ │
│ ConsensusMsg { │
│ type: ACK_DEFER, │
│ zone: "intersection-01", │
│ deferred_agv: "agv-0099",│
│ wait_ms: 200 │
│ } │
│ <───────────────────────────────────── │
│ │
│ [T2-A: AGV-0042에 통과 명령 전송] │
│ [T2-B: AGV-0099에 대기 명령 전송] │
지연 보장: T2↔T2 Bidi Streaming은 엣지 LAN 내에서 동작하며, p99 latency < 10ms 목표를 달성하기 위해 gRPC Keepalive 간격을 5초, deadline을 10ms로 설정한다.
6. 데이터 흐름 설계
6.1 T3 센서 → T1 LLM 에이전트 전체 경로
T3: 진동 센서 (Cortex-M, MQTT)
│
│ [1] MQTT Publish
│ Topic: iot/acme/line-a/vib-sensor-0017/telemetry
│ Payload: {"ts":1749298800, "axis_x": 2.31, "axis_y": 1.05}
│ QoS: 1, Retained: false
│
▼
T2: Edge Gateway (MQTT Broker 수신)
│
│ [2] Protocol Translator 처리
│ MQTT topic → gRPC method 매핑
│ device_serial: vib-sensor-0017 추출
│
│ [3] Message Normalizer 처리
│ JSON → SensorTelemetry Protobuf 변환
│ message SensorTelemetry {
│ string device_id = 1; // spiffe://iot/...
│ int64 timestamp_ms = 2;
│ repeated float values = 3;
│ DeviceContext context = 4; // battery, rssi
│ }
│
│ [4] Device Auth Relay
│ T3 SVID 검증 완료
│ gRPC Metadata 추가:
│ x-device-spiffe-id: spiffe://iot/acme/line-a/device/vib-sensor-0017
│ x-device-class: sensor-vibration
│ x-site-id: line-a
│ traceparent: 00-<trace-id>-<parent-span-id>-01
│
│ [5] Buffer / Batcher
│ 수집: vib-sensor-0001 ~ vib-sensor-5000 (50ms 대기)
│ 배치 크기: 3,200개 메시지 → 1개 gRPC Client Stream
│
│ [6] Interceptor Chain
│ Deadline: 5,000ms 주입
│ Rate Limit: site-a 쿼터 확인 (500k msg/s 이하)
│ Resume Token: 이전 스트림 위치 확인
│
▼
gRPC Client Streaming → T1 (HTTP/3 over QUIC)
│ Service: TelemetryIngestionService.BatchUpload
│ gRPC Metadata: traceparent, x-tenant-id, x-site-id
│
▼
T1: Telemetry Ingestion Service (k8s Pod)
│
│ [7] Stream Receiver
│ Protobuf Deserialize
│ DB Write: TimescaleDB / ClickHouse
│ Publish: Kafka topic "telemetry.line-a.vibration"
│
▼
T1: Anomaly Detection Agent (subscribes Kafka)
│
│ [8] Feature Extraction
│ FFT 분석, 통계 특징 추출
│
│ [9] LLM 에이전트 호출 (MCP Tool)
│ Tool: "analyze_vibration_anomaly"
│ Input: {features: [...], device_id: "vib-sensor-0017"}
│
│ [10] LLM 추론
│ "vib-sensor-0017 베어링 마모 징후 감지 (p=0.92)"
│
│ [11] A2A Task 발행
│ POST /a2a/tasks → T2 Maintenance Agent
│ {task: "schedule_maintenance", device: "vib-sensor-0017"}
│
▼
T2: Maintenance Agent → T3: Maintenance Robot 파견
6.2 긴급 이벤트 역방향 경로 (T3 → T1, < 1s)
긴급 이벤트(낙상 감지, 이상 전압, 충돌 위험)는 배치 경로를 우회하여 직접 전달된다.
T3 Emergency Event
→ MQTT QoS 2 (exactly-once) Publish
→ T2 Buffer/Batcher: EMERGENCY flag 감지 → 즉시 flush (배치 대기 없음)
→ T2 Interceptor: Priority Header 주입 (grpc-priority: critical)
→ gRPC Unary: EmergencyService.Alert (Deadline: 500ms)
→ T1 Alert Service → PagerDuty / SMS / LLM 에이전트 즉시 호출
7. 장애 내성 설계
7.1 Resume Token 상세 설계
Resume Token은 단순 offset이 아닌, 재접속 시 trace 연속성까지 보장하는 복합 구조체다.
message ResumeToken {
string stream_id = 1;
string device_spiffe_id = 2;
int64 last_offset = 3;
int64 last_sequence_number = 4;
string traceparent = 5; // W3C traceparent (trace 연속성)
int64 issued_at_ms = 6;
int32 ttl_seconds = 7;
bytes hmac_signature = 8; // T2 비밀키로 서명 (위조 방지)
}
재접속 시퀀스:
T3 Device (재접속)
│
│ gRPC Metadata: resume-token: <base64-encoded-token>
│ ─────────────────────────────────────────────────>
│
T2 Resume Token Manager
1. HMAC 서명 검증 (위조 방지)
2. TTL 만료 확인
3. SPIFFE ID 일치 확인
4. last_offset 이후부터 스트림 재개
5. 기존 traceparent 유지 (단절 구간도 같은 trace로 연결)
│
│ <── {status: "resumed", from_offset: 8193} ─────
7.2 Deadline 정책
디바이스 클래스별 기본 Deadline은 gRPC Interceptor에서 자동 주입된다. 애플리케이션 코드에서 Deadline을 설정하지 않아도 인터셉터가 강제 적용한다.
| 디바이스 클래스 | RPC 유형 | 기본 Deadline | 근거 |
|---|---|---|---|
| AGV / Robot | Bidi Streaming (합의) | 10ms | 충돌 회피 SLA |
| AGV / Robot | Unary (명령) | 50ms | 제어 루프 주기 |
| IoT 센서 | Client Streaming (배치) | 5,000ms | 배치 처리 허용 |
| IoT 센서 | Unary (상태 조회) | 1,000ms | 단순 조회 |
| 차량 (V2X) | Unary (안전 메시지) | 10ms | ETSI ITS 요구 |
| 웨어러블 | Unary (긴급 알림) | 500ms | 헬스케어 SLA |
| 웨어러블 | Client Streaming (일반) | 10,000ms | 배터리 절약 배치 |
7.3 Retry Policy
# gRPC Service Config (T1 클라이언트에 적용)
methodConfig:
- name: [{service: "TelemetryIngestion"}]
retryPolicy:
maxAttempts: 4
initialBackoff: "0.1s"
maxBackoff: "2s"
backoffMultiplier: 2.0
retryableStatusCodes: [UNAVAILABLE, RESOURCE_EXHAUSTED]
timeout: "10s"
- name: [{service: "EmergencyAlert"}]
retryPolicy:
maxAttempts: 3
initialBackoff: "0.01s"
maxBackoff: "0.1s"
backoffMultiplier: 2.0
retryableStatusCodes: [UNAVAILABLE]
timeout: "0.5s" # 긴급 알림은 짧은 timeout
Hedging Policy (지연 민감 경로용):
안전 메시지나 긴급 알림처럼 첫 번째 응답이 중요한 경우, hedgedDelay 내 응답이 없으면 두 번째 요청을 병렬 전송한다.
hedgingPolicy:
maxAttempts: 2
hedgingDelay: "5ms"
nonFatalStatusCodes: [UNAVAILABLE]
7.4 Circuit Breaker (장애 전파 차단)
T3 디바이스 군집 중 일부가 비정상 상태일 때, 장애가 T2→T1으로 전파되는 것을 차단한다.
Envoy Circuit Breaker 설정:
- max_connections: 1024 (T2↔T1)
- max_pending_requests: 512
- max_requests: 2048
- max_retries: 50
- consecutive_5xx: 5 → OPEN (10s 후 HALF-OPEN)
T2 게이트웨이 자체 Circuit Breaker는 T3 디바이스 클래스별로 독립 인스턴스를 운용하여, 특정 디바이스 클래스의 대량 실패가 다른 클래스에 영향주지 않도록 격리한다.
8. 멀티테넌시 설계
8.1 테넌트 식별 구조
gRPC Metadata 필수 헤더 (모든 RPC):
x-tenant-id: <organization-id>
x-site-id: <site-id>
x-device-class: [sensor|robot|agv|vehicle|wearable|gateway]
x-device-spiffe-id: <spiffe-uri>
SPIFFE ID의 계층 구조가 테넌트 분리와 직결된다. spiffe://iot/<org>/... 패턴에서 <org>가 테넌트 경계를 정의하고, Envoy의 RBAC 정책이 이를 기반으로 크로스-테넌트 접근을 차단한다.
8.2 디바이스 클래스별 쿼터
T3 IoT 센서:
- 메시지 빈도: 분당 120건/디바이스 (2Hz)
- 페이로드 크기: 최대 4KB/메시지
- OTA 업데이트: 시간당 1회
- 초과 시: gRPC RESOURCE_EXHAUSTED (코드 8) 반환
T3 AGV / 산업 로봇:
- 안전 메시지: 초당 100건 (우선 처리, 쿼터 예외)
- 일반 텔레메트리: 분당 600건
- 동시 Bidi 스트림: 최대 4개
- 초과 시: 일반 메시지만 throttle, 안전 메시지 보장
T3 차량 (V2X):
- V2I 안전 메시지: 쿼터 없음 (항상 우선)
- HD맵 업데이트 다운로드: 100MB/시간
- 진단 데이터 업로드: 10MB/시간
T3 웨어러블:
- 연속 모니터링: 분당 60건 (1Hz)
- 긴급 이벤트: 쿼터 없음
- 배터리 절약 배치: 6시간마다 일괄 업로드 허용
T2 엣지 게이트웨이:
- 동시 추론 세션: 최대 8개 (NPU 점유)
- T3 동시 접속 디바이스: 최대 10,000개
- T1 방향 gRPC 연결: 최대 16개 (멀티플렉싱으로 충분)
8.3 RBAC 설계
역할 계층:
system:admin → 전체 테넌트 관리
tenant:admin → 단일 테넌트 전체
site:operator → 특정 사이트 운영
device:reader → 읽기 전용 (모니터링)
device:controller → 명령 전송 가능
agent:orchestrator → A2A Task 위임 가능
agent:executor → A2A Task 실행 가능 (수신 전용)
gRPC Method → Role 매핑 예시:
DeviceService.SendOTA → device:controller 이상
TelemetryService.StreamRead → device:reader 이상
AgentService.DelegateTask → agent:orchestrator 이상
EmergencyService.Alert → device:controller 이상 또는 T3 device 본인
RBAC 정책은 Envoy의 External Authorization (ext_authz) 필터를 통해 OPA(Open Policy Agent)로 위임하여 동적 업데이트를 가능하게 한다.
9. 관측성 설계
9.1 분산 추적 (Distributed Tracing)
traceparent 전파 경로:
T1 LLM Agent
[trace-id: aabbccdd, span-id: 0001]
│
│ gRPC Metadata: traceparent: 00-aabbccdd-0001-01
▼
T2 Edge Gateway (Interceptor: extract → span 생성)
[trace-id: aabbccdd, span-id: 0002, parent: 0001]
│
├── A2A Task 위임 → T2 Agent
│ [trace-id: aabbccdd, span-id: 0003, parent: 0002]
│
└── MQTT Publish → T3 Device
(traceparent을 MQTT User Property로 전달)
[trace-id: aabbccdd, span-id: 0004, parent: 0002]
│
│ T3 응답 수신 시 span 종료
└── Resume Token에 traceparent 임베드
(단절 후 재접속 시 동일 trace로 연속)
T2 게이트웨이는 trace fan-out 지점으로, T3 디바이스가 OTel SDK를 탑재하지 않아도 T2가 T3 span을 대신 생성하여 전체 호출 그래프에 포함시킨다.
9.2 메트릭 체계
수집 계층:
T3 디바이스: 자체 메트릭 없음 (T2가 대행)
↓
T2 게이트웨이: Prometheus Exporter (포트 9090)
↓ (scrape 또는 OTLP push)
T2 OTel Collector: 집계 + 샘플링 + 재전송
↓ (OTLP gRPC)
T1 OTel Collector: 중앙 집계
↓
Prometheus (장기 저장) ← Grafana Dashboard
Jaeger (트레이스 저장) ← Grafana Tempo
SLO 알람 기준:
| 메트릭 | 경고 임계 | 심각 임계 |
|---|---|---|
| T2 Gateway p99 translation latency | > 50ms | > 100ms |
| T3 connection drop rate | > 5% / min | > 20% / min |
| Resume token TTL 만료율 | > 1% | > 5% |
| gRPC UNAVAILABLE error rate | > 1% | > 5% |
| A2A Task failure rate | > 2% | > 10% |
9.3 구조화 로그
모든 로그는 JSON 구조화 형식으로 출력하며, traceparent와 SPIFFE ID를 필수 필드로 포함한다.
{
"timestamp": "2026-06-07T12:00:00.123Z",
"level": "INFO",
"service": "t2-edge-gateway",
"site_id": "factory-line-a",
"trace_id": "aabbccdd1122334455667788",
"span_id": "0002aabb",
"device_spiffe_id": "spiffe://iot/acme/line-a/device/agv-0042",
"event": "protocol_translation_completed",
"from_protocol": "mqtt",
"to_protocol": "grpc",
"latency_ms": 1.2,
"batch_size": 1024
}
10. 사례별 설계 적용
10.1 스마트 팩토리 (Industry 4.0)
핵심 통신 요구: AGV 충돌 회피 p99 < 10ms, 다수 센서 fan-in (10k 노드 × 1Hz), OTA 결함 내성
| 구성 요소 | 설계 선택 | 근거 |
|---|---|---|
| AGV↔T2 | gRPC Bidi Streaming | ms 단위 충돌 회피 합의, 단일 소켓 재활용 |
| 센서→T2 | MQTT QoS 1 + T2 Batcher | 10k 동시 접속, 배치로 gRPC fan-out 최소화 |
| T2↔T1 | gRPC Client Streaming | 배치 업로드, 백프레셔로 T1 과부하 방지 |
| OTA | gRPC Server Streaming + Resume Token | 네트워크 단절 시 청크 이어받기 |
| 디바이스 신원 | TPM + SPIRE | 로봇 물리 변조 대응, 동적 SVID 폐기 |
| 합의 Deadline | 10ms | AGV 충돌 회피 SLA 준수 |
A2A 역할 분담:
- T1 PM Agent: 생산 계획 → T2 Line Agent에 작업 Task 위임 (A2A)
- T2 Line Agent: 라인별 AGV 집단 제어, 품질 이상 감지 시 T1에 알림
- T3 AGV Agent (경량): gRPC-Lite로 T2와 통신, 로컬 충돌 회피 실행
10.2 스마트 빌딩 / 에너지
핵심 통신 요구: 저전력 무선(LoRa/Zigbee) 지원, 피크 수요 절감을 위한 HVAC 협업, 5~15분 주기 배치
| 구성 요소 | 설계 선택 | 근거 |
|---|---|---|
| 스마트 미터→T2 | MQTT QoS 0 + LoRa 브릿지 | 저전력, 1회/5분 허용 |
| HVAC 협업 | gRPC Unary (빠른 명령) + T2 내부 합의 | 피크 절감 응답 < 100ms |
| PV 인버터→T2 | Modbus/MQTT 브릿지 → T2 변환 | 레거시 프로토콜 통합 |
| T2↔T1 | gRPC Server Streaming | 에너지 최적화 모델 실시간 수신 |
| 긴급 차단 | gRPC Unary Deadline 50ms | 과전압 즉시 차단 |
A2A 역할 분담:
- T1 Energy Optimizer Agent: DR(수요 반응) 신호 수신 → T2 Building Agent에 절감 목표 Task 위임
- T2 Building Agent: HVAC/조명/EV 충전기 협업, 피크 절감 최적화
10.3 커넥티드 차량 / V2X
핵심 통신 요구: 핸드오버 무중단(QUIC), V2V 안전 메시지 < 10ms, HD맵 OTA
| 구성 요소 | 설계 선택 | 근거 |
|---|---|---|
| T3 차량↔T2 RSU | C-V2X / ITS-G5 + gRPC at RSU | ETSI ITS 표준 준수 |
| T2 RSU↔T1 | gRPC over QUIC | 5G 핸드오버 시 connection migration |
| V2V (차량간) | QUIC datagram 멀티캐스트 | 브로드캐스트 안전 메시지, HOLB 없음 |
| HD맵 업데이트 | gRPC Server Streaming + Resume Token | 대용량 맵 데이터, 단절 이어받기 |
| 디바이스 신원 | V2X PKI + SPIRE 통합 | ITS 인증서 표준과 SPIFFE ID 브릿지 |
A2A 역할 분담:
- T1 Traffic Management Agent: 교통 흐름 최적화 → T2 RSU Agent에 속도 제한 Task 위임
- T2 RSU Agent: 실시간 V2I 메시지 배포, 사고 감지 시 T1 긴급 알림
10.4 헬스케어 / 원격 모니터링
핵심 통신 요구: 배터리 수명 최대화, 24h 연속 모니터링, 이상 이벤트 < 1s T1 전달
| 구성 요소 | 설계 선택 | 근거 |
|---|---|---|
| 웨어러블→T2 | BLE/Wi-Fi + MQTT QoS 1 | 저전력, Last Will로 연결 단절 감지 |
| 연속 데이터 | Client Streaming + 6시간 배치 | 배터리 절약 duty cycle |
| 긴급 이벤트 | MQTT QoS 2 → 즉시 flush → gRPC Unary | exactly-once + < 1s T1 도달 보장 |
| 환자 데이터 보호 | HIPAA-ready: AES-256 in-transit + at-rest | 의료 데이터 컴플라이언스 |
| 디바이스 신원 | TPM/SE + SPIRE | 환자 안전 디바이스 변조 방지 |
A2A 역할 분담:
- T1 Clinical AI Agent: EHR 데이터 + T2 집계 데이터로 임상 추론
- T2 Hospital Edge Agent: 낙상/부정맥 로컬 감지(< 100ms), T1에 A2A Task로 알림
- T3 Wearable: 센서 수집 + 로컬 오프로드 큐 (BLE 단절 대비)
10.5 사례별 프로토콜 매트릭스 종합
| 설계 항목 | 스마트 팩토리 | 스마트 빌딩 | V2X | 헬스케어 |
|---|---|---|---|---|
| T1↔T2 백본 | gRPC + HTTP/2 | gRPC + 유선/4G | gRPC + QUIC (5G) | gRPC + 유선 |
| T2↔T3 현장 | MQTT 5.0 / gRPC-Lite | MQTT + LoRa 브릿지 | C-V2X / ITS-G5 | BLE + MQTT |
| 저지연 합의 | gRPC Bidi (AGV) | gRPC Unary (HVAC) | QUIC datagram | gRPC Unary (이벤트) |
| 핸드오버 | Resume Token | Resume Token | QUIC conn-migration | Resume Token |
| 디바이스 신원 | TPM + SPIRE | SE + SPIRE | V2X PKI + SPIRE | TPM/SE + SPIRE |
| 저전력 대응 | N/A | MQTT QoS 0 + sleep | N/A | BLE duty cycle |
| 긴급 이벤트 | gRPC Stream 알림 | gRPC Unary 알림 | C-V2X CAM/DENM | gRPC Unary < 1s |
| A2A 위임 방향 | T1→T2→T3 계층 | T1→T2 목표 기반 | T1 교통→T2 RSU | T2 감지→T1 임상 |
부록: Proto 설계 가이드라인
본 프레임워크에서 .proto 파일을 작성할 때 준수해야 할 설계 원칙은 다음과 같다.
- 모든 메시지에
DeviceContext포함: 배터리 수준, RSSI, 펌웨어 버전을 표준 필드로 정의하여 관측성을 기본화한다. oneof활용: 디바이스 클래스별 가변 페이로드는oneof payload { SensorData sensor = 10; RobotStatus robot = 11; ... }구조로 타입 안전하게 설계한다.- 필드 번호 예약: 삭제된 필드 번호를
reserved로 표시하여 OTA 업데이트 중 구버전 디바이스의 역직렬화 오류를 방지한다. - BSR 등록 필수: 모든
.proto는 Buf Schema Registry에 등록하고,buf breakingCI 체크를 PR 조건으로 강제한다. - 서비스별 패키지 분리:
iot.telemetry.v1,iot.command.v1,agent.a2a.v1등 기능 도메인별로 패키지를 분리하여 독립적 버전 관리를 가능케 한다.
본 설계 문서는 FINAL_REPORT.md의 연구 결과를 바탕으로 작성되었으며, 실제 구현 시 각 사이트의 물리적 환경과 규제 요구사항에 맞게 조정되어야 한다.