Claude에게 시스템 아키텍처 문서(system architecture document)를 요청해 보세요. 그러면 결과물을 얻게 될 것입니다. 적절한 섹션, 자신감 넘치는 문체, 다이어그램, 그리고 합리적으로 들리는 트레이드오프(tradeoffs)까지 갖춰져 있을 것입니다. 마치 컨디션이 좋은 스태프 엔지니어(staff engineer)가 작성한 것처럼 보일 것입니다.

이제 그것이 맞는지 저에게 말해 보세요.

사실, 당신은 할 수 없습니다. 단순히 읽는 것만으로는 말이죠. AI가 문서를 잘 생성하게 만드는 바로 그 요소가 문서를 신뢰하기 어렵게 만드는 요소이기도 합니다. AI는 그럴듯한(plausible) 것을 생성하며, 그럴듯함은 타당함(sound)과는 거리가 멉니다.

저는 정확히 이 문제를 해결하기 위한 프레임워크를 구축하는 데 약 1년을 보냈습니다. 그것의 이름은 AIEOS입니다. 이것은 그것을 처음으로 제대로 살펴보는 자리입니다.

AI는 결정권자가 아니라 생성 엔진이다

이 문장이 핵심이기에 잠시 멈춰 생각해보겠습니다.

LLM(대규모 언어 모델)은 PRD(제품 요구 사항 문서), 테스트 전략(test strategy), 릴리스 계획(release plan), 사후 분석(postmortem) 등 거의 모든 엔지니어링 산출물의 초안을 작성하는 데 매우 능숙합니다. 하지만 그 초안이 기반으로 삼기에 충분할 만큼 좋은지 결정하는 데는 능숙하지 않습니다. AI에게 자신의 작업물을 검토하라고 요청하면 AI는 자기 합리화를 할 것입니다. 본인이 직접 쓴 것이니까요. AI는 그것을 채점하게 해서는 안 될 마지막 화자(narrator)입니다.

저는 몇 달 전, The Agent Is 20% of the Work에서 이 논쟁의 플랫폼 측면 버전을 다룬 바 있습니다. 에이전트(agent)는 쉬운 20%에 불과합니다. 그 주변을 둘러싼 지속 가능한 시스템이 나머지 80%이며, 프로젝트의 성패는 바로 그곳에서 결정됩니다. AIEOS는 AI가 전체 소프트웨어 라이프사이클(software lifecycle)에 걸쳐 명세(specs), 설계(designs), 기록(records)을 작성할 때 그 80%가 어떤 모습이어야 하는지에 대한 저의 해답입니다.

이를 지탱하는 세 가지 규칙

AIEOS는 세 가지 규칙에 따라 작동합니다. 서류상으로는 지루해 보일 수 있지만, 실제로는 엄청나게 중요합니다.

첫째, 분리(separation)입니다. 아티팩트(artifact)를 위한 규칙, 그것이 채워질 템플릿(template), 그것을 생성하는 프롬프트(prompt), 그리고 이를 심사하는 검증기(validator)는 모두 별개의 파일에 존재합니다. 프롬프트를 변경하더라도 무엇이 유효한지에 대한 기준(goalposts)을 은밀하게 옮기지 않게 됩니다. 대부분의 AI 작성 설정은 이 네 가지를 하나의 거대한 지침으로 통합해 버리며, 그 결과 지난주의 결과물은 통과했는데 이번 주의 결과물은 왜 통과하지 못하는지 아무도 설명할 수 없게 됩니다.

둘째, 승인 전 동결(freeze before promote)입니다. 어떠한 다운스트림(downstream) 작업이 시작되기 전에, 업스트림(upstream) 아티팩트는 동결됩니다. 아키텍처 문서(architecture document)가 그 위에 구축된 실행 계획(execution plan) 아래에서 몰래 변해서는 안 됩니다. 변경이 필요하다면 그것은 새로운 버전이며 명시적인 재동결(re-freeze) 과정이어야지, 은밀한 수정이 되어서는 안 됩니다. 빌드 도중에 요구사항이 바뀌는 것을 목격해 본 사람이라면 왜 이 규칙이 제 역할을 다하는지 알 것입니다.

셋째, 검증기(validator)는 심사할 뿐, 도와주지 않습니다. 검증기는 PASS 또는 FAIL을 반환합니다. 제안을 하지 않습니다. 초안을 다시 작성하거나 중간 지점에서 타협하지도 않습니다. 검증기가 돕기 시작하는 순간, 그것은 검증해야 할 대상과 협업하는 것이 되며, 당신은 다시 AI가 자신의 작업물을 스스로 승인하는 상황으로 되돌아가게 됩니다.

15개의 레이어, 그리고 루프(loop)

작업은 15개의 레이어로 구성됩니다. 처음 8개는 순차적인 파이프라인(pipeline)입니다: 전략(strategy), 제품 인텔리전스(product intelligence), 솔루션 소싱(solution sourcing), 엔지니어링 실행(engineering execution), 릴리스(release), 신뢰성(reliability), 인사이트(insight), 진단(diagnostics). 각 레이어는 단 하나의 질문에 답하고 다음 레이어로 동결된 아티팩트를 전달합니다.

나머지 7개는 횡단적 키트(cross-cutting kits)입니다 (품질(quality), 보안(security), 데이터(data), 인프라(infrastructure), 문서화(documentation), 피어 리뷰(peer review), 비즈니스 프로세스(business process)). 이들은 정해진 차례를 기다리는 대신 트리거(trigger)에 의해 작동합니다. 보안은 릴리스 뒤에 줄을 서서 기다리지 않습니다. 아티팩트 이벤트가 요구할 때 활성화됩니다.

그리고 이것은 루프(loop)입니다. 레이어 7인 인사이트 및 진화(insight and evolution)는 실제 운영(production)을 통해 배운 내용을 레이어 2로 다시 피드백하며, 그곳에서 다음 라운드의 제품 결정이 내려집니다.

전달(Delivery)은 아래로 흐릅니다. 학습(Learning)은 위로 루프를 그리며 돌아옵니다.

  1  Strategy
...

실체로 만드는 부분

화이트보드 위의 레이어 모델은 아무런 가치가 없습니다. 이와 같은 프레임워크의 경우, 진정한 테스트는 각 컴포넌트가 계약(Contract)에 명시된 대로 작동하는지 여부이며, 특히 Semgrep, Trivy, Syft, cosign, Flux와 같은 실제 도구들을 감싸는 어댑터(Adapter)들이 그러합니다.

AIEOS는 적합성 증명 (Conformance Attestation)을 통해 이를 처리합니다. 모든 어댑터는 고정된 계약 (Frozen Contract)에 대해 실제 출력을 검증하는 적합성 스위트 (Conformance Suite)를 통과해야 합니다. 통과 시, CI는 Sigstore를 사용하여 서명된 증명 (Signed Attestation)을 생성합니다. 즉, Fulcio를 통한 키리스 서명 (Keyless Signing)이 이루어지고, Rekor의 투명성 로그 (Transparency Log)에 기록됩니다. 현재 계약 버전에 대한 유효한 증명이 없다면 등록할 수 없습니다. 어댑터는 참여할 기회를 얻지 못합니다.

        Adapter output
             |
             v
...

저는 지난주에 이 작업을 모두 연결했습니다. 프레임워크 내의 40개가 넘는 모든 리포지토리 (Repo)에서 이제 CI가 실행됩니다. 13개의 모든 어댑터는

사람들이 "멀티 에이전트 (multi-agent)"라는 말을 들었을 때 상상하는 모습이 바로 이것이며, 이는 실제로 존재합니다. 또한 이는 불과 몇 백 줄의 코드에 불과합니다. 제가 이전에 설명한 모든 것들, 즉 명세 (specs), 동결 (freezes), 검증기 (validators), 그리고 서명된 증명 (signed attestations)이 실제로 1년이 걸린 부분입니다.

살펴볼 곳

AIEOS는 공개되어 있습니다. 코드는 github.com/wtlinnertz에 있습니다. aieos-governance-foundation부터 시작하세요. 그것이 전체의 뿌리입니다: 레이어 모델 (layer model), 키트 매니페스트 (kit manifest), 그리고 다른 모든 리포지토리 (repo)가 상속받는 구조적 규칙 (structural rules)이 여기에 있습니다.

미리 경고하자면, 저는 이 중 대부분을 약 1년에 걸쳐 혼자 구축했으며, 그 흔적이 불균형한 부분들에 나타나 있습니다. 어떤 키트 (kits)는 다른 것들보다 더 진척되어 있습니다. 하지만 중추 (spine)는 실재하며 테스트를 거쳤습니다. 이는 현재 "AI 거버넌스 프레임워크 (AI governance framework)"라는 라벨을 달고 있는 대부분의 것들에 대해 제가 말할 수 있는 것보다 더 나은 상태입니다.

이것이 핵심이기에 다시 한번 말씀드립니다. AI는 명세 (spec)를 작성할 수 있습니다. 하지만 그것을 승인할 수는 없습니다. 전체 프레임워크는 이 두 가지 작업이 서로 다른 손에 머물도록 유지하기 위해 필요한 모든 것입니다.