22nd SW Quality Insight 컨퍼런스
트랙1-2 조성배 교수(연세대학교)
주제 : 4차 산업혁명을 위한 인공지능의 핵심기술과 고품질 소프트웨어
2016년 12월 30일 금요일
2016년 12월 29일 목요일
강의 영상: Analytic Database 기반의 빅데이터 분석시스템과 데이터 품질
22nd SW Quality Insight 컨퍼런스
트랙1. 김정중 이사(이글로벌시스템) 강의영상
주제 : Analytic Database 기반의 빅데이터 분석시스템과 데이터 품질
2016년 12월 28일 수요일
4차 산업혁명을 위한 인공지능의 핵심기술과 고품질 소프트웨어
인공지능의정의
•인간 지능의 본질을 규명하고 이를 인공적으로 재현하려는 기술/학문
•强한인공지능(strong AI)
–인간의 지능을 구현하는기술/학문
–사람처럼 생각하는 기계를 만드는기술
•창의/사고/감정
•弱한인공지능(weak AI)
–인간의 지능을 모방하여 특정한 문제를 푸는기술/학문
–주어진 문제를 사람처럼 풀기위한 기술
•편견없이 지치지않고 대용량자료 처리
인공지능구현의어려움과접근방법
•인공지능
–“What”은알겠으나, “How”는?
•지능 기술의발달사: 컴퓨터 발명이후 60여년간 부단히 계속되는 신기술의 출현과퇴조
–논리학, 최적화이론, 확률적모형, 탐색이론, 규칙기반시스템, 전문가시스템, 퍼지논리, 신경회로망, 유전자알고리즘, 카오스이론, ..….
•지능시스템 개발방법론
–지식기반 방법론: 저장된 지식을 기반으로 의사결정 ->IBM 왓슨의인공지능
–데이터기반 방법론: 데이터로부터 추출된 지식으로 의사결정 -> 구글알파고의인공지능
인공지능구현핵심기술: 탐색
인공지능구현핵심기술: 규칙기반시스템
인공지능기술의현황과해결방안
•현황
–다양한 기술이 다양한 분야에서 독자적으로 개발되고 있음
–명칭의 혼란에 따른 과대평가나 기술의오용/남용이 심각함
•해결책1: 통합형 지능기술
–전통적인 인공지능방법이 추구하는 상위수준의 지능과 다양한 방법을 통한 저수준의지능 사이에 협력이필요
–연결주의(connectionist)와 기호주의(전통적인인공지능)
–상향식(인공생명)과 하향식(전통적인인공지능)
–반응형(행동기반)과 숙고형(전통적인인공지능)
•해결책2: 문제해결을 위한 AI 아키텍쳐구축
–기호수준의 표현과 연결주의 표현사이의 협력필요
–사회성, 감정, 감성등에 대한 고려필요
2016년 12월 27일 화요일
Predicting Quality Assurance with Software Metrics and Security Methods
참석자
Will Hayes - Principal engineer in the SEI’s Software Solutions Division
(the Carnegie Mellon University Software Engineering Institute)
Carol Woody - Ph.D., Technical manager of CERT Cybersecurity Engineering Group
요약
오늘 우리가 이야기할 것은 소프트웨어 매트릭스와 보안 방법을 써서 품질 보증을 예측하는 것이다.
우리는 핵심 분야에 대해 개발 방법과 관행을 가지고 개발해 왔습니다. 보안 유지 요구 사항, 소프트웨어 위험 관리 및 공급망 위험 관리는 이러한 것의 세 가지 주요 영역이다. 많은 질적인 조치를 취하고 있지만 실제로 이 영역을 심각하게 관리하기 시작하는 정량적 메커니즘을 확립하는 것은 매우 어렵다.
보안 취약점과 품질 결함 사이의 연결을 알아낼 수 있었다. 주로 다양한 유형의 소프트웨어 전반에 걸쳐 결함 밀도를 추적하는 관점에서 “Capers Jones”가 많은 측정 기준을 가지고 있다.
결점의 1에서 5 %가 실제로 취약성이거나 취약성으로 간주되어야 한다. 매우 제한된 데이터 밖에 없는데 보안 데이터를 공유하려는 사람은 거의 없다. 이러한 데이터는 주로 운영 체제와 연결되어 있다. 이 데이터를 얻기 위해 실제로 상세한 자료를 가지고있는 약 100 개의 프로젝트 정도의 프로세스를 연구했다. 그 중에서 훌륭한 보안 및 안전 결과를 100 개 프로젝트 중 5 개 프로젝트를 식별 할 수 있었다.
중요한 보안 분석과 관행이 라이프 사이클 전반에 걸쳐 연계되어 있음을 확인했고, 초기에 취약점을 포착한 다음 시스템이 설치되기 훨씬 전에 오랫동안 해결하도록 했더니 매우 좋은 운영 결과를 얻을 수 있었다.
다소 적은 데이터 세트라도 최소한의 보안 분석 방법과 관행을 사용하여 높은 상관 관계를 증명할 수 있었고 라이프 사이클 전반에 걸친 취약성 해결이 가능했다.
핀테크 시장에 대한 소프트웨어 개발 업체의 대비 방향
미국에서는 20여년 전에 인터넷 전문은행이 생겼지만 우리나라는 금년말에 케이뱅크가 본인가를 받았고 한국카카오뱅크가 본인가를 신청한다. 은행권은 돈을 다루는 서비스이기 때문에 가장 보수적인 산업으로 잘 알려져 있어 다른 산업과 달리 ICT 기술을 접목시키는데 많은 시간과 어려움이 있었다. 최근에는 핀테크(Fintech; Finance Technology)라는 기술로 새로운 금융 서비스 시대를 열고 있는데, 이번 회에서는 핀테크 시장에 대비하여 소프트웨어 개발 업체는 어떤 준비를 해야 하는지 금융권 프로젝트 PM으로 있는 로만소프트 이영환 대표와 ㈜웹케시 박해윤 박사와 함께 얘기를 들어본다.
Q: 안녕하세요. 핀테크에 대해 많은 말들이 오가고 있지만 정작 핀테크에 대한 의미나 범위는 한가지로 정리되는 것은 아닌 것 같습니다. 핀테크에 대한 정의를 먼저 해주시죠.
저희도 다양한 자리에서 핀테크에 대한 얘기를 하다 보면, 서로 다른 생각을 가지고 얘기하는 경우가 종종 있습니다. 아마도 핀테크의 영역이 그만큼 넓기 때문이지 않을까 싶은데, 아마도 ICT 기술을 잘 모르는 금융권에 너무나 많은 기술들이 한꺼번에 접목되면서 생각할 수 있는 의미나 범위가 더 많은 것이 아닐까 싶네요.
그래도, 핀테크에 대해 한마디로 정리를 하자면, 기존에 있던 금융 서비스 방법을 ICT 기술로 바꾼다는 것이겠죠. 그림1에서 보는 것처럼, 금융권에서 서비스하는 지금/결제, 송금, 대출, 자산관리 등을 ICT를 통해 서비스 하는 것입니다. 최근에 많이 확산되고 있는 모바일 페이먼트의 경우도 신용카드 서비스를 ICT인 스마트폰으로 할 수 있는 것처럼 말이죠.
<그림1> 핀테크의 사업 영역
출처: IPnomics
Q: 인터넷 뱅킹이나 모바일 뱅킹 같은 서비스는 이전에도 많이 해왔던 것들인데 핀테크라는 이름으로 대신하는 것인가요?
그렇지 않습니다. 앞에서 말씀드린 것은 단순히 서비스 측면만 말씀드린 것입니다. 은행이나 신용카드 회사 등을 통해 받던 서비스를 ICT로 활용하는 방법이 바뀌는 것이고요. 서비스 방법을 바꾸기 위해서 필요한 많은 ICT 기술이 있는 것입니다.
그림2는 S사의 페이먼트 관련 아키텍처를 나타내고 있습니다. 페이먼트 서비스 하나를 추가하면 그림과 같이 수많은 ICT 기술이 들어가야 합니다. 페이먼트 서비스를 위해 SMS도 자동 발송되도록 해야 하고 페이먼트 정책은 어떻게 만들고 처리해야 하는지도 고민해서 관리해야 하고, 외부 업체와 연계는 어떻게 되어야 하는지도 생각해야 하죠. 기존 SI 시스템 구축하는 것과 별반 다르지 않습니다.
<그림2> S사의 역할 기반 Multi-Tenant Architecture
모바일 SW 개발 사례 연구 - 품질/테스트
최근 몇 년 사이에 스마트폰의 급격한 증가와 함께 다양한 모바일 소프트웨어가 늘어나고 있고, 상당수의 컴퓨팅 작업들도 스마트폰에서 실현되고 있다. 이러한 이유로 모바일 소프트웨어 사용자의 요구사항이 늘어나고 있으며 요구사항을 반영하기 위한 설계, 개발 기법이나 품질, 테스트 기법들의 필요성도 함께 요구되고 있다. 이번 회에서는 모바일 소프트웨어의 품질과 테스트 방법에 대해 살펴보도록 한다. 품질 확보를 위해 고려해야 하는 테스트 방법을 잘 이해하여 효율적인 모바일 소프트웨어 개발이 되기를 기대한다.
매우 빠른 트렌드 변화를 보이는 모바일 소프트웨어가 성공하기 위해서는 기존의 소프트웨어 개발 방식이 아닌 모바일만의 개발 환경의 특징을 고려하는 것이 중요하다. 거의 유사한 OS와 해상도에서 구동되는 PC 기반 소프트웨어와는 달리 모바일 소프트웨어는 다양한 플랫폼과 해상도에 맞춰 개발해야 하기 때문에 개발자의 많은 노력과 시간이 요구된다.
사례 연구 전 확인 사항
모바일 소프트웨어의 개발 환경과 품질 체크 포인트
매우 빠른 트렌드 변화를 보이는 모바일 소프트웨어가 성공하기 위해서는 기존의 소프트웨어 개발 방식이 아닌 모바일만의 개발 환경의 특징을 고려하는 것이 중요하다. 거의 유사한 OS와 해상도에서 구동되는 PC 기반 소프트웨어와는 달리 모바일 소프트웨어는 다양한 플랫폼과 해상도에 맞춰 개발해야 하기 때문에 개발자의 많은 노력과 시간이 요구된다.
모바일 소프트웨어는 마우스와 키보드 없이 사용자와 인터페이스를 해야 하기 때문에 UI/UX 관점의 검토도 필요하지만 모바일 소프트웨어에서 가장 주목해야 할 것은 비즈니스 환경이다. 하루에도 수많은 모바일 소프트웨어가 등록되기 때문에 짧은 시간 안에 개발해야 하고, 품질 측정과 테스트도 빠른 방법이어야 한다. 그림1은 앞에서 설명한 내용을 바탕으로 모바일 소프트웨어의 특징을 7가지로 나타내었다.
<그림1> 모바일 소프트웨어의 특징
출처: Design of Quality Evaluation Model for Mobile Application
모바일 소프트웨어의 개발 시간을 줄이기 위해서는 개발이 필요한 부분만 신경 쓸 수 있도록 개발 환경을 표준화 하는 것이 좋지만 대부분의 개발자들은 각자의 방식으로 개발 환경을 구축하여 소스 코드가 잘못 관리되거나 약간의 개발 환경 변화에도 이전에는 발생하지 않던 오류가 나타나기도 한다. 표준화 된 개발 환경은 개발 효율성을 높이기 위해 필요하다는 것을 잊으면 안된다.
2016년 12월 26일 월요일
IBM의 Rational Test Workbench
출처: IBM Knowledge Center
IBM의 모바일 테스트 기능은 Android나 iOS 디바이스에서 네이티브, 웹, 그리고 하이브리드 소프트웨어의 기능과 성능의 테스트 계획, 실행, 그리고 분석을 자동화하는 것을 기본으로 한다.
IBM 모바일 테스트의 목표는 모바일 소프트웨어가 설계와 개발에 필요한 요구사항이 충족되었는지 확인하는 것이다. 이 목표를 충족할 수 있도록 Rational Test Workbench 는 테스트 프로세스에서 그림2와 같은 테스트 스테이지를 구현한다.
<그림2> IBM 테스트 프로세스의 스테이지
<참고사이트>
iOS 시뮬레이터에 모바일 테스트 클라이언트 설치
http://www.ibm.com/support/knowledgecenter/ko/SSBLQQ_8.7.0/com.ibm.rational.test.lt.moeb.do
c/topics/t_install_ios_client.html
|
(1) 테스트 워크벤치
윈도우(Windows)나 리눅스(Linux), 애플의 맥(Mac) 등에 설치할 수 있고, 특히 기본 컴포넌트는 모바일 앱 테스트를 지원하도록 설계되어 있다. 테스트 네비게이터에는 테스트를 생성하는데 필요한 모바일 수신 레코딩, 테스트 프로젝트, 테스트 및 모바일 디바이스가 나열된다(그림3).
<그림3> 테스트 네비게이터
모바일 소프트웨어의 품질 평가
PC 기반의 소프트웨어와 모바일 소프트웨어의 품질 평가는 근본적인 평가 관점은 유사하지만 모바일 소프트웨어는 그림1의 특징이 있어 저성능 이지만 고효율을 발휘할 수 있는 관점으로 품질을 평가해야 한다. 모바일 소프트웨어의 품질 평가 모델을 정의하기 위해 ISO/IEC 25000의 평가 항목과 모바일 애플리케이션의 특징을 연결하여 6개의 품질 평가 항목으로 정리된다(표1). 자세한 품질 속성과 메트릭에 대해서는 아래 사이트를 참고한다.
<표1> 모바일 소프트웨어의 품질 평가 항목
<참고사이트>
품질 속성과 메트릭의 맵핑
http://www.kpubs.org/article/articleMain.kpubs?articleANo=HOJBC0_2014_v18n10_2451
|
핀테크 소프트웨어와 오픝 플랫폼
Q: 핀테크 소프트웨어를 개발하기 위해서는 오픈 플랫폼을 이용하면 된다는 말씀이군요. 그런데, 핀
테크 서비스를 은행권에서만 하는 것은 아니지 않습니까?
네, 맞습니다. 오픈 플랫폼을 공동으로 쓰라고 해서 반드시 해야하는 강제 사항은 아니니까요. 은행권 공동 오픈 플랫폼도 금융위원회나 시중 17개 은행만 참여하고 있습니다. 참여하지 않는 곳은 별도의 대안을 마련해야 하는 것이지요.
핀테크 3요소를 살펴본다면, 정의하는 사람마다 다르겠지만 효율성, 편의성, 안정성이라고 말합니다. 많이 건드리지 않고 편하게 쓸 수 있어야 하지만 매우 안정적이어야 한다는 것이죠. 그만큼 핀테크는 신중히 접근해야 합니다.
기존 금융 서비스는 은행과 고객 간 서비스였기 때문에 매우 단순한 서비스 방법을 취했습니다. 고객이 은행가 가거나 인터넷 뱅킹을 통해 원하는 서비스를 받게 됩니다. 하지만, 은행과 고객 사이에 핀테크 서비스가 추가되면서 다중 서비스 개념으로 변하게 되었고, 이러한 변화는 많은 문제점을 가지게 됩니다(그림6).
<그림6> 핀테크의 위험 발생 요인
Q: 새로운 서비스가 추가되면서 그만큼 보안 문제도 발생할 수 있다는 말씀으로 들리네요.
핀테크는 금융 기관 주도로 운용된 것이 사실입니다. 기존 금융 시스템은 대부분B2C를 대상으로 하지만 핀테크 업체까지 대상이 확대되기 때문에 핀테크 금융 시스템은 B2C와 B2B를 모두 고려해야 합니다. 그렇기 때문에, 금융 사고에 대한 위험이 더 많이 존재하고 고객 정보가 외부에서 관리되는 등 정보 보호 문제도 발생할 수 있습니다. 이러한 문제들은 핀테크 관련 규제가 많아지는 가장 큰 요인이 되고 있습니다. 소프트웨어 개발 측면에서 본다면, 여타 시스템보다 훨씬 더 높은 보안 품질을 유지해야 하는 이유이지요.
2016년 12월 23일 금요일
소프트웨어의 테스트 자동화에 대한 장단점 분석
한동안 소프트웨어의 품질을 높이기 위해 QA(Quality Assurance) 활동이 주류를 이루었다. QA의 하나로 가장 주목받는 분야가 테스트라는 것은 누구도 부인하기 어려울 것이다. 그만큼 소프트웨어의 완성도를 확인하기 위해 중요한 활동이 테스트이고, 아직까지도 충분한 만족도를 내지 못하는 분야이기도 하다. 최근에 테스트 자동화를 통해 이러한 한계를 해결하고자 노력하고 있지만, 끊임없는 테스트자동화 도구가 나오는 이유는 아직도 요구를 충분히 만족시키지 못하기 때문일 것이다. 이번 회에서는 테스트 자동화에 대해 국제대학교 김성철 교수를 만나 자세한 얘기를 들어본다.
Q: 안녕하세요. 소프트웨어 테스트에 대한 말들이 요새 더 많이 나오기 시작하는 것 같습니다. 테스트 자동화에 대해 말씀해 주시죠.
테스트는 소프트웨어 개발에 있어 없어서는 안되는 중요한 활동 중의 하나입니다. 소프트웨어라는 것이 처음 나왔을 때부터 지금까지쉼없이 발전하는 분야 중의 하나이기도 합니다. 하지만, 소프트웨어 테스트의 발전은 더디기만 했습니다. 가장 큰 이유는 소프트웨어테스트가 항상 수작업으로 이루어질 수 밖에 없었기 때문입니다. 사람이 할 수 있는 것에는 한계가 있는데 아무리 노력해도 모든 테스트 케이스를 커버하기도 어렵고, 일정한 테스트 수준을 유지하기도 어려웠습니다. 이러한 것을 보완하고자 TDD(Test Driven Development)나 테스트 자동화 같은 분야들이 나오기 시작한 것이죠.
Q: TDD에 대해서는 지난번 185호 인사이드 이슈에서 말씀하셨는데요. 테스트 케이스를 개발하기 전에 만들어 개발한 코드가 정상적으로 동작하는지 미리 확인하자는 것으로 기억하고 있습니다. 그렇다면, 테스트 자동화가 소프트웨어 개발에서 필요한 이유는 무엇인가요?
소프트웨어 테스트는 소프트웨어가 정상적으로 동작하는지를 살펴보기 위해 테스트 데이터를 샘플로 만들어서 개발자가 직접 테스트를 했습니다. 이러한 수작업은 모든 테스트 케이스를 만들 수 없었고 일관된 테스트도 하기 어렵습니다. 그리고, 테스트 계획을 수립할때도 효과적인 테스트 케이스를 만들기 어렵습니다(그림1).
<그림1> 테스트의 효율성과 유효성
출처: http://www.tssg.org/
가장 좋은 테스트는 모든 테스트 케이스를 포함하고 빠르게 테스트가 가능해야 합니다. 그림1에서 보는 것처럼 유효한 테스트가 효율적으로 이루어져야 좋은 테스트가 되고, 좋은 테스트를 통해 안전한 소프트웨어를 완성할 수 있습니다. 표1은 테스트 자동화를 통해 얻을 수 있는 효과를 나타냅니다.
<표1> 테스트 자동화의 효과
SW 특징 - 4차 산업혁명, 품질의 중요도
Real World – 실시간 제어
교통 의료 에너지 전쟁 …
Cost of poor quality (COPQ)
• 도요타의 프리우스 16만대 리콜 2005
• 대량의 방사선 누출 사망 - Therac-25 엑스레이 1985-1987
• 소련 가스 파이프라인 사고 – 역사상 가장 큰 폭발 1982
• 화성탐사선 마리너 1호 - 4분만에 대서양 추락
• 아리안 5 로켓 40초만에 폭발 1996년
• 패트리엇 미사일 -28명의 미국 병사 사망 – 1991
• 심장박동기 오동작 – 미국 메디트로닉스사 - 1994
2016년 12월 22일 목요일
스마트 비서에 대한 동향 분석
아주 오래전 소개된 영화에서도 사람과 대화하는 컴퓨터는 많이 소개되었고, 이에 대한 연구도 지속적으로 이루어져 왔지만 좋은 연구결과가 나타나지는 못했다. 하지만, 최근 스마트폰뿐만 아니고 독자적인 디바이스로 스마트 비서 기능이 많이 소개되고 있다. 사람 목소리를 알아듣고 실시간으로 분석하여 사람이 원하는 결과를 제공해주는 스마트 비서는 IT 서비스 중에서도 가장 주목받는 분야로 주목받고 있다. 이번 회에서는 다양한 스마트 비서에 대해 알아보기로 한다.
인공지능이 발달하며 기계와 인간 간에 음성으로 대화하는 시대가 현실이 됐다. 현대인의 필수 디바이스인 스마트폰은 음성 비서 기능탑재가 기본이 되었고, 스마트홈, 지능형 차량이나 사물인터넷에서도 음성 인식을 통한 기계와 인간의 자연어 대화 기능이 추가되고 있다.
인공지능이나 음성 인식은 70년대부터 많은 연구가 이뤄졌지만, 기술적 한계 때문에 불과 얼마 전까지만 해도 상상의 영역이었다. 컴퓨터가 인간의 음성을 인식하는 것만도 엄청난 연산 작업이 필요한 상황에서 인간의 말을 완전히 이해하여 답을 주는 것은 더욱 어려운일이었다. 이러한 어려움은 머신러닝(Machine Learning)과 딥러닝(Deep Learning) 기술이 발달하면서 조금씩 해소되고 있다. 머신러닝과 딥러닝을 통해 기계가 사람의 대화 패턴, 목소리 높낮이, 자주 쓰는 단어 등을 스스로 학습하여 익힐 수 있게 되면서 음성 인식의정확도가 눈에 띄게 높아졌기 때문이다.
<그림1> 인공지능의 역사
시장 조사 기관인 스트래티지 애널리틱스(SA)는 AI 비서가 탑재된 정보기술(IT) 기기의 세계 판매량이 올해 180만대에서 2018년 520만대, 2020년에는 1천510만대까지 치솟을 것으로 예측하고 있고, KB금융지주경영연구소에서는 AI 비서 시장을 2019년에는 약 20억불 이상, 2024년에는 80억불 이상으로 예측하고 있다(그림2).
<그림2> AI 비서 시장 전망
피드 구독하기:
글
(
Atom
)