원문은 devopsdiary.blog에 게시되었습니다. "The Quiet Years" 시리즈의 R24 포스트입니다.

이 포스트의 초안 제목은 4월부터 제 발행 캘린더에 머물러 있었습니다: "60일 동안 24개의 리포지토리를 구축했습니다." 몇 주마다 한 번씩 제목을 훑어볼 때마다 숫자가 또 틀려 있었습니다. 24는 30이 되었고, 그다음은 41이 되었습니다. 60일은 5개월로 늘어났습니다. 저는 계속해서 글을 쓰지 않았는데, 결과적으로 이는 제가 내리지 않은 최고의 편집적 결정이 되었습니다. 왜냐하면 그 과정 어딘가에서 이야기는 단순한 숫자의 집계가 아니게 되었기 때문입니다.

기록을 위해 말씀드리자면, 숫자는 사실입니다. AIEOS (몇 주 전에 소개했던 프레임워크)는 이제 41개의 리포지토리(repositories)로 구성되어 있습니다: 소프트웨어 전달 수명 주기(software delivery lifecycle)의 15계층 모델, 멀티 에이전트 하네스(multi-agent harness), 브라우저 콘솔, Sherpa라는 이름의 CLI 가이드, 13개의 도구 어댑터(tool adapters), 그리고 아무런 감독 없이 이니셔티브를 수행할 수 있는 컨트롤 플레인(control plane)이 포함됩니다. 모든 리포지토리는 CI(지속적 통합) 하에서 실행됩니다. 어댑터들은 서명된 Sigstore 증명(attestations)을 생성합니다. 오케스트레이션 코어(orchestration core)는 100% 라인 커버리지(line coverage)를 달성했으며, Windows와 Linux 모두에서 452개의 테스트가 통과되었습니다.

하지만 저에게 물어봐야 할 가치가 있는 숫자는 다른 숫자입니다: 바로 0입니다. 두 달 동안 초록색 체크표시가 떠 있었음에도 불구하고, 제가 7월 1일에 감사(audit)를 수행했을 때 어댑터 적합성(adapter conformance)을 통과한 횟수는 0번이었습니다. 이 두 숫자 사이의 간극은 41이라는 숫자보다 저에게 더 많은 것을 가르쳐 주었습니다.

오마하의 3월은 무언가를 구축하기 좋은 날씨입니다

날씨는 흐리고, 온도는 34도이며, 할 수 있는 일은 아무것도 없습니다.

1월은 아이디어를 탐색하는 9개의 커밋(commits)이었습니다. 2월은 스캐폴딩(scaffolding) 단계였습니다. 3월은 24개의 리포지토리에 걸친 358개의 커밋이었으며, 그중 22개는 1일에는 존재하지도 않았던 것들입니다. 4월 9일까지 8개의 파이프라인 계층(pipeline layers)이 모두 구축되었습니다. 올해의 GitHub 기여(contributions)는 580여 건이었으며, 거의 대부분이 그 기간 안에 이루어졌습니다. 저는 30년 동안 소프트웨어를 출시해 왔지만, 이 정도의 속도에 근접한 결과물을 만들어 본 적이 없습니다. 수작업으로는 그 누구도 이 정도를 해낼 수 없습니다.

정직한 메커니즘: 저는 코드를 거의 쓰지 않았습니다. 대신 규칙(rules), 템플릿(templates), 프롬프트(prompts), 그리고 검증기(validators)를 작성한 다음, 모델이 이를 바탕으로 결과물을 생성하게 했습니다. 그리고 다음 결과물이 그 위에 구축되기 전에 모든 산출물(artifact)을 동결(frozen)시켰습니다. 그래서 사람들이 AI 지원 개발(AI-assisted development)로 모두가 자랑하는 그 속도가 진짜냐고 물을 때, 저는 그 속도의 저편에서 대답할 수 있습니다. 그것은 진짜입니다. 저에게 그것은 결코 질문이 아니었습니다.

질문은 제가 지난 3년 동안 다른 팀들에게 물어왔던 바로 그것이었습니다. 그것들이 제대로 작동하는지 어떻게 알 수 있습니까?

두 달간의 초록색, 실제 통과 횟수 0회

7월 1일, 저는 완료되었다고 여겨지는 단 하나의 어댑터(adapter)를 검증하러 갔고, 그 파이프라인(pipeline)에서 무언가가 제 눈을 사로잡았습니다. 서명(signing) 단계가 건너뛰어져 있었습니다. 빨간색(실패)이 아니었습니다. 건너뛰기(skipped)였습니다.

13개의 모든 어댑터에 대해 이 실타래를 풀어보니 전체 그림이 무너져 내렸습니다. 모든 적합성 작업(conformance job)이 continue-on-error: true 설정 하에 실행되고 있었습니다. 이는 실제로 어떤 일이 일어났든 상관없이 해당 단계를 성공으로 보고하도록 강제하는 설정입니다. 서명 단계는 실제 통과 여부에 따라 제어(gated)되었는데, 모든 어댑터의 최신 실행에서 이 단계가 건너뛰어졌습니다. 그런 게이트(gate)는 조건이 거짓(false)일 때만 건너뛰어집니다. 적합성 검사가 통과되지 않았던 것입니다. 단 한 번도. 어떤 어댑터에서도. 단 한 번도 말입니다. 제가 제 문서에서 설명해 왔던 도그푸딩(dogfooding) 루프는 존재하지 않았고, 그 무엇도 저에게 알려주지 않을 것이었습니다.

근본 원인은 모욕적일 정도로 평범했습니다. 한 어댑터의 CI 작업은 pytest를 설치하지 않았고, 그래서 어댑터는 실행할 것이 아무것도 없어 네 가지 기준 모두에서 실패했습니다. 나머지 11개는 테스트 하네스(test harness)가 보내지 않은 입력 키(input keys)를 읽으려 했습니다. 4월 말부터 매 실행마다, 어떤 작업도 수행하기 전에 KeyError가 발생하고 있었습니다.

그 감사(audit)가 있은 지 12일 후, 저는 에이전트(agent)가 생성하는 것과 실제로 검증된 것 사이의 간극을 설명하기 위해 Sonar의 용어인 "검증 부채 (verification debt)"를 채택한 포스트를 게시했습니다. 제가 그 정의를 작성하는 동안 두 달 치의 부채를 떠안고 있었다는 사실을 기록으로 남기고 싶습니다.

해결 작업은 마스크 (mask)를 삭제하는 것부터 시작되었습니다. 전체 복구 과정에서 가장 가치 있는 단일 변화는 YAML 한 줄을 제거한 것이었습니다. 이제 진정한 통과 (pass) 시에는 서명이 이루어지고, 진정한 실패 (failure) 시에는 빌드가 명확하게 중단됩니다. 그다음으로는 각 테스트 스위트 (test suite)가 자체적인 입력 계약 (input contract)을 선언하도록 하는 하네스 (harness) 재설계가 이루어졌으며, 컨테이너 이미지나 라이브 엔드포인트 (live endpoint)를 통해 스스로를 증명해야 하는 어댑터 (adapter)들을 위한 실제 픽스처 (fixtures)도 추가되었습니다. 7월 5일 기준으로, 13개의 모든 어댑터는 진정한 통과로부터 서명된 적합성 증명 (conformance attestations)을 생성하고 있었습니다.

7월 1일 이전 (마스크 처리됨)

  적합성 실패 (conformance fails)
...

단 하나의 YAML 키가 증거와 장식 사이의 차이를 만들었습니다. 건너뛰어진 서명 단계가 파이프라인 (pipeline) 내에서 유일하게 정직한 신호였습니다.

이제 초록색은 무언가를 의미합니다.

프레임워크가 계속해서 저자를 잡아냈다

v1.3은 7월 중순에 출시되었으며, 제가 좋아했던 다음과 같은 주장을 담고 있었습니다: 하나의 공유 엔진 (shared engine) 위에서 세 가지 드라이버(가이드 세션을 위한 Sherpa, 포인트 앤 클릭을 위한 콘솔, 무인 실행을 위한 "다크 팩토리 (dark factory)")가 작동한다는 것입니다. 그 후 저는 실제 모델이 루프 (loop)에 포함된 상태로 첫 번째 독먹기 (dogfood) 테스트를 실행했고, 통과한 실행 결과는 그 주장마저도 허위로 만들었습니다. 콘솔은 콘솔 자체의 테스트 픽스처 (test fixture) 외에는 프레임워크 어디에도 존재하지 않는 플로우 파일 (flow file)을 요구했습니다. 그것은 실제 키트 (kit)를 로드해 본 적이 없었습니다. 하나의 엔진 위에서 세 가지 드라이버가 작동한다는 것은 두 가지 경우에는 참이었지만, 제가 직접 수행한 검증 실행 덕분에 그 사실을 알 수 있었습니다.

같은 실행이었지만, 더 나쁜 발견이 있었습니다. 프레임워크의 두 번째 계명인 '승인 전 동결 (freeze-before-promote)'을 강제하는 함수는 완전한 테스트 스위트 (test suite)를 갖추고 있었지만, 실제 운영 환경에서의 호출은 전무했습니다. 철저하게 테스트되었지만, 호출된 적은 없었습니다. 불변성 (invariant)은 어쨌든 유지되었지만, 그것은 단지 관련 없는 버그가 우연히 동일한 경로를 차단했기 때문이었습니다. 만약 "안전 속성 (safety property)이 다른 결함에 의해 유지되었다"는 말이 당신을 불안하게 만들지 않는다면, 다시 한번 천천히 읽어보십시오.

같은 주에 CI에 Windows 러너 (runner)를 추가했습니다. 그것은 존재하기 시작한 지 45초 만에 인코딩 차이 (encoding gap)로 인해 실패했고, 이는 테스트 스위트 (suite) 역사상 최초로 완전히 정확한 Windows 실행으로 이어졌습니다: 435개의 테스트, 환경적 보조 도구 (environment crutches) 없음. 그 후 이틀 만에 10개의 차이가 해결되었으며, 각 차이는 커밋 메시지에서 닫혔다고 주장하는 대신, 먼저 실패하는 테스트를 통해 닫혔음이 증명되었습니다. 이를 기록하는 레지스터 (register)에는 형용사 대신 이름, 날짜, 그리고 증거가 담겨 있습니다.

속도가 실제로 가져다준 것

지난 5월에 저는 에이전트 (agent)가 작업의 20%이고 플랫폼 (platform)이 나머지 80%라고 썼습니다. 저는 다른 사람들의 에이전트에 대해 그렇게 썼습니다. 그것은 제 에이전트에도 해당하며, 저는 그 80%가 즉흥적으로 만들어지지 않도록 플랫폼 측면을 특별히 구축했습니다.

AI의 지원을 받아 전속력으로 빌드하는 5개월이 어떤 것인지 사람들이 물을 때, 제가 지금 주는 답변은 이것입니다. 생성 (Generation)은 저렴한 부분이며, 리포지토리 (repo) 개수가 더 이상 흥미롭지 않을 정도로 충분히 저렴합니다. 초록색 체크표시는 누군가가 설정한 주장일 뿐입니다. 증거는 그것을 허위로 입증하려는 시도에서 살아남는 것이며, 그 둘 사이의 거리는 검토되지 않은 YAML 키 (key) 하나였습니다. 그리고 스스로는 실행하지 않을 거버넌스 시스템 (governance system)은 슬라이드 덱 (slide deck)입니다. 저의 시스템은 지난 7월 한 달 동안 저 자신을 네 번이나 잡아냈으며 (가려진 준수성 (masked conformance), 유령 드라이버 (phantom driver), 강제되지 않은 불변량 (unenforced invariant), 인코딩 버그 (encoding bug)), 각각의 포착은 약 한 시간 동안은 당혹스러웠지만 그 이후로는 영구적인 지지대 (load-bearing)가 되었습니다.

진부한 제목은 개수를 성과로 취급했습니다. 5개월이 지난 지금, 그 개수는 조직에서 가장 흥미 없는 유물입니다. 제가 실제로 여러분께 보여주고 싶은 것은 제 자신의 체크표시를 거짓말쟁이라고 지적한 7월 1일의 감사 (audit)와, 그 이후로 거짓말을 하는 것을 구조적으로 어렵게 만든 파이프라인 (pipeline) 변경 사항들입니다. AI는 기꺼이 여러분을 위해 41개의 리포지토리를 구축해 줄 것입니다. 그것들을 신뢰할 수 있는지 여부는 여전히 여러분의 몫입니다.

Todd Linnertz는 30년의 엔터프라이즈 엔지니어링 (enterprise engineering) 경험을 보유한 시니어 솔루션 엔지니어 (Senior Solutions Engineer)입니다. 그는 소프트웨어 전달 (software delivery) 팀을 위한 오픈 소스 AI 거버넌스 (AI governance) 시스템인 AIEOS의 제작자입니다. devopsdiary.blog 및 github.com/wtlinnertz에서 그를 찾아보세요.