소프트웨어 형상 관리

변경은 막을 수 없다 — 그래서 관리한다

책마루 온라인 주문 시스템을 개발하는 도중, 사장님이 "배달 지역을 옆 동네까지 넓혀달라"고 요청했다고 하자. 개발자는 이미 "동네 배달은 도보 30분 이내"라는 요구사항을 바탕으로 설계와 코드 일부를 작성해 두었다. 이 요청을 받아들이려면 요구사항 명세서, 설계 문서, 배달 판단 로직 코드, 테스트 케이스까지 줄줄이 고쳐야 한다. 이런 변경이 문서화되지 않은 채 여기저기서 산발적으로 반영되면 어떤 일이 벌어질까? 어떤 문서는 옛 기준(도보 30분)을, 어떤 코드는 새 기준(옆 동네까지)을 따르는 상태가 되어 아무도 지금 시스템의 "진짜 모습"을 알 수 없게 된다.

소프트웨어 개발의 근본적인 특징 중 하나는 요구사항이 계속 변한다는 것이다. 변경 자체는 불가피하고, 심지어 자연스러운 일이다. 문제는 변경을 안 하는 것이 아니라, 변경을 통제되지 않은 채로 두는 것이다. 특히 프로젝트 규모가 커질수록 통제되지 않은 변경은 우리를 돕는 대신 거꾸로 우리를 억압하고 혼란에 빠뜨린다. 이 장에서 다루는 **형상 관리(configuration management, SCM)**는 바로 이 문제에 대한 답이다.

형상이란 무엇인가

형상(形象, configuration)이란 사물이 생긴 모양(form) 또는 이미지(image)를 뜻한다. 그런데 소프트웨어는 손에 잡히지 않는 무형의 결과물이라 "모습"을 설명하기가 애매하다. 다만 소프트웨어 개발의 각 단계마다 그 단계의 산출물인 문서가 만들어진다는 점에 착안하면, 소프트웨어의 형상은 결국 개발 과정에서 생산되는 문서와 코드의 집합으로 설명될 수 있다. 요구사항 명세서, 설계 문서, 소스 코드, 사용자 매뉴얼 — 이 모든 것을 합친 것이 어느 한 시점의 책마루 시스템의 "모습"이다.

소프트웨어 형상 관리는 개발 및 유지보수 과정에서 발생하는 이런 산출물들(문서, 프로그램, 심지어 하드웨어)에 대한 계획·개발·운용을 종합하여 시스템의 형상을 만들고, 그에 대한 변경을 체계적으로 관리·제어하는 활동이다. 프로세스가 시작해서 끝날 때까지 발생하는 모든 문제를 추적하고 제어하는 일련의 행위를 포함하며, 이를 제대로 못하면 혼란이 가중되고 생산성이 떨어진다.

기준선 — 흔들리는 표적은 맞히기 어렵다

설계 단계로 넘어가기 전에 요구사항을 확정하지 않으면 어떤 일이 생길까? 설계자는 계속 바뀌는 목표를 뒤쫓게 되고, 그때마다 이미 만든 설계를 다시 손봐야 한다. "날아다니는 목표를 잡는 것보다 고정된 목표를 잡는 것이 쉽다"는 비유가 이 상황을 정확히 짚는다.

그래서 형상 관리는 각 단계의 산출물이 완성되면 이를 **동결(freezing)**하는 과정을 요구한다. 공식적인 검토와 합의를 거쳐 서명되고 공식 승인된 문서를 **기준선 문서(baselined document)**라고 부른다. 기준선 문서는 그 이후 개발의 기준이 되며, 오직 공식적인 변경 절차를 통해서만 다시 바뀔 수 있다. 예를 들어 책마루 프로젝트에서 요구사항 명세서가 사장님의 서명을 받아 기준선이 되고 나면, 이후 "배달 지역을 넓혀달라"는 요청은 임의로 반영되는 것이 아니라 정해진 변경 절차를 거쳐야만 명세서에 반영될 수 있다.

기준선을 만드는 실무적인 절차는 대개 공식기술검토회(19장 참고)를 통해 이해 당사자들이 문서를 검토하고 서명하는 방식으로 이루어진다. 서명이 끝나면 형상 관리 담당자가 그 문서를 데이터베이스나 저장소(repository)에 보관한다.

형상 항목 — 무엇을 동결할 것인가

형상 관리의 최소 단위를 **형상 항목(software configuration item, SCI)**이라 부른다. 소프트웨어 개발 프로세스의 각 단계마다 산출물이 만들어지고, 이 산출물들이 형상 관리의 대상이 된다. 책마루 프로젝트를 기준으로 형상 항목의 예를 들면 다음과 같다.

각 형상 항목은 서로 구별되도록 이름이 붙여지고 관리되는 기본 단위여야 한다. 어떤 항목을 형상 관리 대상으로 삼을지, 각 항목과 버전을 어떻게 식별할지는 프로젝트 계획 단계에서 미리 정해두어야 한다 — 이 활동을 **형상 식별(configuration identification)**이라 부른다.

형상 통제 — 바꾸려면 절차를 거친다

기준선이 된 형상 항목을 수정하려면 관련된 당사자들의 동의와 승인 절차가 필요하다. 이를 **형상 통제(configuration control)**라 하며, 크게 두 상황으로 나뉜다.

• 신규 형상 항목 등록: 새로 만들어진 문서를 형상 항목으로 등록할 때는 신규등록요청서를 작성해 사유를 밝히고 승인을 받는다. 이 승인을 통해 그 문서의 최초 기준선(초기 승인 버전)이 만들어진다.
• 변경 통제(change control): 이미 기준선이 된 형상 항목에 변경이 필요할 때, 이를 요청·평가·승인(또는 반려, 연기)하는 절차다.

변경 요청은 고객으로부터 들어올 수도 있고("배달 지역을 넓혀달라"), 개발자가 오류를 발견해서 생길 수도 있고, 인도 후 유지보수 과정에서 발생할 수도 있다. 출처가 무엇이든 절차는 같다. 요청이 접수되면 변경 관리자(또는 분석가)가 요청을 분석하고 영향을 평가해 보고서를 작성한다. 이 보고서를 바탕으로 **형상통제위원회(CCB: Configuration Control Board)**가 변경을 심사해 승인, 반려, 또는 추가 분석을 위한 연기를 결정한다. 승인되면 변경 담당자가 지정되어 실제 수정을 수행하고, 수정 결과가 확인(verification)된 뒤 새로운 기준선으로 공식화된다.

책마루의 "배달 지역을 옆 동네까지 넓혀달라"는 요청을 이 절차에 대입해보면 이렇게 흘러간다.

1. 사장님이 변경을 요청하고, 변경 관리자(외주 개발사의 PM)가 이를 접수한다.
2. 분석가가 영향을 평가한다 — 요구사항 명세서의 배달 판단 로직, 배달 담당자 앱의 경로 표시, 관련 테스트 케이스까지 세 곳이 영향을 받는다는 결론이 나온다.
3. 변경 우선순위(긴급/높음/보통/낮음)와 예상 추가 일정·비용을 정리해 사장님에게 보고한다.
4. 사장님이 승인하면(작은 프로젝트에서는 사장님 본인이 사실상 CCB 역할을 한다) 담당 개발자가 배정되어 수정한다.
5. 수정이 요구사항과 일치하는지 확인한 뒤, 요구사항 명세서·코드·테스트 케이스가 함께 새로운 기준선으로 갱신된다.

이 다섯 단계 중 어느 하나라도 생략되면, 예를 들어 4번의 승인 없이 개발자가 곧바로 코드를 고쳐버리면, 나중에 "이 변경에 들어간 시간은 원래 견적에 포함된 것인가"를 둘러싼 다툼을 판정할 근거가 사라진다. 절차가 번거로워 보여도, 그 번거로움이 바로 나중의 분쟁 비용을 미리 지불하는 셈이다.

책마루처럼 작은 프로젝트에서 CCB는 필요한가: 위원회씩이나 꾸릴 규모는 아니지만, 원칙은 똑같이 적용해야 한다 — 변경 요청을 문서로 남기고, 일정과 비용에 미치는 영향을 따져보고, 승인권자(사장님)의 확인을 받은 뒤에만 반영한다. 4장에서 "변경통제위원회 없이 이 원칙만은 지켜야 한다"고 짚었던 것이 바로 이 형상 통제의 축소판이다. 위원회라는 형식이 없어도, "누가 승인하는가"라는 질문에 답이 있어야 범위 관리라는 말이 의미를 갖는다.

형상 상태 기록과 보고 — 지금 무슨 일이 있었는지 알 수 있어야 한다

형상 변경에 관한 기록을 자동화된 저장소와 도구로 관리하는 것을 **형상 상태 기록(configuration status accounting)**이라 하고, 형상 항목의 상태가 바뀔 때마다 이해 당사자가 그 결과를 알 수 있도록 조치하는 것을 **형상 상태 보고(configuration status reporting)**라 한다. 두 활동 모두 "지금 이 문서/코드가 어떤 버전이고, 언제 왜 바뀌었는지"를 누구나 추적할 수 있게 만드는 것이 목적이다.

버전이 쌓이면 하나의 형상 항목이 시간에 따라 어떻게 분기하고 병합되었는지를 그래프 형태로 볼 수 있다. 오늘날 대부분의 개발팀은 이를 수작업 문서 대신 버전 관리 시스템으로 자동화한다. 책마루 프로젝트라면 Git 저장소가 이 역할을 한다 — main 브랜치를 기준선으로 삼고, 배달 지역 확장 같은 새 기능은 별도 브랜치(예: feature/delivery-area-expansion)에서 작업한 뒤, 코드 리뷰(공식기술검토회에 해당)를 거쳐 승인되면 main에 병합해 새로운 기준선을 만드는 흐름은, 20세기 형상 관리 이론이 말하는 "동결 → 통제된 변경 → 새 기준선"의 절차를 그대로 코드 저장소 위에 옮겨놓은 것이다. 태그(tag)를 붙여 특정 버전(예: v1.2 배포본)을 표시하는 것도 형상 식별의 실무적 구현이라 할 수 있다.

형상 감사 — 절차대로 됐는지 확인하기

형상 관리 계획에 나와 있는 변경 관리 프로세스가 실제로 지켜졌는지를 감독하고 검사하는 것을 **형상 감사(configuration audit)**라 한다. 기술적 검토를 통해 변경이 정확히 이루어졌는지, 다른 형상 항목들과 일관성이 있는지를 확인한다. 형상 감사는 소프트웨어와 함께 배달되는 문서들이 논리적으로 일관성을 갖추고 있는지, 그리고 기능 및 성능 요구사항이 실제로 만족되었는지를 검증하는 과정을 포함한다.

책마루 프로젝트를 예로 들면, 오픈 직전에 "배달 지역 확장" 변경이 요구사항 명세서·설계 문서·코드·테스트 결과 전체에 일관되게 반영되었는지 마지막으로 점검하는 활동이 형상 감사다. 코드만 바뀌고 사용자 매뉴얼이 옛 기준을 그대로 담고 있다면, 형상 감사에서 이 불일치가 걸러져야 한다.

형상 관리 계획 — 표준을 따르는 이유

형상 관리를 체계적으로 수행하려면 형상 관리 계획이 프로젝트 초기 단계에서 수립되어야 한다. 이 계획에는 형상 항목 식별 활동, 형상 통제 위원회(또는 담당자)의 권한과 책임, 변경 제어와 버전 관리를 위한 절차, 사용할 도구, 기준선 설정 계획, 형상 감사 계획이 포함된다.

국제적으로는 IEEE Std 828(Software Configuration Management Plans)이, 국내에서는 한국정보통신기술협회(TTA)의 표준이 이런 계획을 작성할 때 참고할 수 있는 지침을 제공한다. 표준을 그대로 따라야 할 의무가 없는 소규모 프로젝트라도, "이 프로젝트에서 무엇을 형상 항목으로 관리할지", "누가 변경을 승인할지", "어떤 도구를 쓸지"라는 세 가지 질문에는 미리 답을 정해두는 편이 좋다 — 이 세 가지가 정해지지 않은 채 개발이 진행되면, 프로젝트 후반부에 "지금 어떤 버전이 맞는 건지" 아무도 확신하지 못하는 상황에 이르기 쉽다.

형상 관리를 생략하면 벌어지는 일

형상 관리는 지루하고 관료적으로 느껴지기 쉬운 활동이다. 문서에 서명을 받고, 변경 요청서를 쓰고, 승인을 기다리는 과정이 개발 속도를 늦추는 것처럼 보이기 때문이다. 실제로 많은 조직에서 이 절차가 과도하면 답답함을 호소하기도 한다. 하지만 형상 관리를 아예 생략한 프로젝트에서 흔히 나타나는 증상들을 나열해보면 왜 이 활동이 필요한지 거꾸로 확인할 수 있다.

• 배포된 버전과 개발팀이 들고 있는 코드가 서로 달라 "지금 운영 중인 게 어느 버전이냐"는 질문에 답할 수 없다.
• 동시에 두 사람이 같은 파일을 고치다 한쪽의 변경 내용이 조용히 사라진다.
• 고객이 "이 기능 넣어달라고 한 적 없다"고 주장할 때, 이를 반박할 근거 문서가 없다.
• 오류가 발생했을 때 "언제부터, 어떤 변경 때문에" 문제가 생겼는지 되짚어갈 방법이 없다.

이 네 가지 증상은 모두 "지금 형상이 무엇인지 아무도 확신하지 못하는" 상태에서 비롯된다는 공통점이 있다. 형상 관리 절차의 무게는 프로젝트 규모에 맞춰 조절할 수 있어도, 이 절차가 답하려는 질문 자체 — 지금 무엇이 기준이고, 누가 그것을 바꿀 권한이 있는가 — 는 규모와 무관하게 답이 있어야 한다.

핵심 정리

• 소프트웨어의 형상은 개발 과정에서 생산되는 문서와 코드의 집합으로 설명되며, 형상 관리는 이를 체계적으로 통제하는 활동이다.
• 각 단계의 산출물은 검토와 승인을 거쳐 동결되어 기준선 문서가 되며, 이후 변경은 공식 절차를 통해서만 가능하다.
• 형상 통제는 신규 등록과 변경 통제로 나뉘고, 변경 요청은 CCB 같은 승인 주체를 거쳐야 임의 반영을 막을 수 있다.
• 형상 상태 기록·보고와 형상 감사는 "지금 무엇이 어떤 상태인지"를 누구나 추적하고 검증할 수 있게 만든다. 현대의 버전 관리 시스템(예: Git 브랜치 전략)은 이 원리를 도구 차원에서 구현한 것이다.

다음 장(21장)에서는 개발한 소프트웨어가 "제대로 만든 것"이면서 동시에 "제대로 된 것을 만든 것"인지 확인하는 소프트웨어 검증과 확인을 다룬다.