서론
지난번에는 ALPACA-template에서 Quality Gate를 '공정 말의 체크리스트'가 아니라, 다음 단계로 진행할 수 없는 상태를 막는 메커니즘으로 생각했던 내용을 작성했습니다.
하지만 게이트만 설치하는 것으로는 충분하지 않습니다. AI도 사람도 '테스트했습니다', '확인했습니다', '문제없습니다'라고 말할 수는 있지만, 그 설명만으로는 무엇을, 어떤 상태에 대해, 누가, 어떤 근거로 확인했는지를 나중에 추적할 수 없습니다.
그래서 template 버전에서는 Gate의 판정 자체와는 별개로, 검증 사실을 남기는 Evidence, Gate의 품질 평가와 진행 판단을 남기는 QGR, 변경이나 예외를 관리하는 CCR을 분리했습니다. 이번에는 이 3가지를 왜 분리했는지라는 관점에서 되돌아봅니다.
'검증했다'와 '진행해도 좋다'는 별개의 문제
ALPACA-template에서는 검증 흔적을 EVD (Acceptance Evidence)로 남기고 있었습니다. EVD에는 대응하는 요구사항・설계・테스트・Gate 등의 ID, 검증 방식, 대상 환경이나 commit, 실행 내용, 기대 결과와 실측 결과, 증거 저장소, 판정 등을 기록합니다.
여기서 중요했던 것은, Evidence가 있다는 것 자체를 공정 통과 판단으로 삼지 않은 것입니다.
예를 들어 자동 테스트가 성공했더라도, 업무 확인이 끝나지 않았을 수 있습니다. 반대로 사람이 화면을 확인했다고 해도, 그 대상 commit이 Gate 심사 시점과 다르면, 그 확인은 그대로 근거로 삼을 수 없습니다.
template 버전에서는 검증 방식을 automated / human / external
,
조작 리스크를 normal / controlled
으로 나누고 있었습니다. 자동화할 수 있는지와 실행해도 되는 조작인지는 같은 축에 두지 않기 위해서입니다.
| 관점 | 무엇을 답하는가 |
|---|
| Evidence | 실제로 무엇을 확인/실행했는가 |
| ... | |
| 이 분리는 만들어보니 상당히 중요했습니다. 특히 AI를 사용할 경우, '테스트가 통과했다'부터 '완료했다'까지를 한 번에 단축하기 쉽기 때문입니다. | |
QGR은 '검사 결과'와 '진행 판단'을 하나로 묶지 않는다
Gate 심사에서는 QGR (Quality Gate Report)을 만들고, 대상 commit이나 성과물, 설정, 이관 정보를 스냅샷으로 고정했습니다.
그 위에서 qa-reviewer가 품질상의 권장 사항을 기록하고, Project Owner가 다른 란에 진행 판단을 기록합니다.
성과물・Evidence
↓
QA가 품질을 평가
...
이 이단계로 나눈 이유는, 품질을 평가하는 사람과 리스크를 수용하고 진행을 결정하는 사람의 책임을 섞지 않기 위해서입니다.
QA가 '합격'이라고 적었다고 해서 자동으로 다음 단계로 넘어가는 것은 아닙니다. 조건부라면, 그 조건과 잔존 리스크를 Owner가 확인해야 합니다. 반대로, Owner가 진행하고 싶다고 해서 QA의 검사 결과를 수정할 수도 없습니다.
지금 돌아보면, 이것은 AI 개발에서 특히 중요했던 경계였다고 생각합니다. AI에게 평가도 판단도 구현까지 전부 시키면, 자기 채점(self-grading)이 되기 쉽기 때문입니다.
변경은 '나중에 문서를 맞추는 것'이 아니라, 먼저 기표한다
또 하나 나눈 것이 CCR (Change Control Register)을 통한 변경・일탈 관리였습니다.
승인된 요구사항, 설계, 시험 범위, 운영 방식을 바꿀 경우, template 버전에서는 CHG를 먼저 기표하고, 영향 분석과 승인을 거쳐서 정본을 바꾸는 흐름으로 했습니다. 코드를 먼저 고치고 나중에 사양서를 맞추는 진행 방식은 피하기 위해서입니다.
예를 들어, 어떤 API의 인증 방식을 도중에 변경한다고 가정해 봅시다. 코드만 수정하면, 요구사항, 설계, 시험, 운영, 권한, 릴리스 절차 중 어디까지 영향을 미쳤는지 모호해집니다.
변경 관리에서는 무엇을 바꿀지 기표하고, 영향받는 요구사항・설계・코드・시험・운영을 확인하며, 대안이나 리스크를 정리한 후 승인 후에 정본을 개정합니다. 그 후에 재검증하고 Evidence와 Gate로 돌아갑니다.
'변경 관리'라고 하면 무거운 절차처럼 보이지만, 본질은 변경 자체보다, 변경으로 인해 무엇이 무효화되었는지 놓치지 않는 것입니다.
예외를 인정한다면, 기한과 범위도 함께 남긴다
CCR에서는 변경 요구사항의 CHG뿐만 아니라, 기한이 있는 일탈을 나타내는 WVR도 다루었습니다.
예를 들어 중간 정도의 지적이 남아있지만, 영향 범위를 한정하여 다음 공정으로 진행하고 싶을 때입니다. 그때 '이번에는 괜찮다'라는 구두 판단에 의존하지 않고, 책임자, 기한, 허가하는 범위, 재확인 방법을 기록합니다.
한편, 모든 것을 WVR로 회피할 수 있게 만든 것은 아니었습니다. 법규(法令), 보안(セキュリティ), 고중대도 지적 사항, 필요한 인간/외부 확인(human / external確認), 통제 대상 작업의 승인 부족 등은 예외적으로 처리하지 않는다는 취급입니다.
이러한 생각은 지금도 중요하다고 생각합니다. 예외를 없애는 것보다, 예외를 정상 상태로 만들지 않는 것이 더 중요하기 때문입니다.
3가지를 분리함으로써 좋았던 점
EVD, QGR, CCR을 분리함으로써 '완료됨'이라는 한 마디를 상당히 해체할 수 있게 되었습니다.
- EVD: 무엇을 확인했는지
- QGR: 그 결과를 어떻게 품질 평가했는지
- CCR: 무엇을 변경했는지, 무엇을 예외로 남겼는지
더 나아가 QGR 내에서도 QA의 품질 권장(品質推奨)과 Owner의 진행 판단(進行判断)을 분리했습니다.
이 구조를 통해 '테스트 결과는 있지만 대상 commit이 다른 경우', '조건부 합격이지만 WVR이 기한 만료인 경우', '사양 변경했는데 구 Evidence를 참조하는 경우'와 같은 모순을 적어도 문서 구조상으로는 찾기 쉬워졌습니다.
AI에게 맡길 수 있는 범위가 넓어질수록, 이처럼 사실(事実)・평가(評価)・판단(判断)・예외(例外)의 경계는 중요해집니다.
만들어보면서 알게 된 과제
한편, template 버전에서는 이러한 통제를 Markdown 표와 ID 참조로 상당히 표현했습니다.
EVD, QGR, CCR 각각에 ID가 있으며, commit, 산출물 hash, 지적 사항, WVR, 승인 이벤트를 상호 참조합니다. 설계 자체는 논리적으로 맞더라도, 사용자 입장에서는 '어디에 무엇을 작성할지', '어떤 ID를 참조할지'가 늘어나면서 Framework 자체가 무거워졌습니다.
또한, 추가형(追記型)으로 만들면서 이력은 남기기 쉬워졌지만, Markdown 표를 정본(正本)으로 하면서 엄격한 상태 전이(状態遷移)나 참조 정합성까지 지키려고 하니 CLI 측의 검사도 복잡해집니다.
여기는 template 버전을 만들면서 강하게 느낀 반성점입니다. 증적을 늘린다고 품질이 올라가는 것이 아니라, 필요한 증거를, 필요한 입자(粒度)로, 기계적으로 다룰 수 있는 구조를 만드는 것이 필요하다는 것입니다.
현재의 ALPACA-FW로 어떻게 이어졌나
현재의 ALPACA-FW에서도 '실행 사실', '품질 평가', '진행 판단', '변경・시정'을 분리하는 원칙 자체는 남아 있습니다.
다만, template 버전처럼 사람이 Markdown 장부를 올바르게 계속 작성하는 것에 강하게 의존하기보다는, 보다 기계 검증하기 쉬운 계약(契約)으로 옮기는 방향으로 재설계하고 있습니다.
구체적인 Evidence 모델이나 Gate, 변경・시정의 내부 구조는, template 버전의 기술 해부와 총괄이 끝난 후 Phase C에서 다시 다룰 예정입니다. 여기서는 template 버전에서 무엇을 지키려고 했는지, 그 배경만 짚고 넘어가겠습니다.
맺음말
ALPACA-template에서 Evidence, QGR, Change Management를 분리한 것은, 장표(帳票)를 늘리고 싶었기 때문이 아닙니다.
사실과 평가, 평가와 판단, 정상 상태와 예외를 섞지 않기 위해서였습니다.
AI가 고속으로 산출물을 만들 수 있을 만큼, '만들었다', '확인했다', '승인했다'를 하나의 상태로 묶지 않는 것이 중요합니다. 다음 시간에는 AI Session Plan / Handoff / Integration을 소재로, AI의 작업을 어디서 구분하고 어떻게 다음 세션으로 넘겼는지를 되돌아보겠습니다.
Discussion
