관리 ④ 변경·형상: 변경통제위원회의 속도 문제 (05/10)

AI 시대의 프로젝트 방법론 · Ep.05

변경요청서가 접수됐을 때,
변경은 이미 배포돼 있었다.

관리 ④ 변경·형상: 변경통제위원회의 속도 문제 · HFC Consulting

---

월간 변경통제위원회. 안건 14건이 상정됐다. 심의 중에 간사가 곤란한 얼굴로 보고한다. "이 중 아홉 건은 이미 반영되어 운영 중입니다. 사후 승인 안건입니다." 위원장이 묻는다. "그러면 우리는 지금 무엇을 심의하는 겁니까." 아무도 답하지 않는다. 위원회가 무력해서가 아니다. 변경이 생기는 속도가 위원회가 모이는 속도를 추월했기 때문이다.

변경관리는 방법론의 마지막 방어선이다. 범위도 일정도 품질도 결국 변경을 통해 무너지기 때문이다. 이 방어선이 형식이 되는 순간, 앞의 모든 관리가 장부상의 것이 된다.

전제 — 변경은 드물고 비싸다는 가정

변경통제위원회(CCB)와 변경요청서 절차는 변경이 예외적 사건이던 시대의 설계다. 변경 한 건의 영향 분석에 며칠이 들고 반영에 몇 주가 들던 환경에서는, 모든 변경을 모아 월간 위원회에서 심의하는 것이 합리적이었다. 변경의 발생 빈도와 심의 주기가 균형을 이뤘다.

균열 — 변경의 발생 속도가 심의 속도를 추월했다

균열은 두 방향에서 왔다. 하나는 요구 쪽 — 프로토타입이 빨라지자 범위 확장 요청이 회의 때마다 자란다. 다른 하나는 실행 쪽 — 1기 4화의 새벽처럼, AI Agent가 심의는커녕 인지도 없이 변경을 수행한다. 월간 위원회는 이 두 속도 앞에서 사후 추인 기관이 된다. 사후 추인이 반복되면 구성원은 배운다 — 먼저 하고 나중에 올리면 된다는 것을. 규정은 문서로 남고 관행이 실질 규정이 되는 순간이며, 그렇게 통제가 무너진다.

존속 — 승인의 원칙과 기준선은 흔들리지 않는다

지킬 것은 세 가지다. 합의된 기준선(범위·계약·아키텍처)의 변경은 반드시 권한 있는 심의를 거친다는 원칙. 모든 변경이 추적 가능해야 한다는 형상관리의 원칙. 그리고 변경의 영향을 실행 전에 따져 본다는 영향 분석의 원칙. 화석이 된 것은 원칙이 아니라 "모든 변경을 같은 절차에" 태우던 일률성이다. 통제의 강도를 변경의 위험도에 비례시키면, 위원회는 다시 살아난다.

재구성 — 일률 심의에서 위험도 3단 처리로

항목	AI 이전	AI 시대
처리 구조	전 변경 위원회 상정 (일률)	위험도 3단: 자동 허용 / 기록 후 보고 / 사전 심의 (3기 6화의 Agent 분류와 동형)
심의 주기	월간 위원회	기준선 변경만 위원회, 나머지는 상시 처리
변경 기록	수기 변경대장	형상관리·파이프라인의 자동 기록 + 결정은 ADR
Agent 변경	(개념 없음)	권한 분류표로 사전 정의, 미분류는 사전 심의 기본값

변경 분류 기준 — ① 기준선(범위·계약·아키텍처·대외 일정)에 닿는 변경: 사전 심의, 예외 없음 ② 공유 자산에 영향이 있으나 되돌릴 수 있는 변경: 기록 후 보고, 주기 확인 ③ 개발 내부의 가역적 변경: 자동 허용, 형상관리 기록만. 판단이 서지 않으면 한 단계 위로.

예상 반론과 대응

반론 1. "3단 처리는 위원회를 우회하는 통로가 되지 않겠습니까."
대응. 우회는 분류 기준이 모호할 때 생긴다. 그래서 ①의 기준선 목록을 착수 시점에 문서로 확정하고, "판단이 서지 않으면 위로"를 기본값으로 둔다. 지금의 실질적 우회 — 사후 추인 9건 — 보다 통제력은 오히려 강해진다.

반론 2. "발주 사업에서는 계약상 모든 변경에 절차가 필요합니다."
대응. 계약 변경과 내부 변경을 구분해야 한다. 과업범위·대가에 닿는 변경은 당연히 계약 절차(2기 3화의 재산정 트리거)를 따른다. 3단 처리는 그 아래층, 계약에 닿지 않는 일상 변경의 이야기다.

변경·형상 체크포인트 — 기준선 목록을 착수 시 문서화 / 위험도 3단 분류와 상향 기본값 / 기준선 변경만 위원회 심의 / 변경 기록의 자동화(형상관리·ADR) / Agent 변경은 권한 분류표와 연동

통제의 목적은 변경을 막는 것이 아니라 변경의 대가를 아는 상태에서 결정하게 만드는 것이다. 속도에 밀려 형식이 된 통제는 그 목적부터 되찾아야 한다. 이것으로 관리방법론 네 영역을 지났다. 다음은 개발방법론이다. 가장 오래 조롱받은 이름부터 다시 본다 — Waterfall은 정말 실패한 방법론이었는가.

※ 본 연재의 비교·재구성 원칙은 일반적 참고용이며, 조직의 표준과 사업 특성에 맞는 조정이 필요합니다.

📎 더 읽을거리
· 소프트웨어사업 계약 및 관리감독에 관한 지침 (국가법령정보센터) — 공공 사업 과업 변경 절차의 기준
· Architectural Decision Records (ADR) — 변경 결정의 기록 양식

HFC Consulting의 관점

변경관리 절차가 사후 추인 기관이 되어 있다면, 최근 3개월의 변경 안건 목록을 보내 주십시오. 3단 분류 기준의 초안을 함께 만들어 드립니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI 시대의 프로젝트 방법론
◀ 이전 편 (04/10) 관리 ③ 의사소통·보고: 주간보고는 누구를 위한 것이었나
다음 편 ▶ (06/10) 개발 ① Waterfall의 재평가
연재 전체 보기 →