8월 2일이 지나갔습니다. 그날은 컴플라이언스 (Compliance) 팀들이 2년 동안이나 표시해 두었던, EU AI 법 (EU AI Act)의 고위험 의무 사항이 발효되기로 했던 날이었습니다. 하지만 EU는 해당 의무 사항들을 대신 디지털 옴니버스 (Digital Omnibus) 패키지에 포함시켰고, 마감 기한은 2027년 12월로 연기되었습니다. 콜로라도의 AI 법은 제가 추적을 시작한 이후로 지연되거나, 법원에서 차단되거나, 다른 법으로 대체되기도 했습니다. AI 거버넌스를 강제하는 규제적 동력은 계속해서 뒤로 밀려나고 있습니다.

따라서 만약 귀사의 AI 거버넌스 프로그램이 그러한 날짜들 때문에 존재했던 것이라면, 이제 지연될 수 있는 16개월의 허락을 받은 셈입니다.

저는 이러한 지연이 유용하다고 생각합니다. 이는 실제로 가치가 있는 프로그램과, 단순히 카운트다운 시계가 달린 컴플라이언스 연극 (Compliance theater)이었던 프로그램을 구분해 줍니다.

마감 기한은 결코 이유가 아니었습니다

금융 서비스는 거버넌스를 실질적으로 만들기 위해 AI 법안이 필요하지 않았습니다. 연준 (Fed)은 이미 2011년에 모델 리스크 관리 (Model risk management)에 관한 지침인 SR 11-7을 발표했습니다 (그 지침은 Kubernetes보다 오래되었습니다). 은행들은 15년 동안 모델을 검증하고, 한계를 문서화하며, 모델의 동작에 대해 책임을 물어왔습니다. 이러한 역량은 하이프 사이클 (Hype cycle)보다 10년 앞서 형성되었습니다.

그리고 규제 대상 기업에서의 실제 압박은 법안의 발효일로부터 결코 오지 않았습니다. 그것은 무언가 고장 난 후, 조사관이 자리에 앉아 질문을 던지기 시작할 때 찾아옵니다. 9일 전 저는 Moody's와 Edward Jones에서의 제 커리어를 형성했던 네 가지 질문에 대해 글을 썼습니다. 그 질문들은 다음과 같습니다: 누가 이것을 승인했는가, 어떻게 롤백 (Roll back)할 것인가, 얼마나 많은 고객이 피해를 입을 수 있는가, 발생한 일을 어떻게 증명할 것인가. 어떤 AI 특화 법안도 이 질문들을 적용하게 만들지 않습니다. 이 질문들은 이미 적용되고 있기 때문입니다.

사고 (Incidents)는 자신들의 발효일을 공지하지 않습니다.

모델의 차이(diff)에 대해 던져지는 동일한 네 가지 질문

이 질문들은 AI 지원 인도 (AI-assisted delivery) 환경과 접촉하더라도 문제없이 살아남습니다. 다만 답을 구축해야 하는 위치가 이동할 뿐입니다.

누가 이것을 승인했습니까? 사람이 했거나, 혹은 아무도 하지 않았습니다. 모델은 자신의 출력물을 스스로 승인할 수 없습니다 (이에 대해 포스팅을 작성한 적이 있습니다). 이제 생성(Generation) 비용은 거의 제로에 가깝기 때문에, 승인이 희소 자원이 되었습니다. 귀사의 누군가는 누가 승인 권한을 가질지, 어떤 리스크 임계값(risk threshold)을 적용할지, 그리고 어떤 증거를 바탕으로 결정할지를 정해야 합니다. 대부분의 기업은 아직 이를 결정하지 못했습니다. 그저 PR(Pull Request) 대기열이 길어지고 있다는 사실만 인지하고 있을 뿐입니다.

어떻게 롤백(Roll back)합니까? 2019년 Moody's에서 저는 제가 여전히 따르고 있는 변경 관리(change-management) 규칙을 제안했습니다. 모든 변경 사항은 번들링(bundling) 없이 12시간 이내에 완료 및 롤백이 가능하도록 범위를 지정해야 한다는 것입니다. AI는 "이왕 들어온 김에"라는 유혹을 그 어느 때보다 강하게 만듭니다. 왜냐하면 추가적인 작업의 한계 비용(marginal cost)이 0으로 떨어졌기 때문입니다. 그럼에도 불구하고 원칙을 고수하십시오. 작고 가역적인(reversible) 변경은 인간이 작성할 때도 좋은 규율이었지만, 이제는 생존의 문제입니다.

얼마나 많은 고객에게 피해를 줄 수 있습니까? 폭발 반경(Blast radius)은 도구보다 상류(upstream)에서 관리되어야 합니다. 에이전트(agent)가 실행되기 전에 어떤 리포지토리(repo), 어떤 환경(environment), 어떤 데이터 클래스(data class)에 접근할 수 있는지 범위를 지정하십시오. 권한(Permissions)이 새로운 변경 창(change window)입니다. 도구가 무언가에 접근할 수 있다면, 언젠가 반드시 접근할 것이라고 가정하십시오.

무슨 일이 일어났는지 어떻게 증명할 것입니까? 과거에는 커밋 기록(commit trail)이 이야기의 시작점이었습니다. 이제는 이야기의 종착점입니다. 모델, 프롬프트(prompt), 컨텍스트(context), 그리고 인간의 검토(human review)가 모두 증거 기록(evidence trail)에 남아야 합니다. 왜냐하면 "AI가 그랬습니다"라는 말은 조사관(examiner)과의 첫 만남에서 살아남지 못할 것이기 때문입니다.

model ---+
prompt --+--> diff --> human review --> commit --> production
context -+
...

과거에는 커밋이 증거 기록의 시작이었습니다. AI 지원 인도 (AI-assisted delivery) 환경에서는 조사관이 원하는 모든 것이 커밋 이전에 발생합니다.

규제된 규모(Regulated scale)가 이제는 이점이 된다

제 30년 경력 중 처음으로, 금융 서비스의 운영 모델(operating model)이 앞서 나갈 수 있는 발판이 되었습니다.

Fiserv는 다른 모든 이들이 불평하는 것과 동일한 규제 제약 조건 하에서 이미 7,500명의 개발자를 위한 골든 패스 (golden paths)를 운영하고 있습니다. Edward Jones에서는 GitOps 도입 승인을 받아내는 데 6개월간의 아키텍처 검토가 필요했으며, 그 승인은 수년간 유지되었습니다. 수정 비용이 저렴할 때 모든 반대 의견이 표면화되었기 때문입니다. 느린 승인, 그리고 지속 가능한 신뢰. 이 패턴은 효과가 있습니다.

스타트업들은 지난 20년 동안 다른 요소, 즉 배포 속도 (shipping speed)를 최적화하는 데 시간을 보냈습니다. 그러다 생성형 AI (generation)가 저렴해지면서 배포는 더 이상 병목 현상이 아니게 되었습니다. 이제는 무엇을 배포했는지에 대해 책임을 지는 것이 제약 사항이며, 규제 대상 기업들은 DevOps라는 이름이 생기기 전부터 정확히 이 역량을 바탕으로 운영되어 왔습니다.

이 모든 이점을 완전히 상쇄해 버리는 한 가지 실패 모드 (failure mode)가 있으며, 저는 그것이 발생하는 것을 목격해 왔습니다. 바로 AI 코딩 도구를 인프라 (infrastructure)가 아닌 개발자 편의 도구로 분류하는 것입니다. Copilot은 파일럿 프로그램과 Teams 채널을 부여받은 반면, GitOps는 한 기업에서 6개월간의 정밀 조사를 거쳤습니다. 프로덕션 코드를 작성하는 도구는 인프라입니다. 인프라처럼 검토하고, 프로덕션에 영향을 미치는 다른 모든 요소에 요구하는 것과 동일한 롤백 (rollback) 기준을 적용하십시오.

16개월 동안 구축해야 할 것들

저렴하고, 구체적이며, 법령이 필요하지 않은 것들입니다.

먼저 인벤토리 (inventory) 파악부터 시작하십시오. 어떤 AI 도구가 사용되고 있는지, 어떤 저장소 (repos)에 접근하고 있는지, 누구의 승인 하에 있는지 확인하십시오. 대부분의 기업은 오늘날 이 질문에 답하지 못하지만, 이는 일주일이면 수행할 수 있는 작업입니다.

다음으로, 첫 사고가 발생한 후가 아니라 발생하기 전에 허용 가능한 사용 범위 (acceptable-use boundary)를 작성하십시오. 에이전트 (agents)가 무엇을 건드릴 수 있는지, 권한을 가진 인간의 개입이 필요한 것은 무엇인지, 완전히 금지된 영역은 무엇인지 정의하십시오.

그다음에는 계측 (instrument)하십시오. AI 지원 PR (Pull Request)에 대한 승인율 (acceptance rate), 검토 시간 (review time), 결함 유출률 (defect escape rate)을 측정하되, 벤더 대시보드 계층이 아닌 전달 계층 (delivery layer)에서 측정하십시오. 여러분이 직접 수집한 두 달 치의 데이터가 벤더가 보여주는 그 어떤 벤치마크 (benchmark)보다 강력합니다.

그리고 다른 누구보다 먼저 스스로를 감사(audit)하십시오. 저는 7월 1일에 제가 직접 만든 41개 리포지토리(repo) 프레임워크에 대해 감사를 실시했고, 두 달 동안 아무런 성과가 없었음을 숨기고 있던 초록색 체크표시들을 발견했습니다. 쓰라린 경험이었지만, 비용은 들지 않았습니다. 만약 규제 기관의 보고서에서 동일한 결과를 발견했다면 비용이 들었을 것입니다.

이 모든 과정은 브뤼셀(Brussels)이나 덴버(Denver)의 결정을 기다릴 필요가 없습니다.

마침내 2027년 12월이 다가왔을 때, 자신들만의 이유로 시스템을 구축해 온 기업들은 이미 운영 중인 통제 항목(controls)을 최종 부속서(annex)의 내용에 맞춰 매핑하는 데 일주일 정도만 소비할 것입니다. 반면 기다리기만 했던 기업들은 이자까지 붙은 채로 인벤토리(inventory) 단계부터 시작해야 할 것입니다.

마감 기한은 연기되었을지 몰라도, 질문들은 변하지 않았습니다.