2016년 10월 11일 화요일

IoT 사례 연구 - 아키텍처



최근 ICT(Information & Communication Technology)의 최고 관심 대상 중 하나는 IoT(Internet of Things)이다. IoT를 다양한 형태로 해석하고 사용하지만 가장 큰 특징은 사물 스스로가 정보를 수집하고 스스로 전달한다는 것이다. 불과 몇 년 전만해도 사물에 네트워크가 연결이 되어도 사람이 지시하지 않으면 아무 일도 할 수 없었지만 이제 스스로 일을 하는 사물을 사용한 다양한 형태의 서비스가 거의 모든 산업에서 나타나기 시작했다. 그만큼 사물이 네트워크에 연결된 일은 매우 흥미롭고 고부가가치를 창출하는 일이기 때문이다. 이번 회에서는 IoT의 아키텍처에 대해 살펴보면서 IoT의 구성 방법에 대해 알아보기로 한다. 체계적인 IoT 아키텍처 구성으로 효율적인 IoT 서비스가 제공되기를 기대한다. 


사례 연구 전 확인 사항 


IoT 모델의 변화 

현재의 IoT가 나오기 이전에도 사물을 활용한 정보 수집은 존재했지만, 필요에 의해 사물에 별도의 네트워크가 연결이 되었고 수집하는 정보도 극히 일부로 제한되었다. 이미 필요한 데이터만 미리 정해서 수집했기 때문에 데이터 양도 적고 데이터 활용처도 한정되어 있었다. 하지만, 최근 들어 빅데이터(Big Data) 활용이 늘어나고 빅데이터 속에서 사람들이 생각하지 못하는 인사이트를 찾아내면서 빅데이터를 수시로 수집할 수 있는 IoT에 대해 더 관심을 갖기 시작했다. 
기존에는 각 산업이나 서비스에서 필요한 정보만을 수집하다 보니 소프트웨어의 규모도 그리 크지 않았지만, 최근에는 엄청난 양의 정보가 수집되어 소프트웨어의 규모도 커지고 그에 필요한 아키텍처도 다양해지는 추세다. 이렇게, 정보를 한 곳으로 모았다가 다시 필요한 곳으로 정보를 제공하는 중앙 집중 식 클라우드 형태가 현재 많이 사용되는 모델이고, 이후 분산 클라우드 형태의 IoT가 많이 연구되어 발표되고 있는 추세다(그림1).  


<그림1> IoT 모델의 변화 





 출처: “분산형 데이터베이스 기반 비중앙식 IoT 플랫폼을 이용한 스마트 홈 서비스”  


IoT는 사물을 상호 연결하여 어떤 서비스를 제공할 것인지가 가장 큰 목표이기 때문에 사물과 사람, 그리고 사물과 사람을 이어주는 디바이스를 기본으로 필요한 서비스를 제공하게 된다. 사물 간 통신을 나타내는 M2M, 사물인터넷을 나타내는 IoT, 그리고 IoT에 공간 개념을 도입한 만물인터넷이 IoT 모델의 변화 모델로 정의할 수 있다. 


IoT 아키텍처의 기본 구성 


IoT는 사물 기반이기 때문에 임베디드(Embedded) 아키텍처와 유사하게 보일 수 있다(그림2). 하지만 사물이 인터넷(Internet)에 연결이 되어 있고 다양한 데이터를 수집한다는 것이 주목적이기 때문에 임베디드 아키텍처와 다소 차이가 있다. 인텔(Intel)에서는 <그림2>와 같은 IoT 아키텍처 구성도와 <표1>과 같은 IoT 아키텍처의 특징을 5가지로 정의하고, 이러한 특징을 고려하여 소프트웨어를 설계하도록 가이드하고 있다.  

                                                        더보기

2016년 10월 10일 월요일

SKT에서 제시하는 IoT 서비스




SKT에서는 IoT 서비스를 위해 최적화된 LoRa(Long Range) 네트워크를 IoT 전용망으로 구축하여 제공하고 있다(그림8). LoRa는 대규모 저전력 장거리 무선기술로 소량의 데이터를 먼 거리까지 보내는 특징이 있는데 소량이 데이터를 전송하다 보니 전력이 많이 필요하지 않고 뛰어난 성능을 요구 하지도 않으면서 IoT 서비스를 이용할 수 있다는 장점이 있다. 그림8의 빨간색 부분이 LoRa 네트워크 범위이고, ThingPlug는 LoRa 기반으로 IoT 서비스를 개발할 수 있는 개발 플랫폼으로 이해하면 된다(그림9). 


<그림8> SKT의 IoT 서비스 아키텍처 


출처: SKT - ThingPlug API Document 



KT에서 제시하는 IoT 서비스




현재의 IoT 서비스의 아키텍처는 비 표준형인 경우가 일반적이다. 비 표준형인 경우는 IoT 서비스와 아키텍처의 확장이나 사용자, 디바이스 추가가 쉽지 않다. 최근에는 표준 프로토콜을 적용하고 IoT 서비스나 디바이스에도 표준이 적용되는 노력이 이루어지고 있다. KT에서는 비 표준 식의 Integral과 표준 식의 Modular 식으로 구분하여 IoT 아키텍처 변화를 제시하고 있다(그림5). 


<그림5> KT의 IoT 아키텍처 변화 
 

출처: KT - IoT 서비스 플랫폼 아키텍처 분석  


현재는 하드웨어 특성이 강하고 표준화 영향이 적은 센서, 디바이스 위주로 IoT 발전이 이루어졌지만 향후에는 IoT 서비스 전용 플랫폼 개발, IoT 전용 디바이스 개발과 표준화와 모듈화가 적용된 IoT 서비스가 필요하다고 제시한다. 표준화된 플랫폼 중심으로 IoT가 구성되면 그에 따른 IoT 센서, 디바이스 등의 표준화도 쉽게 이루어질 것으로 보인다. KT는 Integral과 Modular 방식에 따라 IoT 서비스와 소프트웨어 개발 방식도 달라진다고 말하고 있는데 그림6에 나타나 있다. 


<그림6> KT의 IoT 서비스 개발 프로세스 

 

출처: KT - IoT 서비스 플랫폼 아키텍처 분석  



IoT 서비스 아키텍처




IoT 서비스의 주요 기능에는 IoT 보안인증, 리소스 및 서비스 관리, 수집 데이터의 가공 및 처리 등이 있다. 이러한 서비스는 맞춤형 서비스인 응용 서비스(Application & Service) 형, 빅데이터 기반으로 정보를 분석하여 예측 정보를 제공하는 지식정보(Semantics & Knowledge) 형, IoT와 소프트웨어의 인증, 연동 등을 제공하는 보안인증(Security & Privacy) 형 등이 있다. 이런 내용을 기반으로 그림4와 같은 IoT 서비스 아키텍처가 구성될 수 있다. 


<그림4> IoT 서비스 아키텍처 


출처: KT - IoT 서비스 플랫폼 아키텍처 분석  


그림4를 살펴보면, 센서 등을 통해 수집된 정보는 게이트웨이를 통해 보정되거나 걸러지고, 사용자에게 제공되는 서비스 별로 서비스 플랫폼을 가지게 된다. IoT 서비스 플랫폼은 앞 단의 IoT 구성요소를 연결하는 역할과 데이터 기반 서비스를 제공하는 역할을 수행하게 된다. 서비스 플랫폼을 표준형으로 구성한다면 초기 공수는 많이 들어갈 수 있으나 확장이 용이하고, 또한 제공하는 IoT 서비스들을 독립적인 모듈 형태로 제공되도록 구성하면 IoT 서비스 아키텍처에 IoT 서비스를 쉽게 추가할 수 있다. 



2016년 10월 7일 금요일

현장에 다가가는 SW 공학 - 프로세스와 프로젝트 매트릭스

프로세스와 프로젝트 매트릭스

SW프로세스와 프로젝트 지표는 SW프로세스 프레임워크 프로세스를 활용하여 수행하는 프로젝트에 대한 효과와 통찰력을 얻을 수 있도록 지원하는 정량적인 측정방법으로 기본적인 품질과 생산성데이터를 수집하고 이 데이터에 대한 경험치 평균과 비교 분석하여 품질과 생산성이 향상했는지여부를 결정하기 위해 진행된다. 또한, 측정을 통해 SW프로세스를 개선할 수 있도록 현황을 파악하는데 활용된다.

SW의 측정과 분석은 SW관리자에 의해 평가되고 SW개발자를 통해 데이터를 수집하게 된다. SW프로세스와 프로젝트를 측정하지 않는다면 결과는 주관적인 평가만을 통해 도출될 수밖에 없다. 측정을 통해 미래에 대한 준비 즉, 예측을 할 수 없게 되는 것이다.

프로세스 매트릭스를 구성하기 위한 측정은 모든 프로젝트 기간 동안 수집된다. 진행 중인 프로젝트의 상태를 평가하고 잠재적인 위험을 추적하고 중요한 문제 영역을 발견하거나 작업흐름 또는작업을 조정하고 프로젝트 팀을 평가하는 등 프로젝트 매트릭스를 기반으로 SW프로젝트 관리가가능하게 된다. 또한 프로젝트 팀에 의해 수집된 데이터들은 개선결과와 더불어 SW프로세스 개선에 영향을 미치게 된다

[ SW품질 및 조직의 효율성에 대한 결정 ]



자료: Software Engineering A Practitioner's Approach 7th, Roger S. Pressman

전략적 목적을 위해 사용되는 SW프로세스 측정과는 달리 SW프로젝트의 조치는 전술이다. 즉, 프로젝트 지표이며 이로 인해 파생되는 지표는 프로젝트 관리자 및 프로젝트 워크플로우, 기술 활동을 적용하는 SW개발팀에서 활용하게 된다.


현장에 다가가는 SW 공학 - 제품 매트릭스

제품 매트릭스

모든 공학 프로세스의 핵심요소는 측정이다. 보다 낳은 제품을 만들고 개발할 때 산출물의 품질을 평가하는 모델을 이용하기 위해서는 측정을 수행해야만 한다. 다른 공학분야와 달리 SW공학은 측정이 쉽지는 않다. SW공학에서 측정을 하는 사람들은 SW의 설계 및 구축에 대한통찰력을 갖출 수 있도록 SW공학적 작업의 산출물인 제품의 측정 속성에 대해 고려해야 한다.

언제나 어떠한 제품이라도 질적인 평가는 충분하지 않다. 데이터 구조, 인터페이스 및 구성요소의 설계를 살펴보고 도움이 될 수 있는 객관적인 기준이 필요하다. 또한, 테스트시 테스트케이스와 테스트 방법의 선택에 도움이 되기 위해 정량적인 가이드라인이 필요하게 된다. 데이터에서 도출되는 제품의 매트릭스는 요구사항과 설계 모델, 소스코드, 테스트케이스를 통해 연계되며 수집을 위해 목표를 설정하고 매트릭스를 정의해야 한다. 매트릭스의 정의는 SW개발 제품의 품질에 대한 통찰력을 얻기 위해 수행하게 된다.

제품 매트릭스를 위해서는 측정과 매트릭스 그리고 측정인자를 도출해야 한다. 또한 제품 매트릭스의 도출을 위해 여러 가지를 고려하고 추진해야 하지만 SW의 복잡성에 대한 포괄적인 측정이 쉽지만은 않은 상황이다. 측정자의 필요에 따라 해당 도메인과 제품을 평가하기 위한 매트릭스를 고려해야 한다. 제품 매트릭스는 분석 및 설계모델의 평가에 도움이 되고, 디자인과 소스코드에 대한절차의 복잡성에 관한 표식을 제공하며 효과적인 테스트 설계를 용이하게 해줄 수 있다.

요구사항 모델을 위한 매트릭스를 구성하기 위해서는 기능점수(FP)를 도출하여 SW데이터의 흐름을 확인하는 기능점수기반-매트릭스가 필요하다. SW제품에 대한 정량화를 위해 기능점수로 표현한 후 이를 통제하고 점검할 수 있는 기반을 마련하는 것이다. 아울러 품질요구사항에 대한 매트릭스를 추가로 구성하여 이를 고려해야 한다.



현장에 다가가는 SW 공학 - 형상관리

형상관리

오늘날의 SW개발에서 형상관리는 다양한 방식의 접근과 도구의 활용을 통해 이루어진다. 일반적으로 SW형상관리의 범위를 소스코드의 버전관리가 주된 활동들이라고 생각하는 경향이 있다. 소스코드의 버전관리에 대한 메타 태그와 인덱스를 정리하는 활동들이 형상관리라고 생각하고 이행되고있다.

하지만 실제 개발에 사용되는 것들과 표준화적인 요소를 반영하고 있는 CMMI, SPICE, SP인증, ITIL 등 SW공학관점의 형상관리의 기능은 단순한 소스코드 버전관리를 넘어서 변경되는 내용과이슈에 대한 관리, 릴리즈를 포함한 그 이상의 범위를 대상으로 하고 있다. 실질적으로 변경관리가된 것 들을 빌드하고 테스트한 후에 배포까지의 전체 프로세스 수행상황에 대해 정리하고 관리하는것이 바로 형상관리의 목표인 것이다.

형상관리를 공학적으로 어떻게 표현하든 SW개발과 관련된 산출물 및 과정 그리고 기타 활동들은 기록되고 관리되어 지며 검토를 통해 승인되고 저장되어 향후 발생할 수 있는 상황에 대해 대응하고 문제점과 개선점을 도출하여 보다 발전된 형태로 SW개발을 할 수 있는 기반을 마련하는 것이다.

[ ISO/IEC 15504(SPICE)의 Best Practice ]