SW프로세스 개선을 위한 다른 모델들을 살펴보면 CMMI, SPICE, PRINCE2 등이 있다. 또한 SP인증모델을 기준으로 프로세스 컨설팅을 추진하기도 한다. 국내에서 가장 활발히 컨설팅을 추진하는 모델은 CMMI로 대기업을 중심으로 컨설팅이 추진･운영되고 있다.
SW프로세스개선 컨설팅의 경우 도입 시 많은 이슈와 충돌이 발생하기도 하지만 장기적 이행관점에서 봤을 때 해당 조직의 발전가능성이 가장 높다. 또한, 주먹구구식 개발을 하던 SW기업들이 논리적이고 구조적인 프로세스를 통해 보다 체계적인 개발을 할 수 있게 만들어 주어 조직의 안정성과발전 가능성을 확보할 수 있는 기반이 되는 것이다. SW프로세스와 관련된 모델들은 다양하지만다른 모델 또는 표준간의 관계를 통해 유기적으로 연관관계를 맺고 있으며 다양하게 확장되고 있다.
[ SW프로세스 표준간 관계도 ]
프로젝트 관점에서의 프로세스 컨설팅은 프로젝트를 진행할 때 필요한 방법론을 정의하고 그에 따른 WBS를 작성하고 관리하게 된다. 또한 방법론에서 정의한 각 단계(요구사항, 분석, 설계, 구현,시험, 배포)에 대한 가이드라인을 제공하고 작성된 산출물에 대해 리뷰와 인스펙션을 주관하며 개발자와 관리자간의 조화로운 커뮤니케이션을 할 수 있도록 지원하기도 한다. 프로젝트의 이해당사자들이 합리적으로 일할 수 있는 기반을 제공하는 것이 바로 프로젝트 관점에서의 프로세스 컨설팅이다.
CMMI(Capability Maturity Model Integration)란 미국방성의 요청에 의해 카네기멜론 대학의 SW공학연구소가 개발한 성숙도 평가모델을 기준으로 여러 CMM모델을 포함한 통합모델이다. 국제적 권위를 가진 인증을 통해 회사의 프로세스 및 제품에 대한 신뢰성을 보장하고 CMMI 심사를통해 부족한 프로세스에 대해 외부검토를 수행하고 개선사항을 도출할 수 있는 모델이다.
SW프로세스란 SW를 개발하기 위해 수행하는 일련의 활동을 의미한다. SW를 만들기 위해 필요한 활동들을 명확히 하고 품질확보와 납기를 지키기 위한 방법으로서 SW프로세스를 정립해야 한다.
효과적인 SW프로세스를 만들기 위해서는 프로세스를 정의하고, 필요한 도구를 결정하여 프로세스 를 실행해야 한다. 그리고 지속적인 개선을 통해 SW기술변화를 프로세스에 반영하고 수행자들에게 책임과 교육을 추진하여 결과를 피드백 하는 것이 해당 조직의 SW프로세스를 최적화하는 것이다. SW프로세스는 일반적으로 요구사항 수집 및 분석, 설계, 구현, 시험의 단계를 가지고 조직의 특성 에 따라 활동이 정의된다.
[ 믿을 수 있는 프로세스를 구축하는 방법 ]
SW프로세스의 구조적 특징, 특성, 역할들로 이루어진 집합된 형태를 SW생명주기라고 부른다. SW생명주기는 SW개발 단계에 SW개발전략이나 전사적 정책을 통합시킨 것으로 개발방법, 개발환경에 대한 도구, SW 개발의 시작부터 끝까지 효과적으로 관리하기 위해 만들어진다.
SW프로세스 모델의 유형 결정요소는 문제유형, 관점, 개발 방침에 따라 결정되며, 일반적으로 SW개발 기본 프로세스 모델(생명주기 모델, ISO 12207)을 많이 참조하고 있다.
Dr. Carol Woody
CERT 부문 사이버 보안 엔지니어링 팀 관리자
복잡한 네트워크 시스템이나 시스템 오브 시스템의 보안 소프트웨어를 정의, 취득, 개발 및 관리하고 측정, 유지하는 작업 연구
Rick Kazman
하와이 대학 교수
소프트웨어 아키텍처, 소프트웨어 공학 경제학, 소프트웨어 시각화 연구
시스템에 구현된 아키텍처 설계 상의 약점은 다른 종류의 취약성에 비해 시간이 지나가면 갈수록 그 문제를 수정하기가 매우 어렵기 때문에 아키텍처 취약성에 좀 더 관심을 가져야 합니다. 아키텍처 설계 약점을 초기 단계에서 발견하여 수정할 수 있다면, 라이프사이클 기간 동안 더 편하게 시스템을 사용할 수 있습니다.
아키텍처에는 특정 패턴이 있는데 이 패턴은 필요한 요구사항에 따라 설계됩니다. 여러 종류의 아키텍처 패턴이 각각 보안에 어떤 영향을 주는지 이해하는 것이 매우 중요한데, 중요성을 아키텍처 커뮤니티나 설계 및 구현 커뮤니티에서 충분히 인식하지 못하고 있습니다. 단순한 패턴 상의 문제가 아니라 개발자들의 잘못된 인식 때문에 쓸모 있는 패턴이 문제를 일으키게 됩니다. 반드시 사용해야 하는 패턴을 사용하지 않는 개발자도 있고 사용하지 않았으면서 사용했다고 착각하는 개발자도 있습니다. 이런 이유로 아키텍처 패턴이 취약성의 주된 원인이 될 수 있습니다.
라이프사이클 초기의 취약점을 정확히 진단할 수 있는 도구가 없습니다. 초기 단계에는 각 시스템 조각이 어떻게 연결되고 설계되었는지 만 파악할 수 있을 뿐입니다. 설계 초기 단계에는 앞으로 문제가 될 소지가 있는 부분을 정확히 집어낼 수는 없지만, 관심을 두고 지켜봐야 하는 영역을 점차 좁혀 나가면서 문제를 찾아 내야만 노력과 시간을 줄일 수 있습니다.
시스템 진단 도구와 관련하여 Drexel 대학과 공동 연구를 진행하면서 좀 더 정확도가 높은 스트럭쳐를 얻어낼 수 있었습니다. 이 공동 작업으로 아키텍처 분석을 수행하면서 수많은 메소드를 개발했습니다. 잠재적인 리스크를 찾아내는 효과적인 방법을 개발하려 했지만, 발견한 리스크들의 범위가 너무나 넓었습니다. 좀 더 범위를 좁혀서 아키텍처 약점이나 오류를 찾아낼 수 있는 기능을 개발하고자 했습니다.
지난 5-6년 간 개발한 것은 기존 코드 베이스의 리버스 엔지니어링을 가능하게 하는 설계 재현(Design Representation)이었고 관련 도구도 개발했습니다. 아키텍처 정보, 설계 정보를 추출하고, 의미 있는 방식으로 정보를 조작한 다음 조작된 형태의 정보를 분석하여 아키텍처 오류를 찾아내는 것입니다. 과거에는 모든 리버스 엔지니어링이 전적으로 수작업을 통해 이루어졌기 때문에 매우 노동집약적이었지만, 지금은 이 모든 과정이 자동화 되어서 투입되는 비용과 시간을 크게 줄었습니다.
코드를 리버스 엔지니어링하기 위해 현재 Understand라는 상용 리버스 엔지니어링 툴을 주로 사용하고 있습니다. 엔터프라이즈 아키텍트 로부터 정보를 받아 들이면서 파일 간의 의존도를 발견할 수 있었고, A 파일, B 파일 그리고 두 파일 사이의 관계라는 3중 구조를 생각할 수 있게 되었습니다. 이 3중 구조를 바탕으로 거대한 매트릭스를 만들어 냈습니다. 바로 설계 스트럭처 매트릭스(DSM)입니다.
이 설계 스트럭처 매트릭스(DSM)는 분석과 조작이 가능합니다. 개발한 알고리즘을 통해 설계 규칙 계층 알고리즘이라 부르는 클러스터를 만듭니다. 설계 규칙은 시스템의 중요한 인터페이스나 중요한 클래스와 비슷합니다. 예를 들면, 시스템에서 Abstract Factory를 사용하는 경우, 그 abstraction에 의존하는 많은 다른 파일이 생성됩니다. Abstract Factory 인터페이스를 구현하고, 인터페이스에서 상속 받고, 인터페이스에 의존하고, 인터페이스를 사용하고 종합하는 클래스가 생깁니다. 이 abstract factory 재현은 설계 규칙이고 많은 파일이 그 설계 규칙에 의존하게 됩니다. 의존 관계에 따라 아키텍처를 클러스터로 묶어야 하는데, 최상위에는 시스템에서 가장 중요한 설계 규칙인 선두 클래스가 위치합니다.
시스템의 다른 많은 파일들이 의존하는 파일이나 클래스가 바로 선두 클래스인데요. 파일들을 묶어 계층으로 만들면, 최상위 파일에 의존하는 파일들이 하위 계층이 됩니다. 이런 식으로 계층 구조(Hierarchy)가 이루어집니다. 매우 간단한 예로 의존 관계 주기도 찾아낼 수 있습니다. A 파일이 B 파일을 호출하고, B 파일이 C 파일을 호출하고, C 파일이 A 파일을 호출하는 경우는 100% 잘못된 프로그래밍입니다. 그 이유는 세 파일 중 하나를 변경했을 때 일어날 수 있는 파급 효과를 예측할 수 없기 때문입니다. 하나의 파일을 수정했을 때 발생할 미묘한 변화를 알아내는 것도 쉽지 않습니다. 프로그래머는 수백만 줄의 코드를 확인해야 하기 때문에 이러한 미묘한 문제를 쉽게 찾아낼 수 없습니다.
글로벌 솔루션 개발 회사의 특징을 살펴보는 마지막으로 애플(Apple)을 살펴보도록 한다. 애플은 미국 뿐 만 아니라 전세계적에서 가장 잘 알려진 회사 중 하나로, 개인용 컴퓨터를 생산하던 전자제품 회사였다. 이후, 아이팟을 비롯해서 아이폰, 아이패드 등을 개발하여 독자적인 스마트 디바이스 군을 만들었고, 디바이스에서 사용되는 솔루션을 만들면서 소프트웨어 회사로도 최고로 인정받고 있다. 이번 회에서는 애플의 추구하는 사업 특징과 그에 따른 솔루션 관점의 의미를 살펴보도록 한다. 획기적인 기술과 기획력으로도 어려움을 겪는 다른 솔루션 개발 회사와 비교해보며 솔루션 개발에 필요한 인사이트를 찾기를 기대한다.
애플의 사업 분야 변화
애플은 글로벌 혁신기업으로 잘 알려져 있다. 기존에 경직된 생각에서 벗어나 일반 사람들이 생각하지 못하는 부분을 리딩하고 있다. 애플의 시작은 애플과 매킨토시라는 이라는 PC(개인용 컴퓨터)에서 시작했다. 90년대 당시에는 PC(개인용 컴퓨터) 시장의 벽이 낮지 않았기 때문에 매킨토시는 디자인에 특화되었다는 특징으로 사용자들에게 접근하였다. 이후 사용성에 대한 고민이 많이 반영되면서 아이맥, 아이팟을 출시하였고 제품의 디자인을 특성화 시킨 디바이스들을 만들기 시작했다. 이후, 아이팟에 휴대폰 기능을 추가한 아이폰, 매킨토시나 아이맥에서 사용하던 것에 휴대성을 보완한 아이패드가 나왔고 현재는 스마트 디바이스의 생산 라인업을 갖춘 상태다.
애플의 사업 전략 중 가장 큰 특징은 일반적인 PC(개인용 컴퓨터)로 알려진 윈도우 기반의 PC가 아닌 독자적인 하드웨어를 생산했다는 점이다. 이 것은 애플이 독자적인 디바이스 생태계 뿐 만 아니라 독자적인 소프트웨어 생태계를 구축할 수 있는 이유이기도 하다. 독자적인 디바이스에는 독자적인 소프트웨어나 컨텐츠를 제공해야 하기 때문이다.
그림1에서 보는 것처럼, 애플의 부흥은 스티브 잡스가 CEO로 취임한 이후부터 이다. 스티브 잡스로 인해 애플의 제품이 구축되고 이 제품들이 전세계 스마트 디바이스 시장을 주도한 것은 의심할 여지가 없이 사실이지만 이 것 외에 또 다른 애플의 전략이 있었다고 볼 수 있다. 초기의 애플은 비전과 조직관리를 스티브 잡스, 개발을 스티브 워즈니악, 마케팅에 마이크 마큘라가 맡아 성장을 이루었다. 이후 80년대 중반 이후, 스티브 잡스가 회사를 나가면서 역할 분담이 깨지게 된다. 그리고, 1997년 스티브 잡스가 다시 돌아오면서 지금의 애플 시대를 맞이하게 된다. 밖으로는 스티브 잡스의 카리스마나 팀쿡의 개발 능력 등이 애플의 성공 요소로 보고 있지만, 안으로는 철저한 역할 분담으로 최적의 판단을 하게 되고, 적절한 시점에 필요한 제품이 나오게 되는 효과를 가져왔다.
소프트웨어 개발 프로젝트가 끝나고 나면 유지보수에 대한 고민이 시작된다. 어디까지 무상으로 해줘야 하는지, 상주 인원은 어느 정도 투입해야 하는지, 문서 작업의 범위는 어디까지 인지 등 많은 항목들을 확인해야 한다. 이와 함께, 완성된 소프트웨어를 운영하기 위해 준비해야 하는 품질 방안 수립에도 많은 시간을 할애한다. 이번 회에서는 소프트웨어 개발 프로젝트 종료 후 운영과 유지보수에 필요한 품질 확보 방안에 대해 로만소프트 이영환 대표를 만나 자세한 사항을 들어본다.
Q: 본격적인 이야기 전에 유지보수 품질 방안에 대해 설명을 부탁 드립니다.
개발자들에게 개발 프로젝트의 종료는 매우 기다려지는 일이지만, 유지보수라는 프로젝트가 다시 기다리고 있죠. 많은 개발자들은 너무 힘들었던 개발 프로젝트 때문에 유지보수 프로젝트는 하지 않으려 하지만 쉽지 않은 것이 사실입니다. 안타까운 얘기이지만, 소프트웨어가 고객들에게 납품될 때는 항상 결함을 안고 있습니다. 소프트웨어 자체의 오류도 있겠지만, 무엇보다 고객이 원하는 요구사항이 잘못 동작하거나 제대로 반영되지 않은 경우도 결함이라고 얘기합니다. 그림1을 보시면, 2000년 전후의 개발과 유지보수 프로젝트의 비율을 나타내고 있는데 유지보수의 비율이 더 높아진 것을 볼 수 있고 지금은 더 줄어드는 추세입니다.
<그림1> 개발과 유지보수 프로젝트의 비율
출처: Roger S. Pressman의 Software Engineering
위 그림이 나타내는 것은, 유지보수의 중요성이 점점 높아진다는 것입니다. 흔히, 유지보수는 만들어진 소프트웨어를 운영하면서 오류가 발생하면 일부 수정해주고 새로운 요구사항을 추가로 개발하는 정도로 이해하는 경우가 많습니다.
