왜 형상관리가 필요한가

12편에서 구현 단계의 품질 확보(코딩 표준·코드 리뷰·정적 분석)를, 16편에서 유지보수와 재공학을 다뤘습니다. 이 두 활동에는 공통된 전제가 하나 있습니다. 지금 우리가 보고 있는 소스 코드·문서·산출물이 정확히 어떤 버전인지, 언제 무엇이 왜 바뀌었는지 추적할 수 있어야 한다는 것입니다.

여러 개발자가 동시에 같은 파일을 고치거나, 배포한 뒤에야 결함이 발견되어 “어느 버전에서 문제가 생겼는지” 찾아야 하는 상황을 떠올려 보십시오. 산출물이 통제되지 않으면 어제 잘 되던 기능이 오늘 안 되는데 원인을 아무도 설명하지 못하는 일이 생깁니다. 형상관리(SCM, Software Configuration Management) 는 이런 혼란을 막기 위해 소프트웨어를 구성하는 모든 산출물의 정체성(무엇인지)·이력(어떻게 바뀌었는지)·상태(지금 어느 버전인지) 를 체계적으로 관리하는 활동입니다.

쉽게 말하면: 형상관리는 “지금 우리가 만든 것이 정확히 무엇이고, 어떻게 이 모습이 됐는지”를 항상 답할 수 있게 만드는 관리 체계입니다.

1. 형상항목 — 무엇을 관리 대상으로 삼는가

형상항목(CI, Configuration Item) 은 형상관리의 대상으로 지정되어 개별적으로 식별·통제되는 산출물 단위입니다. 소스 코드 파일 하나만이 아니라 소프트웨어 개발 과정에서 만들어지는 모든 산출물이 후보가 됩니다.

형상항목으로 지정된 산출물에는 고유 식별자(파일명, 버전 번호, 문서 번호 등)를 부여해 어느 것이 어느 버전인지 항상 구분할 수 있게 합니다. 모든 산출물을 형상항목으로 관리하는 것은 아닙니다 — 관리 비용과 통제 효과를 저울질해, 변경되면 다른 산출물에 영향을 주거나 계약·품질 기준과 직결되는 산출물을 선별해 형상항목으로 지정합니다.

2. 베이스라인 — 합의된 시점의 기준선

형상항목은 개발 과정에서 계속 바뀝니다. 그런데 바뀌는 도중의 아무 시점이나 “기준”으로 삼으면, 나중에 “그때 승인받은 버전이 어느 것이었는지”를 두고 다시 다툼이 생깁니다. 이를 막기 위한 개념이 베이스라인(Baseline) 입니다.

베이스라인은 정식 검토·승인 절차를 거쳐 공식적으로 확정된 형상항목(또는 형상항목의 묶음)의 한 시점 스냅숏입니다. 베이스라인이 설정된 이후에는 그 산출물을 함부로 바꿀 수 없고, 바꾸려면 반드시 공식적인 변경 통제 절차(3절)를 거쳐야 합니다.

일반적으로 소프트웨어 생명주기에서는 다음과 같은 베이스라인을 둡니다.

비유: 베이스라인은 등산 중 세우는 “여기까지는 확정된 루트”라는 표지판과 같습니다. 표지판을 세우기 전까지는 길을 자유롭게 탐색하지만, 표지판을 세운 뒤 그 구간을 다시 바꾸려면 왜 바꿔야 하는지 대장(승인권자)에게 보고하고 허락을 받아야 합니다.

3. 변경 통제 — 베이스라인을 바꾸는 공식 절차

베이스라인이 확정된 형상항목을 바꾸려면 아무나 임의로 고칠 수 없고, 변경 통제(Change Control) 라는 공식 절차를 거쳐야 합니다. 이 절차의 핵심 기구가 형상통제위원회(CCB, Configuration Control Board) 입니다. CCB는 변경 요청을 검토해 승인·반려·보류를 결정하는 권한을 가진 조직(또는 역할을 맡은 사람들의 모임)입니다.

이 절차가 있어야 “누군가 조용히 코드를 고쳤는데 아무도 몰랐다”거나 “요구사항 하나를 바꿨는데 설계·테스트 문서는 옛날 버전 그대로다”라는 상황을 막을 수 있습니다. 특히 영향 분석 단계는 비용이 가장 저렴한 시점에 문제를 발견한다는 점에서 중요합니다 — 변경이 다른 산출물에 미치는 파급 효과를 미리 확인하지 않고 구현부터 하면, 나중에 여러 산출물을 다시 뜯어고쳐야 하는 더 큰 비용이 발생합니다.

4. 버전·빌드·릴리스 관리 — 세 용어의 층위 구분

형상관리를 다루는 문항에서 자주 헷갈리는 세 용어가 버전·빌드·릴리스입니다. 세 용어는 “얼마나 많은 변경을 묶어서, 누구에게 전달하느냐”의 층위가 다릅니다.

버전 번호는 보통 주(major).부(minor).수정(patch) 형식(예: 2.3.1)으로 관리하는 관례가 널리 쓰입니다. 주 버전은 호환되지 않는 큰 변경, 부 버전은 호환되는 기능 추가, 수정 버전은 결함 수정을 의미하는 식으로 규칙을 정해 팀 안에서 공유합니다. 이 규칙 자체를 외우기보다, “버전은 식별, 빌드는 산출, 릴리스는 배포 확정”이라는 층위 차이를 구분하는 것이 시험형 문항에서 더 중요합니다.

핵심 정리

• 형상항목(CI) 은 요구사항·설계·구현·테스트·지원 산출물 전반에서 개별 식별·통제 대상으로 지정된 단위이며, 소스 코드만을 뜻하지 않는다.
• 베이스라인은 검토·승인을 거쳐 확정된 특정 시점의 기준선이며, 이후 변경은 반드시 공식 절차를 거쳐야 한다. 기능·할당·제품 베이스라인으로 생명주기 단계마다 확정된다.
• 변경 통제는 변경 요청 → 영향 분석 → CCB(형상통제위원회) 심의 → 구현 → 검증·새 베이스라인 확정의 절차를 따르며, 승인되지 않은 변경은 반영되지 않는다.
• 버전은 변경 식별 번호, 빌드는 컴파일·링크된 실행 가능 산출물, 릴리스는 검증을 마치고 배포하기로 확정한 빌드로, 세 용어는 서로 다른 층위를 가리킨다.

마무리 복습

참고 자료

• SWEBOK topics 상세 - IEEE Computer Society 
• SWEBOK v4 and SFIA v9 가이드