플러터(Flutter)를 활용한 유도탄 시험세트 소프트웨어 설계

플러터는 하나의 코드를 기반으로 여러 플랫폼에서 실행 가능한 애플리케이션을 개발할 수 있도록 설계된 크로스플랫폼 프레임워크이다. 구글이 주도하여 개발한 플러터는 모바일(Android, iOS) 디바이스뿐 아니라 데스크톱(Windows, macOS, Linux), 웹, 임베디드 기기까지 지원한다.^[4] 플러터의 범용성은 독자적인 구조에서 기인한다. 그림 2는 플러터의 아키텍처를 보여준다. 플러터는 플랫폼 고유의 UI 컴포넌트를 사용하는 대신, 구글에서 개발한 오픈소스 2D 그래픽 엔진 Skia를 활용하여 모든 위젯을 직접 그리는 방식을 택하고 있다. 이를 통해 각 플랫폼의 UI 일관성 문제를 해소하며, 개발자는 동일한 코드로 다양한 플랫폼에서 동일한 디자인과 동작을 구현할 수 있다.

그림 2. | Fig. 2. 플러터 아키텍처 계층 | Flutter Architectural layers

Download Original Figure

플러터는 출시 이후 빠르게 성장하며 다양한 산업군에서 실제 서비스에 적용되고 있다. Alibaba는 애플리케이션의 일부 기능을 플러터로 구현하여 배포 주기를 단축하고 유지보수 효율을 높였다. BMW는 전 세계 사용자에게 일관된 차량 애플리케이션 UI/UX를 제공하기 위해 플러터를 선택하였다. 또한 구글 Ads, eBay Motors 등 주요 애플리케이션들도 플러터 기반으로 제작되었으며, 다양한 산업 분야에서 활용 범위가 계속 넓어지고 있다. 실제 서비스에 플러터를 적용한 공통적인 이유는 빠른 개발 속도, UI 일관성, 네이티브 수준의 성능, 커뮤니티와 생태계의 성장성 등을 원인으로 볼 수 있다.^[5] 이는 단순한 기술 트렌드를 넘어, 생산성과 사용자 경험을 동시에 고려한 선택임을 보여준다.

플러터는 BSD 3-Clause 라이선스를 따르는 오픈소스 프로젝트로, 상업적 활용에 제약이 거의 없다. 이는 개발자들이 자유롭게 소스를 수정하고, 원하는 방식으로 재배포할 수 있음을 의미하며, 기업 환경에서도 라이선스 리스크 없이 채택할 수 있는 중요한 근거이다. 구글은 플러터의 주요 기여자이지만, GitHub 기반의 공개 저장소 운영을 통해 전 세계 개발자들의 참여를 적극 장려하고 있다. 실제로 플러터 GitHub 저장소에는 수만 명의 기여자와 이슈 보고자가 활동하고 있으며, 이를 통해 기능 향상과 버그 수정이 빠르게 이루어지고 있다. 아울러 공식 패키지 저장소인 pub.dev(https://pub.dev)는 수많은 오픈소스 라이브러리와 플러그인을 제공하고 있으며, 이는 개발자의 생산성을 크게 향상시키는 핵심 생태계이다. 오픈소스 프레임워크의 특성상 특정 기업에 종속되지 않고 커뮤니티 중심의 기술 발전이 가능하다는 점도 플러터의 경쟁력이다. 활발한 커뮤니티와 생태계 덕분에 최신 기술 트렌드에 빠르게 대응할 수 있으며, 다양한 개발 환경에서 유연하게 적용 가능하다는 점이 큰 장점으로 작용한다.

이러한 장점으로 인해 대학에서는 모바일 및 크로스 플랫폼 수업에 플러터를 적극적으로 도입하고 있다. 플러터는 직관적인 UI 설계 구조와 접근성 높은 Dart 언어를 기반으로 하여 학생들이 비교적 짧은 시간 내에 애플리케이션을 직접 구현해 볼 수 있어 교육 효과가 뛰어나다. 반면 C/C++은 복잡한 문법과 수동 메모리 관리, 플랫폼 의존적인 빌드 환경 등으로 인해 높은 학습 곡선을 요구한다. 이로 인해 실제로 C/C++ 개발자를 주니어 레벨에서 채용하기는 쉽지 않다. 이에 반해, 대학 교육과 산업 수요의 교차점에서 플러터의 입지는 점차 확고해지고 있으며, 기술 초기 단계에서 신속한 제작이 필요한 프로젝트에서는 C/C++보다 플러터가 더 실용적이고 전략적인 선택이 될 수 있다.

표 1은 플러터, React Native을 비교한 결과이다.^[8] 이를 살펴보면 플러터는 자체 렌더링 엔진을 기반으로 플랫폼과 관계없이 동일한 UI를 구성할 수 있어 사용자 경험 측면에서 뛰어난 일관성을 제공한다. 또한 풍부한 커스텀 위젯과 매끄러운 애니메이션 구현 능력은 다른 프레임워크 대비 우수한 점으로 평가된다.^[9] 개발자는 비교적 짧은 시간 내에 고품질의 애플리케이션을 제작할 수 있다. 다만, 플러터는 비교적 신생 프레임워크인 만큼 일부 플랫폼(특히 데스크톱, 웹, 임베디드)에서는 기능적 제약이나 플러그인 미지원 문제가 존재할 수 있다.

실험은 CommTester가 송신한 메시지를 UI_APP에서 간단한 처리 후 다시 CommTester에게 송신하는 형태로 수행한다. 실험 구성은 그림 4와 같다.

그림 4. | Fig. 4. 실험 구성 | Experimental Setup

Download Original Figure

실험 과정에서 각 애플리케이션은 유도탄에서 출력되는 메시지를 모사한 메시지를 송수신 한다. 그림 5는 통신 실험에 사용하는 메시지의 구조를 나타낸다. 메시지는 유도탄에서 출력되는 데이터를 고려하여 1064bytes로 구성하고, 데이터 분석을 위해 세부 필드를 정의 했다. 우선 메시지의 누락 여부를 확인하기 위해 Sequence 필드를 8bytes 할당하고, Data필드에는 1024bytes 데이터를 모사하였다. 또 성능 확인을 위해 TimeStamp필드에 각 프로그램의 송/수신 시각을 할당하여 저장하였다.

그림 5. | Fig. 5. 메시지 구조 | Message Structure

Download Original Figure

실험은 서로 두 대의 노트북을 이용하여 수행되었으며, 실험 환경은 표 2와 같다. 실험은 먼저 UI 프로그램에 인가되는 부하 정도에 따른 성능 차이를 확인하기 위해, UI 갱신 여부에 따라 실험 세트를 구성하였다. 또한 각 세트는 UI 프로그램이 수용 가능한 통신주기를 확인하기 위해, 통신주기를 20Hz/50Hz/100Hz/200Hz/500Hz로 변경하며 실험을 5회씩 10분 동안 진행했다.

CommTester을 기준으로 (수신시각-송신시각)을 계산하여, RTT(Round Trip Time)를 구하고 이를 통해 실험결과를 분석한다. RTT의 평균을 통해 10분간의 통신에서 평균적으로 발생하는 RTT의 값을 확인하였고, 실험마다 최대 RTT 값을 통해 발생할 수 있는 최대 수준의 지연을 확인하였다. 또한 RTT값 간의 표준편차를 통해 변동성을 확인하여, 얼마나 안정적으로 통신환경이 운용되는지 확인하였다. 마지막으로 RTT가 통신주기보다 커져 주기 내에 다시 CommTester로 도달하지 못해 지연이 발생한 경우인 지터(Jitter)의 발생 횟수를 측정하였다.

표 3은 UI_APP에서 UI 갱신을 하지 않고, 통신주기를 변화시키며 실험을 진행한 결과이다. 실험 결과, 통신주기 약 50Hz 수준까지 지연 없이 안정적으로 통신할 수 있다는 것을 확인할 수 있었다. 하지만 100Hz 이상의 통신에서는 지터가 발생하기 시작하며, 500Hz에서는 20,140개의 무시할 수 없는 수준의 지터가 발생하였다.

표 4는 UI_APP에서 UI 갱신을 수행하면서, 통신주기에 따라 실험을 진행한 결과이다. 실험 결과, UI_APP에 UI 갱신에 의한 부하가 걸리더라도 통신주기 약 50Hz 수준까지 지연 없이 안정적으로 통신할 수 있다는 것을 확인할 수 있었다. 하지만 높은 수준의 주기 통신에서는 이전 실험보다 더 많은 수준으로 지터가 발생하는 것을 확인하였다.

결과적으로 표 3과 표 4의 실험 결과를 비교하면, UI 갱신 여부와 관계없이 모두 50Hz 주기 통신을 수행하는 데에는 문제가 없었지만, 그 이상의 주기로 통신을 수행할 때 뚜렷한 차이를 보였다. UI 갱신이 있는 경우, 지터 발생 횟수가 크게 증가하였으며 표준편차도 크게 증가하여 비교적 불안정한 주기 통신을 수행한다는 것을 확인할 수 있다. 그림 6은 50Hz 주기 통신에서 발생하는 데이터를 100개씩 샘플링하여 평균 RTT를 계산하고, 변화 추세를 확인한 결과이다. 이를 통해 UI 갱신 여부에 따라 통신의 안정성이 크게 영향을 받는다는 것을 확인할 수 있다.

그림 6. | Fig. 6. RTT 평균 변화 추세. | RTT average changing trend

Download Original Figure

본 실험을 통해서, 플러터 프레임워크를 사용한 애플리케이션의 UI 부하 여부에 따른 영향성을 확인할 수 있었다,