실시간데이터

기술의 속도를 바꾸는 에지 컴퓨팅_클라우드기반SW연구실 김대원 책임연구원

에지 컴퓨팅은 방대한 데이터를 중앙 클라우드 서버로 보내지 않고, 사용자나 센서 등 데이터가 발생하는 현장과 물리적으로 가까운 곳에서 즉시 처리하는 기술을 의미합니다. 자율주행차나 지능형 로봇처럼 단 1초의 지연도 허용되지 않는 서비스에서 응답 시간을 획기적으로 단축하고 시스템의 안정성을 높이기 위해 필수적으로 도입되고 있습니다. 이러한 방식은 데이터가 발생하는 지점에서 즉각적인 분석과 판단을 가능하게 함으로써, 미래 산업을 지탱하는 핵심적인 인프라 기술로 큰 주목을 받고 있습니다. 최근 국제 표준으로 승인된 ITU-T Y.3541은 에지 컴퓨팅을 실제 서비스로 제공하기 위해 필요한 기능적 요구 사항들을 체계적으로 정리한 결과물입니다. 기존의 Y.3540 표준이 개념적인 틀과 고수준의 요구 사항을 정의하는 데 집중했다면, 새로운 Y.3541 표준은 디바이스 연결부터 서비스 운영, 그리고 이종 인프라 간의 연동에 이르기까지 구체적인 실무 구현 방안을 구체화했습니다. 이는 에지 컴퓨팅 기술이 단순한 이론적 논의를 넘어 산업 현장에서 표준화된 방식으로 널리 확산될 수 있는 탄탄한 기술적 토대를 마련했다는 점에서 의미가 큽니다. 기술의 진정한 가치는 하드웨어라는 물리적 기반 위에 정교한 소프트웨어가 결합될 때 비로소 완성됩니다. 에지 서버가 현장에 위치하여 데이터를 담아내는 그릇이라면, 소프트웨어는 그 안에서 방대한 정보를 분석하고 서비스를 지능적으로 이끌어가는 두뇌 역할을 수행합니다. 이를 의료 시스템에 비유하자면 에지 인프라는 현대적인 장비를 갖춘 응급실 건물과 같으며, 소프트웨어는 의료진의 전문적인 진단과 처방 시스템에 해당합니다. 즉, 에지 기술은 가까운 곳에서 데이터를 처리할 수 있는 환경을 제공하고, 소프트웨어는 그 환경 속에서 실제 가치 있는 지능형 서비스를 구현해냅니다. 자율주행 분야는 에지 컴퓨팅의 효용성이 가장 극명하게 드러나는 대표적인 사례입니다. 주행 중인 차량은 다양한 센서를 통해 정보를 수집하며, 돌발 상황에서 사고를 방지하기 위해 밀리초 단위의 신속한 판단을 내려야 합니다. ITU-T Y.3541 표준은 이러한 자율주행 안전을 위해 저지연 네트워크 연결성과 이동성 지원 기술을 핵심 특성으로 정의하고 있습니다. 모든 데이터를 중앙 서버로 전송하는 대신 도로 인근의 에지 서버가 정보를 즉각 처리함으로써, 차량이 실시간으로 정확한 의사결정을 내릴 수 있는 안전한 주행 환경을 구축할 수 있게 됩니다. 기술이 비약적으로 발전함에 따라 이를 뒷받침하는 국제 표준 또한 멈춰 있지 않고 끊임없이 진화해야 합니다. 한 자리에 정체된 표준은 오히려 새로운 기술 혁신을 가로막는 걸림돌이 될 수 있으며, 시장의 흐름을 반영하지 못하는 표준은 결국 생명력을 잃고 사라지게 될 것입니다. 클라우드와 에지 기술이 우리 삶의 일부로 자리 잡은 만큼, 변화하는 트렌드에 맞춰 표준을 지속적으로 보완하고 발전시키는 노력은 매우 중요합니다. 이러한 표준화 활동은 미래 기술의 방향성을 올바르게 제시하고 더욱 안전하고 효율적인 디지털 생태계를 조성하는 밑거름이 될 것입니다.

한국전자통신연구원

공학·기술

BeeAI 활용 교육 영상(02) - [1단계] 데이터 수집 및 적재하기

BeeAI 개발 프로세스의 첫 번째 단계는 데이터의 수집 및 적재입니다. 이를 위해 준비된 'http_to_mongodb' 워크플로는 스트림 데이터를 받아 배치 형태의 저장소에 적재하는 과정을 실습하기에 적합합니다. 이 워크플로의 핵심 구성 요소인 HTTP 서버 리더는 특정 포트를 열어 외부에서 유입되는 데이터를 실시간으로 받아들일 준비를 합니다. 사용자는 로컬호스트의 53001번 포트를 통해 데이터를 수송하며, 이렇게 수집된 정보는 MongoDB 라이터를 거쳐 지정된 컬렉션에 체계적으로 저장됩니다. 이 과정은 데이터 연산 처리 전, 소스로부터 정보를 안전하게 확보하는 기초적인 단계를 잘 보여줍니다. 적재된 데이터가 실제로 저장소에 잘 들어갔는지 확인하는 과정은 개발의 신뢰성을 높여줍니다. MongoDB에 접속하기 위해서는 터미널에서 Docker 환경 내부로 진입한 후 명령어를 사용해야 합니다. 'use examples' 명령어로 해당 데이터베이스를 선택하고, 'show collections'를 통해 생성된 컬렉션을 확인한 뒤 'find' 명령어를 입력하면 저장된 JSON 형태의 데이터를 직접 조회할 수 있습니다. 쉘 스크립트를 이용해 보낸 데이터가 현재 시간 정보와 함께 MongoDB의 특정 컬렉션에 정확히 쌓여있는 것을 확인하는 것은 스트림 데이터를 배치 형태로 전환하여 관리하는 기술의 핵심을 이해하는 데 큰 도움을 줍니다. 다음 단계는 스트림 데이터를 수집하여 다시 스트림 형태의 저장소인 Kafka에 적재하는 실습입니다. 이 과정에서는 'Stream to Stream' 엔진이 사용되며, 리더는 이전과 동일한 HTTP 서버 리더를 사용하지만 라이터는 Kafka 라이터로 변경됩니다. Kafka를 활용하기 위해서는 부트스트랩 서버, ZooKeeper 커넥트, 그룹 ID, 그리고 토픽 ID와 같은 필수 속성들을 정확히 설정해야 합니다. 토픽은 스트림 데이터가 쌓이는 일종의 큐 역할을 수행하며, 데이터를 처리할 때 해당 토픽에서 정보를 주기적으로 읽어오는 방식으로 동작합니다. 이는 대규모 분산 환경에서 실시간 데이터를 관리하고 저장하는 현대적인 데이터 처리 방식을 보여줍니다. 스트림 처리 외에도 기존에 저장된 대용량 파일을 다른 저장소로 한 번에 옮기는 배치 대 배치 적재 실습도 중요합니다. 'CSV_to_MongoDB' 워크플로는 로컬 저장소에 저장된 CSV 파일을 읽어 MongoDB에 적재하는 과정을 보여줍니다. 여기서는 파일 리더가 사용되며, 파일 경로 속성에 지정된 데이터를 한꺼번에 읽어들입니다. 이 실습에서는 배치 더미 엔진과 컨트롤러를 활용하여 데이터 처리가 완료되면 자동으로 작업 상태가 'Finished'로 변경되는 과정을 관찰할 수 있습니다. 수많은 행을 가진 데이터 세트가 파일 시스템에서 데이터베이스로 순식간에 이동하는 과정은 정형 데이터를 다루는 배치 처리의 효율성을 증명합니다. 이처럼 BeeAI는 다양한 소스로부터 데이터를 수집하고 이를 목적에 맞는 다양한 데스티네이션에 적재할 수 있는 유연한 기능을 제공합니다. 스트림 데이터를 배치 저장소에 저장하거나, 스트림 데이터 그대로 Kafka와 같은 메시지 큐에 전달하고, 대용량 파일을 데이터베이스로 마이그레이션하는 모든 과정이 워크플로 기반으로 직관적으로 수행됩니다. 리더와 라이터, 그리고 이를 제어하는 러너와 컨트롤러의 조합을 통해 사용자는 복잡한 코딩 없이도 데이터 파이프라인의 기초를 구축할 수 있습니다. 이러한 수집 및 적재 기술은 이후 단계에서 진행될 정교한 데이터 분석과 처리를 위한 든든한 밑바탕이 됩니다.

한국전자통신연구원

공학·기술

BeeAI 활용 교육 영상(04) - [2단계] 스트림 데이터 처리하기(이론)

현대 데이터 처리 환경에서 실시간성은 서비스의 가치를 결정짓는 핵심 요소로 자리 잡았습니다. 아파치 스파크(Apache Spark)는 이러한 요구에 부응하기 위해 스파크 스트리밍(Spark Streaming)에 이어 구조적 스트리밍(Structured Streaming)을 선보였습니다. 기존의 방식이 데이터를 마이크로 배치(Micro-batch) 단위로 쪼개어 처리하는 데 집중했다면, 구조적 스트리밍은 센서 데이터와 같은 실시간 정보를 보다 안정적으로 다루기 위해 설계되었습니다. 이는 단순히 속도의 문제를 넘어 운영 단계에서 데이터의 신뢰성을 확보하고 복합적인 연산을 효율적으로 수행하기 위한 기술적 진보라고 할 수 있습니다. 과거의 데이터 처리 방식은 보안 장비나 센서에서 발생한 로그 데이터를 파일이나 데이터베이스에 먼저 저장한 뒤, 이를 다시 불러와 통계를 내는 과정을 거쳤습니다. 하지만 수십 기가바이트에 달하는 방대한 데이터를 데이터베이스(DB)에서 쿼리로 호출하는 방식은 물리적인 시간 소요가 커 실시간 서비스를 구현하는 데 한계가 있었습니다. 이를 극복하기 위해 등장한 스트리밍 처리는 데이터를 디스크에 쓰기 전 메모리 상에서 즉각적으로 연산하는 것을 핵심으로 합니다. 이러한 메모리 기반의 접근 방식은 정제 시간을 획기적으로 단축하여 데이터가 발생하는 즉시 가치를 창출하게 합니다. 구조적 스트리밍의 주요 특징 중 하나는 윈도우(Window)와 워터마크(Watermark)를 통한 데이터 관리입니다. 윈도우 기능은 설정된 시간 동안의 데이터를 메모리에 유지하며 통계 연산을 수행하게 해주며, 워터마크는 네트워크 지연 등으로 늦게 도착하는 센서 데이터를 일정 시간 동안 기다려 주는 역할을 합니다. 이를 통해 데이터 누락이나 순서 뒤섞임 현상을 방지하고 통계의 정확도를 높일 수 있습니다. 또한 체크포인트(Checkpoint) 기능을 활용하면 장비 장애가 발생하더라도 메타데이터를 기반으로 작업을 복구할 수 있어 빅데이터 환경에서의 안정적인 운영을 보장합니다. 구조적 스트리밍은 서비스 시작 전 데이터의 형태인 스키마(Schema)를 엄격하게 정의하는 방식을 취합니다. 스파크 스트리밍이 스키마가 없는 데이터까지 유연하게 받아들여 매번 처리를 시도하는 것과 달리, 구조적 스트리밍은 정의된 포맷에 맞는 데이터만을 선별적으로 수용합니다. 이러한 스키마 중심의 설계는 데이터가 들어올 때마다 발생하는 불필요한 스키마 체크 과정을 생략하게 하여 처리 속도를 비약적으로 향상시킵니다. 결과적으로 로그 파일의 이벤트 발생 시간과 측정값을 구조화된 데이터프레임(DataFrame) 형식으로 즉시 변환하여 후속 분석에 곧바로 활용할 수 있게 됩니다. 스트리밍 처리의 결과물은 비즈니스 목적에 따라 컴플리트(Complete), 어펜드(Append), 업데이트(Update) 세 가지 모드로 출력됩니다. 전체 통계를 매번 갱신해야 하는 작업에는 컴플리트 모드가 적합하며, 데이터 변경이 감지될 때마다 출력하는 업데이트 모드는 실시간 모니터링에 유용합니다. 반면 어펜드 모드는 데이터가 더 이상 변경되지 않는 시점까지 기다렸다가 확정된 결과만을 내보냅니다. 이때 이벤트 시간(Event Time)과 실제 처리 시간의 차이를 정확히 계산하지 않으면 출력 지연이 발생할 수 있으므로, 서비스의 특성에 맞는 적절한 출력 전략과 트리거(Trigger) 설정이 필수적으로 요구됩니다. 체크포인트는 데이터의 정확한 처리를 보장하는 강력한 도구이지만, 실제 테스트 환경에서는 세심한 주의가 필요합니다. 메타데이터가 누적된 상태에서 작업을 재시작하면 번호가 꼬여 데이터 유실이나 중복이 발생할 수 있기 때문입니다. 또한 구조적 스트리밍은 고정된 스키마를 사용하기 때문에 데이터의 행을 열로 바꾸는 피벗(Pivot) 연산이나 복합적인 정규화 과정에서 유연성이 떨어질 수 있습니다. 따라서 전체 데이터를 자유롭게 다루어야 하는 복합 연산의 경우, RDD 방식의 접근이 유리한 기존 스파크 스트리밍이나 다른 분석 도구를 전략적으로 혼합하여 사용하는 지혜가 필요합니다. 결론적으로 스파크 스트리밍과 구조적 스트리밍은 각각의 장단점이 뚜렷한 기술입니다. 구조적 스트리밍은 데이터 수집과 정제 단계에서 높은 안정성과 빠른 속도를 제공하며, 스파크 스트리밍은 로우 레벨의 세밀한 제어와 분석의 유연성을 보장합니다. 실제 에너지 예측 서비스와 같은 프로젝트에서는 앞단에서 데이터를 안정적으로 수용하기 위해 구조적 스트리밍을 사용하고, 뒷단의 정교한 분석 모델링에는 스파크의 다른 기능들을 결합하는 워크플로우를 구성합니다. 기술의 특성을 정확히 이해하고 상황에 맞는 도구를 선택할 때 비로소 진정한 실시간 빅데이터 서비스 구현이 가능해집니다.

한국전자통신연구원

공학·기술