[218호 웹진: SW공학 동영상] Cyber Security Engineering for Software and Systems Assurance

Cyber Security Engineering for Software and Systems Assurance

참석자

Nancy R. Mead - SEI fellow and principal researcher in the CERT Division of the Software Engineering Institute

Carol Woody - Senior member of the technical staff and the technical manager of the Cybersecurity Engineering Team

요약

소프트웨어 및 시스템 보증을 위한 사이버 보안 공학

시스템을 계속 구축되어야 하고 우리가 원하는 모든 기능을 필요로 합니다. 그것은 싸야 하고 빠르게 바뀌지 않아야 합니다. 사람들을 대체할 수 있어야 하고 일을 빨리 끝낼 수 있어야 합니다. 여분의 노력과 추가 비용이 들기 때문에 보안 장비에 대한 여유가 없습니다.

우리가 쓰는 훌륭한 보안 주체는 인수 관리자입니다. 계약이나 상업용 소프트웨어 구매 등을 통해 제품을 개발할뿐만 아니라 사이버 보안에 대해서 고민합니다. 또 다른 보안 주체는 실제로 시스템에 사이버 보안을 구축할 책임이 있는 개발 관리자와 기술자입니다. 그들은 의사 결정권자입니다.

사이버 보안에 종사하는 사람들도 시스템을 개발하고 습득할 때 사이버 보안이 왜 그렇게 중요한지의 연관성을 이해하지 못합니다. 블로그 포스트에서 사이버 보안 공학을 지원하기 위해 7가지 원칙에 대해 이야기했지만 7가지 원칙은 일종의 체계를 구성하는 것입니다.

리스크 관리를 추진력으로 삼았기 때문에 책에 대한 요점이 매우 중요하다고 생각합니다. 아무도 보안을 위한 구입하지 않기 때문입니다. 리스크 유형의 제어나 구조가 필요하고 기술에 대한 설명이 있어야 합니다. 이 기술로 무엇을 하고 있는지, 데이터는 어디에 있는지, 얼마나 광범위하게 정보를 배포하고 있는지, 어떤 종류의 사람들이 그것으로 작업할 것인지 말입니다. 이 모든 것은 의사 결정의 일부가 됩니다. 웹에 게시 될 수도 있고 모든 인터페이스를 제어하지 않고 액세스 될 수도 있습니다.

몇 가지 중요한 점을 제기합니다. 체크리스트를 위한 컨트롤 목록을 제공한다는 것과 소프트웨어를 어디에서 공급하는지에 대한 공급망 문제입니다. 공급망이 어떻게 생겼는지에 대해 알 수가 없습니다.

소프트웨어를 만드는 방법을 살펴 보는 것은 계획된 주요 프로세스입니다. 그러나 이 과정에서 보안을 계획하는 곳은 없습니다. 라이프 사이클 전반에 걸쳐 통합되어 있지 않으면 따로 계획하기 어렵습니다. 누군가 서비스 거부를 만들었고 특정인이 조작할 수 없기 때문에 문제가 생깁니다. 처음에 이러한 것이 만들어질 때 고려해야 합니다.

보안을 처음에 고려하지 않은 경우 나중에 잘 통합되지 않을 가능성이 있습니다. 왜냐하면 보안에 대한 결정이 미리 없었기 때문입니다. 전체 시스템을 안전하게 할 수 없기 때문에 전체 시스템이 문제가 생길 수 있습니다. 보안을 위한 패치의 지속 비용이 엄청난데 그나마 패치 주기에 지칠 수 있고 패치가 다른 문제를 일으킬 수도 있습니다.

집중적으로 고민해야 하는 방법 중 하나는 직원과 조직이 사이버 보안 역량을 향상시키는 방법입니다. 그렇지 않으면 보안 담당은 할 일이 너무 많은데 직원과 조직이 무엇을 해야할지 몰라 아무 것도 하지 않게 됩니다. 역량을 향상시켜 작은 증분 단계를 시작할 수 있으면 개선이 쉬워집니다. 사람들이 할 수 있는 가장 효과적인 방법입니다. 그런데 직원과 조직의 압박은 많습니다. 할 일이 너무 많다라고 생각할 텐데 성장이 필요합니다.

이 팟 캐스트는 SEI 웹 사이트 sei.cmu.edu/podcasts 및 Carnegie Mellon University의 iTunes U 사이트에서 제공됩니다. 항상 그렇듯이 질문이 있으시면 info@sei.cmu.edu로 전자 메일을 보내주십시오. 고맙습니다.

[218호 웹진: 인사이드이슈] 소프트웨어공학의 오해와 필요성

소프트웨어공학의 오해와 필요성

불과 얼마 전까지만 해도 소프트웨어 개발 프로세스나 개발 방법론 등은 개발자들에게 환영 받지 못할 정도로 소프트웨어를 개발할 때 필요한 요소들이 정리된 소프트웨어공학의 관심은 일부 전공자들에게 한정되어 있었다. 하지만 최근에 소프트웨어공학을 다시 살펴보자는 주장들이 많이 나오고 있어 호윤시스템 김기향 팀장과 소프트웨어공학을 전공한 윤광렬 박사를 만나 이야기를 나눠본다.

Q: 안녕하세요. 2000년 전후로 집중적인 관심을 받다가 그 이후 지속적으로 관심이 줄어들고 있던 소프트웨어공학이 요새 다시 회자되고 있습니다.

이 얘기를 들으시는 분 중에 요새 소프트웨어공학이 다시 얘기되는 것을 모르겠다는 분들도 많을 겁니다. 그런데 최근에 이슈가 많이 되고 있는 애자일(Agile)이나 마이크로 서비스(Micro Service), 클라우드 서비스(Cloud Service) 등 많은 부분이 소프트웨어공학 없이는 구현되기가 어려운 것들입니다. 녹아 들어있는 소프트웨어공학을 인지 못하시는 것뿐입니다.

<그림1> 소프트웨어공학 활용의 예

출처: http://blog.creation.net/306

최근까지도 소프트웨어공학을 소프트웨어를 개발하고 유지보수하는 생명주기 전반을 나타낸다고 이해하시는 분들이 많습니다. 특히 위키백과와 같은 사전적 정의도 이렇게 정의된 경우가 대부분이죠. 위키백과에서는 “소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다; 즉, 공학을 소프트웨어에 적용하는 것이다”라고 정의되어 있습니다. 물론 틀린 말은 아니지만 소프트웨어공학이 적용되는 범위는 훨씬 광범위하다는 것이죠.

“소프트웨어를 만들 때”라는 말을 하나의 시스템을 개발하는 것에만 국한하지 말고 어떠한 제품을 만들 때 소프트웨어를 어떻게 하면 잘 적용할 수 있는가 하는 것도 포함시켜야 합니다.

Q: “제품을 만들 때”라는 말이 이해가 어려운데 조금 자세히 말씀해주시겠습니까?

일반적으로 소프트웨어를 만든다고 하면 시스템을 설계해서 코딩을 하고 운영을 하게 됩니다. 말 그대로 소프트웨어가 단독으로 만들어지는 것이지요. SI가 이러한 형태로 개발이 되고 솔루션 개발에서도 이러한 방식을 취하는 경우가 많습니다. 그런데 소프트웨어가 다른 제품에 들어가는 경우도 많지 않습니까? 최근에는 자동차나 비행기, 공장 등지에서도 사용되고 있는 것이 현실이지요. 반도체는 컴퓨터에만 쓰이는 것으로 잘 알려져 있지만 사람이 사용하는 거의 모든 전자 제품에 들어가는 것처럼 소프트웨어도 비슷합니다.

<그림2> 임베디드 소프트웨어 활용의 예

출처: http://j.mp/ZYZ4KF

그림2에서처럼 임베디드 소프트웨어만 그런 것은 아닙니다. 이제 소프트웨어가 거의 모든 기계나 제품에 대부분 들어간다는 것을 인식해야 하고 이에 대비한 소프트웨어 만드는 방식을 준비해야 하는 것이죠.

Q: 요새 나오는 전자 제품에는 소프트웨어가 꼭 들어가니 소프트웨어를 적용하기 위해 소프트웨어공학이 필요하다는 말로 이해가 되네요. 맞나요?

맞는 말이긴 하지만 전자 제품이 아니더라도 소프트웨어공학은 소프트웨어를 만드는 방법적인 것을 말하는 것이기 때문에 개발 프로세스나 개발 방법론에 너무 한정해서는 안된다는 것을 말씀드리는 것입니다.

SI에서 소프트웨어를 만드는 것과 자동차에 들어가는 소프트웨어를 개발하는 것은 매우 다른 방법으로 소프트웨어가 이해되어야 하지만 소프트웨어를 만들기 위해 고민해야 하는 근본적인 문제는 똑같다는 것이죠. 예를 들면 소프트웨어가 어떤 운영체제에서 구동되는지, 보안상 필요한 부분은 무엇인지, 데이터는 어떻게 주고 받아야 하는지 등을 말합니다.

<그림3> 자동차에 탑재되는 소프트웨어의 예

출처: IT조선

그림3에서 차간거리제어를 보죠. 차간 거리를 제어하기 위해서는 거리를 측정하는 센서도 필요하지만 센서에서 거리를 읽어 판단하고 제어하는 소프트웨어도 필요할 겁니다. 이 때 만들어지는 소프트웨어를 SI 개발하듯이 개발할 수 있을까요? 아닐 겁니다. 이러한 소프트웨어를 만들 때는 또다른 방법이 필요하고 이러한 방법은 소프트웨어공학을 기반으로 정의되어야 한다는 것이 오늘 이야기의 핵심입니다.

Q: 그러한 소프트웨어 개발은 임베디드 소프트웨어에만 한정되어 있는 것 아닌가요? 그리고 임베디드 소프트웨어는 SI 개발과는 비교도 안될 만큼 개발 규모가 작지 않나요?

이 부분이 혼동하기 쉬운 부분입니다. 임베디드 소프트웨어는 이미 구분되어 있는 소프트웨어의 한 분야는 맞습니다. 하지만 어디서부터 어디까지 임베디드 소프트웨어라고 할 것인가라는 정의는 따로 없습니다. 어떤 제품이 원활하게 동작할 수 있도록 도와주는 것 정도로만 알고있는 것이 현실인데 최근에는 제품에 들어가는 소프트웨어가 임베디드 소프트웨어인지 시스템이라고 불릴 수 있는 소프트웨어인지 구분하기가 매우 애매해 졌다는 것입니다.

<그림4> 스마트 공장의 소프트웨어 활용

출처: http://www.iuchem.com

Q: 이전의 인터뷰에서 소프트웨어 산업이라는 말이 없어지고 모든 산업에서 소프트웨어가 부자재로 사용될 것이다라는 말이 기억납니다.

네 맞습니다. 소프트웨어 시스템이라고 불리던 SI 형태 위주였던 대규모 소프트웨어 산업에서 모든 산업에서 필요로 하는 소규모지만 반드시 필요한 맞춤형 소프트웨어로 바뀌고 있는 것이지요.

Q: 4차 산업혁명과 맥을 같이 하는 것으로 봐도 되겠네요. 그렇다면 소프트웨어공학과 연관해서 정리를 해주시죠.

4차 산업혁명은 인공지능 중심으로 산업이 변화되는 경우가 많은 것으로 알려져 있지요. 하지만 그 전에 모든 산업에서 필요한 소프트웨어를 탑재하게 됩니다. 초연결 사회를 지향하는 4차 산업혁명의 경우 소프트웨어를 더 효율적이고 체계적으로 적용하기 위해서는 반드시 소프트웨어공학이 필요합니다. 그림5는 고건 교수가 말하는 초연결 사회에서는 소프트웨어공학이 해답이라고 말한 것을 나타내고 있습니다. 물론 시각의 차이는 있겠지만 시대가 지날수록 소프트웨어를 만들 때 소프트웨어공학의 필요성은 점점 증가한다는 것이지요.

<그림5> 초연결 사회와 소프트웨어공학의 연관성

출처: 고건 - 22nd SW Quality Insight Conference

Q: 각 산업 군에서 소프트웨어가 필요하고 소프트웨어 개발을 위해 소프트웨어공학이 필요하다는 것은 이해가 갑니다. 그런데 소프트웨어공학을 어떻게 적용해야 하는 걸까요?

앞에서 소프트웨어공학은 개발 프로세스나 개발 방법론에 국한해서는 안된다는 말을 했습니다. 말하자면 소프트웨어를 만들 때 표준화된 프로세스와 방법론에 따라 만드는 것에서 벗어나야 한다는 것이죠. 각 산업 군에서 사용되는 소프트웨어는 각자 만들어지는 방식도 매우 다를 겁니다. 아니 다르게 만들어져야 합니다. 왜냐하면 각 산업 환경은 매우 다르기 때문에 거기에 맞는 소프트웨어가 있고 개발 방법도 정해진다는 말입니다.

기존에는 임베디드 소프트웨어라는 범위로 획일화된 개발 방식이 있었습니다. 하지만 지금은 자동차에서 사용되는 소프트웨어에서 고민해야 하는 것과 공장 자동화에서 사용되는 소프트웨어에서 고민해야 하는 것이 다를 수 있다는 것이죠. 여기서 말하는 다르다고 하는 것은 소프트웨어를 만드는 방법뿐만 아니라 운영체제, 보안, 데이터 전달, 더 나아가서는 인공지능으로 확대되는 것까지 다양한 형태가 존재합니다.

Q: 운영체제나 보안 같은 분야는 소프트웨어 개발에서 기본적으로 고민되는 부분 아닌가요? 각 산업에서 다르게 적용될 것이라는 이유는 무엇인가요?

예를 들면 자동차에서 고민해야 하는 보안 문제는 무엇일까요? 자율 주행을 적용했는데 해킹을 당해 도로 위에서 사고를 유발할 수 있다는 것을 고려해야 하고 스마트 공장에서 보안을 생각해야 한다면 IoT 장비에 장애가 일어나서 기계들을 멈추게 할 수 있죠. 이와 같이 보안 문제도 산업마다 다르게 나타나고 그에 대비한 소프트웨어 관점의 고민도 달라진다는 것입니다. 바로 산업 안전성 문제가 대두되는 것이죠.

<그림6> 소프트웨어 안정성 분석

산업에 적용해야 할 제품을 체계적으로 분석하고 특성에 맞게 설계하고 효율적인 개발을 통해 산업 발전에 도움을 줄 수 있는 소프트웨어를 만들기 위해서 소프트웨어공학은 이전보다 더 필요한 시대가 왔다고 봐야 합니다. 소프트웨어공학은 소프트웨어를 만드는 순서를 나타낸 것이 아니라 효율적인 소프트웨어를 체계적으로 개발하기 위한 것이 목적이기 때문입니다. 특히 4차 산업혁명이 나타난 지금 시점에 소프트웨어공학의 필요성은 계속 증가할 것으로 예상됩니다.

Q: 최근에 각 산업에서는 안전성에 대한 이슈가 계속 부각되고 있는데 점점 복잡해지는 산업 구조에 소프트웨어가 차지하는 비중도 커지기 때문일 것도 같습니다. 소프트웨어 안전성에 대한 이슈도 더 커지는 것 같고요. 오늘 이야기를 정리해 주시죠.

소프트웨어는 이제 소프트웨어를 만드는 회사나 개발자만 고민해서는 안됩니다. 거의 모든 산업에서 소프트웨어를 사용하고 있고 소프트웨어로 인해 문제가 발생하고 발전도 이룹니다. 소프트웨어의 역할이 그만큼 커졌다는 말이겠죠. 소프트웨어로 인한 안전 사고도 계속 발생할 것으로 보이기 때문에 소프트웨어에 대한 안전성 이슈도 대두될 것이고요. 소프트웨어공학은 이러한 이슈나 문제를 해결하기 위해 반드시 필요한 것이라고 인식해야 합니다. 소프트웨어가 원하는 대로 잘 개발되게 하고 문제가 발생하지 않게 하기 위해서는 소프트웨어공학을 얼마나 잘 적용했느냐 하는 것이 중요하기 때문입니다. 소프트웨어공학에 대한 각 산업의 이해가 더 필요한 시점인 것 같습니다.

Keyword: software engineering, software safety, fourth industrial revolution, software development

[218호 웹진: 공학 트렌드] 클라우드 SW 사례 연구 - 보안

클라우드 SW 사례 연구 - 보안

클라우드 서비스가 전통적인 소프트웨어 시스템을 대체하면서 가장 크게 이슈화된 것이 보안이다. 전통적인 소프트웨어 시스템은 구현 초기부터 보안에 대한 분석과 설계를 함께 하게 되는데 클라우드는 네트워크 자체가 외부에 오픈되어 있는 경우도 많고 가상화나 공유되는 부분도 많아 보안 문제가 항상 노출되어 있다. 하지만 클라우드 서비스도 소프트웨어 시스템의 일종이기 때문에 기존 보안 기술을 적절히 사용한다면 큰 보안 문제는 나타나지 않을 것으로 보인다. 이번 회에서는 클라우드 서비스의 보안에 대해 살펴보기로 한다.

사례 전 확인 사항

클라우드(Cloud) 보안 개념

클라우드 서비스는 시스템 내부의 자원을 사용하지 않고 외부의 자원을 일부나 전부를 사용하는 경우가 많아 보안에 대한 대비가 반드시 필요하다. 클라우드 보안 문제도 전통적인 소프트웨어 시스템의 보안 문제와 유사한 데이터 유출이나 안정성, 네트워크 문제, 그리고 가용성에 따른 서비스 문제 등이 있다(표1).

<표1> 클라우드 서비스의 보안 위협

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드 서비스에서 보안 문제가 더 크게 대두되는 문제는 그림1에서 보는 것처럼 전통적인 소프트웨어 시스템에서는 각 시스템 단위로 보안 문제를 준비하면 되기 때문에 자체적인 보안 가이드에 따라 보안 준비가 가능했지만 클라우드는 외부 네트워크로 연결되어 서비스가 되기 때문에 보안이 외부에 직접적으로 노출되어 있기 때문이다.

<그림1> 전통적인 소프트웨어 시스템과 클라우드 서비스의 비교

출처: 미래창조과학부

클라우드 서비스의 보안은 두가지 관점이 공존한다. 다양한 기업의 정보나 네트워크가 몰려 있기 때문에 보안 사고가 나타나면 여파가 굉장히 크다는 것과 기업이 자체적인 보안보다 체계적인 관리를 하기 때문에 더 안전하다는 관점도 있다. 특히 인프라(IaaS), 플랫폼(PaaS), 그리고 소프트웨어(SaaS)에 따라 보안이 구성되기 때문에 서비스 특성에 따른 맞춤형 보안도 장점 중 하나다. 또 다양한 시스템을 효율적인 구성으로 서비스하는 클라우드는 자원을 빌려 쓰는 개념이다 보니 비용적 측면이나 운영적 측면에서도 매우 효과적이고 보안 사고가 날 경우에도 클라우드 업체와 이용 업체가 책임을 나눌 수 있다는 점에서도 보안 부담이 줄어드는 것도 사실이다.

클라우드 보안 요소

클라우드 보안은 보안 위협 종류와 서비스 방식에 따라 다양한 보안 대처 방법이 필요하기 때문에 이미 몇 년 전부터 보안 위협에 대비하기 위해 클라우드 발전법이 시행되었고 보안 가이드라인이 제정된 상태다. 해외에는 미국의 페드램프(FedRAMP), 싱가포르의 MTCS, 일본의 ASP.SaaS와 같은 클라우드 보안 인증 제도를 운영하고 있다. 우리나라의 경우 한국인터넷진흥원(KISA; Korea Internet & Security Agency)에서 클라우드 서비스를 위한 보안 가이드를 제시하고 있다(표2).

<표2> KISA의 클라우드를 위한 보안 가이드

출처: 한국인터넷진흥원, 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

표2를 살펴보면 전통적인 소프트웨어 시스템은 시스템과 네트워크, 데이터베이스와 같은 스토리지, 그리고 애플리케이션으로 구성되는데 클라우드 서비스는 전통적인 소프트웨어 시스템을 일부 또는 전체를 대체하는 서비스이기 때문에 전통적인 소프트웨어 시스템의 보안 기준과 크게 차이가 나지 않는 것이 특징이다(표3).

<표3> 클라우드 서비스의 보안 기술

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드가 보안에 취약한 가장 큰 이유는 방화벽이나 네트워크 연결 등으로 제한할 수 있는 전통적인 소프트웨어 시스템에 비해 원격 접속을 허용해야 하는 속성과 클라우드 사용에 필요한 소프트웨어를 설치해야 하기 때문이다. 그리고 클라우드 서비스 업체는 보안 문제가 발생해도 외부에 공개하지 않고 처리하는 경우도 많기 때문에 보안 이슈에 대한 정보 공유도 아쉬운 것이 사실이다.

이러한 문제를 해결하기 위해서는 기존 소프트웨어 시스템의 보안 가이드나 보안 기술들을 적용해 보안 위협을 확인해야 하고 클라우드 서비스에서 독특하게 사용되는 가상화 기반 환경에 대해 집중적인 보안 위협 확인이 필요하다(그림2).

<그림2> 클라우드 가상화 기반의 보안 취약점

출처: Tech M

사례 연구

AWS(Amazon Web Services)

출처: https://www.slideshare.net/awskorea/intro-of-aws-cloud-usecase-and-strategy-61567540

AWS는 한 대의 독립된 컴퓨터를 제공하는 EC2, 파일 서버를 제공하는 S3, 데이터베이스를 제공하는 RDS 등의 서비스를 제공한다. 이러한 서비스를 조합해서 웹서비스(Web Service)를 만들게 된다(그림3). 빌딩 블록을 조립하듯이 비즈니스 요구사항에 따라 40여 개 이상의 서비스를 조립하여 유연하게 활용이 가능하다.

<그림3> AWS에서 제공하는 서비스

출처: Amazon

AWS는 세가지 방법으로 사용이 가능한데 웹서비스를 이용하는 AMC(AWS Management Console), 명령어 입력 방식인 CLI(Command Line Interface), 프로그래밍 언어 단위로 개발 API를 제공하는 SDK(Software Development Kit)가 있다. 명령어에 익숙하지 않다면 AMC를 우선적으로 사용하면 된다.

탄력적인 웹 트래픽 관리를 위한 AWS 사용은 그림4와 같이 구성할 수 있는데 로드밸런싱이나 오토스케일링을 통해 서버 부하 문제를 줄일 수 있고 확장성이 용이하다. 이러한 구성을 통해 웹사이트 리뉴얼이 용이하고 트래픽에 따라 최적의 성능이 발휘될 수 있어 AWS 구성에 따른 비용 절감 효과가 뛰어나다고 소개하고 있다.

<그림4> 웹 프래픽 관리를 위한 AWS 구성 예

출처: Amazon

그림5는 최근에 많이 적용되고 있는 빅데이터 관련 구성이다. 빅데이터 분석을 위해 수집과 저장, 분석 모듈에 필요한 AWS 컴포넌트를 사용하고 있다. 빅데이터 분석을 위해 자체적인 모듈이 사용된 경우 그림5에서 해당 모듈을 추가 적용해서 사용하면 된다.

<그림5> 빅데이터 분석을 위한 AWS 구성 예

출처: Amazon

그림6은 그림5의 빅데이터 분석을 위한 AWS 구성을 게임 빅데이터 분석에 적용한 예다. 게임 로그 데이터를 EC2와 S3를 거쳐 하둡(Hadoop)으로 구성된 EMR에서 분석하고 수분 내에 데이터 분석이 완료되도록 구성되어 있다.

<그림6> AWS의 빅데이터 분석을 게임 빅데이터 분석에 적용한 예

출처: Amazon

아마존에서는 기존 소프트웨어 시스템에서 클라우드로 전환하여 서비스하는 형태가 아닌 클라우드에서 신규 서비스를 직접 개발하는 전략을 수립하도록 권장하고 있는데 빠르고 저렴한 비용으로 개발과 배포가 가능하도록 서비스를 구성하고 있다. 이러한 서비스 제공은 다른 클라우드 서비스 업체에서도 제공하는 형태지만 특정 서비스 형태 뿐만 아니라 전체적인 클라우드 서비스를 한 곳에서 모두 제공한다는 점에서 장점이 있다.

또 아마존에서는 기존 소프트웨어 시스템에서 전환하거나 신규 서비스를 제공하더라도 유용한 기능만 우선 적용하도록 권장하고 있는데 자체적으로 구성해도 큰 무리가 없는 시스템까지 모두 클라우드로 전환할 필요는 없다는 이유 때문이다. 클라우드 서비스는 서비스 단위의 모듈 형태로 제공되기 때문에 전체 서비스를 도입할 필요는 없어 기존 인프라나 자체적으로 구성이 가능한 서비스는 그대로 두고 클라우드와 역할을 분리하여 구성하는 것이 좋다(그림7).

<그림7> 하이브리드 클라우드 서비스의 예

출처: Amazon

기대 효과와 결론

클라우드 보안의 경우 기존 서비스와 크게 차이를 보이지 않기 때문에 가급적 기존 보안 가이드나 보안 기술을 이용해 보안 구성을 하는 것이 일차적인 목표다. 이렇게 구성된 보안 기준에 클라우드를 적용해서 나타나는 보안 요소에 대해서는 적용하는 클라우드 서비스 업체가 자세히 상의하는 것이 가장 현명한 방법이다. 클라우드는 기존에 만들어진 형태에 새롭게 만드는 것이 아니고 내가 가진 서비스와 조립을 하는 형태이기 때문이다. 조립에서 나타날 수 있는 보안 요소에 대해 철저히 확인한다면 클라우드 적용으로 인해 발생할 수 있는 보안 문제를 줄일 수 있을 것이다.

Keyword: software engineering, cloud service, paas, saas, iaas, amazon web service, cloud software architecture, cloud security

FRACAS

FRACAS는 고장 데이터를 수집하고, 고장 원인을 결정하기 위한 절차와 수행된 개선 조치에 대한 문서를 제공하는데 목적을 갖는다.

또한, 고장 보고 및 분석은 제품의 신뢰성 및 유지보수성이 요구사항에 부합되고 유지된다는 것을 보장하기 위하여 필요로 한다. FRACAS의 적용은 신규 시스템 개발 및 생산에 대하여 고장 반복 및 재발을 제어하기 위한 핵심 요소이다. FRACAS 절차는 고장이 정확하게 보고되고 철저히 분석되었다는 것과 개선 조치가 고장 재발을 감소하고 예방하기 위하여 적정한 시기에 수행되었음을 보장하기 위한 규정 또는 조항을 포함해야 한다.

• 무엇이 고장을 발행하였는가? 
• 언제 고장이 발생하였는가? 
• 어떻게 고장이 발생하였는가? 
• 왜 고장이 발생하였는가? 
• 이후에 발생할 고장을 어떻게 방지 또는 제거 할 것인가?

FRACAS 흐름

FRACAS 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다. 또한, 수행 결과에 대한 산출물 리스트는 적절한지에 대한 평가를 최종적으로 점검하기 위해서 본 가이드에서는 제시하는 위험원 분석 기법에 대한 검증 표를 제공 한다. 따라서 FRACAS  기법의 수행에 대한 검증은 [표 1]을 통해서 수행된다.

표 1. FRACAS 주요 항목 및 산출물 체크 리스트

FTA(Fault Tree Analysis) 수행절차

일반적인 FTA 수행절차는 아래와 같다.

1. 시스템의 이해
• 원하지 않은 사건이 어떻게 일어나는지 그 원인 인지 식별 한다.
• 관찰 대상(시스템 또는 컴포넌트) 정의 수행 된다.
• 분석 목표 정의 수행 한다.
• 가정(Assumption) 기술 수행 한다.
• FTA 정보는 구성도/ 기능 구조도/ FMEA / HAZOP을 분석 및 수행하는데 중요 한 정보를 제공한다.
2. Top / Main event(정상사상) 정의: 분석 목표로부터 “Top Event” 도출 수행 한다.
3. 분석경계 및 깊이 정의
• 대상 시스템의 분석경계 정의 한다. 
• 내/외부 인터페이스 및 타 시스템 포함여부 결정 한다.
• 시스템 레벨/컴포넌트 등의 분석 대상 깊이 정의 한다.
4. Fault Tree 작성

그림1. Fault Tree 구성요소


• 일반적으로 Fault Tree는 Event와 그것을 연결하는 게이트로 구성된다.
• Top Event 정의하고 그 아래 단에 그 “Top Event”을 직접적으로 발생시키는 원인이 되는 Event들을 나열 후 Gate로 “Top Event”와 연결
• 아래 단의 사상과 바로 그 위의 단의 사상을 연결하는 게이트는 기본적으로 AND 게이트 그리고 OR 게이트
• AND 게이트란 아래 단에서의 사상B1과 B2의 양쪽이 일어나면, 즉, [B1이고 더 구나 B2]이며 위단의 출력 A가 생긴다는 것으로 논리곱의 관계를 표시 할 수 있다. 
• OR게이트는 아래 단에서 사상B1과 B2의 어느 쪽 한쪽에서 일어나면 즉, [B1 또 는 B2]면 위단의 출력 A가 생긴다는 것으로서 논리합의 관계를 표시하게 된다.
5. Fault Tree 정성적 분석
• Fault Tree가 작성되면 Tree의 구조가 정성적으로 고장 메커니즘을 잘 반영하 고 있는지를 분석한다. 
• Tree의 구조는 모든 가능한 고장유형(즉, 정상사상을 일어날 수 있게 하는 사건 들의 모든 조합들)들을 표현한다. 
• 이 과정은 보통 Minimal Cutset 분석을 통하여 이루어진다. 
• 특히, 보호 장치의 유효성, 여러 가지 sub-event들의 정성적인 중요도, 공통 원 인고장의 기여 정도 등을 관찰한다. 
6. Fault Tree 정량적 분석
• Fault Tree 작성되고 각 기초사상 들의 발생빈도를 조사하고, 이로부터 정상사 상의 발생빈도나 확률을 계산한다. 
• 보통, Boolean식으로 표현되는 minimal sut set들을 Poincare식을 사용하여 계산 한다. 
• 정상사상의 발생빈도가 계산되어지면 Sensitivity, Uncertainty와 Importance 분석 을 시행한다. 
7. 개선사항 도출 
• 시험을 통한 개선 
• 런타임 진단 
• 설계 변경 
• 컴포넌트 변경

FTA(Fault Tree Analysis)

FTA는 열거된 원치 않은 사고의 발생확률과 기본 원인을 결정하기 위한 시스템 분석 기술이다. FTA는 잠재적 문제를 이해하고 방지하기 위하여 대규모 복합 기 능의 시스템을 평가하는데 사용된다.

정확하고 조직화된 방법을 사용하여, FTA는 시스템 분석가가 원치 않은 사고의 발생 원인이 되는 고장 사건의 특수한 조합을 만들도록 한다. FTA의 최종 목표는 최상위 위험원의 발생확률을 구성 요소별 고장률을 사용하여 안전 대책을 수립하는데 있다. FTA는 반복적인 분석 과정을 사용하여 여러 가지들로 전개된다. 시스템의 중요한 양상을 표현하는 각각의 주요 층으로 각층에서의 결함트리 전개를 설명한다.

예를 들어, 최상위 결함 트리구조는 대개 시스템 기능과 단계를 모델링하고, 중간 결함트리 구조는 서브시 스템 고장 흐름을 모델링하며, 하부의 결함트리(Fault Tree) 구조는 부품과 컴포넌트 고장 흐름을 모델링 한다. FTA는 서브시스템 레벨에서 기능이나 기능 간 상호작용에 잠재적 고장을 일으킬 수 있는 요인들로부터 위험원을 구분하는데 사용된다. 원인분석은 해당 시스템의 단일 고장과 이들이 전체 시스템에 미치는 영향을 파악하고, 위험원 조건을 제거하거나 이를 허용 가능한 수준까지 필요한 제어 방법을 결정하는데 사용된다.

Fault Tree는 시스템 레벨의 위험원을 하위 레벨 위험원으로 구분하는데 사용된다. FTA는 연역 기법의 하향식 접근법으로 최상위 이벤트에서 상위 이벤트의 원인이 될 수 있는 기본 이벤트에 이르기까지 점진적으로 분석한다. 기본 이벤트(Basic Event)는 서브시스템 기능의 고장 또는 외부 장비와의 서브시스템 인터페이스 장애이다. Fault Tree에서는 단일 혹은 다 수의 기본 이벤트 발생으로 인해 발생될 수 있는 위험원으로 이어지는 경로들을 제시한다.

Fault Tree Diagram은 “AND”, “OR” 등의 로직 게이트 기호를 사 용하여 하위레벨 위험원과 시스템 위험원 사이의 관계를 정의한다.

FMEA 수명주기(Vee-Model)

보다 효율적인 FMEA 기법 수행을 위해서는 아키텍처 기반의 물리적 구성품 분석을 통해, 시스템 분석 및 식별된 물리적 구성품을 바탕으로, FMEA를 통한 안전성 분석을 수행해야 한다.

[그림 1]에서 알 수 있듯이, 보다 효과적인 FMEA 수행을 위해서는 설계 산출물을 활용한 안전성 분석을 수행해야 한다. 시스템/ 하드웨어/소프트웨어에 이르기까지, 각각의 계층 레벨에서 설계 산출물이 활용될 수 있다. 개별 시스템 Layer에서, 특히, 구조적 정보, 기능정보, 기능 기반의 고장(Failure)에 대한 정보 데이터를 활용해야 한다.

위험원 분석 가이드에서는 도구 기반의 FMEA 수행을 통해, 설계 산출물에 대한 확보를 통해 개별 산출물 데이터간 추적성(Traceability)를 확립할 수 있다.

그림 1. 설계적 데이터를 활용한 FMEA 수행 

FMEA(FMECA)

FMEA는 서브시스템, 부품, 컴포넌트 혹은 기능들의 잠재적 고장 상태의 영향을 측정하기 위한 분석기법이다.

이것은 종합적인 시스템 신뢰도에 부정적인 영향을 주는 고장상태를 확인하기 위한 분석기법이기도 하다. 또한, FMEA는 정량적인 분석을 위해 각각의 고장상태에 대한 고장률을 포함하는 특성을 가지고 있다. 게다가 FMEA는 시스템 위험원과 같이 원치 않은 시스템 상태에 의한 고장상태를 측정하기 위해 확장될 수 있으므로 위험원 분석에도 사용될 수 있다.

FMEA는 부품 그 자체에 고장 발생 원인이 개입되는 것을 피하기 위한 기법이다. FMEA의 확장된 기법은 FMECA(Failure Mode Effect and Criticality Analysis)이다. FMEA은 위험과 잠재적 고장상태의 발견을 다룰 때의 자세한 분석과 정보가 포함된 더 많은 정보를 요구한다. FMEA 방식은 제품고장이나 프로세스 고장의 위험률을 줄이기 위한 활동의 우선순위를 정하기 위해 제품과 프로세스의 설계나 기능에 초점을 맞춘 체계적인 상향식 접근의 기법이며 분석된 결과를 기록하고 권고된 설계변경을 반영하는 기법이다. 이 기법은 시스템이 고장난 경우에 고장이 미치는 영향을 파악하는 것을 목적으로 한다. FMEA 수행을 위한 단계는 다음과 같다.

1. 구성요소의 식별: 구성요소의 식별은 아키텍처 산출물을 활용해 수행 대체 가능하다. 
2. 구성요소별 기능의 확인: 개별 구성품이 지닌 기능을 확인하여 기능 분석된 결과를 나열한다. 
3. 고장모드의 선택: 개별 구성품이 지닌 기능 작동(운용)시 발생할 수 있는 다양한 모드에서 오작동 발생 될 수 있는 모드를 식별하여 나타낸다. 
4. 지역적인 오류 확인(결함이 시스템의 다른 부분에 즉시 영향을 주는 것): 해당 결함모드에 따른 기능적 오류 발생 시 발생하는 연계 오류 된 사항을 기 술하게 된다. 
5. 시스템적 오류 확인(시스템 전체에 대한 영향): 기능적 오류가 미치는 시스템적 차원의 오류를 식별하여 기술한다. 이때, 아키 텍처 산출물을 기반으로 분석 가능하다.
6. 결함이 영향을 차단하기 위한 방법 확인: 결함이 미치는 영향을 제거 또는 완화하기 위한 방안을 설계적으로 반영될 수 있는 방안을 기술하게 된다. 
7. 권고안 작성: 최종적으로 설계적 반영하기 위한 권고안에 기술하게 된다. 

고장모드 영향 분석(FMEA) 수행절차

HAZOP 진행 순서

HAZOP은 다음과 같은 순서로 진행된다.

① 설계자의 의도로부터 발생 가능한 차이점을 가정해야 한다.
② 그 차이점으로부터 발생 가능한 원인 및 결과를 조사해야 한다. 다음은 철도 신호 시스템 ATP의‘임시속도 제한 설정’ 오류에 대한 사례 예시이다. 국내 철도도메인에서 적용되는 ‘HAZOP-KR’에서 제공하는 매개변수 및 가이드워 드에 따른 HAZOP 수행을 수행한 사례에 대한 예시이다.  

③ 시스템을 위해 계획된 또는 실제 현장에서의 제어 및 관리 방법 설명 한다.
④ 위험요인의 존재 여부를 결정해야 한다.
⑤ 토의 결과를 기록해야 한다.

HAZOP은 시스템의 위험원을 도출하기 위해 핵심 가이드 워드와 파라미터를 이용한다. 이러한 가이드 워드와 파라미터를 이용하여 설계 의도로부터 벗어나 사고로 이어질 수 있는 상태인 일탈이 정의된다. HAZOP이 수행되는 동안 가이드 워드와 파라미터는 시스템의 특성에 따라 전문가의 충분한 협의를 거쳐 수정이 가능하다. 가이드 워드는 HAZOP에 있어서 상당히 중요한 부분을 차지하며, 설계 자의 의도로부터 특정 차이점을 나타내는 단어 및 설명을 의미한다.

2017년도 SW공학기술 현장적용 지원사업 결과

자세히 보기 >>>

HAZOP(HAZard and OPerability)

HAZOP(HAZard and OPerability)은 위험원의 식별을 위한 형식화된 시스템적 기법이다. HAZOP 분석은 시스템 운영과 관련된 위험원을 식별하고, 분석하기 위한 기술로서 복잡하기 쉬운 분석과정을 보다 단순화 하여 체계적으로 분석하는 방법이다. HAZOP은 계획된 운용 의도부터 핵심 안내어의 특수한 사용에 이르기 까지 일어날 수 있는 시스템의 이상현상(Deviation)을 확인하는 것이며 다음과 같은 목적을 가진다.

l  의도된 설계기능이나 조건 등을 포함하여, 시스템의 상세한 설명을 제공한다.

l  시스템의 모든 부분을 체계적으로 검토함으로써, 설계의도로부터 이상현상(사고, 고장, 결함)이 어떻게 발생하는가를 파악한다.

l  이러한 이상현상들이 위험이나 사용상의 문제를 초래할 수 있는지 결정한다.

위험원 식별에서 가장 중요한 기술은 위험원의 원인과 분석하는 것으로, 이러한 단계에서 HAZOP을 이용하면 안전성 활동을 위한 분석절차 초기에 유용하게 위험원을 식별할 수 있다. 또한 시스템의 안전성 분석은 운영기간 동안에 계속적으로 검토되어야 하며, 특히 시스템에 변경사항이 발생했을 경우에 추가적으로 HAZOP을 다시 수행하는 것이 매우 중요하다.

그림 53. HAZOP 예시 – Hazard가 ‘임시속도제한 설정 오류‘인 경우

HAZOP 기법의 수행에 대한 절차가 완료되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다.

운영 및 지원상의 위험원 분석(O&SHA)

해당 기법은 운용 또는 유지보수 활동 결과에 따라(운영자, 유지보수, 승객 등) 발생할 수 있는 위험원들을 파악하는데 목적이 있다. 뿐만 아니라, 파악된 위험 원을 최소화 또는 제거하기 위해 본 위험원 분석에서 도출된 위험원 저감 대책 이 운용 및 유지보수 매뉴얼 및 안전성 계획서에 반영해야 한다. 시스템이 운용 되기 시작하면 예상치도 못한 여러 가지 상황에서 전혀 예상치 못한 방법으로 시스템을 사용하는 일이 발생하기 때문에 바람직하지 않은 사상이 발생 할 수 있다. O&SHA는 이런 목적을 위해 인간공학, 훈련과 교육, 인간기계 인터페이스 (MMI)를 강조하면서 시스템의 운용과 보전(Maintenance)에 관련된 위험성을 분석 하기 위한 것이다. 

시스템 특성과 관련된 정보들이 추가됨에 따라 반복적으로 O&SHA 결과가 지속적으로 수정해야 하는 것은 물론이다. 이를 통하여 설계완료 이전에 제안된 변경사항, 추가사항 그리고 개발 시스템에 대한 기능적 관점에서 운용모드가 개발되고 평가해야 한다. 따라서 O&SHA는 위험원 발생 가능성을 정량적으로 예측하고 운용/유지보수 절차 및 운용상 위험요소를 유발할 수 있는 조건이나 에러 등을 파악할 수 있어야 한다.

O&SHA 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다. 또한, 수행 결과에 대한 산출물 리스트는 적절한지에 대한 평가를 최종적으로 점검한다.

표 42. O&SHA 주요 항목 및 산출물 체크 리스트

결함 위험원 분석(Fault Hazard Analysis : FHA)

결함 위험원 분석(Fault Hazard Analysis; FHA) 기법의 목적은 대상 시스템이 수 행할 FHA 활동들을 설명하는데 있다. 이 활동들은 사고 발생 위험을 수용 가능 한 수준까지 낮추기 위해서 위험원을 사전에 파악, 추적, 평가, 제거 또는 통제하기 위한 것이다. FHA 활동 범위는 대상 시스템의 설계기간 동안 실시하게 될 FHA와 관련된 활동들을 포함한다. FHA 수행을 위해서는 대상 시스템에 대한 운용 시나리오를 정의해야 한다.

시스템을 개발하는 초기 단계에서는 아직 여러 가지 정보들이 안정되어 있지 못하다. 그 중 어떤 자료들은 시스템의 후기 개발단계에서 정돈되는 것도 있으며, 더욱이 하부 제품에 대한 설계가 어느 정도 진행되어야 경계 면의 문제들을 파악할 수 있다. 따라서 FHA는 통상 PHA보다 약간 늦은 제품 개발단계에서 수행된다. FHA 수행을 통해 각 부품은 한 가지 이상의 고장모드를 가질 수 있으며, 각각의 고장모드는 정상적인 제품 기능에 위험을 초래할 수 있다. 따라서 부품의 위험성 모드나, 위험성의 원인, 그리고 제품이나 하부 제품에 미치는 영향 등 제품이나 하부 제품에 미치는 영향은 발생확률과 강도를 이용하여 기술해야 한다.

FHA 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다.

표 1. FHA 주요 항목 및 산출물 체크 리스트

인터페이스 위험원 분석(IHA)

일반적으로 IHA는 다음 사항에 대한 위험원 분석을 수행하는 활동이다.

l  물리적 환경과 인터페이스

l  다른 기술적인 시스템과의 인터페이스

l  인간과의 인터페이스

l  다른 철도 인증기관과의 인터페이스

시스템의 물리적 환경과의 인터페이스와 다른 기술적인 시스템과의 인터페이스에 대해 고려하여 IHA를 수행한다. 반면, 인간과의 인터페이스는 시스템의 특성상 O&SHA에서 수행한다. 해당 방법은 설계 내/외부 인터페이스 영역에서 발생할 수 있는 잠재적인 위험원을 파악, 분석, 정리하는데 목적이 있다. 또한 이 방법은 서브시스템 인터페이스 운용과 관련한 위험원을 제거 또는 완화하는 방법도 제안한다. 이 분석은 다양한 서브시스템과 인터페이스에서 위험원을 유발 할 수 있는 시스템영역을 표시하는데 사용된다. 또한, 필요하다면 추가적인 인터페이스 조사를 실시해야 할 부분도 표시한다. SSHA와 유사하게 IHA는 각 위험원의 발생 가능성과 각 위험원의 심각도를 정량적으로 예측 가능하다는데 특징이 있다.

IHA 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다.

표 1. IHA 주요 항목 및 산출물 체크 리스트

SSHA 고장 관련 위험원 파악 및 분석

서브시스템에서 예상 가능하거나 외부 장치와의 상호 작용/반응 제공에 실패하여 발생하는 위험원에 초점을 두고 있다. 일반적으로 다음 활동들을 수행해야 한다.

l  서브시스템 간 인터페이스와 시스템(일정_서브시스템을 통해)과 외부 장치 간 인터페이스에서 발생할 수 있는 가능한 모든 장애를 감지한다. 이 단계에서는 각각의 서브시스템 기능과 책임사항을 명확히 한다. 각각의 안전 관련/필수 서브아이템의 장애 모드를 해당 기능 및 타 서브시스템과의 상호 작용에 따라 결 정해야 한다. 각각의 장애는 내부임의 장애 또는 설계 불량이어야 하며, 이는 서브시스템 설계 검토 및 서브시스템 위험 원 분석 과정에서 다룬다.

l  단일 고장 결과 분석을 실시한다. 고장으로 인해 시스템의 정상 동작 왜곡과 관 련해 열화 현상이 발생될 수 있다.

l  다수 고장의 조합으로 인한 가능한 위험원 파악 및 분석을 실시한다. FTA을 사 용한다. FT(Fault Tree) 개발은 PHA에서 제시된 최상위 위험원에서 시작해야 한 다.

l  각각의 FT는 관련 독립적, 의존적, 동시 고장과 외부 이벤트(장치 상태 변경과 운용자의 에러 동작)와의 정확한 논리 접속을 제시하여 타당한 고장 조합을 입 증해야 한다.

l  PHA에서 결정된 각각의 최상위 위험원에 대해 해당 FT 개발 프로세스는 다음 에 초점을 맞춰야 한다.

l  기능 배분과 관련 정보 흐름으로부터의 가능한 모든 원인을 파악한다.

l  시스템이 위험원 상태에 들어갈 수 있는지 여부를 파악하기 위해 파악된 위험 들을 바탕으로 FT생성하여 FTA를 수행한다.

l  각각 관련 서브-서브시스템 관점에서 위험원 방지, 예방, 완화를 위한 안전 메커니즘을 정의 한다.

l  위험원 분석에 준하여 설계 목표와 안전관련 설계 제약사항간 갈등을 파악하여 해결한다. 이를 통해 안전 메커니즘과 다른 기능 설계 결정간 일관성을 유지한다. 이 갈등과 파악되면 아전 메커니즘을 재 정의하거나 설계를 수정하기 위해 예상 안전 속성을 침해하지 않고 상호보완이 이루어져야 한다.

SHA & SSHA기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다. 

[217호 웹진: 동향 브리핑] 구글의 차세대 서비스에 대한 동향

구글의 차세대 서비스에 대한 동향

하루에도 여러 번 새로운 IT 기술이 나오는 요즘이지만 그 중에서도 구글의 다양한 연구 영역은 손에 꼽는다. 연구를 시작할 당시에는 왜 저런 연구를 하는 것인가라는 의심을 받기도 하고 실제로도 쓸모 없는 연구로 선정되기도 하지만 많은 도전과 연구 정신은 다양한 기술과 서비스의 원천이라 할 수 있다. 이번 회에서는 구글이 연구했거나 연구 중인 프로젝트에 대해 살펴보기로 한다.

구글 클라우드 플랫폼(Google Cloud Platform)

구글에서 준비하고 제공하는 서비스 중에서 구글 클라우드 플랫폼을 가장 먼저 얘기하는 이유는 구글의 다양한 서비스와는 별개로 소프트웨어 개발자나 업체에 제공하는 개발 환경 측면에서 매우 중요한 역할을 할 수 있을 것으로 예측되기 때문이다.

클라우드는 직접 지어서 사용하지는 않지만 누군가 만들어 놓은 정해진 장소에 서버 등을 배치하여 사용하던 1세대 방식에서 버추얼 형태로 만들어 사용하던 2세대로 변했고 지금도 2세대 서비스가 많다고 볼 수 있다. 이것이 더 발전되면 환경을 고민하지 않고 개발할 수 있는 3세대로 이동되고 있다(그림1).

<그림1> 클라우드의 변천

출처: Google Cloud

구글 클라우드 플랫폼은 3가지로 구분할 수 있는데 애플리케이션 런타임 서비스(Application Runtime Services), 데이터 서비스(Data Services), 인프라와 운영(Foundation Infrastructure & Operations)이다(그림2). 이러한 플랫폼은 개발자가 동일한 개발 환경에서 개발을 할 수 있도록 도와주는데 예를 들어 원하는 기능의 API를 선택하여 호출해서 쓰는 형태다.

<그림2> 구글 클라우드 플랫폼의 종류

(a) 애플리케이션 런타임 서비스

(b) 데이터 서비스

(c) 인프라와 운영

출처: Google Cloud, http://bcho.tistory.com/1108

최근에는 데이터 분석을 위해 빅데이터 저장, 분석과 머신 러닝에 따른 클라우드 서비스도 제공하고 있다(그림3). 개발자가 빅데이터 분석과 머신 러닝을 이용해 새로운 소프트웨어를 만들고 싶다면 빅데이터 분석과 머신 러닝 관련 소프트웨어는 별도로 만들어야 하는 불편이 있다. 하지만 이렇게 미리 만들어진 API를 호출해서 사용한다면 많은 시간과 부담이 줄어들 수 있다.

<그림3> 구글 클라우드 플랫폼의 데이터 & 분석 서비스

출처: Google Cloud

구글은 이러한 클라우드 서비스를 이용할 수 있는 서비스 요금을 받고 있지만 궁극적인 목적은 소프트웨어 개발자들이 구글의 클라우드 플랫폼을 사용함으로써 구글의 개발 생태계로 들어오게 하는데 있다. 전세계 개발자가 구글의 개발 생태계에 접속 하면서 클라우드 서비스 외 구글의 서비스도 사용하게 하고 빅데이터 수집과 같은 다양한 정보를 가만히 앉아서 찾아낼 수 있기 때문이다. 구글에서는 구글 생태계로 끌어들이게 하기 위해 구글만의 고품질을 제공하는 파운데이션, 구글만의 이노베이션, 전기처럼 사용한 만큼 지불하는 트루 클라우드 이커너믹스 등을 기준으로 삼고 있다.

프로젝트 제로(Project Zero)

구글에서는 소프트웨어의 버그를 악용해 컴퓨터를 감염, 기밀을 훔치고, 통신을 해킹하는 위협없이 사람들이 네트워크를 사용할 수 있어야한다고 강조한다. 인권 운동가를 공격하거나 산업 스파이로 사용되는 정교한 제로데이 공격은 여전히 큰 위협이 되고 있다고 지적했다. 구글 프로젝트 제로는 구글에서 자체적으로 운영하는 보안 팀으로, 보안 팀 자체의 프로젝트를 말한다. 2014년 7월부터 운영하기 시작했고 제로데이 공격을 막는 것이 목적이다(그림4).

<그림4> 구글 프로젝트 제로

출처: Google Project Zero

제로데이는 패치나 보안 업데이트가 없는 취약점을 공격하기 때문에 제로데이 공격을 당한 사용자는 피해가 무궁무진할 수 있다. 가정용에서 인증서나 중요 자료를 빼가거나 기업 대상으로도 막대한 위협을 주는데 이 공격이 무서운 이유는 보안 패치나 업데이트가 뜰 때까지 속수무책으로 당해야 하기 때문이다. 프로젝트 제로에서는 최근 다양해지는 보안 이슈와 제로데이 공격에 대비해 여러 최정상급 보안 전문가와 화이트 해커를 모집하고 있다.

프로젝트 제로에서는 다른 업체의 보안 연구와는 다르게 구글에서 만든 것뿐만 아니라 사람들이 많이 쓰는 프로그램에 대해서는 모두 보안 연구를 한다는 것이다. 구글의 안드로이드는 물론, 마이크로소프트, 삼성전자의 휴대폰이나 애플의 iOS까지 다루고 있다. 긴급한 보안 취약점에 대해서는 해당 업체에 관련 사실을 통보해 조치할 정도로 제로데이를 없애기 위해 노력하는 곳이다.

프로젝트 탱고(Project Tango)

구글 프로젝트 탱고는 휴대폰이나 태블릿과 같은 모바일 기기에서 공간 지각력을 갖게 하는 플랫폼으로 모바일 기기가 실내 공간의 바닥, 벽, 천장의 위치나 기기의 위치와 방향도 인식할 수 있게 해준다. 마이크로소프트 키넥트의 동작 인식과 위 리모트의 운동 인식의 두 가지 기능을 동시에 실행하는 기능을 모바일 기기에서 가능하게 한다고 보면 된다. 스마트폰을 콘솔 게임을 위한 주변기기로 사용할 수 있다.

<그림5> 구글 프로젝트 탱고

출처: Google Project Tango

요새 많이 사용되는 비콘은 실내의 위치를 대략적으로 추적하는데 비콘 앱이 설치된 스마트폰은 설치된 비콘에서 얼마나 떨어져 있는지 인식한다. 탱고는 비콘을 업그레이드한 것인데 비콘이 활용되기 어려운 환경의 실내 위치를 제공하고 정확도도 매우 높다. 탱고는 문이나 계단, 장애물을 인식하여 스마트폰의 위치를 파악할 수 있다. 따라서 원하는 지점을 대략적인 위치가 아니라 정확한 지점을 알 수 있게 해준다(그림6).

<그림6> 프로젝트 탱고 디바이스의 예

출처: LG 이노텍

프로젝트 탱고의 특징을 정리하면 모바일 디바이스를 이용해서 주변을 촬영하면 3D 이미지로 스캔이 가능하다는 것이다. 그림6과 같은 거리 센서나 움직임을 감지하는 카메라를 통해 사용자가 움직이는 방향과 속도를 측정할 수 있고 높낮이나 크기 등도 정확하게 계산할 수 있기 때문에 증강현실을 이용한 기술 적용에 최적화된 프로젝트라 할 수 있다.

프로젝트 아라(Project Ara)

구글의 아라 프로젝트는 ‘16년도 가을에 공식적이지는 않지만 거의 중단 상태에 놓인 프로젝트다. 이미 미디어를 통해 많이 소개된 프로젝트로 스마트폰의 부품을 모듈화 하여 사용자가 원하는 제품을 직접 만들도록 하는 조립식 스마트폰 프로젝트였다(그림7).

<그림7> 구글 프로젝트 아라

출처: Wiki

밑판을 아라 프레임이라고 하는데 5.3인치로 CPU와 GPU, 안테나나 배터리, 스크린과 같은 필수 스마트폰 요소를 포함하고 후면에 6개의 슬롯을 따로 가진다. 아라는 모듈의 크기에 따라 1X2, 2X2 등의 모듈로 나뉘는데 여러 개의 모듈을 프레임에 조립해 하나의 스마트폰을 완성한다. 보통의 사용자에게는 필요성이 떨어졌겠지만 특수한 환경에서 스마트폰을 활용하는 사람에게는 유용했을 것으로 예측되었다.

프로젝트 아라가 실패한 이유는 몇가지 이유가 있는 것으로 알려졌는데 하드웨어 밸런스를 무시할 수 없었다는 것과 완성한 스마트폰의 안정성을 무시할 수 없었다는 점이 가장 크게 제시되었다. 아무래도 필요한 모듈만 조립해서 사용하면 되었기 때문에 각 모듈 간 테스트가 이루어지기 힘들기 때문일 것이다.

프로젝트 아라는 구글의 진취적인 성향이 많이 들어난 프로젝트 중의 하나인데 기업의 관점이 아닌 사용자의 관점으로 접근하고자 하는 구글의 노력이 그대로 반영되었다고 볼 수 있다. 스마트폰의 경우 전세계적으로도 몇 개 되지 않는 제조사에서 만들어지다 보니 사용자의 취향은 전혀 고려되지 않아 많은 불만들이 있었기 때문이다. IT 기술이 발전하는 요즘에는 이러한 사용자 관점의 아이디어가 새로운 서비스나 상품 탄생의 중요한 시발점이 될 수 있기 때문에 매우 의미 있는 프로젝트로 볼 수 있다.

프로젝트 룬(Project Loon)

구글에서는 아프리카와 같은 오지에도 인터넷 회선을 저렴한 가격에 공급하기 위해 풍선을 이용한 와이파이를 공급하는 프로젝트 룬을 진행중이다. 이미 ‘13년에 다양한 실험을 실시하여 의미 있는 결과를 얻은 것으로 알려졌지만 처음 시작 당시에는 많은 사람들이 무모한 도전일 뿐만 아니라 왜 저런 짓을 하는지 이해를 못하는 경우도 많았다. 하지만 지금 생각해보면 거의 모든 IT 기기들은 네트워크로 연결되어 하나의 인터넷 세상에서 구동 되어야 제 기능을 하는 경우가 많아지고 있고 새로운 사용자 확보나 끊김 없는 서비스를 위해서는 지구상 어디에도 네트워크가 연결되어 있어야 한다는 점에서 매우 중요한 프로젝트로 인식된다(그림8).

<그림8> 구글 프로젝트 룬

출처: Google Project Loon

프로젝트 룬은 지름 15미터인 풍선에 헬륨을 넣어 성층권 상공까지 올려 와이파이로 연결되도록 하고 있으며 변하는 온도에도 일정한 압력을 유지하게끔 만들어져 있다. 한번 올라간 풍선은 약 100일 정도 상공에서 머물 수 있고 태양광을 연료로 전력을 공급받는다. 인터넷 연결을 위해서는 해당 지역의 통신사가 풍선에 신호를 발사하고 풍선에서는 이 신호를 더 많은 사용자에게 확산하게 되는 개념이다.

구글에서 연구하는 Google X 프로젝트의 대표적인 프로젝트인 프로젝트 룬의 목적은 전세계 누구나 인터넷에 연결할 수 있도록 하는 것이기 때문에 이를 통해 구글은 광범위한 경제와 사회적 데이터와 이익을 제공할 것으로 예상된다.

프로젝트 윙(Project Wing)

‘14년에 본격 테스트에 들어간 프로젝트 윙은 Google X 프로젝트 중 현재 시점에 가장 주목받는 프로젝트다. 드론을 이용한 배송 서비스인 프로젝트 윙은 ‘12년에 연구가 시작되어 ‘16년에 비행 허가를 받아 사실상 무인 항공기인 드론을 통해 택배 서비스가 가능하게 되었다.

<그림9> 구글 프로젝트 윙

출처: Google Project Wing

구글은 ‘16년 미국 정부로부터 공식적으로 비행 테스트 허가를 받았는데 아마존의 드론 상품 배송 서비스인 ‘프라임 에어’에 대한 시험 비행이 허가 받지 못한 것과는 대조적이다. 아마존은 승인을 위해 영국에서 드론 시험 비행을 추진하겠다고 발표하기도 했다.

프로젝트 윙의 중요성이 강조되는 이유는 드론은 단순히 택배를 위한 기술이 아니고 자율주행 자동차가 하늘을 날아다닌다고 봐야 한다. 이를 위해서는 다양한 IT 기술이 발전되어야 하고 사람이 할 수 없는 다양한 활동이나 전략적 무기에도 활용될 수 있다. 이러한 이유로 미국 연방 정부는 전미과학재단을 통해 향후 5년간 3천 5백만 달러를 투자해 드론 연구를 지원하기로 했다.

시사점

구글이 가진 장점 중의 하나는 모든 서비스나 상품을 사용자 관점에서 고민한다는 것이다. 구글이 새로운 연구를 시작하면 크게 관심을 두지 않다가 완성되는 시점에 확인하면 당시의 IT 기술 흐름에 최적화된 경우를 많이 보이고 있다. 빅데이터나 머신 러닝, 그리고 개발자 환경을 위해 이미 오래전부터 클라우드 플랫폼을 준비하면서 구글 생태계를 준비해왔고 Google X 프로젝트의 발전을 통해 최근 4차 산업혁명에 맞는 혁신에 대비하고 있다.

참고 자료

http://www.qoll.org/watch/fTeI4Fi8E2s/1-5--.html

https://www.youtube.com/watch?v=fTeI4Fi8E2s&feature=youtu.be

http://bcho.tistory.com/1108

http://www.qoll.org/watch/fTeI4Fi8E2s/1-5--.html

https://www.slideshare.net/cjang99/google-cloud-platform-rockplace-big-data-eventmar312016

https://namu.wiki/w/%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%20%EC%A0%9C%EB%A1%9C

https://get.google.com/tango/

http://blog.lginnotek.com/317

https://namu.wiki/w/%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%20%EC%95%84%EB%9D%BC

https://brunch.co.kr/@bruncho7zx/16

https://x.company/loon/

https://x.company/projects/wing/

Keyword: software engineering, google project, project loon, project wing, project ara, dron