기업은 어떤 AI를 사용 중인지 알고 있을까?｜AI Inventory로 모델·데이터·API·Agent 자산을 추적하는 방법

기업은 어떤 AI를 사용 중인지 알고 있을까?｜AI Inventory로 모델·데이터·API·Agent 자산을 추적하는 방법

기업이 생성형 AI와 AI Agent를 빠르게 도입할수록 의외로 어려워지는 문제가 있습니다. “우리 회사 안에 AI가 몇 개나 있는가?”라는 아주 단순한 질문입니다.

AI Governance와 AI Risk Management 관점에서 보면 중요한 것은 새로운 AI를 하나 더 도입하는 속도만이 아닙니다. 어떤 모델·데이터·API·Agent가 실제 업무에 연결되어 있고, 누가 소유하며, 무엇에 접근하고, 지금도 사용 중인지 파악할 수 있는가가 Enterprise AI 운영의 출발점이 됩니다.

오늘은 이 문제를 AI Inventory라는 개념으로 풀어보겠습니다.

어느 금요일 오후, AI 하나를 끄는 데 회사 전체가 멈칫했다.

※ 아래 이야기는 특정 기업의 실제 사건이 아니라 기업의 AI 운영 과정에서 발생할 수 있는 상황을 재구성한 가상의 시뮬레이션입니다.

금요일 오후 4시 42분.

한 중견기업의 IT 운영팀에 다급한 메시지가 도착합니다.

“고객 문의 내용을 요약하는 AI 서비스에서 사용 중인 외부 API를 교체해야 합니다. 이 API를 사용하는 시스템이 어디인지 확인할 수 있을까요?”

처음에는 간단해 보였습니다.

개발팀이 관리하는 서비스 목록을 열어보면 금방 찾을 수 있을 것 같았습니다.

그런데 화면을 하나씩 넘기기 시작하자 이야기가 달라집니다.

고객지원팀은 외부 SaaS 기반 AI 챗봇을 쓰고 있었고, 마케팅팀은 별도로 생성형 AI API를 연결해 상품 설명 초안을 만들고 있었습니다. 영업팀에서는 한 직원이 노코드 자동화 도구와 LLM을 연결해 제안서 요약 Agent를 만들어 사용하고 있었습니다.

개발팀 서버에는 테스트가 끝난 줄 알았던 모델 API가 여전히 호출되고 있었고, 퇴사한 직원 계정으로 만들어진 자동화 워크플로우도 하나 발견됩니다.

회의실이 조용해집니다.

문제는 AI가 많다는 사실이 아니었습니다.

회사가 자신이 가진 AI를 정확하게 모르고 있었다는 것이었습니다.

서버실 팬이 낮게 돌아가고, 모니터에는 API 호출 기록이 끝없이 올라갑니다. 하지만 누구도 화면에 나타난 모든 AI 시스템의 주인과 목적을 한 번에 설명하지 못합니다.

바로 이 지점에서 AI Inventory가 필요해집니다.

AI Inventory란 무엇인가? 단순한 ‘AI 목록’과 다른 이유

AI Inventory를 직역하면 ‘AI 목록’ 정도로 들립니다.

하지만 기업 환경에서의 의미는 훨씬 넓습니다.

미국 NIST의 AI Risk Management Framework Playbook은 AI 시스템을 inventory하는 메커니즘을 마련할 것을 제시하고 있습니다. NIST는 AI System Inventory를 AI 시스템이나 모델과 관련된 정보를 조직적으로 관리하는 데이터베이스로 설명하며, 시스템 문서, 사고 대응 계획, 데이터 사전, 구현 소프트웨어나 소스코드 링크, 관련 AI 담당자의 정보 등이 포함될 수 있다고 설명합니다.

NIST AI RMF Playbook – Govern

쉽게 비유하면 이렇습니다.

집에 물건이 20개 있을 때는 기억으로도 관리할 수 있습니다.

하지만 회사 창고에 물건이 2만 개 있다면 이야기가 달라집니다. 어떤 물건인지, 어느 창고에 있는지, 담당자는 누구인지, 언제 들어왔는지, 폐기 대상인지 기록하는 자산대장이 필요합니다.

AI Inventory는 말하자면 기업 AI의 자산대장입니다.

다만 AI는 책상이나 노트북처럼 가만히 있는 자산이 아닙니다.

모델이 바뀌고, 데이터가 갱신되고, API가 연결되고, Agent의 권한이 추가되며, 새로운 외부 서비스가 업무 흐름에 들어옵니다.

그래서 현대적인 AI Inventory는 정적인 명단보다 살아 움직이는 AI 운영 지도에 가까워지고 있습니다.

WSF 필자의 한 줄: “보이지 않는 AI는 관리할 수 없는 자산이 되고, 주인이 없는 AI는 언젠가 설명하기 어려운 위험이 될 수 있습니다.”

※ 위 문장은 유명 인사의 인용문이 아니라 본 글을 위해 작성한 WSF 필자의 표현입니다.

AI Inventory에는 무엇을 등록해야 할까? AI Asset Registry 구축 가이드

여기서 흔히 하는 실수가 있습니다.

엑셀을 하나 열고 다음처럼 적는 것입니다.

ChatGPT / 고객지원팀 / 사용 중

이것만으로는 부족합니다.

기업에서 AI 하나가 실제 업무를 수행하려면 모델만 필요한 것이 아니기 때문입니다.

Model — 어떤 AI 모델을 사용하는가?

가장 기본적인 항목입니다.

모델 이름, 제공업체, 버전, 사용 목적, 배포 환경, 마지막 변경 시점 등을 추적할 수 있어야 합니다.

여기서 중요한 것은 Model Registry와 AI Inventory를 같은 개념으로 보지 않는 것입니다.

Model Registry가 모델을 중심으로 관리하는 서랍이라면 AI Inventory는 그 서랍뿐 아니라 데이터, Agent, API, 책임자와 실제 비즈니스 시스템까지 연결해 보는 건물 전체의 관리대장에 더 가깝습니다.

첨부 자료에서도 이 차이를 분명히 구분하고 있으며, NIST 역시 AI System Inventory가 모델 자체를 넘어 문서·데이터·구현 코드·담당자 등의 정보를 포함할 수 있다고 설명합니다.

Data — AI는 어떤 데이터를 보고 있는가?

같은 모델이라도 연결된 데이터가 다르면 위험 수준은 크게 달라질 수 있습니다.

공개된 제품 설명을 읽는 AI와 고객의 개인정보가 담긴 데이터베이스에 접근하는 AI를 동일하게 관리하기 어려운 이유입니다.

따라서 Inventory에는 최소한 데이터 출처, 데이터 유형, 민감도, 저장 위치, 접근 범위, 보존 정책과 같은 정보가 연결되어야 합니다.

여기에서 AI Inventory는 자연스럽게 Data Governance와 만납니다.

API·Tool — AI는 무엇과 연결되어 있는가?

생성형 AI가 질문에 답하기만 한다면 위험 범위가 비교적 제한적일 수 있습니다.

하지만 API와 Tool이 연결되는 순간 AI는 ‘말하는 시스템’에서 ‘행동할 수 있는 시스템’으로 변합니다.

CRM을 읽는가?

메일을 보내는가?

사내 문서를 검색하는가?

고객 데이터를 수정할 수 있는가?

외부 시스템에 요청을 전송할 수 있는가?

이 정보가 Inventory에 연결되지 않으면 조직은 AI가 존재한다는 사실은 알아도 그 AI가 어디까지 손을 뻗을 수 있는지는 모르는 상태가 됩니다.

Agent — 이제는 모델보다 ‘행동 주체’를 봐야 한다.

Agentic AI 시대에는 특히 이 부분이 중요해지고 있습니다.

전통적인 질문이

“어떤 모델을 쓰고 있습니까?”

였다면 Agent 시대에는 질문이 달라집니다.

“어떤 Agent가 존재하며, 누구를 대신해 무엇을 할 수 있습니까?”

Microsoft는 2026년 8월 공개한 자사 운영 사례에서 Agent 365를 이용해 내부적으로 50만 개가 넘는 Agent에 대한 가시성을 확보했다고 밝혔습니다. Microsoft는 Agent category, metadata, usage, ownership과 lifecycle 정보를 한곳에서 관리하는 방향을 설명하고 있습니다.

Microsoft의 Agent 365 내부 거버넌스 사례

이 사례가 흥미로운 이유는 숫자 자체보다 관리 대상의 변화에 있습니다.

AI Governance가 이제 ‘모델 몇 개 관리하기’에서 수많은 Agent의 존재·소유권·활동·수명주기를 관리하는 문제로 확장되고 있다는 것입니다.

AI Inventory 비교 분석｜체크해야 할 핵심 자산은 무엇이 다를까?

관리 대상	핵심 질문	기록할 정보 예시	놓쳤을 때 생길 수 있는 문제
AI Model	어떤 모델을 사용하는가?	모델명, 버전, Provider, 목적	오래된 모델·미승인 모델 사용
Dataset	무엇을 학습·검색·참조하는가?	데이터 출처, 민감도, 보관 위치	개인정보·기밀정보 노출 위험
API·Tool	무엇과 연결되어 있는가?	API, 권한, 인증 방식, 호출 범위	예상하지 못한 외부 접근
Prompt	어떤 지시로 작동하는가?	시스템 지시, 버전, 변경 이력	행동 기준 변경 추적 어려움
AI System	어느 업무에 사용되는가?	업무 목적, 사용자, 배포 환경	중복 시스템·관리 사각지대
AI Agent	무엇을 스스로 수행하는가?	Owner, Tool, 권한, 행동 범위	과도한 권한·책임자 부재
Owner	누가 책임지는가?	부서, 담당자, 승인자	사고 발생 시 책임 공백
Lifecycle	현재 어떤 상태인가?	개발·시험·운영·중단·폐기	사용하지 않는 AI의 장기 잔존
Risk	위험 수준은 어느 정도인가?	위험등급, 평가일, 검토 결과	고위험 AI 관리 누락

※ 모바일 화면에서는 표를 좌우로 스크롤하여 전체 내용을 편하게 확인하실 수 있습니다.

표에서 눈여겨볼 부분은 Owner와 Lifecycle입니다.

기술팀은 Model과 API부터 보는 경향이 있지만, 실제 운영에서는 “누가 책임지는가”와 “아직도 필요한가”가 상당히 중요합니다.

AI Inventory와 Agent Identity는 무엇이 다른가?

이 부분은 기존 WSF 콘텐츠와 반드시 구분해야 합니다.

AI Inventory는 ‘무엇이 존재하는가’를 관리합니다.

반면 Agent Identity는 ‘그 Agent가 누구인가’를 식별하고 인증하는 문제에 가깝습니다.

예를 들어 회사에 구매 요청서를 정리하는 Agent가 있다고 해보겠습니다.

Inventory에서는 다음을 묻습니다.

“이 Agent가 존재하는가?”
“담당 부서는 어디인가?”
“어떤 모델과 API를 쓰는가?”
“어떤 데이터에 연결되어 있는가?”
“현재 운영 중인가?”

Identity에서는 질문이 달라집니다.

“이 Agent를 시스템이 어떻게 식별하는가?”
“어떤 자격증명으로 인증하는가?”
“누구의 권한을 위임받았는가?”
“어떤 리소스에 접근할 수 있는가?”

Microsoft의 관련 문서에서도 Agent 365의 발견·Inventory 기능과 Entra Agent ID의 신원·권한 보호 역할을 구분해 설명하고 있습니다.

즉,

Inventory → 존재와 현황

Identity → 신원과 인증

Permission → 접근 범위

Audit → 실제 행동 기록

으로 생각하면 이해하기 쉽습니다.

이 네 가지가 연결될 때 기업은 비로소 “Agent가 있다”에서 “이 Agent가 누구이며 무엇을 할 수 있고 실제 무엇을 했는지 설명할 수 있다”로 넘어갑니다.

AI Transparency와 AI Inventory도 같은 개념이 아닙니다.

또 하나 헷갈리기 쉬운 것이 AI Transparency입니다.

AI Transparency는 특정 AI 시스템의 목적, 작동 특성, 한계, 평가 결과, 업데이트 정보 등을 이해하고 설명할 수 있도록 만드는 문제에 가깝습니다.

AI Inventory는 그보다 한 단계 앞의 질문에서 시작합니다.

“설명해야 할 AI가 회사 안에 무엇이 있는가?”

입니다.

회사에 AI 시스템 100개가 있는데 70개만 알고 있다면, 70개의 Transparency 문서를 아무리 잘 작성해도 나머지 30개는 관리 밖에 남습니다.

그래서 흐름은 다음처럼 생각할 수 있습니다.

Discovery → Inventory → Classification → Ownership → Risk Assessment → Governance → Monitoring → Retirement

이 구조가 이번 글의 핵심입니다.

WSF 필자의 한 줄: “투명성은 AI를 잘 설명하는 능력이고, Inventory는 무엇을 설명해야 하는지 빠뜨리지 않는 능력입니다.”

※ WSF 필자의 창작 문장입니다.

반전은 여기 있습니다.｜AI Inventory의 진짜 문제는 AI가 아니라 ‘Shadow AI’일 수 있다.

기업이 공식 구매한 AI 솔루션만 목록에 넣으면 Inventory 구축이 끝날까요?

그렇지 않을 수 있습니다.

직원이 개인적으로 가입한 생성형 AI 서비스, 팀 단위로 구매한 SaaS, 개발자가 테스트 목적으로 만든 API 연결, 노코드 플랫폼에서 만든 자동화 Agent처럼 중앙 IT 조직이 즉시 파악하지 못하는 AI가 존재할 수 있기 때문입니다.

이런 영역에서 자주 등장하는 용어가 Shadow AI입니다.

쉽게 말하면 회사 건물의 정문으로 들어온 장비는 자산관리팀이 알고 있지만, 직원들이 각자 옆문으로 들고 들어온 장비까지는 관리대장에 없는 상황과 비슷합니다.

문제는 직원이 나쁜 의도로 AI를 사용해서만 발생하는 것이 아닙니다.

오히려 일을 더 빨리 처리하려고 만든 작은 자동화가 관리 대상에서 빠지는 경우를 생각해볼 수 있습니다.

그래서 AI Inventory의 중요한 역할 중 하나가 Discovery, 즉 이미 알고 있는 AI를 기록하는 것뿐 아니라 몰랐던 AI를 발견하는 것으로 확장됩니다.

Microsoft의 Agent 보안 지침 역시 등록되지 않은 Agent는 검토·모니터링·오프보딩에서 보이지 않는 존재가 될 수 있다고 설명하며, 조직 밖 관리 체계에서 만들어진 ‘shadow agents’를 발견해 소유자를 지정하고 접근 범위를 관리하는 방향을 제시합니다.

엑셀 한 장이면 충분할까? Continuous AI Inventory가 필요한 이유

초기 단계에서는 스프레드시트도 훌륭한 출발점입니다.

문제는 규모입니다.

월요일에는 Agent가 18개였습니다.

수요일에는 개발팀이 3개를 추가했습니다.

목요일에는 마케팅팀이 새로운 SaaS AI를 연결했습니다.

금요일에는 기존 Agent의 모델이 바뀌고 API 권한이 확대됐습니다.

다음 달에는 담당자가 다른 부서로 이동했습니다.

이때 한 달에 한 번 사람이 엑셀 파일을 열어 수정하는 방식만으로 실제 환경과 Inventory를 계속 일치시키기는 어려워질 수 있습니다.

그래서 중요한 개념이 Continuous Discovery입니다.

AI를 한 번 조사해 목록을 만드는 행사가 아니라, 새롭게 생성·배포·변경·중단되는 AI 자산을 지속적으로 찾아 Inventory와 연결하는 방식입니다.

ServiceNow는 현재 AI Control Tower를 기업 내 AI를 발견하고 관리하는 중앙 허브로 설명하며 Agent, Model, MCP Server 등의 자산을 Inventory하는 기능을 제시하고 있습니다. 또한 AI 자산을 비즈니스 맥락과 연결하고 lifecycle 및 risk/compliance 관리로 확장하는 방향을 제공하고 있습니다.

ServiceNow AI Control Tower 공식 자료

여기에서 시장의 방향을 읽을 수 있습니다.

Inventory가 단순한 목록에서 Governance 데이터 기반으로 바뀌고 있다는 것입니다.

AI Inventory 구축 실전 가이드｜Discovery → Ownership → Visibility 순서로 시작해보세요.

처음부터 거대한 AI Control Tower를 구축할 필요는 없습니다.

오히려 중요한 것은 조직이 대답해야 할 질문을 먼저 정의하는 것입니다.

Discovery — 무엇이 있는지 찾아보기

회사에서 사용하는 생성형 AI, 자체 모델, 외부 모델 API, SaaS Copilot, 업무 자동화 Agent, RAG 시스템, MCP 연결, 데이터셋 등을 조사합니다.

여기서 공식 구매 목록만 보면 안 됩니다.

클라우드 사용 내역, SaaS 계약, API Key, 개발 저장소, 자동화 플랫폼, 브라우저 기반 AI 서비스, 부서별 자체 도입 도구 등 여러 경로를 함께 살펴볼 필요가 있습니다.

Ownership — AI마다 주인을 정하기

“IT팀에서 관리합니다”만으로는 부족할 수 있습니다.

업무 Owner와 기술 Owner를 구분하는 방식도 고려할 수 있습니다.

예를 들어 HR 채용 Agent라면 HR 부서가 비즈니스 목적과 결과에 책임을 가지고, IT 또는 AI Platform 팀이 기술 운영을 맡는 구조입니다.

Microsoft의 Agent lifecycle 가이드 역시 운영 Agent에 명시적인 Owner가 필요하며, 성능과 위험을 지속적으로 관리하고 필요할 경우 개선 또는 retirement로 연결하는 구조를 설명합니다.

Visibility — 연결관계를 보이게 만들기

좋은 Inventory는 행 하나짜리 명단에서 끝나지 않습니다.

예를 들어 다음 관계가 보이는 편이 훨씬 유용합니다.

고객지원 Agent
→ 외부 LLM
→ 고객 FAQ Dataset
→ CRM Read API
→ 고객지원팀
→ 담당 Owner
→ Risk Level: Medium
→ Production
→ Last Review: 2026-09-15

이렇게 연결하면 모델 하나가 변경됐을 때 어떤 Agent와 업무가 영향을 받는지도 추적하기 쉬워집니다.

Risk Classification — 모든 AI를 똑같이 관리하지 않기

사내 행사 문구를 만드는 AI와 대출 심사나 의료 판단을 지원하는 AI의 위험을 같은 수준으로 취급하는 것은 효율적이지 않습니다.

NIST AI RMF도 AI Risk Management를 조직의 위험 우선순위와 연결하고, AI 시스템 Inventory에 필요한 자원을 위험 우선순위에 따라 배분하도록 제시합니다.

즉 Inventory의 목적은 모든 AI에 똑같은 빨간 딱지를 붙이는 것이 아닙니다.

무엇을 더 엄격하게 관리해야 하는지 구별하기 위한 기반을 만드는 것입니다.

AI Asset Registry에는 어떤 필드를 넣어야 할까?

실무에서는 다음과 같은 구조를 생각해볼 수 있습니다.

Asset ID → Asset Type → Name → Business Purpose → Provider → Model → Data Source → API/Tool → Permission → Owner → Department → Environment → Risk Class → Lifecycle → Last Review → Related Assets

여기서 Asset ID가 생각보다 중요합니다.

사람 이름만으로 직원을 관리하지 않고 사번을 부여하듯, AI 자산에도 고유 식별자를 부여하면 같은 이름의 Agent나 여러 버전의 시스템을 구분하기 쉬워집니다.

또 Related Assets를 두면 하나의 Agent가 어느 모델, 데이터셋, API와 연결되는지 관계를 표현할 수 있습니다.

이 순간 Inventory는 단순한 엑셀 목록에서 AI Asset Registry로 발전하기 시작합니다.

AI Inventory를 만들었는데 6개월 뒤 아무도 보지 않는다면?

여기에서 많은 관리 프로젝트의 함정이 등장합니다.

처음에는 멋진 표가 만들어집니다.

열이 30개이고, 색상도 깔끔합니다.

그런데 담당자가 바뀌고 신규 AI가 들어오면서 실제 환경과 표가 조금씩 달라집니다.

6개월 뒤에는 아무도 어느 정보가 최신인지 확신하지 못합니다.

그래서 AI Inventory에서 중요한 것은 Completeness뿐 아니라 Freshness, 즉 최신성입니다.

등록 시점만 기록하지 말고 다음 검토일, 마지막 확인일, Owner 변경, 모델 업데이트, 권한 변경, 폐기 여부까지 lifecycle에 연결해야 합니다.

Microsoft의 현재 Agent Registry 관련 기능에서도 Agent의 가시성·접근·배포·삭제·소유자 변경 등 lifecycle 관리가 중요한 관리 대상으로 제시되고 있습니다.

WSF 필자의 한 줄: “자산대장의 가치는 얼마나 많이 적혀 있는지가 아니라, 오늘의 현실과 얼마나 가까운지에서 결정됩니다.”

※ 본 글을 위해 작성한 WSF 필자의 창작 문장입니다.

AI Inventory → AI Governance → AI Risk Management로 연결해야 하는 이유

여기까지 읽으면 한 가지 의문이 생길 수 있습니다.

“목록까지 만들었는데 그 다음에는 무엇을 해야 할까?”

여기에서 AI Governance가 시작됩니다.

Inventory 자체는 통제가 아닙니다.

회사에 AI Agent 300개가 있다는 사실을 아는 것과 그 300개가 적절하게 운영되고 있다는 것은 완전히 다른 문제입니다.

따라서 구조는 이렇게 발전합니다.

Discovery
↓
Inventory
↓
Ownership
↓
Classification
↓
Risk Assessment
↓
Policy & Controls
↓
Monitoring
↓
Lifecycle Management

예를 들어 Inventory에서 Owner가 없는 Agent가 발견됐다고 해보겠습니다.

Governance 정책은 “Production Agent는 반드시 Owner를 가져야 한다”고 정할 수 있습니다.

Inventory에서 사용하지 않은 Agent가 발견됐다면 일정 기간 비활성 상태를 확인한 뒤 검토 대상으로 보내는 lifecycle 정책을 적용할 수 있습니다.

과도한 권한을 가진 Agent가 발견됐다면 Identity·Access Management 체계와 연결해 권한을 다시 조정할 수 있습니다.

Microsoft 역시 Agent 365에서 inactive agent 만료, ownerless agent 식별, 위험한 Agent 차단 등 lifecycle 정책을 설명하고 있습니다.

이것이 Inventory → Governance의 실제 연결입니다.

비용 관점에서도 AI Inventory가 필요한 이유｜AI FinOps와 중복 투자 찾기

AI Inventory는 보안팀만의 프로젝트라고 생각하기 쉽습니다.

하지만 CFO나 경영기획 관점에서는 완전히 다른 질문을 던질 수 있습니다.

“우리가 AI에 실제 얼마를 쓰고 있는가?”

부서 A는 요약 AI를 구독하고 있습니다.

부서 B도 비슷한 제품을 사용합니다.

개발팀은 별도의 API를 호출하고 있고, 마케팅팀은 또 다른 생성형 AI SaaS를 결제합니다.

개별 비용은 작아 보여도 조직 전체에서는 중복 구독, 사용하지 않는 라이선스, 방치된 API 호출, 유사 기능 Agent가 쌓일 수 있습니다.

그래서 Inventory에 Provider, License, API Cost, Usage, Department, Business Value 같은 정보를 연결하면 AI Asset Management와 AI FinOps 관점까지 확장할 수 있습니다.

여기서 경제 개념 하나를 쉽게 이해해보겠습니다.

기업이 AI를 도입하는 것은 자동차 한 대를 사는 것과 다릅니다.

오히려 수도관을 여러 개 설치하는 것에 가깝습니다.

수도꼭지 하나의 가격만 알아서는 전체 수도요금을 계산할 수 없습니다. 어디에 수도관이 연결되어 있고 얼마나 사용되는지 알아야 합니다.

AI 비용도 비슷합니다.

모델 가격만 보는 것이 아니라 API 호출, Agent 실행, 데이터 처리, SaaS 라이선스, 운영·보안·모니터링 비용까지 연결해야 실제 Total Cost of Ownership(TCO)에 가까워집니다.

이 때문에 AI Inventory는 보안 자산대장이면서 동시에 비용 가시성의 출발점이 될 수도 있습니다.

기업 규모가 작아도 AI Inventory가 필요할까?

직원 10명의 회사가 대기업과 같은 시스템을 구축할 필요는 없습니다.

하지만 원칙은 적용할 수 있습니다.

작은 회사라면 스프레드시트 하나로 시작해도 됩니다.

중요한 것은 도구가 아니라 질문입니다.

우리는 무엇을 쓰고 있는가?
왜 쓰는가?
누가 책임지는가?
어떤 데이터에 접근하는가?
무엇을 할 수 있는가?
비용은 얼마나 드는가?
문제가 생기면 끌 수 있는가?
더 이상 필요하지 않을 때 어떻게 없앨 것인가?

이 여덟 질문에 답할 수 있다면 이미 상당히 좋은 출발입니다.

반대로 값비싼 AI Governance Platform을 구매했더라도 이 질문에 답하지 못한다면 기술만 있고 운영 체계는 없는 상태가 될 수 있습니다.

AI Inventory 실무 체크리스트｜처음 만들 때 확인할 12가지

• 조직에서 사용 중인 AI Model을 식별했는가?
• 외부 LLM API와 SaaS AI까지 포함했는가?
• 자체 제작 Agent와 부서별 Agent를 조사했는가?
• Agent가 접근하는 Dataset과 API를 연결했는가?
• 각 AI Asset에 명확한 Owner가 있는가?
• 개발·시험·운영 환경을 구분했는가?
• 위험등급 또는 중요도를 기록했는가?
• 모델·Prompt·API 변경 이력을 추적할 수 있는가?
• 마지막 검토일과 다음 검토일이 있는가?
• 사용하지 않는 AI를 폐기하는 절차가 있는가?
• 미승인·미등록 AI 또는 Shadow AI를 발견할 방법이 있는가?
• Inventory가 보안·Compliance·비용 관리와 연결되는가?

여기에서 절반 이상이 “모르겠다”라면 문제가 있다는 의미로 단정할 필요는 없습니다.

오히려 무엇을 모르고 있는지 발견했다는 것 자체가 Inventory 구축의 시작입니다.

AI Inventory의 진짜 가치는 ‘통제’가 아니라 설명 가능성에 있습니다.

AI Governance라는 말을 들으면 규칙과 금지부터 떠올리기 쉽습니다.

하지만 잘 설계된 Inventory의 목적은 직원이 AI를 못 쓰게 만드는 것이 아닙니다.

어떤 팀이 좋은 AI Agent를 만들었다면 조직은 그것을 발견해 다른 팀과 공유할 수 있습니다.

같은 기능을 다섯 부서가 각각 구매하고 있었다면 중복 비용을 줄일 수도 있습니다.

위험이 낮은 AI는 빠르게 승인하고, 민감한 데이터와 연결된 AI에 더 많은 검토 자원을 집중할 수도 있습니다.

Owner가 명확하면 문제가 생겼을 때 책임을 묻는 데서 끝나는 것이 아니라 누구에게 연락해 수정해야 하는지 빠르게 찾을 수 있습니다.

그래서 AI Inventory는 AI 혁신을 막는 브레이크라기보다 교통지도에 가깝습니다.

길이 어디에 있는지 알아야 더 빠르게 달릴 수 있고, 위험한 교차로가 어디인지 알아야 안전장치도 정확한 곳에 설치할 수 있습니다.

이것이 이 글의 작은 반전입니다.

AI를 더 많이 관리하는 것이 반드시 AI를 덜 쓰는 것을 의미하지는 않습니다. 오히려 무엇을 쓰고 있는지 정확하게 아는 조직이 더 자신 있게 AI를 확장할 가능성이 있습니다.

FAQ｜AI Inventory를 처음 구축할 때 많이 궁금한 질문

Q. AI Inventory와 Model Registry는 같은 것인가요?

같다고 보기 어렵습니다. Model Registry는 모델 버전과 배포 등 모델 중심 관리에 유용하지만, AI Inventory는 모델뿐 아니라 AI System, Dataset, API, Agent, Owner, Risk, Lifecycle 등의 관계까지 포함하는 더 넓은 관리 개념으로 설계할 수 있습니다. NIST 역시 AI System Inventory를 조직의 AI 자산을 전체적으로 볼 수 있는 데이터베이스로 설명합니다.

Q. ChatGPT 같은 외부 생성형 AI도 Inventory에 넣어야 하나요?

조직의 업무 데이터나 업무 프로세스와 관련해 사용한다면 관리 범위를 검토할 필요가 있습니다. 다만 모든 서비스에 동일한 관리 수준을 적용하기보다는 사용 목적, 데이터 민감도, 접근 권한, 위험 수준에 따라 분류하는 것이 현실적입니다.

Q. AI Agent와 일반 AI Model을 왜 구분해야 하나요?

모델은 주로 입력을 받아 출력을 생성하지만 Agent는 Tool·API·데이터와 연결되어 여러 단계를 수행할 수 있습니다. 따라서 Agent에서는 Owner, Identity, Permission, Tool Access, Lifecycle 같은 추가 관리 항목의 중요성이 커집니다.

Q. Shadow AI는 무조건 금지해야 하나요?

무조건 금지해야 한다고 일반화하기는 어렵습니다. 조직의 위험 수준과 정책에 따라 접근이 달라질 수 있습니다. 중요한 것은 승인되지 않은 AI가 존재하는지조차 모르는 상태를 줄이고, 발견된 AI의 목적·데이터·권한·위험을 평가할 수 있는 절차를 만드는 것입니다.

Q. AI Inventory는 보안팀이 관리해야 하나요?

보안팀만으로 끝내기보다는 IT, AI Platform, Data Governance, Legal·Compliance, 각 업무부서가 역할을 나누는 구조를 고려할 수 있습니다. 특히 Business Owner와 Technical Owner를 명확하게 구분하면 책임과 운영이 보다 선명해질 수 있습니다.

Q. 소규모 기업도 전용 AI Governance Software를 구매해야 하나요?

반드시 그렇지는 않습니다. 규모가 작다면 스프레드시트나 기존 IT 자산관리 도구에서 시작할 수도 있습니다. 중요한 것은 제품 구매보다 Inventory 범위, Owner, 위험분류, 검토 주기와 폐기 절차를 먼저 정하는 것입니다.

Q. AI Inventory는 한 번 만들면 끝인가요?

그렇게 운영하면 실제 환경과 빠르게 달라질 수 있습니다. Agent와 API, 모델, 데이터 연결이 계속 변하기 때문에 신규 등록, 변경, 정기 검토, 비활성화, 폐기를 lifecycle로 관리하는 것이 중요합니다.

필자의 주관적인 마무리 의견

AI 시대 기업의 가장 위험한 질문은 어쩌면 “우리 AI가 얼마나 똑똑한가?”가 아닐지도 모릅니다. 저는 그보다 먼저 “우리는 지금 어떤 AI가 회사 안에서 움직이고 있는지 알고 있는가?”를 물어야 한다고 생각합니다.

모델의 성능은 숫자로 비교하기 쉽습니다. 하지만 누가 만든 Agent인지, 어떤 데이터에 연결되어 있는지, 어느 API를 호출하는지, 담당자가 퇴사한 뒤에도 계속 작동하고 있는지는 모델 벤치마크에서 알려주지 않습니다.

그래서 AI Inventory를 단순한 보안 목록으로만 보지 않았으면 합니다. 잘 만든 Inventory는 AI Governance의 지도이면서, 비용을 들여다보는 장부이고, 사고가 발생했을 때 원인을 추적하는 출발점이며, 새로운 AI를 더 안전하게 도입하기 위한 기반이 될 수 있습니다.

특히 앞으로 Agent가 늘어날수록 중요한 경쟁력은 AI를 무조건 많이 보유하는 데서만 나오지는 않을 것입니다. 어떤 AI가 어떤 목적을 위해 존재하고, 누가 책임지며, 어떤 자원에 접근하고, 언제 검토되고 폐기되는지 설명할 수 있는 능력이 함께 중요해질 것입니다.

기업의 AI 포트폴리오를 관리한다는 것은 새로운 기술을 막는 일이 아니라 기술 투자의 가시성과 운영 효율을 높이는 과정이라고 생각합니다. AI Governance, AI Risk Management, AI Security, Compliance, AI FinOps를 각각 따로 관리하기보다 그 중심에 신뢰할 수 있는 Inventory를 두는 방식은 충분히 검토할 가치가 있습니다.

AI를 많이 가진 기업보다 자신이 가진 AI를 제대로 알고 있는 기업. 저는 앞으로 Enterprise AI의 성숙도를 가르는 기준 중 하나가 바로 여기에 있다고 봅니다.

함께 보면 좋은 추천 포스팅

이번 글은 기존 WSF의 AI Agent Identity → Agent 간 Trust → AI Inventory 흐름으로 연결하면 Topic Cluster가 자연스럽습니다.

AI 에이전트도 고유한 신원이 필요할까?｜공유 API Key·서비스 계정을 넘어 Agent Identity를 설계하는 방법
AI Inventory가 “어떤 Agent가 존재하는가”를 찾는다면 이 글은 “그 Agent를 시스템이 어떻게 식별해야 하는가”를 다룹니다. Inventory 다음 단계인 Identity 관리가 궁금하다면 함께 읽어보세요.
WSF Agent Identity 가이드 보기

AI 에이전트는 다른 에이전트를 어떻게 신뢰할까?｜Agent-to-Agent 인증·위임 체인·신뢰 검증 구조 이해하기
Inventory에 여러 Agent가 등록된 이후에는 Agent끼리 연결될 때의 신뢰 관계가 새로운 관리 문제가 됩니다. Agent ecosystem까지 확장해 이해하고 싶다면 이어서 살펴보세요.
WSF Agent-to-Agent 인증 가이드 보기

AI 에이전트 권한은 왜 자동 만료되어야 할까?｜영구 API Key의 위험과 Task-Scoped Access·Temporary Credentials 설계
Inventory에서 Agent와 API 연결을 찾았다면 다음 질문은 “그 권한이 언제까지 살아 있어야 하는가?”입니다. AI 자산 발견에서 권한 lifecycle 관리까지 이어지는 글입니다. 해당 게시물 역시 첨부 목록에서 정상 URL로 확인됩니다.
WSF Temporary Credentials 가이드 보기

공식 자료 및 추가 확인 링크

이번 원고에서 외부 사실 확인에 사용한 핵심 공식 자료는 다음과 같습니다.

• NIST AI RMF 공식 페이지 — AI Risk Management Framework의 목적과 구조
• NIST AI RMF Playbook – Govern 1.6 — AI System Inventory의 정의와 관리 권고
• ServiceNow AI Control Tower — Enterprise AI Asset Discovery·Inventory·Governance 사례
• Microsoft Agent 365 내부 운영 사례 — Agent Inventory, ownership, usage, lifecycle 가시성 사례
• Microsoft Agent Registry Governance 문서 — Agent의 Owner·차단·삭제·Lifecycle 관리 기능