Aionda

2026-03-12

에이전트형 AI의 능동적 AIBOM

SBOM의 한계를 넘어 에이전트형 AI의 런타임·드리프트·악용 맥락을 기록하는 AIBOM을 다룹니다.

에이전트형 AI의 능동적 AIBOM

모델이 툴을 호출해 외부 서비스를 사용하고, 프롬프트가 수시로 바뀌고, 실행 환경이 조금씩 드리프트하면—그 결과를 누가 “같은 조건에서 재현”할 수 있나? 더 까다로운 질문도 있다. 그 행동이 보안 사고로 이어졌을 때, “무엇이 취약했는지”를 누가 어떤 증거로 설명할 수 있나? arXiv의 「SBOMs into Agentic AIBOMs: Schema Extensions, Agentic Orchestration, and Reproducibility Evaluation」(arXiv:2603.10057v1)은 이 문제를 직접 다룬다. 정적 의존성 목록인 SBOM만으로는 에이전트형 AI의 런타임 행동, 환경 드리프트, 악용 가능성의 맥락을 담기 어렵다. 그래서 ‘agentic AIBOM’을 “active provenance(능동적 프로비넌스)”로 제안한다.

세 줄 요약

  • 에이전트형 AI에서 정적 SBOM이 놓치는 런타임 행동·환경 드리프트·악용 가능성 맥락을 기록하려는 ‘agentic AIBOM(능동적 프로비넌스)’ 개념이 논의된다.
  • 재현성 평가와 취약성 평가는 **“무슨 코드가 들어갔나”**만으로 끝나지 않는다. **“무슨 조건에서 무엇을 했나”**를 포함하면, 감사·사고조사·공급망 보안에서 요구하는 증거의 형태가 달라진다.
  • 현재 SBOM에 모델/데이터/실행환경 메타데이터와 구성(설정) 정보를 먼저 붙인다. 에이전트 워크플로우에는 프롬프트·결정·툴 호출을 프로비넌스로 연결하는 최소 로그 설계를 파일럿으로 적용한다.

현황

SBOM(Software Bill of Materials)은 소프트웨어 공급망 보안에서 “무엇이 들어갔는지”를 문서화하는 대표 수단이다. 하지만 arXiv:2603.10057v1의 초록은 한계를 분명히 적는다. SBOM은 정적 dependency inventory라서 runtime behaviour, environment drift, exploitability context를 충분히 담지 못한다. 에이전트는 툴을 호출하고 외부 서비스를 경유한다. 정책/프롬프트가 바뀌고 실행 조건이 흔들릴 수도 있다. 정적 목록만으로는 재현성과 취약성 평가에 필요한 정보가 부족해질 수 있다.

그래서 논문은 SBOM을 agentic AIBOM으로 확장해 active provenance로 만들자고 한다(초록에 근거). 여기서 핵심은 “AI-BOM이라는 이름”이 아니라, BOM을 정적 구성표에서 행위와 조건까지 포함한 프로비넌스로 확장하려는 방향이다. 이 방향은 다른 연구들이 지적한 간극과도 연결된다. 예컨대 PROV-AGENT는 에이전트 워크플로우에서 prompts, responses, decisions 같은 에이전트 중심 메타데이터를 기존 프로비넌스 체계가 충분히 포착·연결하지 못한다고 지적한다.

스키마 관점에서 “최소로 무엇을 넣어야 하느냐”는 질문에 대해, 검색 결과로 확인되는 핵심 축은 비교적 보수적이다. 모델 메타데이터(이름/버전/아키텍처/프로비넌스), 데이터셋 메타데이터(출처/라이선스/전처리), 소프트웨어 의존성, 실행/배포 환경 컨텍스트, **구성(설정) 정보 및 모델-데이터 관계(추적성)**가 중심이다. 다만 프롬프트/정책, 툴 호출, 호출 로그/결정 근거를 “최소 필수 필드”로 규정하는 표준 합의 문서가 있다는 근거는 조사 결과에서 확인되지 않는다.

분석

agentic AIBOM의 핵심 가치는 “사고 대응”과 “재현성”을 한 증거 체계로 다루려는 데 있다. 에이전트는 단순히 라이브러리를 링크하는 프로그램이 아니다. 실행 중에 외부 툴과 데이터, 정책, 모델 설정이 얽힌 의사결정 시스템으로 동작한다. 이때 보안팀이 묻는 질문은 “어떤 패키지 버전이었나”로 끝나지 않는다. “어떤 프롬프트/정책이 어떤 툴 호출로 이어졌고, 어떤 실행 환경에서 어떤 결과가 나왔나”를 묻게 된다. 초록이 지적한 exploitability context는 이런 질문을 포함한다. 취약점이 ‘존재’하는 것과 ‘악용 가능’한 것은 다를 수 있다. 런타임 조건이 바뀌면 악용 가능성도 달라질 수 있다.

동시에, 이 접근은 로그와 증거 수집 범위를 넓히는 방향으로 흘러가기 쉽다. 그러면 컴플라이언스·프라이버시·기밀 요구사항과 충돌할 수 있다. 조사 결과에서 NIST AI RMF Playbook은 제3자 자원(모델/데이터/도구 등) 의존이 복잡성과 불투명성을 키울 수 있다고 경고한다. 또한 문서화(identify and maintain documentation)데이터 프로비넌스(documented … data provenance), 법적 요구사항(legal requirements) 확인을 권고한다. 다만 “어디까지를 감사 범위로 잡는가”, “민감 로그를 어떻게 마스킹·보관·접근통제하는가”, “책임소재를 어떻게 표준으로 강제하는가”에 대한 구체 가이드는 검색 결과만으로는 확인하기 어렵다. 결과적으로 AIBOM은 필요성 논의가 앞서고, 거버넌스 세부는 조직 설계로 남아 있는 상태로 보인다.

실전 적용

지금 팀이 할 수 있는 선택지는 “표준이 완성될 때까지 대기”만은 아니다. 기존 SBOM 체계에 붙일 수 있는 형태로 AIBOM을 얇게 시작하는 접근도 가능하다. 검색 결과로 확인되는 최소 축(모델/데이터/의존성/환경/구성/추적성)을 먼저 고정한다. 그다음 에이전트 특화 요소(프롬프트·결정·툴 호출)는 프로비넌스 이벤트로 연결하는 방식으로 파일럿을 붙인다. 핵심은 “모든 로그를 다 저장”이 아니라, 사고 조사·재현성에 필요한 증거 최소 단위를 정의하는 일이다.

예를 들어 에이전트가 외부 검색 툴과 사내 문서 저장소를 호출해 보고서를 쓰는 워크플로우라면, AIBOM은 다음의 “연결”을 남기는 쪽으로 설계한다. (1) 어떤 모델/데이터/코드 참조로 구성됐는지(무결성 옵션 포함), (2) 어떤 실행/배포 환경에서 돌았는지, (3) 어떤 구성(설정)으로 돌았는지, (4) 프롬프트/정책 변경과 툴 호출이 어떤 결과로 이어졌는지. 이때 민감정보가 섞이는 로그는 원문 저장 대신 요약·마스킹·접근통제 같은 운영 원칙을 먼저 세우는 편이 맞을 수 있다(표준 강제 근거는 없으므로 조직 정책으로 다룬다).

오늘 바로 할 일 체크리스트

  • 현재 배포 파이프라인의 SBOM 산출물에 모델/데이터/실행환경/구성 메타데이터를 덧붙이는 “부가 문서”를 만들고, 릴리스 아티팩트로 함께 보관하라.
  • 에이전트 워크플로우에 대해 툴 호출·프롬프트 변경·주요 결정을 이벤트로 남겨라. 민감정보는 처음부터 “저장 금지/마스킹/권한 분리” 규칙을 정해 수집하라.
  • 보안/감사 관점에서 “재현”이 필요한 시나리오(사고 조사, 규제 대응, 고객 문의)를 하나 고르고, 그 시나리오를 만족하는 증거 최소 세트를 역산해 스키마를 고정하라.

FAQ

Q1. AIBOM은 SBOM을 대체합니까, 아니면 붙는 겁니까?
A. 대체라기보다 보완에 가깝습니다. 조사 결과 기준으로는 기존 SBOM 같은 구성요소 인벤토리에 결합해, SBOM이 담기 어려운 모델·데이터·워크플로우·프로비넌스 정보를 문서화하는 방향이 제시됩니다.

Q2. AIBOM의 “최소 필수 필드”는 이미 정해져 있습니까?
A. 검색 결과만 놓고 보면, SBOM처럼 합의된 단일 “최소요소” 표준이 있다고 단정하기 어렵습니다. 다만 모델 메타데이터, 데이터셋 메타데이터, 소프트웨어 의존성, 실행/배포 환경, 구성(설정) 및 모델-데이터 추적성 같은 축은 핵심 구성요소로 반복해서 언급됩니다.

Q3. 프롬프트·결정·툴 호출 로그까지 AIBOM에 넣어야 합니까?
A. 필요성은 연구에서 언급됩니다. 예를 들어 PROV-AGENT는 프롬프트, 응답, 결정 같은 에이전트 중심 메타데이터를 기존 체계가 충분히 포착·연결하지 못한다고 지적합니다. 다만 이것이 “최소 필수 필드”로 표준화됐다고 보기는 어렵고, 조직의 리스크·프라이버시 요구에 맞춰 범위를 정하는 접근이 현실적입니다.

결론

agentic AIBOM은 SBOM의 “다음 버전”이라기보다, “구성표”를 “행위의 계보”로 확장하려는 시도다. 앞으로의 관전 포인트는 스키마 자체뿐 아니라, 런타임 증거(행동·환경·구성)를 어디까지 표준화할지에 있다. 동시에 프라이버시·기밀·책임 분장 요구사항을 그 범위 안에서 어떻게 다룰지도 함께 남는다.

다음으로 읽기


참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.

출처:arxiv.org