AX 성패는 AI가 아니라 데이터 권한에서 갈린다
AX의 성패를 AI Ready Data와 데이터 권한 설계 관점에서 해설합니다. 데이터 계약, RBAC·ABAC 결합, 검색 단계 권한 적용의 실무 기준을 정리합니다.
현업에서 AX를 논의하면 모델 선정, 에이전트 구축, RAG 정확도부터 떠올린다. 그러나 실제 도입이 멈추는 지점은 그보다 앞단인 경우가 많다. 이 데이터가 AI가 읽을 수 있는 상태인가, 그리고 이 사용자가 이 맥락에서 읽어도 되는가라는 질문이다.
AX는 업무에 AI 기능을 하나 추가하는 일이 아니다. 의사결정과 실행 흐름에 AI를 넣어 업무 방식을 바꾸는 일에 가깝다. 그래서 모델의 답변 품질은 프롬프트만으로 결정되지 않는다. 데이터의 의미, 최신성, 출처, 접근 권한이 함께 설계돼야 한다.
한 줄 요약: AX의 성패는 모델 성능이 아니라, AI가 신뢰할 수 있게 활용할 데이터의 의미·품질·출처와 사용자별 접근 권한을 함께 설계했는지에 달려 있다.
AI Ready Data는 ‘많은 데이터’가 아니다
이 글에서 AI Ready Data는 사람이 이해할 수 있고, 시스템이 찾아 쓸 수 있으며, 결과의 근거를 다시 확인할 수 있는 데이터 상태를 뜻한다. 단순히 데이터 레이크나 문서 저장소에 파일이 많이 쌓인 상태와는 다르다.
실무에서는 적어도 네 가지를 점검할 수 있다.
- 의미: 컬럼·문서·지표가 무엇을 뜻하는지 정의돼 있는가
- 품질과 최신성: 결측·중복·오래된 버전의 영향을 알 수 있는가
- 연결성: 고객·설비·제품·업무 같은 핵심 개체가 시스템별로 어떻게 이어지는가
- 출처와 책임: 누가 만들고 승인했고, 언제 갱신했는가
예를 들어 ‘수율’이라는 단어가 보고서마다 서로 다른 기간, 모집단, 계산 기준을 뜻한다면 AI는 그럴듯한 답을 만들 수는 있어도 신뢰할 수 있는 비교를 하기는 어렵다. 검색 정확도를 높이려고 문서를 더 넣는 것만으로는 해결되지 않는 이유다.
실무 사례: “문서는 10만 건인데, AI가 틀린 답을 한다”
제조 기업 N사를 생각해 보겠습니다. N사는 10년간 쌓은 설비 점검 보고서, 품질 기록, 작업 표준서를 RAG 시스템에 넣었습니다. 문서 수는 10만 건이 넘었습니다. 경영진은 “이제 AI가 모든 것을 답해줄 것”이라고 기대했습니다.
그런데 현장 엔지니어가 “3호기 수율이 왜 떨어졌지?”라고 묻자, AI는 2019년 보고서와 2024년 보고서를 섞어서 답변했습니다. 두 보고서의 ‘수율’ 정의가 달랐기 때문입니다. 2019년은 라인 전체 기준, 2024년은 개별 설비 기준이었습니다. AI는 그럴듯한 문장을 만들었지만, 엔지니어는 신뢰할 수 없었습니다.
N사의 문제는 데이터 양이 아니었습니다. 문서마다 ‘수율’이 무엇을 뜻하는지, 어떤 기준으로 계산했는지, 누가 승인했는지가 정리되어 있지 않았기 때문입니다. AI Ready Data의 네 요소(의미·품질·연결성·출처) 중 어느 하나도 충족되지 않은 상태였습니다.
데이터 권한은 보안의 마지막 단계가 아니라 제품 기능이다
AI 에이전트가 여러 문서와 시스템을 넘나들기 시작하면 권한은 사후 통제 항목이 아니라 응답 품질의 일부가 됩니다. 같은 질문이라도 질문자의 조직, 역할, 프로젝트, 요청 목적에 따라 보여 줄 수 있는 근거와 답변 범위가 달라져야 한다.
필요한 것은 ‘모두에게 같은 지식베이스’가 아니다. 데이터 분류, 사용자·역할·속성, 접근 목적, 승인 상태를 함께 고려하는 구조다. 특히 민감 데이터가 있는 환경에서는 조직의 보안 정책에 따라 검색 후보부터 허용된 문서로 제한하는 설계를 우선 검토할 필요가 있다. 답변 뒤에서만 마스킹하면 검색·요약 과정에 과도한 데이터가 들어갈 여지가 있기 때문이다.
NIST의 속성 기반 접근통제(ABAC) 가이드는 주체(subject)·객체(object)·요청 작업(requested operations)·환경(environment)의 속성을 정책 판단에 사용하는 접근을 설명한다. AX에 적용하면 직급 하나로 권한을 고정하기보다 ‘누가’, ‘어떤 업무로’, ‘어떤 시점에’, ‘어느 범위까지’ 접근하는지 정책으로 표현할 수 있다. 이는 만능 해법은 아니다. 기존 역할 기반 권한(RBAC)과 결합하는 방식, 권한 변경 이력, 예외 승인 절차를 조직 환경에 맞게 함께 검토할 수 있다.
실무 사례: “같은 질문, 다른 답변이 나와야 한다”
금융 기업 O사의 사내 AI 비서를 생각해 보겠습니다. O사는 전 직원이 같은 지식베이스를 검색하는 AI 챗봇을 도입했습니다. 처음에는 편리했습니다. 그런데 문제가 생겼습니다.
영업팀 직원이 “A 고객사의 여신 한도가 얼마지?”라고 물으면, AI는 내부 심사 보고서까지 포함해 답변했습니다. 그런데 그 직원은 A 고객사의 여신 심사와 무관한 부서였습니다. 반대로 심사팀 직원이 같은 질문을 하면, AI는 공개 정보만 가져와 “내부 자료를 확인하세요”라고 답했습니다. 권한 구분이 없으니, 보여야 할 사람에게는 안 보이고, 보이지 말아야 할 사람에게는 보인 것입니다.
O사는 권한 설계를 다시 했습니다. 사용자 속성(부서·역할·프로젝트), 데이터 분류(공개·내부·민감·기밀), 접근 목적(조회·분석·승인)을 조합해 검색 후보를 제한했습니다. 심사팀 직원은 심사 관련 문서까지 검색되고, 영업팀 직원은 공개·내부 문서까지만 검색되도록 설계했습니다. 답변 뒤에 마스킹하는 것이 아니라, 검색 단계에서부터 허용된 문서만 후보로 들어오게 한 것입니다.
이 설계는 NIST ABAC 가이드가 설명하는 주체·객체·요청 작업·환경 속성 기반 접근통제의 실무 적용 예입니다. 직급 하나로 권한을 고정하는 RBAC만으로는 “같은 직급이라도 프로젝트에 따라 접근 범위가 달라야 한다”는 요구를 담기 어렵습니다.
비교: RBAC vs ABAC in AX
| 구분 | RBAC (역할 기반) | ABAC (속성 기반) |
|---|---|---|
| 권한 기준 | 직급·부서 등 고정 역할 | 사용자 속성 + 데이터 속성 + 환경(시점·목적·장소) |
| AX 적합성 | 단순 조회·승인에는 충분 | 프로젝트·맥락별 동적 접근에 적합 |
| 검색 단계 적용 | 역할별 인덱스 분리 | 속성 조합으로 검색 후보 필터링 |
| 관리 복잡도 | 낮음 (역할 수만큼) | 높음 (정책 규칙 수만큼) |
| 전형적 한계 | ”같은 직급, 다른 프로젝트” 구분 어려움 | 정책 설계·테스트·감사 비용 증가 |
| 권장 접근 | 기존 RBAC을 기반으로 유지 | 민감·동적 접근이 필요한 영역에 ABAC를 결합 |
이 표에서 보듯 ABAC는 RBAC을 대체하는 것이 아니라, 민감하고 동적인 접근이 필요한 영역에 결합하는 설계 선택지입니다. “모든 권한을 ABAC로 바꿔야 한다”는 뜻이 아닙니다. 기존 RBAC으로 충분한 영역은 유지하고, AI 에이전트가 여러 시스템·문서를 넘나들며 맥락별 접근이 필요한 영역에 ABAC를 검토하는 것이 현실적입니다.
AX의 최소 설계 단위: 모델-데이터-권한의 동시 설계
AX 과제는 다음 순서로 점검해 볼 수 있다.
- 업무 질문을 좁힌다. ‘AI로 혁신’ 대신 ‘설비 이상 보고서에서 원인 후보와 근거 문서를 5분 안에 찾는다’처럼 결과와 사용자를 정한다.
- 근거 데이터의 계약을 만든다. 데이터 소유자, 정의, 갱신 주기, 품질 기준, 사용 가능 범위를 명시한다.
- 권한을 검색 경로에 넣는다. 문서·레코드 분류와 사용자 속성을 연결해, 허용된 근거만 검색되도록 설계한다.
- 답변을 평가한다. 정확도뿐 아니라 근거 링크, 권한 위반 여부, 최신성, 사람이 수정한 비율을 함께 본다.
- 변화를 운영한다. 조직 이동, 프로젝트 종료, 문서 폐기, 정책 변경이 권한과 인덱스에 반영되는지 확인한다.
AI 위험 관리는 모델 출시 직전의 체크리스트가 아니라 설계·도입·운영 전 과정의 일이다. NIST AI RMF도 신뢰할 수 있는 AI를 위해 설계·개발·사용·평가 전 단계에 걸쳐 trustworthiness를 반영하는 자발적 프레임워크를 제공한다. AX에서 데이터 준비도와 데이터 권한을 분리할 수 없는 이유도 여기에 있다.
실무 사례: “5단계로 설계했더니, 파일럿이 운영이 됐다”
물류 기업 P사의 AX 프로젝트를 생각해 보겠습니다. P사는 “AI로 물류 혁신”이라는 거대한 목표로 시작했습니다. 6개월 동안 모델 선정, 벤더 비교, PoC를 반복했지만 현장에 안착하지 못했습니다.
팀장은 접근을 바꿨습니다. 다섯 단계로 좁혔습니다.
- 업무 질문: “배송 지연 사유를 5분 안에 분류하고, 책임 부서와 근거 문서를 찾는다”
- 데이터 계약: 배송 이력·고객 클레임·기상 데이터의 소유자·정의·갱신 주기를 명시
- 권한 설계: 배송팀·고객센터·경영진의 접근 범위를 데이터 분류와 연결
- 답변 평가: 정확도 + 근거 링크 + 권한 위반 여부 + 사람 수정 비율을 주간 리포트로 확인
- 변화 운영: 조직 개편·프로젝트 종료 시 권한·인덱스 자동 반영 절차 수립
이 구조에서 AI는 “모든 것을 답하는 챗봇”이 아니라, 특정 업무 질문에 대해 허용된 근거를 바탕으로 답을 만들고, 사람이 검증하고, 결과가 운영에 반영되는 흐름의 일부가 되었습니다. P사의 파일럿은 3개월 뒤 운영 단계로 전환되었습니다.
데이터 계약 체크리스트
| 점검 항목 | 확인 질문 | 미충족 시 증상 |
|---|---|---|
| 데이터 소유자 | 이 데이터의 책임 부서·담당자는 누구인가? | 문제 발생 시 “내 데이터가 아니다” 회피 |
| 정의·메타데이터 | 컬럼·지표·문서 용어가 표준화되어 있는가? | AI가 같은 용어를 다른 의미로 해석 |
| 갱신 주기 | 데이터가 언제, 어떻게 갱신되는가? | 오래된 데이터 기반 답변, 최신성 상실 |
| 품질 기준 | 결측·중복·오류의 허용 범위가 있는가? | AI 답변의 신뢰도 저하, 검증 비용 증가 |
| 사용 가능 범위 | 이 데이터를 AI 학습·검색·답변에 써도 되는가? | 법적·보안 리스크, 무단 사용 논란 |
| 접근 권한 | 누가, 어떤 맥락에서 이 데이터에 접근하는가? | 민감 데이터 노출, 권한 위반 답변 |
| 변경 이력 | 데이터 정의·권한 변경이 기록되는가? | 감사 불가, 문제 추적 불가 |
결론: AI Ready의 기준은 ‘답할 수 있음’이 아니다
좋은 AX는 가장 많은 데이터를 연결한 시스템이 아니다. 필요한 사람이 필요한 순간에, 허용된 근거를 바탕으로 실행 가능한 답을 얻는 시스템이다. 그래서 AX 로드맵의 첫 질문은 “어떤 모델을 쓸까?”보다 “이 업무 질문에 필요한 데이터의 의미·책임·권한은 준비돼 있는가?”가 되어야 한다.
독자 질문
우리 조직의 AI 시스템은 “답할 수 있는가”를 기준으로 설계되어 있는가, 아니면 “필요한 사람이, 허용된 근거로, 실행 가능한 답을 얻는가”를 기준으로 설계되어 있는가?
확인한 출처 / 근거
- NIST, “AI Risk Management Framework (AI RMF 1.0)”, 2023-01-26 (현재 개정 중) — AI 시스템의 trustworthiness를 설계·개발·사용·평가 전 단계에서 다루는 자발적 프레임워크.
- NIST SP 800-162, “Guide to Attribute Based Access Control (ABAC) Definition and Considerations” (Update 2) — ABAC 정의: 주체(subject)·객체(object)·요청 작업(requested operations)·환경(environment) 속성 기반 접근통제.
- NIST SP 800-53 Rev. 5, “Security and Privacy Controls for Information Systems and Organizations” (Update 1) — 보안·프라이버시 통제 표준.
- 참고: 이 글에서 AI Ready Data는 운영적 정의(의미·품질·연결성·출처)이며 특정 표준의 공식 정의가 아님. ABAC는 만능 해법이 아닌 RBAC와의 결합 선택지. 검색 단계 권한 적용은 설계 권고이며 보편 규칙이 아님. 모든 사례(N사·O사·P사)는 가상 예시.