소프트웨어공학 포털 블로그

2016년 7월 26일 화요일

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

영상출처: 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>

2016년 7월 25일 월요일

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

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

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

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

[현상]

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

[해결]

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

[결과]

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

사용자 스토리 정의

[현상]

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

[해결]

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

[결론]

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

사용자 스토리 구성 항목

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

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

출처: Thoughtworks

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

사용자 스토리 작성

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

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

사용자 스토리 정의

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

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

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

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

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

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

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

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