SW개발유형별 세부 평가항목별 프로세스 수준점수

SW개발유형별로 세부 평가항목에 대한 프로세스 수준점수 산정 결과는 다음의 표와 같다.대부분의 세부 평가항목에 있어서도 IT서비스의 경우 다른 SW개발유형에 비해 그 수준 점수가 높은 것으로 나타나고 있다. 

더보기

SW개발유형별 SP품질인증 프로세스 수준 분석

SW개발유형별로 소프트웨어 프로세스 품질인증의 평가영역별 프로세스 수준점수를 살펴보면, 다 음의 표와 같으며, IT서비스 유형의 경우 모든 평가영역에 있어서 다른 SW개발유형 보다 높은 수 준의 점수를 나타내고 있다. 

 더보기

기업규모별 세부 평가항목별 프로세스 수준점수

기업규모별로 세부 평가항목에 대한 프로세스 수준점수 산정 결과는 다음의 표와 같다. 

기업규모별로 세부 평가항목에 대한 프로세스 수준점수를 분석한 결과 모든 세부 평가항목에 있어 서 대기업의 수준이 높은 것으로 나타났으며, 특히 설계에 있어서는 그 차이가 매우 큼을 확인할 수 있다.

 더보기

기업규모별 SP 품질인증 프로세스 수준 분석

기업규모별로 소프트웨어 프로세스 품질인증의 평가영역별 프로세스 수준점수를 살펴보면, 대기업 의 경우 모든 영역에서 중소기업보다 높은 수준을 보유하고 있는 것으로 기존 SW공학수준의 프로 세스 수준 분석 결과와 동일하게 나타났다.

특이한 점은 기존 SW공학수준 프로세스 수준 분석에 비해 개발 영역의 수준점수 차이가 보다 크게 나오는 것을 확인할 수 있다. 이러한 차이는 개발 영역에 있어서 소프트웨어 프로세스 품질인증 기 준이 CMMI의 기준보다 개발 활동을 보다 세부적으로 구분되었기 때문에 발생된 것으로 파악된다. 

 

 더보기

SW공학수준별 세부 평가항목별 프로세스 수준점수

SW공학수준별로 세부 평가항목에 대한 SP 프로세스 수준점수 산정 결과는 다음의 표와 같다.SW 공학수준별로 세부 평가항목에 대한 프로세스 수준점수를 분석한 결과 SW공학수준이 높을수록 모 든 평가항목의 수준점수가 높은 것으로 나타났다. 

더보기

SW공학수준별 SP품질인증 프로세스 수준 분석

SW공학수준별에 따른 소프트웨어프로세스 품질인증의 평가영역별 프로세스 수준점수를 살펴 보면, 프로세스 수준과의 비교분석 결과와 마찬가지로 SW공학수준이 Advanced 등급인 경우 모든 평가영역에서 높은 수준점수를 보여주고 있으며, 상대적으로 Absent 등급인 경우 모든 평가영역에서 낮은 수준점수를 보여주고 있다. 

 더보기

제21회 SW Quality Insight 컨퍼런스 강의영상

발표영상 보러가기

SW분야 여성 능력 개발과 일자리 창출을 위해 서울시여성능력개발원과 업무협약 체결

6월 2일 서울 자양동 서울시여성능력개발원에서 심현택 소프트웨어공학센터 소장과 서미경 서울시 여성능력개발원 원장이 소프트웨어분야 여성 능력 개발과 여성 일자리 창출을 위한 'SW프로슈머 평가지원 사업'업무협약을 체결했다.

이 협약을 통해 국내 중소기업과 스타트업 기업이 개발한 SW 제품 평가에 참여하는 여성 프로슈머를 양성할 계획이다.

더보기

7월 신규가입 이벤트

효율적이고 효과적인 소프트웨어의 지속성을 향하여

영상출처:  Software Engineering Institute | Carnegie Mellon University


미 국방부는 단종되었지만 수십 년 간 주요 기능을 계속 유지해야하는 레거시 무기 시스템을 지속 가능하게 하기 위해 노력을 기울이고 있음.

- 도입 단계가 이미 지난 레거시 시스템이지만, 매 18 - 24개월 마다 소프트웨어 업그레이드를 해야 함.
- 미미한 하드웨어 변화에 비해 소프- 트웨어는 훨씬 광범위하게 현대화 작업이 진행됨.

 항공기의 하드웨어 부분은 매우 튼튼하게 만들어 지기 때문에 오랜 시간 동안 재사용이 가능합니다. 따라서 하드웨어 내에서 소프트웨어로 구현되는 대부분의 시스템 기능도 다양한 환경에서 장기간 재사용할 수 있어야 하고 또 여러 가지 위협에 대처할 수 있어야 합니다. 이런 이유로 소프트웨어의 지속성은 매우 중요합니다.

 오래된 하드웨어를 다량 보유하고 있는 미 국방부는 상업적인 영역보다 소프트웨어 지속성 문제를 해결하는데 있어 더 많은 경험을 쌓아 왔습니다. 이렇게 오랫동안 성공적으로 시스템을 지속할 수 있는 두 가지 이유 중 하나는 미공군 B-2에서의 경험이었습니다. 20대의 비행기가 운영 중이라면 20대의 비행기는 비행을 시작하기 전에 통합 실험실의 수많은 테스트를 통과해야 합니다. 또 다른 하나는 CMMI(Capability Maturity Model Integration) 입니다. 소프트웨어 프로세스 개선에 앞장서는 조직은 대부분 소프트웨어 지속성(Sustainment) 영역을 담당합니다. 개발사가 최초로 제품을 만들어 내면 소프트웨어 지속성 조직은 해당 제품이 제대로 기능할 수 있도록 소프트웨어를 통해 보장해 줍니다. 이후에는 해당 시스템의 미래 버전을 관리하고 유지하는 책임도 져야 합니다. 이를 향상(Enhancement)이라고 합니다. “향상”이라는 것은 완전히 새로운 시스템을 만들어 내는 것이 아니라 예전 하드웨어 시스템을 그대로 사용하면서 시스템의 유기적인 면을 통해 달성하는 것입니다.

더보기

모바일 소프트웨어 보안 이슈 점검

모 바일 사용자가 급격히 증가하면서 모바일 소프트웨어는 쉼 없이 개발되고 사용된다. 모바일의 특성 상, 항상 사용자 손에 들고 있기 때문에 똑 같은 소프트웨어라 하더라도 PC보다 모바일의 사용량이 훨씬 많다. 그리고, 모바일 디바이스의 전화번호로 PC보다 훨씬 많은 개인정보를 담고 있고 다양한 개인 인증 서비스를 할 수 있다. 이와 같이, 모바일 소프트웨어는 PC보다 개인정보를 접할 수 있는 기회가 더 많이 생기고 상대적으로 취약한 모바일 네트워크로 인해 보안 위험이 항상 존재한다. 이번 회에서는 모바일 소프트웨어를 만들 때와 활용하면서 살펴봐야 하는 보안 활동에는 무엇이 있는지 태그잇(TAG-IT)의 송영상 대표를 만나 자세한 사항을 들어본다. 

Q: 사례를 살펴보기 전에 모바일 소프트웨어에서 보안이 필요한 이유를 말씀해 주시죠.

모 든 소프트웨어를 만들 때는 반드시 보안에 대해 고민해야 합니다. 한 순간의 방심으로 많은 비용과 시간을 들여 만든 소프트웨어가 치명적인 문제를 낳을 수 있기 때문입니다. 소프트웨어 보안을 논의하면, 대부분 비슷한 방안이 논의되는데, 어떤 목적으로 무슨 환경에서 어떻게 사용되는 지에 따라 조금 더 다양한 관점으로 논의되어야 합니다. 그림1은 디바이스 별로 사용량을 나타냅니다. 90% 이상이 모바일 디바이스이고, 그 중에서도 스마트폰은 67%나 차지합니다. 이 것은 양만 늘어난 것이 아니라 그에 따른 보안 이슈는 몇 배 이상 늘어난다고 봐야 합니다. 더구나, 예측된 2017년 이후는 얼마나 더 늘어날지 알 수 없습니다. 빅데이터나 IoT의 발전이 자리를 잡는다면, 모바일 사용량은 상상할 수 없을 만큼 늘어날 겁니다. 

 <그림1> 디바이스 별 데이터 사용량 

PC 보다 모바일의 경우는 개인정보가 더 많이 노출될 수 있고 무선 네트워크를 사용하기 때문에 보안 문제가 더 심각하다고 알려져 있습니다. 한 보안 관련 조사에서는 모바일 기기의 약 68%가 악성 코드와 보안 위협에 노출된 것으로 발표했습니다. 특히 핀테크 시장이 커지면서 모바일 결제, 인터넷 은행 등의 보안 이슈는 점점 늘어날 것으로 보입니다.  

더보기

사용자 스토리 워크샵 사례 연구 - 개발 프로세스와 연계 편

사 용자 스토리가 필요한 이유는 개발자가 어떤 소프트웨어를 왜 개발해야 하는지 알기 위해서이다. 사용자 스토리를 통해 개발을 잘 하는 것이 근본적인 목표이기 때문에 사용자 스토리 워크샵을 마치고 개발과 어떻게 연계할 것인지 잘 정리하는 것이 매우 중요하다. 이번 회에서는 사용자 스토리와 개발을 연계하는 방법에 대해 살펴보기로 한다.

사례 연구 전 확인 사항

사용자 스토리 워크샵의 오해

가 끔 사용자 스토리 워크샵이 애자일 기반의 개발 프로세스로 오해하는 사람들이 있다. 사용자 스토리 워크샵이 애자일 기반의 개발을 위한 프로세스인 것은 맞지만 개발 프로세스 자체는 아니다. 소프트웨어를 사용자의 의도에 맞게 개발하기 위한 준비 작업으로 봐야 한다. 기존 SI에서는 요구사항 분석이 개발 프로세스에 포함되어 있었다. 그러다 보니, 요구사항이 바뀔 경우 개발 프로세스가 흔들리는 문제가 많이 발생했다. 사용자 스토리 워크샵은 이러한 문제를 해결하기 위해 개발 프로세스에서 요구사항 정의 부분을 분리했다(그림1). 

<그림1>

더보기

사용자 스토리 워크샵 사례 연구

이번 사례 연구는 솔루션을 개발하는 중견 기업을 대상으로 한다.

A기업은 사용자 스토리 작성을 자체적으로 진행하였으나 회사 내에서도 만족스럽지 못한 결과를 나타냈다. 사용자 스토리 단위로 도출하는 것도 어려웠고 사용자 스토리에서 사용하는 용어 자체도 모호한 말이 많아 이해하기가 어려웠다. 결국, A기업의 경영진은 해외의 애자일 전문 기업에게 요청하여 사용자 스토리 워크샵에 대한 교육을 실시하였다. 교육에서 사용된 프로젝트는 A기업에서 만들고자 하는 솔루션의 일부를 발췌하였고, 영어 사용이 어려워 동시 통역이 가능한 인력을 함께 투입하였다.

사용자 스토리 워크샵의 참여도 향상

[현상]

교육 프로젝트에 참여하는 개발자들은 대부분 영어를 하지 못하는 경우가 많았다. 동시 통역이 가능한 인력이 있었지만 짧은 시간은 많은 커뮤니케이션이 오가는 미팅에서는 동시 통역 시간이 부족했다. 교육 초기에는 많은 사람들의 참여도가 저조했고 교육 분위기는 침체되어 있었기 때문에 본 목적인 사용자 스토리 정의는 불가능해 보였다.

[해결]

강사로 참여한 해외 기업의 애자일 강사는 복잡한 기술 용어나 설명보다는 평상시에 사용하는 간단한 단어로 대화를 유도하였다. 이러한 대화 방식은 개발자들의 참여율을 높일 수 있었고 짧은 미팅 시간에도 많은 대화가 오갈 수 있었다. 또한, 강사는 화이트 보드와 포스트잍에 그림이나 쉬운 단어를 사용해 부족한 대화를 보충하였다.

[결과]

애자일은 구성원들의 참여가 매우 중요한 부분이다. 만약, 강사가 동시 통역을 통해 내용을 전달했다면 딱딱한 원어민 기술 교육과 다를 바 없었을 것이다. 하지만, 강사와 개발자는 충분한 대화를 할 수 있었고, 부족한 부분은 화이트 보드와 포스트잍으로 그림을 그려 보충했다. 여기서 중요한 점은, 강사는 프로젝트에 대한 이해도가 높지 못하기 때문에 개발자나 사용자와 직접적인 대화를 통해 많은 정보를 얻어낼 수 있었고 결국 사용자 스토리까지 도출할 수 있었다. 개발자들은 교육 후에 설명이 아닌 커뮤니케이션이 필요했기 때문에 어렵지 않게 참여할 수 있었다고 말했다.

사용자 스토리 정의

[현상]

A기업의 개발자들은 사용자 스토리를 작성한 경험이 거의 없었기 때문에 사용자 스토리의 각 항목에 어떤 내용을 작성해야 할지 난감해 했다. 강사도 사용자 스토리에 대한 정보가 전혀 없는 상태였기 때문에 사용자 스토리 카드를 작성하는데 어려움을 겪고 있었다.

[해결]

강사는 사용자 스토리 작성을 위해 작성해야 할 항목을 먼저 보여주지 않았다. 강사와 개발자들은 사용자 스토리에 대한 주요 흐름에 대해서만 커뮤니케이션을 진행하였고, 중요 단어나 토픽이 나올 때는 포스트잍에 작성하여 화이트 보드에 붙여 나갔다. 하나의 사용자 스토리에 대한 커뮤니케이션이 끝나자 강사는 붙여 놓은 포스트잍을 개발자들과 함께 다시 정리해 나갔다. 토론해야 할 범위가 포스트잍에 적힌 것들로 줄어들면서 개발자들은 토론에 참여하기가 쉬워졌다. 결국, 포스트잍은 어느 정도 정리가 되었고, 강사는 포스트잍 앞에 사용자 스토리에서 필요한 항목 이름을 쓰기 시작했다. 중구난방으로 붙었던 포스트잍이 사용자 스토리로 바뀌는 순간이었다.

[결론]

처음부터 사용자 스토리를 작성하자는 목표였다면 작성하기가 쉽지 않았을 것이다. 이전에도 직급이 높거나 경험이 많은 일부 개발자에 의해 작성되는 경우가 많았기 때문이다. 작성해야 하는 항목에 맞춰 작성할 것을 찾아내는 것이 아니고, 사용자 스토리 자체에서 중요한 부분을 발췌 하여 항목을 붙이는 방법을 사용한 것이다. 이런 방법은 위에서 보았던 복잡성, 완벽성, 변동성을 미리 알 수 없기 때문에 바로 중요 단어나 토픽을 찾아내기가 쉽지 않다. 전반적인 사용자 스토리 토론 후에 중요 부분을 찾아내는 것도 방법일 수 있다.

더보기

사용자 스토리 구성 항목

사용자 스토리에 작성해야 하는 항목은 사용자와 개발팀 간 상의하면서 정하면 되지만, 일반적으로 그림3과 같은 항목을 가지면 좋다. 그림3을 살펴보면, 사용자 스토리에 대한 설명을 설명(Description)에, 누가 사용하는지 역할(Role), 사용자 스토리의 목표와 가치를 목표(Goal)과 가치(Value)에 작성한다. 사용자 스토리를 테스트 하기 위해 가정(Assumptions)과 추정(Estimate)을 작성하여 테스트 결과를 예측한다.

<그림3> 사용자 스토리 작성 항목의 예

출처: Thoughtworks

그림3 외에 사용자 스토리는 아래 세가지 항목을 작성하는 경우가 많은데 사용자 스토리의 난이도와 완성도를 미리 파악하여 개발자에게 가이드 하기 위해서이다. 이 외에도 위험도나 예상되는 이슈를 작성해도 된다.

더보기

사용자 스토리 작성

개발 프로젝트를 진행하기 위해 사용자 스토리를 중심으로 단위가 구성된다. 한 개의 사용자 스토리가 되고, 5 ~ 10개의 사용자 스토리가 구성되면 이터레이션(Iteration) 단위가 되고, 30 ~ 50개의 사용자 스토리가 구성되면 릴리이즈(Release) 단위가 구성된다.

<그림2> 사용자 스토리의 활용

사용자 스토리 정의

사용자 스토리 작성을 위해서는 기억해야 할 사항이 몇 가지 있다. 사용자 스토리는 사용자와 개발팀 간 대화가 원활하게 하는 것에 첫 번째 목표가 있기 때문에 하나의 사용자 스토리는 아래와 같은 가이드를 지키는 것이 좋다.

시작과 끝이 있는 하나의 일 단위여야 함

하나의 이터레이션으로 완성 가능해야 함

진행상황이 추적 가능해야 함

개발자 관점이 아닌 사용자 관점이어야 함

추정할 수 있어야 하고, 테스트할 수 있어야 함

인덱스를 매길 수 있어야 하고, 스토리 리스트를 만들 수 있어야 함

프로덕트 백로그로 만들 수 있어야 함

더보기

SP품질인증기준분석종합

SP 품질인증 기준을 적용한 프로세스 수준 점수는 69.5점으로 프로젝트 관리, 개발, 지원의 3개 영역 각각에 대한 영역별 프로세스 수준점수는 75.2점, 68.9점, 64.7점으로 조사되었다. 

 

이번 SW공학수준에서 CMMI를 기준으로 조사된 프로세스 수준 점수와 SP 품질인증 기준으로 산 정된 점수와 비교하면 그 결과는 다음과 같다.

더보기

소프트웨어 프로세스 품질인증 평가항목

더보기

소프트웨어 프로세스 품질인증 기준구성

이번 수준조사를 통해 수집된 데이터를 기반으로 SP 품질인증 2등급에 포함되는 3개 영역과 해당 영역에 대한 평가항목과 세부평가항목은 다음의 표와 같다. 이번 조사에서는 기존 조사 내용과의 중복성과 설문 추가에 대한 어려움으로 인하여 소프트웨어 프로세스 품질인증 기준에 대한 별 도의 추가 조사가 적용되지 않았기 때문에 소프트웨어 프로세스 품질인증 기준에 해당되는 조 사 항목을 매핑하고 이를 기준으로 수집된 데이터를 통해 분석이 이루어졌다. 또한 모든 SP 평가항목의 세부 평가 항목에 대한 1:1 매핑은 불가능했다.

본 조사는 SP 품질인증 기준에 대한 프로세스 수준의 재분석이 아닌 소프트웨어 프로세스 품 질인증 기준 중심으로 프로세스 수준 분석 시 기존 결과와 어떤 차이가 발생하는지를 파악하 고, 향후 SP 모델 기반의 데이터 조사를 위한 데이터 확보 차원에서 수행되었다.

더보기

제65회 SW공학 Technical 세미나 안내 7/28(목)

더보기

소프트웨어 프로세스(Software Process, SP) 모델의 정의

소프트웨어 프로세스(이하 SP) 품질인증 제도는 소프트웨어 및 정보시스템을 개발 관리하는 국내 소프트웨어 기업 및 개발조직의 소프트웨어 프로세스 품질 향상과 신뢰성 확보를 목적으로 소프트 웨어 프로세스 품질역량 수준을 심사하여 등급을 판정하는 제도이다. 

SP 품질인증은 소프트웨어 프로세스 품질인증 기준에 대한 만족여부를 심사를 통해 판단하여 부여 된다. SP 품질인증 기준은 5개 영역, 17개 평가항목, 76개 세부평가 항목으로 구성되었다. 5개의 영역을 구체적으로 살펴보면 프로젝트 관리 영역, 개발 영역, 지원영역, 조직관리 영역 및 프로세스 개선 영역으로 구성되어 있다. 

프로젝트 관리 영역은 다시 프로젝트 계획, 프로젝트 통제, 협력업체 관리와 같은 3개의 평가항목 으로, 개발영역은 요구사항 관리, 분석, 설계, 구현 및 테스트가 포함되는 5개 평가항목으로, 지원 영역은 품질보증, 형상관리, 측정 및 분석과 같은 3개의 평가항목으로 구성되어 있으며 이들 3개의 영역이 2등급 영역이다. 3등급 영역인 조직 프로세스 관리는 기반구조 관리, 구성원 교육을 포함하는 2개의 평가항목으로 구성되고, 프로세스 개선 영역은 정량적 프로세스 관리, 문제해 결, 프로세스 개선 관리를 포함한 3개의 평가항목으로 구성되었다. 

기존 SW공학수준 조사에서 프로세스 수준 분석은 CMMI 만을 기준으로 이루어졌기 때문에 SP 품 질인증에 대한 관심도 증가라는 상황과 맞물려 소프트웨어 프로세스 품질인증 기준에 따른 프로세 스 수준 분석의 필요성이 제기되었으며, 소프트웨어 프로세스 품질인증 기준에 따른 프로세스 수준 에 대한 데이터 확보가 필요하게 되었다. 

이러한 필요성에 대응하고자 SP 품질인증 기준의 분석이 수행되었으며, SP 기준의 프로세스 수준 분석은 CMMI Level 3 수준에 맞는 2등급에 포함되는 3개 영역에 대하여 42개 세부평가항목을 기준으로 11개 평가항목에 대한 점수를 산정하여 분석하였다. 

 더보기

SW공학도구 분석

이번 조사에 참여한 조직의 SW공학도구에 대한 도입연수 비율을 살펴보면 다음의 표와 같다. 
 

 

SW공학도구별로 업무 기여도 정도를 살펴보면, 다음의 표와 같다.

 더보기

SW공학 요소기술 분석

SW공학 요소기술 및 필요수준 수요조사의 대상은 아래의 그림과 같이 총 9개 영역(프로젝트 관리, 프로세스 관리, 품질 관리, 형상 관리, 측정, 요구사항 관리, 분석설계, 구현, 테스트)을 대상으로 각 요소기술 영역별로 현재 보유정도와 향후 필요정도를 조사하였다. 

프로젝트 관리, 요구사항 관리, 프로세스 관리 영역이 현재 보유수준과 향후 수요수준의 차이 가 상대적으로 큰 것으로 나타났다. 

 

1.1 프로젝트관리 기술수요 현황

 

 

프로젝트 관리영역의 요소기술 별 현장의 수요는 아래의 그림과 같다. 아래의 그림에서 살펴보면, 현재 보유정도와 향후 필요정도의 차이가 가장 많이 나는 부분은 일정관리와 자원관리로 나타났다.

 

 

 더보기

SW공학수준과 경영성과

SW공학수준 등급(Abent, Average, Advanced)별로 경영성과를 분류하여 활동성 및 성장성 지표 와 수익성 지표를 살펴보면, 다음의 표와 같다. 

SW공학수준이 높을수록 활동성 및 성장성 지표를 구성하는 매출액 증가액, 영업이익 증가율, 당기 순이익 증가율 모두 높아지는 결과를 확인할 수 있으며, 수익성 지표를 구성하는 매출액 영업이익 율, 매출액 순이익율, 총자산 순이익율 또한 모두 높아지는 결과를 확인할 수 있다.

SW공학수준이 Absent 수준과 Average 수준의 경우 전년도 대비 활동성 및 성장성 지표와 수익성 지표 대부분이 감소하는 경향을 보이고 있으나, Advanced 수준의 경우에는 활동성 및 성장성 지표 와 수익성 지표 모두 전년도 대비 증가하는 긍정적인 결과를 보여주고 있어 높은 SW공학수준 을 보유할수록 좋은 경영성과를 낼 가능성이 높아진다는 상관 관계를 설명해주고 있다.

더보기

경영성과

기업의 경영성과를 파악하여 SW공학수준, 성과, 기업규모, SW개발유형과의 비교를 통해 기업의 경영성과와의 상호 연관관계를 본 분석을 통해 파악하고자 한다. 

분석결과, SW공학수준이 높을수록 경영성과가 상대적으로 높게 나타났으며, 납기와 비용을 준수한 프로젝트가 속한 조직의 경영성과가 그렇지 못한 조직에 비해 상대적으로 높게 나타났다. 

특히 대기업과 중소기업 간의 경영성과 차이가 심각해 중소기업의 경영성과 개선을 위한 노력이 필요함을 확인할 수 있다. 

경영성과 분석을 위해 아래의 표와 같은 지표 및 측정공식을 통해 분석을 수행했다. 

 

경영성과 데이터는 설문조사에 참여한 기업 중 올해 경영공시를 한 기업을 대상으로 추출하였으며, 경영성과 분석 시점이 최종감사 보고서가 공시되지 않은 시점이기 때문에 3분기 보고서를 기준으로 추출하였다. 이번 경영성과 분석은 설문조사에 참여한 기업 중 경영성과 데이터 추출이 가능한 54 개 기업을 대상으로 이루어졌으며, 경영성과 공시정보는 금융감독원의 전자공시시스템 (http://dart.fss.or.kr)을 통해서 확인했다

 더보기

머신 러닝의 발전 방향과 소프트웨어 시장에 미치는 영향

AI는 사람과 똑 같은 사고를 갖게 하는데 목적이 있고 최근에는 사물인터넷(Internet of Things), 클라우드 컴퓨팅(Cloud Computing), 빅데이터(Big Data), 모바일(Mobile) 등과 결합되면서 상상 속에 있던 새로운 비즈니스가 만들어지고 있다. AI는 다양한 분야가 연구되고 있지만 그 중에서도 머신 러닝(Machine Learning)의 관심이 급격히 증가하고 있다. 인간을 이긴 구글의 알파고와 IBM의 왓슨처럼 머신 러닝을 기본으로 한 AI가 이제 영화 속이 아닌 현실에서 나타나고 있고, 시간이 갈수록 머신 러닝의 학습 속도는 점점 빨라져 인간의 뇌와 유사해지고 있다. 이번 회는 머신 러닝이 소프트웨어 활용에 어떤 영향을 미치는지 살펴보도록 한다.

머신 러닝의 동작

머신 러닝은 훈련 데이터(Training Data)를 통해 학습된 속성을 기반으로 결과를 예측하는데 목적을 두고 있기 때문에 데이터 마이닝(Data Mining)을 통해 미처 몰랐던 속성을 발견하는 것에 관심을 보인다. 일반적인 소프트웨어는 개발자가 모든 알고리즘, 로직, 명령어 등에서 필요한 것을 선택해 만들어낸다. 하지만, 머신 러닝의 경우는 자율적인 학습으로 최적의 결과를 만들어낸다.

그림1은 머신 러닝이 동작하는 방법을 간단히 나타내고 있다. 기존에도 프로그램에 의해 입력 받은 데이터를 가공하여 원하는 결과를 나타낼 수 있다. 수학에서 미지수 X의 값을 찾기 위해 많은 수식과 공식을 사용하는 것과 마찬가지다. 하지만, 머신 러닝의 경우는 정해진 수식이나 공식 없이 계속 학습을 하면서 결과를 찾아낸다는 점이 다르다. 개발자는 소프트웨어가 결과를 제시하는 방법을 만들어야 하는 것이 아니라 데이터를 어떻게 받아들이고 결과를 어떻게 보여줄 것인지에 대한 고민이 더 많아야 한다. 아래는 머신 러닝의 수행 단계를 나타낸다.

1. 자료 수집: 엑셀, DB 등의 자료, 텍스트 파일 등에서 학습을 위한 자료를 수집
2. 자료 준비: 데이터의 품질을 높이기 위해 누락, 예외 사항 처리 등을 예비 분석
3. 모델 훈련: 적절한 알고리즘으로 훈련 모델을 개발하고 시험 데이터로 모델을 테스트
4. 모델 평가: 모델의 정확성 여부를 시험하기 위해 평가한 후 정밀도를 결정
5. 성능 개량: 모델의 효율성 증대를 위해 더 많은 변수를 포함하여 모델의 성능을 향상

더보기

제조업의 소프트웨어 개발 프로세스 개선 활동

제조업에서도 소프트웨어의 필요성은 매우 높다. 더구나 첨단 기술이 점점 늘어나면서 제조 라인의 자동화는 더 체계적인고 효율적인 관리가 필요하기 때문에 소프트웨어의 기능은 더 많아지고 관리되는 데이터도 늘어나는 추세다. 이번 회에서는 제조업에서 사용되는 소프트웨어 개발 프로세스를 올바르게 적용해서 성공할 수 있는 방법이 무엇인지에 대해 살펴보기로 한다. ㈜현대파워텍의 이윤희 팀장을 만나 자세한 사항을 들어본다.


Q: 사례를 살펴보기 전에 제조업의 소프트웨어 개발에 프로세스가 필요한 이유에 대해 간략히 설명해 주시죠.

소프트웨어를 개발하는데 프로세스가 필요한 것은 당연한 얘기일 겁니다. 하지만, 제조업의 소프트웨어는 특히 더 필요합니다. 제조업에는 많은 설비, 장비, 그리고 데이터가 있기 때문에 관리되어야 하는 요소나 사람이 직접 보지 못하는 부분도 상당히 많습니다. 소프트웨어가 반드시 필요한 이유이기도 하고 체계적인 소프트웨어 개발이 필요한 이유이기도 합니다. 그림1처럼 제조업 R&D 로드맵의 핵심이 소프트웨어가 없어서는 되지 않는 구조입니다. 제조업의 고도화를 위해서는 어느 제조업이든 반드시 소프트웨어가 필요하죠.

더보기

사용자 스토리 워크샵 사례 연구 - 사용자스토리 정의 편

SI 프로젝트에서도 사용자(고객)가 수행하는 비즈니스를 흐름도로 정의하는 프로세스가 있다. 비즈니스 흐름도, 업무 흐름도 등 다양한 이름으로 정의되지만 사용자가 해야 하는 일을 순서대로 보여준다. 비즈니스 흐름은 사용자가 어떤 비즈니스를 가지는지를 보여주기 때문에 매우 중요한 프로세스이지만 개발 프로젝트에서는 많은 시간을 할애하지 않는 것이 일반적이다. 이번 회에서는 사용자 스토리 워크샵의 사용자 스토리 정의에 대해 살펴보기로 한다. 명확한 사용자 스토리 정의를 통해 애자일 기반 프로젝트의 성공률이 높아지기를 기대한다.


사례 연구 전 확인 사항

사용자 스토리의 필요성

사용자 스토리는 사용자 스토리 워크샵의 핵심 작업 중의 하나다. 사용자가 어떠한 흐름으로 비즈니스를 진행하는지 보여주기 때문이다. SI 프로젝트에도 이와 유사한 비즈니스 흐름도나 업무 흐름도에서 사용자의 업무 흐름을 보여준다. 요구사항을 적용하기 전에는 (As-Is)업무 흐름도, 요구사항을 적용한 후에는 (To-Be)업무 흐름도로 표현된다. 그런데, 이 문서들은 사용자들이 알아볼 수 있는 문서는 아니었다. As-Is는 현재 하고 있는 업무를 나타내는 것이고, To-Be는 개발팀에서 작성하다 보니 시스템 중심으로 작성이 되어 있다. 시스템이 만들어지기 한참 전이기 때문에 사용자가 알아보기 어려운 것이 당연하였다.

사용자 스토리 워크샵의 주요 목적은 사용자와 개발팀 간의 커뮤니케이션이다. 서로 대화가 되기 위해서는 사용자의 업무 흐름이 사용자가 알아보기 쉽게 작성되어야 한다. 사용자 스토리를 만들기 위해 다양한 프로세스가 선행된다.

더보기

개발자 입장에서 바라보는 클라우드 서비스의 발전

클라우드로 인한 패러다임의 변화 

클라우드로 인해 어플리케이션과 서비스 개발에 대한 새로운 패러다임이 나타나고 있다. 온-프레미스(On-premise; 그림5) 환경에서는 물리적 서버 준비, 운영체제 설치, 서비스 배포 등에 수많은 시간이 걸렸지만, 클라우드를 활용하면서 단시간에 원하는 자원을 준비하고 서비스를 배포할 수 있게 되었고 확장과 가용성을 가질 수 있게 되었다.

① 컨테이너를 통한 서비스 배포 시간의 단축

다양한 서비스를 실행하는데 운영체제와 플랫폼의 제한 사항은 그대로지만, 자원을 효율적으로 사용하고 빠르게 서비스를 배포하고자컨테이너를 활용한다. 컨테이너는 기존 서버를 통해 2개 이상의 어플리케이션을 배포하는 부담을 줄이기 위해 서비스를 실행하는데 필요한 프레임워크, 라이브러리, 소스 코드를 별도의 이미지로 만들어 실행할 수 있도록 만든 것이다. 도커(Docker)가 컨테이너 서비스를 주도하고 있다.

개발자는 패키징 된 서비스를 단일 컨테이너에서 수백 개의 가상 서버에서 실행되는 수천 개의 컨테이너까지 쉽게 확장할 수 있다. 컨테이너 서비스를 통해 서비스를 원할 때마다 언제든지 수 초 내에 배포할 수 있다.

② 서버 없는 클라우드 함수의 등장

AWS(Amazon Web Service)에서 제안된 서버 없는 클라우드는 개발자가 간단히 파이썬, 자바로 작성하여 특정한 클라우드 서비스에반응하는 함수로서 실행할 수 있다. 서버 없는 클라우드를 활용하면, 모든 유형의 어플리케이션이나 백엔드 서비스를 별도 서버 없이실행할 수 있다. 소스코드를 업로드 하면 높은 가용성으로 실행하고, 가용성과 확장성 등 필요한 모든 것을 자동으로 고려해주기 때문이다.

AWS에서 제공하는 AWS Lambda는 기존 가상 서버, 컨테이너 서비스와 함께 서버 없이 확장성을 고민하지 않고 바로 원하는 어플리케이션을 빠르게 수행할 수 있다. 최근에는 이를 바로 개발 현장에 접목할 수 있는 Serverless Framework라는 오픈 소스 개발 플랫폼이 나와서 주목을 받고 있기도 하다.

클라우드 서비스 브로커(CSB; Cloud Services Brokerage) 

IaaS가 활성화 되면서 클라우드의 장점을 알고 있는 업체들은 하나의 클라우드 벤더만 사용하지 않고 필요성에 따라 다양한 벤더를 사용하게 되었다. 이러한 다중 클라우드 사용은 다양한 서비스를 한 곳에서 사용할 수 있다는 장점도 있지만 클라우드 자원 관리가 복잡해지는 단점도 있다. 이런 불편함을 덜기 위해 CSB가 나타났다(그림6).

<그림6> CSB 서비스의 예

 

출처 : www.liaison.com

더보기