2.10 소프트웨어 형상 관리

개요와 동기

소프트웨어 형상 관리(SCM)는 소프트웨어 시스템의 구성 요소를 식별하고, 그것이 어떻게 변하는지를 통제하고, 모든 변경의 상태를 기록하고, 만들고 전달한 것이 의도한 것과 일치하는지 검증하는 규율입니다. 단순하게 들리지만 규모에서는 어려워지는 질문에 답합니다. 이 릴리스에는 정확히 무엇이 들어 있고, 어떻게 거기에 왔으며, 누가 승인했는가? SWEBOK은 분명한 이유로 SCM을 기초 지식 영역으로 다룹니다. 다른 모든 엔지니어링 활동이 기댈 안정적이고 알려진 형상이 필요하기 때문입니다.

큰 팀에서 SCM은 수천 개의 움직이는 부분을 일관되게 유지하는 결합 조직입니다. 소스 코드, 라이브러리, 컨테이너 이미지, 인프라 정의, 설정 데이터, 문서, 테스트 산출물이 모두 각자의 시계로 변하며, 전달된 시스템은 이 모두의 특정 버전의 특정 조합 하나입니다. 의도적인 형상 관리가 없으면 그 조합은 알려지지 않고 재현할 수 없습니다. 과거 릴리스를 다시 만들 수도, 결함을 그것을 일으킨 변경까지 추적할 수도, 프로덕션에서 무엇이 돌아가는지 자신 있게 말할 수도 없습니다.

기업과 정부 환경은 이해관계를 높입니다. 규제 및 공공 부문 프로그램은 변경이 승인되고, 검토되고, 기록되었음을, 전달된 빌드가 승인된 요구사항과 소스까지 추적됨을, 아무것도 통제 없이 시스템에 들어오지 않았음을 보여야 합니다. 여기서 SCM은 엔지니어링 시스템인 만큼 증거 시스템이기도 합니다. 버전 관리(2.6장)는 소스 이력을 관리하고, SCM은 전체 형상과 그것이 변하는 통제된 프로세스를 다스립니다. 코드형 인프라(8.2장), 전달 파이프라인(8.1장), 감사와 보증(10.2장)과 긴밀히 연결되어 있습니다.

핵심 원칙

시스템 동작을 결정하는 모든 것은 소스 코드만이 아니라 통제 아래 있는 형상 항목입니다.
기준선은 알려지고 합의된 기준점입니다. 변경은 가볍게가 아니라 의도적으로 기준선에 대해 이루어집니다.
변경은 막는 것이 아니라 통제되고 기록됩니다. 목표는 승인되고 추적 가능한 변경입니다.
상태 회계는 형상에 무엇이 있고 그 변경 이력이 무엇인지 언제나 답할 수 있다는 뜻입니다.
감사는 만들고 전달한 시스템이 기록된 형상과 승인된 요구사항과 일치하는지 검증합니다.
재현 가능성은 협상 불가입니다. 모든 릴리스된 버전은 통제된 입력에서 다시 빌드할 수 있어야 합니다.
식별, 기록, 검증을 자동화하십시오. 수동 장부 정리는 확장되지 않고 감사를 견디지 못합니다.

권장 사항

SCM 프로세스를 정의하고 소유권을 배정한다

무엇이 형상 통제 아래 있는지, 항목이 어떻게 식별되는지, 변경이 어떻게 제안되고 승인되는지, 상태가 어떻게 기록되고 감사되는지를 밝히는 SCM 계획을 쓰십시오. SCM이 모두의 일이라 아무의 일도 아니게 되지 않도록 형상 관리자나 책임 있는 팀 같은 분명한 소유권을 배정하십시오. 프로세스를 위험에 맞춰 조정하십시오. 작은 내부 도구는 가벼운 통제가, 안전 핵심이거나 규제를 받는 시스템은 공식 위원회와 기록이 필요합니다. 감사자와 파트너가 따라갈 수 있도록 IEEE 828 같은 인정받는 표준에 계획을 정박시키십시오.

형상 항목을 식별하고 기준선을 확립한다

시스템이 어떻게 동작하는지 결정하는 형상 항목을 나열하십시오. 소스, 의존성, 빌드 스크립트, 컨테이너 이미지, 인프라 정의, 설정 데이터, 스키마, 핵심 문서입니다. 각각에 안정적인 식별자와 버전 관리 체계를 주십시오. 의미 있는 시점(릴리스된 버전, 승인된 요구사항 집합, 인증된 빌드)에 기준선을 두어, 대해서 바꾸고 돌아갈 합의된 기준을 갖게 하십시오. 기준선은 불변입니다. 일단 선언하면 편집하지 않습니다. 변경 프로세스를 거쳐 만들어진 새 기준선으로 대체할 뿐입니다.

정의된 프로세스와 적절한 위원회로 변경을 통제한다

통제되는 항목의 변경을 정의된 경로로 보내십시오. 제안, 영향 평가, 승인, 구현, 검증입니다. 더 위험이 높은 항목에는 변경을 승인하기 전에 비용, 위험, 일정을 저울질하는 변경 통제 위원회(CCB)를 쓰십시오. 위원회를 적정 규모로 하십시오. 일상적인 코드 변경에는 가벼운 자동 관문을, 기준선, 인터페이스, 규제 대상 동작을 건드리는 변경에는 공식 부서 간 CCB를 둡니다. 각 결정과 그 뒤의 이유를 기록하고, 중대한 형상 결정을 결정 기록(1.6장)에 연결해 이유가 살아남게 하십시오.

형상 상태 회계를 유지한다

모든 형상 항목의 정확하고 질의 가능한 기록을 유지하십시오. 현재 버전, 속한 기준선, 적용된 변경 요청입니다. 이 상태 회계가 언제든 릴리스가 무엇을 담고 어떻게 거기에 왔는지 답할 수 있게 합니다. 현실에서 벗어나는 병렬 스프레드시트를 유지하는 대신 기록 도구(버전 관리, 파이프라인, 산출물 레지스트리)에서 기록을 자동으로 생성하십시오. 이 기록은 요구사항에서 변경, 빌드, 배포까지의 추적성의 척추입니다.

형상 감사를 수행한다

정기적으로 두 가지를 검증하십시오. 기능 형상 감사는 형상이 요구사항이 명세한 대로 수행하는지 확인합니다. 물리 형상 감사는 전달된 산출물이 기록된 형상과 일치하는지, 즉 빌드가 기록된 소스와 의존성에서 왔고 설명되지 않은 것을 담고 있지 않은지 확인합니다. 가능한 한 많이 자동화하십시오. 재현 가능한 빌드, 산출물 체크섬, 소프트웨어 자재 명세서(SBOM), 출처 증명이 감사를 수동 검사에서 지속적 검사로 바꿉니다.

릴리스와 전달을 통제된 사건으로 관리한다

릴리스를 반복 가능한 프로세스로 전달되는 특정하고 식별된 기준선으로 다루십시오. 릴리스를 명시적으로 버전 관리하고, 정확히 무엇이 포함되었는지 설명하는 매니페스트나 자재 명세서를 만들고, 릴리스에서 소스 리비전, 배포된 산출물까지의 대응을 기록하십시오. 하류의 누구든 무결성을 검증할 수 있도록 릴리스된 산출물에 서명하고 체크섬을 매기십시오. 환경 간 승격 자체가 통제되고, 기록되고, 되돌릴 수 있도록 릴리스 관리를 전달 파이프라인(8.1장)에 연결하십시오.

SCM 도구를 고르고 통합한다

규율에만 의존하지 말고 식별, 통제, 회계, 감사를 자동화하는 도구에 기대십시오. 소스를 위한 버전 관리, 바이너리를 위한 산출물 및 이미지 레지스트리, 빌드를 위한 불변 파이프라인, 환경을 위한 코드형 인프라, 출처를 위한 의존성 및 SBOM 도구입니다. 하나의 변경이 커밋에서 배포된 릴리스까지 추적 가능하게 흐르도록 연결하십시오. 목표는 형상 기록이 별개의 사무 잡무가 아니라 일을 하는 부산물인 도구 체인입니다.

장단점

선택	장점	단점
공식 변경 통제 위원회	강한 승인과 감사 추적. 변경 전에 위험을 저울질	처리량이 느림. 일상 변경에 적용하면 오버헤드
가벼운 자동 관문	빠른 흐름. 낮은 오버헤드. 많은 변경에 확장됨	위험이 높은 기준선에는 약함. 숙고가 적음
엄격한 불변 기준선	재현 가능하고 감사 가능한 기준점	규율과 도구가 필요. 과하면 마찰
자동 상태 회계	정확하고 항상 최신인 기록. 감사에 준비됨	선행 도구 및 통합 투자
수동 형상 기록	시작하기 단순. 도구가 필요 없음	현실에서 벗어남. 규모와 감사에서 실패

핵심 트레이드오프는 통제 대 흐름입니다. 무거운 변경 통제는 강한 보증을 주지만 전달을 늦춥니다. 가벼운 통제는 빠르게 흐르지만 추적성을 약하게 합니다. 답은 전역적으로 하나를 고르는 것이 아니라 위험에 따라 통제를 계층화하는 것입니다. 일상 변경은 빠른 관문으로 자동화하고, 승인과 감사 가능성이 진정으로 중요한 항목에 공식 위원회와 불변 기준선을 남겨 두십시오. 두 번째 트레이드오프는 선행 도구 투자 대 지속적인 사무 비용과 감사 위험입니다. 자동 회계는 설정 비용이 더 들지만 함께 사는 비용은 훨씬 적습니다.

팀과 논의할 질문

우리의 형상 항목 목록에는 정확히 무엇이 속하며, 새로운 것이 나타날 때 누가 결정을 소유합니까? SCM은 통제되는 항목의 목록이 동작을 실제로 결정하는 것의 집합과 일치할 때만 작동하는데, 큰 시스템에서 그 집합은 대부분의 팀이 생각하는 것보다 큽니다. 소스, 의존성, 빌드 스크립트, 컨테이너 이미지, 인프라 정의, 스키마, 기능 플래그, 소프트웨어가 하는 일을 조용히 바꾸는 설정 데이터입니다. 아무도 목록을 소유하지 않으면 낡고, 프로덕션에서 여러분을 쓰러뜨린 항목은 아무도 통제할 생각을 못 한 바로 그것으로 드러납니다. 현재 목록을 회의에 가져와 거기서 빠진 동작 결정 항목을 찾으십시오. 책임 있는 소유자(형상 관리자나 이름 있는 팀)를 지정해 새 항목을 추가하는 것이 우연이 아닌 의도적 결정이 되게 하십시오. 모두의 일인 SCM은 아무의 일도 아니기 때문입니다.
배포된 산출물이 우리가 생각하는 소스와 파이프라인에서 왔음을 증명할 수 있으며, 그 증명이 변조를 견딥니까? 재현 가능성과 추적성이 SCM의 전부이며, 날카로운 버전의 질문은 실행 중인 바이너리를 주장이 아니라 증거로 특정 커밋과 빌드 실행에 연결할 수 있는가입니다. 규제를 받거나 가치가 높은 시스템에서 이것은 공급망 방어이기도 합니다. 서명된 출처 증명, 산출물 체크섬, 소프트웨어 자재 명세서는 “꽤 확신한다”를 감사자나 인시던트 대응자가 검증할 수 있는 것으로 바꿉니다. 마지막 릴리스를 가져와 배포된 산출물에서 승인된 변경까지 거꾸로 걸어 보십시오. 어느 한 단계가 기록되고 검증 가능한 연결이 아니라 수동 주장이라면, 거기가 공격자나 정직한 실수가 눈에 띄지 않게 무언가를 끼워 넣을 수 있는 곳이며, 이를 닫으려면 서명과 출처를 파이프라인에 연결해 기록이 전달의 부산물이 되게 해야 합니다.
오늘 누구든 릴리스를 제자리에서 편집할 수 있으며, 그것이 우리가 그것을 신뢰하는 능력에 무엇을 하겠습니까? 기준선은 불변일 때만 유용합니다. “릴리스”가 사후에 편집될 수 있는 순간, 재현하거나 기준으로 의존할 수 없고 모든 하류 감사는 고고학이 됩니다. 전형적인 실패는 프로덕션에서 직접 편집된 설정이나 조용히 옮겨진 태그이며, 이는 해롭지 않게 느껴지면서 나중에 릴리스를 재구성할 수 없게 만드는 바로 그 지름길입니다. 정직한 답을 회의에 가져오십시오. 변경 프로세스를 거치지 않고 배포된 기준선을 바꿀 접근 권한이 누구에게 있으며, 그런 일이 일어났습니까? 해법은 기준선을 진정으로 불변으로 만들고, 모든 변경을 제안, 영향 평가, 승인, 검증으로 라우팅하되, 엄밀함을 계층화해 일상 변경은 빠른 자동 관문을 지나고 기준선과 규제 변경은 위원회로 가게 하는 것입니다.
형상 상태 회계는 기록 도구에서 자동으로 생성됩니까, 수동으로 유지됩니까, 그리고 실제 배포된 것에서 얼마나 벗어났습니까? 상태 회계는 언제든 릴리스가 무엇을 담고 어떻게 거기에 왔는지 답할 수 있게 하는 기록이며, 큰 시스템에서 그 기록은 병렬 스프레드시트에 입력되는 것이 아니라 일에서 저절로 떨어질 때만 신뢰할 수 있습니다. 상충하는 끌림은 손으로 유지하는 대장이 시작하기 싸고 유연하게 느껴지는 반면, 자동화하려면 버전 관리, 파이프라인, 산출물 레지스트리를 통합해 기록이 전달의 부산물이 되게 해야 한다는 점입니다. 오늘 의존하는 대장을 가져와 최근 릴리스 세 건을 무작위로 골라, 기록된 버전, 기준선, 적용된 변경 요청이 도구가 출시했다고 말하는 것과 일치하는지 확인하십시오. 기업이나 정부 프로그램에서 현실과 갈라진 상태 기록은 정돈의 문제가 아니라 감사 지적이 기다리는 것입니다. 감사자는 한 번의 간극을 잡으면 전체 설명을 신뢰하지 않고 손으로 재구성하라고 요구하기 때문입니다.
변경 통제가 위험에 따라 계층화되어 있습니까, 아니면 건드리는 것과 무관하게 모든 변경에 같은 수준의 의식이 적용됩니까? 통제와 흐름은 서로를 당깁니다. 공식 변경 통제 위원회는 변경을 승인하기 전에 비용, 위험, 일정을 저울질하지만, 그 의식을 일상적인 코드 손질에 적용하면 지연만 더하고, 공유 기준선이나 규제 대상 결제 흐름을 빠른 자동 관문으로 보내면 숙고가 가장 필요한 곳에서 숙고를 없앱니다. 실패 양상은 대칭적입니다. 사람들이 우회하는 획일적 무거움, 또는 위험이 높은 변경이 검토 없이 통과하게 하는 획일적 느슨함입니다. 지난 분기 변경의 표본을 각각이 건드린 것에 따라 정렬해, 받은 엄밀함이 실제로 위험에 맞았는지 확인하십시오. 규제 또는 공공 부문 환경에서는 어떤 항목 부류가 부서 간 위원회에 도달해야 하고 어떤 것이 자동 관문을 지나도 되는지 이름 붙여 그 계층화를 명시적으로 기록하십시오. “판단을 쓴다”는 감사자나 감독 기관이 검증할 수 있는 통제가 아니기 때문입니다.
기능 및 물리 형상 감사를 마지막으로 실행한 것은 언제이며, 증거의 얼마가 재구성이 아닌 살아 있는 기록이겠습니까? 기능 형상 감사는 시스템이 요구사항이 명세한 대로 수행하는지, 물리 형상 감사는 전달된 산출물이 기록된 형상과 일치하고 설명되지 않은 것을 담지 않는지 확인합니다. 건너뛰면 기준선과 상태 회계가 정직한지 확인하지 않은 채 믿는 것입니다. 긴장은 비용입니다. 수동 감사는 느리고 고통스러워서 팀이 미루는 것이며, 빠져나가는 길은 재현 가능한 빌드, 산출물 체크섬, 소프트웨어 자재 명세서, 출처 증명으로 검사를 자동화해 검증을 지속적으로 만드는 것입니다. 가장 최근 릴리스를 가져와 요구사항-변경-빌드-배포의 추적과 산출물-소스의 증명을 그 자리에서 만들어 보십시오. 기업과 정부 프로그램에서 이 증거 흔적은 인증과 감독이 요구하는 것이므로, 정직한 질문은 내일의 감사가 이미 가진 기록으로 답해지겠는가, 감당할 수 없는 고고학 작업으로 답해지겠는가입니다.

분야별 관점

스타트업. SCM을 가볍지만 진짜로 유지하십시오. 소스, 인프라 정의, 설정 데이터를 버전 관리에 두고, 모든 릴리스를 손으로 조립한 산출물이 아니라 하나의 파이프라인이 만든 태그된 빌드로 만드십시오. 여러분의 규모에서는 과한 변경 통제 위원회와 공식 기준선은 건너뛰되, 누구도 프로덕션에서 설정을 직접 편집하게 두지 마십시오. 그 하나의 지름길이 다음 화요일에 고객이 버그를 만났을 때 릴리스를 재현할 수 없게 만드는 것이기 때문입니다.

소기업. 형상 관리자도 빠듯한 예산도 있으니, SCM을 거의 공짜로 주는 도구에 의지하십시오. 호스팅 버전 관리 플랫폼, 그 내장 파이프라인, 산출물 레지스트리로, 형상 기록이 인력을 둬야 하는 일이 아니라 부산물이 되게 하십시오. 맞춤 프로세스를 만들지 말고 이미 비용을 내는 도구에 내장된 이 능력을 사십시오. 희소한 주의를 가장 중요한 두 습관, 재현 가능한 태그된 릴리스와 동작을 바꾸는 설정을 수동 프로덕션 편집에서 지키는 것에 쓰십시오.

대기업. 문제는 많은 팀에 걸친 일관성입니다. 공유 SCM 계획, 공통 형상 항목 분류 체계, 계층화된 변경 통제, 버전 관리, 산출물 레지스트리, 파이프라인에서 자동으로 생성되는 상태 회계입니다. 공식 변경 통제 위원회와 불변 기준선은 공유 플랫폼과 규제 흐름에 남겨 두고, 일상 변경은 자동 관문을 지나게 하며, 서명된 출처와 SBOM을 표준화해 어느 팀의 릴리스든 추적할 수 있고 어느 감사자든 재구성을 의뢰하는 대신 살아 있는 기록을 질의할 수 있게 하십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 프로세스를 형성합니다. IEEE 828 같은 인정받는 표준에 맞춘 공식 SCM 계획을 따르고, 계약상 이정표에서 형상 항목을 기준선으로 삼고, 통제된 기준선에 대한 모든 변경을 영향, 결정, 근거를 기록하는 위원회를 통해 보내십시오. 전달된 산출물이 통제된 입력에서 재현 가능하고, 체크섬이 매겨지고, 승인된 요구사항에서 전달된 빌드까지 끝에서 끝까지 추적 가능하도록 요구하십시오. 그 문서화된 증거 흔적이 바로 인증, 감사, 공적 감독이 요구하는 것이기 때문입니다.

사례

스타트업. 여섯 명 규모의 스타트업은 SCM을 가볍지만 진짜로 유지합니다. 소스, 인프라 정의, 설정 데이터가 모두 버전 관리에 있고, 모든 릴리스는 손으로 조립되지 않고 같은 파이프라인이 만든 태그되고 버전이 매겨진 빌드입니다. 고객이 지난 화요일에 나타난 버그를 보고하면, 추측하는 대신 몇 분 안에 배포된 산출물을 정확한 커밋까지 추적합니다. 그들의 규모에서는 과한 변경 통제 위원회와 공식 기준선은 건너뛰지만, 누구도 프로덕션에서 설정을 직접 편집하게 두지 않습니다. 그 하나의 지름길이 릴리스를 나중에 재현할 수 없게 만드는 것이기 때문입니다.

대기업. 한 대형 금융 서비스 회사는 모든 배포 가능한 산출물, 인프라 정의, 설정 데이터를 형상 통제 아래 둡니다. 모든 릴리스는 생성된 소프트웨어 자재 명세서를 갖춘 불변의 버전이 매겨진 기준선이며, 각 배포된 산출물은 특정 소스 리비전과 파이프라인 실행에 연결하는 서명된 출처 증명을 지닙니다. 일상적인 애플리케이션 변경은 자동 파이프라인 관문을 지나고, 공유 플랫폼 기준선이나 규제 대상 결제 흐름의 변경은 변경 통제 위원회로 갑니다. 상태 회계는 버전 관리, 산출물 레지스트리, 파이프라인에서 자동으로 생성되므로, 감사자는 재구성을 요구하는 대신 살아 있는 기록을 질의합니다.

정부. 한 국방 프로그램은 IEEE 828에 맞춘 공식 SCM 계획을 따릅니다. 형상 항목이 나열되어 계약상 이정표에서 기준선이 되고, 변경 통제 위원회가 통제된 기준선에 대한 모든 변경을 승인하며 영향, 결정, 근거를 기록합니다. 기능 형상 감사는 전달된 시스템이 명세된 요구사항을 충족하는지, 물리 형상 감사는 전달된 산출물이 기록된 형상과 정확히 일치하는지 확인합니다. 릴리스는 통제된 입력에서 재현 가능하고, 체크섬이 매겨지고, 승인된 요구사항에서 변경 요청을 거쳐 전달된 빌드까지 끝에서 끝까지 추적 가능하며, 이것이 바로 인증과 감독이 요구하는 증거 흔적입니다.

비즈니스 사례: 동기, ROI, TCO

SCM은 시스템의 수명 전체에 걸쳐 위험과 비용을 통제하려고 존재합니다. 수익은 재현 가능성과 추적성에서 옵니다. 어떤 릴리스든 다시 만들고, 결함을 그것을 일으킨 변경까지 추적하고, 감사 질문에 고고학이 아닌 기록으로 답할 수 있습니다. 그러면 인시던트 진단 시간이 줄고, 감사의 비용과 길이가 줄고, 아무도 무엇이 돌아가는지 또는 어떻게 다시 빌드하는지 말할 수 없는 비싼 부류의 실패를 막습니다.

총소유비용은 자동화에 유리합니다. 수동 형상 기록은 시작하기 싸고 유지하기 꾸준히 비싸며, 현실에서 벗어났기 때문에 가장 필요한 때, 즉 인시던트나 감사 중에 실패합니다. 자동 식별, 회계, 감사는 선행 비용이 더 들지만 형상 기록을 전달 파이프라인의 거의 공짜 부산물로 바꿉니다. 리더십을 설득하려면 SCM을 릴리스를 재현 가능하게 하고 변경을 감사 가능하게 만드는 통제로 설명하고, 재현할 수 없는 릴리스, 길어진 감사, 통제되지 않은 변경의 컴플라이언스 위험의 비용과 견주십시오.

안티패턴과 함정

부족 지식에 의한 형상: 릴리스의 실제 내용이 어떤 기록이 아니라 엔지니어의 머릿속에만 있는 것.
가변 기준선: “릴리스”가 제자리에서 편집되어 더는 재현하거나 기준으로 신뢰할 수 없는 것.
통제되지 않는 설정 데이터: 코드는 버전 관리되지만 그 동작을 바꾸는 설정은 프로덕션에서 임시방편으로 편집되는 것.
변경 통제 연극: 모든 것을 도장 찍어 실제 정밀 검토 없이 지연만 더하는 위원회.
수동 상태 회계: 실제 배포된 것과 조용히 갈라지는 버전의 스프레드시트.
재현 불가능한 빌드: 통제된 입력에서 다시 빌드할 수 없어 감사와 재빌드가 추측이 되는 릴리스.
추적 불가능한 릴리스: 배포된 산출물에서 소스 리비전, 변경 요청, 승인까지의 대응이 없음.

성숙도 모델

1단계(시작): SCM이 그때그때 이루어지고 반응적입니다. 소스만 통제되고, 릴리스는 손으로 조립되며, 기준선도, 무엇이 배포되었는지에 대한 신뢰할 수 있는 기록도, 과거 빌드를 재현할 방법도 없습니다.
2단계(발전): 기본 관행이 있지만 팀마다 다릅니다. 일부 시스템은 형상 항목과 변경 프로세스를 정의하고 릴리스를 버전 관리하고, 여기저기 기준선이 있지만, 기록은 부분적으로 수동이고 통제의 엄밀함은 조직 전반에서 일관되지 않습니다.
3단계(표준화): 관행이 문서화되어 조직 전체에서 시행됩니다. 공통 형상 항목 분류 체계, 불변 기준선, 계층화된 변경 통제, 상태 회계가 확립되어 대체로 자동화되고, 릴리스는 재현 가능하고 추적 가능하며, 감사는 기억이 아닌 도구가 뒷받침합니다.
4단계(관리): SCM이 데이터로 측정되고 통제됩니다. 재현율, 요구사항에서 배포된 산출물까지의 추적성 커버리지, 각 통제 계층을 통한 변경 리드 타임, 형상 표류 인시던트, 감사 지적이 기준선과 목표에 대해 추적됩니다. 편차는 시정을 촉발하고, 각 가부 결정은 주장이 아닌 이 증거에 근거합니다.
5단계(오케스트레이션): SCM이 지속적으로 개선되고 조직 전체에 통합됩니다. 재현 가능한 빌드, SBOM, 출처 증명, 살아 있는 상태 회계로 완전히 자동화되고 지속적으로 검증되며, 프로세스는 전달, 보안, 감사에 엮여 있고, 위험과 전달 성과가 변함에 따라 증거에 근거해 통제를 폐기하고 범위를 다시 정하며 적응합니다.

논의를 위한 아이디어

오늘 통제된 입력에서 마지막 릴리스를 정확히 재현할 수 있으며, 얼마나 걸리겠습니까?
동작을 결정하지만 실제로 통제 아래 있지 않은 형상 항목은 무엇입니까? 특히 설정 데이터와 인프라는?
변경 통제가 위험에 따라 계층화되어 있습니까, 아니면 어디서나 획일적 오버헤드 또는 획일적 느슨함을 더합니까?
형상 기록은 어디에 있으며, 실제 배포된 것에서 얼마나 벗어났습니까?
내일 감사에서 어떤 증거를 낼 수 있으며, 그중 얼마가 기록이 아닌 재구성이겠습니까?
재현 가능한 빌드, SBOM, 출처가 감사가 자동으로 검증할 수 있는 것을 어떻게 바꿉니까?

핵심 요점

SCM은 소스만이 아니라 코드, 의존성, 인프라, 설정 데이터를 포함한 전체 형상을 통제합니다.
기준선은 불변의 기준점입니다. 변경은 막히는 것이 아니라 그에 대해 승인되고 기록됩니다.
상태 회계는 언제든 릴리스가 무엇을 담고 어떻게 거기에 왔는지 답할 수 있게 해야 합니다.
감사는 만들고 전달한 것이 기록된 형상과 승인된 요구사항과 일치하는지 검증합니다.
위험에 따라 통제를 계층화하고, 식별, 회계, 감사를 자동화해 기록이 전달의 부산물이 되게 하십시오.

참고 문헌과 더 읽을거리

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Configuration Management knowledge area
IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (configuration management process)
Jez Humble and David Farley, Continuous Delivery
Bob Aiello and Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World
NIST guidance on software supply chain security, software bills of materials (SBOM), and artifact provenance
CNCF and open standards for build provenance and attestation (as reference frameworks)