변경관리: 운영 중의 변경이 개발 때보다 무겁다 (07/08)

AI 시대의 운영·유지보수 · Ep.07

패치는 세 줄이었다.
영향은 세 시스템에 걸쳐 있었다.

변경관리: 운영 중의 변경이 개발 때보다 무겁다 · HFC Consulting

---

세 줄짜리 패치였다. 사소해 보였고, 변경통제위원회를 거치지 않고 담당자 판단으로 배포되었다. 이틀 뒤, 연계된 다른 시스템에서 이상 동작이 보고되었다. 원인을 추적하니 그 세 줄이었다. 개발 단계였다면 리뷰 한 번으로 걸러졌을 문제가, 운영 단계에서는 이미 퍼진 뒤에야 발견되었다.

이번 화는 운영 중 변경관리가 왜 개발 중 변경관리보다 무거워야 하는지에 관한 이야기다.

오픈 전 가정 — 개발 때 쓰던 절차를 그대로 쓰면 된다

많은 조직이 운영 단계의 변경관리를 개발 단계 절차의 축소판으로 설계한다. 규모가 작으니 승인 단계도 줄이고, 리뷰도 간소화한다. 이 가정은 운영 중 변경의 위험이 개발 중 변경보다 작다는 것을 전제한다.

오픈 후 현실 — 작은 변경이 더 큰 파장을 만든다

개발 단계의 변경은 아직 살아있지 않은 시스템 안에서 일어난다. 운영 단계의 변경은 실시간으로 돈이 오가고 사람이 쓰고 있는 시스템 안에서 일어난다. 같은 세 줄이라도 폭발 반경이 다르다. 게다가 운영 시스템은 시간이 지날수록 다른 시스템과의 연계가 늘어나, 하나의 작은 변경이 예상 못한 경로로 퍼질 가능성이 커진다.

변경통제위원회(CCB)의 속도 문제, 즉 프로토타입발 범위 확장과 Agent 변경을 어떻게 통제할지는 4기 5화에서 다뤘다. AI Agent의 권한을 3분류로 나누는 기준은 3기 6화에서 다뤘다. 운영 단계의 변경관리는 이 두 원칙을 "이미 살아있는 시스템"이라는 조건 위에서 다시 적용하는 일이다.

AI가 코드 생산을 압축하면서 이 문제는 더 미묘해졌다. 세 줄짜리 패치도 이제는 AI가 몇 초 만에 제안한다. 제안이 빠른 만큼 검토를 건너뛰고 싶은 유혹도 커진다. 그러나 코드가 어떻게 만들어졌는지는 그 코드가 무엇에 영향을 주는지와 무관하다. 생성 속도와 영향 범위는 서로 다른 축이며, 하나가 빨라졌다고 다른 하나가 줄어드는 것은 아니다. 빠르게 만들어진 패치일수록 오히려 영향도 평가를 건너뛰지 않는 규율이 더 필요하다.

운영 변경관리 절차와 평가표

운영 변경관리 절차 (개발 단계와의 차이)

① 모든 변경은 규모와 무관하게 영향도 평가를 거친다 (개발 단계는 규모별 생략 가능, 운영 단계는 생략 없음).

② 연계 시스템 목록을 사전에 확인하고, 영향 가능성이 있는 시스템 담당자에게 통지한다.

③ 배포는 트래픽이 낮은 시간대로 고정하고, 예외 시 별도 승인을 받는다.

④ 배포 후 일정 기간 관찰 창(모니터링 강화 기간)을 의무화한다.

변경 영향도 평가표 (예시)

① 변경 대상 모듈과 코드 라인 수

② 연계된 시스템·배치·API 목록

③ 예상 영향 범위(사용자·업무·데이터)

④ 롤백 절차와 소요 시간

예상 반론과 대응

반론 — "모든 변경에 영향도 평가를 요구하면 사소한 패치도 며칠씩 걸린다. 운영 대응 속도가 느려진다."

대응 — 평가의 깊이를 규모에 따라 조정하면 된다. 연계가 없는 단순 수정은 약식 평가(체크리스트 확인)로 몇 분 안에 끝나고, 연계가 있는 변경만 정식 평가를 거친다. 핵심은 평가를 생략하는 예외를 두지 않는 것이지, 모든 평가를 동일한 무게로 하는 것이 아니다.

저트래픽 시간대 배포 원칙도 실무에서는 종종 타협의 대상이 된다. 급한 수정일수록 "지금 바로"라는 압박이 크기 때문이다. 그러나 배포 시점을 앞당겨서 아끼는 시간과, 사용자가 몰린 시간에 문제가 생겨 잃는 시간을 비교하면 답은 명확한 경우가 많다. 예외를 허용하되, 그 예외에는 반드시 더 높은 수준의 승인과 더 짧은 관찰 주기를 붙여야 한다. 예외가 일상이 되는 순간 원칙은 사라진다.

체크포인트 — 영향도 평가 생략 없음 / 연계 시스템 사전 확인 / 저트래픽 시간대 배포 원칙 / 배포 후 관찰 창 의무화 / 롤백 절차 사전 정의

이 절차를 무겁게만 설계하면 현장에서 우회로가 생긴다. "정식 절차를 거치면 너무 오래 걸리니 일단 조용히 반영하자"는 관행이 생기면, 절차는 있으나 지켜지지 않는 문서가 된다. 절차의 무게는 위험의 크기에 정확히 비례해야 하고, 그 비례 관계를 담당자들이 납득해야 자발적으로 따른다. 평가표의 목적은 통제가 아니라, 위험을 미리 보이게 만드는 것이다. 담당자가 평가표를 채우는 그 몇 분 동안, 스스로도 미처 생각하지 못했던 연계 지점을 발견하는 경우가 실제로 많다. 평가표는 남을 설득하는 문서이기 전에, 작성하는 사람 스스로를 점검하는 도구다. 그 점검을 건너뛰고 배포부터 하는 습관이 쌓일 때, 조직은 작은 변경들의 누적 위험을 아무도 모르는 채로 떠안게 된다. 그 위험이 실제로 터지는 날은 대개 가장 바쁜 날이고, 원인을 찾는 사람은 그 세 줄을 배포한 기억조차 흐릿해진 뒤다. 평가표 한 장이 그 흐릿함을 기록으로 남겨 둔다. 기록이 있으면 원인 추적은 몇 시간이면 끝나고, 기록이 없으면 추적 자체가 처음부터 다시 시작하는 새로운 조사 프로젝트가 되어 버린다.

개발 중의 변경은 되돌릴 여지가 있는 실험이다. 운영 중의 변경은 이미 사람이 쓰고 있는 현실에 손을 대는 일이다. 무게가 같을 수 없다.

📎 더 읽을거리

소프트웨어 진흥법 시행령 (국가법령정보센터) — 소프트웨어사업의 형상·변경관리 관련 규정 원문

HFC의 관점

귀사의 운영 변경관리, 개발 때 쓰던 절차를 그대로 쓰고 있지는 않습니까. HFC컨설팅은 운영 단계에 맞는 변경관리 절차와 영향도 평가 체계를 설계합니다.

changks@hfcconsulting.co.kr

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

본 연재의 문구·양식 예시는 법률 자문을 대체하지 않으며, 실제 발주·계약 시 법무 검토를 권장합니다.

---

📚 AI 시대의 운영·유지보수 (전 8화)

◀ 이전 편: 06 장애 대응: 자동복구 시대, 사람은 어디에 있는가

다음 편 ▶ 08 SM 계약과 성과: 다음 재계약을 준비하는 법 (완결)

연재 전체 보기 →