AX LABS
← 블로그 AX Ops 방법론

산출물은 파일이 아니라 증거다

에이전트 결과물은 재현 가능해야 배포된다

AX LABS 6분 읽기

현장에서 에이전트 도입이 막히는 지점은 성능 데모가 아니다. 결과물은 그럴듯한데, 그 결과가 어떤 코드와 어떤 입력과 어떤 도구 호출에서 나왔는지 설명하지 못하는 순간 운영 승인이 멈춘다. 담당자는 다시 사람에게 확인을 맡기고, 에이전트는 파일을 만드는 보조 도구로 후퇴한다.

Artifact provenance bundle은 이 병목을 정면으로 다룬다. 에이전트가 만든 산출물을 단독 파일로 배포하지 않는다. 산출물, 코드, 환경, 입력 해시, 실행 로그, 검증 메타데이터를 하나의 배포 단위로 묶는다. SLSA v1.2가 provenance를 ‘어디서, 언제, 어떻게 만들어졌는지에 대한 검증 가능한 정보’로 정의한 방향과 맞닿아 있다. https://slsa.dev/spec/v1.2/provenance

결과 파일만 배포하면 운영은 추적을 잃는다

AI 산출물의 리스크는 틀린 답만이 아니다. 더 큰 리스크는 맞았는지 틀렸는지 나중에 확인할 수 없는 상태다.

보고서 PDF, 생성 코드, 분석 CSV만 저장하면 운영자는 세 가지를 모른다. 어떤 프롬프트가 들어갔는지, 어떤 문서 조각을 읽었는지, 어떤 도구가 어느 시점에 호출됐는지 모른다. 모델이 비결정적으로 동작한다는 사실까지 겹치면, 같은 사람이 같은 요청을 다시 넣어도 같은 결과를 보장하지 못한다.

그래서 목표는 ‘토큰 단위 동일 재생’이 아니다. 목표는 감사 가능한 재현이다. 같은 입력과 같은 실행 조건을 복원하고, 차이가 나면 어디서 차이가 났는지 좁힐 수 있어야 한다.

에이전트 산출물은 파일이 아니라 실행의 증거 묶음으로 배포되어야 한다.

번들은 산출물의 신분증이 아니라 사건 기록이다

Artifact provenance bundle은 단순 메타데이터 카드가 아니다. 산출물이 만들어진 사건 전체를 압축한 운영 패키지다.

구성 요소 담아야 할 내용 운영 질문
산출물 보고서, 코드, 데이터 파일, 중간 산출물 무엇이 배포됐나
코드 agent harness 버전, 워크플로 코드, 커밋 해시 어떤 로직이 실행됐나
환경 컨테이너 digest, 패키지 lockfile, MCP/tool manifest, 설정값 어디서 실행됐나
입력 해시 사용자 입력, 첨부 파일, RAG 문서 조각의 digest 무엇을 근거로 삼았나
실행 로그 tool call, stdout/stderr, 승인 이력, 오류, trace id 어떤 경로로 도달했나
검증 메타데이터 in-toto Statement, SLSA predicate, 서명, 정책 평가 결과 누가 어떻게 보증했나

GitHub Artifact Attestations는 GitHub Actions에서 산출물의 build provenance를 생성·검증하는 흐름을 제공한다. GitLab Runner도 artifact provenance metadata를 통해 in-toto Statement와 SLSA provenance 형식으로 빌드 산출물과 체크섬을 묶는다. 에이전트 산출물도 같은 원칙을 가져와야 한다. 차이는 빌드 로그 옆에 모델 호출, 검색 컨텍스트, 도구 호출, 사람 승인까지 포함된다는 점이다. https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations / https://docs.gitlab.com/ci/runners/configure_runners/#artifact-provenance-metadata

AX Ops에서는 번들을 파이프라인 산출물로 만든다

번들은 사후 문서화로 만들면 실패한다. 담당자가 릴리스 직전에 엑셀로 입력하면 이미 증거성이 깨진다. AX Ops에서는 에이전트 실행 하네스가 자동으로 번들을 만든다.

첫째, 실행 시작 시점에 run id를 발급한다. 모든 입력, 검색, 도구 호출, 승인, 산출물이 이 id에 묶인다.

둘째, 원문과 해시를 분리한다. 개인정보와 영업비밀은 보존 정책에 따라 별도 저장하고, 번들에는 digest와 접근 참조를 넣는다. 감사자는 원문을 무제한 복사하지 않고도 동일성 여부를 확인한다.

셋째, 관측 가능성 표준과 연결한다. OpenTelemetry는 2025년 이후 GenAI semantic conventions를 별도 영역으로 다루며 trace와 span의 공통 명명 체계를 확장하고 있다. 에이전트 운영에서는 이 trace id를 번들 manifest에 넣어, 장애 분석과 감사 흐름이 같은 기록을 보게 한다. https://opentelemetry.io/docs/specs/semconv/

넷째, 배포 게이트를 둔다. 번들이 없거나, 입력 해시가 비어 있거나, 승인 로그가 누락되면 산출물은 배포되지 않는다. 사람의 품질 검토와 시스템의 provenance 검증을 같은 게이트에 둔다.

재현 가능성이 에이전트 운영의 최소 조건이다

Artifact provenance bundle은 보안팀만의 과제가 아니다. 현업 승인, 내부감사, 장애 대응, 모델 교체, 벤더 변경을 모두 버티는 운영 단위다.

처음부터 모든 업무에 적용할 필요는 없다. 대외 제출 문서, 의사결정 보조 보고서, 코드 변경, 정산·심사·계약처럼 나중에 설명 책임이 발생하는 산출물부터 적용한다. 산출물 하나당 번들 하나. 이 규칙이 자리 잡으면 에이전트는 데모 도구가 아니라 운영 시스템이 된다.

AX Ops의 기준은 명확하다. 에이전트가 무엇을 만들었는가보다, 그 산출물을 다시 설명하고 검증하고 폐기할 수 있는가를 먼저 본다. 이 설계를 파이프라인에 넣는 순간 AI 도입은 사용률 관리에서 운영 통제로 넘어간다. 더 구체적인 적용 방식은 AX Ops 방법론 →에서 다룬다.

참고