변경 전 영향 범위 확인
Spec, PDK, Tool/Model Version, Project Rule, Permission 변화가 어떤 반복 절차, 업무 규칙, Check, Evidence 기준, Configuration과 Assumption에 영향을 주는지 먼저 확인합니다.
변경 · 유지 · 이관 · 운영
Engineer · Project · Tool이 바뀌어도, 검증된 방식과 판단 근거는 남아야 합니다
좋은 Harness는 변화를 막는 구조가 아니라, Spec · PDK · Tool · Model · Rule · 사람과 Project가 바뀌었을 때 영향 범위와 다시 확인할 항목을 찾을 수 있게 하는 구조입니다.
남겨야 할 것은 결과의 복사본보다 다시 확인하고 판단할 수 있는 구조입니다.반복 절차(Skill) · 업무 규칙(Policy) · 입력·출력 조건(Contract) · Evidence 기준 · Qualification Case · 판단 맥락 · Failure Learning이 그 운영 자산에 포함됩니다.
필요한 부분만 수정하고 Version 기록
영향 범위에 맞춰 필요한 부분만 수정(Update)하고 누가 무엇을 왜 바꿨는지 Version과 함께 남깁니다.
Regression과 Re-qualification
Normal뿐 아니라 Failure · Boundary · Stop/Escalation · Historical Bug를 다시 확인해 변경 후에도 정의된 Scope에서 사용할 수 있는지 검증합니다.
Release와 Rollback
어떤 Evidence로 Release했는지 남기고, 예상하지 못한 동작이 생기면 이전 검증 완료 Version(Qualified Version)으로 복구할 수 있게 합니다.
실패 원인과 재발 방지 반영 (Failure Learning)
운영 중 Failure → Root Cause 확인 → 수정에서 끝내지 않고 Regression Case · 업무 규칙(Policy) · Evidence 기준 · Stop/Escalation Rule로 다음 Version에 반영합니다.
다음 Engineer와 Customer가 운영할 수 있도록 이관합니다
검증된 구조를 새로운 Project/Tool/Provider에 그대로 복사하지 않고 달라진 Context를 확인해 필요한 Migration과 Re-qualification을 수행합니다. Customer가 운영 Owner, 검증 완료 Version과 변경 기준을 이해하고 직접 운영할 수 있게 합니다.
변경 관리는 AI 이전에도 하던 Engineering 업무입니다
AI의 강점은 Change Diff 확인, 영향 후보 탐색, 관련 문서·Script·Check·과거 Decision 검색, Update/Regression 후보 준비처럼 반복적 탐색·비교·정리의 부담을 낮추는 데 있습니다. 실제 Engineering Impact와 재검증 범위는 SoC 기준에 따라 판단하고, Harness에는 그 확인 절차와 실행 조건을 반영합니다.
사용→변경→영향 확인→수정→재검증→재사용
Customer가 직접 운영하는 AXCustomer가 어떤 기준으로 만들어졌는지 이해하고, Spec · Tool · Project가 바뀌었을 때 직접 수정 · Regression · Re-qualification하며 운영할 수 있는 능력을 남깁니다. 이것이 Customer 운영 이관(Operational Handoff)과 변경 환경에서의 재사용 가능성(Transferability)의 목표입니다.