IoT 사례 연구 - 아키텍처 - 2

IoT 서비스 아키텍처 

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

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

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

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

                                                                                 더보기

중소기업의 효율적인 개발 프로젝트 관리 방안 - 2

Q: “기간” 단위로 관리한다는 것이 무슨 의미인가요? 

보통 진척 관리는 주 단위로 많이 합니다. 그렇다면, 이번 주에 끝난 일은 어느 정도인가를 파악한다는 의미입니다. 끝나지 않은 일들은 진척률 계산에서는 0%가 되게 합니다. 이러한 관리를 주 단위나 월 단위 등과 같이 일정 기간 단위로 하는 것입니다. 

Q: 끝나지 않은 일들은 0%로 관리하면, 지금 하고 있는 일인데도 진척은 하나도 안된 것으로 나타나는 것 아닌가요? 

여기서 중요한 포인트가 있습니다. 하나의 일을 가급적 진척률 관리하는 단위 정도로 쪼개야 한다는 것입니다. 대체로 주 단위로 만드는 것이 좋습니다. 

Q: 개발하는데 주 단위로 쪼개서 일정을 만드는 것은 쉽지 않은 것 같은데, 어떤 방식으로 쪼개면 될까요? 

요새, 애자일이 주목 받고 있는데 애자일의 일하는 방법 자체가 기간 단위로 일을 쪼개는 겁니다. 이 때, 일을 쪼개는 단위는 반드시 하나의 완성품으로 동작을 해야 한다는 것입니다. 단순히, 소스코드 파일 하나를 마쳤다, 기능 하나를 완성했다가 아니라 단독으로 동작이 가능한 하나의 형태가 완성되는 것을 말합니다. 애자일에서는 이 것을 하나의 스프린트(Sprint)이라고 말하지요(그림4). 

<그림4> 애자일의 스크럼 

 

출처: www.digitalsaber.com  

Q: 요새는 개발 프로젝트나 프로세스에 애자일이 안 들어가는 것이 없네요. 조금 더 자세히 말씀 부탁 드립니다. 

애자일의 스크럼이 중요시 되는 이유는 스프린트 단위로 납품을 하는 것입니다. 납품이라는 것은 완성이 되었다는 것이죠. 완성이 된 것은 별도로 동작을 하고 다시 재작업을 하지 않는다는 것을 의미합니다. 품질이나 검사, 지원 업무 등도 모두 마친 것이지요. 그리고, 이러한 일들이 대개 2 ~ 4주 단위나 짧게는 주 단위로 움직이도록 되어 있다는 것입니다. 만약, 일은 하고 있는데 이번 주에 안 끝났다면 이번 주는 0%이지만 다음주에는 100%로 보고될 수 있다는 것이지요. 모든 스프린트는 다수의 반복(Iteration)을 거쳐 최종 완성이 되기 때문에, 거의 주 단위로 계획된다고 보면 됩니다. 그리고, 위에서 얘기한 비례적 활동과 보조적 활동도 스프린트 활동에 거의 일정하게 들어가기 때문에 어렵지 않게 적용할 수 있습니다. 

                                                                                               더보기

메시 앱과 서비스 아키텍처의 동향분석 - 2

마이크로 서비스 개발을 위한 개발 팀 운영 변화 

마이크로 서비스는 독립적인 배포가 가능하기 때문에 아키텍처나 개발, 운영 등을 독립적으로 할 수 있다. 이러한 것은 독립적인 개발 팀 구성도 가능한 것으로 보이게 한다. 다른 세부 아키텍처나 개발과의 연계를 고려할 필요도 없고 시스템 전체가 가지는 제약도 없기 때문에 개발 팀은 독립적으로 구성할 수 있고, 나아가 원격 개발이나 해외 개발 센터를 활용한 팀 구성도 가능하다. 또한, 오픈 소스 팀을 활용해 마이크로 서비스 추가에 대한 부담도 상당히 낮은 편이다. 다만, 개발되는 단위 마이크로 서비스는 철저히 독립적으로 운용되어야 하고 추가, 제거가 다른 서비스에 영향을 미쳐서는 안 된다.  

<그림5> 마이크로 서비스 개발 팀 구성의 특징 

 

출처: http://www.moreagile.net/  

각 서비스 별로 개발 인원을 구성할 수 있기 때문에 서비스의 규모에 따라 최적인 개발 팀 규모를 구성할 수 있고, 서비스 별로 별도의 아키텍처를 구성할 수 있어 자율성도 보장되지만 최적의 아키텍처를 선택할 수 있는 장점도 있다. 또한, 개발 표준도 서비스 별로 구성할 수 있어 자체적인 개발 방식과 표준으로 개발할 수 있는 상향식 개발이 가능하다. 

                                                                                                     더보기