형상과 변경 기준선

코드는 마감 뒤 취소를 허용하지만 설명서는 금지한다고 쓰여 있습니다. 둘 다 파일로 존재해도 같은 제품 버전의 설명이라고 볼 수 없습니다. 형상 관리는 소프트웨어의 구성과 변경을 식별·통제·기록·확인하는 활동입니다.

구성 항목과 기준선

형상 항목은 관리할 대상으로 선택한 코드·요구·테스트·설정·문서 등입니다. 기준선은 검토한 구성을 특정 시점의 기준으로 확정한 것입니다. 변경이 불가능한 상태가 아니라 정한 절차로 차이를 관리할 기준입니다.

모임 기준선에는 R1~R6 정책, core.mjs, core.test.mjs, 실행·저장 안내를 함께 식별합니다. 커밋 ID가 있어도 어떤 정책이 수락됐는지와 검증 결과가 없으면 업무 기준선으로 충분하지 않을 수 있습니다.

변경 통제와 상태 기록

변경 통제는 요청의 이유·영향·승인 책임을 확인하고 적용 여부를 결정합니다. 상태 기록은 요청이 검토·적용·검증 중 어느 상태인지 남깁니다. 형상 감사는 실제 구성과 기록이 일치하고 정한 절차·요구를 만족하는지 확인합니다. 파일이 존재하는지 확인하는 것만으로 의미 검증까지 끝내지는 않습니다.

변경 ID: CH-03
이유: 마감 뒤 취소 안내가 재개로 오해됨.
영향: 안내 문구, R6 설명, 마감 취소 인수 사례.
결정: CLOSED 유지 정책에 맞추어 안내 수정.
적용 버전: 코드·문서 식별자와 함께 기록.
검증: 자동 회귀와 사용자 안내 검토를 각각 기록.

버전 도구가 돕는 범위

Git 같은 버전 관리 도구는 파일 차이와 기록을 추적합니다. 다음 명령은 저장소의 현재 파일 상태와 차이를 읽는 예입니다. 직접 만든 reading-lab이 Git 저장소가 아니면 실행할 필요가 없습니다.

git status --short
git diff -- core.mjs

브랜치는 변경 흐름을 분리하고 병합은 변경을 합칩니다. 자동 병합이 성공해도 요구 충돌이 사라지는 것은 아닙니다. 한쪽은 중복 먼저, 다른 쪽은 만석 먼저로 요구를 바꾸면 문법 충돌 없이도 정책 충돌이 생길 수 있습니다. 변경 후 회귀와 문서 일치를 확인합니다.

버전 이름과 내용의 식별은 다릅니다. examples/ch10.mjs는 저장 표현의 SHA-256 해시를 계산합니다. 해시는 같은 내용인지 확인하는 근거가 될 수 있지만 작성자의 승인이나 신뢰를 자동으로 증명하지 않습니다. 해시가 맞는 결함 파일도 가능합니다.

독립 문제: 코드는 같고 문서만 바뀔 때

마감 정책 설명을 고쳐도 코어는 원래부터 맞았습니다. 코드 커밋만 기준선이라고 생각한 팀은 릴리스 기록에서 이 변경을 빼려 합니다. 관리 대상과 검증을 어떻게 정할까요?

다음 문서는 기준선이 준비된 제품을 전달하고 문제에서 복구하는 흐름을 다룹니다.