_원문은 devopsdiary.blog에 게시되었습니다.

DORA는 그 어떤 것도 볼 수 없습니다. 애초에 그렇게 설계되지 않았기 때문입니다. DORA에게 AI가 생성한 코드를 평가해달라고 요청하는 것은 온도계에게 메뉴가 무엇인지 묻는 것과 같습니다. 잘못된 도구로 잘못된 질문을 하는 격입니다.

이것이 바로 DORA 대시보드가 건강한 팀들이 첫 번째 AI 관련 장애를 맞닥뜨렸을 때 속수무책으로 당하는 이유입니다. 지표가 거짓말을 한 것이 아닙니다. 단지 고장 난 부분을 지켜보고 있지 않았을 뿐입니다.

첫 번째 계층: 평가 (evaluation)

평가 계층은 특정한 질문에 답합니다. 'AI가 우리가 생각하는 대로 작동하고 있는가?'

제가 이 문제에 처음 직면했던 것은 AI 전환 로드맵 (AI transformation roadmap)을 초안으로 작성할 때였습니다. 당시 저희는 SDLC 워크플로우를 위해 Copilot과 모델 컨텍스트 프로토콜 (Model Context Protocol)을 탐색하고 있었고, 저는 기존의 DORA 대시보드를 가리키기만 하면 된다고 가정하며 측정 섹션을 작성하기 위해 자리에 앉았습니다. 하지만 그럴 수 없었습니다. AI 작업에 대해 제가 실제로 묻고 싶었던 모든 질문은 해당 대시보드가 살피지 않는 곳에 있었습니다. 제안된 코드가 정말 좋은가? 개발자들이 수락해서는 안 될 것들을 수락하고 있지는 않은가? 처리량 (throughput) 수치 아래에서 품질이 저하되고 있지는 않은가? 결국 로드맵에는 AI 생성 코드 품질을 위한 별도의 메트릭 트랙 (metrics track)이 포함되었는데, 당시에는 과하다고 느껴졌지만 지금은 최소한의 요구 사항처럼 느껴집니다.

두 번째 계층: 거버넌스 (governance)

Microsoft는 지난 4월 적응형 AI 거버넌스 (adaptive AI governance)에 관한 글을 발표했는데, 그중 가져올 만한 가치가 있는 부분은 피드백 루프 (feedback loops)에 관한 프레임워크입니다. 그들의 주장을 요약하자면 다음과 같습니다. AI를 위한 거버넌스는 정적인 정책 문서가 될 수 없습니다. 왜냐하면 모델, 유스케이스 (use cases), 그리고 리스크 (risks)가 모두 승인 주기 (approval cycle)가 따라잡을 수 있는 속도보다 더 빠르게 변하기 때문입니다. 따라서 거버넌스는 적응형 (adaptive)이어야 합니다. 적응형이라는 것은 어딘가로부터 신호 (signal)를 수집해야 함을 의미합니다.

그 '어딘가'가 바로 평가 계층 (evaluation layer)입니다.

이 부분이 대부분의 엔터프라이즈 프로그램이 실수하는 지점입니다. 그들은 거버넌스 위원회를 구성하고, 정책을 초안하며, 분기별 검토를 진행하지만, 실제 텔레메트리 (telemetry)를 루프에 전혀 연결하지 않습니다. 위원회는 모여서 벤더 문서를 읽고, 리스크 등급 (risk tiers)에 대해 토론한 뒤 해산합니다. 그들이 관리해야 할 AI 사용은 그들이 볼 수 없는 곳에서 일어나고 있습니다. 저는 이전 직장(배포를 '느낌'만으로 승인하던 변경 자문 위원회 (Change Advisory Board) 시절)에서 이러한 패턴의 수많은 버전을 겪어보았기에, 그 형태를 즉시 알아볼 수 있었습니다. 회의의 명칭은 바뀔지언정, 실패 모드 (failure mode)는 바뀌지 않습니다.

제대로 작동하는 거버넌스 계층 (governance layer)은 세 가지를 수행합니다. 첫째, 임계값 (thresholds)을 정의합니다. 즉, 신뢰하기에 너무 낮은 수락률 (acceptance rate)은 얼마인지, 어떤 오버라이드 (override) 패턴이 모델 퇴보 (model regression)를 나타내는지, 어떤 결함 상관관계 (defect correlation)가 용납 불가능한지를 정의합니다. 둘째, 이러한 임계값을 분기별 검토가 아닌 평가 계층 (evaluation layer)으로부터 지속적으로 가져옵니다. 셋째, '임계값 위반'에서 '도구 일시 중단 또는 범위 축소'로 이어지는 명확한 경로를 제공하며, 이 과정에서 6주간의 변경 관리 (change-management) 사이클을 요구하지 않습니다.

만약 평가 계층이 포착한 지표로부터 거버넌스 계층이 내리는 결정까지 일주일 이내에 선을 그을 수 없다면, 당신이 가진 것은 운영 위원회 (steering committee)일 뿐입니다.

출발지	도착지	흐름 내용
평가 계층 (수락률, 오버라이드, 결함 상관관계)	거버넌스 계층	신호 (Signal)
...	...	...
세 계층은 구성 요소를 이룹니다. 평가 계층은 거버넌스 계층에 정보를 제공하고, 거버넌스 계층은 행동하며, DORA는 그 행동이 효과가 있었는지를 알려줍니다. 어떤 계층이라도 빼버리면 루프 (loop)는 깨집니다.

왜 둘 다 필요하며, 왜 어느 하나도 선택 사항이 아닌가

한 계층이 누락될 경우, 두 계층은 서로 다른 방식으로 실패합니다.

거버넌스 계층이 없는 평가 계층은 아무도 조치를 취하지 않는 대시보드만을 만들어냅니다. AI 성능이 저하되는 것을 볼 수 있고, 그것이 일어나는 과정을 지켜보게 됩니다. 하지만 레버를 당길 권한이나 프레임워크가 아무에게도 없기 때문에 아무것도 변하지 않습니다.

평가 계층이 없는 거버넌스 계층은 정책 연극 (policy theater)을 만들어냅니다. 위원회는 모여서 직관이나 벤더의 슬라이드에 기반해 결정을 내리고, 코드베이스에서 일어나는 그 어떤 일과도 연결되지 않는 규칙들을 배포합니다. 개발자들은 그 규칙들이 현실을 반영하지 못하기 때문에 규칙을 우회합니다.

당신은 둘 다 필요합니다. 평가 계층은 신호를 생성합니다. 거버넌스 계층은 그 신호를 결정으로 바꿉니다. 두 계층의 하류 (downstream)에 위치한 DORA는 여전히 그 결정들이 효과가 있었는지를 알려줍니다. 이 중 하나를 건너뛰거나 나머지만으로 충분하다고 간주한다면, 결국 리더십에게 왜 AI 도입이 슬라이드에서는 훌륭해 보였는데 데모에서는 운영 환경 (production)을 망가뜨렸는지 설명해야 하는 상황에 처하게 될 것입니다.

내가 가장 먼저 구축할 것

다음 주에 플랫폼 팀에서 제로 베이스(starting from zero)로 시작한다면, 저는 다음과 같은 순서로 진행하겠습니다. 팀이 이미 사용 중인 AI 도구들이 무엇이든 간에, 그것이 아무리 투박하더라도 수락(acceptance) 및 오버라이드(override) 텔레메트리 (telemetry)를 구축하겠습니다. 한 달 정도는 웹훅 (webhook)과 SQLite 파일만으로도 충분합니다. 제가 실제로 조치를 취할 용의가 있는 임계값 (threshold) 세 가지를 선정하겠습니다. 임계값이 깨졌을 때 누가 의사결정 권한을 갖는지, 그리고 얼마나 빨리 행동해야 하는지를 한 페이지에 작성하겠습니다. 그런 다음 DORA 대시보드를 다시 살펴보고, 그것이 여전히 얼마나 필요한지 확인하겠습니다.

그것이 전부입니다. 두 개의 계층, 세 개의 임계값, 한 명의 의사결정권자. 그 형태는 슬라이드 덱 (slide decks)에서 보여주는 것보다 훨씬 단순합니다. 이를 설계하는 것은 쉬운 부분입니다. 어려운 부분은 지난 10년 동안 당신이 지켜봐 온 대시보드들이 더 이상 충분하지 않다는 사실을 인정하는 것입니다.