조직의 AI 자산 인벤토리

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

AI를 조직에 들이는 순간 보안팀이 먼저 풀어야 할 문제는 모델의 성능이 아니야. 우리 조직 안에 어떤 AI가 실제로 존재하는지 아는 일이야. 모델·에이전트·추론 파이프라인이 계정과 서버와 외부 API에 흩어져 있으면, 존재를 모르는 자산은 보안 점검의 대상에도 들어오지 못해.¹

한 줄로 말하면

AI 자산 인벤토리는 조직 안의 AI 자산을 찾아 목록으로 만들고, 각 자산이 올라간 인프라와 현재 보안 신호를 연결해 무엇을 먼저 확인할지 보여주는 구조야.

비유로 이해하기

큰 건물의 소방 점검을 한다고 생각해 보자. 방마다 어떤 전기기기가 있는지 모르면, 화재 센서를 달고 위험한 배선을 고치는 일도 시작할 수 없어. AI 자산 인벤토리는 건물의 기기 목록에 가깝고, 보안 가시성은 그 목록에 위치·상태·경보를 겹쳐 보는 일이야.

다만 인벤토리는 안전 판정표와 같지 않아. 목록에 올라왔다는 사실이 안전하다는 뜻은 아니고, 위험 신호와 수정 책임을 더 확인할 출발점을 얻었다는 뜻이야.

정확한 정의

AI 자산 인벤토리는 조직이 사용하는 AI 관련 자산을 발견하고, 분류하고, 기반 인프라와 연결하고, 보안 결과와 함께 조회하는 관리 구조야. 여기서 자산은 모델 하나에만 한정되지 않아. 관리형 AI 서비스, 직접 운영하는 모델·추론 엔드포인트·에이전트, 외부 모델 제공자의 API를 호출하는 의존성까지 포함할 수 있어.¹

이 구조는 네 단계로 읽으면 쉬워.

1. 발견 — 어디에 어떤 AI 자산이 있는지 찾는다.
2. 분류 — 관리형 서비스인지, 직접 호스팅한 워크로드인지, 외부 API 의존성인지 구분한다.
3. 연결 — 자산을 계정·서버·컨테이너 같은 기반 인프라와 묶는다.
4. 상관분석 — 위협 탐지와 구성 오류 같은 보안 결과를 자산에 겹쳐 본다.

중요한 건 네 단계가 각각 따로 끝나지 않는다는 점이야. 자산 이름만 모으면 자산 관리이고, 보안 결과만 모으면 경보 목록이야. 둘을 연결해야 특정 모델이나 에이전트가 어느 인프라에서 실행되고, 어떤 위협 신호와 함께 봐야 하는지 알 수 있어.

왜 중요한가

AI 자산은 같은 방식으로 배포되지 않아. 클라우드가 제공하는 관리형 서비스도 있고, 가상 머신이나 컨테이너에 직접 올린 모델도 있고, 코드가 외부 모델 제공자의 API를 부르는 경우도 있어. 한 가지 검색 방식만 쓰면 이 중 일부가 빠진다.¹

그래서 AI 자산 인벤토리의 핵심은 목록의 개수가 아니라 발견 경로를 여러 겹으로 만드는 것이야. AWS가 발표한 Security Hub AI Inventory는 관리형 AI 서비스에는 AWS Config 리소스를, 자체 호스팅 워크로드에는 Amazon Inspector의 SBOM 분석을, 외부 AI API 엔드포인트에는 Amazon GuardDuty의 DNS 텔레메트리를 사용한다고 설명해.¹

이렇게 모은 자산을 기반 인프라와 보안 결과에 연결하면 보안팀의 질문도 달라져. “경고가 몇 개인가?”에서 “어떤 AI 워크로드가 실제 위협과 잘못된 구성에 함께 노출됐나?”로 옮겨가는 거지. AWS는 계정, 리소스 유형, 발견 방식, 모델 식별자별로 인벤토리를 필터·그룹·조회하고, 위협을 받는 자산과 조직 위험이 큰 워크로드의 조치 우선순위를 정할 수 있다고 설명해.¹

실제 예시

AWS가 2026년 7월 발표한 Security Hub AI Inventory는 이 개념을 제품에 넣은 사례야. 관리형 서비스에서는 Amazon Bedrock, Bedrock AgentCore, Amazon SageMaker의 AWS Config 리소스를 찾아 별도 설정 없이 인벤토리에 넣는다.¹

직접 운영하는 AI 워크로드는 다른 경로로 찾는다. Amazon Inspector의 SBOM 분석이 EC2 인스턴스와 ECR 컨테이너 이미지 안의 추론 엔드포인트, 모델, AI 에이전트를 식별하도록 확장됐고, Ollama·vLLM·Hugging Face TGI 같은 프레임워크도 예로 제시돼.¹

외부 의존성은 네트워크 흔적에서 찾는다. EC2 인스턴스가 제3자 모델 제공자의 엔드포인트를 호출하면, GuardDuty DNS 텔레메트리가 그 외부 AI API 의존성을 드러낼 수 있다는 설명이야.¹

세 경로에서 발견한 자산은 기반 인프라에 매핑되고, GuardDuty를 포함한 AWS 보안 스택의 보안 결과와 상관분석된다. AWS는 이 AI Inventory를 Security Hub Essentials에 추가 비용 없이 포함하고, Security Hub가 제공되는 AWS 상업 리전에서 사용할 수 있다고 밝혔어.¹

헷갈리지 말아야 할 점

• 인벤토리는 보안 통제 자체가 아니야. 자산을 찾고 위험 신호를 연결하지만, 그 결과만으로 안전을 보증하지는 않아.
• 발견됐다는 사실과 소유자가 정해졌다는 사실은 달라. 목록에 자산이 있어도 누가 권한·데이터·배포를 책임지는지는 별도 연결이 필요해.
• 외부 API 호출은 모델을 직접 호스팅하지 않는다는 뜻일 뿐이야. 호출하는 애플리케이션과 네트워크 경로, 사용 중인 제공자 의존성은 조직의 AI 자산 표면에 남아.
• 한 화면이 보안 운영 전체를 대신하지 않아. AWS Security Hub 같은 서비스가 발견과 우선순위의 중심이 될 수 있어도, 실제 수정 권한과 예외 승인까지 자동으로 정리된다는 뜻은 아니야.
• AI 자산의 숫자만 세면 부족해. 어떤 자산이 어떤 인프라·위협·책임자와 연결되는지까지 조회할 수 있어야 인벤토리가 운영에 쓰여.

관련 문서

• 보안 결과를 한 화면에서 모으는 제품의 범위는 AWS Security Hub에서 이어서 볼 수 있어.
• 여러 클라우드의 위험을 함께 읽는 문제는 멀티클라우드 보안과 연결돼.
• AI 워크로드가 실행되는 구조를 더 깊이 보려면 agentic workflow를 참고해.

남은 질문들

• 조직은 AI 자산의 소유자·권한·데이터 흐름을 인벤토리에 어떻게 붙일까?
• 관리형 서비스와 자체 호스팅 모델이 섞인 환경에서 누락·중복 자산을 어떻게 판정할까?
• 인벤토리의 보안 신호가 실제 티켓·예외 승인·수정 확인으로 이어지는 운영 구조는 무엇일까?

각주

1. AWS, 「AWS Security Hub now provides AI inventory for organization-wide visibility of AI assets」(2026-07-14) 공식 발표. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸ ↩︎⁹