소프트웨어 형상관리 (SCM : Software Configuration Management)

소프트웨어 형상관리 (SCM : Software Configuration Management)

출처 http://cafe.naver.com/tobepartners/299

공교롭게도 공급망관리(Supply Chain Management)와 약어가 같다. ^^
그래서 세미나에 가면, 가끔 헷갈려 하는 사람들을 만난다.
그리고, 우리말로는 "구성관리"로 번역되기도 한다.
또한, "변경관리", "버전관리" 등으로 표현되기도 한다.

정확히 말하자면, 흔히 우리가 말하는 "변경관리", "소스관리", "버전관리",
"빌드관리", "릴리즈 관리", "배포관리" 등은 "형상관리"의 하위 개념이다.

형상관리는 제조분야에서 그 태동이 시작되었다고 들었다.
하나의 제품을 만들기 위해, 소요되는 수많은 부품들의 "상태"를
통제하기 위해 제안되었다고 한다.

소프트웨어 공학에 있어서의 형상관리란, 프로젝트의 개발 시점에서
유지보수가 이루어지는 최종단계까지 발생되는 모든 구성 요소의
변경 이력에 관련한 모든 행위들에 대한 관리를 말한다고들 한다.

여기서 말하는 모든 구성요소란.. 소스 코드 및 각종 문서 (개발/설계
/프로젝트 관리 등)와 사용자 요구사항, 참여 인원, 예산, 일정 등,
프로젝트를 구성하는 말 그대로 모든 "요소"를 일컫는다.

소프트웨어 형상관리를, 굳이 한마디로 유치하게 정의하자면
프로젝트를 구성하는 모든 요소에 대한 "상태"와 "변경","이력"에 대한
통제, 보고, 기록 등의 총체적인 관리활동을 뜻한다.

자.. 여기까지 얘기가 나오면 비판적인 시각이 나타나게 마련이다.
프로젝트의 모든 구성요소에 대한 것을 관리한다고?
누가? 어느 시간에? 세상에.. 그 많은 걸? 너무 비효율적인것 아냐?
나보고 개발하지 말고, 그것만 하라고 해도, 다 하진 못할 텐데...

그렇다... 제대로 하려면 한도 끝도 없는게 세상 일이다..
그리고, 일반 프로젝트에서 무거운 형상관리 프로세스를
적용하는 것은 분명히 비효율적이다. 내가 여기서 강조하고자 하는 점은,
형상관리의 정확한 의미와 그 목적, 그리고 그 사상을 이해하자는 것이다.
그리고 그 개념을 유지하면서, 적절하게 융통성을 가지고, 프로젝트에
형상관리를 도입하자는 것이다.

(글을 쓰면서 곤혹스러운 것은 “「나」를 뭐라고 부를 것이냐?”이다.
 일반적으로 많이 쓰는 [필자]라는 단어는 일제시대의 잔재 같은 느낌이 들고,
 그렇다고 [저]라는 단어를 사용하기에는 문체상 아무래도 어색하다. 그래서
 고심끝에 영어의 [I]를 쓰는 기분으로 [나]를 쓰고, 말투도 간결하게
 사용하기로 했다. 혹시 듣기에 반말 같은 느낌이 들더라도, 진의가 그런 것은
 아니므로 너그럽게 이해해 주시기를 부탁드린다.)

무턱대고, 책에서 말하는 형상관리를 100% 적용하려고 한다면, 제대로
될 리가 없다. 그리고 프로젝트에도 적잖은 부담과 스트레스를 주게된다.
무엇보다도, 실무를 담당하고 있는 해당 프로젝트 팀과의 "불신의 벽"이라는
가장 경계해야 할 문제가 생겨나게 된다.

이런 프로젝트에 들어가서 얘기를 들어보면 대부분의 개발자들은
형상관리 담당자를 "제대로 되지도 않고, 별 필요도 없는 걸로
우리를 귀찮게 하고, 쓸데 없는 일만 만들어 내는 사람"으로 인식한다.
그리고 형상관리 담당자는 개발팀들을 "코딩 외에는 아무것도 모르는
이른바 '개뿔'도 모르는 사람"이라고 욕하는 모습을 쉽게 볼 수 있다.

잠시, 옆길로 빠졌었다. (-_-;)

그럼 형상관리를 하면 어떤 점이 좋아지는가?

이 점을 알아보기 전에, 기존에 형상관리를 제대로 하지 않아 발생하는
문제점들을 간략히 짚어보자.

바이러스나 하드디스크 문제로 그 동안 개발해 둔 소스코드를
날려먹은 적이 있는가?

2사람 이상의 공동개발 환경에서, 동료가 무심코 바꿔버린 코드 한줄
때문에 밤을 지새운 경험이 있는가?

소스코드를 백업해 둔답시고 만들어둔 폴더들의 범람으로, 어느 폴더에
있는 파일이 맞는 것인지 헤매면서 고생한 경험이 있는가?

각종 컴포넌트나 외부객체와의 호환성 문제로 고생한 경험이 있는가?

자주 쓰이게 될 코드를 밤새워 만들어 공동모듈에 삽입하려고 하니,
이름까지 똑 같은 코드가 이미 등록되어 있는, 그런 경험이 있는가?

(주로 소스코드에 초점을 맞추어 예를 들었지만, 위에서도 얘기했듯이
 형상관리는 프로젝트의 모든 요소에 적용된다.)

형상관리를 적용한다고 위의 문제들이 전부 해결되지는 않는다.
적어도 내 경험상으로는 그렇다. 위의 문제들이 해결되려면, 프로젝트의
체계적인 관리와 개발환경에 대한 기술적 성숙, 원할한 의사소통을 위한
프로세스와 시스템 등등에 대한 총체적인 관점의 접근이 필요하다.

하지만, 이런 문제를 해결하기 위해서, 형상관리는 가장 중요한 위치를
차지하고 있음에 틀림없다.

물론 경우에 따라, 즉, 1인 개발환경이라던지, 소규모 프로젝트에서는
형상관리의 중요성이 크게 떨어질 수 있다. 물론 이런 경우에는
"소스관리"정도만 하는 것도 나쁘지 않다라는 게 내 생각이다.

하지만, 항공우주/군사/의료 분야와 같은 프로젝트에서는 얘기가 다르다.
"수천억원의 돈" 또는 "생명"과 관련된 것이 될 때는 분명 관점을 달리
해야 한다. 또한 우리 주위에는 "생명"만큼 중요하지는 않으나, 그 중요성
이 회사의 사활을 좌우하는 "Mission Critical"한 프로젝트가 널리고
널렸다.

자, 그럼 형상관리에 대한 본격적인 내용으로 들어가 보자...

형상관리를 우선 시작하려고 하는 분들께, 반가운 소식 하나 전해드린다.

카네기멜론 대학에서 만들어낸, CMM (역량성숙도모델)에서는
소프트웨어 개발조직이 성장해 나가면서 거쳐야 할 단계(레벨)에 대한
총체적인 시각을 제공해 준다. 레벨1의 조직에서는 제대로 된 연구개발에 대한
체계가 없다고 한다. 하지만 레벨2에서는 프로젝트 관리와 품질보증, 형상관리 등에
대한 관리가 이루어지고, 이후의 각 상위 레벨별로 조직 역량에 맞는 과제를 제시해 주고 있다.

이는 무슨 말이냐고 하면, 현재 아무리 회사의 수준이나 역량이 낮더라고,
레벨2에서 다루어지는 내용들은 한번 시도해 볼만한 가치가 있다는 얘기가 된다.

실제로, 제대로 된 프로젝트 체계가 없는 회사에서 레벨3나 4에 있는 내용을
적용해 보려고 하면, 쉽지 않고 많은 시행착오를 거치는 경우를 볼 수 있다.
한참이 지난 후에야 레벨2에 있는 영역들에 대한 정착이 선행되어야만 레벨3,4에 있는
프로세스 영역에 대한 욕심을 내어 볼수 있다는 것을 깨닫는 경우가 많다.

즉, 내가 여러분께 해 드리고자 하는 반가운 얘기란 다름이 아니라,
아무리 현재 조직이나 팀이 엉망이더라 하더라도, 형상관리는 시작해 볼만하다는 얘기가 된다.

별로 반갑지 않았다면, 안타까울 뿐이다.

낮은 개발성숙도를 가진 조직이 레벨3에 있는 Inspection이나, Risk management
같은 프로세스는 적용해 볼 수는 있지만, 비효율적이고, 레벨2의 프로젝트 관리와
품질보증 프로세스가 바탕이 되어야 효과적이다.

형상관리에서 주로 다루어져야 하는 내용들은 무엇이 있을까?
크게 3가지가 있다.

첫째, 베이스라인에 대한 설정과 관리
둘째, 변경항목에 대한 추적과 통제
셋째, 형상 무결성에 대한 검증

척 보고, 아~ 할 수있는 내용은 아니다.
각각의 내용에 대해서는 하나씩 차례대로 다루어 보겠다.
 
하지만, 그 전에 앞서 기본적으로 사용되는 용어에 대한 설명이 앞서야 하겠다.

ㅇ 형상 항목 (Configuration Item)

앞서, 형상관리의 간략한 정의는 [프로젝트를 구성하는 모든 요소에 대한 "상태"와
"변경","이력"에 대한 통제, 보고, 기록 등의 총체적인 관리활동]이라고 한적이 있다.
사실 모든 요소를 관리하는 것은 불가능하다.
그래서, 대부분 프로젝트에서 반드시 관리되어야 할 요소들을 정의해서 그 요소들에
대해서 형상관리 활동을 수행한다. 이 요소들을 형상항목이라고 한다.

대부분의 조직에서 어떤 것들을 형상항목으로 정해야 하는 지 많은 질문을 한다.
정확히 말하면 답은 없다. 회사마다 사정이 다르고, 어떤 프로젝트에서는 쓰레기
취급을 받는 자료가, 다른 프로젝트에서는 핵심 산출물이 되기도 한다. 고객에 따라서
중요하게 생각하는 것들이 다르기 때문에, 형상항목을 정하는데 있어 고객의 의사도 매우 중요하다.

일반적으로 언급되는 주요한 형상항목은 다음과 같다.

계획서 종류 (프로젝트 계획 / 사업계획 / 일정계획 / 품질보증계획 등등)
요구사항 (고객 요구사항, 시스템 요구사항, 테스트 요구사항 등등)
설계 자료 (Use Case, DB 정의서, Class 정의서, 테스트 케이스 등등)
각종 도식자료 들 (ERD, Class Diagram, Use Case Diagram, System Configuration, Context Diagame 등등)
소스 코드

사실 이외에도 많다. (책에서 언급되는 내용중에 국내 현실과 부적합것들은 제외하였다)
그리고 이쯤 되면 우려했던 질문이 나온다.
지금은 소스코드만 CVS같은 툴로 관리하고 있는데, 이 모든 걸 다 관리해야 한다고?
너무 힘들지 않은가? 불가능해 보인다.

맞다. 작은 규모의 조직에서 너무 형상항목을 많이 잡는 것은 바보같은 짓이다.
프로젝트 경험이 없는 QA들이 들어와서 설칠때, 자주 볼 수 있는 모습이다.

이런 경우, 나타나는 대표적인 현상은 모든 프로젝트 자료를 형상관리 리포지토리에 다 집어넣고,
관리를 시작하지만, 관리업무의 양을 감당하지 못하고 결국 어느것도 제대로 관리되지 못하는
일이 생긴다. 결국 리포지토리는 일종의 네트웍 스토리지로 전락하고, 데이터 백업과
자료 공유공간으로서의 역할밖에 수행하지 못하는 일이 생긴다. 제일 흔한 경우다.

하지만, 그렇다고 적은 수의 형상항목을 정하자고 해서, 소스코드만 달랑 관리하는 경우도
많다. 앞에서 언급한 적이 있는데, "소스 관리"는 "형상관리"의 하위 개념으로,
다른 형상항목과 약간 다른 관리적 요구를 가진다. 물론 소스 코드도 관리하지 않는 것보다야
낫겠지만, 프로젝트에서는 소스코드 보다 훨씬 중요한 의미를 가지는 자료도 많다.

예를 들어, 요구사항이 제대로 관리되지 못해, 고객이 원하지 않는 엉뚱한 기능을 가진
소스코드가 만들어지는 경우, 이 소스코드는 슬프지만 쓰레기라고 밖에 말할 수 없다.
이럴 경우, 소스코드는 아예 개발자 각자가 관리하고, 형상관리 항목으로는 "요구사항"
하나만 관리하는 편이 낫다.

그럼 우리 회사에서는 과연 무슨 형상항목을 관리해야 하는가?

다시 원점으로 돌아가서 얘기하게 되는 것 같지만,
정답은 없고, 회사마다의 프로젝트마다의 사정에 맞추어야 한다.
나도 이런 얘기를 처음 들었을때 너무 답답했다.

파레토의 원칙이라고 들어보았는가? 흔히들 20:80 법칙이라고 하는 것이다
19세기 이탈리아의 경제학자 빌 파레토가 주장한 이론이다.
당시 사회에서, 20%의 소수가 사회 전체의 재화 중 80%를 가지고 있었다고 한다.
(이는 현재 우리사회에서도 비슷하게 적용된다)

즉 파레토 원칙이란, 전체 중 20퍼센트만의 투입으로 80퍼센트의 성과가 산출된다는 것이다.
예를 들어

1. 내가 받는 우편물의 20퍼센트가 80퍼센트의 만족감을 준다. 나머지 80퍼센트의 우편물은 쓸모없는 것이다.
2. 회사 매출의 80퍼센트가 20퍼센트의 고객으로부터 나오는 것이다.
3. 1년 동안 통화한 사람 중 20퍼센트와의 통화시간이 총 통화시간의 80퍼센트를 차지한다.
4. 직원 20퍼센트가 병가(病暇)의 80퍼센트를 차지한다.
5. 즐겨 입는 옷의 80퍼센트는 옷장에 걸린 옷의 20퍼센트에 지나지 않는다.

즉, 20%의 프로젝트 산출물만 중점적으로 관리해도, 80%의 효과를 올릴수 있다는 것이다.
어디까지나 개인적인 견해이다. 형상관리 전문가가 본다면 뭐라고 할 지는 모르겠다. (-_-;)
하지만, 돈 없고, 사람없는 국내 개발 현실에서는 20%도 넘 많은 셈이다

[출처] 소프트웨어 형상관리 (SCM : Software Configuration Management) (TIBCO 솔루션 그리고 .....) |작성자 솔나무