원문은 devopsdiary.blog에서 처음 게시되었습니다. "Governing AI in the Enterprise" 시리즈의 F-AID3 포스트입니다.

방금 플래그(flag)를 표시한 대상을 스스로 수정하는 검증기(validator)는 직업을 그만둔 것이나 다름없습니다. 채점하는 것을 멈추고 같은 동작으로 숙제를 직접 하기 시작했기 때문이며, 이제 당신은 결과물의 어느 부분을 신뢰해야 할지 알 수 없게 됩니다.

저는 현재 모든 이들이 출시하고 있는 툴링(tooling)에서 이 문제를 계속 마주하고 있습니다. AI 개발(AI-dev) 벤더들은 지난 1년 동안 많은 좋은 아이디어로 수렴해 왔습니다. 그중 대부분은 제가 훔치고 싶을 정도입니다. 하지만 그중 하나는 제가 싸워야 할 대상인데, 왜냐하면 그것이 애초에 전체 설정을 거버넌스(governable) 가능하게 만들었던 단 하나의 속성을 조용히 깨뜨리기 때문입니다.

먼저 좋은 것들부터 살펴보겠습니다. 저는 오직 안 된다고 말하기 위해서만 나타나는 사람이 되고 싶지는 않습니다.

훔칠 가치가 있는 세 가지 아이디어

첫 번째는 용어입니다: 검증 부채 (verification debt). Sonar는 에이전트(agent)가 기본적으로 생성하는 품질과, 장기적으로 운영되는 비즈니스 핵심 앱(business-critical app)이 실제로 필요로 하는 품질 사이의 간극을 명명하기 위해 이 용어를 사용해 왔습니다. 그 간극은 항상 존재해 왔습니다. 우리는 예전에 이를 "기술 부채 (tech debt)\

셋째, 그리고 이것은 실질적인 파급력이 있는 방법입니다: 섀도 테스트 (shadow testing). 새로운 에이전트(agent)를 실제 에이전트와 병렬로 실행하되, 쓰기 경로(write path)는 비활성화하고, 에이전트가 수행했을 작업과 실제로 일어난 일을 비교하십시오. 한 급여 자동화(payroll-automation) 팀은 단지 몇 주 동안 에이전트를 어둠 속에서 실행하며 인간과 비교하여 점수를 매기는 것만으로, 프로덕션(production)에 적용하기도 전에 에이전트의 정확도를 70%에서 98%로 끌어올렸습니다. 이것이 가능한 이유는 섀도(shadow)가 실행되는 동안 라이브(live) 버전은 동결되기 때문입니다. 동일한 입력, 부작용(side effects) 없음, 정직한 비교. 이것은 제가 에이전트 분야에서 본 가장 절제된 테스트 아이디어이며, 제가 이미 믿고 있던 원칙과 깔끔하게 일치합니다: 제대로 작동하는 것을 관찰하지 않았다면 승격(promote)시키지 마십시오.

여기까지는 모두 동의할 만합니다. 하지만 여기서부터 제 의견은 갈립니다.

제가 받아들일 수 없는 것

Sonar의 프레임워크에는 그들이 Solve라고 부르는 단계가 있습니다. 검증기(validator)는 단순히 문제를 찾는 데 그치지 않습니다. 그것은 문제를 해결합니다. 버그를 찾고, 패치(patch)를 작성하고, 루프를 닫습니다. 이 모든 과정이 코드가 괜찮은지 여부를 알려주는 것이 본업인 바로 그 구성 요소 내부에서 일어납니다.

왜 이것이 데모에서 잘 먹히는지 이해합니다. 도구가 문제를 표시하고 동시에 해결하는 모습을 보는 것은 마법처럼 느껴집니다. 하지만 방금 당신의 감사 추적(audit trail)에 어떤 일을 저질렀는지 생각해 보십시오. 발견(finding)과 수정(fix)이 단 하나의 이벤트로, 단 한 명의 작성자로 붕괴되었습니다. 그리고 그 작성자는 코드가 잘못되었다고 결정한 바로 그 컴포넌트입니다. 당신은 채점하기 전에 채점자에게 당신의 답안을 수정하라고 요청한 것입니다. 그러면 당연히 A를 줄 것입니다. 그럴 이유가 없으니까요.

규제 대상인 작업 환경(regulated shop)에서 그 비용은 구체적이며, 월요일 아침에 닥쳐옵니다. 무언가 고장 난 채로 배포되면, 검토 위원회는 "무엇이 바뀌었는가, 누가 승인했는가, 그리고 체크 과정에서 실제로 무엇을 잡아냈는가"라고 묻게 되며, 당신은 이 질문들에 대해 세 가지 별개의 사실을 제시해야 합니다. 하지만 복구(remediate)를 수행하는 검증기는 이들을 하나의 줄로 뭉뚱그려 버립니다: 도구가 발견했고, 도구가 수정했으며, 깨끗한 상태로 승격함. 아무도 확인하지 않았습니다. 판단(judgment)과 개입(intervention) 사이에 간극이 없으며, 이는 판단이 옳았는지 물을 수 있는 발 디딜 곳이 없음을 의미합니다.

그리고 그 밑에는 폭발 반경(blast-radius) 문제가 숨어 있습니다. 검증기(validator)가 쓰기(write) 권한을 갖는 순간, 그것은 더 이상 읽기 전용(read-only) 관찰자가 아닙니다. 그 범위가 "보고하기 위해 살펴보기"에서 "코드를 변경하기 위해 살펴보기"로 확장된 것입니다. 이는 보안 태세(security posture)가 달라짐을 의미하며, 위협 모델(threat model)이 달라지고, 플랫폼 팀과의 논의 주제도 달라짐을 의미합니다. 하지만 대부분의 사람들은 이것이 하나의 기능(feature)으로 묶여서 제공되기 때문에, 이러한 논의를 전혀 거치지 않은 채 이를 채택합니다.

솔직한 반론

이것이 완벽한 승리인 것처럼 가장하고 싶지는 않습니다. Solve를 향한 이끌림은 실재하며, 이를 만드는 사람들은 바보가 아닙니다.

빠른 피드백(fast feedback)은 좋은 수치를 얻는 방법입니다. 수정 사항이 발견 직후 0.5초 만에 적용될 때, 반복 속도(iteration speed)는 천정부지로 치솟으며, 여기에는 진정한 보상이 걸려 있습니다. 즉, 사람이 코드 한 줄을 검토하기도 전에 편집 단계에서 10개 중 9개의 이슈를 잡아냈다는 식의 보고를 하는 팀들이 생겨납니다. 만약 제가 엄격한 규칙으로 '검증 및 수정(validate-and-remediate)'의 붕괴를 금지한다면, 저는 그 속도 중 일부를 포기하는 셈이 됩니다. 엄격한 "안 돼"에는 비용이 따르며, 그렇지 않다고 말하는 사람은 누군가에게 무언가를 팔고 있는 것입니다.

따라서 문제는 수정(remediation)이 가치 있는가 하는 점이 아닙니다. 분명히 가치가 있습니다. 문제는 그것이 검증기(validator) 내부에 속해야 하는가이며, 제 대답은 여전히 "아니오"입니다.

AIEOS가 지향하는 지점

제가 구축하는 불변량(invariant)은 검증기는 판단할 뿐, 도움을 주지 않는다는 것입니다. 제가 그렇게 말할 때, 사람들은 이를 "아무것도 자동 수정하지 마라"로 듣곤 하는데, 제 의도는 그것이 아닙니다. 원하는 만큼 자동 수정(auto-fix)을 하십시오. 다만 채점자(grader)가 펜을 쥐게 하지는 마십시오.

실제로 수정(remediation)은 자체적인 작성자(author)를 가진 별개의 산출물(artifact)입니다. 수정 에이전트(remediation agent)는 검증기의 판결(verdict)을 소비하여 변경 사항을 제안합니다. 그 변경 사항은 고정된 기준선(frozen baseline)으로부터 다른 모든 변경 사항과 마찬가지로 동일한 게이트를 통과해야 하며, 그 자체의 가치로 이를 통과해야 합니다. 판결과 수정은 두 개의 이벤트, 두 명의 작성자, 두 개의 타임스탬프(timestamp)로 유지됩니다.

  에이전트 출력 (Agent output)
       |
       v
...

검증기(validator)는 판결을 내리고 멈춥니다. 별도의 수정 에이전트(remediation agent)가 해결책을 제안하며, 이는 다른 변경 사항과 마찬가지로 동일한 승인 게이트(promotion gate)를 통과해야 합니다. 두 명의 작성자, 두 개의 이벤트, 하나의 감사 추적(audit trail)이 남습니다.

당신은 속도를 유지합니다. 당신은 감사 추적을 유지합니다. 당신이 포기하게 되는 것은 애초에 당신의 것이 아니었던 것, 즉 검사와 치료가 무엇인지 누구도 놓치지 않으면서 동일한 행위가 될 수 있다는 생각입니다. '승인 전 동결(Freeze-before-promote)'이 하중을 견디는 핵심 작업을 수행합니다. 수정 사항은 스마트한 도구에서 나왔다는 이유로 줄을 건너뛸 수 없습니다. 다른 모든 것과 마찬가지로 게이트를 통과하거나, 아니면 배포되지 않습니다.

내가 아직 찾아내지 못한 부분

수정(remediation)이 검증기(validator) 안에 존재하지 않는다면, 그것은 어디에 존재해야 할까요? 저는 작동하는 답을 가지고 있습니다. 자체적인 거버넌스(governance) 하에 있는 별도의 에이전트입니다. 하지만 이것이 최종적인 형태라고 확신하지는 않습니다. 어쩌면 그것은 일급 계층(first-class layer)일 수도 있습니다. 어쩌면 산출물 분리(artifact separation)에 대한 엄격한 규칙과 함께 검증(verification) 아래에 접혀 있는 하나의 관행일 수도 있습니다. 업계는 아직 이 문제를 해결하지 못했고, 저 또한 마찬가지입니다. 저는 다이어그램으로 이를 대충 덮어버리기보다는 차라리 솔직하게 말하고 싶습니다.

하지만 제가 고수할 단 한 줄의 원칙은 방어할 수 있을 만큼 충분히 좁습니다. 당신의 코드가 좋은지 결정하는 것이 코드를 좋게 만드는 역할까지 맡아서는 안 된다는 것입니다. 그 두 가지 직무를 두 개의 손에 나누어 두십시오. 그 두 직무가 합쳐지는 날, 당신은 당신이 가졌던 유일하고 정직한 신호(honest signal)를 자동화로 없애버린 것이며, 문제를 잡아내기로 신뢰했던 대상이 조용히 문제를 만들어내는 존재가 될 때까지 당신은 이를 알아차리지 못할 것입니다.

Todd Linnertz는 30년의 엔터프라이즈 엔지니어링 경험을 가진 시니어 솔루션 엔지니어(Senior Solutions Engineer)입니다. 그는 소프트웨어 전달 팀을 위한 오픈 소스 AI 거버넌스(AI governance) 시스템인 AIEOS의 창시자입니다. devopsdiary.blog와 github.com/wtlinnertz에서 그를 찾을 수 있습니다.