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>
피드 구독하기:
글
(
Atom
)