온디바이스 AI 환경에서 보안 통신 프로토콜 및 암호화 구성에 따른 딥러닝 추론 성능 영향 분석

전송 계층의 특성(TCP vs. UDP)이 실시간성에 미치는 영향을 비교하기 위해 표 3과 같이 4종의 프로토콜을 선정했다. HTTPS[6]는 TCP를 기반으로 하며, TLS 1.3을 통해 기밀성과 무결성을 제공하는 가장 대표적인 보안 프로토콜이다. TLS 1.3은 초기 연결 시 최소 1-RTT가 필요한 구조를 가지므로 안정적이지만 상대적으로 초기 지연이 발생할 수 있다. 이에 비해 HTTP/3[7]는 UDP 위에서 동작하는 QUIC 프로토콜을 사용하며, 암호화된 핸드셰이크 절차를 QUIC 내부에 통합함으로써 짧은 연결 설정 시간과 높은 전송 효율을 구현한다. QUIC은 1-RTT뿐 아니라 세션 재활용을 통한 0-RTT 연결도 지원하지만, 구현 복잡성으로 인해 경량 디바이스에서는 오버헤드가 증가할 가능성이 있다. MQTT[8]는 메시지 교환을 위한 경량 프로토콜로 설계되어 패킷 오버헤드가 작지만, 자체적으로 암호화를 포함하지 않기 때문에 TLS 적용이 필요하다. MQTT over TLS는 TCP 연결, TLS 핸드셰이크, MQTT CONNECT 메시지 교환이 순차적으로 이루어져 초기 설정 비용이 다른 프로토콜보다 클 수 있다.

Table 3.

Comparison of secure communication protocols and selection rationale

한편, DTLS[9]는 TLS를 UDP 환경에 맞게 확장한 구조로 낮은 지연과 패킷 손실 내성을 제공하나, 비연결형 특성으로 인해 초기 검증 절차가 추가되어 네트워크 품질에 따라 연결 소요 시간이 변동될 수 있다.

하드웨어 가속 지원 여부에 따른 연산 효율성을 평가하기 위해 TLS 1.3의 주요 암호화 알고리즘 3종을 선정하였다. AES-128-GCM과 AES-256-GCM은 ARMv8 아키텍처의 암호화 확장(CE, Cryptographic Extensions) 명령어 세트와 Jetson Orin Nano의 전용 가속기를 통한 하드웨어 가속이 가능하다. 반면, ChaCha20-Poly1305는 하드웨어 가속기가 부재한 환경에서도 높은 성능을 발휘하도록 설계된 소프트웨어 최적화 기반의 스트림 암호이다.

실제 감시 환경의 다양성을 반영하고 딥러닝 모델의 연산 부하 수준을 조절하기 위해, MOT Challenge 플랫폼의 MOT17-05 시퀀스(그림 2)를 실험 데이터로 활용하였다. 해당 시퀀스는 640×480 해상도와 14 FPS로 기록된 총 837프레임의 도심 보행자 장면으로 구성된다. 보행자 탐지 중심의 시나리오는 추론 과정에서 지속적이고 일정한 연산 부하를 유발하므로, 보안 구성에 따른 성능 변화를 정밀하게 분석하기에 적합하다.

Fig. 2.

MOT17-05 input image dataset

그림 3과 그림 4는 Raspberry Pi 5 환경에서 요청률과 패킷 크기 변화에 따른 프로토콜별 딥러닝 추론 성능(FPS)을 비교한 결과이다. 저부하 조건(Rate=1, 512B)의 그림 3에서는 HTTPS, DTLS, MQTT, HTTP/3가 모두 2.89~2.96 FPS 범위에서 동작했으며, 암호화 알고리즘 및 프로토콜 구성에 따른 유의미한 차이는 관측되지 않았다. 프로토콜 간 성능 편차 역시 최대 0.07 FPS 이내로 제한적이어서, 해당 조건에서는 네트워크 입출력 및 암호화 연산량이 전체 추론 파이프라인에서 차지하는 비중이 매우 작음을 확인했다. 고부하 조건(Rate=100, 2048B)의 그림 4에서도 전체 FPS는 2.79~2.93 수준으로, 저부하 대비 약 0.07 FPS(약 2~3%) 감소하는 수준에 그쳤다.

Fig. 3.

FPS on Raspberry Pi 5(Rate=1, Size=512B)

Fig. 4.

FPS on Raspberry Pi 5(Rate=100, Size=2048B)

DTLS는 2.89~2.93 FPS로 가장 높은 성능을, HTTPS는 2.79~2.83 FPS로 가장 낮은 성능을 보였으나, 프로토콜 간 최대 차이는 0.14 FPS로 기준값 대비 약 5% 수준에 불과했다. 이는 요청률과 패킷 크기를 크게 증가시키더라도 통신 계층의 추가 오버헤드는 딥러닝 추론 단계에서 유의미한 병목으로 작용하지 않으며, 온디바이스 환경에서 FPS는 여전히 모델 연산 비용에 의해 지배됨을 보여준다.

저부하 조건(Rate=1, 512B)의 그림 5에서는 프로토콜 구조에 따른 지연 특성이 뚜렷하게 나타난다. HTTP/3는 세 가지 암호화 조합에서 약 9.54~9.69ms로 네 프로토콜 중 가장 낮은 RTT를 기록하였고, MQTT(AES-128/256-GCM)는 10.18~10.72ms 수준으로 그다음으로 낮은 지연을 보였다. HTTPS는 11.42~12.02ms 범위로 다소 높은 RTT를 보였으며, DTLS는 세 알고리즘 모두 12.88ms 수준으로 가장 큰 지연을 나타냈다. 특히 MQTT+ChaCha20 조합에서는 18.32ms로 다른 조합에 비해 큰 값이 관찰되었는데, 이는 MQTT의 구조적 한계라기보다는 ChaCha20 구현의 최적화 정도나 순간적인 자원 경쟁에 따른 일시적인 이상치로 판단된다. 고부하 조건(Rate=100, 2048B)의 그림 6에서는 MQTT는 AES-256-GCM에서 5.96ms, ChaCha20에서 6.42ms로 낮은 RTT를 유지하였고, AES-128-GCM에서도 8.59ms 수준을 보였다. HTTP/3는 ChaCha20에서 5.38ms, AES-128-GCM에서 6.53ms로 가장 낮은 RTT를 기록했지만, AES-256-GCM에서는 10.33ms로 다소 증가하는 양상을 보였다. HTTPS는 9.24~9.67ms 범위로 저부하 조건 대비 RTT가 소폭 감소하였으나 여전히 MQTT·HTTP/3보다는 높은 지연을 유지했고, DTLS는 12.17~13.08ms로 네 프로토콜 중 가장 큰 RTT를 보여 부하 증가에 가장 민감한 모습을 보였다.

Fig. 5.

RTT on Raspberry Pi 5(Rate=1, Size=512B)

Fig. 6.

RTT on Raspberry Pi 5(Rate=100, Size=2048B)

전체적으로, FPS와 달리 RTT는 보안 프로토콜과 암호화 알고리즘에 더 민감하게 반응했다. 저지연이 요구되는 온디바이스 응용에서는 UDP 기반 QUIC을 사용하는 HTTP/3와 경량 메시징 구조의 MQTT가 상대적으로 낮은 RTT를 보였다. 한편 일부 조합에서는 저부하(Rate=1, 512B)보다 고부하(Rate=100, 2048B)에서 p50(중위값) RTT가 오히려 더 작게 측정되는 현상이 나타났다. 저부하에서는 요청 간격이 길어 CPU 전력 상태 전환, 캐시 미스, 컨텍스트 스위칭 등 초기화 비용이 반복적으로 발생하지만, 고부하에서는 CPU 클럭 상승과 캐시 상주 효과가 유지되어 개별 요청의 처리 비용이 감소하기 때문이다.

암호화 알고리즘별 성능 차이를 살펴보면, AES-128-GCM, AES-256-GCM, ChaCha20 간 FPS 편차는 대부분 조건에서 0.05 FPS 이하로 매우 미미하며, DTLS의 일부 조합에서만 최대 0.08 FPS 수준의 차이가 나타난다. 이는 Raspberry Pi 5 환경에서는 암호화 방식의 선택이 딥러닝 추론 처리량에 거의 영향을 주지 않음을 의미한다. RTT 측면에서는 MQTT 저부하 조건에서 ChaCha20이 다른 알고리즘 대비 수 ms 높은 값을 보였고, HTTPS 고부하 조건에서는 AES-256-GCM이 다소 큰 RTT를 기록하는 등 일부 조합에서 제한적인 차이가 확인되었다. 이러한 차이는 ChaCha20의 소프트웨어 최적화 의존성, 알고리즘별 구조적 특성, 일시적인 CPU 자원 경쟁에 기인한 것으로 보이며, 전체적인 지연 특성을 좌우할 정도의 수준은 아니다. 특히 수 ms 이내의 차이는 Jetson Orin Nano의 극단적 꼬리 지연(Tail latency)과 구분된다. 따라서 전체 지연은 주로 프로토콜 특성에 좌우되며, 암호화 알고리즘은 연산 구조 및 최적화 수준에 따라 미세한 영향을 주는 보조 요인으로 판단된다.

표 4는 Raspberry Pi 5 환경에서 측정한 시스템 자원(CPU, GPU, Memory) 데이터를 분석한 결과이다. 모든 조합에서 CPU 사용률은 약 189∼200% 범위에 분포하며, 이는 YOLO 추론 스레드와 보안 통신 처리가 동시에 수행되는 과정에서 대략 두 개의 코어가 지속적으로 포화되어 있음을 의미한다. 본 실험에서의 CPU 사용률은 단일 코어가 아닌 4개 코어를 가진 Raspberry Pi 5의 전체 시스템 사용률을 합산한 값으로, 이론적 최대치는 400%에 해당한다. 따라서 표에서 관찰되는 190% 내외의 값은 여러 코어에서 연산이 병렬로 수행된 결과로 100%를 초과하여 나타난 것이며, 단일 코어 기준의 과부하를 의미하는 것은 아니다. 메모리 사용률은 전반적으로 4.5~6.6% 수준으로 변화 폭이 작아, 본 실험 조건에서는 메모리가 주요 병목 요인으로 작용하지 않음을 확인할 수 있다. RTT 분석 결과, Rate=1 및 512B 조합에서는 모든 프로토콜의 p95가 약 13~47ms, p99가 수십 ms 수준으로 안정적인 수치를 기록했다. 반면, Rate=100 및 2048B의 고부하 환경에서는 여러 프로토콜의 꼬리 지연이 두드러지게 증가하는 양상을 보였다.

Table 4.

Performance measurement results by protocol and encryption algorithm on Raspberry Pi 5

특히 MQTT에서 AES-GCM을 사용한 2048B·Rate=100 조합은 p95가 225.516ms, p99가 395.676ms로 다른 조합 대비 매우 큰 지연 스파이크가 관측되었다. 이는 고부하 메시지 전송 조건에서 MQTT의 메시지 처리 구조와 YOLO 추론 스레드 간 CPU 스케줄링 경합이 특정 시점에 집중되며 꼬리 지연이 급격히 증가한 결과로 해석된다. 한편, 중위값(p50)에서는 DTLS가 네 프로토콜 중 가장 높은 RTT를 보였으나, p95·p99에서는 오히려 다른 프로토콜보다 낮은 수준을 유지했다. 이는 DTLS의 평균 지연은 다소 높으나, 극단적 지연이 발생하는 꼬리 구간이 짧아 전체 분포의 편차가 작고 상대적으로 안정적임을 의미한다.

그림 7과 그림 8은 각각 저부하(Rate=1, 512B)와 고부하(Rate=100, 2048B) 조건에서 측정된 프로토콜별 딥러닝 추론 성능(FPS)을 나타낸다. 그림 7에서 확인할 수 있듯이, 데이터 전송량이 적은 저부하 조건에서는 모든 프로토콜이 평균 7.9~8.1 FPS 범위 내에서 동작하며 유의미한 성능 차이를 보이지 않았다. 이는 저부하 상황에서 네트워크 입출력 처리에 소모되는 CPU 사이클이 전체 시스템 부하에서 차지하는 비중이 미미하여, GPU가 주도하는 딥러닝 추론 파이프라인에 병목을 유발하지 않기 때문이다. 그러나 통신 부하가 증가한 그림 8의 결과를 살펴보면, 프로토콜 오버헤드에 따른 성능 차이가 명확히 드러났다. UDP 기반의 DTLS는 7.93~8.00 FPS를 기록하며 저부하 조건과 거의 유사한 성능을 유지했다. 이는 비연결형 특성상 연결 상태 유지 및 패킷 순서 보장에 필요한 CPU 오버헤드가 가장 적어, 딥러닝 추론을 위한 데이터 공급이 원활하게 이루어졌기 때문이다. TCP 기반의 MQTT 프로토콜은 7.61~7.69 FPS를 기록하며 DTLS에 준하는 우수한 효율성을 보였다. 이는 일반적으로 TCP가 UDP 대비 무겁다는 통념과 달리, MQTT의 경량 헤더 구조와 단순한 메시지 처리 방식이 고부하 상황에서도 CPU 부하를 효과적으로 낮게 유지했음을 시사한다. HTTP/3와 HTTPS는 각각 7.3 FPS 수준과 6.8 FPS 수준을 기록하며 상대적으로 낮은 성능을 보였다. HTTP/3는 UDP 기반임에도 불구하고 사용자 영역에서 암호화 및 패킷 처리가 수행됨에 따라, 잦은 컨텍스트 스위칭 비용이 발생하여 추론 스레드와의 자원 경합을 유발한 것으로 판단된다. 반면, HTTPS는 고부하 조건에서 6.7~6.8 FPS로 네 프로토콜 중 가장 낮은 성능을 보였다. 이는 TCP 기반 전송에서 필수적으로 수행되는 ACK 처리, 재전송 관리, 세그먼트 조립과 같은 커널 레벨 오버헤드가 TLS 암호화 연산과 결합되어 CPU 부담을 크게 증가시키기 때문이다. 실제로 동일 조건에서 HTTPS의 CPU 사용률은 약 112%까지 상승하여 시스템 내 주요 연산 자원을 점유하였고, 그 결과 추론 스레드가 확보할 수 있는 CPU 여유가 감소하면서 전체 딥러닝 추론 성능이 상대적으로 낮아진 것으로 해석된다.

Fig. 7.

FPS on Jetson Orin Nano(Rate=1, Size=512B)

Fig. 8.

FPS on Jetson Orin Nano(Rate=100, Size=2048B)

그림 9와 그림 10은 각각 저부하 및 고부하 조건에서의 네트워크 왕복 지연 시간 분포를 보여준다. 그림 9의 저부하 조건(Rate=1, Size=512B)에서는 경량 프로토콜의 이점이 두드러졌다. MQTT는 암호화 알고리즘과 무관하게 8.14~9.05ms의 가장 낮은 지연 시간을 기록했으며, HTTP/3가 9.18~12.11ms로 그 뒤를 이었다. 반면, HTTPS와 DTLS는 각각 15ms, 13ms 내외로 상대적으로 높은 지연을 보였다. 이는 MQTT의 단순한 패킷 구조가 단건 메시지 전송 시 오버헤드를 최소화하기 때문이다.

Fig. 9.

RTT on Jetson Orin Nano(Rate=1, Size=512B)

Fig. 10.

RTT on Jetson Orin Nano(Rate=100, Size=2048B)

그림 10의 고부하 조건(Rate=100, Size=2048B)에서는 프로토콜과 암호화 알고리즘 조합에 따라 지연 양상이 크게 달라졌다. MQTT는 7.94~9.33ms 수준의 RTT를 유지하며 고부하 상황에서도 가장 안정적인 성능을 보였다. HTTP/3 또한 AES-GCM 적용 시 약 9.24ms로 낮은 지연을 유지하였지만, ChaCha20을 적용한 경우 p50 RTT가 181.47ms까지 증가하는 급격한 성능 저하가 발생했다. 이는 Jetson Orin Nano에서 AES-GCM이 ARMv8 암호화 확장을 통해 하드웨어적으로 처리되는 반면, ChaCha20은 소프트웨어 기반 연산에 의존하여 고부하 환경에서 CPU 자원 경합이 크게 발생하기 때문이다. 특히 QUIC은 TCP와 달리 사용자 공간에서 암호화와 전송 제어를 수행하므로, CPU 스케줄링 지연이 패킷 처리 지연으로 직접 이어져 RTT 변동성이 크게 확대된다. 이러한 자원 경합과 사용자 공간 처리 오버헤드가 누적되면서, HTTP/3+ChaCha20 조합에서 지연이 비정상적으로 증가한 것으로 해석된다.

암호화 알고리즘에 따른 성능 차이는 Jetson Orin Nano의 하드웨어 가속 기능과 프로토콜 처리 방식의 결합에 따라 달라진다. FPS 측면에서 AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305의 성능 차이는 모든 프로토콜과 조건을 통틀어 최대 약 0.22 FPS 수준에 불과해, 딥러닝 추론 처리량에는 실질적으로 거의 영향을 주지 않았다. 그러나 지연 특성에서는 특정 조합에서 뚜렷한 차이가 나타났다. 특히 HTTP/3의 고부하 조건(2048B·Rate=100)에서는 ChaCha20의 p99 지연이 약 742ms까지 증가했지만, AES 계열은 수십 ms 수준에 머물러 꼬리 지연에서 큰 격차를 보였다. 이는 QUIC 계층의 패킷 처리와 암호화 연산이 모두 CPU에서 수행되는 구조에서, 소프트웨어 기반 알고리즘인 ChaCha20이 네트워크 스택과 YOLO 추론 스레드와의 자원 경합을 심화시킨 결과로 해석될 수 있다. 반면 AES-GCM은 ARM Cortex-A78AE가 제공하는 ARMv8 암호화 확장 명령어를 통해 하드웨어 가속 경로를 활용할 수 있어, 동일 조건에서도 지연 분포가 상대적으로 안정적이었다. 이러한 결과는 하드웨어 가속을 지원하는 온디바이스 환경에서 고부하 상황의 지연 안정성을 고려할 때, AES 계열 알고리즘이 ChaCha20 대비 효율적인 선택임을 시사한다.

Jetson Orin Nano 환경에서 측정한 시스템 자원 데이터를 분석한 결과, 프로토콜 간 자원 점유율의 절대적인 수치 차이는 크지 않았으나 자원 활용의 효율성 측면에서는 유의미한 패턴이 관찰되었다. 표 5의 저부하 조건에서는 모든 프로토콜이 CPU 102~105%, GPU 32~36% 범위를 유지하며 대등한 자원 사용량을 보였다. 이는 통신 부하가 낮을 때는 프로토콜의 오버헤드가 전체 시스템에 미치는 영향이 미미하여, 자원이 딥러닝 추론 작업에 온전히 집중될 수 있음을 시사한다. 그러나 고부하 조건에서는 프로토콜별 처리 방식 차이에 따른 자원 사용 특성이 뚜렷하게 나타났다. HTTPS는 CPU 사용률이 112%로 가장 높았으며, TCP 세그먼트 관리와 TLS 암호화 연산이 중첩되어 CPU 자원 소모가 크게 증가했다. GPU 사용률은 약 30% 수준으로 유지되어 GPU 측 병목은 관찰되지 않았다. DTLS는 CPU 사용률이 105~107% 범위에서 안정적으로 유지되었으며, 고부하 조건에서도 지연 분포가 큰 변동 없이 일정한 수준을 유지했다. 이는 UDP 기반 DTLS가 연결 유지와 세그먼트 조립에 필요한 부하가 상대적으로 적어, 꼬리 지연이 크게 증가하지 않는 특성을 보였음을 의미한다. MQTT는 조합에 따라 CPU 사용률이 66~109% 범위에서 크게 변동하였으며, 일부 조합에서는 CPU 사용률과 GPU 사용률이 동시에 낮아지는 현상이 관찰되었다. 이는 MQTT의 단일 이벤트 루프 구조가 특정 조건에서 GPU로의 연산 공급을 지속적으로 유지하지 못할 때 간헐적 idle 구간이 발생할 수 있음을 시사한다. 또한 ChaCha20 적용 시에는 p95·p99 구간에서 뚜렷한 지연 스파이크가 나타나, MQTT의 지연 특성이 암호화 알고리즘 선택에 민감하게 반응할 수 있음을 확인했다. HTTP/3는 AES-GCM 적용 시 자원 사용률과 지연 특성이 안정적이었으나, ChaCha20 적용 시 p95·p99 지연이 각각 589ms와 742ms로 급증했다. 이는 QUIC의 사용자 공간 기반 처리 경로가 소프트웨어 기반 암호화 부하와 결합되면서 스케줄링 지연이 누적된 결과로 분석된다.

Table 5.

Performance Measurement Results by Protocol and Encryption Algorithm on Jetson Orin Nano